From ltru-bounces@ietf.org Wed Aug 01 08:43: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 1IGDYR-0004GK-Ki; Wed, 01 Aug 2007 08:43:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGDYR-0004GA-3t for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 08:43:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDYQ-0004G1-Lv for ltru@ietf.org; Wed, 01 Aug 2007 08:43:54 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGDYQ-0005OM-3r for ltru@ietf.org; Wed, 01 Aug 2007 08:43:54 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.0) with ESMTP id md50006994044.msg for ; Wed, 01 Aug 2007 13:45:35 +0100 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 01 Aug 2007 13:43:50 +0100 From: "Debbie Garside" To: , "'Marion Gunn'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 13:43:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46AF5A83.5040805@yahoo-inc.com> Thread-Index: AcfTiuL0UERwVPNRTraOzSg9fkL58gAriYbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Processed: mx1.nexbyte.net, Wed, 01 Aug 2007 13:45:35 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1733a74405=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, 01 Aug 2007 13:45:36 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Message-Id: 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: > A tag can be valid yet meaningless. I don't really like this as it seems, on the face of it, a contradiction in terms. I would propose one of the following: --- A tag can be well formed yet meaningless. A tag can be well formed in terms of syntax, and thus valid, yet meaningless in terms of its attributes. For example, ... --- Best Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 31 July 2007 16:52 > To: Marion Gunn > Cc: LTRU Working Group > Subject: Re: [Ltru] Updated draft-4646bis... > > Marion Gunn wrote: > > > > However, here goes with one more attempt: > > > > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > as used in > Columbia, > written in Cyrillic script) is > valid, it is [most] unlikely to be of > use, because > such > combination of attributes is unlikely to occur in actual > language > use." > > > > I note that it is useful to look at the actual editor's copy > when suggesting minor editorial changes. Upon reflection, I > found the current sentence to be a bit of a run-on. I've > taken your suggestion of 'unlikely' and edited further such > that the paragraph now reads: > > Validity of a tag is not everything. A tag can be valid > yet meaningless. This is unavoidable with a generative system > like the language subtag mechanism. For example, a tag such > as "ar-Cyrl-CO" > (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > However, it is unlikely to be a useful tag, as it represents > an unlikely combination of language attributes that is > probably unrelated to any real language usage. > > After five minutes from now, you will need to comment on > draft-08. I'm always happy to consider editorial changes that > improve the text. > > 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 > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 10:38: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 1IGFLk-0002oy-P3; Wed, 01 Aug 2007 10:38:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGFLj-0002oi-Is for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 10:38:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFLj-0002oV-6Q for ltru@ietf.org; Wed, 01 Aug 2007 10:38:55 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGFLi-00012H-GX for ltru@ietf.org; Wed, 01 Aug 2007 10:38:54 -0400 Received: (qmail 61326 messnum 11062282 invoked from network[194.125.174.91/ts09-091.dublin.indigo.ie]); 1 Aug 2007 14:38:53 -0000 Received: from ts09-091.dublin.indigo.ie (HELO ?194.125.174.91?) (194.125.174.91) by mail11.svc.cra.dublin.eircom.net (qp 61326) with SMTP; 1 Aug 2007 14:38:53 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <0JM300JXKMMVP5O0@dakota.ucd.ie> References: <0JM300JXKMMVP5O0@dakota.ucd.ie> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <056F9985-F4E7-425D-8C73-12705FDEBCC4@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 15:39:15 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In that case, "well-formed" (although I see nothing wrong with =20 Addison's latest version, since even a bank account number can be, at =20= the same time, both "valid" and "meaningless" if no actual bank =20 account exists). mg On 1 Aug 2007, at 12:43, Debbie Garside: > Addison wrote: > > >> A tag can be valid yet meaningless. >> > > I don't really like this as it seems, on the face of it, a =20 > contradiction in > terms. I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet =20 > meaningless > in terms of its attributes. For example, ... > > --- > > Best > > Debbie > > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 31 July 2007 16:52 >> To: Marion Gunn >> Cc: LTRU Working Group >> Subject: Re: [Ltru] Updated draft-4646bis... >> >> Marion Gunn wrote: >> >>> >>> However, here goes with one more attempt: >>> >>> "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, >>> >> as used in > Columbia, > written in Cyrillic script) is >> valid, it is [most] unlikely to be of > use, because > such >> combination of attributes is unlikely to occur in actual >> language > use." >> >>> >>> >> >> I note that it is useful to look at the actual editor's copy >> when suggesting minor editorial changes. Upon reflection, I >> found the current sentence to be a bit of a run-on. I've >> taken your suggestion of 'unlikely' and edited further such >> that the paragraph now reads: >> >> Validity of a tag is not everything. A tag can be valid >> yet meaningless. This is unavoidable with a generative system >> like the language subtag mechanism. For example, a tag such >> as "ar-Cyrl-CO" >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. >> However, it is unlikely to be a useful tag, as it represents >> an unlikely combination of language attributes that is >> probably unrelated to any real language usage. >> >> After five minutes from now, you will need to comment on >> draft-08. I'm always happy to consider editorial changes that >> improve the text. >> >> 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 >> >> >> > > > > > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 11:33: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 1IGGCN-00067t-IE; Wed, 01 Aug 2007 11:33:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGGCM-0005vx-K3 for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGCM-0005s8-6Y for ltru@ietf.org; Wed, 01 Aug 2007 11:33:18 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGCK-0001b3-Aq for ltru@ietf.org; Wed, 01 Aug 2007 11:33:18 -0400 Received: from [86.132.150.255] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 109950059; Wed, 01 Aug 2007 16:33:12 +0100 From: "David Dalby" To: , , "'Marion Gunn'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 16:33:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfTiuL0UERwVPNRTraOzSg9fkL58gAriYbQAAXyrVA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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! David _____________________________________________________ Dr David Dalby The Linguasphere Observatory Hebron Whitland Wales SA34 0XT -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 01 August 2007 13:44 To: addison@yahoo-inc.com; 'Marion Gunn' Cc: 'LTRU Working Group' Subject: RE: [Ltru] Updated draft-4646bis... Addison wrote: > A tag can be valid yet meaningless. I don't really like this as it seems, on the face of it, a contradiction in terms. I would propose one of the following: --- A tag can be well formed yet meaningless. A tag can be well formed in terms of syntax, and thus valid, yet meaningless in terms of its attributes. For example, ... --- Best Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 31 July 2007 16:52 > To: Marion Gunn > Cc: LTRU Working Group > Subject: Re: [Ltru] Updated draft-4646bis... > > Marion Gunn wrote: > > > > However, here goes with one more attempt: > > > > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > as used in > Columbia, > written in Cyrillic script) is > valid, it is [most] unlikely to be of > use, because > such > combination of attributes is unlikely to occur in actual > language > use." > > > > I note that it is useful to look at the actual editor's copy > when suggesting minor editorial changes. Upon reflection, I > found the current sentence to be a bit of a run-on. I've > taken your suggestion of 'unlikely' and edited further such > that the paragraph now reads: > > Validity of a tag is not everything. A tag can be valid > yet meaningless. This is unavoidable with a generative system > like the language subtag mechanism. For example, a tag such > as "ar-Cyrl-CO" > (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > However, it is unlikely to be a useful tag, as it represents > an unlikely combination of language attributes that is > probably unrelated to any real language usage. > > After five minutes from now, you will need to comment on > draft-08. I'm always happy to consider editorial changes that > improve the text. > > 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 > > _______________________________________________ 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 Aug 01 11: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 1IGGLV-00083i-JG; Wed, 01 Aug 2007 11:42:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGGLU-00083b-Dk for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGLU-00083T-4E for ltru@ietf.org; Wed, 01 Aug 2007 11:42:44 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGLS-0001p9-On for ltru@ietf.org; Wed, 01 Aug 2007 11:42:44 -0400 Received: from [86.132.150.255] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 109952152; Wed, 01 Aug 2007 16:42:40 +0100 From: "David Dalby" To: "'David Dalby'" , , , "'Marion Gunn'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 16:42:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfTiuL0UERwVPNRTraOzSg9fkL58gAriYbQAAXyrVAAADitkA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Why not(?): A langtag may be formally valid but remain unrealized in meaning, e.g. .... -----Original Message----- From: David Dalby [mailto:daviddalby@linguasphere.info] Sent: 01 August 2007 16:33 To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com; 'Marion Gunn' Cc: 'LTRU Working Group' Subject: RE: [Ltru] Updated draft-4646bis... I agree! David _____________________________________________________ Dr David Dalby The Linguasphere Observatory Hebron Whitland Wales SA34 0XT -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 01 August 2007 13:44 To: addison@yahoo-inc.com; 'Marion Gunn' Cc: 'LTRU Working Group' Subject: RE: [Ltru] Updated draft-4646bis... Addison wrote: > A tag can be valid yet meaningless. I don't really like this as it seems, on the face of it, a contradiction in terms. I would propose one of the following: --- A tag can be well formed yet meaningless. A tag can be well formed in terms of syntax, and thus valid, yet meaningless in terms of its attributes. For example, ... --- Best Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 31 July 2007 16:52 > To: Marion Gunn > Cc: LTRU Working Group > Subject: Re: [Ltru] Updated draft-4646bis... > > Marion Gunn wrote: > > > > However, here goes with one more attempt: > > > > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > as used in > Columbia, > written in Cyrillic script) is > valid, it is [most] unlikely to be of > use, because > such > combination of attributes is unlikely to occur in actual > language > use." > > > > I note that it is useful to look at the actual editor's copy > when suggesting minor editorial changes. Upon reflection, I > found the current sentence to be a bit of a run-on. I've > taken your suggestion of 'unlikely' and edited further such > that the paragraph now reads: > > Validity of a tag is not everything. A tag can be valid > yet meaningless. This is unavoidable with a generative system > like the language subtag mechanism. For example, a tag such > as "ar-Cyrl-CO" > (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > However, it is unlikely to be a useful tag, as it represents > an unlikely combination of language attributes that is > probably unrelated to any real language usage. > > After five minutes from now, you will need to comment on > draft-08. I'm always happy to consider editorial changes that > improve the text. > > 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 > > _______________________________________________ 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 Aug 01 11:48: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 1IGGQv-0003AP-AW; Wed, 01 Aug 2007 11:48:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGGQu-0003AK-Sx for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:48:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGQu-0003AC-IG for ltru@ietf.org; Wed, 01 Aug 2007 11:48:20 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGGQu-0002kq-6f for ltru@ietf.org; Wed, 01 Aug 2007 11:48:20 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 787221C0100; Wed, 1 Aug 2007 17:48:19 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 73F5D1C00FA; Wed, 1 Aug 2007 17:48:19 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 70EA358EBF0; Wed, 1 Aug 2007 17:48:19 +0200 (CEST) Date: Wed, 1 Aug 2007 17:48:19 +0200 From: Stephane Bortzmeyer To: Debbie Garside Message-ID: <20070801154819.GA13548@nic.fr> References: <46AF5A83.5040805@yahoo-inc.com> 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-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'LTRU Working Group' Subject: [Ltru] The third level of conformance (Was: Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 01, 2007 at 01:43:40PM +0100, Debbie Garside wrote a message of 83 lines which said: > I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet meaningless > in terms of its attributes. For example, ... Sorry, neither of these sentences is correct in the context of 4646bis-07. Being "well-formed" and being "valid" are two different things (section 2.2.9 of 4646bis-07). Thus saying "A tag can be well formed in terms of syntax, and thus valid" is wrong. And the first sentence is not strong enough. ar-Cyrl-CO is well-formed but it is also valid (in the 4646bis-07 sense of the word, defined in section 2.2.9). The discussion is how we should label the informal "third level", after well-formedness and validity. Meaningfulness? Reality? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 11:52: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 1IGGV2-0005Vc-IY; Wed, 01 Aug 2007 11:52:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGGV0-0005VU-Ks for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:52:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGV0-0005VL-32 for ltru@ietf.org; Wed, 01 Aug 2007 11:52:34 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGGUz-0002wT-Ed for ltru@ietf.org; Wed, 01 Aug 2007 11:52:34 -0400 Received: from [10.72.72.164] (snvvpn1-10-72-72-c164.corp.yahoo.com [10.72.72.164]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l71FpuI4033542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 08:51:56 -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=IKP442Dtos7itj2PnTKNJa5CgyKv0gzaDsRB0TkEPAHh6p7MHQRdisXKT326ojKY Message-ID: <46B0AC1B.60702@yahoo-inc.com> Date: Wed, 01 Aug 2007 08:51:55 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: David Dalby Subject: Re: [Ltru] Updated draft-4646bis... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 You have to read the document. The terms "valid" and "well-formed" have a different meaning in the context of RFC 4646/4646bis. The term "valid" was chosen carefully in this context. Mark and others are correct that every tag has *a* meaning (we even spell out the one for the "meaningless" tag in the example). But that does not mean that every tag is *meaningful*. How about this version instead: Validity of a tag is not everything. While every valid tag has a meaning, it might not represent any real language usage. This is unavoidable in a system in which subtags can be combined freely. For example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in Antarctica, IPA phonetic transcription) are both valid and unlikely to represent a useful combination of language attributes. Addison David Dalby wrote: > I agree! > > David > > _____________________________________________________ > > Dr David Dalby > The Linguasphere Observatory > Hebron > Whitland > Wales > SA34 0XT > > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 01 August 2007 13:44 > To: addison@yahoo-inc.com; 'Marion Gunn' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Updated draft-4646bis... > > Addison wrote: > >> A tag can be valid yet meaningless. > > I don't really like this as it seems, on the face of it, a contradiction in > terms. I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet meaningless > in terms of its attributes. For example, ... > > --- > > Best > > Debbie > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 31 July 2007 16:52 >> To: Marion Gunn >> Cc: LTRU Working Group >> Subject: Re: [Ltru] Updated draft-4646bis... >> >> Marion Gunn wrote: >> > >> > However, here goes with one more attempt: >> > >> > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, >> as used in > Columbia, > written in Cyrillic script) is >> valid, it is [most] unlikely to be of > use, because > such >> combination of attributes is unlikely to occur in actual >> language > use." >> > >> >> I note that it is useful to look at the actual editor's copy >> when suggesting minor editorial changes. Upon reflection, I >> found the current sentence to be a bit of a run-on. I've >> taken your suggestion of 'unlikely' and edited further such >> that the paragraph now reads: >> >> Validity of a tag is not everything. A tag can be valid >> yet meaningless. This is unavoidable with a generative system >> like the language subtag mechanism. For example, a tag such >> as "ar-Cyrl-CO" >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. >> However, it is unlikely to be a useful tag, as it represents >> an unlikely combination of language attributes that is >> probably unrelated to any real language usage. >> >> After five minutes from now, you will need to comment on >> draft-08. I'm always happy to consider editorial changes that >> improve the text. >> >> 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 >> >> > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 12:06: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 1IGGi7-0005fj-OP; Wed, 01 Aug 2007 12:06:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGGi6-0005el-1K for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 12:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGi5-0005d8-N4 for ltru@ietf.org; Wed, 01 Aug 2007 12:06:05 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGi4-0002Uy-4u for ltru@ietf.org; Wed, 01 Aug 2007 12:06:05 -0400 Received: by nz-out-0506.google.com with SMTP id n1so102538nzf for ; Wed, 01 Aug 2007 09:06:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=dsriaLt4x5duMIRYxOXbjAmSXuIBXzTxtZ1X9tv3EG0czdt7OHF9ROE767U0nyGexvumMUVUh9R/0JVTopOpXMdOGea7ILHxmVDsW/NnTDWwU+UAgs52wZ2AttXd0qlYJVDoPta2PjPAhaagfg9DLIfhspV3IEJREPBqBN+4tRc= 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=j3fB177nrmejKDBRazZevhCSSUk30lNxsJkqYdm+pLqY5dkNqlgMR5RKIfXGzma/up1WIqmkKNJYe3E2v8avKqIs7lu7N3/syjX99vrUs+67e0YBZ6ACn0CJ5eQ+j1e6EREjgA+U6Hcj64SiO6FjeVFCkDN9kjhO6GIuVe7ItRk= Received: by 10.114.126.1 with SMTP id y1mr873866wac.1185984361481; Wed, 01 Aug 2007 09:06:01 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 1 Aug 2007 09:06:01 -0700 (PDT) Message-ID: <30b660a20708010906k40b2ea20sf289241aefb1c047@mail.gmail.com> Date: Wed, 1 Aug 2007 09:06:01 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Updated draft-4646bis... In-Reply-To: <46B0AC1B.60702@yahoo-inc.com> MIME-Version: 1.0 References: <46B0AC1B.60702@yahoo-inc.com> X-Google-Sender-Auth: 460a007deb2814ab X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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="===============1551637073==" Errors-To: ltru-bounces@ietf.org --===============1551637073== Content-Type: multipart/alternative; boundary="----=_Part_82500_13886436.1185984361350" ------=_Part_82500_13886436.1185984361350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That's fine by me. On 8/1/07, Addison Phillips wrote: > > You have to read the document. The terms "valid" and "well-formed" have > a different meaning in the context of RFC 4646/4646bis. The term "valid" > was chosen carefully in this context. > > Mark and others are correct that every tag has *a* meaning (we even > spell out the one for the "meaningless" tag in the example). But that > does not mean that every tag is *meaningful*. > > How about this version instead: > > > Validity of a tag is not everything. While every valid tag has a > meaning, it might not represent any real language usage. This is > unavoidable in a system in which subtags can be combined freely. For > example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in > Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in > Antarctica, IPA phonetic transcription) are both valid and unlikely to > represent a useful combination of language attributes. > > Addison > > David Dalby wrote: > > I agree! > > > > David > > > > _____________________________________________________ > > > > Dr David Dalby > > The Linguasphere Observatory > > Hebron > > Whitland > > Wales > > SA34 0XT > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: 01 August 2007 13:44 > > To: addison@yahoo-inc.com; 'Marion Gunn' > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Updated draft-4646bis... > > > > Addison wrote: > > > >> A tag can be valid yet meaningless. > > > > I don't really like this as it seems, on the face of it, a contradiction > in > > terms. I would propose one of the following: > > > > --- > > A tag can be well formed yet meaningless. > > > > A tag can be well formed in terms of syntax, and thus valid, yet > meaningless > > in terms of its attributes. For example, ... > > > > --- > > > > Best > > > > Debbie > > > >> -----Original Message----- > >> From: Addison Phillips [mailto:addison@yahoo-inc.com] > >> Sent: 31 July 2007 16:52 > >> To: Marion Gunn > >> Cc: LTRU Working Group > >> Subject: Re: [Ltru] Updated draft-4646bis... > >> > >> Marion Gunn wrote: > >> > > >> > However, here goes with one more attempt: > >> > > >> > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > >> as used in > Columbia, > written in Cyrillic script) is > >> valid, it is [most] unlikely to be of > use, because > such > >> combination of attributes is unlikely to occur in actual > >> language > use." > >> > > >> > >> I note that it is useful to look at the actual editor's copy > >> when suggesting minor editorial changes. Upon reflection, I > >> found the current sentence to be a bit of a run-on. I've > >> taken your suggestion of 'unlikely' and edited further such > >> that the paragraph now reads: > >> > >> Validity of a tag is not everything. A tag can be valid > >> yet meaningless. This is unavoidable with a generative system > >> like the language subtag mechanism. For example, a tag such > >> as "ar-Cyrl-CO" > >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > >> However, it is unlikely to be a useful tag, as it represents > >> an unlikely combination of language attributes that is > >> probably unrelated to any real language usage. > >> > >> After five minutes from now, you will need to comment on > >> draft-08. I'm always happy to consider editorial changes that > >> improve the text. > >> > >> 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 > >> > >> > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_82500_13886436.1185984361350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That's fine by me.

On 8/1/07, Addison Phillips <addison@yahoo-inc.com> wrote:
You have to read the document. The terms "valid" and "well-formed" have
a different meaning in the context of RFC 4646/4646bis. The term "valid"
was chosen carefully in this context.

Mark and others are correct that every tag has *a* meaning (we even
spell out the one for the "meaningless" tag in the example). But that
does not mean that every tag is *meaningful*.

How about this version instead:


<t>Validity of a tag is not everything. While every valid tag has a
meaning, it might not represent any real language usage. This is
unavoidable in a system in which subtags can be combined freely. For
example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in
Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in
Antarctica, IPA phonetic transcription) are both valid and unlikely to
represent a useful combination of language attributes.</t>

Addison

David Dalby wrote:
> I agree!
>
> David
>
>  _____________________________________________________
>
> Dr David Dalby
> The Linguasphere Observatory
> Hebron
> Whitland
> Wales
> SA34 0XT
>
> -----Original Message-----
> From: Debbie Garside [mailto: debbie@ictmarketing.co.uk]
> Sent: 01 August 2007 13:44
> To: addison@yahoo-inc.com; 'Marion Gunn'
> Cc: 'LTRU Working Group'
> Subject: RE: [Ltru] Updated draft-4646bis...
>
> Addison wrote:
>
>> A tag can be valid yet meaningless.
>
> I don't really like this as it seems, on the face of it, a contradiction in
> terms.  I would propose one of the following:
>
> ---
> A tag can be well formed yet meaningless.
>
> A tag can be well formed in terms of syntax, and thus valid, yet meaningless
> in terms of its attributes. For example, ...
>
> ---
>
> Best
>
> Debbie
>
>> -----Original Message-----
>> From: Addison Phillips [mailto:addison@yahoo-inc.com]
>> Sent: 31 July 2007 16:52
>> To: Marion Gunn
>> Cc: LTRU Working Group
>> Subject: Re: [Ltru] Updated draft-4646bis...
>>
>> Marion Gunn wrote:
>>  >
>>  > However, here goes with one more attempt:
>>  >
>>  > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic,
>> as used in  > Columbia,  > written in Cyrillic script) is
>> valid, it is [most] unlikely to be of  > use, because  > such
>> combination of attributes is unlikely to occur in actual
>> language  > use."
>>  >
>>
>> I note that it is useful to look at the actual editor's copy
>> when suggesting minor editorial changes. Upon reflection, I
>> found the current sentence to be a bit of a run-on. I've
>> taken your suggestion of 'unlikely' and edited further such
>> that the paragraph now reads:
>>
>> <t>Validity of a tag is not everything. A tag can be valid
>> yet meaningless. This is unavoidable with a generative system
>> like the language subtag mechanism. For example, a tag such
>> as "ar-Cyrl-CO"
>> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid.
>> However, it is unlikely to be a useful tag, as it represents
>> an unlikely combination of language attributes that is
>> probably unrelated to any real language usage.</t>
>>
>> After five minutes from now, you will need to comment on
>> draft-08. I'm always happy to consider editorial changes that
>> improve the text.
>>
>> 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
>>
>>
>
>
>
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
>
>

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

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_82500_13886436.1185984361350-- --===============1551637073== 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 --===============1551637073==-- From ltru-bounces@ietf.org Wed Aug 01 15: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 1IGJfb-0001nu-3k; Wed, 01 Aug 2007 15:15:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGJfR-0001eb-PY for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 15:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJfR-0001eS-El; Wed, 01 Aug 2007 15:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJfQ-0008W8-Lh; Wed, 01 Aug 2007 15:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 60CD21760A; Wed, 1 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IGJev-0001Xv-Vf; Wed, 01 Aug 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 01 Aug 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4646bis-07.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-07.txt Pages : 74 Date : 2007-8-1 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-07.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-07.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-07.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-8-1142740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4646bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4646bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-1142740.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 Wed Aug 01 16:22: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 1IGKiB-0005Ca-6D; Wed, 01 Aug 2007 16:22:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGKi9-0005CO-Ay for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 16:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKi9-0005CG-14 for ltru@ietf.org; Wed, 01 Aug 2007 16:22:25 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGKi6-00010y-Uk for ltru@ietf.org; Wed, 01 Aug 2007 16:22:24 -0400 Received: from [86.132.150.255] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 109992662; Wed, 01 Aug 2007 21:22:19 +0100 From: "David Dalby" To: "'Addison Phillips'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 21:22:19 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUVWVJlv5taHzxTs2eWUfDlUPCUwAIxMFg In-Reply-To: <46B0AC1B.60702@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e233469409eae36784776b094a259e13 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="===============2016907536==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============2016907536== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0206_01C7D482.0B74F600" This is a multi-part message in MIME format. ------=_NextPart_000_0206_01C7D482.0B74F600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Addison, You seem to have missed the second in my quick sequence of two e-mails. What is wrong with the simple statement (?): "A langtag may be formally valid but remain unrealized in meaning, e.g. ...." This even allows for the unlikely event of its meaning becoming realized. Of course, the large majority of ALL potential langtags with subtags will never be realized in meaning, but this very obvious point should surely be dealt with as briefly as possible. Regards, David -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: 01 August 2007 16:52 To: David Dalby Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' Subject: Re: [Ltru] Updated draft-4646bis... You have to read the document. The terms "valid" and "well-formed" have a different meaning in the context of RFC 4646/4646bis. The term "valid" was chosen carefully in this context. Mark and others are correct that every tag has *a* meaning (we even spell out the one for the "meaningless" tag in the example). But that does not mean that every tag is *meaningful*. How about this version instead: Validity of a tag is not everything. While every valid tag has a meaning, it might not represent any real language usage. This is unavoidable in a system in which subtags can be combined freely. For example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in Antarctica, IPA phonetic transcription) are both valid and unlikely to represent a useful combination of language attributes. Addison David Dalby wrote: > I agree! > > David > > _____________________________________________________ > > Dr David Dalby > The Linguasphere Observatory > Hebron > Whitland > Wales > SA34 0XT > > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 01 August 2007 13:44 > To: addison@yahoo-inc.com; 'Marion Gunn' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Updated draft-4646bis... > > Addison wrote: > >> A tag can be valid yet meaningless. > > I don't really like this as it seems, on the face of it, a contradiction in > terms. I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet meaningless > in terms of its attributes. For example, ... > > --- > > Best > > Debbie > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 31 July 2007 16:52 >> To: Marion Gunn >> Cc: LTRU Working Group >> Subject: Re: [Ltru] Updated draft-4646bis... >> >> Marion Gunn wrote: >> > >> > However, here goes with one more attempt: >> > >> > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, >> as used in > Columbia, > written in Cyrillic script) is >> valid, it is [most] unlikely to be of > use, because > such >> combination of attributes is unlikely to occur in actual >> language > use." >> > >> >> I note that it is useful to look at the actual editor's copy >> when suggesting minor editorial changes. Upon reflection, I >> found the current sentence to be a bit of a run-on. I've >> taken your suggestion of 'unlikely' and edited further such >> that the paragraph now reads: >> >> Validity of a tag is not everything. A tag can be valid >> yet meaningless. This is unavoidable with a generative system >> like the language subtag mechanism. For example, a tag such >> as "ar-Cyrl-CO" >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. >> However, it is unlikely to be a useful tag, as it represents >> an unlikely combination of language attributes that is >> probably unrelated to any real language usage. >> >> After five minutes from now, you will need to comment on >> draft-08. I'm always happy to consider editorial changes that >> improve the text. >> >> 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 >> >> > > > > > > > _______________________________________________ > 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. ------=_NextPart_000_0206_01C7D482.0B74F600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Addison, You seem = to have missed the second in my quick sequence of two e-mails. What is wrong = with the simple statement (?):

"A langtag = may be formally valid but remain unrealized in meaning, e.g. ...."  = This even allows for the unlikely event of its meaning becoming = realized.

Of course, the = large majority of ALL potential langtags with subtags will never be realized in = meaning, but this very obvious point should surely be dealt with as briefly as = possible.

Regards, = David

 

-----Original Message-----
From: Addison Phillips [mailto:addison@yahoo-inc.com]
Sent: 01 August 2007 16:52
To: David Dalby
Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group'
Subject: Re: [Ltru] Updated draft-4646bis...

 

You have to read the document. The terms "valid" and "well-formed" have

a different meaning in the context of RFC 4646/4646bis. The term "valid"

was chosen carefully in this = context.

 

Mark and others are correct that every tag has *a* meaning (we = even

spell out the one for the "meaningless" tag in the = example). But that

does not mean that every tag is = *meaningful*.

 

How about this version instead:

 

 

<t>Validity of a tag is not everything. While every valid = tag has a

meaning, it might not represent any real language usage. This is =

unavoidable in a system in which subtags can be combined freely. = For

example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic = script, as used in

Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in =

Antarctica, IPA = phonetic transcription) are both valid and unlikely to

represent a useful combination of language = attributes.</t>

 

Addison

 

David Dalby wrote:

> I agree!

>

> David

>

>  = _____________________________________________________

> 

> Dr David Dalby

> The Linguasphere Observatory

> Hebron

> Whitland

> Wales

> SA34 0XT

> 

> -----Original Message-----

> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] =

> Sent: 01 August 2007 13:44

> To: addison@yahoo-inc.com; 'Marion = Gunn'

> Cc: 'LTRU Working Group'

> Subject: RE: [Ltru] Updated = draft-4646bis...

>

> Addison = wrote:

>

>> A tag can be valid yet = meaningless.

>

> I don't really like this as it seems, on the face of it, a contradiction in

> terms.  I would propose one of the = following:

>

> ---

> A tag can be well formed yet = meaningless.

>

> A tag can be well formed in terms of syntax, and thus = valid, yet meaningless

> in terms of its attributes. For example, ... =

>

> ---

>

> Best

>

> Debbie

>

>> -----Original Message-----

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

>> Sent: 31 July 2007 16:52

>> To: Marion Gunn

>> Cc: LTRU Working Group

>> Subject: Re: [Ltru] Updated = draft-4646bis...

>> 

>> Marion Gunn wrote:

>>  >

>>  > However, here goes with one more = attempt:

>>  >

>>  > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic,

>> as used in  > Columbia,  > written in Cyrillic script) is

>> valid, it is [most] unlikely to be of  > use, because  > such

>> combination of attributes is unlikely to occur in = actual

>> language  > = use."

>>  >

>> 

>> I note that it is useful to look at the actual editor's = copy

>> when suggesting minor editorial changes. Upon = reflection, I

>> found the current sentence to be a bit of a run-on. = I've

>> taken your suggestion of 'unlikely' and edited further = such

>> that the paragraph now = reads:

>> 

>> <t>Validity of a tag is not everything. A tag can = be valid

>> yet meaningless. This is unavoidable with a generative = system

>> like the language subtag mechanism. For example, a tag = such

>> as "ar-Cyrl-CO"

>> (Arabic, Cyrillic script, as used in = Colombia) is perfectly valid.

>> However, it is unlikely to be a useful tag, as it = represents

>> an unlikely combination of language attributes that is =

>> probably unrelated to any real language = usage.</t>

>> 

>> After five minutes from now, you will need to comment = on

>> draft-08. I'm always happy to consider editorial = changes that

>> improve the text.

>> 

>> Addison

>> 

>> --

>> Addison Phillips

>> Globalization Architect -- Yahoo! = Inc.

>> Chair -- W3C Internationalization Core = WG

>> 

>> Internationalization is an = architecture.

>> It is not a feature.

>> 

>> 

>> = _______________________________________________<= /p>

>> Ltru mailing list

>> Ltru@ietf.org

>> = https://www1.ietf.org/mailman/listinfo/ltru

>> 

>> 

>

>

>

>

>

>

> = _______________________________________________<= /p>

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

------=_NextPart_000_0206_01C7D482.0B74F600-- --===============2016907536== 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 --===============2016907536==-- From ltru-bounces@ietf.org Wed Aug 01 16:32: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 1IGKro-0004oq-Uz; Wed, 01 Aug 2007 16:32:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGKrn-0004oi-NC for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 16:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKrm-0004oa-Sm for ltru@ietf.org; Wed, 01 Aug 2007 16:32:23 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGKrl-0001IG-Dw for ltru@ietf.org; Wed, 01 Aug 2007 16:32:22 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.0) with ESMTP id md50006996216.msg for ; Wed, 01 Aug 2007 21:34:03 +0100 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 01 Aug 2007 21:32:17 +0100 From: "Debbie Garside" To: , "'David Dalby'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 21:32:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46B0AC1B.60702@yahoo-inc.com> Thread-Index: AcfUVDVOOcX1IJW2QaeMPcjByzkrbwAI5LkA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Processed: mx1.nexbyte.net, Wed, 01 Aug 2007 21:34:03 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1733a74405=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, 01 Aug 2007 21:34:05 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Message-Id: 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 still don't think it sounds right :-) but I take the point made about well formed and valid. How about: The syntax of a language sub tag is such that it is possible to create a valid subtag where the sum of its component attributes may not represent a meaningful combination within actual language usage. For example, etc. Or Validity of a language subtag does not necessarily make it meaningful. A subtag can be valid in terms of syntax yet meaningless in terms of real language usage. For example, etc. Best Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 01 August 2007 16:52 > To: David Dalby > Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' > Subject: Re: [Ltru] Updated draft-4646bis... > > You have to read the document. The terms "valid" and > "well-formed" have a different meaning in the context of RFC > 4646/4646bis. The term "valid" > was chosen carefully in this context. > > Mark and others are correct that every tag has *a* meaning > (we even spell out the one for the "meaningless" tag in the > example). But that does not mean that every tag is *meaningful*. > > How about this version instead: > > > Validity of a tag is not everything. While every valid tag > has a meaning, it might not represent any real language > usage. This is unavoidable in a system in which subtags can > be combined freely. For example, tags such as "ar-Cyrl-CO" > (Arabic, Cyrillic script, as used in Colombia ) or > "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in > Antarctica, IPA phonetic transcription) are both valid and > unlikely to represent a useful combination of language attributes. > > Addison > > David Dalby wrote: > > I agree! > > > > David > > > > _____________________________________________________ > > > > Dr David Dalby > > The Linguasphere Observatory > > Hebron > > Whitland > > Wales > > SA34 0XT > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: 01 August 2007 13:44 > > To: addison@yahoo-inc.com; 'Marion Gunn' > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Updated draft-4646bis... > > > > Addison wrote: > > > >> A tag can be valid yet meaningless. > > > > I don't really like this as it seems, on the face of it, a > > contradiction in terms. I would propose one of the following: > > > > --- > > A tag can be well formed yet meaningless. > > > > A tag can be well formed in terms of syntax, and thus valid, yet > > meaningless in terms of its attributes. For example, ... > > > > --- > > > > Best > > > > Debbie > > > >> -----Original Message----- > >> From: Addison Phillips [mailto:addison@yahoo-inc.com] > >> Sent: 31 July 2007 16:52 > >> To: Marion Gunn > >> Cc: LTRU Working Group > >> Subject: Re: [Ltru] Updated draft-4646bis... > >> > >> Marion Gunn wrote: > >> > > >> > However, here goes with one more attempt: > >> > > >> > "For example, although a tag such as 'ar-Cyrl-CO' > (Arabic, as used > >> in > Columbia, > written in Cyrillic script) is valid, > it is [most] > >> unlikely to be of > use, because > such combination of > attributes > >> is unlikely to occur in actual language > use." > >> > > >> > >> I note that it is useful to look at the actual editor's copy when > >> suggesting minor editorial changes. Upon reflection, I found the > >> current sentence to be a bit of a run-on. I've taken your > suggestion > >> of 'unlikely' and edited further such that the paragraph now reads: > >> > >> Validity of a tag is not everything. A tag can be valid yet > >> meaningless. This is unavoidable with a generative system like the > >> language subtag mechanism. For example, a tag such as "ar-Cyrl-CO" > >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > >> However, it is unlikely to be a useful tag, as it represents an > >> unlikely combination of language attributes that is probably > >> unrelated to any real language usage. > >> > >> After five minutes from now, you will need to comment on draft-08. > >> I'm always happy to consider editorial changes that > improve the text. > >> > >> 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 > >> > >> > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 17:02: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 1IGLLG-0000M6-Sl; Wed, 01 Aug 2007 17:02:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGLLG-0000M0-8O for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLLF-0000Ls-Uq for ltru@ietf.org; Wed, 01 Aug 2007 17:02:49 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGLLE-00021N-9Z for ltru@ietf.org; Wed, 01 Aug 2007 17:02:49 -0400 Received: by nz-out-0506.google.com with SMTP id n1so158966nzf for ; Wed, 01 Aug 2007 14:02:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=JGh8Km5m3wnmtw2TxsFc1vlY57hCHLGBKf+ygWQon1K8uDhwUToNczTh92BLCyxc1q4Ycdo+S/SSr6q1NJbnrTS/Fkr1/RPDJrGP9tMNABWcBdq1iaYZiteipyOHZXoA3FIarsnW38d2UMTAnujSdq7xm8yml7/BTVetFYu85FM= 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=ogkt4ydUYSs+9jmmLIg/tdfnCugzVY4vFvvaeWR9ck3CoRqw0OwlK8uRwwRng9nwvXOs6O0RVDJ5ymGT4PhMHGJzs77aGvVWf8CGavFyWUNsBrHgUOFpFaGLoPUtCjD7vWTtiFjawgd6ji3RNRC+SjV53exy+kICxzEigJPo5O0= Received: by 10.114.154.1 with SMTP id b1mr1115024wae.1186002167337; Wed, 01 Aug 2007 14:02:47 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 1 Aug 2007 14:02:47 -0700 (PDT) Message-ID: <30b660a20708011402g15978b32y2ed693e91007b1c0@mail.gmail.com> Date: Wed, 1 Aug 2007 14:02:47 -0700 From: "Mark Davis" To: "David Dalby" Subject: Re: [Ltru] Updated draft-4646bis... In-Reply-To: MIME-Version: 1.0 References: <46B0AC1B.60702@yahoo-inc.com> X-Google-Sender-Auth: da71df634334695f X-Spam-Score: 0.0 (/) X-Scan-Signature: aafd3813f49c1dfb11e9623a3ab5d812 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="===============0614015006==" Errors-To: ltru-bounces@ietf.org --===============0614015006== Content-Type: multipart/alternative; boundary="----=_Part_88679_5889058.1186002167233" ------=_Part_88679_5889058.1186002167233 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The phrase "remain unrealized in meaning" is very odd, and certainly not very clear. Normally if I "realize the meaning" of something, I understand it. That is not at all what is being talked about. >the sum of its component attributes may not represent a meaningful combination within actual language usage We are not "summing" attributes, and the combinations ARE meaningful. People are confusing a "meaningful" with "currently applicable to existing instances". These are just not the same, and confusing them makes for fuzzy and inappropriate language. - "articulate US president" is perfectly meaningful, but has no existing instances - "colorless green ideas" is not meaningful, and has no existing instances - "controversial US president" is both meaningful, and has existing instances Addisons phrasing is fine. Mark BTW, there are very few times where I have call to use my PhD these days, so its nice to find an application for it ;-) On 8/1/07, David Dalby wrote: > > Addison, You seem to have missed the second in my quick sequence of two > e-mails. What is wrong with the simple statement (?): > > "A langtag may be formally valid but remain unrealized in meaning, e.g. > ...." This even allows for the unlikely event of its meaning becoming > realized. > > Of course, the large majority of ALL potential langtags with subtags will > never be realized in meaning, but this very obvious point should surely be > dealt with as briefly as possible. > > Regards, David > > > > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 01 August 2007 16:52 > To: David Dalby > Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' > Subject: Re: [Ltru] Updated draft-4646bis... > > > > You have to read the document. The terms "valid" and "well-formed" have > > a different meaning in the context of RFC 4646/4646bis. The term "valid" > > was chosen carefully in this context. > > > > Mark and others are correct that every tag has *a* meaning (we even > > spell out the one for the "meaningless" tag in the example). But that > > does not mean that every tag is *meaningful*. > > > > How about this version instead: > > > > > > Validity of a tag is not everything. While every valid tag has a > > meaning, it might not represent any real language usage. This is > > unavoidable in a system in which subtags can be combined freely. For > > example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in > > Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in > > Antarctica, IPA phonetic transcription) are both valid and unlikely to > > represent a useful combination of language attributes. > > > > Addison > > > > David Dalby wrote: > > > I agree! > > > > > > David > > > > > > _____________________________________________________ > > > > > > Dr David Dalby > > > The Linguasphere Observatory > > > Hebron > > > Whitland > > > Wales > > > SA34 0XT > > > > > > -----Original Message----- > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > Sent: 01 August 2007 13:44 > > > To: addison@yahoo-inc.com; 'Marion Gunn' > > > Cc: 'LTRU Working Group' > > > Subject: RE: [Ltru] Updated draft-4646bis... > > > > > > Addison wrote: > > > > > >> A tag can be valid yet meaningless. > > > > > > I don't really like this as it seems, on the face of it, a contradiction > in > > > terms. I would propose one of the following: > > > > > > --- > > > A tag can be well formed yet meaningless. > > > > > > A tag can be well formed in terms of syntax, and thus valid, yet > meaningless > > > in terms of its attributes. For example, ... > > > > > > --- > > > > > > Best > > > > > > Debbie > > > > > >> -----Original Message----- > > >> From: Addison Phillips [mailto:addison@yahoo-inc.com] > > >> Sent: 31 July 2007 16:52 > > >> To: Marion Gunn > > >> Cc: LTRU Working Group > > >> Subject: Re: [Ltru] Updated draft-4646bis... > > >> > > >> Marion Gunn wrote: > > >> > > > >> > However, here goes with one more attempt: > > >> > > > >> > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > > >> as used in > Columbia, > written in Cyrillic script) is > > >> valid, it is [most] unlikely to be of > use, because > such > > >> combination of attributes is unlikely to occur in actual > > >> language > use." > > >> > > > >> > > >> I note that it is useful to look at the actual editor's copy > > >> when suggesting minor editorial changes. Upon reflection, I > > >> found the current sentence to be a bit of a run-on. I've > > >> taken your suggestion of 'unlikely' and edited further such > > >> that the paragraph now reads: > > >> > > >> Validity of a tag is not everything. A tag can be valid > > >> yet meaningless. This is unavoidable with a generative system > > >> like the language subtag mechanism. For example, a tag such > > >> as "ar-Cyrl-CO" > > >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > > >> However, it is unlikely to be a useful tag, as it represents > > >> an unlikely combination of language attributes that is > > >> probably unrelated to any real language usage. > > >> > > >> After five minutes from now, you will need to comment on > > >> draft-08. I'm always happy to consider editorial changes that > > >> improve the text. > > >> > > >> 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 > > >> > > >> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > -- > > Addison Phillips > > Globalization Architect -- Yahoo! Inc. > > Chair -- W3C Internationalization Core WG > > > > Internationalization is an architecture. > > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_88679_5889058.1186002167233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The phrase "remain unrealized in meaning" is very odd, and certainly not very clear. Normally if I "realize the meaning" of something, I understand it. That is not at all what is being talked about.

>the sum of its component attributes may not represent a meaningful combination within actual language usage

We are not "summing" attributes, and the combinations ARE meaningful.

People are confusing a "meaningful" with "currently applicable to existing instances". These are just not the same, and confusing them makes for fuzzy and inappropriate language.
  • "articulate US president" is perfectly meaningful, but has no existing instances
  • "colorless green ideas" is not meaningful, and has no existing instances
  • "controversial US president" is both meaningful, and has existing instances
Addisons phrasing is fine.

Mark

BTW, there are very few times where I have call to use my PhD these days, so its nice to find an application for it ;-)

On 8/1/07, David Dalby <daviddalby@linguasphere.info> wrote:

Addison, You seem to have missed the second in my quick sequence of two e-mails. What is wrong with the simple statement (?):

"A langtag may be formally valid but remain unrealized in meaning, e.g. ...."  This even allows for the unlikely event of its meaning becoming realized.

Of course, the large majority of ALL potential langtags with subtags will never be realized in meaning, but this very obvious point should surely be dealt with as briefly as possible.

Regards, David

 

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

Sent: 01 August 2007 16:52
To: David Dalby
Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group'
Subject: Re: [Ltru] Updated draft-4646bis...

 

You have to read the document. The terms "valid" and "well-formed" have

a different meaning in the context of RFC 4646/4646bis. The term "valid"

was chosen carefully in this context.

 

Mark and others are correct that every tag has *a* meaning (we even

spell out the one for the "meaningless" tag in the example). But that

does not mean that every tag is *meaningful*.

 

How about this version instead:

 

 

<t>Validity of a tag is not everything. While every valid tag has a

meaning, it might not represent any real language usage. This is

unavoidable in a system in which subtags can be combined freely. For

example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in

Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in

Antarctica, IPA phonetic transcription) are both valid and unlikely to

represent a useful combination of language attributes.</t>

 

Addison

 

David Dalby wrote:

> I agree!

>

> David

>

>  _____________________________________________________

> 

> Dr David Dalby

> The Linguasphere Observatory

> Hebron

> Whitland

> Wales

> SA34 0XT

> 

> -----Original Message-----

> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk ]

> Sent: 01 August 2007 13:44

> To: addison@yahoo-inc.com; 'Marion Gunn'

> Cc: 'LTRU Working Group'

> Subject: RE: [Ltru] Updated draft-4646bis...

>

> Addison wrote:

>

>> A tag can be valid yet meaningless.

>

> I don't really like this as it seems, on the face of it, a contradiction in

> terms.  I would propose one of the following:

>

> ---

> A tag can be well formed yet meaningless.

>

> A tag can be well formed in terms of syntax, and thus valid, yet meaningless

> in terms of its attributes. For example, ...

>

> ---

>

> Best

>

> Debbie

>

>> -----Original Message-----

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

>> Sent: 31 July 2007 16:52

>> To: Marion Gunn

>> Cc: LTRU Working Group

>> Subject: Re: [Ltru] Updated draft-4646bis...

>> 

>> Marion Gunn wrote:

>>  >

>>  > However, here goes with one more attempt:

>>  >

>>  > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic,

>> as used in  > Columbia,  > written in Cyrillic script) is

>> valid, it is [most] unlikely to be of  > use, because  > such

>> combination of attributes is unlikely to occur in actual

>> language  > use."

>>  >

>> 

>> I note that it is useful to look at the actual editor's copy

>> when suggesting minor editorial changes. Upon reflection, I

>> found the current sentence to be a bit of a run-on. I've

>> taken your suggestion of 'unlikely' and edited further such

>> that the paragraph now reads:

>> 

>> <t>Validity of a tag is not everything. A tag can be valid

>> yet meaningless. This is unavoidable with a generative system

>> like the language subtag mechanism. For example, a tag such

>> as "ar-Cyrl-CO"

>> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid.

>> However, it is unlikely to be a useful tag, as it represents

>> an unlikely combination of language attributes that is

>> probably unrelated to any real language usage.</t>

>> 

>> After five minutes from now, you will need to comment on

>> draft-08. I'm always happy to consider editorial changes that

>> improve the text.

>> 

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

>> 

>> 

>

>

>

>

>

>

> _______________________________________________

> Ltru mailing list

> Ltru@ietf.org

> https://www1.ietf.org/mailman/listinfo/ltru

>

>

 

--

Addison Phillips

Globalization Architect -- Yahoo! Inc.

Chair -- W3C Internationalization Core WG

 

Internationalization is an architecture.

It is not a feature.


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




--
Mark ------=_Part_88679_5889058.1186002167233-- --===============0614015006== 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 --===============0614015006==-- From ltru-bounces@ietf.org Wed Aug 01 17:09: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 1IGLS6-0002dM-7Z; Wed, 01 Aug 2007 17:09:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGLS4-0002dF-6U for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLS3-0002d7-TD for ltru@ietf.org; Wed, 01 Aug 2007 17:09:51 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGLS2-00029f-GD for ltru@ietf.org; Wed, 01 Aug 2007 17:09:51 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l71L9VSC066009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 14:09:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=zeU2wpnjFr+P4n0wUoKymmrYyjSpyrxhAy+RniBGOf7Cl3n2Q3mvqoia4+S1+I/p Message-ID: <46B0F68A.4060002@yahoo-inc.com> Date: Wed, 01 Aug 2007 14:09:30 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] Updated draft-4646bis... References: <200708012032.l71KWLxv093975@mrin2-b.corp.dcn.yahoo.com> In-Reply-To: <200708012032.l71KWLxv093975@mrin2-b.corp.dcn.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 > > The syntax of a language sub tag is such that it is possible to create a > valid subtag where the sum of its component attributes may not represent a > meaningful combination within actual language usage. For example, etc. I think my proposal says that (even allowing for s/subtag/tag/) far more nicely than this quite complex sentence. I also like Stephane's original proposal (around which mine is based and which was approved by this WG previously) in many ways. > > Or > > Validity of a language subtag does not necessarily make it meaningful. A > subtag can be valid in terms of syntax yet meaningless in terms of real > language usage. For example, etc. No. This runs up against what Mark said before. The tag always has a meaning. It just might not be a meaningful meaning :-). But saying so in a waggish way in an email is not the same as saying so in the document. I also fail to see how your proposal is any different from the equivalent portion of the proposed paragraph: >> Validity of a tag is not everything. While every valid tag >> has a meaning, it might not represent any real language >> usage. It is very helpful if you look at the text in the context of the document and provide full paragraphs of proposal. The difference between your proposals and mine (when excluding the examples) are editorial in nature. Addison -- Addison Phillips Co-Editor -- RFC 4646bis > > > Best > > Debbie > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 01 August 2007 16:52 >> To: David Dalby >> Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' >> Subject: Re: [Ltru] Updated draft-4646bis... >> >> You have to read the document. The terms "valid" and >> "well-formed" have a different meaning in the context of RFC >> 4646/4646bis. The term "valid" >> was chosen carefully in this context. >> >> Mark and others are correct that every tag has *a* meaning >> (we even spell out the one for the "meaningless" tag in the >> example). But that does not mean that every tag is *meaningful*. >> >> How about this version instead: >> >> >> Validity of a tag is not everything. While every valid tag >> has a meaning, it might not represent any real language >> usage. This is unavoidable in a system in which subtags can >> be combined freely. For example, tags such as "ar-Cyrl-CO" >> (Arabic, Cyrillic script, as used in Colombia ) or >> "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in >> Antarctica, IPA phonetic transcription) are both valid and >> unlikely to represent a useful combination of language attributes. >> >> Addison >> >> David Dalby wrote: >>> I agree! >>> >>> David >>> >>> _____________________________________________________ >>> >>> Dr David Dalby >>> The Linguasphere Observatory >>> Hebron >>> Whitland >>> Wales >>> SA34 0XT >>> >>> -----Original Message----- >>> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] >>> Sent: 01 August 2007 13:44 >>> To: addison@yahoo-inc.com; 'Marion Gunn' >>> Cc: 'LTRU Working Group' >>> Subject: RE: [Ltru] Updated draft-4646bis... >>> >>> Addison wrote: >>> >>>> A tag can be valid yet meaningless. >>> I don't really like this as it seems, on the face of it, a >>> contradiction in terms. I would propose one of the following: >>> >>> --- >>> A tag can be well formed yet meaningless. >>> >>> A tag can be well formed in terms of syntax, and thus valid, yet >>> meaningless in terms of its attributes. For example, ... >>> >>> --- >>> >>> Best >>> >>> Debbie >>> >>>> -----Original Message----- >>>> From: Addison Phillips [mailto:addison@yahoo-inc.com] >>>> Sent: 31 July 2007 16:52 >>>> To: Marion Gunn >>>> Cc: LTRU Working Group >>>> Subject: Re: [Ltru] Updated draft-4646bis... >>>> >>>> Marion Gunn wrote: >>>> > >>>> > However, here goes with one more attempt: >>>> > >>>> > "For example, although a tag such as 'ar-Cyrl-CO' >> (Arabic, as used >>>> in > Columbia, > written in Cyrillic script) is valid, >> it is [most] >>>> unlikely to be of > use, because > such combination of >> attributes >>>> is unlikely to occur in actual language > use." >>>> > >>>> >>>> I note that it is useful to look at the actual editor's copy when >>>> suggesting minor editorial changes. Upon reflection, I found the >>>> current sentence to be a bit of a run-on. I've taken your >> suggestion >>>> of 'unlikely' and edited further such that the paragraph now reads: >>>> >>>> Validity of a tag is not everything. A tag can be valid yet >>>> meaningless. This is unavoidable with a generative system like the >>>> language subtag mechanism. For example, a tag such as "ar-Cyrl-CO" >>>> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. >>>> However, it is unlikely to be a useful tag, as it represents an >>>> unlikely combination of language attributes that is probably >>>> unrelated to any real language usage. >>>> >>>> After five minutes from now, you will need to comment on draft-08. >>>> I'm always happy to consider editorial changes that >> improve the text. >>>> 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 >>>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >> -- >> Addison Phillips >> Globalization Architect -- Yahoo! Inc. >> Chair -- W3C Internationalization Core WG >> >> Internationalization is an architecture. >> It is not a feature. >> >> >> > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 01 17:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLbG-000225-5U; Wed, 01 Aug 2007 17:19:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGLbE-000220-Kf for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:19:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLbE-00021f-8S for ltru@ietf.org; Wed, 01 Aug 2007 17:19:20 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGLbA-0003by-Hl for ltru@ietf.org; Wed, 01 Aug 2007 17:19:17 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l71LIr52067026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 14:18:54 -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=ysRueKNEA3uWQZtvGH0oLvgbq3wzD+uLhxI2H33f0simRH3psshEMhVR/jNLNtRu Message-ID: <46B0F8BD.7050503@yahoo-inc.com> Date: Wed, 01 Aug 2007 14:18:53 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: David Dalby Subject: Re: [Ltru] Updated draft-4646bis... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 David, There is nothing wrong in terms of the *meaning* of your sentence :-). However, as a contributor, I suggested an alternative phrasing that also took into account other's suggestions on list, including a paragraph structure previously approved by this WG. I have not seen a groundswell of support for any particular version of the paragraph, so the issue is also not closed yet. David Dalby wrote: > Addison, You seem to have missed the second in my quick sequence of two > e-mails. No, I just don't feel obliged to respond to every email in the thread. > What is wrong with the simple statement (?): The proposed text is imprecisely worded. When suggesting replacement text, if you do not fully and completely spell it out, the editor is likely to need to edit it for consistency, which can defeat the proposed purpose. I attempted to take each person's suggestions and combine them into a single proposed text (or exclude bits of text or suggestions for various reasons expressed on the thread). Note: my proposals are always made as a contributor to the list and not as one of the editors. > > "A langtag may be formally valid but remain unrealized in meaning, e.g. > ...." This even allows for the unlikely event of its meaning becoming > realized. This text has several editorial problems with it. - We say "language tag", never "langtag" - The word "may" is one of the normative words from RFC 2119. We never use it except with its normative meaning. - As noted previously, we have defined "valid" to have a specific meaning. "Formally" is superfluous and could be confusing as a result. - We always spell out the Latin abbreviations "e.g." and "i.e." using their English equivalents ("for example" and "in other words"). Finally, you didn't include the example text itself, which includes some non-simple statements. I note that minor edits suggested out of context often make no sense when they are inserted in context. I fine it best to be careful to quote the entire proposed paragraph each time and in full to help avoid this. As a result, your suggestion is actually: A language tag might be valid but remain unrealized in meaning. For example, a tag such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in Colombia) is both valid and unlikely to represent a useful combination of language attributes. So, finally, the substantive part: I think that the phrase "remain unrealized in meaning" is somewhat obscure. A newbie, especially one who cannot avail herself of this list's mail archive, will have no idea what we're talking about. Thus I prefer my (actually an adaptation of Peter's) "might not represent any real language usage". Note that this formulation does allow for it to either have or acquire real language usage in the future. > > Of course, the large majority of ALL potential langtags with subtags will > never be realized in meaning, but this very obvious point should surely be > dealt with as briefly as possible. It was dealt with not-at-all in RFC's 1766, 3066, or 4646. The WG felt that some mention was warranted now. We're debating what form that mention should take. 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 Aug 01 17:29: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 1IGLkm-0001im-9j; Wed, 01 Aug 2007 17:29:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGLkk-0001dd-Gj for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLkk-0001by-62 for ltru@ietf.org; Wed, 01 Aug 2007 17:29:10 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGLki-0002XC-QO for ltru@ietf.org; Wed, 01 Aug 2007 17:29:10 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.0) with ESMTP id md50006996870.msg for ; Wed, 01 Aug 2007 22:30:50 +0100 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 01 Aug 2007 22:29:04 +0100 From: "Debbie Garside" To: Subject: RE: [Ltru] Updated draft-4646bis... Date: Wed, 1 Aug 2007 22:28:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46B0F68A.4060002@yahoo-inc.com> Thread-Index: AcfUgKajYQNwEqQGRxONFJa0T2uWTAAAI0AQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Processed: mx1.nexbyte.net, Wed, 01 Aug 2007 22:30:50 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1733a74405=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, 01 Aug 2007 22:30:52 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Message-Id: 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 It is this phrase " Validity of a tag is not everything." that I particularly dislike. But if the WG wish to adopt it who am I to disagree ;-) Mine was longwinded though. As to editorial in nature, is that not, partly, what this is about? I have been away from the WG for a while so am playing catch-up. If you just require technical comment I will be quiet on this. Best Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 01 August 2007 22:10 > To: debbie@ictmarketing.co.uk > Cc: 'David Dalby'; 'Marion Gunn'; 'LTRU Working Group' > Subject: Re: [Ltru] Updated draft-4646bis... > > > > > The syntax of a language sub tag is such that it is > possible to create > > a valid subtag where the sum of its component attributes may not > > represent a meaningful combination within actual language > usage. For example, etc. > > I think my proposal says that (even allowing for > s/subtag/tag/) far more nicely than this quite complex > sentence. I also like Stephane's original proposal (around > which mine is based and which was approved by this WG > previously) in many ways. > > > > > Or > > > > Validity of a language subtag does not necessarily make it > meaningful. A > > subtag can be valid in terms of syntax yet meaningless in > terms of real > > language usage. For example, etc. > > No. This runs up against what Mark said before. The tag always has a > meaning. It just might not be a meaningful meaning :-). But > saying so in > a waggish way in an email is not the same as saying so in the > document. > > I also fail to see how your proposal is any different from the > equivalent portion of the proposed paragraph: > > >> Validity of a tag is not everything. While every valid tag > >> has a meaning, it might not represent any real language > >> usage. > > It is very helpful if you look at the text in the context of the > document and provide full paragraphs of proposal. The > difference between > your proposals and mine (when excluding the examples) are > editorial in > nature. > > Addison > > > -- > Addison Phillips > Co-Editor -- RFC 4646bis > > > > > > > Best > > > > Debbie > > > >> -----Original Message----- > >> From: Addison Phillips [mailto:addison@yahoo-inc.com] > >> Sent: 01 August 2007 16:52 > >> To: David Dalby > >> Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' > >> Subject: Re: [Ltru] Updated draft-4646bis... > >> > >> You have to read the document. The terms "valid" and > >> "well-formed" have a different meaning in the context of RFC > >> 4646/4646bis. The term "valid" > >> was chosen carefully in this context. > >> > >> Mark and others are correct that every tag has *a* meaning > >> (we even spell out the one for the "meaningless" tag in the > >> example). But that does not mean that every tag is *meaningful*. > >> > >> How about this version instead: > >> > >> > >> Validity of a tag is not everything. While every valid tag > >> has a meaning, it might not represent any real language > >> usage. This is unavoidable in a system in which subtags can > >> be combined freely. For example, tags such as "ar-Cyrl-CO" > >> (Arabic, Cyrillic script, as used in Colombia ) or > >> "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in > >> Antarctica, IPA phonetic transcription) are both valid and > >> unlikely to represent a useful combination of language > attributes. > >> > >> Addison > >> > >> David Dalby wrote: > >>> I agree! > >>> > >>> David > >>> > >>> _____________________________________________________ > >>> > >>> Dr David Dalby > >>> The Linguasphere Observatory > >>> Hebron > >>> Whitland > >>> Wales > >>> SA34 0XT > >>> > >>> -----Original Message----- > >>> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > >>> Sent: 01 August 2007 13:44 > >>> To: addison@yahoo-inc.com; 'Marion Gunn' > >>> Cc: 'LTRU Working Group' > >>> Subject: RE: [Ltru] Updated draft-4646bis... > >>> > >>> Addison wrote: > >>> > >>>> A tag can be valid yet meaningless. > >>> I don't really like this as it seems, on the face of it, a > >>> contradiction in terms. I would propose one of the following: > >>> > >>> --- > >>> A tag can be well formed yet meaningless. > >>> > >>> A tag can be well formed in terms of syntax, and thus valid, yet > >>> meaningless in terms of its attributes. For example, ... > >>> > >>> --- > >>> > >>> Best > >>> > >>> Debbie > >>> > >>>> -----Original Message----- > >>>> From: Addison Phillips [mailto:addison@yahoo-inc.com] > >>>> Sent: 31 July 2007 16:52 > >>>> To: Marion Gunn > >>>> Cc: LTRU Working Group > >>>> Subject: Re: [Ltru] Updated draft-4646bis... > >>>> > >>>> Marion Gunn wrote: > >>>> > > >>>> > However, here goes with one more attempt: > >>>> > > >>>> > "For example, although a tag such as 'ar-Cyrl-CO' > >> (Arabic, as used > >>>> in > Columbia, > written in Cyrillic script) is valid, > >> it is [most] > >>>> unlikely to be of > use, because > such combination of > >> attributes > >>>> is unlikely to occur in actual language > use." > >>>> > > >>>> > >>>> I note that it is useful to look at the actual editor's > copy when > >>>> suggesting minor editorial changes. Upon reflection, I found the > >>>> current sentence to be a bit of a run-on. I've taken your > >> suggestion > >>>> of 'unlikely' and edited further such that the paragraph > now reads: > >>>> > >>>> Validity of a tag is not everything. A tag can be valid yet > >>>> meaningless. This is unavoidable with a generative > system like the > >>>> language subtag mechanism. For example, a tag such as > "ar-Cyrl-CO" > >>>> (Arabic, Cyrillic script, as used in Colombia) is > perfectly valid. > >>>> However, it is unlikely to be a useful tag, as it represents an > >>>> unlikely combination of language attributes that is probably > >>>> unrelated to any real language usage. > >>>> > >>>> After five minutes from now, you will need to comment on > draft-08. > >>>> I'm always happy to consider editorial changes that > >> improve the text. > >>>> 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 > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Thu Aug 02 02:33: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 1IGUFV-0000YQ-2u; Thu, 02 Aug 2007 02:33:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGUFU-0000YF-Fb for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 02:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGUFU-0000Y4-2Y for ltru@ietf.org; Thu, 02 Aug 2007 02:33:28 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGUFS-0004tM-JD for ltru@ietf.org; Thu, 02 Aug 2007 02:33:28 -0400 Received: from [86.132.150.255] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 110026800; Thu, 02 Aug 2007 07:33:24 +0100 From: "David Dalby" To: "'Addison Phillips'" Subject: RE: [Ltru] Updated draft-4646bis... Date: Thu, 2 Aug 2007 07:33:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUgZ8whcgjJ95XTaqOC4HEvukBrgASysEQ In-Reply-To: <46B0F8BD.7050503@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Thank you very much for your helpful e-mail. I shall try to observe the conventions you have set out, and to respond if anything further suggests itself. I also am just trying to catch up, after an absence on language research (including some of the practical implications and applications of tagging). David (Dalby) The Linguasphere Observatory Hebron SA34 0XT Wales -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: 01 August 2007 22:19 To: David Dalby Cc: debbie@ictmarketing.co.uk; 'Marion Gunn'; 'LTRU Working Group' Subject: Re: [Ltru] Updated draft-4646bis... David, There is nothing wrong in terms of the *meaning* of your sentence :-). However, as a contributor, I suggested an alternative phrasing that also took into account other's suggestions on list, including a paragraph structure previously approved by this WG. I have not seen a groundswell of support for any particular version of the paragraph, so the issue is also not closed yet. David Dalby wrote: > Addison, You seem to have missed the second in my quick sequence of two > e-mails. No, I just don't feel obliged to respond to every email in the thread. > What is wrong with the simple statement (?): The proposed text is imprecisely worded. When suggesting replacement text, if you do not fully and completely spell it out, the editor is likely to need to edit it for consistency, which can defeat the proposed purpose. I attempted to take each person's suggestions and combine them into a single proposed text (or exclude bits of text or suggestions for various reasons expressed on the thread). Note: my proposals are always made as a contributor to the list and not as one of the editors. > > "A langtag may be formally valid but remain unrealized in meaning, e.g. > ...." This even allows for the unlikely event of its meaning becoming > realized. This text has several editorial problems with it. - We say "language tag", never "langtag" - The word "may" is one of the normative words from RFC 2119. We never use it except with its normative meaning. - As noted previously, we have defined "valid" to have a specific meaning. "Formally" is superfluous and could be confusing as a result. - We always spell out the Latin abbreviations "e.g." and "i.e." using their English equivalents ("for example" and "in other words"). Finally, you didn't include the example text itself, which includes some non-simple statements. I note that minor edits suggested out of context often make no sense when they are inserted in context. I fine it best to be careful to quote the entire proposed paragraph each time and in full to help avoid this. As a result, your suggestion is actually: A language tag might be valid but remain unrealized in meaning. For example, a tag such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in Colombia) is both valid and unlikely to represent a useful combination of language attributes. So, finally, the substantive part: I think that the phrase "remain unrealized in meaning" is somewhat obscure. A newbie, especially one who cannot avail herself of this list's mail archive, will have no idea what we're talking about. Thus I prefer my (actually an adaptation of Peter's) "might not represent any real language usage". Note that this formulation does allow for it to either have or acquire real language usage in the future. > > Of course, the large majority of ALL potential langtags with subtags will > never be realized in meaning, but this very obvious point should surely be > dealt with as briefly as possible. It was dealt with not-at-all in RFC's 1766, 3066, or 4646. The WG felt that some mention was warranted now. We're debating what form that mention should take. 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 Aug 02 03:21: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 1IGV0G-0001jW-MU; Thu, 02 Aug 2007 03:21:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGV0F-0001jL-Fe for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 03:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGV0B-0001iu-BK for ltru@ietf.org; Thu, 02 Aug 2007 03:21:43 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGV09-0006ES-UF for ltru@ietf.org; Thu, 02 Aug 2007 03:21:43 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 51D851C010B; Thu, 2 Aug 2007 09:21:41 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4CA511C0109; Thu, 2 Aug 2007 09:21:41 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3F52158EBF0; Thu, 2 Aug 2007 09:21:41 +0200 (CEST) Date: Thu, 2 Aug 2007 09:21:41 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20070802072141.GA15254@nic.fr> References: <46AF5B86.3010207@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46AF5B86.3010207@yahoo-inc.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'LTRU Working Group' Subject: [Ltru] UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 31, 2007 at 08:55:50AM -0700, Addison Phillips wrote a message of 3166 lines which said: > Although the file format uses the UTF-8 encoding, unless > otherwise indicated, fields are restricted to the printable > characters from the US-ASCII [ISO646] repertoire. ... > The 'Description' field MAY thus include non-ASCII characters. I would prefer a positive wording: The 'Description' field MAY thus include UTF-8 characters. Yes, I know that ASCII characters are UTF-8, too but it seems clearer that we mention the encoding we allow, rather than the more limited one. [I used the Find function of my editor to find out which fields were authorized to have UTF-8 and I first discovered none.] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 02 04:20: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 1IGVv2-0002HH-TM; Thu, 02 Aug 2007 04:20:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGVv2-0002HC-AU for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 04:20:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVv1-0002H3-TY for ltru@ietf.org; Thu, 02 Aug 2007 04:20:27 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGVv1-0001JZ-Hc for ltru@ietf.org; Thu, 02 Aug 2007 04:20:27 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 105E01C0100; Thu, 2 Aug 2007 10:20:27 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0BA861C00FE; Thu, 2 Aug 2007 10:20:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 083B558EB9A; Thu, 2 Aug 2007 10:20:27 +0200 (CEST) Date: Thu, 2 Aug 2007 10:20:27 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20070802082027.GA10784@nic.fr> References: <46B0AC1B.60702@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <46B0AC1B.60702@yahoo-inc.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'LTRU Working Group' Subject: [Ltru] Re: Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 01, 2007 at 08:51:55AM -0700, Addison Phillips wrote=20 a message of 141 lines which said: > How about this version instead: Better than the one in 4646bis-07 (which uses the word "meaningless", while I recently noticed that "meaning" is used several times in the draft, in a different sense). What about adding also in 2.2.9. "Classes of Conformance": A tag is considered "real" if it is valid and if there are existing resources available which match that tag. Unlike "well-formedness" and "validity", "reality" is a fuzzy concept, and a moving one (new resources can appear, making a tag real, without any change in the registry). See . [Thanks to Philip Jos=E9 Farmer whose novel "The lovers" gave me the idea to define "reality" :-) ] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 02 08:54: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 1IGaCQ-0005H2-5O; Thu, 02 Aug 2007 08:54:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGaCO-0005Gw-9T for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 08:54:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaCN-0005Go-Va for ltru@ietf.org; Thu, 02 Aug 2007 08:54:40 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGaCN-0000fH-LQ for ltru@ietf.org; Thu, 02 Aug 2007 08:54:39 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IGaCH-0002Au-NH; Thu, 02 Aug 2007 08:54:33 -0400 Date: Thu, 2 Aug 2007 08:54:33 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 Message-ID: <20070802125433.GA11786@mercury.ccil.org> References: <46AF5B86.3010207@yahoo-inc.com> <20070802072141.GA15254@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070802072141.GA15254@nic.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.2 (/) 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 Stephane Bortzmeyer scripsit: > > The 'Description' field MAY thus include non-ASCII characters. > > I would prefer a positive wording: > > The 'Description' field MAY thus include UTF-8 characters. The point is that "ASCII" is both an encoding and a repertoire, whereas "UTF-8" is only an encoding. The meaning is that the Description field may contain characters that are not in the ASCII repertoire (whereas most other fields must not). The whole file is in the UTF-8 encoding. -- 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 Thu Aug 02 10:55: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 1IGc5h-0000ii-Nm; Thu, 02 Aug 2007 10:55:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGc5g-0000ib-Ku for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 10:55:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGc5g-0000iT-Ao for ltru@ietf.org; Thu, 02 Aug 2007 10:55:52 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGc5f-0003Vg-TB for ltru@ietf.org; Thu, 02 Aug 2007 10:55:52 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070802145550.AFD7001.mta16.adelphia.net@DGBP7M81>; Thu, 2 Aug 2007 10:55:50 -0400 Message-ID: <00b501c7d515$387e4fa0$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 2 Aug 2007 07:55:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> The 'Description' field MAY thus include non-ASCII characters. > > I would prefer a positive wording: > > The 'Description' field MAY thus include UTF-8 characters. > > Yes, I know that ASCII characters are UTF-8, too but it seems clearer > that we mention the encoding we allow, rather than the more limited > one. Making distinctions between "ASCII" and "UTF-8" (or "Unicode") tends to mislead people, and leads to such abominations as this, found in the online help for InterSystems Caché: "Valid characters may be 8-bit ASCII, or ISO Latin-1 Unicode." I would prefer something like "The 'Description' field MAY thus include characters outside the Basic Latin range." -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 02 11:04: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 1IGcDz-0000hE-Mr; Thu, 02 Aug 2007 11:04:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGcDx-0000cW-AM for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 11:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcDw-0000b6-9U for ltru@ietf.org; Thu, 02 Aug 2007 11:04:24 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGcDv-0002Br-1l for ltru@ietf.org; Thu, 02 Aug 2007 11:04:24 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070802150422.QZXO28634.mta9.adelphia.net@DGBP7M81>; Thu, 2 Aug 2007 11:04:22 -0400 Message-ID: <00b901c7d516$69663050$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 2 Aug 2007 08:04:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] Re: Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Better than the one in 4646bis-07 (which uses the word "meaningless", > while I recently noticed that "meaning" is used several times in the > draft, in a different sense). I agree with Mark and others who have pointed out this misuse of "meaningless." See Mark's posts for better examples than I can give. > What about adding also in 2.2.9. "Classes of Conformance": > > A tag is considered "real" if it is valid and if there are existing > resources available which match that tag. Unlike "well-formedness" and > "validity", "reality" is a fuzzy concept, and a moving one (new > resources can appear, making a tag real, without any change in the > registry). See . I strongly object to any attempts to define "real" or "reality" in the language tagging document. What do we want to be accused of? Addison's "it might not represent any real language usage" should be understandable to all. I might prefer "real-world" instead of "real," but that is nit-picking. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 02 11:15: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 1IGcOa-0003Zb-M4; Thu, 02 Aug 2007 11:15:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGcOZ-0003Yq-SC for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 11:15:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcOZ-0003Xx-Hu for ltru@ietf.org; Thu, 02 Aug 2007 11:15:23 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGcOY-00047z-OQ for ltru@ietf.org; Thu, 02 Aug 2007 11:15:23 -0400 Received: from [10.72.77.193] (snvvpn2-10-72-77-c193.corp.yahoo.com [10.72.77.193]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l72FFHbd057739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 08:15:17 -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=Gz2G80ZFB1+2Rp4atLvAB0MQTJUAL6LvjcGQ//WR05t1WR55KiHu7ni1m5k+lAwi Message-ID: <46B1F505.80803@yahoo-inc.com> Date: Thu, 02 Aug 2007 08:15:17 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <46B0AC1B.60702@yahoo-inc.com> <20070802082027.GA10784@nic.fr> In-Reply-To: <20070802082027.GA10784@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'LTRU Working Group' Subject: [Ltru] Re: Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > On Wed, Aug 01, 2007 at 08:51:55AM -0700, > Addison Phillips wrote > a message of 141 lines which said: > >> How about this version instead: > > Better than the one in 4646bis-07 (which uses the word "meaningless", > while I recently noticed that "meaning" is used several times in the > draft, in a different sense). The "five minutes" elapsed before the thread got into high gear. Draft-08 will have my proposed text or some similar formulation. > > What about adding also in 2.2.9. "Classes of Conformance": > > A tag is considered "real" if it is valid and if there are existing > resources available which match that tag. Unlike "well-formedness" and > "validity", "reality" is a fuzzy concept, and a moving one (new > resources can appear, making a tag real, without any change in the > registry). See . -1 It think this goes over the top. 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 Aug 02 11:20: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 1IGcTl-0008NB-4v; Thu, 02 Aug 2007 11:20:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGcTj-0008Mz-Jc for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 11:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcTh-0008Mr-Tn for ltru@ietf.org; Thu, 02 Aug 2007 11:20:43 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGcTg-0002ej-IS for ltru@ietf.org; Thu, 02 Aug 2007 11:20:41 -0400 Received: from [10.72.77.193] (snvvpn2-10-72-77-c193.corp.yahoo.com [10.72.77.193]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l72FKUOC058150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 08:20:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=qoesp0lUs+qJ0vctqSYg8Os4QuH5TucCXjjnB1BM2aK2tlP9R8x/gPyboUIMthph Message-ID: <46B1F63D.6080002@yahoo-inc.com> Date: Thu, 02 Aug 2007 08:20:29 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 References: <46AF5B86.3010207@yahoo-inc.com> <20070802072141.GA15254@nic.fr> <20070802125433.GA11786@mercury.ccil.org> In-Reply-To: <20070802125433.GA11786@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> >> The 'Description' field MAY thus include UTF-8 characters. > > The point is that "ASCII" is both an encoding and a repertoire, > whereas "UTF-8" is only an encoding. The meaning is that the > Description field may contain characters that are not in the > ASCII repertoire (whereas most other fields must not). The > whole file is in the UTF-8 encoding. > +1 If "non-ASCII" isn't sufficiently positive, a proper reformulation would be: -- The 'Description' field MAY include the full range of Unicode characters. At least one of the 'Description' fields MUST be written or transcribed into the Latin script; additional 'Description' fields MAY also include a description in a non-Latin script. -- Note that this reverses the existing order. The current text says: -- At least one of the 'Description' fields MUST be written or transcribed into the Latin script; additional 'Description' fields MAY also include a description in a non-Latin script. The 'Description' field MAY thus include non-ASCII characters. -- 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 Aug 02 11:22: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 1IGcVB-0001N3-K0; Thu, 02 Aug 2007 11:22:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGcV9-0001Mv-5D for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 11:22:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcV8-0001Mn-RO for ltru@ietf.org; Thu, 02 Aug 2007 11:22:10 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGcV8-0004Kr-GC for ltru@ietf.org; Thu, 02 Aug 2007 11:22:10 -0400 Received: from [10.72.77.193] (snvvpn2-10-72-77-c193.corp.yahoo.com [10.72.77.193]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l72FM1jl058295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 08:22:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=EreCM7mA8dCaxG1GWaX+qN8NJgbfbcmZH9Ky6FXFxryeEEiG2B0mK+poLCgDi3Jm Message-ID: <46B1F699.3010703@yahoo-inc.com> Date: Thu, 02 Aug 2007 08:22:01 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Updated draft-4646bis... References: <00b901c7d516$69663050$6a01a8c0@DGBP7M81> In-Reply-To: <00b901c7d516$69663050$6a01a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: I might prefer "real-world" instead of "real," > but that is nit-picking. > Nonetheless, I have included the hyphenated version. 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 Aug 02 13:08: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 1IGe9V-0000lv-93; Thu, 02 Aug 2007 13:07:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGe9U-0000lq-LH for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 13:07:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGe9U-0000lh-AX for ltru@ietf.org; Thu, 02 Aug 2007 13:07:56 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGe9T-0006l9-Qf for ltru@ietf.org; Thu, 02 Aug 2007 13:07:56 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 2 Aug 2007 10:07:52 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu, 2 Aug 2007 10:07:51 -0700 From: Peter Constable To: 'LTRU Working Group' Date: Thu, 2 Aug 2007 10:07:48 -0700 Subject: RE: [Ltru] Updated draft-4646bis... Thread-Topic: [Ltru] Updated draft-4646bis... Thread-Index: AcfTiuL0UERwVPNRTraOzSg9fkL58gAriYbQADuLb0A= Message-ID: References: <46AF5A83.5040805@yahoo-inc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org No, Mark had it right: there is a clear semantic. It just may not correspon= d to any reality. "ar-Cyrl-CO" unambiguously means 'Arabic language as used= in Colombia, written in Cyrllic script". It refers to a unicorn in the rea= lm of languages. Peter > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: Wednesday, August 01, 2007 5:44 AM > To: addison@yahoo-inc.com; 'Marion Gunn' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Updated draft-4646bis... > > Addison wrote: > > > A tag can be valid yet meaningless. > > I don't really like this as it seems, on the face of it, a > contradiction in > terms. I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet > meaningless > in terms of its attributes. For example, ... > > --- > > Best > > Debbie > > > -----Original Message----- > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > Sent: 31 July 2007 16:52 > > To: Marion Gunn > > Cc: LTRU Working Group > > Subject: Re: [Ltru] Updated draft-4646bis... > > > > Marion Gunn wrote: > > > > > > However, here goes with one more attempt: > > > > > > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, > > as used in > Columbia, > written in Cyrillic script) is > > valid, it is [most] unlikely to be of > use, because > such > > combination of attributes is unlikely to occur in actual > > language > use." > > > > > > > I note that it is useful to look at the actual editor's copy > > when suggesting minor editorial changes. Upon reflection, I > > found the current sentence to be a bit of a run-on. I've > > taken your suggestion of 'unlikely' and edited further such > > that the paragraph now reads: > > > > Validity of a tag is not everything. A tag can be valid > > yet meaningless. This is unavoidable with a generative system > > like the language subtag mechanism. For example, a tag such > > as "ar-Cyrl-CO" > > (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. > > However, it is unlikely to be a useful tag, as it represents > > an unlikely combination of language attributes that is > > probably unrelated to any real language usage. > > > > After five minutes from now, you will need to comment on > > draft-08. I'm always happy to consider editorial changes that > > improve the text. > > > > 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 > > > > > > > > > > > _______________________________________________ > 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 Aug 02 13:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGeGV-0006pD-K7; Thu, 02 Aug 2007 13:15:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGeGU-0006p8-E2 for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 13:15:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGeGU-0006oz-1o for ltru@ietf.org; Thu, 02 Aug 2007 13:15:10 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGeGT-0006sL-Gg for ltru@ietf.org; Thu, 02 Aug 2007 13:15:09 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 2 Aug 2007 10:15:08 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Thu, 2 Aug 2007 10:15:07 -0700 From: Peter Constable To: LTRU Working Group Date: Thu, 2 Aug 2007 10:15:06 -0700 Subject: RE: [Ltru] Updated draft-4646bis... Thread-Topic: [Ltru] Updated draft-4646bis... Thread-Index: AcfUVeD9R4rJYtWARGu01ogJ13q8ugA0h9rQ Message-ID: References: <46B0AC1B.60702@yahoo-inc.com> <30b660a20708010906k40b2ea20sf289241aefb1c047@mail.gmail.com> In-Reply-To: <30b660a20708010906k40b2ea20sf289241aefb1c047@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: 3d48d865303330c98a6e90d450cf2ff2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0516375607==" Errors-To: ltru-bounces@ietf.org --===============0516375607== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561A95A9456NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561A95A9456NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wah!? Combining the variant tag fonipa with Kore shouldn't be valid, though= I guess we don't have a way to block it at present. (It would take some aw= kward combination of "must have script subtag Latn" OR "must have a lang s= ubtag with Suppress-Script of 'Latn'".) But apart from that, the wording is fine. Peter From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Wednesday, August 01, 2007 9:06 AM To: Addison Phillips Cc: LTRU Working Group Subject: Re: [Ltru] Updated draft-4646bis... That's fine by me. On 8/1/07, Addison Phillips > wrote: You have to read the document. The terms "valid" and "well-formed" have a different meaning in the context of RFC 4646/4646bis. The term "valid" was chosen carefully in this context. Mark and others are correct that every tag has *a* meaning (we even spell out the one for the "meaningless" tag in the example). But that does not mean that every tag is *meaningful*. How about this version instead: Validity of a tag is not everything. While every valid tag has a meaning, it might not represent any real language usage. This is unavoidable in a system in which subtags can be combined freely. For example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in Antarctica, IPA phonetic transcription) are both valid and unlikely to represent a useful combination of language attributes. Addison David Dalby wrote: > I agree! > > David > > _____________________________________________________ > > Dr David Dalby > The Linguasphere Observatory > Hebron > Whitland > Wales > SA34 0XT > > -----Original Message----- > From: Debbie Garside [mailto: debbie@ictmarketing.co.uk] > Sent: 01 August 2007 13:44 > To: addison@yahoo-inc.com; 'Marion Gunn' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Updated draft-4646bis... > > Addison wrote: > >> A tag can be valid yet meaningless. > > I don't really like this as it seems, on the face of it, a contradiction = in > terms. I would propose one of the following: > > --- > A tag can be well formed yet meaningless. > > A tag can be well formed in terms of syntax, and thus valid, yet meaningl= ess > in terms of its attributes. For example, ... > > --- > > Best > > Debbie > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 31 July 2007 16:52 >> To: Marion Gunn >> Cc: LTRU Working Group >> Subject: Re: [Ltru] Updated draft-4646bis... >> >> Marion Gunn wrote: >> > >> > However, here goes with one more attempt: >> > >> > "For example, although a tag such as 'ar-Cyrl-CO' (Arabic, >> as used in > Columbia, > written in Cyrillic script) is >> valid, it is [most] unlikely to be of > use, because > such >> combination of attributes is unlikely to occur in actual >> language > use." >> > >> >> I note that it is useful to look at the actual editor's copy >> when suggesting minor editorial changes. Upon reflection, I >> found the current sentence to be a bit of a run-on. I've >> taken your suggestion of 'unlikely' and edited further such >> that the paragraph now reads: >> >> Validity of a tag is not everything. A tag can be valid >> yet meaningless. This is unavoidable with a generative system >> like the language subtag mechanism. For example, a tag such >> as "ar-Cyrl-CO" >> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid. >> However, it is unlikely to be a useful tag, as it represents >> an unlikely combination of language attributes that is >> probably unrelated to any real language usage. >> >> After five minutes from now, you will need to comment on >> draft-08. I'm always happy to consider editorial changes that >> improve the text. >> >> 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 >> >> > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561A95A9456NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wah!? Combining the variant tag fonipa with Kore shouldnR= 17;t be valid, though I guess we don’t have a way to block it at present. (It= would take some awkward combination of  “must have script subtag Latn&= #8221; OR “must have a lang subtag with Suppress-Script of ‘Latn’”.)

 

But apart from that, the wording is fine.<= /p>

 

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Wednesday, August 01, 2007 9:06 AM
To: Addison Phillips
Cc: LTRU Working Group
Subject: Re: [Ltru] Updated draft-4646bis...

 

That's fine by me.=

On 8/1/07, Addison Phillip= s <addison@yahoo-inc.com> = wrote:

You have to read the document. The terms "valid&q= uot; and "well-formed" have
a different meaning in the context of RFC 4646/4646bis. The term "valid"
was chosen carefully in this context.

Mark and others are correct that every tag has *a* meaning (we even
spell out the one for the "meaningless" tag in the example). But = that
does not mean that every tag is *meaningful*.

How about this version instead:


<t>Validity of a tag is not everything. While every valid tag has a meaning, it might not represent any real language usage. This is
unavoidable in a system in which subtags can be combined freely. For
example, tags such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as u= sed in
Colombia ) or "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as us= ed in
Antarctica, IPA phonetic transcription) are both valid and unlikely to
represent a useful combination of language attributes.</t>

Addison

David Dalby wrote:
> I agree!
>
> David
>
>  _____________________________________________________
>
> Dr David Dalby
> The Linguasphere Observatory
> Hebron
> Whitland
> Wales
> SA34 0XT
>
> -----Original Message-----
> From: Debbie Garside [mailto: debbie@ictmarketing.co.uk]
> Sent: 01 August 2007 13:44
> To: addison@yahoo-inc.com= ; 'Marion Gunn'
> Cc: 'LTRU Working Group'
> Subject: RE: [Ltru] Updated draft-4646bis...
>
> Addison wrote:
>
>> A tag can be valid yet meaningless.
>
> I don't really like this as it seems, on the face of it, a contradicti= on in
> terms.  I would propose one of the following:
>
> ---
> A tag can be well formed yet meaningless.
>
> A tag can be well formed in terms of syntax, and thus valid, yet meaningless
> in terms of its attributes. For example, ...
>
> ---
>
> Best
>
> Debbie
>
>> -----Original Message-----
>> From: Addison Phillips [mailto:addison@yahoo-inc.com]
>> Sent: 31 July 2007 16:52
>> To: Marion Gunn
>> Cc: LTRU Working Group
>> Subject: Re: [Ltru] Updated draft-4646bis...
>>
>> Marion Gunn wrote:
>>  >
>>  > However, here goes with one more attempt:
>>  >
>>  > "For example, although a tag such as 'ar-Cyrl= -CO' (Arabic,
>> as used in  > Columbia,  > written in Cyrillic script) is
>> valid, it is [most] unlikely to be of  > use, because  > such
>> combination of attributes is unlikely to occur in actual
>> language  > use."
>>  >
>>
>> I note that it is useful to look at the actual editor's copy
>> when suggesting minor editorial changes. Upon reflection, I
>> found the current sentence to be a bit of a run-on. I've
>> taken your suggestion of 'unlikely' and edited further such
>> that the paragraph now reads:
>>
>> <t>Validity of a tag is not everything. A tag can be valid <= br> >> yet meaningless. This is unavoidable with a generative system
>> like the language subtag mechanism. For example, a tag such
>> as "ar-Cyrl-CO"
>> (Arabic, Cyrillic script, as used in Colombia) is perfectly valid.=
>> However, it is unlikely to be a useful tag, as it represents
>> an unlikely combination of language attributes that is
>> probably unrelated to any real language usage.</t>
>>
>> After five minutes from now, you will need to comment on
>> draft-08. I'm always happy to consider editorial changes that
>> improve the text.
>>
>> 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://ww= w1.ietf.org/mailman/listinfo/ltru
>>
>>
>
>
>
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.i= etf.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.o= rg/mailman/listinfo/ltru




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561A95A9456NAEXMSGC117re_-- --===============0516375607== 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 --===============0516375607==-- From ltru-bounces@ietf.org Thu Aug 02 22:18: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 1IGmkU-00030i-A3; Thu, 02 Aug 2007 22:18:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGmkT-0002xG-An for ltru-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 22:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGmkT-0002w5-0F for ltru@ietf.org; Thu, 02 Aug 2007 22:18:41 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGmkR-0000gq-Ow for ltru@ietf.org; Thu, 02 Aug 2007 22:18:40 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070803021837.DDMP1161.mta15.adelphia.net@DGBP7M81> for ; Thu, 2 Aug 2007 22:18:37 -0400 Message-ID: <000f01c7d574$9a5d8010$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 2 Aug 2007 19:18:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > If "non-ASCII" isn't sufficiently positive, a proper reformulation > would be: > > -- > The 'Description' field MAY include the full range of Unicode > characters. At least one of the 'Description' fields MUST be written > or transcribed into the Latin script; additional 'Description' fields > MAY also include a description in a non-Latin script. I like this quite a bit, and one of the things I like about it is what it does NOT say. It does NOT say that at least one of the Description fields must be written or transcribed into pure ASCII. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 03 02:20: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 1IGqW5-0005nv-KK; Fri, 03 Aug 2007 02:20:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGqW4-0005iK-50 for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 02:20:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGqW3-0005gn-Pk for ltru@ietf.org; Fri, 03 Aug 2007 02:20:03 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGqW3-0006pi-Aa for ltru@ietf.org; Fri, 03 Aug 2007 02:20:03 -0400 Received: from [10.72.73.78] (snvvpn1-10-72-73-c78.corp.yahoo.com [10.72.73.78]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l736JKmx031406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 23:19:24 -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=S9PhWSJ4RfYelQlzZewDHijbufR6l3Xhbl0IlVa5kTK/bM05jNjT5shf+fuhh2Vn Message-ID: <46B2C8E7.2050808@yahoo-inc.com> Date: Thu, 02 Aug 2007 23:19:19 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 References: <000f01c7d574$9a5d8010$6a01a8c0@DGBP7M81> In-Reply-To: <000f01c7d574$9a5d8010$6a01a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >> If "non-ASCII" isn't sufficiently positive, a proper reformulation >> would be: >> >> -- >> The 'Description' field MAY include the full range of Unicode >> characters. At least one of the 'Description' fields MUST be written >> or transcribed into the Latin script; additional 'Description' fields >> MAY also include a description in a non-Latin script. > > I like this quite a bit, and one of the things I like about it is what > it does NOT say. It does NOT say that at least one of the Description > fields must be written or transcribed into pure ASCII. > Cool. Although I note that this is not novel. RFC 4646 says exactly that. And on purpose too. Addison -- Addison Phillips Unicadet 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 Aug 03 09:46: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 1IGxTg-0004JU-0N; Fri, 03 Aug 2007 09:46:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGxTe-0004I4-HU for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 09:46:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxTe-0004Hv-7L for ltru@ietf.org; Fri, 03 Aug 2007 09:46:02 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGxTd-00032T-T7 for ltru@ietf.org; Fri, 03 Aug 2007 09:46:02 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070803134559.HFCJ28634.mta9.adelphia.net@DGBP7M81>; Fri, 3 Aug 2007 09:45:59 -0400 Message-ID: <005801c7d5d4$a05ab270$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000f01c7d574$9a5d8010$6a01a8c0@DGBP7M81> <46B2C8E7.2050808@yahoo-inc.com> Subject: Re: [Ltru] Re: UTF-8 in which field? (Was: draft-ietf-ltru-4646bis-07 Date: Fri, 3 Aug 2007 06:45:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> I like this quite a bit, and one of the things I like about it is >> what it does NOT say. It does NOT say that at least one of the >> Description fields must be written or transcribed into pure ASCII. > > Cool. Although I note that this is not novel. RFC 4646 says exactly > that. And on purpose too. Yes, but since it seems to have become a bit controversial of late, it's good to see that it isn't changing. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 03 10:15: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 1IGxw8-0006Pa-7B; Fri, 03 Aug 2007 10:15:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGxw7-0006Nc-53 for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 10:15:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxw6-0006Lb-L5 for ltru@ietf.org; Fri, 03 Aug 2007 10:15:26 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGxw6-0003sc-8C for ltru@ietf.org; Fri, 03 Aug 2007 10:15:26 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070803135821.WRPF16842.mta10.adelphia.net@DGBP7M81> for ; Fri, 3 Aug 2007 13:58:21 +0000 Message-ID: <007b01c7d5d6$5a871bb0$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 3 Aug 2007 06:58:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Wah!? Combining the variant tag fonipa with Kore shouldn't be valid, > though I guess we don't have a way to block it at present. (It would > take some awkward combination of "must have script subtag Latn" OR > "must have a lang subtag with Suppress-Script of 'Latn'".) Which is a place we really don't want to go. "Tag content wisely" is the best way to prevent such tags. But I would rather see a different language-script-region-variant combination that doesn't call quite so much attention to the ability to create semantically contradictory tags. The passage is supposed to be about semantically consistent tags that refer to non-existent language variations. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 03 10:39:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGyJp-0007CQ-4z; Fri, 03 Aug 2007 10:39:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGyJn-0007B9-KC for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 10:39:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGyJn-0007B0-AA for ltru@ietf.org; Fri, 03 Aug 2007 10:39:55 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGyJm-0004nj-SO for ltru@ietf.org; Fri, 03 Aug 2007 10:39:55 -0400 Received: from [10.72.73.78] (snvvpn1-10-72-73-c78.corp.yahoo.com [10.72.73.78]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l73EdCXS051980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 07:39:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mzwQiIZuJq7jmO61bT9vZL4BrBPQNVMyDDrG0bnwVG0DkthCxW37o+iBYGbqhu+f Message-ID: <46B33E12.4070108@yahoo-inc.com> Date: Fri, 03 Aug 2007 07:39:14 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Updated draft-4646bis... References: <007b01c7d5d6$5a871bb0$6a01a8c0@DGBP7M81> In-Reply-To: <007b01c7d5d6$5a871bb0$6a01a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug mentioned: > The passage is supposed to be > about semantically consistent tags that refer to non-existent language > variations. I'm not sure that it is. The section is about "valid-yet-useless" tags, which includes, I assume, absurdities. I didn't want to create an absurdity by ignoring Prefix. Thus the "problem" (if you can call it that) is a dearth of generic variants. We could use "tlh-Cyrl-AQ-fonupa", I suppose, or maybe "eu-Cyrl-SN-fonupa" (Basque, Cyrillic, Senegal, UPA transcription). 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 Aug 03 11:04:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGyh5-0004ak-OZ; Fri, 03 Aug 2007 11:03:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGyh4-0004ae-Qf for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 11:03:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGyh4-0004aW-Fy for ltru@ietf.org; Fri, 03 Aug 2007 11:03:58 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGyh4-0005c4-2d for ltru@ietf.org; Fri, 03 Aug 2007 11:03:58 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 3 Aug 2007 08:03:57 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 3 Aug 2007 08:03:56 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 3 Aug 2007 08:03:55 -0700 Subject: RE: [Ltru] Re: Updated draft-4646bis... Thread-Topic: [Ltru] Re: Updated draft-4646bis... Thread-Index: AcfV3C3hKVCcvorHTFy3cYkP/VOK2QAApIWA Message-ID: References: <007b01c7d5d6$5a871bb0$6a01a8c0@DGBP7M81> <46B33E12.4070108@yahoo-inc.com> In-Reply-To: <46B33E12.4070108@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.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 Arabic as used in Colombia written in Cyrillic is not an absurdity. It's pe= rfectly reasonable; it just doesn't happen to be real. But you do already have an absurdity: IPA transcription in Korean script: b= y definition, IPA must be in Latin script. (That's different from phonetic = transcription in Korean script, which does exist, BTW.) In your Klingon and Basque examples, the particular languages, script or re= gions used do not contribute to the absurdity, though some might wrongly pe= rceive that to be the case. It is only the combination of fonupa with Cyrl = that is absurd. Peter > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Friday, August 03, 2007 7:39 AM > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: Updated draft-4646bis... > > Doug mentioned: > > The passage is supposed to be > > about semantically consistent tags that refer to non-existent > language > > variations. > > I'm not sure that it is. The section is about "valid-yet-useless" tags, > which includes, I assume, absurdities. I didn't want to create an > absurdity by ignoring Prefix. Thus the "problem" (if you can call it > that) is a dearth of generic variants. > > We could use "tlh-Cyrl-AQ-fonupa", I suppose, or maybe > "eu-Cyrl-SN-fonupa" (Basque, Cyrillic, Senegal, UPA transcription). > > 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 03 16:43: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 1IH3zO-0001KI-1d; Fri, 03 Aug 2007 16:43:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IH3zM-0001K0-SI for ltru-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 16:43:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3zM-0001Jr-GA for ltru@ietf.org; Fri, 03 Aug 2007 16:43:12 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound2-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH3zL-0007UL-5g for ltru@ietf.org; Fri, 03 Aug 2007 16:43:12 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id 98E8613F92E9 for ; Fri, 3 Aug 2007 20:43:09 +0000 (UTC) Received: from mail91-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 8E2A352805B for ; Fri, 3 Aug 2007 20:43:09 +0000 (UTC) Received: from mail91-sin (localhost.localdomain [127.0.0.1]) by mail91-sin-R.bigfish.com (Postfix) with ESMTP id 5EA7E8801EA for ; Fri, 3 Aug 2007 20:43:09 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail91-sin (MessageSwitch) id 1186173789305763_23411; Fri, 3 Aug 2007 20:43:09 +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 mail91-sin.bigfish.com (Postfix) with ESMTP id B175E1480072 for ; Fri, 3 Aug 2007 20:43:08 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007080313425880-2185 ; Fri, 3 Aug 2007 13:42:58 -0700 In-Reply-To: To: LTRU Working Group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Fri, 3 Aug 2007 13:40:48 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/03/2007 13:40:47, Serialize complete at 08/03/2007 13:40:47, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/03/2007 01:42:58 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/03/2007 01:43:08 PM, Serialize complete at 08/03/2007 01:43:08 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Ltru] Question on variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0650721583==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0650721583== Content-Type: multipart/alternative; boundary="=_alternative 0071CC568825732C_=" This is a multipart message in MIME format. --=_alternative 0071CC568825732C_= Content-Type: text/plain; charset="US-ASCII" All, I need to update some tagging in a language list here at Sony Pictures. My current language requirement for Chinese languages is: Audio Languages: Used for dubbing and original language content. * Chinese (No other variant information known) = zh * Chinese (Mandarin, PRC) = zh-cmn-CN * Chinese (Mandarin, Taiwanese variant) = zh-cmn-TW * Chinese (Cantonese) = zh-yue * Chinese (Taiwanese) = zh-min-nan Text Languages: Used for localization of language other than the original language as well as captions and subtitles. Subtitles may also occur in an original version that features more than one language. * Chinese (No other variant information known) = zh * Chinese (Mandarin, Traditional) = zh-cmn-Hant * Chinese (Mandarin, Simplified) = zh-cmn-Hans * Chinese (Cantonese) = zh-yue * Chinese (Taiwanese) = zh-min-nan I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" will be preferred in RFC 4646bis. Of these tags, which are most likely to be deprecated in the new regime? It's unclear to me how I should code Mandarin, Cantonese, and Taiwanese if I want the best chance of being compatible with the preferred tagging to be determined by this committee at a later date. I thought this business scenario might help the discussion, if this issue is not resolved yet. I looked through the archive and it doesn't look like this issue is closed. To me, the "zh" in these tags (especially written language categories) seems helpful. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 0071CC568825732C_= Content-Type: text/html; charset="US-ASCII"
All,

I need to update some tagging in a language list here at Sony Pictures. My current language requirement for Chinese languages is:

Audio Languages: Used for dubbing and original language content.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, PRC) = zh-cmn-CN
* Chinese (Mandarin, Taiwanese variant) = zh-cmn-TW
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

Text Languages: Used for localization of language other than the original language as well as captions and subtitles. Subtitles may also occur in an original version that features more than one language.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, Traditional) = zh-cmn-Hant
* Chinese (Mandarin, Simplified) = zh-cmn-Hans
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" will be preferred in RFC 4646bis. Of these tags, which are most likely to be deprecated in the new regime? It's unclear to me how I should code Mandarin, Cantonese, and Taiwanese if I want the best chance of being compatible with the preferred tagging to be determined by this committee at a later date. I thought this business scenario might help the discussion, if this issue is not resolved yet. I looked through the archive and it doesn't look like this issue is closed. To me, the "zh" in these tags (especially written language categories) seems helpful.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
--=_alternative 0071CC568825732C_=-- --===============0650721583== 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 --===============0650721583==-- From ltru-bounces@ietf.org Sat Aug 04 12:29: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 1IHMV4-0002RE-AL; Sat, 04 Aug 2007 12:29:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IHMV2-0002J1-Cy for ltru-confirm+ok@megatron.ietf.org; Sat, 04 Aug 2007 12:29:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHMV2-0002HS-1a for ltru@ietf.org; Sat, 04 Aug 2007 12:29:08 -0400 Received: from mta14.mail.adelphia.net ([68.168.78.137] helo=mta14.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHMV1-0002yc-K7 for ltru@ietf.org; Sat, 04 Aug 2007 12:29:07 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070804162634.NVZI28634.mta9.adelphia.net@DGBP7M81>; Sat, 4 Aug 2007 12:26:34 -0400 Message-ID: <004b01c7d6b4$3a2fffb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 4 Aug 2007 09:26:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Karen_Broome@spe.sony.com Subject: [Ltru] Re: Question on variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org wrote: > I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" > will be preferred in RFC 4646bis. Of these tags, which are most likely > to be deprecated in the new regime? It's unclear to me how I should > code Mandarin, Cantonese, and Taiwanese if I want the best chance of > being compatible with the preferred tagging to be determined by this > committee at a later date. I thought this business scenario might help > the discussion, if this issue is not resolved yet. I looked through > the archive and it doesn't look like this issue is closed. The issue is not closed. I'm hoping to see a resolution in the near future so that I can write draft-4645bis-02 against the agreed-upon model (extlang, Macrolanguage, or both). Probably there will not be a quick resolution, and I will have to "fall back" to the model used by Addison in draft-4646bis-07 (i.e. "both"). For reference: Extlang model: Type: extlang Subtag: cmn Description: Mandarin Chinese Description: Chinese, Mandarin Added: 2029-09-09 Prefix: zh Macrolanguage model: Type: language Subtag: cmn Description: Mandarin Chinese Description: Chinese, Mandarin Added: 2029-09-09 Macrolanguage: zh "Both" model: Type: extlang Subtag: cmn Description: Mandarin Chinese Description: Chinese, Mandarin Added: 2029-09-09 Macrolanguage: zh Prefix: zh Note that in the "both" model, the Macrolanguage and Prefix fields are identical except in the few cases where the encompassed language already existed in ISO 639-2, and thus in the Registry. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 02:52: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 1IHwRl-0005Cw-8s; Mon, 06 Aug 2007 02:52:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IHwRj-0005Bq-NP for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 02:52:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwRi-0005Bi-JO for ltru@ietf.org; Mon, 06 Aug 2007 02:52:06 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHwRh-00070k-Vc for ltru@ietf.org; Mon, 06 Aug 2007 02:52:06 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070806065204.REEC6544.mta11.adelphia.net@DGBP7M81>; Mon, 6 Aug 2007 02:52:04 -0400 Message-ID: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 5 Aug 2007 23:52:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Michael Everson Subject: [Ltru] Apostrophes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 proposal for RFC 4645bis and ultimately for the registration process performed on the ietf-languages list, although I have not copied this message to that list. I expect it to be controversial, and I am willing to be talked out of it, but I believe it has merit. In arguing for the conversion of the Registry from hex NCRs to UTF-8, the issue of readability of both formats came up repeatedly. There were several calls, mostly from one participant, to supply an ASCII-only "compatibility" Registry, similar to the Latin-1-only code lists supplied by the ISO 639-2 and -3 maintenance agencies. There have also been proposals to add additional Description or Comments fields which simply duplicate the existing fields in plain ASCII. I don't support either of these approaches because non-ASCII characters are often an integral part of the description or comment, and will become even more so in the RFC 4646bis era, as we add pairs of languages whose names differ only by an accented vs. unaccented letter (such as Arua and Aruá; the latter is spelled A, r, u, a-with-acute). We need to maintain these distinctions to preserve the identity of the language or other entity represented by each subtag, which is what descriptions are for. However, there is one place where we could simplify, or regularize, the characters used in certain Description fields without sacrificing legibility, uniqueness, or identity. These are the various apostrophes and apostrophe-like modifier letters. Right now, the following apostrophes and modifier letters appear in Description fields in the Registry: U+0027 APOSTROPHE Description: Mi'kmaq Description: Ethiopic (Ge'ez) Description: Ol Chiki (Ol Cemet', Ol, Santali) Description: Côte d'Ivoire Description: Korea, Democratic People's Republic of Description: Lao People's Democratic Republic U+00B4 ACUTE ACCENT Description: Gwich´in U+02BB MODIFIER LETTER TURNED COMMA Description: Ethiopic (Geʻez) U+2019 RIGHT SINGLE QUOTATION MARK Description: N’Ko (both language and script) Most people seem to agree that the acute accent used in Gwich'in was a mistake, but we used it in the Registry anyway to be perfectly faithful to the source standard. RFC 4646, however, does not require this type of perfect fidelity, while draft-4646bis-07 adds only the following of relevance: "For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3." "Corresponds to" is not the same as "is character-for-character equivalent to." The ISO 639-3 data includes 117 names containing U+0027, and none containing any other form of apostrophe. This introduces a kind of inconsistency in which we have chosen certain types of apostrophes or apostrophe-like modifier letters in isolated cases, in a noble attempt to use "the right character," but also want to maintain fidelity with source standards that may not have this as a goal. We frankly don't know which of the names in ISO 639-3 really "should" use some other type of apostrophe; indeed, ISO 639-3 spells "N'Ko" with U+0027. In reality, even where U+0027 is not "the right character" for a given name, most users will expect to see it and to be able to search on it any time they see an apostrophe-like character. Unlike the various accented letters, the apostrophes all look pretty much the same in small type sizes. No Description fields in the Registry are now, or will be in the 4646bis era, distinguished only by the type of apostrophe used; this will not be true for other types of non-ASCII letters, as mentioned above. Likewise, it seems quite unlikely that any user will perform lexical analysis on Description or Comments fields, such that strings containing the "wrong" apostrophe will be processed incorrectly in some way. I propose the following: 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters that appear either in the current Registry or in one of the source standards be transformed to the plain ASCII apostrophe, U+0027. 2. Existing pairs of Description fields that differ only in the type of apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. 3. Future registrations use only U+0027 in place of other apostrophe-like characters. I believe items 1 and 2 affect only RFC 4645bis, but I invite the editors and others to check whether 4646bis is affected as well. Again, cogent arguments against this proposal are likely to be more productive than flames. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 05:01: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 1IHySw-0004U1-D1; Mon, 06 Aug 2007 05:01:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IHySu-0004Tt-Js for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 05:01:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHySu-0004Tk-9k for ltru@ietf.org; Mon, 06 Aug 2007 05:01:28 -0400 Received: from white.dnsireland.com ([67.15.182.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHySt-0002Kg-Q5 for ltru@ietf.org; Mon, 06 Aug 2007 05:01:27 -0400 Received: from [88.81.100.235] (helo=[192.168.1.126]) by white.dnsireland.com with esmtp (Exim 4.66) (envelope-from ) id 1IHySr-00013Q-Tj; Mon, 06 Aug 2007 10:01:26 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> Date: Mon, 6 Aug 2007 09:58:03 +0100 To: "Doug Ewell" , "LTRU Working Group" From: Michael Everson Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - white.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [Ltru] Re: Apostrophes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Why are you asking me, Doug? You know what my view is. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 12:43: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 1II5fU-00053g-Ei; Mon, 06 Aug 2007 12:42:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II5fT-00053a-BM for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 12:42:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5fT-00053S-1A for ltru@ietf.org; Mon, 06 Aug 2007 12:42:55 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II5fR-0004dy-Vv for ltru@ietf.org; Mon, 06 Aug 2007 12:42:54 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76GghXg022220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 09:42:46 -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=i+jEWbAb9e1Ze7ogKts7FzHVmV7hbiaglA8G1n8WP8hifG26E5Dl/o05//4APqwe Message-ID: <46B74F83.5060806@yahoo-inc.com> Date: Mon, 06 Aug 2007 09:42:43 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Apostrophes References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> In-Reply-To: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Michael Everson , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > > "Corresponds to" is not the same as "is character-for-character > equivalent to." > You're right, although I tend to think that "corresponds to" usually means "equals" rather than "is similar to". Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 12: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 1II5q9-0001hO-CT; Mon, 06 Aug 2007 12:53:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II5q7-0001hD-I9 for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 12:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5q7-0001h4-8e for ltru@ietf.org; Mon, 06 Aug 2007 12:53:55 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II5q5-0002Wy-Vm for ltru@ietf.org; Mon, 06 Aug 2007 12:53:55 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76GrdIQ023421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 09:53:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=KuauE3nenQqCpS+MkwOO5F545cpU04J5klsHmvTWYrNlxxF5c48ZDGBXO5WOv0iu Message-ID: <46B75213.5080809@yahoo-inc.com> Date: Mon, 06 Aug 2007 09:53:39 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Apostrophes References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> In-Reply-To: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Michael Everson , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > > I propose the following: > > 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters > that appear either in the current Registry or in one of the source > standards be transformed to the plain ASCII apostrophe, U+0027. > > 2. Existing pairs of Description fields that differ only in the type of > apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. Yes, please. > > 3. Future registrations use only U+0027 in place of other > apostrophe-like characters. > > I believe items 1 and 2 affect only RFC 4645bis, but I invite the > editors and others to check whether 4646bis is affected as well. RFC 4646bis would be affected if and only if we feel the need to prescribe this. I note that the sentence you quoted elsewhere in this message occurs in this paragraph: -- For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD also be taken from the source standard. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. The source standard's descriptions MAY be edited, either prior to insertion or via the registration process. For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3. This helps facilitate cross-referencing between ISO 639 and the registry. -- This suggests to me that we can safely ignore this issue in 4646bis, trusting to the Language Subtag Reviewer and/or the reviewer's trusty deputy to make these sorts of edits as a matter of policy. At that same time, I tend to think the the first 'Description' field in a language subtag should be character-for-character equivalent to ISO 639-3, regardless of whether we like it or not. The stated purpose is cross-referencing and my browser's search function does character-by-character identity. You can always have a second, edited, version. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 13:46: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 1II6eY-0003Cf-Cy; Mon, 06 Aug 2007 13:46:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II6eX-0003Ca-Bg for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 13:46:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II6eX-0003CS-1e for ltru@ietf.org; Mon, 06 Aug 2007 13:46:01 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II6eW-000697-PT for ltru@ietf.org; Mon, 06 Aug 2007 13:46:00 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1II6eT-0005WI-5W; Mon, 06 Aug 2007 13:45:57 -0400 Date: Mon, 6 Aug 2007 13:45:57 -0400 To: Doug Ewell Subject: Re: [Ltru] Apostrophes Message-ID: <20070806174557.GA11802@mercury.ccil.org> References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Michael Everson , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I propose the following: +1 to all -- You're a brave man! Go and break through the John Cowan lines, and remember while you're out there cowan@ccil.org risking life and limb through shot and shell, http://ccil.org/~cowan we'll be in here thinking what a sucker you are! --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 15:07: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 1II7uU-0007Xk-VP; Mon, 06 Aug 2007 15:06:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II7uU-0007Xe-Ju for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 15:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II7uU-0007XV-AB for ltru@ietf.org; Mon, 06 Aug 2007 15:06:34 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound2-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II7uS-0006hO-H6 for ltru@ietf.org; Mon, 06 Aug 2007 15:06:34 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id 244C214F531B for ; Mon, 6 Aug 2007 19:06:31 +0000 (UTC) Received: from mail16-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 0409A528067 for ; Mon, 6 Aug 2007 19:06:30 +0000 (UTC) Received: from mail16-sin (localhost.localdomain [127.0.0.1]) by mail16-sin-R.bigfish.com (Postfix) with ESMTP id A637F10303B2 for ; Mon, 6 Aug 2007 19:06:30 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail16-sin (MessageSwitch) id 1186427189609310_4941; Mon, 6 Aug 2007 19:06:29 +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 mail16-sin.bigfish.com (Postfix) with ESMTP id DE04B1C6005D for ; Mon, 6 Aug 2007 19:06:28 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007080612062748-60908 ; Mon, 6 Aug 2007 12:06:27 -0700 In-Reply-To: To: LTRU Working Group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Mon, 6 Aug 2007 12:04:15 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/06/2007 12:04:15, Serialize complete at 08/06/2007 12:04:15, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/06/2007 12:06:27 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/06/2007 12:06:28 PM, Serialize complete at 08/06/2007 12:06:28 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: [Ltru] Serbo-Croatian Deprecations and Variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1746780609==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1746780609== Content-Type: multipart/alternative; boundary="=_alternative 0068F5DE8825732F_=" This is a multipart message in MIME format. --=_alternative 0068F5DE8825732F_= Content-Type: text/plain; charset="US-ASCII" Another practical question to consider in the new era.... I know Peter and I discussed this in the past, but I'm not sure if we raised the question to the rest of the group and it hasn't come up since 639-3 was published. What should I do with films that have been categorized as Serbo-Croatian in the past? The language isn't suddenly different because the political climate changed since the films were first made. The distinction between Serbian and Croatian is not particularly significant in audio works, so we may not find it useful (from a business perspective) to do the research to make guesses as to whether any given film is more Serbian or Croatian. I am not talking about textual forms of the language -- only audio uses. If I wish to maintain classifications previously made against this deprecated language that is now back in business in 639-3, would I extend the deprecated 639-1 prefix and include the 639-3 code; use one of the deprecated 639-2 codes; or just use the new 639-3 code alone? Which of these options is most "wise"? I'm only considering this question in terms of spoken content and I realize we don't have the answer for this yet. But I figure answers start with questions (despite my studio's affiliation with "Jeopardy"). Regards, Karen Broome Karen_Broome@spe.sony.com 08/03/2007 01:40 PM To LTRU Working Group cc Subject [Ltru] Question on variants All, I need to update some tagging in a language list here at Sony Pictures. My current language requirement for Chinese languages is: Audio Languages: Used for dubbing and original language content. * Chinese (No other variant information known) = zh * Chinese (Mandarin, PRC) = zh-cmn-CN * Chinese (Mandarin, Taiwanese variant) = zh-cmn-TW * Chinese (Cantonese) = zh-yue * Chinese (Taiwanese) = zh-min-nan Text Languages: Used for localization of language other than the original language as well as captions and subtitles. Subtitles may also occur in an original version that features more than one language. * Chinese (No other variant information known) = zh * Chinese (Mandarin, Traditional) = zh-cmn-Hant * Chinese (Mandarin, Simplified) = zh-cmn-Hans * Chinese (Cantonese) = zh-yue * Chinese (Taiwanese) = zh-min-nan I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" will be preferred in RFC 4646bis. Of these tags, which are most likely to be deprecated in the new regime? It's unclear to me how I should code Mandarin, Cantonese, and Taiwanese if I want the best chance of being compatible with the preferred tagging to be determined by this committee at a later date. I thought this business scenario might help the discussion, if this issue is not resolved yet. I looked through the archive and it doesn't look like this issue is closed. To me, the "zh" in these tags (especially written language categories) seems helpful. 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 --=_alternative 0068F5DE8825732F_= Content-Type: text/html; charset="US-ASCII"
Another practical question to consider in the new era.... I know Peter and I discussed this in the past, but I'm not sure if we raised the question to the rest of the group and it hasn't come up since 639-3 was published.

What should I do with films that have been categorized as Serbo-Croatian in the past? The language isn't suddenly different because the political climate changed since the films were first made. The distinction between Serbian and Croatian is not particularly significant in audio works, so we may not find it useful (from a business perspective) to do the research to make guesses as to whether any given film is more Serbian or Croatian. I am not talking about textual forms of the language -- only audio uses.

If I wish to maintain classifications previously made against this deprecated language that is now back in business in 639-3, would I extend the deprecated 639-1 prefix and include the 639-3 code; use one of the deprecated 639-2 codes; or just use the new 639-3 code alone? Which of these options is most "wise"?

I'm only considering this question in terms of spoken content and I realize we don't have the answer for this yet. But I figure answers start with questions (despite my studio's affiliation with "Jeopardy").

Regards,

Karen Broome




Karen_Broome@spe.sony.com

08/03/2007 01:40 PM

To
LTRU Working Group <ltru@ietf.org>
cc
Subject
[Ltru] Question on variants






All,

I need to update some tagging in a language list here at Sony Pictures. My current language requirement for Chinese languages is:

Audio Languages: Used for dubbing and original language content.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, PRC) = zh-cmn-CN
* Chinese (Mandarin, Taiwanese variant) = zh-cmn-TW
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

Text Languages: Used for localization of language other than the original language as well as captions and subtitles. Subtitles may also occur in an original version that features more than one language.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, Traditional) = zh-cmn-Hant
* Chinese (Mandarin, Simplified) = zh-cmn-Hans
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" will be preferred in RFC 4646bis. Of these tags, which are most likely to be deprecated in the new regime? It's unclear to me how I should code Mandarin, Cantonese, and Taiwanese if I want the best chance of being compatible with the preferred tagging to be determined by this committee at a later date. I thought this business scenario might help the discussion, if this issue is not resolved yet. I looked through the archive and it doesn't look like this issue is closed. To me, the "zh" in these tags (especially written language categories) seems helpful.

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
--=_alternative 0068F5DE8825732F_=-- --===============1746780609== 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 --===============1746780609==-- From ltru-bounces@ietf.org Mon Aug 06 15:31:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8I4-0005n0-L0; Mon, 06 Aug 2007 15:30:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II8I3-0005mm-KE for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 15:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8I3-0005mc-Aa for ltru@ietf.org; Mon, 06 Aug 2007 15:30:55 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II8I1-0007hI-6H for ltru@ietf.org; Mon, 06 Aug 2007 15:30:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AZvU+9vd87M7luduOiNG9Ix8LMAekraSj6sQRIw6JLGz28akdxiUavS3gvqKjGiA; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.229] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1II8Hw-0000xc-Vx for ltru@ietf.org; Mon, 06 Aug 2007 15:30:49 -0400 Message-ID: <002401c7d860$8683e7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Apostrophes Date: Mon, 6 Aug 2007 12:32:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356a2d5ac6b36c0dcb902279b560e523003350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Michael Everson" > Sent: Sunday, August 05, 2007 11:52 PM > Subject: [Ltru] Apostrophes ... > 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters > that appear either in the current Registry or in one of the source > standards be transformed to the plain ASCII apostrophe, U+0027. > > 2. Existing pairs of Description fields that differ only in the type of > apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. > > 3. Future registrations use only U+0027 in place of other > apostrophe-like characters. ... As a co-chair, I'm concerned that (1) and (2) so would be exceding this WG's proper role. Such a decision belongs to the ietf-languages@iana.org list and the subtag reviewer, rather than this WG, in my opinion. As a technical contributor, though I understand the motivation for (3), I think that hard-coding this kind of a policy detail is something we might eventually regret. The whole point of having a reviewer and discussion list is that we know that specifying a purely mechanical process for handling all aspects of a registration request is impractical. We should spend time spelling out policy where we think the odds are good that submitters, the reviewer, or the discussion list would otherwise be likely to err. I'm also concerned that (3) is just the tip of the look-alike iceberg, and that before too long we might find ourselves specifying a stringprep profile for registry requests. This really feels like over-engineering to me. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 16:11: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 1II8uT-0003m7-2X; Mon, 06 Aug 2007 16:10:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II8uR-0003lu-Tc for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:10:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8uR-0003ll-Ik for ltru@ietf.org; Mon, 06 Aug 2007 16:10:35 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II8uQ-0003al-26 for ltru@ietf.org; Mon, 06 Aug 2007 16:10:34 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76KAMBZ045593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 13:10:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=C4ymqVMvtPetYchsWDOr9hACDT54V5xk90k8wW9CiVgEzKeFLnoPJ10g3jkuah1M Message-ID: <46B7802E.6040500@yahoo-inc.com> Date: Mon, 06 Aug 2007 13:10:22 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Apostrophes References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> In-Reply-To: <002401c7d860$8683e7c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.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 Randy Presuhn wrote: >> 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters >> that appear either in the current Registry or in one of the source >> standards be transformed to the plain ASCII apostrophe, U+0027. >> >> 2. Existing pairs of Description fields that differ only in the type of >> apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. >> >> 3. Future registrations use only U+0027 in place of other >> apostrophe-like characters. > ... > > As a co-chair, I'm concerned that (1) and (2) so would be exceding this > WG's proper role. Such a decision belongs to the ietf-languages@iana.org > list and the subtag reviewer, rather than this WG, in my opinion. Wouldn't #1 and #2 be within scope, since it affects a work item for this WG? It might be a simple policy decision or a bit of editorial discretion (we've been satisfied with those previously). The registration process can always be used to alter or amend any resulting crud. > > As a technical contributor, though I understand the motivation for (3), > I think that hard-coding this kind of a policy detail is something we might > eventually regret. The whole point of having a reviewer and discussion list > is that we know that specifying a purely mechanical process for handling all > aspects of a registration request is impractical. We should spend time > spelling out policy where we think the odds are good that submitters, the > reviewer, or the discussion list would otherwise be likely to err. I'm also > concerned that (3) is just the tip of the look-alike iceberg, and that before > too long we might find ourselves specifying a stringprep profile for registry > requests. This really feels like over-engineering to me. +1 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 16:23: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 1II95v-000227-He; Mon, 06 Aug 2007 16:22:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II95u-000222-88 for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II95t-00021t-Ur for ltru@ietf.org; Mon, 06 Aug 2007 16:22:25 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II95s-0001Ni-Lz for ltru@ietf.org; Mon, 06 Aug 2007 16:22:25 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76KMKPY046778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 13:22:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=KTtHD48OATDmVDGgmioXkLLqh+MLtQ/XvdRk/5E6AGnVbjkTPtYZuMMCr37chj+S Message-ID: <46B782FC.8080404@yahoo-inc.com> Date: Mon, 06 Aug 2007 13:22:20 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Serbo-Croatian Deprecations and Variants References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Karen_Broome@spe.sony.com wrote: > > What should I do with films that have been categorized as Serbo-Croatian > in the past? Nothing? Presumably these were also associated with the defunct region 'YU' (also deprecated, but legal). > The language isn't suddenly different because the political > climate changed since the films were first made. The distinction between > Serbian and Croatian is not particularly significant in audio works, so we > may not find it useful (from a business perspective) to do the research to > make guesses as to whether any given film is more Serbian or Croatian. I > am not talking about textual forms of the language -- only audio uses. Whether you change it for cultural, political, or otherwise-motivated reasons is up to you. The original tags remain (and have always remained) valid. Here's the record in the registry: %% Type: language Subtag: sh Description: Serbo-Croatian Added: 2005-10-16 Deprecated: 2000-02-18 %% > > If I wish to maintain classifications previously made against this > deprecated language that is now back in business in 639-3, would I extend > the deprecated 639-1 prefix and include the 639-3 code; use one of the > deprecated 639-2 codes; or just use the new 639-3 code alone? Which of > these options is most "wise"? Actually, Serbo-Croatian has never been "out of business". It is deprecated, but not illegal. The proposal is that Serbian, Croatian, Bosnian, and Serbo-Croatian are all on the "same level" (as primary language subtags). The fact that there is a macrolangauge mapping from the three former to the latter is not important in language *tagging*, although it might be useful in your applications (for the reasons you give). None of the proposals for extlang would alter this situation (for stability reasons). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 16:32: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 1II9Ec-0006oZ-Kg; Mon, 06 Aug 2007 16:31:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9Eb-0006oU-PS for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9Eb-0006oM-G0 for ltru@ietf.org; Mon, 06 Aug 2007 16:31:25 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9Ea-0001Xa-4l for ltru@ietf.org; Mon, 06 Aug 2007 16:31:25 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tm4VVdFWnFz9HpZZelh0XYDzM9KY9QcDp8pPdDFALD5uJSWBtsNKP/cJzfYeCGcb; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.229] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1II9EV-0004FO-CZ for ltru@ietf.org; Mon, 06 Aug 2007 16:31:19 -0400 Message-ID: <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> <46B7802E.6040500@yahoo-inc.com> Subject: Re: [Ltru] Apostrophes Date: Mon, 6 Aug 2007 13:33:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356c8c1b47d74ca95ca2ce7f1ec936b112d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Monday, August 06, 2007 1:10 PM > Subject: Re: [Ltru] Apostrophes > > Randy Presuhn wrote: > >> 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters > >> that appear either in the current Registry or in one of the source > >> standards be transformed to the plain ASCII apostrophe, U+0027. > >> > >> 2. Existing pairs of Description fields that differ only in the type of > >> apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. > >> > >> 3. Future registrations use only U+0027 in place of other > >> apostrophe-like characters. > > ... > > > > As a co-chair, I'm concerned that (1) and (2) so would be exceding this > > WG's proper role. Such a decision belongs to the ietf-languages@iana.org > > list and the subtag reviewer, rather than this WG, in my opinion. > > Wouldn't #1 and #2 be within scope, since it affects a work item for > this WG? It might be a simple policy decision or a bit of editorial > discretion (we've been satisfied with those previously). The > registration process can always be used to alter or amend any resulting > crud. ... Here's how I look at it: the WG's job is to define policy/process, structure and semantics. The reviewer & list are responsible for content. There's a bit of an intersection for bulk generation of entries derived from other standards. The question here is when do "automatic" transformations of the data provided by other standards cross the line and become decisions about content, that should properly be discussed by the language experts? I can see how this particular case arguably falls into a grey area, but since Doug has already done the work to identify the specific cases, my own preference would be for those cases to be handled on the ietf-languages@iana.org list as change requests, rather than for us here to try to anticipate the outcome of the discussions in that forum. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 16:38: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 1II9KC-0000Ie-CF; Mon, 06 Aug 2007 16:37:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9KB-0000IY-8j for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:37:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9KA-0000IP-U8 for ltru@ietf.org; Mon, 06 Aug 2007 16:37:10 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II9KA-0004R7-Ce for ltru@ietf.org; Mon, 06 Aug 2007 16:37:10 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76KawW4048248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 13:36:58 -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=ikKOt3q1T6uwLo8MAexSdNKotOyJYmxYjr4/2ZrJtjLNb3nBmjg1MhWCcNg+qAvL Message-ID: <46B78669.7080102@yahoo-inc.com> Date: Mon, 06 Aug 2007 13:36:57 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Apostrophes References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> <46B7802E.6040500@yahoo-inc.com> <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> In-Reply-To: <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So... I think we're saying the same thing, which is that Doug should: take the existing registry as an *exact* source; modify those things that *require* modification; add the new records (copying the source standards exactly); and leave any additional changes (such as making the apostrophes "nicer") up to ietf-langauges? Addison Randy Presuhn wrote: > Hi - > >> From: "Addison Phillips" >> To: "Randy Presuhn" >> Cc: "LTRU Working Group" >> Sent: Monday, August 06, 2007 1:10 PM >> Subject: Re: [Ltru] Apostrophes >> >> Randy Presuhn wrote: >>>> 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier letters >>>> that appear either in the current Registry or in one of the source >>>> standards be transformed to the plain ASCII apostrophe, U+0027. >>>> >>>> 2. Existing pairs of Description fields that differ only in the type of >>>> apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single field. >>>> >>>> 3. Future registrations use only U+0027 in place of other >>>> apostrophe-like characters. >>> ... >>> >>> As a co-chair, I'm concerned that (1) and (2) so would be exceding this >>> WG's proper role. Such a decision belongs to the ietf-languages@iana.org >>> list and the subtag reviewer, rather than this WG, in my opinion. >> Wouldn't #1 and #2 be within scope, since it affects a work item for >> this WG? It might be a simple policy decision or a bit of editorial >> discretion (we've been satisfied with those previously). The >> registration process can always be used to alter or amend any resulting >> crud. > ... > > Here's how I look at it: the WG's job is to define policy/process, > structure and semantics. > > The reviewer & list are responsible for content. > > There's a bit of an intersection for bulk generation of entries derived > from other standards. The question here is when do "automatic" transformations > of the data provided by other standards cross the line and become decisions > about content, that should properly be discussed by the language experts? > > I can see how this particular case arguably falls into a grey area, > but since Doug has already done the work to identify the specific cases, my own > preference would be for those cases to be handled on the ietf-languages@iana.org > list as change requests, rather than for us here to try to anticipate the > outcome of the discussions in that forum. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 16:38: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 1II9KK-0000KS-G7; Mon, 06 Aug 2007 16:37:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9KI-0000KK-VG for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9KI-0000KC-Lh for ltru@ietf.org; Mon, 06 Aug 2007 16:37:18 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound6-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9KG-0001ew-RK for ltru@ietf.org; Mon, 06 Aug 2007 16:37:18 -0400 Received: from outbound6-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-sin-R.bigfish.com (Postfix) with ESMTP id 3142410911E9; Mon, 6 Aug 2007 20:33:20 +0000 (UTC) Received: from mail160-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound6-sin.bigfish.com (Postfix) with ESMTP id 1B9671A8004E; Mon, 6 Aug 2007 20:33:20 +0000 (UTC) Received: from mail160-sin (localhost.localdomain [127.0.0.1]) by mail160-sin-R.bigfish.com (Postfix) with ESMTP id 28FEE188819E; Mon, 6 Aug 2007 20:37:15 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail160-sin (MessageSwitch) id 1186432635137908_12474; Mon, 6 Aug 2007 20:37:15 +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 mail160-sin.bigfish.com (Postfix) with ESMTP id D8A9917C007B; Mon, 6 Aug 2007 20:37:14 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007080613371130-66993 ; Mon, 6 Aug 2007 13:37:11 -0700 In-Reply-To: <46B75213.5080809@yahoo-inc.com> To: Addison Phillips Subject: Re: [Ltru] Apostrophes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Mon, 6 Aug 2007 13:34:58 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/06/2007 13:34:59, Serialize complete at 08/06/2007 13:34:59, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/06/2007 01:37:11 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/06/2007 01:37:14 PM, Serialize complete at 08/06/2007 01:37:14 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936260240==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1936260240== Content-Type: multipart/alternative; boundary="=_alternative 0071441F8825732F_=" This is a multipart message in MIME format. --=_alternative 0071441F8825732F_= Content-Type: text/plain; charset="US-ASCII" Addison writes: > At that same time, I tend to think the the first 'Description' field in > a language subtag should be character-for-character equivalent to ISO > 639-3, regardless of whether we like it or not. The stated purpose is > cross-referencing and my browser's search function does > character-by-character identity. You can always have a second, edited, > version. I agree with Doug's apostrophe proposal to the extent that it supports Addison's words above. If there is an incorrectly used apostrophe and someone would like to make issue of it, I would suggest making that change through a change request to the source ISO standard. Any changes that have been made within the registry to date, should likely change back to whatever is specified in the source standard. Two cents, Karen Broome --=_alternative 0071441F8825732F_= Content-Type: text/html; charset="US-ASCII"
Addison writes:

> At that same time, I tend to think the the first 'Description' field in
> a language subtag should be character-for-character equivalent to ISO
> 639-3, regardless of whether we like it or not. The stated purpose is
> cross-referencing and my browser's search function does
> character-by-character identity. You can always have a second, edited,
> version.

I agree with Doug's apostrophe proposal to the extent that it supports Addison's words above. If there is an incorrectly used apostrophe and someone would like to make issue of it, I would suggest making that change through a change request to the source ISO standard. Any changes that have been made within the registry to date, should likely change back to whatever is specified in the source standard.

Two cents,

Karen Broome
 --=_alternative 0071441F8825732F_=-- --===============1936260240== 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 --===============1936260240==-- From ltru-bounces@ietf.org Mon Aug 06 16:41: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 1II9Nx-0003Vw-0P; Mon, 06 Aug 2007 16:41:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9Nv-0003Vp-4M for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9Nu-0003Vg-Qq for ltru@ietf.org; Mon, 06 Aug 2007 16:41:02 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9Nt-0001jo-Ms for ltru@ietf.org; Mon, 06 Aug 2007 16:41:02 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l76Ketqv048590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 13:40:55 -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=XiG9NudvP7hoZMPXI5KDvzdxB3eRsBGA6euypRJtStXVAoaeC6Ppk/wrnTkf5dF6 Message-ID: <46B78756.40906@yahoo-inc.com> Date: Mon, 06 Aug 2007 13:40:54 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Apostrophes References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> <46B7802E.6040500@yahoo-inc.com> <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> <46B78669.7080102@yahoo-inc.com> In-Reply-To: <46B78669.7080102@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 PS> Please note that I personally approve of fixing the various apostrophes. It's just that it does seem unnecessary to modify 4646bis to do it. Addison Addison Phillips wrote: > So... I think we're saying the same thing, which is that Doug should: > take the existing registry as an *exact* source; modify those things > that *require* modification; add the new records (copying the source > standards exactly); and leave any additional changes (such as making the > apostrophes "nicer") up to ietf-langauges? > > Addison > > Randy Presuhn wrote: >> Hi - >> >>> From: "Addison Phillips" >>> To: "Randy Presuhn" >>> Cc: "LTRU Working Group" >>> Sent: Monday, August 06, 2007 1:10 PM >>> Subject: Re: [Ltru] Apostrophes >>> >>> Randy Presuhn wrote: >>>>> 1. In RFC 4645bis, all apostrophes and apostrophe-like modifier >>>>> letters that appear either in the current Registry or in one of the >>>>> source standards be transformed to the plain ASCII apostrophe, U+0027. >>>>> >>>>> 2. Existing pairs of Description fields that differ only in the >>>>> type of apostrophe (e.g. "Ethiopic (Ge'ez)") be reduced to a single >>>>> field. >>>>> >>>>> 3. Future registrations use only U+0027 in place of other >>>>> apostrophe-like characters. >>>> ... >>>> >>>> As a co-chair, I'm concerned that (1) and (2) so would be exceding this >>>> WG's proper role. Such a decision belongs to the >>>> ietf-languages@iana.org >>>> list and the subtag reviewer, rather than this WG, in my opinion. >>> Wouldn't #1 and #2 be within scope, since it affects a work item for >>> this WG? It might be a simple policy decision or a bit of editorial >>> discretion (we've been satisfied with those previously). The >>> registration process can always be used to alter or amend any >>> resulting crud. >> ... >> >> Here's how I look at it: the WG's job is to define policy/process, >> structure and semantics. >> >> The reviewer & list are responsible for content. >> >> There's a bit of an intersection for bulk generation of entries derived >> from other standards. The question here is when do "automatic" >> transformations >> of the data provided by other standards cross the line and become >> decisions >> about content, that should properly be discussed by the language experts? >> >> I can see how this particular case arguably falls into a grey area, >> but since Doug has already done the work to identify the specific >> cases, my own >> preference would be for those cases to be handled on the >> ietf-languages@iana.org >> list as change requests, rather than for us here to try to anticipate the >> outcome of the discussions in that forum. >> >> Randy >> >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 17:03: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 1II9jA-0006nb-69; Mon, 06 Aug 2007 17:03:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9j9-0006nW-GP for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 17:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9j9-0006nO-6w for ltru@ietf.org; Mon, 06 Aug 2007 17:02:59 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9j7-0002Au-Fo for ltru@ietf.org; Mon, 06 Aug 2007 17:02:59 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HkLMlrdV9v6kVncD4N9178rlrOXBhi3fJG0T5eEJDJMfG6Db5ndLPEYpLx4hMoTP; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.229] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1II9j0-0006d7-Nk for ltru@ietf.org; Mon, 06 Aug 2007 17:02:51 -0400 Message-ID: <000401c7d86d$60464000$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> <46B7802E.6040500@yahoo-inc.com> <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> <46B78669.7080102@yahoo-inc.com> Subject: Re: [Ltru] Apostrophes Date: Mon, 6 Aug 2007 14:04:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93560ae2fc6d170812e04980cf8546a70451350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.229 X-Spam-Score: 0.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: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Monday, August 06, 2007 1:36 PM > Subject: Re: [Ltru] Apostrophes > > So... I think we're saying the same thing, which is that Doug should: > take the existing registry as an *exact* source; modify those things > that *require* modification; add the new records (copying the source > standards exactly); and leave any additional changes (such as making the > apostrophes "nicer") up to ietf-langauges? ... That would be my preference, both as a co-chair and as a technical contributor. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 17:05: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 1II9km-0007tS-8C; Mon, 06 Aug 2007 17:04:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1II9kk-0007tN-VL for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 17:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9kk-0007tF-Lo for ltru@ietf.org; Mon, 06 Aug 2007 17:04:38 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9kj-0002CI-7t for ltru@ietf.org; Mon, 06 Aug 2007 17:04:38 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r93bcqkc+cnvNwIquJYVtBCK4TYarz8enPvr6preA0ZPDNYv8iSFmjJV/kz1YfFO; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.229] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1II9kd-0003Di-Vz for ltru@ietf.org; Mon, 06 Aug 2007 17:04:32 -0400 Message-ID: <001001c7d86d$9fb7b480$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <002401c7d860$8683e7c0$6801a8c0@oemcomputer> <46B7802E.6040500@yahoo-inc.com> <000601c7d868$fbc8fcc0$6801a8c0@oemcomputer> <46B78669.7080102@yahoo-inc.com> <46B78756.40906@yahoo-inc.com> Subject: Re: [Ltru] Apostrophes Date: Mon, 6 Aug 2007 14:06:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935691a6ab371c4f29c9330ce2d9cca0b0a0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Addison Phillips" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Monday, August 06, 2007 1:40 PM > Subject: Re: [Ltru] Apostrophes > > PS> Please note that I personally approve of fixing the various > apostrophes. It's just that it does seem unnecessary to modify 4646bis > to do it. ... Ditto. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 23:06: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 1IIFNj-0002J7-Ba; Mon, 06 Aug 2007 23:05:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIFNi-0002J2-0J for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 23:05:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIFNh-0002Iu-Lp for ltru@ietf.org; Mon, 06 Aug 2007 23:05:13 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIFNh-0004pQ-AJ for ltru@ietf.org; Mon, 06 Aug 2007 23:05:13 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070807030512.KYZH6544.mta11.adelphia.net@DGBP7M81>; Mon, 6 Aug 2007 23:05:12 -0400 Message-ID: <001d01c7d89f$c54e6f40$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 6 Aug 2007 20:05:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Karen_Broome@spe.sony.com Subject: [Ltru] Re: Serbo-Croatian Deprecations and Variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org wrote: > What should I do with films that have been categorized as > Serbo-Croatian in the past? The language isn't suddenly different > because the political climate changed since the films were first made. As Addison said, you don't actually have to change anything; that's why we made sure that "deprecated" subtags were still valid, and not removed from the Registry. > If I wish to maintain classifications previously made against this > deprecated language that is now back in business in 639-3, would I > extend the deprecated 639-1 prefix and include the 639-3 code; You don't mean "sh-sr" or "sr-hr", right? That's not well-formed. > use one of the deprecated 639-2 codes; Which are those? > or just use the new 639-3 code alone? Which of these options is most > "wise"? You can leave everything alone, or you can (more or less arbitrarily) choose "sr" or "hr", both of which are valid 639-1 code elements. > I'm only considering this question in terms of spoken content and I > realize we don't have the answer for this yet. But I figure answers > start with questions (despite my studio's affiliation with > "Jeopardy"). -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 ("Jeopardy!" wannabe) http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 06 23:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIFy6-0005rb-GZ; Mon, 06 Aug 2007 23:42:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIFy4-0005rW-CA for ltru-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 23:42:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIFy4-0005rO-1S for ltru@ietf.org; Mon, 06 Aug 2007 23:42:48 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIFy3-0005Yi-G8 for ltru@ietf.org; Mon, 06 Aug 2007 23:42:47 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070807034246.OFCE16842.mta10.adelphia.net@DGBP7M81>; Tue, 7 Aug 2007 03:42:46 +0000 Message-ID: <002d01c7d8a5$04ef3ee0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <006401c7d7f6$4cad7030$6401a8c0@DGBP7M81> <46B75213.5080809@yahoo-inc.com> Subject: Re: [Ltru] Apostrophes Date: Mon, 6 Aug 2007 20:42:45 -0700 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.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > At that same time, I tend to think the the first 'Description' field > in a language subtag should be character-for-character equivalent to > ISO 639-3, regardless of whether we like it or not. The stated purpose > is cross-referencing and my browser's search function does > character-by-character identity. If the intent is for the first Description field to be identical to the 639-3 reference name -- and this is just what I have been doing in RFC 4645bis, *except* that I proposed to ASCII-slam the apostrophes -- then I think the text should emphasize this a bit more. There is lots of text about how Description fields are not normative. > You can always have a second, edited, version. No, please, no. Let's not proliferate this kind of thing: Description: Ethiopic (Geʻez) Description: Ethiopic (Ge'ez) Frankly, I would much rather see just the "official" line with U+02BB than both lines. It's back to what I said about "transcribing" accented Latin letters into ASCII: it proves nothing except that we created a character-encoding problem and had to hack our way out of it. With UTF-8 this will be worse than it is today, because the two lines will look virtually identical: Description: Ethiopic (GeÊ»ez) Description: Ethiopic (Ge'ez) Randy Presuhn wrote: > As a co-chair, I'm concerned that (1) and (2) so would be exceding > this WG's proper role. Such a decision belongs to the > ietf-languages@iana.org list and the subtag reviewer, rather than this > WG, in my opinion. Addison answered this adequately: (1) and (2) are questions about what we should do in RFC 4645bis. > As a technical contributor, though I understand the motivation for > (3), I think that hard-coding this kind of a policy detail is > something we might eventually regret. The whole point of having a > reviewer and discussion list is that we know that specifying a purely > mechanical process for handling all aspects of a registration request > is impractical. We should spend time spelling out policy where we > think the odds are good that submitters, the reviewer, or the > discussion list would otherwise be likely to err. One of the main reasons I bring this up here is that ietf-languages has been unable to establish a consistent pattern for apostrophes and meta-apostrophes, despite much discussion. > I'm also concerned that (3) is just the tip of the look-alike iceberg, > and that before too long we might find ourselves specifying a > stringprep profile for registry requests. This really feels like > over-engineering to me. I have no desire to extend this beyond apostrophe-like characters. Of course, others might pick up this particular ball and run with it. Later: > I can see how this particular case arguably falls into a grey area, > but since Doug has already done the work to identify the specific > cases, my own preference would be for those cases to be handled on the > ietf-languages at iana.org list as change requests, rather than for us > here to try to anticipate the outcome of the discussions in that > forum. I can promise that if this is brought up on the ietf-languages list, the net result will be to convert the U+0027 apostrophes to more "correct" characters, to de-regularize them, which is exactly the opposite of what I had in mind. I've already gotten one private reply to this effect. Addison replied: > So... I think we're saying the same thing, which is that Doug should: > take the existing registry as an *exact* source; modify those things > that *require* modification; add the new records (copying the source > standards exactly); and leave any additional changes (such as making > the apostrophes "nicer") up to ietf-langauges? and Karen and Randy agreed. Oh well, I tried. Thanks to John for his summary "+1", but it looks like this isn't going to happen. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 07 01:54: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 1III1Q-0001I8-Qs; Tue, 07 Aug 2007 01:54:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1III1P-0001I1-FA for ltru-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 01:54:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1III1P-0001Ht-4Z for ltru@ietf.org; Tue, 07 Aug 2007 01:54:23 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1III1O-0008M4-NE for ltru@ietf.org; Tue, 07 Aug 2007 01:54:23 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070807052524.GBTV28634.mta9.adelphia.net@DGBP7M81> for ; Tue, 7 Aug 2007 01:25:24 -0400 Message-ID: <003701c7d8b3$5b1273b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 6 Aug 2007 22:25:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Line lengths in RFC 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've contacted Michelle Cotton of IANA about how to manage updates to a UTF-8 Language Subtag Registry, and hope to hear from IANA in the next week or so. I have a question about "reloading" the Registry in RFC 4645bis, if we are planning to switch to UTF-8. An Internet-Draft must be in pure ASCII, so I'm told. I assume that if we devise a process to manage updates that involves us sending hex NCRs (or some other ASCII representation) to IANA, and IANA converting the text to UTF-8 before inserting it into the Registry, then it would make sense to use the same process when converting the RFC 4645bis contents. The problem is this: 1. RFC 4645bis allows physical lines in the Registry to be up to 72 UTF-8 bytes long. 2. Whatever ASCII representation I use in the I-D will take more bytes than UTF-8. 3. Lines in I-Ds are limited to 72 characters (xml2rfc will see to that). How can I convey the correct line-breaking points to IANA so that the lines will come out right in the reloaded Registry? This would be a particular problem for the Comments field for variant 'baku1926', which contains a relatively large number of non-ASCII characters. One possibility might be to mark the line breaks with a backslash, but I don't want to introduce more meta-syntax than necessary. Suggestions are welcome. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 07 02:15: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 1IIILZ-0003Yp-Ru; Tue, 07 Aug 2007 02:15:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIILY-0003YT-Cj for ltru-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 02:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIILY-0003YL-2Y for ltru@ietf.org; Tue, 07 Aug 2007 02:15:12 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIILW-00053z-Nv for ltru@ietf.org; Tue, 07 Aug 2007 02:15:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LZrut7h8plLv3NEHx2R/kG30EX8NDt9ReTDfRXh/zwg26ylchaL4PngTndMDdLhd; 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.137.247] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IIILR-0003DT-1z for ltru@ietf.org; Tue, 07 Aug 2007 02:15:05 -0400 Message-ID: <001901c7d8ba$8460c6c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003701c7d8b3$5b1273b0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Line lengths in RFC 4645bis Date: Mon, 6 Aug 2007 23:16:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935651a4932e3a2bc8ce979afd242017b976350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.247 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, August 06, 2007 10:25 PM > Subject: [Ltru] Line lengths in RFC 4645bis ... > 1. RFC 4645bis allows physical lines in the Registry to be up to 72 > UTF-8 bytes long. > > 2. Whatever ASCII representation I use in the I-D will take more bytes > than UTF-8. > > 3. Lines in I-Ds are limited to 72 characters (xml2rfc will see to > that). I don't see the problem. Nothing says that we have to make our lines that long. They can be shorter. > How can I convey the correct line-breaking points to IANA so that the > lines will come out right in the reloaded Registry? This would be a > particular problem for the Comments field for variant 'baku1926', which > contains a relatively large number of non-ASCII characters. So it might have a few more lines than might theoretically be possible. This doesn't seem to me to be a real problem. > One possibility might be to mark the line breaks with a backslash, but I > don't want to introduce more meta-syntax than necessary. Suggestions > are welcome. Agreed. My suggestion is to not worry about it. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 07 09:20: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 1IIOyd-0007hT-FS; Tue, 07 Aug 2007 09:19:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIOyc-0007hH-9V for ltru-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 09:19:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOyb-0007h9-V8 for ltru@ietf.org; Tue, 07 Aug 2007 09:19:58 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIOyb-0005gE-EK for ltru@ietf.org; Tue, 07 Aug 2007 09:19:57 -0400 Received: from [10.72.73.72] (snvvpn1-10-72-73-c72.corp.yahoo.com [10.72.73.72]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l77DJNjS036979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2007 06:19:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=wHc4XBnTsrhKzQBlTX3V5muIuo5TCzbOdZ0iJmS2IxPnCo5asGzLAT4BDSl+ZtWA Message-ID: <46B87155.3050908@yahoo-inc.com> Date: Tue, 07 Aug 2007 06:19:17 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Line lengths in RFC 4645bis References: <003701c7d8b3$5b1273b0$6401a8c0@DGBP7M81> <001901c7d8ba$8460c6c0$6801a8c0@oemcomputer> In-Reply-To: <001901c7d8ba$8460c6c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> >> 3. Lines in I-Ds are limited to 72 characters (xml2rfc will see to >> that). > > I don't see the problem. Nothing says that we have to make our lines > that long. They can be shorter. Yes, although it might look funny in the finished product. > >> This would be a >> particular problem for the Comments field for variant 'baku1926', which >> contains a relatively large number of non-ASCII characters. > > So it might have a few more lines than might theoretically be possible. > This doesn't seem to me to be a real problem. There is no limit to the number of lines that a field may take. > >> One possibility might be to mark the line breaks with a backslash, but I >> don't want to introduce more meta-syntax than necessary. Suggestions >> are welcome. > > Agreed. My suggestion is to not worry about it. > We might also give IANA a record-jar parser (I have one handy) for that task. A proper record-jar parser would read the I-D version creating logical records and then reserialize as UTF-8. The fields in the logical records consist of single (unlimited length) lines. The wrapping/folding process is part of the serialization scheme. This doesn't affect the I-D (i.e. Randy's "don't worry about it"), but if we give them a tool to help with the job, it should be tested on the file ahead of time. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 07 12:44: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 1IISAJ-00057S-AB; Tue, 07 Aug 2007 12:44:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IISAH-00057H-IY for ltru-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 12:44:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISAH-000577-6w for ltru@ietf.org; Tue, 07 Aug 2007 12:44:13 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound8-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISAG-0007lW-6K for ltru@ietf.org; Tue, 07 Aug 2007 12:44:13 -0400 Received: from outbound8-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-dub-R.bigfish.com (Postfix) with ESMTP id B385F1729A7F; Tue, 7 Aug 2007 16:44:13 +0000 (UTC) Received: from mail116-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound8-dub.bigfish.com (Postfix) with ESMTP id A51DA1230287; Tue, 7 Aug 2007 16:44:13 +0000 (UTC) Received: from mail116-dub (localhost.localdomain [127.0.0.1]) by mail116-dub-R.bigfish.com (Postfix) with ESMTP id 31F293D043E; Tue, 7 Aug 2007 16:43:53 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail116-dub (MessageSwitch) id 118650503257715_10944; Tue, 7 Aug 2007 16:43:52 +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 mail116-dub.bigfish.com (Postfix) with ESMTP id AF82D1D08083; Tue, 7 Aug 2007 16:43:50 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007080709440219-105304 ; Tue, 7 Aug 2007 09:44:02 -0700 In-Reply-To: <001d01c7d89f$c54e6f40$6401a8c0@DGBP7M81> To: "Doug Ewell" Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 7 Aug 2007 09:41:49 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/07/2007 09:41:50, Serialize complete at 08/07/2007 09:41:50, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/07/2007 09:44:02 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/07/2007 09:44:08 AM, Serialize complete at 08/07/2007 09:44:08 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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="===============2037768871==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============2037768871== Content-Type: multipart/alternative; boundary="=_alternative 005BEBD088257330_=" This is a multipart message in MIME format. --=_alternative 005BEBD088257330_= Content-Type: text/plain; charset="US-ASCII" Doug, I understand that deprecated tags are still valid. I wouldn't use hr or sr because that's a more narrow semantic than Serbo-Croatian. I guess my question is this: Is it "wiser" to use the deprecated ISO 639-1 tag, or the ISO 639-3 tag, which is not deprecated and is a macrolanguage. Assume a clean slate and that any tagging applied to date can be changed with a SQL update, but individual language classifications cannot be reassigned. Should the draft offer guidance on this? I don't know which tag is preferred -- sh or hbs. (I initially thought that perhaps the sh tag might be combined with the hbs tag, but now I realize that's silly -- I was thinking of the Chinese variant examples from the day before.) I'm not really using it in a macrolanguage sense, but I'd rather not use any deprecated tagging, whether it's valid or not. Note: This language tag will not be attached to a region. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Doug Ewell" 08/06/2007 08:05 PM To "LTRU Working Group" cc Karen_Broome@spe.sony.com Subject [Ltru] Re: Serbo-Croatian Deprecations and Variants wrote: > What should I do with films that have been categorized as > Serbo-Croatian in the past? The language isn't suddenly different > because the political climate changed since the films were first made. As Addison said, you don't actually have to change anything; that's why we made sure that "deprecated" subtags were still valid, and not removed from the Registry. > If I wish to maintain classifications previously made against this > deprecated language that is now back in business in 639-3, would I > extend the deprecated 639-1 prefix and include the 639-3 code; You don't mean "sh-sr" or "sr-hr", right? That's not well-formed. > use one of the deprecated 639-2 codes; Which are those? > or just use the new 639-3 code alone? Which of these options is most > "wise"? You can leave everything alone, or you can (more or less arbitrarily) choose "sr" or "hr", both of which are valid 639-1 code elements. > I'm only considering this question in terms of spoken content and I > realize we don't have the answer for this yet. But I figure answers > start with questions (despite my studio's affiliation with > "Jeopardy"). -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 ("Jeopardy!" wannabe) http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 005BEBD088257330_= Content-Type: text/html; charset="US-ASCII"
Doug,

I understand that deprecated tags are still valid. I wouldn't use hr or sr because that's a more narrow semantic than Serbo-Croatian. I guess my question is this: Is it "wiser" to use the deprecated ISO 639-1 tag, or the ISO 639-3 tag, which is not deprecated and is a macrolanguage. Assume a clean slate and that any tagging applied to date can be changed with a SQL update, but individual language classifications cannot be reassigned.

Should the draft offer guidance on this? I don't know which tag is preferred -- sh or hbs. (I initially thought that perhaps the sh tag might be combined with the hbs tag, but now I realize that's silly -- I was thinking of the Chinese variant examples from the day before.)  I'm not really using it in a macrolanguage sense, but I'd rather not use any deprecated tagging, whether it's valid or not. Note: This language tag will not be attached to a region.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


"Doug Ewell" <dewell@roadrunner.com>

08/06/2007 08:05 PM

To
"LTRU Working Group" <ltru@ietf.org>
cc
Karen_Broome@spe.sony.com
Subject
[Ltru] Re: Serbo-Croatian Deprecations and Variants





<Karen underscore Broome at spe dot sony dot com> wrote:

> What should I do with films that have been categorized as
> Serbo-Croatian in the past? The language isn't suddenly different
> because the political climate changed since the films were first made.

As Addison said, you don't actually have to change anything; that's why
we made sure that "deprecated" subtags were still valid, and not removed
from the Registry.

> If I wish to maintain classifications previously made against this
> deprecated language that is now back in business in 639-3, would I
> extend the deprecated 639-1 prefix and include the 639-3 code;

You don't mean "sh-sr" or "sr-hr", right?  That's not well-formed.

> use one of the deprecated 639-2 codes;

Which are those?

> or just use the new 639-3 code alone? Which of these options is most
> "wise"?

You can leave everything alone, or you can (more or less arbitrarily)
choose "sr" or "hr", both of which are valid 639-1 code elements.

> I'm only considering this question in terms of spoken content and I
> realize we don't have the answer for this yet. But I figure answers
> start with questions (despite my studio's affiliation with
> "Jeopardy").

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



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 005BEBD088257330_=-- --===============2037768871== 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 --===============2037768871==-- From ltru-bounces@ietf.org Tue Aug 07 15:43: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 1IIUxM-0007WI-5j; Tue, 07 Aug 2007 15:43:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIUxK-0007Vf-DY for ltru-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 15:43:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUxH-0007V6-1E for ltru@ietf.org; Tue, 07 Aug 2007 15:43:01 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIUxG-0006Ct-NH for ltru@ietf.org; Tue, 07 Aug 2007 15:42:58 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IIUxC-0006Ep-T7; Tue, 07 Aug 2007 15:42:54 -0400 Date: Tue, 7 Aug 2007 15:42:54 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants Message-ID: <20070807194254.GC18607@mercury.ccil.org> References: <001d01c7d89f$c54e6f40$6401a8c0@DGBP7M81> 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: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > Doug, > > I understand that deprecated tags are still valid. I wouldn't use hr or sr > because that's a more narrow semantic than Serbo-Croatian. I guess my > question is this: Is it "wiser" to use the deprecated ISO 639-1 tag, or > the ISO 639-3 tag, which is not deprecated and is a macrolanguage. No 639-1 or -2 tag will ever be replaced by a 639-3 tag. -- 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 Wed Aug 08 02:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIevA-0007mU-Mj; Wed, 08 Aug 2007 02:21:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIevA-0007mO-45 for ltru-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 02:21:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIev9-0007mG-OR for ltru@ietf.org; Wed, 08 Aug 2007 02:21:27 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIev9-0005Fn-AZ for ltru@ietf.org; Wed, 08 Aug 2007 02:21:27 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070808062126.DWDX16842.mta10.adelphia.net@DGBP7M81>; Wed, 8 Aug 2007 06:21:26 +0000 Message-ID: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants Date: Tue, 7 Aug 2007 23:21:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org wrote: > I understand that deprecated tags are still valid. I wouldn't use hr > or sr because that's a more narrow semantic than Serbo-Croatian. I > guess my question is this: Is it "wiser" to use the deprecated ISO > 639-1 tag, or the ISO 639-3 tag, which is not deprecated and is a > macrolanguage. Assume a clean slate and that any tagging applied to > date can be changed with a SQL update, but individual language > classifications cannot be reassigned. You can't use 'hbs' in any case, because it is defined in ISO 639-3 as equivalent to 'sh' (see http://www.sil.org/iso639-3/documentation.asp?id=hbs). Whenever an alpha-2 and an alpha-3 code element exist for the same language, only the alpha-2 can be used in a language tag. That has been the rule since RFC 3066 first allowed alpha-3 subtags, and in the 4646 era we implement it by not putting the alpha-3 in the Registry. What makes Serbo-Croatian unusual in this regard is that there was a code element for it in ISO 639-1 (sh) and there is now one in 639-3 (hbs), but apparently never in ISO 639-2. Furthermore, and strangely, the deletion of 'sh' from ISO 639-1 is no longer listed on the ISO 639-2/RA Change Notice page, even though we know it was once there because we gave 'sh' a Deprecated date of 2000-02-18 in the Registry (the same day Bosnian and many others were added). The resurrection of Serbo-Croatian as an ISO 639-3 macrolanguage poses an interesting challenge, because deprecation is supposed to be forever in the Registry. (Section 3.4, item 1: "Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over time.") My assumption is that 'sh' has to remain deprecated, and 'hbs' has to remain on the outside looking in. Back to your question: If you know the content is Serbian, use 'sr'; if Croatian, use 'hr'; if Bosnian, use 'bs'. If all you know is that it's some type of Serbo-Croatian, and you don't feel comfortable picking one of the other three arbitrarily, your best bet might be to use 'sh' even though Section 3.1.5 says you SHOULD NOT do so, and even though it feels wrong. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 08 04:04: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 1IIgWf-00016j-JO; Wed, 08 Aug 2007 04:04:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IIgWe-00016J-4h for ltru-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 04:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIgWd-00016B-LG for ltru@ietf.org; Wed, 08 Aug 2007 04:04:15 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIgWc-00017m-6V for ltru@ietf.org; Wed, 08 Aug 2007 04:04:15 -0400 Received: from [10.72.73.72] (snvvpn1-10-72-73-c72.corp.yahoo.com [10.72.73.72]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7883sci020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 01:04:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=xWACkeGLQK/dfxhvP/cbzrLgDSPjfUHq8pxK6BmgwlEeCg4r2g4OGdSn1EPnN8II Message-ID: <46B978E5.4070109@yahoo-inc.com> Date: Wed, 08 Aug 2007 01:03:49 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants References: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> In-Reply-To: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Karen_Broome@spe.sony.com, LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > > The resurrection of Serbo-Croatian as an ISO 639-3 macrolanguage poses > an interesting challenge, because deprecation is supposed to be forever > in the Registry. (Section 3.4, item 1: "Values in the fields 'Type', > 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be > changed and are guaranteed to be stable over time.") My assumption is > that 'sh' has to remain deprecated, and 'hbs' has to remain on the > outside looking in. Well... yeah. That's what stability really means. > > Back to your question: If you know the content is Serbian, use 'sr'; if > Croatian, use 'hr'; if Bosnian, use 'bs'. If all you know is that it's > some type of Serbo-Croatian, and you don't feel comfortable picking one > of the other three arbitrarily, your best bet might be to use 'sh' even > though Section 3.1.5 says you SHOULD NOT do so, and even though it feels > wrong. > SHOULD NOT is not the same as MUST NOT. You should not use 'sh' unless you have a (pretty good) reason to do so. The fact that you have (audio) data that cannot otherwise be distinguished or is already labeled as 'sh' seems like a "good reason". 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 Aug 08 18:01: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 1IItas-0004oI-57; Wed, 08 Aug 2007 18:01:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IItaq-0004oD-W8 for ltru-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:01:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItaq-0004o5-Iy for ltru@ietf.org; Wed, 08 Aug 2007 18:01:28 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound8-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IItap-0003cL-QA for ltru@ietf.org; Wed, 08 Aug 2007 18:01:28 -0400 Received: from outbound8-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-dub-R.bigfish.com (Postfix) with ESMTP id 929F31728D55; Wed, 8 Aug 2007 22:01:27 +0000 (UTC) Received: from mail55-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound8-dub.bigfish.com (Postfix) with ESMTP id 833391230050; Wed, 8 Aug 2007 22:01:27 +0000 (UTC) Received: from mail55-dub (localhost.localdomain [127.0.0.1]) by mail55-dub-R.bigfish.com (Postfix) with ESMTP id 5087D19604B3; Wed, 8 Aug 2007 22:01:05 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail55-dub (MessageSwitch) id 1186610465255108_28905; Wed, 8 Aug 2007 22:01:05 +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 mail55-dub.bigfish.com (Postfix) with ESMTP id E84C87D0077; Wed, 8 Aug 2007 22:01:04 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007080815012093-178306 ; Wed, 8 Aug 2007 15:01:20 -0700 In-Reply-To: <46B978E5.4070109@yahoo-inc.com> To: Addison Phillips Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 8 Aug 2007 14:59:08 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/08/2007 14:59:09, Serialize complete at 08/08/2007 14:59:09, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/08/2007 03:01:20 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/08/2007 03:01:24 PM, Serialize complete at 08/08/2007 03:01:24 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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="===============0630635801==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0630635801== Content-Type: multipart/alternative; boundary="=_alternative 0078F8FC88257331_=" This is a multipart message in MIME format. --=_alternative 0078F8FC88257331_= Content-Type: text/plain; charset="US-ASCII" OK, "sh" it is. Just confirming that the deprecated tag is preferred. (Seems a little counterintuitive?) Regards, Karen Addison Phillips 08/08/2007 01:03 AM To Doug Ewell cc Karen_Broome@spe.sony.com, LTRU Working Group Subject Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants Doug Ewell wrote: > > The resurrection of Serbo-Croatian as an ISO 639-3 macrolanguage poses > an interesting challenge, because deprecation is supposed to be forever > in the Registry. (Section 3.4, item 1: "Values in the fields 'Type', > 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be > changed and are guaranteed to be stable over time.") My assumption is > that 'sh' has to remain deprecated, and 'hbs' has to remain on the > outside looking in. Well... yeah. That's what stability really means. > > Back to your question: If you know the content is Serbian, use 'sr'; if > Croatian, use 'hr'; if Bosnian, use 'bs'. If all you know is that it's > some type of Serbo-Croatian, and you don't feel comfortable picking one > of the other three arbitrarily, your best bet might be to use 'sh' even > though Section 3.1.5 says you SHOULD NOT do so, and even though it feels > wrong. > SHOULD NOT is not the same as MUST NOT. You should not use 'sh' unless you have a (pretty good) reason to do so. The fact that you have (audio) data that cannot otherwise be distinguished or is already labeled as 'sh' seems like a "good reason". 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 --=_alternative 0078F8FC88257331_= Content-Type: text/html; charset="US-ASCII"
OK, "sh" it is.

Just confirming that the deprecated tag is preferred.  (Seems a little counterintuitive?)

Regards,

Karen



Addison Phillips <addison@yahoo-inc.com>

08/08/2007 01:03 AM

To
Doug Ewell <dewell@roadrunner.com>
cc
Karen_Broome@spe.sony.com, LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants





Doug Ewell wrote:
>
> The resurrection of Serbo-Croatian as an ISO 639-3 macrolanguage poses
> an interesting challenge, because deprecation is supposed to be forever
> in the Registry.  (Section 3.4, item 1: "Values in the fields 'Type',
> 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be
> changed and are guaranteed to be stable over time.")  My assumption is
> that 'sh' has to remain deprecated, and 'hbs' has to remain on the
> outside looking in.

Well... yeah. That's what stability really means.

>
> Back to your question:  If you know the content is Serbian, use 'sr'; if
> Croatian, use 'hr'; if Bosnian, use 'bs'.  If all you know is that it's
> some type of Serbo-Croatian, and you don't feel comfortable picking one
> of the other three arbitrarily, your best bet might be to use 'sh' even
> though Section 3.1.5 says you SHOULD NOT do so, and even though it feels
> wrong.
>

SHOULD NOT is not the same as MUST NOT. You should not use 'sh' unless
you have a (pretty good) reason to do so. The fact that you have (audio)
data that cannot otherwise be distinguished or is already labeled as
'sh' seems like a "good reason".

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
--=_alternative 0078F8FC88257331_=-- --===============0630635801== 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 --===============0630635801==-- From ltru-bounces@ietf.org Thu Aug 09 02:45: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 1IJ1lh-00054u-0t; Thu, 09 Aug 2007 02:45:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJ1lf-00054o-Nn for ltru-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 02:45:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ1le-00054S-MB for ltru@ietf.org; Thu, 09 Aug 2007 02:45:10 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ1le-00032Y-DC for ltru@ietf.org; Thu, 09 Aug 2007 02:45:10 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070809064509.VOFY6544.mta11.adelphia.net@DGBP7M81>; Thu, 9 Aug 2007 02:45:09 -0400 Message-ID: <00cb01c7da50$d463d620$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants Date: Wed, 8 Aug 2007 23:45:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org wrote: > Just confirming that the deprecated tag is preferred. (Seems a little > counterintuitive?) It won't be the last time. The ISO 639-3 folks have made it known that A might be withdrawn and replaced by B and C, or vice versa, on an annual-review basis as supported by linguistic research. We might have a lot more cases like Serbo-Croatian in the future. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 09 02:59: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 1IJ1zg-00077e-2e; Thu, 09 Aug 2007 02:59:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJ1ze-00077W-2z for ltru-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 02:59:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ1zd-00077N-N7 for ltru@ietf.org; Thu, 09 Aug 2007 02:59:37 -0400 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ1zd-0003Hi-B3 for ltru@ietf.org; Thu, 09 Aug 2007 02:59:37 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070809065936.OILQ7001.mta16.adelphia.net@DGBP7M81> for ; Thu, 9 Aug 2007 02:59:36 -0400 Message-ID: <00d301c7da52$d94af450$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 8 Aug 2007 23:59:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: Line lengths in RFC 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> How can I convey the correct line-breaking points to IANA so that the >> lines will come out right in the reloaded Registry? This would be a >> particular problem for the Comments field for variant 'baku1926', >> which contains a relatively large number of non-ASCII characters. > > So it might have a few more lines than might theoretically be > possible. This doesn't seem to me to be a real problem. OK, I was just trying to make sure the lines didn't come out looking like this, which might look a bit ridiculous, but you're right that it's not a technical problem. I'll stop worrying about it. Addison Phillips replied: > We might also give IANA a record-jar parser (I have one handy) for > that task. A proper record-jar parser would read the I-D version > creating logical records and then reserialize as UTF-8. The fields in > the logical records consist of single (unlimited length) lines. The > wrapping/folding process is part of the serialization scheme. I really like that idea. Can you provide them (and me) with that tool? I'll send you the necessary IANA contacts. > This doesn't affect the I-D (i.e. Randy's "don't worry about it"), but > if we give them a tool to help with the job, it should be tested on > the file ahead of time. Absolutely. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 09 14:51: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 1IJD6P-0003HT-JS; Thu, 09 Aug 2007 14:51:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJD6N-00039H-12 for ltru-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:51:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJD6L-00033m-Do for ltru@ietf.org; Thu, 09 Aug 2007 14:51:18 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJD6K-0004QX-Rf for ltru@ietf.org; Thu, 09 Aug 2007 14:51:17 -0400 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.0.700.0; Thu, 9 Aug 2007 11:51:16 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Thu, 9 Aug 2007 11:51:13 -0700 From: Peter Constable To: LTRU Working Group Date: Thu, 9 Aug 2007 11:51:12 -0700 Subject: RE: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Topic: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Index: AcfaUNiiVYiLOLx9Si61bokaTHk41wAZKWXw Message-ID: References: <00cb01c7da50$d463d620$6401a8c0@DGBP7M81> In-Reply-To: <00cb01c7da50$d463d620$6401a8c0@DGBP7M81> 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: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Clarification on "withdrawn": nothing that gets coded will later be un-code= d: if language Foo is assign an ID "foo", then Foo will always be coded as = "foo". But "foo" can be retired/deprecated. Peter -----Original Message----- From: Doug Ewell [mailto:dewell@roadrunner.com] Sent: Wednesday, August 08, 2007 11:45 PM To: LTRU Working Group Cc: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants wrote: > Just confirming that the deprecated tag is preferred. (Seems a little > counterintuitive?) It won't be the last time. The ISO 639-3 folks have made it known that A might be withdrawn and replaced by B and C, or vice versa, on an annual-review basis as supported by linguistic research. We might have a lot more cases like Serbo-Croatian in the future. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 09 16:13: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 1IJEOC-0003OB-VD; Thu, 09 Aug 2007 16:13:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJEOA-0003Nr-EK for ltru-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 16:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEO9-0003NT-C6 for ltru@ietf.org; Thu, 09 Aug 2007 16:13:46 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJEO8-00042x-15 for ltru@ietf.org; Thu, 09 Aug 2007 16:13:45 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l79KDdhR066112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 13:13:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=nPWEleOQn39jeeGDoA4XlxbtAq2YefJLPMw+DUPxLmzwPTv9zgadLgzarYrbl51X Message-ID: <46BB7573.1090504@yahoo-inc.com> Date: Thu, 09 Aug 2007 13:13:39 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants References: <00cb01c7da50$d463d620$6401a8c0@DGBP7M81> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Does "retired" mean that the code would be formally withdrawn? Assuming it means this, does that mean that the code would never be reused for some other language? Addison Peter Constable wrote: > Clarification on "withdrawn": nothing that gets coded will later be un-coded: if language Foo is assign an ID "foo", then Foo will always be coded as "foo". But "foo" can be retired/deprecated. > > Peter > > -----Original Message----- > From: Doug Ewell [mailto:dewell@roadrunner.com] > Sent: Wednesday, August 08, 2007 11:45 PM > To: LTRU Working Group > Cc: Karen_Broome@spe.sony.com > Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants > > wrote: > >> Just confirming that the deprecated tag is preferred. (Seems a little >> counterintuitive?) > > It won't be the last time. The ISO 639-3 folks have made it known that > A might be withdrawn and replaced by B and C, or vice versa, on an > annual-review basis as supported by linguistic research. We might have > a lot more cases like Serbo-Croatian in the future. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- 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 Aug 10 02:19: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 1IJNqC-00020s-RG; Fri, 10 Aug 2007 02:19:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJNqB-0001v1-Cu for ltru-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 02:19:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNqB-0001tY-11 for ltru@ietf.org; Fri, 10 Aug 2007 02:19:19 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJNqA-0006fY-Jp for ltru@ietf.org; Fri, 10 Aug 2007 02:19:18 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 9 Aug 2007 23:19:17 -0700 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; Thu, 9 Aug 2007 23:19:17 -0700 From: Peter Constable To: LTRU Working Group Date: Thu, 9 Aug 2007 23:19:14 -0700 Subject: RE: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Topic: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Index: AcfawcqYi3FVN7wuR+mUVpJnUO99AQAVCeNw Message-ID: References: <00cb01c7da50$d463d620$6401a8c0@DGBP7M81> <46BB7573.1090504@yahoo-inc.com> In-Reply-To: <46BB7573.1090504@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I thought my statement made that clear: once encoded, always encoded. "Reti= red" means it's no longer recommended -- basically the same as deprecated. = But I think I've made clear for a long time: ISO 639-3 will be stable in th= e sense that an identifier will always retain its semantic and will never g= et re-defined. Peter -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: Thursday, August 09, 2007 1:14 PM To: Peter Constable Cc: LTRU Working Group Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants Does "retired" mean that the code would be formally withdrawn? Assuming it means this, does that mean that the code would never be reused for some other language? Addison Peter Constable wrote: > Clarification on "withdrawn": nothing that gets coded will later be un-co= ded: if language Foo is assign an ID "foo", then Foo will always be coded a= s "foo". But "foo" can be retired/deprecated. > > Peter > > -----Original Message----- > From: Doug Ewell [mailto:dewell@roadrunner.com] > Sent: Wednesday, August 08, 2007 11:45 PM > To: LTRU Working Group > Cc: Karen_Broome@spe.sony.com > Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants > > wrote: > >> Just confirming that the deprecated tag is preferred. (Seems a little >> counterintuitive?) > > It won't be the last time. The ISO 639-3 folks have made it known that > A might be withdrawn and replaced by B and C, or vice versa, on an > annual-review basis as supported by linguistic research. We might have > a lot more cases like Serbo-Croatian in the future. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- 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 Aug 10 04:52: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 1IJQEc-0003jh-Ur; Fri, 10 Aug 2007 04:52:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJQEc-0003jX-7I for ltru-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 04:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJQEb-0003jP-U0 for ltru@ietf.org; Fri, 10 Aug 2007 04:52:41 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJQEa-0006gU-0B for ltru@ietf.org; Fri, 10 Aug 2007 04:52:41 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l7A8qaI7021621 for ; Fri, 10 Aug 2007 17:52:36 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2ad7_0adb6c28_471f_11dc_9d43_0014221fa3c9; Fri, 10 Aug 2007 17:52:36 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60391) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Aug 2007 17:49:56 +0900 Message-Id: <6.0.0.20.2.20070809085736.0b53c4a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 09 Aug 2007 09:05:48 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Serbo-Croatian Deprecations and Variants In-Reply-To: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> References: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:21 07/08/08, Doug Ewell wrote: > wrote: >You can't use 'hbs' in any case, because it is defined in ISO 639-3 as equivalent to 'sh' (see http://www.sil.org/iso639-3/documentation.asp?id=hbs). Whenever an alpha-2 and an alpha-3 code element exist for the same language, only the alpha-2 can be used in a language tag. Yes, very much so. >That has been the rule since RFC 3066 first allowed alpha-3 subtags, and in the 4646 era we implement it by not putting the alpha-3 in the Registry. Just cross-checking to be sure (and offline, so not able to look at the document directly): Is this rule worded so that it clearly includes all kinds of different sources? Regards, Martin. >What makes Serbo-Croatian unusual in this regard is that there was a code element for it in ISO 639-1 (sh) and there is now one in 639-3 (hbs), but apparently never in ISO 639-2. Furthermore, and strangely, the deletion of 'sh' from ISO 639-1 is no longer listed on the ISO 639-2/RA Change Notice page, even though we know it was once there because we gave 'sh' a Deprecated date of 2000-02-18 in the Registry (the same day Bosnian and many others were added). > >The resurrection of Serbo-Croatian as an ISO 639-3 macrolanguage poses an interesting challenge, because deprecation is supposed to be forever in the Registry. (Section 3.4, item 1: "Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over time.") My assumption is that 'sh' has to remain deprecated, and 'hbs' has to remain on the outside looking in. Is there any way in the registry to find that instead of 'hbs', one has to use 'sh'? Or is 'hbs' just simply totally absent from the registry, even from comments? >Back to your question: If you know the content is Serbian, use 'sr'; if Croatian, use 'hr'; if Bosnian, use 'bs'. If all you know is that it's some type of Serbo-Croatian, and you don't feel comfortable picking one of the other three arbitrarily, your best bet might be to use 'sh' even though Section 3.1.5 says you SHOULD NOT do so, and even though it feels wrong. I think the resurrection of 'hbs' in iso-639-3 shows that the depreciaton of 'sh' was somehow less serious than maybe other depreciations. On a simple level, it didn't make sense to keep in 'sh' if subdivisions were added, especially from a political viewpoint. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 10 10:50: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 1IJVpG-0008JF-LY; Fri, 10 Aug 2007 10:50:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJVpG-0008J5-4k for ltru-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 10:50:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVpF-0008It-Pk for ltru@ietf.org; Fri, 10 Aug 2007 10:50:53 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJVpF-0005Jo-EE for ltru@ietf.org; Fri, 10 Aug 2007 10:50:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070810145050.CIBG16842.mta10.adelphia.net@DGBP7M81>; Fri, 10 Aug 2007 14:50:50 +0000 Message-ID: <00a901c7db5d$d7e9be50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> <6.0.0.20.2.20070809085736.0b53c4a0@localhost> Date: Fri, 10 Aug 2007 07:50:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Karen_Broome@spe.sony.com Subject: [Ltru] Re: Serbo-Croatian Deprecations and Variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> That has been the rule since RFC 3066 first allowed alpha-3 subtags, >> and in the 4646 era we implement it by not putting the alpha-3 in the >> Registry. > > Just cross-checking to be sure (and offline, so not able to look at > the document directly): Is this rule worded so that it clearly > includes all kinds of different sources? Section 2.2.1: "Note: For languages that have both an ISO 639-1 two-character code and an ISO 639-2 three-character code, only the ISO 639-1 two-character code is defined in the IANA registry." To be very strict, this should probably be "... only one subtag, corresponding to the ISO 639-1 two-character code, is defined..." We don't define ISO codes, we define subtags based on them. > Is there any way in the registry to find that instead of 'hbs', one > has to use 'sh'? Or is 'hbs' just simply totally absent from the > registry, even from comments? 'hbs' is totally absent from the Registry, just like 'eng' and 'fra' and 'deu'. > I think the resurrection of 'hbs' in iso-639-3 shows that the > depreciaton of 'sh' was somehow less serious than maybe other > depreciations. On a simple level, it didn't make sense to keep in 'sh' > if subdivisions were added, especially from a political viewpoint. I don't know if it was a less-serious deprecation. ISO 639-3 brought it back as a macrolanguage, a concept which didn't formally exist in -1 and -2. The whole business of splitting the concept of "Serbo-Croatian" on political grounds troubles me. I know there are linguistic differences as well, but mutual non-intelligibility? And in any case, 'no' was not withdrawn when 'nb' and nn' were added. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 10 11:03: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 1IJW1H-0002s0-PL; Fri, 10 Aug 2007 11:03:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJW1F-0002rp-UD for ltru-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJW1F-0002re-KV for ltru@ietf.org; Fri, 10 Aug 2007 11:03:17 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJW1E-0007lz-93 for ltru@ietf.org; Fri, 10 Aug 2007 11:03:17 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070810150315.FWJK27505.mta13.adelphia.net@DGBP7M81>; Fri, 10 Aug 2007 11:03:15 -0400 Message-ID: <00ad01c7db5f$93fa29d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 10 Aug 2007 08:03:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Karen_Broome@spe.sony.com Subject: [Ltru] Re: Serbo-Croatian Deprecations and Variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Just cross-checking to be sure (and offline, so not able to look at > the document directly): Is this rule worded so that it clearly > includes all kinds of different sources? and I quoted RFC 4646: > Section 2.2.1: "Note: For languages that have both an ISO 639-1 > two-character code and an ISO 639-2 three-character code, only the ISO > 639-1 two-character code is defined in the IANA registry." I missed the intent of Martin's question. Draft-4646bis-08 does also include ISO 639-3 in this wording: "Note: For languages that have both an ISO 639-1 two-character code and a three character code assigned by either ISO 639-2 or ISO 639-3, only the ISO 639-1 two-character code is defined in the IANA registry." Language subtags are the only types of subtags for which this issue applies. ISO 3166 defines three-letter and numeric country codes, and ISO 15924 defines numeric script codes, but these are not our concern since they cannot be valid LSR subtags. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 10 13:37: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 1IJYQQ-0000D4-T6; Fri, 10 Aug 2007 13:37:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJYQP-0000Cx-Ph for ltru-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYQP-0000Cp-GA for ltru@ietf.org; Fri, 10 Aug 2007 13:37:25 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYQO-000396-8Y for ltru@ietf.org; Fri, 10 Aug 2007 13:37:25 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 10 Aug 2007 10:37:23 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 10 Aug 2007 10:37:23 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 10 Aug 2007 10:37:21 -0700 Subject: RE: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Topic: [Ltru] Re: Serbo-Croatian Deprecations and Variants Thread-Index: AcfbXdwgLOLaG/GfTrGxc77wDHCglgAFw5Jg Message-ID: References: <001601c7d984$5966faa0$6401a8c0@DGBP7M81> <6.0.0.20.2.20070809085736.0b53c4a0@localhost> <00a901c7db5d$d7e9be50$6401a8c0@DGBP7M81> In-Reply-To: <00a901c7db5d$d7e9be50$6401a8c0@DGBP7M81> 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: 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: , Errors-To: ltru-bounces@ietf.org From: Doug Ewell [mailto:dewell@roadrunner.com] > To be very strict, this should probably be "... only one subtag, > corresponding to the ISO 639-1 two-character code, is defined..." We > don't define ISO codes, we define subtags based on them. I'd be inclined to say we don't define subtags; we register them. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 11 14:07: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 1IJvN8-000086-Uf; Sat, 11 Aug 2007 14:07:34 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IJvN8-000080-7V for ltru-confirm+ok@megatron.ietf.org; Sat, 11 Aug 2007 14:07:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvN7-00007s-Ta for ltru@ietf.org; Sat, 11 Aug 2007 14:07:33 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJvN7-0004iT-Ki for ltru@ietf.org; Sat, 11 Aug 2007 14:07:33 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070811180731.FGLZ6544.mta11.adelphia.net@DGBP7M81> for ; Sat, 11 Aug 2007 14:07:31 -0400 Message-ID: <006901c7dc42$7c5388b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Aug 2007 11:07:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Serbo-Croatian Deprecations and Variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> To be very strict, this should probably be "... only one subtag, >> corresponding to the ISO 639-1 two-character code, is defined..." We >> don't define ISO codes, we define subtags based on them. > > I'd be inclined to say we don't define subtags; we register them. Fair enough. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 17 01:46: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 1ILuex-00015L-13; Fri, 17 Aug 2007 01:46:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1ILuev-00015D-VR for ltru-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 01:46:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILuev-000155-KE for ltru@ietf.org; Fri, 17 Aug 2007 01:46:09 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILuev-0003kl-4G for ltru@ietf.org; Fri, 17 Aug 2007 01:46:09 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070817054608.SZMD19326.mta15.adelphia.net@DGBP7M81> for ; Fri, 17 Aug 2007 01:46:08 -0400 Message-ID: <019301c7e091$e8f1f800$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 16 Aug 2007 22:46:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ltru] Notes before draft-4645bis-02 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'm getting ready to put together draft-ietf-ltru-4645bis-02, and I have a few random comments for the list before I do. I'm going to go ahead and be consistent with the model set in draft-4646bis-07, which has both extlang subtags and the Macrolanguage field, though I continue to believe only one of these features should ultimately be offered, to avoid needless confusion and duplication. Only seven primary language subtags will have a Macrolanguage field; for all the non-sign language extlangs -- 330 of them -- the Macrolanguage and Prefix fields will contain the exact same information. One result of using extlangs is that the new ISO 639-3 code elements for sign languages will continue to be implemented as extlangs. British Sign Language will be coded as "sgn-bfi" and not "bfi". There are 152 of these. The reloaded Registry provided in draft-4645bis will continue to use hex NCRs instead of UTF-8, because Internet-Drafts must be all ASCII. IANA will be responsible for converting the hex NCRs into UTF-8. They have indicated that they can handle this, and I am willing to help with the process if needed. We need to agree on what to do with almost-identical Description fields that will be created by adopting the exact ISO 639-3 reference names, which is an important point for some. Without some other arrangement, we will have to add: Gwichʼin to the existing Gwich´in N'Ko to the existing N’Ko Macedo Romanian to the existing Macedo-Romanian and keep the following pairs of descriptions which will be separated into their own fields: GeÊ»ez and Ge'ez Hangul and HangÅ­l (plus Hangeul) Hanunoo and Hanunóo (Whether your e-mail system shows or does not show the correct UTF-8 characters above, the problem should be apparent.) At this point, exactly 7,223 new language and extlang subtags will be added to the existing 490 language subtags. As in previous drafts, the capitalization of the grandfathered tag "yi-latn" will be canonicalized to "yi-Latn", and the language subtags "anp" and "frr" will be moved out of the range of 2-letter subtags and into alphabetical order within the 3-letter range. Draft-4645bis-02 will add script subtag "Avst" to this list, which was inserted ahead of "Arab" and "Armn" in the existing Registry. RFC 4646 says it is not an error for IANA to insert new subtags out of alphabetical order, but I think it would be more consistent to reload the Registry with them in order, and others have not objected in the past. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 17 18:18: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 1IMA9T-0001Qs-KV; Fri, 17 Aug 2007 18:18:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMA9S-0001ND-Kr for ltru-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 18:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMA9S-0001MT-Ak for ltru@ietf.org; Fri, 17 Aug 2007 18:18:42 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMA9R-0004lR-R8 for ltru@ietf.org; Fri, 17 Aug 2007 18:18:42 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IMA9P-0000ou-D7; Fri, 17 Aug 2007 18:18:39 -0400 Date: Fri, 17 Aug 2007 18:18:39 -0400 To: Doug Ewell Subject: Re: [Ltru] Notes before draft-4645bis-02 Message-ID: <20070817221839.GP13031@mercury.ccil.org> References: <019301c7e091$e8f1f800$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019301c7e091$e8f1f800$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I'm going to go ahead and be consistent with the model set in > draft-4646bis-07, which has both extlang subtags and the Macrolanguage > field, though I continue to believe only one of these features should > ultimately be offered, to avoid needless confusion and duplication. I've been trying to think how to formulate my perception that both extlangs and the Macrolanguage: header have their place for some weeks now, but am not entirely satisfied with any of it. However, I'm going to go ahead rather than continue in silence. I think that extlang subtags and the Macrolanguage: header serve separate purposes. Extlang subtags are normative, and provide a shim between the 639-2 world we are in and the 639-3 world we are going to. I would be quite happy if, after the initial load, no more extlang subtags were created *ever*. It just allows people to tag their Algerian Arabic content unambiguously without breaking the link to the existing tag "ar". The Macrolanguage: header, however, is informative, not normative, and it's subject to change as SIL adds and removes languages. If a language is split, the old tag may become a macrolanguage rather than being retired by SIL (though this has not happened so far); if two languages are merged, a new macrolanguage level may be created above them. A language may be moved into or out of an existing macrolanguage cluster. All of this change we can adapt to in order to provide additional assistance to "RFC 4647 plus" matchers. Authoritatively recording the relationship between no, nb, and nn can't be anything but useful to those who care, and at worst an excrescence (but a small one) to those who don't. Comments? > We need to agree on what to do with almost-identical Description fields > that will be created by adopting the exact ISO 639-3 reference names, > which is an important point for some. Let's blow off the 639-2 names; they are much less well checked and maintained, and the field is only informative anyhow. > As in previous drafts, [...] +1 to all. -- We do, doodley do, doodley do, doodley do, John Cowan What we must, muddily must, muddily must, muddily must; Muddily do, muddily do, muddily do, muddily do, http://www.ccil.org/~cowan Until we bust, bodily bust, bodily bust, bodily bust. --Bokonon _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 18 01:17:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMGh3-0001kC-SA; Sat, 18 Aug 2007 01:17:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMGh2-0001k7-LW for ltru-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 01:17:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMGh1-0001jz-2h for ltru@ietf.org; Sat, 18 Aug 2007 01:17:47 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMGgy-0008KZ-SI for ltru@ietf.org; Sat, 18 Aug 2007 01:17:46 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070818051744.VLLM16955.mta11.adelphia.net@DGBP7M81> for ; Sat, 18 Aug 2007 01:17:44 -0400 Message-ID: <001901c7e157$1bad3910$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 17 Aug 2007 22:17:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] New draft posted to Web X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org An editor's copy of draft-ietf-ltru-4645bis-02 has been posted to my Web site: http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-02.html http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-02.txt Please review and offer comments. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 18 11:42: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 1IMQRn-0003c9-Bi; Sat, 18 Aug 2007 11:42:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMQRm-0003c2-1K for ltru-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 11:42:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMQRl-0003bu-NT for ltru@ietf.org; Sat, 18 Aug 2007 11:42:41 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMQRl-0006aK-Ec for ltru@ietf.org; Sat, 18 Aug 2007 11:42:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YA+NMUjtcJ/OHg3sN3GBarEHyYAesG6Q87lApYlSCWLwmU5U3XTZ02o2exuWeiBN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.121] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IMQRk-0000vJ-Jg for ltru@ietf.org; Sat, 18 Aug 2007 11:42:40 -0400 Message-ID: <000601c7e1ae$b416ca20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001901c7e157$1bad3910$6401a8c0@DGBP7M81> Subject: Re: [Ltru] New draft posted to Web Date: Sat, 18 Aug 2007 08:44:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93566f16a081c05ba325858a7c8667a2b290350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, August 17, 2007 10:17 PM > Subject: [Ltru] New draft posted to Web > > An editor's copy of draft-ietf-ltru-4645bis-02 has been posted to my Web > site: ... Please, if you want the working group to comment, submit the draft to internet-drafts@ietf.org Working from "editor's copies" gives the impression that internet-drafts have more weight than they do. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 18 13:28: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 1IMS5g-00031P-Vz; Sat, 18 Aug 2007 13:28:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMS5f-0002zB-FA for ltru-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 13:27:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMS5e-0002xs-F1 for ltru@ietf.org; Sat, 18 Aug 2007 13:27:58 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMS5e-0001Mw-4A for ltru@ietf.org; Sat, 18 Aug 2007 13:27:58 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070818172757.DLDY19326.mta15.adelphia.net@DGBP7M81> for ; Sat, 18 Aug 2007 13:27:57 -0400 Message-ID: <002b01c7e1bd$1e19e2f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 18 Aug 2007 10:27:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: New draft posted to Web X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Please, if you want the working group to comment, submit the draft to > internet-drafts at ietf.org Done. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 18 14:01: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 1IMSc6-0003ud-P3; Sat, 18 Aug 2007 14:01:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMSc6-0003uX-0X for ltru-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 14:01:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMSc5-0003uP-Mf for ltru@ietf.org; Sat, 18 Aug 2007 14:01:29 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMSc5-0002RE-9T for ltru@ietf.org; Sat, 18 Aug 2007 14:01:29 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070818180128.WZTN4998.mta10.adelphia.net@DGBP7M81>; Sat, 18 Aug 2007 18:01:28 +0000 Message-ID: <006101c7e1c1$ccce7a50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 18 Aug 2007 11:01:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] Re: Notes before draft-4645bis-02 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I think that extlang subtags and the Macrolanguage: header serve > separate purposes... The draft I just submitted supports both, and I fixed my program that converts the ISO 639-3 files to subtags so it will handle all three models: extlang only (as in previous drafts), Macrolanguage field only, or both (as in this draft), so future drafts can follow whichever model the group prefers. > Let's blow off the 639-2 names; they are much less well checked and > maintained, and the field is only informative anyhow. I thought we actively decided to change "N'Ko" (the language) to use the U+2019 curly apostrophe, to match the script name which came from ISO 15924. "Gwich´in" is a known abomination which was fixed within 639-2. "Macedo Romanian" is probably just a matter of inconsistent style. But the three latter examples all come from 15924, whose Registration Authority can probably be assumed to know about character choices. :-) I don't mind Hangul and HangÅ­l, and Hanunoo and Hanunóo so much -- at least they're visually distinguishable -- but I really don't like GeÊ»ez and Ge'ez. If it were up to me I'd pick one of those two and discard the other. Anyway, the draft has been submitted to the RFC Editor with both fields, and with all names, so I hope the group provides thoughtful and timely feedback on what it really wants so we can finish this project. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 19 21:39: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 1IMwFA-0005gw-Ss; Sun, 19 Aug 2007 21:39:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMwF9-0005gr-SK for ltru-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 21:39:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMwF9-0005gi-IF for ltru@ietf.org; Sun, 19 Aug 2007 21:39:47 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMwF9-0007pV-8q for ltru@ietf.org; Sun, 19 Aug 2007 21:39:47 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070820013946.MQHX16955.mta11.adelphia.net@DGBP7M81>; Sun, 19 Aug 2007 21:39:46 -0400 Message-ID: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 19 Aug 2007 18:39:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Michelle Cotton Subject: [Ltru] Talking about UTF-8 in 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Draft-4645bis-02 doesn't make any mention of UTF-8, or of the fact that IANA must convert the "meat" of the document to UTF-8 in the process of reloading the Registry. I'm guessing that it should, but where would be a suitable place? Draft-4646bis-08 already talks about the Reviewer's and IANA's responsibilities in converting data to UTF-8, and I don't think it would be appropriate for draft-4645bis to supersede or contradict that. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 20 00:05:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMyWT-0005hb-6M; Mon, 20 Aug 2007 00:05:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IMyWS-0005hV-Eo for ltru-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 00:05:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMyWS-0005hM-1l for ltru@ietf.org; Mon, 20 Aug 2007 00:05:48 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMyWR-0002qe-GF for ltru@ietf.org; Mon, 20 Aug 2007 00:05:47 -0400 Received: from [10.72.73.50] (snvvpn1-10-72-73-c50.corp.yahoo.com [10.72.73.50]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7K45D9N059909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Aug 2007 21:05:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=QC4yYELm9AcWHDmFBEVerdWm8axMPQ+9FksPS3tGmdZGxKQmKMGtC6cJYI5/NrDn Message-ID: <46C912F9.1040508@yahoo-inc.com> Date: Sun, 19 Aug 2007 21:05:13 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Talking about UTF-8 in 4645bis References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> In-Reply-To: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Michelle Cotton , 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'd suggest: In either section 2.5, as part of the introductory bits of section 3, or in section 5, add the text: -- The final registry format uses the UTF-8 character encoding. Non-ASCII characters represented in this document by XML hex entities (such as ´) were converted by IANA to Unicode characters in the UTF-8 encoding when the updated registry was instantiated. -- We don't say (or need to say) how. Addison Doug Ewell wrote: > Draft-4645bis-02 doesn't make any mention of UTF-8, or of the fact that > IANA must convert the "meat" of the document to UTF-8 in the process of > reloading the Registry. I'm guessing that it should, but where would be > a suitable place? > > Draft-4646bis-08 already talks about the Reviewer's and IANA's > responsibilities in converting data to UTF-8, and I don't think it would > be appropriate for draft-4645bis to supersede or contradict that. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 20 02:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1Ev-0007NB-2G; Mon, 20 Aug 2007 02:59:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IN1Et-0007N0-Tv for ltru-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 02:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1Et-0007Mr-KM for ltru@ietf.org; Mon, 20 Aug 2007 02:59:51 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1Et-00045B-6w for ltru@ietf.org; Mon, 20 Aug 2007 02:59:51 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070820065950.JJAA19326.mta15.adelphia.net@DGBP7M81>; Mon, 20 Aug 2007 02:59:50 -0400 Message-ID: <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "Addison Phillips" References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Sun, 19 Aug 2007 23:59:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Michelle Cotton , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I'd suggest: In either section 2.5, as part of the introductory bits > of section 3, or in section 5, add the text: > > -- > The final registry format uses the UTF-8 character encoding. Non-ASCII > characters represented in this document by XML hex entities (such as > ´) were converted by IANA to Unicode characters in the UTF-8 > encoding when the updated registry was instantiated. I've added this to Section 3, after the RFC Editor Note. As such, it's now an instruction to IANA about reloading the Registry, so I've converted it to the present tense. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 20 11:44: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 1IN9QJ-0007Lu-34; Mon, 20 Aug 2007 11:44:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IN9QH-0007Lp-N9 for ltru-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9QH-0007Lh-Dd for ltru@ietf.org; Mon, 20 Aug 2007 11:44:09 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN9QG-0000Bz-2W for ltru@ietf.org; Mon, 20 Aug 2007 11:44:09 -0400 Received: from [10.72.73.50] (snvvpn1-10-72-73-c50.corp.yahoo.com [10.72.73.50]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7KFhemQ005014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 08:43:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=rDcHgsizKVS9F11rzc5khgJatjno/kjOVDSPIhEIBgw5eXWHpVB6+I9j7GiupHPN Message-ID: <46C9B6AC.7070209@yahoo-inc.com> Date: Mon, 20 Aug 2007 08:43:40 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Talking about UTF-8 in 4645bis References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> In-Reply-To: <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Michelle Cotton , 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 Actually, I was thinking of adding the present tense version and some MUSTard in Section 3.8 (Update of the Language Subtag Registry) of 4646bis. In reading the current draft of your document, I didn't see any specific IANA instructions, and so guessed that it should use the past tense (as a matter of historical record). Not that it makes much difference. What matters is that IANA knows what to do. Doug Ewell wrote: > Addison Phillips wrote: > >> I'd suggest: In either section 2.5, as part of the introductory bits >> of section 3, or in section 5, add the text: >> >> -- >> The final registry format uses the UTF-8 character encoding. Non-ASCII >> characters represented in this document by XML hex entities (such as >> ´) were converted by IANA to Unicode characters in the UTF-8 >> encoding when the updated registry was instantiated. > > I've added this to Section 3, after the RFC Editor Note. As such, it's > now an instruction to IANA about reloading the Registry, so I've > converted it to the present tense. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > -- 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 Aug 21 10:22: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 1INUcU-0005LE-1f; Tue, 21 Aug 2007 10:22:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INUcS-0005JB-Qb for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 10:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUcS-0005J3-H7 for ltru@ietf.org; Tue, 21 Aug 2007 10:22:08 -0400 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INUcR-00034B-W7 for ltru@ietf.org; Tue, 21 Aug 2007 10:22:08 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070821142207.NUHA20752.mta16.adelphia.net@DGBP7M81>; Tue, 21 Aug 2007 10:22:07 -0400 Message-ID: <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "Addison Phillips" References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 07:22:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Michelle Cotton , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Actually, I was thinking of adding the present tense version and some > MUSTard in Section 3.8 (Update of the Language Subtag Registry) of > 4646bis. In reading the current draft of your document, I didn't see > any specific IANA instructions, and so guessed that it should use the > past tense (as a matter of historical record). Here's what I actually added to draft-03 (which still lives only on my jump drive, given that no comments on draft-02 have emerged yet). This paragraph appears right after "must not be deleted" and right before the File-Date record. "The Language Subtag Registry uses the UTF-8 character encoding. Non-ASCII characters represented in this document by XML hex entities (such as &#xB4;) MUST be converted by IANA to Unicode characters in the UTF-8 encoding when the updated Registry is instantiated." How is that? Anyone? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 10:45: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 1INUyo-0004Kd-Dz; Tue, 21 Aug 2007 10:45:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INUyn-0004Jb-0S for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 10:45:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUym-0004JI-BX for ltru@ietf.org; Tue, 21 Aug 2007 10:45:12 -0400 Received: from mail19.svc.cra.dublin.eircom.net ([159.134.118.218]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INUyl-0008W7-Kj for ltru@ietf.org; Tue, 21 Aug 2007 10:45:12 -0400 Received: (qmail 28848 messnum 7111735 invoked from network[194.125.174.96/ts09-096.dublin.indigo.ie]); 21 Aug 2007 14:31:53 -0000 Received: from ts09-096.dublin.indigo.ie (HELO ?194.125.174.96?) (194.125.174.96) by mail19.svc.cra.dublin.eircom.net (qp 28848) with SMTP; 21 Aug 2007 14:31:53 -0000 In-Reply-To: <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 15:32:00 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "Instantiated" just means "represented by an instance" (check your =20 Concise Oxford). Please make it less hard on users, perhaps by using =20 "instated" (or something even simpler again). mg On 21 Aug 2007, at 14:22, scr=EDobh Doug Ewell: > Addison Phillips wrote: > > > >> Actually, I was thinking of adding the present tense version and =20 >> some MUSTard in Section 3.8 (Update of the Language Subtag =20 >> Registry) of 4646bis. In reading the current draft of your =20 >> document, I didn't see any specific IANA instructions, and so =20 >> guessed that it should use the past tense (as a matter of =20 >> historical record). >> >> > > Here's what I actually added to draft-03 (which still lives only on =20= > my jump drive, given that no comments on draft-02 have emerged =20 > yet). This paragraph appears right after "must not be deleted" and =20= > right before the File-Date record. > > "The Language Subtag Registry uses the UTF-8 character encoding. =20 > Non-ASCII characters represented in this document by XML hex =20 > entities (such as &#xB4;) MUST be converted by IANA to Unicode =20 > characters in the UTF-8 encoding when the updated Registry is =20 > instantiated." > > How is that? Anyone? > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Marion Gunn mgunn@ucd.ie - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 12:44: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 1INWpo-00054C-A9; Tue, 21 Aug 2007 12:44:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INWpn-00052z-1Y for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 12:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWpm-00052r-Jp for ltru@ietf.org; Tue, 21 Aug 2007 12:44:02 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INWpl-0000LB-Tg for ltru@ietf.org; Tue, 21 Aug 2007 12:44:02 -0400 Received: from [10.72.76.30] (snvvpn2-10-72-76-c30.corp.yahoo.com [10.72.76.30]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7LGhkp9024211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 09:43:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=jYc5hIqvGNw65v+/cwyyPh0Yr3Tt+1EYMHOqxzV+rKTHlp6gd9PqbxnUndOZUndD Message-ID: <46CB1641.3090809@yahoo-inc.com> Date: Tue, 21 Aug 2007 09:43:45 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> 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 l7LGhkp9024211 X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 (laughing) 'Instantiated' is a bit of programming jargon. It will be=20 well-understood by that portion of the reader community. I didn't mean=20 to send anyone to their Oxford dictionary (concise or otherwise). The important connotation of the word "instantiated" here is that the=20 act of instantiation is the creation of the registry. If we were to=20 replace the word (unnecessary, I think), it would be with the word=20 "created". Best Regards, Addison --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. Marion Gunn wrote: > "Instantiated" just means "represented by an instance" (check your=20 > Concise Oxford). Please make it less hard on users, perhaps by using=20 > "instated" (or something even simpler again). > mg > On 21 Aug 2007, at 14:22, scr=C3=ADobh Doug Ewell: >=20 >=20 >> Addison Phillips wrote: >> >> >> >>> Actually, I was thinking of adding the present tense version and some= =20 >>> MUSTard in Section 3.8 (Update of the Language Subtag Registry) of=20 >>> 4646bis. In reading the current draft of your document, I didn't see=20 >>> any specific IANA instructions, and so guessed that it should use the= =20 >>> past tense (as a matter of historical record). >>> >>> >> >> Here's what I actually added to draft-03 (which still lives only on my= =20 >> jump drive, given that no comments on draft-02 have emerged yet). =20 >> This paragraph appears right after "must not be deleted" and right=20 >> before the File-Date record. >> >> "The Language Subtag Registry uses the UTF-8 character encoding.=20 >> Non-ASCII characters represented in this document by XML hex entities=20 >> (such as &#xB4;) MUST be converted by IANA to Unicode characters=20 >> in the UTF-8 encoding when the updated Registry is instantiated." >> >> How is that? Anyone? >> >> --=20 >> Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >> http://users.adelphia.net/~dewell/ >> http://www1.ietf.org/html.charters/ltru-charter.html >> http://www.alvestrand.no/mailman/listinfo/ietf-languages >> >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >=20 > --=20 > Marion Gunn > mgunn@ucd.ie >=20 >=20 >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=C3=A1irc an Fh=C3=A9ithlinn, Baile an > Bh=C3=B3thair, Co. =C3=81tha Cliath, =C3=89ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 13:17: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 1INXM4-0004KA-JB; Tue, 21 Aug 2007 13:17:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INXM2-0004J9-Pd for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 13:17:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INXM2-0004Iv-FR for ltru@ietf.org; Tue, 21 Aug 2007 13:17:22 -0400 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INXM1-0005wU-WE for ltru@ietf.org; Tue, 21 Aug 2007 13:17:22 -0400 Received: (qmail 627 messnum 2893082 invoked from network[194.125.174.111/ts09-111.dublin.indigo.ie]); 21 Aug 2007 17:17:20 -0000 Received: from ts09-111.dublin.indigo.ie (HELO ?194.125.174.111?) (194.125.174.111) by mail06.svc.cra.dublin.eircom.net (qp 627) with SMTP; 21 Aug 2007 17:17:20 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <46CB1641.3090809@yahoo-inc.com> References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> <46CB1641.3090809@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 18:17:28 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I happen to know that particular piece of programming jargon, =20 Addison, too, but do _not_ believe that all the target community can =20 be expected to do so. I do believe that it it would be easier for =20 such users if you used another word simply indicating the "creation =20 of the registry", as you put it. So much of my life is dedicated to =20 collecting and compiling dictionaries and standardizing new =20 terminology that I tend now to believe the simpler approach tends to =20 foster better comprehension. Not fighting the jargon at all - if you =20 like it, leave it in. mg On 21 Aug 2007, at 16:43, scr=EDobh Addison Phillips: > (laughing) 'Instantiated' is a bit of programming jargon. It will =20 > be well-understood by that portion of the reader community. I =20 > didn't mean to send anyone to their Oxford dictionary (concise or =20 > otherwise). > > The important connotation of the word "instantiated" here is that =20 > the act of instantiation is the creation of the registry. If we =20 > were to replace the word (unnecessary, I think), it would be with =20 > the word "created". > > Best Regards, > > Addison - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 13:30: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 1INXYT-0007Rx-3U; Tue, 21 Aug 2007 13:30:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INXYR-0007Rn-G3 for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 13:30:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INXYR-0007Re-6O for ltru@ietf.org; Tue, 21 Aug 2007 13:30:11 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INXYQ-0001bR-J8 for ltru@ietf.org; Tue, 21 Aug 2007 13:30:11 -0400 Received: from [10.72.76.30] (snvvpn2-10-72-76-c30.corp.yahoo.com [10.72.76.30]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7LHTpuS029713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 10:29:51 -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=IGvxSZhDXVF0sdYnp9EEGHnhfYCGwlO0qUWe1MxKSIM+VM+L8rfdL9V9ZkR1JCzN Message-ID: <46CB210F.8060206@yahoo-inc.com> Date: Tue, 21 Aug 2007 10:29:51 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> <46CB1641.3090809@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id l7LHTpuS029713 X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 In this case, you have to convince Doug: he's the editor of 4645bis :-). Addison Marion Gunn wrote: > I happen to know that particular piece of programming jargon, Addison,=20 > too, but do _not_ believe that all the target community can be expected= =20 > to do so. I do believe that it it would be easier for such users if you= =20 > used another word simply indicating the "creation of the registry", as=20 > you put it. So much of my life is dedicated to collecting and compiling= =20 > dictionaries and standardizing new terminology that I tend now to=20 > believe the simpler approach tends to foster better comprehension. Not=20 > fighting the jargon at all - if you like it, leave it in. > mg > On 21 Aug 2007, at 16:43, scr=C3=ADobh Addison Phillips: >=20 >> (laughing) 'Instantiated' is a bit of programming jargon. It will be=20 >> well-understood by that portion of the reader community. I didn't mean= =20 >> to send anyone to their Oxford dictionary (concise or otherwise). >> >> The important connotation of the word "instantiated" here is that the=20 >> act of instantiation is the creation of the registry. If we were to=20 >> replace the word (unnecessary, I think), it would be with the word=20 >> "created". >> >> Best Regards, >> >> Addison >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=C3=A1irc an Fh=C3=A9ithlinn, Baile an > Bh=C3=B3thair, Co. =C3=81tha Cliath, =C3=89ire. > * mgunn@egt.ie * eamonn@egt.ie * >=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 Tue Aug 21 13:39: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 1INXh0-0004nw-GU; Tue, 21 Aug 2007 13:39:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INXgz-0004nq-I1 for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 13:39:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INXgz-0004ni-7x for ltru@ietf.org; Tue, 21 Aug 2007 13:39:01 -0400 Received: from mail09.svc.cra.dublin.eircom.net ([159.134.118.25]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INXgy-0006aF-Mv for ltru@ietf.org; Tue, 21 Aug 2007 13:39:00 -0400 Received: (qmail 38371 messnum 2888840 invoked from network[194.125.174.33/ts09-033.dublin.indigo.ie]); 21 Aug 2007 17:38:59 -0000 Received: from ts09-033.dublin.indigo.ie (HELO ?194.125.174.33?) (194.125.174.33) by mail09.svc.cra.dublin.eircom.net (qp 38371) with SMTP; 21 Aug 2007 17:38:59 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <46CB210F.8060206@yahoo-inc.com> References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> <46CB1641.3090809@yahoo-inc.com> <46CB210F.8060206@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4A5372AE-5B60-48A1-BBFE-DC8B70945B4D@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 18:39:07 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mostly, I get paid for de-jargonizing things for clients who afraid =20 their in-house covens are scaring away more customers than they =20 attract - here, Doug gets my advice for free!:-) mg On 21 Aug 2007, at 17:29, scr=EDobh Addison Phillips: > In this case, you have to convince Doug: he's the editor of =20 > 4645bis :-). > > Addison - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 13:43: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 1INXlS-000070-0x; Tue, 21 Aug 2007 13:43:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INXlQ-0008Uu-SW for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 13:43:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INXlQ-0008Ul-Hj for ltru@ietf.org; Tue, 21 Aug 2007 13:43:36 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INXlQ-0006iy-5s for ltru@ietf.org; Tue, 21 Aug 2007 13:43:36 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.0) with ESMTP id md50007128179.msg for ; Tue, 21 Aug 2007 18:45:49 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 21 Aug 2007 18:43:35 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81><46C912F9.1040508@yahoo-inc.com><010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81><46C9B6AC.7070209@yahoo-inc.com><006501c7e3fe$a7b87330$6401a8c0@DGBP7M81><46CB1641.3090809@yahoo-inc.com><46CB210F.8060206@yahoo-inc.com> <4A5372AE-5B60-48A1-BBFE-DC8B70945B4D@egt.ie> Subject: RE: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 18:38:49 +0100 Message-ID: <012f01c7e41a$222e70e0$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <4A5372AE-5B60-48A1-BBFE-DC8B70945B4D@egt.ie> Thread-Index: AcfkGkKKFsZkSbZoSNqkdqxkW14LjgAADs5g Received-SPF: neutral (145.nexbyte.net: 83.67.121.192 is neither permitted nor denied by domain of ictmarketing.co.uk) client-ip=83.67.121.192 X-Spam-Processed: mx1.nexbyte.net, Tue, 21 Aug 2007 18:45:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1753d432e8=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 21 Aug 2007 18:45:50 +0100 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There is definitely scope for a plain english campaign here :-) Best Debbie > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie] > Sent: 21 August 2007 19:39 > To: LTRU Working Group > Subject: Re: [Ltru] Talking about UTF-8 in 4645bis > > Mostly, I get paid for de-jargonizing things for clients who afraid > their in-house covens are scaring away more customers than they > attract - here, Doug gets my advice for free!:-) mg On 21 Aug > 2007, at 17:29, scríobh Addison Phillips: > > > In this case, you have to convince Doug: he's the editor of 4645bis > > :-). > > > > Addison > > - - > Marion Gunn * EGTeo (Estab.1991) > 27 Páirc an Fhéithlinn, Baile an > Bhóthair, Co. Átha Cliath, Éire. > * mgunn@egt.ie * eamonn@egt.ie * > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 13:43: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 1INXlZ-0000IJ-5G; Tue, 21 Aug 2007 13:43:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INXlX-0000IC-Ve for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 13:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INXlX-0000I3-M8 for ltru@ietf.org; Tue, 21 Aug 2007 13:43:43 -0400 Received: from mail20.svc.cra.dublin.eircom.net ([159.134.118.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INXlW-0002Bh-0M for ltru@ietf.org; Tue, 21 Aug 2007 13:43:43 -0400 Received: (qmail 38248 messnum 3575186 invoked from network[194.125.174.33/ts09-033.dublin.indigo.ie]); 21 Aug 2007 17:43:33 -0000 Received: from ts09-033.dublin.indigo.ie (HELO ?194.125.174.33?) (194.125.174.33) by mail20.svc.cra.dublin.eircom.net (qp 38248) with SMTP; 21 Aug 2007 17:43:33 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <4A5372AE-5B60-48A1-BBFE-DC8B70945B4D@egt.ie> References: <00e201c7e2ca$fd7430f0$6401a8c0@DGBP7M81> <46C912F9.1040508@yahoo-inc.com> <010401c7e2f7$b3fcff10$6401a8c0@DGBP7M81> <46C9B6AC.7070209@yahoo-inc.com> <006501c7e3fe$a7b87330$6401a8c0@DGBP7M81> <46CB1641.3090809@yahoo-inc.com> <46CB210F.8060206@yahoo-inc.com> <4A5372AE-5B60-48A1-BBFE-DC8B70945B4D@egt.ie> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7D929D13-2B06-4D48-B178-51CE137270A0@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Talking about UTF-8 in 4645bis Date: Tue, 21 Aug 2007 18:43:48 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Recte "are afraid". Actually, I first wrote "coveys", but replaced it =20= with "covens", in case that would send too many members of this list =20 fumbling for the nearest dictionary to hand. mg On 21 Aug 2007, at 18:39, Marion Gunn: > Mostly, I get paid for de-jargonizing things for clients who afraid =20= > their in-house covens are scaring away more customers than they =20 > attract - here, Doug gets my advice for free!:-) > mg > On 21 Aug 2007, at 17:29, scr=EDobh Addison Phillips: > > >> In this case, you have to convince Doug: he's the editor of =20 >> 4645bis :-). >> >> Addison >> > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 21 21:45: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 1INfHv-0003Rb-OG; Tue, 21 Aug 2007 21:45:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INfHt-0003OB-Hl for ltru-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 21:45:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INfHt-0003Nu-65 for ltru@ietf.org; Tue, 21 Aug 2007 21:45:37 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound3-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INfHr-0003BU-44 for ltru@ietf.org; Tue, 21 Aug 2007 21:45:36 -0400 Received: from outbound3-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-sin-R.bigfish.com (Postfix) with ESMTP id AABAB811FD2; Wed, 22 Aug 2007 01:45:33 +0000 (UTC) Received: from mail213-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound3-sin.bigfish.com (Postfix) with ESMTP id A04C2DD004D; Wed, 22 Aug 2007 01:45:33 +0000 (UTC) Received: from mail213-sin (localhost.localdomain [127.0.0.1]) by mail213-sin-R.bigfish.com (Postfix) with ESMTP id 92CAA124020F; Wed, 22 Aug 2007 01:45:33 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail213-sin (MessageSwitch) id 1187747133530747_10415; Wed, 22 Aug 2007 01:45:33 +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 mail213-sin.bigfish.com (Postfix) with ESMTP id 1B6AA1808071; Wed, 22 Aug 2007 01:45:33 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007082118452885-24928 ; Tue, 21 Aug 2007 18:45:28 -0700 In-Reply-To: To: Caoimhin O Donnaile 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: Tue, 21 Aug 2007 18:43:13 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/21/2007 18:43:14, Serialize complete at 08/21/2007 18:43:14, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/21/2007 06:45:28 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/21/2007 06:45:33 PM, Serialize complete at 08/21/2007 06:45:33 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: IETF Languages Discussion , ltru@ietf.org Subject: [Ltru] Re: Scottish English (was: LANGUAGE SUBTAG REGISTRATION FORM) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0448891986==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0448891986== Content-Type: multipart/alternative; boundary="=_alternative 0009A7D58825733F_=" This is a multipart message in MIME format. --=_alternative 0009A7D58825733F_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Caoimhin, I don't think what I'm seeing referred to as Standard Scottish English is=20 what you're referencing below. I don't see it mentioned as a "business=20 dialect". Do you have a link where this is described? All, Keep in mind: This is not abstract. I have a specific business need and=20 that semantic is best represented by a region. As previously noted, I'll=20 accept a classification of Standard Scottish English, but I don't think=20 this will be as accurate for what I'm trying to classify as "Scottish=20 English." A region tag would cover any Scottish dialect of English found=20 in the film and that's the reality of this situation.=20 Films flagged with the Scottish English tag would be more likely=20 candidates for subtitles or redubbing than other English variants, and the = audience for these films would be different. I need a tag so users will=20 pull the right product from an online retailer, distributors will send the = right product, the right language track is played on a DVD containing=20 multiple audio tracks, video-on-demand will push the right film based on=20 user preferences, we can accurately identify these items in a large=20 archive used to create derivative works and additional versions -- and=20 existing XML formats can effortlessly express all these variations. To be honest, with so much documentation on the Web, a real-life use case, = and a set of ears, I can't believe there is so much controversy over the=20 legitimacy of my request. I would think the controversy would be over the = best way to represent this linguistic entity as there's no way other than=20 a variant tag in RFC 4646 and it seems like there should be. I will need=20 to employ a private use tag if this request is not granted and whatever=20 the resulting tag is, I will need to encourage this use throughout the=20 entertainment industry. If spelling matters in written contexts, surely=20 accents matter in spoken contexts -- even if no differences in word choice = existed.=20 English is a language and Scotland is a well-defined region. There is no=20 controversy about these two statements -- why is there so much controversy = over putting the two together? Isn't this what the variant tag is for? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment Caoimhin O Donnaile =20 Sent by: ietf-languages-bounces@alvestrand.no 08/21/2007 05:39 PM To Michael Everson cc IETF Languages Discussion Subject Re: Scottish English (was: LANGUAGE SUBTAG REGISTRATION FORM) > >But Scottish English is clear and well-defined enough as a variety=20 > >to be worth registering. >=20 > Where and how is it defined? I don't know. Since everything is a continuum between "English", "Scottish English" and "Scots", not to mention the regional variations, any definition would have to be somewhat arbitrary. I am sure, though, that if you did a cluster analysis of English speech throughout Great Britain (having first eliminated anything which you wished to classify as "Scots"), English speech in Scotland would form a distinctive enough cluster to be worth giving a name to. And indeed if you search with Google for "Scottish-English Scots" you get 220,000 hits, showing that "Scottish English" is very often used as a linguistic term. I expect the same kind of problem would arise with most variant tags which people wish to register, apart=20 from those relating to orthographic standards and suchlike. If we wanted to attempt to pin down some kind of demarcation lines at this stage, Derrick McLure at Aberdeen University would be a good contact. > Does "Scottish English" include Glasgow, Edinburgh, Aberdeen, and=20 > Inverness equally? It would certainly include Glasgow, Edinburgh and Inverness. I have never been to Aberdeen, but I expect that a fair bit of the speech on the streets o Aiberdeen would be classed as Scots - more so than in the other Scottish cities. After thinking about it, I share Michael's view that "en-scottish" would be better than an obscure M.49 code, even if one were possible. There was some talk of defining "en-scottish" to be "Standard Scottish English" rather than "Scottish English". I think that would be a bad idea. If I understand things, the archetype of Standard Scottish English would be the English which educated Scottish businessmen would aspire to use among themselves, which would probably exclude a lot of the language in the Glasgow films which Karen needs to catalogue. Contrast: http://www.youtube.com/watch?v=3DwRXfF2sH0aU with: http://www.youtube.com/watch?v=3D6wPf6xR4RTA There is a fair difference between the language in each, I think. Part of it may be that when confronted with a reporter from BBC Scotland speaking something like Scottish Standard English, John Smeaton attempts to match his language to hers. Caoimh=EDn =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages --=_alternative 0009A7D58825733F_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Caoimhin,

I don't think what I'm seeing referr= ed to as Standard Scottish English is what you're referencing below. I don't see it mentioned as a "business dialect". Do you have a link where this is described?

All,

Keep in mind: This is not abstract. I have a specific business need and that semantic is best represented by a region. As previously noted, I'll accept a classification of Standard Scottish English, but I don't think this will be as accurate for what I'm trying to classify as "Scottish English." A region tag would cover any Scottish dialect of English found in the film and that's the reality of this situation.  

Films flagged with the Scottish Engl= ish tag would be more likely candidates for subtitles or redubbing than other English variants, and the audience for these films would be different. I need a tag so users will pull the right product from an online retailer, distributors will send the right product, the right language track is played on a DVD containing multiple audio tracks, video-on-demand will push the right film based on user preferences, we can accurately identify these items in a large archive used to create derivative works and additional versions -- and existing XML formats can effortlessly express all these variations.

To be honest, with so much documenta= tion on the Web, a real-life use case, and a set of ears, I can't believe there is so much controversy over the legitimacy of my request.  I would think the controversy would be over the best way to represent this linguist= ic entity as there's no way other than a variant tag in RFC 4646 and it seems like there should be. I will need to employ a private use tag if this reque= st is not granted and whatever the resulting tag is, I will need to encourage this use throughout the entertainment industry. If spelling matters in written contexts, surely accents matter in spoken contexts -- even if no differences in word choice existed.

English is a language and Scotland is a well-defined region. There is no controversy about these two statements -- why is there so much controversy over putting the two together? Isn't this what the variant tag is for?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment


Caoimhin O Donnaile &= lt;caoimhin@smo.uhi.ac.uk>
Sent by: ietf-languages-bounces@alve= strand.no

08/21/2007 05:39 PM

To
Michael Everson <everson@evertype= .com>
cc
IETF Languages Discussion <ietf-l= anguages@iana.org>
Subject
Re: Scottish English (was: LANGUAGE SUBTAG REGISTRATION FORM)





> >But Scottish English is clear and well-defi= ned enough as a variety
> >to be worth registering.
>
> Where and how is it defined?

I don't know.  Since everything is a continuum between "English&q= uot;,
"Scottish English" and "Scots", not to mention the regional
variations, any definition would have to be somewhat arbitrary.

I am sure, though, that if you did a cluster analysis of English speech
throughout Great Britain (having first eliminated anything which you
wished to classify as "Scots"), English speech in Scotland would<= br> form a distinctive enough cluster to be worth giving a name to.
And indeed if you search with Google for "Scottish-English Scots"=
you get 220,000 hits, showing that "Scottish English" is very
often used as a linguistic term.  I expect the same kind of problem
would arise with most variant tags which people wish to register, apart
from those relating to orthographic standards and suchlike.

If we wanted to attempt to pin down some kind of demarcation lines
at this stage, Derrick McLure at Aberdeen University would be a
good contact.

> Does "Scottish English" include Glasgow, Edinburgh, Aberdeen, and
> Inverness equally?

It would certainly include Glasgow, Edinburgh and Inverness.  I have never been to Aberdeen, but I expect that a fair bit of the speech
on the streets o Aiberdeen would be classed as Scots - more so than
in the other Scottish cities.

After thinking about it, I share Michael's view that "en-scottish"= ;
would be better than an obscure M.49 code, even if one were possible.

There was some talk of defining "en-scottish" to be "Standar= d
Scottish English" rather than "Scottish English".  I think that
would be a bad idea.  If I understand things, the archetype of
Standard Scottish English would be the English which educated
Scottish businessmen would aspire to use among themselves, which
would probably exclude a lot of the language in the Glasgow films
which Karen needs to catalogue.

Contrast:
 http://www.youtube.com/watch?v=3DwRXfF2sH0aU

with:
 http://www.youtube.com/watch?v=3D6wPf6xR4RTA

There is a fair difference between the language in each, I think.
Part of it may be that when confronted with a reporter from
BBC Scotland speaking something like Scottish Standard English,
John Smeaton attempts to match his language to hers.

Caoimh=EDn
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
--=_alternative 0009A7D58825733F_=-- --===============0448891986== 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 --===============0448891986==-- From ltru-bounces@ietf.org Wed Aug 22 02:11: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 1INjRQ-00015Y-6v; Wed, 22 Aug 2007 02:11:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1INjRP-00015P-14 for ltru-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 02:11:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INjRO-00015H-G0 for ltru@ietf.org; Wed, 22 Aug 2007 02:11:42 -0400 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INjRO-0007sq-4M for ltru@ietf.org; Wed, 22 Aug 2007 02:11:42 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070822061141.PUFQ20752.mta16.adelphia.net@DGBP7M81> for ; Wed, 22 Aug 2007 02:11:41 -0400 Message-ID: <006a01c7e483$4ed57850$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 21 Aug 2007 23:11:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: Talking about UTF-8 in 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > In this case, you have to convince Doug: he's the editor of 4645bis > :-). I have no problem with changing this to "created." -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 23 05: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 1IO8og-00013d-2p; Thu, 23 Aug 2007 05:17:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IO8of-0000y6-1I for ltru-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 05:17:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8oe-0000u5-Au for ltru@ietf.org; Thu, 23 Aug 2007 05:17:24 -0400 Received: from mta14.mail.adelphia.net ([68.168.78.137] helo=mta14.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8od-0000dp-U2 for ltru@ietf.org; Thu, 23 Aug 2007 05:17:24 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070820013155.MGRQ16955.mta11.adelphia.net@DGBP7M81> for ; Sun, 19 Aug 2007 21:31:55 -0400 Message-ID: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 19 Aug 2007 18:31:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Ltru] NFC X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, 3 Jul 2007 08:07:18 -0700, Peter Constable wrote: > +1 to specifying NFC (whether we use UTF-8 or NCRs). I don't see this yet in draft-4646bis-08, so I propose the following New Wordingâ„¢ for Section 3.1.1: OLD: Each field can be considered a single, logical line of Unicode [Unicode] characters, comprising a field-name and a field-body separated by a COLON character (%x3A). NEW: Each field can be considered a single, logical line of Unicode [Unicode] characters, comprising a field-name and a field-body separated by a COLON character (%x3A). Each Unicode character MUST be represented in Normalization Form C (NFC), as specified in Unicode Standard Annex #15 [UAX15]. [Note: This will require a new normative reference to UAX #15. I don't know whether it will also require the existing informative reference to the Unicode Standard to be made normative.] OLD: Folding is always done on Unicode code point boundaries (never in the middle of a multibyte UTF-8 sequence). NEW: Folding is always done on Unicode code point boundaries (never in the middle of a multibyte UTF-8 sequence), and SHOULD NOT be done immediately before a combining character as defined by Unicode [Unicode]. [Note: Again, the SHOULD NOT may require the Unicode reference to be normative.] Are there any other places where NFC needs to be mentioned, in either 4646bis or 4645bis? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 23 08:22: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 1IOBho-0002A0-Ff; Thu, 23 Aug 2007 08:22:32 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOBhn-00029u-4d for ltru-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 08:22:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBhm-00029m-Pc for ltru@ietf.org; Thu, 23 Aug 2007 08:22:30 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBhm-0004yp-Dl for ltru@ietf.org; Thu, 23 Aug 2007 08:22:30 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IOBhl-0002IE-GF; Thu, 23 Aug 2007 08:22:29 -0400 Date: Thu, 23 Aug 2007 08:22:29 -0400 To: Doug Ewell Subject: Re: [Ltru] NFC Message-ID: <20070823122229.GA6422@mercury.ccil.org> References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > NEW: > Each field can be considered a single, logical line of Unicode [Unicode] > characters, comprising a field-name and a field-body separated by a > COLON character (%x3A). Each Unicode character MUST be represented in > Normalization Form C (NFC), as specified in Unicode Standard Annex #15 > [UAX15]. Being in NFC is a property of the field as a whole, not of each character. For example, a + COMBINING ACUTE is not NFC, but q + COMBINING ACUTE is. So: s/Each Unicode character/The field > [Note: This will require a new normative reference to UAX #15. I don't > know whether it will also require the existing informative reference to > the Unicode Standard to be made normative.] A normative reference to Unicode is a normative reference to UAX #15, because UAXes are logically part of Unicode, and are kept separate only for maintenance reasons. (They are physically included in TUS 5.0 and later.) > NEW: > Folding is always done on Unicode code point boundaries (never in the > middle of a multibyte UTF-8 sequence), and SHOULD NOT be done > immediately before a combining character as defined by Unicode > [Unicode]. Make that MUST NOT. A combining character applies to the immediatelly preceding base character, and if that happens to be whitespace, that means something different. -- John Cowan http://ccil.org/~cowan cowan@ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 24 02:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSHu-0002KB-PJ; Fri, 24 Aug 2007 02:04:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOSHt-0002K6-MA for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 02:04:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSHt-0002Jy-Bd for ltru@ietf.org; Fri, 24 Aug 2007 02:04:53 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOSHs-0000rh-W7 for ltru@ietf.org; Fri, 24 Aug 2007 02:04:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070824060452.SWNY16955.mta11.adelphia.net@DGBP7M81>; Fri, 24 Aug 2007 02:04:52 -0400 Message-ID: <005301c7e614$afac0850$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> Subject: Re: [Ltru] NFC Date: Thu, 23 Aug 2007 23:04:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Being in NFC is a property of the field as a whole, not of each > character. For example, a + COMBINING ACUTE is not NFC, but q + > COMBINING ACUTE is. So: > > s/Each Unicode character/The field Of course it is. I knew that. > A normative reference to Unicode is a normative reference to UAX #15, > because UAXes are logically part of Unicode, and are kept separate > only for maintenance reasons. (They are physically included in TUS > 5.0 and later.) I'm starting to think I should claim this was really just a Unicode pop quiz in disguise, and John passed. > Make that MUST NOT. A combining character applies to the immediatelly > preceding base character, and if that happens to be whitespace, that > means something different. I almost had a defense here, that line folding would be collapsed to nothing, but of course that's not true either; lines are only folded where whitespace would occur anyway. Any NFC-related edits to 4646bis should follow John's corrections. And Doug needs to go back to Unicode school. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 24 11:47: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 1IObNt-0001RP-54; Fri, 24 Aug 2007 11:47:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IObNr-0001Pf-TR for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 11:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObNr-0001Oi-Ir for ltru@ietf.org; Fri, 24 Aug 2007 11:47:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IObNq-0004Su-9x for ltru@ietf.org; Fri, 24 Aug 2007 11:47:39 -0400 Received: from [10.72.72.191] (snvvpn1-10-72-72-c191.corp.yahoo.com [10.72.72.191]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7OFlSsJ005553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:47:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=lNgmQZI8SECW+c3o5pVEBv9ghUuWnclXMGN8+0iJhxqjzbS5LcAN1FvH/Rvf+X1A Message-ID: <46CEFD90.6030604@yahoo-inc.com> Date: Fri, 24 Aug 2007 08:47:28 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] NFC References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> <005301c7e614$afac0850$6401a8c0@DGBP7M81> In-Reply-To: <005301c7e614$afac0850$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> Make that MUST NOT. A combining character applies to the immediatelly >> preceding base character, and if that happens to be whitespace, that >> means something different. > > I almost had a defense here, that line folding would be collapsed to > nothing, but of course that's not true either; lines are only folded > where whitespace would occur anyway. > > Any NFC-related edits to 4646bis should follow John's corrections. And > Doug needs to go back to Unicode school. > Actually, this is a flaw in our version of record-jar. What we should have is the line-continuation character at the end of the previous line. Otherwise languages that use spaces to separate words are at a disadvantage... or languages that don't use spaces will have spurious ones introduced (pick your poison). That is, consider this text: Field: This is a wrapped line of text. The unwrapping would make that field-body into this string: "This is a wrappedline of text." If a space were introduced by the unwrapping, any text that does not use spaces (Japanese, Chinese, Korean, Thai, etc. etc.) would have spurious spaces added at each line wrap. If we added line continuation, we would have: Field: The one space is followed by \ ́ which is a combining mark. John's objection that the U+0301 combines with the leading whitespace on the second line wouldn't hold if unwrapping were considered a higher-order file formatting rule. That is, the whitespace at the start of the second line isn't considered to be part of the text. This, actually, is how I considered it to work in my own implementations and the reason I only specified code point separation previously. However, since we don't supply a very full description of record-jar, I have made the edits, including the MUST NOT edit, to prevent others from falling into the trap of interpreting the file as text and then performing the unwrapping. 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 Aug 24 14:22: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 1IOdnY-0006Ka-2J; Fri, 24 Aug 2007 14:22:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOdnW-0006KV-VM for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 14:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOdnW-0006KN-Ln for ltru@ietf.org; Fri, 24 Aug 2007 14:22:18 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOdnV-000231-77 for ltru@ietf.org; Fri, 24 Aug 2007 14:22:18 -0400 Received: by rv-out-0910.google.com with SMTP id l15so675585rvb for ; Fri, 24 Aug 2007 11:22:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=ELpRpXfBbKtWS8JKLfLfqqCjWaK1CZD1jctSbi+cILf4hLmAh1VjOxumcTTwn1wNkonrwi1+4WKjZ+aKnTwYMs6G8/tNFmJBxsBDUYpGQDb+8rdO1whQ2g6lBKQHIdf2EUznN7FK5HNaj3DjnQK6jAHln6zdjtZrFuqMPi1xbXo= 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=mVnS2tomVAGsTcw+F6++9MFWt05dU1ACP1+Ah4idvtzQoSQk/sI2R319qw1tdmP+g+L1hzfa0E/p8+wrNcTsh8ohp5Sfh+Vj4q0hWoD7xrdynJc1QDYaQoX7GCSuS61Rc7x1FubCshDXBgpHGYE+RG+i27INAURIdqyT1jb3rEE= Received: by 10.114.57.1 with SMTP id f1mr1580566waa.1187979734307; Fri, 24 Aug 2007 11:22:14 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Fri, 24 Aug 2007 11:22:14 -0700 (PDT) Message-ID: <30b660a20708241122r3ae96721u920733647e43fcac@mail.gmail.com> Date: Fri, 24 Aug 2007 11:22:14 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] NFC In-Reply-To: <46CEFD90.6030604@yahoo-inc.com> MIME-Version: 1.0 References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> <005301c7e614$afac0850$6401a8c0@DGBP7M81> <46CEFD90.6030604@yahoo-inc.com> X-Google-Sender-Auth: 6196f6dbb7bf1ef6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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="===============1138661844==" Errors-To: ltru-bounces@ietf.org --===============1138661844== Content-Type: multipart/alternative; boundary="----=_Part_15255_8289408.1187979734200" ------=_Part_15255_8289408.1187979734200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline My real preference would be no broken lines at all. Then we don't have to jimmy around with it. Parsing is simpler and straightforward, and If someone wants to see wrapped lines, then they just turn that on in their viewer (or copy the contents to one that does wrap). Mark On 8/24/07, Addison Phillips wrote: > > Doug Ewell wrote: > >> Make that MUST NOT. A combining character applies to the immediatelly > >> preceding base character, and if that happens to be whitespace, that > >> means something different. > > > > I almost had a defense here, that line folding would be collapsed to > > nothing, but of course that's not true either; lines are only folded > > where whitespace would occur anyway. > > > > Any NFC-related edits to 4646bis should follow John's corrections. And > > Doug needs to go back to Unicode school. > > > > Actually, this is a flaw in our version of record-jar. What we should > have is the line-continuation character at the end of the previous line. > Otherwise languages that use spaces to separate words are at a > disadvantage... or languages that don't use spaces will have spurious > ones introduced (pick your poison). > > That is, consider this text: > > Field: This is a wrapped > line of text. > > The unwrapping would make that field-body into this string: > > "This is a wrappedline of text." > > If a space were introduced by the unwrapping, any text that does not use > spaces (Japanese, Chinese, Korean, Thai, etc. etc.) would have spurious > spaces added at each line wrap. > > If we added line continuation, we would have: > > Field: The one space is followed by \ > ́ which is a combining mark. > > John's objection that the U+0301 combines with the leading whitespace on > the second line wouldn't hold if unwrapping were considered a > higher-order file formatting rule. That is, the whitespace at the start > of the second line isn't considered to be part of the text. This, > actually, is how I considered it to work in my own implementations and > the reason I only specified code point separation previously. > > However, since we don't supply a very full description of record-jar, I > have made the edits, including the MUST NOT edit, to prevent others from > falling into the trap of interpreting the file as text and then > performing the unwrapping. > > 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_15255_8289408.1187979734200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline My real preference would be no broken lines at all. Then we don't have to jimmy around with it. Parsing is simpler and straightforward, and If someone wants to see wrapped lines, then they just turn that on in their viewer (or copy the contents to one that does wrap).

Mark

On 8/24/07, Addison Phillips <addison@yahoo-inc.com> wrote:
Doug Ewell wrote:
>> Make that MUST NOT.  A combining character applies to the immediatelly
>> preceding base character, and if that happens to be whitespace, that
>> means something different.
>
> I almost had a defense here, that line folding would be collapsed to
> nothing, but of course that's not true either; lines are only folded
> where whitespace would occur anyway.
>
> Any NFC-related edits to 4646bis should follow John's corrections.  And
> Doug needs to go back to Unicode school.
>

Actually, this is a flaw in our version of record-jar. What we should
have is the line-continuation character at the end of the previous line.
Otherwise languages that use spaces to separate words are at a
disadvantage... or languages that don't use spaces will have spurious
ones introduced (pick your poison).

That is, consider this text:

Field: This is a wrapped
    line of text.

The unwrapping would make that field-body into this string:

"This is a wrappedline of text."

If a space were introduced by the unwrapping, any text that does not use
spaces (Japanese, Chinese, Korean, Thai, etc. etc.) would have spurious
spaces added at each line wrap.

If we added line continuation, we would have:

Field: The one space is followed by \
    &#x301; which is a combining mark.

John's objection that the U+0301 combines with the leading whitespace on
the second line wouldn't hold if unwrapping were considered a
higher-order file formatting rule. That is, the whitespace at the start
of the second line isn't considered to be part of the text. This,
actually, is how I considered it to work in my own implementations and
the reason I only specified code point separation previously.

However, since we don't supply a very full description of record-jar, I
have made the edits, including the MUST NOT edit, to prevent others from
falling into the trap of interpreting the file as text and then
performing the unwrapping.

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_15255_8289408.1187979734200-- --===============1138661844== 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 --===============1138661844==-- From ltru-bounces@ietf.org Fri Aug 24 14:29: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 1IOduZ-0002Zo-JY; Fri, 24 Aug 2007 14:29:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOduZ-0002Zj-1F for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 14:29:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOduY-0002Zb-Mk for ltru@ietf.org; Fri, 24 Aug 2007 14:29:34 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOduY-0005PP-0l for ltru@ietf.org; Fri, 24 Aug 2007 14:29:34 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7OITK0f022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 11:29:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=VM5/ls6JMQXXibmm/M6IgvTCboZvYAoL2y9dRlaMUGpbv+VwjKlaU/7DsK2oVgDu Message-ID: <46CF2380.5080903@yahoo-inc.com> Date: Fri, 24 Aug 2007 11:29:20 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] NFC References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> <005301c7e614$afac0850$6401a8c0@DGBP7M81> <46CEFD90.6030604@yahoo-inc.com> <30b660a20708241122r3ae96721u920733647e43fcac@mail.gmail.com> In-Reply-To: <30b660a20708241122r3ae96721u920733647e43fcac@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Yes, I agree completely. However, we made 72-byte line length limits a part of RFC 4646. For compatibility's sake, we're probably stuck with wrapping. Note that this also means no line continuation character :-). Addison Mark Davis wrote: > My real preference would be no broken lines at all. Then we don't have > to jimmy around with it. Parsing is simpler and straightforward, and If > someone wants to see wrapped lines, then they just turn that on in their > viewer (or copy the contents to one that does wrap). > > Mark > > On 8/24/07, *Addison Phillips* > wrote: > > Doug Ewell wrote: > >> Make that MUST NOT. A combining character applies to the > immediatelly > >> preceding base character, and if that happens to be whitespace, that > >> means something different. > > > > I almost had a defense here, that line folding would be collapsed to > > nothing, but of course that's not true either; lines are only folded > > where whitespace would occur anyway. > > > > Any NFC-related edits to 4646bis should follow John's > corrections. And > > Doug needs to go back to Unicode school. > > > > Actually, this is a flaw in our version of record-jar. What we should > have is the line-continuation character at the end of the previous line. > Otherwise languages that use spaces to separate words are at a > disadvantage... or languages that don't use spaces will have spurious > ones introduced (pick your poison). > > That is, consider this text: > > Field: This is a wrapped > line of text. > > The unwrapping would make that field-body into this string: > > "This is a wrappedline of text." > > If a space were introduced by the unwrapping, any text that does not use > spaces (Japanese, Chinese, Korean, Thai, etc. etc.) would have spurious > spaces added at each line wrap. > > If we added line continuation, we would have: > > Field: The one space is followed by \ > ́ which is a combining mark. > > John's objection that the U+0301 combines with the leading > whitespace on > the second line wouldn't hold if unwrapping were considered a > higher-order file formatting rule. That is, the whitespace at the start > of the second line isn't considered to be part of the text. This, > actually, is how I considered it to work in my own implementations and > the reason I only specified code point separation previously. > > However, since we don't supply a very full description of record-jar, I > have made the edits, including the MUST NOT edit, to prevent others from > falling into the trap of interpreting the file as text and then > performing the unwrapping. > > 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 -- 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 Aug 24 17:59: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 1IOhBz-0002JH-3T; Fri, 24 Aug 2007 17:59:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOhBx-0002J9-77 for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 17:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOhBw-0002Il-Ou; Fri, 24 Aug 2007 17:59:44 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOhBu-000132-7G; Fri, 24 Aug 2007 17:59:44 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7OLxXnB040866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 14:59:34 -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; b=jAnPL3Q+5i8G4Cuq7LSU4k4Ozz8w0ZjqTRF+dpmDEkRCsxAQ4SHO30CES1iMEo0D Message-ID: <46CF54C4.2090707@yahoo-inc.com> Date: Fri, 24 Aug 2007 14:59:32 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: internet-drafts@ietf.org, "'LTRU Working Group'" Content-Type: multipart/mixed; boundary="------------040309020300080408060809" X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 84303620e82e9a60a8e52c2a3452e7c1 Cc: Subject: [Ltru] draft-ietf-ltru-rfc4646bis-08 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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. --------------040309020300080408060809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Editors, Please find attached in the usual text format draft-08 of draft-ietf-ltru-rfc4646bis. Best Regards, Addison (for the editors) -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. --------------040309020300080408060809 Content-Type: text/plain; name="draft-ietf-ltru-4646bis-08.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ltru-4646bis-08.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWFob28hIEluYy4NCk9ic29sZXRl czogNDY0NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4g RGF2aXMsIEVkLg0KSW50ZW5kZWQgc3RhdHVzOiBCZXN0IEN1cnJlbnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlDQpQcmFjdGljZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjQsIDIwMDcNCkV4 cGlyZXM6IEZlYnJ1YXJ5IDI1LCAyMDA4DQoNCg0KICAgICAgICAgICAgICAgICAgICAgVGFn cyBmb3IgSWRlbnRpZnlpbmcgTGFuZ3VhZ2VzDQogICAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtbHRydS00NjQ2YmlzLTA4DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg Qnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNl bnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1z IG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUg ZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBC Q1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2Yg dGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91 cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0K ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gRmVicnVhcnkgMjUsIDIwMDguDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAg Q29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAy MDA4ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoN CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBzdHJ1Y3R1cmUs IGNvbnRlbnQsIGNvbnN0cnVjdGlvbiwgYW5kDQogICBzZW1hbnRpY3Mgb2YgbGFuZ3VhZ2Ug dGFncyBmb3IgdXNlIGluIGNhc2VzIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSB0bw0KICAgaW5k aWNhdGUgdGhlIGxhbmd1YWdlIHVzZWQgaW4gYW4gaW5mb3JtYXRpb24gb2JqZWN0LiAgSXQg YWxzbw0KICAgZGVzY3JpYmVzIGhvdyB0byByZWdpc3RlciB2YWx1ZXMgZm9yIHVzZSBpbiBs YW5ndWFnZSB0YWdzIGFuZCB0aGUNCiAgIGNyZWF0aW9uIG9mIHVzZXItZGVmaW5lZCBleHRl bnNpb25zIGZvciBwcml2YXRlIGludGVyY2hhbmdlLg0KDQoNClRhYmxlIG9mIENvbnRlbnRz DQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMi4gIFRoZSBMYW5ndWFnZSBUYWcgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgIDIuMS4g IFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUNCiAgICAgMi4yLiAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVy cHJldGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDIuMi4xLiAgUHJpbWFyeSBM YW5ndWFnZSBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAg ICAgMi4yLjIuICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTENCiAgICAgICAyLjIuMy4gIFNjcmlwdCBTdWJ0YWcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgICAgIDIuMi40LiAgUmVn aW9uIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEz DQogICAgICAgMi4yLjUuICBWYXJpYW50IFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAgICAgICAyLjIuNi4gIEV4dGVuc2lvbiBTdWJ0YWdz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICAgIDIuMi43 LiAgUHJpdmF0ZSBVc2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3DQogICAgICAgMi4yLjguICBHcmFuZGZhdGhlcmVkIFJlZ2lzdHJhdGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgICAyLjIuOS4gIENsYXNzZXMgb2Yg Q29uZm9ybWFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgMy4g IFJlZ2lzdHJ5IEZvcm1hdCBhbmQgTWFpbnRlbmFuY2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDIwDQogICAgIDMuMS4gIEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5ndWFnZSBT dWJ0YWcgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gMjANCiAgICAgICAzLjEuMS4gIEZpbGUg Rm9ybWF0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0K ICAgICAgIDMuMS4yLiAgUmVjb3JkIERlZmluaXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDIxDQogICAgICAgMy4xLjMuICBTdWJ0YWcgYW5kIFRhZyBGaWVs ZHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgICAgICAzLjEuNC4g IERlc2NyaXB0aW9uIEZpZWxkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNA0KICAgICAgIDMuMS41LiAgRGVwcmVjYXRlZCBGaWVsZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgICAgMy4xLjYuICBQcmVmZXJyZWQtVmFs dWUgRmllbGQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUNCiAgICAgICAz LjEuNy4gIFByZWZpeCBGaWVsZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyNg0KICAgICAgIDMuMS44LiAgU3VwcHJlc3MtU2NyaXB0IEZpZWxkICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DQogICAgICAgMy4xLjkuICBNYWNyb2xh bmd1YWdlIEZpZWxkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNCiAg ICAgICAzLjEuMTAuIENvbW1lbnRzIEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyOA0KICAgICAzLjIuICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4DQogICAgIDMuMy4gIE1haW50 ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjkNCiAgICAgMy40LiAgU3RhYmlsaXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0KICAgICAzLjUuICBSZWdpc3RyYXRpb24gUHJvY2Vk dXJlIGZvciBTdWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM0DQogICAgIDMuNi4g IFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMzgNCiAgICAgMy43LiAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3Ry eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0KICAgICAzLjguICBVcGRhdGUgb2YgdGhl IExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzDQogICA0 LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDQNCiAgICAgNC4xLiAgQ2hvaWNlIG9mIExhbmd1YWdlIFRhZyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NA0KICAgICA0LjIuICBNZWFuaW5n IG9mIHRoZSBMYW5ndWFnZSBUYWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ4 DQogICAgIDQuMy4gIExlbmd0aCBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNTANCiAgICAgICA0LjMuMS4gIFdvcmtpbmcgd2l0aCBMaW1p dGVkIEJ1ZmZlciBTaXplcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA1MA0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAg ICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAgICAgNC4zLjIu ICBUcnVuY2F0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTINCiAgICAgNC40LiAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Mg0KICAgICA0LjUuICBDb25zaWRlcmF0aW9ucyBm b3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0DQogICA1LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNTYNCiAgICAgNS4xLiAgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Ng0KICAgICA1LjIuICBFeHRlbnNpb25z IFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU3DQog ICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNTgNCiAgIDcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25z IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1OQ0KICAgOC4gIENoYW5nZXMg ZnJvbSBSRkMgNDY0NiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDYwDQogICA5LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNjQNCiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NA0KICAgICA5LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDY1DQogICBBcHBlbmRpeCBBLiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcNCiAgIEFwcGVuZGl4IEIuICBFeGFtcGxl cyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkgLiAuIC4gLiAuIC4gLiA2OA0KICAg QXBwZW5kaXggQy4gIEV4YW1wbGVzIG9mIFJlZ2lzdHJhdGlvbiBGb3JtcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDcxDQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNzMNCiAgIEludGVsbGVjdHVhbCBQ cm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiA3 NA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3Qg MjAwNw0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgSHVtYW4gYmVpbmdzIG9uIG91ciBw bGFuZXQgaGF2ZSwgcGFzdCBhbmQgcHJlc2VudCwgdXNlZCBhIG51bWJlciBvZg0KICAgbGFu Z3VhZ2VzLiAgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyB3aHkgb25lIHdvdWxkIHdhbnQgdG8g aWRlbnRpZnkgdGhlDQogICBsYW5ndWFnZSB1c2VkIHdoZW4gcHJlc2VudGluZyBvciByZXF1 ZXN0aW5nIGluZm9ybWF0aW9uLg0KDQogICBBIHVzZXIncyBsYW5ndWFnZSBwcmVmZXJlbmNl cyBvZnRlbiBuZWVkIHRvIGJlIGlkZW50aWZpZWQgc28gdGhhdA0KICAgYXBwcm9wcmlhdGUg cHJvY2Vzc2luZyBjYW4gYmUgYXBwbGllZC4gIEZvciBleGFtcGxlLCB0aGUgdXNlcidzDQog ICBsYW5ndWFnZSBwcmVmZXJlbmNlcyBpbiBhIFdlYiBicm93c2VyIGNhbiBiZSB1c2VkIHRv IHNlbGVjdCBXZWIgcGFnZXMNCiAgIGFwcHJvcHJpYXRlbHkuICBMYW5ndWFnZSBwcmVmZXJl bmNlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIHNlbGVjdCBhbW9uZw0KICAgdG9vbHMgKHN1Y2gg YXMgZGljdGlvbmFyaWVzKSB0byBhc3Npc3QgaW4gdGhlIHByb2Nlc3Npbmcgb3INCiAgIHVu ZGVyc3RhbmRpbmcgb2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBJ biBhZGRpdGlvbiwga25vd2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVz ZWQgYnkgc29tZQ0KICAgcGllY2Ugb2YgaW5mb3JtYXRpb24gY29udGVudCBtaWdodCBiZSB1 c2VmdWwgb3IgZXZlbiByZXF1aXJlZCBieSBzb21lDQogICB0eXBlcyBvZiBwcm9jZXNzaW5n OyBmb3IgZXhhbXBsZSwgc3BlbGwtY2hlY2tpbmcsIGNvbXB1dGVyLQ0KICAgc3ludGhlc2l6 ZWQgc3BlZWNoLCBCcmFpbGxlIHRyYW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eSBwcmlu dA0KICAgcmVuZGVyaW5ncy4NCg0KICAgT25lIG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxh bmd1YWdlIHVzZWQgaXMgYnkgbGFiZWxpbmcgdGhlDQogICBpbmZvcm1hdGlvbiBjb250ZW50 IHdpdGggYW4gaWRlbnRpZmllciBvciAidGFnIi4gIFRoZXNlIHRhZ3MgY2FuIGJlDQogICB1 c2VkIHRvIHNwZWNpZnkgdXNlciBwcmVmZXJlbmNlcyB3aGVuIHNlbGVjdGluZyBpbmZvcm1h dGlvbiBjb250ZW50LA0KICAgb3IgZm9yIGxhYmVsaW5nIGFkZGl0aW9uYWwgYXR0cmlidXRl cyBvZiBjb250ZW50IGFuZCBhc3NvY2lhdGVkDQogICByZXNvdXJjZXMuDQoNCiAgIFRhZ3Mg Y2FuIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsIGxhbmd1YWdlIGF0dHJp YnV0ZXMgb2YNCiAgIGNvbnRlbnQuICBGb3IgZXhhbXBsZSwgaW5kaWNhdGluZyBzcGVjaWZp YyBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgIGRpYWxlY3QsIHdyaXRpbmcgc3lzdGVtLCBv ciBvcnRob2dyYXBoeSB1c2VkIGluIGEgZG9jdW1lbnQgb3INCiAgIHJlc291cmNlIG1heSBl bmFibGUgdGhlIHVzZXIgdG8gb2J0YWluIGluZm9ybWF0aW9uIGluIGEgZm9ybSB0aGF0DQog ICB0aGV5IGNhbiB1bmRlcnN0YW5kLCBvciBpdCBjYW4gYmUgaW1wb3J0YW50IGluIHByb2Nl c3Npbmcgb3INCiAgIHJlbmRlcmluZyB0aGUgZ2l2ZW4gY29udGVudCBpbnRvIGFuIGFwcHJv cHJpYXRlIGZvcm0gb3Igc3R5bGUuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEg cGFydGljdWxhciBpZGVudGlmaWVyIG1lY2hhbmlzbSAodGhlDQogICBsYW5ndWFnZSB0YWcp IGFuZCBhIHJlZ2lzdHJhdGlvbiBmdW5jdGlvbiBmb3IgdmFsdWVzIHRvIGJlIHVzZWQgdG8N CiAgIGZvcm0gdGFncy4gIEl0IGFsc28gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgcHJpdmF0 ZSB1c2UgdmFsdWVzIGFuZA0KICAgZnV0dXJlIGV4dGVuc2lvbi4NCg0KICAgVGhpcyBkb2N1 bWVudCByZXBsYWNlcyBbUkZDNDY0Nl0sIHdoaWNoIHJlcGxhY2VkIFtSRkMzMDY2XSBhbmQg aXRzDQogICBwcmVkZWNlc3NvciBbUkZDMTc2Nl0uICBGb3IgYSBsaXN0IG9mIGNoYW5nZXMg aW4gdGhpcyBkb2N1bWVudCwgc2VlDQogICBTZWN0aW9uIDguDQoNCiAgIFRoZSBrZXkgd29y ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9U IiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAg IFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQoyLiAgVGhlIExhbmd1YWdl IFRhZw0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSB1c2VkIHRvIGhlbHAgaWRlbnRpZnkgbGFu Z3VhZ2VzLCB3aGV0aGVyIHNwb2tlbiwNCiAgIHdyaXR0ZW4sIHNpZ25lZCwgb3Igb3RoZXJ3 aXNlIHNpZ25hbGVkLCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIGNvbW11bmljYXRpb24uICBU aGlzIGluY2x1ZGVzIGNvbnN0cnVjdGVkIGFuZCBhcnRpZmljaWFsIGxhbmd1YWdlcywNCiAg IGJ1dCBleGNsdWRlcyBsYW5ndWFnZXMgbm90IGludGVuZGVkIHByaW1hcmlseSBmb3IgaHVt YW4NCiAgIGNvbW11bmljYXRpb24sIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLg0K DQoyLjEuICBTeW50YXgNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBpcyBjb21wb3NlZCBvZiBv bmUgb3IgbW9yZSBwYXJ0cywga25vd24gYXMNCiAgICJzdWJ0YWdzIi4gIEVhY2ggc3VidGFn IGNvbnNpc3RzIG9mIGEgc2VxdWVuY2Ugb2YgYWxwaGFudW1lcmljDQogICBjaGFyYWN0ZXJz LiAgU3VidGFncyBhcmUgZGlzdGluZ3Vpc2hlZCBhbmQgc2VwYXJhdGVkIGZyb20gb25lIGFu b3RoZXINCiAgIGJ5IGEgaHlwaGVuICgiLSIsIEFCTkYgW1JGQzQyMzRdICV4MkQpLiAgQSBs YW5ndWFnZSB0YWcgY29uc2lzdHMgb2YgYQ0KICAgInByaW1hcnkgbGFuZ3VhZ2UiIHN1YnRh ZyBhbmQgYSAocG9zc2libHkgZW1wdHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50DQogICBzdWJ0 YWdzLCBlYWNoIG9mIHdoaWNoIHJlZmluZXMgb3IgbmFycm93cyB0aGUgcmFuZ2Ugb2YgbGFu Z3VhZ2VzDQogICBpZGVudGlmaWVkIGJ5IHRoZSBvdmVyYWxsIHRhZy4NCg0KICAgVXN1YWxs eSwgZWFjaCB0eXBlIG9mIHN1YnRhZyBpcyBkaXN0aW5ndWlzaGVkIGJ5IGxlbmd0aCwgcG9z aXRpb24gaW4NCiAgIHRoZSB0YWcsIGFuZCBjb250ZW50OiBzdWJ0YWdzIGNhbiBiZSByZWNv Z25pemVkIHNvbGVseSBieSB0aGVzZQ0KICAgZmVhdHVyZXMuICBUaGUgb25seSBleGNlcHRp b24gdG8gdGhpcyBpcyBhIGZpeGVkIGxpc3Qgb2YNCiAgIGdyYW5kZmF0aGVyZWQgdGFncyBy ZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2IFtSRkMzMDY2XS4gIFRoaXMgbWFrZXMNCiAgIGl0 IHBvc3NpYmxlIHRvIGNvbnN0cnVjdCBhIHBhcnNlciB0aGF0IGNhbiBleHRyYWN0IGFuZCBh c3NpZ24gc29tZQ0KICAgc2VtYW50aWMgaW5mb3JtYXRpb24gdG8gdGhlIHN1YnRhZ3MsIGV2 ZW4gaWYgdGhlIHNwZWNpZmljIHN1YnRhZw0KICAgdmFsdWVzIGFyZSBub3QgcmVjb2duaXpl ZC4gIFRodXMsIGEgcGFyc2VyIG5lZWQgbm90IGhhdmUgYW4gdXAtdG8tDQogICBkYXRlIGNv cHkgKG9yIGFueSBjb3B5IGF0IGFsbCkgb2YgdGhlIHN1YnRhZyByZWdpc3RyeSB0byBwZXJm b3JtIG1vc3QNCiAgIHNlYXJjaGluZyBhbmQgbWF0Y2hpbmcgb3BlcmF0aW9ucy4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgICBb UGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgVGhlIHN5bnRheCBvZiB0 aGUgbGFuZ3VhZ2UgdGFnIGluIEFCTkYgW1JGQzQyMzRdIGlzOg0KDQogICBMYW5ndWFnZS1U YWcgID0gbGFuZ3RhZw0KICAgICAgICAgICAgICAgICAvIHByaXZhdGV1c2UgICAgICAgICAg ICAgOyBwcml2YXRlIHVzZSB0YWcNCiAgICAgICAgICAgICAgICAgLyBpcnJlZ3VsYXIgICAg ICAgICAgICAgIDsgdGFncyBncmFuZGZhdGhlcmVkIGJ5IHJ1bGUNCg0KICAgbGFuZ3RhZyAg ICAgICA9IChsYW5ndWFnZQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHNjcmlwdF0NCiAg ICAgICAgICAgICAgICAgICAgWyItIiByZWdpb25dDQogICAgICAgICAgICAgICAgICAgICoo Ii0iIHZhcmlhbnQpDQogICAgICAgICAgICAgICAgICAgICooIi0iIGV4dGVuc2lvbikNCiAg ICAgICAgICAgICAgICAgICAgWyItIiBwcml2YXRldXNlXSkNCg0KICAgbGFuZ3VhZ2UgICAg ICA9ICgyKjNBTFBIQSBbIGV4dGxhbmcgXSkgOyBzaG9ydGVzdCBJU08gNjM5IGNvZGUNCiAg ICAgICAgICAgICAgICAgLyA0QUxQSEEgICAgICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9y IGZ1dHVyZSB1c2UNCiAgICAgICAgICAgICAgICAgLyA1KjhBTFBIQSAgICAgICAgICAgICAg IDsgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCg0KICAgZXh0bGFuZyAgICAgICA9ICoz KCItIiAzQUxQSEEpICAgICAgICAgOyBzcGVjaWZpYyBJU08gNjM5LTMgY29kZXMNCg0KICAg c2NyaXB0ICAgICAgICA9IDRBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMTU5MjQgY29k ZQ0KDQogICByZWdpb24gICAgICAgID0gMkFMUEhBICAgICAgICAgICAgICAgICA7IElTTyAz MTY2IGNvZGUNCiAgICAgICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgICAgIDsg VU4gTS40OSBjb2RlDQoNCiAgIHZhcmlhbnQgICAgICAgPSA1KjhhbHBoYW51bSAgICAgICAg ICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KICAgICAgICAgICAgICAgICAvIChESUdJVCAz YWxwaGFudW0pDQoNCiAgIGV4dGVuc2lvbiAgICAgPSBzaW5nbGV0b24gMSooIi0iICgyKjhh bHBoYW51bSkpDQoNCiAgIHNpbmdsZXRvbiAgICAgPSAleDQxLTU3IC8gJXg1OS01QSAvICV4 NjEtNzcgLyAleDc5LTdBIC8gRElHSVQNCiAgICAgICAgICAgICAgICAgOyAiYSItInciIC8g InkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloiIC8gIjAiLSI5Ig0KICAgICAgICAgICAgICAg ICA7IFNpbmdsZSBhbHBoYW51bWVyaWNzDQogICAgICAgICAgICAgICAgIDsgIngiIGlzIHJl c2VydmVkIGZvciBwcml2YXRlIHVzZQ0KDQogICBwcml2YXRldXNlICAgID0gIngiIDEqKCIt IiAoMSo4YWxwaGFudW0pKQ0KDQogICBpcnJlZ3VsYXIgICAgID0gImVuLUdCLW9lZCIgLyAi aS1hbWkiIC8gImktYm5uIiAvICJpLWRlZmF1bHQiDQogICAgICAgICAgICAgICAgIC8gImkt ZW5vY2hpYW4iIC8gImktaGFrIiAvICJpLWtsaW5nb24iIC8gImktbHV4Ig0KICAgICAgICAg ICAgICAgICAvICJpLW1pbmdvIiAvICJpLW5hdmFqbyIgLyAiaS1wd24iIC8gImktdGFvIg0K ICAgICAgICAgICAgICAgICAvICJpLXRheSIgLyAiaS10c3UiIC8gInNnbi1CRS1mciIgLyAi c2duLUJFLW5sIg0KICAgICAgICAgICAgICAgICAvICJzZ24tQ0gtZGUiDQoNCiAgIGFscGhh bnVtICAgICAgPSAoQUxQSEEgLyBESUdJVCkgICAgICAgOyBsZXR0ZXJzIGFuZCBudW1iZXJz DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMYW5ndWFnZSBUYWcgQUJO Rg0KDQogICBBbGwgc3VidGFncyBoYXZlIGEgbWF4aW11bSBsZW5ndGggb2YgZWlnaHQgY2hh cmFjdGVycyBhbmQgd2hpdGVzcGFjZQ0KICAgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1 YWdlIHRhZy4gIFRoZXJlIGlzIGEgc3VidGxldHkgaW4gdGhlIEFCTkYNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAg ICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgcHJvZHVjdGlv biAndmFyaWFudCc6IHZhcmlhbnRzIHN0YXJ0aW5nIHdpdGggYSBkaWdpdCBNQVkgYmUgZm91 cg0KICAgY2hhcmFjdGVycyBsb25nLCB3aGlsZSB0aG9zZSBzdGFydGluZyB3aXRoIGEgbGV0 dGVyIE1VU1QgYmUgYXQgbGVhc3QNCiAgIGZpdmUgY2hhcmFjdGVycyBsb25nLiAgRm9yIGV4 YW1wbGVzIG9mIGxhbmd1YWdlIHRhZ3MsIHNlZSBBcHBlbmRpeCBCLg0KDQogICBOb3RlIFdl bGw6IHRoZSBBQk5GIHN5bnRheCBkb2VzIG5vdCBkaXN0aW5ndWlzaCBiZXR3ZWVuIHVwcGVy IGFuZA0KICAgbG93ZXJjYXNlLiAgVGhlIGFwcGVhcmFuY2Ugb2YgdXBwZXIgYW5kIGxvd2Vy Y2FzZSBsZXR0ZXJzIGluIHRoZQ0KICAgdmFyb3VzIEFCTkYgcHJvZHVjdGlvbnMgYWJvdmUg ZG8gbm90IGFmZmVjdCBob3cgaW1wbGVtZW50YXRpb25zDQogICBpbnRlcnByZXQgdGFncy4g IFRoYXQgaXMsIHRoZSB0YWcgIkktQU1JIiBtYXRjaGVzIHRoZSBpdGVtICJpLWFtaSIgaW4N CiAgIHRoZSAnaXJyZWd1bGFyJyBwcm9kdWN0aW9uLiAgQXQgYWxsIHRpbWVzLCB0aGUgdGFn cyBhbmQgdGhlaXINCiAgIHN1YnRhZ3MsIGluY2x1ZGluZyBwcml2YXRlIHVzZSBhbmQgZXh0 ZW5zaW9ucywgYXJlIHRvIGJlIHRyZWF0ZWQgYXMNCiAgIGNhc2UgaW5zZW5zaXRpdmU6IHRo ZXJlIGV4aXN0IGNvbnZlbnRpb25zIGZvciB0aGUgY2FwaXRhbGl6YXRpb24gb2YNCiAgIHNv bWUgb2YgdGhlIHN1YnRhZ3MsIGJ1dCB0aGVzZSBNVVNUIE5PVCBiZSB0YWtlbiB0byBjYXJy eSBtZWFuaW5nLg0KDQogICBGb3IgZXhhbXBsZToNCg0KICAgbyAgW0lTTzYzOS0xXSByZWNv bW1lbmRzIHRoYXQgbGFuZ3VhZ2UgY29kZXMgYmUgd3JpdHRlbiBpbiBsb3dlcmNhc2UNCiAg ICAgICgnbW4nIE1vbmdvbGlhbikuDQoNCiAgIG8gIFtJU08zMTY2LTFdIHJlY29tbWVuZHMg dGhhdCBjb3VudHJ5IGNvZGVzIGJlIGNhcGl0YWxpemVkICgnTU4nDQogICAgICBNb25nb2xp YSkuDQoNCiAgIG8gIFtJU08xNTkyNF0gcmVjb21tZW5kcyB0aGF0IHNjcmlwdCBjb2RlcyB1 c2UgbG93ZXJjYXNlIHdpdGggdGhlDQogICAgICBpbml0aWFsIGxldHRlciBjYXBpdGFsaXpl ZCAoJ0N5cmwnIEN5cmlsbGljKS4NCg0KICAgSG93ZXZlciwgaW4gdGhlIHRhZ3MgZGVmaW5l ZCBieSB0aGlzIGRvY3VtZW50LCB0aGUgdXBwZXJjYXNlIFVTLUFTQ0lJDQogICBsZXR0ZXJz IGluIHRoZSByYW5nZSAnQScgdGhyb3VnaCAnWicgYXJlIGNvbnNpZGVyZWQgZXF1aXZhbGVu dCBhbmQNCiAgIG1hcHBlZCBkaXJlY3RseSB0byB0aGVpciBVUy1BU0NJSSBsb3dlcmNhc2Ug ZXF1aXZhbGVudHMgaW4gdGhlIHJhbmdlDQogICAnYScgdGhyb3VnaCAneicuICBUaHVzLCB0 aGUgdGFnICJtbi1DeXJsLU1OIiBpcyBub3QgZGlzdGluY3QgZnJvbQ0KICAgIk1OLWNZUkwt bW4iIG9yICJtTi1jWXJMLU1uIiAob3IgYW55IG90aGVyIGNvbWJpbmF0aW9uKSwgYW5kIGVh Y2ggb2YNCiAgIHRoZXNlIHZhcmlhdGlvbnMgY29udmV5cyB0aGUgc2FtZSBtZWFuaW5nOiBN b25nb2xpYW4gd3JpdHRlbiBpbiB0aGUNCiAgIEN5cmlsbGljIHNjcmlwdCBhcyB1c2VkIGlu IE1vbmdvbGlhLg0KDQogICBBbHRob3VnaCBjYXNlIGRpc3RpbmN0aW9ucyBkbyBub3QgY2Fy cnkgbWVhbmluZyBpbiBsYW5ndWFnZSB0YWdzLA0KICAgY29uc2lzdGVudCBmb3JtYXR0aW5n IGFuZCBwcmVzZW50YXRpb24gb2YgdGhlIHRhZ3Mgd2lsbCBhaWQgdXNlcnMuDQogICBUaGUg Zm9ybWF0IG9mIHRoZSB0YWdzIGFuZCBzdWJ0YWdzIGluIHRoZSByZWdpc3RyeSBpcyBSRUNP TU1FTkRFRC4NCiAgIEluIHRoaXMgZm9ybWF0LCBhbGwgbm9uLWluaXRpYWwgdHdvLWxldHRl ciBzdWJ0YWdzIGFyZSB1cHBlcmNhc2UsIGFsbA0KICAgbm9uLWluaXRpYWwgZm91ci1sZXR0 ZXIgc3VidGFncyBhcmUgdGl0bGVjYXNlLCBhbmQgYWxsIG90aGVyIHN1YnRhZ3MNCiAgIGFy ZSBsb3dlcmNhc2UuDQoNCiAgIE5vdGUgdGhhdCBhbHRob3VnaCBbUkZDNDIzNF0gcmVmZXJz IHRvIG9jdGV0cywgdGhlIGxhbmd1YWdlIHRhZ3MNCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50IGFyZSBzZXF1ZW5jZXMgb2YgY2hhcmFjdGVycyBmcm9tIHRoZSBVUy0NCiAgIEFT Q0lJIFtJU082NDZdIHJlcGVydG9pcmUuICBMYW5ndWFnZSB0YWdzIE1BWSBiZSB1c2VkIGlu IGRvY3VtZW50cw0KICAgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBvdGhlciBlbmNvZGlu Z3MsIHNvIGxvbmcgYXMgdGhlc2UgZW5jb21wYXNzDQogICB0aGUgVVMtQVNDSUkgcmVwZXJ0 b2lyZS4gIEFuIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSBhbiBYTUwgZG9jdW1lbnQNCiAg IHRoYXQgdXNlcyB0aGUgVVRGLTE2TEUgW1JGQzI3ODFdIGVuY29kaW5nIG9mIFtVbmljb2Rl XS4NCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjUsIDIwMDggICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA3DQoNCg0KMi4yLiAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVycHJldGF0 aW9uDQoNCiAgIFRoZSBuYW1lc3BhY2Ugb2YgbGFuZ3VhZ2UgdGFncyBhbmQgdGhlaXIgc3Vi dGFncyBpcyBhZG1pbmlzdGVyZWQgYnkNCiAgIHRoZSBJbnRlcm5ldCBBc3NpZ25lZCBOdW1i ZXJzIEF1dGhvcml0eSAoSUFOQSkgW1JGQzI4NjBdIGFjY29yZGluZyB0bw0KICAgdGhlIHJ1 bGVzIGluIFNlY3Rpb24gNSBvZiB0aGlzIGRvY3VtZW50LiAgVGhlIExhbmd1YWdlIFN1YnRh Zw0KICAgUmVnaXN0cnkgbWFpbnRhaW5lZCBieSBJQU5BIGlzIHRoZSBzb3VyY2UgZm9yIHZh bGlkIHN1YnRhZ3M6IG90aGVyDQogICBzdGFuZGFyZHMgcmVmZXJlbmNlZCBpbiB0aGlzIHNl Y3Rpb24gcHJvdmlkZSB0aGUgc291cmNlIG1hdGVyaWFsIGZvcg0KICAgdGhhdCByZWdpc3Ry eS4NCg0KICAgVGVybWlub2xvZ3kgdXNlZCBpbiB0aGlzIGRvY3VtZW50Og0KDQogICBvICBU YWcgb3IgdGFncyByZWZlcnMgdG8gYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcsIHN1Y2ggYXMN CiAgICAgICJzci1MYXRuLVJTIiBvciAiYXotQXJhYi1JUiIuICBFeGFtcGxlcyBvZiB0YWdz IGluIHRoaXMgZG9jdW1lbnQNCiAgICAgIGFyZSBlbmNsb3NlZCBpbiBkb3VibGUtcXVvdGVz ICgiZW4tVVMiKS4NCg0KICAgbyAgU3VidGFnIHJlZmVycyB0byBhIHNwZWNpZmljIHNlY3Rp b24gb2YgYSB0YWcsIGRlbGltaXRlZCBieSBoeXBoZW4sDQogICAgICBzdWNoIGFzIHRoZSBz dWJ0YWcgJ0hhbnQnIGluICJ6aC1IYW50LUNOIi4gIEV4YW1wbGVzIG9mIHN1YnRhZ3MgaW4N CiAgICAgIHRoaXMgZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluIHNpbmdsZSBxdW90ZXMgKCdI YW50JykuDQoNCiAgIG8gIENvZGUgb3IgY29kZXMgcmVmZXJzIHRvIHZhbHVlcyBkZWZpbmVk IGluIGV4dGVybmFsIHN0YW5kYXJkcyAoYW5kDQogICAgICB3aGljaCBhcmUgdXNlZCBhcyBz dWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQpLiAgRm9yIGV4YW1wbGUsICdIYW50Jw0KICAgICAg aXMgYW4gW0lTTzE1OTI0XSBzY3JpcHQgY29kZSB0aGF0IHdhcyB1c2VkIHRvIGRlZmluZSB0 aGUgJ0hhbnQnDQogICAgICBzY3JpcHQgc3VidGFnIGZvciB1c2UgaW4gYSBsYW5ndWFnZSB0 YWcuICBFeGFtcGxlcyBvZiBjb2RlcyBpbg0KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5j bG9zZWQgaW4gc2luZ2xlIHF1b3RlcyAoJ2VuJywgJ0hhbnQnKS4NCg0KICAgVGhlIGRlZmlu aXRpb25zIGluIHRoaXMgc2VjdGlvbiBhcHBseSB0byB0aGUgdmFyaW91cyBzdWJ0YWdzIHdp dGhpbg0KICAgdGhlIGxhbmd1YWdlIHRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCBl eGNlcHRpbmcgdGhvc2UNCiAgICJncmFuZGZhdGhlcmVkIiB0YWdzIGRlZmluZWQgaW4gU2Vj dGlvbiAyLjIuOC4NCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgZGVzaWduZWQgc28gdGhhdCBl YWNoIHN1YnRhZyB0eXBlIGhhcyB1bmlxdWUgbGVuZ3RoDQogICBhbmQgY29udGVudCByZXN0 cmljdGlvbnMuICBUaGVzZSBtYWtlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBzdWJ0YWcncw0K ICAgdHlwZSBwb3NzaWJsZSwgZXZlbiBpZiB0aGUgY29udGVudCBvZiB0aGUgc3VidGFnIGl0 c2VsZiBpcw0KICAgdW5yZWNvZ25pemVkLiAgVGhpcyBhbGxvd3MgdGFncyB0byBiZSBwYXJz ZWQgYW5kIHByb2Nlc3NlZCB3aXRob3V0DQogICByZWZlcmVuY2UgdG8gdGhlIGxhdGVzdCB2 ZXJzaW9uIG9mIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcyBvciB0aGUNCiAgIElBTkEgcmVn aXN0cnkgYW5kIG1ha2VzIHRoZSBhc3NvY2lhdGVkIGV4Y2VwdGlvbiBoYW5kbGluZyB3aGVu DQogICBwYXJzaW5nIHRhZ3Mgc2ltcGxlci4NCg0KICAgU3VidGFncyBpbiB0aGUgSUFOQSBy ZWdpc3RyeSB0aGF0IGRvIG5vdCBjb21lIGZyb20gYW4gdW5kZXJseWluZw0KICAgc3RhbmRh cmQgY2FuIG9ubHkgYXBwZWFyIGluIHNwZWNpZmljIHBvc2l0aW9ucyBpbiBhIHRhZy4NCiAg IFNwZWNpZmljYWxseSwgdGhleSBjYW4gb25seSBvY2N1ciBhcyBwcmltYXJ5IGxhbmd1YWdl IHN1YnRhZ3Mgb3IgYXMNCiAgIHZhcmlhbnQgc3VidGFncy4NCg0KICAgTm90ZSB0aGF0IHNl cXVlbmNlcyBvZiBwcml2YXRlIHVzZSBhbmQgZXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBvY2N1 cg0KICAgYXQgdGhlIGVuZCBvZiB0aGUgc2VxdWVuY2Ugb2Ygc3VidGFncyBhbmQgTVVTVCBO T1QgYmUgaW50ZXJzcGVyc2VkDQogICB3aXRoIHN1YnRhZ3MgZGVmaW5lZCBlbHNld2hlcmUg aW4gdGhpcyBkb2N1bWVudC4NCg0KICAgU2luZ2xlLWxldHRlciBhbmQgc2luZ2xlLWRpZ2l0 IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9yDQogICBmdXR1cmUgdXNlLiAg VGhlc2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgdXNlczoNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAg ICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgbyAgVGhlIHNp bmdsZS1sZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBpbnRyb2R1Y2UgYSBzZXF1 ZW5jZQ0KICAgICAgb2YgcHJpdmF0ZSB1c2Ugc3VidGFncy4gIFRoZSBpbnRlcnByZXRhdGlv biBvZiBhbnkgcHJpdmF0ZSB1c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVmaW5lZCBzb2xlbHkg YnkgcHJpdmF0ZSBhZ3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAgICBieSB0aGUg cnVsZXMgaW4gdGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3RyeQ0K ICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBBbGwgb3RoZXIgc2lu Z2xlLWxldHRlciBzdWJ0YWdzIGFyZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0 YW5kYXJkaXplZCBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4N CiAgICAgIFNlY3Rpb24gMy43Lg0KDQogICBUaGUgc2luZ2xlLWxldHRlciBzdWJ0YWcgJ2kn IGlzIHVzZWQgYnkgc29tZSBncmFuZGZhdGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWRl ZmF1bHQiLCB3aGVyZSBpdCBhbHdheXMgYXBwZWFycyBpbiB0aGUgZmlyc3QgcG9zaXRpb24g YW5kDQogICBjYW5ub3QgYmUgY29uZnVzZWQgd2l0aCBhbiBleHRlbnNpb24uDQoNCjIuMi4x LiAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0KICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcNCiAgICh3aXRo IHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNlcnRhaW4gZ3JhbmRmYXRoZXJl ZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhlIGZvbGxvd2luZyBydWxl cyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAxLiAg QWxsIHR3by1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUgZGVmaW5l ZCBpbiB0aGUNCiAgICAgICBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdu bWVudHMgZm91bmQgaW4gdGhlIHN0YW5kYXJkDQogICAgICAgSVNPIDYzOSBQYXJ0IDEsICJJ U08gNjM5LTE6MjAwMiwgQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZg0KICAgICAg IG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0IDE6IEFscGhhLTIgY29kZSIgW0lTTzYzOS0x XSwgb3IgdXNpbmcNCiAgICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0 aGUgSVNPIDYzOS0xIHJlZ2lzdHJhdGlvbg0KICAgICAgIGF1dGhvcml0eSAoUkEpIG9yIGdv dmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAyLiAgQWxsIHRocmVlLWNo YXJhY3RlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZQ0K ICAgICAgIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3Vu ZCBpbiBlaXRoZXIgSVNPDQogICAgICAgNjM5IFBhcnQgMiwgIklTTyA2MzktMjoxOTk4IC0g Q29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZg0KICAgICAgIG5hbWVzIG9mIGxhbmd1 YWdlcyAtLSBQYXJ0IDI6IEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSINCiAgICAgICBbSVNP NjM5LTJdLCBJU08gNjM5IFBhcnQgMywgIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24g b2YNCiAgICAgICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAzOiBBbHBoYS0zIGNvZGUg Zm9yIGNvbXByZWhlbnNpdmUNCiAgICAgICBjb3ZlcmFnZSBvZiBsYW5ndWFnZXMiIFtJU082 MzktM10sIG9yIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseQ0KICAgICAgIG1hZGUgYnkgdGhl IHJlbGV2YW50IElTTyA2MzkgcmVnaXN0cmF0aW9uIGF1dGhvcml0aWVzIG9yDQogICAgICAg Z292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDMuICBUaGUgc3VidGFn cyBpbiB0aGUgcmFuZ2UgJ3FhYScgdGhyb3VnaCAncXR6JyBhcmUgcmVzZXJ2ZWQgZm9yDQog ICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29y cmVzcG9uZCB0byBjb2Rlcw0KICAgICAgIHJlc2VydmVkIGJ5IElTTyA2MzktMiBmb3IgcHJp dmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZA0KICAgICAgIGZvciBub24tcmVn aXN0ZXJlZCBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgKGluc3RlYWQgb2YgdXNpbmcNCiAg ICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzIGZvbGxvd2luZyAneC0nKS4gIFBsZWFzZSByZWZl ciB0byBTZWN0aW9uIDQuNQ0KICAgICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHByaXZh dGUgdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBBbGwgZm91ci1jaGFyYWN0ZXIgbGFuZ3VhZ2Ug c3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxlDQogICAgICAgZnV0dXJlIHN0YW5k YXJkaXphdGlvbi4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVn dXN0IDIwMDcNCg0KDQogICA1LiAgQWxsIGxhbmd1YWdlIHN1YnRhZ3Mgb2YgNSB0byA4IGNo YXJhY3RlcnMgaW4gbGVuZ3RoIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgd2VyZSBk ZWZpbmVkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgaW4gU2VjdGlvbiAzLjUNCiAg ICAgICBhbmQgTUFZIGJlIHVzZWQgdG8gZm9ybSB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0 YWcuICBBdCB0aGUgdGltZQ0KICAgICAgIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIHRo ZXJlIHdlcmUgbm8gZXhhbXBsZXMgb2YgdGhpcyBraW5kIG9mDQogICAgICAgc3VidGFnIGFu ZCBmdXR1cmUgcmVnaXN0cmF0aW9ucyBvZiB0aGlzIHR5cGUgd2lsbCBiZSBkaXNjb3VyYWdl ZDoNCiAgICAgICBwcmltYXJ5IGxhbmd1YWdlcyBhcmUgc3Ryb25nbHkgUkVDT01NRU5ERUQg Zm9yIHJlZ2lzdHJhdGlvbiB3aXRoDQogICAgICAgSVNPIDYzOSwgYW5kIHByb3Bvc2FscyBy ZWplY3RlZCBieSBJU08gNjM5L1JBLUpBQyB3aWxsIGJlIGNsb3NlbHkNCiAgICAgICBzY3J1 dGluaXplZCBiZWZvcmUgdGhleSBhcmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEuDQoNCiAgIDYu ICBUaGUgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnIGFzIHRoZSBwcmltYXJ5IHN1YnRh ZyBpbmRpY2F0ZXMNCiAgICAgICB0aGF0IHRoZSBsYW5ndWFnZSB0YWcgY29uc2lzdHMgc29s ZWx5IG9mIHN1YnRhZ3Mgd2hvc2UgbWVhbmluZyBpcw0KICAgICAgIGRlZmluZWQgYnkgcHJp dmF0ZSBhZ3JlZW1lbnQuICBGb3IgZXhhbXBsZSwgaW4gdGhlIHRhZyAieC1mci1DSCIsDQog ICAgICAgdGhlIHN1YnRhZ3MgJ2ZyJyBhbmQgJ0NIJyBTSE9VTEQgTk9UIGJlIHRha2VuIHRv IHJlcHJlc2VudCB0aGUNCiAgICAgICBGcmVuY2ggbGFuZ3VhZ2Ugb3IgdGhlIGNvdW50cnkg b2YgU3dpdHplcmxhbmQgKG9yIGFueSBvdGhlciB2YWx1ZQ0KICAgICAgIGluIHRoZSBJQU5B IHJlZ2lzdHJ5KSB1bmxlc3MgdGhlcmUgaXMgYSBwcml2YXRlIGFncmVlbWVudCBpbg0KICAg ICAgIHBsYWNlIHRvIGRvIHNvLiAgU2VlIFNlY3Rpb24gNC41Lg0KDQogICA3LiAgVGhlIHNp bmdsZS1jaGFyYWN0ZXIgc3VidGFnICdpJyBpcyB1c2VkIGJ5IHNvbWUgZ3JhbmRmYXRoZXJl ZA0KICAgICAgIHRhZ3MgKHNlZSBTZWN0aW9uIDIuMi44KSBzdWNoIGFzICJpLWtsaW5nb24i IGFuZCAiaS1ibm4iLiAgKE90aGVyDQogICAgICAgZ3JhbmRmYXRoZXJlZCB0YWdzIGhhdmUg YSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGVpciBmaXJzdA0KICAgICAgIHBvc2l0 aW9uLikNCg0KICAgOC4gIE90aGVyIHZhbHVlcyBNVVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0 aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0IGJ5DQogICAgICAgcmV2aXNpb24gb3IgdXBkYXRl IG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFnZXMgdGhhdCBoYXZl IGJvdGggYW4gSVNPIDYzOS0xIHR3by1jaGFyYWN0ZXIgY29kZQ0KICAgYW5kIGEgdGhyZWUg Y2hhcmFjdGVyIGNvZGUgYXNzaWduZWQgYnkgZWl0aGVyIElTTyA2MzktMiBvciBJU08gNjM5 LTMsDQogICBvbmx5IHRoZSBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2RlIGlzIGRlZmlu ZWQgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5Lg0KDQogICBOb3RlOiBGb3IgbGFuZ3VhZ2Vz IHRoYXQgaGF2ZSBubyBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2RlIGFuZCBmb3INCiAg IHdoaWNoIHRoZSBJU08gNjM5LTIvVCAoVGVybWlub2xvZ3kpIGNvZGUgYW5kIHRoZSBJU08g NjM5LTIvQg0KICAgKEJpYmxpb2dyYXBoaWMpIGNvZGVzIGRpZmZlciwgb25seSB0aGUgVGVy bWlub2xvZ3kgY29kZSBpcyBkZWZpbmVkIGluDQogICB0aGUgSUFOQSByZWdpc3RyeS4gIEF0 IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIGFsbA0KICAgbGFuZ3VhZ2Vz IHRoYXQgaGFkIGJvdGgga2luZHMgb2YgdGhyZWUtY2hhcmFjdGVyIGNvZGUgd2VyZSBhbHNv DQogICBhc3NpZ25lZCBhIHR3by1jaGFyYWN0ZXIgY29kZTsgaXQgaXMgZXhwZWN0ZWQgdGhh dCBmdXR1cmUgYXNzaWdubWVudHMNCiAgIG9mIHRoaXMgbmF0dXJlIHdpbGwgbm90IG9jY3Vy Lg0KDQogICBOb3RlOiBUbyBhdm9pZCBwcm9ibGVtcyB3aXRoIHZlcnNpb25pbmcgYW5kIHN1 YnRhZyBjaG9pY2UgYXMNCiAgIGV4cGVyaWVuY2VkIGR1cmluZyB0aGUgdHJhbnNpdGlvbiBi ZXR3ZWVuIFJGQyAxNzY2IGFuZCBSRkMgMzA2NiwgYXMNCiAgIHdlbGwgYXMgdGhlIGNhbm9u aWNhbCBuYXR1cmUgb2Ygc3VidGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZQ0K ICAgSVNPIDYzOSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5IEpvaW50IEFkdmlzb3J5IENvbW1p dHRlZSAoSVNPIDYzOS8NCiAgIFJBLUpBQykgaGFzIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcg c3RhdGVtZW50IGluIFtpc282MzkucHJpbl06DQoNCiAgICAgICJBIGxhbmd1YWdlIGNvZGUg YWxyZWFkeSBpbiBJU08gNjM5LTIgYXQgdGhlIHBvaW50IG9mIGZyZWV6aW5nIElTTw0KICAg ICAgNjM5LTEgc2hhbGwgbm90IGxhdGVyIGJlIGFkZGVkIHRvIElTTyA2MzktMS4gIFRoaXMg aXMgdG8gZW5zdXJlDQogICAgICBjb25zaXN0ZW5jeSBpbiB1c2FnZSBvdmVyIHRpbWUsIHNp bmNlIHVzZXJzIGFyZSBkaXJlY3RlZCBpbg0KICAgICAgSW50ZXJuZXQgYXBwbGljYXRpb25z IHRvIGVtcGxveSB0aGUgYWxwaGEtMyBjb2RlIHdoZW4gYW4gYWxwaGEtMg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAg ICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAgICBjb2Rl IGZvciB0aGF0IGxhbmd1YWdlIGlzIG5vdCBhdmFpbGFibGUuIg0KDQogICBJbiBvcmRlciB0 byBhdm9pZCBpbnN0YWJpbGl0eSBpbiB0aGUgY2Fub25pY2FsIGZvcm0gb2YgdGFncywgaWYg YQ0KICAgdHdvLWNoYXJhY3RlciBjb2RlIGlzIGFkZGVkIHRvIElTTyA2MzktMSBmb3IgYSBs YW5ndWFnZSBmb3Igd2hpY2ggYQ0KICAgdGhyZWUtY2hhcmFjdGVyIGNvZGUgd2FzIGFscmVh ZHkgaW5jbHVkZWQgaW4gZWl0aGVyIElTTyA2MzktMiBvciBJU08NCiAgIDYzOS0zLCB0aGUg dHdvLWNoYXJhY3RlciBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQuICBTZWUNCiAgIFNl Y3Rpb24gMy40Lg0KDQogICBGb3IgZXhhbXBsZSwgaWYgc29tZSBjb250ZW50IHdlcmUgdGFn Z2VkIHdpdGggJ2hhdycgKEhhd2FpaWFuKSwgd2hpY2gNCiAgIGN1cnJlbnRseSBoYXMgbm8g dHdvLWNoYXJhY3RlciBjb2RlLCB0aGUgdGFnIHdvdWxkIG5vdCBiZSBpbnZhbGlkYXRlZA0K ICAgaWYgSVNPIDYzOS0xIHdlcmUgdG8gYXNzaWduIGEgdHdvLWNoYXJhY3RlciBjb2RlIHRv IHRoZSBIYXdhaWlhbg0KICAgbGFuZ3VhZ2UgYXQgYSBsYXRlciBkYXRlLg0KDQogICBOb3Rl OiBBbiBleGFtcGxlIG9mIGluZGVwZW5kZW50IHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIHJl Z2lzdHJhdGlvbg0KICAgbWlnaHQgaW5jbHVkZTogb25lIG9mIHRoZSBncmFuZGZhdGhlcmVk IElBTkEgcmVnaXN0cmF0aW9ucyBpcw0KICAgImktZW5vY2hpYW4iLiAgVGhlIHN1YnRhZyAn ZW5vY2hpYW4nIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5 IGFzIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGFzc3VtaW5nIHRoYXQgSVNPIDYzOSBk b2VzIG5vdA0KICAgcmVnaXN0ZXIgdGhpcyBsYW5ndWFnZSBmaXJzdCksIG1ha2luZyB0YWdz IHN1Y2ggYXMgImVub2NoaWFuLUFRIiBhbmQNCiAgICJlbm9jaGlhbi1MYXRuIiB2YWxpZC4N Cg0KMi4yLjIuICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAgIEV4dGVuZGVkIGxh bmd1YWdlIHN1YnRhZ3MgYXJlIHVzZWQgdG8gaWRlbnRpZnkgbGFuZ3VhZ2VzIHRoYXQgYXJl DQogICBlbmNvbXBhc3NlZCBieSBhICJtYWNyb2xhbmd1YWdlIi4gIElTTyA2MzktMyBkZWZp bmVzIGNlcnRhaW4NCiAgIGxhbmd1YWdlcyB0byBiZSAibWFjcm9sYW5ndWFnZXMiOyB0aGF0 IGlzLCB0aGV5IGFyZSBncm91cHMgb2YgdmVyeQ0KICAgY2xvc2VseSByZWxhdGVkIGxhbmd1 YWdlcyB3aGljaCBhcmUgdHJlYXRlZCBhcyBhIHNpbmdsZSBsYW5ndWFnZSBpbg0KICAgY2Vy dGFpbiBjb250ZXh0cy4gIEluIG9yZGVyIHRvIGltcHJvdmUgbWF0Y2hpbmcgYmVoYXZpb3Ig YW5kIHRhZ2dpbmcNCiAgIGNvbnNpc3RlbmN5LCBlYWNoIGxhbmd1YWdlIGVuY29tcGFzc2Vk IGJ5IGEgSVNPIDYzOS0zIG1hY3JvbGFuZ3VhZ2UNCiAgIGlzIHJlcHJlc2VudGVkIGluIHRo ZSBJQU5BIHJlZ2lzdHJ5IHVzaW5nIGFuIGV4dGVuZGVkIGxhbmd1YWdlDQogICBzdWJ0YWcs IHByb3ZpZGVkIHRoYXQgaXQgaXMgbm90IGFscmVhZHkgcmVwcmVzZW50ZWQgdXNpbmcgYSBs YW5ndWFnZQ0KICAgc3VidGFnLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUg ZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnczoNCg0KICAgMS4gIFRoZXNlIHN1YnRhZ3Mgd2Vy ZSBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0bw0KICAgICAgIGFz c2lnbm1lbnRzIGZvdW5kIGluIElTTyA2MzkgUGFydCAzLg0KDQogICAyLiAgQSBzZXF1ZW5j ZSBvZiB1cCB0byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIE1BWSBhcHBlYXIg aW4NCiAgICAgICBhIGxhbmd1YWdlIHRhZy4gIFRoaXMgc2VxdWVuY2UgTVVTVCBmb2xsb3cg dGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcgYW5kIHByZWNlZGUgYW55IG90 aGVyIHN1YnRhZ3MuDQoNCiAgIDMuICBFYWNoIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZyBN VVNUIG9ubHkgYXBwZWFyIGluIGEgdGFnDQogICAgICAgaW1tZWRpYXRlbHkgZm9sbG93aW5n IHRoZSBleGFjdCBzZXF1ZW5jZSBvZiBzdWJ0YWdzIHRoYXQgYXBwZWFycw0KICAgICAgIGlu IHRoZSAnUHJlZml4JyBmaWVsZCBpbiBpdHMgcmVnaXN0cnkgcmVjb3JkLg0KDQogICA0LiAg T3RoZXIgdmFsdWVzIE1VU1QgTk9UIGJlIGFzc2lnbmVkIHRvIHRoZSBleHRlbmRlZCBsYW5n dWFnZSBzdWJ0YWcNCiAgICAgICBleGNlcHQgYnkgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRo aXMgZG9jdW1lbnQuDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZyByZWNvcmRzIE1V U1QgaW5jbHVkZSBleGFjdGx5IG9uZSAnUHJlZml4Jw0KICAgZmllbGQgaW5kaWNhdGluZyBh biBhcHByb3ByaWF0ZSBzdWJ0YWcgb3Igc2VxdWVuY2Ugb2Ygc3VidGFncyBmb3INCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAg ICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgdGhh dCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgJ2dh bicgYW5kICdjbW4nIHN1YnRhZ3MgcmVwcmVzZW50IHRoZSBsYW5ndWFnZXMgR2FuDQogICBD aGluZXNlIGFuZCBNYW5kYXJpbiBDaGluZXNlLiAgRWFjaCBpcyBlbmNvbXBhc3NlZCBieSB0 aGUNCiAgIG1hY3JvbGFuZ3VhZ2UgJ3poJyAoQ2hpbmVzZSkuICBUaGVyZWZvcmUsIHRoZXkg Ym90aCBoYXZlIHRoZSBwcmVmaXgNCiAgICJ6aCIgaW4gdGhlaXIgcmVnaXN0cnkgcmVjb3Jk cy4gIENvbnNlcXVlbnRseSwgR2FuIENoaW5lc2UgaXMNCiAgIHJlcHJlc2VudGVkIGFzICJ6 aC1nYW4iIGFuZCBNYW5kYXJpbiBDaGluZXNlIGFzICJ6aC1jbW4iLiAgVGhlDQogICBsYW5n dWFnZSBzdWJ0YWcgJ3poJyBjYW4gc3RpbGwgYmUgdXNlZCB3aXRob3V0IGFuIGV4dGVuZGVk IGxhbmd1YWdlDQogICBzdWJ0YWcgdG8gbGFiZWwgYSByZXNvdXJjZSBhcyBzb21lIHVuc3Bl Y2lmaWVkIHZhcmlldHkgb2YgQ2hpbmVzZQ0KICAgKHdoaWNoIGluIHByYWN0aWNlIHdpbGwg dXN1YWxseSBiZSBNYW5kYXJpbiwgdGhlIGRvbWluYW50IHZhcmlldHkgb2YNCiAgIENoaW5l c2UsIGJ1dCBtaWdodCBhbHNvIGJlIHNvbWUgb3RoZXIgdmFyaWV0eSkuDQoNCiAgIE5vdyBz dXBwb3NlIHRoYXQsIGluIHRoZSBmdXR1cmUsIHRoZSBJU08gNjM5LTMgUmVnaXN0cmF0aW9u IEF1dGhvcml0eQ0KICAgd2VyZSB0byBkZWNpZGUgdGhhdCBHYW4gQ2hpbmVzZSBpcyBhY3R1 YWxseSB0d28gZGlmZmVyZW50IGNsb3NlbHkNCiAgIHJlbGF0ZWQgbGFuZ3VhZ2VzOiBpdCBt aWdodCByZWNsYXNzaWZ5ICdnYW4nIGFzIGEgbWFjcm9sYW5ndWFnZSBhbmQNCiAgIGludHJv ZHVjZSB0d28gbmV3IGNvZGUgZWxlbWVudHMuICBJbiB0aGF0IGNhc2UsIHRoZXNlIGNvZGUg ZWxlbWVudHMNCiAgIHdvdWxkIGJlIGFkZGVkIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIGV4 dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3Mgd2l0aA0KICAgcHJlZml4ZXMgb2YgInpoLWdhbiIu ICBObyBjaGFuZ2Ugd291bGQgYmUgbWFkZSB0byB0aGUgcmVnaXN0cnkgcmVjb3JkDQogICBm b3IgJ2dhbicuDQoNCjIuMi4zLiAgU2NyaXB0IFN1YnRhZw0KDQogICBTY3JpcHQgc3VidGFn cyBhcmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgc2NyaXB0IG9yIHdyaXRpbmcgc3lzdGVtDQog ICB2YXJpYXRpb25zIHRoYXQgZGlzdGluZ3Vpc2ggdGhlIHdyaXR0ZW4gZm9ybXMgb2YgYSBs YW5ndWFnZSBvciBpdHMNCiAgIGRpYWxlY3RzLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBs eSB0byB0aGUgc2NyaXB0IHN1YnRhZ3M6DQoNCiAgIDEuICBBbGwgZm91ci1jaGFyYWN0ZXIg c3VidGFncyB3ZXJlIGRlZmluZWQgYWNjb3JkaW5nIHRvDQogICAgICAgW0lTTzE1OTI0XS0t IkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgdGhlIG5hbWVzIG9mDQogICAgICAg c2NyaXB0cyI6IGFscGhhLTQgc2NyaXB0IGNvZGVzLCBvciBzdWJzZXF1ZW50bHkgYXNzaWdu ZWQgYnkgdGhlDQogICAgICAgSVNPIDE1OTI0IG1haW50ZW5hbmNlIGFnZW5jeSBvciBnb3Zl cm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcywNCiAgICAgICBkZW5vdGluZyB0aGUgc2Ny aXB0IG9yIHdyaXRpbmcgc3lzdGVtIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aA0KICAgICAg IHRoaXMgbGFuZ3VhZ2UuDQoNCiAgIDIuICBTY3JpcHQgc3VidGFncyBNVVNUIGltbWVkaWF0 ZWx5IGZvbGxvdyB0aGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgICAgIHN1YnRhZyBhbmQgYWxs IGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgYW5kIE1VU1Qgb2NjdXIgYmVmb3JlDQogICAg ICAgYW55IG90aGVyIHR5cGUgb2Ygc3VidGFnIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgMy4g IFRoZSBzY3JpcHQgc3VidGFncyAnUWFhYScgdGhyb3VnaCAnUWFieCcgYXJlIHJlc2VydmVk IGZvciBwcml2YXRlDQogICAgICAgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0 YWdzIGNvcnJlc3BvbmQgdG8gY29kZXMgcmVzZXJ2ZWQNCiAgICAgICBieSBJU08gMTU5MjQg Zm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMgTUFZIGJlIHVzZWQgZm9yIG5vbi0NCiAg ICAgICByZWdpc3RlcmVkIHNjcmlwdCB2YWx1ZXMuICBQbGVhc2UgcmVmZXIgdG8gU2VjdGlv biA0LjUgZm9yIG1vcmUNCiAgICAgICBpbmZvcm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0 YWdzLg0KDQogICA0LiAgU2NyaXB0IHN1YnRhZ3MgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZCB1 c2luZyB0aGUgcHJvY2VzcyBpbg0KICAgICAgIFNlY3Rpb24gMy41IG9mIHRoaXMgZG9jdW1l bnQuICBWYXJpYW50IHN1YnRhZ3MgTUFZIGJlIGNvbnNpZGVyZWQNCiAgICAgICBmb3IgcmVn aXN0cmF0aW9uIGZvciB0aGF0IHB1cnBvc2UuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug MTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICA1LiAgVGhlcmUgTVVTVCBiZSBh dCBtb3N0IG9uZSBzY3JpcHQgc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFnLCBhbmQNCiAgICAg ICB0aGUgc2NyaXB0IHN1YnRhZyBTSE9VTEQgYmUgb21pdHRlZCB3aGVuIGl0IGFkZHMgbm8N CiAgICAgICBkaXN0aW5ndWlzaGluZyB2YWx1ZSB0byB0aGUgdGFnIG9yIHdoZW4gdGhlIHBy aW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcncyByZWNvcmQgaW5jbHVkZXMgYSBTdXBw cmVzcy1TY3JpcHQgZmllbGQgbGlzdGluZyB0aGUNCiAgICAgICBhcHBsaWNhYmxlIHNjcmlw dCBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6ICJzci1MYXRuIiByZXByZXNlbnRzIFNlcmJpYW4g d3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0Lg0KDQoyLjIuNC4gIFJlZ2lvbiBTdWJ0 YWcNCg0KICAgUmVnaW9uIHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgbGluZ3Vpc3Rp YyB2YXJpYXRpb25zIGFzc29jaWF0ZWQNCiAgIHdpdGggb3IgYXBwcm9wcmlhdGUgdG8gYSBz cGVjaWZpYyBjb3VudHJ5LCB0ZXJyaXRvcnksIG9yIHJlZ2lvbi4NCiAgIFR5cGljYWxseSwg YSByZWdpb24gc3VidGFnIGlzIHVzZWQgdG8gaW5kaWNhdGUgcmVnaW9uYWwgZGlhbGVjdHMg b3INCiAgIHVzYWdlLCBvciByZWdpb24tc3BlY2lmaWMgc3BlbGxpbmcgY29udmVudGlvbnMu ICBBIHJlZ2lvbiBzdWJ0YWcgY2FuDQogICBhbHNvIGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhh dCBjb250ZW50IGlzIGV4cHJlc3NlZCBpbiBhIHdheSB0aGF0IGlzDQogICBhcHByb3ByaWF0 ZSBmb3IgdXNlIHRocm91Z2hvdXQgYSByZWdpb24sIGZvciBpbnN0YW5jZSwgU3BhbmlzaA0K ICAgY29udGVudCB0YWlsb3JlZCB0byBiZSB1c2VmdWwgdGhyb3VnaG91dCBMYXRpbiBBbWVy aWNhLg0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSByZWdpb24gc3Vi dGFnczoNCg0KICAgMS4gIFJlZ2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFueSBsYW5ndWFn ZSwgZXh0ZW5kZWQgbGFuZ3VhZ2UsIG9yDQogICAgICAgc2NyaXB0IHN1YnRhZ3MgYW5kIE1V U1QgcHJlY2VkZSBhbGwgb3RoZXIgc3VidGFncy4NCg0KICAgMi4gIEFsbCB0d28tY2hhcmFj dGVyIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyB3ZXJlDQogICAgICAg ZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1l bnRzIGZvdW5kDQogICAgICAgaW4gW0lTTzMxNjYtMV0gKCJDb2RlcyBmb3IgdGhlIHJlcHJl c2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgY291bnRyaWVzIGFuZCB0aGVpciBzdWJk aXZpc2lvbnMgLS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIikgdXNpbmcNCiAgICAgICB0aGUg bGlzdCBvZiBhbHBoYS0yIGNvdW50cnkgY29kZXMsIG9yIHVzaW5nIGFzc2lnbm1lbnRzDQog ICAgICAgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyAzMTY2IG1haW50ZW5hbmNlIGFn ZW5jeSBvciBnb3Zlcm5pbmcNCiAgICAgICBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQog ICAzLiAgQWxsIHRocmVlLWNoYXJhY3RlciBzdWJ0YWdzIGNvbnNpc3Rpbmcgb2YgZGlnaXQg KG51bWVyaWMpDQogICAgICAgY2hhcmFjdGVycyBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3Vi dGFnIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IGFjY29yZGlu ZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQgaW4gVU4gU3RhbmRhcmQNCiAgICAgICBDb3Vu dHJ5IG9yIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSBbVU5fTS40OV0gb3INCiAg ICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgZ292ZXJuaW5nIHN0 YW5kYXJkcyBib2R5Lg0KICAgICAgIE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5 IGNvZGVzIGFyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkuICBUaGUg Zm9sbG93aW5nIHJ1bGVzIGRlZmluZSB3aGljaCBjb2RlcyBhcmUgZW50ZXJlZA0KICAgICAg IGludG8gdGhlIHJlZ2lzdHJ5IGFzIHZhbGlkIHN1YnRhZ3M6DQoNCiAgICAgICBBLiAgVU4g bnVtZXJpYyBjb2RlcyBhc3NpZ25lZCB0byAnbWFjcm8tZ2VvZ3JhcGhpY2FsDQogICAgICAg ICAgIChjb250aW5lbnRhbCknIG9yIHN1Yi1yZWdpb25zIE1VU1QgYmUgcmVnaXN0ZXJlZCBp biB0aGUNCiAgICAgICAgICAgcmVnaXN0cnkuICBUaGVzZSBjb2RlcyBhcmUgbm90IGFzc29j aWF0ZWQgd2l0aCBhbiBhc3NpZ25lZA0KICAgICAgICAgICBJU08gMzE2NiBhbHBoYS0yIGNv ZGUgYW5kIHJlcHJlc2VudCBzdXByYS1uYXRpb25hbCBhcmVhcywNCiAgICAgICAgICAgdXN1 YWxseSBjb3ZlcmluZyBtb3JlIHRoYW4gb25lIG5hdGlvbiwgc3RhdGUsIHByb3ZpbmNlLCBv cg0KICAgICAgICAgICB0ZXJyaXRvcnkuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTNd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAgICAgQi4gIFVOIG51bWVyaWMgY29k ZXMgZm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAgICAgICAgICBncm91 cGluZ3MnIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYW5k DQogICAgICAgICAgIE1VU1QgTk9UIGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzLg0K DQogICAgICAgQy4gIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB3 aXRoIGFtYmlndW91cyBJU08NCiAgICAgICAgICAgMzE2NiBhbHBoYS0yIGNvZGVzLCB3aGVu IGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnksIE1VU1QgYmUNCiAgICAgICAgICAgZGVmaW5l ZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFNlY3Rpb24gMy40IGFuZCBNVVNUIGJlDQog ICAgICAgICAgIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHRoYXQgcmVwcmVzZW50IHRo ZSBjb3VudHJ5IG9yDQogICAgICAgICAgIHJlZ2lvbiBmb3Igd2hpY2ggdGhleSBhcmUgZGVm aW5lZC4NCg0KICAgICAgIEQuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3Ig YXJlYXMgZm9yIHdoaWNoIHRoZXJlIGlzIGFuDQogICAgICAgICAgIGFzc29jaWF0ZWQgSVNP IDMxNjYgYWxwaGEtMiBjb2RlIGluIHRoZSByZWdpc3RyeSBNVVNUIE5PVCBiZQ0KICAgICAg ICAgICBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRv IGZvcm0NCiAgICAgICAgICAgbGFuZ3VhZ2UgdGFncy4gIE5vdGUgdGhhdCB0aGUgSVNPIDMx NjYtYmFzZWQgc3VidGFnIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeSBNVVNUIGFjdHVh bGx5IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgVU4gTS40OSBjb2RlIGluDQogICAgICAgICAg IHF1ZXN0aW9uLg0KDQogICAgICAgRS4gIFVOIG51bWVyaWMgY29kZXMgYW5kIElTTyAzMTY2 IGFscGhhLTIgY29kZXMgZm9yIGNvdW50cmllcyBvcg0KICAgICAgICAgICBhcmVhcyBsaXN0 ZWQgYXMgZWxpZ2libGUgZm9yIHJlZ2lzdHJhdGlvbiBpbiBbUkZDNDY0NV0gYnV0DQogICAg ICAgICAgIG5vdCBwcmVzZW50bHkgcmVnaXN0ZXJlZCBNQVkgYmUgZW50ZXJlZCBpbnRvIHRo ZSBJQU5BDQogICAgICAgICAgIHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2VzcyBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjUuICBPbmNlDQogICAgICAgICAgIHJlZ2lzdGVyZWQsIHRoZXNlIGNv ZGVzIE1BWSBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEYuICBB bGwgb3RoZXIgVU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIHRoYXQg ZG8gbm90DQogICAgICAgICAgIGhhdmUgYW4gYXNzb2NpYXRlZCBJU08gMzE2NiBhbHBoYS0y IGNvZGUgTVVTVCBOT1QgYmUgZW50ZXJlZA0KICAgICAgICAgICBpbnRvIHRoZSByZWdpc3Ry eSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQogICAgICAg ICAgIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUgU2VjdGlv biAzLjQuDQoNCiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNvZGVzIGluIEFwcGVu ZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1QgYmUgZW50ZXJlZCBp bnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0KICAgICAgIGZvcm0g bGFuZ3VhZ2UgdGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVk LA0KICAgICAgIHRoZXNlIHZhbHVlcyBtYXRjaGVkIHRoZSBJU08gMzE2NiBhbHBoYS0yIGNv ZGVzLikNCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgcmVnaW9uIHN1YnRh ZyBpbiBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgcmVnaW9uIHN1YnRhZyBNQVkg YmUgb21pdHRlZCwgYXMgd2hlbiBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAg dmFsdWUgdG8gdGhlIHRhZy4NCg0KICAgNi4gIFRoZSByZWdpb24gc3VidGFncyAnQUEnLCAn UU0nLSdRWicsICdYQSctJ1haJywgYW5kICdaWicgYXJlDQogICAgICAgcmVzZXJ2ZWQgZm9y IHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzDQogICAgICAg Y29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0ZSB1 c2UuICBUaGVzZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBwcml2YXRlIHVzZSBy ZWdpb24gc3VidGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEgcHJpdmF0ZSB1c2Ug c3VidGFnIHNlcXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAgIFNlY3Rpb24gNC41 IGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgICJk ZS1DSCIgcmVwcmVzZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQg KCdDSCcpLg0KDQogICAic3ItTGF0bi1SUyIgcmVwcmVzZW50cyBTZXJiaWFuICgnc3InKSB3 cml0dGVuIHVzaW5nIExhdGluIHNjcmlwdA0KICAgKCdMYXRuJykgYXMgdXNlZCBpbiBTZXJi aWEgKCdSUycpLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0 IDIwMDcNCg0KDQogICAiZXMtNDE5IiByZXByZXNlbnRzIFNwYW5pc2ggKCdlcycpIGFwcHJv cHJpYXRlIHRvIHRoZSBVTi1kZWZpbmVkDQogICBMYXRpbiBBbWVyaWNhIGFuZCBDYXJpYmJl YW4gcmVnaW9uICgnNDE5JykuDQoNCjIuMi41LiAgVmFyaWFudCBTdWJ0YWdzDQoNCiAgIFZh cmlhbnQgc3VidGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsLCB3ZWxsLXJl Y29nbml6ZWQNCiAgIHZhcmlhdGlvbnMgdGhhdCBkZWZpbmUgYSBsYW5ndWFnZSBvciBpdHMg ZGlhbGVjdHMgdGhhdCBhcmUgbm90DQogICBjb3ZlcmVkIGJ5IG90aGVyIGF2YWlsYWJsZSBz dWJ0YWdzLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUNCiAgIHZhcmlhbnQg c3VidGFnczoNCg0KICAgMS4gIFZhcmlhbnQgc3VidGFncyBhcmUgbm90IGFzc29jaWF0ZWQg d2l0aCBhbnkgZXh0ZXJuYWwgc3RhbmRhcmQuDQogICAgICAgVmFyaWFudCBzdWJ0YWdzIGFu ZCB0aGVpciBtZWFuaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUNCiAgICAgICByZWdpc3RyYXRp b24gcHJvY2VzcyBkZWZpbmVkIGluIFNlY3Rpb24gMy41Lg0KDQogICAyLiAgVmFyaWFudCBz dWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBvZiB0aGUgb3RoZXIgZGVmaW5lZCBzdWJ0YWdzLCBi dXQNCiAgICAgICBwcmVjZWRlIGFueSBleHRlbnNpb24gb3IgcHJpdmF0ZSB1c2Ugc3VidGFn IHNlcXVlbmNlcy4NCg0KICAgMy4gIE1vcmUgdGhhbiBvbmUgdmFyaWFudCBNQVkgYmUgdXNl ZCB0byBmb3JtIHRoZSBsYW5ndWFnZSB0YWcuDQoNCiAgIDQuICBWYXJpYW50IHN1YnRhZ3Mg TVVTVCBiZSByZWdpc3RlcmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICAg cnVsZXMgaW4gU2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcgdXNl ZCB0byBmb3JtDQogICAgICAgbGFuZ3VhZ2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1 aXNoIHZhcmlhbnRzIGZyb20gb3RoZXIgdHlwZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdp c3RyYXRpb25zIE1VU1QgbWVldCB0aGUgZm9sbG93aW5nIGxlbmd0aCBhbmQNCiAgICAgICBj b250ZW50IHJlc3RyaWN0aW9uczoNCg0KICAgICAgIDEuICBWYXJpYW50IHN1YnRhZ3MgdGhh dCBiZWdpbiB3aXRoIGEgbGV0dGVyIChhLXosIEEtWikgTVVTVCBiZQ0KICAgICAgICAgICBh dCBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgICAgIDIuICBWYXJpYW50IHN1 YnRhZ3MgdGhhdCBiZWdpbiB3aXRoIGEgZGlnaXQgKDAtOSkgTVVTVCBiZSBhdA0KICAgICAg ICAgICBsZWFzdCBmb3VyIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgVmFyaWFudCBzdWJ0YWcg cmVjb3JkcyBpbiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5IE1BWSBpbmNsdWRlDQog ICBvbmUgb3IgbW9yZSAnUHJlZml4JyBmaWVsZHMuICBUaGUgJ1ByZWZpeCcgaW5kaWNhdGVz IHRoZSBsYW5ndWFnZSB0YWcNCiAgIG9yIHRhZ3MgdGhhdCB3b3VsZCBtYWtlIGEgc3VpdGFi bGUgcHJlZml4ICh3aXRoIG90aGVyIHN1YnRhZ3MsIGFzDQogICBhcHByb3ByaWF0ZSkgaW4g Zm9ybWluZyBhIGxhbmd1YWdlIHRhZyB3aXRoIHRoZSB2YXJpYW50LiAgVGhhdCBpcywNCiAg IGVhY2ggb2YgdGhlIHN1YnRhZ3MgaW4gdGhlIHByZWZpeCBTSE9VTEQgYXBwZWFyIGJlZm9y ZSB0aGUgdmFyaWFudC4NCiAgIEZvciBleGFtcGxlLCB0aGUgc3VidGFnICduZWRpcycgaGFz IGEgUHJlZml4IG9mICJzbCIsIG1ha2luZyBpdA0KICAgc3VpdGFibGUgdG8gZm9ybSBsYW5n dWFnZSB0YWdzIHN1Y2ggYXMgInNsLW5lZGlzIiBhbmQgInNsLUlULW5lZGlzIiwNCiAgIGJ1 dCBub3Qgc3VpdGFibGUgZm9yIHVzZSBpbiBhIHRhZyBzdWNoIGFzICJ6aC1uZWRpcyIgb3Ig Iml0LUlULQ0KICAgbmVkaXMiLg0KDQogICAic2wtbmVkaXMiIHJlcHJlc2VudHMgdGhlIE5h dGlzb25lIG9yIE5hZGl6YSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4NCg0KICAgImRlLUNILTE5 OTYiIHJlcHJlc2VudHMgR2VybWFuIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgYW5kIGFzIHdy aXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0gYmVnaW5uaW5nIGluIHRoZSB5 ZWFyIDE5OTYgQy5FLg0KDQogICBNb3N0IHZhcmlhbnRzIHRoYXQgc2hhcmUgYSBwcmVmaXgg YXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIEdlcm1hbiBv cnRob2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcxOTAxJyBTSE9VTEQNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAg ICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgTk9U IGJlIHVzZWQgaW4gdGhlIHNhbWUgdGFnLCBhcyB0aGV5IHJlcHJlc2VudCB0aGUgZGF0ZXMg b2YgZGlmZmVyZW50DQogICBzcGVsbGluZyByZWZvcm1zLiAgQSB2YXJpYW50IHRoYXQgY2Fu IG1lYW5pbmdmdWxseSBiZSB1c2VkIGluDQogICBjb21iaW5hdGlvbiB3aXRoIGFub3RoZXIg dmFyaWFudCBTSE9VTEQgaW5jbHVkZSBhICdQcmVmaXgnIGZpZWxkIGluDQogICBpdHMgcmVn aXN0cnkgcmVjb3JkIHRoYXQgbGlzdHMgdGhhdCBvdGhlciB2YXJpYW50LiAgRm9yIGV4YW1w bGUsIGlmDQogICBhbm90aGVyIEdlcm1hbiB2YXJpYW50ICdleGFtcGxlJyB3ZXJlIGNyZWF0 ZWQgdGhhdCBtYWRlIHNlbnNlIHRvIHVzZQ0KICAgd2l0aCAnMTk5NicsIHRoZW4gJ2V4YW1w bGUnIHNob3VsZCBpbmNsdWRlIHR3byBQcmVmaXggZmllbGRzOiAiZGUiDQogICBhbmQgImRl LTE5OTYiLg0KDQoyLjIuNi4gIEV4dGVuc2lvbiBTdWJ0YWdzDQoNCiAgIEV4dGVuc2lvbnMg cHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGxhbmd1YWdlIHRhZ3MgZm9yIHVz ZSBpbg0KICAgdmFyaW91cyBhcHBsaWNhdGlvbnMuICBTZWUgU2VjdGlvbiAzLjcuICBUaGUg Zm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvDQogICBleHRlbnNpb25zOg0KDQogICAxLiAgIEV4 dGVuc2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFncyBk ZWZpbmVkDQogICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUtY2hhcmFjdGVy IHN1YnRhZyAoInNpbmdsZXRvbiIpLg0KICAgICAgICBUaGUgc2luZ2xldG9uIE1VU1QgYmUg b25lIGFsbG9jYXRlZCB0byBhIHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkNCiAgICAgICAgdmlh IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gMy43IGFuZCBNVVNUIE5PVCBi ZSB0aGUNCiAgICAgICAgbGV0dGVyICd4Jywgd2hpY2ggaXMgcmVzZXJ2ZWQgZm9yIHByaXZh dGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMuDQoNCiAgIDIuICAgTm90ZTogUHJpdmF0ZSB1c2Ug c3VidGFnIHNlcXVlbmNlcyBzdGFydGluZyB3aXRoIHRoZSBzaW5nbGV0b24NCiAgICAgICAg c3VidGFnICd4JyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4yLjcgYmVsb3cuDQoNCiAg IDMuICAgQW4gZXh0ZW5zaW9uIE1VU1QgZm9sbG93IGF0IGxlYXN0IGEgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWcuDQogICAgICAgIFRoYXQgaXMsIGEgbGFuZ3VhZ2UgdGFnIGNhbm5vdCBi ZWdpbiB3aXRoIGFuIGV4dGVuc2lvbi4NCiAgICAgICAgRXh0ZW5zaW9ucyBleHRlbmQgbGFu Z3VhZ2UgdGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUgb3IgcmVwbGFjZQ0KICAgICAgICB0 aGVtLiAgRm9yIGV4YW1wbGUsICJhLXZhbHVlIiBpcyBub3QgYSB3ZWxsLWZvcm1lZCBsYW5n dWFnZSB0YWcsDQogICAgICAgIHdoaWxlICJkZS1hLXZhbHVlIiBpcy4NCg0KICAgNC4gICBF YWNoIHNpbmdsZXRvbiBzdWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBvbmUgdGltZSBpbiBl YWNoIHRhZw0KICAgICAgICAob3RoZXIgdGhhbiBhcyBhIHByaXZhdGUgdXNlIHN1YnRhZyku ICBUaGF0IGlzLCBzaW5nbGV0b24NCiAgICAgICAgc3VidGFncyBNVVNUIE5PVCBiZSByZXBl YXRlZC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLWJiYi1hLQ0KICAgICAgICBjY2Mi IGlzIGludmFsaWQgYmVjYXVzZSB0aGUgc3VidGFnICdhJyBhcHBlYXJzIHR3aWNlLiAgTm90 ZSB0aGF0DQogICAgICAgIHRoZSB0YWcgImVuLWEtYmJiLXgtYS1jY2MiIGlzIHZhbGlkIGJl Y2F1c2UgdGhlIHNlY29uZA0KICAgICAgICBhcHBlYXJhbmNlIG9mIHRoZSBzaW5nbGV0b24g J2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2UuDQoNCiAgIDUuICAgRXh0ZW5zaW9u IHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUNCiAg ICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGlzIGRv Y3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgbWVldCB3aGF0ZXZl ciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAgICAgZG9jdW1lbnQgdGhhdCBk ZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyDQogICAgICAgIHJl cXVpcmVtZW50cyBhcmUgcHJvdmlkZWQgYnkgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eS4N Cg0KICAgNy4gICBFYWNoIGV4dGVuc2lvbiBzdWJ0YWcgTVVTVCBiZSBmcm9tIHR3byB0byBl aWdodCBjaGFyYWN0ZXJzIGxvbmcNCiAgICAgICAgYW5kIGNvbnNpc3Qgc29sZWx5IG9mIGxl dHRlcnMgb3IgZGlnaXRzLCB3aXRoIGVhY2ggc3VidGFnDQogICAgICAgIHNlcGFyYXRlZCBi eSBhIHNpbmdsZSAnLScuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDcNCg0KDQogICA4LiAgIEVhY2ggc2luZ2xldG9uIE1VU1QgYmUgZm9s bG93ZWQgYnkgYXQgbGVhc3Qgb25lIGV4dGVuc2lvbg0KICAgICAgICBzdWJ0YWcuICBGb3Ig ZXhhbXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQgYmVjYXVzZQ0KICAg ICAgICB0aGUgZmlyc3Qgc2luZ2xldG9uICdhJyBpcyBmb2xsb3dlZCBpbW1lZGlhdGVseSBi eSBhbm90aGVyDQogICAgICAgIHNpbmdsZXRvbiAnYicuDQoNCiAgIDkuICAgRXh0ZW5zaW9u IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwN CiAgICAgICAgc2NyaXB0LCByZWdpb24sIGFuZCB2YXJpYW50IHN1YnRhZ3MgaW4gYSB0YWcu DQoNCiAgIDEwLiAgQWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBzaW5nbGV0b24gYW5kIGJl Zm9yZSBhbm90aGVyIHNpbmdsZXRvbg0KICAgICAgICBhcmUgcGFydCBvZiB0aGUgZXh0ZW5z aW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhlDQogICAgICAgIHN1 YnRhZyAnTGF0bicgZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFnICdMYXRu Jw0KICAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3Ry eS4gIEl0cyBtZWFuaW5nIGlzDQogICAgICAgIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiAn YScuDQoNCiAgIDExLiAgSW4gdGhlIGV2ZW50IHRoYXQgbW9yZSB0aGFuIG9uZSBleHRlbnNp b24gYXBwZWFycyBpbiBhIHNpbmdsZQ0KICAgICAgICB0YWcsIHRoZSB0YWcgU0hPVUxEIGJl IGNhbm9uaWNhbGl6ZWQgYXMgZGVzY3JpYmVkIGluDQogICAgICAgIFNlY3Rpb24gNC40Lg0K DQogICBGb3IgZXhhbXBsZSwgaWYgdGhlIHByZWZpeCBzaW5nbGV0b24gJ3InIGFuZCB0aGUg c2hvd24gc3VidGFncyB3ZXJlDQogICBkZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFn IHdvdWxkIGJlIGEgdmFsaWQgZXhhbXBsZTogImVuLUxhdG4tDQogICBHQi1ib29udC1yLWV4 dGVuZGVkLXNlcXVlbmNlLXgtcHJpdmF0ZSINCg0KMi4yLjcuICBQcml2YXRlIFVzZSBTdWJ0 YWdzDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgZGlz dGluY3Rpb25zIGluIGxhbmd1YWdlDQogICBpbXBvcnRhbnQgaW4gYSBnaXZlbiBjb250ZXh0 IGJ5IHByaXZhdGUgYWdyZWVtZW50LiAgVGhlIGZvbGxvd2luZw0KICAgcnVsZXMgYXBwbHkg dG8gcHJpdmF0ZSB1c2Ugc3VidGFnczoNCg0KICAgMS4gIFByaXZhdGUgdXNlIHN1YnRhZ3Mg YXJlIHNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBzdWJ0YWdzIGRlZmluZWQNCiAgICAgICBp biB0aGlzIGRvY3VtZW50IGJ5IHRoZSByZXNlcnZlZCBzaW5nbGUtY2hhcmFjdGVyIHN1YnRh ZyAneCcuDQoNCiAgIDIuICBQcml2YXRlIHVzZSBzdWJ0YWdzIE1VU1QgY29uZm9ybSB0byB0 aGUgZm9ybWF0IGFuZCBjb250ZW50DQogICAgICAgY29uc3RyYWludHMgZGVmaW5lZCBpbiB0 aGUgQUJORiBmb3IgYWxsIHN1YnRhZ3MuDQoNCiAgIDMuICBQcml2YXRlIHVzZSBzdWJ0YWdz IE1VU1QgZm9sbG93IGFsbCBsYW5ndWFnZSwgZXh0ZW5kZWQgbGFuZ3VhZ2UsDQogICAgICAg c2NyaXB0LCByZWdpb24sIHZhcmlhbnQsIGFuZCBleHRlbnNpb24gc3VidGFncyBpbiB0aGUg dGFnLg0KICAgICAgIEFub3RoZXIgd2F5IG9mIHNheWluZyB0aGlzIGlzIHRoYXQgYWxsIHN1 YnRhZ3MgZm9sbG93aW5nIHRoZQ0KICAgICAgIHNpbmdsZXRvbiAneCcgTVVTVCBiZSBjb25z aWRlcmVkIHByaXZhdGUgdXNlLiAgRXhhbXBsZTogVGhlDQogICAgICAgc3VidGFnICdVUycg aW4gdGhlIHRhZyAiZW4teC1VUyIgaXMgYSBwcml2YXRlIHVzZSBzdWJ0YWcuDQoNCiAgIDQu ICBBIHRhZyBNQVkgY29uc2lzdCBlbnRpcmVseSBvZiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0K DQogICA1LiAgTm8gc291cmNlIGlzIGRlZmluZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRhZ3Mu ICBVc2Ugb2YgcHJpdmF0ZSB1c2UNCiAgICAgICBzdWJ0YWdzIGlzIGJ5IHByaXZhdGUgYWdy ZWVtZW50IG9ubHkuDQoNCiAgIDYuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSBOT1QgUkVD T01NRU5ERUQgd2hlcmUgYWx0ZXJuYXRpdmVzIGV4aXN0DQogICAgICAgb3IgZm9yIGdlbmVy YWwgaW50ZXJjaGFuZ2UuICBTZWUgU2VjdGlvbiA0LjUgZm9yIG1vcmUgaW5mb3JtYXRpb24N CiAgICAgICBvbiBwcml2YXRlIHVzZSBzdWJ0YWcgY2hvaWNlLg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAg W1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBGb3IgZXhhbXBsZTog VXNlcnMgd2hvIHdpc2hlZCB0byB1dGlsaXplIGNvZGVzIGZyb20gdGhlIEV0aG5vbG9ndWUN CiAgIHB1YmxpY2F0aW9uIG9mIFNJTCBJbnRlcm5hdGlvbmFsIGZvciBsYW5ndWFnZSBpZGVu dGlmaWNhdGlvbiBtaWdodA0KICAgYWdyZWUgdG8gZXhjaGFuZ2UgdGFncyBzdWNoIGFzICJh ei1BcmFiLXgtQVpFLWRlcmJlbmQiLiAgVGhpcyBleGFtcGxlDQogICBjb250YWlucyB0d28g cHJpdmF0ZSB1c2Ugc3VidGFncy4gIFRoZSBmaXJzdCBpcyAnQVpFJyBhbmQgdGhlIHNlY29u ZA0KICAgaXMgJ2RlcmJlbmQnLg0KDQoyLjIuOC4gIEdyYW5kZmF0aGVyZWQgUmVnaXN0cmF0 aW9ucw0KDQogICBQcmlvciB0byBSRkMgNDY0Niwgd2hvbGUgbGFuZ3VhZ2UgdGFncyB3ZXJl IHJlZ2lzdGVyZWQgYWNjb3JkaW5nIHRvDQogICB0aGUgcnVsZXMgaW4gUkZDIDE3NjYgYW5k L29yIFJGQyAzMDY2LiAgVGhlc2UgcmVnaXN0ZXJlZCB0YWdzDQogICBtYWludGFpbiB0aGVp ciB2YWxpZGl0eS4gIE9mIHRob3NlIHRhZ3MsIHRob3NlIHRoYXQgd2VyZSBtYWRlDQogICBv YnNvbGV0ZSBvciByZWR1bmRhbnQgYnkgdGhlIGFkdmVudCBvZiBSRkMgNDY0NiwgYnkgdGhp cyBkb2N1bWVudCwgb3INCiAgIGJ5IHN1YnNlcXVlbnQgcmVnaXN0cmF0aW9uIG9mIHN1YnRh Z3MgYXJlIG1haW50YWluZWQgaW4gdGhlIHJlZ2lzdHJ5DQogICBpbiByZWNvcmRzIGFzICJy ZWR1bmRhbnQiIHJlY29yZHMuICBUaG9zZSB0YWdzIHRoYXQgZG8gbm90IG1hdGNoIHRoZQ0K ICAgJ2xhbmd0YWcnIHByb2R1Y3Rpb24gaW4gdGhlIEFCTkYgaW4gdGhpcyBkb2N1bWVudCBv ciB0aGF0IGNvbnRhaW4NCiAgIHN1YnRhZ3MgdGhhdCBkbyBub3QgaW5kaXZpZHVhbGx5IGFw cGVhciBpbiB0aGUgcmVnaXN0cnkgYXJlDQogICBtYWludGFpbmVkIGluIHRoZSByZWdpc3Ry eSBpbiByZWNvcmRzIG9mIHRoZSAiZ3JhbmRmYXRoZXJlZCIgdHlwZS4NCg0KICAgR3JhbmRm YXRoZXJlZCB0YWdzIGNvbnRhaW4gb25lIG9yIG1vcmUgc3VidGFncyB0aGF0IGFyZSBub3Qg ZGVmaW5lZA0KICAgaW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoc2VlIFNlY3Rp b24gMykuICBSZWR1bmRhbnQgdGFncw0KICAgY29uc2lzdCBlbnRpcmVseSBvZiBzdWJ0YWdz IGRlZmluZWQgYWJvdmUgYW5kIHdob3NlIGluZGVwZW5kZW50DQogICByZWdpc3RyYXRpb24g d2FzIHN1cGVyc2VkZWQgYnkgW1JGQzQ2NDZdLiAgRm9yIG1vcmUgaW5mb3JtYXRpb24gc2Vl DQogICBTZWN0aW9uIDMuOC4NCg0KICAgU29tZSBncmFuZGZhdGhlcmVkIHRhZ3MgYXJlICJy ZWd1bGFyIiBpbiB0aGF0IHRoZXkgbWF0Y2ggdGhlDQogICAnbGFuZ3RhZycgcHJvZHVjdGlv biBpbiBGaWd1cmUgMS4gIEluIHNvbWUgY2FzZXMsIHRoZXNlIHRhZ3MgY291bGQNCiAgIGJl Y29tZSByZWR1bmRhbnQgaWYgdGhlaXIgKGN1cnJlbnQgdW5yZWdpc3RlcmVkKSBzdWJ0YWdz IHdlcmUgdG8gYmUNCiAgIHJlZ2lzdGVyZWQgKGFzIHZhcmlhbnRzLCBmb3IgZXhhbXBsZSku ICBJbiBvdGhlciBjYXNlcywgYWx0aG91Z2ggdGhlDQogICBzdWJ0YWdzIG1hdGNoIHRoZSBs YW5ndWFnZSB0YWcgcGF0dGVybiwgdGhlIG1lYW5pbmcgYXNzaWduZWQgdG8gdGhlDQogICB2 YXJpb3VzIHN1YnRhZ3MgaXMgcHJvaGliaXRlZCBieSBydWxlcyBlbHNld2hlcmUgaW4gdGhp cyBkb2N1bWVudC4NCiAgIFRob3NlIHRhZ3MgY2FuIG5ldmVyIGJlY29tZSByZWR1bmRhbnQu DQoNCiAgIFRoZSByZW1haW5pbmcgZ3JhbmRmYXRoZXJlZCB0YWdzIGFyZSAiaXJyZWd1bGFy IiBhbmQgZG8gbm90IG1hdGNoIHRoZQ0KICAgJ2xhbmd0YWcnIHByb2R1Y3Rpb24uICBUaGVz ZSBhcmUgbGlzdGVkIGluIHRoZSAnaXJyZWd1bGFyJyBwcm9kdWN0aW9uDQogICBpbiBGaWd1 cmUgMS4gIFRoZXNlIGdyYW5kZmF0aGVyZWQgdGFncyBjYW4gbmV2ZXIgYmVjb21lIHJlZHVu ZGFudC4NCiAgIE1hbnkgb2YgdGhlc2UgdGFncyBoYXZlIGJlZW4gc3VwZXJzZWRlZCBieSBv dGhlciByZWdpc3RyYXRpb25zOiB0aGVpcg0KICAgcmVjb3JkIGNvbnRhaW5zIGEgUHJlZmVy cmVkLVZhbHVlIGZpZWxkIHRoYXQgcmVhbGx5IG91Z2h0IHRvIGJlIHVzZWQNCiAgIHRvIGZv cm0gbGFuZ3VhZ2UgdGFncyByZXByZXNlbnRpbmcgdGhhdCB2YWx1ZS4NCg0KMi4yLjkuICBD bGFzc2VzIG9mIENvbmZvcm1hbmNlDQoNCiAgIEltcGxlbWVudGF0aW9ucyBzb21ldGltZXMg bmVlZCB0byBkZXNjcmliZSB0aGVpciBjYXBhYmlsaXRpZXMgd2l0aA0KICAgcmVnYXJkIHRv IHRoZSBydWxlcyBhbmQgcHJhY3RpY2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiAg VGFncw0KICAgY2FuIGJlIGNoZWNrZWQgb3IgdmVyaWZpZWQgaW4gYSBudW1iZXIgb2Ygd2F5 cywgYnV0IHR3byBwYXJ0aWN1bGFyDQogICBjbGFzc2VzIG9mIHRhZyBjb25mb3JtYW5jZSBh cmUgZm9ybWFsbHkgZGVmaW5lZCBoZXJlLg0KDQogICBBIHRhZyBpcyBjb25zaWRlcmVkICJ3 ZWxsLWZvcm1lZCIgaWYgaXQgY29uZm9ybXMgdG8gdGhlIEFCTkYNCiAgIChTZWN0aW9uIDIu MSkuICBOb3RlIHRoYXQgaXJyZWd1bGFyIGdyYW5kZmF0aGVyZWQgdGFncyBhcmUgbm93IGxp c3RlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAy NSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcN Cg0KDQogICBpbiB0aGUgJ2lycmVndWxhcicgcHJvZHVjdGlvbi4NCg0KICAgQSB0YWcgaXMg Y29uc2lkZXJlZCAidmFsaWQiIGlmIGl0IHdlbGwtZm9ybWVkIGFuZCBpdCBhbHNvIHNhdGlz Zmllcw0KICAgdGhlc2UgY29uZGl0aW9uczoNCg0KICAgbyAgVGhlIHRhZyBpcyBlaXRoZXIg YSBncmFuZGZhdGhlcmVkIHRhZywgb3IgYWxsIG9mIGl0cyBsYW5ndWFnZSwNCiAgICAgIGV4 dGVuZGVkIGxhbmd1YWdlLCBzY3JpcHQsIHJlZ2lvbiwgYW5kIHZhcmlhbnQgc3VidGFncyBh cHBlYXIgaW4NCiAgICAgIHRoZSBJQU5BIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBhcyBv ZiB0aGUgcGFydGljdWxhciByZWdpc3RyeQ0KICAgICAgZGF0ZS4NCg0KICAgbyAgVGhlcmUg YXJlIG5vIGR1cGxpY2F0ZSBzaW5nbGV0b24gKGV4dGVuc2lvbikgc3VidGFncyBhbmQgbm8N CiAgICAgIGR1cGxpY2F0ZSB2YXJpYW50IHN1YnRhZ3MuDQoNCiAgIG8gIEZvciBlYWNoIHN1 YnRhZyB0aGF0IGhhcyBhICdQcmVmaXgnIGZpZWxkIGluIHRoZSByZWdpc3RyeSwgdGhlDQog ICAgICBQcmVmaXggbWF0Y2hlcyB0aGUgbGFuZ3VhZ2UgdGFnIHVzaW5nIEV4dGVuZGVkIEZp bHRlcmluZw0KICAgICAgW1JGQzQ2NDddLiAgVGhhdCBpcywgZWFjaCBzdWJ0YWcgaW4gdGhl IFByZWZpeCBpcyBwcmVzZW50IGluIHRoZQ0KICAgICAgdGFnIGFuZCBpbiB0aGUgc2FtZSBv cmRlci4gIEZ1cnRoZXJtb3JlLCBhbGwgb2YgdGhlIFByZWZpeCdzDQogICAgICBzdWJ0YWdz IE1VU1QgYXBwZWFyIGJlZm9yZSB0aGUgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSBQcmVm aXgNCiAgICAgICJ6aC1UVyIgbWF0Y2hlcyB0aGUgdGFnICJ6aC1IYW50LVRXIi4NCg0KICAg Tm90ZSB0aGF0IGEgdGFnJ3MgdmFsaWRpdHkgZGVwZW5kcyBvbiB0aGUgZGF0ZSBvZiB0aGUg cmVnaXN0cnkgdXNlZA0KICAgdG8gdmFsaWRhdGUgdGhlIHRhZy4gIEEgbW9yZS1yZWNlbnQg Y29weSBvZiB0aGUgcmVnaXN0cnkgbWlnaHQNCiAgIGNvbnRhaW4gYSBzdWJ0YWcgdGhhdCBh biBvbGRlciB2ZXJzaW9uIGRvZXMgbm90Lg0KDQogICBBIHRhZyBpcyBjb25zaWRlcmVkICJ2 YWxpZCIgZm9yIGEgZ2l2ZW4gZXh0ZW5zaW9uIChTZWN0aW9uIDMuNykgKGFzDQogICBvZiBh IHBhcnRpY3VsYXIgdmVyc2lvbiwgcmV2aXNpb24sIGFuZCBkYXRlKSBpZiBpdCBtZWV0cyB0 aGUgY3JpdGVyaWENCiAgIGZvciAidmFsaWQiIGFib3ZlIGFuZCBhbHNvIHNhdGlzZmllcyB0 aGlzIGNvbmRpdGlvbjoNCg0KICAgICAgRWFjaCBzdWJ0YWcgdXNlZCBpbiB0aGUgZXh0ZW5z aW9uIHBhcnQgb2YgdGhlIHRhZyBpcyB2YWxpZA0KICAgICAgYWNjb3JkaW5nIHRvIHRoZSBl eHRlbnNpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAg ICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCjMuICBSZWdp c3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVz IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgYW5kIHRoZSBtYWludGVuYW5jZQ0KICAg YW5kIHVwZGF0ZSBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0aCBpdCwgYXMgd2VsbCBhcyBh IHJlZ2lzdHJ5IGZvcg0KICAgZXh0ZW5zaW9ucyB0byBsYW5ndWFnZSB0YWdzIChTZWN0aW9u IDMuNykuDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgY29udGFpbnMgYSBj b21wcmVoZW5zaXZlIGxpc3Qgb2YgYWxsIG9mDQogICB0aGUgc3VidGFncyB2YWxpZCBpbiBs YW5ndWFnZSB0YWdzLiAgVGhpcyBhbGxvd3MgaW1wbGVtZW50ZXJzIGENCiAgIHN0cmFpZ2h0 Zm9yd2FyZCBhbmQgcmVsaWFibGUgd2F5IHRvIHZhbGlkYXRlIGxhbmd1YWdlIHRhZ3MuICBU aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28g dGhhdCwgZXhjZXB0IGZvcg0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxl IHRvIHZhbGlkYXRlIGFsbCBvZiB0aGUgc3VidGFncyB0aGF0DQogICBhcHBlYXIgaW4gYSBs YW5ndWFnZSB0YWcgdW5kZXIgdGhlIHByb3Zpc2lvbnMgb2YgdGhpcyBkb2N1bWVudCBvciBp dHMNCiAgIHJldmlzaW9ucyBvciBzdWNjZXNzb3JzLiAgSW4gYWRkaXRpb24sIHRoZSBtZWFu aW5nIG9mIHRoZSB2YXJpb3VzDQogICBzdWJ0YWdzIHdpbGwgYmUgdW5hbWJpZ3VvdXMgYW5k IHN0YWJsZSBvdmVyIHRpbWUuICAoVGhlIG1lYW5pbmcgb2YNCiAgIHByaXZhdGUgdXNlIHN1 YnRhZ3MsIG9mIGNvdXJzZSwgaXMgbm90IGRlZmluZWQgYnkgdGhlIElBTkEgcmVnaXN0cnku KQ0KDQozLjEuICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5 DQoNCiAgIFRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3Ry eSIpIGlzIGEgbWFjaGluZS0NCiAgIHJlYWRhYmxlIGZpbGUgaW4gdGhlIGZvcm1hdCBkZXNj cmliZWQgaW4gdGhpcyBzZWN0aW9uLCBwbHVzIGNvcGllcyBvZg0KICAgdGhlIHJlZ2lzdHJh dGlvbiBmb3JtcyBhcHByb3ZlZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHByb2Nlc3MNCiAg IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNS4gIFRoZSBleGlzdGluZyByZWdpc3RyYXRpb24g Zm9ybXMgZm9yDQogICBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncyB0YWtlbiBm cm9tIFJGQyAzMDY2IHdpbGwgYmUNCiAgIG1haW50YWluZWQgYXMgcGFydCBvZiB0aGUgb2Jz b2xldGUgUkZDIDMwNjYgcmVnaXN0cnkuICBUaGUgcmVtYWluaW5nDQogICBzZXQgb2Ygc3Vi dGFncyBjcmVhdGVkIGJ5IGVpdGhlciBbUkZDNDY0NV0gb3IgW3JlZ2lzdHJ5LXVwZGF0ZV0g d2lsbA0KICAgbm90IGhhdmUgcmVnaXN0cmF0aW9uIGZvcm1zIGNyZWF0ZWQgZm9yIHRoZW0u DQoNCjMuMS4xLiAgRmlsZSBGb3JtYXQNCg0KICAgVGhlIHJlZ2lzdHJ5IGNvbnNpc3RzIG9m IGEgc2VyaWVzIG9mIHJlY29yZHMgc3RvcmVkIGluIHRoZSByZWNvcmQtamFyDQogICBmb3Jt YXQgKGRlc2NyaWJlZCBpbiBbcmVjb3JkLWphcl0pLiAgRWFjaCByZWNvcmQsIGluIHR1cm4s IGNvbnNpc3RzDQogICBvZiBhIHNlcmllcyBvZiBmaWVsZHMgdGhhdCBkZXNjcmliZSB0aGUg dmFyaW91cyBzdWJ0YWdzIGFuZCB0YWdzLg0KICAgVGhlIHJlZ2lzdHJ5IGlzIGEgVW5pY29k ZSBbVW5pY29kZV0gdGV4dCBmaWxlLCB1c2luZyB0aGUgVVRGLTgNCiAgIFtSRkMzNjI5XSBj aGFyYWN0ZXIgZW5jb2RpbmcuDQoNCiAgIEVhY2ggZmllbGQgY2FuIGJlIGNvbnNpZGVyZWQg YSBzaW5nbGUsIGxvZ2ljYWwgbGluZSBvZiBVbmljb2RlDQogICBbVW5pY29kZV0gY2hhcmFj dGVycywgY29tcHJpc2luZyBhIGZpZWxkLW5hbWUgYW5kIGEgZmllbGQtYm9keQ0KICAgc2Vw YXJhdGVkIGJ5IGEgQ09MT04gY2hhcmFjdGVyICgleDNBKS4gIEVhY2ggZmllbGQgaXMgdGVy bWluYXRlZCBieQ0KICAgdGhlIG5ld2xpbmUgc2VxdWVuY2UgQ1JMRi4gIFRoZSB0ZXh0IGlu IGVhY2ggZmllbGQgTVVTVCBiZSBpbiBVbmljb2RlDQogICBOb3JtYWxpemF0aW9uIEZvcm0g QyAoTkZDKS4NCg0KICAgQSBjb2xsZWN0aW9uIG9mIGZpZWxkcyBmb3JtcyBhICdyZWNvcmQn LiAgUmVjb3JkcyBhcmUgc2VwYXJhdGVkIGJ5DQogICBsaW5lcyBjb250YWluaW5nIG9ubHkg dGhlIHNlcXVlbmNlICIlJSIgKCV4MjUuMjUpLg0KDQogICBBbHRob3VnaCBmaWVsZHMgYXJl IGxvZ2ljYWxseSBhIHNpbmdsZSBsaW5lIG9mIHRleHQsIGVhY2ggbGluZSBvZg0KICAgdGV4 dCBpbiB0aGUgZmlsZSBmb3JtYXQgaXMgbGltaXRlZCB0byA3MiBieXRlcyBpbiBsZW5ndGgu ICBUbw0KICAgYWNjb21tb2RhdGUgdGhpcywgdGhlIGZpZWxkLWJvZHkgY2FuIGJlIHNwbGl0 IGludG8gYSBtdWx0aXBsZS1saW5lDQogICByZXByZXNlbnRhdGlvbjsgdGhpcyBpcyBjYWxs ZWQgImZvbGRpbmciLiAgRm9sZGluZyBpcyBhbHdheXMgZG9uZSBvbg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAg ICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBVbmljb2RlIGNv ZGUgcG9pbnQgYm91bmRhcmllcyAobmV2ZXIgaW4gdGhlIG1pZGRsZSBvZiBhIG11bHRpYnl0 ZQ0KICAgVVRGLTggc2VxdWVuY2UpIGFuZCBNVVNUIE5PVCBvY2N1ciBqdXN0IHByaW9yIHRv IGEgY29tYmluaW5nIG1hcmsuDQoNCiAgIEFsdGhvdWdoIHRoZSBmaWxlIGZvcm1hdCB1c2Vz IHRoZSBVVEYtOCBlbmNvZGluZywgdW5sZXNzIG90aGVyd2lzZQ0KICAgaW5kaWNhdGVkLCBm aWVsZHMgYXJlIHJlc3RyaWN0ZWQgdG8gdGhlIHByaW50YWJsZSBjaGFyYWN0ZXJzIGZyb20g dGhlDQogICBVUy1BU0NJSSBbSVNPNjQ2XSByZXBlcnRvaXJlLg0KDQogICBUaGUgZm9ybWF0 IG9mIHRoZSByZWdpc3RyeSBpcyBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2luZyBBQk5GIChw ZXINCiAgIFtSRkM0MjM0XSk6DQoNCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENS TEYgcmVjb3JkKQ0KICAgcmVjb3JkICAgICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQ IGZpZWxkLWJvZHkgQ1JMRiApDQogICBmaWVsZC1uYW1lID0gKEFMUEhBIC8gRElHSVQpIFsq KEFMUEhBIC8gRElHSVQgLyAiLSIpIChBTFBIQSAvIERJR0lUKV0NCiAgIGZpZWxkLWJvZHkg PSAqKFtbKlNQIENSTEZdIDEqU1BdIDEqQ0hBUlMpDQogICBDSEFSUyAgICAgID0gKCV4MjEt MTBGRkZGKSAgICAgIDsgVW5pY29kZSBjb2RlIHBvaW50cw0KDQogICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDI6IFJlZ2lzdHJ5IEZvcm1hdCBBQk5GDQoNCiAgIFRoZSBzZXF1ZW5j ZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBhIHJhbmdlIG9mDQog ICB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVwcmVzZW50cyBhbGwgc3VidGFncyBvZiB0aGUg c2FtZSBsZW5ndGggdGhhdA0KICAgYXJlIGluIGFscGhhYmV0aWMgb3IgbnVtZXJpYyBvcmRl ciB3aXRoaW4gdGhhdCByYW5nZSwgaW5jbHVkaW5nIHRoZQ0KICAgdmFsdWVzIGV4cGxpY2l0 bHkgbWVudGlvbmVkLiAgRm9yIGV4YW1wbGUgJ2EuLmMnIGRlbm90ZXMgdGhlIHZhbHVlcw0K ICAgJ2EnLCAnYicsIGFuZCAnYycgYW5kICcxMS4uMTMnIGRlbm90ZXMgdGhlIHZhbHVlcyAn MTEnLCAnMTInLCBhbmQNCiAgICcxMycuDQoNCiAgIEFsbCBmaWVsZHMgd2hvc2UgZmllbGQt Ym9keSBjb250YWlucyBhIGRhdGUgdmFsdWUgdXNlIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9y bWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogIjIwMDQtMDYtMjgi IHJlcHJlc2VudHMNCiAgIEp1bmUgMjgsIDIwMDQsIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5k YXIuDQoNCjMuMS4yLiAgUmVjb3JkIERlZmluaXRpb25zDQoNCiAgIFRoZXJlIGFyZSB0aHJl ZSB0eXBlcyBvZiByZWNvcmRzIGluIHRoZSByZWdpc3RyeTogIkZpbGUtRGF0ZSIsDQogICAi U3VidGFnIiwgYW5kICJUYWciIHJlY29yZHMuDQoNCiAgIFRoZSBmaXJzdCByZWNvcmQgaW4g dGhlIHJlZ2lzdHJ5IGlzIGEgIkZpbGUtRGF0ZSIgcmVjb3JkLiAgVGhpcw0KICAgcmVjb3Jk IGNvbnRhaW5zIHRoZSBzaW5nbGUgZmllbGQgd2hvc2UgZmllbGQtbmFtZSBpcyAiRmlsZS1E YXRlIiAoc2VlDQogICBGaWd1cmUgMikuICBUaGUgZmllbGQtYm9keSBvZiB0aGlzIHJlY29y ZCBjb250YWlucyB0aGUgbGFzdA0KICAgbW9kaWZpY2F0aW9uIGRhdGUgb2YgdGhpcyBjb3B5 IG9mIHRoZSByZWdpc3RyeSwgbWFraW5nIGl0IHBvc3NpYmxlIHRvDQogICBjb21wYXJlIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgcmVnaXN0cnkuICBUaGUgcmVnaXN0cnkgb24gdGhl IElBTkENCiAgIHdlYnNpdGUgaXMgdGhlIG1vc3QgY3VycmVudC4gIFZlcnNpb25zIHdpdGgg YW4gb2xkZXIgZGF0ZSB0aGFuIHRoYXQNCiAgIG9uZSBhcmUgbm90IHVwLXRvLWRhdGUuDQoN CiAgIEZpbGUtRGF0ZTogMjAwNC0wNi0yOA0KICAgJSUNCg0KICAgICAgICAgICAgICAgICBG aWd1cmUgMzogRXhhbXBsZSBvZiB0aGUgRmlsZS1EYXRlIFJlY29yZA0KDQogICBTdWJzZXF1 ZW50IHJlY29yZHMgcmVwcmVzZW50IGVpdGhlciBzdWJ0YWdzIG9yIHRhZ3MgaW4gdGhlIHJl Z2lzdHJ5Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDcNCg0KDQogICAiU3VidGFnIiByZWNvcmRzIGNvbnRhaW4gYSBmaWVsZCB3aXRoIGEgZmll bGQtbmFtZSBvZiAiU3VidGFnIiwNCiAgIHdoaWxlLCB1bnN1cnByaXNpbmdseSwgIlRhZyIg cmVjb3JkcyBjb250YWluIGEgZmllbGQgd2l0aCBhIGZpZWxkLQ0KICAgbmFtZSBvZiAiVGFn Ii4gIEVhY2ggb2YgdGhlIGZpZWxkcyBpbiBlYWNoIHJlY29yZCBNVVNUIG9jY3VyIG5vIG1v cmUNCiAgIHRoYW4gb25jZSwgdW5sZXNzIG90aGVyd2lzZSBub3RlZCBiZWxvdy4gIEVhY2gg cmVjb3JkIE1VU1QgY29udGFpbg0KICAgdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8g ICdUeXBlJw0KDQogICAgICAqICBUeXBlJ3MgZmllbGQtYm9keSBNVVNUIGNvbnNpc3Qgb2Yg b25lIG9mIHRoZSBmb2xsb3dpbmcgc3RyaW5nczoNCiAgICAgICAgICJsYW5ndWFnZSIsICJl eHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCAidmFyaWFudCIsDQogICAgICAgICAiZ3Jh bmRmYXRoZXJlZCIsIGFuZCAicmVkdW5kYW50IiBhbmQgZGVub3RlcyB0aGUgdHlwZSBvZiB0 YWcgb3INCiAgICAgICAgIHN1YnRhZy4NCg0KICAgbyAgRWl0aGVyICdTdWJ0YWcnIG9yICdU YWcnDQoNCiAgICAgICogIFN1YnRhZydzIGZpZWxkLWJvZHkgY29udGFpbnMgdGhlIHN1YnRh ZyBiZWluZyBkZWZpbmVkLiAgVGhpcw0KICAgICAgICAgZmllbGQgTVVTVCBvbmx5IGFwcGVh ciBpbiByZWNvcmRzIG9mIHdob3NlICdUeXBlJyBoYXMgb25lIG9mDQogICAgICAgICB0aGVz ZSB2YWx1ZXM6ICJsYW5ndWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBv cg0KICAgICAgICAgInZhcmlhbnQiLg0KDQogICAgICAqICBUYWcncyBmaWVsZC1ib2R5IGNv bnRhaW5zIGEgY29tcGxldGUgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBmaWVsZA0KICAgICAgICAg TVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJyBoYXMgb25lIG9mIHRo ZXNlDQogICAgICAgICB2YWx1ZXM6ICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50Ii4g IE5vdGUgdGhhdCB0aGUgZmllbGQtDQogICAgICAgICBib2R5IHdpbGwgYWx3YXlzIGZvbGxv dyB0aGUgJ2dyYW5kZmF0aGVyZWQnIHByb2R1Y3Rpb24gaW4gdGhlDQogICAgICAgICBBQk5G IGluIFNlY3Rpb24gMi4xDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2Ny aXB0aW9uJ3MgZmllbGQtYm9keSBjb250YWlucyBhIG5vbi1ub3JtYXRpdmUgZGVzY3JpcHRp b24NCiAgICAgICAgIG9mIHRoZSBzdWJ0YWcgb3IgdGFnLg0KDQogICBvICBBZGRlZA0KDQog ICAgICAqICBBZGRlZCdzIGZpZWxkLWJvZHkgY29udGFpbnMgdGhlIGRhdGUgdGhlIHJlY29y ZCB3YXMgYWRkZWQgdG8NCiAgICAgICAgIHRoZSByZWdpc3RyeS4NCg0KICAgRWFjaCByZWNv cmQgTUFZIGFsc28gY29udGFpbiB0aGUgZm9sbG93aW5nIGZpZWxkczoNCg0KICAgbyAgUHJl ZmVycmVkLVZhbHVlDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnc2NyaXB0Jywg J3JlZ2lvbicsIGFuZCAndmFyaWFudCcsDQogICAgICAgICAnUHJlZmVycmVkLVZhbHVlJyBj b250YWlucyB0aGUgc3VidGFnIG9mIHRoZSBzYW1lICdUeXBlJyB0aGF0DQogICAgICAgICBp cyBwcmVmZXJyZWQgZm9yIGZvcm1pbmcgdGhlIGxhbmd1YWdlIHRhZy4NCg0KICAgICAgKiAg Rm9yIGZpZWxkcyBvZiB0eXBlICdsYW5ndWFnZScgYW5kICdleHRsYW5nJywgJ1ByZWZlcnJl ZC1WYWx1ZScNCiAgICAgICAgIGNvbnRhaW5zIHRoZSBsYW5ndWFnZSBwcm9kdWN0aW9uIChz ZWUgRmlndXJlIDEpIHRoYXQgaXMNCiAgICAgICAgIHByZWZlcnJlZCB3aGVuIGZvcm1pbmcg dGhlIGxhbmd1YWdlIHRhZy4gIFRoaXMgY2FuIGJlIHNpbXBseSBhDQogICAgICAgICAnbGFu Z3VhZ2UnIHN1YnRhZywgb3IgaXQgY2FuIGJlIGEgJ2xhbmd1YWdlJyBzdWJ0YWcgZm9sbG93 ZWQgYnkNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3 DQoNCg0KICAgICAgICAgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2Ugc2VxdWVuY2UuDQoNCiAgICAg ICogIEZvciBmaWVsZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgYW5kICdyZWR1bmRhbnQn LCBhIGNhbm9uaWNhbA0KICAgICAgICAgbWFwcGluZyB0byBhIGNvbXBsZXRlIGxhbmd1YWdl IHRhZy4NCg0KICAgbyAgRGVwcmVjYXRlZA0KDQogICAgICAqICBEZXByZWNhdGVkJ3MgZmll bGQtYm9keSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcw0KICAgICAgICAgZGVw cmVjYXRlZC4NCg0KICAgbyAgUHJlZml4DQoNCiAgICAgICogIFByZWZpeCdzIGZpZWxkLWJv ZHkgY29udGFpbnMgYSBsYW5ndWFnZSB0YWcgd2l0aCB3aGljaCB0aGlzDQogICAgICAgICBz dWJ0YWcgTUFZIGJlIHVzZWQgdG8gZm9ybSBhIG5ldyBsYW5ndWFnZSB0YWcsIHBlcmhhcHMg d2l0aA0KICAgICAgICAgb3RoZXIgc3VidGFncyBhcyB3ZWxsLiAgVGhlIFByZWZpeCdzIHN1 YnRhZ3MgYXBwZWFyIGJlZm9yZSB0aGUNCiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQg TVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmll bGQtYm9keSBpcyAndmFyaWFudCcgb3IgJ2V4dGxhbmcnLiAgRm9yIGV4YW1wbGUsIHRoZQ0K ICAgICAgICAgJ1ByZWZpeCcgZm9yIHRoZSB2YXJpYW50ICduZWRpcycgaXMgJ3NsJywgbWVh bmluZyB0aGF0IHRoZSB0YWdzDQogICAgICAgICAic2wtbmVkaXMiIGFuZCAic2wtSVQtbmVk aXMiIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHdoaWxlIHRoZSB0YWcNCiAgICAgICAgICJpcy1u ZWRpcyIgaXMgbm90Lg0KDQogICBvICBDb21tZW50cw0KDQogICAgICAqICBDb21tZW50cyBj b250YWlucyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJ0YWcsIGFzDQog ICAgICAgICBkZWVtZWQgYXBwcm9wcmlhdGUgZm9yIHVuZGVyc3RhbmRpbmcgdGhlIHJlZ2lz dHJ5IGFuZA0KICAgICAgICAgaW1wbGVtZW50aW5nIGxhbmd1YWdlIHRhZ3MgdXNpbmcgdGhl IHN1YnRhZyBvciB0YWcuDQoNCiAgIG8gIFN1cHByZXNzLVNjcmlwdA0KDQogICAgICAqICBT dXBwcmVzcy1TY3JpcHQgY29udGFpbnMgYSBzY3JpcHQgc3VidGFnIHRoYXQgU0hPVUxEIE5P VCBiZQ0KICAgICAgICAgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgd2l0aCB0aGUgYXNz b2NpYXRlZCBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgICBzdWJ0YWcuICBUaGlzIGZpZWxk IE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAnVHlwZScNCiAgICAgICAgIGZp ZWxkLWJvZHkgaXMgJ2xhbmd1YWdlJy4gIFNlZSBTZWN0aW9uIDQuMS4NCg0KICAgbyAgTWFj cm9sYW5ndWFnZQ0KDQogICAgICAqICBNYWNyb2xhbmd1YWdlIGNvbnRhaW5zIGEgcHJpbWFy eSBvciBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgICAgIGRlZmluZWQgYnkgSVNP IDYzOSBhcyBhICJtYWNyb2xhbmd1YWdlIiB0aGF0IGVuY29tcGFzc2VzIHRoaXMNCiAgICAg ICAgIGxhbmd1YWdlIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiBy ZWNvcmRzIHdob3NlDQogICAgICAgICAnVHlwZScgZmllbGQtYm9keSBpcyAnbGFuZ3VhZ2Un IG9yICdleHRsYW5nJy4NCg0KICAgRnV0dXJlIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQg bWlnaHQgYWRkIGFkZGl0aW9uYWwgZmllbGRzIHRvIHRoZQ0KICAgcmVnaXN0cnksIHNvIGlt cGxlbWVudGF0aW9ucyBTSE9VTEQgaWdub3JlIGZpZWxkcyBmb3VuZCBpbiB0aGUNCiAgIHJl Z2lzdHJ5IHRoYXQgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIw MDggICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0K My4xLjMuICBTdWJ0YWcgYW5kIFRhZyBGaWVsZHMNCg0KICAgVGhlICdTdWJ0YWcnIGZpZWxk IE1VU1QgdXNlIGxvd2VyY2FzZSBsZXR0ZXJzIHRvIGZvcm0gdGhlIHN1YnRhZywNCiAgIHdp dGggdHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBpcyAnc2Ny aXB0JyAoaW4NCiAgIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDE1OTI0 KSBNVVNUIHVzZSB0aXRsZWNhc2UuDQogICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBp cyAncmVnaW9uJyAoaW4gb3RoZXIgd29yZHMsIHRoZSBub24tDQogICBudW1lcmljIHJlZ2lv biBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDMxNjYpIE1VU1QgdXNlIHVwcGVyY2FzZS4NCiAg IFRoZXNlIGV4Y2VwdGlvbnMgbWlycm9yIHRoZSB1c2Ugb2YgY2FzZSBpbiB0aGUgdW5kZXJs eWluZyBzdGFuZGFyZHMuDQoNCiAgIEVhY2ggc3VidGFnIGluIHRoZSB0YWdzIGNvbnRhaW5l ZCBpbiBhICdUYWcnIGZpZWxkIE1VU1QgYmUgZm9ybWF0dGVkDQogICB1c2luZyB0aGUgcnVs ZXMgaW4gdGhlIHByZWNlZWRpbmcgcGFyYWdyYXBoLiAgVGhhdCBpcywgYWxsIHN1YnRhZ3MN CiAgIGFyZSBsb3dlcmNhc2UgZXhjZXB0IGZvciBzdWJ0YWdzIHRoYXQgcmVwcmVzZW50IHNj cmlwdCBvciByZWdpb24NCiAgIGNvZGVzLg0KDQozLjEuNC4gIERlc2NyaXB0aW9uIEZpZWxk DQoNCiAgIFRoZSBmaWVsZCAnRGVzY3JpcHRpb24nIGNvbnRhaW5zIGEgZGVzY3JpcHRpb24g b2YgdGhlIHRhZyBvciBzdWJ0YWcNCiAgIGluIHRoZSByZWNvcmQuICBUaGUgJ0Rlc2NyaXB0 aW9uJyBmaWVsZCBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIHBlcg0KICAgcmVjb3JkLCB0 aGF0IGlzLCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgZGVzY3JpcHRpb25zIGZvciBhIGdpdmVu DQogICByZWNvcmQuICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNQVkgaW5jbHVkZSB0aGUg ZnVsbCByYW5nZSBvZg0KICAgVW5pY29kZSBjaGFyYWN0ZXJzLiAgQXQgbGVhc3Qgb25lIG9m IHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkcyBNVVNUIGJlDQogICB3cml0dGVuIG9yIHRyYW5z Y3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsgYWRkaXRpb25hbA0KICAgJ0Rlc2NyaXB0 aW9uJyBmaWVsZHMgTUFZIGFsc28gaW5jbHVkZSBhIGRlc2NyaXB0aW9uIGluIGEgbm9uLUxh dGluDQogICBzY3JpcHQuICBFYWNoICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBiZSB1bmlx dWUsIGJvdGggd2l0aGluIHRoZQ0KICAgcmVjb3JkIGluIHdoaWNoIGl0IGFwcGVhcnMgYW5k IGZvciB0aGUgY29sbGVjdGlvbiBvZiByZWNvcmRzIG9mIHRoZQ0KICAgc2FtZSB0eXBlLiAg TW9yZW92ZXIsIGZvcm1hdHRpbmcgdmFyaWF0aW9ucyBvZiB0aGUgc2FtZSBkZXNjcmlwdGlv bg0KICAgTVVTVCBOT1Qgb2NjdXIgaW4gdGhhdCBzcGVjaWZpYyByZWNvcmQgb3IgaW4gYW55 IG90aGVyIHJlY29yZCBvZiB0aGUNCiAgIHNhbWUgdHlwZS4gIEZvciBleGFtcGxlLCB3aGls ZSB0aGUgSVNPIDYzOS0xIGNvZGUgJ2Z5JyBjb250YWlucyBib3RoDQogICB0aGUgZGVzY3Jp cHRpb25zICJXZXN0ZXJuIEZyaXNpYW4iIGFuZCAiRnJpc2lhbiwgV2VzdGVybiIsIG9ubHkg b25lDQogICBvZiB0aGVzZSBkZXNjcmlwdGlvbnMgYXBwZWFycyBpbiB0aGUgcmVnaXN0cnku DQoNCiAgIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0 aW9uIHB1cnBvc2VzIGFuZA0KICAgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXByZXNlbnQg dGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUNCiAgIGxhbmd1YWdlIG9yIHZhcmlhdGlv biBvciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCg0KICAgRm9yIHJlY29y ZHMgdGFrZW4gZnJvbSBhIHNvdXJjZSBzdGFuZGFyZCAoc3VjaCBhcyBJU08gNjM5IG9yIElT Tw0KICAgMzE2NiksIHRoZSAnRGVzY3JpcHRpb24nIHZhbHVlKHMpIFNIT1VMRCBhbHNvIGJl IHRha2VuIGZyb20gdGhlDQogICBzb3VyY2Ugc3RhbmRhcmQuICBNdWx0aXBsZSBkZXNjcmlw dGlvbnMgaW4gdGhlIHNvdXJjZSBzdGFuZGFyZCBNVVNUDQogICBiZSBzcGxpdCBpbnRvIHNl cGFyYXRlICdEZXNjcmlwdGlvbicgZmllbGRzLiAgVGhlIHNvdXJjZSBzdGFuZGFyZCdzDQog ICBkZXNjcmlwdGlvbnMgTUFZIGJlIGVkaXRlZCwgZWl0aGVyIHByaW9yIHRvIGluc2VydGlv biBvciB2aWEgdGhlDQogICByZWdpc3RyYXRpb24gcHJvY2Vzcy4gIEZvciBmaWVsZHMgb2Yg dHlwZSAnbGFuZ3VhZ2UnIG9yICdleHRsYW5nJywNCiAgIHRoZSBmaXJzdCAnRGVzY3JpcHRp b24nIGZpZWxkIGFwcGVhcmluZyBpbiB0aGUgUmVnaXN0cnkgY29ycmVzcG9uZHMNCiAgIHRv IHRoZSBSZWZlcmVuY2UgTmFtZSBhc3NpZ25lZCBieSBJU08gNjM5LTMuICBUaGlzIGhlbHBz IGZhY2lsaXRhdGUNCiAgIGNyb3NzLXJlZmVyZW5jaW5nIGJldHdlZW4gSVNPIDYzOSBhbmQg dGhlIHJlZ2lzdHJ5Lg0KDQogICBXaGVuIGNyZWF0aW5nIG9yIHVwZGF0aW5nIGEgcmVjb3Jk IGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUNCiAgIHNvdXJjZSBzdGFuZGFyZHMs IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgU0hPVUxEIHJlbW92ZQ0KICAgZHVwbGlj YXRlIG9yIHJlZHVuZGFudCBkZXNjcmlwdGlvbnMgYW5kIE1BWSBlZGl0IGRlc2NyaXB0aW9u cyB0bw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAy NSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcN Cg0KDQogICBjb3JyZWN0IGlycmVndWxhcml0aWVzIGluIGZvcm1hdHRpbmcgKHN1Y2ggYXMg bWlzc3BlbGxpbmdzLA0KICAgaW5hcHByb3ByaWF0ZSBhcG9zdHJvcGhlcyBvciBvdGhlciBw dW5jdHVhdGlvbiwgb3IgZXhjZXNzaXZlIG9yDQogICBtaXNzaW5nIHNwYWNlcykgcHJpb3Ig dG8gc3VibWl0dGluZyB0aGUgcHJvcG9zZWQgcmVjb3JkIHRvIHRoZSBpZXRmLQ0KICAgbGFu Z3VhZ2VzIGxpc3QuDQoNCiAgIE5vdGU6IERlc2NyaXB0aW9ucyBpbiByZWdpc3RyeSBlbnRy aWVzIHRoYXQgY29ycmVzcG9uZCB0byBJU08gNjM5LA0KICAgSVNPIDE1OTI0LCBJU08gMzE2 Niwgb3IgVU4gTS40OSBjb2RlcyBhcmUgaW50ZW5kZWQgb25seSB0byBpbmRpY2F0ZQ0KICAg dGhlIG1lYW5pbmcgb2YgdGhhdCBpZGVudGlmaWVyIGFzIGRlZmluZWQgaW4gdGhlIHNvdXJj ZSBzdGFuZGFyZCBhdA0KICAgdGhlIHRpbWUgaXQgd2FzIGFkZGVkIHRvIHRoZSByZWdpc3Ry eS4gIFRoZSBkZXNjcmlwdGlvbiBkb2VzIG5vdA0KICAgcmVwbGFjZSB0aGUgY29udGVudCBv ZiB0aGUgc291cmNlIHN0YW5kYXJkIGl0c2VsZi4gIFRoZSBkZXNjcmlwdGlvbnMNCiAgIGFy ZSBub3QgaW50ZW5kZWQgdG8gYmUgdGhlIEVuZ2xpc2ggbG9jYWxpemVkIG5hbWVzIGZvciB0 aGUgc3VidGFncy4NCiAgIExvY2FsaXphdGlvbiBvciB0cmFuc2xhdGlvbiBvZiBsYW5ndWFn ZSB0YWcgYW5kIHN1YnRhZyBkZXNjcmlwdGlvbnMNCiAgIGlzIG91dCBvZiBzY29wZSBvZiB0 aGlzIGRvY3VtZW50Lg0KDQozLjEuNS4gIERlcHJlY2F0ZWQgRmllbGQNCg0KICAgVGhlIGZp ZWxkICdEZXByZWNhdGVkJyBNQVkgYmUgYWRkZWQgdG8gYW55IHJlY29yZCB2aWEgdGhlIG1h aW50ZW5hbmNlDQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMyBvciB2aWEg dGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUu ICBVc3VhbGx5LCB0aGUgYWRkaXRpb24gb2YgYSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxkIGlz IGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUgc3RhbmRhcmRzIGJvZGllcywgc3Vj aCBhcw0KICAgSVNPIDMxNjYsIHdpdGhkcmF3aW5nIGEgY29kZS4gIEluIHNvbWUgaGlzdG9y aWNhbCBjYXNlcywgaXQgbWlnaHQgbm90DQogICBoYXZlIGJlZW4gcG9zc2libGUgdG8gcmVj b25zdHJ1Y3QgdGhlIG9yaWdpbmFsIGRlcHJlY2F0aW9uIGRhdGUuICBGb3INCiAgIHRoZXNl IGNhc2VzLCBhbiBhcHByb3hpbWF0ZSBkYXRlIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5LiAg QWx0aG91Z2gNCiAgIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIHN1YnRhZ3MgYW5kIHRhZ3Mg d2l0aCBhICdEZXByZWNhdGVkJyBmaWVsZA0KICAgYXJlIGRlcHJlY2F0ZWQgYW5kIHZhbGlk YXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UIGdlbmVyYXRlIHRoZXNlDQogICBzdWJ0YWdz LiAgTm90ZSB0aGF0IGEgcmVjb3JkIHRoYXQgY29udGFpbnMgYSAnRGVwcmVjYXRlZCcgZmll bGQgYW5kDQogICBubyBjb3JyZXNwb25kaW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGhh cyBubyByZXBsYWNlbWVudCBtYXBwaW5nLg0KDQozLjEuNi4gIFByZWZlcnJlZC1WYWx1ZSBG aWVsZA0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJlZC1WYWx1ZScgY29udGFpbnMgYSBtYXBw aW5nIGJldHdlZW4gdGhlIHJlY29yZCBpbg0KICAgd2hpY2ggaXQgYXBwZWFycyBhbmQgYW5v dGhlciB0YWcgb3Igc3VidGFnLiAgVGhlIHZhbHVlIGluIHRoaXMgZmllbGQNCiAgIGlzIHN0 cm9uZ2x5IFJFQ09NTUVOREVEIGFzIHRoZSBiZXN0IGNob2ljZSB0byByZXByZXNlbnQgdGhl IHZhbHVlIG9mDQogICB0aGlzIHJlY29yZCB3aGVuIHNlbGVjdGluZyBhIGxhbmd1YWdlIHRh Zy4gIFRoZXNlIHZhbHVlcyBmb3JtIHRocmVlDQogICBncm91cHM6DQoNCiAgIDEuICBJU08g NjM5IGxhbmd1YWdlIGNvZGVzIHRoYXQgd2VyZSBsYXRlciB3aXRoZHJhd24gaW4gZmF2b3Ig b2YNCiAgICAgICBvdGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUgbW9zdGx5IGEgaGlz dG9yaWNhbCBjdXJpb3NpdHkuDQoNCiAgIDIuICBJU08gMzE2NiByZWdpb24gY29kZXMgdGhh dCBoYXZlIGJlZW4gd2l0aGRyYXduIGluIGZhdm9yIG9mIGEgbmV3DQogICAgICAgY29kZS4g IFRoaXMgc29tZXRpbWVzIGhhcHBlbnMgd2hlbiBhIGNvdW50cnkgY2hhbmdlcyBpdHMgbmFt ZSBvcg0KICAgICAgIGFkbWluaXN0cmF0aW9uIGluIHN1Y2ggYSB3YXkgdGhhdCB3YXJyYW50 cyBhIG5ldyByZWdpb24gY29kZS4NCg0KICAgMy4gIEdyYW5kZmF0aGVyZWQgb3IgcmVkdW5k YW50IHRhZ3MgZnJvbSBSRkMgMzA2Ni4gIEluIG1hbnkgY2FzZXMsDQogICAgICAgdGhlc2Ug dGFncyBoYXZlIGJlY29tZSBvYnNvbGV0ZSBiZWNhdXNlIHRoZSB2YWx1ZXMgdGhleSByZXBy ZXNlbnQNCiAgICAgICB3ZXJlIGxhdGVyIGVuY29kZWQgYnkgSVNPIDYzOS4NCg0KICAgUmVj b3JkcyB0aGF0IGNvbnRhaW4gYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBNVVNUIGFsc28g aGF2ZSBhDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw Nw0KDQoNCiAgICdEZXByZWNhdGVkJyBmaWVsZC4gIFRoaXMgZmllbGQgY29udGFpbnMgYSBk YXRlIG9mIGRlcHJlY2F0aW9uLg0KICAgVGh1cywgYSBsYW5ndWFnZSB0YWcgcHJvY2Vzc29y IGNhbiB1c2UgdGhlIHJlZ2lzdHJ5IHRvIGNvbnN0cnVjdCB0aGUNCiAgIHZhbGlkLCBub24t ZGVwcmVjYXRlZCBzZXQgb2Ygc3VidGFncyBmb3IgYSBnaXZlbiBkYXRlLiAgSW4gYWRkaXRp b24sDQogICBmb3IgYW55IGdpdmVuIHRhZywgYSBwcm9jZXNzb3IgY2FuIGNvbnN0cnVjdCB0 aGUgc2V0IG9mIHZhbGlkDQogICBsYW5ndWFnZSB0YWdzIHRoYXQgY29ycmVzcG9uZCB0byB0 aGF0IHRhZyBmb3IgYWxsIGRhdGVzIHVwIHRvIHRoZQ0KICAgZGF0ZSBvZiB0aGUgcmVnaXN0 cnkuICBUaGUgYWJpbGl0eSB0byBkbyB0aGVzZSBtYXBwaW5ncyBNQVkgYmUNCiAgIGJlbmVm aWNpYWwgdG8gYXBwbGljYXRpb25zIHRoYXQgYXJlIG1hdGNoaW5nLCBzZWxlY3RpbmcsIGZv cg0KICAgZmlsdGVyaW5nIGNvbnRlbnQgYmFzZWQgb24gaXRzIGxhbmd1YWdlIHRhZ3MuDQoN CiAgIE5vdGUgdGhhdCAnUHJlZmVycmVkLVZhbHVlJyBtYXBwaW5ncyBpbiByZWNvcmRzIG9m IHR5cGUgJ3JlZ2lvbicNCiAgIHNvbWV0aW1lcyBkbyBub3QgcmVwcmVzZW50IGV4YWN0bHkg dGhlIHNhbWUgbWVhbmluZyBhcyB0aGUgb3JpZ2luYWwNCiAgIHZhbHVlLiAgVGhlcmUgYXJl IG1hbnkgcmVhc29ucyBmb3IgYSBjb3VudHJ5IGNvZGUgdG8gYmUgY2hhbmdlZCwgYW5kDQog ICB0aGUgZWZmZWN0IHRoaXMgaGFzIG9uIHRoZSBmb3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFn cyB3aWxsIGRlcGVuZCBvbg0KICAgdGhlIG5hdHVyZSBvZiB0aGUgY2hhbmdlIGluIHF1ZXN0 aW9uLg0KDQogICBJbiBwYXJ0aWN1bGFyLCB0aGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQg ZG9lcyBub3QgaW1wbHkgcmV0YWdnaW5nDQogICBjb250ZW50IHRoYXQgdXNlcyB0aGUgYWZm ZWN0ZWQgc3VidGFnLg0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJlZC1WYWx1ZScgTVVTVCBO T1QgYmUgbW9kaWZpZWQgb25jZSBjcmVhdGVkIGluIHRoZQ0KICAgcmVnaXN0cnkuICBUaGUg ZmllbGQgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgYWNjb3JkaW5nIHRvIHRoZSBydWxlcw0K ICAgaW4gU2VjdGlvbiAzLjMuDQoNCiAgIFRoZSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBp biByZWNvcmRzIG9mIHR5cGUgImdyYW5kZmF0aGVyZWQiIGFuZA0KICAgInJlZHVuZGFudCIg Y29udGFpbnMgd2hvbGUgbGFuZ3VhZ2UgdGFncyB0aGF0IGFyZSBzdHJvbmdseQ0KICAgUkVD T01NRU5ERUQgZm9yIHVzZSBpbiBwbGFjZSBvZiB0aGUgcmVjb3JkJ3MgdmFsdWUuICBJbiBt YW55IGNhc2VzLA0KICAgdGhlIG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBkZXByZWNhdGlv biBvZiB0aGUgdGFncyBkdXJpbmcgdGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9jdW1l bnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4iIHdh cyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEtZGVmaW5lZCBsYW5ndWFn ZSBjb2RlDQogICAnbm4nLg0KDQozLjEuNy4gIFByZWZpeCBGaWVsZA0KDQogICBUaGUgJ1By ZWZpeCcgZmllbGQgY29udGFpbnMgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2Ugd2hvc2Ug c3VidGFncw0KICAgYXJlIGFwcHJvcHJpYXRlIHRvIHVzZSB3aXRoIHRoaXMgc3VidGFnOiBl YWNoIG9mIHRoZSBzdWJ0YWdzIGluIG9uZQ0KICAgb2YgdGhlIHN1YnRhZydzIFByZWZpeCBm aWVsZHMgTVVTVCBhcHBlYXIgYmVmb3JlIHRoZSB2YXJpYW50IGluIGENCiAgIHZhbGlkIHRh Zy4gIEZvciBleGFtcGxlLCB0aGUgdmFyaWFudCBzdWJ0YWcgJzE5OTYnIGhhcyBhICdQcmVm aXgnDQogICBmaWVsZCBvZiAiZGUiLiAgVGhpcyBtZWFucyB0aGF0IHRhZ3Mgc3RhcnRpbmcg d2l0aCB0aGUgc2VxdWVuY2UgImRlLSINCiAgIGFyZSBhcHByb3ByaWF0ZSB3aXRoIHRoaXMg c3VidGFnLCBzbyAiZGUtTGF0Zy0xOTk2IiBhbmQgImRlLUNILTE5OTYiDQogICBhcmUgYm90 aCBhY2NlcHRhYmxlLCB3aGlsZSB0aGUgdGFnICJmci0xOTk2IiBpcyBhbiBpbmFwcHJvcHJp YXRlDQogICBjaG9pY2UuDQoNCiAgIFRoZSBmaWVsZCBvZiB0eXBlICdQcmVmaXgnIE1VU1Qg Tk9UIGJlIHJlbW92ZWQgZnJvbSBhbnkgcmVjb3JkLiAgVGhlDQogICBmaWVsZC1ib2R5IGZv ciB0aGlzIHR5cGUgb2YgZmllbGQgTUFZIGJlIG1vZGlmaWVkLCBidXQgb25seSBpZiB0aGUN CiAgIG1vZGlmaWNhdGlvbiBicm9hZGVucyB0aGUgbWVhbmluZyBvZiB0aGUgc3VidGFnLiAg VGhhdCBpcywgdGhlIGZpZWxkLQ0KICAgYm9keSBjYW4gYmUgcmVwbGFjZWQgb25seSBieSBh IHByZWZpeCBhIHByZWZpeCBvZiBpdHNlbGYuICBGb3INCiAgIGV4YW1wbGUsIHRoZSBQcmVm aXggImJlLUxhdG4iIChCZWxhcnVzaWFuLCBMYXRpbiBzY3JpcHQpIGNvdWxkIGJlDQogICBy ZXBsYWNlZCBieSB0aGUgUHJlZml4ICJiZSIgKEJlbGFydXNpYW4pIGJ1dCBub3QgYnkgdGhl IFByZWZpeCAicnUtDQogICBMYXRuIiAoUnVzc2lhbiwgTGF0aW4gc2NyaXB0KS4NCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAg ICAgICAgICAgIFtQYWdlIDI2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgUmVj b3JkcyBvZiB0eXBlICd2YXJpYW50JyBNQVkgaGF2ZSBtb3JlIHRoYW4gb25lIGZpZWxkIG9m IHR5cGUNCiAgICdQcmVmaXgnLiAgQWRkaXRpb25hbCBmaWVsZHMgb2YgdGhpcyB0eXBlIE1B WSBiZSBhZGRlZCB0byBhICd2YXJpYW50Jw0KICAgcmVjb3JkIHZpYSB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MuDQoNCiAgIFRoZSBmaWVsZC1ib2R5IG9mIHRoZSAnUHJlZml4JyBmaWVs ZCBNVVNUIE5PVCBjb25mbGljdCB3aXRoIGFueQ0KICAgJ1ByZWZpeCcgYWxyZWFkeSByZWdp c3RlcmVkIGZvciBhIGdpdmVuIHJlY29yZC4gIFN1Y2ggYSBjb25mbGljdA0KICAgd291bGQg b2NjdXIgd2hlbiB3aGVuIG5vIHZhbGlkIHRhZyBjb3VsZCBiZSBjb25zdHJ1Y3RlZCB0aGF0 IHdvdWxkDQogICBjb250YWluIHRoZSBwcmVmaXgsIHN1Y2ggYXMgd2hlbiB3aGVuIHR3byBz dWJ0YWdzIGVhY2ggaGF2ZSBhDQogICAnUHJlZml4JyB0aGF0IGNvbnRhaW5zIHRoZSBvdGhl ciBzdWJ0YWcuICBGb3IgZXhhbXBsZSwgc3VwcG9zZSB0aGF0DQogICB0aGUgc3VidGFnICdh dmFyaWFudCcgaGFzIHRoZSBwcmVmaXggImVzLWJ2YXJpYW50Ii4gIFRoZW4gdGhlIHN1YnRh Zw0KICAgJ2J2YXJpYW50JyBjYW5ub3QgZ2l2ZW4gdGhlIHByZWZpeCAnYXZhcmlhbnQnLCBm b3IgdGhhdCB3b3VsZCByZXF1aXJlDQogICBhIHRhZyBvZiB0aGUgZm9ybSAiZXMtYXZhcmlh bnQtYnZhcmlhbnQtYXZhcmlhbnQiLCB3aGljaCB3b3VsZCBub3QgYmUNCiAgIHZhbGlkLg0K DQogICBSZWNvcmRzIG9mIHR5cGUgJ2V4dGxhbmcnIE1VU1QgaGF2ZSBfZXhhY3RseV8gb25l ICdQcmVmaXgnIGZpZWxkLg0KDQozLjEuOC4gIFN1cHByZXNzLVNjcmlwdCBGaWVsZA0KDQog ICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgY29udGFpbnMgYSBzY3JpcHQgc3VidGFn ICh3aG9zZSByZWNvcmQNCiAgIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5KS4gIFRoZSBmaWVs ZCAnU3VwcHJlc3MtU2NyaXB0JyBNVVNUIG9ubHkNCiAgIGFwcGVhciBpbiByZWNvcmRzIHdo b3NlICdUeXBlJyBmaWVsZC1ib2R5IGlzICdsYW5ndWFnZScuICBUaGlzIGZpZWxkDQogICBN VVNUIE5PVCBhcHBlYXIgbW9yZSB0aGFuIG9uZSB0aW1lIGluIGEgcmVjb3JkLiAgVGhpcyBm aWVsZCBpbmRpY2F0ZXMNCiAgIGEgc2NyaXB0IHVzZWQgdG8gd3JpdGUgdGhlIG92ZXJ3aGVs bWluZyBtYWpvcml0eSBvZiBkb2N1bWVudHMgZm9yIHRoZQ0KICAgZ2l2ZW4gbGFuZ3VhZ2Uu ICBUaGlzIHNjcmlwdCBjb2RlIHRoZXJlZm9yZSBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQog ICBpbmZvcm1hdGlvbiB0byBhIGxhbmd1YWdlIHRhZy4gIFRoaXMgaGVscHMgZW5zdXJlIGdy ZWF0ZXINCiAgIGNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UgdGFncyBnZW5l cmF0ZWQgYWNjb3JkaW5nIHRvIHRoZQ0KICAgcnVsZXMgaW4gdGhpcyBkb2N1bWVudCBhbmQg bGFuZ3VhZ2UgdGFncyBhbmQgdGFnIHByb2Nlc3NvcnMgb3INCiAgIGNvbnN1bWVycyBiYXNl ZCBvbiBSRkMgMzA2NiBieSBpbmRpY2F0aW5nIHRoYXQgdGhlIHNjcmlwdCBzdWJ0YWcNCiAg IFNIT1VMRCBOT1QgYmUgdXNlZCBmb3IgbW9zdCBkb2N1bWVudHMgaW4gdGhhdCBsYW5ndWFn ZS4gIEZvciBleGFtcGxlLA0KICAgdmlydHVhbGx5IGFsbCBJY2VsYW5kaWMgZG9jdW1lbnRz IGFyZSB3cml0dGVuIGluIHRoZSBMYXRpbiBzY3JpcHQsDQogICBtYWtpbmcgdGhlIHN1YnRh ZyAnTGF0bicgcmVkdW5kYW50IGluIHRoZSB0YWcgImlzLUxhdG4iLg0KDQogICBNYW55IGxh bmd1YWdlIHN1YnRhZyByZWNvcmRzIGRvIG5vdCBoYXZlIGEgU3VwcHJlc3MtU2NyaXB0IGZp ZWxkLg0KICAgVGhlIGxhY2sgb2YgYSBTdXBwcmVzcy1TY3JpcHQgbWlnaHQgaW5kaWNhdGUg dGhhdCB0aGUgbGFuZ3VhZ2UgaXMNCiAgIGN1c3RvbWFyaWx5IHdyaXR0ZW4gaW4gbW9yZSB0 aGFuIG9uZSBzY3JpcHQgb3IgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMNCiAgIG5vdCBjdXN0b21h cmlseSB3cml0dGVuIGF0IGFsbC4gIEl0IG1pZ2h0IGFsc28gbWVhbiB0aGF0IHN1ZmZpY2ll bnQNCiAgIGluZm9ybWF0aW9uIHdhcyBub3QgYXZhaWxhYmxlIHdoZW4gdGhlIHJlY29yZCB3 YXMgY3JlYXRlZCBhbmQgdGh1cw0KICAgcmVtYWlucyBhIGNhbmRpZGF0ZSBmb3IgZnV0dXJl IHJlZ2lzdHJhdGlvbi4NCg0KMy4xLjkuICBNYWNyb2xhbmd1YWdlIEZpZWxkDQoNCiAgIFRo ZSBNYWNyb2xhbmd1YWdlIGZpZWxkIGNvbnRhaW5zIGEgcHJpbWFyeSBvciBleHRlbmRlZCBs YW5ndWFnZQ0KICAgc3VidGFnIHRoYXQgZW5jb21wYXNzZXMgdGhpcyBzdWJ0YWcncyBsYW5n dWFnZS4gIFRoYXQgaXMsIHRoZQ0KICAgbGFuZ3VhZ2Ugc3VidGFnIHdob3NlIHJlY29yZCB0 aGlzIGZpZWxkIGFwcGVhcnMgaW4gaXMgc29tZXRpbWVzDQogICBjb25zaWRlcmVkIHRvIGJl IGEgc3ViLWxhbmd1YWdlIG9mIHRoZSBNYWNyb2xhbmd1YWdlLiAgTWFjcm9sYW5ndWFnZQ0K ICAgdmFsdWVzIGFyZSBkZWZpbmVkIGJ5IElTTyA2MzktMyBhbmQgdGhlIGV4YWN0IG5hdHVy ZSBvZiB0aGUNCiAgIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBlbmNvbXBhc3NlZCBhbmQg ZW5jb21wYXNzaW5nIGxhbmd1YWdlcw0KICAgdmFyaWVzIG9uIGEgY2FzZS1ieS1jYXNlIGJh c2lzLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAy NSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcN Cg0KDQogICBUaGlzIGZpZWxkIGNhbiBiZSB1c2VmdWwgdG8gYXBwbGljYXRpb25zIG9yIHVz ZXJzIHdoZW4gc2VsZWN0aW5nDQogICBsYW5ndWFnZSB0YWdzIG9yIGFzIGFkZGl0aW9uYWwg bWV0YWRhdGEgdXNlZnVsIGluIG1hdGNoaW5nLiAgVGhlDQogICBNYWNyb2xhbmd1YWdlIGZp ZWxkIGNhbiBvbmx5IG9jY3VyIGluIHJlY29yZHMgb2YgdHlwZSAnbGFuZ3VhZ2UnIG9yDQog ICAnZXh0bGFuZycuICBPbmx5IHZhbHVlcyBhc3NpZ25lZCBieSBJU08gNjM5LTMgd2lsbCBi ZSBjb25zaWRlcmVkIGZvcg0KICAgaW5jbHVzaW9uLiAgTWFjcm9sYW5ndWFnZSBmaWVsZHMg TUFZIGJlIGFkZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgbm9ybWFsIHJlZ2lzdHJhdGlv biBwcm9jZXNzIHdoZW5ldmVyIElTTyA2MzktMyBkZWZpbmVzIG5ldyB2YWx1ZXMuDQogICBN YWNyb2xhbmd1YWdlcyBhcmUgaW5mb3JtYXRpb25hbCwgYW5kIE1BWSBiZSByZW1vdmVkIG9y IGNoYW5nZWQgaWYNCiAgIElTTyA2MzktMyBjaGFuZ2VzIHRoZSB2YWx1ZXMuDQoNCiAgIEZv ciBleGFtcGxlLCB0aGUgbGFuZ3VhZ2Ugc3VidGFncyAnbmInIChOb3J3ZWdpYW4gQm9rbWFs KSBhbmQgJ25uJw0KICAgKE5vcndlZ2lhbiBOeW5vcnNrKSBlYWNoIGhhdmUgYSBNYWNyb2xh bmd1YWdlIGVudHJ5IG9mICdubycNCiAgIChOb3J3ZWdpYW4pLiAgRm9yIG1vcmUgaW5mb3Jt YXRpb24gc2VlIFNlY3Rpb24gNC4xLg0KDQozLjEuMTAuICBDb21tZW50cyBGaWVsZA0KDQog ICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBjb252ZXlzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g YWJvdXQgdGhlIHJlY29yZA0KICAgYW5kIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVy IHJlY29yZC4gIFRoZSBmaWVsZC1ib2R5IE1BWSBpbmNsdWRlDQogICB0aGUgZnVsbCByYW5n ZSBvZiBVbmljb2RlIGNoYXJhY3RlcnMgYW5kIGlzIG5vdCByZXN0cmljdGVkIHRvIGFueQ0K ICAgcGFydGljdWxhciBzY3JpcHQuICBUaGlzIGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBj aGFuZ2VkIHZpYSB0aGUNCiAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGFuZCBubyBndWFyYW50 ZWUgb2Ygc3RhYmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhlDQogICBjb250ZW50IG9mIHRoaXMg ZmllbGQgaXMgbm90IHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0bw0KICAgcmVn aXN0ZXIgdGhlIGluZm9ybWF0aW9uLCB0aGUgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVlc3Qs IGFuZCBieQ0KICAgcmVhc29uYWJsZSBwcmFjdGljYWwgc2l6ZSBsaW1pdGF0aW9ucy4NCg0K My4yLiAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3ZXIgbW9kZXJhdGVzIHRoZSBpZXRmLWxhbmd1YWdlcyBtYWlsaW5nDQogICBs aXN0LCByZXNwb25kcyB0byByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uLCBhbmQgcGVyZm9y bXMgdGhlIG90aGVyDQogICByZWdpc3RyeSBtYWludGVuYW5jZSBkdXRpZXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gMy4zLiAgT25seSB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdl ciBpcyBwZXJtaXR0ZWQgdG8gcmVxdWVzdCBJQU5BIHRvIGNoYW5nZSwNCiAgIHVwZGF0ZSwg b3IgYWRkIHJlY29yZHMgdG8gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIFRoZSBM YW5ndWFnZQ0KICAgU3VidGFnIFJldmlld2VyIE1BWSBkZWxlZ2F0ZSBsaXN0IG1vZGVyYXRp b24gYW5kIG90aGVyIGNsZXJpY2FsDQogICBkdXRpZXMgYXMgbmVlZGVkLg0KDQogICBUaGUg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRyBmb3Ig YW4NCiAgIGluZGVmaW5pdGUgdGVybSwgc3ViamVjdCB0byByZW1vdmFsIG9yIHJlcGxhY2Vt ZW50IGF0IHRoZSBJRVNHJ3MNCiAgIGRpc2NyZXRpb24uICBUaGUgSUVTRyB3aWxsIHNvbGlj aXQgbm9taW5lZXMgZm9yIHRoZSBwb3NpdGlvbiAodXBvbg0KICAgYWRvcHRpb24gb2YgdGhp cyBkb2N1bWVudCBvciB1cG9uIGEgdmFjYW5jeSkgYW5kIHRoZW4gc29saWNpdA0KICAgZmVl ZGJhY2sgb24gdGhlIG5vbWluZWVzJyBxdWFsaWZpY2F0aW9ucy4gIFF1YWxpZmllZCBjYW5k aWRhdGVzDQogICBzaG91bGQgYmUgZmFtaWxpYXIgd2l0aCBCQ1AgNDcgYW5kIGl0cyByZXF1 aXJlbWVudHM7IGJlIHdpbGxpbmcgdG8NCiAgIGZhaXJseSwgcmVzcG9uc2l2ZWx5LCBhbmQg anVkaWNpb3VzbHkgYWRtaW5pc3RlciB0aGUgcmVnaXN0cmF0aW9uDQogICBwcm9jZXNzOyBh bmQgYmUgc3VpdGFibHkgaW5mb3JtZWQgYWJvdXQgdGhlIGlzc3VlcyBvZiBsYW5ndWFnZQ0K ICAgaWRlbnRpZmljYXRpb24gc28gdGhhdCB0aGV5IGNhbiBkcmF3IHVwb24gYW5kIGFzc2Vz cyB0aGUgY2xhaW0gYW5kDQogICBjb250cmlidXRpb25zIG9mIGxhbmd1YWdlIGV4cGVydHMg YW5kIHN1YnRhZyByZXF1ZXN0ZXJzLg0KDQogICBUaGUgc3Vic2VxdWVudCBwZXJmb3JtYW5j ZSBvciBkZWNpc2lvbnMgb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KICAgUmV2aWV3ZXIgTUFZ IGJlIGFwcGVhbGVkIHRvIHRoZSBJRVNHIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVy DQogICBJRVRGIGRlY2lzaW9ucyAoc2VlIFtSRkMyMDI2XSkuICBUaGUgSUVTRyBjYW4gcmV2 ZXJzZSBvciBvdmVydHVybiB0aGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgZGVjaXNpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRh ZyBSZXZpZXdlciwgcHJvdmlkZSBndWlkYW5jZSwgb3IgdGFrZQ0KICAgb3RoZXIgYXBwcm9w cmlhdGUgYWN0aW9ucy4NCg0KMy4zLiAgTWFpbnRlbmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5DQoN CiAgIE1haW50ZW5hbmNlIG9mIHRoZSByZWdpc3RyeSByZXF1aXJlcyB0aGF0IGFzIGNvZGVz IGFyZSBhc3NpZ25lZCBvcg0KICAgd2l0aGRyYXduIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg SVNPIDMxNjYsIGFuZCBVTiBNLjQ5LCB0aGUgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBSZXZpZXdl ciBNVVNUIGV2YWx1YXRlIGVhY2ggY2hhbmdlIGFuZCBkZXRlcm1pbmUgdGhlDQogICBhcHBy b3ByaWF0ZSBjb3Vyc2Ugb2YgYWN0aW9uIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gdGhp cyBkb2N1bWVudC4NCiAgIFN1Y2ggdXBkYXRlcyBmb2xsb3cgdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZXNzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjUuICBVc3VhbGx5IHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmV2aWV3ZXIgd2lsbCBzdGFydCB0aGUNCiAgIHByb2Nlc3MgZm9yIHRo ZSBuZXcgb3IgdXBkYXRlZCByZWNvcmQgYnkgZmlsbGluZyBpbiB0aGUgcmVnaXN0cmF0aW9u DQogICBmb3JtIGFuZCBzdWJtaXR0aW5nIGl0LiAgSWYgYSBjaGFuZ2UgdG8gb25lIG9mIHRo ZXNlIHN0YW5kYXJkcyB0YWtlcw0KICAgcGxhY2UgYW5kIHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgZG9lcyBub3QgZG8gdGhpcyBpbiBhIHRpbWVseQ0KICAgbWFubmVyLCB0aGVu IGFueSBpbnRlcmVzdGVkIHBhcnR5IE1BWSBzdWJtaXQgdGhlIGZvcm0uICBUaGVyZWFmdGVy DQogICB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgY29udGludWVzIG5vcm1hbGx5Lg0KDQog ICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgZW5zdXJlIHRoYXQgbmV3IHN1 YnRhZ3MgbWVldCB0aGUNCiAgIHJlcXVpcmVtZW50cyBlbHNld2hlcmUgaW4gdGhpcyBkb2N1 bWVudCAoYW5kIG1vc3QgZXNwZWNpYWxseSBpbg0KICAgU2VjdGlvbiAzLjQpIG9yIHN1Ym1p dCBhbiBhcHByb3ByaWF0ZSByZWdpc3RyYXRpb24gZm9ybSBmb3IgYW4NCiAgIGFsdGVybmF0 ZSBzdWJ0YWcgYXMgZGVzY3JpYmVkIGluIHRoYXQgc2VjdGlvbi4gIEVhY2ggaW5kaXZpZHVh bA0KICAgc3VidGFnIGFmZmVjdGVkIGJ5IGEgY2hhbmdlIE1VU1QgYmUgc2VudCB0byB0aGUg aWV0Zi1sYW5ndWFnZXMgbGlzdA0KICAgd2l0aCBpdHMgb3duIHJlZ2lzdHJhdGlvbiBmb3Jt IGFuZCBpbiBhIHNlcGFyYXRlIG1lc3NhZ2UuDQoNCjMuNC4gIFN0YWJpbGl0eSBvZiBJQU5B IFJlZ2lzdHJ5IEVudHJpZXMNCg0KICAgVGhlIHN0YWJpbGl0eSBvZiBlbnRyaWVzIGFuZCB0 aGVpciBtZWFuaW5nIGluIHRoZSByZWdpc3RyeSBpcw0KICAgY3JpdGljYWwgdG8gdGhlIGxv bmctdGVybSBzdGFiaWxpdHkgb2YgbGFuZ3VhZ2UgdGFncy4gIFRoZSBydWxlcyBpbg0KICAg dGhpcyBzZWN0aW9uIGd1YXJhbnRlZSB0aGF0IGEgc3BlY2lmaWMgbGFuZ3VhZ2UgdGFnJ3Mg bWVhbmluZyBpcw0KICAgc3RhYmxlIG92ZXIgdGltZSBhbmQgd2lsbCBub3QgY2hhbmdlLg0K DQogICBUaGVzZSBydWxlcyBzcGVjaWZpY2FsbHkgZGVhbCB3aXRoIGhvdyBjaGFuZ2VzIHRv IGNvZGVzIChpbmNsdWRpbmcNCiAgIHdpdGhkcmF3YWwgYW5kIGRlcHJlY2F0aW9uIG9mIGNv ZGVzKSBtYWludGFpbmVkIGJ5IElTTyA2MzksIElTTw0KICAgMTU5MjQsIElTTyAzMTY2LCBh bmQgVU4gTS40OSBhcmUgcmVmbGVjdGVkIGluIHRoZSBJQU5BIExhbmd1YWdlDQogICBTdWJ0 YWcgUmVnaXN0cnkuICBBc3NpZ25tZW50cyB0byB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcg UmVnaXN0cnkNCiAgIE1VU1QgZm9sbG93IHRoZSBmb2xsb3dpbmcgc3RhYmlsaXR5IHJ1bGVz Og0KDQogICAxLiAgIFZhbHVlcyBpbiB0aGUgZmllbGRzICdUeXBlJywgJ1N1YnRhZycsICdU YWcnLCAnQWRkZWQnLA0KICAgICAgICAnRGVwcmVjYXRlZCcgYW5kICdQcmVmZXJyZWQtVmFs dWUnIE1VU1QgTk9UIGJlIGNoYW5nZWQgYW5kIGFyZQ0KICAgICAgICBndWFyYW50ZWVkIHRv IGJlIHN0YWJsZSBvdmVyIHRpbWUuDQoNCiAgIDIuICAgVmFsdWVzIGluIHRoZSAnRGVzY3Jp cHRpb24nIGZpZWxkIE1VU1QgTk9UIGJlIGNoYW5nZWQgaW4gYSB3YXkNCiAgICAgICAgdGhh dCB3b3VsZCBpbnZhbGlkYXRlIHByZXZpb3VzbHktZXhpc3RpbmcgdGFncy4gIFRoZXkgTUFZ IGJlDQogICAgICAgIGJyb2FkZW5lZCBzb21ld2hhdCBpbiBzY29wZSwgY2hhbmdlZCB0byBh ZGQgaW5mb3JtYXRpb24sIG9yDQogICAgICAgIGFkYXB0ZWQgdG8gdGhlIG1vc3QgY29tbW9u IG1vZGVybiB1c2FnZS4gIEZvciBleGFtcGxlLCBjb3VudHJpZXMNCiAgICAgICAgb2NjYXNp b25hbGx5IGNoYW5nZSB0aGVpciBvZmZpY2lhbCBuYW1lczsgYSBoaXN0b3JpY2FsIGV4YW1w bGUNCiAgICAgICAgb2YgdGhpcyB3b3VsZCBiZSAiVXBwZXIgVm9sdGEiIGNoYW5naW5nIHRv ICJCdXJraW5hIEZhc28iLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNw0KDQoNCiAgIDMuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4 JyBNQVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBvZiB0eXBlDQogICAgICAgICd2YXJpYW50JyB2 aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgSWYgYSBwcmVmaXggaXMgYWRkZWQgdG8N CiAgICAgICAgYSB2YXJpYW50IHJlY29yZCwgJ0NvbW1lbnQnIGZpZWxkcyBTSE9VTEQgYmUg dXNlZCB0byBleHBsYWluDQogICAgICAgIGRpZmZlcmVudCB1c2FnZXMgd2l0aCB0aGUgdmFy aW91cyBwcmVmaXhlcy4NCg0KICAgNC4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdQcmVmaXgn IGluIHJlY29yZHMgb2YgdHlwZSAndmFyaWFudCcgTUFZIGJlDQogICAgICAgIG1vZGlmaWVk LCBzbyBsb25nIGFzIHRoZSBtb2RpZmljYXRpb25zIGJyb2FkZW4gdGhlIHNldCBvZg0KICAg ICAgICBwcmVmaXhlcy4gIFRoYXQgaXMsIGEgcHJlZml4IE1BWSBiZSByZXBsYWNlZCBieSBv bmUgb2YgaXRzIG93bg0KICAgICAgICBwcmVmaXhlcy4gIEZvciBleGFtcGxlLCB0aGUgcHJl Zml4ICJlbi1VUyIgY291bGQgYmUgcmVwbGFjZWQgYnkNCiAgICAgICAgImVuIiwgYnV0IG5v dCBieSB0aGUgcHJlZml4ZXMgImVuLUxhdG4iLCAiZnIiLCBvciAiZW4tVVMtYm9vbnQiLg0K ICAgICAgICBJZiBvbmUgb2YgdGhvc2UgcHJlZml4ZXMgd2VyZSBuZWVkZWQsIGEgbmV3IFBy ZWZpeCBTSE9VTEQgYmUNCiAgICAgICAgcmVnaXN0ZXJlZC4NCg0KICAgNS4gICBWYWx1ZXMg aW4gdGhlIGZpZWxkICdQcmVmaXgnIGluIHJlY29yZHMgb2YgdHlwZSAnZXh0bGFuZycgTVVT VA0KICAgICAgICBOT1QgYmUgbW9kaWZpZWQuDQoNCiAgIDYuICAgVmFsdWVzIGluIHRoZSBm aWVsZCAnUHJlZml4JyBNVVNUIE5PVCBiZSByZW1vdmVkLg0KDQogICA3LiAgIFRoZSBmaWVs ZCAnQ29tbWVudHMnIE1BWSBiZSBhZGRlZCwgY2hhbmdlZCwgbW9kaWZpZWQsIG9yIHJlbW92 ZWQNCiAgICAgICAgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvciBhbnkgb2YgdGhl IHByb2Nlc3NlcyBvcg0KICAgICAgICBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhp cyBzZWN0aW9uLg0KDQogICA4LiAgIFRoZSBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBNQVkg YmUgYWRkZWQgb3IgcmVtb3ZlZCB2aWEgdGhlDQogICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzLg0KDQogICA5LiAgIFRoZSBmaWVsZCAnTWFjcm9sYW5ndWFnZScgTUFZIGJlIGFkZGVk IG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgICByZWdpc3RyYXRpb24gcHJvY2VzcywgYnV0 IG9ubHkgaW4gcmVzcG9uc2UgdG8gY2hhbmdlcyBtYWRlIGJ5DQogICAgICAgIElTTyA2Mzku ICBUaGUgTWFjcm9sYW5ndWFnZSBmaWVsZCBhcHBlYXJzIHdoZW5ldmVyIGEgbGFuZ3VhZ2UN CiAgICAgICAgaGFzIGEgY29ycmVzcG9uZGluZyBNYWNyb2xhbmd1YWdlIGluIElTTyA2Mzku ICBUaGF0IGlzLCB0aGUNCiAgICAgICAgbWFjcm9sYW5ndWFnZSBmaWVsZHMgaW4gdGhlIHJl Z2lzdHJ5IGV4YWN0bHkgbWF0Y2ggdGhvc2Ugb2YgSVNPDQogICAgICAgIDYzOS4gIE5vIG90 aGVyIG1hY3JvbGFuZ3VhZ2UgbWFwcGluZ3Mgd2lsbCBiZSBjb25zaWRlcmVkIGZvcg0KICAg ICAgICByZWdpc3RyYXRpb24uDQoNCiAgIDEwLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYz OS0xIHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAgdHdvLWxl dHRlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgYW5kIHdoaWNoIGhhdmUgbm8NCiAgICAg ICAgY29ycmVzcG9uZGluZyB0aHJlZS1sZXR0ZXIgcHJpbWFyeSBvciBleHRlbmRlZCBsYW5n dWFnZSBzdWJ0YWdzDQogICAgICAgIGRlZmluZWQgaW4gdGhlIHJlZ2lzdHJ5IGFyZSBlbnRl cmVkIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMNCiAgICAgICAgbmV3IHJlY29yZHMgb2Yg dHlwZSAnbGFuZ3VhZ2UnLg0KDQogICAxMS4gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2Mzkt MiB0aGF0IGRvIG5vdCBjb25mbGljdCB3aXRoIGV4aXN0aW5nDQogICAgICAgIHRocmVlLWxl dHRlciBwcmltYXJ5IG9yIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgYXJlIGVudGVyZWQN CiAgICAgICAgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3JkcyBvZiB0eXBl ICdsYW5ndWFnZScuDQoNCiAgIDEyLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOS0zIHRo YXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAgdGhyZWUtbGV0dGVy IHByaW1hcnkgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgZW50ZXJlZA0KICAg ICAgICBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzLg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAg ICAgICAgICAgIFtQYWdlIDMwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgICAg ICAxLiAgQ29kZXMgdGhhdCBoYXZlIGEgZGVmaW5lZCAibWFjcm9sYW5ndWFnZSIgbWFwcGlu ZyBhdCB0aGUNCiAgICAgICAgICAgIHRpbWUgb2YgdGhlaXIgcmVnaXN0cmF0aW9uIE1VU1Qg YmUgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeQ0KICAgICAgICAgICAgYXMgcmVjb3JkcyBv ZiB0eXBlICdleHRsYW5nJyB3aXRoIGEgJ1ByZWZpeCcgZmllbGQNCiAgICAgICAgICAgIGNv bnRhaW5pbmcgdGhlIGFwcHJvcHJpYXRlIHByZWZpeCB0YWcuICBUaGV5IE1VU1QgYWxzbw0K ICAgICAgICAgICAgaW5jbHVkZSBhICJNYWNyb2xhbmd1YWdlIiBmaWVsZCBpbiB0aGVpciBy ZWNvcmQuDQoNCiAgICAgICAgMi4gIENvZGVzIHRoYXQgcmVwcmVzZW50IHNpZ24gbGFuZ3Vh Z2VzIE1VU1QgYmUgZW50ZXJlZCBpbnRvIHRoZQ0KICAgICAgICAgICAgcmVnaXN0cnkgYXMg cmVjb3JkIG9mIHR5cGUgJ2V4dGxhbmcnIHdpdGggYSAnUHJlZml4JyBmaWVsZA0KICAgICAg ICAgICAgdGhhdCBtYXRjaGVzIHRoZSBCYXNpYyBMYW5ndWFnZSBSYW5nZSAic2duIiAoc2Vl IFNlY3Rpb24NCiAgICAgICAgICAgIDMuMy4xICJCYXNpYyBGaWx0ZXJpbmciIGluIFtSRkM0 NjQ3XSkuDQoNCiAgICAgICAgMy4gIEFsbCBvdGhlciBjb2RlcyBNVVNUIGJlIGVudGVyZWQg aW50byB0aGUgcmVnaXN0cnkgYXMgcmVjb3Jkcw0KICAgICAgICAgICAgb2YgdHlwZSAnbGFu Z3VhZ2UnLg0KDQogICAxMy4gIEEgcmVjb3JkIG9mIHR5cGUgJ2xhbmd1YWdlJyBvciAnZXh0 bGFuZycgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZA0KICAgICAgICBpZiB0aGVyZSBleGlzdHMg YSByZWNvcmQgb2YgZWl0aGVyIHR5cGUgd2l0aCB0aGUgc2FtZSBzdWJ0YWcNCiAgICAgICAg dmFsdWUuICBGb3IgZXhhbXBsZSwgaWYgYW4gJ2V4dGxhbmcnIHN1YnRhZyAnZm9vJyBleGlz dHMgaW4gdGhlDQogICAgICAgIHJlZ2lzdHJ5LCBhbGwgYXR0ZW1wdHMgdG8gcmVnaXN0ZXIg YSAnbGFuZ3VhZ2UnIHN1YnRhZyAnZm9vJw0KICAgICAgICB3aWxsIGJlIHJlamVjdGVkLg0K DQogICAxNC4gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyAxNTkyNCBhbmQgSVNPIDMxNjYgdGhh dCBkbyBub3QgY29uZmxpY3QNCiAgICAgICAgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRo ZSBhc3NvY2lhdGVkIHR5cGUgYW5kIHdob3NlIG1lYW5pbmcNCiAgICAgICAgaXMgbm90IHRo ZSBzYW1lIGFzIGFuIGV4aXN0aW5nIHN1YnRhZyBvZiB0aGUgc2FtZSB0eXBlIGFyZQ0KICAg ICAgICBlbnRlcmVkIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29yZHMuDQoN CiAgIDE1LiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08g MzE2NiB0aGF0IGFyZQ0KICAgICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVzcGVjdGl2ZSBt YWludGVuYW5jZSBvciByZWdpc3RyYXRpb24NCiAgICAgICAgYXV0aG9yaXR5IHJlbWFpbiB2 YWxpZCBpbiBsYW5ndWFnZSB0YWdzLiAgQSAnRGVwcmVjYXRlZCcgZmllbGQNCiAgICAgICAg Y29udGFpbmluZyB0aGUgZGF0ZSBvZiB3aXRoZHJhd2FsIE1VU1QgYmUgYWRkZWQgdG8gdGhl IHJlY29yZC4NCiAgICAgICAgSWYgYSBuZXcgcmVjb3JkIG9mIHRoZSBzYW1lIHR5cGUgaXMg YWRkZWQgdGhhdCByZXByZXNlbnRzIGENCiAgICAgICAgcmVwbGFjZW1lbnQgdmFsdWUsIHRo ZW4gYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBNQVkgYWxzbyBiZQ0KICAgICAgICBhZGRl ZC4gIFRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBNQVkgYmUgdXNlZCB0byBhZGQgY29tbWVu dHMNCiAgICAgICAgYWJvdXQgdGhlIHdpdGhkcmF3YWwgb2YgdGhlIGNvZGUgYnkgdGhlIHJl c3BlY3RpdmUgc3RhbmRhcmQuDQoNCiAgICAgICAgRXhhbXBsZSAgVGhlIHJlZ2lvbiBjb2Rl ICdUTCcgd2FzIGFzc2lnbmVkIHRvIHRoZSBjb3VudHJ5DQogICAgICAgICAgICdUaW1vci1M ZXN0ZScsIHJlcGxhY2luZyB0aGUgY29kZSAnVFAnICh3aGljaCB3YXMgYXNzaWduZWQgdG8N CiAgICAgICAgICAgJ0Vhc3QgVGltb3InIHdoZW4gaXQgd2FzIHVuZGVyIGFkbWluaXN0cmF0 aW9uIGJ5IFBvcnR1Z2FsKS4NCiAgICAgICAgICAgVGhlIHN1YnRhZyAnVFAnIHJlbWFpbnMg dmFsaWQgaW4gbGFuZ3VhZ2UgdGFncywgYnV0IGl0cw0KICAgICAgICAgICByZWNvcmQgY29u dGFpbnMgdGhlIGEgJ1ByZWZlcnJlZC1WYWx1ZScgb2YgJ1RMJyBhbmQgaXRzIGZpZWxkDQog ICAgICAgICAgICdEZXByZWNhdGVkJyBjb250YWlucyB0aGUgZGF0ZSB0aGUgbmV3IGNvZGUg d2FzIGFzc2lnbmVkDQogICAgICAgICAgICgnMjAwNC0wNy0wNicpLg0KDQogICAxNi4gIENv ZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBj b25mbGljdA0KICAgICAgICB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0 ZWQgdHlwZSwgaW5jbHVkaW5nIHN1YnRhZ3MNCiAgICAgICAgdGhhdCBhcmUgZGVwcmVjYXRl ZCwgTVVTVCBOT1QgYmUgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeS4gIFRoZQ0KICAgICAg ICBmb2xsb3dpbmcgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBhcHBseSB0byBzdWJ0YWcg dmFsdWVzIHRoYXQNCiAgICAgICAgYXJlIHJlYXNzaWduZWQ6DQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAg IFtQYWdlIDMxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgICAgICBBLiAgRm9y IElTTyA2MzkgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBp cw0KICAgICAgICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5B IHJlZ2lzdHJ5LCB0aGUNCiAgICAgICAgICAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LCBTSEFMTA0KICAgICAgICAgICAgcHJlcGFy ZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBzb29u DQogICAgICAgICAgICBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRh ZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAgICAgICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUu ICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJlZCBsYW5ndWFnZQ0KICAgICAgICAgICAgc3Vi dGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0K ICAgICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlciByZXN0cmlj dGlvbnMgb24gbGFuZ3VhZ2UNCiAgICAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVu dC4NCg0KICAgICAgICBCLiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVy aXZlZCBmcm9tIGFuIGV4dGVybmFsDQogICAgICAgICAgICBzdGFuZGFyZCAodGhhdCBpcywg YnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2Niwgb3IgVU4NCiAgICAgICAgICAgIE0u NDkpLCBpZiBhIG5ldyBtZWFuaW5nIGlzIGFzc2lnbmVkIHRvIGFuIGV4aXN0aW5nIGNvZGUg YW5kDQogICAgICAgICAgICB0aGUgbmV3IG1lYW5pbmcgYnJvYWRlbnMgdGhlIG1lYW5pbmcg b2YgdGhhdCBjb2RlLCB0aGVuIHRoZQ0KICAgICAgICAgICAgbWVhbmluZyBmb3IgdGhlIGFz c29jaWF0ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1hdGNoLg0KICAgICAgICAgICAg VGhlIG1lYW5pbmcgb2YgYSBzdWJ0YWcgTVVTVCBOT1QgYmUgbmFycm93ZWQsIGhvd2V2ZXIs IGFzDQogICAgICAgICAgICB0aGlzIGNhbiByZXN1bHQgaW4gYW4gdW5rbm93biBwcm9wb3J0 aW9uIG9mIHRoZSBleGlzdGluZw0KICAgICAgICAgICAgdXNlcyBvZiBhIHN1YnRhZyBiZWNv bWluZyBpbnZhbGlkLiAgTm90ZTogSVNPIDYzOQ0KICAgICAgICAgICAgbWFpbnRlbmFuY2Ug YWdlbmN5L3JlZ2lzdHJhdGlvbiBhdXRob3JpdHkgKE1BL1JBKSBoYXMNCiAgICAgICAgICAg IGFkb3B0ZWQgYSBzaW1pbGFyIHN0YWJpbGl0eSBwb2xpY3kuDQoNCiAgICAgICAgQy4gIEZv ciBJU08gMTU5MjQgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmlu ZyBpcw0KICAgICAgICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJ QU5BIHJlZ2lzdHJ5LCB0aGUNCiAgICAgICAgICAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdl ciwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LCBTSEFMTA0KICAgICAgICAgICAgcHJl cGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBz b29uDQogICAgICAgICAgICBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQgc3Vi dGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBuZXcgY29k ZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQNCiAgICAgICAgICAgIHN1 YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcN CiAgICAgICAgICAgIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJp Y3Rpb25zIG9uIHZhcmlhbnQNCiAgICAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVu dC4NCg0KICAgICAgICBELiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNz aWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0 aGUgc2FtZSBVTiBNLjQ5IGNvZGUgYXMgYW5vdGhlciAncmVnaW9uJw0KICAgICAgICAgICAg c3VidGFnLCB0aGVuIHRoZSBleGlzdGluZyByZWdpb24gc3VidGFnIHJlbWFpbnMgYXMgdGhl DQogICAgICAgICAgICBwcmVmZXJyZWQgdmFsdWUgZm9yIHRoYXQgcmVnaW9uIGFuZCBubyBu ZXcgZW50cnkgaXMgY3JlYXRlZC4NCiAgICAgICAgICAgIEEgY29tbWVudCBNQVkgYmUgYWRk ZWQgdG8gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcNCiAgICAgICAgICAgIGluZGljYXRp bmcgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgbmV3IElTTyAzMTY2IGNvZGUuDQoNCiAgICAg ICAgRS4gIEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUn cyBtZWFuaW5nIGlzDQogICAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggYSBVTiBNLjQ5IGNv ZGUgdGhhdCBpcyBub3QgcmVwcmVzZW50ZWQgYnkgYW4NCiAgICAgICAgICAgIGV4aXN0aW5n IHJlZ2lvbiBzdWJ0YWcsIHRoZW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwNCiAg ICAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNSwgU0hBTEwgcHJlcGFyZSBh IHByb3Bvc2FsIGZvcg0KICAgICAgICAgICAgZW50ZXJpbmcgdGhlIGFwcHJvcHJpYXRlIFVO IE0uNDkgY291bnRyeSBjb2RlIGFzIGFuIGVudHJ5IGluDQogICAgICAgICAgICB0aGUgSUFO QSByZWdpc3RyeS4NCg0KICAgICAgICBGLiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGVy ZSBpcyBubyBhc3NvY2lhdGVkIFVOIG51bWVyaWMNCiAgICAgICAgICAgIGNvZGUsIHRoZW4g dGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwZXRpdGlvbiB0aGUNCiAgICAg ICAgICAgIFVOIHRvIGNyZWF0ZSBvbmUuICBJZiB0aGVyZSBpcyBubyByZXNwb25zZSBmcm9t IHRoZSBVTg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMzJdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDcNCg0KDQogICAgICAgICAgICB3aXRoaW4gbmluZXR5IGRheXMgb2YgdGhlIHJlcXVlc3Qg YmVpbmcgc2VudCwgdGhlIExhbmd1YWdlDQogICAgICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIg U0hBTEwgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUNCiAgICAgICAg ICAgIElBTkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZh cmlhbnQNCiAgICAgICAgICAgIHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRo ZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mDQogICAgICAgICAgICB0aGUgcmVnaXN0ZXJlZCB2 YXJpYW50IHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mDQogICAgICAgICAg ICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8gb3Ro ZXINCiAgICAgICAgICAgIHJlc3RyaWN0aW9ucyBvbiB2YXJpYW50IHN1YnRhZ3MgaW4gdGhp cyBkb2N1bWVudC4gIFRoaXMNCiAgICAgICAgICAgIHNpdHVhdGlvbiBpcyB2ZXJ5IHVubGlr ZWx5IHRvIGV2ZXIgb2NjdXIuDQoNCiAgIDE3LiAgVU4gTS40OSBoYXMgY29kZXMgZm9yIGJv dGggY291bnRyaWVzIGFuZCBhcmVhcyAoc3VjaCBhcyAnMjc2Jw0KICAgICAgICBmb3IgR2Vy bWFueSkgYW5kIGdlb2dyYXBoaWNhbCByZWdpb25zIGFuZCBzdWItcmVnaW9ucyAoc3VjaCBh cw0KICAgICAgICAnMTUwJyBmb3IgRXVyb3BlKS4gIFVOIE0uNDkgY291bnRyeSBvciBhcmVh IGNvZGVzIGZvciB3aGljaA0KICAgICAgICB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nIElT TyAzMTY2IGNvZGUgU0hPVUxEIE5PVCBiZQ0KICAgICAgICByZWdpc3RlcmVkLCBleGNlcHQg YXMgYSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2IGNvZGUgdGhhdCBpcw0KICAgICAgICBi bG9ja2VkIGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4gIElmIHN1 Y2ggYSBjb2RlDQogICAgICAgIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuIHRoZSByZWdpc3Ry YXRpb24gYXV0aG9yaXR5IGZvciBJU08gMzE2Ng0KICAgICAgICBTSE9VTEQgZmlyc3QgYmUg cGV0aXRpb25lZCB0byBhc3NpZ24gYSBjb2RlIHRvIHRoZSByZWdpb24uICBJZg0KICAgICAg ICB0aGUgcGV0aXRpb24gZm9yIGEgY29kZSBhc3NpZ25tZW50IGJ5IElTTyAzMTY2IGlzIHJl ZnVzZWQgb3Igbm90DQogICAgICAgIGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhl IHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlc2NyaWJlZA0KICAgICAgICBpbiBTZWN0aW9uIDMu NSBNQVkgdGhlbiBiZSB1c2VkIHRvIHJlZ2lzdGVyIHRoZSBjb3JyZXNwb25kaW5nIFVODQog ICAgICAgIE0uNDkgY29kZS4gIFRoaXMgd2F5LCBVTiBNLjQ5IGNvZGVzIHJlbWFpbiBhdmFp bGFibGUgYXMgdGhlDQogICAgICAgIHZhbHVlIG9mIGxhc3QgcmVzb3J0IGluIGNhc2VzIHdo ZXJlIElTTyAzMTY2IHJlYXNzaWducyBhDQogICAgICAgIGRlcHJlY2F0ZWQgdmFsdWUgaW4g dGhlIHJlZ2lzdHJ5Lg0KDQogICAxOC4gIFN0YWJpbGl0eSBwcm92aXNpb25zIGFwcGx5IHRv IGdyYW5kZmF0aGVyZWQgdGFncyB3aXRoIHRoaXMNCiAgICAgICAgZXhjZXB0aW9uOiBzaG91 bGQgaXQgYmUgcG9zc2libGUgdG8gY29tcG9zZSBvbmUgb2YgdGhlDQogICAgICAgIGdyYW5k ZmF0aGVyZWQgdGFncyBmcm9tIHJlZ2lzdGVyZWQgc3VidGFncywgdGhlbiB0aGUgZmllbGQN CiAgICAgICAgJ1R5cGUnIGluIHRoYXQgcmVjb3JkIGlzIGNoYW5nZWQgZnJvbSAnZ3JhbmRm YXRoZXJlZCcgdG8NCiAgICAgICAgJ3JlZHVuZGFudCcuICBOb3RlIHRoYXQgdGhpcyB3aWxs IG5vdCBhZmZlY3QgbGFuZ3VhZ2UgdGFncyB0aGF0DQogICAgICAgIG1hdGNoIHRoZSBncmFu ZGZhdGhlcmVkIHRhZywgc2luY2UgdGhlc2UgdGFncyB3aWxsIG5vdyBtYXRjaA0KICAgICAg ICB2YWxpZCBnZW5lcmF0aXZlIHN1YnRhZyBzZXF1ZW5jZXMuICBGb3IgZXhhbXBsZSwgdGhp cyBkb2N1bWVudA0KICAgICAgICBjYXVzZWQgdGhlIElTTyA2MzktMyBjb2RlICdnYW4nLCB1 c2VkIGluIHRoZSByZWR1bmRhbnQgdGFnICJ6aC0NCiAgICAgICAgZ2FuIiwgdG8gYmUgcmVn aXN0ZXJlZCBhcyBhbiBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuICBUaGUNCiAgICAgICAg Zm9ybWVybHktZ3JhbmRmYXRoZXJlZCB0YWcgInpoLWdhbiIgYmVjYW1lIGEgcmVkdW5kYW50 IHRhZyBhcyBhDQogICAgICAgIHJlc3VsdCAoYnV0IGV4aXN0aW5nIGNvbnRlbnQgb3IgaW1w bGVtZW50YXRpb25zIHRoYXQgdXNlICJ6aC0NCiAgICAgICAgZ2FuIiByZW1haW4gdmFsaWQp Lg0KDQogICBOb3RlOiBUaGUgcmVkdW5kYW50IGFuZCBncmFuZGZhdGhlcmVkIGVudHJpZXMg dG9nZXRoZXIgYXJlIHRoZQ0KICAgY29tcGxldGUgbGlzdCBvZiB0YWdzIHJlZ2lzdGVyZWQg dW5kZXIgW1JGQzMwNjZdLiAgVGhlIHJlZHVuZGFudCB0YWdzDQogICBhcmUgdGhvc2UgdGhh dCBjYW4gbm93IGJlIGZvcm1lZCB1c2luZyB0aGUgc3VidGFncyBkZWZpbmVkIGluIHRoZQ0K ICAgcmVnaXN0cnkgdG9nZXRoZXIgd2l0aCB0aGUgcnVsZXMgb2YgU2VjdGlvbiAyLjIuICBU aGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50cmllcyBpbmNsdWRlIHRob3NlIHRoYXQgY2FuIG5l dmVyIGJlIGxlZ2FsIHVuZGVyIHRob3NlIHNhbWUNCiAgIHByb3Zpc2lvbnMgcGx1cyB0aG9z ZSB0YWdzIHRoYXQgY29udGFpbiBzdWJ0YWdzIG5vdCB5ZXQgcmVnaXN0ZXJlZA0KICAgb3Is IHBlcmhhcHMsIGluYXBwcm9wcmlhdGUgZm9yIHJlZ2lzdHJhdGlvbi4NCg0KICAgVGhlIHNl dCBvZiByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQgdGFncyBpcyBwZXJtYW5lbnQgYW5k IHN0YWJsZToNCiAgIG5ldyBlbnRyaWVzIGluIHRoaXMgc2VjdGlvbiBNVVNUIE5PVCBiZSBh ZGRlZCBhbmQgZXhpc3RpbmcgZW50cmllcw0KICAgTVVTVCBOT1QgYmUgcmVtb3ZlZC4gIFJl Y29yZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgTUFZIGhhdmUgdGhlaXINCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAg ICAgICAgIFtQYWdlIDMzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgdHlwZSBj b252ZXJ0ZWQgdG8gJ3JlZHVuZGFudCc7IHNlZSBpdGVtIDEyIGluIFNlY3Rpb24gMy42IGZv ciBtb3JlDQogICBpbmZvcm1hdGlvbi4gIFRoZSBkZWNpc2lvbi1tYWtpbmcgcHJvY2VzcyBh Ym91dCB3aGljaCB0YWdzIHdlcmUNCiAgIGluaXRpYWxseSBncmFuZGZhdGhlcmVkIGFuZCB3 aGljaCB3ZXJlIG1hZGUgcmVkdW5kYW50IGlzIGRlc2NyaWJlZCBpbg0KICAgW1JGQzQ2NDVd Lg0KDQogICBSRkMgMzA2NiB0YWdzIHRoYXQgd2VyZSBkZXByZWNhdGVkIHByaW9yIHRvIHRo ZSBhZG9wdGlvbiBvZiBbUkZDNDY0Nl0NCiAgIGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdy YW5kZmF0aGVyZWQgdGFncywgYW5kIHRoZWlyIGNvbXBvbmVudA0KICAgc3VidGFncyB3ZXJl IG5vdCBpbmNsdWRlZCBhcyByZWdpc3RlcmVkIHZhcmlhbnRzIChhbHRob3VnaCB0aGV5DQog ICByZW1haW4gZWxpZ2libGUgZm9yIHJlZ2lzdHJhdGlvbikuICBGb3IgZXhhbXBsZSwgdGhl IHRhZyAiYXJ0LWxvamJhbiINCiAgIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBs YW5ndWFnZSBzdWJ0YWcgJ2pibycuDQoNCjMuNS4gIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUg Zm9yIFN1YnRhZ3MNCg0KICAgVGhlIHByb2NlZHVyZSBnaXZlbiBoZXJlIE1VU1QgYmUgdXNl ZCBieSBhbnlvbmUgd2hvIHdhbnRzIHRvIHVzZSBhDQogICBzdWJ0YWcgbm90IGN1cnJlbnRs eSBpbiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuDQoNCiAgIE9ubHkgc3Vi dGFncyBvZiB0eXBlICdsYW5ndWFnZScgYW5kICd2YXJpYW50JyB3aWxsIGJlIGNvbnNpZGVy ZWQgZm9yDQogICBpbmRlcGVuZGVudCByZWdpc3RyYXRpb24gb2YgbmV3IHN1YnRhZ3MuICBT dWJ0YWdzIG5lZWRlZCBmb3INCiAgIHN0YWJpbGl0eSBhbmQgc3VidGFncyBuZWNlc3Nhcnkg dG8ga2VlcCB0aGUgcmVnaXN0cnkgc3luY2hyb25pemVkDQogICB3aXRoIElTTyA2MzksIElT TyAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IHdpdGhpbiB0aGUgbGltaXRzDQogICBk ZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYWxzbyB1c2UgdGhpcyBwcm9jZXNzLCBhcyBkZXNj cmliZWQgaW4NCiAgIFNlY3Rpb24gMy4zLiAgU3RhYmlsaXR5IHByb3Zpc2lvbnMgYXJlIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4NCg0KICAgVGhpcyBwcm9jZWR1cmUgTUFZIGFsc28g YmUgdXNlZCB0byByZWdpc3RlciBvciBhbHRlciB0aGUgaW5mb3JtYXRpb24NCiAgIGZvciB0 aGUgJ0Rlc2NyaXB0aW9uJywgJ0NvbW1lbnRzJywgJ0RlcHJlY2F0ZWQnLCAnUHJlZml4Jywg b3INCiAgICdTdXBwcmVzcy1TY3JpcHQnIGZpZWxkcyBpbiBhIHN1YnRhZydzIHJlY29yZCBh cyBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy40LiAgQ2hhbmdlcyB0byBhbGwgb3RoZXIg ZmllbGRzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFyZQ0KICAgTk9UIHBlcm1pdHRlZC4NCg0K ICAgUmVnaXN0ZXJpbmcgYSBuZXcgc3VidGFnIG9yIHJlcXVlc3RpbmcgbW9kaWZpY2F0aW9u cyB0byBhbiBleGlzdGluZw0KICAgdGFnIG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUgcmVx dWVzdGVyIGZpbGxpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24NCiAgIGZvcm0gcmVwcm9kdWNl ZCBiZWxvdy4gIE5vdGUgdGhhdCBlYWNoIHJlc3BvbnNlIGlzIG5vdCBsaW1pdGVkIGluDQog ICBzaXplIHNvIHRoYXQgdGhlIHJlcXVlc3QgY2FuIGFkZXF1YXRlbHkgZGVzY3JpYmUgdGhl IHJlZ2lzdHJhdGlvbi4NCiAgIFRoZSBmaWVsZHMgaW4gdGhlICJSZWNvcmQgUmVxdWVzdGVk IiBzZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhlDQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlv biAzLjEuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdl IDM0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgTEFOR1VBR0UgU1VCVEFHIFJF R0lTVFJBVElPTiBGT1JNDQogICAxLiBOYW1lIG9mIHJlcXVlc3RlcjoNCiAgIDIuIEUtbWFp bCBhZGRyZXNzIG9mIHJlcXVlc3RlcjoNCiAgIDMuIFJlY29yZCBSZXF1ZXN0ZWQ6DQoNCiAg ICAgIFR5cGU6DQogICAgICBTdWJ0YWc6DQogICAgICBEZXNjcmlwdGlvbjoNCiAgICAgIFBy ZWZpeDoNCiAgICAgIFByZWZlcnJlZC1WYWx1ZToNCiAgICAgIERlcHJlY2F0ZWQ6DQogICAg ICBTdXBwcmVzcy1TY3JpcHQ6DQogICAgICBNYWNyb2xhbmd1YWdlOg0KICAgICAgQ29tbWVu dHM6DQoNCiAgIDQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhlIHN1YnRhZzoNCiAgIDUuIFJl ZmVyZW5jZSB0byBwdWJsaXNoZWQgZGVzY3JpcHRpb24NCiAgICAgIG9mIHRoZSBsYW5ndWFn ZSAoYm9vayBvciBhcnRpY2xlKToNCiAgIDYuIEFueSBvdGhlciByZWxldmFudCBpbmZvcm1h dGlvbjoNCg0KICAgICAgICAgICAgICBGaWd1cmUgNDogVGhlIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyYXRpb24gRm9ybQ0KDQogICBFeGFtcGxlcyBvZiBjb21wbGV0ZWQgcmVnaXN0cmF0 aW9uIGZvcm1zIGNhbiBiZSBmb3VuZCBpbiBBcHBlbmRpeCBDDQogICBvciBvbmxpbmUgYXQg aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9sYW5nLXN1YnRhZ3MtdGVtcGxhdGVz Ly4NCg0KICAgVGhlIHN1YnRhZyByZWdpc3RyYXRpb24gZm9ybSBNVVNUIGJlIHNlbnQgdG8N CiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4gZm9yIGEgdHdvLXdlZWsgcmV2aWV3IHBl cmlvZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0ZWQgdG8gSUFOQS4gIElmIG1vZGlm aWNhdGlvbnMgYXJlIG1hZGUgdG8gdGhlIHJlcXVlc3QNCiAgIGR1cmluZyB0aGUgY291cnNl IG9mIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyAoc3VjaCBhcyBjb3JyZWN0aW9ucyB0bw0K ICAgbWVldCB0aGUgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMy4xKSB0aGUgbW9kaWZpZWQg Zm9ybSBNVVNUIGFsc28gYmUNCiAgIHNlbnQgdG8gPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3Jn PiBhdCBsZWFzdCBvbmUgd2VlayBwcmlvciB0bw0KICAgc3VibWlzc2lvbiB0byBJQU5BLg0K DQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGluIHRoZSBy ZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFydCBvZiB0 aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCByZWNlbnQg bW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhlIFtSRkMzMzM5XSAiZnVsbC1kYXRlIiBmb3JtYXQu DQoNCiAgIEJlZm9yZSBmb3J3YXJkaW5nIGEgbmV3IHJlZ2lzdHJhdGlvbiB0byBJQU5BLCB0 aGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZXZpZXdlciBNVVNUIGVuc3VyZSB0aGF0IHZhbHVl cyBpbiB0aGUgJ1N1YnRhZycgZmllbGQgbWF0Y2ggY2FzZQ0KICAgYWNjb3JkaW5nIHRvIHRo ZSBkZXNjcmlwdGlvbiBpbiBTZWN0aW9uIDMuMS4NCg0KICAgVGhlIGlldGYtbGFuZ3VhZ2Vz IGxpc3QgaXMgYW4gb3BlbiBsaXN0IGFuZCBjYW4gYmUgam9pbmVkIGJ5IHNlbmRpbmcNCiAg IGEgcmVxdWVzdCB0byA8aWV0Zi1sYW5ndWFnZXMtcmVxdWVzdEBpYW5hLm9yZz4uICBUaGUg bGlzdCBjYW4gYmUNCiAgIGhvc3RlZCBieSBJQU5BIG9yIGJ5IGFueSB0aGlyZCBwYXJ0eSBh dCB0aGUgcmVxdWVzdCBvZiBJRVNHLg0KDQogICBTb21lIGZpZWxkcyBpbiBib3RoIHRoZSBy ZWdpc3RyYXRpb24gZm9ybSBhcyB3ZWxsIGFzIHRoZSByZWdpc3RyeQ0KICAgcmVjb3JkIGl0 c2VsZiBwZXJtaXQgdGhlIHVzZSBvZiBub24tQVNDSUkgY2hhcmFjdGVycy4gIFJlZ2lzdHJh dGlvbg0KICAgcmVxdWVzdHMgU0hPVUxEIHVzZSB0aGUgVVRGLTggZW5jb2RpbmcgZm9yIGNv bnNpc3RlbmN5IGFuZCBjbGFyaXR5Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMzVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBIb3dldmVyLCBzaW5jZSBzb21lIG1haWwgY2xp ZW50cyBkbyBub3Qgc3VwcG9ydCB0aGlzIGVuY29kaW5nLCBvdGhlcg0KICAgZW5jb2Rpbmdz IE1BWSBiZSB1c2VkIGZvciB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuICBUaGUgTGFuZ3Vh Z2UNCiAgIFN1YnRhZyBSZXZpZXdlciBpcyByZXNwb25zaWJsZSBmb3IgZW5zdXJpbmcgdGhh dCB0aGUgcHJvcGVyIFVuaWNvZGUNCiAgIGNoYXJhY3RlcnMgYXBwZWFyIGluIGJvdGggdGhl IGFyY2hpdmVkIHJlcXVlc3QgZm9ybSBhbmQgdGhlIHJlZ2lzdHJ5DQogICByZWNvcmQuICBJ biB0aGUgY2FzZSBvZiBhIHRyYW5zY3JpcHRpb24gb3IgZW5jb2RpbmcgZXJyb3IgYnkgSUFO QSwNCiAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgd2lsbCByZXF1ZXN0IHRoYXQg dGhlIHJlZ2lzdHJ5IGJlDQogICByZXBhaXJlZCwgcHJvdmlkaW5nIGFueSBuZWNlc3Nhcnkg aW5mb3JtYXRpb24gdG8gYXNzaXN0IElBTkEuDQoNCiAgIFZhcmlhbnQgc3VidGFncyBhcmUg dXN1YWxseSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIHBhcnRpY3VsYXINCiAgIHJhbmdl IG9mIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAncm96YWonIGlz IGludGVuZGVkDQogICBmb3IgdXNlIHdpdGggbGFuZ3VhZ2UgdGFncyB0aGF0IHN0YXJ0IHdp dGggdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1YnRhZyAic2wiLCBzaW5jZSBSZXNpYW4g aXMgYSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4gIFRodXMsIHRoZQ0KICAgc3VidGFnICdyb3ph aicgd291bGQgYmUgYXBwcm9wcmlhdGUgaW4gdGFncyBzdWNoIGFzICJzbC1MYXRuLXJvemFq Ig0KICAgb3IgInNsLUlULXJvemFqIi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGlu IHRoZSAnUHJlZml4JyBmaWVsZA0KICAgaW4gdGhlIHJlZ2lzdHJ5LiAgVmFyaWFudCByZWdp c3RyYXRpb24gcmVxdWVzdHMgU0hPVUxEIGluY2x1ZGUgYXQNCiAgIGxlYXN0IG9uZSAnUHJl Zml4JyBmaWVsZCBpbiB0aGUgcmVnaXN0cmF0aW9uIGZvcm0uDQoNCiAgIEV4dGVuZGVkIGxh bmd1YWdlIHN1YnRhZ3MgTVVTVCBpbmNsdWRlIGV4YWN0bHkgb25lICdQcmVmaXgnIGZpZWxk Lg0KDQogICBUaGUgJ1ByZWZpeCcgZmllbGQgZm9yIGEgZ2l2ZW4gcmVnaXN0ZXJlZCBzdWJ0 YWcgZXhpc3RzIGluIHRoZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVzYWdl LiAgQWRkaXRpb25hbCBwcmVmaXhlcyBNQVkgYmUgYWRkZWQgYnkNCiAgIGZpbGluZyBhbiBh ZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiBmb3JtLiAgSW4gdGhhdCBmb3JtLCB0aGUgIkFueSBv dGhlcg0KICAgcmVsZXZhbnQgaW5mb3JtYXRpb246IiBmaWVsZCBNVVNUIGluZGljYXRlIHRo YXQgaXQgaXMgdGhlIGFkZGl0aW9uIG9mDQogICBhIHByZWZpeC4NCg0KICAgUmVxdWVzdHMg dG8gYWRkIGEgcHJlZml4IHRvIGEgdmFyaWFudCBzdWJ0YWcgdGhhdCBpbXBseSBhIGRpZmZl cmVudA0KICAgc2VtYW50aWMgbWVhbmluZyB3aWxsIHByb2JhYmx5IGJlIHJlamVjdGVkLiAg Rm9yIGV4YW1wbGUsIGEgcmVxdWVzdA0KICAgdG8gYWRkIHRoZSBwcmVmaXggImRlIiB0byB0 aGUgc3VidGFnICduZWRpcycgc28gdGhhdCB0aGUgdGFnICJkZS0NCiAgIG5lZGlzIiByZXBy ZXNlbnRlZCBzb21lIEdlcm1hbiBkaWFsZWN0IHdvdWxkIGJlIHJlamVjdGVkLiAgVGhlDQog ICAnbmVkaXMnIHN1YnRhZyByZXByZXNlbnRzIGEgcGFydGljdWxhciBTbG92ZW5pYW4gZGlh bGVjdCBhbmQgdGhlDQogICBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiB3b3VsZCBjaGFuZ2Ug dGhlIHNlbWFudGljIG1lYW5pbmcgYXNzaWduZWQgdG8NCiAgIHRoZSBzdWJ0YWcuICBBIHNl cGFyYXRlIHN1YnRhZyBTSE9VTEQgYmUgcHJvcG9zZWQgaW5zdGVhZC4NCg0KICAgVGhlICdE ZXNjcmlwdGlvbicgZmllbGQgTVVTVCBjb250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRh ZyBiZWluZw0KICAgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhl IExhdGluIHNjcmlwdDsgaXQgTUFZIGFsc28NCiAgIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBp biBhIG5vbi1MYXRpbiBzY3JpcHQuICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZA0KICAgaXMg dXNlZCBmb3IgaWRlbnRpZmljYXRpb24gcHVycG9zZXMgYW5kIGRvZXNuJ3QgbmVjZXNzYXJp bHkgcmVwcmVzZW50DQogICB0aGUgYWN0dWFsIG5hdGl2ZSBuYW1lIG9mIHRoZSBsYW5ndWFn ZSBvciB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55DQogICBwYXJ0aWN1bGFyIGxhbmd1YWdl Lg0KDQogICBXaGlsZSB0aGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpdHNlbGYgaXMgbm90IGd1 YXJhbnRlZWQgdG8gYmUgc3RhYmxlDQogICBhbmQgZXJyYXRhIGNvcnJlY3Rpb25zIE1BWSBi ZSB1bmRlcnRha2VuIGZyb20gdGltZSB0byB0aW1lLCBhdHRlbXB0cw0KICAgdG8gcHJvdmlk ZSB0cmFuc2xhdGlvbnMgb3IgdHJhbnNjcmlwdGlvbnMgb2YgZW50cmllcyBpbiB0aGUgcmVn aXN0cnkNCiAgIGl0c2VsZiB3aWxsIHByb2JhYmx5IGJlIGZyb3duZWQgdXBvbiBieSB0aGUg Y29tbXVuaXR5IG9yIHJlamVjdGVkDQogICBvdXRyaWdodCwgYXMgY2hhbmdlcyBvZiB0aGlz IG5hdHVyZSBoYXZlIGFuIGltcGFjdCBvbiB0aGUgcHJvdmlzaW9ucw0KICAgaW4gU2VjdGlv biAzLjQuDQoNCiAgIFdoZW4gdGhlIHR3by13ZWVrIHBlcmlvZCBoYXMgcGFzc2VkLCB0aGUg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSAzNl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIE1VU1QgdGFrZSBvbmUgb2YgdGhlIGZvbGxv d2luZyBhY3Rpb25zOg0KDQogICBvICBFeHBsaWNpdGx5IGFjY2VwdCB0aGUgcmVxdWVzdCBh bmQgZm9yd2FyZCB0aGUgZm9ybSBjb250YWluaW5nIHRoZQ0KICAgICAgcmVjb3JkIHRvIGJl IGluc2VydGVkIG9yIG1vZGlmaWVkIHRvIGlhbmFAaWFuYS5vcmcgYWNjb3JkaW5nIHRvDQog ICAgICB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAgbyAg RXhwbGljaXRseSByZWplY3QgdGhlIHJlcXVlc3QgYmVjYXVzZSBvZiBzaWduaWZpY2FudCBv YmplY3Rpb25zDQogICAgICByYWlzZWQgb24gdGhlIGxpc3Qgb3IgZHVlIHRvIHByb2JsZW1z IHdpdGggY29uc3RyYWludHMgaW4gdGhpcw0KICAgICAgZG9jdW1lbnQgKHdoaWNoIE1VU1Qg YmUgZXhwbGljaXRseSBjaXRlZCkuDQoNCiAgIG8gIEV4dGVuZCB0aGUgcmV2aWV3IHBlcmlv ZCBieSBncmFudGluZyBhbiBhZGRpdGlvbmFsIHR3by13ZWVrDQogICAgICBpbmNyZW1lbnQg dG8gcGVybWl0IGZ1cnRoZXIgZGlzY3Vzc2lvbi4gIEFmdGVyIGVhY2ggdHdvLXdlZWsNCiAg ICAgIGluY3JlbWVudCwgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNVVNUIGluZGlj YXRlIG9uIHRoZSBsaXN0DQogICAgICB3aGV0aGVyIHRoZSByZWdpc3RyYXRpb24gaGFzIGJl ZW4gYWNjZXB0ZWQsIHJlamVjdGVkLCBvciBleHRlbmRlZC4NCg0KICAgTm90ZSB0aGF0IHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZIHJhaXNlIG9iamVjdGlvbnMgb24gdGhl DQogICBsaXN0IGlmIGhlIG9yIHNoZSBzbyBkZXNpcmVzLiAgVGhlIGltcG9ydGFudCB0aGlu ZyBpcyB0aGF0IHRoZQ0KICAgb2JqZWN0aW9uIE1VU1QgYmUgbWFkZSBwdWJsaWNseS4NCg0K ICAgU29tZXRpbWVzIHRoZSByZXF1ZXN0IG5lZWRzIHRvIGJlIG1vZGlmaWVkIGFzIGEgcmVz dWx0IG9mIGRpc2N1c3Npb24NCiAgIGR1cmluZyB0aGUgcmV2aWV3IHBlcmlvZCBvciBkdWUg dG8gcmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQuDQogICBUaGUgYXBwbGljYW50LCBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIG9yIG90aGVycyBhcmUgZnJlZSB0byBzdWJtaXQN CiAgIGEgbW9kaWZpZWQgdmVyc2lvbiBvZiB0aGUgY29tcGxldGVkIHJlZ2lzdHJhdGlvbiBm b3JtLCB3aGljaCB3aWxsIGJlDQogICBjb25zaWRlcmVkIGluIGxpZXUgb2YgdGhlIG9yaWdp bmFsIHJlcXVlc3Qgd2l0aCB0aGUgZXhwbGljaXQgYXBwcm92YWwNCiAgIG9mIHRoZSBhcHBs aWNhbnQuICBTdWNoIGNoYW5nZXMgZG8gbm90IHJlc3RhcnQgdGhlIHR3by13ZWVrDQogICBk aXNjdXNzaW9uIHBlcmlvZCwgYWx0aG91Z2ggYW4gYXBwbGljYXRpb24gY29udGFpbmluZyB0 aGUgZmluYWwNCiAgIHJlY29yZCBzdWJtaXR0ZWQgdG8gSUFOQSBNVVNUIGFwcGVhciBvbiB0 aGUgbGlzdCBhdCBsZWFzdCBvbmUgd2Vlaw0KICAgcHJpb3IgdG8gdGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBmb3J3YXJkaW5nIHRoZSByZWNvcmQgdG8gSUFOQS4NCiAgIFRoZSBh cHBsaWNhbnQgaXMgYWxzbyBmcmVlIHRvIG1vZGlmeSBhIHJlamVjdGVkIGFwcGxpY2F0aW9u IHdpdGgNCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYW5kIHN1Ym1pdCBpdCBhZ2Fpbjsg dGhpcyBzdGFydHMgYSBuZXcgdHdvLQ0KICAgd2VlayBjb21tZW50IHBlcmlvZC4NCg0KICAg UmVnaXN0cmF0aW9ucyBpbml0aWF0ZWQgZHVlIHRvIHRoZSBwcm92aXNpb25zIG9mIFNlY3Rp b24gMy4zIG9yDQogICBTZWN0aW9uIDMuNCBTSEFMTCBOT1QgYmUgcmVqZWN0ZWQgYWx0b2dl dGhlciAoc2luY2UgdGhleSBoYXZlIHRvDQogICB1bHRpbWF0ZWx5IGFwcGVhciBpbiB0aGUg cmVnaXN0cnkpIGFuZCBTSE9VTEQgYmUgY29tcGxldGVkIGFzIHF1aWNrbHkNCiAgIGFzIHBv c3NpYmxlLiAgVGhlIHJldmlldyBwcm9jZXNzIGFsbG93cyBsaXN0IG1lbWJlcnMgdG8gY29t bWVudCBvbg0KICAgdGhlIHNwZWNpZmljIGluZm9ybWF0aW9uIGluIHRoZSBmb3JtIGFuZCB0 aGUgcmVjb3JkIGl0IGNvbnRhaW5zIGFuZA0KICAgdGh1cyBoZWxwIGVuc3VyZSB0aGF0IGl0 IGlzIGNvcnJlY3QgYW5kIGNvbnNpc3RlbnQuICBUaGUgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBS ZXZpZXdlciBNQVkgcmVqZWN0IGEgc3BlY2lmaWMgdmVyc2lvbiBvZiB0aGUgZm9ybSwgYnV0 IE1VU1QNCiAgIGluY2x1ZGUgaW4gdGhlIHJlamVjdGlvbiBhIHN1aXRhYmxlIHJlcGxhY2Vt ZW50LCBleHRlbmRpbmcgdGhlIHJldmlldw0KICAgcGVyaW9kIGFzIGRlc2NyaWJlZCBhYm92 ZSwgdW50aWwgdGhlIGZvcm0gaXMgaW4gYSBmb3JtYXQgd29ydGh5IG9mDQogICByZXZpZXdl cidzIGFwcHJvdmFsLg0KDQogICBEZWNpc2lvbnMgbWFkZSBieSB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyIE1BWSBiZSBhcHBlYWxlZCB0byB0aGUNCiAgIElFU0cgW1JGQzIwMjhd IHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYgZGVjaXNpb25zDQogICBbUkZD MjAyNl0uICBUaGlzIGluY2x1ZGVzIGEgZGVjaXNpb24gdG8gZXh0ZW5kIHRoZSByZXZpZXcg cGVyaW9kIG9yDQogICB0aGUgZmFpbHVyZSB0byBhbm5vdW5jZSBhIGRlY2lzaW9uIGluIGEg Y2xlYXIgYW5kIHRpbWVseSBtYW5uZXIuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDM3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgVGhlIGFwcHJvdmVkIHJlY29yZHMgYXBw ZWFyIGluIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuICBUaGUNCiAgIGFwcHJvdmVk IHJlZ2lzdHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSB1bmRlcg0KICAgaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9sYW5nLXN1YnRhZ3MtdGVtcGxhdGVzLy4N Cg0KICAgVXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMgZm9sbG93IHRo ZSBzYW1lIHByb2NlZHVyZSBhcw0KICAgbmV3IHJlZ2lzdHJhdGlvbnMuICBUaGUgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyIGRlY2lkZXMgd2hldGhlcg0KICAgdGhlcmUgaXMgY29uc2Vu c3VzIHRvIHVwZGF0ZSB0aGUgcmVnaXN0cmF0aW9uIGZvbGxvd2luZyB0aGUgdHdvIHdlZWsN CiAgIHJldmlldyBwZXJpb2Q7IG5vcm1hbGx5LCBvYmplY3Rpb25zIGJ5IHRoZSBvcmlnaW5h bCByZWdpc3RyYW50IHdpbGwNCiAgIGNhcnJ5IGV4dHJhIHdlaWdodCBpbiBmb3JtaW5nIHN1 Y2ggYSBjb25zZW5zdXMuDQoNCiAgIFJlZ2lzdHJhdGlvbnMgYXJlIHBlcm1hbmVudCBhbmQg c3RhYmxlLiAgT25jZSByZWdpc3RlcmVkLCBzdWJ0YWdzDQogICB3aWxsIG5vdCBiZSByZW1v dmVkIGZyb20gdGhlIHJlZ2lzdHJ5IGFuZCB3aWxsIHJlbWFpbiBhIHZhbGlkIHdheSBpbg0K ICAgd2hpY2ggdG8gc3BlY2lmeSBhIHNwZWNpZmljIGxhbmd1YWdlIG9yIHZhcmlhbnQuDQoN CiAgIE5vdGU6IFRoZSBwdXJwb3NlIG9mIHRoZSAiUmVmZXJlbmNlIHRvIHB1Ymxpc2hlZCBk ZXNjcmlwdGlvbiIgc2VjdGlvbg0KICAgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGlzIHRv IGFpZCBpbiB2ZXJpZnlpbmcgd2hldGhlciBhIGxhbmd1YWdlIGlzDQogICByZWdpc3RlcmVk IG9yIHdoYXQgbGFuZ3VhZ2Ugb3IgbGFuZ3VhZ2UgdmFyaWF0aW9uIGEgcGFydGljdWxhciBz dWJ0YWcNCiAgIHJlZmVycyB0by4gIEluIG1vc3QgY2FzZXMsIHJlZmVyZW5jZSB0byBhbiBh dXRob3JpdGF0aXZlIGdyYW1tYXIgb3INCiAgIGRpY3Rpb25hcnkgb2YgdGhhdCBsYW5ndWFn ZSB3aWxsIGJlIHVzZWZ1bDsgaW4gY2FzZXMgd2hlcmUgbm8gc3VjaA0KICAgd29yayBleGlz dHMsIG90aGVyIHdlbGwta25vd24gd29ya3MgZGVzY3JpYmluZyB0aGF0IGxhbmd1YWdlIG9y IGluDQogICB0aGF0IGxhbmd1YWdlIE1BWSBiZSBhcHByb3ByaWF0ZS4gIFRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXINCiAgIGRlY2lkZXMgd2hhdCBjb25zdGl0dXRlcyAiZ29vZCBl bm91Z2giIHJlZmVyZW5jZSBtYXRlcmlhbC4gIFRoaXMNCiAgIHJlcXVpcmVtZW50IGlzIG5v dCBpbnRlbmRlZCB0byBleGNsdWRlIHBhcnRpY3VsYXIgbGFuZ3VhZ2VzIG9yDQogICBkaWFs ZWN0cyBkdWUgdG8gdGhlIHNpemUgb2YgdGhlIHNwZWFrZXIgcG9wdWxhdGlvbiBvciBsYWNr IG9mIGENCiAgIHN0YW5kYXJkaXplZCBvcnRob2dyYXBoeS4gIE1pbm9yaXR5IGxhbmd1YWdl cyB3aWxsIGJlIGNvbnNpZGVyZWQNCiAgIGVxdWFsbHkgb24gdGhlaXIgb3duIG1lcml0cy4N Cg0KMy42LiAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uDQoNCiAgIFBvc3NpYmls aXRpZXMgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdWJ0YWdzIG9yIGluZm9ybWF0aW9uIGFib3V0 DQogICBzdWJ0YWdzIGluY2x1ZGU6DQoNCiAgIG8gIFByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFn cyBmb3IgbGFuZ3VhZ2VzIG5vdCBsaXN0ZWQgaW4gSVNPIDYzOSB0aGF0DQogICAgICBhcmUg bm90IHZhcmlhbnRzIG9mIGFueSBsaXN0ZWQgb3IgcmVnaXN0ZXJlZCBsYW5ndWFnZSBNQVkg YmUNCiAgICAgIHJlZ2lzdGVyZWQuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBj cmVhdGVkLCB0aGVyZSB3ZXJlIG5vDQogICAgICBleGFtcGxlcyBvZiB0aGlzIGZvcm0gb2Yg c3VidGFnLiAgQmVmb3JlIGF0dGVtcHRpbmcgdG8gcmVnaXN0ZXIgYQ0KICAgICAgbGFuZ3Vh Z2Ugc3VidGFnLCB0aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVnaXN0ZXIgdGhlIGxh bmd1YWdlDQogICAgICB3aXRoIElTTyA2MzkuICBTdWJ0YWdzIE1VU1QgTk9UIGJlIHJlZ2lz dGVyZWQgZm9yIGxhbmd1YWdlcw0KICAgICAgZGVmaW5lZCBieSBjb2RlcyB0aGF0IGV4aXN0 IGluIElTTyA2MzktMSwgSVNPIDYzOS0yLCBvciBJU08gNjM5LTMsDQogICAgICBvciB0aGF0 IGFyZSB1bmRlciBjb25zaWRlcmF0aW9uIGJ5IHRoZSBJU08gNjM5IHJlZ2lzdHJhdGlvbg0K ICAgICAgYXV0aG9yaXRpZXMsIG9yIHRoYXQgaGF2ZSBuZXZlciBiZWVuIGF0dGVtcHRlZCBm b3IgcmVnaXN0cmF0aW9uDQogICAgICB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiAgSWYgSVNP IDYzOSBoYXMgcHJldmlvdXNseSByZWplY3RlZCBhDQogICAgICBsYW5ndWFnZSBmb3IgcmVn aXN0cmF0aW9uLCBpdCBpcyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IHRoZXJlDQogICAg ICBtdXN0IGJlIGFkZGl0aW9uYWwsIHZlcnkgY29tcGVsbGluZyBldmlkZW5jZSBvZiBuZWVk IGJlZm9yZSBpdA0KICAgICAgd2lsbCBiZSByZWdpc3RlcmVkIGFzIGEgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWcgaW4gdGhlIElBTkENCiAgICAgIHJlZ2lzdHJ5ICh0byB0aGUgZXh0ZW50 IHRoYXQgaXQgaXMgdmVyeSB1bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzDQogICAgICB3aWxs IGJlIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug MzhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBEaWFsZWN0IG9yIG90aGVy IGRpdmlzaW9ucyBvciB2YXJpYXRpb25zIHdpdGhpbiBhIGxhbmd1YWdlLCBpdHMNCiAgICAg IG9ydGhvZ3JhcGh5LCB3cml0aW5nIHN5c3RlbSwgcmVnaW9uYWwgb3IgaGlzdG9yaWNhbCB1 c2FnZSwNCiAgICAgIHRyYW5zbGl0ZXJhdGlvbiBvciBvdGhlciB0cmFuc2Zvcm1hdGlvbiwg b3IgZGlzdGluZ3Vpc2hpbmcNCiAgICAgIHZhcmlhdGlvbiBNQVkgYmUgcmVnaXN0ZXJlZCBh cyB2YXJpYW50IHN1YnRhZ3MuICBBbiBleGFtcGxlIGlzIHRoZQ0KICAgICAgJ3JvemFqJyBz dWJ0YWcgKHRoZSBSZXNpYW4gZGlhbGVjdCBvZiBTbG92ZW5pYW4pLg0KDQogICBvICBUaGUg YWRkaXRpb24gb3IgbWFpbnRlbmFuY2Ugb2YgZmllbGRzIChnZW5lcmFsbHkgb2YgYW4NCiAg ICAgIGluZm9ybWF0aW9uYWwgbmF0dXJlKSBpbiBUYWcgb3IgU3VidGFnIHJlY29yZHMgYXMg ZGVzY3JpYmVkIGluDQogICAgICBTZWN0aW9uIDMuMSBhbmQgc3ViamVjdCB0byB0aGUgc3Rh YmlsaXR5IHByb3Zpc2lvbnMgaW4NCiAgICAgIFNlY3Rpb24gMy40LiAgVGhpcyBpbmNsdWRl cyBkZXNjcmlwdGlvbnMsIGNvbW1lbnRzLCBkZXByZWNhdGlvbg0KICAgICAgYW5kIHByZWZl cnJlZCB2YWx1ZXMgZm9yIG9ic29sZXRlIG9yIHdpdGhkcmF3biBjb2Rlcywgb3IgdGhlDQog ICAgICBhZGRpdGlvbiBvZiBzY3JpcHQgb3IgZXh0bGFuZyBpbmZvcm1hdGlvbiB0byBwcmlt YXJ5IGxhbmd1YWdlDQogICAgICBzdWJ0YWdzLg0KDQogICBvICBUaGUgYWRkaXRpb24gb2Yg cmVjb3JkcyBhbmQgcmVsYXRlZCBmaWVsZCB2YWx1ZSBjaGFuZ2VzIG5lY2Vzc2FyeQ0KICAg ICAgdG8gcmVmbGVjdCBhc3NpZ25tZW50cyBtYWRlIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg SVNPIDMxNjYsIGFuZA0KICAgICAgVU4gTS40OSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjQuDQoNCiAgIFN1YnRhZ3MgcHJvcG9zZWQgZm9yIHJlZ2lzdHJhdGlvbiB0aGF0IHdvdWxk IGNhdXNlIGFsbCBvciBwYXJ0IG9mIGENCiAgIGdyYW5kZmF0aGVyZWQgdGFnIHRvIGJlY29t ZSByZWR1bmRhbnQgYnV0IHdob3NlIG1lYW5pbmcgY29uZmxpY3RzDQogICB3aXRoIG9yIGFs dGVycyB0aGUgbWVhbmluZyBvZiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcgTVVTVCBiZSByZWpl Y3RlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBsZWF2ZXMgdGhlIGRlY2lzaW9uIG9uIHdoYXQg c3VidGFncyBvciBjaGFuZ2VzIHRvDQogICBzdWJ0YWdzIGFyZSBhcHByb3ByaWF0ZSAob3Ig bm90KSB0byB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MNCiAgIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuNS4NCg0KICAgTm90ZTogZm91ci1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBz dWJ0YWdzIGFyZSByZXNlcnZlZCB0byBhbGxvdw0KICAgZm9yIHRoZSBwb3NzaWJpbGl0eSBv ZiBhbHBoYTQgY29kZXMgaW4gc29tZSBmdXR1cmUgYWRkaXRpb24gdG8gdGhlDQogICBJU08g NjM5IGZhbWlseSBvZiBzdGFuZGFyZHMuDQoNCiAgIElTTyA2MzkgZGVmaW5lcyBhIG1haW50 ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzIGluDQogICB0aGUg bGlzdCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS4gIFRoaXMgYWdlbmN5IGlzOg0KDQogICBJ bnRlcm5hdGlvbmFsIEluZm9ybWF0aW9uIENlbnRyZSBmb3IgVGVybWlub2xvZ3kgKEluZm90 ZXJtKQ0KICAgQWljaGhvbHpnYXNzZSA2LzEyLCBBVC0xMTIwDQogICBXaWVuLCBBdXN0cmlh DQogICBQaG9uZTogKzQzIDEgMjYgNzUgMzUgRXh0LiAzMTIgRmF4OiArNDMgMSAyMTYgMzIg NzINCg0KICAgSVNPIDYzOS0yIGRlZmluZXMgYSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIGFk ZGl0aW9ucyB0byBhbmQgY2hhbmdlcw0KICAgaW4gdGhlIGxpc3Qgb2YgbGFuZ3VhZ2VzIGlu IElTTyA2MzktMi4gIFRoaXMgYWdlbmN5IGlzOg0KDQogICBMaWJyYXJ5IG9mIENvbmdyZXNz DQogICBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBNQVJDIFN0YW5kYXJkcyBPZmZpY2UNCiAg IFdhc2hpbmd0b24sIEQuQy4gMjA1NDAgVVNBDQogICBQaG9uZTogKzEgMjAyIDcwNyA2MjM3 IEZheDogKzEgMjAyIDcwNyAwMTE1DQogICBVUkw6IGh0dHA6Ly93d3cubG9jLmdvdi9zdGFu ZGFyZHMvaXNvNjM5LTINCg0KICAgSVNPIDYzOS0zIGRlZmluZXMgYSBtYWludGVuYW5jZSBh Z2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcw0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1Bh Z2UgMzldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBpbiB0aGUgbGlzdCBvZiBs YW5ndWFnZXMgaW4gSVNPIDYzOS0zLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIFNJTCBJbnRl cm5hdGlvbmFsDQogICBJU08gNjM5LTMgUmVnaXN0cmFyDQogICA3NTAwIFcuIENhbXAgV2lz ZG9tIFJkLg0KICAgRGFsbGFzLCBUWCA3NTIzNiBVU0ENCiAgIFBob25lOiArMSA5NzIgNzA4 IDc0MDAsIGV4dC4gMjI5MyBGYXg6ICsxIDk3MiA3MDggNzU0Ng0KICAgRW1haWw6IGlzbzYz OS0zQHNpbC5vcmcNCiAgIFVSTDogaHR0cDovL3d3dy5zaWwub3JnL2lzbzYzOS0zDQoNCiAg IFRoZSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAzMTY2IChjb3VudHJ5IGNvZGVzKSBp czoNCg0KICAgSVNPIDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5DQogICBjL28gSW50ZXJuYXRp b25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbg0KICAgQ2FzZSBwb3N0YWxl IDU2DQogICBDSC0xMjExIEdlbmV2YSAyMCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0MSAy MiA3NDkgNzIgMzMgRmF4OiArNDEgMjIgNzQ5IDczIDQ5DQogICBVUkw6IGh0dHA6Ly93d3cu aXNvLm9yZy9pc28vZW4vcHJvZHMtc2VydmljZXMvaXNvMzE2Nm1hL2luZGV4Lmh0bWwNCg0K ICAgVGhlIHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkgZm9yIElTTyAxNTkyNCAoc2NyaXB0IGNv ZGVzKSBpczoNCg0KICAgVW5pY29kZSBDb25zb3J0aXVtIEJveCAzOTE0NzYNCiAgIE1vdW50 YWluIFZpZXcsIENBIDk0MDM5LTE0NzYsIFVTQQ0KICAgVVJMOiBodHRwOi8vd3d3LnVuaWNv ZGUub3JnL2lzbzE1OTI0DQoNCiAgIFRoZSBTdGF0aXN0aWNzIERpdmlzaW9uIG9mIHRoZSBV bml0ZWQgTmF0aW9ucyBTZWNyZXRhcmlhdCBtYWludGFpbnMNCiAgIHRoZSBTdGFuZGFyZCBD b3VudHJ5IG9yIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSBhbmQgY2FuIGJlDQog ICByZWFjaGVkIGF0Og0KDQogICBTdGF0aXN0aWNhbCBTZXJ2aWNlcyBCcmFuY2gNCiAgIFN0 YXRpc3RpY3MgRGl2aXNpb24NCiAgIFVuaXRlZCBOYXRpb25zLCBSb29tIERDMi0xNjIwDQog ICBOZXcgWW9yaywgTlkgMTAwMTcsIFVTQQ0KDQogICBGYXg6ICsxLTIxMi05NjMtMDYyMw0K ICAgRS1tYWlsOiBzdGF0aXN0aWNzQHVuLm9yZw0KICAgVVJMOiBodHRwOi8vdW5zdGF0cy51 bi5vcmcvdW5zZC9tZXRob2RzL200OS9tNDlhbHBoYS5odG0NCg0KMy43LiAgRXh0ZW5zaW9u cyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBFeHRlbnNpb24gc3VidGFncyBhcmUg dGhvc2UgaW50cm9kdWNlZCBieSBzaW5nbGUtY2hhcmFjdGVyIHN1YnRhZ3MNCiAgICgic2lu Z2xldG9ucyIpIG90aGVyIHRoYW4gJ3gnLiAgVGhleSBhcmUgcmVzZXJ2ZWQgZm9yIHRoZSBn ZW5lcmF0aW9uDQogICBvZiBpZGVudGlmaWVycyB0aGF0IGNvbnRhaW4gYSBsYW5ndWFnZSBj b21wb25lbnQgYW5kIGFyZSBjb21wYXRpYmxlDQogICB3aXRoIGFwcGxpY2F0aW9ucyB0aGF0 IHVuZGVyc3RhbmQgbGFuZ3VhZ2UgdGFncy4NCg0KICAgVGhlIHN0cnVjdHVyZSBhbmQgZm9y bSBvZiBleHRlbnNpb25zIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgc28NCiAgIHRo YXQgaW1wbGVtZW50YXRpb25zIGNhbiBiZSBjcmVhdGVkIHRoYXQgYXJlIGZvcndhcmQgY29t cGF0aWJsZSB3aXRoDQogICBhcHBsaWNhdGlvbnMgdGhhdCBtaWdodCBiZSBjcmVhdGVkIHVz aW5nIHNpbmdsZXRvbnMgaW4gdGhlIGZ1dHVyZS4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDQw XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgSW4gYWRkaXRpb24sIGRlZmluaW5n IGEgbWVjaGFuaXNtIGZvciBtYWludGFpbmluZyBzaW5nbGV0b25zIHdpbGwNCiAgIGxlbmQg c3RhYmlsaXR5IHRvIHRoaXMgZG9jdW1lbnQgYnkgcmVkdWNpbmcgdGhlIGxpa2VseSBuZWVk IGZvcg0KICAgZnV0dXJlIHJldmlzaW9ucyBvciB1cGRhdGVzLg0KDQogICBTaW5nbGUtY2hh cmFjdGVyIHN1YnRhZ3MgYXJlIGFzc2lnbmVkIGJ5IElBTkEgdXNpbmcgdGhlICJJRVRGDQog ICBDb25zZW5zdXMiIHBvbGljeSBkZWZpbmVkIGJ5IFtSRkMyNDM0XS4gIFRoaXMgcG9saWN5 IHJlcXVpcmVzIHRoZQ0KICAgZGV2ZWxvcG1lbnQgb2YgYW4gUkZDLCB3aGljaCBTSEFMTCBk ZWZpbmUgdGhlIG5hbWUsIHB1cnBvc2UsDQogICBwcm9jZXNzZXMsIGFuZCBwcm9jZWR1cmVz IGZvciBtYWludGFpbmluZyB0aGUgc3VidGFncy4gIFRoZQ0KICAgbWFpbnRhaW5pbmcgb3Ig cmVnaXN0ZXJpbmcgYXV0aG9yaXR5LCBpbmNsdWRpbmcgbmFtZSwgY29udGFjdCBlbWFpbCwN CiAgIGRpc2N1c3Npb24gbGlzdCBlbWFpbCwgYW5kIFVSTCBsb2NhdGlvbiBvZiB0aGUgcmVn aXN0cnksIE1VU1QgYmUNCiAgIGluZGljYXRlZCBjbGVhcmx5IGluIHRoZSBSRkMuICBUaGUg UkZDIE1VU1Qgc3BlY2lmeSBvciBpbmNsdWRlIGVhY2gNCiAgIG9mIHRoZSBmb2xsb3dpbmc6 DQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgcmVmZXJlbmNlIHRoZSBzcGVjaWZp YyB2ZXJzaW9uIG9yIHJldmlzaW9uDQogICAgICBvZiB0aGlzIGRvY3VtZW50IHRoYXQgZ292 ZXJucyBpdHMgY3JlYXRpb24gYW5kIE1VU1QgcmVmZXJlbmNlIHRoaXMNCiAgICAgIHNlY3Rp b24gb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gYW5kIGFs bCBzdWJ0YWdzIGRlZmluZWQgYnkgdGhlIHNwZWNpZmljYXRpb24NCiAgICAgIE1VU1QgZm9s bG93IHRoZSBBQk5GIGFuZCBvdGhlciBydWxlcyBmb3IgdGhlIGZvcm1hdGlvbiBvZiB0YWdz IGFuZA0KICAgICAgc3VidGFncyBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBJbiBw YXJ0aWN1bGFyLCBpdCBNVVNUDQogICAgICBzcGVjaWZ5IHRoYXQgY2FzZSBpcyBub3Qgc2ln bmlmaWNhbnQgYW5kIHRoYXQgc3VidGFncyBNVVNUIE5PVA0KICAgICAgZXhjZWVkIGVpZ2h0 IGNoYXJhY3RlcnMgaW4gbGVuZ3RoLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNU IHNwZWNpZnkgYSBjYW5vbmljYWwgcmVwcmVzZW50YXRpb24uDQoNCiAgIG8gIFRoZSBzcGVj aWZpY2F0aW9uIG9mIHZhbGlkIHN1YnRhZ3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0aGUN CiAgICAgIEludGVybmV0IGFuZCBhdCBubyBjb3N0Lg0KDQogICBvICBUaGUgc3BlY2lmaWNh dGlvbiBNVVNUIGJlIGluIHRoZSBwdWJsaWMgZG9tYWluIG9yIGF2YWlsYWJsZSB2aWEgYQ0K ICAgICAgcm95YWx0eS1mcmVlIGxpY2Vuc2UgYWNjZXB0YWJsZSB0byB0aGUgSUVURiBhbmQg c3BlY2lmaWVkIGluIHRoZQ0KICAgICAgUkZDLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlv biBNVVNUIGJlIHZlcnNpb25lZCwgYW5kIGVhY2ggdmVyc2lvbiBvZiB0aGUNCiAgICAgIHNw ZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQsIGFuZCBzdGFibGUuDQoNCiAg IG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxlLiAgVGhhdCBpcywgZXh0ZW5z aW9uIHN1YnRhZ3MsDQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBzcGVjaWZpY2F0aW9uLCBN VVNUIE5PVCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBtZWFuaW5nIGluIGFu eSBzdWJzdGFudGlhbCB3YXkuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgaW5j bHVkZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRpb24gZm9y bSByZXByb2R1Y2VkIGluIHRoaXMgc2VjdGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4NCiAg ICAgIHJlZ2lzdGVyaW5nIHRoZSBleHRlbnNpb24gdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBS RkMuDQoNCiAgIG8gIElBTkEgTVVTVCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBj b250YWN0IGluZm9ybWF0aW9uIGFuZA0KICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNhdGlv bi4NCg0KICAgSUFOQSB3aWxsIG1haW50YWluIGEgcmVnaXN0cnkgb2YgYWxsb2NhdGVkIHNp bmdsZS1jaGFyYWN0ZXINCiAgIChzaW5nbGV0b24pIHN1YnRhZ3MuICBUaGlzIHJlZ2lzdHJ5 IE1VU1QgdXNlIHRoZSByZWNvcmQtamFyIGZvcm1hdA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug NDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBkZXNjcmliZWQgYnkgdGhlIEFC TkYgaW4gU2VjdGlvbiAzLjEuICBVcG9uIHB1YmxpY2F0aW9uIG9mIGFuDQogICBleHRlbnNp b24gYXMgYW4gUkZDLCB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGRlZmluZWQgaW4gdGhl IFJGQw0KICAgTVVTVCBmb3J3YXJkIHRoaXMgcmVnaXN0cmF0aW9uIGZvcm0gdG8gaWVzZ0Bp ZXRmLm9yZywgd2hvIE1VU1QNCiAgIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gaWFuYUBpYW5h Lm9yZy4gIFRoZSBtYWludGFpbmluZyBhdXRob3JpdHkgb2YNCiAgIHRoZSBleHRlbnNpb24g TVVTVCBtYWludGFpbiB0aGUgYWNjdXJhY3kgb2YgdGhlIHJlY29yZCBieSBzZW5kaW5nIGFu DQogICB1cGRhdGVkIGZ1bGwgY29weSBvZiB0aGUgcmVjb3JkIHRvIGlhbmFAaWFuYS5vcmcg d2l0aCB0aGUgc3ViamVjdA0KICAgbGluZSAiTEFOR1VBR0UgVEFHIEVYVEVOU0lPTiBVUERB VEUiIHdoZW5ldmVyIGNvbnRlbnQgY2hhbmdlcy4gIE9ubHkNCiAgIHRoZSAnQ29tbWVudHMn LCAnQ29udGFjdF9FbWFpbCcsICdNYWlsaW5nX0xpc3QnLCBhbmQgJ1VSTCcgZmllbGRzIE1B WQ0KICAgYmUgbW9kaWZpZWQgaW4gdGhlc2UgdXBkYXRlcy4NCg0KICAgRmFpbHVyZSB0byBt YWludGFpbiB0aGlzIHJlY29yZCwgbWFpbnRhaW4gdGhlIGNvcnJlc3BvbmRpbmcgcmVnaXN0 cnksDQogICBvciBtZWV0IG90aGVyIGNvbmRpdGlvbnMgaW1wb3NlZCBieSB0aGlzIHNlY3Rp b24gb2YgdGhpcyBkb2N1bWVudCBNQVkNCiAgIGJlIGFwcGVhbGVkIHRvIHRoZSBJRVNHIFtS RkMyMDI4XSB1bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhlciBJRVRGDQogICBkZWNpc2lv bnMgKHNlZSBbUkZDMjAyNl0pIGFuZCBNQVkgcmVzdWx0IGluIHRoZSBhdXRob3JpdHkgdG8g bWFpbnRhaW4NCiAgIHRoZSBleHRlbnNpb24gYmVpbmcgd2l0aGRyYXduIG9yIHJlYXNzaWdu ZWQgYnkgdGhlIElFU0cuDQogICAlJQ0KICAgSWRlbnRpZmllcjoNCiAgIERlc2NyaXB0aW9u Og0KICAgQ29tbWVudHM6DQogICBBZGRlZDoNCiAgIFJGQzoNCiAgIEF1dGhvcml0eToNCiAg IENvbnRhY3RfRW1haWw6DQogICBNYWlsaW5nX0xpc3Q6DQogICBVUkw6DQogICAlJQ0KDQog ICAgRmlndXJlIDU6IEZvcm1hdCBvZiBSZWNvcmRzIGluIHRoZSBMYW5ndWFnZSBUYWcgRXh0 ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICAnSWRlbnRpZmllcicgY29udGFpbnMgdGhlIHNpbmds ZS1jaGFyYWN0ZXIgc3VidGFnIChzaW5nbGV0b24pDQogICBhc3NpZ25lZCB0byB0aGUgZXh0 ZW5zaW9uLiAgVGhlIEludGVybmV0LURyYWZ0IHN1Ym1pdHRlZCB0byBkZWZpbmUNCiAgIHRo ZSBleHRlbnNpb24gU0hPVUxEIHNwZWNpZnkgd2hpY2ggbGV0dGVyIG9yIGRpZ2l0IHRvIHVz ZSwgYWx0aG91Z2gNCiAgIHRoZSBJRVNHIE1BWSBjaGFuZ2UgdGhlIGFzc2lnbm1lbnQgd2hl biBhcHByb3ZpbmcgdGhlIFJGQy4NCg0KICAgJ0Rlc2NyaXB0aW9uJyBjb250YWlucyB0aGUg bmFtZSBhbmQgZGVzY3JpcHRpb24gb2YgdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0NvbW1lbnRz JyBpcyBhbiBPUFRJT05BTCBmaWVsZCBhbmQgTUFZIGNvbnRhaW4gYSBicm9hZGVyIGRlc2Ny aXB0aW9uDQogICBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQWRkZWQnIGNvbnRhaW5zIHRo ZSBkYXRlIHRoZSBSRkMgd2FzIHB1Ymxpc2hlZCBpbiB0aGUgImZ1bGwtZGF0ZSINCiAgIGZv cm1hdCBzcGVjaWZpZWQgaW4gW1JGQzMzMzldLiAgRm9yIGV4YW1wbGU6IDIwMDQtMDYtMjgg cmVwcmVzZW50cw0KICAgSnVuZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRh ci4NCg0KICAgJ1JGQycgY29udGFpbnMgdGhlIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhl IGV4dGVuc2lvbi4NCg0KICAgJ0F1dGhvcml0eScgY29udGFpbnMgdGhlIG5hbWUgb2YgdGhl IG1haW50YWluaW5nIGF1dGhvcml0eSBmb3IgdGhlDQogICBleHRlbnNpb24uDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAg ICAgICAgICAgIFtQYWdlIDQyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgJ0Nv bnRhY3RfRW1haWwnIGNvbnRhaW5zIHRoZSBlbWFpbCBhZGRyZXNzIHVzZWQgdG8gY29udGFj dCB0aGUNCiAgIG1haW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgJ01haWxpbmdfTGlzdCcg Y29udGFpbnMgdGhlIFVSTCBvciBzdWJzY3JpcHRpb24gZW1haWwgYWRkcmVzcyBvZiB0aGUN CiAgIG1haWxpbmcgbGlzdCB1c2VkIGJ5IHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkuDQoN CiAgICdVUkwnIGNvbnRhaW5zIHRoZSBVUkwgb2YgdGhlIHJlZ2lzdHJ5IGZvciB0aGlzIGV4 dGVuc2lvbi4NCg0KICAgVGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhlciBhbiBJbnRlcm5l dC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAgIGNvbmRpdGlvbnMgYW5kIHRoZSBkZWNpc2lv biB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1dGhvcml0eSByZXN0cw0KICAgc29sZWx5 IHdpdGggdGhlIElFU0cgYW5kIGlzIHN1YmplY3QgdG8gdGhlIG5vcm1hbCByZXZpZXcgYW5k IGFwcGVhbHMNCiAgIHByb2Nlc3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBSRkMgcHJvY2Vzcy4N Cg0KICAgRXh0ZW5zaW9uIGF1dGhvcnMgYXJlIHN0cm9uZ2x5IGNhdXRpb25lZCB0aGF0IG1h bnkgKGluY2x1ZGluZyBtb3N0DQogICB3ZWxsLWZvcm1lZCkgcHJvY2Vzc29ycyB3aWxsIGJl IHVuYXdhcmUgb2YgYW55IHNwZWNpYWwgcmVsYXRpb25zaGlwcw0KICAgb3IgbWVhbmluZyBp bmhlcmVudCBpbiB0aGUgb3JkZXIgb2YgZXh0ZW5zaW9uIHN1YnRhZ3MuICBFeHRlbnNpb24N CiAgIGF1dGhvcnMgU0hPVUxEIGF2b2lkIHN1YnRhZyByZWxhdGlvbnNoaXBzIG9yIGNhbm9u aWNhbGl6YXRpb24NCiAgIG1lY2hhbmlzbXMgdGhhdCBpbnRlcmZlcmUgd2l0aCBtYXRjaGlu ZyBvciB3aXRoIGxlbmd0aCByZXN0cmljdGlvbnMNCiAgIHRoYXQgc29tZXRpbWVzIGV4aXN0 IGluIGNvbW1vbiBwcm90b2NvbHMgd2hlcmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkLg0KICAg SW4gcGFydGljdWxhciwgYXBwbGljYXRpb25zIE1BWSB0cnVuY2F0ZSB0aGUgc3VidGFncyBp biBkb2luZw0KICAgbWF0Y2hpbmcgb3IgaW4gZml0dGluZyBpbnRvIGxpbWl0ZWQgbGVuZ3Ro cywgc28gaXQgaXMgUkVDT01NRU5ERUQNCiAgIHRoYXQgdGhlIG1vc3Qgc2lnbmlmaWNhbnQg aW5mb3JtYXRpb24gYmUgaW4gdGhlIG1vc3Qgc2lnbmlmaWNhbnQNCiAgIChsZWZ0LW1vc3Qp IHN1YnRhZ3MgYW5kIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gZ3JhY2VmdWxseSBoYW5kbGUN CiAgIHRydW5jYXRlZCBzdWJ0YWdzLg0KDQogICBXaGVuIGEgbGFuZ3VhZ2UgdGFnIGlzIHRv IGJlIHVzZWQgaW4gYSBzcGVjaWZpYywga25vd24sIHByb3RvY29sLCBpdA0KICAgaXMgUkVD T01NRU5ERUQgdGhhdCB0aGF0IHRoZSBsYW5ndWFnZSB0YWcgbm90IGNvbnRhaW4gZXh0ZW5z aW9ucyBub3QNCiAgIHN1cHBvcnRlZCBieSB0aGF0IHByb3RvY29sLiAgSW4gYWRkaXRpb24s IG5vdGUgdGhhdCBzb21lIHByb3RvY29scw0KICAgTUFZIGltcG9zZSB1cHBlciBsaW1pdHMg b24gdGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5ncyB1c2VkIHRvIHN0b3JlIG9yDQogICB0cmFu c3BvcnQgdGhlIGxhbmd1YWdlIHRhZy4NCg0KMy44LiAgVXBkYXRlIG9mIHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmVnaXN0cnkNCg0KICAgVXBvbiBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB3aWxsDQogICBuZWVkIGFuIHVw ZGF0ZSBzbyB0aGF0IGl0IGNvbnRhaW5zIHRoZSBjb21wbGV0ZSBzZXQgb2Ygc3VidGFncyB2 YWxpZA0KICAgaW4gYSBsYW5ndWFnZSB0YWcuICBUaGlzIGNvbGxlY3Rpb24gb2Ygc3VidGFn cywgYWxvbmcgd2l0aCBhDQogICBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2VzcyB1c2VkIHRv IGNyZWF0ZSBpdCwgaXMgZGVzY3JpYmVkIGJ5DQogICBbcmVnaXN0cnktdXBkYXRlXS4gIElB TkEgd2lsbCBwdWJsaXNoIHRoZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhlDQogICByZWdpc3Ry eSBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudCB1c2luZyB0aGUgaW5zdHJ1Y3Rpb25zIGFu ZA0KICAgY29udGVudCBvZiBbcmVnaXN0cnktdXBkYXRlXS4gIE9uY2UgcHVibGlzaGVkIGJ5 IElBTkEsIHRoZQ0KICAgbWFpbnRlbmFuY2UgcHJvY2VkdXJlcywgcnVsZXMsIGFuZCByZWdp c3RyYXRpb24gcHJvY2Vzc2VzIGRlc2NyaWJlZA0KICAgaW4gdGhpcyBkb2N1bWVudCB3aWxs IGJlIGF2YWlsYWJsZSBmb3IgbmV3IHJlZ2lzdHJhdGlvbnMgb3IgdXBkYXRlcy4NCg0KICAg UmVnaXN0cmF0aW9ucyB0aGF0IGFyZSBpbiBwcm9jZXNzIHVuZGVyIHRoZSBydWxlcyBkZWZp bmVkIGluDQogICBbUkZDNDY0Nl0gd2hlbiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgTVVT VCBiZSBjb21wbGV0ZWQgdW5kZXIgdGhlDQogICBydWxlcyBjb250YWluZWQgaW4gdGhpcyBk b2N1bWVudC4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSA0M10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1 c3QgMjAwNw0KDQoNCjQuICBGb3JtYXRpb24gYW5kIFByb2Nlc3Npbmcgb2YgTGFuZ3VhZ2Ug VGFncw0KDQogICBUaGlzIHNlY3Rpb24gYWRkcmVzc2VzIGhvdyB0byB1c2UgdGhlIGluZm9y bWF0aW9uIGluIHRoZSByZWdpc3RyeQ0KICAgd2l0aCB0aGUgdGFnIHN5bnRheCB0byBjaG9v c2UsIGZvcm0sIGFuZCBwcm9jZXNzIGxhbmd1YWdlIHRhZ3MuDQoNCjQuMS4gIENob2ljZSBv ZiBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIGd1aWRpbmcgcHJpbmNpcGxlIGluIGZvcm1pbmcg bGFuZ3VhZ2UgdGFncyBpcyB0byAidGFnIGNvbnRlbnQNCiAgIHdpc2VseS4iICBTb21ldGlt ZXMgdGhlcmUgaXMgYSBjaG9pY2UgYmV0d2VlbiBzZXZlcmFsIHBvc3NpYmxlIHRhZ3MNCiAg IGZvciB0aGUgc2FtZSBjb250ZW50LiAgVGhlIGNob2ljZSBvZiB3aGljaCB0YWcgdG8gdXNl IGRlcGVuZHMgb24gdGhlDQogICBjb250ZW50IGFuZCBhcHBsaWNhdGlvbiBpbiBxdWVzdGlv biBhbmQgc29tZSBhbW91bnQgb2YganVkZ21lbnQgbWlnaHQNCiAgIGJlIG5lY2Vzc2FyeSB3 aGVuIHNlbGVjdGluZyBhIHRhZy4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBpcyBiZXN0IHNl cnZlZCB3aGVuIHRoZSBzYW1lIGxhbmd1YWdlIHRhZyBpcyB1c2VkDQogICBjb25zaXN0ZW50 bHkgdG8gcmVwcmVzZW50IHRoZSBzYW1lIGxhbmd1YWdlLiAgSWYgYW4gYXBwbGljYXRpb24g aGFzDQogICByZXF1aXJlbWVudHMgdGhhdCBtYWtlIHRoZSBydWxlcyBoZXJlIGluYXBwbGlj YWJsZSwgdGhlbiB0aGF0DQogICBhcHBsaWNhdGlvbiByaXNrcyBkYW1hZ2luZyBpbnRlcm9w ZXJhYmlsaXR5LiAgSXQgaXMgc3Ryb25nbHkNCiAgIFJFQ09NTUVOREVEIHRoYXQgdXNlcnMg bm90IGRlZmluZSB0aGVpciBvd24gcnVsZXMgZm9yIGxhbmd1YWdlIHRhZw0KICAgY2hvaWNl Lg0KDQogICBBIHN1YnRhZyBTSE9VTEQgb25seSBiZSB1c2VkIHdoZW4gaXQgYWRkcyB1c2Vm dWwgZGlzdGluZ3Vpc2hpbmcNCiAgIGluZm9ybWF0aW9uIHRvIHRoZSB0YWcuICBFeHRyYW5l b3VzIHN1YnRhZ3MgaW50ZXJmZXJlIHdpdGggdGhlDQogICBtZWFuaW5nLCB1bmRlcnN0YW5k aW5nLCBhbmQgcHJvY2Vzc2luZyBvZiBsYW5ndWFnZSB0YWdzLiAgSW4NCiAgIHBhcnRpY3Vs YXIsIHVzZXJzIGFuZCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0aGUgJ1ByZWZp eCcgYW5kDQogICAnU3VwcHJlc3MtU2NyaXB0JyBmaWVsZHMgaW4gdGhlIHJlZ2lzdHJ5IChk ZWZpbmVkIGluIFNlY3Rpb24gMy4xKToNCiAgIHRoZXNlIGZpZWxkcyBwcm92aWRlIGd1aWRh bmNlIG9uIHdoZW4gc3BlY2lmaWMgYWRkaXRpb25hbCBzdWJ0YWdzDQogICBTSE9VTEQgYmUg dXNlZCBvciBhdm9pZGVkIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBTb21lIGFwcGxpY2F0 aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2Ygc2NyaXB0IHN1YnRhZ3MgaW4NCiAg IGxhbmd1YWdlIHRhZ3MsIGFzIGxvbmcgYXMgdGhlIHVzZSBpcyBjb25zaXN0ZW50IGZvciBh IGdpdmVuIGNvbnRleHQuDQogICBTY3JpcHQgc3VidGFncyBhcmUgbmV2ZXIgYXBwcm9wcmlh dGUgZm9yIHVud3JpdHRlbiBjb250ZW50IChzdWNoIGFzDQogICBhdWRpbyByZWNvcmRpbmdz KS4NCg0KICAgU2NyaXB0IHN1YnRhZ3Mgd2VyZSBub3QgZm9ybWFsbHkgZGVmaW5lZCBpbiBb UkZDMzA2Nl0gYW5kIHRoZWlyIHVzZQ0KICAgY2FuIGFmZmVjdCBtYXRjaGluZyBhbmQgc3Vi dGFnIGlkZW50aWZpY2F0aW9uIGZvciBpbXBsZW1lbnRhdGlvbnMgb2YNCiAgIFJGQyAzMDY2 LCBhcyB0aGVzZSBzdWJ0YWdzIGFwcGVhciBiZXR3ZWVuIHRoZSBwcmltYXJ5IGxhbmd1YWdl IGFuZA0KICAgcmVnaW9uIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgYW4gaW1wbGVtZW50 YXRpb24gc2VsZWN0cyBjb250ZW50DQogICB1c2luZyBCYXNpYyBGaWx0ZXJpbmcgW1JGQzQ2 NDddIChvcmlnaW5hbGx5IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuNQ0KICAgb2YgW1JGQzMw NjZdKSBhbmQgdGhlIHVzZXIgcmVxdWVzdGVkIHRoZSBsYW5ndWFnZSByYW5nZSAiZW4tVVMi LA0KICAgY29udGVudCBsYWJlbGVkICJlbi1MYXRuLVVTIiB3aWxsIG5vdCBtYXRjaCB0aGUg cmVxdWVzdCBhbmQgdGh1cyBub3QNCiAgIGJlIHNlbGVjdGVkLiAgVGhlcmVmb3JlLCBpdCBp cyBpbXBvcnRhbnQgdG8ga25vdyB3aGVuIHNjcmlwdCBzdWJ0YWdzDQogICB3aWxsIGN1c3Rv bWFyaWx5IGJlIHVzZWQgYW5kIHdoZW4gdGhleSBvdWdodCBub3QgYmUgdXNlZC4gIEluIHRo ZQ0KICAgcmVnaXN0cnksIHRoZSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgaGVscHMgZW5zdXJl IGdyZWF0ZXINCiAgIGNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UgdGFncyBi eSBkZWZpbmluZyB3aGVuIHVzZXJzIFNIT1VMRA0KICAgTk9UIGluY2x1ZGUgYSBzY3JpcHQg c3VidGFnIHdpdGggYSBwYXJ0aWN1bGFyIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1YnRhZy4N Cg0KICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyAodHlwZSAnZXh0bGFuZycgaW4gdGhl IHJlZ2lzdHJ5OyBzZWUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDQ0XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA3DQoNCg0KICAgU2VjdGlvbiAzLjEpIGFsc28gYXBwZWFyIGJldHdlZW4gdGhl IHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHN1YnNlcXVlbnQNCiAgIChzY3JpcHQsIHJlZ2lvbiwg b3IgdmFyaWFudCkgc3VidGFncy4gIEluIG1vc3QgY2FzZXMsIHVzZSB0aGUNCiAgIE1hY3Jv bGFuZ2F1Z2UgKGluZGljYXRlZCBieSB0aGUgUHJlZml4KSBieSBpdHNlbGYgdG8gZm9ybSB0 aGUNCiAgIGxhbmd1YWdlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIGluY2x1ZGluZyB0aGUgZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLg0KICAgT25seSB1c2UgdGhlIGV4dGVuZGVkIGxhbmd1 YWdlIHN1YnRhZyBpZiBpdCBhZGRzIHVzZWZ1bA0KICAgZGlzdGluZ3Vpc2hpbmcgaW5mb3Jt YXRpb24gdG8gdGhlIHRhZyB3aXRoaW4geW91ciBhcHBsaWNhdGlvbi4NCg0KICAgVGhlIGNo b2ljZSBvZiBzdWJ0YWdzIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZyBTSE9VTEQgYmUg Z3VpZGVkIGJ5DQogICB0aGUgZm9sbG93aW5nIHJ1bGVzOg0KDQogICAxLiAgVXNlIGFzIHBy ZWNpc2UgYSB0YWcgYXMgcG9zc2libGUsIGJ1dCBubyBtb3JlIHNwZWNpZmljIHRoYW4gaXMN CiAgICAgICBqdXN0aWZpZWQuICBBdm9pZCB1c2luZyBzdWJ0YWdzIHRoYXQgYXJlIG5vdCBp bXBvcnRhbnQgZm9yDQogICAgICAgZGlzdGluZ3Vpc2hpbmcgY29udGVudCBpbiBhbiBhcHBs aWNhdGlvbi4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCAnZGUnIG1pZ2h0IHN1ZmZpY2Ug Zm9yIHRhZ2dpbmcgYW4gZW1haWwgd3JpdHRlbg0KICAgICAgICAgIGluIEdlcm1hbiwgd2hp bGUgImRlLUNILTE5OTYiIGlzIHByb2JhYmx5IHVubmVjZXNzYXJpbHkNCiAgICAgICAgICBw cmVjaXNlIGZvciBzdWNoIGEgdGFzay4NCg0KICAgMi4gIFRoZSBzY3JpcHQgc3VidGFnIFNI T1VMRCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MgdW5sZXNzDQogICAgICAg dGhlIHNjcmlwdCBhZGRzIHNvbWUgZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gdGhl IHRhZy4gIFRoZQ0KICAgICAgIGZpZWxkICdTdXBwcmVzcy1TY3JpcHQnIGluIHRoZSBwcmlt YXJ5IGxhbmd1YWdlIHJlY29yZCBpbiB0aGUNCiAgICAgICByZWdpc3RyeSBpbmRpY2F0ZXMg c2NyaXB0IHN1YnRhZ3MgdGhhdCBkbyBub3QgYWRkIGRpc3Rpbmd1aXNoaW5nDQogICAgICAg aW5mb3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLiAgRm9yIGV4YW1wbGU6DQoNCiAg ICAgICAqICBUaGUgc3VidGFnICdMYXRuJyBzaG91bGQgbm90IGJlIHVzZWQgd2l0aCB0aGUg cHJpbWFyeSBsYW5ndWFnZQ0KICAgICAgICAgICdlbicgYmVjYXVzZSBuZWFybHkgYWxsIEVu Z2xpc2ggZG9jdW1lbnRzIGFyZSB3cml0dGVuIGluIHRoZQ0KICAgICAgICAgIExhdGluIHNj cmlwdCBhbmQgaXQgYWRkcyBubyBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbi4NCiAgICAg ICAgICBIb3dldmVyLCBpZiBhIGRvY3VtZW50IHdlcmUgd3JpdHRlbiBpbiBFbmdsaXNoIG1p eGluZyBMYXRpbg0KICAgICAgICAgIHNjcmlwdCB3aXRoIGFub3RoZXIgc2NyaXB0IHN1Y2gg YXMgQnJhaWxsZSAoJ0JyYWknKSwgdGhlbiBpdA0KICAgICAgICAgIG1pZ2h0IGJlIGFwcHJv cHJpYXRlIHRvIGNob29zZSB0byBpbmRpY2F0ZSBib3RoIHNjcmlwdHMgdG8gYWlkDQogICAg ICAgICAgaW4gY29udGVudCBzZWxlY3Rpb24sIHN1Y2ggYXMgdGhlIGFwcGxpY2F0aW9uIG9m IGEgc3R5bGUNCiAgICAgICAgICBzaGVldC4NCg0KICAgICAgICogIFdoZW4gbGFiZWxpbmcg Y29udGVudCB0aGF0IGlzIHVud3JpdHRlbiAoc3VjaCBhcyBhIHJlY29yZGluZw0KICAgICAg ICAgIG9mIGh1bWFuIHNwZWVjaCksIHRoZSBzY3JpcHQgc3VidGFnIHNob3VsZCBub3QgYmUg dXNlZCwgZXZlbg0KICAgICAgICAgIGlmIHRoZSBsYW5ndWFnZSBpcyBjdXN0b21hcmlseSB3 cml0dGVuIGluIHNldmVyYWwgc2NyaXB0cy4NCiAgICAgICAgICBUaHVzIHRoZSBzdWJ0aXRs ZXMgdG8gYSBtb3ZpZSBtaWdodCB1c2UgdGhlIHRhZyAiemgtY21uLUhhbnQiDQogICAgICAg ICAgKENoaW5lc2UsIE1hbmRhcmluLCBUcmFkaXRpb25hbCBzY3JpcHQpLCBidXQgdGhlIGF1 ZGlvIHRyYWNrDQogICAgICAgICAgZm9yIHRoZSBzYW1lIGxhbmd1YWdlIHdvdWxkIGJlIHRh Z2dlZCAiemgtY21uIi4NCg0KICAgMy4gIElmIGEgdGFnIG9yIHN1YnRhZyBoYXMgYSAnUHJl ZmVycmVkLVZhbHVlJyBmaWVsZCBpbiBpdHMgcmVnaXN0cnkNCiAgICAgICBlbnRyeSwgdGhl biB0aGUgdmFsdWUgb2YgdGhhdCBmaWVsZCBTSE9VTEQgYmUgdXNlZCB0byBmb3JtIHRoZQ0K ICAgICAgIGxhbmd1YWdlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIHRoZSB0YWcgb3Igc3VidGFn IGluIHdoaWNoIHRoZQ0KICAgICAgIHByZWZlcnJlZCB2YWx1ZSBhcHBlYXJzLg0KDQogICAg ICAgKiAgRm9yIGV4YW1wbGUsIHVzZSAnaGUnIGZvciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0 byAnaXcnLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDQ1XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA3DQoNCg0KICAgNC4gIFtJU082MzktMl0gaGFzIGRlZmluZWQgc2V2ZXJhbCBjb2Rl cyBpbmNsdWRlZCBpbiB0aGUgc3VidGFnDQogICAgICAgcmVnaXN0cnkgdGhhdCByZXF1aXJl IGFkZGl0aW9uYWwgY2FyZSB3aGVuIGNob29zaW5nIGxhbmd1YWdlDQogICAgICAgdGFncy4g IEluIG1vc3Qgb2YgdGhlc2UgY2FzZXMsIHdoZXJlIG9taXR0aW5nIHRoZSBsYW5ndWFnZSB0 YWcgaXMNCiAgICAgICBwZXJtaXR0ZWQsIHN1Y2ggb21pc3Npb24gaXMgcHJlZmVyYWJsZSB0 byB1c2luZyB0aGVzZSBjb2Rlcy4NCiAgICAgICBMYW5ndWFnZSB0YWdzIFNIT1VMRCBOT1Qg aW5jb3Jwb3JhdGUgdGhlc2Ugc3VidGFncyBhcyBhIHByZWZpeCwNCiAgICAgICB1bmxlc3Mg dGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gY29udmV5cyBzb21lIHZhbHVlIHRvIHRoZQ0K ICAgICAgIGFwcGxpY2F0aW9uLg0KDQogICAgICAgMS4gIFVzZSBzcGVjaWZpYyBsYW5ndWFn ZSBzdWJ0YWdzIG9yIHN1YnRhZyBzZXF1ZW5jZXMgaW4NCiAgICAgICAgICAgcHJlZmVyZW5j ZSB0byBzdWJ0YWdzIGZvciBsYW5ndWFnZSBjb2xsZWN0aW9ucy4gIEEgImxhbmd1YWdlDQog ICAgICAgICAgIGNvbGxlY3Rpb24iIGlzIGEgc3VidGFnIGRlcml2ZWQgZnJvbSBvbmUgb2Yg dGhlIFtJU082MzktMl0NCiAgICAgICAgICAgY29kZXMgdGhhdCByZXByZXNlbnRzIG11bHRp cGxlIHJlbGF0ZWQgbGFuZ3VhZ2VzLiAgVGhlc2UNCiAgICAgICAgICAgY29kZXMgYXJlIGlu Y2x1ZGVkIGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBpbiB0aGUNCiAgICAgICAgICAg cmVnaXN0cnkuICBGb3IgZXhhbXBsZSwgdGhlIGNvZGUgJ2NtYycgcmVwcmVzZW50cyAiQ2hh bWljDQogICAgICAgICAgIGxhbmd1YWdlcyIuICBUaGUgcmVnaXN0cnkgY29udGFpbnMgdmFs dWVzIGZvciBlYWNoIG9mIHRoZQ0KICAgICAgICAgICBhcHByb3hpbWF0ZWx5IHRlbiBpbmRp dmlkdWFsIGxhbmd1YWdlcyByZXByZXNlbnRlZCBieSB0aGlzDQogICAgICAgICAgIGNvbGxl Y3RpdmUgY29kZS4gIFNvbWUgb3RoZXIgZXhhbXBsZXMgaW5jbHVkZSB0aGUgc3VidGFncw0K ICAgICAgICAgICBHZXJtYW5pYyBsYW5ndWFnZXMgKCdnZW0nKSBvciBBbGdvbnF1aWFuIGxh bmd1YWdlcyAoJ2FsZycpLg0KICAgICAgICAgICBTaW5jZSB0aGVzZSBjb2RlcyBhcmUgaW50 ZXJwcmV0ZWQgaW5jbHVzaXZlbHksIGNvbnRlbnQgdGFnZ2VkDQogICAgICAgICAgIHdpdGgg ImVuIiAoRW5nbGlzaCksICJkZSIgKEdlcm1hbiksIG9yICJnc3ciIChTd2lzcyBHZXJtYW4s DQogICAgICAgICAgIEFsZW1hbm5pYykgY291bGQgYWxzbyAoYnV0IFNIT1VMRCBOT1QpIGJl IHRhZ2dlZCB3aXRoICJnZW0iDQogICAgICAgICAgIChHZXJtYW5pYyBsYW5ndWFnZXMpLiAg U3VidGFncyBkZXJpdmVkIGZyb20gY29sbGVjdGlvbiBjb2Rlcw0KICAgICAgICAgICBTSE9V TEQgTk9UIGJlIHVzZWQgYmUgdXNlZCB1bmxlc3MgbW9yZSBzcGVjaWZpYyBsYW5ndWFnZQ0K ICAgICAgICAgICBpbmZvcm1hdGlvbiBpcyBub3QgYXZhaWxhYmxlLiAgTm90ZSB0aGF0IG1h dGNoaW5nDQogICAgICAgICAgIGltcGxlbWVudGF0aW9ucyBnZW5lcmFsbHkgZG8gbm90IHVu ZGVyc3RhbmQgdGhlIHJlbGF0aW9uc2hpcA0KICAgICAgICAgICBiZXR3ZWVuIHRoZSBjb2xs ZWN0aW9uIGFuZCBpdHMgZW5jb21wYXNzZWQgbGFuZ3VhZ2VzLCBhbmQgc28NCiAgICAgICAg ICAgdXNlcnMgb3VnaHQgbm90IGFzc3VtZSBhIHN1YnRhZyBiYXNlZCBvbiBhIGxhbmd1YWdl DQogICAgICAgICAgIGNvbGxlY3Rpb24gaXMgYSB1c2VmdWwgbWVhbnMgZm9yIHNlbGVjdGlu ZyBjb250ZW50IGluIGl0cw0KICAgICAgICAgICBlbmNvbXBhc3NlZCBsYW5ndWFnZXMuDQoN CiAgICAgICAyLiAgVGhlICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0 YWcgaWRlbnRpZmllcw0KICAgICAgICAgICBjb250ZW50IGluIG11bHRpcGxlIGxhbmd1YWdl cy4gIEl0IFNIT1VMRCBOT1QgYmUgdXNlZCB3aGVuIGENCiAgICAgICAgICAgbGlzdCBvZiBs YW5ndWFnZXMgKHN1Y2ggYXMgQ29udGVudC1MYW5ndWFnZSkgb3IgaW5kaXZpZHVhbA0KICAg ICAgICAgICB0YWdzIGZvciBlYWNoIGNvbnRlbnQgZWxlbWVudCBjYW4gYmUgdXNlZCBpbnN0 ZWFkLg0KDQogICAgICAgMy4gIFRoZSAndW5kJyAoVW5kZXRlcm1pbmVkKSBwcmltYXJ5IGxh bmd1YWdlIHN1YnRhZyBpZGVudGlmaWVzDQogICAgICAgICAgIGxpbmd1aXN0aWMgY29udGVu dCB3aG9zZSBsYW5ndWFnZSBpcyBub3Qga25vd24uICBJdCBTSE9VTEQNCiAgICAgICAgICAg Tk9UIGJlIHVzZWQgdW5sZXNzIGEgbGFuZ3VhZ2UgdGFnIGlzIHJlcXVpcmVkIGFuZCBsYW5n dWFnZQ0KICAgICAgICAgICBpbmZvcm1hdGlvbiBpcyBub3QgYXZhaWxhYmxlIG9yIGNhbm5v dCBiZSBkZXRlcm1pbmVkLg0KICAgICAgICAgICBPbWl0dGluZyB0aGUgbGFuZ3VhZ2UgdGFn ICh3aGVyZSBwZXJtaXR0ZWQpIGlzIHByZWZlcnJlZC4NCiAgICAgICAgICAgVGhlICd1bmQn IHN1YnRhZyBNQVkgYmUgdXNlZnVsIGZvciBwcm90b2NvbHMgdGhhdCByZXF1aXJlIGENCiAg ICAgICAgICAgbGFuZ3VhZ2UgdGFnIHRvIGJlIHByb3ZpZGVkIG9yIHdoZXJlIGEgcHJpbWFy eSBsYW5ndWFnZQ0KICAgICAgICAgICBzdWJ0YWcgaXMgcmVxdWlyZWQgKHN1Y2ggYXMgaW4g InVuZC1MYXRuIikuICBUaGUgJ3VuZCcgc3VidGFnDQogICAgICAgICAgIE1BWSBhbHNvIGJl IHVzZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbg0KICAgICAg ICAgICBzaXR1YXRpb25zLg0KDQogICAgICAgNC4gIFRoZSAnenh4JyAoTm9uLUxpbmd1aXN0 aWMpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlkZW50aWZpZXMNCiAgICAgICAgICAgY29u dGVudCB0aGF0IGhhcyBubyBsYW5ndWFnZS4gIFNvbWUgZXhhbXBsZXMgbWlnaHQgaW5jbHVk ZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwg MjAwOCAgICAgICAgICAgICAgW1BhZ2UgNDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0K DQogICAgICAgICAgIGluc3RydW1lbnRhbCBvciBlbGVjdHJvbmljIG11c2ljOyBzb3VuZCBy ZWNvcmRpbmdzIGNvbnNpc3RpbmcNCiAgICAgICAgICAgb2Ygbm9udmVyYmFsIHNvdW5kczsg YXVkaW92aXN1YWwgbWF0ZXJpYWxzIHdpdGggbm8gbmFycmF0aW9uLA0KICAgICAgICAgICBw cmludGVkIHRpdGxlcywgb3Igc3VidGl0bGVzOyBtYWNoaW5lLXJlYWRhYmxlIGRhdGEgZmls ZXMNCiAgICAgICAgICAgY29uc2lzdGluZyBvZiBtYWNoaW5lIGxhbmd1YWdlcyBvciBjaGFy YWN0ZXIgY29kZXM7IG9yDQogICAgICAgICAgIHByb2dyYW1taW5nIHNvdXJjZSBjb2RlLiAg Tm90ZTogd2hlcmUgdGhlcmUgYXJlIGZyYWdtZW50cyBvZg0KICAgICAgICAgICBsaW5ndWlz dGljIGNvbnRlbnQsIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgc291cmNlIGNvZGUNCiAgICAgICAg ICAgY29udGFpbmluZyBjb21tZW50cyB3cml0dGVuIGluIEVuZ2xpc2gsIHRoZSBzdWJ0YWcg J3p4eCcNCiAgICAgICAgICAgbWlnaHQgc3RpbGwgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUg cHJpbWFyeSBzdGF0dXMgb2YgdGhlDQogICAgICAgICAgIGNvbnRlbnQsIGp1c3QgYXMgJ2Vu JyBjYW4gYmUgYXBwbGllZCB0byBhIHByZWRvbWluYW50bHkNCiAgICAgICAgICAgRW5nbGlz aCB0ZXh0IHRoYXQgY29udGFpbnMgYSBmZXcgRnJlbmNoIHBocmFzZXMuDQoNCiAgICAgICA1 LiAgVGhlICdtaXMnIChVbmNvZGVkKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpZGVudGlm aWVzDQogICAgICAgICAgIGNvbnRlbnQgd2hvc2UgbGFuZ3VhZ2UgaXMga25vd24gYnV0IHdo aWNoIGRvZXMgbm90IGN1cnJlbnRseQ0KICAgICAgICAgICBoYXZlIGEgY29ycmVzcG9uZGlu ZyBzdWJ0YWcuICBUaGlzIHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQuDQogICAgICAgICAg IEJlY2F1c2UgdGhlIGFkZGl0aW9uIG9mIG90aGVyIGNvZGVzIGluIHRoZSBmdXR1cmUgY2Fu IHJlbmRlcg0KICAgICAgICAgICBpdHMgYXBwbGljYXRpb24gaW52YWxpZCwgaXQgaXMgaW5o ZXJlbnRseSB1bnN0YWJsZSBhbmQgaGVuY2UNCiAgICAgICAgICAgaW5jb21wYXRpYmxlIHdp dGggdGhlIHN0YWJpbGl0eSBnb2FscyBvZiBCQ1AgNDcuICBJdCBpcw0KICAgICAgICAgICBh bHdheXMgcHJlZmVyYWJsZSB0byB1c2Ugb3RoZXIgc3VidGFnczogZWl0aGVyICd1bmQnIG9y ICh3aXRoDQogICAgICAgICAgIHByaW9yIGFncmVlbWVudCkgcHJpdmF0ZSB1c2Ugc3VidGFn cy4NCg0KICAgICAgIDYuICBUaGUgZ3JhbmRmYXRoZXJlZCB0YWcgImktZGVmYXVsdCIgKERl ZmF1bHQgTGFuZ3VhZ2UpIHdhcw0KICAgICAgICAgICBvcmlnaW5hbGx5IHJlZ2lzdGVyZWQg YWNjb3JkaW5nIHRvIFtSRkMxNzY2XSB0byBtZWV0IHRoZQ0KICAgICAgICAgICBuZWVkcyBv ZiBbUkZDMjI3N10uICBJdCBpcyB1c2VkIHRvIGluZGljYXRlIG5vdCBhIHNwZWNpZmljDQog ICAgICAgICAgIGxhbmd1YWdlLCBidXQgcmF0aGVyLCBpdCBpZGVudGlmaWVzIHRoZSBjb25k aXRpb24gb3IgY29udGVudA0KICAgICAgICAgICB1c2VkIHdoZXJlIHRoZSBsYW5ndWFnZSBw cmVmZXJlbmNlcyBvZiB0aGUgdXNlciBjYW5ub3QgYmUNCiAgICAgICAgICAgZXN0YWJsaXNo ZWQuICBJdCBTSE9VTEQgTk9UIGJlIHVzZWQgZXhjZXB0IGFzIGEgbWVhbnMgb2YNCiAgICAg ICAgICAgbGFiZWxpbmcgdGhlIGRlZmF1bHQgY29udGVudCBmb3IgYXBwbGljYXRpb25zIG9y IHByb3RvY29scw0KICAgICAgICAgICB0aGF0IHJlcXVpcmUgZGVmYXVsdCBsYW5ndWFnZSBj b250ZW50IHRvIGJlIGxhYmVsZWQgd2l0aCB0aGF0DQogICAgICAgICAgIHNwZWNpZmljIHRh Zy4gIEl0IE1BWSBhbHNvIGJlIHVzZWQgYnkgYW4gYXBwbGljYXRpb24gb3INCiAgICAgICAg ICAgcHJvdG9jb2wgdG8gaWRlbnRpZnkgd2hlbiB0aGUgZGVmYXVsdCBsYW5ndWFnZSBjb250 ZW50IGlzDQogICAgICAgICAgIGJlaW5nIHJldHVybmVkLg0KDQogICA1LiAgVGhlIHNhbWUg dmFyaWFudCBzdWJ0YWcgTVVTVCBOT1QgYmUgdXNlZCBtb3JlIHRoYW4gb25jZSB3aXRoaW4g YQ0KICAgICAgIGxhbmd1YWdlIHRhZy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCB0aGUg dGFnICJkZS1ERS0xOTAxLTE5MDEiIGlzIG5vdCB2YWxpZC4NCg0KICAgTGFuZ3VhZ2VzIHdp dGggYSBNYWNyb2xhbmd1YWdlIGZpZWxkIGluIHRoZSByZWdpc3RyeSBzb21ldGltZXMgY2Fu IGJlDQogICB1c2VmdWxseSByZWZlcmVuY2VkIHVzaW5nIHRoZWlyIE1hY3JvbGFuZ3VhZ2Uu ICBIb3dldmVyLCB0aGUNCiAgIE1hY3JvbGFuZ3VhZ2UgZmllbGQgZG9lc24ndCBkZWZpbmUg d2hhdCB0aGUgcmVsYXRpb25zaGlwIGlzIGJldHdlZW4NCiAgIHRoZSBsYW5ndWFnZSBzdWJ0 YWcgd2hvc2UgcmVjb3JkIGl0IGFwcGVhcnMgaW4gYW5kIGl0cyBlbmNvbXBhc3NlZA0KICAg bGFuZ3VhZ2Ugb3IgbGFuZ3VhZ2VzLiAgTm9yIGRvZXMgaXQgZGVmaW5lIGhvdyB0aGUgZW5j b21wYXNzZWQNCiAgIGxhbmd1YWdlcyBhcmUgcmVsYXRlZCB0byBvbmUtYW5vdGhlci4gIElu IHNvbWUgY2FzZXMsIHRoZQ0KICAgTWFjcm9sYW5ndWFnZSBoYXMgYSBzdGFuZGFyZCBmb3Jt IGFzIHdlbGwgYXMgYSB2YXJpZXR5IG9mIGxlc3MtY29tbW9uDQogICBkaWFsZWN0cy4gIElu IG90aGVyIGNhc2VzIHRoZXJlIGlzIG5vIHBhcnRpY3VsYXIgc3RhbmRhcmQgZm9ybSBhbmQN CiAgIHRoZSBlbmNvbXBhc3NlZCBzdWJ0YWdzIGRlc2NyaWJlIHNwZWNpZmljIHZhcmlhdGlv bnMgd2l0aGluIHRoZQ0KICAgcGFyZW50IGxhbmd1YWdlLg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBb UGFnZSA0N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIEFwcGxpY2F0aW9ucyBN QVkgdXNlIE1hY3JvbGFuZ3VhZ2UgaW5mb3JtYXRpb24gdG8gaW1wcm92ZSBtYXRjaGluZyBv cg0KICAgbGFuZ3VhZ2UgbmVnb3RpYXRpb24uICBGb3IgZXhhbXBsZSwgdGhlIGluZm9ybWF0 aW9uIHRoYXQgJ3NyJw0KICAgKFNlcmJpYW4pIGFuZCAnaHInIChDcm9hdGlhbikgc2hhcmUg YSBNYWNyb2xhbmd1YWdlIGV4cHJlc3NlcyBhDQogICBjbG9zZXIgcmVsYXRpb24gYmV0d2Vl biB0aG9zZSBsYW5ndWFnZXMgdGhhbiBiZXR3ZWVuLCBzYXksICdzcicNCiAgIChTZXJiaWFu KSBhbmQgJ21hJyAoTWFjZWRvbmlhbikuICBJdCBpcyB2YWxpZCB0byB1c2UgdGhlIGVuY29t cGFzc2VkDQogICBsYW5ndWFnZSBvciBqdXN0IGl0cyBNYWNyb2xhbmd1YWdlIHRvIGZvcm0g bGFuZ3VhZ2UgdGFncy4gIEhvd2V2ZXIsDQogICBtYW55IG1hdGNoaW5nIGFwcGxpY2F0aW9u cyB3aWxsIG5vdCBiZSBhd2FyZSBvZiB0aGUgcmVsYXRpb25zaGlwDQogICBiZXR3ZWVuIHRo ZSBsYW5ndWFnZXMuICBDYXJlIGluIHNlbGVjdGluZyB3aGljaCBzdWJ0YWdzIGFyZSB1c2Vk IGlzDQogICBjcnVjaWFsIHRvIGludGVyb3BlcmFiaWxpdHkuICBJbiBnZW5lcmFsLCB1c2Ug dGhlIG1vc3Qgc3BlY2lmaWMgdGFnLg0KICAgSG93ZXZlciwgd2hlcmUgdGhlIHN0YW5kYXJk IGZvcm0gb2YgYW4gZW5jb21wYXNzZWQgbGFuZ3VhZ2UgaXMNCiAgIGNhcHR1cmVkIGJ5IHRo ZSBNYWNyb2xhbmd1YWdlLCB0aGUgTWFjcm9sYW5ndWFnZSBTSE9VTEQgYmUgdXNlZCBpbg0K ICAgcHJlZmVyZW5jZSB0byBvbmUgb2YgaXRzIHN1Ymxhbmd1YWdlcyB1bmxlc3MgdGhlcmUg aXMgYSBzcGVjaWZpYw0KICAgcmVhc29uIG5vdCB0by4NCg0KICAgSW4gcGFydGljdWxhciwg dGhlIENoaW5lc2UgZmFtaWx5IG9mIGxhbmd1YWdlcyBjYWxsIGZvciBzcGVjaWFsDQogICBj b25zaWRlcmF0aW9uLiAgQmVjYXVzZSB0aGUgd3JpdHRlbiBmb3JtIGlzIHZlcnkgc2ltaWxh ciBmb3IgbW9zdA0KICAgbGFuZ3VhZ2VzIGhhdmluZyAnemgnIGFzIGEgTWFjcm9sYW5ndWFn ZSAoYW5kIGJlY2F1c2UgaGlzdG9yaWNhbGx5DQogICBzdWJ0YWdzIGZvciB0aGUgdmFyaW91 cyBzdWItbGFuZ3VhZ2VzIGFuZCBkaWFsZWN0cyB3ZXJlIG5vdA0KICAgYXZhaWxhYmxlKSwg bGFuZ3VhZ2VzIHN1Y2ggYXMgJ3l1ZScgKENhbnRvbmVzZSkgaGF2ZSB1c3VhbGx5IHVzZWQN CiAgIHRhZ3MgYmVnaW5uaW5nIHdpdGggdGhlIHN1YnRhZyAnemgnLiAgVGhpcyBtZWFucyB0 aGF0IE1hY3JvbGFuZ3VhZ2UNCiAgIGluZm9ybWF0aW9uIGlzIGNhbiBiZSB1c2VmdWxseSBh cHBsaWVkIHdoZW4gc2VhcmNoaW5nIGZvciBjb250ZW50IG9yDQogICB3aGVuIHByb3ZpZGlu ZyBmYWxsYmFja3MgaW4gbGFuZ3VhZ2UgbmVnb3RpYXRpb24uICBGb3IgZXhhbXBsZSwgdGhl DQogICBpbmZvcm1hdGlvbiB0aGF0ICd5dWUnIGhhcyBhIG1hY3JvbGFuZ2F1Z2Ugb2YgJ3po JyBjb3VsZCBiZSB1c2VkIGluDQogICB0aGUgTG9va3VwIGFsZ29yaXRobSB0byBmYWxsYmFj ayBmcm9tIGEgcmVxdWVzdCBmb3IgInl1ZS1IYW5zLUNOIiB0bw0KICAgInpoLUhhbnMtQ04i IHdpdGhvdXQgbG9zaW5nIHRoZSBzY3JpcHQgYW5kIHJlZ2lvbiBpbmZvcm1hdGlvbiAoZXZl bg0KICAgdGhvdWdoIHRoZSB1c2VyIGRpZCBub3Qgc3BlY2lmeSAiemgtSGFucy1DTiIgaW4g dGhlaXIgcmVxdWVzdCkuDQoNCiAgIFRvIGVuc3VyZSBjb25zaXN0ZW50IGJhY2t3YXJkIGNv bXBhdGliaWxpdHksIHRoaXMgZG9jdW1lbnQgY29udGFpbnMNCiAgIHNldmVyYWwgcHJvdmlz aW9ucyB0byBhY2NvdW50IGZvciBwb3RlbnRpYWwgaW5zdGFiaWxpdHkgaW4gdGhlDQogICBz dGFuZGFyZHMgdXNlZCB0byBkZWZpbmUgdGhlIHN1YnRhZ3MgdGhhdCBtYWtlIHVwIGxhbmd1 YWdlIHRhZ3MuDQogICBUaGVzZSBwcm92aXNpb25zIG1lYW4gdGhhdCBubyBsYW5ndWFnZSB0 YWcgY3JlYXRlZCB1bmRlciB0aGUgcnVsZXMgaW4NCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBi ZWNvbWUgaW52YWxpZC4NCg0KICAgU3RhbmRhcmRzLCBwcm90b2NvbHMsIGFuZCBhcHBsaWNh dGlvbnMgdGhhdCByZWZlcmVuY2UgdGhpcyBkb2N1bWVudA0KICAgbm9ybWF0aXZlbHkgYnV0 IGFwcGx5IGRpZmZlcmVudCBydWxlcyB0byB0aGUgb25lcyBnaXZlbiBpbiB0aGlzDQogICBz ZWN0aW9uIE1VU1Qgc3BlY2lmeSBob3cgbGFuZ3VhZ2UgdGFnIHNlbGVjdGlvbiB2YXJpZXMg ZnJvbSB0aGUNCiAgIGd1aWRlbGluZXMgZ2l2ZW4gaGVyZS4NCg0KNC4yLiAgTWVhbmluZyBv ZiB0aGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIFRoZSBtZWFuaW5nIG9mIGEgbGFuZ3VhZ2UgdGFn IGlzIHJlbGF0ZWQgdG8gdGhlIG1lYW5pbmcgb2YgdGhlDQogICBzdWJ0YWdzIHRoYXQgaXQg Y29udGFpbnMuICBFYWNoIHN1YnRhZywgaW4gdHVybiwgaW1wbGllcyBhIGNlcnRhaW4NCiAg IHJhbmdlIG9mIGV4cGVjdGF0aW9ucyBvbmUgbWlnaHQgaGF2ZSBmb3IgcmVsYXRlZCBjb250 ZW50LCBhbHRob3VnaCBpdA0KICAgaXMgbm90IGEgZ3VhcmFudGVlLiAgRm9yIGV4YW1wbGUs IHRoZSB1c2Ugb2YgYSBzY3JpcHQgc3VidGFnIHN1Y2ggYXMNCiAgICdBcmFiJyAoQXJhYmlj IHNjcmlwdCkgZG9lcyBub3QgbWVhbiB0aGF0IHRoZSBjb250ZW50IGNvbnRhaW5zIG9ubHkN CiAgIEFyYWJpYyBjaGFyYWN0ZXJzLiAgSXQgZG9lcyBtZWFuIHRoYXQgdGhlIGxhbmd1YWdl IGludm9sdmVkIGlzDQogICBwcmVkb21pbmVudGx5IGluIHRoZSBBcmFiaWMgc2NyaXB0LiAg VGh1cyBhIGxhbmd1YWdlIHRhZyBhbmQgaXRzDQogICBzdWJ0YWdzIGNhbiBlbmNvbXBhc3Mg YSB2ZXJ5IHdpZGUgcmFuZ2Ugb2YgdmFyaWF0aW9uIGFuZCB5ZXQgcmVtYWluDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAg ICAgICAgICBbUGFnZSA0OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIHZhbGlk IGluIGVhY2ggcGFydGljdWxhciBpbnN0YW5jZS4NCg0KICAgVmFsaWRpdHkgb2YgYSB0YWcg aXMgbm90IGV2ZXJ5dGhpbmcuICBXaGlsZSBldmVyeSB2YWxpZCB0YWcgaGFzIGENCiAgIG1l YW5pbmcsIGl0IG1pZ2h0IG5vdCByZXByZXNlbnQgYW55IHJlYWwtd29ybGQgbGFuZ3VhZ2Ug dXNhZ2UuICBUaGlzDQogICBpcyB1bmF2b2lkYWJsZSBpbiBhIHN5c3RlbSBpbiB3aGljaCBz dWJ0YWdzIGNhbiBiZSBjb21iaW5lZCBmcmVlbHkuDQogICBGb3IgZXhhbXBsZSwgdGFncyBz dWNoIGFzICJhci1DeXJsLUNPIiAoQXJhYmljLCBDeXJpbGxpYyBzY3JpcHQsIGFzDQogICB1 c2VkIGluIENvbG9tYmlhICkgb3IgInRsaC1Lb3JlLUFRLWZvbmlwYSIgKEtsaW5nb24sIEtv cmVhbiBzY3JpcHQsDQogICBhcyB1c2VkIGluIEFudGFyY3RpY2EsIElQQSBwaG9uZXRpYyB0 cmFuc2NyaXB0aW9uKSBhcmUgYm90aCB2YWxpZCBhbmQNCiAgIHVubGlrZWx5IHRvIHJlcHJl c2VudCBhIHVzZWZ1bCBjb21iaW5hdGlvbiBvZiBsYW5ndWFnZSBhdHRyaWJ1dGVzLg0KDQog ICBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHRhZyBhbmQgdGhlIGluZm9ybWF0aW9u IGl0IGlkZW50aWZpZXMgaXMNCiAgIGRlZmluZWQgYnkgdGhlIGNvbnRleHQgaW4gd2hpY2gg dGhlIHRhZyBhcHBlYXJzLiAgQWNjb3JkaW5nbHksIHRoaXMNCiAgIHNlY3Rpb24gZ2l2ZXMg b25seSBwb3NzaWJsZSBleGFtcGxlcyBvZiBpdHMgdXNhZ2UuDQoNCiAgIG8gIEZvciBhIHNp bmdsZSBpbmZvcm1hdGlvbiBvYmplY3QsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MN CiAgICAgIG1pZ2h0IGJlIGludGVycHJldGVkIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHRo YXQgaXMgbmVjZXNzYXJ5IGZvcg0KICAgICAgYSBjb21wbGV0ZSBjb21wcmVoZW5zaW9uIG9m IHRoZSBjb21wbGV0ZSBvYmplY3QuICBFeGFtcGxlOiBQbGFpbg0KICAgICAgdGV4dCBkb2N1 bWVudHMuDQoNCiAgIG8gIEZvciBhbiBhZ2dyZWdhdGlvbiBvZiBpbmZvcm1hdGlvbiBvYmpl Y3RzLCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZQ0KICAgICAgdGFncyBjb3VsZCBiZSB0YWtl biBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB1c2VkIGluc2lkZSBjb21wb25lbnRzDQogICAg ICBvZiB0aGF0IGFnZ3JlZ2F0aW9uLiAgRXhhbXBsZXM6IERvY3VtZW50IHN0b3JlcyBhbmQg bGlicmFyaWVzLg0KDQogICBvICBGb3IgaW5mb3JtYXRpb24gb2JqZWN0cyB3aG9zZSBwdXJw b3NlIGlzIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmVzLA0KICAgICAgdGhlIGFzc29jaWF0ZWQg bGFuZ3VhZ2UgdGFncyBjb3VsZCBiZSByZWdhcmRlZCBhcyBhIGhpbnQgdGhhdCB0aGUNCiAg ICAgIGNvbnRlbnQgaXMgcHJvdmlkZWQgaW4gc2V2ZXJhbCBsYW5ndWFnZXMgYW5kIHRoYXQg b25lIGhhcyB0bw0KICAgICAgaW5zcGVjdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZXMgaW4g b3JkZXIgdG8gZmluZCBpdHMgbGFuZ3VhZ2Ugb3INCiAgICAgIGxhbmd1YWdlcy4gIEluIHRo aXMgY2FzZSwgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIHRhZ3MgbWlnaHQgbm90DQogICAg ICBtZWFuIHRoYXQgb25lIG5lZWRzIHRvIGJlIG11bHRpLWxpbmd1YWwgdG8gZ2V0IGNvbXBs ZXRlDQogICAgICB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4gIEV4YW1wbGU6IE1J TUUgbXVsdGlwYXJ0Lw0KICAgICAgYWx0ZXJuYXRpdmUuDQoNCiAgIG8gIEluIG1hcmt1cCBs YW5ndWFnZXMsIHN1Y2ggYXMgSFRNTCBhbmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlvbg0K ICAgICAgY2FuIGJlIGFkZGVkIHRvIGVhY2ggcGFydCBvZiB0aGUgZG9jdW1lbnQgaWRlbnRp ZmllZCBieSB0aGUgbWFya3VwDQogICAgICBzdHJ1Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hv bGUgZG9jdW1lbnQgaXRzZWxmKS4gIEZvciBleGFtcGxlLCBvbmUNCiAgICAgIGNvdWxkIHdy aXRlIDxzcGFuIGxhbmc9ImZyIj5DJ2VzdCBsYSB2aWUuPC9zcGFuPiBpbnNpZGUgYQ0KICAg ICAgTm9yd2VnaWFuIGRvY3VtZW50OyB0aGUgTm9yd2VnaWFuLXNwZWFraW5nIHVzZXIgY291 bGQgdGhlbiBhY2Nlc3MNCiAgICAgIGEgRnJlbmNoLU5vcndlZ2lhbiBkaWN0aW9uYXJ5IHRv IGZpbmQgb3V0IHdoYXQgdGhlIG1hcmtlZCBzZWN0aW9uDQogICAgICBtZWFudC4gIElmIHRo ZSB1c2VyIHdlcmUgbGlzdGVuaW5nIHRvIHRoYXQgZG9jdW1lbnQgdGhyb3VnaCBhDQogICAg ICBzcGVlY2ggc3ludGhlc2lzIGludGVyZmFjZSwgdGhpcyBmb3JtYXRpb24gY291bGQgYmUg dXNlZCB0byBzaWduYWwNCiAgICAgIHRoZSBzeW50aGVzaXplciB0byBhcHByb3ByaWF0ZWx5 IGFwcGx5IEZyZW5jaCB0ZXh0LXRvLXNwZWVjaA0KICAgICAgcHJvbnVuY2lhdGlvbiBydWxl cyB0byB0aGF0IHNwYW4gb2YgdGV4dCwgaW5zdGVhZCBvZiBhcHBseWluZyB0aGUNCiAgICAg IGluYXBwcm9wcmlhdGUgTm9yd2VnaWFuIHJ1bGVzLg0KDQogICBMYW5ndWFnZSB0YWdzIGFy ZSByZWxhdGVkIHdoZW4gdGhleSBjb250YWluIGEgc2ltaWxhciBzZXF1ZW5jZSBvZg0KICAg c3VidGFncy4gIEZvciBleGFtcGxlLCBpZiBhIGxhbmd1YWdlIHRhZyBCIGNvbnRhaW5zIGxh bmd1YWdlIHRhZyBBIGFzDQogICBhIHByZWZpeCwgdGhlbiBCIGlzIHR5cGljYWxseSAibmFy cm93ZXIiIG9yICJtb3JlIHNwZWNpZmljIiB0aGFuIEEuDQogICBUaHVzLCAiemgtSGFudC1U VyIgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICJ6aC1IYW50Ii4NCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQ YWdlIDQ5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgVGhpcyByZWxhdGlvbnNo aXAgaXMgbm90IGd1YXJhbnRlZWQgaW4gYWxsIGNhc2VzOiBzcGVjaWZpY2FsbHksDQogICBs YW5ndWFnZXMgdGhhdCBiZWdpbiB3aXRoIHRoZSBzYW1lIHNlcXVlbmNlIG9mIHN1YnRhZ3Mg YXJlIE5PVA0KICAgZ3VhcmFudGVlZCB0byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFs dGhvdWdoIHRoZXkgbWlnaHQgYmUuICBGb3INCiAgIGV4YW1wbGUsIHRoZSB0YWcgImF6IiBz aGFyZXMgYSBwcmVmaXggd2l0aCBib3RoICJhei1MYXRuIg0KICAgKEF6ZXJiYWlqYW5pIHdy aXR0ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdCkgYW5kICJhei1DeXJsIg0KICAgKEF6ZXJi YWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkuICBBIHBlcnNvbiBm bHVlbnQgaW4NCiAgIG9uZSBzY3JpcHQgbWlnaHQgbm90IGJlIGFibGUgdG8gcmVhZCB0aGUg b3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQogICBtaWdodCBiZSBpZGVudGljYWwuICBD b250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFibHkgaXMgd3JpdHRlbg0KICAgaW4g anVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBiZSBpbnRlbGxpZ2libGUgdG8g YSByZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhlIG90aGVyIHNjcmlwdC4NCg0KNC4zLiAg TGVuZ3RoIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGlzIG5vIGRlZmluZWQgdXBwZXIg bGltaXQgb24gdGhlIHNpemUgb2YgbGFuZ3VhZ2UgdGFncy4gIFdoaWxlDQogICBoaXN0b3Jp Y2FsbHkgbW9zdCBsYW5ndWFnZSB0YWdzIGhhdmUgY29uc2lzdGVkIG9mIGxhbmd1YWdlIGFu ZCByZWdpb24NCiAgIHN1YnRhZ3Mgd2l0aCBhIGNvbWJpbmVkIHRvdGFsIGxlbmd0aCBvZiB1 cCB0byBzaXggY2hhcmFjdGVycywgbGFyZ2VyDQogICB0YWdzIGhhdmUgYWx3YXlzIGJlZW4g Ym90aCBwb3NzaWJsZSBhbmQgYWN0dWFsbHkgYXBwZWFyZWQgaW4gdXNlLg0KDQogICBOZWl0 aGVyIHRoZSBsYW5ndWFnZSB0YWcgc3ludGF4IG5vciBvdGhlciByZXF1aXJlbWVudHMgaW4g dGhpcw0KICAgZG9jdW1lbnQgaW1wb3NlIGEgZml4ZWQgdXBwZXIgbGltaXQgb24gdGhlIG51 bWJlciBvZiBzdWJ0YWdzIGluIGENCiAgIGxhbmd1YWdlIHRhZyAoYW5kIHRodXMgYW4gdXBw ZXIgYm91bmQgb24gdGhlIHNpemUgb2YgYSB0YWcpLiAgVGhlDQogICBsYW5ndWFnZSB0YWcg c3ludGF4IHN1Z2dlc3RzIHRoYXQsIGRlcGVuZGluZyBvbiB0aGUgc3BlY2lmaWMNCiAgIGxh bmd1YWdlLCBtb3JlIHN1YnRhZ3MgKGFuZCB0aHVzIGEgbG9uZ2VyIHRhZykgYXJlIHNvbWV0 aW1lcw0KICAgbmVjZXNzYXJ5IHRvIGNvbXBsZXRlbHkgaWRlbnRpZnkgdGhlIGxhbmd1YWdl IGZvciBjZXJ0YWluDQogICBhcHBsaWNhdGlvbnM7IHRodXMsIGl0IGlzIHBvc3NpYmxlIHRv IGVudmlzaW9uIGxvbmcgb3IgY29tcGxleCBzdWJ0YWcNCiAgIHNlcXVlbmNlcy4NCg0KNC4z LjEuICBXb3JraW5nIHdpdGggTGltaXRlZCBCdWZmZXIgU2l6ZXMNCg0KICAgU29tZSBhcHBs aWNhdGlvbnMgYW5kIHByb3RvY29scyBhcmUgZm9yY2VkIHRvIGFsbG9jYXRlIGZpeGVkIGJ1 ZmZlcg0KICAgc2l6ZXMgb3Igb3RoZXJ3aXNlIGxpbWl0IHRoZSBsZW5ndGggb2YgYSBsYW5n dWFnZSB0YWcuICBBIGNvbmZvcm1hbnQNCiAgIGltcGxlbWVudGF0aW9uIG9yIHNwZWNpZmlj YXRpb24gTUFZIHJlZnVzZSB0byBzdXBwb3J0IHRoZSBzdG9yYWdlIG9mDQogICBsYW5ndWFn ZSB0YWdzIHRoYXQgZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0aC4gIEFueSBzdWNoIGxpbWl0 YXRpb24NCiAgIFNIT1VMRCBiZSBjbGVhcmx5IGRvY3VtZW50ZWQsIGFuZCBzdWNoIGRvY3Vt ZW50YXRpb24gU0hPVUxEIGluY2x1ZGUNCiAgIHdoYXQgaGFwcGVucyB0byBsb25nZXIgdGFn cyAoZm9yIGV4YW1wbGUsIHdoZXRoZXIgYW4gZXJyb3IgdmFsdWUgaXMNCiAgIGdlbmVyYXRl ZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIGlzIHRydW5jYXRlZCkuICBBIHByb3RvY29sIHRoYXQg YWxsb3dzDQogICB0YWdzIHRvIGJlIHRydW5jYXRlZCBhdCBhbiBhcmJpdHJhcnkgbGltaXQs IHdpdGhvdXQgZ2l2aW5nIGFueQ0KICAgaW5kaWNhdGlvbiBvZiB3aGF0IHRoYXQgbGltaXQg aXMsIGhhcyB0aGUgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm0NCiAgIGJ5IGNoYW5naW5n IHRoZSBtZWFuaW5nIG9mIHRhZ3MgaW4gc3Vic3RhbnRpYWwgd2F5cy4NCg0KICAgSW4gcHJh Y3RpY2UsIG1vc3QgbGFuZ3VhZ2UgdGFncyBkbyBub3QgcmVxdWlyZSBtb3JlIHRoYW4gYSBm ZXcNCiAgIHN1YnRhZ3MgYW5kIHdpbGwgbm90IGFwcHJvYWNoIHJlYXNvbmFibHkgc2l6ZWQg YnVmZmVyIGxpbWl0YXRpb25zOw0KICAgc2VlIFNlY3Rpb24gNC4xLg0KDQogICBTb21lIHNw ZWNpZmljYXRpb25zIG9yIHByb3RvY29scyBoYXZlIGxpbWl0cyBvbiB0YWcgbGVuZ3RoIGJ1 dCBkbyBub3QNCiAgIGhhdmUgYSBmaXhlZCBsZW5ndGggbGltaXRhdGlvbi4gIEZvciBleGFt cGxlLCBbUkZDMjIzMV0gaGFzIG5vDQogICBleHBsaWNpdCBsZW5ndGggbGltaXRhdGlvbjog dGhlIGxlbmd0aCBhdmFpbGFibGUgZm9yIHRoZSBsYW5ndWFnZSB0YWcNCiAgIGlzIGNvbnN0 cmFpbmVkIGJ5IHRoZSBsZW5ndGggb2Ygb3RoZXIgaGVhZGVyIGNvbXBvbmVudHMgKHN1Y2gg YXMgdGhlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSA1MF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw Nw0KDQoNCiAgIGNoYXJzZXQncyBuYW1lKSBjb3VwbGVkIHdpdGggdGhlIDc2LWNoYXJhY3Rl ciBsaW1pdCBpbiBbUkZDMjA0N10uDQogICBUaHVzLCB0aGUgImxpbWl0IiBtaWdodCBiZSA1 MCBvciBtb3JlIGNoYXJhY3RlcnMsIGJ1dCBpdCBjb3VsZA0KICAgcG90ZW50aWFsbHkgYmUg cXVpdGUgc21hbGwuDQoNCiAgIFRoZSBjb25zaWRlcmF0aW9ucyBmb3IgYXNzaWduaW5nIGEg YnVmZmVyIGxpbWl0IGFyZToNCg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1Qg dHJ1bmNhdGUgbGFuZ3VhZ2UgdGFncyB1bmxlc3MgdGhlDQogICAgICBtZWFuaW5nIG9mIHRo ZSB0YWcgaXMgcHVycG9zZWZ1bGx5IGJlaW5nIGNoYW5nZWQsIG9yIHVubGVzcyB0aGUNCiAg ICAgIHRhZyBkb2VzIG5vdCBmaXQgaW50byBhIGxpbWl0ZWQgYnVmZmVyIHNpemUgc3BlY2lm aWVkIGJ5IGENCiAgICAgIHByb3RvY29sIGZvciBzdG9yYWdlIG9yIHRyYW5zbWlzc2lvbi4N Cg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCB3YXJuIHRoZSB1c2VyIHdoZW4gYSB0 YWcgaXMgdHJ1bmNhdGVkIHNpbmNlDQogICAgICB0cnVuY2F0aW9uIGNoYW5nZXMgdGhlIHNl bWFudGljIG1lYW5pbmcgb2YgdGhlIHRhZy4NCg0KICAgICAgSW1wbGVtZW50YXRpb25zIG9m IHByb3RvY29scyBvciBzcGVjaWZpY2F0aW9ucyB0aGF0IGFyZSBzcGFjZQ0KICAgICAgY29u c3RyYWluZWQgYnV0IGRvIG5vdCBoYXZlIGEgZml4ZWQgbGltaXQgU0hPVUxEIHVzZSB0aGUg bG9uZ2VzdA0KICAgICAgcG9zc2libGUgdGFnIGluIHByZWZlcmVuY2UgdG8gdHJ1bmNhdGlv bi4NCg0KICAgICAgUHJvdG9jb2xzIG9yIHNwZWNpZmljYXRpb25zIHRoYXQgc3BlY2lmeSBs aW1pdGVkIGJ1ZmZlciBzaXplcyBmb3INCiAgICAgIGxhbmd1YWdlIHRhZ3MgTVVTVCBhbGxv dyBmb3IgbGFuZ3VhZ2UgdGFncyBvZiB1cCB0byAzMyBjaGFyYWN0ZXJzLg0KDQogICAgICBQ cm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBzcGVjaWZ5IGxpbWl0ZWQgYnVmZmVy IHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWxsb3cgZm9yIGxhbmd1 YWdlIHRhZ3Mgb2YgYXQgbGVhc3QgNDINCiAgICAgIGNoYXJhY3RlcnMuDQoNCiAgIFRoZSBm b2xsb3dpbmcgaWxsdXN0cmF0aW9uIHNob3dzIGhvdyB0aGUgNDItY2hhcmFjdGVyIHJlY29t bWVuZGF0aW9uDQogICB3YXMgZGVyaXZlZC4gIFRoZSBjb21iaW5hdGlvbiBvZiBsYW5ndWFn ZSBhbmQgZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZ3Mgd2FzIGNob3NlbiBmb3IgZnV0 dXJlIGNvbXBhdGliaWxpdHkuICBBdCB1cCB0byAxNSBjaGFyYWN0ZXJzLA0KICAgdGhpcyBj b21iaW5hdGlvbiBpcyBsb25nZXIgdGhhbiB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBwcmltYXJ5 IGxhbmd1YWdlDQogICBzdWJ0YWcgKDggY2hhcmFjdGVycyk6DQoNCiAgIGxhbmd1YWdlICAg ICAgPSAgMyAoSVNPIDYzOS0yOyBJU08gNjM5LTEgcmVxdWlyZXMgMikNCiAgIGV4dGxhbmcx ICAgICAgPSAgNCAoZWFjaCBzdWJzZXF1ZW50IHN1YnRhZyBpbmNsdWRlcyAnLScpDQogICBl eHRsYW5nMiAgICAgID0gIDQgKHVubGlrZWx5OiBuZWVkcyBwcmVmaXg9Imxhbmd1YWdlLWV4 dGxhbmcxIikNCiAgIGV4dGxhbmczICAgICAgPSAgNCAoZXh0cmVtZWx5IHVubGlrZWx5KQ0K ICAgc2NyaXB0ICAgICAgICA9ICA1IChpZiBub3Qgc3VwcHJlc3NlZDogc2VlIFNlY3Rpb24g NC4xKQ0KICAgcmVnaW9uICAgICAgICA9ICA0IChVTiBNLjQ5OyBJU08gMzE2NiByZXF1aXJl cyAzKQ0KICAgdmFyaWFudDEgICAgICA9ICA5IChuZWVkcyAnbGFuZ3VhZ2UnIGFzIGEgcHJl Zml4KQ0KICAgdmFyaWFudDIgICAgICA9ICA5IChuZWVkcyAnbGFuZ3VhZ2UtdmFyaWFudDEn IGFzIGEgcHJlZml4KQ0KDQogICB0b3RhbCAgICAgICAgID0gNDIgY2hhcmFjdGVycw0KDQog ICAgICAgICAgICAgIEZpZ3VyZSA2OiBEZXJpdmF0aW9uIG9mIHRoZSBMaW1pdCBvbiBUYWcg TGVuZ3RoDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgNTFdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg QXVndXN0IDIwMDcNCg0KDQo0LjMuMi4gIFRydW5jYXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0K DQogICBUcnVuY2F0aW9uIG9mIGEgbGFuZ3VhZ2UgdGFnIGFsdGVycyB0aGUgbWVhbmluZyBv ZiB0aGUgdGFnLCBhbmQgdGh1cw0KICAgU0hPVUxEIGJlIGF2b2lkZWQuICBIb3dldmVyLCB0 cnVuY2F0aW9uIG9mIGxhbmd1YWdlIHRhZ3MgaXMgc29tZXRpbWVzDQogICBuZWNlc3Nhcnkg ZHVlIHRvIGxpbWl0ZWQgYnVmZmVyIHNpemVzLiAgU3VjaCB0cnVuY2F0aW9uIE1VU1QgTk9U DQogICBwZXJtaXQgYSBzdWJ0YWcgdG8gYmUgY2hvcHBlZCBvZmYgaW4gdGhlIG1pZGRsZSBv ciB0aGUgZm9ybWF0aW9uIG9mDQogICBpbnZhbGlkIHRhZ3MgKGZvciBleGFtcGxlLCBvbmUg ZW5kaW5nIHdpdGggdGhlICItIiBjaGFyYWN0ZXIpLg0KDQogICBUaGlzIG1lYW5zIHRoYXQg YXBwbGljYXRpb25zIG9yIHByb3RvY29scyB0aGF0IHRydW5jYXRlIHRhZ3MgTVVTVCBkbw0K ICAgc28gYnkgcHJvZ3Jlc3NpdmVseSByZW1vdmluZyBzdWJ0YWdzIGFsb25nIHdpdGggdGhl aXIgcHJlY2VkaW5nICItIg0KICAgZnJvbSB0aGUgcmlnaHQgc2lkZSBvZiB0aGUgbGFuZ3Vh Z2UgdGFnIHVudGlsIHRoZSB0YWcgaXMgc2hvcnQgZW5vdWdoDQogICBmb3IgdGhlIGdpdmVu IGJ1ZmZlci4gIElmIHRoZSByZXN1bHRpbmcgdGFnIGVuZHMgd2l0aCBhIHNpbmdsZS0NCiAg IGNoYXJhY3RlciBzdWJ0YWcsIHRoYXQgc3VidGFnIGFuZCBpdHMgcHJlY2VkaW5nICItIiBN VVNUIGFsc28gYmUNCiAgIHJlbW92ZWQuICBGb3IgZXhhbXBsZToNCg0KICAgVGFnIHRvIHRy dW5jYXRlOiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlLXByaXZh dGUxDQogICAxLiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlDQog ICAyLiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMQ0KICAgMy4gemgtTGF0bi1DTi12 YXJpYW50MQ0KICAgNC4gemgtTGF0bi1DTg0KICAgNS4gemgtTGF0bg0KICAgNi4gemgNCg0K ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNzogRXhhbXBsZSBvZiBUYWcgVHJ1bmNhdGlv bg0KDQo0LjQuICBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgU2lu Y2UgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBtYW55 IHByb2Nlc3NlcywNCiAgIGxhbmd1YWdlIHRhZ3MgU0hPVUxEIGFsd2F5cyBiZSBjcmVhdGVk IG9yIGdlbmVyYXRlZCBpbiBhIGNhbm9uaWNhbA0KICAgZm9ybS4NCg0KICAgQSBsYW5ndWFn ZSB0YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KICAgMS4gIFRoZSB0YWcgaXMg d2VsbC1mb3JtZWQgYWNjb3JkaW5nIHRoZSBydWxlcyBpbiBTZWN0aW9uIDIuMSBhbmQNCiAg ICAgICBTZWN0aW9uIDIuMi4NCg0KICAgMi4gIFN1YnRhZ3Mgb2YgdHlwZSAnUmVnaW9uJyB0 aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbg0KICAgICAgIHRoZSBJQU5B IHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIFNIT1VMRCBiZSByZXBsYWNlZCB3aXRoIHRo ZWlyDQogICAgICAgbWFwcGVkIHZhbHVlLiAgTm90ZTogSW4gcmFyZSBjYXNlcywgdGhlIG1h cHBlZCB2YWx1ZSB3aWxsIGFsc28NCiAgICAgICBoYXZlIGEgUHJlZmVycmVkLVZhbHVlLg0K DQogICAzLiAgUmVkdW5kYW50IG9yIGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQ cmVmZXJyZWQtVmFsdWUNCiAgICAgICBtYXBwaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChz ZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQNCiAgICAgICB3aXRoIHRoZWlyIG1h cHBlZCB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGVpdGhlciBhcmUgZGVwcmVjYXRlZA0KICAgICAg IG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IChzdWNoIGFzDQogICAgICAgdGhlIG1hcHBpbmcgb2YgIm5vLW55biIgdG8gIm5uIiBvciAi aS1rbGluZ29uIiB0byAidGxoIikgb3IgYXJlDQogICAgICAgdGhlIHJlc3VsdCBvZiBsYXRl ciByZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9ucyB0byB0aGlzIGRvY3VtZW50DQogICAgICAg KGZvciBleGFtcGxlLCAiemgtaGFra2EiIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRo ZSBsYW5ndWFnZS0NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDUyXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA3DQoNCg0KICAgICAgIGV4dGxhbmcgY29tYmluYXRpb24gInpoLWhhayIgd2hlbiB0 aGlzIGRvY3VtZW50IHdhcyBhZG9wdGVkKS4NCg0KICAgNC4gIE90aGVyIHN1YnRhZ3MgdGhh dCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlIG1hcHBpbmcgaW4gdGhlIElBTkENCiAgICAgICBy ZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkIHdpdGggdGhlaXIg bWFwcGVkDQogICAgICAgdmFsdWUuICBUaGVzZSBpdGVtcyBjb25zaXN0IGVudGlyZWx5IG9m IGNsZXJpY2FsIGNvcnJlY3Rpb25zIHRvDQogICAgICAgSVNPIDYzOS0xIGluIHdoaWNoIHRo ZSBkZXByZWNhdGVkIHN1YnRhZ3MgaGF2ZSBiZWVuIG1haW50YWluZWQNCiAgICAgICBmb3Ig Y29tcGF0aWJpbGl0eSBwdXJwb3Nlcy4NCg0KICAgNS4gIElmIG1vcmUgdGhhbiBvbmUgZXh0 ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNpb24NCiAgICAgICBz ZXF1ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVy IGJ5DQogICAgICAgc2luZ2xldG9uIHN1YnRhZy4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1 YWdlIHRhZyAiZW4tQS1hYWEtQi1jY2MtYmJiLXgteHl6IiBpcyBpbiBjYW5vbmljYWwNCiAg IGZvcm0sIHdoaWxlICJlbi1CLWNjYy1iYmItQS1hYWEtWC14eXoiIGlzIHdlbGwtZm9ybWVk IGJ1dCBub3QgaW4NCiAgIGNhbm9uaWNhbCBmb3JtLg0KDQogICBFeGFtcGxlOiBUaGUgbGFu Z3VhZ2UgdGFnICJlbi1CVSIgKEVuZ2xpc2ggYXMgdXNlZCBpbiBCdXJtYSkgaXMgbm90DQog ICBjYW5vbmljYWwgYmVjYXVzZSB0aGUgJ0JVJyBzdWJ0YWcgaGFzIGEgY2Fub25pY2FsIG1h cHBpbmcgdG8gJ01NJw0KICAgKE15YW5tYXIpLCBhbHRob3VnaCB0aGUgdGFnICJlbi1CVSIg bWFpbnRhaW5zIGl0cyB2YWxpZGl0eS4NCg0KICAgQ2Fub25pY2FsaXphdGlvbiBvZiBsYW5n dWFnZSB0YWdzIGRvZXMgbm90IGltcGx5IGFueXRoaW5nIGFib3V0IHRoZQ0KICAgdXNlIG9m IHVwcGVyIG9yIGxvd2VyY2FzZSBsZXR0ZXJzIHdoZW4gcHJvY2Vzc2luZyBvciBjb21wYXJp bmcNCiAgIHN1YnRhZ3MgKGFuZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEpLiAgQWxs IGNvbXBhcmlzb25zIE1VU1QgYmUNCiAgIHBlcmZvcm1lZCBpbiBhIGNhc2UtaW5zZW5zaXRp dmUgbWFubmVyLg0KDQogICBXaGVuIHBlcmZvcm1pbmcgY2Fub25pY2FsaXphdGlvbiBvZiBs YW5ndWFnZSB0YWdzLCBwcm9jZXNzb3JzIE1BWQ0KICAgcmVndWxhcml6ZSB0aGUgY2FzZSBv ZiB0aGUgc3VidGFncyAodGhhdCBpcywgdGhpcyBwcm9jZXNzIGlzDQogICBPUFRJT05BTCks IGZvbGxvd2luZyB0aGUgY2FzZSB1c2VkIGluIHRoZSByZWdpc3RyeS4gIE5vdGUgdGhhdCB0 aGlzDQogICBjb3JyZXNwb25kcyB0byB0aGUgZm9sbG93aW5nIGNhc2luZyBydWxlczogdXBw ZXJjYXNlIGFsbCBub24taW5pdGlhbA0KICAgdHdvLWxldHRlciBzdWJ0YWdzOyB0aXRsZWNh c2UgYWxsIG5vbi1pbml0aWFsIGZvdXItbGV0dGVyIHN1YnRhZ3M7DQogICBsb3dlcmNhc2Ug ZXZlcnl0aGluZyBlbHNlLg0KDQogICBOb3RlOiBDYXNlIGZvbGRpbmcgb2YgQVNDSUkgbGV0 dGVycyBpbiBjZXJ0YWluIGxvY2FsZXMsIHVubGVzcw0KICAgY2FyZWZ1bGx5IGhhbmRsZWQs IHNvbWV0aW1lcyBwcm9kdWNlcyBub24tQVNDSUkgY2hhcmFjdGVyIHZhbHVlcy4NCiAgIFRo ZSBVbmljb2RlIENoYXJhY3RlciBEYXRhYmFzZSBmaWxlICJTcGVjaWFsQ2FzaW5nLnR4dCIg ZGVmaW5lcyB0aGUNCiAgIHNwZWNpZmljIGNhc2VzIHRoYXQgYXJlIGtub3duIHRvIGNhdXNl IHByb2JsZW1zIHdpdGggdGhpcy4gIEluDQogICBwYXJ0aWN1bGFyLCB0aGUgbGV0dGVyICdp JyAoVSswMDY5KSBpbiBUdXJraXNoIGFuZCBBemVyYmFpamFuaSBpcw0KICAgdXBwZXJjYXNl ZCB0byBVKzAxMzAgKExBVElOIENBUElUQUwgTEVUVEVSIEkgV0lUSCBET1QgQUJPVkUpLg0K ICAgSW1wbGVtZW50ZXJzIFNIT1VMRCBzcGVjaWZ5IGEgbG9jYWxlLW5ldXRyYWwgY2FzaW5n IG9wZXJhdGlvbiB0bw0KICAgZW5zdXJlIHRoYXQgY2FzZSBmb2xkaW5nIG9mIHN1YnRhZ3Mg ZG9lcyBub3QgcHJvZHVjZSB0aGlzIHZhbHVlLA0KICAgd2hpY2ggaXMgaWxsZWdhbCBpbiBs YW5ndWFnZSB0YWdzLiAgRm9yIGV4YW1wbGUsIGlmIG9uZSB3ZXJlIHRvDQogICB1cHBlcmNh c2UgdGhlIHJlZ2lvbiBzdWJ0YWcgJ2luJyB1c2luZyBUdXJraXNoIGxvY2FsZSBydWxlcywg dGhlDQogICBzZXF1ZW5jZSBVKzAxMzAgVSswMDRFIHdvdWxkIHJlc3VsdCBpbnN0ZWFkIG9m IHRoZSBleHBlY3RlZCAnSU4nLg0KDQogICBOb3RlOiBpZiB0aGUgZmllbGQgJ0RlcHJlY2F0 ZWQnIGFwcGVhcnMgaW4gYSByZWdpc3RyeSByZWNvcmQgd2l0aG91dA0KICAgYW4gYWNjb21w YW55aW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkLCB0aGVuIHRoYXQgdGFnIG9yIHN1YnRh ZyBpcw0KICAgZGVwcmVjYXRlZCB3aXRob3V0IGEgcmVwbGFjZW1lbnQuICBWYWxpZGF0aW5n IHByb2Nlc3NvcnMgU0hPVUxEIE5PVA0KICAgZ2VuZXJhdGUgdGFncyB0aGF0IGluY2x1ZGUg dGhlc2UgdmFsdWVzLCBhbHRob3VnaCB0aGUgdmFsdWVzIGFyZQ0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAg W1BhZ2UgNTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBjYW5vbmljYWwgd2hl biB0aGV5IGFwcGVhciBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAgQW4gZXh0ZW5zaW9uIE1V U1QgZGVmaW5lIGFueSByZWxhdGlvbnNoaXBzIHRoYXQgZXhpc3QgYmV0d2VlbiB0aGUNCiAg IHZhcmlvdXMgc3VidGFncyBpbiB0aGUgZXh0ZW5zaW9uIGFuZCB0aHVzIE1BWSBkZWZpbmUg YW4gYWx0ZXJuYXRlDQogICBjYW5vbmljYWxpemF0aW9uIHNjaGVtZSBmb3IgdGhlIGV4dGVu c2lvbidzIHN1YnRhZ3MuICBFeHRlbnNpb25zIE1BWQ0KICAgZGVmaW5lIGhvdyB0aGUgb3Jk ZXIgb2YgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MgYXJlIGludGVycHJldGVkLiAgRm9yDQog ICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgZGVmaW5lIHRoYXQgaXRzIHN1YnRhZ3Mg YXJlIGluIGNhbm9uaWNhbA0KICAgb3JkZXIgd2hlbiB0aGUgc3VidGFncyBhcmUgcGxhY2Vk IGludG8gQVNDSUkgb3JkZXI6IHRoYXQgaXMsICJlbi1hLQ0KICAgYWFhLWJiYi1jY2MiIGlu c3RlYWQgb2YgImVuLWEtY2NjLWJiYi1hYWEiLiAgQW5vdGhlciBleHRlbnNpb24gbWlnaHQN CiAgIGRlZmluZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVuY2VzIHRo ZWlyIHNlbWFudGljDQogICBtZWFuaW5nIChzbyB0aGF0ICJlbi1iLWNjYy1iYmItYWFhIiBo YXMgYSBkaWZmZXJlbnQgdmFsdWUgZnJvbSAiZW4tYi0NCiAgIGFhYS1iYmItY2NjIikuICBI b3dldmVyLCBleHRlbnNpb24gc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGJlIGRlc2lnbmVkDQog ICBzbyB0aGF0IHRoZXkgYXJlIHRvbGVyYW50IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBk ZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy43Lg0KDQo0LjUuICBDb25zaWRlcmF0aW9ucyBm b3IgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBQcml2YXRlIHVzZSBzdWJ0YWdzLCBsaWtl IGFsbCBvdGhlciBzdWJ0YWdzLCBNVVNUIGNvbmZvcm0gdG8gdGhlDQogICBmb3JtYXQgYW5k IGNvbnRlbnQgY29uc3RyYWludHMgaW4gdGhlIEFCTkYuICBQcml2YXRlIHVzZSBzdWJ0YWdz IGhhdmUNCiAgIG5vIG1lYW5pbmcgb3V0c2lkZSB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQgYmV0 d2VlbiB0aGUgcGFydGllcyB0aGF0DQogICBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdlIGxh bmd1YWdlIHRhZ3MgdGhhdCBlbXBsb3kgdGhlbS4gIFRoZSBzYW1lDQogICBzdWJ0YWdzIE1B WSBiZSB1c2VkIHdpdGggYSBkaWZmZXJlbnQgbWVhbmluZyB1bmRlciBhIHNlcGFyYXRlIHBy aXZhdGUNCiAgIGFncmVlbWVudC4gIFRoZXkgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZXJlIGFs dGVybmF0aXZlcyBleGlzdCBhbmQNCiAgIFNIT1VMRCBOT1QgYmUgdXNlZCBpbiBjb250ZW50 IG9yIHByb3RvY29scyBpbnRlbmRlZCBmb3IgZ2VuZXJhbCB1c2UuDQoNCiAgIFByaXZhdGUg dXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2VsZXNzIGZvciBpbmZvcm1hdGlvbiBleGNoYW5n ZQ0KICAgd2l0aG91dCBwcmlvciBhcnJhbmdlbWVudC4gIFRoZSB2YWx1ZSBhbmQgc2VtYW50 aWMgbWVhbmluZyBvZiBwcml2YXRlDQogICB1c2UgdGFncyBhbmQgb2YgdGhlIHN1YnRhZ3Mg dXNlZCB3aXRoaW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90DQogICBkZWZpbmVkIGJ5 IHRoaXMgZG9jdW1lbnQuDQoNCiAgIFN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdp c3RyeSBhcyBoYXZpbmcgYSBzcGVjaWZpYyBwcml2YXRlIHVzZQ0KICAgbWVhbmluZyBjb252 ZXkgbW9yZSBpbmZvcm1hdGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNlIHRhZw0KICAg cHJlZml4ZWQgYnkgdGhlIHNpbmdsZXRvbiBzdWJ0YWcgJ3gnLiAgRm9yIGFwcGxpY2F0aW9u cywgdGhpcw0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBNQVkgYmUgdXNlZnVsLg0KDQog ICBGb3IgZXhhbXBsZSwgdGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdaWicsIGFuZCBpbiB0 aGUgcmFuZ2VzDQogICAnUU0nLSdRWicgYW5kICdYQSctJ1haJyAoZGVyaXZlZCBmcm9tIElT TyAzMTY2IHByaXZhdGUgdXNlIGNvZGVzKSBNQVkNCiAgIGJlIHVzZWQgdG8gZm9ybSBhIGxh bmd1YWdlIHRhZy4gIEEgdGFnIHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMgYQ0KICAg Z3JlYXQgZGVhbCBvZiBwdWJsaWMsIGludGVyY2hhbmdlYWJsZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgbGFuZ3VhZ2UNCiAgIG1hdGVyaWFsICh0aGF0IGl0IGlzIENoaW5lc2UgaW4gdGhl IHNpbXBsaWZpZWQgQ2hpbmVzZSBzY3JpcHQgYW5kIGlzDQogICBzdWl0YWJsZSBmb3Igc29t ZSBnZW9ncmFwaGljIHJlZ2lvbiAnWFEnKS4gIFdoaWxlIHRoZSBwcmVjaXNlDQogICBnZW9n cmFwaGljIHJlZ2lvbiBpcyBub3Qga25vd24gb3V0c2lkZSBvZiBwcml2YXRlIGFncmVlbWVu dCwgdGhlIHRhZw0KICAgY29udmV5cyBmYXIgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIGFuIG9w YXF1ZSB0YWcgc3VjaCBhcyAieC1zb21lTGFuZyIsDQogICB3aGljaCBjb250YWlucyBubyBp bmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIG9yIHNjcmlwdA0KICAgc3Vi dGFnIG91dHNpZGUgb2YgdGhlIHByaXZhdGUgYWdyZWVtZW50Lg0KDQogICBIb3dldmVyLCBp biBzb21lIGNhc2VzIGNvbnRlbnQgdGFnZ2VkIHdpdGggcHJpdmF0ZSB1c2Ugc3VidGFncyBN QVkNCiAgIGludGVyYWN0IHdpdGggb3RoZXIgc3lzdGVtcyBpbiBhIGRpZmZlcmVudCBhbmQg cG9zc2libHkgdW5zdWl0YWJsZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgNTRdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDcNCg0KDQogICBtYW5uZXIgY29tcGFyZWQgdG8gdGFncyB0aGF0IHVz ZSBvcGFxdWUsIHByaXZhdGVseSBkZWZpbmVkIHN1YnRhZ3MsDQogICBzbyB0aGUgY2hvaWNl IG9mIHRoZSBiZXN0IGFwcHJvYWNoIHNvbWV0aW1lcyBkZXBlbmRzIG9uIHRoZQ0KICAgcGFy dGljdWxhciBkb21haW4gaW4gcXVlc3Rpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSA1NV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3Qg MjAwNw0KDQoNCjUuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBk ZWFscyB3aXRoIHRoZSBwcm9jZXNzZXMgYW5kIHJlcXVpcmVtZW50cyBuZWNlc3NhcnkgZm9y DQogICBJQU5BIHRvIHVuZGVydGFrZSB0byBtYWludGFpbiB0aGUgc3VidGFnIGFuZCBleHRl bnNpb24gcmVnaXN0cmllcyBhcw0KICAgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IGFuZCBp biBhY2NvcmRhbmNlIHdpdGggdGhlIHJlcXVpcmVtZW50cyBvZg0KICAgW1JGQzI0MzRdLg0K DQogICBUaGUgaW1wYWN0IG9uIHRoZSBJQU5BIG1haW50YWluZXJzIG9mIHRoZSB0d28gcmVn aXN0cmllcyBkZWZpbmVkIGJ5DQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmUgYSBzbWFsbCBp bmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldw0KICAgZW50cmllcyBvciB1cGRhdGVz Lg0KDQo1LjEuICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCg0KICAgVXBvbiBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50LCBJQU5BIHdpbGwgdXBkYXRlIHRoZSByZWdpc3RyeSB1c2lu Zw0KICAgaW5zdHJ1Y3Rpb25zIGFuZCBjb250ZW50IHByb3ZpZGVkIGluIGEgY29tcGFuaW9u IGRvY3VtZW50Og0KICAgW3JlZ2lzdHJ5LXVwZGF0ZV0uICBUaGUgY3JpdGVyaWEgYW5kIHBy b2Nlc3MgZm9yIHNlbGVjdGluZyB0aGUNCiAgIHVwZGF0ZWQgc2V0IG9mIHJlY29yZHMgYXJl IGRlc2NyaWJlZCBpbiB0aGF0IGRvY3VtZW50LiAgVGhlIHVwZGF0ZWQNCiAgIHNldCBvZiBy ZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEsIHNpbmNlIHRoZSB3b3JrIHRv IGNyZWF0ZQ0KICAgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0ZXJuYWxseS4NCg0KICAgRnV0 dXJlIHdvcmsgb24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBoYXMgYmVlbiBsaW1p dGVkIHRvDQogICBpbnNlcnRpbmcgb3IgcmVwbGFjaW5nIHdob2xlIHJlY29yZHMgcHJlZm9y bWF0dGVkIGZvciBJQU5BIGJ5IHRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMyBvZiB0aGlzIGRvY3VtZW50DQogICBhbmQgYXJj aGl2aW5nIGFuZCBtYWtpbmcgcHVibGljYWxseSBhdmFpbGFibGUgdGhlIGZvcndhcmRlZA0K ICAgcmVnaXN0cmF0aW9uIGZvcm0uDQoNCiAgIEVhY2ggcmVnaXN0cmF0aW9uIGZvcm0gc2Vu dCB0byBJQU5BIGNvbnRhaW5zIGEgc2luZ2xlIHJlY29yZCBmb3INCiAgIGluY29ycG9yYXRp b24gaW50byB0aGUgcmVnaXN0cnkuICBUaGUgZm9ybSBNVVNUIGJlIHNlbnQgdG8NCiAgIGlh bmFAaWFuYS5vcmcgYnkgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlci4gIEl0IHdpbGwg aGF2ZSBhDQogICBzdWJqZWN0IGxpbmUgaW5kaWNhdGluZyB3aGV0aGVyIHRoZSBlbmNsb3Nl ZCBmb3JtIHJlcHJlc2VudHMgYW4NCiAgIGluc2VydGlvbiBvZiBhIG5ldyByZWNvcmQgKGlu ZGljYXRlZCBieSB0aGUgd29yZCAiSU5TRVJUIiBpbiB0aGUNCiAgIHN1YmplY3QgbGluZSkg b3IgYSByZXBsYWNlbWVudCBvZiBhbiBleGlzdGluZyByZWNvcmQgKGluZGljYXRlZCBieQ0K ICAgdGhlIHdvcmQgIk1PRElGWSIgaW4gdGhlIHN1YmplY3QgbGluZSkuICBSZWNvcmRzIE1V U1QgTk9UIGJlIGRlbGV0ZWQNCiAgIGZyb20gdGhlIHJlZ2lzdHJ5Lg0KDQogICBJQU5BIE1V U1QgZXh0cmFjdCB0aGUgcmVjb3JkIGZyb20gdGhlIGZvcm0gYW5kIHBsYWNlIHRoZSBpbnNl cnRlZCBvcg0KICAgbW9kaWZpZWQgcmVjb3JkIGludG8gdGhlIGFwcHJvcHJpYXRlIHNlY3Rp b24gb2YgdGhlIGxhbmd1YWdlIHN1YnRhZw0KICAgcmVnaXN0cnksIGdyb3VwaW5nIHRoZSBy ZWNvcmRzIGJ5IHRoZWlyICdUeXBlJyBmaWVsZC4gIEluc2VydGVkDQogICByZWNvcmRzIE1B WSBiZSBwbGFjZWQgYW55d2hlcmUgaW4gdGhlIGFwcHJvcHJpYXRlIHNlY3Rpb247IHRoZXJl IGlzDQogICBubyBndWFyYW50ZWUgb2YgdGhlIG9yZGVyIG9mIHRoZSByZWNvcmRzIGJleW9u ZCBncm91cGluZyB0aGVtDQogICB0b2dldGhlciBieSAnVHlwZScuICBNb2RpZmllZCByZWNv cmRzIE1VU1Qgb3ZlcndyaXRlIHRoZSByZWNvcmQgdGhleQ0KICAgcmVwbGFjZS4NCg0KICAg SUFOQSBNVVNUIHVwZGF0ZSB0aGUgRmlsZS1EYXRlIHJlY29yZCB0byBjb250YWluIHRoZSBt b3N0IHJlY2VudA0KICAgbW9kaWZpY2F0aW9uIGRhdGUgd2hlbiBwZXJmb3JtaW5nIGFueSBp bnNlcnRpbmcgb3IgbW9kaWZpY2F0aW9uOg0KICAgaW5jbHVkZWQgaW4gYW55IHJlcXVlc3Qg dG8gaW5zZXJ0IG9yIG1vZGlmeSByZWNvcmRzIHdpbGwgYmUgYSBuZXcNCiAgIEZpbGUtRGF0 ZSByZWNvcmQgaW5kaWNhdGluZyB0aGUgYWNjZXB0YW5jZSBkYXRlIG9mIHRoZSByZWNvcmQu ICBUaGlzDQogICByZWNvcmQgTVVTVCBiZSBwbGFjZWQgZmlyc3QgaW4gdGhlIHJlZ2lzdHJ5 LCByZXBsYWNpbmcgdGhlIGV4aXN0aW5nDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSA1Nl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIEZpbGUtRGF0ZSByZWNvcmQuICBJbiB0aGUg ZXZlbnQgdGhhdCB0aGUgRmlsZS1EYXRlIHJlY29yZCBwcmVzZW50IGluDQogICB0aGUgcmVn aXN0cnkgaGFzIGEgbGF0ZXIgZGF0ZSB0aGFuIHRoZSByZWNvcmQgYmVpbmcgaW5zZXJ0ZWQg b3INCiAgIG1vZGlmaWVkLCB0aGVuIHRoZSBsYXRlc3QgKG1vc3QgcmVjZW50KSByZWNvcmQg TVVTVCBiZSBwcmVzZXJ2ZWQuDQogICBJQU5BIFNIT1VMRCBwcm9jZXNzIG11bHRpcGxlIHJl Z2lzdHJhdGlvbiByZXF1ZXN0cyBpbiBvcmRlciBhY2NvcmRpbmcNCiAgIHRvIHRoZSBGaWxl LURhdGUgaW4gdGhlIGZvcm0sIHNpbmNlIG9uZSByZWdpc3RyYXRpb24gY291bGQgb3RoZXJ3 aXNlDQogICBjYXVzZSBhIG1vcmUgcmVjZW50IGNoYW5nZSB0byBiZSBvdmVyd3JpdHRlbi4N Cg0KICAgVGhlIHVwZGF0ZWQgcmVnaXN0cnkgZmlsZSBNVVNUIHVzZSB0aGUgVVRGLTggY2hh cmFjdGVyIGVuY29kaW5nIGFuZA0KICAgSUFOQSBNVVNUIGNoZWNrIHRoZSByZWdpc3RyeSBm aWxlIGZvciBwcm9wZXIgZW5jb2RpbmcuICBOb24tQVNDSUkNCiAgIGNoYXJhY3RlcnMgY2Fu IGJlIHNlbnQgdG8gSUFOQSBieSBhdHRhY2hpbmcgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIHRv DQogICB0aGUgZW1haWwgbWVzc2FnZSBvciBieSB1c2luZyB2YXJpb3VzIGVuY29kaW5ncyBp biB0aGUgbWFpbCBtZXNzYWdlDQogICBib2R5IChVVEYtOCBpcyByZWNvbW1lbmRlZCkuICBJ QU5BIHdpbGwgdmVyaWZ5IGFueSB1bmNsZWFyIG9yDQogICBjb3JydXB0ZWQgY2hhcmFjdGVy cyB3aXRoIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgcHJpb3IgdG8NCiAgIHBvc3Rp bmcgdGhlIHVwZGF0ZWQgcmVnaXN0cnkuDQoNCiAgIFRoZSByZWdpc3RyYXRpb24gZm9ybSBz ZW50IHRvIElBTkEgTVVTVCBiZSBhcmNoaXZlZCBhbmQgbWFkZSBwdWJsaWNseQ0KICAgYXZh aWxhYmxlIGZyb20NCiAgICJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmct c3VidGFncy10ZW1wbGF0ZXMvIi4gIE5vdGUgdGhhdA0KICAgbXVsdGlwbGUgcmVnaXN0cmF0 aW9ucyBjYW4gcGVydGFpbiB0byB0aGUgc2FtZSByZWNvcmQgaW4gdGhlDQogICByZWdpc3Ry eS4NCg0KICAgRGV2ZWxvcGVycyB3aG8gYXJlIGRlcGVuZGVudCB1cG9uIHRoZSBsYW5ndWFn ZSBzdWJ0YWcgcmVnaXN0cnkNCiAgIHNvbWV0aW1lcyB3b3VsZCBsaWtlIHRvIGJlIGluZm9y bWVkIG9mIGNoYW5nZXMgaW4gdGhlIHJlZ2lzdHJ5IHNvDQogICB0aGF0IHRoZXkgY2FuIHVw ZGF0ZSB0aGVpciBpbXBsZW1lbnRhdGlvbnMuICBXaGVuIGFueSBjaGFuZ2UgaXMgbWFkZQ0K ICAgdG8gdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSwgSUFOQSBNVVNUIHNlbmQgYW4g YW5ub3VuY2VtZW50DQogICBtZXNzYWdlIHRvIGlldGYtbGFuZ3VhZ2VzLWFubm91bmNlbWVu dHNAaWFuYS5vcmcgKGEgc2VsZi1zdWJzY3JpYmluZw0KICAgbGlzdCB0aGF0IG9ubHkgSUFO QSBjYW4gcG9zdCB0bykuDQoNCjUuMi4gIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgVGhl IExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5IGNhbiBjb250YWluIGF0IG1vc3Qg MzUgcmVjb3Jkcw0KICAgYW5kIHRodXMgY2hhbmdlcyB0byB0aGlzIHJlZ2lzdHJ5IGFyZSBl eHBlY3RlZCB0byBiZSB2ZXJ5IGluZnJlcXVlbnQuDQoNCiAgIEZ1dHVyZSB3b3JrIGJ5IElB TkEgb24gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5IGlzDQogICBsaW1p dGVkIHRvIHR3byBjYXNlcy4gIEZpcnN0LCB0aGUgSUVTRyBNQVkgcmVxdWVzdCB0aGF0IG5l dyByZWNvcmRzDQogICBiZSBpbnNlcnRlZCBpbnRvIHRoaXMgcmVnaXN0cnkgZnJvbSB0aW1l IHRvIHRpbWUuICBUaGVzZSByZXF1ZXN0cw0KICAgTVVTVCBpbmNsdWRlIHRoZSByZWNvcmQg dG8gaW5zZXJ0IGluIHRoZSBleGFjdCBmb3JtYXQgZGVzY3JpYmVkIGluDQogICBTZWN0aW9u IDMuNy4gIEluIGFkZGl0aW9uLCB0aGVyZSBNQVkgYmUgb2NjYXNpb25hbCByZXF1ZXN0cyBm cm9tIHRoZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciBhIHNwZWNpZmljIGV4dGVu c2lvbiB0byB1cGRhdGUgdGhlIGNvbnRhY3QNCiAgIGluZm9ybWF0aW9uIG9yIFVSTHMgaW4g dGhlIHJlY29yZC4gIFRoZXNlIHJlcXVlc3RzIE1VU1QgaW5jbHVkZSB0aGUNCiAgIGNvbXBs ZXRlLCB1cGRhdGVkIHJlY29yZC4gIElBTkEgaXMgbm90IHJlc3BvbnNpYmxlIGZvciB2YWxp ZGF0aW5nIHRoZQ0KICAgaW5mb3JtYXRpb24gcHJvdmlkZWQsIG9ubHkgdGhhdCBpdCBpcyBw cm9wZXJseSBmb3JtYXR0ZWQuICBJdCBzaG91bGQNCiAgIHJlYXNvbmFibHkgYmUgc2VlbiB0 byBjb21lIGZyb20gdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBuYW1lZCBpbg0KICAgdGhl IHJlY29yZCBwcmVzZW50IGluIHRoZSByZWdpc3RyeS4NCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAg ICAgW1BhZ2UgNTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQo2LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCg0KICAgTGFuZ3VhZ2UgdGFncyB1c2VkIGluIGNvbnRlbnQgbmVn b3RpYXRpb24sIGxpa2UgYW55IG90aGVyIGluZm9ybWF0aW9uDQogICBleGNoYW5nZWQgb24g dGhlIEludGVybmV0LCBtaWdodCBiZSBhIHNvdXJjZSBvZiBjb25jZXJuIGJlY2F1c2UgdGhl eQ0KICAgbWlnaHQgYmUgdXNlZCB0byBpbmZlciB0aGUgbmF0aW9uYWxpdHkgb2YgdGhlIHNl bmRlciwgYW5kIHRodXMNCiAgIGlkZW50aWZ5IHBvdGVudGlhbCB0YXJnZXRzIGZvciBzdXJ2 ZWlsbGFuY2UuDQoNCiAgIFRoaXMgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGdlbmVyYWwg cHJvYmxlbSB0aGF0IGFueXRoaW5nIHNlbnQgaXMNCiAgIHZpc2libGUgdG8gdGhlIHJlY2Vp dmluZyBwYXJ0eSBhbmQgcG9zc2libHkgdG8gdGhpcmQgcGFydGllcyBhcyB3ZWxsLg0KICAg SXQgaXMgdXNlZnVsIHRvIGJlIGF3YXJlIHRoYXQgc3VjaCBjb25jZXJucyBjYW4gZXhpc3Qg aW4gc29tZSBjYXNlcy4NCg0KICAgVGhlIGV2YWx1YXRpb24gb2YgdGhlIGV4YWN0IG1hZ25p dHVkZSBvZiB0aGUgdGhyZWF0LCBhbmQgYW55IHBvc3NpYmxlDQogICBjb3VudGVybWVhc3Vy ZXMsIGlzIGxlZnQgdG8gZWFjaCBhcHBsaWNhdGlvbiBwcm90b2NvbCAoc2VlIEJDUCA3Mg0K ICAgW1JGQzM1NTJdIGZvciBiZXN0IGN1cnJlbnQgcHJhY3RpY2UgZ3VpZGFuY2Ugb24gc2Vj dXJpdHkgdGhyZWF0cyBhbmQNCiAgIGRlZmVuc2VzKS4NCg0KICAgVGhlIGxhbmd1YWdlIHRh ZyBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIGluZm9ybWF0aW9uIGl0ZW0gaXMgb2YN CiAgIG5vIGNvbnNlcXVlbmNlIHdoYXRzb2V2ZXIgaW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0 aGF0IGNvbnRlbnQgbWlnaHQNCiAgIGNvbnRhaW4gcG9zc2libGUgaG9tb2dyYXBocy4gIFRo ZSBmYWN0IHRoYXQgYSB0ZXh0IGlzIHRhZ2dlZCBhcyBiZWluZw0KICAgaW4gb25lIGxhbmd1 YWdlIG9yIHVzaW5nIGEgcGFydGljdWxhciBzY3JpcHQgc3VidGFnIHByb3ZpZGVzIG5vDQog ICBhc3N1cmFuY2Ugd2hhdHNvZXZlciB0aGF0IGl0IGRvZXMgbm90IGNvbnRhaW4gY2hhcmFj dGVycyBmcm9tIHNjcmlwdHMNCiAgIG90aGVyIHRoYW4gdGhlIG9uZShzKSBhc3NvY2lhdGVk IHdpdGggb3Igc3BlY2lmaWVkIGJ5IHRoYXQgbGFuZ3VhZ2UNCiAgIHRhZy4NCg0KICAgU2lu Y2UgdGhlcmUgaXMgbm8gbGltaXQgdG8gdGhlIG51bWJlciBvZiB2YXJpYW50LCBwcml2YXRl IHVzZSwgYW5kDQogICBleHRlbnNpb24gc3VidGFncywgYW5kIGNvbnNlcXVlbnRseSBubyBs aW1pdCBvbiB0aGUgcG9zc2libGUgbGVuZ3RoDQogICBvZiBhIHRhZywgaW1wbGVtZW50YXRp b25zIG5lZWQgdG8gZ3VhcmQgYWdhaW5zdCBidWZmZXIgb3ZlcmZsb3cNCiAgIGF0dGFja3Mu ICBTZWUgU2VjdGlvbiA0LjMgZm9yIGRldGFpbHMgb24gbGFuZ3VhZ2UgdGFnIHRydW5jYXRp b24sDQogICB3aGljaCBjYW4gb2NjdXIgYXMgYSBjb25zZXF1ZW5jZSBvZiBkZWZlbnNlcyBh Z2FpbnN0IGJ1ZmZlciBvdmVyZmxvdy4NCg0KICAgQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRp b24gb2YgdmFsaWQgc3VidGFncyBmb3IgYW4gZXh0ZW5zaW9uIChzZWUNCiAgIFNlY3Rpb24g My43KSBNVVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50YXRp b25zDQogICBTSE9VTEQgTk9UIG1lY2hhbmljYWxseSBkZXBlbmQgb24gaXQgYmVpbmcgYWx3 YXlzIGFjY2Vzc2libGUsIHRvDQogICBwcmV2ZW50IGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFj a3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug NThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQo3LiAgQ2hhcmFjdGVyIFNldCBDb25z aWRlcmF0aW9ucw0KDQogICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMg dGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVosIGEt eiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQog ICBjaGFyYWN0ZXIgc2V0cywgc28gdGhlIGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mg c2hvdWxkIG5vdCBoYXZlDQogICBhbnkgY2hhcmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJl bmRlcmluZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3Vh Z2UgdGFnIGlzIG5vdA0KICAgYWRkcmVzc2VkIGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxs eSwgc29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQgb24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lm aWMgY2hhcmFjdGVyIHNldHMgb3Igb3RoZXIgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8NCiAg IGluZmVyIGhvdyBhIHNwZWNpZmljIGNoYXJhY3RlciBzaG91bGQgYmUgcmVuZGVyZWQgKG5v dGFibHkgdGhpcw0KICAgYXBwbGllcyB0byBsYW5ndWFnZS0gYW5kIGN1bHR1cmUtc3BlY2lm aWMgdmFyaWF0aW9ucyBvZiBIYW4NCiAgIGlkZW9ncmFwaHMgYXMgdXNlZCBpbiBKYXBhbmVz ZSwgQ2hpbmVzZSwgYW5kIEtvcmVhbikuICBXaGVuIGxhbmd1YWdlDQogICB0YWdzIGFyZSBh cHBsaWVkIHRvIHNwYW5zIG9mIHRleHQsIHJlbmRlcmluZyBlbmdpbmVzIHNvbWV0aW1lcyB1 c2UNCiAgIHRoYXQgaW5mb3JtYXRpb24gaW4gZGVjaWRpbmcgd2hpY2ggZm9udCB0byB1c2Ug aW4gdGhlIGFic2VuY2Ugb2YNCiAgIG90aGVyIGluZm9ybWF0aW9uLCBwYXJ0aWN1bGFybHkg d2hlcmUgbGFuZ3VhZ2VzIHdpdGggZGlzdGluY3Qgd3JpdGluZw0KICAgdHJhZGl0aW9ucyB1 c2UgdGhlIHNhbWUgY2hhcmFjdGVycy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug NTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQo4LiAgQ2hhbmdlcyBmcm9tIFJGQyA0 NjQ2DQoNCiAgIFRoZSBtYWluIGdvYWwgZm9yIHRoaXMgcmV2aXNpb24gb2YgdGhpcyBkb2N1 bWVudCB3YXMgdG8gaW5jb3Jwb3JhdGUNCiAgIElTTyA2MzktMyBhbmQgaXRzIGF0dGVuZGVu dCBzZXQgb2YgbGFuZ3VhZ2UgY29kZXMgaW50byB0aGUgSUFOQQ0KICAgTGFuZ3VhZ2UgU3Vi dGFnIFJlZ2lzdHJ5LCBwZXJtaXR0aW5nIHRoZSBpZGVudGlmaWNhdGlvbiBvZiBtYW55IG1v cmUNCiAgIGxhbmd1YWdlcyBhbmQgZGlhbGVjdHMgdGhhbiBwcmV2aW91c2x5IHN1cHBvcnRl ZC4NCg0KICAgVGhlIHNwZWNpZmljIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCB0byBtZWV0 IHRoZXNlIGdvYWxzIGFyZToNCg0KICAgbyAgRGVmaW5lcyB0aGUgaW5jb3Jwb3JhdGlvbiBv ZiBJU08gNjM5LTMgY29kZXMgYXMgbGFuZ3VhZ2UgYW5kDQogICAgICBleHRsYW5nIHN1YnRh Z3MuICBFeHRsYW5ncyBhcmUgbm93IHBlcm1pdHRlZCBpbiBsYW5ndWFnZSB0YWdzLg0KICAg ICAgVGhlIGNoYW5nZXMgbmVjZXNzYXJ5IHRvIGFjaGlldmUgdGhpcyB3ZXJlOg0KDQogICAg ICAqICBzb21ldGhpbmcNCg0KICAgbyAgQ2hhbmdlZCB0aGUgQUJORiByZWxhdGVkIHRvIGdy YW5kZmF0aGVyZWQgdGFncy4gIFRoZSBpcnJlZ3VsYXINCiAgICAgIHRhZ3MgYXJlIG5vdyBs aXN0ZWQuICBXZWxsLWZvcm1lZCBncmFuZGZhdGhlcmVkIHRhZ3MgYXJlIG5vdw0KICAgICAg ZGVzY3JpYmVkIGJ5IHRoZSAnbGFuZ3RhZycgcHJvZHVjdGlvbiBhbmQgdGhlICdncmFuZGZh dGhlcmVkJw0KICAgICAgcHJvZHVjdGlvbiB3YXMgcmVtb3ZlZCBhcyBhIHJlc3VsdC4gIEFs c286IGFkZGVkIGRlc2NyaXB0aW9uIG9mDQogICAgICBib3RoIHR5cGVzIG9mIGdyYW5kZmF0 aGVyZWQgdGFncyB0byBTZWN0aW9uIDIuMi44Lg0KDQogICBvICBBZGRlZCB0aGUgcGFyYWdy YXBoIG9uICJjb2xsZWN0aW9ucyIgdG8gU2VjdGlvbiA0LjEuDQoNCiAgIG8gIENoYW5nZWQg dGhlIGNhcGl0YWxpemF0aW9uIHJ1bGVzIGZvciAnVGFnJyBmaWVsZHMgaW4gU2VjdGlvbiAz LjEuDQoNCiAgIG8gIFNwbGl0IHNlY3Rpb24gMy4xIHVwIGludG8gc3Vic2VjdGlvbnMuDQoN CiAgIG8gIE1vZGlmaWVkIHNlY3Rpb24gMy41IHRvIGFsbG93IFN1cHByZXNzLVNjcmlwdCBm aWVsZHMgdG8gYmUgYWRkZWQsDQogICAgICBtb2RpZmllZCwgb3IgcmVtb3ZlZCB2aWEgdGhl IHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgVGhpcyB3YXMgYW4NCiAgICAgIGVycmF0dW0gZnJv bSBSRkMgNDY0Ni4NCg0KICAgbyAgTW9kaWZpZWQgZXhhbXBsZXMgdGhhdCB1c2VkIHJlZ2lv biBjb2RlICdDUycgKGZvcm1lcmx5IFNlcmJpYSBhbmQNCiAgICAgIE1vbnRlbmVncm8pIHRv IHVzZSAnUlMnIChTZXJiaWEpIGluc3RlYWQuDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSBydWxl cyBmb3IgY3JlYXRpbmcgYW5kIG1haW50YWluaW5nIHJlY29yZA0KICAgICAgJ0Rlc2NyaXB0 aW9uJyBmaWVsZHMgdG8gcHJldmVudCBkdXBsaWNhdGVzLCBpbmNsdWRpbmcgaW52ZXJ0ZWQN CiAgICAgIGR1cGxpY2F0ZXMuDQoNCiAgIG8gIFJlbW92ZWQgdGhlIGxlbmd0aHkgZGVzY3Jp cHRpb24gb2Ygd2h5IFJGQyA0NjQ2IHdhcyBjcmVhdGVkIGZyb20NCiAgICAgIHRoaXMgc2Vj dGlvbiwgd2hpY2ggYWxzbyBjYXVzZWQgdGhlIHJlbW92YWwgb2YgdGhlIHJlZmVyZW5jZSB0 bw0KICAgICAgWE1MIFNjaGVtYS4NCg0KICAgbyAgTW9kaWZpZWQgdGhlIHRleHQgaW4gc2Vj dGlvbiAyLjEgdG8gcGxhY2UgbW9yZSBlbXBoYXNpcyBvbiB0aGUNCiAgICAgIGZhY3QgdGhh dCBsYW5ndWFnZSB0YWdzIGFyZSBub3QgY2FzZSBzZW5zaXRpdmUuDQoNCiAgIG8gIFJlcGxh Y2VkIHRoZSBleGFtcGxlICJmci1MYXRuLUNBIiBpbiBTZWN0aW9uIDIuMSB3aXRoICJzci1M YXRuLVJTIg0KICAgICAgYW5kICJhei1BcmFiLUlSIiBiZWNhdXNlICJmci1MYXRuLUNBIiBk b2Vzbid0IHJlc3BlY3QgdGhlDQogICAgICBTdXBwcmVzcy1TY3JpcHQgb24gJ0xhdG4nIHdp dGggJ2ZyJy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDYwXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA3DQoNCg0KICAgbyAgQ2hhbmdlZCB0aGUgcmVxdWlyZW1lbnRzIGZvciB3ZWxsLWZvcm1l ZG5lc3MgdG8gbWFrZSBzaW5nbGV0b24NCiAgICAgIHJlcGV0aXRpb24gY2hlY2tpbmcgb3B0 aW9uYWwgKGl0IGlzIHJlcXVpcmVkIGZvciB2YWxpZGl0eQ0KICAgICAgY2hlY2tpbmcpIGlu IFNlY3Rpb24gMi4yLjkuDQoNCiAgIG8gIENoYW5nZWQgdGhlIHRleHQgaW4gU2VjdGlvbiAy LjIuOSByZWZlcmluZyB0byBncmFuZGZhdGhlcmVkDQogICAgICBjaGVja2luZyB0byBub3Rl IHRoYXQgdGhlIGxpc3QgaXMgbm93IGluY2x1ZGVkIGluIHRoZSBBQk5GLg0KDQogICBvICBN b2RpZmllZCBhbmQgYWRkZWQgdGV4dCB0byBTZWN0aW9uIDMuMi4gIFRoZSBqb2IgZGVzY3Jp cHRpb24gd2FzDQogICAgICBwbGFjZWQgZmlyc3QuICBBIG5vdGUgd2FzIGFkZGVkIG1ha2lu ZyBjbGVhciB0aGF0IHRoZSBMYW5ndWFnZQ0KICAgICAgU3VidGFnIFJldmlld2VyIG1heSBk ZWxlZ2F0ZSB2YXJpb3VzIG5vbi1jcml0aWNhbCBkdXRpZXMsDQogICAgICBpbmNsdWRpbmcg bGlzdCBtb2RlcmF0aW9uLiAgRmluYWxseSwgYWRkaXRpb25hbCB0ZXh0IHdhcyBhZGRlZCB0 bw0KICAgICAgbWFrZSB0aGUgYXBwb2ludG1lbnQgcHJvY2VzcyBjbGVhciBhbmQgdG8gY2xh cmlmeSB0aGF0IGRlY2lzaW9ucw0KICAgICAgYW5kIHBlcmZvcm1hbmNlIG9mIHRoZSByZXZp ZXdlciBhcmUgYXBwZWFsYWJsZS4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byBTZWN0aW9uIDMu NSBjbGFyaWZ5aW5nIHRoYXQgdGhlIGlldGYtbGFuZ3VhZ2VzIGxpc3QNCiAgICAgIGlzIG9w ZXJhdGVkIGJ5IHdob21ldmVyIHRoZSBJRVNHIGFwcG9pbnRzLg0KDQogICBvICBBZGRlZCB0 ZXh0IHRvIFNlY3Rpb24gMy4xLjQgY2xhcmlmeWluZyB0aGF0IHRoZSBmaXJzdCBEZXNjcmlw dGlvbg0KICAgICAgaW4gYSAnbGFuZ3VhZ2UnIG9yICdleHRsYW5nJyByZWNvcmQgbWF0Y2hl cyB0aGUgY29ycmVzcG9uZGluZw0KICAgICAgUmVmZXJlbmNlIE5hbWUgZm9yIHRoZSBsYW5n dWFnZSBpbiBJU08gNjM5LTMuDQoNCiAgIG8gIE1vZGlmaWVkIFNlY3Rpb24gMi4yLjkgdG8g ZGVmaW5lIGNsYXNzZXMgb2YgY29uZm9ybWFuY2UgcmVsYXRlZCB0bw0KICAgICAgc3BlY2lm aWMgdGFncyAoZm9ybWVybHkgJ3dlbGwtZm9ybWVkJyBhbmQgJ3ZhbGlkJyByZWZlcnJlZCB0 bw0KICAgICAgaW1wbGVtZW50YXRpb25zKS4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byB0aGUg ZW5kIG9mIFNlY3Rpb24gMy4xLjIgbm90aW5nIHRoYXQgZnV0dXJlIHZlcnNpb25zDQogICAg ICBvZiB0aGlzIGRvY3VtZW50IG1pZ2h0IGFkZCBuZXcgZmllbGQgdHlwZXMgYW5kIHJlY29t bWVuZGluZyB0aGF0DQogICAgICBpbXBsZW1lbnRhdGlvbnMgaWdub3JlIGFueSB1bnJlY29n bml6ZWQgZmllbGRzLg0KDQogICBvICBNb2RpZmllZCB0aGUgJ2V4dGxhbmcnIGV4YW1wbGVz IGluIEFwcGVuZGl4IEEgdG8gdXNlIHZhbGlkIHN1YnRhZ3MNCiAgICAgIGFuZCByZW1vdmVk IHRoZSBub3RlIHNheWluZyB0aGF0IHRoZXkgd2VyZSBvbmx5IGV4YW1wbGVzLg0KDQogICBv ICBBZGRlZCB0ZXh0IGFib3V0IHdoYXQgdGhlIGxhY2sgb2YgYSBTdXBwcmVzcy1TY3JpcHQg ZmllbGQgbWVhbnMgaW4NCiAgICAgIGEgcmVjb3JkIHRvIFNlY3Rpb24gMy4xLjguDQoNCiAg IG8gIEFkZGVkIHRleHQgYWxsb3dpbmcgdGhlIGNvcnJlY3Rpb24gb2YgbWlzc3BlbGxpbmdz IGFuZCB0eXBvZ3JhcGhpYw0KICAgICAgZXJyb3JzIHRvIFNlY3Rpb24gMy4xLjQuDQoNCiAg IG8gIEFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjEuNyBkaXNhbGxvd2luZyBQcmVmaXggZmll bGQgY29uZmxpY3RzDQogICAgICAoc3VjaCBhcyBjaXJjdWxhciBwcmVmaXggcmVmZXJlbmNl cykuDQoNCiAgIG8gIE1vZGlmaWVkIHRleHQgaW4gU2VjdGlvbiAzLjUgdG8gcmVxdWlyZSB0 aGUgc3VidGFnIHJldmlld2VyIHRvDQogICAgICBhbm5vdW5jZSBoaXMvaGVyIGRlY2lzaW9u IChvciBleHRlbnNpb24pIGZvbGxvd2luZyB0aGUgdHdvLXdlZWsNCiAgICAgIHBlcmlvZC4g IEFsc28gY2xhcmlmaWVkIHRoYXQgYW55IGRlY2lzaW9uIG9yIGZhaWx1cmUgdG8gZGVjaWRl IGNhbg0KICAgICAgYmUgYXBwZWFsZWQuDQoNCiAgIG8gIE1vZGlmaWVkIHRleHQgaW4gU2Vj dGlvbiA0LjEgdG8gaW5jbHVkZSB0aGUgKGhlcmV0b2ZvcmUgYW5lY2RvdGFsKQ0KICAgICAg Z3VpZGluZyBwcmluY2lwbGUgb2YgdGFnIGNob2ljZSwgYW5kIGNsYXJpZnlpbmcgdGhlIG5v bi11c2Ugb2YNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDYxXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA3DQoNCg0KICAgICAgc2NyaXB0IHN1YnRhZ3MgaW4gbm9uLXdyaXR0ZW4gYXBwbGljYXRp b25zLiAgQWxzbyB1cGRhdGVkIGV4YW1wbGVzDQogICAgICBpbiB0aGlzIHNlY3Rpb24gdG8g dXNlIENoYW1pYyBsYW5ndWFnZXMgYXMgYW4gZXhhbXBsZSBvZiBsYW5ndWFnZQ0KICAgICAg Y29sbGVjdGlvbnMuDQoNCiAgIG8gIFByb2hpYml0ZWQgbXVsdGlwbGUgdXNlIG9mIHRoZSBz YW1lIHZhcmlhbnQgaW4gYSB0YWcgKGkuZS4gImRlLQ0KICAgICAgMTkwMS0xOTAxIikuICBQ cmV2aW91c2x5IHRoaXMgd2FzIG9ubHkgYSByZWNvbW1lbmRhdGlvbg0KICAgICAgKCJTSE9V TEQiKS4NCg0KICAgbyAgUmVtb3ZlZCBpbmFwcHJvcHJpYXRlIFtSRkMyMTE5XSBsYW5ndWFn ZSBmcm9tIHRoZSBpbGx1c3RyYXRpb24gaW4NCiAgICAgIFNlY3Rpb24gNC4zLjEuDQoNCiAg IG8gIFJlcGxhY2VkIHRoZSBleGFtcGxlIG9mICJ6aC1nb3V5dSIgd2l0aCAiemgtaGFra2Ei LT4iemgtaGFrIiBpbg0KICAgICAgU2VjdGlvbiA0LjQsIG5vdGluZyB0aGF0IGl0IHdhcyB0 aGlzIGRvY3VtZW50IHRoYXQgY2F1c2VkIHRoZQ0KICAgICAgY2hhbmdlLg0KDQogICBvICBS ZXBsYWNlZCB0aGUgc2VjdGlvbiBpbiBTZWN0aW9uIDQuMSBkZWFsaW5nIHdpdGggIm11bCIv InVuZCIgdG8NCiAgICAgIGluY2x1ZGUgdGhlIHN1YnRhZ3MgJ3p4eCcgYW5kICdtaXMnLCBh cyB3ZWxsIGFzIHRoZSB0YWcNCiAgICAgICJpLWRlZmF1bHQiLiAgQSBub3JtYXRpdmUgcmVm ZXJlbmNlIHRvIFJGQyAyMjc3IHdhcyBhZGRlZCwgYWxvbmcNCiAgICAgIHdpdGggYW4gaW5m b3JtYXRpdmUgcmVmZXJlbmNlIHRvIE1BUkMyMS4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byBT ZWN0aW9uIDMuNSBjbGFyaWZ5aW5nIHRoYXQgYW55IG1vZGlmaWNhdGlvbnMgb2YgYQ0KICAg ICAgcmVnaXN0cmF0aW9uIHJlcXVlc3QgbXVzdCBiZSBzZW50IHRvIHRoZSBpZXRmLWxhbmd1 YWdlcyBsaXN0DQogICAgICBiZWZvcmUgc3VibWlzc2lvbiB0byBJQU5BLg0KDQogICBvICBD aGFuZ2VkIHRoZSBBQk5GIGZvciB0aGUgcmVjb3JkLWphciBmb3JtYXQgZnJvbSB1c2luZyB0 aGUgTFdTUA0KICAgICAgcHJvZHVjdGlvbiB0byB1c2UgYSBmb2xkaW5nIHdoaXRlc3BhY2Ug cHJvZHVjdGlvbiBzaW1pbGFyIHRvIG9icy0NCiAgICAgIEZXUyBpbiBbUkZDNDIzNF0uICBU aGlzIGVmZmVjdGl2ZWx5IHByZXZlbnRzIHVuaW50ZW50aW9uYWwgYmxhbmsNCiAgICAgIGxp bmVzIGluc2lkZSBhIGZpZWxkLg0KDQogICBvICBDbGFyaWZpZWQgYW5kIHJldmlzZWQgdGV4 dCBpbiBTZWN0aW9uIDMuMywgU2VjdGlvbiAzLjUsIGFuZA0KICAgICAgU2VjdGlvbiA1LjEg dG8gY2xhcmlmeSB0aGF0IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgc2VuZHMgdGhl DQogICAgICBjb21wbGV0ZSByZWdpc3RyYXRpb24gZm9ybXMgdG8gSUFOQSwgdGhhdCBJQU5B IGV4dHJhY3RzIHRoZSByZWNvcmQNCiAgICAgIGZyb20gdGhlIGZvcm0sIGFuZCB0aGF0IHRo ZSBmb3JtcyBtdXN0IGFsc28gYmUgYXJjaGl2ZWQgc2VwYXJhdGVseQ0KICAgICAgZnJvbSB0 aGUgcmVnaXN0cnkuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gU2VjdGlvbiA1IHJlcXVpcmlu ZyBJQU5BIHRvIHNlbmQgYW4gYW5ub3VuY2VtZW50IHRvDQogICAgICBhbiBpZXRmLWxhbmd1 YWdlcy1hbm5vdW5jZSBsaXN0IHdoZW5ldmVyIHRoZSByZWdpc3RyeSBpcyB1cGRhdGVkLg0K DQogICBvICBNb2RpZmljYXRpb24gb2YgdGhlIHJlZ2lzdHJ5IHRvIHVzZSBVVEYtOCBhcyBp dHMgY2hhcmFjdGVyDQogICAgICBlbmNvZGluZy4gIFRoaXMgYWxzbyBlbnRhaWxzIGFkZGl0 aW9uYWwgaW5zdHJ1Y3Rpb25zIHRvIElBTkEgYW5kDQogICAgICB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyIGluIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgW1tFZC5O b3RlOiBPcGVuIGlzc3VlcyBpbiB0aGlzIHZlcnNpb246DQoNCiAgICAgIFdoZXRoZXIgZW5j b21wYXNzZWQgbGFuZ3VhZ2UgcnVsZXMgZm9yIHRoZSBjcmVhdGlvbiBvZiBleHRsYW5nDQog ICAgICByZWNvcmRzIGluIHRoZSByZWdpc3RyeSBzaG91bGQgYmUgcmV0YWluZWQgb3IgbW9k aWZpZWQuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgNjJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0 IDIwMDcNCg0KDQogICAgICBJbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBy ZWxhdGVkIHRvIFN1cHByZXNzLVNjcmlwdCBpbg0KICAgICAgdGhlIHJlZ2lzdHJ5IChlLmcu IHRoYXQgaXQgd2Fzbid0IGFzc2lnbmVkIG9uIHB1cnBvc2UpDQoNCiAgIF1dDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgNjNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQo5LiAgUmVmZXJlbmNlcw0KDQo5LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcw0KDQogICBbSVNPMTA2NDZdDQogICAgICAgICAgICAgIEludGVy bmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08vSUVDDQog ICAgICAgICAgICAgIDEwNjQ2OjIwMDMuIEluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLS0gVW5p dmVyc2FsIE11bHRpcGxlLQ0KICAgICAgICAgICAgICBPY3RldCBDb2RlZCBDaGFyYWN0ZXIg U2V0IChVQ1MpIiwgMjAwMy4NCg0KICAgW0lTTzE1OTI0XQ0KICAgICAgICAgICAgICBJbnRl cm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPDQogICAg ICAgICAgICAgIDE1OTI0OjIwMDQuIEluZm9ybWF0aW9uIGFuZCBkb2N1bWVudGF0aW9uIC0t IENvZGVzIGZvciB0aGUNCiAgICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMg b2Ygc2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0KICAgW0lTTzMxNjYtMV0NCiAgICAgICAg ICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwg IklTTyAzMTY2LQ0KICAgICAgICAgICAgICAxOjE5OTcuIENvZGVzIGZvciB0aGUgcmVwcmVz ZW50YXRpb24gb2YgbmFtZXMgb2YgY291bnRyaWVzDQogICAgICAgICAgICAgIGFuZCB0aGVp ciBzdWJkaXZpc2lvbnMgLS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIiwgMTk5Ny4NCg0KICAg W0lTTzYzOS0xXQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBm b3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPIDYzOS0NCiAgICAgICAgICAgICAgMToyMDAyLiBD b2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcw0KICAg ICAgICAgICAgICAtLSBQYXJ0IDE6IEFscGhhLTIgY29kZSIsIDIwMDIuDQoNCiAgIFtJU082 MzktMl0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0 YW5kYXJkaXphdGlvbiwgIklTTyA2MzktDQogICAgICAgICAgICAgIDI6MTk5OC4gQ29kZXMg Zm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAg ICAgICAgLS0gUGFydCAyOiBBbHBoYS0zIGNvZGUsIGZpcnN0IGVkaXRpb24iLCAxOTk4Lg0K DQogICBbSVNPNjM5LTNdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0 aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAgICAgICAzOjIw MDcuIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2Vz DQogICAgICAgICAgICAgIC0tIFBhcnQgMzogQWxwaGEtMyBjb2RlIGZvciBjb21wcmVoZW5z aXZlIGNvdmVyYWdlIG9mDQogICAgICAgICAgICAgIGxhbmd1YWdlcyIsIDIwMDcuDQoNCiAg IFtJU082NDZdICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXph dGlvbiwgIklTTy9JRUMNCiAgICAgICAgICAgICAgNjQ2OjE5OTEsIEluZm9ybWF0aW9uIHRl Y2hub2xvZ3kgLS0gSVNPIDctYml0IGNvZGVkDQogICAgICAgICAgICAgIGNoYXJhY3RlciBz ZXQgZm9yIGluZm9ybWF0aW9uIGludGVyY2hhbmdlLiIsIDE5OTEuDQoNCiAgIFtSRkMyMDI2 XSAgQnJhZG5lciwgUy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0gUmV2 aXNpb24NCiAgICAgICAgICAgICAgMyIsIEJDUCA5LCBSRkMgMjAyNiwgT2N0b2JlciAxOTk2 Lg0KDQogICBbUkZDMjAyOF0gIEhvdmV5LCBSLiBhbmQgUy4gQnJhZG5lciwgIlRoZSBPcmdh bml6YXRpb25zIEludm9sdmVkIGluDQogICAgICAgICAgICAgIHRoZSBJRVRGIFN0YW5kYXJk cyBQcm9jZXNzIiwgQkNQIDExLCBSRkMgMjAyOCwNCiAgICAgICAgICAgICAgT2N0b2JlciAx OTk2Lg0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi LCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1BhZ2Ug NjRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBbUkZDMjI3N10gIEFsdmVzdHJh bmQsIEguLCAiSUVURiBQb2xpY3kgb24gQ2hhcmFjdGVyIFNldHMgYW5kDQogICAgICAgICAg ICAgIExhbmd1YWdlcyIsIEJDUCAxOCwgUkZDIDIyNzcsIEphbnVhcnkgMTk5OC4NCg0KICAg W1JGQzI0MzRdICBOYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBm b3IgV3JpdGluZyBhbg0KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rp b24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDIDI0MzQsDQogICAgICAgICAgICAgIE9jdG9iZXIg MTk5OC4NCg0KICAgW1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwgRi4sIGFuZCBN LiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBVbmRlcnN0YW5kaW5n IENvbmNlcm5pbmcgdGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAgICAgICAgICBJ bnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIw MDAuDQoNCiAgIFtSRkMzMzM5XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFu ZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDoNCiAgICAgICAgICAgICAgVGltZXN0YW1wcyIsIFJG QyAzMzM5LCBKdWx5IDIwMDIuDQoNCiAgIFtSRkM0MjM0XSAgQ3JvY2tlciwgRC4gYW5kIFAu IE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAgICAgICAgU3Bl Y2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNDIzNCwgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZD NDY0NV0gIEV3ZWxsLCBELiwgRWQuLCAiSW5pdGlhbCBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0 cnkiLA0KICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNiwgPGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjL3JmYzQ2NDUudHh0Pi4NCg0KICAgW1JGQzQ2NDddICBQaGlsbGlwcywgQS4sIEVk LiBhbmQgTS4gRGF2aXMsIEVkLiwgIk1hdGNoaW5nIG9mIExhbmd1YWdlDQogICAgICAgICAg ICAgIFRhZ3MiLCBTZXB0ZW1iZXIgMjAwNiwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjL3JmYzQ2NDcudHh0Pi4NCg0KICAgW1VOX00uNDldICBTdGF0aXN0aWNz IERpdmlzaW9uLCBVbml0ZWQgTmF0aW9ucywgIlN0YW5kYXJkIENvdW50cnkgb3INCiAgICAg ICAgICAgICAgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIiwgVU4gU3RhbmRhcmQg Q291bnRyeSBvcg0KICAgICAgICAgICAgICBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBV c2UsIFJldmlzaW9uIDQgKFVuaXRlZCBOYXRpb25zDQogICAgICAgICAgICAgIHB1YmxpY2F0 aW9uLCBTYWxlcyBOby4gOTguWFZJSS45LCBKdW5lIDE5OTkuDQoNCjkuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzE3NjZdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3Mg Zm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBS RkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0KICAgW1JGQzIwNDddICBNb29yZSwgSy4sICJNSU1F IChNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zKQ0KICAgICAgICAgICAg ICBQYXJ0IFRocmVlOiBNZXNzYWdlIEhlYWRlciBFeHRlbnNpb25zIGZvciBOb24tQVNDSUkg VGV4dCIsDQogICAgICAgICAgICAgIFJGQyAyMDQ3LCBOb3ZlbWJlciAxOTk2Lg0KDQogICBb UkZDMjIzMV0gIEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1 ZSBhbmQgRW5jb2RlZA0KICAgICAgICAgICAgICBXb3JkIEV4dGVuc2lvbnM6IENoYXJhY3Rl ciBTZXRzLCBMYW5ndWFnZXMsIGFuZA0KICAgICAgICAgICAgICBDb250aW51YXRpb25zIiwg UkZDIDIyMzEsIE5vdmVtYmVyIDE5OTcuDQoNCiAgIFtSRkMyNzgxXSAgSG9mZm1hbiwgUC4g YW5kIEYuIFllcmdlYXUsICJVVEYtMTYsIGFuIGVuY29kaW5nIG9mIElTTw0KICAgICAgICAg ICAgICAxMDY0NiIsIFJGQyAyNzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBbUkZDMzA2Nl0g IEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAg ICAgICAgICAgIExhbmd1YWdlcyIsIEJDUCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4N Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwg MjAwOCAgICAgICAgICAgICAgW1BhZ2UgNjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0K DQogICBbUkZDMzU1Ml0gIFJlc2NvcmxhLCBFLiBhbmQgQi4gS29ydmVyLCAiR3VpZGVsaW5l cyBmb3IgV3JpdGluZyBSRkMNCiAgICAgICAgICAgICAgVGV4dCBvbiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyIsIEJDUCA3MiwgUkZDIDM1NTIsDQogICAgICAgICAgICAgIEp1bHkgMjAw My4NCg0KICAgW1JGQzM2MjldICBZZXJnZWF1LCBGLiwgIlVURi04LCBhIHRyYW5zZm9ybWF0 aW9uIGZvcm1hdCBvZiBJU08NCiAgICAgICAgICAgICAgMTA2NDYiLCBTVEQgNjMsIFJGQyAz NjI5LCBOb3ZlbWJlciAyMDAzLg0KDQogICBbUkZDNDY0Nl0gIFBoaWxsaXBzLCBBLiwgRWQu IGFuZCBNLiBEYXZpcywgRWQuLCAiVGFncyBmb3IgdGhlDQogICAgICAgICAgICAgIElkZW50 aWZpY2F0aW9uIG9mIExhbmd1YWdlcyIsIFNlcHRlbWJlciAyMDA2LA0KICAgICAgICAgICAg ICA8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNDY0Ni50eHQ+Lg0KDQogICBbVW5pY29k ZV0gIFVuaWNvZGUgQ29uc29ydGl1bSwgIlRoZSBVbmljb2RlIENvbnNvcnRpdW0uIFRoZSBV bmljb2RlDQogICAgICAgICAgICAgIFN0YW5kYXJkLCBWZXJzaW9uIDUuMCwgKEJvc3Rvbiwg TUEsIEFkZGlzb24tV2VzbGV5LCAyMDAzLg0KICAgICAgICAgICAgICBJU0JOIDAtMzIxLTQ5 MDgxLTApIiwgSmFudWFyeSAyMDA3Lg0KDQogICBbaXNvNjM5LnByaW5dDQogICAgICAgICAg ICAgIElTTyA2MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlLCAiSVNPIDYzOSBKb2ludCBB ZHZpc29yeQ0KICAgICAgICAgICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBsZXMg Zm9yIElTTyA2MzkgbWFpbnRlbmFuY2UiLA0KICAgICAgICAgICAgICBNYXJjaCAyMDAwLA0K ICAgICAgICAgICAgICA8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi8N CiAgICAgICAgICAgICAgaXNvNjM5amFjX24zci5odG1sPi4NCg0KICAgW3JlY29yZC1qYXJd DQogICAgICAgICAgICAgIFJheW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1t aW5nIiwgMjAwMywNCiAgICAgICAgICAgICAgPHVybjppc2JuOjAtMTMtMTQyOTAxLTk+Lg0K DQogICBbcmVnaXN0cnktdXBkYXRlXQ0KICAgICAgICAgICAgICBFd2VsbCwgRC4sIEVkLiwg IlVwZGF0ZSB0byB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IiwNCiAgICAgICAgICAg ICAgU2VwdGVtYmVyIDIwMDYsIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtcmVnaXN0cnktMDAu dHh0Pi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDggICAgICAgICAg ICAgIFtQYWdlIDY2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KQXBwZW5kaXggQS4g IEFja25vd2xlZGdlbWVudHMNCg0KICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlzIGJv dW5kIHRvIGJlIGluY29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlDQogICBmb2xsb3dpbmcg YXMgb25seSBhIHNlbGVjdGlvbiBmcm9tIHRoZSBncm91cCBvZiBwZW9wbGUgd2hvIGhhdmUN CiAgIGNvbnRyaWJ1dGVkIHRvIG1ha2UgdGhpcyBkb2N1bWVudCB3aGF0IGl0IGlzIHRvZGF5 Lg0KDQogICBUaGUgY29udHJpYnV0b3JzIHRvIFJGQyA0NjQ2LCBSRkMgNDY0NywgUkZDIDMw NjYsIGFuZCBSRkMgMTc2NiwgdGhlDQogICBwcmVjdXJzb3JzIG9mIHRoaXMgZG9jdW1lbnQs IG1hZGUgZW5vcm1vdXMgY29udHJpYnV0aW9ucyBkaXJlY3RseSBvcg0KICAgaW5kaXJlY3Rs eSB0byB0aGlzIGRvY3VtZW50IGFuZCBhcmUgZ2VuZXJhbGx5IHJlc3BvbnNpYmxlIGZvciB0 aGUNCiAgIHN1Y2Nlc3Mgb2YgbGFuZ3VhZ2UgdGFncy4NCg0KICAgVGhlIGZvbGxvd2luZyBw ZW9wbGUgY29udHJpYnV0ZWQgdG8gdGhpcyBkb2N1bWVudDoNCg0KICAgU3RlcGhhbmUgQm9y dHptZXllciwgS2FyZW4gQnJvb21lLCBQZXRlciBDb25zdGFibGUsIEpvaG4gQ293YW4sDQog ICBNYXJ0aW4gRHVlcnN0LCBGcmFuayBFbGxlcm1hbiwgRG91ZyBFd2VsbCwgRGVib3JhaCBH YXJzaWRlLCBNYXJpb24NCiAgIEd1bm4sIEtlbnQgS2FybHNzb24sIENocmlzIE5ld21hbiwg UmFuZHkgUHJlc3VobiwgU3RlcGhlbiBTaWx2ZXIsIGFuZA0KICAgbWFueSwgbWFueSBvdGhl cnMuDQoNCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQg QWx2ZXN0cmFuZCwgd2hvDQogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBhbmQgMzA2NiwgYW5k IHdpdGhvdXQgd2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBub3QgaGF2ZSBiZWVuIHBv c3NpYmxlLg0KDQogICBTcGVjaWFsIHRoYW5rcyBnbyB0byBNaWNoYWVsIEV2ZXJzb24sIHdo byBzZXJ2ZWQgYXMgdGhlIExhbmd1YWdlIFRhZw0KICAgUmV2aWV3ZXIgZm9yIGFsbW9zdCB0 aGUgZW50aXJlIFJGQyAxNzY2L1JGQyAzMDY2IHBlcmlvZCwgYXMgd2VsbCBhcw0KICAgdGhl IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBzaW5jZSB0aGUgYWRvcHRpb24gb2YgUkZDIDQ2 NDYuDQoNCiAgIFNwZWNpYWwgdGhhbmtzIGFsc28gdG8gRG91ZyBFd2VsbCwgZm9yIGhpcyBw cm9kdWN0aW9uIG9mIHRoZSBmaXJzdA0KICAgY29tcGxldGUgc3VidGFnIHJlZ2lzdHJ5LCBo aXMgd29yayB0byBzdXBwb3J0IGFuZCBtYWludGFpbiBuZXcNCiAgIHJlZ2lzdHJhdGlvbnMs IGFuZCBoaXMgY2FyZWZ1bCBlZGl0b3JzaGlwIG9mIGJvdGggUkZDIDQ2NDUgYW5kDQogICBb cmVnaXN0cnktdXBkYXRlXS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIw MDggICAgICAgICAgICAgIFtQYWdlIDY3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0K QXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKQ0K DQogICBTaW1wbGUgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBkZSAoR2VybWFuKQ0KDQog ICAgICBmciAoRnJlbmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoNCiAgICAgIGktZW5v Y2hpYW4gKGV4YW1wbGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0KICAgTGFuZ3VhZ2Ug c3VidGFnIHBsdXMgU2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hpbmVzZSB3 cml0dGVuIHVzaW5nIHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAg emgtSGFucyAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ug c2NyaXB0KQ0KDQogICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlIEN5 cmlsbGljIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0biAoU2VyYmlhbiB3cml0dGVuIHVzaW5n IHRoZSBMYXRpbiBzY3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb246DQoNCiAg ICAgIHpoLUhhbnMtQ04gKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgU2ltcGxpZmllZCBz Y3JpcHQgYXMgdXNlZCBpbg0KICAgICAgbWFpbmxhbmQgQ2hpbmEpDQoNCiAgICAgIHNyLUxh dG4tUlMgKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0IGFzIHVzZWQg aW4NCiAgICAgIFNlcmJpYSkNCg0KICAgTGFuZ3VhZ2UtVmFyaWFudDoNCg0KICAgICAgc2wt cm96YWogKFJlc2lhbiBkaWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgICAgc2wtbmVkaXMg KE5hZGl6YSBkaWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZh cmlhbnQ6DQoNCiAgICAgIGRlLUNILTE5MDEgKEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJs YW5kIHVzaW5nIHRoZSAxOTAxIHZhcmlhbnQNCiAgICAgIFtvcnRob2dyYXBoeV0pDQoNCiAg ICAgIHNsLUlULW5lZGlzIChTbG92ZW5pYW4gYXMgdXNlZCBpbiBJdGFseSwgTmFkaXphIGRp YWxlY3QpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb24tVmFyaWFudDoNCg0KDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAw OCAgICAgICAgICAgICAgW1BhZ2UgNjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQog ICAgICBoeS1MYXRuLUlULWFyZXZlbGEgKEVhc3Rlcm4gQXJtZW5pYW4gd3JpdHRlbiBpbiBM YXRpbiBzY3JpcHQsIGFzDQogICAgICB1c2VkIGluIEl0YWx5KQ0KDQogICBMYW5ndWFnZS1S ZWdpb246DQoNCiAgICAgIGRlLURFIChHZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAgIGVu LVVTIChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMpDQoNCiAgICAgIGVz LTQxOSAoU3BhbmlzaCBhcHByb3ByaWF0ZSBmb3IgdGhlIExhdGluIEFtZXJpY2EgYW5kIENh cmliYmVhbg0KICAgICAgcmVnaW9uIHVzaW5nIHRoZSBVTiByZWdpb24gY29kZSkNCg0KICAg UHJpdmF0ZSB1c2Ugc3VidGFnczoNCg0KICAgICAgZGUtQ0gteC1waG9uZWJrDQoNCiAgICAg IGF6LUFyYWIteC1BWkUtZGVyYmVuZA0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdz Og0KDQogICAgICB6aC1jbW4NCg0KICAgICAgemgtY21uLUhhbnQtQ04NCg0KICAgUHJpdmF0 ZSB1c2UgcmVnaXN0cnkgdmFsdWVzOg0KDQogICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVz ZSB1c2luZyB0aGUgc2luZ2xldG9uICd4JykNCg0KICAgICAgcWFhLVFhYWEtUU0teC1zb3V0 aGVybiAoYWxsIHByaXZhdGUgdGFncykNCg0KICAgICAgZGUtUWFhYSAoR2VybWFuLCB3aXRo IGEgcHJpdmF0ZSBzY3JpcHQpDQoNCiAgICAgIHNyLUxhdG4tUU0gKFNlcmJpYW4sIExhdGlu LXNjcmlwdCwgcHJpdmF0ZSByZWdpb24pDQoNCiAgICAgIHNyLVFhYWEtUlMgKFNlcmJpYW4s IHByaXZhdGUgc2NyaXB0LCBmb3IgU2VyYmlhKQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVu c2lvbnMgKGV4YW1wbGVzIE9OTFk6IGV4dGVuc2lvbnMgTVVTVCBiZSBkZWZpbmVkDQogICBi eSByZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCBvciBieSBSRkMpOg0KDQog ICAgICBlbi1VUy11LWlzbGFtQ2FsDQoNCiAgICAgIHpoLUNOLWEtbXlFeHQteC1wcml2YXRl DQoNCiAgICAgIGVuLWEtbXlFeHQtYi1hbm90aGVyDQoNCiAgIFNvbWUgSW52YWxpZCBUYWdz Og0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MjUsIDIwMDggICAgICAgICAgICAgIFtQYWdlIDY5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3 DQoNCg0KICAgICAgZGUtNDE5LURFICh0d28gcmVnaW9uIHRhZ3MpDQoNCiAgICAgIGEtREUg KHVzZSBvZiBhIHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFnIGluIHByaW1hcnkgcG9zaXRpb247 IG5vdGUNCiAgICAgIHRoYXQgdGhlcmUgYXJlIGEgZmV3IGdyYW5kZmF0aGVyZWQgdGFncyB0 aGF0IHN0YXJ0IHdpdGggImktIiB0aGF0DQogICAgICBhcmUgdmFsaWQpDQoNCiAgICAgIGFy LWEtYWFhLWItYmJiLWEtY2NjICh0d28gZXh0ZW5zaW9ucyB3aXRoIHNhbWUgc2luZ2xlLWxl dHRlcg0KICAgICAgcHJlZml4KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAg ICAgICAgICBbUGFnZSA3MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCkFwcGVuZGl4 IEMuICBFeGFtcGxlcyBvZiBSZWdpc3RyYXRpb24gRm9ybXMNCiAgIExBTkdVQUdFIFNVQlRB RyBSRUdJU1RSQVRJT04gRk9STQ0KICAgMS4gTmFtZSBvZiByZXF1ZXN0ZXI6IEhhbiBTdGVl bndpamsNCiAgIDIuIEUtbWFpbCBhZGRyZXNzIG9mIHJlcXVlc3RlcjogaGFuLnN0ZWVud2lq ayBAIHVuaXBkLml0DQogICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICBUeXBlOiAgICAg ICAgdmFyaWFudA0KICAgU3VidGFnOiAgICAgIGJpc2tlDQogICBEZXNjcmlwdGlvbjogVGhl IFNhbiBHaW9yZ2lvIGRpYWxlY3Qgb2YgUmVzaWFuDQogICBEZXNjcmlwdGlvbjogVGhlIEJp bGEgZGlhbGVjdCBvZiBSZXNpYW4NCiAgIFByZWZpeDogICAgICBzbC1yb3phag0KICAgQ29t bWVudHM6ICAgIFRoZSBkaWFsZWN0IG9mIFNhbiBHaW9yZ2lvL0JpbGEgaXMgb25lIG9mIHRo ZQ0KICAgICAgZm91ciBtYWpvciBsb2NhbCBkaWFsZWN0cyBvZiBSZXNpYW4NCg0KICAgNC4g SW50ZW5kZWQgbWVhbmluZyBvZiB0aGUgc3VidGFnOiBUaGUgbG9jYWwgdmFyaWV0eSBvZiBS ZXNpYW4gYXMNCiAgIHNwb2tlbiBpbiBTYW4gR2lvcmdpby9CaWxhDQoNCiAgIDUuIFJlZmVy ZW5jZSB0byBwdWJsaXNoZWQgZGVzY3JpcHRpb24gb2YgdGhlIGxhbmd1YWdlIChib29rIG9y DQogICBhcnRpY2xlKToNCiAgICAtLSBKYW4gSS5OLiBCYXVkb3VpbiBkZSBDb3VydGVuYXkg LSBPcHl0IGZvbmV0aWtpIHJleidqYW5za2ljaA0KICAgZ292b3JvdiwgVmFyc2F2YSAtIFBl dGVyYnVyZzogVmVuZGUgLSBLb3phbmNpa292LCAxODc1Lg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNSwgMjAwOCAgICAgICAgICAgICAgW1Bh Z2UgNzFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQpMQU5HVUFHRSBTVUJUQUcgUkVH SVNUUkFUSU9OIEZPUk0NCjEuIE5hbWUgb2YgcmVxdWVzdGVyOiBKYXNrYSBaZWRsaWsNCjIu IEUtbWFpbCBhZGRyZXNzIG9mIHJlcXVlc3Rlcjogano1MyBAIHplZGxpay5jb20NCjMuIFJl Y29yZCBSZXF1ZXN0ZWQ6DQoNClR5cGU6ICAgdmFyaWFudA0KU3VidGFnOiB0YXJhc2sNCkRl c2NyaXB0aW9uOiBCZWxhcnVzaWFuIGluIFRhcmFza2lldmljYSBvcnRob2dyYXBoeQ0KUHJl Zml4OiBiZQ0KQ29tbWVudHM6IFRoZSBzdWJ0YWcgcmVwcmVzZW50cyBCcmFuaXNsYXUgVGFy YXNraWV2aWMncyBCZWxhcnVzaWFuDQogIG9ydGhvZ3JhcGh5IGFzIHB1Ymxpc2hlZCBpbiAi QmllbGFydXNraSBrbGFzeWNueSBwcmF2YXBpcyIgYnkgSnVyYXMNCiAgQnVzbGFrb3UsIFZp bmN1ayBWaWFjb3JrYSwgWm1pY2llciBTYW5rbywgYW5kIFptaWNpZXIgU2F1a2ENCiAgKFZp bG5pYS1NaWVuc2sgMjAwNSkuDQoNCjQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhlIHN1YnRh ZzoNCg0KVGhlIHN1YnRhZyBpcyBpbnRlbmRlZCB0byByZXByZXNlbnQgdGhlIEJlbGFydXNp YW4gb3J0aG9ncmFwaHkgYXMNCnB1Ymxpc2hlZCBpbiAiQmllbGFydXNraSBrbGFzeWNueSBw cmF2YXBpcyIgYnkgSnVyYXMgQnVzbGFrb3UsIFZpbmN1aw0KVmlhY29ya2EsIFptaWNpZXIg U2Fua28sIGFuZCBabWljaWVyIFNhdWthIChWaWxuaWEtTWllbnNrIDIwMDUpLg0KDQo1LiBS ZWZlcmVuY2UgdG8gcHVibGlzaGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBsYW5ndWFnZSAoYm9v ayBvciBhcnRpY2xlKToNCg0KVGFyYXNraWV2aWMsIEJyYW5pc2xhdS4gQmllbGFydXNrYWph IGdyYW1hdHlrYSBkbGEgc2tvbC4gVmlsbmlhOiBWeWQuDQoiQmllbGFydXNrYWhhIGthbWl0 ZXR1IiwgMTkyOSwgNXRoIGVkaXRpb24uDQoNCkJ1c2xha291LCBKdXJhczsgVmlhY29ya2Es IFZpbmN1azsgU2Fua28sIFptaWNpZXI7IFNhdWthLCBabWljaWVyLg0KQmllbGFydXNraSBr bGFzeWNueSBwcmF2YXBpcy4gVmlsbmlhLU1pZW5zaywgMjAwNS4NCg0KNi4gQW55IG90aGVy IHJlbGV2YW50IGluZm9ybWF0aW9uOg0KDQpCZWxhcnVzaWFuIGluIFRhcmFza2lldmljYSBv cnRob2dyYXBoeSBiZWNhbWUgd2lkZWx5IHVzZWQsIGVzcGVjaWFsbHkgaW4NCkJlbGFydXNp YW4tc3BlYWtpbmcgSW50ZXJuZXQgc2VnbWVudCwgYnV0IGJlc2lkZXMgdGhpcyBzb21lIGJv b2tzIGFuZA0KbmV3c3BhcGVycyBhcmUgYWxzbyBwcmludGVkIHVzaW5nIHRoaXMgb3J0aG9n cmFwaHkgb2YgQmVsYXJ1c2lhbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjUsIDIwMDgg ICAgICAgICAgICAgIFtQYWdlIDcyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KQXV0 aG9ycycgQWRkcmVzc2VzDQoNCiAgIEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikNCiAgIFlh aG9vISBJbmMuDQoNCiAgIEVtYWlsOiBhZGRpc29uQGludGVyLWxvY2FsZS5jb20NCiAgIFVS STogICBodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20NCg0KDQogICBNYXJrIERhdmlzIChl ZGl0b3IpDQogICBHb29nbGUNCg0KICAgRW1haWw6IG1hcmsuZGF2aXNAbWFjY2hpYXRvLmNv bSBvciBtYXJrLmRhdmlzQGdvb2dsZS5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI1LCAyMDA4ICAgICAgICAg ICAgICBbUGFnZSA3M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCkZ1bGwgQ29weXJp Z2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vu c2VzIGFuZCByZXN0cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNl cHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRo ZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMN CiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFks IFRIRSBJRVRGIFRSVVNUIEFORA0KICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MNCiAgIE9SIElNUExJRUQs IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVT RSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkg UklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1 YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAg cGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5 IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNo IGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3Qg YmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1h ZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMu ICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJp Z2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBC Q1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVU RiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJl IG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUg dG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ug b2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2Vy cyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJ RVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJy aW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBh dGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhh dCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24g dG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdt ZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3Zp ZGVkIGJ5IHRoZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJ QVNBKS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI1LCAyMDA4ICAgICAgICAgICAgICBbUGFnZSA3NF0NCgwNCg== --------------040309020300080408060809 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 --------------040309020300080408060809-- From ltru-bounces@ietf.org Fri Aug 24 22:34: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 1IOlTR-0000wX-E2; Fri, 24 Aug 2007 22:34:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOlTP-0000wS-GW for ltru-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 22:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOlTP-0000wK-73 for ltru@ietf.org; Fri, 24 Aug 2007 22:34:03 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOlTN-0006p8-Vw for ltru@ietf.org; Fri, 24 Aug 2007 22:34:03 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070825023400.HSZA19326.mta15.adelphia.net@DGBP7M81>; Fri, 24 Aug 2007 22:34:00 -0400 Message-ID: <006c01c7e6c0$652ce9a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> <005301c7e614$afac0850$6401a8c0@DGBP7M81> <46CEFD90.6030604@yahoo-inc.com> Subject: Re: [Ltru] NFC Date: Fri, 24 Aug 2007 19:34:00 -0700 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.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Actually, this is a flaw in our version of record-jar. What we should > have is the line-continuation character at the end of the previous > line. Otherwise languages that use spaces to separate words are at a > disadvantage... or languages that don't use spaces will have spurious > ones introduced (pick your poison). Yeah, but I don't think we've got room right now for another change in the registry format, considering that 4646bis was widely portrayed as "ISO 639-3 plus a few minor tweaks." I'd like to see both drafts go to WG Last Call by the end of September 2007. Can we manage that? > John's objection that the U+0301 combines with the leading whitespace > on the second line wouldn't hold if unwrapping were considered a > higher-order file formatting rule. That is, the whitespace at the > start of the second line isn't considered to be part of the text. > This, actually, is how I considered it to work in my own > implementations and the reason I only specified code point separation > previously. Actually, the way I view wrapping is that the whitespace at the start of the second line ISN'T part of the text. Rather, the CRLF at the end of the first line and the two spaces at the start of the second line are removed, and then a single space is inserted. I don't know if that's confusing to anyone else, but it makes sense to me. Since we already reference Unicode, I suppose we could add a rule that a space should or should not be inserted at the line-wrap point depending on the Script category of the surrounding text. That would be compatible with what we say now about the matter (viz. nothing). But since this is only likely to affect Comments fields, you can imagine how low a priority I think it should be. -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 25 00:09: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 1IOmxy-00081a-JT; Sat, 25 Aug 2007 00:09:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IOmxx-00081U-2u for ltru-confirm+ok@megatron.ietf.org; Sat, 25 Aug 2007 00:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOmxw-00081M-Ph for ltru@ietf.org; Sat, 25 Aug 2007 00:09:40 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOmxv-0008PE-Bh for ltru@ietf.org; Sat, 25 Aug 2007 00:09:40 -0400 Received: by wa-out-1112.google.com with SMTP id m16so1186574waf for ; Fri, 24 Aug 2007 21:09:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=CcieUGENdc4wvoc04aiX12NrZJxU+pybbScIf1+6WTy4k5ZZUGkPSNZ3OSeF75wT00QE9A8ZnpfXMyx3YJh74bgPp9VkEItq18KYTYscPt2uz7dikNkw9B4XpnAw8JgraRrp7kIlYBfmH7AJ7G43EW+6/uFqkhsXuM4u58e1sfw= 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=m3dk+S0+MNcmqJ0bMIRlgv0Mh1JoP1e17iKcq3RKE8iPcBMRky8IY4OxqlPPX9E1VpeRkKvNxBhvOjiqSk4QMC3ncDUDVtDkowy9sF9EpVxAqdulXL1lzt9x8o+xdE/owUm/L2R1WfBjzJEQWXweBhWwZFudVONxHcXU8o5J60I= Received: by 10.114.53.1 with SMTP id b1mr663685waa.1188014978516; Fri, 24 Aug 2007 21:09:38 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Fri, 24 Aug 2007 21:09:38 -0700 (PDT) Message-ID: <30b660a20708242109w5aac4dfdwa71405aa9a9fd68e@mail.gmail.com> Date: Fri, 24 Aug 2007 21:09:38 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] NFC In-Reply-To: <006c01c7e6c0$652ce9a0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <00de01c7e2c9$e487aff0$6401a8c0@DGBP7M81> <20070823122229.GA6422@mercury.ccil.org> <005301c7e614$afac0850$6401a8c0@DGBP7M81> <46CEFD90.6030604@yahoo-inc.com> <006c01c7e6c0$652ce9a0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 6a175b71a5365cae X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1677447911==" Errors-To: ltru-bounces@ietf.org --===============1677447911== Content-Type: multipart/alternative; boundary="----=_Part_21366_18605744.1188014978462" ------=_Part_21366_18605744.1188014978462 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > I'd like to see both drafts go to WG Last Call by the end of September > 2007. Can we manage that? It really depends on whether we can resolve the extlang question -- I think that is the only major outstanding issue. Mark ------=_Part_21366_18605744.1188014978462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'd like to see both drafts go to WG Last Call by the end of September
2007.  Can we manage that?


It really depends on whether we can resolve the extlang question -- I think that is the only major outstanding issue.

Mark
------=_Part_21366_18605744.1188014978462-- --===============1677447911== 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 --===============1677447911==-- From ltru-bounces@ietf.org Tue Aug 28 08:55: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 1IQ0bc-0005UZ-Ka; Tue, 28 Aug 2007 08:55:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ0bb-0005UQ-GL for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 08:55:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ0bb-0005UH-6G for ltru@ietf.org; Tue, 28 Aug 2007 08:55:39 -0400 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQ0ba-0007E8-DZ for ltru@ietf.org; Tue, 28 Aug 2007 08:55:38 -0400 Received: (qmail 73648 messnum 2900909 invoked from network[194.125.205.5/ts07-005.dublin.indigo.ie]); 28 Aug 2007 12:55:36 -0000 Received: from ts07-005.dublin.indigo.ie (HELO ?194.125.205.5?) (194.125.205.5) by mail06.svc.cra.dublin.eircom.net (qp 73648) with SMTP; 28 Aug 2007 12:55:36 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <46CF54C4.2090707@yahoo-inc.com> References: <46CF54C4.2090707@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 Date: Tue, 28 Aug 2007 13:55:39 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For starters, suggest losing the entire first sentence of paragraph 1 =20= below, inserting the word "human" before "language" in its second =20 sentence and inserting the following comma-plus-clause text ", such =20 reasons as are set out below" before its closing full stop. mg On 24 Aug 2007, at 21:59, scr=EDobh Addison Phillips: > Phillips & Davis Expires February 25, 2008 =20 > [Page 3] > Internet-Draft langtags-registry August =20= > 2007 > > > 1. Introduction > > Human beings on our planet have, past and present, used a number of > languages. There are many reasons why one would want to =20 > identify the > language used when presenting or requesting information. > > -- Marion Gunn mgunn@ucd.ie= _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 09: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 1IQ1Vx-0006aJ-Nq; Tue, 28 Aug 2007 09:53:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ1Vw-0006aD-Is for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 09:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1Vw-0006a5-9P for ltru@ietf.org; Tue, 28 Aug 2007 09:53:52 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ1Vu-0002L2-Vy for ltru@ietf.org; Tue, 28 Aug 2007 09:53:52 -0400 Received: from [10.72.77.153] (snvvpn2-10-72-77-c153.corp.yahoo.com [10.72.77.153]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7SDrctJ071344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 06:53:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=D5Pk/EwRLhSojl/Ul4s+77tW2HrCTTdsukC0j3UYpFOfkSFyU5kujavL/G69h/Qo Message-ID: <46D428E2.50804@yahoo-inc.com> Date: Tue, 28 Aug 2007 06:53:38 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 References: <46CF54C4.2090707@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp1.corp.yahoo.com id l7SDrctJ071344 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Marion, This text has existed for a long time. In fact, it is taken verbatim=20 from RFC 3066 (RFC 1766 had a similar, but different, sentence). This=20 isn't a substantive edit and doesn't address the real open issue in our=20 draft, which is how to handle extlangs. Regards, Addison Marion Gunn wrote: > For starters, suggest losing the entire first sentence of paragraph 1=20 > below, inserting the word "human" before "language" in its second=20 > sentence and inserting the following comma-plus-clause text ", such=20 > reasons as are set out below" before its closing full stop. > mg >=20 >=20 > On 24 Aug 2007, at 21:59, scr=C3=ADobh Addison Phillips: >=20 >=20 >> Phillips & Davis Expires February 25, 2008 [Page = 3] >> Internet-Draft langtags-registry August 20= 07 >> >> >> 1. Introduction >> >> Human beings on our planet have, past and present, used a number of >> languages. There are many reasons why one would want to identify t= he >> language used when presenting or requesting information. >> >> >=20 > --=20 > Marion Gunn > mgunn@ucd.ie >=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 Tue Aug 28 10:07: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 1IQ1jX-0000Xg-TQ; Tue, 28 Aug 2007 10:07:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ1jW-0000Xa-Bh for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 10:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1jW-0000XR-0Z for ltru@ietf.org; Tue, 28 Aug 2007 10:07:54 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ1jR-0002fz-4W for ltru@ietf.org; Tue, 28 Aug 2007 10:07:53 -0400 Received: by wa-out-1112.google.com with SMTP id k40so363189wah for ; Tue, 28 Aug 2007 07:07:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=d2kC0T7YOj5JRD2WcdweQj4KuPT+mATUJEUUQWfQ/uzM2Be39+WMSaGKZEl9dTpLS3GjIKRqNYuogVFjlOxbe3EAdinwl876TA0Xx3OSgrqVa6b5SKo38KPzs7dVFQis4zON4Ztq1CPMqioLH7kG7N0iqvoWSXE4S1rmlaq72Ec= 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=fGXXpYxCAOWFCs6TrQTCzuEeTaNoKqkiDv1S2z/dtSbC6ZEVNvoOZnfGJInkLPcMjFfVMGoEmzkrCQz0WquH8X5yMnMqvbiWMk6FCqVE5QKXUg6sk/oEhJEW0dkMozz9DEvz6/kXHg8qXkx27ymLalTRrb6yVRr9xPuPgQHCIQQ= Received: by 10.114.159.1 with SMTP id h1mr418448wae.1188310067958; Tue, 28 Aug 2007 07:07:47 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 07:07:47 -0700 (PDT) Message-ID: <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> Date: Tue, 28 Aug 2007 07:07:47 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 In-Reply-To: <46CF54C4.2090707@yahoo-inc.com> MIME-Version: 1.0 References: <46CF54C4.2090707@yahoo-inc.com> X-Google-Sender-Auth: fca3ba2a67b0da16 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a277fb76972082607405dff31ef2a60 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="===============0036778801==" Errors-To: ltru-bounces@ietf.org --===============0036778801== Content-Type: multipart/alternative; boundary="----=_Part_95185_17479944.1188310067868" ------=_Part_95185_17479944.1188310067868 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Just to open up the discussion, the biggest problem with this version is that it uses a substantial new mechanism (extlang) which was not used in RFC 4646, and for which there is no consensus in this group to use in RFC 4646bis. We haven't removed extlang from the draft yet, but the people that want this new mechanism need to provide justification, that: 1. it is substantially better to have languages like 'cmn' be put in a secondary position (eg zh-cmn-Hant-CN), rather than being primary subtags on their own (eg cmn-Hant-CN). 2. it is sufficiently better to warrant making the language tags more complicated by the addition of this mechanism. Mark On 8/24/07, Addison Phillips wrote: > > Dear Editors, > > Please find attached in the usual text format draft-08 of > draft-ietf-ltru-rfc4646bis. > > Best Regards, > > Addison (for the editors) > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > > > Network Working Group A. Phillips, Ed. > Internet-Draft Yahoo! Inc. > Obsoletes: 4646 (if approved) M. Davis, Ed. > Intended status: Best Current Google > Practice August 24, 2007 > Expires: February 25, 2008 > > > Tags for Identifying Languages > draft-ietf-ltru-4646bis-08 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on February 25, 2008. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > > > > > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 1] > > Internet-Draft langtags-registry August 2007 > > > Abstract > > This document describes the structure, content, construction, and > semantics of language tags for use in cases where it is desirable to > indicate the language used in an information object. It also > describes how to register values for use in language tags and the > creation of user-defined extensions for private interchange. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.2. Language Subtag Sources and Interpretation . . . . . . . . 8 > 2.2.1. Primary Language Subtag . . . . . . . . . . . . . . . 9 > 2.2.2. Extended Language Subtags . . . . . . . . . . . . . . 11 > 2.2.3. Script Subtag . . . . . . . . . . . . . . . . . . . . 12 > 2.2.4. Region Subtag . . . . . . . . . . . . . . . . . . . . 13 > 2.2.5. Variant Subtags . . . . . . . . . . . . . . . . . . . 15 > 2.2.6. Extension Subtags . . . . . . . . . . . . . . . . . . 16 > 2.2.7. Private Use Subtags . . . . . . . . . . . . . . . . . 17 > 2.2.8. Grandfathered Registrations . . . . . . . . . . . . . 18 > 2.2.9. Classes of Conformance . . . . . . . . . . . . . . . . 18 > 3. Registry Format and Maintenance . . . . . . . . . . . . . . . 20 > 3.1. Format of the IANA Language Subtag Registry . . . . . . . 20 > 3.1.1. File Format . . . . . . . . . . . . . . . . . . . . . 20 > 3.1.2. Record Definitions . . . . . . . . . . . . . . . . . . 21 > 3.1.3. Subtag and Tag Fields . . . . . . . . . . . . . . . . 24 > 3.1.4. Description Field . . . . . . . . . . . . . . . . . . 24 > 3.1.5. Deprecated Field . . . . . . . . . . . . . . . . . . . 25 > 3.1.6. Preferred-Value Field . . . . . . . . . . . . . . . . 25 > 3.1.7. Prefix Field . . . . . . . . . . . . . . . . . . . . . 26 > 3.1.8. Suppress-Script Field . . . . . . . . . . . . . . . . 27 > 3.1.9. Macrolanguage Field . . . . . . . . . . . . . . . . . 27 > 3.1.10. Comments Field . . . . . . . . . . . . . . . . . . . . 28 > 3.2. Language Subtag Reviewer . . . . . . . . . . . . . . . . . 28 > 3.3. Maintenance of the Registry . . . . . . . . . . . . . . . 29 > 3.4. Stability of IANA Registry Entries . . . . . . . . . . . . 29 > 3.5. Registration Procedure for Subtags . . . . . . . . . . . . 34 > 3.6. Possibilities for Registration . . . . . . . . . . . . . . 38 > 3.7. Extensions and Extensions Registry . . . . . . . . . . . . 40 > 3.8. Update of the Language Subtag Registry . . . . . . . . . . 43 > 4. Formation and Processing of Language Tags . . . . . . . . . . 44 > 4.1. Choice of Language Tag . . . . . . . . . . . . . . . . . . 44 > 4.2. Meaning of the Language Tag . . . . . . . . . . . . . . . 48 > 4.3. Length Considerations . . . . . . . . . . . . . . . . . . 50 > 4.3.1. Working with Limited Buffer Sizes . . . . . . . . . . 50 > > > > Phillips & Davis Expires February 25, 2008 [Page 2] > > Internet-Draft langtags-registry August 2007 > > > 4.3.2. Truncation of Language Tags . . . . . . . . . . . . . 52 > 4.4. Canonicalization of Language Tags . . . . . . . . . . . . 52 > 4.5. Considerations for Private Use Subtags . . . . . . . . . . 54 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 > 5.1. Language Subtag Registry . . . . . . . . . . . . . . . . . 56 > 5.2. Extensions Registry . . . . . . . . . . . . . . . . . . . 57 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 58 > 7. Character Set Considerations . . . . . . . . . . . . . . . . . 59 > 8. Changes from RFC 4646 . . . . . . . . . . . . . . . . . . . . 60 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 67 > Appendix B. Examples of Language Tags (Informative) . . . . . . . 68 > Appendix C. Examples of Registration Forms . . . . . . . . . . . 71 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 > Intellectual Property and Copyright Statements . . . . . . . . . . 74 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 3] > > Internet-Draft langtags-registry August 2007 > > > 1. Introduction > > Human beings on our planet have, past and present, used a number of > languages. There are many reasons why one would want to identify the > language used when presenting or requesting information. > > A user's language preferences often need to be identified so that > appropriate processing can be applied. For example, the user's > language preferences in a Web browser can be used to select Web pages > appropriately. Language preferences can also be used to select among > tools (such as dictionaries) to assist in the processing or > understanding of content in different languages. > > In addition, knowledge about the particular language used by some > piece of information content might be useful or even required by some > types of processing; for example, spell-checking, computer- > synthesized speech, Braille transcription, or high-quality print > renderings. > > One means of indicating the language used is by labeling the > information content with an identifier or "tag". These tags can be > used to specify user preferences when selecting information content, > or for labeling additional attributes of content and associated > resources. > > Tags can also be used to indicate additional language attributes of > content. For example, indicating specific information about the > dialect, writing system, or orthography used in a document or > resource may enable the user to obtain information in a form that > they can understand, or it can be important in processing or > rendering the given content into an appropriate form or style. > > This document specifies a particular identifier mechanism (the > language tag) and a registration function for values to be used to > form tags. It also defines a mechanism for private use values and > future extension. > > This document replaces [RFC4646], which replaced [RFC3066] and its > predecessor [RFC1766]. For a list of changes in this document, see > Section 8. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 4] > > Internet-Draft langtags-registry August 2007 > > > 2. The Language Tag > > Language tags are used to help identify languages, whether spoken, > written, signed, or otherwise signaled, for the purpose of > communication. This includes constructed and artificial languages, > but excludes languages not intended primarily for human > communication, such as programming languages. > > 2.1. Syntax > > The language tag is composed of one or more parts, known as > "subtags". Each subtag consists of a sequence of alphanumeric > characters. Subtags are distinguished and separated from one another > by a hyphen ("-", ABNF [RFC4234] %x2D). A language tag consists of a > "primary language" subtag and a (possibly empty) series of subsequent > subtags, each of which refines or narrows the range of languages > identified by the overall tag. > > Usually, each type of subtag is distinguished by length, position in > the tag, and content: subtags can be recognized solely by these > features. The only exception to this is a fixed list of > grandfathered tags registered under RFC 3066 [RFC3066]. This makes > it possible to construct a parser that can extract and assign some > semantic information to the subtags, even if the specific subtag > values are not recognized. Thus, a parser need not have an up-to- > date copy (or any copy at all) of the subtag registry to perform most > searching and matching operations. > > > > > > > > > > > > > > > > > > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 5] > > Internet-Draft langtags-registry August 2007 > > > The syntax of the language tag in ABNF [RFC4234] is: > > Language-Tag = langtag > / privateuse ; private use tag > / irregular ; tags grandfathered by rule > > langtag = (language > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) > > language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag > > extlang = *3("-" 3ALPHA) ; specific ISO 639-3 codes > > script = 4ALPHA ; ISO 15924 code > > region = 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code > > variant = 5*8alphanum ; registered variants > / (DIGIT 3alphanum) > > extension = singleton 1*("-" (2*8alphanum)) > > singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single alphanumerics > ; "x" is reserved for private use > > privateuse = "x" 1*("-" (1*8alphanum)) > > irregular = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default" > / "i-enochian" / "i-hak" / "i-klingon" / "i-lux" > / "i-mingo" / "i-navajo" / "i-pwn" / "i-tao" > / "i-tay" / "i-tsu" / "sgn-BE-fr" / "sgn-BE-nl" > / "sgn-CH-de" > > alphanum = (ALPHA / DIGIT) ; letters and numbers > > Figure 1: Language Tag ABNF > > All subtags have a maximum length of eight characters and whitespace > is not permitted in a language tag. There is a subtlety in the ABNF > > > > Phillips & Davis Expires February 25, 2008 [Page 6] > > Internet-Draft langtags-registry August 2007 > > > production 'variant': variants starting with a digit MAY be four > characters long, while those starting with a letter MUST be at least > five characters long. For examples of language tags, see Appendix B. > > Note Well: the ABNF syntax does not distinguish between upper and > lowercase. The appearance of upper and lowercase letters in the > varous ABNF productions above do not affect how implementations > interpret tags. That is, the tag "I-AMI" matches the item "i-ami" in > the 'irregular' production. At all times, the tags and their > subtags, including private use and extensions, are to be treated as > case insensitive: there exist conventions for the capitalization of > some of the subtags, but these MUST NOT be taken to carry meaning. > > For example: > > o [ISO639-1] recommends that language codes be written in lowercase > ('mn' Mongolian). > > o [ISO3166-1] recommends that country codes be capitalized ('MN' > Mongolia). > > o [ISO15924] recommends that script codes use lowercase with the > initial letter capitalized ('Cyrl' Cyrillic). > > However, in the tags defined by this document, the uppercase US-ASCII > letters in the range 'A' through 'Z' are considered equivalent and > mapped directly to their US-ASCII lowercase equivalents in the range > 'a' through 'z'. Thus, the tag "mn-Cyrl-MN" is not distinct from > "MN-cYRL-mn" or "mN-cYrL-Mn" (or any other combination), and each of > these variations conveys the same meaning: Mongolian written in the > Cyrillic script as used in Mongolia. > > Although case distinctions do not carry meaning in language tags, > consistent formatting and presentation of the tags will aid users. > The format of the tags and subtags in the registry is RECOMMENDED. > In this format, all non-initial two-letter subtags are uppercase, all > non-initial four-letter subtags are titlecase, and all other subtags > are lowercase. > > Note that although [RFC4234] refers to octets, the language tags > described in this document are sequences of characters from the US- > ASCII [ISO646] repertoire. Language tags MAY be used in documents > and applications that use other encodings, so long as these encompass > the US-ASCII repertoire. An example of this would be an XML document > that uses the UTF-16LE [RFC2781] encoding of [Unicode]. > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 7] > > Internet-Draft langtags-registry August 2007 > > > 2.2. Language Subtag Sources and Interpretation > > The namespace of language tags and their subtags is administered by > the Internet Assigned Numbers Authority (IANA) [RFC2860] according to > the rules in Section 5 of this document. 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. > > Terminology used in this document: > > o Tag or tags refers to a complete language tag, such as > "sr-Latn-RS" or "az-Arab-IR". Examples of tags in this document > are enclosed in double-quotes ("en-US"). > > o Subtag refers to a specific section of a tag, delimited by hyphen, > such as the subtag 'Hant' in "zh-Hant-CN". Examples of subtags in > this document are enclosed in single quotes ('Hant'). > > o Code or codes refers to values defined in external standards (and > which are used as subtags in this document). For example, 'Hant' > is an [ISO15924] script code that was used to define the 'Hant' > script subtag for use in a language tag. Examples of codes in > this document are enclosed in single quotes ('en', 'Hant'). > > The definitions in this section apply to the various subtags within > the language tags defined by this document, excepting those > "grandfathered" tags defined in Section 2.2.8. > > Language tags are designed so that each subtag type has unique length > and content restrictions. These make identification of the subtag's > type possible, even if the content of the subtag itself is > unrecognized. This allows tags to be parsed and processed without > reference to the latest version of the underlying standards or the > IANA registry and makes the associated exception handling when > parsing tags simpler. > > Subtags in the IANA registry that do not come from an underlying > standard can only appear in specific positions in a tag. > Specifically, they can only occur as primary language subtags or as > variant subtags. > > Note that sequences of private use and extension subtags MUST occur > at the end of the sequence of subtags and MUST NOT be interspersed > with subtags defined elsewhere in this document. > > Single-letter and single-digit subtags are reserved for current or > future use. These include the following current uses: > > > > Phillips & Davis Expires February 25, 2008 [Page 8] > > Internet-Draft langtags-registry August 2007 > > > o The single-letter subtag 'x' is reserved to introduce a sequence > of private use subtags. The interpretation of any private use > subtags is defined solely by private agreement and is not defined > by the rules in this section or in any standard or registry > defined in this document. > > o All other single-letter subtags are reserved to introduce > standardized extension subtag sequences as described in > Section 3.7. > > The single-letter subtag 'i' is used by some grandfathered tags, such > as "i-default", where it always appears in the first position and > cannot be confused with an extension. > > 2.2.1. Primary Language Subtag > > The primary language subtag is the first subtag in a language tag > (with the exception of private use and certain grandfathered tags) > and cannot be omitted. The following rules apply to the primary > language subtag: > > 1. All two-character primary language subtags were defined in the > IANA registry according to the assignments found in the standard > ISO 639 Part 1, "ISO 639-1:2002, Codes for the representation of > names of languages -- Part 1: Alpha-2 code" [ISO639-1], or using > assignments subsequently made by the ISO 639-1 registration > authority (RA) or governing standardization bodies. > > 2. All three-character primary language subtags were defined in the > IANA registry according to the assignments found in either ISO > 639 Part 2, "ISO 639-2:1998 - Codes for the representation of > names of languages -- Part 2: Alpha-3 code - edition 1" > [ISO639-2], ISO 639 Part 3, "Codes for the representation of > names of languages -- Part 3: Alpha-3 code for comprehensive > coverage of languages" [ISO639-3], or assignments subsequently > made by the relevant ISO 639 registration authorities or > governing standardization bodies. > > 3. The subtags in the range 'qaa' through 'qtz' are reserved for > private use in language tags. These subtags correspond to codes > reserved by ISO 639-2 for private use. These codes MAY be used > for non-registered primary language subtags (instead of using > private use subtags following 'x-'). Please refer to Section 4.5 > for more information on private use subtags. > > 4. All four-character language subtags are reserved for possible > future standardization. > > > > > Phillips & Davis Expires February 25, 2008 [Page 9] > > Internet-Draft langtags-registry August 2007 > > > 5. All language subtags of 5 to 8 characters in length in the IANA > registry were defined via the registration process in Section 3.5 > and MAY be used to form the primary language subtag. At the time > this document was created, there were no examples of this kind of > subtag and future registrations of this type will be discouraged: > primary languages are strongly RECOMMENDED for registration with > ISO 639, and proposals rejected by ISO 639/RA-JAC will be closely > scrutinized before they are registered with IANA. > > 6. The single-character subtag 'x' as the primary subtag indicates > that the language tag consists solely of subtags whose meaning is > defined by private agreement. For example, in the tag "x-fr-CH", > the subtags 'fr' and 'CH' SHOULD NOT be taken to represent the > French language or the country of Switzerland (or any other value > in the IANA registry) unless there is a private agreement in > place to do so. See Section 4.5. > > 7. The single-character subtag 'i' is used by some grandfathered > tags (see Section 2.2.8) such as "i-klingon" and "i-bnn". (Other > grandfathered tags have a primary language subtag in their first > position.) > > 8. Other values MUST NOT be assigned to the primary subtag except by > revision or update of this document. > > Note: For languages that have both an ISO 639-1 two-character code > and a three character code assigned by either ISO 639-2 or ISO 639-3, > only the ISO 639-1 two-character code is defined in the IANA > registry. > > Note: For languages that have no ISO 639-1 two-character code and for > which the ISO 639-2/T (Terminology) code and the ISO 639-2/B > (Bibliographic) codes differ, only the Terminology code is defined in > the IANA registry. At the time this document was created, all > languages that had both kinds of three-character code were also > assigned a two-character code; it is expected that future assignments > of this nature will not occur. > > Note: To avoid problems with versioning and subtag choice as > experienced during the transition between RFC 1766 and RFC 3066, as > well as the canonical nature of subtags defined by this document, the > ISO 639 Registration Authority Joint Advisory Committee (ISO 639/ > RA-JAC) has included the following statement in [iso639.prin]: > > "A language code already in ISO 639-2 at the point of freezing ISO > 639-1 shall not later be added to ISO 639-1. This is to ensure > consistency in usage over time, since users are directed in > Internet applications to employ the alpha-3 code when an alpha-2 > > > > Phillips & Davis Expires February 25, 2008 [Page 10] > > Internet-Draft langtags-registry August 2007 > > > code for that language is not available." > > In order to avoid instability in the canonical form of tags, if a > two-character code is added to ISO 639-1 for a language for which a > three-character code was already included in either ISO 639-2 or ISO > 639-3, the two-character code MUST NOT be registered. See > Section 3.4. > > For example, if some content were tagged with 'haw' (Hawaiian), which > currently has no two-character code, the tag would not be invalidated > if ISO 639-1 were to assign a two-character code to the Hawaiian > language at a later date. > > Note: An example of independent primary language subtag registration > might include: one of the grandfathered IANA registrations is > "i-enochian". The subtag 'enochian' could be registered in the IANA > registry as a primary language subtag (assuming that ISO 639 does not > register this language first), making tags such as "enochian-AQ" and > "enochian-Latn" valid. > > 2.2.2. Extended Language Subtags > > Extended language subtags are used to identify languages that are > encompassed by a "macrolanguage". ISO 639-3 defines certain > languages to be "macrolanguages"; that is, they are groups of very > closely related languages which are treated as a single language in > certain contexts. In order to improve matching behavior and tagging > consistency, each language encompassed by a ISO 639-3 macrolanguage > is represented in the IANA registry using an extended language > subtag, provided that it is not already represented using a language > subtag. The following rules apply to the extended language subtags: > > 1. These subtags were defined in the IANA registry according to > assignments found in ISO 639 Part 3. > > 2. A sequence of up to three extended language subtags MAY appear in > a language tag. This sequence MUST follow the primary language > subtag and precede any other subtags. > > 3. Each extended language subtag MUST only appear in a tag > immediately following the exact sequence of subtags that appears > in the 'Prefix' field in its registry record. > > 4. Other values MUST NOT be assigned to the extended language subtag > except by revision or update of this document. > > Extended language subtag records MUST include exactly one 'Prefix' > field indicating an appropriate subtag or sequence of subtags for > > > > Phillips & Davis Expires February 25, 2008 [Page 11] > > Internet-Draft langtags-registry August 2007 > > > that extended language subtag. > > For example, the 'gan' and 'cmn' subtags represent the languages Gan > Chinese and Mandarin Chinese. Each is encompassed by the > macrolanguage 'zh' (Chinese). Therefore, they both have the prefix > "zh" in their registry records. Consequently, Gan Chinese is > represented as "zh-gan" and Mandarin Chinese as "zh-cmn". The > language subtag 'zh' can still be used without an extended language > subtag to label a resource as some unspecified variety of Chinese > (which in practice will usually be Mandarin, the dominant variety of > Chinese, but might also be some other variety). > > Now suppose that, in the future, the ISO 639-3 Registration Authority > were to decide that Gan Chinese is actually two different closely > related languages: it might reclassify 'gan' as a macrolanguage and > introduce two new code elements. In that case, these code elements > would be added to the IANA registry as extended language subtags with > prefixes of "zh-gan". No change would be made to the registry record > for 'gan'. > > 2.2.3. Script Subtag > > Script subtags are used to indicate the script or writing system > variations that distinguish the written forms of a language or its > dialects. The following rules apply to the script subtags: > > 1. All four-character subtags were defined according to > [ISO15924]--"Codes for the representation of the names of > scripts": alpha-4 script codes, or subsequently assigned by the > ISO 15924 maintenance agency or governing standardization bodies, > denoting the script or writing system used in conjunction with > this language. > > 2. Script subtags MUST immediately follow the primary language > subtag and all extended language subtags and MUST occur before > any other type of subtag described below. > > 3. The script subtags 'Qaaa' through 'Qabx' are reserved for private > use in language tags. These subtags correspond to codes reserved > by ISO 15924 for private use. These codes MAY be used for non- > registered script values. Please refer to Section 4.5 for more > information on private use subtags. > > 4. Script subtags MUST NOT be registered using the process in > Section 3.5 of this document. Variant subtags MAY be considered > for registration for that purpose. > > > > > > Phillips & Davis Expires February 25, 2008 [Page 12] > > Internet-Draft langtags-registry August 2007 > > > 5. There MUST be at most one script subtag in a language tag, and > the script subtag SHOULD be omitted when it adds no > distinguishing value to the tag or when the primary language > subtag's record includes a Suppress-Script field listing the > applicable script subtag. > > Example: "sr-Latn" represents Serbian written using the Latin script. > > 2.2.4. Region Subtag > > Region subtags are used to indicate linguistic variations associated > with or appropriate to a specific country, territory, or region. > Typically, a region subtag is used to indicate regional dialects or > usage, or region-specific spelling conventions. A region subtag can > also be used to indicate that content is expressed in a way that is > appropriate for use throughout a region, for instance, Spanish > content tailored to be useful throughout Latin America. > > The following rules apply to the region subtags: > > 1. Region subtags MUST follow any language, extended language, or > script subtags and MUST precede all other 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. > > 3. All three-character subtags consisting of digit (numeric) > characters following the primary subtag were defined in the IANA > registry according to the assignments found in UN Standard > Country or Area Codes for Statistical Use [UN_M.49] or > assignments subsequently made by the governing standards body. > Note that not all of the UN M.49 codes are defined in the IANA > registry. The following rules define which codes are entered > into the registry as valid subtags: > > A. UN numeric codes assigned to 'macro-geographical > (continental)' or sub-regions MUST be registered in the > registry. These codes are not associated with an assigned > ISO 3166 alpha-2 code and represent supra-national areas, > usually covering more than one nation, state, province, or > territory. > > > > > > Phillips & Davis Expires February 25, 2008 [Page 13] > > Internet-Draft langtags-registry August 2007 > > > B. UN numeric codes for 'economic groupings' or 'other > groupings' MUST NOT be registered in the IANA registry and > MUST NOT be used to form language tags. > > C. UN numeric codes for countries or areas with ambiguous ISO > 3166 alpha-2 codes, when entered into the registry, MUST be > defined according to the rules in Section 3.4 and MUST be > used to form language tags that represent the country or > region for which they are defined. > > D. UN numeric codes for countries or areas for which there is an > associated ISO 3166 alpha-2 code in the registry MUST NOT be > entered into the registry and MUST NOT be used to form > language tags. Note that the ISO 3166-based subtag in the > registry MUST actually be associated with the UN M.49 code in > question. > > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or > areas listed as eligible for registration in [RFC4645] but > not presently registered MAY be entered into the IANA > registry via the process described in Section 3.5. Once > registered, these codes MAY be used to form language tags. > > F. All other UN numeric codes for countries or areas that do not > have an associated ISO 3166 alpha-2 code MUST NOT be entered > into the registry and MUST NOT be used to form language tags. > For more information about these codes, see Section 3.4. > > 4. Note: The alphanumeric codes in Appendix X of the UN document > MUST NOT be entered into the registry and MUST NOT be used to > form language tags. (At the time this document was created, > these values matched the ISO 3166 alpha-2 codes.) > > 5. There MUST be at most one region subtag in a language tag and the > region subtag MAY be omitted, as when it adds no distinguishing > value to the tag. > > 6. The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are > reserved for private use in language tags. These subtags > correspond to codes reserved by ISO 3166 for private use. These > codes MAY be used for private use region subtags (instead of > using a private use subtag sequence). Please refer to > Section 4.5 for more information on private use subtags. > > "de-CH" represents German ('de') as used in Switzerland ('CH'). > > "sr-Latn-RS" represents Serbian ('sr') written using Latin script > ('Latn') as used in Serbia ('RS'). > > > > Phillips & Davis Expires February 25, 2008 [Page 14] > > Internet-Draft langtags-registry August 2007 > > > "es-419" represents Spanish ('es') appropriate to the UN-defined > Latin America and Caribbean region ('419'). > > 2.2.5. Variant Subtags > > Variant subtags are used to indicate additional, well-recognized > variations that define a language or its dialects that are not > covered by other available subtags. The following rules apply to the > variant subtags: > > 1. Variant subtags are not associated with any external standard. > Variant subtags and their meanings are defined by the > registration process defined in Section 3.5. > > 2. Variant subtags MUST follow all of the other defined subtags, but > precede any extension or private use subtag sequences. > > 3. More than one variant MAY be used to form the language tag. > > 4. Variant subtags MUST be registered with IANA according to the > rules in Section 3.5 of this document before being used to form > language tags. In order to distinguish variants from other types > of subtags, registrations MUST meet the following length and > content restrictions: > > 1. Variant subtags that begin with a letter (a-z, A-Z) MUST be > at least five characters long. > > 2. Variant subtags that begin with a digit (0-9) MUST be at > least four characters long. > > Variant subtag records in the language subtag registry MAY include > one or more 'Prefix' fields. The 'Prefix' indicates the language tag > or tags that would make a suitable prefix (with other subtags, as > appropriate) in forming a language tag with the variant. That is, > each of the subtags in the prefix SHOULD appear before the variant. > For example, the subtag 'nedis' has a Prefix of "sl", making it > suitable to form language tags such as "sl-nedis" and "sl-IT-nedis", > but not suitable for use in a tag such as "zh-nedis" or "it-IT- > nedis". > > "sl-nedis" represents the Natisone or Nadiza dialect of Slovenian. > > "de-CH-1996" represents German as used in Switzerland and as written > using the spelling reform beginning in the year 1996 C.E. > > Most variants that share a prefix are mutually exclusive. For > example, the German orthographic variations '1996' and '1901' SHOULD > > > > Phillips & Davis Expires February 25, 2008 [Page 15] > > Internet-Draft langtags-registry August 2007 > > > NOT be used in the same tag, as they represent the dates of different > spelling reforms. A variant that can meaningfully be used in > combination with another variant SHOULD include a 'Prefix' field in > its registry record that lists that other variant. For example, if > another German variant 'example' were created that made sense to use > with '1996', then 'example' should include two Prefix fields: "de" > and "de-1996". > > 2.2.6. Extension Subtags > > Extensions provide a mechanism for extending language tags for use in > various applications. See Section 3.7. The following rules apply to > extensions: > > 1. Extension subtags are separated from the other subtags defined > in this document by a single-character subtag ("singleton"). > The singleton MUST be one allocated to a registration authority > via the mechanism described in Section 3.7 and MUST NOT be the > letter 'x', which is reserved for private use subtag sequences. > > 2. Note: Private use subtag sequences starting with the singleton > subtag 'x' are described in Section 2.2.7 below. > > 3. An extension MUST follow at least a primary language subtag. > That is, a language tag cannot begin with an extension. > Extensions extend language tags, they do not override or replace > them. For example, "a-value" is not a well-formed language tag, > while "de-a-value" is. > > 4. Each singleton subtag MUST appear at most one time in each tag > (other than as a private use subtag). That is, singleton > subtags MUST NOT be repeated. For example, the tag "en-a-bbb-a- > ccc" is invalid because the subtag 'a' appears twice. Note that > the tag "en-a-bbb-x-a-ccc" is valid because the second > appearance of the singleton 'a' is in a private use sequence. > > 5. Extension subtags MUST meet all of the requirements for the > content and format of subtags defined in this document. > > 6. Extension subtags MUST meet whatever requirements are set by the > document that defines their singleton prefix and whatever > requirements are provided by the maintaining authority. > > 7. Each extension subtag MUST be from two to eight characters long > and consist solely of letters or digits, with each subtag > separated by a single '-'. > > > > > > Phillips & Davis Expires February 25, 2008 [Page 16] > > Internet-Draft langtags-registry August 2007 > > > 8. Each singleton MUST be followed by at least one extension > subtag. For example, the tag "tlh-a-b-foo" is invalid because > the first singleton 'a' is followed immediately by another > singleton 'b'. > > 9. Extension subtags MUST follow all language, extended language, > script, region, and variant subtags in a tag. > > 10. All subtags following the singleton and before another singleton > are part of the extension. Example: In the tag "fr-a-Latn", the > subtag 'Latn' does not represent the script subtag 'Latn' > defined in the IANA Language Subtag Registry. Its meaning is > defined by the extension 'a'. > > 11. In the event that more than one extension appears in a single > tag, the tag SHOULD be canonicalized as described in > Section 4.4. > > For example, if the prefix singleton 'r' and the shown subtags were > defined, then the following tag would be a valid example: "en-Latn- > GB-boont-r-extended-sequence-x-private" > > 2.2.7. Private Use Subtags > > Private use subtags are used to indicate distinctions in language > important in a given context by private agreement. The following > rules apply to private use subtags: > > 1. Private use subtags are separated from the other subtags defined > in this document by the reserved single-character subtag 'x'. > > 2. Private use subtags MUST conform to the format and content > constraints defined in the ABNF for all subtags. > > 3. Private use subtags MUST follow all language, extended language, > script, region, variant, and extension subtags in the tag. > Another way of saying this is that all subtags following the > singleton 'x' MUST be considered private use. Example: The > subtag 'US' in the tag "en-x-US" is a private use subtag. > > 4. A tag MAY consist entirely of private use subtags. > > 5. No source is defined for private use subtags. Use of private use > subtags is by private agreement only. > > 6. Private use subtags are NOT RECOMMENDED where alternatives exist > or for general interchange. See Section 4.5 for more information > on private use subtag choice. > > > > Phillips & Davis Expires February 25, 2008 [Page 17] > > Internet-Draft langtags-registry August 2007 > > > For example: Users who wished to utilize codes from the Ethnologue > publication of SIL International for language identification might > agree to exchange tags such as "az-Arab-x-AZE-derbend". This example > contains two private use subtags. The first is 'AZE' and the second > is 'derbend'. > > 2.2.8. Grandfathered Registrations > > Prior to RFC 4646, whole language tags were registered according to > the rules in RFC 1766 and/or RFC 3066. These registered tags > maintain their validity. Of those tags, those that were made > obsolete or redundant by the advent of RFC 4646, by this document, or > by subsequent registration of subtags are maintained in the registry > in records as "redundant" records. Those tags that do not match the > 'langtag' production in the ABNF in this document or that contain > subtags that do not individually appear in the registry are > maintained in the registry in records of the "grandfathered" type. > > Grandfathered tags contain one or more subtags that are not defined > in the Language Subtag Registry (see Section 3). Redundant tags > consist entirely of subtags defined above and whose independent > registration was superseded by [RFC4646]. For more information see > Section 3.8. > > Some grandfathered tags are "regular" in that they match the > 'langtag' production in Figure 1. In some cases, these tags could > become redundant if their (current unregistered) subtags were to be > registered (as variants, for example). In other cases, although the > subtags match the language tag pattern, the meaning assigned to the > various subtags is prohibited by rules elsewhere in this document. > Those tags can never become redundant. > > The remaining grandfathered tags are "irregular" and do not match the > 'langtag' production. These are listed in the 'irregular' production > in Figure 1. These grandfathered tags can never become redundant. > Many of these tags have been superseded by other registrations: their > record contains a Preferred-Value field that really ought to be used > to form language tags representing that value. > > 2.2.9. Classes of Conformance > > Implementations sometimes need to describe their capabilities with > regard to the rules and practices described in this document. Tags > can be checked or verified in a number of ways, but two particular > classes of tag conformance are formally defined here. > > A tag is considered "well-formed" if it conforms to the ABNF > (Section 2.1). Note that irregular grandfathered tags are now listed > > > > Phillips & Davis Expires February 25, 2008 [Page 18] > > Internet-Draft langtags-registry August 2007 > > > in the 'irregular' production. > > A tag is considered "valid" if it well-formed and it also satisfies > these conditions: > > o The tag is either a grandfathered tag, or all of its language, > extended language, script, region, and variant subtags appear in > the IANA language subtag registry as of the particular registry > date. > > o There are no duplicate singleton (extension) subtags and no > duplicate variant subtags. > > o For each subtag that has a 'Prefix' field in the registry, the > Prefix matches the language tag using Extended Filtering > [RFC4647]. That is, each subtag in the Prefix is present in the > tag and in the same order. Furthermore, all of the Prefix's > subtags MUST appear before the subtag. For example, the Prefix > "zh-TW" matches the tag "zh-Hant-TW". > > Note that a tag's validity depends on the date of the registry used > to validate the tag. A more-recent copy of the registry might > contain a subtag that an older version does not. > > A tag is considered "valid" for a given extension (Section 3.7) (as > of a particular version, revision, and date) if it meets the criteria > for "valid" above and also satisfies this condition: > > Each subtag used in the extension part of the tag is valid > according to the extension. > > > > > > > > > > > > > > > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 19] > > Internet-Draft langtags-registry August 2007 > > > 3. Registry Format and Maintenance > > This section defines the Language Subtag Registry and the maintenance > and update procedures associated with it, as well as a registry for > extensions to language tags (Section 3.7). > > The Language Subtag Registry contains a comprehensive list of all of > the subtags valid in language tags. This allows implementers a > straightforward and reliable way to validate language tags. The > Language Subtag Registry will be maintained so that, except for > extension subtags, it is possible to validate all of the subtags that > appear in a language tag under the provisions of this document or its > revisions or successors. In addition, the meaning of the various > subtags will be unambiguous and stable over time. (The meaning of > private use subtags, of course, is not defined by the IANA registry.) > > 3.1. Format of the IANA Language Subtag Registry > > The IANA Language Subtag Registry ("the registry") is a machine- > readable file in the format described in this section, plus copies of > the registration forms approved in accordance with the process > described in Section 3.5. The existing registration forms for > grandfathered and redundant tags taken from RFC 3066 will be > maintained as part of the obsolete RFC 3066 registry. The remaining > set of subtags created by either [RFC4645] or [registry-update] will > not have registration forms created for them. > > 3.1.1. File Format > > The registry consists of a series of records stored in the record-jar > format (described in [record-jar]). Each record, in turn, consists > of a series of fields that describe the various subtags and tags. > The registry is a Unicode [Unicode] text file, using the UTF-8 > [RFC3629] character encoding. > > Each field can be considered a single, logical line of Unicode > [Unicode] characters, comprising a field-name and a field-body > separated by a COLON character (%x3A). Each field is terminated by > the newline sequence CRLF. The text in each field MUST be in Unicode > Normalization Form C (NFC). > > A collection of fields forms a 'record'. Records are separated by > lines containing only the sequence "%%" (%x25.25). > > Although fields are logically a single line of text, each line of > text in the file format is limited to 72 bytes in length. To > accommodate this, the field-body can be split into a multiple-line > representation; this is called "folding". Folding is always done on > > > > Phillips & Davis Expires February 25, 2008 [Page 20] > > Internet-Draft langtags-registry August 2007 > > > Unicode code point boundaries (never in the middle of a multibyte > UTF-8 sequence) and MUST NOT occur just prior to a combining mark. > > Although the file format uses the UTF-8 encoding, unless otherwise > indicated, fields are restricted to the printable characters from the > US-ASCII [ISO646] repertoire. > > The format of the registry is described by the following ABNF (per > [RFC4234]): > > registry = record *("%%" CRLF record) > record = 1*( field-name *SP ":" *SP field-body CRLF ) > field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > field-body = *([[*SP CRLF] 1*SP] 1*CHARS) > CHARS = (%x21-10FFFF) ; Unicode code points > > Figure 2: Registry Format ABNF > > The sequence '..' (%x2E.2E) in a field-body denotes a range of > values. Such a range represents all subtags of the same length that > are in alphabetic or numeric order within that range, including the > values explicitly mentioned. For example 'a..c' denotes the values > 'a', 'b', and 'c' and '11..13' denotes the values '11', '12', and > '13'. > > All fields whose field-body contains a date value use the "full-date" > format specified in [RFC3339]. For example: "2004-06-28" represents > June 28, 2004, in the Gregorian calendar. > > 3.1.2. Record Definitions > > There are three types of records in the registry: "File-Date", > "Subtag", and "Tag" records. > > The first record in the registry is a "File-Date" record. This > record contains the single field whose field-name is "File-Date" (see > Figure 2). The field-body of this record contains the last > modification date of this copy of the registry, making it possible to > compare different versions of the registry. The registry on the IANA > website is the most current. Versions with an older date than that > one are not up-to-date. > > File-Date: 2004-06-28 > %% > > Figure 3: Example of the File-Date Record > > Subsequent records represent either subtags or tags in the registry. > > > > Phillips & Davis Expires February 25, 2008 [Page 21] > > Internet-Draft langtags-registry August 2007 > > > "Subtag" records contain a field with a field-name of "Subtag", > while, unsurprisingly, "Tag" records contain a field with a field- > name of "Tag". Each of the fields in each record MUST occur no more > than once, unless otherwise noted below. Each record MUST contain > the following fields: > > o 'Type' > > * Type's field-body MUST consist of one of the following strings: > "language", "extlang", "script", "region", "variant", > "grandfathered", and "redundant" and denotes the type of tag or > subtag. > > o Either 'Subtag' or 'Tag' > > * Subtag's field-body contains the subtag being defined. This > field MUST only appear in records of whose 'Type' has one of > these values: "language", "extlang", "script", "region", or > "variant". > > * Tag's field-body contains a complete language tag. This field > MUST only appear in records whose 'Type' has one of these > values: "grandfathered" or "redundant". Note that the field- > body will always follow the 'grandfathered' production in the > ABNF in Section 2.1 > > o Description > > * Description's field-body contains a non-normative description > of the subtag or tag. > > o Added > > * Added's field-body contains the date the record was added to > the registry. > > Each record MAY also contain the following fields: > > o Preferred-Value > > * For fields of type 'script', 'region', and 'variant', > 'Preferred-Value' contains the subtag of the same 'Type' that > is preferred for forming the language tag. > > * For fields of type 'language' and 'extlang', 'Preferred-Value' > contains the language production (see Figure 1) that is > preferred when forming the language tag. This can be simply a > 'language' subtag, or it can be a 'language' subtag followed by > > > > Phillips & Davis Expires February 25, 2008 [Page 22] > > Internet-Draft langtags-registry August 2007 > > > an extended language sequence. > > * For fields of type 'grandfathered' and 'redundant', a canonical > mapping to a complete language tag. > > o Deprecated > > * Deprecated's field-body contains the date the record was > deprecated. > > o Prefix > > * Prefix's field-body contains a language tag with which this > subtag MAY be used to form a new language tag, perhaps with > other subtags as well. The Prefix's subtags appear before the > subtag. This field MUST only appear in records whose 'Type' > field-body is 'variant' or 'extlang'. For example, the > 'Prefix' for the variant 'nedis' is 'sl', meaning that the tags > "sl-nedis" and "sl-IT-nedis" might be appropriate while the tag > "is-nedis" is not. > > o Comments > > * Comments contains additional information about the subtag, as > deemed appropriate for understanding the registry and > implementing language tags using the subtag or tag. > > o Suppress-Script > > * Suppress-Script contains a script subtag that SHOULD NOT be > used to form language tags with the associated primary language > subtag. This field MUST only appear in records whose 'Type' > field-body is 'language'. See Section 4.1. > > o Macrolanguage > > * Macrolanguage contains a primary or extended language subtag > defined by ISO 639 as a "macrolanguage" that encompasses this > language subtag. This field MUST only appear in records whose > 'Type' field-body is 'language' or 'extlang'. > > Future versions of this document might add additional fields to the > registry, so implementations SHOULD ignore fields found in the > registry that are not defined in this document. > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 23] > > Internet-Draft langtags-registry August 2007 > > > 3.1.3. Subtag and Tag Fields > > The 'Subtag' field MUST use lowercase letters to form the subtag, > with two exceptions. Subtags whose 'Type' field is 'script' (in > other words, subtags defined by ISO 15924) MUST use titlecase. > Subtags whose 'Type' field is 'region' (in other words, the non- > numeric region subtags defined by ISO 3166) MUST use uppercase. > These exceptions mirror the use of case in the underlying standards. > > Each subtag in the tags contained in a 'Tag' field MUST be formatted > using the rules in the preceeding paragraph. That is, all subtags > are lowercase except for subtags that represent script or region > codes. > > 3.1.4. Description Field > > The field 'Description' contains a description of the tag or subtag > in the record. The 'Description' field MAY appear more than once per > record, that is, there can be multiple descriptions for a given > record. The 'Description' field MAY include the full range of > Unicode characters. At least one of the 'Description' fields MUST be > written or transcribed into the Latin script; additional > 'Description' fields MAY also include a description in a non-Latin > script. Each 'Description' field MUST be unique, both within the > record in which it appears and for the collection of records of the > same type. Moreover, formatting variations of the same description > MUST NOT occur in that specific record or in any other record of the > same type. For example, while the ISO 639-1 code 'fy' contains both > the descriptions "Western Frisian" and "Frisian, Western", only one > of these descriptions appears in the registry. > > The 'Description' field is used for identification purposes and > SHOULD NOT be taken to represent the actual native name of the > language or variation or to be in any particular language. > > For records taken from a source standard (such as ISO 639 or ISO > 3166), the 'Description' value(s) SHOULD also be taken from the > source standard. Multiple descriptions in the source standard MUST > be split into separate 'Description' fields. The source standard's > descriptions MAY be edited, either prior to insertion or via the > registration process. For fields of type 'language' or 'extlang', > the first 'Description' field appearing in the Registry corresponds > to the Reference Name assigned by ISO 639-3. This helps facilitate > cross-referencing between ISO 639 and the registry. > > When creating or updating a record due to the action of one of the > source standards, the Language Subtag Reviewer SHOULD remove > duplicate or redundant descriptions and MAY edit descriptions to > > > > Phillips & Davis Expires February 25, 2008 [Page 24] > > Internet-Draft langtags-registry August 2007 > > > correct irregularities in formatting (such as misspellings, > inappropriate apostrophes or other punctuation, or excessive or > missing spaces) prior to submitting the proposed record to the ietf- > languages list. > > Note: Descriptions in registry entries that correspond to ISO 639, > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate > the meaning of that identifier as defined in the source standard at > the time it was added to the registry. The description does not > replace the content of the source standard itself. The descriptions > are not intended to be the English localized names for the subtags. > Localization or translation of language tag and subtag descriptions > is out of scope of this document. > > 3.1.5. Deprecated Field > > The field 'Deprecated' MAY be added to any record via the maintenance > process described in Section 3.3 or via the registration process > described in Section 3.5. Usually, the addition of a 'Deprecated' > field is due to the action of one of the standards bodies, such as > ISO 3166, withdrawing a code. In some historical cases, it might not > have been possible to reconstruct the original deprecation date. For > these cases, an approximate date appears in the registry. Although > valid in language tags, subtags and tags with a 'Deprecated' field > are deprecated and validating processors SHOULD NOT generate these > subtags. Note that a record that contains a 'Deprecated' field and > no corresponding 'Preferred-Value' field has no replacement mapping. > > 3.1.6. Preferred-Value Field > > The field 'Preferred-Value' contains a mapping between the record in > which it appears and another tag or subtag. The value in this field > is strongly RECOMMENDED as the best choice to represent the value of > this record when selecting a language tag. These values form three > groups: > > 1. ISO 639 language codes that were later withdrawn in favor of > other codes. These values are mostly a historical curiosity. > > 2. ISO 3166 region codes that have been withdrawn in favor of a new > code. This sometimes happens when a country changes its name or > administration in such a way that warrants a new region code. > > 3. Grandfathered or redundant tags from RFC 3066. In many cases, > these tags have become obsolete because the values they represent > were later encoded by ISO 639. > > Records that contain a 'Preferred-Value' field MUST also have a > > > > Phillips & Davis Expires February 25, 2008 [Page 25] > > Internet-Draft langtags-registry August 2007 > > > 'Deprecated' field. This field contains a date of deprecation. > Thus, a language tag processor can use the registry to construct the > valid, non-deprecated set of subtags for a given date. In addition, > for any given tag, a processor can construct the set of valid > language tags that correspond to that tag for all dates up to the > date of the registry. The ability to do these mappings MAY be > beneficial to applications that are matching, selecting, for > filtering content based on its language tags. > > Note that 'Preferred-Value' mappings in records of type 'region' > sometimes do not represent exactly the same meaning as the original > value. There are many reasons for a country code to be changed, and > the effect this has on the formation of language tags will depend on > the nature of the change in question. > > In particular, the 'Preferred-Value' field does not imply retagging > content that uses the affected subtag. > > The field 'Preferred-Value' MUST NOT be modified once created in the > registry. The field MAY be added to records according to the rules > in Section 3.3. > > The 'Preferred-Value' field in records of type "grandfathered" and > "redundant" contains whole language tags that are strongly > RECOMMENDED for use in place of the record's value. In many cases, > the mappings were created by deprecation of the tags during the > period before this document was adopted. For example, the tag "no- > nyn" was deprecated in favor of the ISO 639-1-defined language code > 'nn'. > > 3.1.7. Prefix Field > > The 'Prefix' field contains an extended language range whose subtags > are appropriate to use with this subtag: each of the subtags in one > of the subtag's Prefix fields MUST appear before the variant in a > valid tag. For example, the variant subtag '1996' has a 'Prefix' > field of "de". This means that tags starting with the sequence "de-" > are appropriate with this subtag, so "de-Latg-1996" and "de-CH-1996" > are both acceptable, while the tag "fr-1996" is an inappropriate > choice. > > The field of type 'Prefix' MUST NOT be removed from any record. The > field-body for this type of field MAY be modified, but only if the > modification broadens the meaning of the subtag. That is, the field- > body can be replaced only by a prefix a prefix of itself. For > example, the Prefix "be-Latn" (Belarusian, Latin script) could be > replaced by the Prefix "be" (Belarusian) but not by the Prefix "ru- > Latn" (Russian, Latin script). > > > > Phillips & Davis Expires February 25, 2008 [Page 26] > > Internet-Draft langtags-registry August 2007 > > > Records of type 'variant' MAY have more than one field of type > 'Prefix'. Additional fields of this type MAY be added to a 'variant' > record via the registration process. > > The field-body of the 'Prefix' field MUST NOT conflict with any > 'Prefix' already registered for a given record. Such a conflict > would occur when when no valid tag could be constructed that would > contain the prefix, such as when when two subtags each have a > 'Prefix' that contains the other subtag. For example, suppose that > the subtag 'avariant' has the prefix "es-bvariant". Then the subtag > 'bvariant' cannot given the prefix 'avariant', for that would require > a tag of the form "es-avariant-bvariant-avariant", which would not be > valid. > > Records of type 'extlang' MUST have _exactly_ one 'Prefix' field. > > 3.1.8. Suppress-Script Field > > The field 'Suppress-Script' contains a script subtag (whose record > appears in the registry). The field 'Suppress-Script' MUST only > appear in records whose 'Type' field-body is 'language'. This field > MUST NOT appear more than one time in a record. This field indicates > a script used to write the overwhelming majority of documents for the > given language. This script code therefore adds no distinguishing > information to a language tag. This helps ensure greater > compatibility between the language tags generated according to the > rules in this document and language tags and tag processors or > consumers based on RFC 3066 by indicating that the script subtag > SHOULD NOT be used for most documents in that language. For example, > virtually all Icelandic documents are written in the Latin script, > making the subtag 'Latn' redundant in the tag "is-Latn". > > Many language subtag records do not have a Suppress-Script field. > The lack of a Suppress-Script might indicate that the language is > customarily written in more than one script or that the language is > not customarily written at all. It might also mean that sufficient > information was not available when the record was created and thus > remains a candidate for future registration. > > 3.1.9. Macrolanguage Field > > The Macrolanguage field contains a primary or extended language > subtag that encompasses this subtag's language. That is, the > language subtag whose record this field appears in is sometimes > considered to be a sub-language of the Macrolanguage. Macrolanguage > values are defined by ISO 639-3 and the exact nature of the > relationship between the encompassed and encompassing languages > varies on a case-by-case basis. > > > > Phillips & Davis Expires February 25, 2008 [Page 27] > > Internet-Draft langtags-registry August 2007 > > > This field can be useful to applications or users when selecting > language tags or as additional metadata useful in matching. The > Macrolanguage field can only occur in records of type 'language' or > 'extlang'. Only values assigned by ISO 639-3 will be considered for > inclusion. Macrolanguage fields MAY be added or removed via the > normal registration process whenever ISO 639-3 defines new values. > Macrolanguages are informational, and MAY be removed or changed if > ISO 639-3 changes the values. > > For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn' > (Norwegian Nynorsk) each have a Macrolanguage entry of 'no' > (Norwegian). For more information see Section 4.1. > > 3.1.10. Comments Field > > The field 'Comments' conveys additional information about the record > and MAY appear more than once per record. The field-body MAY include > the full range of Unicode characters and is not restricted to any > particular script. This field MAY be inserted or changed via the > registration process and no guarantee of stability is provided. The > content of this field is not restricted, except by the need to > register the information, the suitability of the request, and by > reasonable practical size limitations. > > 3.2. Language Subtag Reviewer > > The Language Subtag Reviewer moderates the ietf-languages mailing > list, responds to requests for registration, and performs the other > registry maintenance duties described in Section 3.3. Only the > Language Subtag Reviewer is permitted to request IANA to change, > update, or add records to the Language Subtag Registry. The Language > Subtag Reviewer MAY delegate list moderation and other clerical > duties as needed. > > The Language Subtag Reviewer is appointed by the IESG for an > indefinite term, subject to removal or replacement at the IESG's > discretion. The IESG will solicit nominees for the position (upon > adoption of this document or upon a vacancy) and then solicit > feedback on the nominees' qualifications. Qualified candidates > should be familiar with BCP 47 and its requirements; be willing to > fairly, responsively, and judiciously administer the registration > process; and be suitably informed about the issues of language > identification so that they can draw upon and assess the claim and > contributions of language experts and subtag requesters. > > The subsequent performance or decisions of the Language Subtag > Reviewer MAY be appealed to the IESG under the same rules as other > IETF decisions (see [RFC2026]). The IESG can reverse or overturn the > > > > Phillips & Davis Expires February 25, 2008 [Page 28] > > Internet-Draft langtags-registry August 2007 > > > decision of the Language Subtag Reviewer, provide guidance, or take > other appropriate actions. > > 3.3. Maintenance of the Registry > > Maintenance of the registry requires that as codes are assigned or > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language > Subtag Reviewer MUST evaluate each change and determine the > appropriate course of action according to the rules in this document. > Such updates follow the registration process described in > Section 3.5. Usually the Language Subtag Reviewer will start the > process for the new or updated record by filling in the registration > form and submitting it. If a change to one of these standards takes > place and the Language Subtag Reviewer does not do this in a timely > manner, then any interested party MAY submit the form. Thereafter > the registration process continues normally. > > The Language Subtag Reviewer MUST ensure that new subtags meet the > requirements elsewhere in this document (and most especially in > Section 3.4) or submit an appropriate registration form for an > alternate subtag as described in that section. Each individual > subtag affected by a change MUST be sent to the ietf-languages list > with its own registration form and in a separate message. > > 3.4. Stability of IANA Registry Entries > > The stability of entries and their meaning in the registry is > critical to the long-term stability of language tags. The rules in > this section guarantee that a specific language tag's meaning is > stable over time and will not change. > > These rules specifically deal with how changes to codes (including > withdrawal and deprecation of codes) maintained by ISO 639, ISO > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language > Subtag Registry. Assignments to the IANA Language Subtag Registry > MUST follow the following stability rules: > > 1. Values in the fields 'Type', 'Subtag', 'Tag', 'Added', > 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are > guaranteed to be stable over time. > > 2. Values in the 'Description' field MUST NOT be changed in a way > that would invalidate previously-existing tags. They MAY be > broadened somewhat in scope, changed to add information, or > adapted to the most common modern usage. For example, countries > occasionally change their official names; a historical example > of this would be "Upper Volta" changing to "Burkina Faso". > > > > > Phillips & Davis Expires February 25, 2008 [Page 29] > > Internet-Draft langtags-registry August 2007 > > > 3. Values in the field 'Prefix' MAY be added to records of type > 'variant' via the registration process. If a prefix is added to > a variant record, 'Comment' fields SHOULD be used to explain > different usages with the various prefixes. > > 4. Values in the field 'Prefix' in records of type 'variant' MAY be > modified, so long as the modifications broaden the set of > prefixes. That is, a prefix MAY be replaced by one of its own > prefixes. For example, the prefix "en-US" could be replaced by > "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". > If one of those prefixes were needed, a new Prefix SHOULD be > registered. > > 5. Values in the field 'Prefix' in records of type 'extlang' MUST > NOT be modified. > > 6. Values in the field 'Prefix' MUST NOT be removed. > > 7. The field 'Comments' MAY be added, changed, modified, or removed > via the registration process or any of the processes or > considerations described in this section. > > 8. The field 'Suppress-Script' MAY be added or removed via the > registration process. > > 9. The field 'Macrolanguage' MAY be added or removed via the > registration process, but only in response to changes made by > ISO 639. The Macrolanguage field appears whenever a language > has a corresponding Macrolanguage in ISO 639. That is, the > macrolanguage fields in the registry exactly match those of ISO > 639. No other macrolanguage mappings will be considered for > registration. > > 10. Codes assigned by ISO 639-1 that do not conflict with existing > two-letter primary language subtags and which have no > corresponding three-letter primary or extended language subtags > defined in the registry are entered into the IANA registry as > new records of type 'language'. > > 11. Codes assigned by ISO 639-2 that do not conflict with existing > three-letter primary or extended language subtags are entered > into the IANA registry as new records of type 'language'. > > 12. Codes assigned by ISO 639-3 that do not conflict with existing > three-letter primary or extended language subtags are entered > into the IANA registry as new records. > > > > > > Phillips & Davis Expires February 25, 2008 [Page 30] > > Internet-Draft langtags-registry August 2007 > > > 1. Codes that have a defined "macrolanguage" mapping at the > time of their registration MUST be entered into the registry > as records of type 'extlang' with a 'Prefix' field > containing the appropriate prefix tag. They MUST also > include a "Macrolanguage" field in their record. > > 2. Codes that represent sign languages MUST be entered into the > registry as record of type 'extlang' with a 'Prefix' field > that matches the Basic Language Range "sgn" (see Section > 3.3.1 "Basic Filtering" in [RFC4647]). > > 3. All other codes MUST be entered into the registry as records > of type 'language'. > > 13. A record of type 'language' or 'extlang' MUST NOT be registered > if there exists a record of either type with the same subtag > value. For example, if an 'extlang' subtag 'foo' exists in the > registry, all attempts to register a 'language' subtag 'foo' > will be rejected. > > 14. Codes assigned by 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. > > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are > withdrawn by their respective maintenance or registration > authority remain valid in language tags. A 'Deprecated' field > containing the date of withdrawal MUST be added to the record. > If a new record of the same type is added that represents a > replacement value, then a 'Preferred-Value' field MAY also be > added. The registration process MAY be used to add comments > about the withdrawal of the code by the respective standard. > > Example The region code 'TL' was assigned to the country > 'Timor-Leste', replacing the code 'TP' (which was assigned to > 'East Timor' when it was under administration by Portugal). > The subtag 'TP' remains valid in language tags, but its > record contains the a 'Preferred-Value' of 'TL' and its field > 'Deprecated' contains the date the new code was assigned > ('2004-07-06'). > > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict > with existing subtags of the associated type, including subtags > that are deprecated, MUST NOT be entered into the registry. The > following additional considerations apply to subtag values that > are reassigned: > > > > > Phillips & Davis Expires February 25, 2008 [Page 31] > > Internet-Draft langtags-registry August 2007 > > > A. For ISO 639 codes, if the newly assigned code's meaning is > not represented by a subtag in the IANA registry, the > Language Subtag Reviewer, as described in Section 3.5, SHALL > prepare a proposal for entering in the IANA registry as soon > as practical a registered language subtag as an alternate > value for the new code. The form of the registered language > subtag will be at the discretion of the Language Subtag > Reviewer and MUST conform to other restrictions on language > subtags in this document. > > B. For all subtags whose meaning is derived from an external > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN > M.49), if a new meaning is assigned to an existing code and > the new meaning broadens the meaning of that code, then the > meaning for the associated subtag MAY be changed to match. > The meaning of a subtag MUST NOT be narrowed, however, as > this can result in an unknown proportion of the existing > uses of a subtag becoming invalid. Note: ISO 639 > maintenance agency/registration authority (MA/RA) has > adopted a similar stability policy. > > C. For ISO 15924 codes, if the newly assigned code's meaning is > not represented by a subtag in the IANA registry, the > Language Subtag Reviewer, as described in Section 3.5, SHALL > prepare a proposal for entering in the IANA registry as soon > as practical a registered variant subtag as an alternate > value for the new code. The form of the registered variant > subtag will be at the discretion of the Language Subtag > Reviewer and MUST conform to other restrictions on variant > subtags in this document. > > D. For ISO 3166 codes, if the newly assigned code's meaning is > associated with the same UN M.49 code as another 'region' > subtag, then the existing region subtag remains as the > preferred value for that region and no new entry is created. > A comment MAY be added to the existing region subtag > indicating the relationship to the new ISO 3166 code. > > E. For ISO 3166 codes, if the newly assigned code's meaning is > associated with a UN M.49 code that is not represented by an > existing region subtag, then the Language Subtag Reviewer, > as described in Section 3.5, SHALL prepare a proposal for > entering the appropriate UN M.49 country code as an entry in > the IANA registry. > > F. For ISO 3166 codes, if there is no associated UN numeric > code, then the Language Subtag Reviewer SHALL petition the > UN to create one. If there is no response from the UN > > > > Phillips & Davis Expires February 25, 2008 [Page 32] > > Internet-Draft langtags-registry August 2007 > > > within ninety days of the request being sent, the Language > Subtag Reviewer SHALL prepare a proposal for entering in the > IANA registry as soon as practical a registered variant > subtag as an alternate value for the new code. The form of > the registered variant subtag will be at the discretion of > the Language Subtag Reviewer and MUST conform to other > restrictions on variant subtags in this document. This > situation is very unlikely to ever occur. > > 17. UN M.49 has codes for both countries and areas (such as '276' > for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is > blocked from registration by an existing subtag. If such a code > becomes necessary, then the registration authority for ISO 3166 > SHOULD first be petitioned to assign a code to the region. If > the petition for a code assignment by ISO 3166 is refused or not > acted on in a timely manner, the registration process described > in Section 3.5 MAY then be used to register the corresponding UN > M.49 code. This way, UN M.49 codes remain available as the > value of last resort in cases where ISO 3166 reassigns a > deprecated value in the registry. > > 18. Stability provisions apply to grandfathered tags with this > exception: should it be possible to compose one of the > grandfathered tags from registered subtags, then the field > 'Type' in that record is changed from 'grandfathered' to > 'redundant'. Note that this will not affect language tags that > match the grandfathered tag, since these tags will now match > valid generative subtag sequences. For example, this document > caused the ISO 639-3 code 'gan', used in the redundant tag "zh- > gan", to be registered as an extended language subtag. The > formerly-grandfathered tag "zh-gan" became a redundant tag as a > result (but existing content or implementations that use "zh- > gan" remain valid). > > Note: The redundant and grandfathered entries together are the > complete list of tags registered under [RFC3066]. The redundant tags > are those that can now be formed using the subtags defined in the > registry together with the rules of Section 2.2. The grandfathered > entries include those that can never be legal under those same > provisions plus those tags that contain subtags not yet registered > or, perhaps, inappropriate for registration. > > The set of redundant and grandfathered tags is permanent and stable: > new entries in this section MUST NOT be added and existing entries > MUST NOT be removed. Records of type 'grandfathered' MAY have their > > > > Phillips & Davis Expires February 25, 2008 [Page 33] > > Internet-Draft langtags-registry August 2007 > > > type converted to 'redundant'; see item 12 in Section 3.6 for more > information. The decision-making process about which tags were > initially grandfathered and which were made redundant is described in > [RFC4645]. > > RFC 3066 tags that were deprecated prior to the adoption of [RFC4646] > are part of the list of grandfathered tags, and their component > subtags were not included as registered variants (although they > remain eligible for registration). For example, the tag "art-lojban" > was deprecated in favor of the language subtag 'jbo'. > > 3.5. Registration Procedure for Subtags > > The procedure given here MUST be used by anyone who wants to use a > subtag not currently in the IANA Language Subtag Registry. > > Only subtags of type 'language' and 'variant' will be considered for > independent registration of new subtags. Subtags needed for > stability and subtags necessary to keep the registry synchronized > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits > defined by this document also use this process, as described in > Section 3.3. Stability provisions are described in Section 3.4. > > This procedure MAY also be used to register or alter the information > for the 'Description', 'Comments', 'Deprecated', 'Prefix', or > 'Suppress-Script' fields in a subtag's record as described in > Section 3.4. Changes to all other fields in the IANA registry are > NOT permitted. > > Registering a new subtag or requesting modifications to an existing > tag or subtag starts with the requester filling out the registration > form reproduced below. Note that each response is not limited in > size so that the request can adequately describe the registration. > The fields in the "Record Requested" section SHOULD follow the > requirements in Section 3.1. > > > > > > > > > > > > > > > > > Phillips & Davis Expires February 25, 2008 [Page 34] > > Internet-Draft langtags-registry August 2007 > > > LANGUAGE SUBTAG REGISTRATION FORM > 1. Name of requester: > 2. E-mail address of requester: > 3. Record Requested: > > Type: > Subtag: > Description: > Prefix: > Preferred-Value: > Deprecated: > Suppress-Script: > Macrolanguage: > Comments: > > 4. Intended meaning of the subtag: > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: > > Figure 4: The Language Subtag Registration Form > > Examples of completed registration forms can be found in Appendix C > or online at http://www.iana.org/assignments/lang-subtags-templates/. > > The subtag registration form MUST be sent to > for a two-week review period before it can > be submitted to IANA. If modifications are made to the request > during the course of the registration process (such as corrections to > meet the requirements in Section 3.1) the modified form MUST also be > sent to at least one week prior to > submission to IANA. > > Whenever an entry is created or modified in the registry, the 'File- > Date' record at the start of the registry is updated to reflect the > most recent modification date in the [RFC3339] "full-date" format. > > Before forwarding a new registration to IANA, the Language Subtag > Reviewer MUST ensure that values in the 'Subtag' field match case > according to the description in Section 3.1. > > The ietf-languages list is an open list and can be joined by sending > a request to . The list can be > hosted by IANA or by any third party at the request of IESG. > > Some fields in both the registration form as well as the registry > record itself permit the use of non-ASCII characters. Registration > requests SHOULD use the UTF-8 encoding for consistency and clarity. > > > > Phillips & Davis Expires February 25, 2008 [Page 35] > > Internet-Draft langtags-registry August 2007 > > > However, since some mail clients do not support this encoding, other > encodings MAY be used for the registration request. The Language > Subtag Reviewer is responsible for ensuring that the proper Unicode > characters appear in both the archived request form and the registry > record. In the case of a transcription or encoding error by IANA, > the Language Subtag Reviewer will request that the registry be > repaired, providing any necessary information to assist IANA. > > Variant subtags are usually registered for use with a particular > range of language tags. For example, the subtag 'rozaj' is intended > for use with language tags that start with the primary language > subtag "sl", since Resian is a dialect of Slovenian. Thus, the > subtag 'rozaj' would be appropriate in tags such as "sl-Latn-rozaj" > or "sl-IT-rozaj". This information is stored in the 'Prefix' field > in the registry. Variant registration requests SHOULD include at > least one 'Prefix' field in the registration form. > > Extended language subtags MUST include exactly one 'Prefix' field. > > The 'Prefix' field for a given registered subtag exists in the IANA > registry as a guide to usage. Additional prefixes MAY be added by > filing an additional registration form. In that form, the "Any other > relevant information:" field MUST indicate that it is the addition of > a prefix. > > Requests to add a prefix to a variant subtag that imply a different > semantic meaning will probably be rejected. For example, a request > to add the prefix "de" to the subtag 'nedis' so that the tag "de- > nedis" represented some German dialect would be rejected. The > 'nedis' subtag represents a particular Slovenian dialect and the > additional registration would change the semantic meaning assigned to > the subtag. A separate subtag SHOULD be proposed instead. > > The 'Description' field MUST contain a description of the tag being > registered written or transcribed into the Latin script; it MAY also > include a description in a non-Latin script. The 'Description' field > is used for identification purposes and doesn't necessarily represent > the actual native name of the language or variation or to be in any > particular language. > > While the 'Description' field itself is not guaranteed to be stable > and errata corrections MAY be undertaken from time to time, attempts > to provide translations or transcriptions of entries in the registry > itself will probably be frowned upon by the community or rejected > outright, as changes of this nature have an impact on the provisions > in Section 3.4. > > When the two-week period has passed, the Language Subtag Reviewer > > > > Phillips & Davis Expires February 25, 2008 [Page 36] > > Internet-Draft langtags-registry August 2007 > > > MUST take one of the following actions: > > o Explicitly accept the request and forward the form containing the > record to be inserted or modified to iana@iana.org according to > the procedure described in Section 3.3. > > o Explicitly reject the request because of significant objections > raised on the list or due to problems with constraints in this > document (which MUST be explicitly cited). > > o Extend the review period by granting an additional two-week > increment to permit further discussion. After each two-week > increment, the Language Subtag Reviewer MUST indicate on the list > whether the registration has been accepted, rejected, or extended. > > Note that the Language Subtag Reviewer MAY raise objections on the > list if he or she so desires. The important thing is that the > objection MUST be made publicly. > > Sometimes the request needs to be modified as a result of discussion > during the review period or due to requirements in this document. > The applicant, Language Subtag Reviewer, or others are free to submit > a modified version of the completed registration form, which will be > considered in lieu of the original request with the explicit approval > of the applicant. Such changes do not restart the two-week > discussion period, although an application containing the final > record submitted to IANA MUST appear on the list at least one week > prior to the Language Subtag Reviewer forwarding the record to IANA. > The applicant is also free to modify a rejected application with > additional information and submit it again; this starts a new two- > week comment period. > > Registrations initiated due to the provisions of Section 3.3 or > Section 3.4 SHALL NOT be rejected altogether (since they have to > ultimately appear in the registry) and SHOULD be completed as quickly > as possible. The review process allows list members to comment on > the specific information in the form and the record it contains and > thus help ensure that it is correct and consistent. The Language > Subtag Reviewer MAY reject a specific version of the form, but MUST > include in the rejection a suitable replacement, extending the review > period as described above, until the form is in a format worthy of > reviewer's approval. > > Decisions made by the Language Subtag Reviewer MAY be appealed to the > IESG [RFC2028] under the same rules as other IETF decisions > [RFC2026]. This includes a decision to extend the review period or > the failure to announce a decision in a clear and timely manner. > > > > > Phillips & Davis Expires February 25, 2008 [Page 37] > > Internet-Draft langtags-registry August 2007 > > > The approved records appear in the Language Subtag Registry. The > approved registration forms are available online under > http://www.iana.org/assignments/lang-subtags-templates/. > > Updates or changes to existing records follow the same procedure as > new registrations. The Language Subtag Reviewer decides whether > there is consensus to update the registration following the two week > review period; normally, objections by the original registrant will > carry extra weight in forming such a consensus. > > Registrations are permanent and stable. Once registered, subtags > will not be removed from the registry and will remain a valid way in > which to specify a specific language or variant. > > Note: The purpose of the "Reference to published description" section > in the registration form is to aid in verifying whether a language is > registered or what language or language variation a particular subtag > refers to. In most cases, reference to an authoritative grammar or > dictionary of that language will be useful; in cases where no such > work exists, other well-known works describing that language or in > that language MAY be appropriate. The Language Subtag Reviewer > decides what constitutes "good enough" reference material. This > requirement is not intended to exclude particular languages or > dialects due to the size of the speaker population or lack of a > standardized orthography. Minority languages will be considered > equally on their own merits. > > 3.6. Possibilities for Registration > > Possibilities for registration of subtags or information about > subtags include: > > o Primary language subtags for languages not listed in ISO 639 that > are not variants of any listed or registered language MAY be > registered. At the time this document was created, there were no > examples of this form of subtag. Before attempting to register a > language subtag, there MUST be an attempt to register the language > with ISO 639. Subtags MUST NOT be registered for languages > defined by codes that exist in ISO 639-1, ISO 639-2, or ISO 639-3, > or that are under consideration by the ISO 639 registration > authorities, or that have never been attempted for registration > with those authorities. If ISO 639 has previously rejected a > language for registration, it is reasonable to assume that there > must be additional, very compelling evidence of need before it > will be registered as a primary language subtag in the IANA > registry (to the extent that it is very unlikely that any subtags > will be registered of this type). > > > > > Phillips & Davis Expires February 25, 2008 [Page 38] > > Internet-Draft langtags-registry August 2007 > > > o Dialect or other divisions or variations within a language, its > orthography, writing system, regional or historical usage, > transliteration or other transformation, or distinguishing > variation MAY be registered as variant subtags. An example is the > 'rozaj' subtag (the Resian dialect of Slovenian). > > o The addition or maintenance of fields (generally of an > informational nature) in Tag or Subtag records as described in > Section 3.1 and subject to the stability provisions in > Section 3.4. This includes descriptions, comments, deprecation > and preferred values for obsolete or withdrawn codes, or the > addition of script or extlang information to primary language > subtags. > > o The addition of records and related field value changes necessary > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and > UN M.49 as described in Section 3.4. > > Subtags proposed for registration that would cause all or part of a > grandfathered tag to become redundant but whose meaning conflicts > with or alters the meaning of the grandfathered tag MUST be rejected. > > This document leaves the decision on what subtags or changes to > subtags are appropriate (or not) to the registration process > described in Section 3.5. > > Note: four-character primary language subtags are reserved to allow > for the possibility of alpha4 codes in some future addition to the > ISO 639 family of standards. > > ISO 639 defines a maintenance agency for additions to and changes in > the list of languages in ISO 639. This agency is: > > International Information Centre for Terminology (Infoterm) > Aichholzgasse 6/12, AT-1120 > Wien, Austria > Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 > > ISO 639-2 defines a maintenance agency for additions to and changes > in the list of languages in ISO 639-2. This agency is: > > Library of Congress > Network Development and MARC Standards Office > Washington, D.C. 20540 USA > Phone: +1 202 707 6237 Fax: +1 202 707 0115 > URL: http://www.loc.gov/standards/iso639-2 > > ISO 639-3 defines a maintenance agency for additions to and changes > > > > Phillips & Davis Expires February 25, 2008 [Page 39] > > Internet-Draft langtags-registry August 2007 > > > in the list of languages in ISO 639-3. This agency is: > > SIL International > ISO 639-3 Registrar > 7500 W. Camp Wisdom Rd. > Dallas, TX 75236 USA > Phone: +1 972 708 7400, ext. 2293 Fax: +1 972 708 7546 > Email: iso639-3@sil.org > URL: http://www.sil.org/iso639-3 > > The maintenance agency for ISO 3166 (country codes) is: > > ISO 3166 Maintenance Agency > c/o International Organization for Standardization > Case postale 56 > CH-1211 Geneva 20 Switzerland > Phone: +41 22 749 72 33 Fax: +41 22 749 73 49 > URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html > > The registration authority for ISO 15924 (script codes) is: > > Unicode Consortium Box 391476 > Mountain View, CA 94039-1476, USA > URL: http://www.unicode.org/iso15924 > > The Statistics Division of the United Nations Secretariat maintains > the Standard Country or Area Codes for Statistical Use and can be > reached at: > > Statistical Services Branch > Statistics Division > United Nations, Room DC2-1620 > New York, NY 10017, USA > > Fax: +1-212-963-0623 > E-mail: statistics@un.org > URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm > > 3.7. Extensions and Extensions Registry > > Extension subtags are those introduced by single-character subtags > ("singletons") other than 'x'. They are reserved for the generation > of identifiers that contain a language component and are compatible > with applications that understand language tags. > > The structure and form of extensions are defined by this document so > that implementations can be created that are forward compatible with > applications that might be created using singletons in the future. > > > > Phillips & Davis Expires February 25, 2008 [Page 40] > > Internet-Draft langtags-registry August 2007 > > > In addition, defining a mechanism for maintaining singletons will > lend stability to this document by reducing the likely need for > future revisions or updates. > > Single-character subtags are assigned by IANA using the "IETF > Consensus" policy defined by [RFC2434]. This policy requires the > development of an RFC, which SHALL define the name, purpose, > processes, and procedures for maintaining the subtags. The > maintaining or registering authority, including name, contact email, > discussion list email, and URL location of the registry, MUST be > indicated clearly in the RFC. The RFC MUST specify or include each > of the following: > > o The specification MUST reference the specific version or revision > of this document that governs its creation and MUST reference this > section of this document. > > o The specification and all subtags defined by the specification > MUST follow the ABNF and other rules for the formation of tags and > subtags as defined in this document. In particular, it MUST > specify that case is not significant and that subtags MUST NOT > exceed eight characters in length. > > o The specification MUST specify a canonical representation. > > o The specification of valid subtags MUST be available over the > Internet and at no cost. > > o The specification MUST be in the public domain or available via a > royalty-free license acceptable to the IETF and specified in the > RFC. > > o The specification MUST be versioned, and each version of the > specification MUST be numbered, dated, and stable. > > o The specification MUST be stable. That is, extension subtags, > once defined by a specification, MUST NOT be retracted or change > in meaning in any substantial way. > > o The specification MUST include in a separate section the > registration form reproduced in this section (below) to be used in > registering the extension upon publication as an RFC. > > o IANA MUST be informed of changes to the contact information and > URL for the specification. > > IANA will maintain a registry of allocated single-character > (singleton) subtags. This registry MUST use the record-jar format > > > > Phillips & Davis Expires February 25, 2008 [Page 41] > > Internet-Draft langtags-registry August 2007 > > > described by the ABNF in Section 3.1. Upon publication of an > extension as an RFC, the maintaining authority defined in the RFC > MUST forward this registration form to iesg@ietf.org, who MUS > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_95185_17479944.1188310067868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Just to open up the discussion, the biggest problem with this version is that it uses a substantial new mechanism (extlang) which was not used in RFC 4646, and for which there is no consensus in this group to use in RFC 4646bis. We haven't removed extlang from the draft yet, but the people that want this new mechanism need to provide justification, that:
  1. it is substantially better to have languages like 'cmn' be put in a secondary position (eg zh-cmn-Hant-CN), rather than being primary subtags on their own (eg cmn-Hant-CN).
  2. it is sufficiently better to warrant making the language tags more complicated by the addition of this mechanism.
Mark

On 8/24/07, Addison Phillips <addison@yahoo-inc.com> wrote:
Dear Editors,

Please find attached in the usual text format draft-08 of
draft-ietf-ltru-rfc4646bis.

Best Regards,

Addison (for the editors)

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

Internationalization is an architecture.
It is not a feature.




Network Working Group                                   A. Phillips, Ed.
Internet-Draft                                               Yahoo! Inc.
Obsoletes: 4646 (if approved)                              M. Davis, Ed.
Intended status: Best Current                                     Google
Practice                                                 August 24, 2007
Expires: February 25, 2008


                     Tags for Identifying Languages
                       draft-ietf-ltru-4646bis-08

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt .

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Phillips & Davis        Expires February 25, 2008               [Page 1]

Internet-Draft              langtags-registry                August 2007


Abstract

   This document describes the structure, content, construction, and
   semantics of language tags for use in cases where it is desirable to
   indicate the language used in an information object.  It also
   describes how to register values for use in language tags and the
   creation of user-defined extensions for private interchange.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Language Tag . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Language Subtag Sources and Interpretation . . . . . . . .  8
       2.2.1.  Primary Language Subtag  . . . . . . . . . . . . . . .  9
       2.2.2.  Extended Language Subtags  . . . . . . . . . . . . . . 11
       2.2.3.  Script Subtag  . . . . . . . . . . . . . . . . . . . . 12
       2.2.4.  Region Subtag  . . . . . . . . . . . . . . . . . . . . 13
       2.2.5.  Variant Subtags  . . . . . . . . . . . . . . . . . . . 15
       2.2.6.  Extension Subtags  . . . . . . . . . . . . . . . . . . 16
       2.2.7.  Private Use Subtags  . . . . . . . . . . . . . . . . . 17
       2.2.8.  Grandfathered Registrations  . . . . . . . . . . . . . 18
       2.2.9.  Classes of Conformance . . . . . . . . . . . . . . . . 18
   3.  Registry Format and Maintenance  . . . . . . . . . . . . . . . 20
     3.1.  Format of the IANA Language Subtag Registry  . . . . . . . 20
       3.1.1.  File Format  . . . . . . . . . . . . . . . . . . . . . 20
       3.1.2.  Record Definitions . . . . . . . . . . . . . . . . . . 21
       3.1.3.  Subtag and Tag Fields  . . . . . . . . . . . . . . . . 24
       3.1.4.  Description Field  . . . . . . . . . . . . . . . . . . 24
       3.1.5.  Deprecated Field . . . . . . . . . . . . . . . . . . . 25
       3.1.6.  Preferred-Value Field  . . . . . . . . . . . . . . . . 25
       3.1.7.  Prefix Field . . . . . . . . . . . . . . . . . . . . . 26
       3.1.8.  Suppress-Script Field  . . . . . . . . . . . . . . . . 27
       3.1.9.  Macrolanguage Field  . . . . . . . . . . . . . . . . . 27
       3.1.10. Comments Field . . . . . . . . . . . . . . . . . . . . 28
     3.2.  Language Subtag Reviewer . . . . . . . . . . . . . . . . . 28
     3.3.  Maintenance of the Registry  . . . . . . . . . . . . . . . 29
     3.4.  Stability of IANA Registry Entries . . . . . . . . . . . . 29
     3.5.  Registration Procedure for Subtags . . . . . . . . . . . . 34
     3.6.  Possibilities for Registration . . . . . . . . . . . . . . 38
     3.7.  Extensions and Extensions Registry . . . . . . . . . . . . 40
     3.8.  Update of the Language Subtag Registry . . . . . . . . . . 43
   4.  Formation and Processing of Language Tags  . . . . . . . . . . 44
     4.1.  Choice of Language Tag . . . . . . . . . . . . . . . . . . 44
     4.2.  Meaning of the Language Tag  . . . . . . . . . . . . . . . 48
     4.3.  Length Considerations  . . . . . . . . . . . . . . . . . . 50
       4.3.1.  Working with Limited Buffer Sizes  . . . . . . . . . . 50



Phillips & Davis        Expires February 25, 2008               [Page 2]

Internet-Draft              langtags-registry                August 2007


       4.3.2.  Truncation of Language Tags  . . . . . . . . . . . . . 52
     4.4.  Canonicalization of Language Tags  . . . . . . . . . . . . 52
     4.5.  Considerations for Private Use Subtags . . . . . . . . . . 54
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 56
     5.1.  Language Subtag Registry . . . . . . . . . . . . . . . . . 56
     5.2.  Extensions Registry  . . . . . . . . . . . . . . . . . . . 57
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 58
   7.  Character Set Considerations . . . . . . . . . . . . . . . . . 59
   8.  Changes from RFC 4646  . . . . . . . . . . . . . . . . . . . . 60
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 64
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 65
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 67
   Appendix B.  Examples of Language Tags (Informative) . . . . . . . 68
   Appendix C.  Examples of Registration Forms  . . . . . . . . . . . 71
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
   Intellectual Property and Copyright Statements . . . . . . . . . . 74


































Phillips & Davis        Expires February 25, 2008               [Page 3]

Internet-Draft              langtags-registry                August 2007


1.  Introduction

   Human beings on our planet have, past and present, used a number of
   languages.  There are many reasons why one would want to identify the
   language used when presenting or requesting information.

   A user's language preferences often need to be identified so that
   appropriate processing can be applied.  For example, the user's
   language preferences in a Web browser can be used to select Web pages
   appropriately.  Language preferences can also be used to select among
   tools (such as dictionaries) to assist in the processing or
   understanding of content in different languages.

   In addition, knowledge about the particular language used by some
   piece of information content might be useful or even required by some
   types of processing; for example, spell-checking, computer-
   synthesized speech, Braille transcription, or high-quality print
   renderings.

   One means of indicating the language used is by labeling the
   information content with an identifier or "tag".  These tags can be
   used to specify user preferences when selecting information content,
   or for labeling additional attributes of content and associated
   resources.

   Tags can also be used to indicate additional language attributes of
   content.  For example, indicating specific information about the
   dialect, writing system, or orthography used in a document or
   resource may enable the user to obtain information in a form that
   they can understand, or it can be important in processing or
   rendering the given content into an appropriate form or style.

   This document specifies a particular identifier mechanism (the
   language tag) and a registration function for values to be used to
   form tags.  It also defines a mechanism for private use values and
   future extension.

   This document replaces [RFC4646], which replaced [RFC3066] and its
   predecessor [RFC1766].  For a list of changes in this document, see
   Section 8.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].







Phillips & Davis        Expires February 25, 2008               [Page 4]

Internet-Draft              langtags-registry                August 2007


2.  The Language Tag

   Language tags are used to help identify languages, whether spoken,
   written, signed, or otherwise signaled, for the purpose of
   communication.  This includes constructed and artificial languages,
   but excludes languages not intended primarily for human
   communication, such as programming languages.

2.1.  Syntax

   The language tag is composed of one or more parts, known as
   "subtags".  Each subtag consists of a sequence of alphanumeric
   characters.  Subtags are distinguished and separated from one another
   by a hyphen ("-", ABNF [RFC4234] %x2D).  A language tag consists of a
   "primary language" subtag and a (possibly empty) series of subsequent
   subtags, each of which refines or narrows the range of languages
   identified by the overall tag.

   Usually, each type of subtag is distinguished by length, position in
   the tag, and content: subtags can be recognized solely by these
   features.  The only exception to this is a fixed list of
   grandfathered tags registered under RFC 3066 [RFC3066].  This makes
   it possible to construct a parser that can extract and assign some
   semantic information to the subtags, even if the specific subtag
   values are not recognized.  Thus, a parser need not have an up-to-
   date copy (or any copy at all) of the subtag registry to perform most
   searching and matching operations.
























Phillips & Davis        Expires February 25, 2008               [Page 5]

Internet-Draft              langtags-registry                August 2007


   The syntax of the language tag in ABNF [RFC4234] is:

   Language-Tag  = langtag
                 / privateuse             ; private use tag
                 / irregular              ; tags grandfathered by rule

   langtag       = (language
                    ["-" script]
                    ["-" region]
                    *("-" variant)
                    *("-" extension)
                    ["-" privateuse])

   language      = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
                 / 4ALPHA                 ; reserved for future use
                 / 5*8ALPHA               ; registered language subtag

   extlang       = *3("-" 3ALPHA)         ; specific ISO 639-3 codes

   script        = 4ALPHA                 ; ISO 15924 code

   region        = 2ALPHA                 ; ISO 3166 code
                 / 3DIGIT                 ; UN M.49 code

   variant       = 5*8alphanum            ; registered variants
                 / (DIGIT 3alphanum)

   extension     = singleton 1*("-" (2*8alphanum))

   singleton     = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
                 ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
                 ; Single alphanumerics
                 ; "x" is reserved for private use

   privateuse    = "x" 1*("-" (1*8alphanum))

   irregular     = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default"
                 / "i-enochian" / "i-hak" / "i-klingon" / "i-lux"
                 / "i-mingo" / "i-navajo" / "i-pwn" / "i-tao"
                 / "i-tay" / "i-tsu" / "sgn-BE-fr" / "sgn-BE-nl"
                 / "sgn-CH-de"

   alphanum      = (ALPHA / DIGIT)       ; letters and numbers

                        Figure 1: Language Tag ABNF

   All subtags have a maximum length of eight characters and whitespace
   is not permitted in a language tag.  There is a subtlety in the ABNF



Phillips & Davis        Expires February 25, 2008               [Page 6]

Internet-Draft              langtags-registry                August 2007


   production 'variant': variants starting with a digit MAY be four
   characters long, while those starting with a letter MUST be at least
   five characters long.  For examples of language tags, see Appendix B.

   Note Well: the ABNF syntax does not distinguish between upper and
   lowercase.  The appearance of upper and lowercase letters in the
   varous ABNF productions above do not affect how implementations
   interpret tags.  That is, the tag "I-AMI" matches the item "i-ami" in
   the 'irregular' production.  At all times, the tags and their
   subtags, including private use and extensions, are to be treated as
   case insensitive: there exist conventions for the capitalization of
   some of the subtags, but these MUST NOT be taken to carry meaning.

   For example:

   o  [ISO639-1] recommends that language codes be written in lowercase
      ('mn' Mongolian).

   o  [ISO3166-1] recommends that country codes be capitalized ('MN'
      Mongolia).

   o  [ISO15924] recommends that script codes use lowercase with the
      initial letter capitalized ('Cyrl' Cyrillic).

   However, in the tags defined by this document, the uppercase US-ASCII
   letters in the range 'A' through 'Z' are considered equivalent and
   mapped directly to their US-ASCII lowercase equivalents in the range
   'a' through 'z'.  Thus, the tag "mn-Cyrl-MN" is not distinct from
   "MN-cYRL-mn" or "mN-cYrL-Mn" (or any other combination), and each of
   these variations conveys the same meaning: Mongolian written in the
   Cyrillic script as used in Mongolia.

   Although case distinctions do not carry meaning in language tags,
   consistent formatting and presentation of the tags will aid users.
   The format of the tags and subtags in the registry is RECOMMENDED.
   In this format, all non-initial two-letter subtags are uppercase, all
   non-initial four-letter subtags are titlecase, and all other subtags
   are lowercase.

   Note that although [RFC4234] refers to octets, the language tags
   described in this document are sequences of characters from the US-
   ASCII [ISO646] repertoire.  Language tags MAY be used in documents
   and applications that use other encodings, so long as these encompass
   the US-ASCII repertoire.  An example of this would be an XML document
   that uses the UTF-16LE [RFC2781] encoding of [Unicode].






Phillips & Davis        Expires February 25, 2008               [Page 7]

Internet-Draft              langtags-registry                August 2007


2.2.  Language Subtag Sources and Interpretation

   The namespace of language tags and their subtags is administered by
   the Internet Assigned Numbers Authority (IANA) [RFC2860] according to
   the rules in Section 5 of this document.  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.

   Terminology used in this document:

   o  Tag or tags refers to a complete language tag, such as
      "sr-Latn-RS" or "az-Arab-IR".  Examples of tags in this document
      are enclosed in double-quotes ("en-US").

   o  Subtag refers to a specific section of a tag, delimited by hyphen,
      such as the subtag 'Hant' in "zh-Hant-CN".  Examples of subtags in
      this document are enclosed in single quotes ('Hant').

   o  Code or codes refers to values defined in external standards (and
      which are used as subtags in this document).  For example, 'Hant'
      is an [ISO15924] script code that was used to define the 'Hant'
      script subtag for use in a language tag.  Examples of codes in
      this document are enclosed in single quotes ('en', 'Hant').

   The definitions in this section apply to the various subtags within
   the language tags defined by this document, excepting those
   "grandfathered" tags defined in Section 2.2.8.

   Language tags are designed so that each subtag type has unique length
   and content restrictions.  These make identification of the subtag's
   type possible, even if the content of the subtag itself is
   unrecognized.  This allows tags to be parsed and processed without
   reference to the latest version of the underlying standards or the
   IANA registry and makes the associated exception handling when
   parsing tags simpler.

   Subtags in the IANA registry that do not come from an underlying
   standard can only appear in specific positions in a tag.
   Specifically, they can only occur as primary language subtags or as
   variant subtags.

   Note that sequences of private use and extension subtags MUST occur
   at the end of the sequence of subtags and MUST NOT be interspersed
   with subtags defined elsewhere in this document.

   Single-letter and single-digit subtags are reserved for current or
   future use.  These include the following current uses:



Phillips & Davis        Expires February 25, 2008               [Page 8]

Internet-Draft              langtags-registry                August 2007


   o  The single-letter subtag 'x' is reserved to introduce a sequence
      of private use subtags.  The interpretation of any private use
      subtags is defined solely by private agreement and is not defined
      by the rules in this section or in any standard or registry
      defined in this document.

   o  All other single-letter subtags are reserved to introduce
      standardized extension subtag sequences as described in
      Section 3.7.

   The single-letter subtag 'i' is used by some grandfathered tags, such
   as "i-default", where it always appears in the first position and
   cannot be confused with an extension.

2.2.1.  Primary Language Subtag

   The primary language subtag is the first subtag in a language tag
   (with the exception of private use and certain grandfathered tags)
   and cannot be omitted.  The following rules apply to the primary
   language subtag:

   1.  All two-character primary language subtags were defined in the
       IANA registry according to the assignments found in the standard
       ISO 639 Part 1, "ISO 639-1:2002, Codes for the representation of
       names of languages -- Part 1: Alpha-2 code" [ISO639-1], or using
       assignments subsequently made by the ISO 639-1 registration
       authority (RA) or governing standardization bodies.

   2.  All three-character primary language subtags were defined in the
       IANA registry according to the assignments found in either ISO
       639 Part 2, "ISO 639-2:1998 - Codes for the representation of
       names of languages -- Part 2: Alpha-3 code - edition 1"
       [ISO639-2], ISO 639 Part 3, "Codes for the representation of
       names of languages -- Part 3: Alpha-3 code for comprehensive
       coverage of languages" [ISO639-3], or assignments subsequently
       made by the relevant ISO 639 registration authorities or
       governing standardization bodies.

   3.  The subtags in the range 'qaa' through 'qtz' are reserved for
       private use in language tags.  These subtags correspond to codes
       reserved by ISO 639-2 for private use.  These codes MAY be used
       for non-registered primary language subtags (instead of using
       private use subtags following 'x-').  Please refer to Section 4.5
       for more information on private use subtags.

   4.  All four-character language subtags are reserved for possible
       future standardization.




Phillips & Davis        Expires February 25, 2008               [Page 9]

Internet-Draft              langtags-registry                August 2007


   5.  All language subtags of 5 to 8 characters in length in the IANA
       registry were defined via the registration process in Section 3.5
       and MAY be used to form the primary language subtag.  At the time
       this document was created, there were no examples of this kind of
       subtag and future registrations of this type will be discouraged:
       primary languages are strongly RECOMMENDED for registration with
       ISO 639, and proposals rejected by ISO 639/RA-JAC will be closely
       scrutinized before they are registered with IANA.

   6.  The single-character subtag 'x' as the primary subtag indicates
       that the language tag consists solely of subtags whose meaning is
       defined by private agreement.  For example, in the tag "x-fr-CH",
       the subtags 'fr' and 'CH' SHOULD NOT be taken to represent the
       French language or the country of Switzerland (or any other value
       in the IANA registry) unless there is a private agreement in
       place to do so.  See Section 4.5.

   7.  The single-character subtag 'i' is used by some grandfathered
       tags (see Section 2.2.8) such as "i-klingon" and "i-bnn".  (Other
       grandfathered tags have a primary language subtag in their first
       position.)

   8.  Other values MUST NOT be assigned to the primary subtag except by
       revision or update of this document.

   Note: For languages that have both an ISO 639-1 two-character code
   and a three character code assigned by either ISO 639-2 or ISO 639-3,
   only the ISO 639-1 two-character code is defined in the IANA
   registry.

   Note: For languages that have no ISO 639-1 two-character code and for
   which the ISO 639-2/T (Terminology) code and the ISO 639-2/B
   (Bibliographic) codes differ, only the Terminology code is defined in
   the IANA registry.  At the time this document was created, all
   languages that had both kinds of three-character code were also
   assigned a two-character code; it is expected that future assignments
   of this nature will not occur.

   Note: To avoid problems with versioning and subtag choice as
   experienced during the transition between RFC 1766 and RFC 3066, as
   well as the canonical nature of subtags defined by this document, the
   ISO 639 Registration Authority Joint Advisory Committee (ISO 639/
   RA-JAC) has included the following statement in [iso639.prin]:

      "A language code already in ISO 639-2 at the point of freezing ISO
      639-1 shall not later be added to ISO 639-1.  This is to ensure
      consistency in usage over time, since users are directed in
      Internet applications to employ the alpha-3 code when an alpha-2



Phillips & Davis        Expires February 25, 2008              [Page 10]

Internet-Draft              langtags-registry                August 2007


      code for that language is not available."

   In order to avoid instability in the canonical form of tags, if a
   two-character code is added to ISO 639-1 for a language for which a
   three-character code was already included in either ISO 639-2 or ISO
   639-3, the two-character code MUST NOT be registered.  See
   Section 3.4.

   For example, if some content were tagged with 'haw' (Hawaiian), which
   currently has no two-character code, the tag would not be invalidated
   if ISO 639-1 were to assign a two-character code to the Hawaiian
   language at a later date.

   Note: An example of independent primary language subtag registration
   might include: one of the grandfathered IANA registrations is
   "i-enochian".  The subtag 'enochian' could be registered in the IANA
   registry as a primary language subtag (assuming that ISO 639 does not
   register this language first), making tags such as "enochian-AQ" and
   "enochian-Latn" valid.

2.2.2.  Extended Language Subtags

   Extended language subtags are used to identify languages that are
   encompassed by a "macrolanguage".  ISO 639-3 defines certain
   languages to be "macrolanguages"; that is, they are groups of very
   closely related languages which are treated as a single language in
   certain contexts.  In order to improve matching behavior and tagging
   consistency, each language encompassed by a ISO 639-3 macrolanguage
   is represented in the IANA registry using an extended language
   subtag, provided that it is not already represented using a language
   subtag.  The following rules apply to the extended language subtags:

   1.  These subtags were defined in the IANA registry according to
       assignments found in ISO 639 Part 3.

   2.  A sequence of up to three extended language subtags MAY appear in
       a language tag.  This sequence MUST follow the primary language
       subtag and precede any other subtags.

   3.  Each extended language subtag MUST only appear in a tag
       immediately following the exact sequence of subtags that appears
       in the 'Prefix' field in its registry record.

   4.  Other values MUST NOT be assigned to the extended language subtag
       except by revision or update of this document.

   Extended language subtag records MUST include exactly one 'Prefix'
   field indicating an appropriate subtag or sequence of subtags for



Phillips & Davis        Expires February 25, 2008              [Page 11]

Internet-Draft              langtags-registry                August 2007


   that extended language subtag.

   For example, the 'gan' and 'cmn' subtags represent the languages Gan
   Chinese and Mandarin Chinese.  Each is encompassed by the
   macrolanguage 'zh' (Chinese).  Therefore, they both have the prefix
   "zh" in their registry records.  Consequently, Gan Chinese is
   represented as "zh-gan" and Mandarin Chinese as "zh-cmn".  The
   language subtag 'zh' can still be used without an extended language
   subtag to label a resource as some unspecified variety of Chinese
   (which in practice will usually be Mandarin, the dominant variety of
   Chinese, but might also be some other variety).

   Now suppose that, in the future, the ISO 639-3 Registration Authority
   were to decide that Gan Chinese is actually two different closely
   related languages: it might reclassify 'gan' as a macrolanguage and
   introduce two new code elements.  In that case, these code elements
   would be added to the IANA registry as extended language subtags with
   prefixes of "zh-gan".  No change would be made to the registry record
   for 'gan'.

2.2.3.  Script Subtag

   Script subtags are used to indicate the script or writing system
   variations that distinguish the written forms of a language or its
   dialects.  The following rules apply to the script subtags:

   1.  All four-character subtags were defined according to
       [ISO15924]--"Codes for the representation of the names of
       scripts": alpha-4 script codes, or subsequently assigned by the
       ISO 15924 maintenance agency or governing standardization bodies,
       denoting the script or writing system used in conjunction with
       this language.

   2.  Script subtags MUST immediately follow the primary language
       subtag and all extended language subtags and MUST occur before
       any other type of subtag described below.

   3.  The script subtags 'Qaaa' through 'Qabx' are reserved for private
       use in language tags.  These subtags correspond to codes reserved
       by ISO 15924 for private use.  These codes MAY be used for non-
       registered script values.  Please refer to Section 4.5 for more
       information on private use subtags.

   4.  Script subtags MUST NOT be registered using the process in
       Section 3.5 of this document.  Variant subtags MAY be considered
       for registration for that purpose.





Phillips & Davis        Expires February 25, 2008              [Page 12]

Internet-Draft              langtags-registry                August 2007


   5.  There MUST be at most one script subtag in a language tag, and
       the script subtag SHOULD be omitted when it adds no
       distinguishing value to the tag or when the primary language
       subtag's record includes a Suppress-Script field listing the
       applicable script subtag.

   Example: "sr-Latn" represents Serbian written using the Latin script.

2.2.4.  Region Subtag

   Region subtags are used to indicate linguistic variations associated
   with or appropriate to a specific country, territory, or region.
   Typically, a region subtag is used to indicate regional dialects or
   usage, or region-specific spelling conventions.  A region subtag can
   also be used to indicate that content is expressed in a way that is
   appropriate for use throughout a region, for instance, Spanish
   content tailored to be useful throughout Latin America.

   The following rules apply to the region subtags:

   1.  Region subtags MUST follow any language, extended language, or
       script subtags and MUST precede all other 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.

   3.  All three-character subtags consisting of digit (numeric)
       characters following the primary subtag were defined in the IANA
       registry according to the assignments found in UN Standard
       Country or Area Codes for Statistical Use [UN_M.49] or
       assignments subsequently made by the governing standards body.
       Note that not all of the UN M.49 codes are defined in the IANA
       registry.  The following rules define which codes are entered
       into the registry as valid subtags:

       A.  UN numeric codes assigned to 'macro-geographical
           (continental)' or sub-regions MUST be registered in the
           registry.  These codes are not associated with an assigned
           ISO 3166 alpha-2 code and represent supra-national areas,
           usually covering more than one nation, state, province, or
           territory.





Phillips & Davis        Expires February 25, 2008              [Page 13]

Internet-Draft              langtags-registry                August 2007


       B.  UN numeric codes for 'economic groupings' or 'other
           groupings' MUST NOT be registered in the IANA registry and
           MUST NOT be used to form language tags.

       C.  UN numeric codes for countries or areas with ambiguous ISO
           3166 alpha-2 codes, when entered into the registry, MUST be
           defined according to the rules in Section 3.4 and MUST be
           used to form language tags that represent the country or
           region for which they are defined.

       D.  UN numeric codes for countries or areas for which there is an
           associated ISO 3166 alpha-2 code in the registry MUST NOT be
           entered into the registry and MUST NOT be used to form
           language tags.  Note that the ISO 3166-based subtag in the
           registry MUST actually be associated with the UN M.49 code in
           question.

       E.  UN numeric codes and ISO 3166 alpha-2 codes for countries or
           areas listed as eligible for registration in [RFC4645] but
           not presently registered MAY be entered into the IANA
           registry via the process described in Section 3.5.  Once
           registered, these codes MAY be used to form language tags.

       F.  All other UN numeric codes for countries or areas that do not
           have an associated ISO 3166 alpha-2 code MUST NOT be entered
           into the registry and MUST NOT be used to form language tags.
           For more information about these codes, see Section 3.4 .

   4.  Note: The alphanumeric codes in Appendix X of the UN document
       MUST NOT be entered into the registry and MUST NOT be used to
       form language tags.  (At the time this document was created,
       these values matched the ISO 3166 alpha-2 codes.)

   5.  There MUST be at most one region subtag in a language tag and the
       region subtag MAY be omitted, as when it adds no distinguishing
       value to the tag.

   6.  The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are
       reserved for private use in language tags.  These subtags
       correspond to codes reserved by ISO 3166 for private use.  These
       codes MAY be used for private use region subtags (instead of
       using a private use subtag sequence).  Please refer to
       Section 4.5 for more information on private use subtags.

   "de-CH" represents German ('de') as used in Switzerland ('CH').

   "sr-Latn-RS" represents Serbian ('sr') written using Latin script
   ('Latn') as used in Serbia ('RS').



Phillips & Davis        Expires February 25, 2008              [Page 14]

Internet-Draft              langtags-registry                August 2007


   "es-419" represents Spanish ('es') appropriate to the UN-defined
   Latin America and Caribbean region ('419').

2.2.5.  Variant Subtags

   Variant subtags are used to indicate additional, well-recognized
   variations that define a language or its dialects that are not
   covered by other available subtags.  The following rules apply to the
   variant subtags:

   1.  Variant subtags are not associated with any external standard.
       Variant subtags and their meanings are defined by the
       registration process defined in Section 3.5.

   2.  Variant subtags MUST follow all of the other defined subtags, but
       precede any extension or private use subtag sequences.

   3.  More than one variant MAY be used to form the language tag.

   4.  Variant subtags MUST be registered with IANA according to the
       rules in Section 3.5 of this document before being used to form
       language tags.  In order to distinguish variants from other types
       of subtags, registrations MUST meet the following length and
       content restrictions:

       1.  Variant subtags that begin with a letter (a-z, A-Z) MUST be
           at least five characters long.

       2.  Variant subtags that begin with a digit (0-9) MUST be at
           least four characters long.

   Variant subtag records in the language subtag registry MAY include
   one or more 'Prefix' fields.  The 'Prefix' indicates the language tag
   or tags that would make a suitable prefix (with other subtags, as
   appropriate) in forming a language tag with the variant.  That is,
   each of the subtags in the prefix SHOULD appear before the variant.
   For example, the subtag 'nedis' has a Prefix of "sl", making it
   suitable to form language tags such as "sl-nedis" and "sl-IT-nedis",
   but not suitable for use in a tag such as "zh-nedis" or "it-IT-
   nedis".

   "sl-nedis" represents the Natisone or Nadiza dialect of Slovenian.

   "de-CH-1996" represents German as used in Switzerland and as written
   using the spelling reform beginning in the year 1996 C.E.

   Most variants that share a prefix are mutually exclusive.  For
   example, the German orthographic variations '1996' and '1901' SHOULD



Phillips & Davis        Expires February 25, 2008              [Page 15]

Internet-Draft              langtags-registry                August 2007


   NOT be used in the same tag, as they represent the dates of different
   spelling reforms.  A variant that can meaningfully be used in
   combination with another variant SHOULD include a 'Prefix' field in
   its registry record that lists that other variant.  For example, if
   another German variant 'example' were created that made sense to use
   with '1996', then 'example' should include two Prefix fields: "de"
   and "de-1996".

2.2.6.  Extension Subtags

   Extensions provide a mechanism for extending language tags for use in
   various applications.  See Section 3.7.  The following rules apply to
   extensions:

   1.   Extension subtags are separated from the other subtags defined
        in this document by a single-character subtag ("singleton").
        The singleton MUST be one allocated to a registration authority
        via the mechanism described in Section 3.7 and MUST NOT be the
        letter 'x', which is reserved for private use subtag sequences.

   2.   Note: Private use subtag sequences starting with the singleton
        subtag 'x' are described in Section 2.2.7 below.

   3.   An extension MUST follow at least a primary language subtag.
        That is, a language tag cannot begin with an extension.
        Extensions extend language tags, they do not override or replace
        them.  For example, "a-value" is not a well-formed language tag,
        while "de-a-value" is.

   4.   Each singleton subtag MUST appear at most one time in each tag
        (other than as a private use subtag).  That is, singleton
        subtags MUST NOT be repeated.  For example, the tag "en-a-bbb-a-
        ccc" is invalid because the subtag 'a' appears twice.  Note that
        the tag "en-a-bbb-x-a-ccc" is valid because the second
        appearance of the singleton 'a' is in a private use sequence.

   5.   Extension subtags MUST meet all of the requirements for the
        content and format of subtags defined in this document.

   6.   Extension subtags MUST meet whatever requirements are set by the
        document that defines their singleton prefix and whatever
        requirements are provided by the maintaining authority.

   7.   Each extension subtag MUST be from two to eight characters long
        and consist solely of letters or digits, with each subtag
        separated by a single '-'.





Phillips & Davis        Expires February 25, 2008              [Page 16]

Internet-Draft              langtags-registry                August 2007


   8.   Each singleton MUST be followed by at least one extension
        subtag.  For example, the tag "tlh-a-b-foo" is invalid because
        the first singleton 'a' is followed immediately by another
        singleton 'b'.

   9.   Extension subtags MUST follow all language, extended language,
        script, region, and variant subtags in a tag.

   10.  All subtags following the singleton and before another singleton
        are part of the extension.  Example: In the tag "fr-a-Latn", the
        subtag 'Latn' does not represent the script subtag 'Latn'
        defined in the IANA Language Subtag Registry.  Its meaning is
        defined by the extension 'a'.

   11.  In the event that more than one extension appears in a single
        tag, the tag SHOULD be canonicalized as described in
        Section 4.4.

   For example, if the prefix singleton 'r' and the shown subtags were
   defined, then the following tag would be a valid example: "en-Latn-
   GB-boont-r-extended-sequence-x-private"

2.2.7 .  Private Use Subtags

   Private use subtags are used to indicate distinctions in language
   important in a given context by private agreement.  The following
   rules apply to private use subtags:

   1.  Private use subtags are separated from the other subtags defined
       in this document by the reserved single-character subtag 'x'.

   2.  Private use subtags MUST conform to the format and content
       constraints defined in the ABNF for all subtags.

   3.  Private use subtags MUST follow all language, extended language,
       script, region, variant, and extension subtags in the tag.
       Another way of saying this is that all subtags following the
       singleton 'x' MUST be considered private use.  Example: The
       subtag 'US' in the tag "en-x-US" is a private use subtag.

   4.  A tag MAY consist entirely of private use subtags.

   5.  No source is defined for private use subtags.  Use of private use
       subtags is by private agreement only.

   6.  Private use subtags are NOT RECOMMENDED where alternatives exist
       or for general interchange.  See Section 4.5 for more information
       on private use subtag choice.



Phillips & Davis        Expires February 25, 2008              [Page 17]

Internet-Draft              langtags-registry                August 2007


   For example: Users who wished to utilize codes from the Ethnologue
   publication of SIL International for language identification might
   agree to exchange tags such as "az-Arab-x-AZE-derbend".  This example
   contains two private use subtags.  The first is 'AZE' and the second
   is 'derbend'.

2.2.8.  Grandfathered Registrations

   Prior to RFC 4646, whole language tags were registered according to
   the rules in RFC 1766 and/or RFC 3066.  These registered tags
   maintain their validity.  Of those tags, those that were made
   obsolete or redundant by the advent of RFC 4646, by this document, or
   by subsequent registration of subtags are maintained in the registry
   in records as "redundant" records.  Those tags that do not match the
   'langtag' production in the ABNF in this document or that contain
   subtags that do not individually appear in the registry are
   maintained in the registry in records of the "grandfathered" type.

   Grandfathered tags contain one or more subtags that are not defined
   in the Language Subtag Registry (see Section 3).  Redundant tags
   consist entirely of subtags defined above and whose independent
   registration was superseded by [RFC4646].  For more information see
   Section 3.8.

   Some grandfathered tags are "regular" in that they match the
   'langtag' production in Figure 1.  In some cases, these tags could
   become redundant if their (current unregistered) subtags were to be
   registered (as variants, for example).  In other cases, although the
   subtags match the language tag pattern, the meaning assigned to the
   various subtags is prohibited by rules elsewhere in this document.
   Those tags can never become redundant.

   The remaining grandfathered tags are "irregular" and do not match the
   'langtag' production.  These are listed in the 'irregular' production
   in Figure 1.  These grandfathered tags can never become redundant.
   Many of these tags have been superseded by other registrations: their
   record contains a Preferred-Value field that really ought to be used
   to form language tags representing that value.

2.2.9.  Classes of Conformance

   Implementations sometimes need to describe their capabilities with
   regard to the rules and practices described in this document.  Tags
   can be checked or verified in a number of ways, but two particular
   classes of tag conformance are formally defined here.

   A tag is considered "well-formed" if it conforms to the ABNF
   (Section 2.1).  Note that irregular grandfathered tags are now listed



Phillips & Davis        Expires February 25, 2008              [Page 18]

Internet-Draft              langtags-registry                August 2007


   in the 'irregular' production.

   A tag is considered "valid" if it well-formed and it also satisfies
   these conditions:

   o  The tag is either a grandfathered tag, or all of its language,
      extended language, script, region, and variant subtags appear in
      the IANA language subtag registry as of the particular registry
      date.

   o  There are no duplicate singleton (extension) subtags and no
      duplicate variant subtags.

   o  For each subtag that has a 'Prefix' field in the registry, the
      Prefix matches the language tag using Extended Filtering
      [RFC4647].  That is, each subtag in the Prefix is present in the
      tag and in the same order.  Furthermore, all of the Prefix's
      subtags MUST appear before the subtag.  For example, the Prefix
      "zh-TW" matches the tag "zh-Hant-TW".

   Note that a tag's validity depends on the date of the registry used
   to validate the tag.  A more-recent copy of the registry might
   contain a subtag that an older version does not.

   A tag is considered "valid" for a given extension (Section 3.7) (as
   of a particular version, revision, and date) if it meets the criteria
   for "valid" above and also satisfies this condition:

      Each subtag used in the extension part of the tag is valid
      according to the extension.





















Phillips & Davis        Expires February 25, 2008              [Page 19]

Internet-Draft              langtags-registry                August 2007


3.  Registry Format and Maintenance

   This section defines the Language Subtag Registry and the maintenance
   and update procedures associated with it, as well as a registry for
   extensions to language tags (Section 3.7).

   The Language Subtag Registry contains a comprehensive list of all of
   the subtags valid in language tags.  This allows implementers a
   straightforward and reliable way to validate language tags.  The
   Language Subtag Registry will be maintained so that, except for
   extension subtags, it is possible to validate all of the subtags that
   appear in a language tag under the provisions of this document or its
   revisions or successors.  In addition, the meaning of the various
   subtags will be unambiguous and stable over time.  (The meaning of
   private use subtags, of course, is not defined by the IANA registry.)

3.1.  Format of the IANA Language Subtag Registry

   The IANA Language Subtag Registry ("the registry") is a machine-
   readable file in the format described in this section, plus copies of
   the registration forms approved in accordance with the process
   described in Section 3.5.  The existing registration forms for
   grandfathered and redundant tags taken from RFC 3066 will be
   maintained as part of the obsolete RFC 3066 registry.  The remaining
   set of subtags created by either [RFC4645] or [registry-update] will
   not have registration forms created for them.

3.1.1.  File Format

   The registry consists of a series of records stored in the record-jar
   format (described in [record-jar]).  Each record, in turn, consists
   of a series of fields that describe the various subtags and tags.
   The registry is a Unicode [Unicode] text file, using the UTF-8
   [RFC3629] character encoding.

   Each field can be considered a single, logical line of Unicode
   [Unicode] characters, comprising a field-name and a field-body
   separated by a COLON character (%x3A).  Each field is terminated by
   the newline sequence CRLF.  The text in each field MUST be in Unicode
   Normalization Form C (NFC).

   A collection of fields forms a 'record'.  Records are separated by
   lines containing only the sequence "%%" (%x25.25).

   Although fields are logically a single line of text, each line of
   text in the file format is limited to 72 bytes in length.  To
   accommodate this, the field-body can be split into a multiple-line
   representation; this is called "folding".  Folding is always done on



Phillips & Davis        Expires February 25, 2008              [Page 20]

Internet-Draft              langtags-registry                August 2007


   Unicode code point boundaries (never in the middle of a multibyte
   UTF-8 sequence) and MUST NOT occur just prior to a combining mark.

   Although the file format uses the UTF-8 encoding, unless otherwise
   indicated, fields are restricted to the printable characters from the
   US-ASCII [ISO646] repertoire.

   The format of the registry is described by the following ABNF (per
   [RFC4234]):

   registry   = record *("%%" CRLF record)
   record     = 1*( field-name *SP ":" *SP field-body CRLF )
   field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
   field-body = *([[*SP CRLF] 1*SP] 1*CHARS)
   CHARS      = (%x21-10FFFF)      ; Unicode code points

                      Figure 2: Registry Format ABNF

   The sequence '..' (%x2E.2E) in a field-body denotes a range of
   values.  Such a range represents all subtags of the same length that
   are in alphabetic or numeric order within that range, including the
   values explicitly mentioned.  For example 'a..c' denotes the values
   'a', 'b', and 'c' and '11..13' denotes the values '11', '12', and
   '13'.

   All fields whose field-body contains a date value use the "full-date"
   format specified in [RFC3339].  For example: "2004-06-28" represents
   June 28, 2004, in the Gregorian calendar.

3.1.2.  Record Definitions

   There are three types of records in the registry: "File-Date",
   "Subtag", and "Tag" records.

   The first record in the registry is a "File-Date" record.  This
   record contains the single field whose field-name is "File-Date" (see
   Figure 2).  The field-body of this record contains the last
   modification date of this copy of the registry, making it possible to
   compare different versions of the registry.  The registry on the IANA
   website is the most current.  Versions with an older date than that
   one are not up-to-date.

   File-Date: 2004-06-28
   %%

                 Figure 3: Example of the File-Date Record

   Subsequent records represent either subtags or tags in the registry.



Phillips & Davis        Expires February 25, 2008              [Page 21]

Internet-Draft              langtags-registry                August 2007


   "Subtag" records contain a field with a field-name of "Subtag",
   while, unsurprisingly, "Tag" records contain a field with a field-
   name of "Tag".  Each of the fields in each record MUST occur no more
   than once, unless otherwise noted below.  Each record MUST contain
   the following fields:

   o  'Type'

      *  Type's field-body MUST consist of one of the following strings:
         "language", "extlang", "script", "region", "variant",
         "grandfathered", and "redundant" and denotes the type of tag or
         subtag.

   o  Either 'Subtag' or 'Tag'

      *  Subtag's field-body contains the subtag being defined.  This
         field MUST only appear in records of whose 'Type' has one of
         these values: "language", "extlang", "script", "region", or
         "variant".

      *  Tag's field-body contains a complete language tag.  This field
         MUST only appear in records whose 'Type' has one of these
         values: "grandfathered" or "redundant".  Note that the field-
         body will always follow the 'grandfathered' production in the
         ABNF in Section 2.1

   o  Description

      *  Description's field-body contains a non-normative description
         of the subtag or tag.

   o  Added

      *  Added's field-body contains the date the record was added to
         the registry.

   Each record MAY also contain the following fields:

   o  Preferred-Value

      *  For fields of type 'script', 'region', and 'variant',
         'Preferred-Value' contains the subtag of the same 'Type' that
         is preferred for forming the language tag.

      *  For fields of type 'language' and 'extlang', 'Preferred-Value'
         contains the language production (see Figure 1) that is
         preferred when forming the language tag.  This can be simply a
         'language' subtag, or it can be a 'language' subtag followed by



Phillips & Davis        Expires February 25, 2008              [Page 22]

Internet-Draft              langtags-registry                August 2007


         an extended language sequence.

      *  For fields of type 'grandfathered' and 'redundant', a canonical
         mapping to a complete language tag.

   o  Deprecated

      *  Deprecated's field-body contains the date the record was
         deprecated.

   o  Prefix

      *  Prefix's field-body contains a language tag with which this
         subtag MAY be used to form a new language tag, perhaps with
         other subtags as well.  The Prefix's subtags appear before the
         subtag.  This field MUST only appear in records whose 'Type'
         field-body is 'variant' or 'extlang'.  For example, the
         'Prefix' for the variant 'nedis' is 'sl', meaning that the tags
         "sl-nedis" and "sl-IT-nedis" might be appropriate while the tag
         "is-nedis" is not.

   o  Comments

      *  Comments contains additional information about the subtag, as
         deemed appropriate for understanding the registry and
         implementing language tags using the subtag or tag.

   o  Suppress-Script

      *  Suppress-Script contains a script subtag that SHOULD NOT be
         used to form language tags with the associated primary language
         subtag.  This field MUST only appear in records whose 'Type'
         field-body is 'language'.  See Section 4.1.

   o  Macrolanguage

      *  Macrolanguage contains a primary or extended language subtag
         defined by ISO 639 as a "macrolanguage" that encompasses this
         language subtag.  This field MUST only appear in records whose
         'Type' field-body is 'language' or 'extlang'.

   Future versions of this document might add additional fields to the
   registry, so implementations SHOULD ignore fields found in the
   registry that are not defined in this document.







Phillips & Davis        Expires February 25, 2008              [Page 23]

Internet-Draft              langtags-registry                August 2007


3.1.3.  Subtag and Tag Fields

   The 'Subtag' field MUST use lowercase letters to form the subtag,
   with two exceptions.  Subtags whose 'Type' field is 'script' (in
   other words, subtags defined by ISO 15924) MUST use titlecase.
   Subtags whose 'Type' field is 'region' (in other words, the non-
   numeric region subtags defined by ISO 3166) MUST use uppercase.
   These exceptions mirror the use of case in the underlying standards.

   Each subtag in the tags contained in a 'Tag' field MUST be formatted
   using the rules in the preceeding paragraph.  That is, all subtags
   are lowercase except for subtags that represent script or region
   codes.

3.1.4.  Description Field

   The field 'Description' contains a description of the tag or subtag
   in the record.  The 'Description' field MAY appear more than once per
   record, that is, there can be multiple descriptions for a given
   record.  The 'Description' field MAY include the full range of
   Unicode characters.  At least one of the 'Description' fields MUST be
   written or transcribed into the Latin script; additional
   'Description' fields MAY also include a description in a non-Latin
   script.  Each 'Description' field MUST be unique, both within the
   record in which it appears and for the collection of records of the
   same type.  Moreover, formatting variations of the same description
   MUST NOT occur in that specific record or in any other record of the
   same type.  For example, while the ISO 639-1 code 'fy' contains both
   the descriptions "Western Frisian" and "Frisian, Western", only one
   of these descriptions appears in the registry.

   The 'Description' field is used for identification purposes and
   SHOULD NOT be taken to represent the actual native name of the
   language or variation or to be in any particular language.

   For records taken from a source standard (such as ISO 639 or ISO
   3166), the 'Description' value(s) SHOULD also be taken from the
   source standard.  Multiple descriptions in the source standard MUST
   be split into separate 'Description' fields.  The source standard's
   descriptions MAY be edited, either prior to insertion or via the
   registration process.  For fields of type 'language' or 'extlang',
   the first 'Description' field appearing in the Registry corresponds
   to the Reference Name assigned by ISO 639-3.  This helps facilitate
   cross-referencing between ISO 639 and the registry.

   When creating or updating a record due to the action of one of the
   source standards, the Language Subtag Reviewer SHOULD remove
   duplicate or redundant descriptions and MAY edit descriptions to



Phillips & Davis        Expires February 25, 2008              [Page 24]

Internet-Draft              langtags-registry                August 2007


   correct irregularities in formatting (such as misspellings,
   inappropriate apostrophes or other punctuation, or excessive or
   missing spaces) prior to submitting the proposed record to the ietf-
   languages list.

   Note: Descriptions in registry entries that correspond to ISO 639,
   ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate
   the meaning of that identifier as defined in the source standard at
   the time it was added to the registry.  The description does not
   replace the content of the source standard itself.  The descriptions
   are not intended to be the English localized names for the subtags.
   Localization or translation of language tag and subtag descriptions
   is out of scope of this document.

3.1.5.  Deprecated Field

   The field 'Deprecated' MAY be added to any record via the maintenance
   process described in Section 3.3 or via the registration process
   described in Section 3.5.  Usually, the addition of a 'Deprecated'
   field is due to the action of one of the standards bodies, such as
   ISO 3166, withdrawing a code.  In some historical cases, it might not
   have been possible to reconstruct the original deprecation date.  For
   these cases, an approximate date appears in the registry.  Although
   valid in language tags, subtags and tags with a 'Deprecated' field
   are deprecated and validating processors SHOULD NOT generate these
   subtags.  Note that a record that contains a 'Deprecated' field and
   no corresponding 'Preferred-Value' field has no replacement mapping.

3.1.6.  Preferred-Value Field

   The field 'Preferred-Value' contains a mapping between the record in
   which it appears and another tag or subtag.  The value in this field
   is strongly RECOMMENDED as the best choice to represent the value of
   this record when selecting a language tag.  These values form three
   groups:

   1.  ISO 639 language codes that were later withdrawn in favor of
       other codes.  These values are mostly a historical curiosity.

   2.  ISO 3166 region codes that have been withdrawn in favor of a new
       code.  This sometimes happens when a country changes its name or
       administration in such a way that warrants a new region code.

   3.  Grandfathered or redundant tags from RFC 3066.  In many cases,
       these tags have become obsolete because the values they represent
       were later encoded by ISO 639.

   Records that contain a 'Preferred-Value' field MUST also have a



Phillips & Davis        Expires February 25, 2008              [Page 25]

Internet-Draft              langtags-registry                August 2007


   'Deprecated' field.  This field contains a date of deprecation.
   Thus, a language tag processor can use the registry to construct the
   valid, non-deprecated set of subtags for a given date.  In addition,
   for any given tag, a processor can construct the set of valid
   language tags that correspond to that tag for all dates up to the
   date of the registry.  The ability to do these mappings MAY be
   beneficial to applications that are matching, selecting, for
   filtering content based on its language tags.

   Note that 'Preferred-Value' mappings in records of type 'region'
   sometimes do not represent exactly the same meaning as the original
   value.  There are many reasons for a country code to be changed, and
   the effect this has on the formation of language tags will depend on
   the nature of the change in question.

   In particular, the 'Preferred-Value' field does not imply retagging
   content that uses the affected subtag.

   The field 'Preferred-Value' MUST NOT be modified once created in the
   registry.  The field MAY be added to records according to the rules
   in Section 3.3.

   The 'Preferred-Value' field in records of type "grandfathered" and
   "redundant" contains whole language tags that are strongly
   RECOMMENDED for use in place of the record's value.  In many cases,
   the mappings were created by deprecation of the tags during the
   period before this document was adopted.  For example, the tag "no-
   nyn" was deprecated in favor of the ISO 639-1-defined language code
   'nn'.

3.1.7.  Prefix Field

   The 'Prefix' field contains an extended language range whose subtags
   are appropriate to use with this subtag: each of the subtags in one
   of the subtag's Prefix fields MUST appear before the variant in a
   valid tag.  For example, the variant subtag '1996' has a 'Prefix'
   field of "de".  This means that tags starting with the sequence "de-"
   are appropriate with this subtag, so "de-Latg-1996" and "de-CH-1996"
   are both acceptable, while the tag "fr-1996" is an inappropriate
   choice.

   The field of type 'Prefix' MUST NOT be removed from any record.  The
   field-body for this type of field MAY be modified, but only if the
   modification broadens the meaning of the subtag.  That is, the field-
   body can be replaced only by a prefix a prefix of itself.  For
   example, the Prefix "be-Latn" (Belarusian, Latin script) could be
   replaced by the Prefix "be" (Belarusian) but not by the Prefix "ru-
   Latn" (Russian, Latin script).



Phillips & Davis        Expires February 25, 2008              [Page 26]

Internet-Draft              langtags-registry                August 2007


   Records of type 'variant' MAY have more than one field of type
   'Prefix'.  Additional fields of this type MAY be added to a 'variant'
   record via the registration process.

   The field-body of the 'Prefix' field MUST NOT conflict with any
   'Prefix' already registered for a given record.  Such a conflict
   would occur when when no valid tag could be constructed that would
   contain the prefix, such as when when two subtags each have a
   'Prefix' that contains the other subtag.  For example, suppose that
   the subtag 'avariant' has the prefix "es-bvariant".  Then the subtag
   'bvariant' cannot given the prefix 'avariant', for that would require
   a tag of the form "es-avariant-bvariant-avariant", which would not be
   valid.

   Records of type 'extlang' MUST have _exactly_ one 'Prefix' field.

3.1.8.  Suppress-Script Field

   The field 'Suppress-Script' contains a script subtag (whose record
   appears in the registry).  The field 'Suppress-Script' MUST only
   appear in records whose 'Type' field-body is 'language'.  This field
   MUST NOT appear more than one time in a record.  This field indicates
   a script used to write the overwhelming majority of documents for the
   given language.  This script code therefore adds no distinguishing
   information to a language tag.  This helps ensure greater
   compatibility between the language tags generated according to the
   rules in this document and language tags and tag processors or
   consumers based on RFC 3066 by indicating that the script subtag
   SHOULD NOT be used for most documents in that language.  For example,
   virtually all Icelandic documents are written in the Latin script,
   making the subtag 'Latn' redundant in the tag "is-Latn".

   Many language subtag records do not have a Suppress-Script field.
   The lack of a Suppress-Script might indicate that the language is
   customarily written in more than one script or that the language is
   not customarily written at all.  It might also mean that sufficient
   information was not available when the record was created and thus
   remains a candidate for future registration.

3.1.9.  Macrolanguage Field

   The Macrolanguage field contains a primary or extended language
   subtag that encompasses this subtag's language.  That is, the
   language subtag whose record this field appears in is sometimes
   considered to be a sub-language of the Macrolanguage.  Macrolanguage
   values are defined by ISO 639-3 and the exact nature of the
   relationship between the encompassed and encompassing languages
   varies on a case-by-case basis.



Phillips & Davis        Expires February 25, 2008              [Page 27]

Internet-Draft              langtags-registry                August 2007


   This field can be useful to applications or users when selecting
   language tags or as additional metadata useful in matching.  The
   Macrolanguage field can only occur in records of type 'language' or
   'extlang'.  Only values assigned by ISO 639-3 will be considered for
   inclusion.  Macrolanguage fields MAY be added or removed via the
   normal registration process whenever ISO 639-3 defines new values.
   Macrolanguages are informational, and MAY be removed or changed if
   ISO 639-3 changes the values.

   For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn'
   (Norwegian Nynorsk) each have a Macrolanguage entry of 'no'
   (Norwegian).  For more information see Section 4.1.

3.1.10.  Comments Field

   The field 'Comments' conveys additional information about the record
   and MAY appear more than once per record.  The field-body MAY include
   the full range of Unicode characters and is not restricted to any
   particular script.  This field MAY be inserted or changed via the
   registration process and no guarantee of stability is provided.  The
   content of this field is not restricted, except by the need to
   register the information, the suitability of the request, and by
   reasonable practical size limitations.

3.2.  Language Subtag Reviewer

   The Language Subtag Reviewer moderates the ietf-languages mailing
   list, responds to requests for registration, and performs the other
   registry maintenance duties described in Section 3.3.  Only the
   Language Subtag Reviewer is permitted to request IANA to change,
   update, or add records to the Language Subtag Registry.  The Language
   Subtag Reviewer MAY delegate list moderation and other clerical
   duties as needed.

   The Language Subtag Reviewer is appointed by the IESG for an
   indefinite term, subject to removal or replacement at the IESG's
   discretion.  The IESG will solicit nominees for the position (upon
   adoption of this document or upon a vacancy) and then solicit
   feedback on the nominees' qualifications.  Qualified candidates
   should be familiar with BCP 47 and its requirements; be willing to
   fairly, responsively, and judiciously administer the registration
   process; and be suitably informed about the issues of language
   identification so that they can draw upon and assess the claim and
   contributions of language experts and subtag requesters.

   The subsequent performance or decisions of the Language Subtag
   Reviewer MAY be appealed to the IESG under the same rules as other
   IETF decisions (see [RFC2026]).  The IESG can reverse or overturn the



Phillips & Davis        Expires February 25, 2008              [Page 28]

Internet-Draft              langtags-registry                August 2007


   decision of the Language Subtag Reviewer, provide guidance, or take
   other appropriate actions.

3.3.  Maintenance of the Registry

   Maintenance of the registry requires that as codes are assigned or
   withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language
   Subtag Reviewer MUST evaluate each change and determine the
   appropriate course of action according to the rules in this document.
   Such updates follow the registration process described in
   Section 3.5.  Usually the Language Subtag Reviewer will start the
   process for the new or updated record by filling in the registration
   form and submitting it.  If a change to one of these standards takes
   place and the Language Subtag Reviewer does not do this in a timely
   manner, then any interested party MAY submit the form.  Thereafter
   the registration process continues normally.

   The Language Subtag Reviewer MUST ensure that new subtags meet the
   requirements elsewhere in this document (and most especially in
   Section 3.4) or submit an appropriate registration form for an
   alternate subtag as described in that section.  Each individual
   subtag affected by a change MUST be sent to the ietf-languages list
   with its own registration form and in a separate message.

3.4.  Stability of IANA Registry Entries

   The stability of entries and their meaning in the registry is
   critical to the long-term stability of language tags.  The rules in
   this section guarantee that a specific language tag's meaning is
   stable over time and will not change.

   These rules specifically deal with how changes to codes (including
   withdrawal and deprecation of codes) maintained by ISO 639, ISO
   15924, ISO 3166, and UN M.49 are reflected in the IANA Language
   Subtag Registry.  Assignments to the IANA Language Subtag Registry
   MUST follow the following stability rules:

   1.   Values in the fields 'Type', 'Subtag', 'Tag', 'Added',
        'Deprecated' and 'Preferred-Value' MUST NOT be changed and are
        guaranteed to be stable over time.

   2.   Values in the 'Description' field MUST NOT be changed in a way
        that would invalidate previously-existing tags.  They MAY be
        broadened somewhat in scope, changed to add information, or
        adapted to the most common modern usage.  For example, countries
        occasionally change their official names; a historical example
        of this would be "Upper Volta" changing to "Burkina Faso".




Phillips & Davis        Expires February 25, 2008              [Page 29]

Internet-Draft              langtags-registry                August 2007


   3.   Values in the field 'Prefix' MAY be added to records of type
        'variant' via the registration process.  If a prefix is added to
        a variant record, 'Comment' fields SHOULD be used to explain
        different usages with the various prefixes.

   4.   Values in the field 'Prefix' in records of type 'variant' MAY be
        modified, so long as the modifications broaden the set of
        prefixes.  That is, a prefix MAY be replaced by one of its own
        prefixes.  For example, the prefix "en-US" could be replaced by
        "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont".
        If one of those prefixes were needed, a new Prefix SHOULD be
        registered.

   5.   Values in the field 'Prefix' in records of type 'extlang' MUST
        NOT be modified.

   6.   Values in the field 'Prefix' MUST NOT be removed.

   7.   The field 'Comments' MAY be added, changed, modified, or removed
        via the registration process or any of the processes or
        considerations described in this section.

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

   9.   The field 'Macrolanguage' MAY be added or removed via the
        registration process, but only in response to changes made by
        ISO 639.  The Macrolanguage field appears whenever a language
        has a corresponding Macrolanguage in ISO 639.  That is, the
        macrolanguage fields in the registry exactly match those of ISO
        639.  No other macrolanguage mappings will be considered for
        registration.

   10.  Codes assigned by ISO 639-1 that do not conflict with existing
        two-letter primary language subtags and which have no
        corresponding three-letter primary or extended language subtags
        defined in the registry are entered into the IANA registry as
        new records of type 'language'.

   11.  Codes assigned by ISO 639-2 that do not conflict with existing
        three-letter primary or extended language subtags are entered
        into the IANA registry as new records of type 'language'.

   12.  Codes assigned by ISO 639-3 that do not conflict with existing
        three-letter primary or extended language subtags are entered
        into the IANA registry as new records.





Phillips & Davis        Expires February 25, 2008              [Page 30]

Internet-Draft              langtags-registry                August 2007


        1.  Codes that have a defined "macrolanguage" mapping at the
            time of their registration MUST be entered into the registry
            as records of type 'extlang' with a 'Prefix' field
            containing the appropriate prefix tag.  They MUST also
            include a "Macrolanguage" field in their record.

        2.  Codes that represent sign languages MUST be entered into the
            registry as record of type 'extlang' with a 'Prefix' field
            that matches the Basic Language Range "sgn" (see Section
            3.3.1 "Basic Filtering" in [RFC4647]).

        3.  All other codes MUST be entered into the registry as records
            of type 'language'.

   13.  A record of type 'language' or 'extlang' MUST NOT be registered
        if there exists a record of either type with the same subtag
        value.  For example, if an 'extlang' subtag 'foo' exists in the
        registry, all attempts to register a 'language' subtag 'foo'
        will be rejected.

   14.  Codes assigned by 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.

   15.  Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are
        withdrawn by their respective maintenance or registration
        authority remain valid in language tags.  A 'Deprecated' field
        containing the date of withdrawal MUST be added to the record.
        If a new record of the same type is added that represents a
        replacement value, then a 'Preferred-Value' field MAY also be
        added.  The registration process MAY be used to add comments
        about the withdrawal of the code by the respective standard.

        Example  The region code 'TL' was assigned to the country
           'Timor-Leste', replacing the code 'TP' (which was assigned to
           'East Timor' when it was under administration by Portugal).
           The subtag 'TP' remains valid in language tags, but its
           record contains the a 'Preferred-Value' of 'TL' and its field
           'Deprecated' contains the date the new code was assigned
           ('2004-07-06').

   16.  Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict
        with existing subtags of the associated type, including subtags
        that are deprecated, MUST NOT be entered into the registry.  The
        following additional considerations apply to subtag values that
        are reassigned:




Phillips & Davis        Expires February 25, 2008              [Page 31]

Internet-Draft              langtags-registry                August 2007


        A.  For ISO 639 codes, if the newly assigned code's meaning is
            not represented by a subtag in the IANA registry, the
            Language Subtag Reviewer, as described in Section 3.5, SHALL
            prepare a proposal for entering in the IANA registry as soon
            as practical a registered language subtag as an alternate
            value for the new code.  The form of the registered language
            subtag will be at the discretion of the Language Subtag
            Reviewer and MUST conform to other restrictions on language
            subtags in this document.

        B.  For all subtags whose meaning is derived from an external
            standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN
            M.49), if a new meaning is assigned to an existing code and
            the new meaning broadens the meaning of that code, then the
            meaning for the associated subtag MAY be changed to match.
            The meaning of a subtag MUST NOT be narrowed, however, as
            this can result in an unknown proportion of the existing
            uses of a subtag becoming invalid.  Note: ISO 639
            maintenance agency/registration authority (MA/RA) has
            adopted a similar stability policy.

        C.  For ISO 15924 codes, if the newly assigned code's meaning is
            not represented by a subtag in the IANA registry, the
            Language Subtag Reviewer, as described in Section 3.5, SHALL
            prepare a proposal for entering in the IANA registry as soon
            as practical a registered variant subtag as an alternate
            value for the new code.  The form of the registered variant
            subtag will be at the discretion of the Language Subtag
            Reviewer and MUST conform to other restrictions on variant
            subtags in this document.

        D.  For ISO 3166 codes, if the newly assigned code's meaning is
            associated with the same UN M.49 code as another 'region'
            subtag, then the existing region subtag remains as the
            preferred value for that region and no new entry is created.
            A comment MAY be added to the existing region subtag
            indicating the relationship to the new ISO 3166 code.

        E.  For ISO 3166 codes, if the newly assigned code's meaning is
            associated with a UN M.49 code that is not represented by an
            existing region subtag, then the Language Subtag Reviewer,
            as described in Section 3.5, SHALL prepare a proposal for
            entering the appropriate UN M.49 country code as an entry in
            the IANA registry.

        F.  For ISO 3166 codes, if there is no associated UN numeric
            code, then the Language Subtag Reviewer SHALL petition the
            UN to create one.  If there is no response from the UN



Phillips & Davis        Expires February 25, 2008              [Page 32]

Internet-Draft              langtags-registry                August 2007


            within ninety days of the request being sent, the Language
            Subtag Reviewer SHALL prepare a proposal for entering in the
            IANA registry as soon as practical a registered variant
            subtag as an alternate value for the new code.  The form of
            the registered variant subtag will be at the discretion of
            the Language Subtag Reviewer and MUST conform to other
            restrictions on variant subtags in this document.  This
            situation is very unlikely to ever occur.

   17.  UN M.49 has codes for both countries and areas (such as '276'
        for Germany) and geographical regions and sub-regions (such as
        '150' for Europe).  UN M.49 country or area codes for which
        there is no corresponding ISO 3166 code SHOULD NOT be
        registered, except as a surrogate for an ISO 3166 code that is
        blocked from registration by an existing subtag.  If such a code
        becomes necessary, then the registration authority for ISO 3166
        SHOULD first be petitioned to assign a code to the region.  If
        the petition for a code assignment by ISO 3166 is refused or not
        acted on in a timely manner, the registration process described
        in Section 3.5 MAY then be used to register the corresponding UN
        M.49 code.  This way, UN M.49 codes remain available as the
        value of last resort in cases where ISO 3166 reassigns a
        deprecated value in the registry.

   18.  Stability provisions apply to grandfathered tags with this
        exception: should it be possible to compose one of the
        grandfathered tags from registered subtags, then the field
        'Type' in that record is changed from 'grandfathered' to
        'redundant'.  Note that this will not affect language tags that
        match the grandfathered tag, since these tags will now match
        valid generative subtag sequences.  For example, this document
        caused the ISO 639-3 code 'gan', used in the redundant tag "zh-
        gan", to be registered as an extended language subtag.  The
        formerly-grandfathered tag "zh-gan" became a redundant tag as a
        result (but existing content or implementations that use "zh-
        gan" remain valid).

   Note: The redundant and grandfathered entries together are the
   complete list of tags registered under [RFC3066].  The redundant tags
   are those that can now be formed using the subtags defined in the
   registry together with the rules of Section 2.2.  The grandfathered
   entries include those that can never be legal under those same
   provisions plus those tags that contain subtags not yet registered
   or, perhaps, inappropriate for registration.

   The set of redundant and grandfathered tags is permanent and stable:
   new entries in this section MUST NOT be added and existing entries
   MUST NOT be removed.  Records of type 'grandfathered' MAY have their



Phillips & Davis        Expires February 25, 2008              [Page 33]

Internet-Draft              langtags-registry                August 2007


   type converted to 'redundant'; see item 12 in Section 3.6 for more
   information.  The decision-making process about which tags were
   initially grandfathered and which were made redundant is described in
   [RFC4645].

   RFC 3066 tags that were deprecated prior to the adoption of [RFC4646]
   are part of the list of grandfathered tags, and their component
   subtags were not included as registered variants (although they
   remain eligible for registration).  For example, the tag "art-lojban"
   was deprecated in favor of the language subtag 'jbo'.

3.5.  Registration Procedure for Subtags

   The procedure given here MUST be used by anyone who wants to use a
   subtag not currently in the IANA Language Subtag Registry.

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

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

   Registering a new subtag or requesting modifications to an existing
   tag or subtag starts with the requester filling out the registration
   form reproduced below.  Note that each response is not limited in
   size so that the request can adequately describe the registration.
   The fields in the "Record Requested" section SHOULD follow the
   requirements in Section 3.1.
















Phillips & Davis        Expires February 25, 2008              [Page 34]

Internet-Draft              langtags-registry                August 2007


   LANGUAGE SUBTAG REGISTRATION FORM
   1. Name of requester:
   2. E-mail address of requester:
   3. Record Requested:

      Type:
      Subtag:
      Description:
      Prefix:
      Preferred-Value:
      Deprecated:
      Suppress-Script:
      Macrolanguage:
      Comments:

   4. Intended meaning of the subtag:
   5. Reference to published description
      of the language (book or article):
   6. Any other relevant information:

              Figure 4: The Language Subtag Registration Form

   Examples of completed registration forms can be found in Appendix C
   or online at http://www.iana.org/assignments/lang-subtags-templates/.

   The subtag registration form MUST be sent to
   <ietf-languages@iana.org> for a two-week review period before it can
   be submitted to IANA.  If modifications are made to the request
   during the course of the registration process (such as corrections to
   meet the requirements in Section 3.1) the modified form MUST also be
   sent to <ietf-languages@iana.org> at least one week prior to
   submission to IANA.

   Whenever an entry is created or modified in the registry, the 'File-
   Date' record at the start of the registry is updated to reflect the
   most recent modification date in the [RFC3339] "full-date" format.

   Before forwarding a new registration to IANA, the Language Subtag
   Reviewer MUST ensure that values in the 'Subtag' field match case
   according to the description in Section 3.1.

   The ietf-languages list is an open list and can be joined by sending
   a request to < ietf-languages-request@iana.org>.  The list can be
   hosted by IANA or by any third party at the request of IESG.

   Some fields in both the registration form as well as the registry
   record itself permit the use of non-ASCII characters.  Registration
   requests SHOULD use the UTF-8 encoding for consistency and clarity.



Phillips & Davis        Expires February 25, 2008              [Page 35]

Internet-Draft              langtags-registry                August 2007


   However, since some mail clients do not support this encoding, other
   encodings MAY be used for the registration request.  The Language
   Subtag Reviewer is responsible for ensuring that the proper Unicode
   characters appear in both the archived request form and the registry
   record.  In the case of a transcription or encoding error by IANA,
   the Language Subtag Reviewer will request that the registry be
   repaired, providing any necessary information to assist IANA.

   Variant subtags are usually registered for use with a particular
   range of language tags.  For example, the subtag 'rozaj' is intended
   for use with language tags that start with the primary language
   subtag "sl", since Resian is a dialect of Slovenian.  Thus, the
   subtag 'rozaj' would be appropriate in tags such as "sl-Latn-rozaj"
   or "sl-IT-rozaj".  This information is stored in the 'Prefix' field
   in the registry.  Variant registration requests SHOULD include at
   least one 'Prefix' field in the registration form.

   Extended language subtags MUST include exactly one 'Prefix' field.

   The 'Prefix' field for a given registered subtag exists in the IANA
   registry as a guide to usage.  Additional prefixes MAY be added by
   filing an additional registration form.  In that form, the "Any other
   relevant information:" field MUST indicate that it is the addition of
   a prefix.

   Requests to add a prefix to a variant subtag that imply a different
   semantic meaning will probably be rejected.  For example, a request
   to add the prefix "de" to the subtag 'nedis' so that the tag "de-
   nedis" represented some German dialect would be rejected.  The
   'nedis' subtag represents a particular Slovenian dialect and the
   additional registration would change the semantic meaning assigned to
   the subtag.  A separate subtag SHOULD be proposed instead.

   The 'Description' field MUST contain a description of the tag being
   registered written or transcribed into the Latin script; it MAY also
   include a description in a non-Latin script.  The 'Description' field
   is used for identification purposes and doesn't necessarily represent
   the actual native name of the language or variation or to be in any
   particular language.

   While the 'Description' field itself is not guaranteed to be stable
   and errata corrections MAY be undertaken from time to time, attempts
   to provide translations or transcriptions of entries in the registry
   itself will probably be frowned upon by the community or rejected
   outright, as changes of this nature have an impact on the provisions
   in Section 3.4.

   When the two-week period has passed, the Language Subtag Reviewer



Phillips & Davis        Expires February 25, 2008              [Page 36]

Internet-Draft              langtags-registry                August 2007


   MUST take one of the following actions:

   o  Explicitly accept the request and forward the form containing the
      record to be inserted or modified to iana@iana.org according to
      the procedure described in Section 3.3.

   o  Explicitly reject the request because of significant objections
      raised on the list or due to problems with constraints in this
      document (which MUST be explicitly cited).

   o  Extend the review period by granting an additional two-week
      increment to permit further discussion.  After each two-week
      increment, the Language Subtag Reviewer MUST indicate on the list
      whether the registration has been accepted, rejected, or extended.

   Note that the Language Subtag Reviewer MAY raise objections on the
   list if he or she so desires.  The important thing is that the
   objection MUST be made publicly.

   Sometimes the request needs to be modified as a result of discussion
   during the review period or due to requirements in this document.
   The applicant, Language Subtag Reviewer, or others are free to submit
   a modified version of the completed registration form, which will be
   considered in lieu of the original request with the explicit approval
   of the applicant.  Such changes do not restart the two-week
   discussion period, although an application containing the final
   record submitted to IANA MUST appear on the list at least one week
   prior to the Language Subtag Reviewer forwarding the record to IANA.
   The applicant is also free to modify a rejected application with
   additional information and submit it again; this starts a new two-
   week comment period.

   Registrations initiated due to the provisions of Section 3.3 or
   Section 3.4 SHALL NOT be rejected altogether (since they have to
   ultimately appear in the registry) and SHOULD be completed as quickly
   as possible.  The review process allows list members to comment on
   the specific information in the form and the record it contains and
   thus help ensure that it is correct and consistent.  The Language
   Subtag Reviewer MAY reject a specific version of the form, but MUST
   include in the rejection a suitable replacement, extending the review
   period as described above, until the form is in a format worthy of
   reviewer's approval.

   Decisions made by the Language Subtag Reviewer MAY be appealed to the
   IESG [RFC2028] under the same rules as other IETF decisions
   [RFC2026].  This includes a decision to extend the review period or
   the failure to announce a decision in a clear and timely manner.




Phillips & Davis        Expires February 25, 2008              [Page 37]

Internet-Draft              langtags-registry                August 2007


   The approved records appear in the Language Subtag Registry.  The
   approved registration forms are available online under
   http://www.iana.org/assignments/lang-subtags-templates/.

   Updates or changes to existing records follow the same procedure as
   new registrations.  The Language Subtag Reviewer decides whether
   there is consensus to update the registration following the two week
   review period; normally, objections by the original registrant will
   carry extra weight in forming such a consensus.

   Registrations are permanent and stable.  Once registered, subtags
   will not be removed from the registry and will remain a valid way in
   which to specify a specific language or variant.

   Note: The purpose of the "Reference to published description" section
   in the registration form is to aid in verifying whether a language is
   registered or what language or language variation a particular subtag
   refers to.  In most cases, reference to an authoritative grammar or
   dictionary of that language will be useful; in cases where no such
   work exists, other well-known works describing that language or in
   that language MAY be appropriate.  The Language Subtag Reviewer
   decides what constitutes "good enough" reference material.  This
   requirement is not intended to exclude particular languages or
   dialects due to the size of the speaker population or lack of a
   standardized orthography.  Minority languages will be considered
   equally on their own merits.

3.6.  Possibilities for Registration

   Possibilities for registration of subtags or information about
   subtags include:

   o  Primary language subtags for languages not listed in ISO 639 that
      are not variants of any listed or registered language MAY be
      registered.  At the time this document was created, there were no
      examples of this form of subtag.  Before attempting to register a
      language subtag, there MUST be an attempt to register the language
      with ISO 639.  Subtags MUST NOT be registered for languages
      defined by codes that exist in ISO 639-1, ISO 639-2, or ISO 639-3,
      or that are under consideration by the ISO 639 registration
      authorities, or that have never been attempted for registration
      with those authorities.  If ISO 639 has previously rejected a
      language for registration, it is reasonable to assume that there
      must be additional, very compelling evidence of need before it
      will be registered as a primary language subtag in the IANA
      registry (to the extent that it is very unlikely that any subtags
      will be registered of this type).




Phillips & Davis        Expires February 25, 2008              [Page 38]

Internet-Draft              langtags-registry                August 2007


   o  Dialect or other divisions or variations within a language, its
      orthography, writing system, regional or historical usage,
      transliteration or other transformation, or distinguishing
      variation MAY be registered as variant subtags.  An example is the
      'rozaj' subtag (the Resian dialect of Slovenian).

   o  The addition or maintenance of fields (generally of an
      informational nature) in Tag or Subtag records as described in
      Section 3.1 and subject to the stability provisions in
      Section 3.4.  This includes descriptions, comments, deprecation
      and preferred values for obsolete or withdrawn codes, or the
      addition of script or extlang information to primary language
      subtags.

   o  The addition of records and related field value changes necessary
      to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and
      UN M.49 as described in Section 3.4.

   Subtags proposed for registration that would cause all or part of a
   grandfathered tag to become redundant but whose meaning conflicts
   with or alters the meaning of the grandfathered tag MUST be rejected.

   This document leaves the decision on what subtags or changes to
   subtags are appropriate (or not) to the registration process
   described in Section 3.5.

   Note: four-character primary language subtags are reserved to allow
   for the possibility of alpha4 codes in some future addition to the
   ISO 639 family of standards.

   ISO 639 defines a maintenance agency for additions to and changes in
   the list of languages in ISO 639.  This agency is:

   International Information Centre for Terminology (Infoterm)
   Aichholzgasse 6/12, AT-1120
   Wien, Austria
   Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72

   ISO 639-2 defines a maintenance agency for additions to and changes
   in the list of languages in ISO 639-2.  This agency is:

   Library of Congress
   Network Development and MARC Standards Office
   Washington, D.C. 20540 USA
   Phone: +1 202 707 6237 Fax: +1 202 707 0115
   URL: http://www.loc.gov/standards/iso639-2

   ISO 639-3 defines a maintenance agency for additions to and changes



Phillips & Davis        Expires February 25, 2008              [Page 39]

Internet-Draft              langtags-registry                August 2007


   in the list of languages in ISO 639-3.  This agency is:

   SIL International
   ISO 639-3 Registrar
   7500 W. Camp Wisdom Rd.
   Dallas, TX 75236 USA
   Phone: +1 972 708 7400, ext. 2293 Fax: +1 972 708 7546
   Email: iso639-3@sil.org
   URL: http://www.sil.org/iso639-3

   The maintenance agency for ISO 3166 (country codes) is:

   ISO 3166 Maintenance Agency
   c/o International Organization for Standardization
   Case postale 56
   CH-1211 Geneva 20 Switzerland
   Phone: +41 22 749 72 33 Fax: +41 22 749 73 49
   URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html

   The registration authority for ISO 15924 (script codes) is:

   Unicode Consortium Box 391476
   Mountain View, CA 94039-1476, USA
   URL: http://www.unicode.org/iso15924

   The Statistics Division of the United Nations Secretariat maintains
   the Standard Country or Area Codes for Statistical Use and can be
   reached at:

   Statistical Services Branch
   Statistics Division
   United Nations, Room DC2-1620
   New York, NY 10017, USA

   Fax: +1-212-963-0623
   E-mail: statistics@un.org
   URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm

3.7.  Extensions and Extensions Registry

   Extension subtags are those introduced by single-character subtags
   ("singletons") other than 'x'.  They are reserved for the generation
   of identifiers that contain a language component and are compatible
   with applications that understand language tags.

   The structure and form of extensions are defined by this document so
   that implementations can be created that are forward compatible with
   applications that might be created using singletons in the future.



Phillips & Davis        Expires February 25, 2008              [Page 40]

Internet-Draft              langtags-registry                August 2007


   In addition, defining a mechanism for maintaining singletons will
   lend stability to this document by reducing the likely need for
   future revisions or updates.

   Single-character subtags are assigned by IANA using the "IETF
   Consensus" policy defined by [RFC2434].  This policy requires the
   development of an RFC, which SHALL define the name, purpose,
   processes, and procedures for maintaining the subtags.  The
   maintaining or registering authority, including name, contact email,
   discussion list email, and URL location of the registry, MUST be
   indicated clearly in the RFC.  The RFC MUST specify or include each
   of the following:

   o  The specification MUST reference the specific version or revision
      of this document that governs its creation and MUST reference this
      section of this document.

   o  The specification and all subtags defined by the specification
      MUST follow the ABNF and other rules for the formation of tags and
      subtags as defined in this document.  In particular, it MUST
      specify that case is not significant and that subtags MUST NOT
      exceed eight characters in length.

   o  The specification MUST specify a canonical representation.

   o  The specification of valid subtags MUST be available over the
      Internet and at no cost.

   o  The specification MUST be in the public domain or available via a
      royalty-free license acceptable to the IETF and specified in the
      RFC.

   o  The specification MUST be versioned, and each version of the
      specification MUST be numbered, dated, and stable.

   o  The specification MUST be stable.  That is, extension subtags,
      once defined by a specification, MUST NOT be retracted or change
      in meaning in any substantial way.

   o  The specification MUST include in a separate section the
      registration form reproduced in this section (below) to be used in
      registering the extension upon publication as an RFC.

   o  IANA MUST be informed of changes to the contact information and
      URL for the specification.

   IANA will maintain a registry of allocated single-character
   (singleton) subtags.  This registry MUST use the record-jar format



Phillips & Davis        Expires February 25, 2008              [Page 41]

Internet-Draft              langtags-registry                August 2007


   described by the ABNF in Section 3.1.  Upon publication of an
   extension as an RFC, the maintaining authority defined in the RFC
   MUST forward this registration form to iesg@ietf.org, who MUS
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




--
Mark ------=_Part_95185_17479944.1188310067868-- --===============0036778801== 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 --===============0036778801==-- From ltru-bounces@ietf.org Tue Aug 28 10:18: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 1IQ1tg-0001jO-8A; Tue, 28 Aug 2007 10:18:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ1te-0001iU-Rz for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 10:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1te-0001iM-IR for ltru@ietf.org; Tue, 28 Aug 2007 10:18:22 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ1td-0002y4-AO for ltru@ietf.org; Tue, 28 Aug 2007 10:18:22 -0400 Received: by wa-out-1112.google.com with SMTP id k40so367534wah for ; Tue, 28 Aug 2007 07:18:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=bpo+XNgch6FliE/mJ+BmRtS10WzVGyjZF/j58vBfHdC3qXb2H/lf/VX7PZcxsHJh+l68sb3ffJpNC4TsHX63XwXvhH2pjKYblFmWda1EwUtN0X1FBAPoO1pg/qgqU7dgJ0FNkYLh2HSzIMwh1x2F0Narqe5d/ccorURMCJ0zmhQ= 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=H0u7CBCA4riOQfFucgI/tqarrLNHLoKC0kiyb3kwuxPr9umESkBtAr+BLd/F3APe43211xTDwEdIKqEC5rXQsi5LCmcjQ98j8q1FsIC+y8L/P1rAuda1KPAQTlN7Qlbr4J++40hj7W2QRXmGQTxNP3A+Zz5tNvbE7dX8WxaOBdo= Received: by 10.115.90.1 with SMTP id s1mr756712wal.1188310700224; Tue, 28 Aug 2007 07:18:20 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 07:18:20 -0700 (PDT) Message-ID: <30b660a20708280718y4d937418r6ed515aef010a2b4@mail.gmail.com> Date: Tue, 28 Aug 2007 07:18:20 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 In-Reply-To: <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> MIME-Version: 1.0 References: <46CF54C4.2090707@yahoo-inc.com> <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> X-Google-Sender-Auth: 14545fa767470908 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2046201364==" Errors-To: ltru-bounces@ietf.org --===============2046201364== Content-Type: multipart/alternative; boundary="----=_Part_95414_22023971.1188310700117" ------=_Part_95414_22023971.1188310700117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, didn't mean to quote the whole document! Mark ------=_Part_95414_22023971.1188310700117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, didn't mean to quote the whole document!

Mark
------=_Part_95414_22023971.1188310700117-- --===============2046201364== 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 --===============2046201364==-- From ltru-bounces@ietf.org Tue Aug 28 12:35: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 1IQ421-00012S-3N; Tue, 28 Aug 2007 12:35:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ420-00012M-4i for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 12:35:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ41z-00012D-Nf for ltru@ietf.org; Tue, 28 Aug 2007 12:35:07 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ41z-0005uz-C9 for ltru@ietf.org; Tue, 28 Aug 2007 12:35:07 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jxqHFs2GSpqroYIKX032aeb/7tSDP++V9pnGaKGfGAq/IHj0j1A6TmLyxjaIZdOm; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ41y-0003Ed-Qn for ltru@ietf.org; Tue, 28 Aug 2007 12:35:07 -0400 Message-ID: <003d01c7e991$bc972420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <46CF54C4.2090707@yahoo-inc.com><30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> <30b660a20708280718y4d937418r6ed515aef010a2b4@mail.gmail.com> Date: Tue, 28 Aug 2007 09:37:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935677e72a35ac523b9413d930607e732ad2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Subject lines for issues in *any* ltru WG i-d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 - Everyone: When you raise an issue, PLEASE use a new (and hopefully descriptive) Subject: line. Things like "Re: [Ltru] draft-ietf-ltru-rfc4646bis-08" are rarely helpful. Randy as ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 12:50: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 1IQ4Gt-0005bu-Jk; Tue, 28 Aug 2007 12:50:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ4Gt-0005az-6Z for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 12:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4Gs-0005ar-T5 for ltru@ietf.org; Tue, 28 Aug 2007 12:50:30 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4Gr-0008TS-HW for ltru@ietf.org; Tue, 28 Aug 2007 12:50:30 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eZ6PwHwSk2QtB7BROsPAvuGoA885nsFwmb0g0bR5ib4FPhS/LQEZjnNHmoowsq91; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ4Gq-0005u7-Ob for ltru@ietf.org; Tue, 28 Aug 2007 12:50:29 -0400 Message-ID: <005601c7e993$e2e262a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> Date: Tue, 28 Aug 2007 09:52:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93565d3db090e841f43c712407d455de3e45350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ltru] first paragraph of draft-ietf-ltru-rfc4646bis-08 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair... We work by rough consensus. The assessment whether a proposed edit needs to be made is up to the WG. If a change is agreed (and I'm not saying this particular one has been) the editors need to implement it, whether they personally agree with it or not. So while as a technical contributor you're certainly expected to give your views, to avoid confusion please make it clear whether you're commenting as a technical contributor or as an editor. As a technical contributor: While I'm not fond of the existing text, I also haven't seen a convincing rationale that removing it would help (or hurt) anything. As for the proposed change, I think tacking on the addtional text with a comma would result in an awkward run-on sentence. If we were to make a change, I'd want the added text to be sentence in its own right. My net position: leave it alone. It's not sufficiently broken. Randy ----- Original Message ----- From: "Addison Phillips" To: "Marion Gunn" Cc: "LTRU Working Group" Sent: Tuesday, August 28, 2007 6:53 AM Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 Marion, This text has existed for a long time. In fact, it is taken verbatim from RFC 3066 (RFC 1766 had a similar, but different, sentence). This isn't a substantive edit and doesn't address the real open issue in our draft, which is how to handle extlangs. Regards, Addison Marion Gunn wrote: > For starters, suggest losing the entire first sentence of paragraph 1 > below, inserting the word "human" before "language" in its second > sentence and inserting the following comma-plus-clause text ", such > reasons as are set out below" before its closing full stop. > mg > > > On 24 Aug 2007, at 21:59, scríobh Addison Phillips: > > >> Phillips & Davis Expires February 25, 2008 [Page 3] >> Internet-Draft langtags-registry August 2007 >> >> >> 1. Introduction >> >> Human beings on our planet have, past and present, used a number of >> languages. There are many reasons why one would want to identify the >> language used when presenting or requesting information. >> >> > > -- > Marion Gunn > mgunn@ucd.ie > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 13:07:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4XU-0005l5-Qe; Tue, 28 Aug 2007 13:07:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ4XS-0005ky-Or for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:07:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4XS-0005kq-FK for ltru@ietf.org; Tue, 28 Aug 2007 13:07:38 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4XR-0000Or-20 for ltru@ietf.org; Tue, 28 Aug 2007 13:07:38 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iFiDZxGgcp+YL+iYR25mtmZ+0XdBPtqD2+64WEZe01dHSGKKZUp+JYDarJdu/0Xu; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ4XQ-0008JO-Ch for ltru@ietf.org; Tue, 28 Aug 2007 13:07:36 -0400 Message-ID: <008d01c7e996$4747c300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <46CF54C4.2090707@yahoo-inc.com> <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> Date: Tue, 28 Aug 2007 10:10:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356bc2a14ad84c68b37cf5a78d8dca9e279350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Ltru] extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Addison Phillips" > Cc: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 7:07 AM > Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 > > Just to open up the discussion, the biggest problem with this version is > that it uses a substantial new mechanism (extlang) which was not used in RFC > 4646, and for which there is no consensus in this group to use in RFC > 4646bis. We haven't removed extlang from the draft yet, but the people that > want this new mechanism need to provide justification, that: > > 1. it is substantially better to have languages like 'cmn' be put in a > secondary position (eg zh-cmn-Hant-CN), rather than being primary subtags on > their own (eg cmn-Hant-CN). > 2. it is sufficiently better to warrant making the language tags more > complicated by the addition of this mechanism. > > Mark As a co-chair trying to help the discussion, I've extracted the passages I could find where "extlang" appears. I think it is helpful to read through these, even with the limited context. > > language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > > / 4ALPHA ; reserved for future use > > / 5*8ALPHA ; registered language subtag > > > > extlang = *3("-" 3ALPHA) ; specific ISO 639-3 codes > > o 'Type' > > > > * Type's field-body MUST consist of one of the following strings: > > "language", "extlang", "script", "region", "variant", > > "grandfathered", and "redundant" and denotes the type of tag or > > subtag. > > > > o Either 'Subtag' or 'Tag' > > > > * Subtag's field-body contains the subtag being defined. This > > field MUST only appear in records of whose 'Type' has one of > > these values: "language", "extlang", "script", "region", or > > "variant". > > o Preferred-Value > > > > * For fields of type 'script', 'region', and 'variant', > > 'Preferred-Value' contains the subtag of the same 'Type' that > > is preferred for forming the language tag. > > > > * For fields of type 'language' and 'extlang', 'Preferred-Value' > > contains the language production (see Figure 1) that is > > preferred when forming the language tag. This can be simply a > > 'language' subtag, or it can be a 'language' subtag followed by > > an extended language sequence. > > For records taken from a source standard (such as ISO 639 or ISO > > 3166), the 'Description' value(s) SHOULD also be taken from the > > source standard. Multiple descriptions in the source standard MUST > > be split into separate 'Description' fields. The source standard's > > descriptions MAY be edited, either prior to insertion or via the > > registration process. For fields of type 'language' or 'extlang', > > the first 'Description' field appearing in the Registry corresponds > > to the Reference Name assigned by ISO 639-3. This helps facilitate > > cross-referencing between ISO 639 and the registry. > > Records of type 'extlang' MUST have _exactly_ one 'Prefix' field. > > This field can be useful to applications or users when selecting > > language tags or as additional metadata useful in matching. The > > Macrolanguage field can only occur in records of type 'language' or > > 'extlang'. Only values assigned by ISO 639-3 will be considered for > > inclusion. Macrolanguage fields MAY be added or removed via the > > normal registration process whenever ISO 639-3 defines new values. > > Macrolanguages are informational, and MAY be removed or changed if > > ISO 639-3 changes the values. > > 5. Values in the field 'Prefix' in records of type 'extlang' MUST > > NOT be modified. > > 1. Codes that have a defined "macrolanguage" mapping at the > > time of their registration MUST be entered into the registry > > as records of type 'extlang' with a 'Prefix' field > > containing the appropriate prefix tag. They MUST also > > include a "Macrolanguage" field in their record. > > > > 2. Codes that represent sign languages MUST be entered into the > > registry as record of type 'extlang' with a 'Prefix' field > > that matches the Basic Language Range "sgn" (see Section > > 3.3.1 "Basic Filtering" in [RFC4647]). > > 13. A record of type 'language' or 'extlang' MUST NOT be registered > > if there exists a record of either type with the same subtag > > value. For example, if an 'extlang' subtag 'foo' exists in the > > registry, all attempts to register a 'language' subtag 'foo' > > will be rejected. > > o The addition or maintenance of fields (generally of an > > informational nature) in Tag or Subtag records as described in > > Section 3.1 and subject to the stability provisions in > > Section 3.4. This includes descriptions, comments, deprecation > > and preferred values for obsolete or withdrawn codes, or the > > addition of script or extlang information to primary language > > subtags. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 14:02: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 1IQ5Or-0001RM-P9; Tue, 28 Aug 2007 14:02:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ5Or-0001RG-El for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 14:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Or-0001R8-5L for ltru@ietf.org; Tue, 28 Aug 2007 14:02:49 -0400 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQ5Op-0002DK-Pc for ltru@ietf.org; Tue, 28 Aug 2007 14:02:49 -0400 Received: (qmail 70433 messnum 6393780 invoked from network[194.125.174.87/ts09-087.dublin.indigo.ie]); 28 Aug 2007 18:02:46 -0000 Received: from ts09-087.dublin.indigo.ie (HELO ?194.125.174.87?) (194.125.174.87) by mail00.svc.cra.dublin.eircom.net (qp 70433) with SMTP; 28 Aug 2007 18:02:46 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <46D428E2.50804@yahoo-inc.com> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 Date: Tue, 28 Aug 2007 19:02:49 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org First impressions are important, so - however long that particular =20 expression has been in there - it is common knowledge that texts =20 starting "on our planet" tend not to be taken seriously and that such =20= expressions tend only detract/distract somewhat, from the substance =20 of a document without adding anything of substance to it. By all =20 means leave it in, if you disagree with the above. For ease of reference and for the sake of new readers, I'd also like =20 to see "Definitions" fronted in the document, pace the ISO practice =20 of fronting "Scope" and "Definitions", and to see "extlang" defined =20 under "Definitions", as one of the many relevant terms (defined as a =20 group of concepts) to be grasped, before describing how all those =20 bits are meant to work together. If this means cutting and pasting in =20= definitions straight out of other documents, that is fine and good =20 for consistency checks across documents. I didn't address the question of handling extlangs simply because I =20 am currently not at all sure how to do so. mg On 28 Aug 2007, at 13:53, scr=EDobh Addison Phillips: > Marion, > > This text has existed for a long time. In fact, it is taken =20 > verbatim from RFC 3066 (RFC 1766 had a similar, but different, =20 > sentence). This isn't a substantive edit and doesn't address the =20 > real open issue in our draft, which is how to handle extlangs. > > Regards, > > Addison - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 14:15: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 1IQ5bS-0003V4-BC; Tue, 28 Aug 2007 14:15:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ5bS-0003Uy-1T for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 14:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5bR-0003Up-OD for ltru@ietf.org; Tue, 28 Aug 2007 14:15:49 -0400 Received: from mail10.svc.cra.dublin.eircom.net ([159.134.118.26]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQ5bP-0002W3-Sr for ltru@ietf.org; Tue, 28 Aug 2007 14:15:49 -0400 Received: (qmail 25748 messnum 6708388 invoked from network[194.125.174.87/ts09-087.dublin.indigo.ie]); 28 Aug 2007 18:15:46 -0000 Received: from ts09-087.dublin.indigo.ie (HELO ?194.125.174.87?) (194.125.174.87) by mail10.svc.cra.dublin.eircom.net (qp 25748) with SMTP; 28 Aug 2007 18:15:46 -0000 In-Reply-To: <008d01c7e996$4747c300$6801a8c0@oemcomputer> References: <46CF54C4.2090707@yahoo-inc.com> <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> <008d01c7e996$4747c300$6801a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] extlang Date: Tue, 28 Aug 2007 19:15:50 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 28 Aug 2007, at 17:10, scr=EDobh Randy Presuhn: > > As a co-chair trying to help the discussion, I've extracted > the passages I could find where "extlang" appears. Good work. > I think > it is helpful to read through these, even with the limited context. Sorry, I still cannot glean enough from that to offer a useful =20 opinion on handling extlangs, so I leave that to others (it is the =20 end of day here in Ireland). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 14: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 1IQ5fk-000556-Lj; Tue, 28 Aug 2007 14:20:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ5fj-00054r-Iu for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 14:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5fj-000543-8y for ltru@ietf.org; Tue, 28 Aug 2007 14:20:15 -0400 Received: from mail14.svc.cra.dublin.eircom.net ([159.134.118.30]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQ5fh-0002e9-TC for ltru@ietf.org; Tue, 28 Aug 2007 14:20:15 -0400 Received: (qmail 34729 messnum 5484677 invoked from network[194.125.174.87/ts09-087.dublin.indigo.ie]); 28 Aug 2007 18:20:12 -0000 Received: from ts09-087.dublin.indigo.ie (HELO ?194.125.174.87?) (194.125.174.87) by mail14.svc.cra.dublin.eircom.net (qp 34729) with SMTP; 28 Aug 2007 18:20:12 -0000 In-Reply-To: <005601c7e993$e2e262a0$6801a8c0@oemcomputer> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> <005601c7e993$e2e262a0$6801a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] first paragraph of draft-ietf-ltru-rfc4646bis-08 Date: Tue, 28 Aug 2007 19:20:16 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org First impressions are important, so - however long that particular =20 expression has been in there - it is common knowledge that texts =20 starting "on our planet" tend not to be taken seriously and that such =20= expressions tend more to detract/distract somewhat, from the =20 substance of a document than add substance to it. By all means leave =20 it in, if you disagree with the above. For ease of reference and for the sake of new readers, I'd also like =20 to see "Definitions" fronted in the document, pace the ISO practice =20 of fronting "Scope" and "Definitions", and to see "extlang" defined =20 under "Definitions", as one of the many relevant terms (defined as a =20 group of concepts) to be grasped, before describing how all those =20 bits are meant to work together. If this means cutting and pasting in =20= definitions straight out of other documents, that is fine and good =20 for consistency checks across documents. I didn't address the question of handling extlangs simply because I =20 am currently not at all sure how to do so. mg On 28 Aug 2007, at 13:53, scr=EDobh Addison Phillips: > Marion, > > This text has existed for a long time. In fact, it is taken =20 > verbatim from RFC 3066 (RFC 1766 had a similar, but different, =20 > sentence). This isn't a substantive edit and doesn't address the =20 > real open issue in our draft, which is how to handle extlangs. > > Regards, > > Addison > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 14:47: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 1IQ660-0007HQ-Vm; Tue, 28 Aug 2007 14:47:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ660-0007BL-1w for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 14:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ65z-00078i-78 for ltru@ietf.org; Tue, 28 Aug 2007 14:47:23 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ65x-00040K-TY for ltru@ietf.org; Tue, 28 Aug 2007 14:47:23 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HKXoHKCKPKiTbJWWlt/DEZWv0RC3YGTYdSDyD6ocpDgsXtd4pmTBuYVqyxHTlakt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ65x-00020m-Ba for ltru@ietf.org; Tue, 28 Aug 2007 14:47:21 -0400 Message-ID: <000c01c7e9a4$347771e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <46CF54C4.2090707@yahoo-inc.com><46D428E2.50804@yahoo-inc.com><005601c7e993$e2e262a0$6801a8c0@oemcomputer> Date: Tue, 28 Aug 2007 11:49:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935696841f560e935b5f6fbf672abd3464b3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Definitions section X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair: PLEASE remember to use a new subject line when you raise a new issue. Randy > From: "Marion Gunn" > To: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 12:20 PM > Subject: Re: [Ltru] first paragraph of draft-ietf-ltru-rfc4646bis-08 ... > For ease of reference and for the sake of new readers, I'd also like > to see "Definitions" fronted in the document, pace the ISO practice > of fronting "Scope" and "Definitions", and to see "extlang" defined > under "Definitions", as one of the many relevant terms (defined as a > group of concepts) to be grasped, before describing how all those > bits are meant to work together. If this means cutting and pasting in > definitions straight out of other documents, that is fine and good > for consistency checks across documents. ... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 15:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6yk-0001QX-25; Tue, 28 Aug 2007 15:43:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ6yi-0001QQ-9W for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 15:43:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6yh-0001QH-Uw for ltru@ietf.org; Tue, 28 Aug 2007 15:43:55 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ6yh-0005HW-7U for ltru@ietf.org; Tue, 28 Aug 2007 15:43:55 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IQ6yc-0004w5-1r; Tue, 28 Aug 2007 15:43:50 -0400 Date: Tue, 28 Aug 2007 15:43:50 -0400 To: Mark Davis Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 Message-ID: <20070828194349.GX31670@mercury.ccil.org> References: <46CF54C4.2090707@yahoo-inc.com> <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20708280707h20c489b7h49f0909cbad32735@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: > Just to open up the discussion, the biggest problem with this version is > that it uses a substantial new mechanism (extlang) which was not used in RFC > 4646, and for which there is no consensus in this group to use in RFC > 4646bis. As far as the record appears, there is no consensus because you are single-handedly blocking it. > We haven't removed extlang from the draft yet, "We haven't yet" implicatures "We will", as you well know. Its use here is quite inappropriate. > but the people that want this new mechanism need to provide > justification, This mechanism has long been planned, but was held up pending the publication and stabilization of ISO 639-3. It is you who wish to change the plan, and therefore you who bear the burden of persuasion. > 1. it is substantially better to have languages like 'cmn' be put in a > secondary position (eg zh-cmn-Hant-CN), rather than being primary subtags on > their own (eg cmn-Hant-CN). It is better because all documents in Sinitic languages have been historically tagged "zh", most of them are in Mandarin, and allowing "cmn" as a primary language tag will break people who expect "zh" to Just Work. Furthermore, people who have been using "zh-yue" for Cantonese should not have to switch to "yue" to allow flexibilities such as adding script, region, or variant tags. (Currently "zh-yue" is grandfathered and cannot be used generatively.) > 2. it is sufficiently better to warrant making the language tags more > complicated by the addition of this mechanism. Language tags become more complicated *if* it is desired to make them so. Those who find "zh" sufficient may continue to use it while still interoperating with "zh-cmn", "zh-yue", and so on. Existing deployed matchers will continue to work, as will existing deployed software that understands specific tags; they will not need to become more complicated to understand the out-of-band relationship between "zh", "cmn", "yue", etc. -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow cowan@ccil.org Was para-dichloro- Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 16:15: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 1IQ7TO-0006kr-IO; Tue, 28 Aug 2007 16:15:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ7TK-0006dO-W8 for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 16:15:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7TJ-0006aa-8X; Tue, 28 Aug 2007 16:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ7TI-0006vq-Qa; Tue, 28 Aug 2007 16:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A25BA2AC73; Tue, 28 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ7So-0006wS-5b; Tue, 28 Aug 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4646bis-08.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-08.txt Pages : 74 Date : 2007-8-28 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-08.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-08.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-08.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-8-28152116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4646bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4646bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28152116.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 Tue Aug 28 18:00: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 1IQ96R-0007vw-88; Tue, 28 Aug 2007 18:00:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ96Q-0007vr-Fq for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ96Q-0007vj-6A for ltru@ietf.org; Tue, 28 Aug 2007 18:00:02 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ96O-00036S-Jf for ltru@ietf.org; Tue, 28 Aug 2007 18:00:02 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1207536uge for ; Tue, 28 Aug 2007 14:59:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=T3k7bggQPKvf5gVJC3dhO/lnID9aHRyxQmZW6gH17HHOEyRNzx0U3KGa/RbGunqEnGY6qlVT988jYEd8CyBd602ekPJ19HUbwHoI6yWozqUozUIHRV8LKY8qPY7tX0xL6GxG82n84XJZjGxPO+QXwKTGZd+TSm3bRiSLZJn31Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=Na4onE7tLhLan8/tA0WMDzifLZ/M3v82totz7j4MzoZBOhICpci4B6Xsw63P2Mpswj7ObZuq2+eyH6SSUlK1uSYEzlY7TbkmsauzMu6yVmf1bSMOv6MmCb28ssVXdK9V/jh9x+4c4BBhlJP1Se8V67tjEhYLzbSQuDTJTRILCaA= Received: by 10.114.193.1 with SMTP id q1mr1203348waf.1188338397197; Tue, 28 Aug 2007 14:59:57 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 14:59:57 -0700 (PDT) Message-ID: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> Date: Tue, 28 Aug 2007 14:59:57 -0700 From: "Mark Davis" To: "John Cowan" MIME-Version: 1.0 X-Google-Sender-Auth: fe51580001acba97 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: LTRU Working Group Subject: [Ltru] extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1487091753==" Errors-To: ltru-bounces@ietf.org --===============1487091753== Content-Type: multipart/alternative; boundary="----=_Part_103581_30387954.1188338397170" ------=_Part_103581_30387954.1188338397170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/28/07, John Cowan wrote: > > Mark Davis scripsit: > > > Just to open up the discussion, the biggest problem with this version is > > that it uses a substantial new mechanism (extlang) which was not used in > RFC > > 4646, and for which there is no consensus in this group to use in RFC > > 4646bis. > > As far as the record appears, there is no consensus because you are > single-handedly blocking it. Not single-handedly: Addison has also commented on it. And on the other side, I've heard 3 strong proponents. So not exactly overwhelming either way. > We haven't removed extlang from the draft yet, > > "We haven't yet" implicatures "We will", as you well know. Its use here > is quite inappropriate. I think you are being overly sensitive here. I clearly don't want extlang in, but the "yet" is only indicating that it is still in the draft. And leaving it in until we come to a conclusion is reasonable, since it is less work if we decide we want it. > but the people that want this new mechanism need to provide > > justification, > > This mechanism has long been planned, but was held up pending the > publication and stabilization of ISO 639-3. It is you who wish to change > the plan, and therefore you who bear the burden of persuasion. I've said before, and will say again: it was never a foregone conclusion. I as one of the authors would never have agreed to add a major structure that was not fully fleshed out, in advance of having a completed standard AND having had a chance to test that structure in practice. Because we were locking down the syntax, we wanted to ENABLE the addition of extlang should the group decide that it was worth adding. Do I really have to repeat this over and over???? > 1. it is substantially better to have languages like 'cmn' be put in a > > secondary position (eg zh-cmn-Hant-CN), rather than being primary > subtags on > > their own (eg cmn-Hant-CN). > > It is better because all documents in Sinitic languages have been > historically tagged "zh", most of them are in Mandarin, and allowing "cmn" > as a primary language tag will break people who expect "zh" to Just Work. > Furthermore, people who have been using "zh-yue" for Cantonese should > not have to switch to "yue" to allow flexibilities such as adding script, > region, or variant tags. (Currently "zh-yue" is grandfathered and cannot > be used generatively.) You are not revealing some important hidden assumptions in your statements. 1. The macrolanguage is always a better fallback for every encompassed language than other alternatives. Out of the many encompassed languages, you implying that a speaker of every encompassed language will be able to understand the macrolanguage, or at least better than the alteratives. 2. People don't lose anything by having the fallback. I dispute this as well. As previously noted: 1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and the SG; falling back from ar-arb-SA to 'ar' loses the "SA". 2. It introduces ambiguous language names. Right now, in the overwhelming majority of practice, standard Arabic is "ar"; after the change, standard Arabic is "ar-arb". 3. People can't get along without this. 1. Anyone who has to deal with language issues on all but a trivial level must already have a mechanism to deal with sh, sr, hr; with no, nb, nn. Those are macrolanguages and encompassed languages. They exist right now WITHOUT an extlang mechanism, and people deal with them. The proposed mechanism won't handle these, and anyone who can handle these doesn't need extlang. 2. With the Macrolanguage field, there is sufficient information for *anyone* who wants to to implement extlang-like fallback (including for sh or no), *without* encumbering the IDs with superfluous information. > 2. it is sufficiently better to warrant making the language tags more > > complicated by the addition of this mechanism. > > Language tags become more complicated *if* it is desired to make them > so. Those who find "zh" sufficient may continue to use it while still > interoperating with "zh-cmn", "zh-yue", and so on. Existing deployed > matchers will continue to work, as will existing deployed software > that understands specific tags; they will not need to become more > complicated to understand the out-of-band relationship between "zh", > "cmn", "yue", etc. This is untrue. As soon as we implemented extlang in prototype, we ran into the problems listed above. It *didn't* work out of the box. -- > A mosquito cried out in his pain, John Cowan > "A chemist has poisoned my brain!" http://www.ccil.org/~cowan > The cause of his sorrow cowan@ccil.org > Was para-dichloro- > Diphenyltrichloroethane. (aka DDT) > -- Mark ------=_Part_103581_30387954.1188338397170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 8/28/07, John Cowan <cowan@ccil.org> wrote:
Mark Davis scripsit:

> Just to open up the discussion, the biggest problem with this version is
> that it uses a substantial new mechanism (extlang) which was not used in RFC
> 4646, and for which there is no consensus in this group to use in RFC
> 4646bis.

As far as the record appears, there is no consensus because you are
single-handedly blocking it.

Not single-handedly: Addison has also commented on it. And on the other side, I've heard 3 strong proponents. So not exactly overwhelming either way.

> We haven't removed extlang from the draft yet,

"We haven't yet" implicatures "We will", as you well know.  Its use here
is quite inappropriate.

I think you are being overly sensitive here. I clearly don't want extlang in, but the "yet" is only indicating that it is still in the draft. And leaving it in until we come to a conclusion is reasonable, since it is less work if we decide we want it.

> but the people that want this new mechanism need to provide
> justification,

This mechanism has long been planned, but was held up pending the
publication and stabilization of ISO 639-3.  It is you who wish to change
the plan, and therefore you who bear the burden of persuasion.

I've said before, and will say again: it was never a foregone conclusion. I as one of the authors would never have agreed to add a major structure that was not fully fleshed out, in advance of having a completed standard AND having had a chance to test that structure in practice. Because we were locking down the syntax, we wanted to ENABLE the addition of extlang should the group decide that it was worth adding. Do I really have to repeat this over and over????

>    1. it is substantially better to have languages like 'cmn' be put in a
>    secondary position (eg zh-cmn-Hant-CN), rather than being primary subtags on
>    their own (eg cmn-Hant-CN).

It is better because all documents in Sinitic languages have been
historically tagged "zh", most of them are in Mandarin, and allowing "cmn"
as a primary language tag will break people who expect "zh" to Just Work.
Furthermore, people who have been using "zh-yue" for Cantonese should
not have to switch to "yue" to allow flexibilities such as adding script,
region, or variant tags.  (Currently "zh-yue" is grandfathered and cannot
be used generatively.)

You are not revealing some important hidden assumptions in your statements.
  1. The macrolanguage is always a better fallback for every encompassed language than other alternatives. Out of the many encompassed languages, you implying that a speaker of every encompassed language will be able to understand the macrolanguage, or at least better than the alteratives.
  2. People don't lose anything by having the fallback. I dispute this as well. As previously noted:
    1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and the SG; falling back from ar-arb-SA to 'ar' loses the "SA".
    2. It introduces ambiguous language names. Right now, in the overwhelming majority of practice, standard Arabic is "ar"; after the change, standard Arabic is "ar-arb".
  3. People can't get along without this.
    1. Anyone who has to deal with language issues on all but a trivial level must already have a mechanism to deal with sh, sr, hr; with no, nb, nn. Those are macrolanguages and encompassed languages. They exist right now WITHOUT an extlang mechanism, and people deal with them. The proposed mechanism won't handle these, and anyone who can handle these doesn't need extlang.
    2. With the Macrolanguage field, there is sufficient information for *anyone* who wants to to implement extlang-like fallback (including for sh or no), *without* encumbering the IDs with superfluous information.

>    2. it is sufficiently better to warrant making the language tags more
>    complicated by the addition of this mechanism.

Language tags become more complicated *if* it is desired to make them
so.  Those who find "zh" sufficient may continue to use it while still
interoperating with "zh-cmn", "zh-yue", and so on.  Existing deployed
matchers will continue to work, as will existing deployed software
that understands specific tags; they will not need to become more
complicated to understand the out-of-band relationship between "zh",
"cmn", "yue", etc.

This is untrue. As soon as we implemented extlang in prototype, we ran into the problems listed above. It *didn't* work out of the box.

--
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"               http://www.ccil.org/~cowan
        The cause of his sorrow                 cowan@ccil.org
        Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)



--
Mark ------=_Part_103581_30387954.1188338397170-- --===============1487091753== 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 --===============1487091753==-- From ltru-bounces@ietf.org Tue Aug 28 18:04: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 1IQ9Ap-0007e9-NG; Tue, 28 Aug 2007 18:04:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9Ao-0007dw-Tw for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9Ao-0007de-HW for ltru@ietf.org; Tue, 28 Aug 2007 18:04:34 -0400 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ9An-0003Bf-6W for ltru@ietf.org; Tue, 28 Aug 2007 18:04:34 -0400 Received: by el-out-1112.google.com with SMTP id s27so461322ele for ; Tue, 28 Aug 2007 15:04:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=n1UGkvs7UUuD62iBVQfNJzMlpS0IFzq2ceE9Bm10zdOPAcKSc5xXYJ04cy2OAEwTExDi3XULc23aPrWWg7btnUa13g0yByWzA7SA5yH2iZT5SZhRnL32V3uJtiXSxRFYCizx8vjgmeSXiWdXk5iO39KqkV/lhAHNoamtz3gd1qw= 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=JcTjUNd0W9vxP6RH58RIyrZgQm837RWOrGffQe8uBAW9v4uSCFozxYAaOmmvfDxyDfbWOojuoxuVHgO3TD5i+J5mYUN+4RQ1UdMebGHGTt6Sx45rn80Shu6ai/7+1qG/5eB7CesLMleDme6UhCplZJ6uiS2vdM6TcJQTg+Rg+CI= Received: by 10.114.66.2 with SMTP id o2mr1566331waa.1188338672034; Tue, 28 Aug 2007 15:04:32 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 15:04:32 -0700 (PDT) Message-ID: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> Date: Tue, 28 Aug 2007 15:04:32 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 428df1f4d9bcb02c X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] extlang straw poll X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0075803639==" Errors-To: ltru-bounces@ietf.org --===============0075803639== Content-Type: multipart/alternative; boundary="----=_Part_103629_17806330.1188338672008" ------=_Part_103629_17806330.1188338672008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline As a straw poll, where do people stand on extlang? That is, vis-a-vis the question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do you: 1. Strongly favor having extlang 2. Favor having extlang, but don't mind too much if it were not in 3. Don't care much either way 4. Favor not having extlang, but don't mind too much if it were in 5. Strongly favor not having extlang Mark ------=_Part_103629_17806330.1188338672008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline As a straw poll, where do people stand on extlang? That is, vis-a-vis the question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do you:
  1. Strongly favor having extlang
  2. Favor having extlang, but don't mind too much if it were not in
  3. Don't care much either way
  4. Favor not having extlang, but don't mind too much if it were in
  5. Strongly favor not having extlang
Mark
------=_Part_103629_17806330.1188338672008-- --===============0075803639== 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 --===============0075803639==-- From ltru-bounces@ietf.org Tue Aug 28 18:19: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 1IQ9P4-0003Mx-Ac; Tue, 28 Aug 2007 18:19:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9P3-0003LM-9a for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:19:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9P2-0003LD-TW for ltru@ietf.org; Tue, 28 Aug 2007 18:19:17 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound9-blu-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ9P2-0002IW-5C for ltru@ietf.org; Tue, 28 Aug 2007 18:19:16 -0400 Received: from outbound9-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound9-blu-R.bigfish.com (Postfix) with ESMTP id 8D74B12F0EB7; Tue, 28 Aug 2007 22:17:02 +0000 (UTC) Received: from mail216-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound9-blu.bigfish.com (Postfix) with ESMTP id 720C11B90057; Tue, 28 Aug 2007 22:17:02 +0000 (UTC) Received: from mail216-blu (localhost.localdomain [127.0.0.1]) by mail216-blu-R.bigfish.com (Postfix) with ESMTP id 622851508143; Tue, 28 Aug 2007 22:17:02 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail216-blu (MessageSwitch) id 1188339421494431_29234; Tue, 28 Aug 2007 22:17:01 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail216-blu.bigfish.com (Postfix) with ESMTP id 4F4494B006A; Tue, 28 Aug 2007 22:17:01 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007082815165162-217476 ; Tue, 28 Aug 2007 15:16:51 -0700 In-Reply-To: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] extlang straw poll 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: Tue, 28 Aug 2007 15:14:34 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/28/2007 15:14:34, Serialize complete at 08/28/2007 15:14:34, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/28/2007 03:16:51 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/28/2007 03:17:01 PM, Serialize complete at 08/28/2007 03:17:01 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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="===============1883208739==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1883208739== Content-Type: multipart/alternative; boundary="=_alternative 007A644288257345_=" This is a multipart message in MIME format. --=_alternative 007A644288257345_= Content-Type: text/plain; charset="US-ASCII" I'm not sure the question is clear. Extlang would contain the "microlanguages" from 639-3, such as "cmn", right? Karen "Mark Davis" 08/28/2007 03:04 PM To "LTRU Working Group" cc Subject [Ltru] extlang straw poll As a straw poll, where do people stand on extlang? That is, vis-a-vis the question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do you: 1. Strongly favor having extlang 2. Favor having extlang, but don't mind too much if it were not in 3. Don't care much either way 4. Favor not having extlang, but don't mind too much if it were in 5. Strongly favor not having extlang Mark_______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 007A644288257345_= Content-Type: text/html; charset="US-ASCII"
I'm not sure the question is clear. Extlang would contain the "microlanguages" from 639-3, such as "cmn",  right?

Karen



"Mark Davis" <mark.davis@icu-project.org>

08/28/2007 03:04 PM

To
"LTRU Working Group" <ltru@ietf.org>
cc
Subject
[Ltru] extlang straw poll





As a straw poll, where do people stand on extlang? That is, vis-a-vis the question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do you:
1.        Strongly favor having extlang
2.        Favor having extlang, but don't mind too much if it were not in
3.        Don't care much either way
4.        Favor not having extlang, but don't mind too much if it were in
5.        Strongly favor not having extlang
Mark_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 007A644288257345_=-- --===============1883208739== 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 --===============1883208739==-- From ltru-bounces@ietf.org Tue Aug 28 18: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 1IQ9aM-0007EU-Ky; Tue, 28 Aug 2007 18:30:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9aL-0007EO-Fc for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:30:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9aK-0007EG-SW for ltru@ietf.org; Tue, 28 Aug 2007 18:30:57 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ9aK-0002Y8-3b for ltru@ietf.org; Tue, 28 Aug 2007 18:30:56 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YM7i35tSb8ibFbjZOF5O7XgiKSDE6RTV3/OabWDQHATTcj7FDe21sF6O2NUqVcwu; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ9aJ-0003k3-Be for ltru@ietf.org; Tue, 28 Aug 2007 18:30:55 -0400 Message-ID: <001501c7e9c3$71f00b80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> Subject: Re: [Ltru] extlang Date: Tue, 28 Aug 2007 15:33:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93565c0710376ec2c2966c68a24449faf2cf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Mark Davis" > To: "John Cowan" > Cc: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 2:59 PM > Subject: [Ltru] extlang ... > You are not revealing some important hidden assumptions in your statements. > > 1. The macrolanguage is always a better fallback for every encompassed > language than other alternatives. Out of the many encompassed languages, you > implying that a speaker of every encompassed language will be able to > understand the macrolanguage, or at least better than the alteratives. I don't see how the use of extlang would require this as an assumption. Making such an assumption seems a bit like assuming that all languages whose tags begin in "a" are somehow related. > 2. People don't lose anything by having the fallback. I dispute this > as well. As previously noted: > 1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and > the SG; falling back from ar-arb-SA to 'ar' loses the "SA". It is the nature of truncation fallback to lose information. No matter what order the subtags are trimmed off, someone will be able to argue that for some particular case, a different order might have been better. This isn't an argument against extlang; it's an argument against unrealistically high expectations for truncation fallback. > 2. It introduces ambiguous language names. Right now, in the > overwhelming majority of practice, standard Arabic is "ar"; after the > change, standard Arabic is "ar-arb". This would not be desirable. However, I wonder whether the semantic associated by most taggers and users of tags with "ar" is "standard Arabic" or merely "Arabic". > 3. People can't get along without this. > 1. Anyone who has to deal with language issues on all but a trivial > level must already have a mechanism to deal with sh, sr, hr; with no, nb, > nn. Those are macrolanguages and encompassed languages. They > exist right now > WITHOUT an extlang mechanism, and people deal with them. The proposed > mechanism won't handle these, and anyone who can handle these > doesn't need > extlang. I think this argument is flawed in that it neglects the cost of supporting such constellations of languages. There are already some messes that we're stuck with, and that have to be handled in an ad hoc manner. This doesn't justify requiring ad hoc handling for every other such constellation of languages. > 2. With the Macrolanguage field, there is sufficient information > for *anyone* who wants to to implement extlang-like fallback > (including for > sh or no), *without* encumbering the IDs with superfluous information. This would be a compelling argument, if fallback were the sole reason for extlang. However, fallback is not the sole motivation for extlangs; they are also of use to taggers with incomplete knowledge of the languages used in the materials they are tagging. The library staff in my home town would be doing well if they correctly recognized material as "zh" or "ar". It would be quite unrealistic to expect them to be any more precise. Of course we'd all like everyone who has to tag material to have perfect knowledge of the languages involved so that tags with sufficient precision and accuracy would be used. But we also know that in reality people work with incomplete knowledge. Consequently, I think we should allow people to who by necessity tag with low precision to nonetheless do so accurately. > > > 2. it is sufficiently better to warrant making the language tags more > > > complicated by the addition of this mechanism. > > > > Language tags become more complicated *if* it is desired to make them > > so. Those who find "zh" sufficient may continue to use it while still > > interoperating with "zh-cmn", "zh-yue", and so on. Existing deployed > > matchers will continue to work, as will existing deployed software > > that understands specific tags; they will not need to become more > > complicated to understand the out-of-band relationship between "zh", > > "cmn", "yue", etc. > > > This is untrue. As soon as we implemented extlang in prototype, we ran into > the problems listed above. It *didn't* work out of the box. I'm missing something. Precisely what scenario was it that was expected to work that did not? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 18:35: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 1IQ9f0-0003X0-Ac; Tue, 28 Aug 2007 18:35:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9ez-0003SA-5v for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9ey-0003PZ-Pk for ltru@ietf.org; Tue, 28 Aug 2007 18:35:44 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ9ex-0003kr-Fm for ltru@ietf.org; Tue, 28 Aug 2007 18:35:44 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IQ9eq-0002Lv-L3; Tue, 28 Aug 2007 18:35:36 -0400 Date: Tue, 28 Aug 2007 18:35:36 -0400 To: Mark Davis Message-ID: <20070828223536.GB31670@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: LTRU Working Group Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Not single-handedly: Addison has also commented on it. AFAIK he has acquiesced in, but not defended, your position. (I may be wrong.) > And on the other side, I've heard 3 strong proponents. So not exactly > overwhelming either way. FWIW, I have heard privately from several normally active listmembers supporting my position. I assume that you know I wouldn't lie about this. > I've said before, and will say again: it was never a foregone conclusion. I have never said so. I do say that it is the status quo, and it's a change to the status quo that requires defending. > Do I really have to repeat this over and over???? Alas, we do seem to be looping. I wish I saw the way ahead. > 1. The macrolanguage is always a better fallback for every encompassed > language than other alternatives. Out of the many encompassed languages, you > implying that a speaker of every encompassed language will be able to > understand the macrolanguage, or at least better than the alteratives. RFC 1766 already said that fallback doesn't always work, and sometimes produces something unintelligible to the requester. But I believe you are misusing the term "macrolanguage". A macrolanguage is not to be equated with a "main" or standardized variety. Some macrolanguages like Chinese and Arabic have such varieties, others like Quechua and Nahuatl do not. Rather, a macrolanguage is a group of languages that *in some domain* is recognized as a single language. By definition, if you speak Sudan Arabic, you are speaking something that is part of the Arabic macrolanguage, even if you cannot speak modern standard Arabic at all. Thus it may be empirically sound to assume that anything (or at least any text) tagged "ar" is in MSA, it is not certain. > 1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and > the SG; falling back from ar-arb-SA to 'ar' loses the "SA". So it does. > 2. It introduces ambiguous language names. Right now, in the > overwhelming majority of practice, standard Arabic is "ar"; after the > change, standard Arabic is "ar-arb". You propose in the alternative that "ar" and "arb" both be understood as modern standard Arabic. I submit that that is worse. > 1. Anyone who has to deal with language issues on all but a trivial > level must already have a mechanism to deal with sh, sr, hr; > with no, nb, nn. Those are macrolanguages and encompassed > languages. They exist right now WITHOUT an extlang mechanism, > and people deal with them. The proposed mechanism won't handle > these, and anyone who can handle these doesn't need extlang. True, but not everyone does. As I have said before, the majority of language-sensitive applications, I believe, deal only with recognizing a short list of languages that they know what to do with, and all others have the semantics of "unknown language". It's perfectly compliant just to look at the first subtag, decide if it is 'en', 'fr', or 'ar', and throw away all other information; furthermore, I believe this to be typical. Most applications just don't involve processing almost every document known to man. I want this sort of application to continue to work without having to be modified to add "arb" as a fourth alternative. > 2. With the Macrolanguage field, there is sufficient information > for *anyone* who wants to to implement extlang-like fallback > (including for sh or no), *without* encumbering the IDs with > superfluous information. I support the Macrolanguage: field for the uses which you mention. Furthermore, I support extlangs *only* in the context of using newly introduced 639-3 identifiers that are encompassed by a macrolanguage registered in 639-2. Thus, I do *not* support changes to language tags based on shifting macrolanguage information as SIL learns more, just the 350+ specific code elements of 639-3, and no more. > This is untrue. As soon as we implemented extlang in prototype, we ran into > the problems listed above. It *didn't* work out of the box. I can well understand that in certain applications having an unusual breadth of scope, both in the matter of documents and in the matter of languages, that it might well not. -- 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 Aug 28 18:36: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 1IQ9fz-0005qu-M9; Tue, 28 Aug 2007 18:36:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9fx-0005ju-Md for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:36:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9fx-0005iz-Bm for ltru@ietf.org; Tue, 28 Aug 2007 18:36:45 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ9fx-0002gV-0w for ltru@ietf.org; Tue, 28 Aug 2007 18:36:45 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IQ9fw-0002OU-O2; Tue, 28 Aug 2007 18:36:44 -0400 Date: Tue, 28 Aug 2007 18:36:44 -0400 To: Mark Davis Subject: Re: [Ltru] extlang straw poll Message-ID: <20070828223644.GC31670@mercury.ccil.org> References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > 1. Strongly favor having extlang I fall in this camp, of course, but with the caveat noted in my previous posting: once and only once, no further changes after RFC 4646bis adoption. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Historians aren't constantly confronted with people who carry on self-confidently about the rule against adultery in the sixth amendment to the Declamation of Independence, as written by Benjamin Hamilton. Computer scientists aren't always having to correct people who make bold assertions about the value of Objectivist Programming, as examplified in the HCNL entities stored in Relaxational Databases. --Mark Liberman _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 18:43: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 1IQ9lz-00028V-FV; Tue, 28 Aug 2007 18:42:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9lx-00028P-UC for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:42:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9lx-00028G-JE for ltru@ietf.org; Tue, 28 Aug 2007 18:42:57 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ9lx-0002on-2W for ltru@ietf.org; Tue, 28 Aug 2007 18:42:57 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WHEdWBWykWtqMWu+zgMkoPP20FzNFDJottypo0IzGIoRccss1c4l0PlREmTMdBUK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQ9lu-0002I9-6v for ltru@ietf.org; Tue, 28 Aug 2007 18:42:54 -0400 Message-ID: <003501c7e9c5$1e696040$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> Subject: Re: [Ltru] extlang straw poll Date: Tue, 28 Aug 2007 15:45:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356c4d14042668d1676213c7d201638a86a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair... >From a process perspective, while I like getting a sense of whether we have any contributors in the "can't live with" or "can't live without" camps, I'm afraid that "having extlang" needs to be teased apart a little more carefully first. The devils are generally in the details, and at this point it's still not clear to me whether objections are to the concept itself or to details of the current proposal. For example, some might have lingering worries about having more than one way to tag a language, or what the consequences for sgn- might be if extlang is removed. Consequently, we need to be sure we understand what the current proposal for extlang really means, and work through any suggestions for modifying it, before we can address the question of whether to eliminate it altogether. Randy > From: "Mark Davis" > To: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 3:04 PM > Subject: [Ltru] extlang straw poll > > As a straw poll, where do people stand on extlang? That is, vis-a-vis the > question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do > you: > > 1. Strongly favor having extlang > 2. Favor having extlang, but don't mind too much if it were not in > 3. Don't care much either way > 4. Favor not having extlang, but don't mind too much if it were in > 5. Strongly favor not having extlang > > Mark > -------------------------------------------------------------------------------- > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 18:51: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 1IQ9tq-0006Nm-It; Tue, 28 Aug 2007 18:51:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQ9tp-0006Nf-PZ for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 18:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9tp-0006NX-Fp for ltru@ietf.org; Tue, 28 Aug 2007 18:51:05 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ9to-00044B-7P for ltru@ietf.org; Tue, 28 Aug 2007 18:51:05 -0400 Received: by an-out-0708.google.com with SMTP id b6so280553ana for ; Tue, 28 Aug 2007 15:51:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=JXrgz6hgF2nUu42Ptih4PRCaLQqTAer8mS8KY+V2/RaqUlm1gGLC78HHQ9GkIiV7SpS2yLMCRmWbT51jMv/CqGxsS79+iHenHeu/S/J3xiomkfM4l66+5hQQp8tVCoAGqqrkuRy6duU2A5OVYt2cKNiNmGT++sbcSLlK3M7zN+0= 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=FXB3e5MxGr2AQaeXNrmPc1oFEypyVgnTGEVz868DfD+pe9FrpLE5ON/5hjxe6iCME9ET7OvOJwa3ia1tFARV9a2U03VmdmavfcNOsgOG7xJBDAD+cFjqV3PJSTWJaH+VzWa6+Xq8kLEal9zQgKNXWVIrQuPA0a4/96kziRU61iw= Received: by 10.114.190.6 with SMTP id n6mr2409waf.1188341462631; Tue, 28 Aug 2007 15:51:02 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 15:51:02 -0700 (PDT) Message-ID: <30b660a20708281551w32726462i8c4a32e700ef01de@mail.gmail.com> Date: Tue, 28 Aug 2007 15:51:02 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] extlang straw poll In-Reply-To: <003501c7e9c5$1e696040$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> <003501c7e9c5$1e696040$6801a8c0@oemcomputer> X-Google-Sender-Auth: c49b980c852baf69 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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="===============1052750571==" Errors-To: ltru-bounces@ietf.org --===============1052750571== Content-Type: multipart/alternative; boundary="----=_Part_104109_9587000.1188341462603" ------=_Part_104109_9587000.1188341462603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline If you don't want to have a straw poll at this point that's fine. But then John needs to stop saying I'm the only one standing in the way of the train ;-) Mark On 8/28/07, Randy Presuhn wrote: > > Hi - > > As co-chair... > > >From a process perspective, while I like getting a sense of whether we > have > any contributors in the "can't live with" or "can't live without" camps, > I'm afraid that "having extlang" needs to be teased apart a little more > carefully first. The devils are generally in the details, and at this > point it's still not clear to me whether objections are to the concept > itself or to details of the current proposal. For example, some might > have lingering worries about having more than one way to tag a language, > or > what the consequences for sgn- might be if extlang is > removed. Consequently, > we need to be sure we understand what the current proposal for extlang > really > means, and work through any suggestions for modifying it, before we can > address > the question of whether to eliminate it altogether. > > Randy > > > From: "Mark Davis" > > To: "LTRU Working Group" > > Sent: Tuesday, August 28, 2007 3:04 PM > > Subject: [Ltru] extlang straw poll > > > > As a straw poll, where do people stand on extlang? That is, vis-a-vis > the > > question of using extlang in RFC4646bis to contain 639-3 macrolanguages, > do > > you: > > > > 1. Strongly favor having extlang > > 2. Favor having extlang, but don't mind too much if it were not in > > 3. Don't care much either way > > 4. Favor not having extlang, but don't mind too much if it were in > > 5. Strongly favor not having extlang > > > > Mark > > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > 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_104109_9587000.1188341462603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline If you don't want to have a straw poll at this point that's fine. But then John needs to stop saying I'm the only one standing in the way of the train ;-)

Mark

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

As co-chair...

>From a process perspective, while I like getting a sense of whether we have
any contributors in the "can't live with" or "can't live without" camps,
I'm afraid that "having extlang" needs to be teased apart a little more
carefully first.  The devils are generally in the details, and at this
point it's still not clear to me whether objections are to the concept
itself or to details of the current proposal.  For example, some might
have lingering worries about having more than one way to tag a language, or
what the consequences for sgn- might be if extlang is removed.  Consequently,
we need to be sure we understand what the current proposal for extlang really
means, and work through any suggestions for modifying it, before we can address
the question of whether to eliminate it altogether.

Randy

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "LTRU Working Group" <ltru@ietf.org >
> Sent: Tuesday, August 28, 2007 3:04 PM
> Subject: [Ltru] extlang straw poll
>
> As a straw poll, where do people stand on extlang? That is, vis-a-vis the
> question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do
> you:
>
>    1. Strongly favor having extlang
>    2. Favor having extlang, but don't mind too much if it were not in
>    3. Don't care much either way
>    4. Favor not having extlang, but don't mind too much if it were in
>    5. Strongly favor not having extlang
>
> Mark
>


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


> _______________________________________________
> 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_104109_9587000.1188341462603-- --===============1052750571== 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 --===============1052750571==-- From ltru-bounces@ietf.org Tue Aug 28 19:01: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 1IQA3h-0005Aq-Ob; Tue, 28 Aug 2007 19:01:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQA3g-0005Al-Uk for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 19:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQA3g-0005Ac-L5 for ltru@ietf.org; Tue, 28 Aug 2007 19:01:16 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQA3f-0004Ie-B5 for ltru@ietf.org; Tue, 28 Aug 2007 19:01:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RbT1sG6LWqHbN1gPRoREEFMbJe9EMipX84RNI9+F4Ol9s+39Av2HbgnMRi4ovwiY; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.252] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQA3e-0004O1-Ma for ltru@ietf.org; Tue, 28 Aug 2007 19:01:15 -0400 Message-ID: <000701c7e9c7$ae6b9bc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> <003501c7e9c5$1e696040$6801a8c0@oemcomputer> <30b660a20708281551w32726462i8c4a32e700ef01de@mail.gmail.com> Subject: Re: [Ltru] extlang straw poll Date: Tue, 28 Aug 2007 16:03:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935635a32efe5f75b7f5b494dd3178d98635350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 3:51 PM > Subject: Re: [Ltru] extlang straw poll > > If you don't want to have a straw poll at this point that's fine. ... As Co-chair: Everyone has a homework item: look at the *current* extlang text. If you have specific suggestions for changes to it, post them to this mailing list *THIS WEEK*. By this weekend (September 1) we should have the "this is as good as it gets" text (at least in email) for extlang. About September 5 we should be able to do the straw poll, if a rough consensus hasn't already emerged from the discussion. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 21:12: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 1IQC6Q-0003Yi-Mf; Tue, 28 Aug 2007 21:12:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQC6O-0003Yc-TH for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 21:12:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQC6O-0003YR-HX for ltru@ietf.org; Tue, 28 Aug 2007 21:12:12 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQC6N-00076L-Je for ltru@ietf.org; Tue, 28 Aug 2007 21:12:12 -0400 Received: by wa-out-1112.google.com with SMTP id k40so4892wah for ; Tue, 28 Aug 2007 18:12:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=KXts8PuA42vKRvEv4Ti3FcU3NVy0301vEr7vYvQGdkz7HAthDjuLmP0DdBw2ewT+kI3MlsDWi6no+CGITmiog3iGWH0SpcF92uEIVRjXkq4I/teSK74rO5MGZ2Dedt9uoFOwi6427lRRqqUePcla/GUqcR6S4N03D209RqkOrhQ= 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=jah2rp9oqeFwP/UMkUY6flP52r4hE0groW3OdnaS1nBvuBVGPleKieEbuhdnzXJDxNN7nOc7UNswRrt7qaGBdRvR8pAXIkM+vljH1pmoXnP/vsiZgOTyWXNC91WQDhtCM/otxDNjTXbWRBV8atbGYwOw7LxFFyG5sF4o+5+6tGY= Received: by 10.114.95.1 with SMTP id s1mr24236wab.1188349930495; Tue, 28 Aug 2007 18:12:10 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 18:12:10 -0700 (PDT) Message-ID: <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> Date: Tue, 28 Aug 2007 18:12:10 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <20070828223536.GB31670@mercury.ccil.org> MIME-Version: 1.0 References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> X-Google-Sender-Auth: 0e07330a814c19ba X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: LTRU Working Group Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1970632107==" Errors-To: ltru-bounces@ietf.org --===============1970632107== Content-Type: multipart/alternative; boundary="----=_Part_105216_13446033.1188349930450" ------=_Part_105216_13446033.1188349930450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > RFC 1766 already said that fallback doesn't always work, and sometimes > produces something unintelligible to the requester. > > But I believe you are misusing the term "macrolanguage". A macrolanguage > is not to be equated with a "main" or standardized variety. Some > macrolanguages like Chinese and Arabic have such varieties, others like > Quechua and Nahuatl do not. I'm not misusing it -- nothing I said had anything to do with the definition, it has to do with the functional implications. If a language yyy has the macrolanguage xx, we are talking about two possible representations a) extlang: xx-yyy b) lang: yyy The main reason I've heard from you for doing (a) instead of (b) is that (a) it has better fallback behavior. For that to be true, xx has to be a good fallback for users of yyy, in the majority of cases. And the value has to be worth having the extra structure. So, a natural question to ask is: are you sure that of ALL the languages on http://www.sil.org/iso639-3/macrolanguages.asp, the ones that we are talking about this mechanism for, that the fallback is indeed good. I really want some reasonable attention paid to the implications of this whole apparatus before we ship this, because once we do, it is irrevocable! There are (at least) two cases to consider here. 1. There is a predominent choice in the industry for the macro language. For example, the content for zh is typically always Mandarin; the content for ar is typically always standard Arabic. Look at the concrete implications. It means that whenever Joe looks for a web page in Hakka Chinese, he will typically fall back to Mandarin. Whenever Sarah looks for a page in Tunisian Arabic, it will fall back to standard Mandarin. If you are saying however, that zh is not necessarily Mandarin, that Arabic is not necessarily Standard Arabic, then we fall through to case 2. 2. There is not a predominant choice in the industry, let's say for Hmong. In this case, the situation is different. I could choose any of the Hmong for the content for hmn. We then have an even dicer case for the value of extlang. I localize my hmn locale with contents appropriate for Northeastern Dian Hmong; is that a good default for someone speaking Eastern Xiangxi Hmong? for Luopohe Hmong? For all the other Hmongs? For extlang to be a good apparatus, these always have to be good choices, since we are baking the structure into the tag. If Peter Constable came out and said the following, then I would admit to my sins, give in gracefully, and go along with extlang. - "Yes, each of the Hmongs (encompassed by hmn) are mutually intelligible, and are better for each one than another fallback like Chinese" - and the same is true for all the other cases with no predominant variant. - "Yes, standard Arabic is intelligible for all the encompassed languages from Algerian Saharan Arabic to Shihhi Arabic, and are better for each one than another fallback like French" - and the same is true for all the other cases with a predominant variant. Mark ------=_Part_105216_13446033.1188349930450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
RFC 1766 already said that fallback doesn't always work, and sometimes
produces something unintelligible to the requester.

But I believe you are misusing the term "macrolanguage".  A macrolanguage
is not to be equated with a "main" or standardized variety.  Some
macrolanguages like Chinese and Arabic have such varieties, others like
Quechua and Nahuatl do not.

I'm not misusing it -- nothing I said had anything to do with the definition, it has to do with the functional implications. If a language yyy has the macrolanguage xx, we are talking about two possible representations

a) extlang: xx-yyy
b) lang: yyy

The main reason I've heard from you for doing (a) instead of (b) is that (a) it has better fallback behavior. For that to be true, xx has to be a good fallback for users of yyy, in the majority of cases. And the value has to be worth having the extra structure. So, a natural question to ask is: are you sure that of ALL the languages on http://www.sil.org/iso639-3/macrolanguages.asp , the ones that we are talking about this mechanism for, that the fallback is indeed good.

I really want some reasonable attention paid to the implications of this whole apparatus before we ship this, because once we do, it is irrevocable!

There are (at least) two cases to consider here.

  1. There is a predominent choice in the industry for the macro language. For example, the content for zh is typically always Mandarin; the content for ar is typically always standard Arabic. Look at the concrete implications. It means that whenever Joe looks for a web page in Hakka Chinese, he will typically fall back to Mandarin. Whenever Sarah looks for a page in Tunisian Arabic, it will fall back to standard Mandarin.

    If you are saying however, that zh is not necessarily Mandarin, that Arabic is not necessarily Standard Arabic, then we fall through to case 2.
     
  2. There is not a predominant choice in the industry, let's say for Hmong. In this case, the situation is different. I could choose any of the Hmong for the content for hmn. We then have an even dicer case for the value of extlang. I localize my hmn locale with contents appropriate for Northeastern Dian Hmong; is that a good default for someone speaking Eastern Xiangxi Hmong? for Luopohe Hmong? For all the other Hmongs?

For extlang to be a good apparatus, these always have to be good choices, since we are baking the structure into the tag.

If Peter Constable came out and said the following, then I would admit to my sins, give in gracefully, and go along with extlang.
  • "Yes, each of the Hmongs (encompassed by hmn) are mutually intelligible, and are better for each one than another fallback like Chinese"
    • and the same is true for all the other cases with no predominant variant.
  • "Yes, standard Arabic is intelligible for all the encompassed languages from Algerian Saharan Arabic to Shihhi Arabic, and are better for each one than another fallback like French"
    • and the same is true for all the other cases with a predominant variant.
Mark
------=_Part_105216_13446033.1188349930450-- --===============1970632107== 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 --===============1970632107==-- From ltru-bounces@ietf.org Tue Aug 28 22:40: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 1IQDU3-0001gC-SO; Tue, 28 Aug 2007 22:40:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQDU2-0001fm-Mi for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQDU2-0001fW-D1 for ltru@ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQDU0-0001dq-Fy for ltru@ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T2eaAl000558 for ; Wed, 29 Aug 2007 11:40:36 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 722f_38afeb74_55d9_11dc_9422_0014221fa3c9; Wed, 29 Aug 2007 11:40:35 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47160) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 11:37:42 +0900 Message-Id: <6.0.0.20.2.20070829112728.09e2d3d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 11:32:29 +0900 To: Marion Gunn , LTRU Working Group From: Martin Duerst Subject: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) In-Reply-To: <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by scmailgw2.scop.aoyama.ac.jp id l7T2eaAl000558 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: In addition to my previous statement (leave things alone), I have to agree with Marion that "on our planet" can go. We even had English spoken on the Moon, and nobody would want to claim that our work can't be used to tag utterances made on the Moon, or maybe in the distant future on Mars. Regards, Martin. At 04:02 07/08/29, Marion Gunn wrote: >First impressions are important, so - however long that particular =20 >expression has been in there - it is common knowledge that texts =20 >starting "on our planet" tend not to be taken seriously and that such =20 >expressions tend only detract/distract somewhat, from the substance =20 >of a document without adding anything of substance to it. By all =20 >means leave it in, if you disagree with the above. > >For ease of reference and for the sake of new readers, I'd also like =20 >to see "Definitions" fronted in the document, pace the ISO practice =20 >of fronting "Scope" and "Definitions", and to see "extlang" defined =20 >under "Definitions", as one of the many relevant terms (defined as a =20 >group of concepts) to be grasped, before describing how all those =20 >bits are meant to work together. If this means cutting and pasting in =20 >definitions straight out of other documents, that is fine and good =20 >for consistency checks across documents. > >I didn't address the question of handling extlangs simply because I =20 >am currently not at all sure how to do so. >mg > >On 28 Aug 2007, at 13:53, scr=1B$ByP=1B(Bbh Addison Phillips: > >> Marion, >> >> This text has existed for a long time. In fact, it is taken =20 >> verbatim from RFC 3066 (RFC 1766 had a similar, but different, =20 >> sentence). This isn't a substantive edit and doesn't address the =20 >> real open issue in our draft, which is how to handle extlangs. >> >> Regards, >> >> Addison > >- - >Marion Gunn * EGTeo (Estab.1991) >27 P=1B$BaJ=1B(Brc an Fh=1B$BqJ=1B(Bthlinn, Baile an >Bh=1B$B=85U=1B(Bhair, Co. =1B$B%A=1B(Btha Cliath, =1B$B%N=1B(Bire. >* mgunn@egt.ie * eamonn@egt.ie * > > > >_______________________________________________ >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 = =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 22:40: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 1IQDU3-0001g8-PY; Tue, 28 Aug 2007 22:40:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQDU2-0001fl-Md for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQDU2-0001fV-Cr for ltru@ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQDU0-0001dr-G0 for ltru@ietf.org; Tue, 28 Aug 2007 22:40:42 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T2eY7f000557 for ; Wed, 29 Aug 2007 11:40:36 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5d13_37dd5d8a_55d9_11dc_9052_0014221f2a2d; Wed, 29 Aug 2007 11:40:34 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47160) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 11:37:40 +0900 Message-Id: <6.0.0.20.2.20070829112259.09e313c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 11:25:14 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] first paragraph of draft-ietf-ltru-rfc4646bis-08 In-Reply-To: <005601c7e993$e2e262a0$6801a8c0@oemcomputer> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> <005601c7e993$e2e262a0$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 agree with Randy. The proposal makes the text more precise, but this is at the start of the Introduction, where being more and more precise ultimately leads to writing the spec again. So my opinion is: leave it as is, details will follow, and everybody who has a bit of understanding of how documents are written (in particular, that the intro is general, and details will follow) will know that. Regards, Martin. At 01:52 07/08/29, Randy Presuhn wrote: >Hi - > >As co-chair... > >We work by rough consensus. The assessment whether a proposed >edit needs to be made is up to the WG. If a change is agreed >(and I'm not saying this particular one has been) the editors >need to implement it, whether they personally agree with it or not. >So while as a technical contributor you're certainly expected to >give your views, to avoid confusion please make it clear whether >you're commenting as a technical contributor or as an editor. > >As a technical contributor: > >While I'm not fond of the existing >text, I also haven't seen a convincing rationale that removing >it would help (or hurt) anything. As for the proposed change, >I think tacking on the addtional text with a comma would result >in an awkward run-on sentence. If we were to make a change, >I'd want the added text to be sentence in its own right. My >net position: leave it alone. It's not sufficiently broken. > >Randy > >----- Original Message ----- >From: "Addison Phillips" >To: "Marion Gunn" >Cc: "LTRU Working Group" >Sent: Tuesday, August 28, 2007 6:53 AM >Subject: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08 > > >Marion, > >This text has existed for a long time. In fact, it is taken verbatim >from RFC 3066 (RFC 1766 had a similar, but different, sentence). This >isn't a substantive edit and doesn't address the real open issue in our >draft, which is how to handle extlangs. > >Regards, > >Addison > >Marion Gunn wrote: >> For starters, suggest losing the entire first sentence of paragraph 1 >> below, inserting the word "human" before "language" in its second >> sentence and inserting the following comma-plus-clause text ", such >> reasons as are set out below" before its closing full stop. >> mg >> >> >> On 24 Aug 2007, at 21:59, scr$B%F%e(Bobh Addison Phillips: >> >> >>> Phillips & Davis Expires February 25, 2008 [Page 3] >>> Internet-Draft langtags-registry August 2007 >>> >>> >>> 1. Introduction >>> >>> Human beings on our planet have, past and present, used a number of >>> languages. There are many reasons why one would want to identify the >>> language used when presenting or requesting information. >>> >>> >> >> -- >> Marion Gunn >> mgunn@ucd.ie >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. >Chair -- W3C Internationalization Core WG > >Internationalization is an architecture. >It is not a feature. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# 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 Aug 28 22:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQDU5-0001hS-Vn; Tue, 28 Aug 2007 22:40:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQDU3-0001g3-HI for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 22:40:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQDU3-0001fv-6N for ltru@ietf.org; Tue, 28 Aug 2007 22:40:43 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQDU2-00011B-DT for ltru@ietf.org; Tue, 28 Aug 2007 22:40:43 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T2eckR000566 for ; Wed, 29 Aug 2007 11:40:38 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5d13_3a57a2dc_55d9_11dc_9052_0014221f2a2d; Wed, 29 Aug 2007 11:40:38 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47160) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 11:37:44 +0900 Message-Id: <6.0.0.20.2.20070829113233.09e33380@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 11:38:40 +0900 To: Marion Gunn , LTRU Working Group From: Martin Duerst Subject: Definitions (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) In-Reply-To: <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by scmailgw2.scop.aoyama.ac.jp id l7T2eckR000566 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org as a technical contributor: If we got a lot of requests from new readers for a definition section, I would be all for it. But as this creates more work for our editors, I'll leave it to them. I think our draft in general is easy to use: if you want to know about a particular topic such as extlangs, go to the relevant subsection. My experience with ISO-style definitions is that they are often circular, and it's often only after reading the rest of the document that you actually start to really understand them. Putting them at the front is mostly just a convention, they could be at the end, to. One benefit is that it helps spec writers to try things through, but the IETF has other ways of trying to make sure that the specs really work. Regards, Martin. At 04:02 07/08/29, Marion Gunn wrote: >For ease of reference and for the sake of new readers, I'd also like =20 >to see "Definitions" fronted in the document, pace the ISO practice =20 >of fronting "Scope" and "Definitions", and to see "extlang" defined =20 >under "Definitions", as one of the many relevant terms (defined as a =20 >group of concepts) to be grasped, before describing how all those =20 >bits are meant to work together. If this means cutting and pasting in =20 >definitions straight out of other documents, that is fine and good =20 >for consistency checks across documents. > >I didn't address the question of handling extlangs simply because I =20 >am currently not at all sure how to do so. >mg > >On 28 Aug 2007, at 13:53, scr=1B$ByP=1B(Bbh Addison Phillips: > >> Marion, >> >> This text has existed for a long time. In fact, it is taken =20 >> verbatim from RFC 3066 (RFC 1766 had a similar, but different, =20 >> sentence). This isn't a substantive edit and doesn't address the =20 >> real open issue in our draft, which is how to handle extlangs. >> >> Regards, >> >> Addison > >- - >Marion Gunn * EGTeo (Estab.1991) >27 P=1B$BaJ=1B(Brc an Fh=1B$BqJ=1B(Bthlinn, Baile an >Bh=1B$B=85U=1B(Bhair, Co. =1B$B%A=1B(Btha Cliath, =1B$B%N=1B(Bire. >* mgunn@egt.ie * eamonn@egt.ie * > > > >_______________________________________________ >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 = =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 23:59: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 1IQEig-0004aV-HO; Tue, 28 Aug 2007 23:59:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQEif-0004a8-Nh for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEif-0004Zp-DI for ltru@ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQEie-0002gp-Pe for ltru@ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T3xpxI009973 for ; Wed, 29 Aug 2007 12:59:51 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7171_4ad24cba_55e4_11dc_9a8e_0014221fa3c9; Wed, 29 Aug 2007 12:59:50 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 12:56:57 +0900 Message-Id: <6.0.0.20.2.20070829115711.05bc15b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 12:00:41 +0900 To: John Cowan , Mark Davis From: Martin Duerst Subject: Re: [Ltru] Re: extlang In-Reply-To: <20070828223536.GB31670@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@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: 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 07:35 07/08/29, John Cowan wrote: >Mark Davis scripsit: >> I've said before, and will say again: it was never a foregone conclusion. > >I have never said so. I do say that it is the status quo, and it's >a change to the status quo that requires defending. chair hat on: Given the importance and controversy over the subject, any assumtion either way of a 'default' would be bad process. What we need to do is to try to find the technically best solution, for a wide variety of applications. 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 Aug 28 23:59: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 1IQEii-0004cA-KA; Tue, 28 Aug 2007 23:59:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQEif-0004aD-UN for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEif-0004Zx-JJ for ltru@ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQEie-0002gk-Pc for ltru@ietf.org; Tue, 28 Aug 2007 23:59:53 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T3xnxh009963 for ; Wed, 29 Aug 2007 12:59:49 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 725d_499e53e8_55e4_11dc_9956_0014221fa3c9; Wed, 29 Aug 2007 12:59:48 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 12:56:55 +0900 Message-Id: <6.0.0.20.2.20070829115031.05bc12f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 11:53:48 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] extlang straw poll In-Reply-To: <003501c7e9c5$1e696040$6801a8c0@oemcomputer> References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> <003501c7e9c5$1e696040$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I fully agree with Randy on this and his follow-up mail. For all WG members, please leave assessments of consensus (starting with statements such as "only one person is in favor of XYZ") as well as conducting straw polls to the co-chairs. If you think that that an assessment of consensus is possible and necessary, or a straw poll is in order, please ask the co-chairs to do it. If you don't get any response after a reminder, please feel free to ping the AD (you don't need to make this an appeal!). Regards, Martin. At 07:45 07/08/29, Randy Presuhn wrote: >Hi - > >As co-chair... > >>From a process perspective, while I like getting a sense of whether we have >any contributors in the "can't live with" or "can't live without" camps, >I'm afraid that "having extlang" needs to be teased apart a little more >carefully first. The devils are generally in the details, and at this >point it's still not clear to me whether objections are to the concept >itself or to details of the current proposal. For example, some might >have lingering worries about having more than one way to tag a language, or >what the consequences for sgn- might be if extlang is removed. Consequently, >we need to be sure we understand what the current proposal for extlang really >means, and work through any suggestions for modifying it, before we can address >the question of whether to eliminate it altogether. > >Randy > >> From: "Mark Davis" >> To: "LTRU Working Group" >> Sent: Tuesday, August 28, 2007 3:04 PM >> Subject: [Ltru] extlang straw poll >> >> As a straw poll, where do people stand on extlang? That is, vis-a-vis the >> question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do >> you: >> >> 1. Strongly favor having extlang >> 2. Favor having extlang, but don't mind too much if it were not in >> 3. Don't care much either way >> 4. Favor not having extlang, but don't mind too much if it were in >> 5. Strongly favor not having extlang >> >> Mark >> > > >-------------------------------------------------------------------------------- > > >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 28 23:59: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 1IQEii-0004cZ-NM; Tue, 28 Aug 2007 23:59:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQEih-0004b5-BO for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEih-0004aa-1R for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQEif-00036R-5R for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T3xnNp020199 for ; Wed, 29 Aug 2007 12:59:49 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 724f_4a23c104_55e4_11dc_843d_0014221fa3c9; Wed, 29 Aug 2007 12:59:49 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 12:56:56 +0900 Message-Id: <6.0.0.20.2.20070829115411.05bc1d00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 11:56:58 +0900 To: "Mark Davis" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] extlang In-Reply-To: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.co m> References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 07:04 07/08/29, Mark Davis wrote: >As a straw poll, where do people stand on extlang? That is, vis-a-vis the question of using extlang in RFC4646bis to contain 639-3 macrolanguages, do you: > * Strongly favor having extlang > * Favor having extlang, but don't mind too much if it were not in > * Don't care much either way > * Favor not having extlang, but don't mind too much if it were in > * Strongly favor not having extlang To give my technical opinion, at the moment, my understanding would be: it depends. For some languages/language families (in particular ar, zh, and probably sng), extlangs seem preferable. For others, probably not. But we'll have an official straw poll anyway after having hashed out 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 Aug 28 23:59: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 1IQEii-0004dd-Qp; Tue, 28 Aug 2007 23:59:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQEih-0004bQ-Mq for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEih-0004bA-Ch for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQEif-00036U-QC for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T3xq6c020210 for ; Wed, 29 Aug 2007 12:59:52 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5df7_4bd67492_55e4_11dc_8922_0014221f2a2d; Wed, 29 Aug 2007 12:59:52 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 12:56:58 +0900 Message-Id: <6.0.0.20.2.20070829120052.05bc6e60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 12:11:43 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] extlang In-Reply-To: <001501c7e9c3$71f00b80$6801a8c0@oemcomputer> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <001501c7e9c3$71f00b80$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 quite agree with Randy. See below for more details. At 07:33 07/08/29, Randy Presuhn wrote: >Hi - > >As a technical contributor... > >> From: "Mark Davis" >> To: "John Cowan" >> Cc: "LTRU Working Group" >> Sent: Tuesday, August 28, 2007 2:59 PM >> Subject: [Ltru] extlang >... >> You are not revealing some important hidden assumptions in your statements. >> >> 1. The macrolanguage is always a better fallback for every encompassed >> language than other alternatives. Out of the many encompassed languages, you >> implying that a speaker of every encompassed language will be able to >> understand the macrolanguage, or at least better than the alteratives. > >I don't see how the use of extlang would require this as an assumption. >Making such an assumption seems a bit like assuming that all languages whose >tags begin in "a" are somehow related. > >> 2. People don't lose anything by having the fallback. I dispute this >> as well. As previously noted: >> 1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and >> the SG; falling back from ar-arb-SA to 'ar' loses the "SA". > >It is the nature of truncation fallback to lose information. No matter >what order the subtags are trimmed off, someone will be able to argue >that for some particular case, a different order might have been better. >This isn't an argument against extlang; it's an argument against unrealistically >high expectations for truncation fallback. > >> 2. It introduces ambiguous language names. Right now, in the >> overwhelming majority of practice, standard Arabic is "ar"; after the >> change, standard Arabic is "ar-arb". > >This would not be desirable. However, I wonder whether the semantic associated >by most taggers and users of tags with "ar" is "standard Arabic" or merely >"Arabic". Well, probably both ways. Most written Arabic is standard Arabic, I guess, so even if you assume "ar" just means "whatever Arabic it means", most stuff tagged "ar" will be Standard Arabic. The question is whether we can make that assumption stronger, or whether we can live with such an uncertainity. I think to some extent, we have always done this. As an example, "ja" means Japanese, but it also, by suppress-script, means Japanese written in Kanji-Kana-mixture, and it also, by "tag wisely", means Japanese as used in Japan. In general, "tag wisely" seems to include "tag special cases very precisely, general cases can be tagged more shortly". So in practice using ar rather than ar-arb for Standard Arabic seems to be extremely feasible. The question may be how we can say that in our draft without contradicting ourselves, and/or how we can help practice moving that way even if we don't say so in the spec. >> 3. People can't get along without this. >> 1. Anyone who has to deal with language issues on all but a trivial >> level must already have a mechanism to deal with sh, sr, hr; with no, nb, >> nn. Those are macrolanguages and encompassed languages. They >> exist right now >> WITHOUT an extlang mechanism, and people deal with them. The proposed >> mechanism won't handle these, and anyone who can handle these >> doesn't need >> extlang. > >I think this argument is flawed in that it neglects the cost of supporting >such constellations of languages. There are already some messes that we're >stuck with, and that have to be handled in an ad hoc manner. This doesn't >justify requiring ad hoc handling for every other such constellation of >languages. Thinking about what problems Mark actually has, it may be that what he is saying is: I know I have to deal with some things as special cases, but I'd like to limit these to single-tag cases and not to have to combine fallback code and special-case code. Mark, if this is what you are after, please confirm, and maybe give some details. Others, if that doesn't look like it would work, please give some counterexamples. Regards, Martin. >> 2. With the Macrolanguage field, there is sufficient information >> for *anyone* who wants to to implement extlang-like fallback >> (including for >> sh or no), *without* encumbering the IDs with superfluous information. > >This would be a compelling argument, if fallback were the sole reason for >extlang. >However, fallback is not the sole motivation for extlangs; they are also >of use to taggers with incomplete knowledge of the languages used in the >materials they are tagging. The library staff in my home town would be >doing well if they correctly recognized material as "zh" or "ar". It would >be quite unrealistic to expect them to be any more precise. > >Of course we'd all like everyone who has to tag material to have perfect >knowledge of the languages involved so that tags with sufficient precision >and accuracy would be used. But we also know that in reality people work >with incomplete knowledge. Consequently, I think we should allow people to >who by necessity tag with low precision to nonetheless do so accurately. > >> > > 2. it is sufficiently better to warrant making the language tags more >> > > complicated by the addition of this mechanism. >> > >> > Language tags become more complicated *if* it is desired to make them >> > so. Those who find "zh" sufficient may continue to use it while still >> > interoperating with "zh-cmn", "zh-yue", and so on. Existing deployed >> > matchers will continue to work, as will existing deployed software >> > that understands specific tags; they will not need to become more >> > complicated to understand the out-of-band relationship between "zh", >> > "cmn", "yue", etc. >> >> >> This is untrue. As soon as we implemented extlang in prototype, we ran into >> the problems listed above. It *didn't* work out of the box. > >I'm missing something. Precisely what scenario was it that was expected to >work that did not? > >Randy > > > >_______________________________________________ >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 Aug 28 23:59: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 1IQEii-0004ei-Un; Tue, 28 Aug 2007 23:59:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQEih-0004c4-To for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEih-0004bI-Hz for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQEig-0002h2-SR for ltru@ietf.org; Tue, 28 Aug 2007 23:59:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l7T3xrp8020215 for ; Wed, 29 Aug 2007 12:59:53 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7263_4c63e098_55e4_11dc_9ac5_0014221fa3c9; Wed, 29 Aug 2007 12:59:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Aug 2007 12:57:00 +0900 Message-Id: <6.0.0.20.2.20070829124940.05bc2ad0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Aug 2007 12:51:52 +0900 To: John Cowan , Mark Davis From: Martin Duerst Subject: Re: [Ltru] Re: extlang In-Reply-To: <20070828223536.GB31670@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@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: b19722fc8d3865b147c75ae2495625f2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 07:35 07/08/29, John Cowan wrote: >Mark Davis scripsit: >> 2. With the Macrolanguage field, there is sufficient information >> for *anyone* who wants to to implement extlang-like fallback >> (including for sh or no), *without* encumbering the IDs with >> superfluous information. > >I support the Macrolanguage: field for the uses which you mention. >Furthermore, I support extlangs *only* in the context of using newly >introduced 639-3 identifiers that are encompassed by a macrolanguage >registered in 639-2. Thus, I do *not* support changes to language >tags based on shifting macrolanguage information as SIL learns more, >just the 350+ specific code elements of 639-3, and no more. Hello John, I'm sure you have done so somewhere already, but for everybody to see, could you (pointer is okay) provide a list of the macrolanguages that would be handled by extlangs? (and maybe also those that wouldn't). Also, is your proposal above the same thing as what's in the current draft, or would the draft need tweaking? (My reading of Randy's collection of snippets seems to indicate that our draft would need some work.) If that's the case, can you provide some proposed text? 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 Aug 29 01:27: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 1IQG5p-00057f-BI; Wed, 29 Aug 2007 01:27:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQG5o-00057a-I1 for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 01:27:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQG5o-00057S-29 for ltru@ietf.org; Wed, 29 Aug 2007 01:27:52 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQG5n-0004Kz-MH for ltru@ietf.org; Wed, 29 Aug 2007 01:27:51 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070829052750.NWAP9920.mta10.adelphia.net@DGBP7M81> for ; Wed, 29 Aug 2007 05:27:50 +0000 Message-ID: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Tue, 28 Aug 2007 22:27:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 am in fairly weak agreement with Marion over the introductory text. The wording about human beings on our planet, past and present, has certainly been around since RFC 3066, but RFCs have become more formal in their wording (and in other ways) since then. RFC 4646 is over four times as long as 3066 and might call for a different approach. The current wording has also been parodied more than once in other documents. I'm not so sure about putting a Definitions section near the front. Like Martin, I've also had trouble with ISO documents that start me off with pages of definitions of terms I've never seen before, and no context in which to place them. Usually I look for such reference material near the end of a document, not the beginning. What is important is that all such material be in an easy-to-find place. However, at this stage it is much more important to me that we resolve the real technical debate over extlangs, and get the drafts to WG Last Call, than to engage in fine-tuning and wordsmithing at this level. The current wording doesn't cause any confusion or misinterpretation. If we weren't already half a year behind schedule, I would probably care more about this. -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 02:00:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGbo-0001N5-Pd; Wed, 29 Aug 2007 02:00:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQGbn-0001Mi-Lj for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 02:00:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGbm-0001Iu-EJ for ltru@ietf.org; Wed, 29 Aug 2007 02:00:54 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQGbm-0005ZT-3O for ltru@ietf.org; Wed, 29 Aug 2007 02:00:54 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070829060053.KIFG16016.mta9.adelphia.net@DGBP7M81> for ; Wed, 29 Aug 2007 02:00:53 -0400 Message-ID: <007301c7ea01$f59bbe00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] extlang straw poll Date: Tue, 28 Aug 2007 23:00:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Everyone has a homework item: look at the *current* extlang text. > If you have specific suggestions for changes to it, post them to > this mailing list *THIS WEEK*. By this weekend (September 1) we > should have the "this is as good as it gets" text (at least in > email) for extlang. About September 5 we should be able to do > the straw poll, if a rough consensus hasn't already emerged from > the discussion. I'll have a much better chance of addressing this properly over the weekend than during the week, especially given that it's a three-day weekend in the U.S. My gut feeling, though, is that the specific suggestion I will make is to revert the extlang/macrolanguage text to what it was in draft-ietf-ltru-4646bis-06. -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 02:11: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 1IQGlo-0001Ce-1d; Wed, 29 Aug 2007 02:11:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQGln-0001CZ-J1 for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 02:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGln-0001CR-5g for ltru@ietf.org; Wed, 29 Aug 2007 02:11:15 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQGll-0005pn-OC for ltru@ietf.org; Wed, 29 Aug 2007 02:11:15 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WhVXFZ86naV7FbeefII1SPIg9xJeY7xnpyC81S5nxhCb1/9MfjOLYJbE3EqZ4tP1; 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.81.142] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQGlk-00012A-SM for ltru@ietf.org; Wed, 29 Aug 2007 02:11:13 -0400 Message-ID: <006e01c7ea03$be82e7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com><20070828223536.GB31670@mercury.ccil.org> <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> Subject: Re: [Ltru] Re: extlang Date: Tue, 28 Aug 2007 23:13:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356b2908b6d817209a884e61b6c3af53449350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.142 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 - Forgive the extended context. My comments are inline. As a technical contributor... > From: "Mark Davis" > To: "John Cowan" > Cc: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 6:12 PM > Subject: [Ltru] Re: extlang > > > RFC 1766 already said that fallback doesn't always work, and sometimes > > produces something unintelligible to the requester. > > > > But I believe you are misusing the term "macrolanguage". A macrolanguage > > is not to be equated with a "main" or standardized variety. Some > > macrolanguages like Chinese and Arabic have such varieties, others like > > Quechua and Nahuatl do not. > > > I'm not misusing it -- nothing I said had anything to do with the > definition, it has to do with the functional implications. If a language yyy > has the macrolanguage xx, we are talking about two possible representations > > a) extlang: xx-yyy > b) lang: yyy > > The main reason I've heard from you for doing (a) instead of (b) is that (a) > it has better fallback behavior. For that to be true, xx has to be a good > fallback for users of yyy, in the majority of cases. As I see it, the qualification "in the majority of cases" is far too strong. As I see it, if there are *any* significant cases where (a) would work better, there is reason to consider that approach worth investigating. > And the value has to be > worth having the extra structure. What is the cost of the "extra structure"? > So, a natural question to ask is: are you > sure that of ALL the languages on > http://www.sil.org/iso639-3/macrolanguages.asp, the ones that we are talking > about this mechanism for, that the fallback is indeed good. I think this is a mis-statement of the argument. I think the question is whether there are any cases for which the fallback would be useful, or for which there would be other reasons (which I'd like to see spelled out somewhere) to prefer the (a) format over the (b) format. > I really want some reasonable attention paid to the implications of this > whole apparatus before we ship this, because once we do, it is irrevocable! Full agreement. > There are (at least) two cases to consider here. > > > 1. There is a predominent choice in the industry for the macro > language. For example, the content for zh is typically always Mandarin; the > content for ar is typically always standard Arabic. Look at the concrete > implications. It means that whenever Joe looks for a web page in Hakka > Chinese, he will typically fall back to Mandarin. Whenever Sarah looks for a > page in Tunisian Arabic, it will fall back to standard Mandarin. I assume the last Mandarin was Arabic. > > If you are saying however, that zh is not necessarily Mandarin, that > Arabic is not necessarily Standard Arabic, then we fall through to case 2. This is the case of what I would call "accurately but imprecisely" tagged material, > 2. There is not a predominant choice in the industry, let's say for > Hmong. In this case, the situation is different. I could choose any of the > Hmong for the content for hmn. We then have an even dicer case for the value > of extlang. I localize my hmn locale with contents appropriate for > Northeastern Dian Hmong; is that a good default for someone speaking Eastern > Xiangxi Hmong? for Luopohe Hmong? For all the other Hmongs? The use of extlang per se has no effect on how this scenario plays out. What you're assuming here is that the extlang element would always correspond to some identifiable single language variety, and that there might be content which would be fully identified by it. In my opinion, this should happen solely for those cases where we already have a specific string that is already used for a particular language. The only other case where I could see it making sense to tag content solely with the extlang is in cases where a more accurate identification of the language hasn't happened. > For extlang to be a good apparatus, these always have to be good choices, > since we are baking the structure into the tag. > > If Peter Constable came out and said the following, then I would admit to my > sins, give in gracefully, and go along with extlang. > > - "Yes, each of the Hmongs (encompassed by hmn) are mutually > intelligible, and are better for each one than another fallback like > Chinese" > - and the same is true for all the other cases with no > predominant variant. > - "Yes, standard Arabic is intelligible for all the encompassed > languages from Algerian Saharan Arabic to Shihhi Arabic, and are better for > each one than another fallback like French" > - and the same is true for all the other cases with a > predominant variant. It's pretty easy to come up with scenarios in which just about any fallback scheme will produce results other than the desired ones. That's the problem with heuristics. They don't predict things like the fact that 'de' is easier for me than 'en-scottish' even though my preferred language might be 'en-US'. Fallback has probably been over-sold. But I think the real question is whether using extlang would provide value at all, and what (if any) cost there would be to supporting it. THAT's the equation that needs to be solved. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 02:14: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 1IQGol-0003XU-Ps; Wed, 29 Aug 2007 02:14:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQGoj-0003XJ-P3 for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 02:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGoj-0003XB-FL for ltru@ietf.org; Wed, 29 Aug 2007 02:14:17 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQGoh-0005rq-He for ltru@ietf.org; Wed, 29 Aug 2007 02:14:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=n6yCAEE85rIOmR/8E/un2Dp2gdXV0T4p26AtEx5QsH29cUrD9ZsprjdD/5vhtUpB; 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.81.142] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQGog-0005u6-VS for ltru@ietf.org; Wed, 29 Aug 2007 02:14:15 -0400 Message-ID: <007301c7ea04$2b1ae4a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007301c7ea01$f59bbe00$6401a8c0@DGBP7M81> Subject: Re: [Ltru] extlang straw poll Date: Tue, 28 Aug 2007 23:16:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356a0c6d8e65694514ddadf83fdd03d2a60350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.142 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, August 28, 2007 11:00 PM > Subject: Re: [Ltru] extlang straw poll ... > I'll have a much better chance of addressing this properly over the > weekend than during the week, especially given that it's a three-day > weekend in the U.S. ... OK, if it will help let's move the period for comment out to September 5. But please, folks, let's try to get some closure on this! Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 07:16: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 1IQLXA-0002Zt-Kr; Wed, 29 Aug 2007 07:16:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQLXA-0002Zn-4L for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 07:16:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLX9-0002Zf-Mq for ltru@ietf.org; Wed, 29 Aug 2007 07:16:27 -0400 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQLX8-00056d-V1 for ltru@ietf.org; Wed, 29 Aug 2007 07:16:27 -0400 Received: (qmail 90123 messnum 6392371 invoked from network[194.125.174.31/ts09-031.dublin.indigo.ie]); 29 Aug 2007 11:16:25 -0000 Received: from ts09-031.dublin.indigo.ie (HELO ?194.125.174.31?) (194.125.174.31) by mail00.svc.cra.dublin.eircom.net (qp 90123) with SMTP; 29 Aug 2007 11:16:25 -0000 In-Reply-To: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Wed, 29 Aug 2007 12:16:27 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 29 Aug 2007, at 05:27, scr=EDobh Doug Ewell: > I am in fairly weak agreement with Marion over the introductory text. :-) > The wording about human beings on our planet, past and present, has =20= > certainly been around since RFC 3066, but RFCs have become more =20 > formal in their wording (and in other ways) since then. Exactly. There is nothing so out of date as last year's fashion, and =20 nothing so likely to irritate professional readers as informal =20 language where we feel it is out of place. > RFC 4646 is over four times as long as 3066 and might call for a =20 > different approach. The current wording has also been parodied =20 > more than once in other documents. > > I'm not so sure about putting a Definitions section near the front. =20= > Like Martin, I've also had trouble with ISO documents that start me =20= > off with pages of definitions of terms I've never seen before, and =20 > no context in which to place them. As a terminologist, that's _exactly_ were I expect to find them (like =20= the key we expect to be fronted in most dictionaries). > Usually I look for such reference material near the end of a =20 > document, not the beginning. What is important is that all such =20 > material be in an easy-to-find place. I find myself in strong agreement with Doug on that (first or last =20 placement is less important than _inclusion_ of keys/definitions). > > However, at this stage it is much more important to me that we =20 > resolve the real technical debate over extlangs, and get the drafts =20= > to WG Last Call, than to engage in fine-tuning and wordsmithing at =20 > this level. The current wording doesn't cause any confusion or =20 > misinterpretation. If we weren't already half a year behind =20 > schedule, I would probably care more about this. I haven't been minding any schedule to do with this. Part of the =20 problem in maintaining continuous transatlantic dialogue is that US =20 citizens are only coming to life as workers in the rest of the "West" =20= are winding down for the day (we French, Irish, German workers are =20 finding our mailboxes suddenly filling up with US mail as we are =20 clearing our desks for the day - unless one stays on to give it a =20 quick once-over, it is hard to come cold to the debate next morning). Then again, I suppose we could - as so many US ex-pats do over here - =20= sleep until noon, breakfast at lunchtime and only schedule business =20 mtgs for after 4 pm and real hard work from then until 3am, but we'd =20 have to be unemployed or self-employed to make that system work, and =20 our neighbours might shun us vampires!:-) Long way of saying sorry to raise such points as affect the structure =20= so late in the work schedule, but I'd rather raise such points while =20 the doc. is still in draft form than not at all. To me, "fine-tuning =20 and wordsmithing" are non-structural matters, changing the structure =20 something definitely to do at drafting stage. In any case, I would not in any way wish my comments to delay =20 progress to final draft, so feel free not to mind what I have =20 suggested at this stage. Now, signing off for mid-day break (12:10 =20 here). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 07:22: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 1IQLcZ-0000DB-Ul; Wed, 29 Aug 2007 07:22:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQLcY-0000Cs-OW for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 07:22:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLcY-0000Ci-DR for ltru@ietf.org; Wed, 29 Aug 2007 07:22:02 -0400 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQLcX-0005Dr-Uh for ltru@ietf.org; Wed, 29 Aug 2007 07:22:02 -0400 Received: (qmail 43010 messnum 2893074 invoked from network[194.125.174.31/ts09-031.dublin.indigo.ie]); 29 Aug 2007 11:22:00 -0000 Received: from ts09-031.dublin.indigo.ie (HELO ?194.125.174.31?) (194.125.174.31) by mail07.svc.cra.dublin.eircom.net (qp 43010) with SMTP; 29 Aug 2007 11:22:00 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070829065903.E19631A37F@smtp7-g19.free.fr> References: <46CF54C4.2090707@yahoo-inc.com> <46D428E2.50804@yahoo-inc.com> <4E492106-F6A3-48F5-BE3D-ED229FA841A9@egt.ie> <6.0.0.20.2.20070829113233.09e33380@localhost> <20070829065903.E19631A37F@smtp7-g19.free.fr> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Definitions (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Wed, 29 Aug 2007 12:22:02 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org While agreeing with the thrust of what I think you are saying below, =20 JFC, I see Debbie as rather having introduced greater clarity with =20 her NWIP by forcing discussion to clear some confusion on important =20 points (so placing drafters and potential users alike in her debt). Best, mg On 29 Aug 2007, at 06:59, scr=EDobh JFC Morfin: > At 04:38 29/08/2007, Martin Duerst wrote: > >> One benefit is that it helps spec writers to try things through, =20 >> but the IETF has other ways of trying to make sure that the specs =20 >> really work. >> > > ... > I am impressed by your interest in thesauri and ontologies. =20 > Nevertheless would there be, at the beginning or at the end I do =20 > not care, a definition of what you consider a "language" is, that =20 > could help many people understanding what BCP 47 speaks about. Look =20= > at the confusion that Debbie has introduced with her NWIP, not =20 > understanding the difference of what is a language for ISO 639 and =20 > 3166... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 07:40: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 1IQLu7-0006VG-Bw; Wed, 29 Aug 2007 07:40:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQLu6-0006RK-CR for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 07:40:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLu5-0006Pi-VR for ltru@ietf.org; Wed, 29 Aug 2007 07:40:09 -0400 Received: from mail04.svc.cra.dublin.eircom.net ([159.134.118.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQLu5-0005ek-Fd for ltru@ietf.org; Wed, 29 Aug 2007 07:40:09 -0400 Received: (qmail 87025 messnum 5275933 invoked from network[194.125.174.31/ts09-031.dublin.indigo.ie]); 29 Aug 2007 11:40:08 -0000 Received: from ts09-031.dublin.indigo.ie (HELO ?194.125.174.31?) (194.125.174.31) by mail04.svc.cra.dublin.eircom.net (qp 87025) with SMTP; 29 Aug 2007 11:40:08 -0000 In-Reply-To: <003501c7e9c5$1e696040$6801a8c0@oemcomputer> References: <30b660a20708281504t32b862f1u38dc7fc9a70dc3ad@mail.gmail.com> <003501c7e9c5$1e696040$6801a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <611F450C-E0E8-461B-8AEB-3D81FF991CF8@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] extlang straw poll Date: Wed, 29 Aug 2007 12:40:11 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 strongly agree with what Randy _and_ Mark say below, respectively, =20 only to stress that it would be wiser to have the question decided in =20= draft, rather than at any "fine-tuning' stage. mg On 28 Aug 2007, at 22:45, scr=EDobh Randy Presuhn: > Hi - > > As co-chair... > > > >> =46rom a process perspective, while I like getting a sense of =20 >> whether we have >> >> > any contributors in the "can't live with" or "can't live without" =20 > camps, > I'm afraid that "having extlang" needs to be teased apart a little =20 > more > carefully first. The devils are generally in the details, and at this > point it's still not clear to me whether objections are to the concept > itself or to details of the current proposal. For example, some might > have lingering worries about having more than one way to tag a =20 > language, or > what the consequences for sgn- might be if extlang is removed. =20 > Consequently, > we need to be sure we understand what the current proposal for =20 > extlang really > means, and work through any suggestions for modifying it, before we =20= > can address > the question of whether to eliminate it altogether. > On 28 Aug 2007, at 22:51, Mark Davis wrote: > If you don't want to have a straw poll at this point that's fine. =20 > But then John needs to stop saying I'm the only one standing in the =20= > way of the train ;-) > > Mark > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 09:14: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 1IQNMy-0004Ri-Ls; Wed, 29 Aug 2007 09:14:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQNMw-0004Kp-Ru for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 09:14:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQNMv-0004Kg-R3 for ltru@ietf.org; Wed, 29 Aug 2007 09:14:01 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQNMu-0000Vw-GJ for ltru@ietf.org; Wed, 29 Aug 2007 09:14:00 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IQNMp-0004cJ-DK; Wed, 29 Aug 2007 09:13:55 -0400 Date: Wed, 29 Aug 2007 09:13:55 -0400 To: Martin Duerst Subject: Re: [Ltru] Re: extlang Message-ID: <20070829131355.GC2623@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <6.0.0.20.2.20070829124940.05bc2ad0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070829124940.05bc2ad0@localhost> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > I'm sure you have done so somewhere already, but for everybody > to see, could you (pointer is okay) provide a list of the > macrolanguages that would be handled by extlangs? Note that it's the "microlanguages" (not an official term), the languages encompassed by macrolanguages, that are handled by extlang subtags. http://www.sil.org/iso639-3/macrolanguages.asp is the core list of macrolanguage mappings. For our purposes, the macrolanguages Akan (Fat, Twi), Norwegian (Bokmal, Nynorsk), and Serbo-Croatian (Serbian, Croatian, Bosnian) are out of the case, because the "microlanguages" already have primary language subtags. (Mark has mentioned the Norwegian and Serbo-Croatian cases as ones that one needs to handle specially even under an extlang regime.) In addition to these, "sgn" is treated as a macrolanguage encompassing all sign languages. A list of these can be found at http://www.ethnologue.com/show_family.asp?subid=90008 (the Deaf ones) and http://www.ethnologue.com/show_family.asp?subid=90503 (the others). > (and maybe also those that wouldn't). That would be all the existing languages of 639-2, plus all the languages of 639-3 that do *not* appear on the right side of the above-referenced table. > Also, is your proposal above the same thing as what's in the > current draft, or would the draft need tweaking? I understand it to be the same. -- There are three kinds of people in the world: John Cowan those who can count, cowan@ccil.org and those who can't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 29 14:29: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 1IQSIN-0007IK-5x; Wed, 29 Aug 2007 14:29:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQSIJ-0007Gy-MK for ltru-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 14:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSIJ-0007Gl-CK for ltru@ietf.org; Wed, 29 Aug 2007 14:29:35 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQSII-0001dk-22 for ltru@ietf.org; Wed, 29 Aug 2007 14:29:35 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tBYbjzmMnL7kJSSU1ucfgK/jCPRlRWeYc9tR9aIks5JAAJnM9Dv7tG4jD78JWLtr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.101] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQSIH-0006ni-Gp for ltru@ietf.org; Wed, 29 Aug 2007 14:29:33 -0400 Message-ID: <002401c7ea6a$e4404a40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> Date: Wed, 29 Aug 2007 11:32:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356632e77cea25d2d97cfda23caf8ae4b40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.101 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] On word-smithing X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair.... My experience in the IETF is that the time to do "word-smithing" is *BEFORE* a working group last call. The later we are in the process, the greater the reluctance to change *anything* will become, due to concerns about inadvertantly breaking something. Though not yet at the WG last call stage, we are quite late, and the reluctance to make changes is starting to show. This is quite different from how things may work in some other organizations that people on this list may be accustomed to, particularly ones with official "editing meetings". But when in Rome... Remember: after completion of a WG last call and production of an update succefully addressing last call comments, only changes resulting from the IESG and the IETF last call comments are considered, and generally only "show stoppers" are required to be addressed. Consequently, if you would like to see an editorial change, I ask that you please propose specific text for discussion sooner rather than later. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 10:29: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 1IQl1C-00016k-O5; Thu, 30 Aug 2007 10:29:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQl1A-000168-Tw for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 10:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQl1A-00015j-DE for ltru@ietf.org; Thu, 30 Aug 2007 10:29:08 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQl18-0005ST-Fj for ltru@ietf.org; Thu, 30 Aug 2007 10:29:08 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 30 Aug 2007 07:29:02 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Thu, 30 Aug 2007 07:29:02 -0700 From: Peter Constable To: LTRU Working Group Date: Thu, 30 Aug 2007 07:29:01 -0700 Subject: RE: [Ltru] Re: extlang Thread-Topic: [Ltru] Re: extlang Thread-Index: Acfp2aWuIFgKV1mIQFeq1nr3p3argABKwY4g Message-ID: References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> In-Reply-To: <30b660a20708281812s3401e193u7c90d3ab22ac3eda@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: c021adebe99b05433d94f84a85f41df2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1316597711==" Errors-To: ltru-bounces@ietf.org --===============1316597711== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561ABDC7644NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561ABDC7644NAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgbXkgcmVzcG9uc2VzIHRvIHRoaXMgbWFpbCBmcm9tIE1hcmsuIEkgY3JpdGlxdWUg aGlzIGFyZ3VtZW50YXRpb24sIGJ1dCBiZSBjYXJlZnVsIG5vdCB0byBqdW1wIHRvIGNvbmNsdXNp b25zIGFib3V0IHdoYXQgSeKAmW0gc2F5aW5nIHJlZ2FyZGluZyB0aGUgb3BlbiBpc3N1ZTogd2hh dCBJIHNheSBoZXJlIGNyaXRpcXVlcyBNYXJrcyBhcmd1bWVudHMgYWdhaW5zdCBleHRsYW5nLCBi dXQgZG9lcyBub3QgYXR0ZW1wdCB0byBtYWtlIGEgc3VmZmljaWVudCBjYXNlIGZvciBleHRsYW5n Lg0KDQoNCkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9y Z10NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAwNyA2OjEyIFBNDQoNCj4gSWYgYSBsYW5n dWFnZSB5eXkgaGFzIHRoZSBtYWNyb2xhbmd1YWdlIHh4LCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0 d28gcG9zc2libGUgcmVwcmVzZW50YXRpb25zDQphKSBleHRsYW5nOiB4eC15eXkNCmIpIGxhbmc6 IHl5eQ0KDQo+VGhlIG1haW4gcmVhc29uIEkndmUgaGVhcmQgZnJvbSB5b3UgZm9yIGRvaW5nIChh KSBpbnN0ZWFkIG9mIChiKSBpcyB0aGF0IChhKSBpdCBoYXMgYmV0dGVyIGZhbGxiYWNrIGJlaGF2 aW9yLiBGb3IgdGhhdCB0byBiZSB0cnVlLCB4eCBoYXMgdG8gYmUgYSBnb29kIGZhbGxiYWNrIGZv ciB1c2VycyBvZiB5eXksIGluIHRoZSBtYWpvcml0eSBvZiBjYXNlcy4NCkkgdGhpbmsg4oCcZmFs bGJhY2sgYmVoYXZpb3LigJ0gbmVlZHMgbW9yZSBjYXJlZnVsIGNvbnNpZGVyYXRpb24gaGVyZS4g SXQgYXBwZWFycyB0aGF0IE1hcmsgaXMgZm9jdXNpbmcgb24gYSBwYXJ0aWN1bGFyIHNjZW5hcmlv OiByZXF1ZXN0IGlzIGZvciByZXNvdXJjZSBpbiBsYW5nIEEsIGJ1dCB0aGF0IGlzIG5vdCBhdmFp bGFibGUgc28gcHJvY2VzcyBuZWVkcyB0byBmYWxsYmFjayB0byBhIGxpa2VseS1uZXh0LWJlc3Qg Y2hvaWNlIGF2YWlsYWJsZS4NCldoZW4gSSBmaXJzdCBwcm9wb3NlZCB0aGUgZXh0bGFuZyBtZWNo YW5pc20sIHRoYXQgd2FzIG5vdCB0aGUgaW50ZW50LiBSYXRoZXIsIHRoZSBpbnRlbnQgd2FzIGZv Y3VzZWQgb24gYW5vdGhlciBzY2VuYXJpbzogYXV0aG9yIHdhbnRzIHRvIHRhZyBjb250ZW50IHVz aW5nIG1vcmUgc3BlY2lmaWMgSUQgeXl5LCBidXQgbWFueSByZXF1ZXN0cywgZXNwZWNpYWxseSBm cm9tIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMsIHdpbGwgdXNlIHh4LCB3aGljaCBoYXMgYmVlbiBp biB1c2UgZm9yIHNvbWUgdGltZS4gVGhpcyBzY2VuYXJpbyBwZXJ0YWlucyB0byBMYW5ndWFnZS1y YW5nZSBhcyBkZWZpbmVkIHNpbmNlIEhUVFAvMS4xLg0KICAgICAgICAgICAgICAgIExhbmd1YWdl LXJhbmdlID0geHgNCiAgICAgICAgICAgICAgICBDb250ZW50IHRvIGJlIG1hdGNoZWQgPSB5eXkg b3IgeHgteXl5DQpJZiB0aGUgY29udGVudCBpcyB0YWdnZWQgeHgteXl5LCB0aGVyZSBpcyBhIG1h dGNoLiBCdXQgaWYgdGhlIGNvbnRlbnQgaXMgdGFnZ2VkIHl5eSwgdGhlcmUgaXMgbm8gbWF0Y2gg dXNpbmcgYSBiYXNpYyBhbGdvcml0aG0g4oCTIG9uZSB3b3VsZCBuZWVkIGEgbW9yZSBhZHZhbmNl ZCBhbGdvcml0aG0gdGhhdCBrbm93cyBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4geHgg YW5kIHl5eS4NCkkgdGhpbmsgTWFya+KAmXMgaXMgdGhlIHJlY2lwcm9jYWwgc2NlbmFyaW86IHVz ZXJzIHByZWZlcnMgdGhlIHNwZWNpZmljIHZhcmlldHkgeXl5LCBidXQgbW9zdCBjb250ZW50IGlz IGFscmVhZHkgdGFnZ2VkIHVzaW5nIHh4LCB3aGljaCBoYXMgYmVlbiBpbiB1c2UgZm9yIHNvbWUg dGltZS4gVGhpcyBpcyBhIHBhcnRpY3VsYXIgY2FzZSBpbiB0aGUgZ2VuZXJhbCBzZXQgb2YgZmFs bGJhY2sgc2NlbmFyaW9zLCBhbmQgaXQgc2VlbXMgdG8gYmUgZXhhY3RseSB0aGUgb25lIE1hcmsg aXMgZm9jdXNpbmcgb24uIEJ1dCBub3RlIHRoYXQgbGFuZ3VhZ2UtcmFuZ2UgZG9lcyBub3QgYXBw bHkgaGVyZSDigJMgb3IsIGZyb20gYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUsIGRvZXNu4oCZdCB3 b3JrIGhlcmU6DQpsYW5ndWFnZS1yYW5nZSA9IHl5eSBvciB4eC15eXkNCmNvbnRlbnQgdG8gYmUg bWF0Y2hlZCA9IHh4DQpXaGljaGV2ZXIgd2F5IHRoZSBsYW5ndWFnZS1yYW5nZSBpcyBleHByZXNz ZWQsIHRoZXJlIGlzIG5vIG1hdGNoIHdpdGggYSBiYXNpYyBhbGdvcml0aG0g4oCTIG9uZSB3b3Vs ZCBuZWVkIGEgbW9yZSBhZHZhbmNlZCBhbGdvcml0aG0gdGhhdCBrbm93cyBhYm91dCB0aGUgcmVs YXRpb25zaGlwIGJldHdlZW4geHggYW5kIHl5eS4NClNvLCBjb25zaWRlcmluZyBqdXN0IHRob3Nl IHNjZW5hcmlvcywgeHgteXl5IGhhcyBhbiBhZHZhbnRhZ2Ugb3ZlciB5eXkgaW4gdGhhdCBpdCBw cm92aWRlcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBvbmUgc2NlbmFyaW8gd2hpbGUgdGhlIHR3byBh bHRlcm5hdGl2ZXMgYXJlIGVxdWFsIHdydCB0aGUgb3RoZXIuIE9mIGNvdXJzZSwgdGhvc2UgYXJl buKAmXQgdGhlIG9ubHkgc2NlbmFyaW9zLiBXZSBuZWVkIHRvIGNvbnNpZGVyIGEgYnJvYWRlciBz ZXQgb2Ygc2NlbmFyaW9zLCBhbmQgYWxzbyBjb25zaWRlciBob3cgdGhleSByYW5rIGluIHByaW9y aXR5Lg0KDQoNCj4gVGhlcmUgYXJlIChhdCBsZWFzdCkgdHdvIGNhc2VzIHRvIGNvbnNpZGVyIGhl cmUuDQoNCiAxLiAgVGhlcmUgaXMgYSBwcmVkb21pbmVudCBjaG9pY2UgaW4gdGhlIGluZHVzdHJ5 IGZvciB0aGUgbWFjcm8gbGFuZ3VhZ2UuIEZvciBleGFtcGxlLCB0aGUgY29udGVudCBmb3Igemgg aXMgdHlwaWNhbGx5IGFsd2F5cyBNYW5kYXJpbjsgdGhlIGNvbnRlbnQgZm9yIGFyIGlzIHR5cGlj YWxseSBhbHdheXMgc3RhbmRhcmQgQXJhYmljLg0KVHlwaWNhbGx5LCB5ZXMuIFdlIGp1c3QgbXVz dCBub3QgYXNzdW1lIHRoYXQgaXMgYWx3YXlzIHRoZSBjYXNlLiBUaGUgdmVyeSB0aGluZyB0aGF0 IHN0YXJ0ZWQgbWUgdGhpbmtpbmcgYWJvdXQgdGhlIG1hY3JvbGFuZ3VhZ2UgY29uY2VwdCBpbiB0 aGUgZmlyc3QgcGxhY2UsIHJhdGhlciB0aGFuIGVxdWF0aW5nIGV4aXN0aW5nIElTTyA2MzkgSURz IGxpa2UgemggYW5kIGFyIHdpdGggdGhlIHByZWRvbWluYW50IHZhcmlldHksIHdhcyB0aGUgZmFj dCB0aGF0IHRoZXJlIHdlcmUgbGFuZ3VhZ2UgdGFncyByZWdpc3RlcmVkIHdpdGggSUFOQSBleHBs aWNpdGx5IGFzc29jaWF0aW5nIHpoIHdpdGggQ2hpbmVzZSBsYW5ndWFnZXMgb3RoZXIgdGhhbiBN YW5kYXJpbi4gV2hlbiBmYWNlZCB3aXRoIHByZS1leGlzdGluZyB1c2FnZSDigJx6aC13dXXigJ0s IHdlIGhhdmUgdHdvIGNob2ljZXM6DQphKSB3dXUgaXMgYSBzcGVjaWZpYyB2YXJpZXR5IG9mIHpo DQpiKSB3dXUgcmVsYXRlcyB0byB6aCBpbiBzb21lIG90aGVyIHdheSwgc3VjaCBhcyB6aCBiZWlu ZyBhIGdvb2QgZmFsbGJhY2sgY2hvaWNlDQpJIHN1c3BlY3QgdGhhdCB0aGUgcmVxdWVzdCBmb3Ig emgtd3V1IHdhcyBiYXNlZCBvbiB0aGUgZmlyc3QgcGVyc3BlY3RpdmUsIGFuZCB0aGF0IHdhcyB0 aGUgcGVyc3BlY3RpdmUgSSBhc3N1bWVkLg0KDQo+IExvb2sgYXQgdGhlIGNvbmNyZXRlIGltcGxp Y2F0aW9ucy4gSXQgbWVhbnMgdGhhdCB3aGVuZXZlciBKb2UgbG9va3MgZm9yIGEgd2ViIHBhZ2Ug aW4gSGFra2EgQ2hpbmVzZSwgaGUgd2lsbCB0eXBpY2FsbHkgZmFsbCBiYWNrIHRvIE1hbmRhcmlu LiBXaGVuZXZlciBTYXJhaCBsb29rcyBmb3IgYSBwYWdlIGluIFR1bmlzaWFuIEFyYWJpYywgaXQg d2lsbCBmYWxsIGJhY2sgdG8gc3RhbmRhcmQgTWFuZGFyaW4uDQpXZSBuZWVkIHRvIGJlIGEgYml0 IG1vcmUgY2FyZWZ1bCBoZXJlOiBleGFjdGx5IGhvdyBkb2VzIEpvZSBnbyBhYm91dCByZXF1ZXN0 aW5nIEhha2thPyBJZiBoZSBhc2tzIGZvciDigJx6aOKAnSBob3BpbmcgdG8gZ2V0IGNvbnRlbnQg aW4gSGFra2EsIHRoZXJlIGlzIGEgdmVyeSBoaWdoIHByb2JhYmlsaXR5IGhlIHdpbGwgZ2V0IHBh Z2VzIGluIE1hbmRhcmluLiBCdXQgaWYgaGUgYXNrcyBmb3Ig4oCcemgtaGFra2HigJ0sIGhlIHdp bGwgb25seSBnZXQgcGFnZXMgdGFnZ2VkIOKAnHpoLWhha2th4oCdIGZyb20gc2VydmVycyBpbXBs ZW1lbnRpbmcgSFRUUC8xLjEgbGFuZ3VhZ2UtcmFuZ2UsIG5vdCDigJx6aOKAnSBwYWdlczogdGhh dCBpcyBob3cgbGFuZ3VhZ2UtcmFuZ2Ugd29ya3MuDQoNCj5JZiB5b3UgYXJlIHNheWluZyBob3dl dmVyLCB0aGF0IHpoIGlzIG5vdCBuZWNlc3NhcmlseSBNYW5kYXJpbiwgdGhhdCBBcmFiaWMgaXMg bm90IG5lY2Vzc2FyaWx5IFN0YW5kYXJkIEFyYWJpYywgdGhlbiB3ZSBmYWxsIHRocm91Z2ggdG8g Y2FzZSAyLg0KDQogMS4gIFRoZXJlIGlzIG5vdCBhIHByZWRvbWluYW50IGNob2ljZSBpbiB0aGUg aW5kdXN0cnksIGxldCdzIHNheSBmb3IgSG1vbmcuIEluIHRoaXMgY2FzZSwgdGhlIHNpdHVhdGlv biBpcyBkaWZmZXJlbnQuIEkgY291bGQgY2hvb3NlIGFueSBvZiB0aGUgSG1vbmcgZm9yIHRoZSBj b250ZW50IGZvciBobW4uIFdlIHRoZW4gaGF2ZSBhbiBldmVuIGRpY2VyIGNhc2UgZm9yIHRoZSB2 YWx1ZSBvZiBleHRsYW5nLiBJIGxvY2FsaXplIG15IGhtbiBsb2NhbGUgd2l0aCBjb250ZW50cyBh cHByb3ByaWF0ZSBmb3IgTm9ydGhlYXN0ZXJuIERpYW4gSG1vbmc7IGlzIHRoYXQgYSBnb29kIGRl ZmF1bHQgZm9yIHNvbWVvbmUgc3BlYWtpbmcgRWFzdGVybiBYaWFuZ3hpIEhtb25nPyBmb3IgTHVv cG9oZSBIbW9uZz8gRm9yIGFsbCB0aGUgb3RoZXIgSG1vbmdzPw0KPiBGb3IgZXh0bGFuZyB0byBi ZSBhIGdvb2QgYXBwYXJhdHVzLCB0aGVzZSBhbHdheXMgaGF2ZSB0byBiZSBnb29kIGNob2ljZXMs IHNpbmNlIHdlIGFyZSBiYWtpbmcgdGhlIHN0cnVjdHVyZSBpbnRvIHRoZSB0YWcuDQoNCkFnYWlu LCBsZXTigJlzIGJlIG1vcmUgY2FyZWZ1bCBpbiB0aGUgYW5hbHlzaXMgYW5kIGFyZ3VtZW50YXRp b24uIFlvdeKAmXJlIHF1ZXN0aW9uaW5nIHdoZXRoZXIgYSByZXF1ZXN0IGZvciBobW4gc2hvdWxk IGJlIGFibGUgdG8gcmV0dXJuIGNvbnRlbnQgaW4gYW55IEhtb25nIGxhbmd1YWdlLCBhbmQgc2F5 aW5nIHRoYXQg4oCcaG1uLWhtZOKAnSAoTkUgRGlhbikgaXMgYmFkIGJlY2F1c2Ugc29tZW9uZSBh c2tpbmcgZm9yIEhtb25nIG1pZ2h0IHJlYWxseSBiZSBhIHNwZWFrZXIgb2YgTHVvcG9oZSBIbW9u Zy4gSXQgc2VlbXMgdG8gbWUgdGhpcyBpcyBhIGZhbGxhY2lvdXMgYXJndW1lbnQ6IGl04oCZcyBw cmVtaXNlIGlzIHRoYXQg4oCcaG1u4oCdIGNhbiBhbmQgbXVzdCBiZSBzdWZmaWNpZW50IGZvciBh bnkgb2YgdGhlc2UgdmFyaW91cyBzcGVha2Vycy4gV2VsbCwgZWl0aGVyIGl0IGlzIG9yIGl0IGlz buKAmXQuIElmIGl0IGlzLCB0aGVuIHRoZSBhcmd1bWVudCBmYWlscy4gSWYgaXQgaXNu4oCZdCwg dGhlbiBhbGwgdGhhdCBwcm92ZXMgaXMgdGhhdCDigJxobW7igJ0gcmVhbGx5IGlzIG5ldmVyIHN1 ZmZpY2llbnQ6IGEgbW9yZSBzcGVjaWZpYyBsYW5ndWFnZS1yYW5nZSByZWFsbHkgaXMgbmVlZGVk LCBhbmQgYW55b25lIHJlcXVlc3RpbmcgdGhlaXIgcmVzb3VyY2VzIHVzaW5nIOKAnGhtbuKAnSBp cyBtYWtpbmcgYSB2YWd1ZSByZXF1ZXN0IHRoYXQgd2lsbCBiZSBzdWJqZWN0IHRvIHNvbWV3aGF0 IGFyYml0cmFyeSByZXN1bHRzLiBBdCB0aGF0IHBvaW50IHlvdSBkZWNpZGUgYSBtb3JlIHNwZWNp ZmljIGxhbmd1YWdlLXJhbmdlIGlzIG5lZWRlZCwgaXQgbWFrZXMgbm8gZGlmZmVyZW5jZSB3aGV0 aGVyIHRoZSBsYW5ndWFnZSByYW5nZSB1c2VkIGlzIOKAnGhtZOKAnSBvciDigJxobW4taG1k4oCd OiBib3RoIHdvdWxkIHN1Y2NlZWQgaW4gb2J0YWluaW5nIHRoZSBkZXNpcmVkIHJlc3VsdC4NCg0K U28sIHdlIHJlYWxseSBjYW7igJl0IHVzZSB0aGUgbWFjcm9sYW5ndWFnZSBjYXNlcyBsaWtlIEht b25nIHRvIGRlY2lkZSB0aGlzIG9wZW4gaXNzdWUuIElmIE5FIERpYW4gaXMgbm90IGEgZ29vZCBj aG9pY2UgZm9yIEx1b3BvaGUsIHRoZSAqb25seSogdGhpbmcgdGhhdCBwb2ludHMgdG8gaXMgdGhh dCDigJxobW7igJ0gaXMgdG9vIHZhZ3VlIHRvIGJlIHVzZWZ1bCBmb3IgcmVxdWVzdGluZyByZXNv dXJjZXMuDQoNCkJ0dywga2VlcCBpbiBtaW5kIHdoeSDigJxobW7igJ0gd2FzIGNyZWF0ZWQgaW4g dGhlIGZpcnN0IHBsYWNlLCBhbmQgd2h5IGl0IHdhcyBjcmVhdGVkIGFzIGFuIGluZGl2aWR1YWwt bGFuZ3VhZ2UgaWRlbnRpZmllcjoNCg0KDQotICAgICAgICAgIGxpYnJhcmlhbnMgbmVlZGVkIGEg dGFnIGZvciBjb250ZW50DQoNCg0KLSAgICAgICAgICB0aGV5IHdlcmUgbm90IEhtb25nIHNwZWNp YWxpc3RzIGFuZCBoYWQgbm8gYWJpbGl0eSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdmFyaWV0 aWVzDQoNCg0KLSAgICAgICAgICBhcyB0aGVzZSBhcmUgbm90LWhpZ2hseS1kZXZlbG9wZWQgdmFy aWV0aWVzIChpbiB0aGUgbGFuZ3VhZ2UtZGV2ZWxvcG1lbnQgc2Vuc2Ug4oCTIGxpdGVyYXR1cmUs IG1lZGlhLCBzdGFuZGFyZGl6YXRpb24pLCB0aGVyZSB3YXMgbm8gcmVhc29uIGZvciB0aGVzZSBu b24tc3BlY2lhbGlzdHMgdG8gc3VwcG9zZSB0aGF0IHRoZXNlIHZhcmlldGllcyB3ZXJlIGFueXRo aW5nIG1vcmUgdGhhbiBkaWFsZWN0cyBvZiBhIHNpbmdsZSBsYW5ndWFnZSAoYXNzdW1pbmcgdGhl eSBoYWQgbXVjaCBhd2FyZW5lc3Mgb2YgYW55IHZhcmlhdGlvbnMgaW4gdGhlIGZpcnN0IHBsYWNl KQ0KDQoNCk5vdywgYXMgSSBhcHByb2FjaGVkIGhvdyB0byBkZWFsIHdpdGgg4oCcaG1u4oCdIGlu IElTTyA2MzktMiB3aGVuIGl0IGNhbWUgdG8gY3JlYXRpbmcgSVNPIDYzOS0zLCBJIGhhZCB0d28g b3B0aW9uczogYXJndWUgdGhhdCDigJxobW7igJ0gc2hvdWxkIHJlYWxseSBiZSBhIGNvbGxlY3Rp b24sIG9yIHRyZWF0IOKAnGhtbuKAnSBhcyBhIG1hY3JvbGFuZ3VhZ2UuIEluIHRoZSBvcmlnaW5h bCBhbmFseXNpcywgKGh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20vMTQvaXNvNjM5L2FuYWx5c2lz LmFzcCksIEkgaGFkIGNvbmNsdWRlZCDigJxobW7igJ0gaXMgcmVhbGx5IGEgY29sbGVjdGlvbi4g QnV0IHNpbmNlIEkgYWxzbyBhbSBub3QgYSBIbW9uZyBzcGVjaWFsaXN0IGFuZCBkaWRu4oCZdCBo YXZlIHRoZSBjYXBhY2l0eSAoZmFyIGZyb20gaXQhKSBvZiBnZXR0aW5nIGFuIGV4cGVydCBhbmFs eXNpcyBvZiB0aGlzIGFuZCBldmVyeSBvdGhlciB1bmNlcnRhaW4gY2FzZSBpbiBJU08gNjM5IGlu IGFueSByZWFzb25hYmxlIGFtb3VudCBvZiB0aW1lLCBJIGNob3NlIHRoZSBwYXRoIG9mIGxlYXN0 IHJlc2lzdGFuY2U6IHRyZWF0IGl0IGFzIGEgbWFjcm9sYW5ndWFnZSBzaW5jZSBJU08gNjM5LTIg YW5kIGl0cyB1c2VyIGNvbW11bml0eSBjb25zaWRlcnMgaXQgYW4gaW5kaXZpZHVhbCBsYW5ndWFn ZSwgYW5kIHRoYXQgd2F5IEkgZG9u4oCZdCBoYXZlIHRvIGdldCB0aGUgSkFDIHRvIHRha2UgYWN0 aW9uIG9uIHlldCBvbmUgZGVjaXNpb24gd2hlcmUgdGhlIGltcGFjdCBpcyB1bmNsZWFyIGFuZCB0 aGUgaW50ZXJuYWwgZXhwZXJ0aXNlIG9uIHdoaWNoIHRvIGJhc2UgdGhlIGRlY2lzaW9uIGlzIG1p bmltYWwuDQoNCkJ1dCBub3RlIHRoYXQgZm9yIG91ciBwdXJwb3NlcyBoZXJlIGl0IHJlYWxseSBk b2VzbuKAmXQgbWF0dGVyIHdoZXRoZXIg4oCcaG1u4oCdIGVuZGVkIHVwIGFzIGEgbWFjcm9sYW5n dWFnZSBvciBhcyBhIGNvbGxlY3Rpb246IGVpdGhlciB3YXksIGl0IGlzIHN0aWxsIHZhZ3VlIGFu ZCB0aGVyZWZvcmUgbm90IGEgZ29vZCB0YWcgdG8gdXNlIGZvciByZXF1ZXN0aW5nIHJlc291cmNl cyBpZiB0aGUgZGlzdGluY3Rpb25zIG1hdHRlciB0byB5b3UuDQoNCg0KPiBJZiBQZXRlciBDb25z dGFibGUgY2FtZSBvdXQgYW5kIHNhaWQgdGhlIGZvbGxvd2luZywgdGhlbiBJIHdvdWxkIGFkbWl0 IHRvIG15IHNpbnMsIGdpdmUgaW4gZ3JhY2VmdWxseSwgYW5kIGdvIGFsb25nIHdpdGggZXh0bGFu Zy4NCg0KICogICAiWWVzLCBlYWNoIG9mIHRoZSBIbW9uZ3MgKGVuY29tcGFzc2VkIGJ5IGhtbikg YXJlIG11dHVhbGx5IGludGVsbGlnaWJsZSwgYW5kIGFyZSBiZXR0ZXIgZm9yIGVhY2ggb25lIHRo YW4gYW5vdGhlciBmYWxsYmFjayBsaWtlIENoaW5lc2UiDQoNCiAgICAqICAgYW5kIHRoZSBzYW1l IGlzIHRydWUgZm9yIGFsbCB0aGUgb3RoZXIgY2FzZXMgd2l0aCBubyBwcmVkb21pbmFudCB2YXJp YW50Lg0KSSBoYXZlbuKAmXQgY29tZSBvdXQgc2F5aW5nIHRoYXQ7IEkgYXNzdW1lIHRoZXkgYXJl IG5vdC4gQnV0LCBJ4oCZbSBzYXlpbmcgdGhhdCB0aGlzIGNhc2UgaXMgaXJyZWxldmFudCBmb3Ig d2hhdCB3ZSBuZWVkIHRvIGRlY2lkZS4NCj4NCg0KICogICAiWWVzLCBzdGFuZGFyZCBBcmFiaWMg aXMgaW50ZWxsaWdpYmxlIGZvciBhbGwgdGhlIGVuY29tcGFzc2VkIGxhbmd1YWdlcyBmcm9tIEFs Z2VyaWFuIFNhaGFyYW4gQXJhYmljIHRvIFNoaWhoaSBBcmFiaWMsIGFuZCBhcmUgYmV0dGVyIGZv ciBlYWNoIG9uZSB0aGFuIGFub3RoZXIgZmFsbGJhY2sgbGlrZSBGcmVuY2giDQoNCiAgICAqICAg YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIGFsbCB0aGUgb3RoZXIgY2FzZXMgd2l0aCBhIHByZWRv bWluYW50IHZhcmlhbnQuDQpXZWxsLCB3aGF0IHlvdeKAmXJlIGFza2luZyBtZSB0byBzYXkgaGVy ZSBpcyB0aGF0IGEgcmVxdWVzdCBmb3IgZS5nLiBBbGdlcmlhbiBTYWhhcmFuIEFyYWJpYyBjYW4g YXBwcm9wcmlhdGVseSBiZSBzZXJ2aWNlZCB3aXRoIFN0YW5kYXJkIEFyYWJpYyByZXNvdXJjZXMg cmF0aGVyIHRoYW4sIHNheSwgRnJlbmNoLiBJbiBvdGhlciB3b3JkcywgYSBsYW5ndWFnZS1yYW5n ZSDigJxhci1hcnHigJ0gY2FuIGFwcHJvcHJpYXRlbHkgbWF0Y2gg4oCcYXLigJ0gY29udGVudC4g QnV0IHRoYXQgd291bGQgbmV2ZXIgaGFwcGVuIGJlY2F1c2UgdGhhdCBpcyBub3QgaG93IGxhbmd1 YWdlLXJhbmdlIHdvcmtzLiBTbywgSeKAmW0gbm90IHN1cmUgaG93IHRoaXMgaXMgcmVsZXZhbnQ6 IHdoZXRoZXIgdGhlIGxhbmd1YWdlLXJhbmdlIGlzIOKAnGFyLWFyceKAnSBvciDigJxhcnHigJ0g dGhlIG9ubHkgcmVzdWx0cyByZXR1cm5lZCB3aWxsIGJlIEFsZ2VyaWFuIFNhaGFyYW4gQXJhYmlj LCB1bmxlc3Mgc29tZSBtb3JlIGFkdmFuY2VkIGZhbGxiYWNrIGJlaGF2aW91ciBpcyBpbnZva2Vk Lg0KDQpUaGUgcXVlc3Rpb24gdGhhdCB3b3VsZCBiZSByZWxldmFudCBpbiB0ZXJtcyBvZiBsYW5n dWFnZS1yYW5nZSBmb3IgdGhlIEFyYWJpYy9NYW5kYXJpbiBjYXNlcyBpcyB0aGlzOiBpZiBzb21l b25lIHJlcXVlc3RzIOKAnGFy4oCdLCBob3cgYmFkIGlzIGl0IGlmIHRoZXkgZ2V0IHBhZ2VzIGlu IOKAnGFyLWFyceKAnT8gSWYgc29tZW9uZSByZXF1ZXN0cyDigJx6aOKAnSwgaG93IGJhZCBpcyBp dCBpZiB0aGV5IGdldCBwYWdlcyBpbiDigJx6aC1oYWtrYeKAnT8gVGhlc2UgYXJlIHRoZSBjYXNl cyB0aGF0IHJlbGF0ZSB0byB0aGUgd2F5IGxhbmd1YWdlLXJhbmdlIHdvcmtzLg0KDQoNClBldGVy DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561ABDC7644NAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQog QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTMxMzYzNTY4NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTcxMzI1MzYwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE2MjcyNzY0MTA7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzI0NzQ0NjY2IC0xMzIxNTU4NzcwIDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxODYwMTky NjM2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTMxMzE1NTEyNDt9DQpAbGlzdCBsMjpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8 L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPkhlcmUNCmFyZSBteSByZXNwb25zZXMgdG8gdGhp cyBtYWlsIGZyb20gTWFyay4gSSBjcml0aXF1ZSBoaXMgYXJndW1lbnRhdGlvbiwgYnV0IGJlDQpj YXJlZnVsIG5vdCB0byBqdW1wIHRvIGNvbmNsdXNpb25zIGFib3V0IHdoYXQgSeKAmW0gc2F5aW5n IHJlZ2FyZGluZyB0aGUgb3Blbg0KaXNzdWU6IHdoYXQgSSBzYXkgaGVyZSBjcml0aXF1ZXMgTWFy a3MgYXJndW1lbnRzIGFnYWluc3QgZXh0bGFuZywgYnV0IGRvZXMgbm90IGF0dGVtcHQNCnRvIG1h a2UgYSBzdWZmaWNpZW50IGNhc2UgZm9yIGV4dGxhbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IE1hcmsgRGF2aXMNClttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5v cmddIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMDcgNjoxMiBQTTxi cj4NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bh bj48L2I+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5JZiBhIGxhbmd1YWdlIHl5eQ0KaGFzIHRoZSBtYWNyb2xh bmd1YWdlIHh4LCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gcG9zc2libGUgcmVwcmVzZW50YXRp b25zIDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdiBz dHlsZT0nbWFyZ2luLWxlZnQ6MzAuMHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPmEpIGV4dGxh bmc6IHh4LXl5eTxicj4NCmIpIGxhbmc6IHl5eTxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KPHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDs8L3NwYW4+VGhlIG1haW4gcmVhc29uIEkndmUg aGVhcmQgZnJvbSB5b3UgZm9yDQpkb2luZyAoYSkgaW5zdGVhZCBvZiAoYikgaXMgdGhhdCAoYSkg aXQgaGFzIGJldHRlciBmYWxsYmFjayBiZWhhdmlvci4gRm9yIHRoYXQNCnRvIGJlIHRydWUsIHh4 IGhhcyB0byBiZSBhIGdvb2QgZmFsbGJhY2sgZm9yIHVzZXJzIG9mIHl5eSwgaW4gdGhlIG1ham9y aXR5IG9mDQpjYXNlcy4gPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgdGhpbmsg4oCcZmFsbGJhY2sgYmVoYXZpb3Li gJ0NCm5lZWRzIG1vcmUgY2FyZWZ1bCBjb25zaWRlcmF0aW9uIGhlcmUuIEl0IGFwcGVhcnMgdGhh dCBNYXJrIGlzIGZvY3VzaW5nIG9uIGENCnBhcnRpY3VsYXIgc2NlbmFyaW86IHJlcXVlc3QgaXMg Zm9yIHJlc291cmNlIGluIGxhbmcgQSwgYnV0IHRoYXQgaXMgbm90DQphdmFpbGFibGUgc28gcHJv Y2VzcyBuZWVkcyB0byBmYWxsYmFjayB0byBhIGxpa2VseS1uZXh0LWJlc3QgY2hvaWNlIGF2YWls YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaGVuIEkgZmly c3QgcHJvcG9zZWQgdGhlDQpleHRsYW5nIG1lY2hhbmlzbSwgdGhhdCB3YXMgbm90IHRoZSBpbnRl bnQuIFJhdGhlciwgdGhlIGludGVudCB3YXMgZm9jdXNlZCBvbg0KYW5vdGhlciBzY2VuYXJpbzog YXV0aG9yIHdhbnRzIHRvIHRhZyBjb250ZW50IHVzaW5nIG1vcmUgc3BlY2lmaWMgSUQgeXl5LCBi dXQgbWFueQ0KcmVxdWVzdHMsIGVzcGVjaWFsbHkgZnJvbSBsZWdhY3kgaW1wbGVtZW50YXRpb25z LCB3aWxsIHVzZSB4eCwgd2hpY2ggaGFzIGJlZW4NCmluIHVzZSBmb3Igc29tZSB0aW1lLiBUaGlz IHNjZW5hcmlvIHBlcnRhaW5zIHRvIExhbmd1YWdlLXJhbmdlIGFzIGRlZmluZWQgc2luY2UNCkhU VFAvMS4xLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBMYW5ndWFnZS1yYW5nZQ0KPSB4eDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBDb250ZW50IHRvIGJlDQptYXRjaGVkID0geXl5IG9yIHh4LXl5eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIHRoZSBjb250ZW50IGlzIHRhZ2dlZA0KeHgteXl5 LCB0aGVyZSBpcyBhIG1hdGNoLiBCdXQgaWYgdGhlIGNvbnRlbnQgaXMgdGFnZ2VkIHl5eSwgdGhl cmUgaXMgbm8gbWF0Y2ggdXNpbmcNCmEgYmFzaWMgYWxnb3JpdGhtIOKAkyBvbmUgd291bGQgbmVl ZCBhIG1vcmUgYWR2YW5jZWQgYWxnb3JpdGhtIHRoYXQga25vd3MgYWJvdXQNCnRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiB4eCBhbmQgeXl5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkkgdGhpbmsgTWFya+KAmXMgaXMgdGhlDQpyZWNpcHJvY2FsIHNjZW5hcmlvOiB1 c2VycyBwcmVmZXJzIHRoZSBzcGVjaWZpYyB2YXJpZXR5IHl5eSwgYnV0IG1vc3QgY29udGVudA0K aXMgYWxyZWFkeSB0YWdnZWQgdXNpbmcgeHgsIHdoaWNoIGhhcyBiZWVuIGluIHVzZSBmb3Igc29t ZSB0aW1lLiBUaGlzIGlzIGENCnBhcnRpY3VsYXIgY2FzZSBpbiB0aGUgZ2VuZXJhbCBzZXQgb2Yg ZmFsbGJhY2sgc2NlbmFyaW9zLCBhbmQgaXQgc2VlbXMgdG8gYmUNCmV4YWN0bHkgdGhlIG9uZSBN YXJrIGlzIGZvY3VzaW5nIG9uLiBCdXQgbm90ZSB0aGF0IGxhbmd1YWdlLXJhbmdlIGRvZXMgbm90 DQphcHBseSBoZXJlIOKAkyBvciwgZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSwgZG9lc27i gJl0IHdvcmsgaGVyZTogPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtaW5kZW50Oi41aW4nPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPmxhbmd1YWdlLXJhbmdlDQo9IHl5eSBvciB4eC15eXk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQ7dGV4dC1pbmRlbnQ6LjVpbic+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Y29udGVudA0K dG8gYmUgbWF0Y2hlZCA9IHh4PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+V2hpY2hldmVyIHdheSB0aGUNCmxhbmd1YWdlLXJhbmdlIGlzIGV4cHJlc3NlZCwgdGhlcmUg aXMgbm8gbWF0Y2ggd2l0aCBhIGJhc2ljIGFsZ29yaXRobSDigJMgb25lIHdvdWxkDQpuZWVkIGEg bW9yZSBhZHZhbmNlZCBhbGdvcml0aG0gdGhhdCBrbm93cyBhYm91dCB0aGUgcmVsYXRpb25zaGlw IGJldHdlZW4geHggYW5kDQp5eXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+U28sIGNvbnNpZGVyaW5nIGp1c3QgdGhvc2UNCnNjZW5hcmlvcywgeHgteXl5IGhhcyBh biBhZHZhbnRhZ2Ugb3ZlciB5eXkgaW4gdGhhdCBpdCBwcm92aWRlcyBhbiBhZHZhbnRhZ2UNCmZv ciB0aGUgb25lIHNjZW5hcmlvIHdoaWxlIHRoZSB0d28gYWx0ZXJuYXRpdmVzIGFyZSBlcXVhbCB3 cnQgdGhlIG90aGVyLiBPZg0KY291cnNlLCB0aG9zZSBhcmVu4oCZdCB0aGUgb25seSBzY2VuYXJp b3MuIFdlIG5lZWQgdG8gY29uc2lkZXIgYSBicm9hZGVyIHNldCBvZg0Kc2NlbmFyaW9zLCBhbmQg YWxzbyBjb25zaWRlciBob3cgdGhleSByYW5rIGluIHByaW9yaXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KPHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPlRoZXJlIGFyZSAoYXQgbGVhc3Qp IHR3byBjYXNlcyB0bw0KY29uc2lkZXIgaGVyZS48bzpwPjwvbzpwPjwvcD4NCg0KPG9sIHN0YXJ0 PTEgdHlwZT0xPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMCBsZXZl bDEgbGZvMSc+VGhlcmUgaXMgYSBwcmVkb21pbmVudCBjaG9pY2UgaW4gdGhlIGluZHVzdHJ5IGZv cg0KICAgICB0aGUgbWFjcm8gbGFuZ3VhZ2UuIEZvciBleGFtcGxlLCB0aGUgY29udGVudCBmb3Ig emggaXMgdHlwaWNhbGx5IGFsd2F5cw0KICAgICBNYW5kYXJpbjsgdGhlIGNvbnRlbnQgZm9yIGFy IGlzIHR5cGljYWxseSBhbHdheXMgc3RhbmRhcmQgQXJhYmljLiA8bzpwPjwvbzpwPjwvbGk+DQo8 L29sPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UeXBp Y2FsbHksDQp5ZXMuIFdlIGp1c3QgbXVzdCBub3QgYXNzdW1lIHRoYXQgaXMgYWx3YXlzIHRoZSBj YXNlLiBUaGUgdmVyeSB0aGluZyB0aGF0DQpzdGFydGVkIG1lIHRoaW5raW5nIGFib3V0IHRoZSBt YWNyb2xhbmd1YWdlIGNvbmNlcHQgaW4gdGhlIGZpcnN0IHBsYWNlLCByYXRoZXINCnRoYW4gZXF1 YXRpbmcgZXhpc3RpbmcgSVNPIDYzOSBJRHMgbGlrZSB6aCBhbmQgYXIgd2l0aCB0aGUgcHJlZG9t aW5hbnQgdmFyaWV0eSwNCndhcyB0aGUgZmFjdCB0aGF0IHRoZXJlIHdlcmUgbGFuZ3VhZ2UgdGFn cyByZWdpc3RlcmVkIHdpdGggSUFOQSBleHBsaWNpdGx5DQphc3NvY2lhdGluZyB6aCB3aXRoIENo aW5lc2UgbGFuZ3VhZ2VzIG90aGVyIHRoYW4gTWFuZGFyaW4uIFdoZW4gZmFjZWQgd2l0aCBwcmUt ZXhpc3RpbmcNCnVzYWdlIOKAnHpoLXd1deKAnSwgd2UgaGF2ZSB0d28gY2hvaWNlczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPmEpDQp3dXUgaXMgYSBzcGVjaWZpYyB2YXJpZXR5IG9mIHpoPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5i KQ0Kd3V1IHJlbGF0ZXMgdG8gemggaW4gc29tZSBvdGhlciB3YXksIHN1Y2ggYXMgemggYmVpbmcg YSBnb29kIGZhbGxiYWNrIGNob2ljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SQ0Kc3VzcGVjdCB0aGF0IHRoZSBy ZXF1ZXN0IGZvciB6aC13dXUgd2FzIGJhc2VkIG9uIHRoZSBmaXJzdCBwZXJzcGVjdGl2ZSwgYW5k DQp0aGF0IHdhcyB0aGUgcGVyc3BlY3RpdmUgSSBhc3N1bWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCm1hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQptYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+Jmd0OyA8L3NwYW4+TG9vayBhdCB0aGUgY29uY3JldGUNCmltcGxpY2F0aW9ucy4gSXQgbWVh bnMgdGhhdCB3aGVuZXZlciBKb2UgbG9va3MgZm9yIGEgd2ViIHBhZ2UgaW4gSGFra2EgQ2hpbmVz ZSwNCmhlIHdpbGwgdHlwaWNhbGx5IGZhbGwgYmFjayB0byBNYW5kYXJpbi4gV2hlbmV2ZXIgU2Fy YWggbG9va3MgZm9yIGEgcGFnZSBpbg0KVHVuaXNpYW4gQXJhYmljLCBpdCB3aWxsIGZhbGwgYmFj ayB0byBzdGFuZGFyZCBNYW5kYXJpbi4gPHNwYW4NCnN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPldlDQpuZWVkIHRvIGJlIGEgYml0IG1vcmUgY2FyZWZ1bCBoZXJlOiBleGFjdGx5 IDxpPmhvdzwvaT4gZG9lcyBKb2UgZ28gYWJvdXQNCnJlcXVlc3RpbmcgSGFra2E/IElmIGhlIGFz a3MgZm9yIOKAnHpo4oCdIGhvcGluZyB0byBnZXQgY29udGVudCBpbiBIYWtrYSwgdGhlcmUgaXMN CmEgdmVyeSBoaWdoIHByb2JhYmlsaXR5IGhlIHdpbGwgZ2V0IHBhZ2VzIGluIE1hbmRhcmluLiBC dXQgaWYgaGUgYXNrcyBmb3Ig4oCcemgtaGFra2HigJ0sDQpoZSB3aWxsIG9ubHkgZ2V0IHBhZ2Vz IHRhZ2dlZCDigJx6aC1oYWtrYeKAnSBmcm9tIHNlcnZlcnMgaW1wbGVtZW50aW5nIEhUVFAvMS4x DQpsYW5ndWFnZS1yYW5nZSwgbm90IOKAnHpo4oCdIHBhZ2VzOiB0aGF0IGlzIGhvdyBsYW5ndWFn ZS1yYW5nZSB3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQptYXJnaW4tbGVmdDouNWluJz48YnI+DQo8c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ Jmd0Ozwvc3Bhbj5JZiB5b3UgYXJlIHNheWluZyBob3dldmVyLCB0aGF0IHpoIGlzDQpub3QgbmVj ZXNzYXJpbHkgTWFuZGFyaW4sIHRoYXQgQXJhYmljIGlzIG5vdCBuZWNlc3NhcmlseSBTdGFuZGFy ZCBBcmFiaWMsIHRoZW4NCndlIGZhbGwgdGhyb3VnaCB0byBjYXNlIDIuJm5ic3A7PG86cD48L286 cD48L3A+DQoNCjxvbCBzdGFydD0yIHR5cGU9MT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAg ICAgbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPlRoZXJlIGlzIG5vdCBhIHByZWRvbWluYW50IGNo b2ljZSBpbiB0aGUgaW5kdXN0cnksDQogICAgIGxldCdzIHNheSBmb3IgSG1vbmcuIEluIHRoaXMg Y2FzZSwgdGhlIHNpdHVhdGlvbiBpcyBkaWZmZXJlbnQuIEkgY291bGQNCiAgICAgY2hvb3NlIGFu eSBvZiB0aGUgSG1vbmcgZm9yIHRoZSBjb250ZW50IGZvciBobW4uIFdlIHRoZW4gaGF2ZSBhbiBl dmVuDQogICAgIGRpY2VyIGNhc2UgZm9yIHRoZSB2YWx1ZSBvZiBleHRsYW5nLiBJIGxvY2FsaXpl IG15IGhtbiBsb2NhbGUgd2l0aA0KICAgICBjb250ZW50cyBhcHByb3ByaWF0ZSBmb3IgTm9ydGhl YXN0ZXJuIERpYW4gSG1vbmc7IGlzIHRoYXQgYSBnb29kIGRlZmF1bHQNCiAgICAgZm9yIHNvbWVv bmUgc3BlYWtpbmcgRWFzdGVybiBYaWFuZ3hpIEhtb25nPyBmb3IgTHVvcG9oZSBIbW9uZz8gRm9y IGFsbCB0aGUNCiAgICAgb3RoZXIgSG1vbmdzPyA8bzpwPjwvbzpwPjwvbGk+DQo8L29sPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFu PkZvciBleHRsYW5nIHRvIGJlIGENCmdvb2QgYXBwYXJhdHVzLCB0aGVzZSBhbHdheXMgaGF2ZSB0 byBiZSBnb29kIGNob2ljZXMsIHNpbmNlIHdlIGFyZSBiYWtpbmcgdGhlDQpzdHJ1Y3R1cmUgaW50 byB0aGUgdGFnLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+QWdhaW4sIGxldOKAmXMgYmUgbW9yZSBjYXJlZnVsIGluIHRoZSBhbmFseXNpcyBhbmQg YXJndW1lbnRhdGlvbi4NCllvdeKAmXJlIHF1ZXN0aW9uaW5nIHdoZXRoZXIgYSByZXF1ZXN0IGZv ciBobW4gc2hvdWxkIGJlIGFibGUgdG8gcmV0dXJuIGNvbnRlbnQNCmluIGFueSBIbW9uZyBsYW5n dWFnZSwgYW5kIHNheWluZyB0aGF0IOKAnGhtbi1obWTigJ0gKE5FIERpYW4pIGlzIGJhZCBiZWNh dXNlIHNvbWVvbmUNCmFza2luZyBmb3IgSG1vbmcgbWlnaHQgcmVhbGx5IGJlIGEgc3BlYWtlciBv ZiBMdW9wb2hlIEhtb25nLiBJdCBzZWVtcyB0byBtZQ0KdGhpcyBpcyBhIGZhbGxhY2lvdXMgYXJn dW1lbnQ6IGl04oCZcyBwcmVtaXNlIGlzIHRoYXQg4oCcaG1u4oCdIGNhbiBhbmQgbXVzdCBiZQ0K c3VmZmljaWVudCBmb3IgYW55IG9mIHRoZXNlIHZhcmlvdXMgc3BlYWtlcnMuIFdlbGwsIGVpdGhl ciBpdCBpcyBvciBpdCBpc27igJl0Lg0KSWYgaXQgaXMsIHRoZW4gdGhlIGFyZ3VtZW50IGZhaWxz LiBJZiBpdCBpc27igJl0LCB0aGVuIGFsbCB0aGF0IHByb3ZlcyBpcyB0aGF0IOKAnGhtbuKAnQ0K cmVhbGx5IGlzIG5ldmVyIHN1ZmZpY2llbnQ6IGEgbW9yZSBzcGVjaWZpYyBsYW5ndWFnZS1yYW5n ZSByZWFsbHkgaXMgbmVlZGVkLA0KYW5kIGFueW9uZSByZXF1ZXN0aW5nIHRoZWlyIHJlc291cmNl cyB1c2luZyDigJxobW7igJ0gaXMgbWFraW5nIGEgdmFndWUgcmVxdWVzdA0KdGhhdCB3aWxsIGJl IHN1YmplY3QgdG8gc29tZXdoYXQgYXJiaXRyYXJ5IHJlc3VsdHMuIEF0IHRoYXQgcG9pbnQgeW91 IGRlY2lkZSBhDQptb3JlIHNwZWNpZmljIGxhbmd1YWdlLXJhbmdlIGlzIG5lZWRlZCwgaXQgbWFr ZXMgbm8gZGlmZmVyZW5jZSB3aGV0aGVyIHRoZQ0KbGFuZ3VhZ2UgcmFuZ2UgdXNlZCBpcyDigJxo bWTigJ0gb3Ig4oCcaG1uLWhtZOKAnTogYm90aCB3b3VsZCBzdWNjZWVkIGluIG9idGFpbmluZyB0 aGUNCmRlc2lyZWQgcmVzdWx0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+U28sIHdl IHJlYWxseSBjYW7igJl0IHVzZSB0aGUgbWFjcm9sYW5ndWFnZSBjYXNlcyBsaWtlIEhtb25nIHRv DQpkZWNpZGUgdGhpcyBvcGVuIGlzc3VlLiBJZiBORSBEaWFuIGlzIG5vdCBhIGdvb2QgY2hvaWNl IGZvciBMdW9wb2hlLCB0aGUgKjxiPm9ubHk8L2I+Kg0KdGhpbmcgdGhhdCBwb2ludHMgdG8gaXMg dGhhdCDigJxobW7igJ0gaXMgdG9vIHZhZ3VlIHRvIGJlIHVzZWZ1bCBmb3IgcmVxdWVzdGluZw0K cmVzb3VyY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QnR3LCBrZWVwIGluIG1p bmQgd2h5IOKAnGhtbuKAnSB3YXMgY3JlYXRlZCBpbiB0aGUgZmlyc3QgcGxhY2UsIGFuZA0Kd2h5 IGl0IHdhcyBjcmVhdGVkIGFzIGFuIGluZGl2aWR1YWwtbGFuZ3VhZ2UgaWRlbnRpZmllcjogPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs Zm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3Bhbg0K c3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+bGlicmFyaWFucyBuZWVkZWQgYSB0YWcgZm9yIGNvbnRlbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo IHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuDQpzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz50 aGV5IHdlcmUgbm90IEhtb25nIHNwZWNpYWxpc3RzIGFuZCBoYWQgbm8gYWJpbGl0eSB0bw0KZGlm ZmVyZW50aWF0ZSBiZXR3ZWVuIHZhcmlldGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPmFzIHRoZXNlIGFyZSBub3Qt aGlnaGx5LWRldmVsb3BlZCB2YXJpZXRpZXMgKGluIHRoZQ0KbGFuZ3VhZ2UtZGV2ZWxvcG1lbnQg c2Vuc2Ug4oCTIGxpdGVyYXR1cmUsIG1lZGlhLCBzdGFuZGFyZGl6YXRpb24pLCB0aGVyZSB3YXMg bm8NCnJlYXNvbiBmb3IgdGhlc2Ugbm9uLXNwZWNpYWxpc3RzIHRvIHN1cHBvc2UgdGhhdCB0aGVz ZSB2YXJpZXRpZXMgd2VyZSBhbnl0aGluZw0KbW9yZSB0aGFuIGRpYWxlY3RzIG9mIGEgc2luZ2xl IGxhbmd1YWdlIChhc3N1bWluZyB0aGV5IGhhZCBtdWNoIGF3YXJlbmVzcyBvZg0KYW55IHZhcmlh dGlvbnMgaW4gdGhlIGZpcnN0IHBsYWNlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPk5vdywgYXMgSSBhcHByb2FjaGVkIGhvdyB0byBkZWFsIHdpdGgg4oCcaG1u4oCdIGlu IElTTyA2MzktMiB3aGVuIGl0DQpjYW1lIHRvIGNyZWF0aW5nIElTTyA2MzktMywgSSBoYWQgdHdv IG9wdGlvbnM6IGFyZ3VlIHRoYXQg4oCcaG1u4oCdIHNob3VsZCByZWFsbHkNCmJlIGEgY29sbGVj dGlvbiwgb3IgdHJlYXQg4oCcaG1u4oCdIGFzIGEgbWFjcm9sYW5ndWFnZS4gSW4gdGhlIG9yaWdp bmFsIGFuYWx5c2lzLCAoPGENCmhyZWY9Imh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20vMTQvaXNv NjM5L2FuYWx5c2lzLmFzcCI+aHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbS8xNC9pc282MzkvYW5h bHlzaXMuYXNwPC9hPiksDQpJIGhhZCBjb25jbHVkZWQg4oCcaG1u4oCdIGlzIHJlYWxseSBhIGNv bGxlY3Rpb24uIEJ1dCBzaW5jZSBJIGFsc28gYW0gbm90IGEgSG1vbmcNCnNwZWNpYWxpc3QgYW5k IGRpZG7igJl0IGhhdmUgdGhlIGNhcGFjaXR5IChmYXIgZnJvbSBpdCEpIG9mIGdldHRpbmcgYW4g ZXhwZXJ0IGFuYWx5c2lzDQpvZiB0aGlzIGFuZCBldmVyeSBvdGhlciB1bmNlcnRhaW4gY2FzZSBp biBJU08gNjM5IGluIGFueSByZWFzb25hYmxlIGFtb3VudCBvZg0KdGltZSwgSSBjaG9zZSB0aGUg cGF0aCBvZiBsZWFzdCByZXNpc3RhbmNlOiB0cmVhdCBpdCBhcyBhIG1hY3JvbGFuZ3VhZ2Ugc2lu Y2UNCklTTyA2MzktMiBhbmQgaXRzIHVzZXIgY29tbXVuaXR5IGNvbnNpZGVycyBpdCBhbiBpbmRp dmlkdWFsIGxhbmd1YWdlLCBhbmQgdGhhdA0Kd2F5IEkgZG9u4oCZdCBoYXZlIHRvIGdldCB0aGUg SkFDIHRvIHRha2UgYWN0aW9uIG9uIHlldCBvbmUgZGVjaXNpb24gd2hlcmUgdGhlIGltcGFjdA0K aXMgdW5jbGVhciBhbmQgdGhlIGludGVybmFsIGV4cGVydGlzZSBvbiB3aGljaCB0byBiYXNlIHRo ZSBkZWNpc2lvbiBpcyBtaW5pbWFsLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5C dXQgbm90ZSB0aGF0IGZvciBvdXIgcHVycG9zZXMgaGVyZSBpdCByZWFsbHkgZG9lc27igJl0IG1h dHRlcg0Kd2hldGhlciDigJxobW7igJ0gZW5kZWQgdXAgYXMgYSBtYWNyb2xhbmd1YWdlIG9yIGFz IGEgY29sbGVjdGlvbjogZWl0aGVyIHdheSwgaXQgaXMNCnN0aWxsIHZhZ3VlIGFuZCB0aGVyZWZv cmUgbm90IGEgZ29vZCB0YWcgdG8gdXNlIGZvciByZXF1ZXN0aW5nIHJlc291cmNlcyBpZiB0aGUN CmRpc3RpbmN0aW9ucyBtYXR0ZXIgdG8geW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPklmIFBldGVyIENvbnN0YWJsZQ0K Y2FtZSBvdXQgYW5kIHNhaWQgdGhlIGZvbGxvd2luZywgdGhlbiBJIHdvdWxkIGFkbWl0IHRvIG15 IHNpbnMsIGdpdmUgaW4NCmdyYWNlZnVsbHksIGFuZCBnbyBhbG9uZyB3aXRoIGV4dGxhbmcuIDxv OnA+PC9vOnA+PC9wPg0KDQo8dWwgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K ICAgICBtc28tbGlzdDpsMiBsZXZlbDEgbGZvMic+JnF1b3Q7WWVzLCBlYWNoIG9mIHRoZSBIbW9u Z3MgKGVuY29tcGFzc2VkIGJ5DQogICAgIGhtbikgYXJlIG11dHVhbGx5IGludGVsbGlnaWJsZSwg YW5kIGFyZSBiZXR0ZXIgZm9yIGVhY2ggb25lIHRoYW4gYW5vdGhlcg0KICAgICBmYWxsYmFjayBs aWtlIENoaW5lc2UmcXVvdDs8bzpwPjwvbzpwPjwvbGk+DQo8L3VsPg0KDQo8dWwgdHlwZT1kaXNj Pg0KIDx1bCB0eXBlPWNpcmNsZT4NCiAgPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0Og0KICAgICAgYXV0bzttc28t bGlzdDpsMiBsZXZlbDIgbGZvMic+YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIGFsbCB0aGUgb3Ro ZXINCiAgICAgIGNhc2VzIHdpdGggbm8gcHJlZG9taW5hbnQgdmFyaWFudC4gPG86cD48L286cD48 L2xpPg0KIDwvdWw+DQo8L3VsPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0Kc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JDQpoYXZlbuKAmXQgY29tZSBvdXQgc2F5aW5nIHRoYXQ7IEkgYXNzdW1lIHRo ZXkgYXJlIG5vdC4gQnV0LCBJ4oCZbSBzYXlpbmcgdGhhdCB0aGlzDQpjYXNlIGlzIGlycmVsZXZh bnQgZm9yIHdoYXQgd2UgbmVlZCB0byBkZWNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8dWwgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KICAgICBtc28tbGlzdDpsMiBsZXZlbDEgbGZvMic+JnF1b3Q7WWVzLCBzdGFuZGFyZCBB cmFiaWMgaXMgaW50ZWxsaWdpYmxlIGZvcg0KICAgICBhbGwgdGhlIGVuY29tcGFzc2VkIGxhbmd1 YWdlcyBmcm9tIEFsZ2VyaWFuIFNhaGFyYW4gQXJhYmljIHRvIFNoaWhoaQ0KICAgICBBcmFiaWMs IGFuZCBhcmUgYmV0dGVyIGZvciBlYWNoIG9uZSB0aGFuIGFub3RoZXIgZmFsbGJhY2sgbGlrZQ0K ICAgICBGcmVuY2gmcXVvdDs8bzpwPjwvbzpwPjwvbGk+DQo8L3VsPg0KDQo8dWwgdHlwZT1kaXNj Pg0KIDx1bCB0eXBlPWNpcmNsZT4NCiAgPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0Og0KICAgICAgYXV0bzttc28t bGlzdDpsMiBsZXZlbDIgbGZvMic+YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIGFsbCB0aGUgb3Ro ZXINCiAgICAgIGNhc2VzIHdpdGggYSBwcmVkb21pbmFudCB2YXJpYW50LiA8bzpwPjwvbzpwPjwv bGk+DQogPC91bD4NCjwvdWw+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPldlbGwsIHdoYXQgeW914oCZcmUgYXNraW5nIG1lIHRvDQpz YXkgaGVyZSBpcyB0aGF0IGEgcmVxdWVzdCBmb3IgZS5nLiBBbGdlcmlhbiBTYWhhcmFuIEFyYWJp YyBjYW4gYXBwcm9wcmlhdGVseQ0KYmUgc2VydmljZWQgd2l0aCBTdGFuZGFyZCBBcmFiaWMgcmVz b3VyY2VzIHJhdGhlciB0aGFuLCBzYXksIEZyZW5jaC4gSW4gb3RoZXINCndvcmRzLCBhIGxhbmd1 YWdlLXJhbmdlIOKAnGFyLWFyceKAnSBjYW4gYXBwcm9wcmlhdGVseSBtYXRjaCDigJxhcuKAnSBj b250ZW50LiBCdXQgdGhhdA0Kd291bGQgbmV2ZXIgaGFwcGVuIGJlY2F1c2UgdGhhdCBpcyBub3Qg aG93IGxhbmd1YWdlLXJhbmdlIHdvcmtzLiBTbywgSeKAmW0gbm90DQpzdXJlIGhvdyB0aGlzIGlz IHJlbGV2YW50OiB3aGV0aGVyIHRoZSBsYW5ndWFnZS1yYW5nZSBpcyDigJxhci1hcnHigJ0gb3Ig 4oCcYXJx4oCdIHRoZQ0Kb25seSByZXN1bHRzIHJldHVybmVkIHdpbGwgYmUgQWxnZXJpYW4gU2Fo YXJhbiBBcmFiaWMsIHVubGVzcyBzb21lIG1vcmUNCmFkdmFuY2VkIGZhbGxiYWNrIGJlaGF2aW91 ciBpcyBpbnZva2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIHF1 ZXN0aW9uIHRoYXQgd291bGQgYmUNCnJlbGV2YW50IGluIHRlcm1zIG9mIGxhbmd1YWdlLXJhbmdl IGZvciB0aGUgQXJhYmljL01hbmRhcmluIGNhc2VzIGlzIHRoaXM6IGlmDQpzb21lb25lIHJlcXVl c3RzIOKAnGFy4oCdLCBob3cgYmFkIGlzIGl0IGlmIHRoZXkgZ2V0IHBhZ2VzIGluIOKAnGFyLWFy ceKAnT8gSWYgc29tZW9uZQ0KcmVxdWVzdHMg4oCcemjigJ0sIGhvdyBiYWQgaXMgaXQgaWYgdGhl eSBnZXQgcGFnZXMgaW4g4oCcemgtaGFra2HigJ0/IFRoZXNlIGFyZSB0aGUNCmNhc2VzIHRoYXQg cmVsYXRlIHRvIHRoZSB3YXkgbGFuZ3VhZ2UtcmFuZ2Ugd29ya3MuPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UGV0ZXI8L3NwYW4+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0K PC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561ABDC7644NAEXMSGC117re_-- --===============1316597711== 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 --===============1316597711==-- From ltru-bounces@ietf.org Thu Aug 30 11:22: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 1IQlr7-0008UN-S4; Thu, 30 Aug 2007 11:22:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQlr6-0008QV-Up for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 11:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlr6-0008OR-J5 for ltru@ietf.org; Thu, 30 Aug 2007 11:22:48 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQlr5-0007O2-6E for ltru@ietf.org; Thu, 30 Aug 2007 11:22:48 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007167646.msg for ; Thu, 30 Aug 2007 16:25:14 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 30 Aug 2007 16:22:41 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> Subject: RE: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Thu, 30 Aug 2007 16:17:47 +0100 Message-ID: <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfp/WL7kBhjP02qTGSOCv0rpSS7mgBGsxbg In-Reply-To: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> X-Spam-Processed: mx1.nexbyte.net, Thu, 30 Aug 2007 16:25:14 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1762102b4b=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, 30 Aug 2007 16:25:15 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > I'm not so sure about putting a Definitions section near the front. > Like Martin, I've also had trouble with ISO documents that > start me off with pages of definitions of terms I've never > seen before, and no context in which to place them. Usually > I look for such reference material near the end of a > document, not the beginning. What is important is that all > such material be in an easy-to-find place. In general, I have found that I cannot understand an ISO document unless I refer to the Terms and Definitions section. I am in agreement with Doug, whether it be placed front or back matters not but I think to devise a Terms and Definitions section would be very useful to newbies. It would also cement the terminology for ease of use in other documents wishing to reference the RFC. Best Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@roadrunner.com] > Sent: 29 August 2007 06:28 > To: LTRU Working Group > Subject: Re: Introduction (was: Re: [Ltru] > draft-ietf-ltru-rfc4646bis-08) > > I am in fairly weak agreement with Marion over the introductory text. > The wording about human beings on our planet, past and > present, has certainly been around since RFC 3066, but RFCs > have become more formal in their wording (and in other ways) > since then. RFC 4646 is over four times as long as 3066 and > might call for a different approach. The current wording has > also been parodied more than once in other documents. > > I'm not so sure about putting a Definitions section near the front. > Like Martin, I've also had trouble with ISO documents that > start me off with pages of definitions of terms I've never > seen before, and no context in which to place them. Usually > I look for such reference material near the end of a > document, not the beginning. What is important is that all > such material be in an easy-to-find place. > > However, at this stage it is much more important to me that > we resolve the real technical debate over extlangs, and get > the drafts to WG Last Call, than to engage in fine-tuning and > wordsmithing at this level. The current wording doesn't > cause any confusion or misinterpretation. If we weren't > already half a year behind schedule, I would probably care > more about this. > > -- > Doug Ewell . Fullerton, California, USA . RFC 4645 . UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 12:04: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 1IQmVD-0002g1-C3; Thu, 30 Aug 2007 12:04:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQmVC-0002fl-0z for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 12:04:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmVB-0002fb-MI for ltru@ietf.org; Thu, 30 Aug 2007 12:04:13 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQmVB-0005OB-7K for ltru@ietf.org; Thu, 30 Aug 2007 12:04:13 -0400 Received: (qmail 76097 messnum 11062337 invoked from network[194.125.174.30/ts09-030.dublin.indigo.ie]); 30 Aug 2007 16:04:11 -0000 Received: from ts09-030.dublin.indigo.ie (HELO ?194.125.174.30?) (194.125.174.30) by mail11.svc.cra.dublin.eircom.net (qp 76097) with SMTP; 30 Aug 2007 16:04:11 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Thu, 30 Aug 2007 17:04:12 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I am in total agreement with DG on this matter (as set out below in =20 her msg of today - as cited below - which msg of hers echoes the =20 substance of one of mine of yesterday, I believe). mg On 30 Aug 2007, at 15:17, scr=EDobh Debbie Garside: > ... I think to devise a Terms > and Definitions section would be very useful to newbies. It would =20 > also > cement the terminology for ease of use in other documents wishing to > reference the RFC. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 12:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmr5-0004rJ-9n; Thu, 30 Aug 2007 12:26:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQmr3-0004b8-Bh for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 12:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmr2-0004Y5-UR for ltru@ietf.org; Thu, 30 Aug 2007 12:26:48 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQmr1-0000yf-MX for ltru@ietf.org; Thu, 30 Aug 2007 12:26:48 -0400 Received: by nz-out-0506.google.com with SMTP id n1so418143nzf for ; Thu, 30 Aug 2007 09:26:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=ibJ4E1u7wwtnDaoe0Z6r8vojRB3mafF9LC+8IienXTWFGv8GFCeDFD3ZRsnWwmu/Ex73JG8CkP3A0XCdj2KXQfKZHdBC/bO8i3hZuLp9OYC7v+DLMW3JGz1TYA1G+bAQLXF/FBG5WjS2Sj+nckFs75Z/dTOzBVcmz3o9RGqOpPw= 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=E6E9ROZYZYfvv4X21Py6NfF/w5e0b1404loTL8BeFjg37/t54WjJxpJd6CmGYDzWzkjm9WAnk0gYWVrqDZLzDWOnr1TBgdM5ivuAc5/k1hvc1s1OEGorcwRbjcFU/ptigibYSKVQbinhB8LxTjgSKH8x1qdxFzVAGOV7WwYvpkQ= Received: by 10.114.103.1 with SMTP id a1mr107340wac.1188491206377; Thu, 30 Aug 2007 09:26:46 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Thu, 30 Aug 2007 09:26:46 -0700 (PDT) Message-ID: <30b660a20708300926v71aeb83eu33c8ccaa0d986a01@mail.gmail.com> Date: Thu, 30 Aug 2007 09:26:46 -0700 From: "Mark Davis" To: "Marion Gunn" Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) In-Reply-To: MIME-Version: 1.0 References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> X-Google-Sender-Auth: b437fd1dcee43a10 X-Spam-Score: 0.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: , Content-Type: multipart/mixed; boundary="===============0365927648==" Errors-To: ltru-bounces@ietf.org --===============0365927648== Content-Type: multipart/alternative; boundary="----=_Part_6737_25084171.1188491206342" ------=_Part_6737_25084171.1188491206342 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBmaW5kIHRoZSB0eXBpY2FsIFRlcm1zIGFuZCBEZWZpbml0aW9ucyBzZWN0aW9ucyBhdCB0aGUg c3RhcnQgb2YgbWFueSBJU08KZG9jdW1lbnRzIGFjdHVhbGx5IGNvdW50ZXItcHJvZHVjdGl2ZS4g VGhlIGl0ZW1zIGFyZSBwcmVzZW50ZWQgYmVmb3JlIHlvdQpoYXZlIGFueSBiYWNrZ3JvdW5kIGZv ciB3aGF0IHRoZSBkZWZpbml0aW9ucyByZWFsbHkgbWVhbiwgYW5kIGFyZSBpbiBubwpjb2hlc2l2 ZSBvcmRlci4KCkFzIHlvdSByZWFkIHRoZSBkb2N1bWVudCwgZWFjaCB0ZWNobmljYWwgdGVybSBz aG91bGQgYmUgZGVmaW5lZCBpbiB0aGUKcGFyYWdyYXBoIHdoZXJlIGl0IGlzIGZpcnN0IHVzZWQu IElmIHRoYXQgaXMgbm90IHRoZSBjYXNlLCB0aGVuIHBsZWFzZSBtYWtlCnNwZWNpZmljIHN1Z2dl c3Rpb25zIGZvciBhZGRpdGlvbnMgdG8gdGhlIHRleHQuCgpJJ20gbm90LCBpbiB0aGVvcnksIGFn YWluc3QgaGF2aW5nIGEgZ2xvc3Nhcnkgb2YgY29sbGVjdGVkIHRlcm1zIGF0IHRoZSBlbmQKb2Yg dGhlIGRvY3VtZW50IGZvciByZWZlcmVuY2UuIEJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIHdvcnRo IHRoZSB0aW1lIGFuZAplZmZvcnQgY29tcGFyZWQgdG8gZ2V0dGluZyB0aGUgImZpcnN0IHVzYWdl IiBpbnN0YW5jZXMgY29ycmVjdC4gQW5kIGl0IG1pZ2h0CmJldHRlciBnbyBpbiBhICJMYW5ndWFn ZSBUYWcgVHV0b3JpYWwiLgoKTWFyawoKT24gOC8zMC8wNywgTWFyaW9uIEd1bm4gPG1ndW5uQGVn dC5pZT4gd3JvdGU6Cj4KPiBJIGFtIGluIHRvdGFsIGFncmVlbWVudCB3aXRoIERHIG9uIHRoaXMg bWF0dGVyIChhcyBzZXQgb3V0IGJlbG93IGluCj4gaGVyIG1zZyBvZiB0b2RheSAtIGFzIGNpdGVk IGJlbG93IC0gd2hpY2ggbXNnIG9mIGhlcnMgZWNob2VzIHRoZQo+IHN1YnN0YW5jZSBvZiBvbmUg b2YgbWluZSBvZiB5ZXN0ZXJkYXksIEkgYmVsaWV2ZSkuCj4gbWcKPgo+IE9uIDMwIEF1ZyAyMDA3 LCBhdCAxNToxNywgc2Nyw61vYmggRGViYmllIEdhcnNpZGU6Cj4KPiA+IC4uLiBJIHRoaW5rIHRv IGRldmlzZSBhIFRlcm1zCj4gPiBhbmQgRGVmaW5pdGlvbnMgc2VjdGlvbiB3b3VsZCBiZSB2ZXJ5 IHVzZWZ1bCB0byBuZXdiaWVzLiAgSXQgd291bGQKPiA+IGFsc28KPiA+IGNlbWVudCB0aGUgdGVy bWlub2xvZ3kgZm9yIGVhc2Ugb2YgdXNlIGluIG90aGVyIGRvY3VtZW50cyB3aXNoaW5nIHRvCj4g PiByZWZlcmVuY2UgdGhlIFJGQy4KPgo+IC0gLQo+IE1hcmlvbiBHdW5uICogRUdUZW8gKEVzdGFi LjE5OTEpCj4gMjcgUMOhaXJjIGFuIEZow6lpdGhsaW5uLCBCYWlsZSBhbgo+IEJow7N0aGFpciwg Q28uIMOBdGhhIENsaWF0aCwgw4lpcmUuCj4gKiBtZ3VubkBlZ3QuaWUgKiBlYW1vbm5AZWd0Lmll ICoKPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgoKCgotLSAKTWFyawo= ------=_Part_6737_25084171.1188491206342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBmaW5kIHRoZSB0eXBpY2FsIFRlcm1zIGFuZCBEZWZpbml0aW9ucyBzZWN0aW9ucyBhdCB0aGUg c3RhcnQgb2YgbWFueSBJU08gZG9jdW1lbnRzIGFjdHVhbGx5IGNvdW50ZXItcHJvZHVjdGl2ZS4g VGhlIGl0ZW1zIGFyZSBwcmVzZW50ZWQgYmVmb3JlIHlvdSBoYXZlIGFueSBiYWNrZ3JvdW5kIGZv ciB3aGF0IHRoZSBkZWZpbml0aW9ucyByZWFsbHkgbWVhbiwgYW5kIGFyZSBpbiBubyBjb2hlc2l2 ZSBvcmRlci4KPGJyPjxicj5BcyB5b3UgcmVhZCB0aGUgZG9jdW1lbnQsIGVhY2ggdGVjaG5pY2Fs IHRlcm0gc2hvdWxkIGJlIGRlZmluZWQgaW4gdGhlIHBhcmFncmFwaCB3aGVyZSBpdCBpcyBmaXJz dCB1c2VkLiBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgdGhlbiBwbGVhc2UgbWFrZSBzcGVjaWZp YyBzdWdnZXN0aW9ucyBmb3IgYWRkaXRpb25zIHRvIHRoZSB0ZXh0Ljxicj48YnI+SSYjMzk7bSBu b3QsIGluIHRoZW9yeSwgYWdhaW5zdCBoYXZpbmcgYSBnbG9zc2FyeSBvZiBjb2xsZWN0ZWQgdGVy bXMgYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQgZm9yIHJlZmVyZW5jZS4gQnV0IEkgZG9uJiMz OTt0IHRoaW5rIGl0IGlzIHdvcnRoIHRoZSB0aW1lIGFuZCBlZmZvcnQgY29tcGFyZWQgdG8gZ2V0 dGluZyB0aGUgJnF1b3Q7Zmlyc3QgdXNhZ2UmcXVvdDsgaW5zdGFuY2VzIGNvcnJlY3QuIEFuZCBp dCBtaWdodCBiZXR0ZXIgZ28gaW4gYSAmcXVvdDtMYW5ndWFnZSBUYWcgVHV0b3JpYWwmcXVvdDsu Cjxicj48YnI+TWFyazxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDgv MzAvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5NYXJpb24gR3VubjwvYj4gJmx0Ozxh IGhyZWY9Im1haWx0bzptZ3VubkBlZ3QuaWUiPm1ndW5uQGVndC5pZTwvYT4mZ3Q7IHdyb3RlOjwv c3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDog MXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg cGFkZGluZy1sZWZ0OiAxZXg7Ij4KSSBhbSBpbiB0b3RhbCBhZ3JlZW1lbnQgd2l0aCBERyBvbiB0 aGlzIG1hdHRlciAoYXMgc2V0IG91dCBiZWxvdyBpbjxicj5oZXIgbXNnIG9mIHRvZGF5IC0gYXMg Y2l0ZWQgYmVsb3cgLSB3aGljaCBtc2cgb2YgaGVycyBlY2hvZXMgdGhlPGJyPnN1YnN0YW5jZSBv ZiBvbmUgb2YgbWluZSBvZiB5ZXN0ZXJkYXksIEkgYmVsaWV2ZSkuPGJyPm1nPGJyPjxicj5PbiAz MCBBdWcgMjAwNywgYXQgMTU6MTcsIHNjcsOtb2JoIERlYmJpZSBHYXJzaWRlOgo8YnI+PGJyPiZn dDsgLi4uIEkgdGhpbmsgdG8gZGV2aXNlIGEgVGVybXM8YnI+Jmd0OyBhbmQgRGVmaW5pdGlvbnMg c2VjdGlvbiB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCB0byBuZXdiaWVzLiZuYnNwOyZuYnNwO0l0IHdv dWxkPGJyPiZndDsgYWxzbzxicj4mZ3Q7IGNlbWVudCB0aGUgdGVybWlub2xvZ3kgZm9yIGVhc2Ug b2YgdXNlIGluIG90aGVyIGRvY3VtZW50cyB3aXNoaW5nIHRvPGJyPiZndDsgcmVmZXJlbmNlIHRo ZSBSRkMuCjxicj48YnI+LSAtPGJyPk1hcmlvbiBHdW5uICogRUdUZW8gKEVzdGFiLjE5OTEpPGJy PjI3IFDDoWlyYyBhbiBGaMOpaXRobGlubiwgQmFpbGUgYW48YnI+QmjDs3RoYWlyLCBDby4gw4F0 aGEgQ2xpYXRoLCDDiWlyZS48YnI+KiA8YSBocmVmPSJtYWlsdG86bWd1bm5AZWd0LmllIj5tZ3Vu bkBlZ3QuaWU8L2E+ICogPGEgaHJlZj0ibWFpbHRvOmVhbW9ubkBlZ3QuaWUiPmVhbW9ubkBlZ3Qu aWU8L2E+CiAqPGJyPjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpM dHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1CjwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xl YXI9ImFsbCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_6737_25084171.1188491206342-- --===============0365927648== 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 --===============0365927648==-- From ltru-bounces@ietf.org Thu Aug 30 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 1IQn30-000763-AA; Thu, 30 Aug 2007 12:39:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQn2z-00075x-V5 for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 12:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQn2z-00075h-LS for ltru@ietf.org; Thu, 30 Aug 2007 12:39:09 -0400 Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQn2y-0001Gv-4g for ltru@ietf.org; Thu, 30 Aug 2007 12:39:09 -0400 Received: (qmail 55862 messnum 5376514 invoked from network[194.125.205.91/ts07-091.dublin.indigo.ie]); 30 Aug 2007 16:39:03 -0000 Received: from ts07-091.dublin.indigo.ie (HELO ?194.125.205.91?) (194.125.205.91) by mail08.svc.cra.dublin.eircom.net (qp 55862) with SMTP; 30 Aug 2007 16:39:03 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20708300926v71aeb83eu33c8ccaa0d986a01@mail.gmail.com> References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> <30b660a20708300926v71aeb83eu33c8ccaa0d986a01@mail.gmail.com> Message-Id: From: Marion Gunn Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Thu, 30 Aug 2007 17:38:58 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2075556667==" Errors-To: ltru-bounces@ietf.org --===============2075556667== Content-Type: multipart/alternative; boundary=Apple-Mail-2--265058629 --Apple-Mail-2--265058629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On 30 Aug 2007, at 16:26, scr=EDobh Mark Davis: > I find the typical Terms and Definitions sections at the start of =20 > many ISO documents actually counter-productive. The items are =20 > presented before you have any background for what the definitions =20 > really mean, and are in no cohesive order. Alphabetical order is cohesive enough for most professional users. =20 Added to that, even for newbies, it is predictable, logical, =20 consistent with ISO documents in general, with which one would expect =20= most users of this list to be familiar. > > As you read the document, each technical term should be defined in =20 > the paragraph where it is first used. If that is not the case, then =20= > please make specific suggestions for additions to the text. Is that the case with regard to this particular document, Mark? Or - =20 rather than asking that question - let us assume that it is, then =20 have its editors simply cut and past each "first use mention" into a =20 "Terms and Definitions" section, so that it can be used by those used =20= to using dictionaries and ISO documents with the same ease as it can =20 be ignored by those who are not. > > I'm not, in theory, against having a glossary of collected terms at =20= > the end of the document for reference. Good. It would be a worry if you were against including in the =20 document a glossary of collected terms (I say this because I =20 generally find myself in agreement with much of the content of many =20 of your msgs, and would not like this to be different). > But I don't think it is worth the time and effort compared to =20 > getting the "first usage" instances correct. And it might better go =20= > in a "Language Tag Tutorial". If you are proposing to compose a "Language Tag Tutorial", that would =20= probably be useful, as well (but much more work for you to compile =20 than the usual "Terms and Definitions" component users of ISO =20 standards find so handy for ref.). mg > > > Mark > > On 8/30/07, Marion Gunn wrote: > I am in total agreement with DG on this matter (as set out below in > her msg of today - as cited below - which msg of hers echoes the > substance of one of mine of yesterday, I believe). > mg > > On 30 Aug 2007, at 15:17, scr=EDobh Debbie Garside: > > > ... I think to devise a Terms > > and Definitions section would be very useful to newbies. It would > > also > > cement the terminology for ease of use in other documents wishing to > > reference the RFC. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-2--265058629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 30 Aug 2007, at = 16:26, scr=EDobh Mark Davis:

I find the = typical Terms and Definitions sections at the start of many ISO = documents actually counter-productive. The items are presented before = you have any background for what the definitions really mean, and are in = no cohesive order.

Alphabetical order is cohesive = enough for most professional users. Added to that, even for newbies, it = is predictable, logical, consistent with ISO documents in general, with = which one would expect most users of this list to be = familiar.


As you read the = document, each technical term should be defined in the paragraph where = it is first used. If that is not the case, then please make specific = suggestions for additions to the text.

Is that the case with regard to = this particular document, Mark? Or - rather than asking that question -=A0= let us assume that it is, then have its editors simply cut and past = each "first use mention" into a "Terms and Definitions" section, so that = it can be used by those used to using dictionaries and ISO documents = with the same ease as it can be ignored by those who are = not.


I'm not, in theory, = against having a glossary of collected terms at the end of the document = for reference.

Good. It would be a worry if you = were against including in the document a glossary of collected terms (I = say this because I generally find myself in agreement with much of the = content of many of your msgs, and would not like this to be = different).

But I don't think it = is worth the time and effort compared to getting the "first usage" = instances correct. And it might better go in a "Language Tag = Tutorial".

If=A0you are proposing to = compose a "Language Tag Tutorial", that would probably be useful, as = well=A0 (but much more work for you to compile than the usual "Terms and = Definitions" component users of ISO standards find so handy for = ref.).
mg

=

Mark

On 8/30/07, Marion Gunn <mgunn@egt.ie> = wrote:
I am in total agreement with DG on this matter (as set out below = in
her msg of today - as cited below - which msg of hers echoes = the
substance of one of mine of yesterday, I = believe).
mg

On 30 Aug 2007, at 15:17, scr=EDobh Debbie = Garside:

> ... I think to devise a Terms
> and = Definitions section would be very useful to newbies.=A0=A0It = would
> also
> cement the terminology for ease of use in = other documents wishing to
> reference the = RFC.=A0

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

= --Apple-Mail-2--265058629-- --===============2075556667== 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 --===============2075556667==-- From ltru-bounces@ietf.org Thu Aug 30 12:39: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 1IQn3L-0007Aj-Fb; Thu, 30 Aug 2007 12:39:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQn3K-0007Ad-8D for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 12:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQn3J-0007AU-Ug for ltru@ietf.org; Thu, 30 Aug 2007 12:39:29 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQn3I-0001HZ-63 for ltru@ietf.org; Thu, 30 Aug 2007 12:39:29 -0400 Received: by wa-out-1112.google.com with SMTP id k40so803596wah for ; Thu, 30 Aug 2007 09:39:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=cvCrrPcKQFnWFG/MfGuV1gA1YkqEc6VzS5yd/uLw/vBaZDIuiKYY8UXrRbJwrXIFsrLBaEGC8qDdAQQdYokv+YRAFx0F7E6l3aFqAgXj2uyTMKNHaejZ90u/wksN150SUKMWhrX5bOD+iDcUrplLqB7jPMdOek818LBbS08h9MI= 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=MAJMiE4mUqujwmvoJXtthFOwEPnTrcD4KmEiGPKWtA8wbQM1pQqrPH9GbxcBAd+/Ssubt2kollu7D9qGCXiD7w9qK0hSoPiOEe0I9W1ONWajmQUMdFXCQZNzdxnwQrd5keibd+5ooBMlv/HzMhzj/MlKPjK3Ck7/u/AxupcHLE4= Received: by 10.114.106.1 with SMTP id e1mr10725wac.1188491966912; Thu, 30 Aug 2007 09:39:26 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Thu, 30 Aug 2007 09:39:26 -0700 (PDT) Message-ID: <30b660a20708300939i959d765o4bc21c0b67a46bda@mail.gmail.com> Date: Thu, 30 Aug 2007 09:39:26 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: extlang In-Reply-To: MIME-Version: 1.0 References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> X-Google-Sender-Auth: 987a79792e698403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 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="===============2060856516==" Errors-To: ltru-bounces@ietf.org --===============2060856516== Content-Type: multipart/alternative; boundary="----=_Part_6809_22761074.1188491966852" ------=_Part_6809_22761074.1188491966852 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmtzIFBldGVyOyBiYWNrZ3JvdW5kIG1hdGVyaWFsIGxpa2UgdGhpcyBhbmQgc3BlY2lmaWMg c2NlbmFyaW9zIHJlYWxseQpoZWxwIHRvIG1ha2UgY2xlYXIgd2hhdCB0aGUgcmVxdWlyZW1lbnRz IGFyZSwgYmVjYXVzZSB0aGV5IGFyZSB2ZXJ5CmRpZmZlcmVudCBkZXBlbmRpbmcgb24gdGhlIGtp bmRzIG9mIHVzYWdlIHBhdHRlcm5zIHBlb3BsZSBoYXZlIGluIG1pbmQuCldoaWxlIEkgbWF5IGRp c2FncmVlIHdpdGggc29tZSBvZiB5b3VyIHBvaW50cywgdGhpcyBkaXNjdXNzaW9uIGlzIGdvaW5n IGluIGEKZ29vZCBkaXJlY3Rpb24uCgpJdCBpcyBrZXkgdG8gaWRlbnRpZnkgZXhhY3RseSBob3cg ZXh0bGFuZyB3b3VsZCB3b3JrIGluIGRpZmZlcmVudApzaXR1YXRpb25zLiBXZSB0aG91Z2h0IGxv bmcgYW5kIGhhcmQgYWJvdXQgdGhlIGludHJvZHVjdGlvbiBvZiBzY3JpcHRzLCBhbmQKbG9va2Vk IGF0IG1hbnkgZGlmZmVyZW50IGFzcGVjdHMgLS0gd2UgbmVlZCB0byBkbyB0aGUgc2FtZSB3aXRo IHRoZSBleHRsYW5nCnByb3Bvc2FsLgoKSXQgYXBwZWFycyB0aGF0IHRoZXJlIGFyZSB0d28gc3Vi c3RhbnRpYWxseSBkaWZmZXJlbnQga2luZHMgb2YgdXNhZ2UgdGhhdCB3ZQpuZWVkIHRvIGV4YW1p bmU6CgpSZXNvdXJjZSBMb29rdXA6IHVzZXIgcmVxdWVzdHMgbGFuZ3VhZ2UgWDsgc3VwcGxpZXIg ZG9lc24ndCBoYXZlIGV4YWN0bHkgWApidXQgd2FudHMgdG8gZ2V0IHRoZSBiZXN0IG1hdGNoIChp biB0aGUgc2Vuc2Ugb2YgbW9zdCBsaWtlbHkgdG8gYmUKdW5kZXJzdG9vZCBieSB0aGUgdXNlciku IFRoZSBleHRsYW5nIHByb3BvbmVudHMgYXBwZWFyZWQgdG8gYmUgYXJndWluZyB0aGF0Cml0IHdh cyBiZXR0ZXIgZm9yIHRoaXMgY2FzZSwgYnV0IGl0IGp1c3QgZG9lc24ndCBzZWVtIHRvIHdvcmsg d2VsbC4KClF1ZXJ5OiB1c2VyIHJlcXVlc3RzIGNvbnRlbnQgbWF0Y2hpbmcgWCwgaW4gc29tZSAi bG9vc2UiIGZhc2hpb24sIHN1Y2ggYXMgYQpsaWJyYXJ5IGxvb2t1cC4gVW5sZXNzIEknbSBtaXNy ZWFkaW5nIFBldGVyLCBpdCBhcHBlYXJzIHRoYXQgdGhpcyB3YXMKYWN0dWFsbHkgdGhlIHByaW1h cnkgdGFyZ2V0IG9mIHRoZSBleHRsYW5nIG1lY2hhbmlzbS4gU28gdGhpcyBiZWFycyBzb21lCnNp Z25pZmljYW50IGF0dGVudGlvbiwgdG8gc2VlIGhvdyB0aGUgZXh0bGFuZyBtZWNoYW5pc20gd291 bGQgd29yayBpbiB0aGlzCmNhc2UuCgpPbmNlIHdlIGdldCBhIHNlbnNlIG9mIHRoZSByZWxhdGl2 ZSBiZW5lZml0cy9kcmF3YmFja3Mgb2YgZXh0bGFuZyBmb3IgZWFjaApvZiB0aGVzZSAtLSBhbmQg d2VpZ2h0IHRoZSByZWxhdGl2ZSBpbXBvcnRhbmNlIG9mIHRoZXNlIHdpdGggcmVzcGVjdCB0bwps YW5ndWFnZSB0YWcgdXNhZ2UsIHRoZW4gd2UnZCBiZSBpbiBiZXR0ZXIgc2hhcGUgdG8ga25vdyB0 aGUgb3ZlcmFsbCBwcm9zCmFuZCBjb25zIG9mIGFkZGluZyBpdC4KCk1hcmsKCk9uIDgvMzAvMDcs IFBldGVyIENvbnN0YWJsZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiAgIEhl cmUgYXJlIG15IHJlc3BvbnNlcyB0byB0aGlzIG1haWwgZnJvbSBNYXJrLiBJIGNyaXRpcXVlIGhp cwo+IGFyZ3VtZW50YXRpb24sIGJ1dCBiZSBjYXJlZnVsIG5vdCB0byBqdW1wIHRvIGNvbmNsdXNp b25zIGFib3V0IHdoYXQgSSdtCj4gc2F5aW5nIHJlZ2FyZGluZyB0aGUgb3BlbiBpc3N1ZTogd2hh dCBJIHNheSBoZXJlIGNyaXRpcXVlcyBNYXJrcyBhcmd1bWVudHMKPiBhZ2FpbnN0IGV4dGxhbmcs IGJ1dCBkb2VzIG5vdCBhdHRlbXB0IHRvIG1ha2UgYSBzdWZmaWNpZW50IGNhc2UgZm9yIGV4dGxh bmcuCj4KPgo+Cj4gKiAqCj4KPiAqRnJvbToqIE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlz QGljdS1wcm9qZWN0Lm9yZ10KPiAqU2VudDoqIFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAwNyA2OjEy IFBNCj4KPiAqKgo+Cj4gPiBJZiBhIGxhbmd1YWdlIHl5eSBoYXMgdGhlIG1hY3JvbGFuZ3VhZ2Ug eHgsIHdlIGFyZSB0YWxraW5nIGFib3V0IHR3bwo+IHBvc3NpYmxlIHJlcHJlc2VudGF0aW9ucwo+ Cj4gYSkgZXh0bGFuZzogeHgteXl5Cj4gYikgbGFuZzogeXl5Cj4KPgo+ID5UaGUgbWFpbiByZWFz b24gSSd2ZSBoZWFyZCBmcm9tIHlvdSBmb3IgZG9pbmcgKGEpIGluc3RlYWQgb2YgKGIpIGlzIHRo YXQKPiAoYSkgaXQgaGFzIGJldHRlciBmYWxsYmFjayBiZWhhdmlvci4gRm9yIHRoYXQgdG8gYmUg dHJ1ZSwgeHggaGFzIHRvIGJlIGEKPiBnb29kIGZhbGxiYWNrIGZvciB1c2VycyBvZiB5eXksIGlu IHRoZSBtYWpvcml0eSBvZiBjYXNlcy4KPgo+IEkgdGhpbmsgImZhbGxiYWNrIGJlaGF2aW9yIiBu ZWVkcyBtb3JlIGNhcmVmdWwgY29uc2lkZXJhdGlvbiBoZXJlLiBJdAo+IGFwcGVhcnMgdGhhdCBN YXJrIGlzIGZvY3VzaW5nIG9uIGEgcGFydGljdWxhciBzY2VuYXJpbzogcmVxdWVzdCBpcyBmb3IK PiByZXNvdXJjZSBpbiBsYW5nIEEsIGJ1dCB0aGF0IGlzIG5vdCBhdmFpbGFibGUgc28gcHJvY2Vz cyBuZWVkcyB0byBmYWxsYmFjawo+IHRvIGEgbGlrZWx5LW5leHQtYmVzdCBjaG9pY2UgYXZhaWxh YmxlLgo+Cj4gV2hlbiBJIGZpcnN0IHByb3Bvc2VkIHRoZSBleHRsYW5nIG1lY2hhbmlzbSwgdGhh dCB3YXMgbm90IHRoZSBpbnRlbnQuCj4gUmF0aGVyLCB0aGUgaW50ZW50IHdhcyBmb2N1c2VkIG9u IGFub3RoZXIgc2NlbmFyaW86IGF1dGhvciB3YW50cyB0byB0YWcKPiBjb250ZW50IHVzaW5nIG1v cmUgc3BlY2lmaWMgSUQgeXl5LCBidXQgbWFueSByZXF1ZXN0cywgZXNwZWNpYWxseSBmcm9tCj4g bGVnYWN5IGltcGxlbWVudGF0aW9ucywgd2lsbCB1c2UgeHgsIHdoaWNoIGhhcyBiZWVuIGluIHVz ZSBmb3Igc29tZSB0aW1lLgo+IFRoaXMgc2NlbmFyaW8gcGVydGFpbnMgdG8gTGFuZ3VhZ2UtcmFu Z2UgYXMgZGVmaW5lZCBzaW5jZSBIVFRQLzEuMS4KPgo+ICAgICAgICAgICAgICAgICBMYW5ndWFn ZS1yYW5nZSA9IHh4Cj4KPiAgICAgICAgICAgICAgICAgQ29udGVudCB0byBiZSBtYXRjaGVkID0g eXl5IG9yIHh4LXl5eQo+Cj4gSWYgdGhlIGNvbnRlbnQgaXMgdGFnZ2VkIHh4LXl5eSwgdGhlcmUg aXMgYSBtYXRjaC4gQnV0IGlmIHRoZSBjb250ZW50IGlzCj4gdGFnZ2VkIHl5eSwgdGhlcmUgaXMg bm8gbWF0Y2ggdXNpbmcgYSBiYXNpYyBhbGdvcml0aG0g4oCTIG9uZSB3b3VsZCBuZWVkIGEKPiBt b3JlIGFkdmFuY2VkIGFsZ29yaXRobSB0aGF0IGtub3dzIGFib3V0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB4eCBhbmQKPiB5eXkuCj4KPiBJIHRoaW5rIE1hcmsncyBpcyB0aGUgcmVjaXByb2Nh bCBzY2VuYXJpbzogdXNlcnMgcHJlZmVycyB0aGUgc3BlY2lmaWMKPiB2YXJpZXR5IHl5eSwgYnV0 IG1vc3QgY29udGVudCBpcyBhbHJlYWR5IHRhZ2dlZCB1c2luZyB4eCwgd2hpY2ggaGFzIGJlZW4g aW4KPiB1c2UgZm9yIHNvbWUgdGltZS4gVGhpcyBpcyBhIHBhcnRpY3VsYXIgY2FzZSBpbiB0aGUg Z2VuZXJhbCBzZXQgb2YgZmFsbGJhY2sKPiBzY2VuYXJpb3MsIGFuZCBpdCBzZWVtcyB0byBiZSBl eGFjdGx5IHRoZSBvbmUgTWFyayBpcyBmb2N1c2luZyBvbi4gQnV0IG5vdGUKPiB0aGF0IGxhbmd1 YWdlLXJhbmdlIGRvZXMgbm90IGFwcGx5IGhlcmUg4oCTIG9yLCBmcm9tIGEgZGlmZmVyZW50IHBl cnNwZWN0aXZlLAo+IGRvZXNuJ3Qgd29yayBoZXJlOgo+Cj4gbGFuZ3VhZ2UtcmFuZ2UgPSB5eXkg b3IgeHgteXl5Cj4KPiBjb250ZW50IHRvIGJlIG1hdGNoZWQgPSB4eAo+Cj4gV2hpY2hldmVyIHdh eSB0aGUgbGFuZ3VhZ2UtcmFuZ2UgaXMgZXhwcmVzc2VkLCB0aGVyZSBpcyBubyBtYXRjaCB3aXRo IGEKPiBiYXNpYyBhbGdvcml0aG0g4oCTIG9uZSB3b3VsZCBuZWVkIGEgbW9yZSBhZHZhbmNlZCBh bGdvcml0aG0gdGhhdCBrbm93cyBhYm91dAo+IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB4eCBh bmQgeXl5Lgo+Cj4gU28sIGNvbnNpZGVyaW5nIGp1c3QgdGhvc2Ugc2NlbmFyaW9zLCB4eC15eXkg aGFzIGFuIGFkdmFudGFnZSBvdmVyIHl5eSBpbgo+IHRoYXQgaXQgcHJvdmlkZXMgYW4gYWR2YW50 YWdlIGZvciB0aGUgb25lIHNjZW5hcmlvIHdoaWxlIHRoZSB0d28KPiBhbHRlcm5hdGl2ZXMgYXJl IGVxdWFsIHdydCB0aGUgb3RoZXIuIE9mIGNvdXJzZSwgdGhvc2UgYXJlbid0IHRoZSBvbmx5Cj4g c2NlbmFyaW9zLiBXZSBuZWVkIHRvIGNvbnNpZGVyIGEgYnJvYWRlciBzZXQgb2Ygc2NlbmFyaW9z LCBhbmQgYWxzbyBjb25zaWRlcgo+IGhvdyB0aGV5IHJhbmsgaW4gcHJpb3JpdHkuCj4KPgo+Cj4K PiA+IFRoZXJlIGFyZSAoYXQgbGVhc3QpIHR3byBjYXNlcyB0byBjb25zaWRlciBoZXJlLgo+Cj4g ICAgMS4gVGhlcmUgaXMgYSBwcmVkb21pbmVudCBjaG9pY2UgaW4gdGhlIGluZHVzdHJ5IGZvciB0 aGUgbWFjcm8KPiAgICBsYW5ndWFnZS4gRm9yIGV4YW1wbGUsIHRoZSBjb250ZW50IGZvciB6aCBp cyB0eXBpY2FsbHkgYWx3YXlzIE1hbmRhcmluOyB0aGUKPiAgICBjb250ZW50IGZvciBhciBpcyB0 eXBpY2FsbHkgYWx3YXlzIHN0YW5kYXJkIEFyYWJpYy4KPgo+IFR5cGljYWxseSwgeWVzLiBXZSBq dXN0IG11c3Qgbm90IGFzc3VtZSB0aGF0IGlzIGFsd2F5cyB0aGUgY2FzZS4gVGhlIHZlcnkKPiB0 aGluZyB0aGF0IHN0YXJ0ZWQgbWUgdGhpbmtpbmcgYWJvdXQgdGhlIG1hY3JvbGFuZ3VhZ2UgY29u Y2VwdCBpbiB0aGUgZmlyc3QKPiBwbGFjZSwgcmF0aGVyIHRoYW4gZXF1YXRpbmcgZXhpc3Rpbmcg SVNPIDYzOSBJRHMgbGlrZSB6aCBhbmQgYXIgd2l0aCB0aGUKPiBwcmVkb21pbmFudCB2YXJpZXR5 LCB3YXMgdGhlIGZhY3QgdGhhdCB0aGVyZSB3ZXJlIGxhbmd1YWdlIHRhZ3MgcmVnaXN0ZXJlZAo+ IHdpdGggSUFOQSBleHBsaWNpdGx5IGFzc29jaWF0aW5nIHpoIHdpdGggQ2hpbmVzZSBsYW5ndWFn ZXMgb3RoZXIgdGhhbgo+IE1hbmRhcmluLiBXaGVuIGZhY2VkIHdpdGggcHJlLWV4aXN0aW5nIHVz YWdlICJ6aC13dXUiLCB3ZSBoYXZlIHR3byBjaG9pY2VzOgo+Cj4gYSkgd3V1IGlzIGEgc3BlY2lm aWMgdmFyaWV0eSBvZiB6aAo+Cj4gYikgd3V1IHJlbGF0ZXMgdG8gemggaW4gc29tZSBvdGhlciB3 YXksIHN1Y2ggYXMgemggYmVpbmcgYSBnb29kIGZhbGxiYWNrCj4gY2hvaWNlCj4KPiBJIHN1c3Bl Y3QgdGhhdCB0aGUgcmVxdWVzdCBmb3Igemgtd3V1IHdhcyBiYXNlZCBvbiB0aGUgZmlyc3QgcGVy c3BlY3RpdmUsCj4gYW5kIHRoYXQgd2FzIHRoZSBwZXJzcGVjdGl2ZSBJIGFzc3VtZWQuCj4KPgo+ Cj4gPiBMb29rIGF0IHRoZSBjb25jcmV0ZSBpbXBsaWNhdGlvbnMuIEl0IG1lYW5zIHRoYXQgd2hl bmV2ZXIgSm9lIGxvb2tzIGZvcgo+IGEgd2ViIHBhZ2UgaW4gSGFra2EgQ2hpbmVzZSwgaGUgd2ls bCB0eXBpY2FsbHkgZmFsbCBiYWNrIHRvIE1hbmRhcmluLgo+IFdoZW5ldmVyIFNhcmFoIGxvb2tz IGZvciBhIHBhZ2UgaW4gVHVuaXNpYW4gQXJhYmljLCBpdCB3aWxsIGZhbGwgYmFjayB0bwo+IHN0 YW5kYXJkIE1hbmRhcmluLgo+Cj4gV2UgbmVlZCB0byBiZSBhIGJpdCBtb3JlIGNhcmVmdWwgaGVy ZTogZXhhY3RseSAqaG93KiBkb2VzIEpvZSBnbyBhYm91dAo+IHJlcXVlc3RpbmcgSGFra2E/IElm IGhlIGFza3MgZm9yICJ6aCIgaG9waW5nIHRvIGdldCBjb250ZW50IGluIEhha2thLCB0aGVyZQo+ IGlzIGEgdmVyeSBoaWdoIHByb2JhYmlsaXR5IGhlIHdpbGwgZ2V0IHBhZ2VzIGluIE1hbmRhcmlu LiBCdXQgaWYgaGUgYXNrcyBmb3IKPiAiemgtaGFra2EiLCBoZSB3aWxsIG9ubHkgZ2V0IHBhZ2Vz IHRhZ2dlZCAiemgtaGFra2EiIGZyb20gc2VydmVycwo+IGltcGxlbWVudGluZyBIVFRQLzEuMSBs YW5ndWFnZS1yYW5nZSwgbm90ICJ6aCIgcGFnZXM6IHRoYXQgaXMgaG93Cj4gbGFuZ3VhZ2UtcmFu Z2Ugd29ya3MuCj4KPgo+ID5JZiB5b3UgYXJlIHNheWluZyBob3dldmVyLCB0aGF0IHpoIGlzIG5v dCBuZWNlc3NhcmlseSBNYW5kYXJpbiwgdGhhdAo+IEFyYWJpYyBpcyBub3QgbmVjZXNzYXJpbHkg U3RhbmRhcmQgQXJhYmljLCB0aGVuIHdlIGZhbGwgdGhyb3VnaCB0byBjYXNlIDIuCj4KPiAgICAx LiBUaGVyZSBpcyBub3QgYSBwcmVkb21pbmFudCBjaG9pY2UgaW4gdGhlIGluZHVzdHJ5LCBsZXQn cyBzYXkgZm9yCj4gICAgSG1vbmcuIEluIHRoaXMgY2FzZSwgdGhlIHNpdHVhdGlvbiBpcyBkaWZm ZXJlbnQuIEkgY291bGQgY2hvb3NlIGFueSBvZiB0aGUKPiAgICBIbW9uZyBmb3IgdGhlIGNvbnRl bnQgZm9yIGhtbi4gV2UgdGhlbiBoYXZlIGFuIGV2ZW4gZGljZXIgY2FzZSBmb3IgdGhlIHZhbHVl Cj4gICAgb2YgZXh0bGFuZy4gSSBsb2NhbGl6ZSBteSBobW4gbG9jYWxlIHdpdGggY29udGVudHMg YXBwcm9wcmlhdGUgZm9yCj4gICAgTm9ydGhlYXN0ZXJuIERpYW4gSG1vbmc7IGlzIHRoYXQgYSBn b29kIGRlZmF1bHQgZm9yIHNvbWVvbmUgc3BlYWtpbmcgRWFzdGVybgo+ICAgIFhpYW5neGkgSG1v bmc/IGZvciBMdW9wb2hlIEhtb25nPyBGb3IgYWxsIHRoZSBvdGhlciBIbW9uZ3M/Cj4KPiA+IEZv ciBleHRsYW5nIHRvIGJlIGEgZ29vZCBhcHBhcmF0dXMsIHRoZXNlIGFsd2F5cyBoYXZlIHRvIGJl IGdvb2QKPiBjaG9pY2VzLCBzaW5jZSB3ZSBhcmUgYmFraW5nIHRoZSBzdHJ1Y3R1cmUgaW50byB0 aGUgdGFnLgo+Cj4gIEFnYWluLCBsZXQncyBiZSBtb3JlIGNhcmVmdWwgaW4gdGhlIGFuYWx5c2lz IGFuZCBhcmd1bWVudGF0aW9uLiBZb3UncmUKPiBxdWVzdGlvbmluZyB3aGV0aGVyIGEgcmVxdWVz dCBmb3IgaG1uIHNob3VsZCBiZSBhYmxlIHRvIHJldHVybiBjb250ZW50IGluCj4gYW55IEhtb25n IGxhbmd1YWdlLCBhbmQgc2F5aW5nIHRoYXQgImhtbi1obWQiIChORSBEaWFuKSBpcyBiYWQgYmVj YXVzZQo+IHNvbWVvbmUgYXNraW5nIGZvciBIbW9uZyBtaWdodCByZWFsbHkgYmUgYSBzcGVha2Vy IG9mIEx1b3BvaGUgSG1vbmcuIEl0Cj4gc2VlbXMgdG8gbWUgdGhpcyBpcyBhIGZhbGxhY2lvdXMg YXJndW1lbnQ6IGl0J3MgcHJlbWlzZSBpcyB0aGF0ICJobW4iIGNhbgo+IGFuZCBtdXN0IGJlIHN1 ZmZpY2llbnQgZm9yIGFueSBvZiB0aGVzZSB2YXJpb3VzIHNwZWFrZXJzLiBXZWxsLCBlaXRoZXIg aXQgaXMKPiBvciBpdCBpc24ndC4gSWYgaXQgaXMsIHRoZW4gdGhlIGFyZ3VtZW50IGZhaWxzLiBJ ZiBpdCBpc24ndCwgdGhlbiBhbGwgdGhhdAo+IHByb3ZlcyBpcyB0aGF0ICJobW4iIHJlYWxseSBp cyBuZXZlciBzdWZmaWNpZW50OiBhIG1vcmUgc3BlY2lmaWMKPiBsYW5ndWFnZS1yYW5nZSByZWFs bHkgaXMgbmVlZGVkLCBhbmQgYW55b25lIHJlcXVlc3RpbmcgdGhlaXIgcmVzb3VyY2VzIHVzaW5n Cj4gImhtbiIgaXMgbWFraW5nIGEgdmFndWUgcmVxdWVzdCB0aGF0IHdpbGwgYmUgc3ViamVjdCB0 byBzb21ld2hhdCBhcmJpdHJhcnkKPiByZXN1bHRzLiBBdCB0aGF0IHBvaW50IHlvdSBkZWNpZGUg YSBtb3JlIHNwZWNpZmljIGxhbmd1YWdlLXJhbmdlIGlzIG5lZWRlZCwKPiBpdCBtYWtlcyBubyBk aWZmZXJlbmNlIHdoZXRoZXIgdGhlIGxhbmd1YWdlIHJhbmdlIHVzZWQgaXMgImhtZCIgb3IKPiAi aG1uLWhtZCI6IGJvdGggd291bGQgc3VjY2VlZCBpbiBvYnRhaW5pbmcgdGhlIGRlc2lyZWQgcmVz dWx0Lgo+Cj4KPgo+IFNvLCB3ZSByZWFsbHkgY2FuJ3QgdXNlIHRoZSBtYWNyb2xhbmd1YWdlIGNh c2VzIGxpa2UgSG1vbmcgdG8gZGVjaWRlIHRoaXMKPiBvcGVuIGlzc3VlLiBJZiBORSBEaWFuIGlz IG5vdCBhIGdvb2QgY2hvaWNlIGZvciBMdW9wb2hlLCB0aGUgKipvbmx5KioKPiB0aGluZyB0aGF0 IHBvaW50cyB0byBpcyB0aGF0ICJobW4iIGlzIHRvbyB2YWd1ZSB0byBiZSB1c2VmdWwgZm9yIHJl cXVlc3RpbmcKPiByZXNvdXJjZXMuCj4KPgo+Cj4gQnR3LCBrZWVwIGluIG1pbmQgd2h5ICJobW4i IHdhcyBjcmVhdGVkIGluIHRoZSBmaXJzdCBwbGFjZSwgYW5kIHdoeSBpdCB3YXMKPiBjcmVhdGVk IGFzIGFuIGluZGl2aWR1YWwtbGFuZ3VhZ2UgaWRlbnRpZmllcjoKPgo+Cj4KPiAtICAgICAgICAg IGxpYnJhcmlhbnMgbmVlZGVkIGEgdGFnIGZvciBjb250ZW50Cj4KPgo+Cj4gLSAgICAgICAgICB0 aGV5IHdlcmUgbm90IEhtb25nIHNwZWNpYWxpc3RzIGFuZCBoYWQgbm8gYWJpbGl0eSB0bwo+IGRp ZmZlcmVudGlhdGUgYmV0d2VlbiB2YXJpZXRpZXMKPgo+Cj4KPiAtICAgICAgICAgIGFzIHRoZXNl IGFyZSBub3QtaGlnaGx5LWRldmVsb3BlZCB2YXJpZXRpZXMgKGluIHRoZQo+IGxhbmd1YWdlLWRl dmVsb3BtZW50IHNlbnNlIOKAkyBsaXRlcmF0dXJlLCBtZWRpYSwgc3RhbmRhcmRpemF0aW9uKSwg dGhlcmUgd2FzCj4gbm8gcmVhc29uIGZvciB0aGVzZSBub24tc3BlY2lhbGlzdHMgdG8gc3VwcG9z ZSB0aGF0IHRoZXNlIHZhcmlldGllcyB3ZXJlCj4gYW55dGhpbmcgbW9yZSB0aGFuIGRpYWxlY3Rz IG9mIGEgc2luZ2xlIGxhbmd1YWdlIChhc3N1bWluZyB0aGV5IGhhZCBtdWNoCj4gYXdhcmVuZXNz IG9mIGFueSB2YXJpYXRpb25zIGluIHRoZSBmaXJzdCBwbGFjZSkKPgo+Cj4KPiBOb3csIGFzIEkg YXBwcm9hY2hlZCBob3cgdG8gZGVhbCB3aXRoICJobW4iIGluIElTTyA2MzktMiB3aGVuIGl0IGNh bWUgdG8KPiBjcmVhdGluZyBJU08gNjM5LTMsIEkgaGFkIHR3byBvcHRpb25zOiBhcmd1ZSB0aGF0 ICJobW4iIHNob3VsZCByZWFsbHkgYmUgYQo+IGNvbGxlY3Rpb24sIG9yIHRyZWF0ICJobW4iIGFz IGEgbWFjcm9sYW5ndWFnZS4gSW4gdGhlIG9yaWdpbmFsIGFuYWx5c2lzLCAoCj4gaHR0cDovL3d3 dy5ldGhub2xvZ3VlLmNvbS8xNC9pc282MzkvYW5hbHlzaXMuYXNwKSwgSSBoYWQgY29uY2x1ZGVk ICJobW4iCj4gaXMgcmVhbGx5IGEgY29sbGVjdGlvbi4gQnV0IHNpbmNlIEkgYWxzbyBhbSBub3Qg YSBIbW9uZyBzcGVjaWFsaXN0IGFuZAo+IGRpZG4ndCBoYXZlIHRoZSBjYXBhY2l0eSAoZmFyIGZy b20gaXQhKSBvZiBnZXR0aW5nIGFuIGV4cGVydCBhbmFseXNpcyBvZgo+IHRoaXMgYW5kIGV2ZXJ5 IG90aGVyIHVuY2VydGFpbiBjYXNlIGluIElTTyA2MzkgaW4gYW55IHJlYXNvbmFibGUgYW1vdW50 IG9mCj4gdGltZSwgSSBjaG9zZSB0aGUgcGF0aCBvZiBsZWFzdCByZXNpc3RhbmNlOiB0cmVhdCBp dCBhcyBhIG1hY3JvbGFuZ3VhZ2UKPiBzaW5jZSBJU08gNjM5LTIgYW5kIGl0cyB1c2VyIGNvbW11 bml0eSBjb25zaWRlcnMgaXQgYW4gaW5kaXZpZHVhbCBsYW5ndWFnZSwKPiBhbmQgdGhhdCB3YXkg SSBkb24ndCBoYXZlIHRvIGdldCB0aGUgSkFDIHRvIHRha2UgYWN0aW9uIG9uIHlldCBvbmUgZGVj aXNpb24KPiB3aGVyZSB0aGUgaW1wYWN0IGlzIHVuY2xlYXIgYW5kIHRoZSBpbnRlcm5hbCBleHBl cnRpc2Ugb24gd2hpY2ggdG8gYmFzZSB0aGUKPiBkZWNpc2lvbiBpcyBtaW5pbWFsLgo+Cj4KPgo+ IEJ1dCBub3RlIHRoYXQgZm9yIG91ciBwdXJwb3NlcyBoZXJlIGl0IHJlYWxseSBkb2Vzbid0IG1h dHRlciB3aGV0aGVyICJobW4iCj4gZW5kZWQgdXAgYXMgYSBtYWNyb2xhbmd1YWdlIG9yIGFzIGEg Y29sbGVjdGlvbjogZWl0aGVyIHdheSwgaXQgaXMgc3RpbGwKPiB2YWd1ZSBhbmQgdGhlcmVmb3Jl IG5vdCBhIGdvb2QgdGFnIHRvIHVzZSBmb3IgcmVxdWVzdGluZyByZXNvdXJjZXMgaWYgdGhlCj4g ZGlzdGluY3Rpb25zIG1hdHRlciB0byB5b3UuCj4KPgo+Cj4KPgo+ID4gSWYgUGV0ZXIgQ29uc3Rh YmxlIGNhbWUgb3V0IGFuZCBzYWlkIHRoZSBmb2xsb3dpbmcsIHRoZW4gSSB3b3VsZCBhZG1pdAo+ IHRvIG15IHNpbnMsIGdpdmUgaW4gZ3JhY2VmdWxseSwgYW5kIGdvIGFsb25nIHdpdGggZXh0bGFu Zy4KPgo+ICAgIC0gIlllcywgZWFjaCBvZiB0aGUgSG1vbmdzIChlbmNvbXBhc3NlZCBieSBobW4p IGFyZSBtdXR1YWxseQo+ICAgIGludGVsbGlnaWJsZSwgYW5kIGFyZSBiZXR0ZXIgZm9yIGVhY2gg b25lIHRoYW4gYW5vdGhlciBmYWxsYmFjayBsaWtlCj4gICAgQ2hpbmVzZSIKPgo+Cj4gICAgIC0g YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIGFsbCB0aGUgb3RoZXIgY2FzZXMgd2l0aCBubyBwcmVk b21pbmFudAo+ICAgICAgIHZhcmlhbnQuCj4KPiBJIGhhdmVuJ3QgY29tZSBvdXQgc2F5aW5nIHRo YXQ7IEkgYXNzdW1lIHRoZXkgYXJlIG5vdC4gQnV0LCBJJ20gc2F5aW5nCj4gdGhhdCB0aGlzIGNh c2UgaXMgaXJyZWxldmFudCBmb3Igd2hhdCB3ZSBuZWVkIHRvIGRlY2lkZS4KPgo+ID4KPgo+ICAg IC0gIlllcywgc3RhbmRhcmQgQXJhYmljIGlzIGludGVsbGlnaWJsZSBmb3IgYWxsIHRoZSBlbmNv bXBhc3NlZAo+ICAgIGxhbmd1YWdlcyBmcm9tIEFsZ2VyaWFuIFNhaGFyYW4gQXJhYmljIHRvIFNo aWhoaSBBcmFiaWMsIGFuZCBhcmUgYmV0dGVyIGZvcgo+ICAgIGVhY2ggb25lIHRoYW4gYW5vdGhl ciBmYWxsYmFjayBsaWtlIEZyZW5jaCIKPgo+Cj4gICAgIC0gYW5kIHRoZSBzYW1lIGlzIHRydWUg Zm9yIGFsbCB0aGUgb3RoZXIgY2FzZXMgd2l0aCBhIHByZWRvbWluYW50Cj4gICAgICAgdmFyaWFu dC4KPgo+ICBXZWxsLCB3aGF0IHlvdSdyZSBhc2tpbmcgbWUgdG8gc2F5IGhlcmUgaXMgdGhhdCBh IHJlcXVlc3QgZm9yIGUuZy4KPiBBbGdlcmlhbiBTYWhhcmFuIEFyYWJpYyBjYW4gYXBwcm9wcmlh dGVseSBiZSBzZXJ2aWNlZCB3aXRoIFN0YW5kYXJkIEFyYWJpYwo+IHJlc291cmNlcyByYXRoZXIg dGhhbiwgc2F5LCBGcmVuY2guIEluIG90aGVyIHdvcmRzLCBhIGxhbmd1YWdlLXJhbmdlCj4gImFy LWFycSIgY2FuIGFwcHJvcHJpYXRlbHkgbWF0Y2ggImFyIiBjb250ZW50LiBCdXQgdGhhdCB3b3Vs ZCBuZXZlciBoYXBwZW4KPiBiZWNhdXNlIHRoYXQgaXMgbm90IGhvdyBsYW5ndWFnZS1yYW5nZSB3 b3Jrcy4gU28sIEknbSBub3Qgc3VyZSBob3cgdGhpcyBpcwo+IHJlbGV2YW50OiB3aGV0aGVyIHRo ZSBsYW5ndWFnZS1yYW5nZSBpcyAiYXItYXJxIiBvciAiYXJxIiB0aGUgb25seSByZXN1bHRzCj4g cmV0dXJuZWQgd2lsbCBiZSBBbGdlcmlhbiBTYWhhcmFuIEFyYWJpYywgdW5sZXNzIHNvbWUgbW9y ZSBhZHZhbmNlZCBmYWxsYmFjawo+IGJlaGF2aW91ciBpcyBpbnZva2VkLgo+Cj4KPgo+IFRoZSBx dWVzdGlvbiB0aGF0IHdvdWxkIGJlIHJlbGV2YW50IGluIHRlcm1zIG9mIGxhbmd1YWdlLXJhbmdl IGZvciB0aGUKPiBBcmFiaWMvTWFuZGFyaW4gY2FzZXMgaXMgdGhpczogaWYgc29tZW9uZSByZXF1 ZXN0cyAiYXIiLCBob3cgYmFkIGlzIGl0IGlmCj4gdGhleSBnZXQgcGFnZXMgaW4gImFyLWFycSI/ IElmIHNvbWVvbmUgcmVxdWVzdHMgInpoIiwgaG93IGJhZCBpcyBpdCBpZiB0aGV5Cj4gZ2V0IHBh Z2VzIGluICJ6aC1oYWtrYSI/IFRoZXNlIGFyZSB0aGUgY2FzZXMgdGhhdCByZWxhdGUgdG8gdGhl IHdheQo+IGxhbmd1YWdlLXJhbmdlIHdvcmtzLgo+Cj4KPgo+Cj4KPiBQZXRlcgo+Cj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcg bGlzdAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sdHJ1Cj4KPgoKCi0tIApNYXJrCg== ------=_Part_6809_22761074.1188491966852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmtzIFBldGVyOyBiYWNrZ3JvdW5kIG1hdGVyaWFsIGxpa2UgdGhpcyBhbmQgc3BlY2lmaWMg c2NlbmFyaW9zIHJlYWxseSBoZWxwIHRvIG1ha2UgY2xlYXIgd2hhdCB0aGUgcmVxdWlyZW1lbnRz IGFyZSwgYmVjYXVzZSB0aGV5IGFyZSB2ZXJ5IGRpZmZlcmVudCBkZXBlbmRpbmcgb24gdGhlIGtp bmRzIG9mIHVzYWdlIHBhdHRlcm5zIHBlb3BsZSBoYXZlIGluIG1pbmQuIFdoaWxlIEkgbWF5IGRp c2FncmVlIHdpdGggc29tZSBvZiB5b3VyIHBvaW50cywgdGhpcyBkaXNjdXNzaW9uIGlzIGdvaW5n IGluIGEgZ29vZCBkaXJlY3Rpb24uCjxicj48YnI+SXQgaXMga2V5IHRvIGlkZW50aWZ5IGV4YWN0 bHkgaG93IGV4dGxhbmcgd291bGQgd29yayBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucy4gV2UgdGhv dWdodCBsb25nIGFuZCBoYXJkIGFib3V0IHRoZSBpbnRyb2R1Y3Rpb24gb2Ygc2NyaXB0cywgYW5k IGxvb2tlZCBhdCBtYW55IGRpZmZlcmVudCBhc3BlY3RzIC0tIHdlIG5lZWQgdG8gZG8gdGhlIHNh bWUgd2l0aCB0aGUgZXh0bGFuZyBwcm9wb3NhbC4KPGJyPjxicj5JdCBhcHBlYXJzIHRoYXQgdGhl cmUgYXJlIHR3byBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBraW5kcyBvZiB1c2FnZSB0aGF0IHdl IG5lZWQgdG8gZXhhbWluZTo8YnI+PGJyPjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+UmVzb3VyY2UgTG9va3VwOiA8L3NwYW4+ dXNlciByZXF1ZXN0cyBsYW5ndWFnZSBYOyBzdXBwbGllciBkb2VzbiYjMzk7dCBoYXZlIGV4YWN0 bHkgWCBidXQgd2FudHMgdG8gZ2V0IHRoZSBiZXN0IG1hdGNoIChpbiB0aGUgc2Vuc2Ugb2YgbW9z dCBsaWtlbHkgdG8gYmUgdW5kZXJzdG9vZCBieSB0aGUgdXNlcikuIFRoZSBleHRsYW5nIHByb3Bv bmVudHMgYXBwZWFyZWQgdG8gYmUgYXJndWluZyB0aGF0IGl0IHdhcyBiZXR0ZXIgZm9yIHRoaXMg Y2FzZSwgYnV0IGl0IGp1c3QgZG9lc24mIzM5O3Qgc2VlbSB0byB3b3JrIHdlbGwuCjxicj48YnI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+UXVlcnk6IDwvc3Bhbj51c2VyIHJlcXVl c3RzIGNvbnRlbnQgbWF0Y2hpbmcgWCwgaW4gc29tZSAmcXVvdDtsb29zZSZxdW90OyBmYXNoaW9u LCBzdWNoIGFzIGEgbGlicmFyeSBsb29rdXAuIFVubGVzcyBJJiMzOTttIG1pc3JlYWRpbmcgUGV0 ZXIsIGl0IGFwcGVhcnMgdGhhdCB0aGlzIHdhcyBhY3R1YWxseSB0aGUgcHJpbWFyeSB0YXJnZXQg b2YgdGhlIGV4dGxhbmcgbWVjaGFuaXNtLiBTbyB0aGlzIGJlYXJzIHNvbWUgc2lnbmlmaWNhbnQg YXR0ZW50aW9uLCB0byBzZWUgaG93IHRoZSBleHRsYW5nIG1lY2hhbmlzbSB3b3VsZCB3b3JrIGlu IHRoaXMgY2FzZS4KPGJyPjwvZGl2Pjxicj5PbmNlIHdlIGdldCBhIHNlbnNlIG9mIHRoZSByZWxh dGl2ZSBiZW5lZml0cy9kcmF3YmFja3Mgb2YgZXh0bGFuZyBmb3IgZWFjaCBvZiB0aGVzZSAtLSBh bmQgd2VpZ2h0IHRoZSByZWxhdGl2ZSBpbXBvcnRhbmNlIG9mIHRoZXNlIHdpdGggcmVzcGVjdCB0 byBsYW5ndWFnZSB0YWcgdXNhZ2UsIHRoZW4gd2UmIzM5O2QgYmUgaW4gYmV0dGVyIHNoYXBlIHRv IGtub3cgdGhlIG92ZXJhbGwgcHJvcyBhbmQgY29ucyBvZiBhZGRpbmcgaXQuCjxicj48YnI+TWFy azxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDgvMzAvMDcsIDxiIGNs YXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBocmVmPSJt YWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCgoKCgoKCgoKPGRpdiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPGRpdiBzdHlsZT0iYm9yZGVy LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp IC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcjsgYm9yZGVyLXdpZHRoOiAx cHQgbWVkaXVtIG1lZGl1bTsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4KCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7Ij5IZXJlCmFyZSBteSByZXNwb25zZXMgdG8gdGhpcyBtYWlsIGZy b20gTWFyay4gSSBjcml0aXF1ZSBoaXMgYXJndW1lbnRhdGlvbiwgYnV0IGJlCmNhcmVmdWwgbm90 IHRvIGp1bXAgdG8gY29uY2x1c2lvbnMgYWJvdXQgd2hhdCBJJ20gc2F5aW5nIHJlZ2FyZGluZyB0 aGUgb3Blbgppc3N1ZTogd2hhdCBJIHNheSBoZXJlIGNyaXRpcXVlcyBNYXJrcyBhcmd1bWVudHMg YWdhaW5zdCBleHRsYW5nLCBidXQgZG9lcyBub3QgYXR0ZW1wdAp0byBtYWtlIGEgc3VmZmljaWVu dCBjYXNlIGZvciBleHRsYW5nLjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9iPjwvcD4KCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsi PiBNYXJrIERhdmlzClttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2pl Y3Qub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiPm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPC9hPl0gPHNw YW4gY2xhc3M9InEiPjxicj4KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAwNyA2 OjEyIFBNPGJyPgo8YnI+CjxiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi Pjwvc3Bhbj48L2I+PC9zcGFuPjwvc3Bhbj48L3A+PHNwYW4gY2xhc3M9InEiPgoKPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8L3NwYW4+SWYgYSBsYW5ndWFn ZSB5eXkKaGFzIHRoZSBtYWNyb2xhbmd1YWdlIHh4LCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28g cG9zc2libGUgcmVwcmVzZW50YXRpb25zIDwvcD4KCjwvc3Bhbj48L2Rpdj4KCjxkaXY+Cgo8ZGl2 PjxzcGFuIGNsYXNzPSJxIj4KCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiAzMHB0OyI+Cgo8cD5h KSBleHRsYW5nOiB4eC15eXk8YnI+CmIpIGxhbmc6IHl5eTwvcD4KCjwvZGl2PgoKPHAgc3R5bGU9 Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48YnI+CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPiZndDs8L3NwYW4+VGhlIG1haW4gcmVhc29uIEkmIzM5O3ZlIGhlYXJkIGZyb20g eW91IGZvcgpkb2luZyAoYSkgaW5zdGVhZCBvZiAoYikgaXMgdGhhdCAoYSkgaXQgaGFzIGJldHRl ciBmYWxsYmFjayBiZWhhdmlvci4gRm9yIHRoYXQKdG8gYmUgdHJ1ZSwgeHggaGFzIHRvIGJlIGEg Z29vZCBmYWxsYmFjayBmb3IgdXNlcnMgb2YgeXl5LCBpbiB0aGUgbWFqb3JpdHkgb2YKY2FzZXMu IDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjwvc3Bhbj48L3A+PC9zcGFu PgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkkgdGhpbmsgImZhbGxiYWNrIGJlaGF2 aW9yIgpuZWVkcyBtb3JlIGNhcmVmdWwgY29uc2lkZXJhdGlvbiBoZXJlLiBJdCBhcHBlYXJzIHRo YXQgTWFyayBpcyBmb2N1c2luZyBvbiBhCnBhcnRpY3VsYXIgc2NlbmFyaW86IHJlcXVlc3QgaXMg Zm9yIHJlc291cmNlIGluIGxhbmcgQSwgYnV0IHRoYXQgaXMgbm90CmF2YWlsYWJsZSBzbyBwcm9j ZXNzIG5lZWRzIHRvIGZhbGxiYWNrIHRvIGEgbGlrZWx5LW5leHQtYmVzdCBjaG9pY2UgYXZhaWxh YmxlLjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+V2hlbiBJIGZp cnN0IHByb3Bvc2VkIHRoZQpleHRsYW5nIG1lY2hhbmlzbSwgdGhhdCB3YXMgbm90IHRoZSBpbnRl bnQuIFJhdGhlciwgdGhlIGludGVudCB3YXMgZm9jdXNlZCBvbgphbm90aGVyIHNjZW5hcmlvOiBh dXRob3Igd2FudHMgdG8gdGFnIGNvbnRlbnQgdXNpbmcgbW9yZSBzcGVjaWZpYyBJRCB5eXksIGJ1 dCBtYW55CnJlcXVlc3RzLCBlc3BlY2lhbGx5IGZyb20gbGVnYWN5IGltcGxlbWVudGF0aW9ucywg d2lsbCB1c2UgeHgsIHdoaWNoIGhhcyBiZWVuCmluIHVzZSBmb3Igc29tZSB0aW1lLiBUaGlzIHNj ZW5hcmlvIHBlcnRhaW5zIHRvIExhbmd1YWdlLXJhbmdlIGFzIGRlZmluZWQgc2luY2UKSFRUUC8x LjEuPC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGFuZ3VhZ2UtcmFuZ2UKPSB4eDwvc3Bhbj48L3A+Cgo8 cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvbnRlbnQgdG8gYmUKbWF0Y2hlZCA9IHl5eSBvciB4eC15eXk8L3NwYW4+PC9wPgoK PHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPklmIHRoZSBjb250ZW50IGlzIHRhZ2dlZAp4 eC15eXksIHRoZXJlIGlzIGEgbWF0Y2guIEJ1dCBpZiB0aGUgY29udGVudCBpcyB0YWdnZWQgeXl5 LCB0aGVyZSBpcyBubyBtYXRjaCB1c2luZwphIGJhc2ljIGFsZ29yaXRobSDigJMgb25lIHdvdWxk IG5lZWQgYSBtb3JlIGFkdmFuY2VkIGFsZ29yaXRobSB0aGF0IGtub3dzIGFib3V0CnRoZSByZWxh dGlvbnNoaXAgYmV0d2VlbiB4eCBhbmQgeXl5Ljwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2lu LWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+SSB0aGluayBNYXJrJ3MgaXMgdGhlCnJlY2lwcm9jYWwgc2NlbmFyaW86 IHVzZXJzIHByZWZlcnMgdGhlIHNwZWNpZmljIHZhcmlldHkgeXl5LCBidXQgbW9zdCBjb250ZW50 CmlzIGFscmVhZHkgdGFnZ2VkIHVzaW5nIHh4LCB3aGljaCBoYXMgYmVlbiBpbiB1c2UgZm9yIHNv bWUgdGltZS4gVGhpcyBpcyBhCnBhcnRpY3VsYXIgY2FzZSBpbiB0aGUgZ2VuZXJhbCBzZXQgb2Yg ZmFsbGJhY2sgc2NlbmFyaW9zLCBhbmQgaXQgc2VlbXMgdG8gYmUKZXhhY3RseSB0aGUgb25lIE1h cmsgaXMgZm9jdXNpbmcgb24uIEJ1dCBub3RlIHRoYXQgbGFuZ3VhZ2UtcmFuZ2UgZG9lcyBub3QK YXBwbHkgaGVyZSDigJMgb3IsIGZyb20gYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUsIGRvZXNuJ3Qg d29yayBoZXJlOiA8L3NwYW4+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7IHRl eHQtaW5kZW50OiAwLjVpbjsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+bGFuZ3VhZ2UtcmFuZ2UKPSB5eXkgb3IgeHgteXl5PC9zcGFuPjwv cD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyB0ZXh0LWluZGVudDogMC41aW47Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmNv bnRlbnQKdG8gYmUgbWF0Y2hlZCA9IHh4PC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90 dG9tOiAxMnB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5XaGljaGV2ZXIgd2F5IHRoZQpsYW5ndWFnZS1yYW5nZSBpcyBleHByZXNzZWQs IHRoZXJlIGlzIG5vIG1hdGNoIHdpdGggYSBiYXNpYyBhbGdvcml0aG0g4oCTIG9uZSB3b3VsZApu ZWVkIGEgbW9yZSBhZHZhbmNlZCBhbGdvcml0aG0gdGhhdCBrbm93cyBhYm91dCB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4geHggYW5kCnl5eS48L3NwYW4+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1i b3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPlNvLCBjb25zaWRlcmluZyBqdXN0IHRob3NlCnNjZW5hcmlvcywgeHgteXl5 IGhhcyBhbiBhZHZhbnRhZ2Ugb3ZlciB5eXkgaW4gdGhhdCBpdCBwcm92aWRlcyBhbiBhZHZhbnRh Z2UKZm9yIHRoZSBvbmUgc2NlbmFyaW8gd2hpbGUgdGhlIHR3byBhbHRlcm5hdGl2ZXMgYXJlIGVx dWFsIHdydCB0aGUgb3RoZXIuIE9mCmNvdXJzZSwgdGhvc2UgYXJlbid0IHRoZSBvbmx5IHNjZW5h cmlvcy4gV2UgbmVlZCB0byBjb25zaWRlciBhIGJyb2FkZXIgc2V0IG9mCnNjZW5hcmlvcywgYW5k IGFsc28gY29uc2lkZXIgaG93IHRoZXkgcmFuayBpbiBwcmlvcml0eS48L3NwYW4+PC9wPjxzcGFu IGNsYXNzPSJxIj4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+ PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48YnI+CjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZndDsgPC9zcGFuPlRoZXJlIGFyZSAoYXQgbGVhc3Qp IHR3byBjYXNlcyB0bwpjb25zaWRlciBoZXJlLjwvcD4KCjwvc3Bhbj48b2wgc3RhcnQ9IjEiIHR5 cGU9IjEiPjxzcGFuIGNsYXNzPSJxIj4KIDxsaT5UaGVyZSBpcyBhIHByZWRvbWluZW50IGNob2lj ZSBpbiB0aGUgaW5kdXN0cnkgZm9yCiAgICAgdGhlIG1hY3JvIGxhbmd1YWdlLiBGb3IgZXhhbXBs ZSwgdGhlIGNvbnRlbnQgZm9yIHpoIGlzIHR5cGljYWxseSBhbHdheXMKICAgICBNYW5kYXJpbjsg dGhlIGNvbnRlbnQgZm9yIGFyIGlzIHR5cGljYWxseSBhbHdheXMgc3RhbmRhcmQgQXJhYmljLiA8 L2xpPjwvc3Bhbj4KPC9vbD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+VHlwaWNhbGx5LAp5ZXMuIFdlIGp1c3QgbXVzdCBub3QgYXNz dW1lIHRoYXQgaXMgYWx3YXlzIHRoZSBjYXNlLiBUaGUgdmVyeSB0aGluZyB0aGF0CnN0YXJ0ZWQg bWUgdGhpbmtpbmcgYWJvdXQgdGhlIG1hY3JvbGFuZ3VhZ2UgY29uY2VwdCBpbiB0aGUgZmlyc3Qg cGxhY2UsIHJhdGhlcgp0aGFuIGVxdWF0aW5nIGV4aXN0aW5nIElTTyA2MzkgSURzIGxpa2Ugemgg YW5kIGFyIHdpdGggdGhlIHByZWRvbWluYW50IHZhcmlldHksCndhcyB0aGUgZmFjdCB0aGF0IHRo ZXJlIHdlcmUgbGFuZ3VhZ2UgdGFncyByZWdpc3RlcmVkIHdpdGggSUFOQSBleHBsaWNpdGx5CmFz c29jaWF0aW5nIHpoIHdpdGggQ2hpbmVzZSBsYW5ndWFnZXMgb3RoZXIgdGhhbiBNYW5kYXJpbi4g V2hlbiBmYWNlZCB3aXRoIHByZS1leGlzdGluZwp1c2FnZSAiemgtd3V1Iiwgd2UgaGF2ZSB0d28g Y2hvaWNlczo8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5hKQp3dXUgaXMgYSBzcGVjaWZpYyB2YXJpZXR5IG9mIHpo PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+YikKd3V1IHJlbGF0ZXMgdG8gemggaW4gc29tZSBvdGhlciB3YXksIHN1 Y2ggYXMgemggYmVpbmcgYSBnb29kIGZhbGxiYWNrIGNob2ljZTwvc3Bhbj48L3A+Cgo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkkKc3Vz cGVjdCB0aGF0IHRoZSByZXF1ZXN0IGZvciB6aC13dXUgd2FzIGJhc2VkIG9uIHRoZSBmaXJzdCBw ZXJzcGVjdGl2ZSwgYW5kCnRoYXQgd2FzIHRoZSBwZXJzcGVjdGl2ZSBJIGFzc3VtZWQuPC9zcGFu PjwvcD48c3BhbiBjbGFzcz0icSI+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij4mZ3Q7IDwvc3Bhbj5Mb29rIGF0IHRoZSBjb25jcmV0ZQppbXBsaWNhdGlvbnMu IEl0IG1lYW5zIHRoYXQgd2hlbmV2ZXIgSm9lIGxvb2tzIGZvciBhIHdlYiBwYWdlIGluIEhha2th IENoaW5lc2UsCmhlIHdpbGwgdHlwaWNhbGx5IGZhbGwgYmFjayB0byBNYW5kYXJpbi4gV2hlbmV2 ZXIgU2FyYWggbG9va3MgZm9yIGEgcGFnZSBpbgpUdW5pc2lhbiBBcmFiaWMsIGl0IHdpbGwgZmFs bCBiYWNrIHRvIHN0YW5kYXJkIE1hbmRhcmluLiA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij48L3NwYW4+PC9wPjwvc3Bhbj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+V2UKbmVlZCB0byBiZSBhIGJpdCBtb3Jl IGNhcmVmdWwgaGVyZTogZXhhY3RseSA8aT5ob3c8L2k+IGRvZXMgSm9lIGdvIGFib3V0CnJlcXVl c3RpbmcgSGFra2E/IElmIGhlIGFza3MgZm9yICJ6aCIgaG9waW5nIHRvIGdldCBjb250ZW50IGlu IEhha2thLCB0aGVyZSBpcwphIHZlcnkgaGlnaCBwcm9iYWJpbGl0eSBoZSB3aWxsIGdldCBwYWdl cyBpbiBNYW5kYXJpbi4gQnV0IGlmIGhlIGFza3MgZm9yICJ6aC1oYWtrYSIsCmhlIHdpbGwgb25s eSBnZXQgcGFnZXMgdGFnZ2VkICJ6aC1oYWtrYSIgZnJvbSBzZXJ2ZXJzIGltcGxlbWVudGluZyBI VFRQLzEuMQpsYW5ndWFnZS1yYW5nZSwgbm90ICJ6aCIgcGFnZXM6IHRoYXQgaXMgaG93IGxhbmd1 YWdlLXJhbmdlIHdvcmtzLjwvc3Bhbj48L3A+PHNwYW4gY2xhc3M9InEiPgoKPHAgc3R5bGU9Im1h cmdpbi1sZWZ0OiAwLjVpbjsiPjxicj4KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+Jmd0Ozwvc3Bhbj5JZiB5b3UgYXJlIHNheWluZyBob3dldmVyLCB0aGF0IHpoIGlzCm5v dCBuZWNlc3NhcmlseSBNYW5kYXJpbiwgdGhhdCBBcmFiaWMgaXMgbm90IG5lY2Vzc2FyaWx5IFN0 YW5kYXJkIEFyYWJpYywgdGhlbgp3ZSBmYWxsIHRocm91Z2ggdG8gY2FzZSAyLiZuYnNwOzwvcD4K CjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+CiA8bGk+VGhlcmUgaXMgbm90IGEgcHJlZG9taW5hbnQg Y2hvaWNlIGluIHRoZSBpbmR1c3RyeSwKICAgICBsZXQmIzM5O3Mgc2F5IGZvciBIbW9uZy4gSW4g dGhpcyBjYXNlLCB0aGUgc2l0dWF0aW9uIGlzIGRpZmZlcmVudC4gSSBjb3VsZAogICAgIGNob29z ZSBhbnkgb2YgdGhlIEhtb25nIGZvciB0aGUgY29udGVudCBmb3IgaG1uLiBXZSB0aGVuIGhhdmUg YW4gZXZlbgogICAgIGRpY2VyIGNhc2UgZm9yIHRoZSB2YWx1ZSBvZiBleHRsYW5nLiBJIGxvY2Fs aXplIG15IGhtbiBsb2NhbGUgd2l0aAogICAgIGNvbnRlbnRzIGFwcHJvcHJpYXRlIGZvciBOb3J0 aGVhc3Rlcm4gRGlhbiBIbW9uZzsgaXMgdGhhdCBhIGdvb2QgZGVmYXVsdAogICAgIGZvciBzb21l b25lIHNwZWFraW5nIEVhc3Rlcm4gWGlhbmd4aSBIbW9uZz8gZm9yIEx1b3BvaGUgSG1vbmc/IEZv ciBhbGwgdGhlCiAgICAgb3RoZXIgSG1vbmdzPyA8L2xpPgo8L29sPgoKPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8L3NwYW4+Rm9yIGV4dGxhbmcgdG8gYmUg YQpnb29kIGFwcGFyYXR1cywgdGhlc2UgYWx3YXlzIGhhdmUgdG8gYmUgZ29vZCBjaG9pY2VzLCBz aW5jZSB3ZSBhcmUgYmFraW5nIHRoZQpzdHJ1Y3R1cmUgaW50byB0aGUgdGFnLjxicj4KPGJyPgo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48L3NwYW4+PC9wPjwvc3Bhbj4K CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+QWdhaW4sIGxldCdzIGJlIG1vcmUgY2FyZWZ1bCBpbiB0aGUgYW5hbHlzaXMgYW5kIGFyZ3Vt ZW50YXRpb24uCllvdSdyZSBxdWVzdGlvbmluZyB3aGV0aGVyIGEgcmVxdWVzdCBmb3IgaG1uIHNo b3VsZCBiZSBhYmxlIHRvIHJldHVybiBjb250ZW50CmluIGFueSBIbW9uZyBsYW5ndWFnZSwgYW5k IHNheWluZyB0aGF0ICJobW4taG1kIiAoTkUgRGlhbikgaXMgYmFkIGJlY2F1c2Ugc29tZW9uZQph c2tpbmcgZm9yIEhtb25nIG1pZ2h0IHJlYWxseSBiZSBhIHNwZWFrZXIgb2YgTHVvcG9oZSBIbW9u Zy4gSXQgc2VlbXMgdG8gbWUKdGhpcyBpcyBhIGZhbGxhY2lvdXMgYXJndW1lbnQ6IGl0J3MgcHJl bWlzZSBpcyB0aGF0ICJobW4iIGNhbiBhbmQgbXVzdCBiZQpzdWZmaWNpZW50IGZvciBhbnkgb2Yg dGhlc2UgdmFyaW91cyBzcGVha2Vycy4gV2VsbCwgZWl0aGVyIGl0IGlzIG9yIGl0IGlzbid0LgpJ ZiBpdCBpcywgdGhlbiB0aGUgYXJndW1lbnQgZmFpbHMuIElmIGl0IGlzbid0LCB0aGVuIGFsbCB0 aGF0IHByb3ZlcyBpcyB0aGF0ICJobW4iCnJlYWxseSBpcyBuZXZlciBzdWZmaWNpZW50OiBhIG1v cmUgc3BlY2lmaWMgbGFuZ3VhZ2UtcmFuZ2UgcmVhbGx5IGlzIG5lZWRlZCwKYW5kIGFueW9uZSBy ZXF1ZXN0aW5nIHRoZWlyIHJlc291cmNlcyB1c2luZyAiaG1uIiBpcyBtYWtpbmcgYSB2YWd1ZSBy ZXF1ZXN0CnRoYXQgd2lsbCBiZSBzdWJqZWN0IHRvIHNvbWV3aGF0IGFyYml0cmFyeSByZXN1bHRz LiBBdCB0aGF0IHBvaW50IHlvdSBkZWNpZGUgYQptb3JlIHNwZWNpZmljIGxhbmd1YWdlLXJhbmdl IGlzIG5lZWRlZCwgaXQgbWFrZXMgbm8gZGlmZmVyZW5jZSB3aGV0aGVyIHRoZQpsYW5ndWFnZSBy YW5nZSB1c2VkIGlzICJobWQiIG9yICJobW4taG1kIjogYm90aCB3b3VsZCBzdWNjZWVkIGluIG9i dGFpbmluZyB0aGUKZGVzaXJlZCByZXN1bHQuPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwv cD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+U28sIHdlIHJlYWxseSBjYW4ndCB1c2UgdGhlIG1hY3JvbGFuZ3VhZ2UgY2FzZXMgbGlr ZSBIbW9uZyB0bwpkZWNpZGUgdGhpcyBvcGVuIGlzc3VlLiBJZiBORSBEaWFuIGlzIG5vdCBhIGdv b2QgY2hvaWNlIGZvciBMdW9wb2hlLCB0aGUgKjxiPm9ubHk8L2I+Kgp0aGluZyB0aGF0IHBvaW50 cyB0byBpcyB0aGF0ICJobW4iIGlzIHRvbyB2YWd1ZSB0byBiZSB1c2VmdWwgZm9yIHJlcXVlc3Rp bmcKcmVzb3VyY2VzLjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkJ0dywga2Vl cCBpbiBtaW5kIHdoeSAiaG1uIiB3YXMgY3JlYXRlZCBpbiB0aGUgZmlyc3QgcGxhY2UsIGFuZAp3 aHkgaXQgd2FzIGNyZWF0ZWQgYXMgYW4gaW5kaXZpZHVhbC1sYW5ndWFnZSBpZGVudGlmaWVyOiA8 L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHAgc3R5bGU9InRleHQtaW5kZW50OiAt MC4yNWluOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij48c3Bhbj4tPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+bGlicmFyaWFucyBuZWVkZWQg YSB0YWcgZm9yIGNvbnRlbnQ8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHAgc3R5 bGU9InRleHQtaW5kZW50OiAtMC4yNWluOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48c3Bhbj4tPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ dGhleSB3ZXJlIG5vdCBIbW9uZyBzcGVjaWFsaXN0cyBhbmQgaGFkIG5vIGFiaWxpdHkgdG8KZGlm ZmVyZW50aWF0ZSBiZXR3ZWVuIHZhcmlldGllczwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48 L3A+Cgo8cCBzdHlsZT0idGV4dC1pbmRlbnQ6IC0wLjI1aW47Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxzcGFuPi08c3Bhbj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5hcyB0aGVzZSBhcmUgbm90LWhpZ2hseS1kZXZlbG9wZWQgdmFyaWV0aWVzIChp biB0aGUKbGFuZ3VhZ2UtZGV2ZWxvcG1lbnQgc2Vuc2Ug4oCTIGxpdGVyYXR1cmUsIG1lZGlhLCBz dGFuZGFyZGl6YXRpb24pLCB0aGVyZSB3YXMgbm8KcmVhc29uIGZvciB0aGVzZSBub24tc3BlY2lh bGlzdHMgdG8gc3VwcG9zZSB0aGF0IHRoZXNlIHZhcmlldGllcyB3ZXJlIGFueXRoaW5nCm1vcmUg dGhhbiBkaWFsZWN0cyBvZiBhIHNpbmdsZSBsYW5ndWFnZSAoYXNzdW1pbmcgdGhleSBoYWQgbXVj aCBhd2FyZW5lc3Mgb2YKYW55IHZhcmlhdGlvbnMgaW4gdGhlIGZpcnN0IHBsYWNlKTwvc3Bhbj48 L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk5vdywgYXMgSSBhcHByb2FjaGVkIGhvdyB0byBk ZWFsIHdpdGggImhtbiIgaW4gSVNPIDYzOS0yIHdoZW4gaXQKY2FtZSB0byBjcmVhdGluZyBJU08g NjM5LTMsIEkgaGFkIHR3byBvcHRpb25zOiBhcmd1ZSB0aGF0ICJobW4iIHNob3VsZCByZWFsbHkK YmUgYSBjb2xsZWN0aW9uLCBvciB0cmVhdCAiaG1uIiBhcyBhIG1hY3JvbGFuZ3VhZ2UuIEluIHRo ZSBvcmlnaW5hbCBhbmFseXNpcywgKDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20v MTQvaXNvNjM5L2FuYWx5c2lzLmFzcCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LmV0aG5vbG9n dWUuY29tLzE0L2lzbzYzOS9hbmFseXNpcy5hc3AKPC9hPiksCkkgaGFkIGNvbmNsdWRlZCAiaG1u IiBpcyByZWFsbHkgYSBjb2xsZWN0aW9uLiBCdXQgc2luY2UgSSBhbHNvIGFtIG5vdCBhIEhtb25n CnNwZWNpYWxpc3QgYW5kIGRpZG4ndCBoYXZlIHRoZSBjYXBhY2l0eSAoZmFyIGZyb20gaXQhKSBv ZiBnZXR0aW5nIGFuIGV4cGVydCBhbmFseXNpcwpvZiB0aGlzIGFuZCBldmVyeSBvdGhlciB1bmNl cnRhaW4gY2FzZSBpbiBJU08gNjM5IGluIGFueSByZWFzb25hYmxlIGFtb3VudCBvZgp0aW1lLCBJ IGNob3NlIHRoZSBwYXRoIG9mIGxlYXN0IHJlc2lzdGFuY2U6IHRyZWF0IGl0IGFzIGEgbWFjcm9s YW5ndWFnZSBzaW5jZQpJU08gNjM5LTIgYW5kIGl0cyB1c2VyIGNvbW11bml0eSBjb25zaWRlcnMg aXQgYW4gaW5kaXZpZHVhbCBsYW5ndWFnZSwgYW5kIHRoYXQKd2F5IEkgZG9uJ3QgaGF2ZSB0byBn ZXQgdGhlIEpBQyB0byB0YWtlIGFjdGlvbiBvbiB5ZXQgb25lIGRlY2lzaW9uIHdoZXJlIHRoZSBp bXBhY3QKaXMgdW5jbGVhciBhbmQgdGhlIGludGVybmFsIGV4cGVydGlzZSBvbiB3aGljaCB0byBi YXNlIHRoZSBkZWNpc2lvbiBpcyBtaW5pbWFsLgo8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+ PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5CdXQgbm90ZSB0aGF0IGZvciBvdXIgcHVycG9zZXMgaGVyZSBpdCByZWFsbHkgZG9l c24ndCBtYXR0ZXIKd2hldGhlciAiaG1uIiBlbmRlZCB1cCBhcyBhIG1hY3JvbGFuZ3VhZ2Ugb3Ig YXMgYSBjb2xsZWN0aW9uOiBlaXRoZXIgd2F5LCBpdCBpcwpzdGlsbCB2YWd1ZSBhbmQgdGhlcmVm b3JlIG5vdCBhIGdvb2QgdGFnIHRvIHVzZSBmb3IgcmVxdWVzdGluZyByZXNvdXJjZXMgaWYgdGhl CmRpc3RpbmN0aW9ucyBtYXR0ZXIgdG8geW91Ljwvc3Bhbj48L3A+PHNwYW4gY2xhc3M9InEiPgoK PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8L3NwYW4+SWYgUGV0ZXIgQ29uc3RhYmxl CmNhbWUgb3V0IGFuZCBzYWlkIHRoZSBmb2xsb3dpbmcsIHRoZW4gSSB3b3VsZCBhZG1pdCB0byBt eSBzaW5zLCBnaXZlIGluCmdyYWNlZnVsbHksIGFuZCBnbyBhbG9uZyB3aXRoIGV4dGxhbmcuIDwv cD4KCjx1bCB0eXBlPSJkaXNjIj4KIDxsaT4mcXVvdDtZZXMsIGVhY2ggb2YgdGhlIEhtb25ncyAo ZW5jb21wYXNzZWQgYnkKICAgICBobW4pIGFyZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFuZCBh cmUgYmV0dGVyIGZvciBlYWNoIG9uZSB0aGFuIGFub3RoZXIKICAgICBmYWxsYmFjayBsaWtlIENo aW5lc2UmcXVvdDs8L2xpPgo8L3VsPgoKPC9zcGFuPjx1bCB0eXBlPSJkaXNjIj4KIDx1bCB0eXBl PSJjaXJjbGUiPjxzcGFuIGNsYXNzPSJxIj4KICA8bGk+YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9y IGFsbCB0aGUgb3RoZXIKICAgICAgY2FzZXMgd2l0aCBubyBwcmVkb21pbmFudCB2YXJpYW50LiA8 L2xpPjwvc3Bhbj4KIDwvdWw+CjwvdWw+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkkKaGF2ZW4ndCBjb21lIG91dCBzYXlpbmcgdGhh dDsgSSBhc3N1bWUgdGhleSBhcmUgbm90LiBCdXQsIEknbSBzYXlpbmcgdGhhdCB0aGlzCmNhc2Ug aXMgaXJyZWxldmFudCBmb3Igd2hhdCB3ZSBuZWVkIHRvIGRlY2lkZS48L3NwYW4+PC9wPjxzcGFu IGNsYXNzPSJxIj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+Jmd0OyZuYnNwOzwvc3Bhbj48L3A+Cgo8dWwgdHlwZT0iZGlzYyI+CiA8 bGk+JnF1b3Q7WWVzLCBzdGFuZGFyZCBBcmFiaWMgaXMgaW50ZWxsaWdpYmxlIGZvcgogICAgIGFs bCB0aGUgZW5jb21wYXNzZWQgbGFuZ3VhZ2VzIGZyb20gQWxnZXJpYW4gU2FoYXJhbiBBcmFiaWMg dG8gU2hpaGhpCiAgICAgQXJhYmljLCBhbmQgYXJlIGJldHRlciBmb3IgZWFjaCBvbmUgdGhhbiBh bm90aGVyIGZhbGxiYWNrIGxpa2UKICAgICBGcmVuY2gmcXVvdDs8L2xpPgo8L3VsPgoKPC9zcGFu Pjx1bCB0eXBlPSJkaXNjIj4KIDx1bCB0eXBlPSJjaXJjbGUiPjxzcGFuIGNsYXNzPSJxIj4KICA8 bGk+YW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIGFsbCB0aGUgb3RoZXIKICAgICAgY2FzZXMgd2l0 aCBhIHByZWRvbWluYW50IHZhcmlhbnQuIDwvbGk+PC9zcGFuPgogPC91bD4KPC91bD4KCjwvZGl2 PgoKPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+V2VsbCwgd2hhdCB5 b3UncmUgYXNraW5nIG1lIHRvCnNheSBoZXJlIGlzIHRoYXQgYSByZXF1ZXN0IGZvciBlLmcuIEFs Z2VyaWFuIFNhaGFyYW4gQXJhYmljIGNhbiBhcHByb3ByaWF0ZWx5CmJlIHNlcnZpY2VkIHdpdGgg U3RhbmRhcmQgQXJhYmljIHJlc291cmNlcyByYXRoZXIgdGhhbiwgc2F5LCBGcmVuY2guIEluIG90 aGVyCndvcmRzLCBhIGxhbmd1YWdlLXJhbmdlICJhci1hcnEiIGNhbiBhcHByb3ByaWF0ZWx5IG1h dGNoICJhciIgY29udGVudC4gQnV0IHRoYXQKd291bGQgbmV2ZXIgaGFwcGVuIGJlY2F1c2UgdGhh dCBpcyBub3QgaG93IGxhbmd1YWdlLXJhbmdlIHdvcmtzLiBTbywgSSdtIG5vdApzdXJlIGhvdyB0 aGlzIGlzIHJlbGV2YW50OiB3aGV0aGVyIHRoZSBsYW5ndWFnZS1yYW5nZSBpcyAiYXItYXJxIiBv ciAiYXJxIiB0aGUKb25seSByZXN1bHRzIHJldHVybmVkIHdpbGwgYmUgQWxnZXJpYW4gU2FoYXJh biBBcmFiaWMsIHVubGVzcyBzb21lIG1vcmUKYWR2YW5jZWQgZmFsbGJhY2sgYmVoYXZpb3VyIGlz IGludm9rZWQuPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5UaGUgcXVlc3Rpb24gdGhhdCB3b3VsZCBiZQpyZWxldmFudCBpbiB0ZXJtcyBv ZiBsYW5ndWFnZS1yYW5nZSBmb3IgdGhlIEFyYWJpYy9NYW5kYXJpbiBjYXNlcyBpcyB0aGlzOiBp Zgpzb21lb25lIHJlcXVlc3RzICJhciIsIGhvdyBiYWQgaXMgaXQgaWYgdGhleSBnZXQgcGFnZXMg aW4gImFyLWFycSI/IElmIHNvbWVvbmUKcmVxdWVzdHMgInpoIiwgaG93IGJhZCBpcyBpdCBpZiB0 aGV5IGdldCBwYWdlcyBpbiAiemgtaGFra2EiPyBUaGVzZSBhcmUgdGhlCmNhc2VzIHRoYXQgcmVs YXRlIHRvIHRoZSB3YXkgbGFuZ3VhZ2UtcmFuZ2Ugd29ya3MuPC9zcGFuPjwvcD4KCjxwPjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoK PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+UGV0ZXI8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48L3Nw YW4+PC9wPgoKPC9kaXY+Cgo8L2Rpdj4KCjwvZGl2PgoKCjxicj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJl Zj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9 InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+ Cmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj48 L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_6809_22761074.1188491966852-- --===============2060856516== 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 --===============2060856516==-- From ltru-bounces@ietf.org Thu Aug 30 12:46: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 1IQnAE-0001hD-OV; Thu, 30 Aug 2007 12:46:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQnAC-0001YK-Me for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 12:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnAC-0001Ws-Cm for ltru@ietf.org; Thu, 30 Aug 2007 12:46:36 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQnAB-0001TI-0q for ltru@ietf.org; Thu, 30 Aug 2007 12:46:36 -0400 Received: by nz-out-0506.google.com with SMTP id n1so422320nzf for ; Thu, 30 Aug 2007 09:46:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=VbUIco7Et9DgvR36Qp42iIor2Ma0lSPZxvdcVjKGl6+J3x9ehU0B5p3PYHXv8zqAtyMQn25anVimNQH7tdWxsjEazxbkwoZnHM8s0hTT90eWH+/dui9ATmB/cRVApEOgHLYhFw28s6/ECGQoQ+fMu+QW+1/HKnnp8pLugTEoywM= 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=uoEFosh6qhA6//6kmWuz8yjFpnPS4t+dji2UaeeiGGZZxZ0n1cB6+vRbzVQ4+EHmbmlZLvSccYbBlMBWoTrX6lkWNvkskj4drgQe2uTqLYiylpg1aacyc2fN3c6ITXtxJntEm2Z1nz2konLlwk9uEcWfh1A/eBTbDZiFNa2f6sY= Received: by 10.114.184.7 with SMTP id h7mr25869waf.1188492393507; Thu, 30 Aug 2007 09:46:33 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Thu, 30 Aug 2007 09:46:33 -0700 (PDT) Message-ID: <30b660a20708300946t2295b031vba4b3d2af8f1165@mail.gmail.com> Date: Thu, 30 Aug 2007 09:46:33 -0700 From: "Mark Davis" To: "Marion Gunn" Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) In-Reply-To: MIME-Version: 1.0 References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> <30b660a20708300926v71aeb83eu33c8ccaa0d986a01@mail.gmail.com> X-Google-Sender-Auth: 5f380c07aeafb08a X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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="===============1174200385==" Errors-To: ltru-bounces@ietf.org --===============1174200385== Content-Type: multipart/alternative; boundary="----=_Part_6840_11942534.1188492393444" ------=_Part_6840_11942534.1188492393444 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gOC8zMC8wNywgTWFyaW9uIEd1bm4gPG1ndW5uQGVndC5pZT4gd3JvdGU6Cj4KPgo+IE9uIDMw IEF1ZyAyMDA3LCBhdCAxNjoyNiwgc2Nyw61vYmggTWFyayBEYXZpczoKPgo+IEkgZmluZCB0aGUg dHlwaWNhbCBUZXJtcyBhbmQgRGVmaW5pdGlvbnMgc2VjdGlvbnMgYXQgdGhlIHN0YXJ0IG9mIG1h bnkgSVNPCj4gZG9jdW1lbnRzIGFjdHVhbGx5IGNvdW50ZXItcHJvZHVjdGl2ZS4gVGhlIGl0ZW1z IGFyZSBwcmVzZW50ZWQgYmVmb3JlIHlvdQo+IGhhdmUgYW55IGJhY2tncm91bmQgZm9yIHdoYXQg dGhlIGRlZmluaXRpb25zIHJlYWxseSBtZWFuLCBhbmQgYXJlIGluIG5vCj4gY29oZXNpdmUgb3Jk ZXIuCj4KPgo+IEFscGhhYmV0aWNhbCBvcmRlciBpcyBjb2hlc2l2ZSBlbm91Z2ggZm9yIG1vc3Qg cHJvZmVzc2lvbmFsIHVzZXJzLiBBZGRlZAo+IHRvIHRoYXQsIGV2ZW4gZm9yIG5ld2JpZXMsIGl0 IGlzIHByZWRpY3RhYmxlLCBsb2dpY2FsLCBjb25zaXN0ZW50IHdpdGggSVNPCj4gZG9jdW1lbnRz IGluIGdlbmVyYWwsIHdpdGggd2hpY2ggb25lIHdvdWxkIGV4cGVjdCBtb3N0IHVzZXJzIG9mIHRo aXMgbGlzdCB0bwo+IGJlIGZhbWlsaWFyLgo+CgpJIGRpc2FncmVlLiBJJ3ZlIGhpdCBtYW55IGlu c3RhbmNlcyB3aGVyZSB0aGUgZGVmaW5pdGlvbiBvZiBhbiBJU08gdGVybQptYWtlcyBubyBzZW5z ZSB1bnRpbCB5b3UndmUgcmVhZCBlbm91Z2ggb2YgdGhlIHdheSB0aHJvdWdoIHRoZSBkb2N1bWVu dCB0bwp1bmRlcnN0YW5kIGl0LiBBbHBoYWJldGljYWwgaXMgZmluZSBmb3IgcmVmZXJlbmNlICph ZnRlciogeW91J3ZlIHJlYWQgdGhlCmRvY3VtZW50LCBidXQgaXQgaXMgYSBuaWNlIHRvIGhhdmUs IGFuZCBub3QgYSByZXF1aXJlbWVudC4KCldlIGFyZSBub3Qgd3JpdGluZyBhbiBJU08gZG9jdW1l bnQsIGFuZCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBmb2xsb3cKaXRzIGZvcm1hdC4KCkFz IHlvdSByZWFkIHRoZSBkb2N1bWVudCwgZWFjaCB0ZWNobmljYWwgdGVybSBzaG91bGQgYmUgZGVm aW5lZCBpbiB0aGUKPiBwYXJhZ3JhcGggd2hlcmUgaXQgaXMgZmlyc3QgdXNlZC4gSWYgdGhhdCBp cyBub3QgdGhlIGNhc2UsIHRoZW4gcGxlYXNlIG1ha2UKPiBzcGVjaWZpYyBzdWdnZXN0aW9ucyBm b3IgYWRkaXRpb25zIHRvIHRoZSB0ZXh0Lgo+Cj4KPiBJcyB0aGF0IHRoZSBjYXNlIHdpdGggcmVn YXJkIHRvIHRoaXMgcGFydGljdWxhciBkb2N1bWVudCwgTWFyaz8gT3IgLQo+IHJhdGhlciB0aGFu IGFza2luZyB0aGF0IHF1ZXN0aW9uIC0gIGxldCB1cyBhc3N1bWUgdGhhdCBpdCBpcywgdGhlbiBo YXZlIGl0cwo+IGVkaXRvcnMgc2ltcGx5IGN1dCBhbmQgcGFzdCBlYWNoICJmaXJzdCB1c2UgbWVu dGlvbiIgaW50byBhICJUZXJtcyBhbmQKPiBEZWZpbml0aW9ucyIgc2VjdGlvbiwgc28gdGhhdCBp dCBjYW4gYmUgdXNlZCBieSB0aG9zZSB1c2VkIHRvIHVzaW5nCj4gZGljdGlvbmFyaWVzIGFuZCBJ U08gZG9jdW1lbnRzIHdpdGggdGhlIHNhbWUgZWFzZSBhcyBpdCBjYW4gYmUgaWdub3JlZCBieQo+ IHRob3NlIHdobyBhcmUgbm90Lgo+CgpOby4gSSdtIHNheWluZyB0aGF0IGlmIHlvdSBwZXJzb25h bGx5LCBvciBhbnlvbmUgZWxzZSBvbiB0aGlzIGxpc3QsIGZpbmRzIGEKY2FzZSB3aGVyZSBhIHRl cm0gaXMgbm90IGNsZWFyIG9uIGZpcnN0IHVzYWdlLCB0aGVuIHlvdSBzaG91bGQgcG9pbnQgaXQg b3V0CmFuZCBzdWdnZXN0IGFkZGl0aW9uYWwgdGV4dCBhdCB0aGF0IHBvaW50LgoKSSdtIG5vdCwg aW4gdGhlb3J5LCBhZ2FpbnN0IGhhdmluZyBhIGdsb3NzYXJ5IG9mIGNvbGxlY3RlZCB0ZXJtcyBh dCB0aGUgZW5kCj4gb2YgdGhlIGRvY3VtZW50IGZvciByZWZlcmVuY2UuCj4KPgo+IEdvb2QuIEl0 IHdvdWxkIGJlIGEgd29ycnkgaWYgeW91IHdlcmUgYWdhaW5zdCBpbmNsdWRpbmcgaW4gdGhlIGRv Y3VtZW50IGEKPiBnbG9zc2FyeSBvZiBjb2xsZWN0ZWQgdGVybXMgKEkgc2F5IHRoaXMgYmVjYXVz ZSBJIGdlbmVyYWxseSBmaW5kIG15c2VsZiBpbgo+IGFncmVlbWVudCB3aXRoIG11Y2ggb2YgdGhl IGNvbnRlbnQgb2YgbWFueSBvZiB5b3VyIG1zZ3MsIGFuZCB3b3VsZCBub3QgbGlrZQo+IHRoaXMg dG8gYmUgZGlmZmVyZW50KS4KPgo+IEJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIHdvcnRoIHRoZSB0 aW1lIGFuZCBlZmZvcnQgY29tcGFyZWQgdG8gZ2V0dGluZyB0aGUKPiAiZmlyc3QgdXNhZ2UiIGlu c3RhbmNlcyBjb3JyZWN0LiBBbmQgaXQgbWlnaHQgYmV0dGVyIGdvIGluIGEgIkxhbmd1YWdlIFRh Zwo+IFR1dG9yaWFsIi4KPgo+Cj4gSWYgeW91IGFyZSBwcm9wb3NpbmcgdG8gY29tcG9zZSBhICJM YW5ndWFnZSBUYWcgVHV0b3JpYWwiLCB0aGF0IHdvdWxkCj4gcHJvYmFibHkgYmUgdXNlZnVsLCBh cyB3ZWxsICAoYnV0IG11Y2ggbW9yZSB3b3JrIGZvciB5b3UgdG8gY29tcGlsZSB0aGFuIHRoZQo+ IHVzdWFsICJUZXJtcyBhbmQgRGVmaW5pdGlvbnMiIGNvbXBvbmVudCB1c2VycyBvZiBJU08gc3Rh bmRhcmRzIGZpbmQgc28gaGFuZHkKPiBmb3IgcmVmLikuCj4KCk5vLiBJJ20gc2F5aW5nIHRoYXQg aWYgc29tZW9uZSB3YW50cyB0byB3cml0ZSBhIHR1dG9yaWFsLCBhbmQgY29sbGVjdCB0ZXJtcywK dGhhdCdzIGZpbmUuIEdvIGFoZWFkLgoKbWcKPgo+Cj4KPiBNYXJrCj4KPiBPbiA4LzMwLzA3LCBN YXJpb24gR3VubiA8bWd1bm5AZWd0LmllPiB3cm90ZToKPiA+Cj4gPiBJIGFtIGluIHRvdGFsIGFn cmVlbWVudCB3aXRoIERHIG9uIHRoaXMgbWF0dGVyIChhcyBzZXQgb3V0IGJlbG93IGluCj4gPiBo ZXIgbXNnIG9mIHRvZGF5IC0gYXMgY2l0ZWQgYmVsb3cgLSB3aGljaCBtc2cgb2YgaGVycyBlY2hv ZXMgdGhlCj4gPiBzdWJzdGFuY2Ugb2Ygb25lIG9mIG1pbmUgb2YgeWVzdGVyZGF5LCBJIGJlbGll dmUpLgo+ID4gbWcKPiA+Cj4gPiBPbiAzMCBBdWcgMjAwNywgYXQgMTU6MTcsIHNjcsOtb2JoIERl YmJpZSBHYXJzaWRlOgo+ID4KPiA+ID4gLi4uIEkgdGhpbmsgdG8gZGV2aXNlIGEgVGVybXMKPiA+ ID4gYW5kIERlZmluaXRpb25zIHNlY3Rpb24gd291bGQgYmUgdmVyeSB1c2VmdWwgdG8gbmV3Ymll cy4gIEl0IHdvdWxkCj4gPiA+IGFsc28KPiA+ID4gY2VtZW50IHRoZSB0ZXJtaW5vbG9neSBmb3Ig ZWFzZSBvZiB1c2UgaW4gb3RoZXIgZG9jdW1lbnRzIHdpc2hpbmcgdG8KPiA+ID4gcmVmZXJlbmNl IHRoZSBSRkMuCj4KPgo+IC0gLQo+IE1hcmlvbiBHdW5uICogRUdUZW8gKEVzdGFiLjE5OTEpCj4g MjcgUMOhaXJjIGFuIEZow6lpdGhsaW5uLCBCYWlsZSBhbgo+IEJow7N0aGFpciwgQ28uIMOBdGhh IENsaWF0aCwgw4lpcmUuCj4gKiBtZ3VubkBlZ3QuaWUgKiBlYW1vbm5AZWd0LmllICoKPgo+Cj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1h aWxpbmcgbGlzdAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1Cj4KPgoKCi0tIApNYXJrCg== ------=_Part_6840_11942534.1188492393444 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA4LzMwLzA3LCA8YiBjbGFzcz0i Z21haWxfc2VuZGVybmFtZSI+TWFyaW9uIEd1bm48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86bWd1 bm5AZWd0LmllIj5tZ3VubkBlZ3QuaWU8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0 LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyI+CjxkaXYgc3R5bGU9IiI+PGJyPjxkaXY+PGRpdj5PbiAzMCBBdWcgMjAwNywgYXQgMTY6MjYs IHNjcsOtb2JoIE1hcmsgRGF2aXM6PC9kaXY+PHNwYW4gY2xhc3M9InEiPjxicj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5JIGZpbmQgdGhlIHR5cGljYWwgVGVybXMgYW5kIERlZmluaXRpb25zIHNl Y3Rpb25zIGF0IHRoZSBzdGFydCBvZiBtYW55IElTTyBkb2N1bWVudHMgYWN0dWFsbHkgY291bnRl ci1wcm9kdWN0aXZlLiBUaGUgaXRlbXMgYXJlIHByZXNlbnRlZCBiZWZvcmUgeW91IGhhdmUgYW55 IGJhY2tncm91bmQgZm9yIHdoYXQgdGhlIGRlZmluaXRpb25zIHJlYWxseSBtZWFuLCBhbmQgYXJl IGluIG5vIGNvaGVzaXZlIG9yZGVyLiAKPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48 L3NwYW4+QWxwaGFiZXRpY2FsIG9yZGVyIGlzIGNvaGVzaXZlIGVub3VnaCBmb3IgbW9zdCBwcm9m ZXNzaW9uYWwgdXNlcnMuIEFkZGVkIHRvIHRoYXQsIGV2ZW4gZm9yIG5ld2JpZXMsIGl0IGlzIHBy ZWRpY3RhYmxlLCBsb2dpY2FsLCBjb25zaXN0ZW50IHdpdGggSVNPIGRvY3VtZW50cyBpbiBnZW5l cmFsLCB3aXRoIHdoaWNoIG9uZSB3b3VsZCBleHBlY3QgbW9zdCB1c2VycyBvZiB0aGlzIGxpc3Qg dG8gYmUgZmFtaWxpYXIuCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5JIGRpc2Fn cmVlLiBJJiMzOTt2ZSBoaXQgbWFueSBpbnN0YW5jZXMgd2hlcmUgdGhlIGRlZmluaXRpb24gb2Yg YW4gSVNPIHRlcm0gbWFrZXMgbm8gc2Vuc2UgdW50aWwgeW91JiMzOTt2ZSByZWFkIGVub3VnaCBv ZiB0aGUgd2F5IHRocm91Z2ggdGhlIGRvY3VtZW50IHRvIHVuZGVyc3RhbmQgaXQuIEFscGhhYmV0 aWNhbCBpcyBmaW5lIGZvciByZWZlcmVuY2UgKmFmdGVyKiB5b3UmIzM5O3ZlIHJlYWQgdGhlIGRv Y3VtZW50LCBidXQgaXQgaXMgYSBuaWNlIHRvIGhhdmUsIGFuZCBub3QgYSByZXF1aXJlbWVudC4K PGJyPjxicj5XZSBhcmUgbm90IHdyaXRpbmcgYW4gSVNPIGRvY3VtZW50LCBhbmQgdGhlcmUgaXMg bm8gcmVxdWlyZW1lbnQgdG8gZm9sbG93IGl0cyBmb3JtYXQuPGJyPjwvZGl2Pjxicj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4KPGRpdiBzdHlsZT0iIj48ZGl2PjxzcGFuIGNsYXNzPSJxIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj5BcyB5b3UgcmVhZCB0aGUgZG9jdW1lbnQsIGVhY2ggdGVjaG5pY2FsIHRlcm0g c2hvdWxkIGJlIGRlZmluZWQgaW4gdGhlIHBhcmFncmFwaCB3aGVyZSBpdCBpcyBmaXJzdCB1c2Vk LiBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgdGhlbiBwbGVhc2UgbWFrZSBzcGVjaWZpYyBzdWdn ZXN0aW9ucyBmb3IgYWRkaXRpb25zIHRvIHRoZSB0ZXh0Lgo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+ PGJyPjwvZGl2Pjwvc3Bhbj5JcyB0aGF0IHRoZSBjYXNlIHdpdGggcmVnYXJkIHRvIHRoaXMgcGFy dGljdWxhciBkb2N1bWVudCwgTWFyaz8gT3IgLSByYXRoZXIgdGhhbiBhc2tpbmcgdGhhdCBxdWVz dGlvbiAtJm5ic3A7IGxldCB1cyBhc3N1bWUgdGhhdCBpdCBpcywgdGhlbiBoYXZlIGl0cyBlZGl0 b3JzIHNpbXBseSBjdXQgYW5kIHBhc3QgZWFjaCAmcXVvdDtmaXJzdCB1c2UgbWVudGlvbiZxdW90 OyBpbnRvIGEgJnF1b3Q7VGVybXMgYW5kIERlZmluaXRpb25zJnF1b3Q7IHNlY3Rpb24sIHNvIHRo YXQgaXQgY2FuIGJlIHVzZWQgYnkgdGhvc2UgdXNlZCB0byB1c2luZyBkaWN0aW9uYXJpZXMgYW5k IElTTyBkb2N1bWVudHMgd2l0aCB0aGUgc2FtZSBlYXNlIGFzIGl0IGNhbiBiZSBpZ25vcmVkIGJ5 IHRob3NlIHdobyBhcmUgbm90Lgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+Tm8u IEkmIzM5O20gc2F5aW5nIHRoYXQgaWYgeW91IHBlcnNvbmFsbHksIG9yIGFueW9uZSBlbHNlIG9u IHRoaXMgbGlzdCwgZmluZHMgYSBjYXNlIHdoZXJlIGEgdGVybSBpcyBub3QgY2xlYXIgb24gZmly c3QgdXNhZ2UsIHRoZW4geW91IHNob3VsZCBwb2ludCBpdCBvdXQgYW5kIHN1Z2dlc3QgYWRkaXRp b25hbCB0ZXh0IGF0IHRoYXQgcG9pbnQuCjxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRp diBzdHlsZT0iIj48ZGl2PjxzcGFuIGNsYXNzPSJxIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5J JiMzOTttIG5vdCwgaW4gdGhlb3J5LCBhZ2FpbnN0IGhhdmluZyBhIGdsb3NzYXJ5IG9mIGNvbGxl Y3RlZCB0ZXJtcyBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVudCBmb3IgcmVmZXJlbmNlLiAKPGJy PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48L3NwYW4+R29vZC4gSXQgd291bGQgYmUgYSB3 b3JyeSBpZiB5b3Ugd2VyZSBhZ2FpbnN0IGluY2x1ZGluZyBpbiB0aGUgZG9jdW1lbnQgYSBnbG9z c2FyeSBvZiBjb2xsZWN0ZWQgdGVybXMgKEkgc2F5IHRoaXMgYmVjYXVzZSBJIGdlbmVyYWxseSBm aW5kIG15c2VsZiBpbiBhZ3JlZW1lbnQgd2l0aCBtdWNoIG9mIHRoZSBjb250ZW50IG9mIG1hbnkg b2YgeW91ciBtc2dzLCBhbmQgd291bGQgbm90IGxpa2UgdGhpcyB0byBiZSBkaWZmZXJlbnQpLgo8 L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJxIj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+QnV0 IEkgZG9uJiMzOTt0IHRoaW5rIGl0IGlzIHdvcnRoIHRoZSB0aW1lIGFuZCBlZmZvcnQgY29tcGFy ZWQgdG8gZ2V0dGluZyB0aGUgJnF1b3Q7Zmlyc3QgdXNhZ2UmcXVvdDsgaW5zdGFuY2VzIGNvcnJl Y3QuIEFuZCBpdCBtaWdodCBiZXR0ZXIgZ28gaW4gYSAmcXVvdDtMYW5ndWFnZSBUYWcgVHV0b3Jp YWwmcXVvdDsuCjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PC9zcGFuPklmJm5ic3A7 eW91IGFyZSBwcm9wb3NpbmcgdG8gY29tcG9zZSBhICZxdW90O0xhbmd1YWdlIFRhZyBUdXRvcmlh bCZxdW90OywgdGhhdCB3b3VsZCBwcm9iYWJseSBiZSB1c2VmdWwsIGFzIHdlbGwmbmJzcDsgKGJ1 dCBtdWNoIG1vcmUgd29yayBmb3IgeW91IHRvIGNvbXBpbGUgdGhhbiB0aGUgdXN1YWwgJnF1b3Q7 VGVybXMgYW5kIERlZmluaXRpb25zJnF1b3Q7IGNvbXBvbmVudCB1c2VycyBvZiBJU08gc3RhbmRh cmRzIGZpbmQgc28gaGFuZHkgZm9yIHJlZi4pLgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48YnI+Tm8uIEkmIzM5O20gc2F5aW5nIHRoYXQgaWYgc29tZW9uZSB3YW50cyB0byB3cml0ZSBh IHR1dG9yaWFsLCBhbmQgY29sbGVjdCB0ZXJtcywgdGhhdCYjMzk7cyBmaW5lLiBHbyBhaGVhZC48 YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2IHN0eWxlPSIiPjxzcGFuIGNsYXNzPSJz ZyI+PGRpdj5tZzwvZGl2Pjwvc3Bhbj48c3BhbiBjbGFzcz0icSI+PGRpdj48YnI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+IDxicj48YnI+TWFyazxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIDgvMzAvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5NYXJpb24g R3VubjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzptZ3VubkBlZ3QuaWUiIHRhcmdldD0iX2JsYW5r IiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+ Cm1ndW5uQGVndC5pZTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0 KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4gSSBhbSBp biB0b3RhbCBhZ3JlZW1lbnQgd2l0aCBERyBvbiB0aGlzIG1hdHRlciAoYXMgc2V0IG91dCBiZWxv dyBpbgo8YnI+aGVyIG1zZyBvZiB0b2RheSAtIGFzIGNpdGVkIGJlbG93IC0gd2hpY2ggbXNnIG9m IGhlcnMgZWNob2VzIHRoZTxicj5zdWJzdGFuY2Ugb2Ygb25lIG9mIG1pbmUgb2YgeWVzdGVyZGF5 LCBJIGJlbGlldmUpLjxicj5tZzxicj48YnI+T24gMzAgQXVnIDIwMDcsIGF0IDE1OjE3LCBzY3LD rW9iaCBEZWJiaWUgR2Fyc2lkZTogPGJyPjxicj4mZ3Q7IC4uLiBJIHRoaW5rIHRvIGRldmlzZSBh IFRlcm1zCjxicj4mZ3Q7IGFuZCBEZWZpbml0aW9ucyBzZWN0aW9uIHdvdWxkIGJlIHZlcnkgdXNl ZnVsIHRvIG5ld2JpZXMuJm5ic3A7Jm5ic3A7SXQgd291bGQ8YnI+Jmd0OyBhbHNvPGJyPiZndDsg Y2VtZW50IHRoZSB0ZXJtaW5vbG9neSBmb3IgZWFzZSBvZiB1c2UgaW4gb3RoZXIgZG9jdW1lbnRz IHdpc2hpbmcgdG88YnI+Jmd0OyByZWZlcmVuY2UgdGhlIFJGQy4mbmJzcDs8L2Jsb2NrcXVvdGU+ PC9kaXY+PC9ibG9ja3F1b3RlPgo8L2Rpdj48YnI+PGRpdj4gPGRpdj4tIC0mbmJzcDs8L2Rpdj48 ZGl2Pk1hcmlvbiBHdW5uICogRUdUZW8gKEVzdGFiLjE5OTEpPC9kaXY+PGRpdj4yNyBQw6FpcmMg YW4gRmjDqWl0aGxpbm4sIEJhaWxlIGFuIDwvZGl2PjxkaXY+QmjDs3RoYWlyLCBDby4gw4F0aGEg Q2xpYXRoLCDDiWlyZS48L2Rpdj48ZGl2PiogPGEgaHJlZj0ibWFpbHRvOm1ndW5uQGVndC5pZSIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj4KbWd1bm5AZWd0LmllPC9hPiAqIDxhIGhyZWY9Im1haWx0bzplYW1vbm5A ZWd0LmllIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiPmVhbW9ubkBlZ3QuaWU8L2E+ICo8L2Rpdj4gIDwvZGl2Pjxi cj48L3NwYW4+PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCjxicj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOkx0cnVAaWV0 Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+Cmh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+ PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_6840_11942534.1188492393444-- --===============1174200385== 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 --===============1174200385==-- From ltru-bounces@ietf.org Thu Aug 30 13:05: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 1IQnSR-0001sN-Io; Thu, 30 Aug 2007 13:05:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQnSQ-0001n3-Cw for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 13:05:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnSP-0001jh-DH for ltru@ietf.org; Thu, 30 Aug 2007 13:05:25 -0400 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQnSO-0007T6-UH for ltru@ietf.org; Thu, 30 Aug 2007 13:05:25 -0400 Received: (qmail 84545 messnum 2903288 invoked from network[194.125.205.91/ts07-091.dublin.indigo.ie]); 30 Aug 2007 17:05:22 -0000 Received: from ts07-091.dublin.indigo.ie (HELO ?194.125.205.91?) (194.125.205.91) by mail07.svc.cra.dublin.eircom.net (qp 84545) with SMTP; 30 Aug 2007 17:05:22 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070829131355.GC2623@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <6.0.0.20.2.20070829124940.05bc2ad0@localhost> <20070829131355.GC2623@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: extlang Date: Thu, 30 Aug 2007 18:05:17 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 29 Aug 2007, at 13:13, scr=EDobh John Cowan: > Note that it's the "microlanguages" (not an official term), the =20 > languages > encompassed by macrolanguages, that are handled by extlang subtags... > I strongly object to the use of the above unofficial term, which John =20= Cowan is now using this list to promote (as evidenced in a recent msg =20= from him, as cited below) and I believe that, if the administrators =20 of this list _fail_ to deprecate his use of such an objectionable =20 term, that this may be an appropriate time for representatives of the =20= National Bodies of governments of the countries whose indigenous =20 languages he has so denigrated (by his deliberate use of said =20 unofficial term) to withdraw any provisional support they may have =20 given until now to the use of the term "macrolanguages" (because that =20= provisional support for treating that term as "official" would seem =20 to be providing the opportunity to use an objectionable word to =20 denigrate languages without even naming them). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 13:13: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 1IQnZx-0001Q6-IS; Thu, 30 Aug 2007 13:13:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQnZx-0001Q1-1x for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 13:13:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnZw-0001Pt-NH for ltru@ietf.org; Thu, 30 Aug 2007 13:13:12 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQnZw-0007hN-1E for ltru@ietf.org; Thu, 30 Aug 2007 13:13:12 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7UHD7vV079751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 10:13:07 -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=nTYQVdFl+OIp+ZCQxHEQGIb/0VhfzKEV5IUC7uUGFEIOALvSPhlK32bTz05EAp7/ Message-ID: <46D6FAA3.2030805@yahoo-inc.com> Date: Thu, 30 Aug 2007 10:13:07 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: extlang References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -13.8 (-------------) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > These are the cases that relate to the > way language-range works. > Not exactly. Language-ranges are the expression of the preference. While HTTP 1.1 and others didn't put a lot of structure around language negotiation, we spent some time doing so in RFC 4647. HTTP 1.1 and other, similar, items defined what we now call "basic filtering". That's what Peter means by the above. There is also "lookup", which is widely implemented (not well that I do not say "more widely"). In fact, we have different mechanisms for working with language tagged materials and these mechanisms each have their own uses and practical usage scenarios. As for extlangs... I'm not sure we can solve this by arguing either case. Both the pro- and anti-extlang parties have valid points and in some cases the extlang tags *are* more useful and in some cases they *are* more harmful. For a long time I supported extlangs because they were the direction we had laid down, in particular for Chinese languages. However, some things bother me about this approach: 1. If the languages in question really are distinct languages, why does subordinating the language make sense? Yes, you couldn't tag this or that language yesterday via the less distinct macrolanguage tag. Is that appropriate? Thus, if I were to support extlang, it would be based solely on John Cowan's argument that we need extlang to prevent a "retagging crisis" for languages formerly enclosed by a macrolanguage. 2. Randy suggested (a long while ago now) that cherry-picking from the macrolanguage list would be a bad idea. Yet tag stability provisions prevent us from taking the list wholesale. And I have some concern that the macrolanguage "collections" (if you'll pardon this inaccurate term) have yet to be thoroughly tested. They may not be stable or suitable in the short-to-medium term. This is not a critique of ISO 639-3's work here. It is merely a note of caution. If I were to support doing extlangs, it would consider each macrolanguage separately, as a one-time-event, and, again, solely as a compatibility item. Note that we also face our own exception--I assume future sign languages would be treated as extlangs for compatibility reasons. Note that sign languages are NOT macrolanguages in the first place--they are already exceptional. I would favor eliminating this use of extlang too. 3. Mark's arguments about "better matching choices" really don't fit with matching as described in RFC 4647. Applications really do need to do more than the trivial matching in BCP 47 in many cases, but these depend on application specific needs. "Pure" BCP 47 matching has its place and cannot do many of the things that Mark suggests (as with Breton -> French fallback). Mark's arguments about losing subsidiary subtags when matching extlangs *do* concern me. I had to modify my implementation of filtering to make it work in an extlang world. The modifications were not difficult and were reasonably successful. I *could* support a very limited application of extlang... ... but I feel that we're doing a disservice to the various languages involved by making them extlangs. Shouldn't Cantonese, Wu, or Hakka be treated fully as languages? Yes, it saves some retagging in the short term, but it is cleaner and clearer to tag languages directly. Users can still use the macrolanguage tag instead (I doubt we'll see much 'cmn-*' when 'zh-*' is available). It eliminates a complexity in tagging and language negotiation/selection who's purpose is served by compatibility alone. And content will need to be retagged in either case to take advantage of the distinction. Content that is not retagged won't be distinct. 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 Aug 30 13:37: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 1IQnxK-0008Cs-Lh; Thu, 30 Aug 2007 13:37:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQnxJ-0008C7-35 for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 13:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnxI-0008Bz-Ps for ltru@ietf.org; Thu, 30 Aug 2007 13:37:20 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQnxH-0002b5-H4 for ltru@ietf.org; Thu, 30 Aug 2007 13:37:20 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l7UHb4PD001628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 10:37: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=HdbBAGg3vtN3idx9zBcS0EETSUHz7/5KX1kRhEtFjqBOUFSWv6ecM7//YWVJ240r Message-ID: <46D7003F.7080202@yahoo-inc.com> Date: Thu, 30 Aug 2007 10:37:03 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> In-Reply-To: <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dewell@roadrunner.com, 'LTRU Working Group' Subject: [Ltru] Re: Introduction X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have several comments on this thread, submitted as a technical contributor unless otherwise noted: 1. I objected to making extensive editorial changes to the introduction and elsewhere because this work, RFC 4646bis, follows hard on the heels of a quite extensive revision of the document. I have been editing this document for 4 1/2 years now. I don't love every word of it. Like many documents written by a committee, it is not truly beautiful. However, having recently achieved consensus on this document (since it was published as an RFC)---a consensus that must have included on some level the commenters, since their names appear in the acknowledgments--I am loathe to go back and make an extensive series of revisions. This effort was chartered as a fairly minor one focused on extlangs. As an editor, I do occasionally restructure or rewrite text as a result of the changes we are currently working on. However, I don't feel we should proceed, paragraph by paragraph, to alter the document at length. 2. Terms and definitions sections are all very well. This document even has such a section, although it is not called that. Section 2.2 contains a terminology section, where we define the critical terms for understanding the document. 3. I note that the original comment was about the term 'extlang'. However, 'extlang' is NOT a term (although we use it as one on this list). It has two uses in the document: i. It is the name of a production in the ABNF grammar. ii. It is a subtag 'type' string. It is references very carefully this way in all cases. The proper term is "extended language subtag" and it is defined in Section 2.2.2. Note that this is the same part of the document where the other terminology is defined. 4. I suspect that a Terms and Definitions appendix will serve to make the document longer, but will little avail readers. I invite someone to suggest the terminology list with definitions. However, me tendency is to think that it will be somewhat redundant with the body of the document. Regards, 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 Aug 30 13:47: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 1IQo6h-0002Ms-86; Thu, 30 Aug 2007 13:47:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQo6f-0002Mh-AV for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 13:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQo6f-0002MW-0q for ltru@ietf.org; Thu, 30 Aug 2007 13:47:01 -0400 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQo6d-0002nf-LF for ltru@ietf.org; Thu, 30 Aug 2007 13:47:01 -0400 Received: (qmail 75516 messnum 5104160 invoked from network[194.125.205.91/ts07-091.dublin.indigo.ie]); 30 Aug 2007 17:46:58 -0000 Received: from ts07-091.dublin.indigo.ie (HELO ?194.125.205.91?) (194.125.205.91) by mail17.svc.cra.dublin.eircom.net (qp 75516) with SMTP; 30 Aug 2007 17:46:58 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <46D6FAA3.2030805@yahoo-inc.com> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com> <46D6FAA3.2030805@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: extlang Date: Thu, 30 Aug 2007 18:46:59 +0000 To: LTRU Working Group , Addison Phillips X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 30 Aug 2007, at 17:13, scr=EDobh Addison Phillips: > ... > As for extlangs... I'm not sure we can solve this by arguing either =20= > case. Both the pro- and anti-extlang parties have valid points and =20 > in some cases the extlang tags *are* more useful and in some cases =20 > they *are* more harmful... The most harmful aspect of extlangs, Addison, is John Cowan's =20 reckless use of an objectionable unofficial term (in his msg below), =20 which I am still waiting for a list administrator to challenge/=20 deprecate via the list, because that unofficial term denigrates the =20 indigenous languages of certain countries. mg On 29 Aug 2007, at 13:13, scr=EDobh John Cowan: > Note that it's the "microlanguages" (not an official term), the =20 > languages > encompassed by macrolanguages, that are handled by extlang subtags... > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 14: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 1IQoRw-0004Yw-AH; Thu, 30 Aug 2007 14:09:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQoRv-0004Yq-OX for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 14:08:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQoRv-0004Yi-EE for ltru@ietf.org; Thu, 30 Aug 2007 14:08:59 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQoRv-0000dv-1l for ltru@ietf.org; Thu, 30 Aug 2007 14:08:59 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k4cZnlQOJlEUR4nDNahJBwCooRRqcSykec7g/jekrXLz+dmmyZsTlGsLbWIHISw6; 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.242.127] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQoRu-0000Ow-7E for ltru@ietf.org; Thu, 30 Aug 2007 14:08:58 -0400 Message-ID: <005201c7eb31$2d34ac20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> Subject: Re: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Thu, 30 Aug 2007 11:11:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356b735514f8b6fd659479a64c05eab6683350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.242.127 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org hi - As a co-chair... > From: "Debbie Garside" > To: ; "'LTRU Working Group'" > Sent: Thursday, August 30, 2007 8:17 AM > Subject: RE: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) ... > In general, I have found that I cannot understand an ISO document unless I > refer to the Terms and Definitions section. This is a direct consequence of their custom of putting most definitions in this section. Another approach, more typical of IETF documents, is for terms and conventions to be defined on first use. Some documents will collect this information into a section on conventions or definitions, but there is no requirement to do it in any particular manner. > I am in agreement with Doug, > whether it be placed front or back matters not but I think to devise a Terms > and Definitions section would be very useful to newbies. It would also > cement the terminology for ease of use in other documents wishing to > reference the RFC. For this proposal to get any traction, you should propose specific text, or at least provide specific examples of terms which have caused problems for readers of the document. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 14:29: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 1IQolH-0002S4-L7; Thu, 30 Aug 2007 14:28:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQolG-0002Ry-7I for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 14:28:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQolF-0002Rq-RO for ltru@ietf.org; Thu, 30 Aug 2007 14:28:57 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQolF-00018F-D8 for ltru@ietf.org; Thu, 30 Aug 2007 14:28:57 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aCY5bRw8hY4EiDQwilfMRM0TNvQx13lDOh6BPnNGOvcTWro88BkfcSme21E8guZg; 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.242.127] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQol9-00062u-P1 for ltru@ietf.org; Thu, 30 Aug 2007 14:28:52 -0400 Message-ID: <008801c7eb33$f4688b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com><20070828223536.GB31670@mercury.ccil.org><6.0.0.20.2.20070829124940.05bc2ad0@localhost><20070829131355.GC2623@mercury.ccil.org> <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> Date: Thu, 30 Aug 2007 11:31:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356931064ef4729b2af1d6b54c3c7576c43350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.242.127 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Ltru] Use of the string "microlangauges" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair... > From: "Marion Gunn" > To: "LTRU Working Group" > Sent: Thursday, August 30, 2007 11:05 AM > Subject: Re: [Ltru] Re: extlang > > On 29 Aug 2007, at 13:13, scríobh John Cowan: > > > Note that it's the "microlanguages" (not an official term), the > > languages > > encompassed by macrolanguages, that are handled by extlang subtags... > > > > I strongly object to the use of the above unofficial term, which John On what grounds? If the string '"microlanguages" (not an official term)' is objectionable to you as a shorthand for "language tag which are constructed by joining an extlang representing an macrolanguage and an additional subtag to identify the specific language" (or something like that), please suggest a concise alternative suitable for use in our discussion. > Cowan is now using this list to promote (as evidenced in a recent msg > from him, as cited below) and I believe that, if the administrators > of this list _fail_ to deprecate his use of such an objectionable > term, that this may be an appropriate time for representatives of the > National Bodies of governments of the countries whose indigenous > languages he has so denigrated (by his deliberate use of said > unofficial term) to withdraw any provisional support they may have > given until now to the use of the term "macrolanguages" (because that > provisional support for treating that term as "official" would seem > to be providing the opportunity to use an objectionable word to > denigrate languages without even naming them). ... Participation in the IETF is by individuals, not National Body representatives. Calls such as this are meaningless. We use "unofficial terms" all the time. Honestly, I completely fail to see how "microlanguage" (formed by obvious analogy from "macrolanguage") to describe language tags formed in a particular way could be though to "denigrate" a language. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 14:34: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 1IQoqm-0007vO-O3; Thu, 30 Aug 2007 14:34:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQoql-0007vH-CJ for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 14:34:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQoqk-0007v9-Vy for ltru@ietf.org; Thu, 30 Aug 2007 14:34:39 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound10-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQoqj-0001IV-R8 for ltru@ietf.org; Thu, 30 Aug 2007 14:34:38 -0400 Received: from outbound10-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound10-sin-R.bigfish.com (Postfix) with ESMTP id 52B391BA8228; Thu, 30 Aug 2007 18:34:35 +0000 (UTC) Received: from mail87-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound10-sin.bigfish.com (Postfix) with ESMTP id 3E47E2C0057; Thu, 30 Aug 2007 18:34:35 +0000 (UTC) Received: from mail87-sin (localhost.localdomain [127.0.0.1]) by mail87-sin-R.bigfish.com (Postfix) with ESMTP id DEAD4D280A6; Thu, 30 Aug 2007 18:34:34 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail87-sin (MessageSwitch) id 1188498874845010_27491; Thu, 30 Aug 2007 18:34:34 +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 mail87-sin.bigfish.com (Postfix) with ESMTP id 55D9E728076; Thu, 30 Aug 2007 18:34:34 +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 2007083011343185-330268 ; Thu, 30 Aug 2007 11:34:31 -0700 In-Reply-To: To: Marion Gunn Subject: Re: [Ltru] Re: extlang 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: Thu, 30 Aug 2007 11:32:14 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/30/2007 11:32:15, Serialize complete at 08/30/2007 11:32:15, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/30/2007 11:34:31 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/30/2007 11:34:34 AM, Serialize complete at 08/30/2007 11:34:34 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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="===============1654012221==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1654012221== Content-Type: multipart/alternative; boundary="=_alternative 006609AC88257347_=" This is a multipart message in MIME format. --=_alternative 006609AC88257347_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" For the record, I suspect John used this term -- in quotes indicating that = this wasn't formal language -- because I had just used this term in an=20 offline e-mail to him trying to clarify the straw poll question. I=20 certainly meant nothing by it -- I was making sure that we were talking=20 about the languages encapsulated by the macrolanguage, not the=20 macrolanguage itself as was implied by the text. If this term has offended = you, I'm sorry for my part in it. I'm quite sure John did not use this in=20 the spirit you are suggesting.=20 If m*crolanguage is an offensive term, perhaps macrolanguage is as well? Regards, Karen Broome Marion Gunn =20 08/30/2007 11:46 AM To LTRU Working Group , Addison Phillips=20 cc Subject Re: [Ltru] Re: extlang On 30 Aug 2007, at 17:13, scr=EDobh Addison Phillips: > ... > As for extlangs... I'm not sure we can solve this by arguing either=20 > case. Both the pro- and anti-extlang parties have valid points and=20 > in some cases the extlang tags *are* more useful and in some cases=20 > they *are* more harmful... The most harmful aspect of extlangs, Addison, is John Cowan's=20 reckless use of an objectionable unofficial term (in his msg below),=20 which I am still waiting for a list administrator to challenge/=20 deprecate via the list, because that unofficial term denigrates the=20 indigenous languages of certain countries. mg On 29 Aug 2007, at 13:13, scr=EDobh John Cowan: > Note that it's the "microlanguages" (not an official term), the=20 > languages > encompassed by macrolanguages, that are handled by extlang subtags... > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006609AC88257347_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
For the record, I suspect John used this term -- in quotes indicating that this wasn't formal language -- becau= se I had just used this term in an offline e-mail to him trying to clarify the straw poll question. I certainly meant nothing by it -- I was making sure that we were talking about the languages encapsulated by the macrolang= uage, not the macrolanguage itself as was implied by the text. If this term has offended you, I'm sorry for my part in it. I'm quite sure John did not use this in the spirit you are suggesting.

If m*crolanguage is an offensive ter= m, perhaps macrolanguage is as well?

Regards,

Karen Broome




Marion Gunn <mgunn= @egt.ie>

08/30/2007 11:46 AM

To
LTRU Working Group <ltru@ietf.org= >, Addison Phillips <addison@yahoo-inc.com>
cc
Subject
Re: [Ltru] Re: extlang





On 30 Aug 2007, at 17:13, scr=EDobh Addison Phillips= :

> ...
> As for extlangs... I'm not sure we can solve this by arguing either  
> case. Both the pro- and anti-extlang parties have valid points and  
> in some cases the extlang tags *are* more useful and in some cases  
> they *are* more harmful...

The most harmful aspect of extlangs, Addison, is John Cowan's  
reckless use of an objectionable unofficial term (in his msg below),  =
which I am still waiting for a list administrator to challenge/
deprecate via the list, because that unofficial term denigrates the  <= br> indigenous languages of certain countries.
mg


On 29 Aug 2007, at 13:13, scr=EDobh John Cowan:


> Note that it's the "microlanguages" (not an official term), the  
> languages
> encompassed by macrolanguages, that are handled by extlang subtags...<= br> >


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



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 006609AC88257347_=-- --===============1654012221== 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 --===============1654012221==-- From ltru-bounces@ietf.org Thu Aug 30 15:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpHt-0002m3-LG; Thu, 30 Aug 2007 15:02:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQpHs-0002lu-5Z for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 15:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpHr-0002kr-RK for ltru@ietf.org; Thu, 30 Aug 2007 15:02:39 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQpHq-0004W6-J2 for ltru@ietf.org; Thu, 30 Aug 2007 15:02:39 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IQpHp-0005QZ-3t; Thu, 30 Aug 2007 15:02:37 -0400 Date: Thu, 30 Aug 2007 15:02:37 -0400 To: Marion Gunn Subject: Re: [Ltru] Re: extlang Message-ID: <20070830190237.GH11901@mercury.ccil.org> References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <6.0.0.20.2.20070829124940.05bc2ad0@localhost> <20070829131355.GC2623@mercury.ccil.org> <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Marion Gunn scripsit: > I strongly object to the use of the above unofficial term, which John > Cowan is now using this list to promote Promote? Rubbish. > if the administrators of this list _fail_ to deprecate his use of such > an objectionable term As Randy told you, this is the IETF, where we speak only for ourselves. In particular, I don't at any time speak for any group. > that this may be an appropriate time for representatives of the National > Bodies of governments of the countries whose indigenous languages > he has so denigrated (by his deliberate use of said unofficial term) > to withdraw any provisional support they may have given until now to > the use of the term "macrolanguages" (because that provisional support > for treating that term as "official" would seem to be providing the > opportunity to use an objectionable word to denigrate languages without > even naming them). However, you ought to know by now that threats against me don't get you very far. I'm sure the 639-3/RA and the 639/RA-JAC can take care of themselves; the notion that one word in one email can put ISO funding at risk is preposterous. I'm sorry to take up the list members' time with this, but baseless charges have to be nailed to the wall. Dixi. That said, the term is indeed a poor one, and I do acknowledge the unconscious influence of Karen's email to me. "Encompassed languages" is what I meant and should have said. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 17:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrWQ-00078l-HX; Thu, 30 Aug 2007 17:25:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQrWP-00075t-MI for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 17:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrWP-000757-CY for ltru@ietf.org; Thu, 30 Aug 2007 17:25:49 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQrWO-0007bB-4o for ltru@ietf.org; Thu, 30 Aug 2007 17:25:49 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 30 Aug 2007 14:25:44 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Thu, 30 Aug 2007 14:25:44 -0700 From: Peter Constable To: Marion Gunn , LTRU Working Group Date: Thu, 30 Aug 2007 14:25:43 -0700 Subject: RE: [Ltru] Re: extlang Thread-Topic: [Ltru] Re: extlang Thread-Index: AcfrKB8up4fz8jZCQEy11dr3WVFD8QAI7WQA Message-ID: References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <6.0.0.20.2.20070829124940.05bc2ad0@localhost> <20070829131355.GC2623@mercury.ccil.org> <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> In-Reply-To: <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think it's fairly obvious that John was using the term as a convenience f= or our discussions with purely technical meaning that does not in any way i= mply a value judgment on any language variety. For that matter, "macrolanguage" as defined in ISO 639-3 also does not conn= ote any value judgment on language varieties so designated, or even on thei= r sociolinguistic status. It has a technical meaning given in ISO 639-3 tha= t, I think, is clear in this regard. Peter > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie] > Sent: Thursday, August 30, 2007 11:05 AM > To: LTRU Working Group > Subject: Re: [Ltru] Re: extlang > > On 29 Aug 2007, at 13:13, scr=EDobh John Cowan: > > > Note that it's the "microlanguages" (not an official term), the > > languages > > encompassed by macrolanguages, that are handled by extlang subtags... > > > > I strongly object to the use of the above unofficial term, which John > Cowan is now using this list to promote (as evidenced in a recent msg > from him, as cited below) and I believe that, if the administrators > of this list _fail_ to deprecate his use of such an objectionable > term, that this may be an appropriate time for representatives of the > National Bodies of governments of the countries whose indigenous > languages he has so denigrated (by his deliberate use of said > unofficial term) to withdraw any provisional support they may have > given until now to the use of the term "macrolanguages" (because that > provisional support for treating that term as "official" would seem > to be providing the opportunity to use an objectionable word to > denigrate languages without even naming them). > mg > > > > > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 30 17:50: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 1IQrto-0007eR-SY; Thu, 30 Aug 2007 17:50:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQrtn-0007eL-2k for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 17:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrtm-0007eD-PM for ltru@ietf.org; Thu, 30 Aug 2007 17:49:58 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQrtl-00081Y-Gh for ltru@ietf.org; Thu, 30 Aug 2007 17:49:58 -0400 Received: by nz-out-0506.google.com with SMTP id n1so483043nzf for ; Thu, 30 Aug 2007 14:49:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=tFKrDs4lNoj1AsHJvIRgJHFRyvWeaoY/UD49jzujq797l3URmoecYf1mg/rlWoRgY0ByzNAiOEbT600UiITXk1msvO7qvbH6BE+BO43S9PMI3bT9FsMmqHo3WeTOtEhvWdz5WVG16V3ozRea+ttOeu2ZINpYtQzK4VOJvZsZGNg= 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=rpAPMWsaYYgQONdwNYuE0AMPWVEuIB/K+HaZlt7Ddlx0SZA/YEWC1lZu5kBcZ2zBlOJ9uFMr8ZZuS0kBcYcqIcwVVXTyEEit5YX7BX3dfpsht96vdl28CTDoj9imokkCtimeu0HTjWl23fTrrPtEYLSFiJTlo1SxHR/fT5Q+Ru0= Received: by 10.115.22.1 with SMTP id z1mr196589wai.1188510596440; Thu, 30 Aug 2007 14:49:56 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Thu, 30 Aug 2007 14:49:56 -0700 (PDT) Message-ID: <30b660a20708301449i62f2910chf03758ce3fc3b374@mail.gmail.com> Date: Thu, 30 Aug 2007 14:49:56 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: extlang In-Reply-To: MIME-Version: 1.0 References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org> <6.0.0.20.2.20070829124940.05bc2ad0@localhost> <20070829131355.GC2623@mercury.ccil.org> <9006FE87-D1F4-4720-AC9E-0288E0A10BD1@egt.ie> X-Google-Sender-Auth: 29577065323d2562 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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="===============1560206896==" Errors-To: ltru-bounces@ietf.org --===============1560206896== Content-Type: multipart/alternative; boundary="----=_Part_8062_28115820.1188510596396" ------=_Part_8062_28115820.1188510596396 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZS4gSXQgaXMgb2J2aW91cyB0aGF0IEpvaG4gd2FzIG5vdCBpbXBseWluZyBhbnl0aGlu ZyBhYm91dCB0aGUgdmFsdWUKb2YgdGhlIGxhbmd1YWdlcy4KCk1hcmsKCk9uIDgvMzAvMDcsIFBl dGVyIENvbnN0YWJsZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiBJIHRoaW5r IGl0J3MgZmFpcmx5IG9idmlvdXMgdGhhdCBKb2huIHdhcyB1c2luZyB0aGUgdGVybSBhcyBhIGNv bnZlbmllbmNlCj4gZm9yIG91ciBkaXNjdXNzaW9ucyB3aXRoIHB1cmVseSB0ZWNobmljYWwgbWVh bmluZyB0aGF0IGRvZXMgbm90IGluIGFueSB3YXkKPiBpbXBseSBhIHZhbHVlIGp1ZGdtZW50IG9u IGFueSBsYW5ndWFnZSB2YXJpZXR5Lgo+Cj4gRm9yIHRoYXQgbWF0dGVyLCAibWFjcm9sYW5ndWFn ZSIgYXMgZGVmaW5lZCBpbiBJU08gNjM5LTMgYWxzbyBkb2VzIG5vdAo+IGNvbm5vdGUgYW55IHZh bHVlIGp1ZGdtZW50IG9uIGxhbmd1YWdlIHZhcmlldGllcyBzbyBkZXNpZ25hdGVkLCBvciBldmVu IG9uCj4gdGhlaXIgc29jaW9saW5ndWlzdGljIHN0YXR1cy4gSXQgaGFzIGEgdGVjaG5pY2FsIG1l YW5pbmcgZ2l2ZW4gaW4gSVNPIDYzOS0zCj4gdGhhdCwgSSB0aGluaywgaXMgY2xlYXIgaW4gdGhp cyByZWdhcmQuCj4KPgo+Cj4gUGV0ZXIKPgo+Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+ID4gRnJvbTogTWFyaW9uIEd1bm4gW21haWx0bzptZ3VubkBlZ3QuaWVdCj4gPiBTZW50OiBU aHVyc2RheSwgQXVndXN0IDMwLCAyMDA3IDExOjA1IEFNCj4gPiBUbzogTFRSVSBXb3JraW5nIEdy b3VwCj4gPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBleHRsYW5nCj4gPgo+ID4gT24gMjkgQXVn IDIwMDcsIGF0IDEzOjEzLCBzY3LDrW9iaCBKb2huIENvd2FuOgo+ID4KPiA+ID4gTm90ZSB0aGF0 IGl0J3MgdGhlICJtaWNyb2xhbmd1YWdlcyIgKG5vdCBhbiBvZmZpY2lhbCB0ZXJtKSwgdGhlCj4g PiA+IGxhbmd1YWdlcwo+ID4gPiBlbmNvbXBhc3NlZCBieSBtYWNyb2xhbmd1YWdlcywgdGhhdCBh cmUgaGFuZGxlZCBieSBleHRsYW5nIHN1YnRhZ3MuLi4KPiA+ID4KPiA+Cj4gPiBJIHN0cm9uZ2x5 IG9iamVjdCB0byB0aGUgdXNlIG9mIHRoZSBhYm92ZSB1bm9mZmljaWFsIHRlcm0sIHdoaWNoIEpv aG4KPiA+IENvd2FuIGlzIG5vdyB1c2luZyB0aGlzIGxpc3QgdG8gcHJvbW90ZSAoYXMgZXZpZGVu Y2VkIGluIGEgcmVjZW50IG1zZwo+ID4gZnJvbSBoaW0sIGFzIGNpdGVkIGJlbG93KSBhbmQgSSBi ZWxpZXZlIHRoYXQsIGlmIHRoZSBhZG1pbmlzdHJhdG9ycwo+ID4gb2YgdGhpcyBsaXN0IF9mYWls XyB0byBkZXByZWNhdGUgaGlzIHVzZSBvZiBzdWNoIGFuIG9iamVjdGlvbmFibGUKPiA+IHRlcm0s IHRoYXQgdGhpcyBtYXkgYmUgYW4gYXBwcm9wcmlhdGUgdGltZSBmb3IgcmVwcmVzZW50YXRpdmVz IG9mIHRoZQo+ID4gTmF0aW9uYWwgQm9kaWVzIG9mIGdvdmVybm1lbnRzIG9mIHRoZSBjb3VudHJp ZXMgd2hvc2UgaW5kaWdlbm91cwo+ID4gbGFuZ3VhZ2VzIGhlIGhhcyBzbyBkZW5pZ3JhdGVkIChi eSBoaXMgZGVsaWJlcmF0ZSB1c2Ugb2Ygc2FpZAo+ID4gdW5vZmZpY2lhbCB0ZXJtKSB0byB3aXRo ZHJhdyBhbnkgcHJvdmlzaW9uYWwgc3VwcG9ydCB0aGV5IG1heSBoYXZlCj4gPiBnaXZlbiB1bnRp bCBub3cgdG8gdGhlIHVzZSBvZiB0aGUgdGVybSAibWFjcm9sYW5ndWFnZXMiIChiZWNhdXNlIHRo YXQKPiA+IHByb3Zpc2lvbmFsIHN1cHBvcnQgZm9yIHRyZWF0aW5nIHRoYXQgdGVybSBhcyAib2Zm aWNpYWwiIHdvdWxkIHNlZW0KPiA+IHRvIGJlIHByb3ZpZGluZyB0aGUgb3Bwb3J0dW5pdHkgdG8g dXNlIGFuIG9iamVjdGlvbmFibGUgd29yZCB0bwo+ID4gZGVuaWdyYXRlIGxhbmd1YWdlcyB3aXRo b3V0IGV2ZW4gbmFtaW5nIHRoZW0pLgo+ID4gbWcKPiA+Cj4gPgo+ID4KPiA+Cj4gPiAtIC0KPiA+ IE1hcmlvbiBHdW5uICogRUdUZW8gKEVzdGFiLjE5OTEpCj4gPiAyNyBQw6FpcmMgYW4gRmjDqWl0 aGxpbm4sIEJhaWxlIGFuCj4gPiBCaMOzdGhhaXIsIENvLiDDgXRoYSBDbGlhdGgsIMOJaXJlLgo+ ID4gKiBtZ3VubkBlZ3QuaWUgKiBlYW1vbm5AZWd0LmllICoKPiA+Cj4gPgo+ID4KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBMdHJ1IG1haWxp bmcgbGlzdAo+ID4gTHRydUBpZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydQo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgoKCgotLSAKTWFyawo= ------=_Part_8062_28115820.1188510596396 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZS4gSXQgaXMgb2J2aW91cyB0aGF0IEpvaG4gd2FzIG5vdCBpbXBseWluZyBhbnl0aGlu ZyBhYm91dCB0aGUgdmFsdWUgb2YgdGhlIGxhbmd1YWdlcy48YnI+PGJyPk1hcms8YnI+PGJyPjxk aXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA4LzMwLzA3LCA8YiBjbGFzcz0iZ21haWxf c2VuZGVybmFtZSI+UGV0ZXIgQ29uc3RhYmxlPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBldGVy Y29uQG1pY3Jvc29mdC5jb20iPgpwZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4 OyBwYWRkaW5nLWxlZnQ6IDFleDsiPkkgdGhpbmsgaXQmIzM5O3MgZmFpcmx5IG9idmlvdXMgdGhh dCBKb2huIHdhcyB1c2luZyB0aGUgdGVybSBhcyBhIGNvbnZlbmllbmNlIGZvciBvdXIgZGlzY3Vz c2lvbnMgd2l0aCBwdXJlbHkgdGVjaG5pY2FsIG1lYW5pbmcgdGhhdCBkb2VzIG5vdCBpbiBhbnkg d2F5IGltcGx5IGEgdmFsdWUganVkZ21lbnQgb24gYW55IGxhbmd1YWdlIHZhcmlldHkuCjxicj48 YnI+Rm9yIHRoYXQgbWF0dGVyLCAmcXVvdDttYWNyb2xhbmd1YWdlJnF1b3Q7IGFzIGRlZmluZWQg aW4gSVNPIDYzOS0zIGFsc28gZG9lcyBub3QgY29ubm90ZSBhbnkgdmFsdWUganVkZ21lbnQgb24g bGFuZ3VhZ2UgdmFyaWV0aWVzIHNvIGRlc2lnbmF0ZWQsIG9yIGV2ZW4gb24gdGhlaXIgc29jaW9s aW5ndWlzdGljIHN0YXR1cy4gSXQgaGFzIGEgdGVjaG5pY2FsIG1lYW5pbmcgZ2l2ZW4gaW4gSVNP IDYzOS0zIHRoYXQsIEkgdGhpbmssIGlzIGNsZWFyIGluIHRoaXMgcmVnYXJkLgo8YnI+PGJyPjxi cj48YnI+UGV0ZXI8YnI+PGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy PiZndDsgRnJvbTogTWFyaW9uIEd1bm4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWd1bm5AZWd0 LmllIj5tZ3VubkBlZ3QuaWU8L2E+XTxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzAs IDIwMDcgMTE6MDUgQU08YnI+Jmd0OyBUbzogTFRSVSBXb3JraW5nIEdyb3VwCjxicj4mZ3Q7IFN1 YmplY3Q6IFJlOiBbTHRydV0gUmU6IGV4dGxhbmc8YnI+Jmd0Ozxicj4mZ3Q7IE9uIDI5IEF1ZyAy MDA3LCBhdCAxMzoxMywgc2Nyw61vYmggSm9obiBDb3dhbjo8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsg Tm90ZSB0aGF0IGl0JiMzOTtzIHRoZSAmcXVvdDttaWNyb2xhbmd1YWdlcyZxdW90OyAobm90IGFu IG9mZmljaWFsIHRlcm0pLCB0aGU8YnI+Jmd0OyAmZ3Q7IGxhbmd1YWdlcwo8YnI+Jmd0OyAmZ3Q7 IGVuY29tcGFzc2VkIGJ5IG1hY3JvbGFuZ3VhZ2VzLCB0aGF0IGFyZSBoYW5kbGVkIGJ5IGV4dGxh bmcgc3VidGFncy4uLjxicj4mZ3Q7ICZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEkgc3Ryb25nbHkgb2Jq ZWN0IHRvIHRoZSB1c2Ugb2YgdGhlIGFib3ZlIHVub2ZmaWNpYWwgdGVybSwgd2hpY2ggSm9objxi cj4mZ3Q7IENvd2FuIGlzIG5vdyB1c2luZyB0aGlzIGxpc3QgdG8gcHJvbW90ZSAoYXMgZXZpZGVu Y2VkIGluIGEgcmVjZW50IG1zZwo8YnI+Jmd0OyBmcm9tIGhpbSwgYXMgY2l0ZWQgYmVsb3cpIGFu ZCBJIGJlbGlldmUgdGhhdCwgaWYgdGhlIGFkbWluaXN0cmF0b3JzPGJyPiZndDsgb2YgdGhpcyBs aXN0IF9mYWlsXyB0byBkZXByZWNhdGUgaGlzIHVzZSBvZiBzdWNoIGFuIG9iamVjdGlvbmFibGU8 YnI+Jmd0OyB0ZXJtLCB0aGF0IHRoaXMgbWF5IGJlIGFuIGFwcHJvcHJpYXRlIHRpbWUgZm9yIHJl cHJlc2VudGF0aXZlcyBvZiB0aGUKPGJyPiZndDsgTmF0aW9uYWwgQm9kaWVzIG9mIGdvdmVybm1l bnRzIG9mIHRoZSBjb3VudHJpZXMgd2hvc2UgaW5kaWdlbm91czxicj4mZ3Q7IGxhbmd1YWdlcyBo ZSBoYXMgc28gZGVuaWdyYXRlZCAoYnkgaGlzIGRlbGliZXJhdGUgdXNlIG9mIHNhaWQ8YnI+Jmd0 OyB1bm9mZmljaWFsIHRlcm0pIHRvIHdpdGhkcmF3IGFueSBwcm92aXNpb25hbCBzdXBwb3J0IHRo ZXkgbWF5IGhhdmU8YnI+CiZndDsgZ2l2ZW4gdW50aWwgbm93IHRvIHRoZSB1c2Ugb2YgdGhlIHRl cm0gJnF1b3Q7bWFjcm9sYW5ndWFnZXMmcXVvdDsgKGJlY2F1c2UgdGhhdDxicj4mZ3Q7IHByb3Zp c2lvbmFsIHN1cHBvcnQgZm9yIHRyZWF0aW5nIHRoYXQgdGVybSBhcyAmcXVvdDtvZmZpY2lhbCZx dW90OyB3b3VsZCBzZWVtPGJyPiZndDsgdG8gYmUgcHJvdmlkaW5nIHRoZSBvcHBvcnR1bml0eSB0 byB1c2UgYW4gb2JqZWN0aW9uYWJsZSB3b3JkIHRvCjxicj4mZ3Q7IGRlbmlncmF0ZSBsYW5ndWFn ZXMgd2l0aG91dCBldmVuIG5hbWluZyB0aGVtKS48YnI+Jmd0OyBtZzxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgLSAtPGJyPiZndDsgTWFyaW9uIEd1bm4gKiBFR1RlbyAo RXN0YWIuMTk5MSk8YnI+Jmd0OyAyNyBQw6FpcmMgYW4gRmjDqWl0aGxpbm4sIEJhaWxlIGFuPGJy PiZndDsgQmjDs3RoYWlyLCBDby4gw4F0aGEgQ2xpYXRoLCDDiWlyZS4KPGJyPiZndDsgKiA8YSBo cmVmPSJtYWlsdG86bWd1bm5AZWd0LmllIj5tZ3VubkBlZ3QuaWU8L2E+ICogPGEgaHJlZj0ibWFp bHRvOmVhbW9ubkBlZ3QuaWUiPmVhbW9ubkBlZ3QuaWU8L2E+ICo8YnI+Jmd0Ozxicj4mZ3Q7PGJy PiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4mZ3Q7IEx0cnUgbWFpbGluZyBsaXN0PGJyPiZndDsgCjxhIGhyZWY9Im1haWx0bzpM dHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiPmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Ckx0cnUgbWFpbGluZyBsaXN0PGJyPjxh IGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVm PSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxicj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+Ci0tIDxicj5NYXJrCg== ------=_Part_8062_28115820.1188510596396-- --===============1560206896== 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 --===============1560206896==-- From ltru-bounces@ietf.org Thu Aug 30 20:43: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 1IQubz-0002lv-9t; Thu, 30 Aug 2007 20:43:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQuby-0002lT-8i for ltru-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 20:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQubx-0002lL-Tw for ltru@ietf.org; Thu, 30 Aug 2007 20:43:45 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQubw-0002uj-63 for ltru@ietf.org; Thu, 30 Aug 2007 20:43:45 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007170609.msg for ; Fri, 31 Aug 2007 01:46:12 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 31 Aug 2007 01:43:37 +0100 From: "Debbie Garside" To: , "'Marion Gunn'" References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81><072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110><30b660a20708300926v71aeb83eu33c8ccaa0d986a01@mail.gmail.com> <30b660a20708300946t2295b031vba4b3d2af8f1165@mail.gmail.com> Subject: RE: Introduction (was: Re: [Ltru] draft-ietf-ltru-rfc4646bis-08) Date: Fri, 31 Aug 2007 01:38:42 +0100 Message-ID: <07e601c7eb67$4843cbf0$0b00a8c0@CPQ86763045110> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfrJWCUbQXLN4QVTgSbfK9bcfb1qgAQMSPA In-Reply-To: <30b660a20708300946t2295b031vba4b3d2af8f1165@mail.gmail.com> X-Spam-Processed: mx1.nexbyte.net, Fri, 31 Aug 2007 01:46:12 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1763f3518e=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 31 Aug 2007 01:46:12 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad 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: , Content-Type: multipart/mixed; boundary="===============0761669422==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0761669422== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07E7_01C7EB6F.AA0833F0" This is a multi-part message in MIME format. ------=_NextPart_000_07E7_01C7EB6F.AA0833F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark wrote: =20 >I disagree. I've hit many instances where the definition of an ISO term makes no sense until you've read enough of the way through the document = to understand it. Alphabetical is fine for reference *after* you've read = the document, but it is a nice to have, and not a requirement.=20 I agree, somewhat. However, I find it useful to read the Terms first = then read the document whilst trying to remember the terms that are defined - looking them up as I come across them to remind myself as to their = meaning; which by that time makes sense. It means a bit of going backwards and forwards sometimes but essentially it works in that there can be no misunderstanding as to the authors intended meaning. As Terminology is really coming to the fore within industry this is now becoming quite important.=20 =20 Reading and understanding ISO standards is an art in itself :-) =20 Best =20 Debbie PS When I first started out in Standardization it took me ages to fathom = out the meaning of Data Categories - I hadn't read the Ts and Ds ;-) I = thought it was something really obscure. =20 =20 =20 =20 _____ =20 From: Mark Davis [mailto:mark.davis@icu-project.org]=20 Sent: 30 August 2007 17:47 To: Marion Gunn Cc: LTRU Working Group Subject: Re: Introduction (was: Re: [Ltru] = draft-ietf-ltru-rfc4646bis-08) On 8/30/07, Marion Gunn wrote:=20 On 30 Aug 2007, at 16:26, scr=EDobh Mark Davis: I find the typical Terms and Definitions sections at the start of many = ISO documents actually counter-productive. The items are presented before = you have any background for what the definitions really mean, and are in no cohesive order.=20 Alphabetical order is cohesive enough for most professional users. Added = to that, even for newbies, it is predictable, logical, consistent with ISO documents in general, with which one would expect most users of this = list to be familiar.=20 I disagree. I've hit many instances where the definition of an ISO term makes no sense until you've read enough of the way through the document = to understand it. Alphabetical is fine for reference *after* you've read = the document, but it is a nice to have, and not a requirement.=20 We are not writing an ISO document, and there is no requirement to = follow its format. As you read the document, each technical term should be defined in the paragraph where it is first used. If that is not the case, then please = make specific suggestions for additions to the text.=20 Is that the case with regard to this particular document, Mark? Or - = rather than asking that question - let us assume that it is, then have its = editors simply cut and past each "first use mention" into a "Terms and = Definitions" section, so that it can be used by those used to using dictionaries and = ISO documents with the same ease as it can be ignored by those who are not.=20 No. I'm saying that if you personally, or anyone else on this list, = finds a case where a term is not clear on first usage, then you should point it = out and suggest additional text at that point.=20 I'm not, in theory, against having a glossary of collected terms at the = end of the document for reference.=20 Good. It would be a worry if you were against including in the document = a glossary of collected terms (I say this because I generally find myself = in agreement with much of the content of many of your msgs, and would not = like this to be different).=20 But I don't think it is worth the time and effort compared to getting = the "first usage" instances correct. And it might better go in a "Language = Tag Tutorial".=20 If you are proposing to compose a "Language Tag Tutorial", that would probably be useful, as well (but much more work for you to compile than = the usual "Terms and Definitions" component users of ISO standards find so = handy for ref.).=20 No. I'm saying that if someone wants to write a tutorial, and collect = terms, that's fine. Go ahead. mg Mark On 8/30/07, Marion Gunn < mgunn@egt.ie > wrote:=20 I am in total agreement with DG on this matter (as set out below in=20 her msg of today - as cited below - which msg of hers echoes the substance of one of mine of yesterday, I believe). mg On 30 Aug 2007, at 15:17, scr=EDobh Debbie Garside:=20 > ... I think to devise a Terms=20 > and Definitions section would be very useful to newbies. It would > also > cement the terminology for ease of use in other documents wishing to > reference the RFC.=20 - -=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________=20 Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=20 Mark=20 ------=_NextPart_000_07E7_01C7EB6F.AA0833F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mark wrote:
 
>I=20 disagree. I've hit many instances where the definition of an ISO term = makes no=20 sense until you've read enough of the way through the document to = understand it.=20 Alphabetical is fine for reference *after* you've read the document, but = it is a=20 nice to have, and not a requirement.
I agree, somewhat.  However, I find it = useful to=20 read the Terms first then read the document whilst trying to = remember=20 the terms that are defined - looking them up as I come across them to = remind=20 myself as to their meaning; which by that time makes sense.  It = means a bit=20 of going backwards and forwards sometimes but essentially it works in = that there=20 can be no misunderstanding as to the authors intended = meaning.  As=20 Terminology is really coming to the fore within industry this is now = becoming=20 quite important. 
 
Reading and understanding ISO standards = is an art=20 in itself :-)
 
Best
 
Debbie
PS When I first started out in = Standardization it took=20 me ages to fathom out the meaning of Data Categories - I hadn't read the = Ts and=20 Ds ;-)  I thought it was something really = obscure.
 
   
 
 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 30 August 2007=20 17:47
To: Marion Gunn
Cc: LTRU Working=20 Group
Subject: Re: Introduction (was: Re: [Ltru]=20 draft-ietf-ltru-rfc4646bis-08)


On 8/30/07, Marion=20 Gunn <mgunn@egt.ie> = wrote:

On 30 Aug 2007, at 16:26, scr=EDobh Mark Davis:

I find the typical Terms and Definitions = sections=20 at the start of many ISO documents actually counter-productive. = The items=20 are presented before you have any background for what the = definitions=20 really mean, and are in no cohesive order.

Alphabetical order is cohesive enough for most = professional users. Added to that, even for newbies, it is = predictable,=20 logical, consistent with ISO documents in general, with which one = would=20 expect most users of this list to be familiar. =

I disagree. I've hit many instances where the definition of = an ISO=20 term makes no sense until you've read enough of the way through the = document=20 to understand it. Alphabetical is fine for reference *after* you've = read the=20 document, but it is a nice to have, and not a requirement.

We = are not=20 writing an ISO document, and there is no requirement to follow its=20 format.

As you read the document, each technical = term=20 should be defined in the paragraph where it is first used. If that = is not=20 the case, then please make specific suggestions for additions to = the text.=20

Is that the case with regard to this = particular=20 document, Mark? Or - rather than asking that question -  let us = assume=20 that it is, then have its editors simply cut and past each "first = use=20 mention" into a "Terms and Definitions" section, so that it can be = used by=20 those used to using dictionaries and ISO documents with the same = ease as it=20 can be ignored by those who are not.

No. I'm saying that if you personally, or anyone else on this = list,=20 finds a case where a term is not clear on first usage, then you should = point=20 it out and suggest additional text at that point.

I'm not, in theory, against having a = glossary of=20 collected terms at the end of the document for reference. =

Good. It would be a worry if you were against=20 including in the document a glossary of collected terms (I say this = because=20 I generally find myself in agreement with much of the content of = many of=20 your msgs, and would not like this to be different).

But I don't think it is worth the time and = effort=20 compared to getting the "first usage" instances correct. And it = might=20 better go in a "Language Tag Tutorial".

If you are proposing to compose a = "Language Tag=20 Tutorial", that would probably be useful, as well  (but much = more work=20 for you to compile than the usual "Terms and Definitions" component = users of=20 ISO standards find so handy for ref.).

No. I'm saying that if someone wants to write a tutorial, and = collect=20 terms, that's fine. Go ahead.

mg



Mark

On 8/30/07, Marion=20 Gunn < mgunn@egt.ie> = wrote:
I=20 am in total agreement with DG on this matter (as set out below = in=20
her msg of today - as cited below - which msg of hers echoes = the
substance of one of mine of yesterday, I=20 believe).
mg

On 30 Aug 2007, at 15:17, scr=EDobh = Debbie Garside:=20

> ... I think to devise a Terms
> and = Definitions=20 section would be very useful to newbies.  It = would
>=20 also
> cement the terminology for ease of use in other = documents=20 wishing to
> reference the=20 RFC. 

- - 
Marion Gunn * EGTeo (Estab.1991)
27 P=E1irc an Fh=E9ithlinn, Baile an
Bh=F3thair, Co. =C1tha Cliath, =C9ire.
* mgunn@egt.ie * eamonn@egt.ie=20 = *


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



--
Mark ------=_NextPart_000_07E7_01C7EB6F.AA0833F0-- --===============0761669422== 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 --===============0761669422==-- From ltru-bounces@ietf.org Fri Aug 31 05:25: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 1IR2l9-0008SU-Nf; Fri, 31 Aug 2007 05:25:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IR2l9-0008SJ-05 for ltru-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 05:25:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR2l8-0008SA-Lf for ltru@ietf.org; Fri, 31 Aug 2007 05:25:46 -0400 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IR2l7-0005m9-Pa for ltru@ietf.org; Fri, 31 Aug 2007 05:25:46 -0400 Received: (qmail 92831 messnum 5143933 invoked from network[194.125.174.115/ts09-115.dublin.indigo.ie]); 31 Aug 2007 09:25:43 -0000 Received: from ts09-115.dublin.indigo.ie (HELO ?194.125.174.115?) (194.125.174.115) by mail17.svc.cra.dublin.eircom.net (qp 92831) with SMTP; 31 Aug 2007 09:25:43 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Message-Id: From: Marion Gunn Subject: Re: [Ltru] Re: extlang Date: Fri, 31 Aug 2007 10:25:44 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1740496001==" Errors-To: ltru-bounces@ietf.org --===============1740496001== Content-Type: multipart/alternative; boundary=Apple-Mail-1--204653051 --Apple-Mail-1--204653051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On 30 Aug 2007, at 18:32, scr=EDobh Karen_Broome@spe.sony.com: > For the record, I suspect John used this term -- in quotes =20 > indicating that this wasn't formal language -- because I had just =20 > used this term in an offline e-mail to him trying to clarify the =20 > straw poll question. Thanks, Karen. > I certainly meant nothing by it -- I was making sure that we were =20 > talking about the languages encapsulated by the macrolanguage, not =20 > the macrolanguage itself as was implied by the text. If this term =20 > has offended you, I'm sorry for my part in it. For my part, I'm sorry if I seem to sometimes get in with a criticism =20= too early (but, in this case, I felt we had already waited way too =20 long - days - for the list owners to deprecate that expression). > I'm quite sure John did not use this in the spirit you are suggesting. If he abides by what he says below, that will be good. On 30 Aug 2007, at 19:02, John Cowan: > ... > > That said, the term is indeed a poor one, and I do acknowledge the > unconscious influence of Karen's email to me. "Encompassed languages" > is what I meant and should have said. On 30 Aug 2007, at 18:32, scr=EDobh Karen_Broome@spe.sony.com: > > If m*crolanguage is an offensive term, perhaps macrolanguage is as =20 > well? This episode most certainly casts some doubt on that term, if its use =20= can so easily generate a concept we do not want to planted in the =20 mind of an innocent professional (such as yourself). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-1--204653051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 30 Aug 2007, at = 18:32, scr=EDobh Karen_Broome@spe.sony.com:

For the record, I suspect = John used this term -- in quotes indicating that this wasn't formal = language -- because I had just used this term in an offline e-mail to = him trying to clarify the straw poll question. =



Thanks, = Karen.

I certainly meant nothing by it -- I was making sure = that we were talking about the languages encapsulated by the = macrolanguage, not the macrolanguage itself as was implied by the text. = If this term has offended you, I'm sorry for my part in it. =


For my part, I'm sorry if I = seem to sometimes get in with a criticism too early (but, in this case, = I felt we had already waited way too long - days - for the list owners = to deprecate that expression).=A0

I'm quite sure John did not = use this in the spirit you are suggesting.=A0


If he abides by what he says below, that will be = good.

On 30 Aug 2007, at = 19:02, John Cowan:
...

That said, the = term is indeed a poor one, and I do acknowledge = the
unconscious influence of Karen's email to = me.=A0 "Encompassed languages"
is what I meant = and should have said.


On 30 Aug 2007, at 18:32, = scr=EDobh Karen_Broome@spe.sony.com:

If m*crolanguage is an offensive term, = perhaps macrolanguage is as well?

This episode most certainly = casts some doubt on that term, if its use can so easily generate a = concept we do not want to planted in the mind of an innocent = professional (such as yourself).
mg

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

= --Apple-Mail-1--204653051-- --===============1740496001== 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 --===============1740496001==-- From ltru-bounces@ietf.org Fri Aug 31 13:26: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 1IRAGI-0007jL-Ct; Fri, 31 Aug 2007 13:26:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IRAGG-0007j6-9o for ltru-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 13:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRAGG-0007ix-0K for ltru@ietf.org; Fri, 31 Aug 2007 13:26:24 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRAGE-0004te-N2 for ltru@ietf.org; Fri, 31 Aug 2007 13:26:23 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070831172622.WPKZ14340.mta11.adelphia.net@DGBP7M81> for ; Fri, 31 Aug 2007 13:26:22 -0400 Message-ID: <011501c7ebf4$0cc5b6a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: extlang Date: Fri, 31 Aug 2007 10:26:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: >> If m*crolanguage is an offensive term, perhaps macrolanguage is as >> well? > > This episode most certainly casts some doubt on that term, if its use > can so easily generate a concept we do not want to planted in the mind > of an innocent professional (such as yourself). Okay, we need to end this line of insinnuendo *right now*. NOBODY in this Working Group, which is chartered to provide a mechanism for tagging content in over 7,600 languages and variants, is interested in "denigrating," or insulting, or relegating to second-class status, any of those 7,600 languages. I am certain beyond question that neither Karen nor John in particular has that in mind. We would not be in this WG if that were the case. ISO 639-3 introduced a new word, "macrolanguage," for a concept such as "Chinese" which is considered a single language in some contexts and multiple languages in others. It's a useful concept, and the term is more or less arbitrary; I doubt I could come up with a better one in five minutes. The word "encompassed" has been used in ISO 639-3 to describe languages like Cantonese and Wu that are covered under the "macrolanguage" called Chinese. The term "encompassed language" doesn't flow off the tongue nearly as easily as its counterpart "macrolanguage," and might not have caught on yet, so Karen apparently used the ad-hoc term "microlanguage" in a private message and John repeated it on-list. "Micro-" is an obvious opposite of "macro-". This sort of word-forming process is common among technical-minded people, including much of the LTRU membership (I make up words every day). There is no negative connotation associated with this "micro-" prefix, least of all in the minds of people who work every day with "microcomputers" which use "microprocessors" that execute "microcode" and run software produced by a business giant called "Microsoft." We had to endure a similar accusation some time ago over the terms "primary language subtag" and "extended language subtag." No, we do not consider some languages to be "primary" and other, less fortunate languages to be "extended"; those are terms used to describe the short alphabetic identifiers that go into a language tag. The same is true for "macrolanguage" and whatever we choose to call the individual languages they stand for. Let's all get back to the business at hand and show some respect for the intentions of our fellow list members. A little less caffeine might be a good idea as well. -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 31 13:48: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 1IRAbf-00065p-44; Fri, 31 Aug 2007 13:48:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IRAbd-00064j-UC for ltru-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 13:48:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRAbd-00064b-Ib for ltru@ietf.org; Fri, 31 Aug 2007 13:48:29 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound5-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRAbc-0005dZ-Sv for ltru@ietf.org; Fri, 31 Aug 2007 13:48:29 -0400 Received: from outbound5-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-dub-R.bigfish.com (Postfix) with ESMTP id 1680F41B88C; Fri, 31 Aug 2007 17:55:39 +0000 (UTC) Received: from mail86-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound5-dub.bigfish.com (Postfix) with ESMTP id 002C2838050; Fri, 31 Aug 2007 17:55:39 +0000 (UTC) Received: from mail86-dub (localhost.localdomain [127.0.0.1]) by mail86-dub-R.bigfish.com (Postfix) with ESMTP id E4DAE16101F4; Fri, 31 Aug 2007 17:47:39 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail86-dub (MessageSwitch) id 1188582459868546_10803; Fri, 31 Aug 2007 17:47:39 +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 mail86-dub.bigfish.com (Postfix) with ESMTP id 72A3BE6007D; Fri, 31 Aug 2007 17:47:39 +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 2007083110482254-389208 ; Fri, 31 Aug 2007 10:48:22 -0700 In-Reply-To: <011501c7ebf4$0cc5b6a0$6401a8c0@DGBP7M81> To: "Doug Ewell" Subject: Re: [Ltru] Re: extlang 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: Fri, 31 Aug 2007 10:46:04 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 08/31/2007 10:46:05, Serialize complete at 08/31/2007 10:46:05, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/31/2007 10:48:22 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 08/31/2007 10:48:27 AM, Serialize complete at 08/31/2007 10:48:27 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'd also add that I'm far from innocent, but that discussion is outside of = the scope of the charter so let's get back to business. Thanks, Doug. Karen Broome "Doug Ewell" =20 08/31/2007 10:26 AM To "LTRU Working Group" cc Subject Re: [Ltru] Re: extlang Marion Gunn wrote: >> If m*crolanguage is an offensive term, perhaps macrolanguage is as=20 >> well? > > This episode most certainly casts some doubt on that term, if its use=20 > can so easily generate a concept we do not want to planted in the mind=20 > of an innocent professional (such as yourself). Okay, we need to end this line of insinnuendo *right now*. NOBODY in this Working Group, which is chartered to provide a mechanism=20 for tagging content in over 7,600 languages and variants, is interested=20 in "denigrating," or insulting, or relegating to second-class status,=20 any of those 7,600 languages. I am certain beyond question that neither=20 Karen nor John in particular has that in mind. We would not be in this=20 WG if that were the case. ISO 639-3 introduced a new word, "macrolanguage," for a concept such as=20 "Chinese" which is considered a single language in some contexts and=20 multiple languages in others. It's a useful concept, and the term is=20 more or less arbitrary; I doubt I could come up with a better one in=20 five minutes. The word "encompassed" has been used in ISO 639-3 to describe languages=20 like Cantonese and Wu that are covered under the "macrolanguage" called=20 Chinese. The term "encompassed language" doesn't flow off the tongue=20 nearly as easily as its counterpart "macrolanguage," and might not have=20 caught on yet, so Karen apparently used the ad-hoc term "microlanguage"=20 in a private message and John repeated it on-list. "Micro-" is an obvious opposite of "macro-". This sort of word-forming=20 process is common among technical-minded people, including much of the=20 LTRU membership (I make up words every day). There is no negative=20 connotation associated with this "micro-" prefix, least of all in the=20 minds of people who work every day with "microcomputers" which use=20 "microprocessors" that execute "microcode" and run software produced by=20 a business giant called "Microsoft." We had to endure a similar accusation some time ago over the terms=20 "primary language subtag" and "extended language subtag." No, we do not=20 consider some languages to be "primary" and other, less fortunate=20 languages to be "extended"; those are terms used to describe the short=20 alphabetic identifiers that go into a language tag. The same is true=20 for "macrolanguage" and whatever we choose to call the individual=20 languages they stand for. Let's all get back to the business at hand and show some respect for the=20 intentions of our fellow list members. A little less caffeine might be=20 a good idea as well. -- Doug Ewell =B7 Fullerton, California, USA =B7 RFC 4645 =B7 UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 31 14:26: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 1IRBCV-0007ZW-VE; Fri, 31 Aug 2007 14:26:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IRBCT-0007Z6-GQ for ltru-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 14:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRBCT-0007Yx-6x for ltru@ietf.org; Fri, 31 Aug 2007 14:26:33 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRBCS-0007Rf-0U for ltru@ietf.org; Fri, 31 Aug 2007 14:26:33 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070831182631.QIAL7790.mta9.adelphia.net@DGBP7M81> for ; Fri, 31 Aug 2007 14:26:31 -0400 Message-ID: <013301c7ebfc$74172bb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000f01c7e9fd$57f96bb0$6401a8c0@DGBP7M81> <072f01c7eb18$ed434620$0b00a8c0@CPQ86763045110> <46D7003F.7080202@yahoo-inc.com> Date: Fri, 31 Aug 2007 11:26:30 -0700 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.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ltru] Re: Introduction X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 1. ... This effort was chartered as a fairly minor one focused on > extlangs. As an editor, I do occasionally restructure or rewrite text > as a result of the changes we are currently working on. However, I > don't feel we should proceed, paragraph by paragraph, to alter the > document at length. i agree. I also regret the extent to which LTRU 2.0 has expanded in scope. I think it will actually be a bit ironic if we come out of LTRU 2.0 with a pair of documents to replace 4646 and 4645, and the one thing we *didn't* do is add extlangs. :-) > 3. I note that the original comment was about the term 'extlang'. > However, 'extlang' is NOT a term (although we use it as one on this > list). It has two uses in the document: > > i. It is the name of a production in the ABNF grammar. > ii. It is a subtag 'type' string. It is references very carefully > this way in all cases. > > The proper term is "extended language subtag" and it is defined in > Section 2.2.2. Note that this is the same part of the document where > the other terminology is defined. For my part, I understand that "extlang" is not the official name for this type of subtag, and didn't mean to propose defining it formally if you were talking to me. We use it all the time because it's easier to type 7 letters than 24. > 4. I suspect that a Terms and Definitions appendix will serve to make > the document longer, but will little avail readers. One thing the document does not need is to be longer. If we do add such a section, we should attempt to strip out the now-redundant inline definitions that exist throughout the document. > However, me tendency is to think... Now hold on, is that en-IE or en-scotland? Oh wait, that reminds me... -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 31 19:25: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 1IRFrO-0004Zm-BC; Fri, 31 Aug 2007 19:25:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IRFrM-0004YA-Pz for ltru-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 19:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRFrM-0004Y2-GU for ltru@ietf.org; Fri, 31 Aug 2007 19:25:04 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRFrL-0005TM-7w for ltru@ietf.org; Fri, 31 Aug 2007 19:25:04 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070831232502.TWQF9920.mta10.adelphia.net@DGBP7M81> for ; Fri, 31 Aug 2007 23:25:02 +0000 Message-ID: <01bf01c7ec26$27ef3910$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 31 Aug 2007 16:25:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Fallback has probably been over-sold. I think at least two things have been oversold. Fallback is definitely one of them. As I've said so many times, after all the effort and delay we went through to generate RFC 4647, after everything we've created that might require RFC 3066-style matching and validation engines to be modified or rewritten, we are still hooked on the idea that remove-from-right truncation is of paramount importance, and that a mechanism like extlang that might exhibit unwanted results in some RFR-truncation scenarios is thereby fatally flawed. The other thing that has been oversold is the identification of a macrolanguage with one of its encompassed languages. From reading this thread, you would think people are making a conscious decision to tag Mandarin Chinese, and only Mandarin Chinese, as "zh", and tag other flavors of Chinese as "zh-yue" or "zh-hakka" or whatever. Furthermore, you would think people are planning to make the same decision with respect to Arabic, explicitly equating "ar" with Standard Arabic and not with any other flavor, as soon as RFC 4646bis comes out with its 30-odd new Arabic subtags. I don't think this sort of conscious decision is what drives the current tagging scenario. Instead, consider the following: 1. Most (not all) of the content that is currently tagged with BCP 47 language tags tends to be written, not spoken, sung, etc. This will not necessarily be the case forever, but it is likely the case today. 2. Most written Chinese that is tagged tends to be either Mandarin Chinese, or written according to Mandarin conventions. 3. Almost all written Arabic that is tagged tends to be Standard Arabic. 4. The tags registered under RFC 3066, and grandfathered into RFC 4646 for individual Chinese languages, including Mandarin, are often considered (incorrectly) to be exceptions to the "normal" tagging syntax, and are used relatively infrequently. No such tags exist at all yet for individual Arabic variations. Given this, it is natural that in current practice "zh" tends to correspond to Mandarin and "ar" tends to correspond to Standard Arabic. That doesn't mean we should "bake" this assumption into our solution. People are not saying, "I will use plain 'zh' for Mandarin but 'zh-yue' for Cantonese." That's why "zh-cmn" was registered, to make this explicit. "zh" is *not* explicit. A lot of attention is being paid to the "fallback" scenario and the equation of a macrolanguage X with one specific flavor X1, such that the question being asked is whether all speakers of X2 and X3 and X4 can also comprehend X1, or each other. This isn't how I understand macrolanguages at all. There are contexts in which X1 and X2 and so forth are considered the same language, and others in which they are not. Tagging the unified language as "X" for the contexts where it applies, and tagging the individual languages as "X-X1", "X-X2", and so forth, where they apply, reflects this relationship and establishes that "X" is sometimes a legitimate way to think of individual language X1. An informative "Macrolanguage" field doesn't do this, because it exists only in the Registry and not in the tag. In object-oriented (OO) design, there is a concept called "is a" that I think describes the macrolanguage model well. In OO design, you have a class called "vehicle" and then you have other classes such as "car," "boat," and "airplane" that are subclasses of "vehicle." One would say that a car, boat, or airplane "is a" vehicle. That doesn't imply that any of the subclasses are completely equivalent to the superclass; you would not say that a vehicle "is a" car, and you would certainly not presume that a car is always a suitable substitute ("fallback") for any other type of vehicle, even if it is the most common, and even if people sometimes use the word "vehicle" when they specifically mean "car." *That* is what extlang "bakes into" the tag: the superclass-subclass relationship that Mandarin "is a" Chinese, and the notion that sometimes it is appropriate to think of it as "Mandarin" and sometimes as "Chinese." Randy wanted specific wording. There's too much specific to extlangs and macrolanguages to call out explicitly in OLD: and NEW: blocks, but I suppose my first choice, as I predicted before, would be to go back to what we had in draft-4646bis-06. That also means not changing the rules to prohibit adding new extlangs in the future, which Addison and even John don't agree with, so I don't really expect this to happen. My second choice, if we absolutely must jettison extlangs, would be to go all the way and not pretend to recognize the ISO 639-3 macrolanguage structure at all. That means not having a Macrolanguage field, since as we are often reminded, it is not sufficient for so-called "fallback" to determine what language to serve to an arbitrary requester in case the requested language is unavailable. If we don't expect software tools to parse and match tags intelligently instead of using Fred Flintstone RFR truncation, why would we expect them to consult a Macrolanguage field to see if there's a relationship of unspecified nature between X1 and X? My third choice would be to get rid of extlangs but keep the Macrolanguage field. I still don't agree with keeping both extlangs *and* the Macrolanguage field. John says that one would be normative and govern the structure of the tag, and the other would be informative, and he and I understand this and so does probably everyone else on this list, but I still think it would cause colossal confusion among ordinary users who have not been thinking about this stuff for years. At the very least, the new paragraph in Section 4.1 beginning "In particular" needs to be cleaned up to reflect whatever decision is made regarding extlangs. Right now it refers to "languages such as 'yue'" and falling back from "yue-Hans-CN" to "zh-Hans-CN"; these "yue" references should be "zh-yue" if we decide to keep extlangs. I'll go along with whatever decision is made, but I don't think one implementation from one of the possible language-tagging perspectives, with results characterized as "it just doesn't seem to work well," should be sufficient to reverse the tide of the past 3 years. -- Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru