From ltru-bounces@ietf.org Sun Apr 01 10:14: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 1HY0p4-00036k-5t; Sun, 01 Apr 2007 10:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY0p2-00036e-R0 for ltru@ietf.org; Sun, 01 Apr 2007 10:14:20 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound1-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY0p1-0007sb-0R for ltru@ietf.org; Sun, 01 Apr 2007 10:14:20 -0400 Received: from outbound1-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-sin-R.bigfish.com (Postfix) with ESMTP id E74301418993 for ; Sun, 1 Apr 2007 14:14:14 +0000 (UTC) Received: from mail46-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound1-sin.bigfish.com (Postfix) with ESMTP id CFF841C90086 for ; Sun, 1 Apr 2007 14:14:14 +0000 (UTC) Received: from mail46-sin (localhost.localdomain [127.0.0.1]) by mail46-sin-R.bigfish.com (Postfix) with ESMTP id 88906CC84B0 for ; Sun, 1 Apr 2007 14:14:14 +0000 (UTC) X-BigFish: P Received: by mail46-sin (MessageSwitch) id 1175436854512086_22170; Sun, 1 Apr 2007 14:14:14 +0000 (UCT) Received: from lonsmime02.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail46-sin.bigfish.com (Postfix) with ESMTP id 296BF1748070 for ; Sun, 1 Apr 2007 14:14:12 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Sun, 1 Apr 2007 14:14:11 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JFT007R1OVNFA@eupig2.dtc.lon.ime.reuters.com>; Sun, 01 Apr 2007 14:14:11 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sun, 01 Apr 2007 15:14:11 +0100 Date: Sun, 01 Apr 2007 15:14:09 +0100 From: Misha Wolf In-reply-to: <004a01c77465$db00a540$6401a8c0@rishida> To: Richard Ishida , WWW International , LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: New web app: Searching for language subtags Thread-Index: Acd0ZcOg+/byMnEKR5CxVtgxAdLOqQAAVaQw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 01 Apr 2007 14:14:11.0036 (UTC) FILETIME=[04DCF9C0:01C77468] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Ltru] RE: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Richard, Having spent a few minutes playing with this, it seems to = be both useful and fun. My one concern is that people who haven't been initiated = into the arcane mysteries of BCP 47, might misunderstand = the meaning of a heading like "redundant" in response to = a search for "Chinese". It needs to be made clear to = people that this is a tool for examining the registry, = *NOT* a tool for finding appropriate language tags. If = it is meant to be used for the latter purpose, then some = changes are very much needed :-) Regards, Misha = -----Original Message----- From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida Sent: 01 April 2007 14:59 To: 'WWW International' Subject: New web app: Searching for language subtags You may find this of interest. It's purely a personal project. http://people.w3.org/rishida/utils/subtags/ http://people.w3.org/rishida/blog/?p=3D90 says: This tool allows you to search for tags that have, say, 'french' in their description (there are currently 11), or to find out what that mysterious 'ch' tag stands for (there are 2 possibilities). Or you can simply list all current language tags, or script tags, or variants, etc. For months I've been wanting to write a small, Web-based tool for finding things in the subtag registry without having to work on the (for many people, intimidating) raw text file on the IANA site. Tom Gruner created an initial tool for pretty printing the IANA list, which handled enough of the basics to allow me to use the little time I have these days to add the search functionality on top. If you have JavaScript running, you are shown just the tags and descriptions initially, but by clicking on those you can reveal all additional information in the registry for a given tag. I also highlight tags that are deprecated, so you can see that straight away. (PS: Some final tweaks to the code will come when I have a spare moment for things like making the expanding list more accessible, etc.) RI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) = http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ = This email was sent to you by Reuters, the global news and information comp= any. = To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, = except where the sender specifically states them to be the views of Reuters= Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters= Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South = Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 01 12:41: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 1HY37Q-0007KK-1q; Sun, 01 Apr 2007 12:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY37O-0007GM-FX for ltru@ietf.org; Sun, 01 Apr 2007 12:41:26 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY37N-0004LN-0E for ltru@ietf.org; Sun, 01 Apr 2007 12:41:26 -0400 Received: from [10.72.72.202] (snvvpn1-10-72-72-c202.corp.yahoo.com [10.72.72.202]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l31GevL0047958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 09:41:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=YgARjYpwN2OlN4WRL1C7udgrSK8wLLvImTg9sCq6oKX3bYgmHifd7uSLUeMPesA6 Message-ID: <460FE096.8020607@yahoo-inc.com> Date: Sun, 01 Apr 2007 09:40:54 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Misha Wolf Subject: Re: [Ltru] RE: New web app: Searching for language subtags 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: 944ecb6e61f753561f559a497458fb4f Cc: LTRU Working Group , WWW International X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 This is quite a nice tool. I note: I think a bit more care should be used with the terms "tag" and "subtag". The use of the word "tag" in the tool is misleading, since it implies the tools searches for tags. In fact, the tool can only look at the grandfathered/redundant tags. It's really a subtag tool. Addison Misha Wolf wrote: > Hi Richard, > > Having spent a few minutes playing with this, it seems to > be both useful and fun. > > My one concern is that people who haven't been initiated > into the arcane mysteries of BCP 47, might misunderstand > the meaning of a heading like "redundant" in response to > a search for "Chinese". It needs to be made clear to > people that this is a tool for examining the registry, > *NOT* a tool for finding appropriate language tags. If > it is meant to be used for the latter purpose, then some > changes are very much needed :-) > > Regards, > Misha > > > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > Sent: 01 April 2007 14:59 > To: 'WWW International' > Subject: New web app: Searching for language subtags > > > You may find this of interest. It's purely a personal project. > > http://people.w3.org/rishida/utils/subtags/ > > > http://people.w3.org/rishida/blog/?p=90 says: > > This tool allows you to search for tags that have, say, 'french' in > their description (there are currently 11), or to find out what that > mysterious 'ch' tag stands for (there are 2 possibilities). Or you can > simply list all current language tags, or script tags, or variants, etc. > > For months I've been wanting to write a small, Web-based tool for > finding things in the subtag registry without having to work on the (for > many people, intimidating) raw text file on the IANA site. > > Tom Gruner created an initial tool for pretty printing the IANA list, > which handled enough of the basics to allow me to use the little time I > have these days to add the search functionality on top. > > If you have JavaScript running, you are shown just the tags and > descriptions initially, but by clicking on those you can reveal all > additional information in the registry for a given tag. I also highlight > tags that are deprecated, so you can see that straight away. > > (PS: Some final tweaks to the code will come when I have a spare moment > for things like making the expanding list more accessible, etc.) > > RI > > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > > This email was sent to you by Reuters, the global news and information company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender, > except where the sender specifically states them to be the views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom > Registered No: 3296375 > Registered in England and Wales > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 05:49: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 1HYJ97-0001ik-Ra; Mon, 02 Apr 2007 05:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJ96-0001if-3a for ltru@ietf.org; Mon, 02 Apr 2007 05:48:16 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJ93-000071-Om for ltru@ietf.org; Mon, 02 Apr 2007 05:48:16 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5B4A91C011C; Mon, 2 Apr 2007 11:48:03 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 56BDD1C008D; Mon, 2 Apr 2007 11:48:02 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4858A58ED21; Mon, 2 Apr 2007 11:48:02 +0200 (CEST) Date: Mon, 2 Apr 2007 11:48:02 +0200 From: Stephane Bortzmeyer To: WWW International , LTRU Working Group Message-ID: <20070402094802.GA10226@nic.fr> References: <004a01c77465$db00a540$6401a8c0@rishida> 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Apr 01, 2007 at 03:14:09PM +0100, Misha Wolf wrote a message of 88 lines which said: > My one concern is that people who haven't been initiated into the > arcane mysteries of BCP 47, might misunderstand Yes, there are funny things for instance: "french" gives you three geographic regions, not one of them being France ("fr") Knowing the registry, I can understand i, but ordinary users may deserve more warnings. Bug report: multiline comments are not properly handled, only the first line is displayed. See variant "1694acad" or region "gb" for an example. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 09:35: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 1HYMgo-0003S4-RS; Mon, 02 Apr 2007 09:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMgo-0003OH-2D for ltru@ietf.org; Mon, 02 Apr 2007 09:35:18 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMgm-0005kl-KU for ltru@ietf.org; Mon, 02 Apr 2007 09:35:18 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 949194EEFD; Mon, 2 Apr 2007 09:35:15 -0400 (EDT) From: "Richard Ishida" To: "'WWW International'" , "'LTRU Working Group'" References: <931823.98314.qm@web51611.mail.re2.yahoo.com> Date: Mon, 2 Apr 2007 14:35:44 +0100 Message-ID: <00de01c7752b$d0fc55f0$6401a8c0@rishida> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1JuXrREoysJTGQ/aexIF2wzl5ggAApAEg In-Reply-To: <931823.98314.qm@web51611.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [Ltru] RE: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have just uploaded a new version. It now allows you to enter a hyphen-separated string of subtags in the search field and reports what it finds in the registry. See also the new notes on the right hand side. RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Najib TOUNSI [mailto:tounsin@yahoo.com] > Sent: 02 April 2007 14:00 > To: Richard Ishida; WWW International; LTRU Working Group > Subject: RE: New web app: Searching for language subtags > > Hi all, > > --- Misha Wolf wrote: > > > > > Hi Richard, > > > > Having spent a few minutes playing with this, it seems to be both > > useful and fun. > +1 > > > > My one concern is that people who haven't been initiated into the > > arcane mysteries of BCP 47, might misunderstand the meaning of a > > heading like "redundant" in response to a search for "Chinese". > > "people who haven't been initiated into the arcane mysteries > of BCP 47", might even not understand what 'redundant', > 'Grandfathered' and other 'variant' mean or what they are for. > > http://en.wikipedia.org/wiki/BCP_47 just refers to > http://www.w3.org/International/articles/language-tags/Overview.en.php > (which defines what variant means, but not all other key > vocabularies) http://www.iana.org/assignments/language-subtag-registry > (which is a list of language subtags.) > > Najib > > > It needs to be made clear > > to > > people that this is a tool for examining the registry, > > *NOT* a tool for finding appropriate language tags. > > If > > it is meant to be used for the latter purpose, then some > changes are > > very much needed :-) > > > > Regards, > > Misha > > > > > > -----Original Message----- > > From: www-international-request@w3.org > > [mailto:www-international-request@w3.org] On Behalf Of > Richard Ishida > > Sent: 01 April 2007 14:59 > > To: 'WWW International' > > Subject: New web app: Searching for language subtags > > > > > > You may find this of interest. It's purely a personal project. > > > > http://people.w3.org/rishida/utils/subtags/ > > > > > > http://people.w3.org/rishida/blog/?p=90 says: > > > > This tool allows you to search for tags that have, say, 'french' in > > their description (there are currently 11), or to find out > what that > > mysterious 'ch' tag stands for (there are 2 possibilities). > Or you can > > simply list all current language tags, or script tags, or variants, > > etc. > > > > For months I've been wanting to write a small, Web-based tool for > > finding things in the subtag registry without having to work on the > > (for many people, intimidating) raw text file on the IANA site. > > > > Tom Gruner created an initial tool for pretty printing the > IANA list, > > which handled enough of the basics to allow me to use the > little time > > I have these days to add the search functionality on top. > > > > If you have JavaScript running, you are shown just the tags and > > descriptions initially, but by clicking on those you can reveal all > > additional information in the registry for a given tag. I also > > highlight tags that are deprecated, so you can see that > straight away. > > > > (PS: Some final tweaks to the code will come when I have a spare > > moment for things like making the expanding list more accessible, > > etc.) > > > > RI > > > > > > ============ > > Richard Ishida > > Internationalization Lead > > W3C (World Wide Web Consortium) > > > > http://www.w3.org/People/Ishida/ > > http://www.w3.org/International/ > > http://people.w3.org/rishida/blog/ > > http://www.flickr.com/photos/ishida/ > > > > > > > > > > > > This email was sent to you by Reuters, the global news and > information > > company. > > To find out more about Reuters visit > > www.about.reuters.com > > > > Any views expressed in this message are those of the individual > > sender, except where the sender specifically states them to be the > > views of Reuters Limited. > > > > Reuters Limited is part of the Reuters Group of companies, of which > > Reuters Group PLC is the ultimate parent company. > > Reuters Group PLC - Registered office address: The Reuters > Building, > > South Colonnade, Canary Wharf, London E14 5EP, United Kingdom > > Registered No: 3296375 Registered in England and Wales > > > > > > > > > > > > > ______________________________________________________________ > ______________________ > Food fight? Enjoy some healthy debate > in the Yahoo! Answers Food & Drink Q&A. > http://answers.yahoo.com/dir/?link=list&sid=396545367 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 09:36: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 1HYMiF-0004Xt-Ri; Mon, 02 Apr 2007 09:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMiF-0004Xo-0j for ltru@ietf.org; Mon, 02 Apr 2007 09:36:47 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMiD-0005wk-Ja for ltru@ietf.org; Mon, 02 Apr 2007 09:36:47 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 7CC094EEFD; Mon, 2 Apr 2007 09:36:44 -0400 (EDT) From: "Richard Ishida" To: "'Addison Phillips'" References: <460FE096.8020607@yahoo-inc.com> Subject: RE: [Ltru] RE: New web app: Searching for language subtags Date: Mon, 2 Apr 2007 14:37:13 +0100 Message-ID: <00df01c7752c$06170050$6401a8c0@rishida> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd0fJp9ywaZZXziQU6/s1VuFuo3kgArzyEw In-Reply-To: <460FE096.8020607@yahoo-inc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 'LTRU Working Group' , 'WWW International' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Addison, I tried to clarify uses of tag and subtag properly, and added the = ability to look at tags too. RI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) =20 http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ =20 =20 > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com]=20 > Sent: 01 April 2007 17:41 > To: Misha Wolf > Cc: Richard Ishida; WWW International; LTRU Working Group > Subject: Re: [Ltru] RE: New web app: Searching for language subtags >=20 > +1 >=20 > This is quite a nice tool. >=20 > I note: I think a bit more care should be used with the terms=20 > "tag" and "subtag". The use of the word "tag" in the tool is=20 > misleading, since it implies the tools searches for tags. In=20 > fact, the tool can only look at the grandfathered/redundant=20 > tags. It's really a subtag tool. >=20 > Addison >=20 > Misha Wolf wrote: > > Hi Richard, > >=20 > > Having spent a few minutes playing with this, it seems to be both=20 > > useful and fun. > >=20 > > My one concern is that people who haven't been initiated into the=20 > > arcane mysteries of BCP 47, might misunderstand the meaning of a=20 > > heading like "redundant" in response to a search for "Chinese". It=20 > > needs to be made clear to people that this is a tool for=20 > examining the=20 > > registry, > > *NOT* a tool for finding appropriate language tags. If it=20 > is meant to=20 > > be used for the latter purpose, then some changes are very=20 > much needed=20 > > :-) > >=20 > > Regards, > > Misha > > =20 > >=20 > > -----Original Message----- > > From: www-international-request@w3.org=20 > > [mailto:www-international-request@w3.org] On Behalf Of=20 > Richard Ishida > > Sent: 01 April 2007 14:59 > > To: 'WWW International' > > Subject: New web app: Searching for language subtags > >=20 > >=20 > > You may find this of interest. It's purely a personal project. > >=20 > > http://people.w3.org/rishida/utils/subtags/ > >=20 > >=20 > > http://people.w3.org/rishida/blog/?p=3D90 says: > >=20 > > This tool allows you to search for tags that have, say, 'french' in=20 > > their description (there are currently 11), or to find out=20 > what that=20 > > mysterious 'ch' tag stands for (there are 2 possibilities).=20 > Or you can=20 > > simply list all current language tags, or script tags, or=20 > variants, etc. > >=20 > > For months I've been wanting to write a small, Web-based tool for=20 > > finding things in the subtag registry without having to work on the=20 > > (for many people, intimidating) raw text file on the IANA site. > >=20 > > Tom Gruner created an initial tool for pretty printing the=20 > IANA list,=20 > > which handled enough of the basics to allow me to use the=20 > little time=20 > > I have these days to add the search functionality on top. > >=20 > > If you have JavaScript running, you are shown just the tags and=20 > > descriptions initially, but by clicking on those you can reveal all=20 > > additional information in the registry for a given tag. I also=20 > > highlight tags that are deprecated, so you can see that=20 > straight away. > >=20 > > (PS: Some final tweaks to the code will come when I have a spare=20 > > moment for things like making the expanding list more accessible,=20 > > etc.) > >=20 > > RI > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Richard Ishida > > Internationalization Lead > > W3C (World Wide Web Consortium) > > =20 > > http://www.w3.org/People/Ishida/ > > http://www.w3.org/International/ > > http://people.w3.org/rishida/blog/ > > http://www.flickr.com/photos/ishida/ > > =20 > >=20 > >=20 > >=20 > >=20 > > This email was sent to you by Reuters, the global news and=20 > information company.=20 > > To find out more about Reuters visit www.about.reuters.com > >=20 > > Any views expressed in this message are those of the individual=20 > > sender, except where the sender specifically states them to=20 > be the views of Reuters Limited. > >=20 > > Reuters Limited is part of the Reuters Group of companies,=20 > of which Reuters Group PLC is the ultimate parent company. > > Reuters Group PLC - Registered office address: The Reuters=20 > Building,=20 > > South Colonnade, Canary Wharf, London E14 5EP, United Kingdom=20 > > Registered No: 3296375 Registered in England and Wales > >=20 > >=20 > >=20 > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. >=20 > Internationalization is an architecture. > It is not a feature. >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 09:46: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 1HYMrS-0000Tp-8M; Mon, 02 Apr 2007 09:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMrQ-0000Th-TO for ltru@ietf.org; Mon, 02 Apr 2007 09:46:16 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMrP-00085s-DW for ltru@ietf.org; Mon, 02 Apr 2007 09:46:16 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6F4A64EFCE; Mon, 2 Apr 2007 09:46:14 -0400 (EDT) From: "Richard Ishida" To: "'Stephane Bortzmeyer'" References: <004a01c77465$db00a540$6401a8c0@rishida> <20070402094802.GA10226@nic.fr> Subject: RE: [Ltru] Re: New web app: Searching for language subtags Date: Mon, 2 Apr 2007 14:46:42 +0100 Message-ID: <00e301c7752d$59ceed60$6401a8c0@rishida> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1DChUkWgKM1NDRX20gPccZNgRfwAH97LA In-Reply-To: <20070402094802.GA10226@nic.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'WWW International' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Stephane, > "french" gives you three geographic regions, not one of them > being France ("fr") > > Knowing the registry, I can understand i, but ordinary users > may deserve more warnings. This is an issue for the registry (if it is an issue) since people will look for things there in the same way as they do using this form. The only other way to find FR for France would be to read the registry, and I don't think people will thank you for suggesting that (especially if they are looking for say a language that begins with 'w') ;-) As it happens, I'm not sure it's an issue. I think that if you are looking for a country code you'd search on France, not French. I think that whats happening here is rather that you are getting some regions when you search for a language - which, for me, is not a big deal either. > Bug report: multiline comments are not properly handled, only > the first line is displayed. See variant "1694acad" or region > "gb" for an example. Yes, thanks. I was aware, but have not had time to fix it yet. Will do so asap. RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: 02 April 2007 10:48 > To: WWW International; LTRU Working Group > Subject: [Ltru] Re: New web app: Searching for language subtags > > On Sun, Apr 01, 2007 at 03:14:09PM +0100, Misha Wolf > wrote a message of 88 lines which said: > > > My one concern is that people who haven't been initiated into the > > arcane mysteries of BCP 47, might misunderstand > > Yes, there are funny things for instance: > > "french" gives you three geographic regions, not one of them > being France ("fr") > > Knowing the registry, I can understand i, but ordinary users > may deserve more warnings. > > Bug report: multiline comments are not properly handled, only > the first line is displayed. See variant "1694acad" or region > "gb" for an example. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 09:53: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 1HYMyg-00086m-Ln; Mon, 02 Apr 2007 09:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMyf-0007v8-1B for ltru@ietf.org; Mon, 02 Apr 2007 09:53:45 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMyd-0001dj-Li for ltru@ietf.org; Mon, 02 Apr 2007 09:53:45 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8797B4EFD2; Mon, 2 Apr 2007 09:53:42 -0400 (EDT) From: "Richard Ishida" To: "'Misha Wolf'" References: <004a01c77465$db00a540$6401a8c0@rishida> Date: Mon, 2 Apr 2007 14:54:11 +0100 Message-ID: <00e401c7752e$64e96030$6401a8c0@rishida> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd0ZcOg+/byMnEKR5CxVtgxAdLOqQAAVaQwADG8vxA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: 'LTRU Working Group' , 'WWW International' Subject: [Ltru] RE: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hmm. People who haven't been initiated into the arcane mysteries of BCP 47 still have to use the registry to find subtags. If there are things they need to understand, we'd better help them there. Note that they no longer see redundant tags when searching for Chinese with my tool, and that I included a short explanation of redundant in the side notes. I hope that will help. RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Misha Wolf [mailto:Misha.Wolf@reuters.com] > Sent: 01 April 2007 15:14 > To: Richard Ishida; WWW International; LTRU Working Group > Subject: RE: New web app: Searching for language subtags > > Hi Richard, > > Having spent a few minutes playing with this, it seems to be > both useful and fun. > > My one concern is that people who haven't been initiated into > the arcane mysteries of BCP 47, might misunderstand the > meaning of a heading like "redundant" in response to a search > for "Chinese". It needs to be made clear to people that this > is a tool for examining the registry, > *NOT* a tool for finding appropriate language tags. If it is > meant to be used for the latter purpose, then some changes > are very much needed :-) > > Regards, > Misha > > > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > Sent: 01 April 2007 14:59 > To: 'WWW International' > Subject: New web app: Searching for language subtags > > > You may find this of interest. It's purely a personal project. > > http://people.w3.org/rishida/utils/subtags/ > > > http://people.w3.org/rishida/blog/?p=90 says: > > This tool allows you to search for tags that have, say, > 'french' in their description (there are currently 11), or to > find out what that mysterious 'ch' tag stands for (there are > 2 possibilities). Or you can simply list all current language > tags, or script tags, or variants, etc. > > For months I've been wanting to write a small, Web-based tool > for finding things in the subtag registry without having to > work on the (for many people, intimidating) raw text file on > the IANA site. > > Tom Gruner created an initial tool for pretty printing the > IANA list, which handled enough of the basics to allow me to > use the little time I have these days to add the search > functionality on top. > > If you have JavaScript running, you are shown just the tags > and descriptions initially, but by clicking on those you can > reveal all additional information in the registry for a given > tag. I also highlight tags that are deprecated, so you can > see that straight away. > > (PS: Some final tweaks to the code will come when I have a > spare moment for things like making the expanding list more > accessible, etc.) > > RI > > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > > This email was sent to you by Reuters, the global news and > information company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the > individual sender, except where the sender specifically > states them to be the views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of > which Reuters Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters > Building, South Colonnade, Canary Wharf, London E14 5EP, > United Kingdom Registered No: 3296375 Registered in England and Wales > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 02 14:15: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 1HYR3l-00015b-OT; Mon, 02 Apr 2007 14:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR3k-00015V-9i for ltru@ietf.org; Mon, 02 Apr 2007 14:15:16 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR3i-0002uY-Jz for ltru@ietf.org; Mon, 02 Apr 2007 14:15:16 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1488070wri for ; Mon, 02 Apr 2007 11:15: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=nGymBc2bRt0+lPmaBfWzBAHihOVA07MjCSw9i6HtYKmeliuVMg5dKV5G/ESPQHlps+Glu0jpyferHZOXt1syQFrbYaXMtF9QUBhuwsxcyuTCpAEqFl39UJ9U8/wfTho+go3AD45JnfWR4SmNWmggVoRMadWNMGTN4Oe6uv3hn68= 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=AZw/FOh4RFMQw4zhMNqP6ujifuvfCbpCb+AiAOdU0nRrBl5JXGZmTTFr/D/mmsFnlTRAcPREKLsewI4yPS0/14h+15mTO1U4Ol6ByH8DWq+LL1evWk87YEGs/yd/A77oVdVGNHiYgpIgviBak5sBtAfZgq3pA8trM++rwF2rUYg= Received: by 10.114.148.1 with SMTP id v1mr1905168wad.1175537713221; Mon, 02 Apr 2007 11:15:13 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Mon, 2 Apr 2007 11:15:13 -0700 (PDT) Message-ID: <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> Date: Mon, 2 Apr 2007 11:15:13 -0700 From: "Mark Davis" To: "Richard Ishida" Subject: Re: [Ltru] RE: New web app: Searching for language subtags In-Reply-To: <00e401c7752e$64e96030$6401a8c0@rishida> MIME-Version: 1.0 References: <004a01c77465$db00a540$6401a8c0@rishida> <00e401c7752e$64e96030$6401a8c0@rishida> X-Google-Sender-Auth: 602b7e61810341be X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: WWW International , Misha Wolf , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054408463==" Errors-To: ltru-bounces@ietf.org --===============0054408463== Content-Type: multipart/alternative; boundary="----=_Part_136546_18212104.1175537713164" ------=_Part_136546_18212104.1175537713164 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a couple of usability suggestions. Example. Click on Regions, put in "France" in *Search for: *and click *Show Result*. You get unexpected outcome. It isn't clear that the push button only affects what the radio button says. And even after you know this, it's clumsy, since you always have to switch the radio button, then hit the push button. Rather than the current interface, it would be faster and less confusing to have pushbuttons for all of what you have as radio buttons, and remove "Show Results". And retitle Descriptions and Subtags as "Search Descriptions" and "Search Subtags". Subtags isn't quite right either, since I can put in whole language tags like "ar-Arab". So I'd suggest separating that as a separate button "Search Tags". You don't test for invalid whole tags right now, so "Arab-en". You document that, but it would be easy to fix. I have a regex that tests validity and divides up the language tag into the pieces, so you could use that if you want. Mark ** On 4/2/07, Richard Ishida wrote: > > Hmm. People who haven't been initiated into the arcane mysteries of BCP 47 > still have to use the registry to find subtags. If there are things they > need to understand, we'd better help them there. Note that they no longer > see redundant tags when searching for Chinese with my tool, and that I > included a short explanation of redundant in the side notes. I hope that > will help. > > RI > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > -----Original Message----- > > From: Misha Wolf [mailto:Misha.Wolf@reuters.com] > > Sent: 01 April 2007 15:14 > > To: Richard Ishida; WWW International; LTRU Working Group > > Subject: RE: New web app: Searching for language subtags > > > > Hi Richard, > > > > Having spent a few minutes playing with this, it seems to be > > both useful and fun. > > > > My one concern is that people who haven't been initiated into > > the arcane mysteries of BCP 47, might misunderstand the > > meaning of a heading like "redundant" in response to a search > > for "Chinese". It needs to be made clear to people that this > > is a tool for examining the registry, > > *NOT* a tool for finding appropriate language tags. If it is > > meant to be used for the latter purpose, then some changes > > are very much needed :-) > > > > Regards, > > Misha > > > > > > -----Original Message----- > > From: www-international-request@w3.org > > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > > Sent: 01 April 2007 14:59 > > To: 'WWW International' > > Subject: New web app: Searching for language subtags > > > > > > You may find this of interest. It's purely a personal project. > > > > http://people.w3.org/rishida/utils/subtags/ > > > > > > http://people.w3.org/rishida/blog/?p=90 says: > > > > This tool allows you to search for tags that have, say, > > 'french' in their description (there are currently 11), or to > > find out what that mysterious 'ch' tag stands for (there are > > 2 possibilities). Or you can simply list all current language > > tags, or script tags, or variants, etc. > > > > For months I've been wanting to write a small, Web-based tool > > for finding things in the subtag registry without having to > > work on the (for many people, intimidating) raw text file on > > the IANA site. > > > > Tom Gruner created an initial tool for pretty printing the > > IANA list, which handled enough of the basics to allow me to > > use the little time I have these days to add the search > > functionality on top. > > > > If you have JavaScript running, you are shown just the tags > > and descriptions initially, but by clicking on those you can > > reveal all additional information in the registry for a given > > tag. I also highlight tags that are deprecated, so you can > > see that straight away. > > > > (PS: Some final tweaks to the code will come when I have a > > spare moment for things like making the expanding list more > > accessible, etc.) > > > > RI > > > > > > ============ > > Richard Ishida > > Internationalization Lead > > W3C (World Wide Web Consortium) > > > > http://www.w3.org/People/Ishida/ > > http://www.w3.org/International/ > > http://people.w3.org/rishida/blog/ > > http://www.flickr.com/photos/ishida/ > > > > > > > > > > > > This email was sent to you by Reuters, the global news and > > information company. > > To find out more about Reuters visit www.about.reuters.com > > > > Any views expressed in this message are those of the > > individual sender, except where the sender specifically > > states them to be the views of Reuters Limited. > > > > Reuters Limited is part of the Reuters Group of companies, of > > which Reuters Group PLC is the ultimate parent company. > > Reuters Group PLC - Registered office address: The Reuters > > Building, South Colonnade, Canary Wharf, London E14 5EP, > > United Kingdom Registered No: 3296375 Registered in England and Wales > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_136546_18212104.1175537713164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a couple of usability suggestions.

Example. Click on Regions, put in "France" in Search for: and click Show Result. You get unexpected outcome. It isn't clear that the push button only affects what the radio button says. And even after you know this, it's clumsy, since you always have to switch the radio button, then hit the push button.

Rather than the current interface, it would be faster and less confusing to have pushbuttons for all of what you have as radio buttons, and remove "Show Results". And retitle Descriptions and Subtags as "Search Descriptions" and "Search Subtags".

Subtags isn't quite right either, since I can put in whole language tags like "ar-Arab". So I'd suggest separating that as a separate button "Search Tags". You don't test for invalid whole tags right now, so "Arab-en". You document that, but it would be easy to fix. I have a regex that tests validity and divides up the language tag into the pieces, so you could use that if you want.

Mark

On 4/2/07, Richard Ishida <ishida@w3.org> wrote:
Hmm. People who haven't been initiated into the arcane mysteries of BCP 47
still have to use the registry to find subtags. If there are things they
need to understand, we'd better help them there.  Note that they no longer
see redundant tags when searching for Chinese with my tool, and that I
included a short explanation of redundant in the side notes.  I hope that
will help.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/



> -----Original Message-----
> From: Misha Wolf [mailto: Misha.Wolf@reuters.com]
> Sent: 01 April 2007 15:14
> To: Richard Ishida; WWW International; LTRU Working Group
> Subject: RE: New web app: Searching for language subtags
>
> Hi Richard,
>
> Having spent a few minutes playing with this, it seems to be
> both useful and fun.
>
> My one concern is that people who haven't been initiated into
> the arcane mysteries of BCP 47, might misunderstand the
> meaning of a heading like "redundant" in response to a search
> for "Chinese".  It needs to be made clear to people that this
> is a tool for examining the registry,
> *NOT* a tool for finding appropriate language tags.  If it is
> meant to be used for the latter purpose, then some changes
> are very much needed :-)
>
> Regards,
> Misha
>
>
> -----Original Message-----
> From: www-international-request@w3.org
> [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida
> Sent: 01 April 2007 14:59
> To: 'WWW International'
> Subject: New web app: Searching for language subtags
>
>
> You may find this of interest.  It's purely a personal project.
>
> http://people.w3.org/rishida/utils/subtags/
>
>
> http://people.w3.org/rishida/blog/?p=90 says:
>
> This tool allows you to search for tags that have, say,
> 'french' in their description (there are currently 11), or to
> find out what that mysterious 'ch' tag stands for (there are
> 2 possibilities). Or you can simply list all current language
> tags, or script tags, or variants, etc.
>
> For months I've been wanting to write a small, Web-based tool
> for finding things in the subtag registry without having to
> work on the (for many people, intimidating) raw text file on
> the IANA site.
>
> Tom Gruner created an initial tool for pretty printing the
> IANA list, which handled enough of the basics to allow me to
> use the little time I have these days to add the search
> functionality on top.
>
> If you have JavaScript running, you are shown just the tags
> and descriptions initially, but by clicking on those you can
> reveal all additional information in the registry for a given
> tag. I also highlight tags that are deprecated, so you can
> see that straight away.
>
> (PS: Some final tweaks to the code will come when I have a
> spare moment for things like making the expanding list more
> accessible, etc.)
>
> RI
>
>
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
>
> http://www.w3.org/People/Ishida/
> http://www.w3.org/International/
> http://people.w3.org/rishida/blog/
> http://www.flickr.com/photos/ishida/
>
>
>
>
>
> This email was sent to you by Reuters, the global news and
> information company.
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the
> individual sender, except where the sender specifically
> states them to be the views of Reuters Limited.
>
> Reuters Limited is part of the Reuters Group of companies, of
> which Reuters Group PLC is the ultimate parent company.
> Reuters Group PLC - Registered office address: The Reuters
> Building, South Colonnade, Canary Wharf, London E14 5EP,
> United Kingdom Registered No: 3296375 Registered in England and Wales
>
>


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



--
Mark ------=_Part_136546_18212104.1175537713164-- --===============0054408463== 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 --===============0054408463==-- From ltru-bounces@ietf.org Mon Apr 02 14:55: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 1HYRgY-0005ct-Qt; Mon, 02 Apr 2007 14:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRgX-0005ci-Je for ltru@ietf.org; Mon, 02 Apr 2007 14:55:21 -0400 Received: from bay0-omc3-s22.bay0.hotmail.com ([65.54.246.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRgV-0005PO-Vq for ltru@ietf.org; Mon, 02 Apr 2007 14:55:21 -0400 Received: from hotmail.com ([65.54.169.38]) by bay0-omc3-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 2 Apr 2007 11:55:19 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Apr 2007 11:55:19 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Mon, 02 Apr 2007 18:55:15 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> From: "CE Whitehead" To: mark.davis@icu-project.org, ishida@w3.org Bcc: Subject: Re: [Ltru] RE: New web app: Searching for language subtags Date: Mon, 02 Apr 2007 14:55:15 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Apr 2007 18:55:19.0247 (UTC) FILETIME=[758375F0:01C77558] X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: www-international@w3.org, 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 Hi, thanks it seems you are right Mark one has to put in a code like fr or something and then choose descriptions or subtags that's the only way to use the text box The text box does not work for the radio buttons; it would be nice to search for a language name (if there were consistent language names for all languages!) and get language, variant, what have you subtags. >I have a couple of usability suggestions. > >Example. Click on Regions, put in "France" in *Search for: *and click *Show >Result*. You get unexpected outcome. It isn't clear that the push button >only affects what the radio button says. And even after you know this, it's >clumsy, since you always have to switch the radio button, then hit the push >button. > >Rather than the current interface, it would be faster and less confusing to >have pushbuttons for all of what you have as radio buttons, and remove >"Show >Results". And retitle Descriptions and Subtags as "Search Descriptions" and >"Search Subtags". > >Subtags isn't quite right either, since I can put in whole language tags >like "ar-Arab". So I'd suggest separating that as a separate button "Search >Tags". You don't test for invalid whole tags right now, so "Arab-en". You >document that, but it would be easy to fix. I have a regex that tests >validity and divides up the language tag into the pieces, so you could use >that if you want. > >Mark >** >On 4/2/07, Richard Ishida wrote: >> >>Hmm. People who haven't been initiated into the arcane mysteries of BCP 47 >>still have to use the registry to find subtags. If there are things they >>need to understand, we'd better help them there. Note that they no longer >>see redundant tags when searching for Chinese with my tool, and that I >>included a short explanation of redundant in the side notes. I hope that >>will help. >> >>RI >> >>============ >>Richard Ishida >>Internationalization Lead >>W3C (World Wide Web Consortium) >> >>http://www.w3.org/People/Ishida/ >>http://www.w3.org/International/ >>http://people.w3.org/rishida/blog/ >>http://www.flickr.com/photos/ishida/ >> >> >> >> > -----Original Message----- >> > From: Misha Wolf [mailto:Misha.Wolf@reuters.com] >> > Sent: 01 April 2007 15:14 >> > To: Richard Ishida; WWW International; LTRU Working Group >> > Subject: RE: New web app: Searching for language subtags >> > >> > Hi Richard, >> > >> > Having spent a few minutes playing with this, it seems to be >> > both useful and fun. >> > >> > My one concern is that people who haven't been initiated into >> > the arcane mysteries of BCP 47, might misunderstand the >> > meaning of a heading like "redundant" in response to a search >> > for "Chinese". It needs to be made clear to people that this >> > is a tool for examining the registry, >> > *NOT* a tool for finding appropriate language tags. If it is >> > meant to be used for the latter purpose, then some changes >> > are very much needed :-) >> > >> > Regards, >> > Misha >> > >> > >> > -----Original Message----- >> > From: www-international-request@w3.org >> > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida >> > Sent: 01 April 2007 14:59 >> > To: 'WWW International' >> > Subject: New web app: Searching for language subtags >> > >> > >> > You may find this of interest. It's purely a personal project. >> > >> > http://people.w3.org/rishida/utils/subtags/ >> > >> > >> > http://people.w3.org/rishida/blog/?p=90 says: >> > >> > This tool allows you to search for tags that have, say, >> > 'french' in their description (there are currently 11), or to >> > find out what that mysterious 'ch' tag stands for (there are >> > 2 possibilities). Or you can simply list all current language >> > tags, or script tags, or variants, etc. >> > >> > For months I've been wanting to write a small, Web-based tool >> > for finding things in the subtag registry without having to >> > work on the (for many people, intimidating) raw text file on >> > the IANA site. >> > >> > Tom Gruner created an initial tool for pretty printing the >> > IANA list, which handled enough of the basics to allow me to >> > use the little time I have these days to add the search >> > functionality on top. >> > >> > If you have JavaScript running, you are shown just the tags >> > and descriptions initially, but by clicking on those you can >> > reveal all additional information in the registry for a given >> > tag. I also highlight tags that are deprecated, so you can >> > see that straight away. >> > >> > (PS: Some final tweaks to the code will come when I have a >> > spare moment for things like making the expanding list more >> > accessible, etc.) >> > >> > RI >> > >> > >> > ============ >> > Richard Ishida >> > Internationalization Lead >> > W3C (World Wide Web Consortium) >> > >> > http://www.w3.org/People/Ishida/ >> > http://www.w3.org/International/ >> > http://people.w3.org/rishida/blog/ >> > http://www.flickr.com/photos/ishida/ >> > >> > >> > >> > >> > >> > This email was sent to you by Reuters, the global news and >> > information company. >> > To find out more about Reuters visit www.about.reuters.com >> > >> > Any views expressed in this message are those of the >> > individual sender, except where the sender specifically >> > states them to be the views of Reuters Limited. >> > >> > Reuters Limited is part of the Reuters Group of companies, of >> > which Reuters Group PLC is the ultimate parent company. >> > Reuters Group PLC - Registered office address: The Reuters >> > Building, South Colonnade, Canary Wharf, London E14 5EP, >> > United Kingdom Registered No: 3296375 Registered in England and Wales >> > >> > >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> > > > >-- >Mark _________________________________________________________________ 5.5%* 30 year fixed mortgage rate. Good credit refinance. Up to 5 free quotes - *Terms https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h2a5d&s=4056&p=5117&disc=y&vers=910 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 03 02:46: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 1HYcmJ-0008A4-8D; Tue, 03 Apr 2007 02:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMlf-0007J0-Tq for ltru@ietf.org; Mon, 02 Apr 2007 09:40:19 -0400 Received: from smtp2.menara.ma ([81.192.53.161] helo=IMSS2.menara.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMlb-0006Yk-AS for ltru@ietf.org; Mon, 02 Apr 2007 09:40:19 -0400 Received: from IMSS2.menara.local (localhost.localdomain [127.0.0.1]) by localhost.menara.local (Postfix) with ESMTP id B03C62010C; Mon, 2 Apr 2007 13:39:57 +0000 (WET) Received: from [81.192.111.226] (adsl-226-111-192-81.adsl.iam.net.ma [81.192.111.226])by IMSS2.menara.local (Postfix) with ESMTPid 9B12E200BD; Mon, 2 Apr 2007 13:39:56 +0000 (WET) Message-ID: <461107A7.9040803@emi.ac.ma> Date: Mon, 02 Apr 2007 13:39:51 +0000 From: Najib Tounsi User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Richard Ishida , WWW International , LTRU Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(15086.003) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:4 M:4 S:4 R:4 (1.0000 1.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 X-Mailman-Approved-At: Tue, 03 Apr 2007 02:46:02 -0400 Cc: Subject: [Ltru] RE: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi all, --- Misha Wolf wrote: > > Hi Richard, > > Having spent a few minutes playing with this, it > seems to > be both useful and fun. +1 > > My one concern is that people who haven't been > initiated > into the arcane mysteries of BCP 47, might > misunderstand > the meaning of a heading like "redundant" in > response to > a search for "Chinese". "people who haven't been initiated into the arcane mysteries of BCP 47", might even not understand what 'redundant', 'Grandfathered' and other 'variant' mean or what they are for. A small definition of the key vocabulary would be welcome. One can try http://en.wikipedia.org/wiki/BCP_47, but it doesn't give any explanation, and just refers to http://www.w3.org/International/articles/language-tags/Overview.en.php (which defines what variant means, but not all the other related vocabulary) and http://www.iana.org/assignments/language-subtag-registry (which is a list of language subtags.) Najib > It needs to be made clear > to > people that this is a tool for examining the > registry, > *NOT* a tool for finding appropriate language tags. > If > it is meant to be used for the latter purpose, then > some > changes are very much needed :-) > > Regards, > Misha > > > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf > Of Richard Ishida > Sent: 01 April 2007 14:59 > To: 'WWW International' > Subject: New web app: Searching for language subtags > > > You may find this of interest. It's purely a > personal project. > > http://people.w3.org/rishida/utils/subtags/ > > > http://people.w3.org/rishida/blog/?p=90 says: > > This tool allows you to search for tags that have, > say, 'french' in > their description (there are currently 11), or to > find out what that > mysterious 'ch' tag stands for (there are 2 > possibilities). Or you can > simply list all current language tags, or script > tags, or variants, etc. > > For months I've been wanting to write a small, > Web-based tool for > finding things in the subtag registry without having > to work on the (for > many people, intimidating) raw text file on the IANA > site. > > Tom Gruner created an initial tool for pretty > printing the IANA list, > which handled enough of the basics to allow me to > use the little time I > have these days to add the search functionality on > top. > > If you have JavaScript running, you are shown just > the tags and > descriptions initially, but by clicking on those you > can reveal all > additional information in the registry for a given > tag. I also highlight > tags that are deprecated, so you can see that > straight away. > > (PS: Some final tweaks to the code will come when I > have a spare moment > for things like making the expanding list more > accessible, etc.) > > RI > > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > > This email was sent to you by Reuters, the global > news and information company. > To find out more about Reuters visit > www.about.reuters.com > > Any views expressed in this message are those of the > individual sender, > except where the sender specifically states them to > be the views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of > companies, of which Reuters Group PLC is the > ultimate parent company. > Reuters Group PLC - Registered office address: The > Reuters Building, South Colonnade, Canary Wharf, > London E14 5EP, United Kingdom > Registered No: 3296375 > Registered in England and Wales > > > > -- Najib TOUNSI (mailto:tounsi @ emi.ac.ma) Ecole Mohammadia d'Ingenieurs, BP 765 Agdal-RABAT Maroc (Morocco) Phone : +212 (0) 37 68 71 50 (P1711) Fax : +212 (0) 37 77 88 53 Mobile: +212 (0) 61 22 00 30 -- Najib TOUNSI (mailto:tounsi @ w3.org) Bureau W3C au Maroc (http://www.w3c.org.ma/) Ecole Mohammadia d'Ingenieurs, BP 765 Agdal-RABAT Maroc (Morocco) Phone : +212 (0) 37 68 71 50 (P1711) Fax : +212 (0) 37 77 88 53 Mobile: +212 (0) 61 22 00 30 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 04 04:08: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 1HZ0Wc-0005rs-QW; Wed, 04 Apr 2007 04:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0Wc-0005rn-1Z for ltru@ietf.org; Wed, 04 Apr 2007 04:07:26 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ0Wa-0001h6-On for ltru@ietf.org; Wed, 04 Apr 2007 04:07:26 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 37D3B1C00EB; Wed, 4 Apr 2007 10:07:07 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 325A21C00DD; Wed, 4 Apr 2007 10:07:04 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2475A58ED21; Wed, 4 Apr 2007 10:07:04 +0200 (CEST) Date: Wed, 4 Apr 2007 10:07:03 +0200 From: Stephane Bortzmeyer To: Najib Tounsi Message-ID: <20070404080703.GB25398@nic.fr> References: <461107A7.9040803@emi.ac.ma> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461107A7.9040803@emi.ac.ma> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group , WWW International Subject: [Ltru] Re: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Apr 02, 2007 at 01:39:51PM +0000, Najib Tounsi wrote a message of 168 lines which said: > One can try http://en.wikipedia.org/wiki/BCP_47, Very bad article, which does not even point to the real Wikipedia article: http://en.wikipedia.org/wiki/IETF_language_code _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 04 05:21: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 1HZ1gV-0005tq-Jy; Wed, 04 Apr 2007 05:21:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1gT-0005te-Ne for ltru@ietf.org; Wed, 04 Apr 2007 05:21:41 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1gR-0008SU-VO for ltru@ietf.org; Wed, 04 Apr 2007 05:21:41 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 0DAAF4EFD2; Wed, 4 Apr 2007 05:21:37 -0400 (EDT) From: "Richard Ishida" To: "'Mark Davis'" References: <004a01c77465$db00a540$6401a8c0@rishida> <00e401c7752e$64e96030$6401a8c0@rishida> <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> Subject: RE: [Ltru] RE: New web app: Searching for language subtags Date: Wed, 4 Apr 2007 10:22:05 +0100 Message-ID: <000a01c7769a$b6d063e0$6401a8c0@rishida> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1Ut2p2PgLOgykSuKMjG/ieymevgBR8E8g X-Spam-Score: 0.1 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: 'WWW International' , 'Misha Wolf' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867611153==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1867611153== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C776A3.1894CBE0" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C776A3.1894CBE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So you're aware. I'm looking at modifying the UI, but don't have a lot = of time to work on it just now. =20 RI =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) =20 http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ =20 =20 _____ =20 From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis Sent: 02 April 2007 19:15 To: Richard Ishida Cc: Misha Wolf; LTRU Working Group; WWW International Subject: Re: [Ltru] RE: New web app: Searching for language subtags I have a couple of usability suggestions. Example. Click on Regions, put in "France" in Search for: and click Show = Result. You get unexpected outcome. It isn't clear that the push button = only affects what the radio button says. And even after you know this, = it's clumsy, since you always have to switch the radio button, then hit = the push button.=20 Rather than the current interface, it would be faster and less confusing = to have pushbuttons for all of what you have as radio buttons, and = remove "Show Results". And retitle Descriptions and Subtags as "Search = Descriptions" and "Search Subtags".=20 Subtags isn't quite right either, since I can put in whole language tags = like "ar-Arab". So I'd suggest separating that as a separate button = "Search Tags". You don't test for invalid whole tags right now, so = "Arab-en". You document that, but it would be easy to fix. I have a = regex that tests validity and divides up the language tag into the = pieces, so you could use that if you want.=20 Mark On 4/2/07, Richard Ishida wrote:=20 Hmm. People who haven't been initiated into the arcane mysteries of BCP = 47 still have to use the registry to find subtags. If there are things they need to understand, we'd better help them there. Note that they no = longer=20 see redundant tags when searching for Chinese with my tool, and that I included a short explanation of redundant in the side notes. I hope = that will help. RI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead=20 W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Misha Wolf [mailto: Misha.Wolf@reuters.com = ] > Sent: 01 April 2007 15:14 > To: Richard Ishida; WWW International; LTRU Working Group > Subject: RE: New web app: Searching for language subtags > > Hi Richard, > > Having spent a few minutes playing with this, it seems to be > both useful and fun. > > My one concern is that people who haven't been initiated into > the arcane mysteries of BCP 47, might misunderstand the=20 > meaning of a heading like "redundant" in response to a search > for "Chinese". It needs to be made clear to people that this > is a tool for examining the registry, > *NOT* a tool for finding appropriate language tags. If it is=20 > meant to be used for the latter purpose, then some changes > are very much needed :-) > > Regards, > Misha > > > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > Sent: 01 April 2007 14:59 > To: 'WWW International'=20 > Subject: New web app: Searching for language subtags > > > You may find this of interest. It's purely a personal project. > > http://people.w3.org/rishida/utils/subtags/ > > > http://people.w3.org/rishida/blog/?p=3D90 says: > > This tool allows you to search for tags that have, say,=20 > 'french' in their description (there are currently 11), or to > find out what that mysterious 'ch' tag stands for (there are > 2 possibilities). Or you can simply list all current language=20 > tags, or script tags, or variants, etc. > > For months I've been wanting to write a small, Web-based tool > for finding things in the subtag registry without having to > work on the (for many people, intimidating) raw text file on=20 > the IANA site. > > Tom Gruner created an initial tool for pretty printing the > IANA list, which handled enough of the basics to allow me to > use the little time I have these days to add the search=20 > functionality on top. > > If you have JavaScript running, you are shown just the tags > and descriptions initially, but by clicking on those you can > reveal all additional information in the registry for a given=20 > tag. I also highlight tags that are deprecated, so you can > see that straight away. > > (PS: Some final tweaks to the code will come when I have a > spare moment for things like making the expanding list more=20 > accessible, etc.) > > RI > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > > This email was sent to you by Reuters, the global news and > information company.=20 > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the > individual sender, except where the sender specifically=20 > states them to be the views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of > which Reuters Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters=20 > Building, South Colonnade, Canary Wharf, London E14 5EP, > United Kingdom Registered No: 3296375 Registered in England and Wales > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=20 Mark=20 ------=_NextPart_000_000B_01C776A3.1894CBE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
So=20 you're aware.  I'm looking at modifying the UI, but don't have a = lot of=20 time to work on it just now.
 
RI
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Richard = Ishida
Internationalization = Lead
W3C (World Wide Web=20 Consortium)
 
http://www.w3.org/People/Ishida= /
http://www.w3.org/International= /
http://people.w3.org/rishida/= blog/
http://www.flickr.com/photo= s/ishida/
 
 

From: mark.edward.davis@gmail.com=20 [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark=20 Davis
Sent: 02 April 2007 19:15
To: Richard=20 Ishida
Cc: Misha Wolf; LTRU Working Group; WWW=20 International
Subject: Re: [Ltru] RE: New web app: Searching = for=20 language subtags

I have a couple of usability suggestions.

Example. = Click on=20 Regions, put in "France" in Search for: and = click=20 Show Result. You get unexpected outcome. = It=20 isn't clear that the push button only affects what the radio button = says. And=20 even after you know this, it's clumsy, since you always have to switch = the=20 radio button, then hit the push button.

Rather than the = current=20 interface, it would be faster and less confusing to have pushbuttons = for all=20 of what you have as radio buttons, and remove "Show Results". And = retitle=20 Descriptions and Subtags as "Search Descriptions" and "Search = Subtags".=20

Subtags isn't quite right either, since I can put in whole = language=20 tags like "ar-Arab". So I'd suggest separating that as a separate = button=20 "Search Tags". You don't test for invalid whole tags right now, so = "Arab-en".=20 You document that, but it would be easy to fix. I have a regex that = tests=20 validity and divides up the language tag into the pieces, so you could = use=20 that if you want.

Mark

On 4/2/07, Richard=20 Ishida <ishida@w3.org>=20 wrote:
Hmm.=20 People who haven't been initiated into the arcane mysteries of BCP=20 47
still have to use the registry to find subtags. If there are = things=20 they
need to understand, we'd better help them = there.  Note=20 that they no longer
see redundant tags when searching for = Chinese with=20 my tool, and that I
included a short explanation of redundant in = the side=20 notes.  I hope that
will=20 = help.

RI

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Richard=20 Ishida
Internationalization Lead
W3C (World Wide Web=20 Consortium)

http://www.w3.org/People/Ishida= /
http://www.w3.org/International= /
http://people.w3.org/rishida/= blog/
http://www.flickr.com/photo= s/ishida/



>=20 -----Original Message-----
> From: Misha Wolf [mailto: = Misha.Wolf@reuters.com]
>=20 Sent: 01 April 2007 15:14
> To: Richard Ishida; WWW = International;=20 LTRU Working Group
> Subject: RE: New web app: Searching for = language=20 subtags
>
> Hi Richard,
>
> Having spent a = few=20 minutes playing with this, it seems to be
> both useful and=20 fun.
>
> My one concern is that people who haven't been=20 initiated into
> the arcane mysteries of BCP 47, might = misunderstand=20 the
> meaning of a heading like "redundant" in response to a=20 search
> for "Chinese".  It needs to be made clear = to people=20 that this
> is a tool for examining the registry,
> = *NOT* a tool=20 for finding appropriate language tags.  If it is
> = meant to=20 be used for the latter purpose, then some changes
> are very = much=20 needed :-)
>
> Regards,
> = Misha
>
>
>=20 -----Original Message-----
> From: www-international-reques= t@w3.org
>=20 [mailto:www-international-reques= t@w3.org]=20 On Behalf Of Richard Ishida
> Sent: 01 April 2007 = 14:59
> To:=20 'WWW International'
> Subject: New web app: Searching for = language=20 subtags
>
>
> You may find this of=20 interest.  It's purely a personal project.
>
> = http://people.w3.org= /rishida/utils/subtags/
>
>
>=20 http://people.w3.org/r= ishida/blog/?p=3D90=20 says:
>
> This tool allows you to search for tags that = have,=20 say,
> 'french' in their description (there are currently = 11), or=20 to
> find out what that mysterious 'ch' tag stands for (there=20 are
> 2 possibilities). Or you can simply list all current = language=20
> tags, or script tags, or variants, etc.
>
> For = months=20 I've been wanting to write a small, Web-based tool
> for = finding=20 things in the subtag registry without having to
> work on the = (for=20 many people, intimidating) raw text file on
> the IANA=20 site.
>
> Tom Gruner created an initial tool for pretty = printing=20 the
> IANA list, which handled enough of the basics to allow = me=20 to
> use the little time I have these days to add the search =
>=20 functionality on top.
>
> If you have JavaScript = running, you=20 are shown just the tags
> and descriptions initially, but by = clicking=20 on those you can
> reveal all additional information in the = registry=20 for a given
> tag. I also highlight tags that are deprecated, = so you=20 can
> see that straight away.
>
> (PS: Some final = tweaks=20 to the code will come when I have a
> spare moment for things = like=20 making the expanding list more
> accessible, = etc.)
>
>=20 RI
>
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Richard Ishida
>=20 Internationalization Lead
> W3C (World Wide Web=20 Consortium)
>
> http://www.w3.org/People/Ishida= /
>=20 http://www.w3.org/International= /
>=20 http://people.w3.org/rishida/= blog/
>=20 http://www.flickr.com/photo= s/ishida/
>
>
>
>
>
>=20 This email was sent to you by Reuters, the global news and
>=20 information company.
> To find out more about Reuters visit = www.about.reuters.com
>>=20 Any views expressed in this message are those of the
> = individual=20 sender, except where the sender specifically
> states them to = be the=20 views of Reuters Limited.
>
> Reuters Limited is part of = the=20 Reuters Group of companies, of
> which Reuters Group PLC is = the=20 ultimate parent company.
> Reuters Group PLC - Registered = office=20 address: The Reuters
> Building, South Colonnade, Canary = Wharf,=20 London E14 5EP,
> United Kingdom Registered No: 3296375 = Registered in=20 England and=20 = Wales
>
>


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


--
Mark ------=_NextPart_000_000B_01C776A3.1894CBE0-- --===============1867611153== 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 --===============1867611153==-- From ltru-bounces@ietf.org Wed Apr 04 06:45: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 1HZ2zf-000084-2w; Wed, 04 Apr 2007 06:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ2ze-00007s-87 for ltru@ietf.org; Wed, 04 Apr 2007 06:45:34 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ2zc-0006b0-R0 for ltru@ietf.org; Wed, 04 Apr 2007 06:45:34 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 71B331C00E4 for ; Wed, 4 Apr 2007 12:45:18 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6D4271C0092 for ; Wed, 4 Apr 2007 12:45:18 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6967C58ED21 for ; Wed, 4 Apr 2007 12:45:18 +0200 (CEST) Date: Wed, 4 Apr 2007 12:45:18 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20070404104518.GA14793@nic.fr> References: 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ltru] Grammar and grandfathered (Was: I-D ACTION:draft-ietf-ltru-4646bis-03.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 On Thu, Mar 29, 2007 at 10:50:02AM -0400, Internet-Drafts@ietf.org wrote a message of 94 lines which said: > Title : Tags for Identifying Languages > Author(s) : A. Phillips, M. Davis > Filename : draft-ietf-ltru-4646bis-03.txt I approve the new wording of well-formed vs. invalid in section 2.2 "Classes of conformance". However, it is now at odds with the ABNF (the comment in the production). Following a suggestion by John Cowan (http://www1.ietf.org/mail-archive/web/ltru/current/msg07422.html), I suggest the following ABNF, where "grandfathered" was completely removed (it is a semantic concept and does not belong in the grammar): Language-Tag = langtag / privateuse ; private use tag / irregular ; some grandfathered registrations 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 04 11:08: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 1HZ76K-0003fk-Nb; Wed, 04 Apr 2007 11:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ76J-0003f7-Gf for ltru@lists.ietf.org; Wed, 04 Apr 2007 11:08:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ76I-0006jG-78 for ltru@lists.ietf.org; Wed, 04 Apr 2007 11:08:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZ765-0000lE-II for ltru@lists.ietf.org; Wed, 04 Apr 2007 17:08:29 +0200 Received: from d252030.dialin.hansenet.de ([80.171.252.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 17:08:29 +0200 Received: from nobody by d252030.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2007 17:08:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 04 Apr 2007 17:07:35 +0200 Organization: Lines: 19 Message-ID: <4613BF37.2A32@xyzzy.claranet.de> References: <461107A7.9040803@emi.ac.ma> <20070404080703.GB25398@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252030.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: www-international@w3.org Subject: [Ltru] Re: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: >> One can try http://en.wikipedia.org/wiki/BCP_47 > Very bad article, which does not even point to > the real Wikipedia article: > http://en.wikipedia.org/wiki/IETF_language_code [[User:Zundark]] redirected the former to the latter. I've added some categories, fixed a nit about the supranational UN codes, and tried to add a link to ltru.generic-nic.net/ (that failed because I've no account anymore, and the "captchas" don't work with my browser - one of several severe reasons why I've killed all my wikimedia accounts). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 04 11:22: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 1HZ7J9-0002ud-PO; Wed, 04 Apr 2007 11:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7J7-0002uO-QX for ltru@ietf.org; Wed, 04 Apr 2007 11:21:58 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7J1-0001Iq-TQ for ltru@ietf.org; Wed, 04 Apr 2007 11:21:57 -0400 Received: from [10.72.72.239] (snvvpn1-10-72-72-c239.corp.yahoo.com [10.72.72.239]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l34FLZ6b097112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 08:21:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=R8rilMmWTkSkPlG2ZpOwxueLnHI9jF5sniMKDqBG/pqMn+4T7CVh7aYh5CkzvN88 Message-ID: <4613C27E.7060905@yahoo-inc.com> Date: Wed, 04 Apr 2007 08:21:34 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Grammar and grandfathered (Was: I-D ACTION:draft-ietf-ltru-4646bis-03.txt References: <20070404104518.GA14793@nic.fr> In-Reply-To: <20070404104518.GA14793@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane, John's note came after draft-03 was submitted. I had incorporated this already in the editor's copy, which has not yet been submitted. See: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.html#syntax Addison Stephane Bortzmeyer wrote: > On Thu, Mar 29, 2007 at 10:50:02AM -0400, > Internet-Drafts@ietf.org wrote > a message of 94 lines which said: > >> Title : Tags for Identifying Languages >> Author(s) : A. Phillips, M. Davis >> Filename : draft-ietf-ltru-4646bis-03.txt > > I approve the new wording of well-formed vs. invalid in section 2.2 > "Classes of conformance". > > However, it is now at odds with the ABNF (the comment in the > production). Following a suggestion by John Cowan > (http://www1.ietf.org/mail-archive/web/ltru/current/msg07422.html), I > suggest the following ABNF, where "grandfathered" was completely > removed (it is a semantic concept and does not belong in the grammar): > > > Language-Tag = langtag > / privateuse ; private use tag > / irregular ; some grandfathered registrations > > 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 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 05 13:16: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 1HZVYe-0007BU-FG; Thu, 05 Apr 2007 13:15:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVYd-0007B2-24; Thu, 05 Apr 2007 13:15:35 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZVYV-0004aM-NW; Thu, 05 Apr 2007 13:15:35 -0400 Received: from [10.72.76.144] (snvvpn2-10-72-76-c144.corp.yahoo.com [10.72.76.144]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l35HFG24000628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 10: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:content-type; b=UB/95gLBqt5YqORzVBs0jxRMsqxtgyMN2w016IQ1qf+k0qR7SENAunVage/6d/gg Message-ID: <46152EA4.8070202@yahoo-inc.com> Date: Thu, 05 Apr 2007 10:15:16 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------010406030502090308080205" X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 7b17087aaa7b9435c17742243033845e Cc: 'LTRU Working Group' Subject: [Ltru] submission: draft-04 of ietf-ltru-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 This is a multi-part message in MIME format. --------------010406030502090308080205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear editors, Please find attached draft-ietf-ltru-4646bis-04. Thanks, Addison (for the editors) -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. --------------010406030502090308080205 Content-Type: text/plain; name="draft-ietf-ltru-4646bis-04.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ltru-4646bis-04.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWFob28hIEluYy4NCk9ic29sZXRl czogNDY0NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4g RGF2aXMsIEVkLg0KSW50ZW5kZWQgc3RhdHVzOiBCZXN0IEN1cnJlbnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlDQpQcmFjdGljZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDUsIDIwMDcNCkV4 cGlyZXM6IE9jdG9iZXIgNywgMjAwNw0KDQoNCiAgICAgICAgICAgICAgICAgICAgIFRhZ3Mg Zm9yIElkZW50aWZ5aW5nIExhbmd1YWdlcw0KICAgICAgICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLWx0cnUtNDY0NmJpcy0wNA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5 IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50 cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBv ZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRp c2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUg d2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQ IDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVh cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQog ICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAg IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRm LzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIE9jdG9iZXIgNywgMjAwNy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAg ICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29u dGVudCwgY29uc3RydWN0aW9uLCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdz IGZvciB1c2UgaW4gY2FzZXMgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0 ZSB0aGUgbGFuZ3VhZ2UgdXNlZCBpbiBhbiBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNv DQogICBkZXNjcmliZXMgaG93IHRvIHJlZ2lzdGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1 YWdlIHRhZ3MgYW5kIHRoZQ0KICAgY3JlYXRpb24gb2YgdXNlci1kZWZpbmVkIGV4dGVuc2lv bnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0K ICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA0DQogICAyLiAgVGhlIExhbmd1YWdlIFRhZyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4xLiAgU3lu dGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNQ0KICAgICAyLjIuICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50ZXJwcmV0 YXRpb24gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgMi4yLjEuICBQcmltYXJ5IExhbmd1 YWdlIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgICAy LjIuMi4gIEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMQ0KICAgICAgIDIuMi4zLiAgU2NyaXB0IFN1YnRhZyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgICAgMi4yLjQuICBSZWdpb24g U3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAg ICAgICAyLjIuNS4gIFZhcmlhbnQgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNQ0KICAgICAgIDIuMi42LiAgRXh0ZW5zaW9uIFN1YnRhZ3MgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgMi4yLjcuICBQ cml2YXRlIFVzZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTcNCiAgICAgICAyLjIuOC4gIEdyYW5kZmF0aGVyZWQgUmVnaXN0cmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAgIDIuMi45LiAgQ2xhc3NlcyBvZiBDb25m b3JtYW5jZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAzLiAgUmVn aXN0cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjANCiAgICAgMy4xLiAgRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRh ZyBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAyMA0KICAgICAgIDMuMS4xLiAgRmlsZSBGb3Jt YXQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICAg ICAgMy4xLjIuICBSZWNvcmQgRGVmaW5pdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjENCiAgICAgICAzLjEuMy4gIFN1YnRhZyBhbmQgVGFnIEZpZWxkcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0KICAgICAgIDMuMS40LiAgRGVz Y3JpcHRpb24gRmllbGQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0 DQogICAgICAgMy4xLjUuICBEZXByZWNhdGVkIEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjUNCiAgICAgICAzLjEuNi4gIFByZWZlcnJlZC1WYWx1ZSBG aWVsZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0KICAgICAgIDMuMS43 LiAgUHJlZml4IEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDI2DQogICAgICAgMy4xLjguICBDb21tZW50cyBGaWVsZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNCiAgICAgICAzLjEuOS4gIFN1cHByZXNzLVNj cmlwdCBGaWVsZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNw0KICAgICAz LjIuICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI3DQogICAgIDMuMy4gIE1haW50ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgMy40LiAgU3RhYmlsaXR5 IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0K ICAgICAzLjUuICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBTdWJ0YWdzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMzDQogICAgIDMuNi4gIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lz dHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgICAgMy43LiAgRXh0 ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzOA0KICAgICAzLjguICBVcGRhdGUgb2YgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3Ry eSAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxDQogICA0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNz aW5nIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDINCiAgICAgNC4x LiAgQ2hvaWNlIG9mIExhbmd1YWdlIFRhZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA0Mg0KICAgICA0LjIuICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0DQogICAgIDQuMy4gIExlbmd0aCBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDUNCiAg ICAgICA0LjMuMS4gIFdvcmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBTaXplcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiA0Ng0KICAgICAgIDQuMy4yLiAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFn ZSBUYWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3DQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICAg W1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgICAgNC40LiAgQ2Fub25p Y2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0 OA0KICAgICA0LjUuICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAu IC4gLiAuIC4gLiAuIC4gLiAuIDUwDQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTENCiAgICAgNS4xLiAg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1MQ0KICAgICA1LjIuICBFeHRlbnNpb25zIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUxDQogICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTMNCiAgIDcu ICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1NA0KICAgOC4gIENoYW5nZXMgZnJvbSBSRkMgNDY0NiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1DQogICA5LiAgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTgN CiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1OA0KICAgICA5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5DQogICBBcHBlbmRpeCBB LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNjENCiAgIEFwcGVuZGl4IEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZv cm1hdGl2ZSkgLiAuIC4gLiAuIC4gLiA2Mg0KICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY1DQogICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gNjYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg ICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICBBcHJpbCAyMDA3DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBIdW1hbiBi ZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBwYXN0IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVt YmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBhcmUgbWFueSByZWFzb25zIHdoeSBvbmUg d291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxhbmd1YWdlIHVzZWQgd2hlbiBwcmVz ZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoNCiAgIEEgdXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIG9mdGVuIG5lZWQgdG8gYmUgaWRlbnRpZmllZCBzbyB0aGF0DQog ICBhcHByb3ByaWF0ZSBwcm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yIGV4YW1wbGUs IHRoZSB1c2VyJ3MNCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzIGluIGEgV2ViIGJyb3dzZXIg Y2FuIGJlIHVzZWQgdG8gc2VsZWN0IFdlYiBwYWdlcw0KICAgYXBwcm9wcmlhdGVseS4gIExh bmd1YWdlIHByZWZlcmVuY2VzIGNhbiBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nDQog ICB0b29scyAoc3VjaCBhcyBkaWN0aW9uYXJpZXMpIHRvIGFzc2lzdCBpbiB0aGUgcHJvY2Vz c2luZyBvcg0KICAgdW5kZXJzdGFuZGluZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5n dWFnZXMuDQoNCiAgIEluIGFkZGl0aW9uLCBrbm93bGVkZ2UgYWJvdXQgdGhlIHBhcnRpY3Vs YXIgbGFuZ3VhZ2UgdXNlZCBieSBzb21lDQogICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250 ZW50IG1pZ2h0IGJlIHVzZWZ1bCBvciBldmVuIHJlcXVpcmVkIGJ5IHNvbWUNCiAgIHR5cGVz IG9mIHByb2Nlc3Npbmc7IGZvciBleGFtcGxlLCBzcGVsbC1jaGVja2luZywgY29tcHV0ZXIt DQogICBzeW50aGVzaXplZCBzcGVlY2gsIEJyYWlsbGUgdHJhbnNjcmlwdGlvbiwgb3IgaGln aC1xdWFsaXR5IHByaW50DQogICByZW5kZXJpbmdzLg0KDQogICBPbmUgbWVhbnMgb2YgaW5k aWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBieSBsYWJlbGluZyB0aGUNCiAgIGluZm9y bWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBpZGVudGlmaWVyIG9yICJ0YWciLiAgVGhlc2UgdGFn cyBjYW4gYmUNCiAgIHVzZWQgdG8gc3BlY2lmeSB1c2VyIHByZWZlcmVuY2VzIHdoZW4gc2Vs ZWN0aW5nIGluZm9ybWF0aW9uIGNvbnRlbnQsDQogICBvciBmb3IgbGFiZWxpbmcgYWRkaXRp b25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQgYW5kIGFzc29jaWF0ZWQNCiAgIHJlc291cmNl cy4NCg0KICAgVGFncyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0aW9uYWwg bGFuZ3VhZ2UgYXR0cmlidXRlcyBvZg0KICAgY29udGVudC4gIEZvciBleGFtcGxlLCBpbmRp Y2F0aW5nIHNwZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KICAgZGlhbGVjdCwgd3Jp dGluZyBzeXN0ZW0sIG9yIG9ydGhvZ3JhcGh5IHVzZWQgaW4gYSBkb2N1bWVudCBvcg0KICAg cmVzb3VyY2UgbWF5IGVuYWJsZSB0aGUgdXNlciB0byBvYnRhaW4gaW5mb3JtYXRpb24gaW4g YSBmb3JtIHRoYXQNCiAgIHRoZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGl0IGNhbiBiZSBpbXBv cnRhbnQgaW4gcHJvY2Vzc2luZyBvcg0KICAgcmVuZGVyaW5nIHRoZSBnaXZlbiBjb250ZW50 IGludG8gYW4gYXBwcm9wcmlhdGUgZm9ybSBvciBzdHlsZS4NCg0KICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYSBwYXJ0aWN1bGFyIGlkZW50aWZpZXIgbWVjaGFuaXNtICh0aGUNCiAg IGxhbmd1YWdlIHRhZykgYW5kIGEgcmVnaXN0cmF0aW9uIGZ1bmN0aW9uIGZvciB2YWx1ZXMg dG8gYmUgdXNlZCB0bw0KICAgZm9ybSB0YWdzLiAgSXQgYWxzbyBkZWZpbmVzIGEgbWVjaGFu aXNtIGZvciBwcml2YXRlIHVzZSB2YWx1ZXMgYW5kDQogICBmdXR1cmUgZXh0ZW5zaW9uLg0K DQogICBUaGlzIGRvY3VtZW50IHJlcGxhY2VzIFtSRkM0NjQ2XSwgd2hpY2ggcmVwbGFjZWQg W1JGQzMwNjZdIGFuZCBpdHMNCiAgIHByZWRlY2Vzc29yIFtSRkMxNzY2XS4gIEZvciBhIGxp c3Qgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50LCBzZWUNCiAgIFNlY3Rpb24gOC4NCg0K ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcg ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCjIu ICBUaGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIHVzZWQgdG8gaGVs cCBpZGVudGlmeSBsYW5ndWFnZXMsIHdoZXRoZXIgc3Bva2VuLA0KICAgd3JpdHRlbiwgc2ln bmVkLCBvciBvdGhlcndpc2Ugc2lnbmFsZWQsIGZvciB0aGUgcHVycG9zZSBvZg0KICAgY29t bXVuaWNhdGlvbi4gIFRoaXMgaW5jbHVkZXMgY29uc3RydWN0ZWQgYW5kIGFydGlmaWNpYWwg bGFuZ3VhZ2VzLA0KICAgYnV0IGV4Y2x1ZGVzIGxhbmd1YWdlcyBub3QgaW50ZW5kZWQgcHJp bWFyaWx5IGZvciBodW1hbg0KICAgY29tbXVuaWNhdGlvbiwgc3VjaCBhcyBwcm9ncmFtbWlu ZyBsYW5ndWFnZXMuDQoNCjIuMS4gIFN5bnRheA0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGlz IGNvbXBvc2VkIG9mIG9uZSBvciBtb3JlIHBhcnRzLCBrbm93biBhcw0KICAgInN1YnRhZ3Mi LiAgRWFjaCBzdWJ0YWcgY29uc2lzdHMgb2YgYSBzZXF1ZW5jZSBvZiBhbHBoYW51bWVyaWMN CiAgIGNoYXJhY3RlcnMuICBTdWJ0YWdzIGFyZSBkaXN0aW5ndWlzaGVkIGFuZCBzZXBhcmF0 ZWQgZnJvbSBvbmUgYW5vdGhlcg0KICAgYnkgYSBoeXBoZW4gKCItIiwgQUJORiBbUkZDNDIz NF0gJXgyRCkuICBBIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBvZiBhDQogICAicHJpbWFyeSBs YW5ndWFnZSIgc3VidGFnIGFuZCBhIChwb3NzaWJseSBlbXB0eSkgc2VyaWVzIG9mIHN1YnNl cXVlbnQNCiAgIHN1YnRhZ3MsIGVhY2ggb2Ygd2hpY2ggcmVmaW5lcyBvciBuYXJyb3dzIHRo ZSByYW5nZSBvZiBsYW5ndWFnZXMNCiAgIGlkZW50aWZpZWQgYnkgdGhlIG92ZXJhbGwgdGFn Lg0KDQogICBVc3VhbGx5LCBlYWNoIHR5cGUgb2Ygc3VidGFnIGlzIGRpc3Rpbmd1aXNoZWQg YnkgbGVuZ3RoLCBwb3NpdGlvbiBpbg0KICAgdGhlIHRhZywgYW5kIGNvbnRlbnQ6IHN1YnRh Z3MgY2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5IHRoZXNlDQogICBmZWF0dXJlcy4gIFRo ZSBvbmx5IGV4Y2VwdGlvbiB0byB0aGlzIGlzIGEgZml4ZWQgbGlzdCBvZg0KICAgZ3JhbmRm YXRoZXJlZCB0YWdzIHJlZ2lzdGVyZWQgdW5kZXIgUkZDIDMwNjYgW1JGQzMwNjZdLiAgVGhp cyBtYWtlcw0KICAgaXQgcG9zc2libGUgdG8gY29uc3RydWN0IGEgcGFyc2VyIHRoYXQgY2Fu IGV4dHJhY3QgYW5kIGFzc2lnbiBzb21lDQogICBzZW1hbnRpYyBpbmZvcm1hdGlvbiB0byB0 aGUgc3VidGFncywgZXZlbiBpZiB0aGUgc3BlY2lmaWMgc3VidGFnDQogICB2YWx1ZXMgYXJl IG5vdCByZWNvZ25pemVkLiAgVGh1cywgYSBwYXJzZXIgbmVlZCBub3QgaGF2ZSBhbiB1cC10 by0NCiAgIGRhdGUgY29weSAob3IgYW55IGNvcHkgYXQgYWxsKSBvZiB0aGUgc3VidGFnIHJl Z2lzdHJ5IHRvIHBlcmZvcm0gbW9zdA0KICAgc2VhcmNoaW5nIGFuZCBtYXRjaGluZyBvcGVy YXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBU aGUgc3ludGF4IG9mIHRoZSBsYW5ndWFnZSB0YWcgaW4gQUJORiBbUkZDNDIzNF0gaXM6DQoN CiAgIExhbmd1YWdlLVRhZyAgPSBsYW5ndGFnDQogICAgICAgICAgICAgICAgIC8gcHJpdmF0 ZXVzZSAgICAgICAgICAgICA7IHByaXZhdGUgdXNlIHRhZw0KICAgICAgICAgICAgICAgICAv IGlycmVndWxhciAgICAgICAgICAgICAgOyB0YWdzIGdyYW5kZmF0aGVyZWQgYnkgcnVsZQ0K DQogICBsYW5ndGFnICAgICAgID0gKGxhbmd1YWdlDQogICAgICAgICAgICAgICAgICAgIFsi LSIgc2NyaXB0XQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHJlZ2lvbl0NCiAgICAgICAg ICAgICAgICAgICAgKigiLSIgdmFyaWFudCkNCiAgICAgICAgICAgICAgICAgICAgKigiLSIg ZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHByaXZhdGV1c2VdKQ0KDQog ICBsYW5ndWFnZSAgICAgID0gKDIqM0FMUEhBIFsgZXh0bGFuZyBdKSA7IHNob3J0ZXN0IElT TyA2MzkgY29kZQ0KICAgICAgICAgICAgICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAg OyByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZQ0KICAgICAgICAgICAgICAgICAvIDUqOEFMUEhB ICAgICAgICAgICAgICAgOyByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRhZw0KDQogICBleHRs YW5nICAgICAgID0gKjMoIi0iIDNBTFBIQSkgICAgICAgICA7IHNwZWNpZmljIElTTyA2Mzkt MyBjb2Rlcw0KDQogICBzY3JpcHQgICAgICAgID0gNEFMUEhBICAgICAgICAgICAgICAgICA7 IElTTyAxNTkyNCBjb2RlDQoNCiAgIHJlZ2lvbiAgICAgICAgPSAyQUxQSEEgICAgICAgICAg ICAgICAgIDsgSVNPIDMxNjYgY29kZQ0KICAgICAgICAgICAgICAgICAvIDNESUdJVCAgICAg ICAgICAgICAgICAgOyBVTiBNLjQ5IGNvZGUNCg0KICAgdmFyaWFudCAgICAgICA9IDUqOGFs cGhhbnVtICAgICAgICAgICAgOyByZWdpc3RlcmVkIHZhcmlhbnRzDQogICAgICAgICAgICAg ICAgIC8gKERJR0lUIDNhbHBoYW51bSkNCg0KICAgZXh0ZW5zaW9uICAgICA9IHNpbmdsZXRv biAxKigiLSIgKDIqOGFscGhhbnVtKSkNCg0KICAgc2luZ2xldG9uICAgICA9ICV4NDEtNTcg LyAleDU5LTVBIC8gJXg2MS03NyAvICV4NzktN0EgLyBESUdJVA0KICAgICAgICAgICAgICAg ICA7ICJhIi0idyIgLyAieSItInoiIC8gIkEiLSJXIiAvICJZIi0iWiIgLyAiMCItIjkiDQog ICAgICAgICAgICAgICAgIDsgU2luZ2xlIGFscGhhbnVtZXJpY3MNCiAgICAgICAgICAgICAg ICAgOyAieCIgaXMgcmVzZXJ2ZWQgZm9yIHByaXZhdGUgdXNlDQoNCiAgIHByaXZhdGV1c2Ug ICAgPSAieCIgMSooIi0iICgxKjhhbHBoYW51bSkpDQoNCiAgIGlycmVndWxhciAgICAgPSAi ZW4tR0Itb2VkIiAvICJpLWFtaSIgLyAiaS1ibm4iIC8gImktZGVmYXVsdCINCiAgICAgICAg ICAgICAgICAgLyAiaS1lbm9jaGlhbiIgLyAiaS1oYWsiIC8gImkta2xpbmdvbiIgLyAiaS1s dXgiDQogICAgICAgICAgICAgICAgIC8gImktbWluZ28iIC8gImktbmF2YWpvIiAvICJpLXB3 biIgLyAiaS10YW8iDQogICAgICAgICAgICAgICAgIC8gImktdGF5IiAvICJpLXRzdSIgLyAi c2duLUJFLWZyIiAvICJzZ24tQkUtbmwiDQogICAgICAgICAgICAgICAgIC8gInNnbi1DSC1k ZSINCg0KICAgYWxwaGFudW0gICAgICA9IChBTFBIQSAvIERJR0lUKSAgICAgICA7IGxldHRl cnMgYW5kIG51bWJlcnMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExh bmd1YWdlIFRhZyBBQk5GDQoNCiAgIEFsbCBzdWJ0YWdzIGhhdmUgYSBtYXhpbXVtIGxlbmd0 aCBvZiBlaWdodCBjaGFyYWN0ZXJzIGFuZCB3aGl0ZXNwYWNlDQogICBpcyBub3QgcGVybWl0 dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAgVGhlcmUgaXMgYSBzdWJ0bGV0eSBpbiB0aGUgQUJO Rg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICBwcm9kdWN0aW9uICd2YXJpYW50JzogdmFyaWFudHMgc3RhcnRpbmcgd2l0aCBhIGRp Z2l0IE1BWSBiZSBmb3VyDQogICBjaGFyYWN0ZXJzIGxvbmcsIHdoaWxlIHRob3NlIHN0YXJ0 aW5nIHdpdGggYSBsZXR0ZXIgTVVTVCBiZSBhdCBsZWFzdA0KICAgZml2ZSBjaGFyYWN0ZXJz IGxvbmcuICBGb3IgZXhhbXBsZXMgb2YgbGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIu DQoNCiAgIE5vdGUgV2VsbDogdGhlIEFCTkYgc3ludGF4IGRvZXMgbm90IGRpc3Rpbmd1aXNo IGJldHdlZW4gdXBwZXIgYW5kDQogICBsb3dlcmNhc2UuICBUaGUgYXBwZWFyYW5jZSBvZiB1 cHBlciBhbmQgbG93ZXJjYXNlIGxldHRlcnMgaW4gdGhlDQogICB2YXJvdXMgQUJORiBwcm9k dWN0aW9ucyBhYm92ZSBkbyBub3QgYWZmZWN0IGhvdyBpbXBsZW1lbnRhdGlvbnMNCiAgIGlu dGVycHJldCB0YWdzLiAgVGhhdCBpcywgdGhlIHRhZyAiSS1BTUkiIG1hdGNoZXMgdGhlIGl0 ZW0gImktYW1pIiBpbg0KICAgdGhlICdpcnJlZ3VsYXInIHByb2R1Y3Rpb24uICBBdCBhbGwg dGltZXMsIHRoZSB0YWdzIGFuZCB0aGVpcg0KICAgc3VidGFncywgaW5jbHVkaW5nIHByaXZh dGUgdXNlIGFuZCBleHRlbnNpb25zLCBhcmUgdG8gYmUgdHJlYXRlZCBhcw0KICAgY2FzZSBp bnNlbnNpdGl2ZTogdGhlcmUgZXhpc3QgY29udmVudGlvbnMgZm9yIHRoZSBjYXBpdGFsaXph dGlvbiBvZg0KICAgc29tZSBvZiB0aGUgc3VidGFncywgYnV0IHRoZXNlIE1VU1QgTk9UIGJl IHRha2VuIHRvIGNhcnJ5IG1lYW5pbmcuDQoNCiAgIEZvciBleGFtcGxlOg0KDQogICBvICBb SVNPNjM5LTFdIHJlY29tbWVuZHMgdGhhdCBsYW5ndWFnZSBjb2RlcyBiZSB3cml0dGVuIGlu IGxvd2VyY2FzZQ0KICAgICAgKCdtbicgTW9uZ29saWFuKS4NCg0KICAgbyAgW0lTTzMxNjYt MV0gcmVjb21tZW5kcyB0aGF0IGNvdW50cnkgY29kZXMgYmUgY2FwaXRhbGl6ZWQgKCdNTicN CiAgICAgIE1vbmdvbGlhKS4NCg0KICAgbyAgW0lTTzE1OTI0XSByZWNvbW1lbmRzIHRoYXQg c2NyaXB0IGNvZGVzIHVzZSBsb3dlcmNhc2Ugd2l0aCB0aGUNCiAgICAgIGluaXRpYWwgbGV0 dGVyIGNhcGl0YWxpemVkICgnQ3lybCcgQ3lyaWxsaWMpLg0KDQogICBIb3dldmVyLCBpbiB0 aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZSB1cHBlcmNhc2UgVVMtQVND SUkNCiAgIGxldHRlcnMgaW4gdGhlIHJhbmdlICdBJyB0aHJvdWdoICdaJyBhcmUgY29uc2lk ZXJlZCBlcXVpdmFsZW50IGFuZA0KICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRoZWlyIFVTLUFT Q0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0aHJvdWdo ICd6Jy4gIFRodXMsIHRoZSB0YWcgIm1uLUN5cmwtTU4iIGlzIG5vdCBkaXN0aW5jdCBmcm9t DQogICAiTU4tY1lSTC1tbiIgb3IgIm1OLWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmlu YXRpb24pLCBhbmQgZWFjaCBvZg0KICAgdGhlc2UgdmFyaWF0aW9ucyBjb252ZXlzIHRoZSBz YW1lIG1lYW5pbmc6IE1vbmdvbGlhbiB3cml0dGVuIGluIHRoZQ0KICAgQ3lyaWxsaWMgc2Ny aXB0IGFzIHVzZWQgaW4gTW9uZ29saWEuDQoNCiAgIEFsdGhvdWdoIGNhc2UgZGlzdGluY3Rp b25zIGRvIG5vdCBjYXJyeSBtZWFuaW5nIGluIGxhbmd1YWdlIHRhZ3MsDQogICBjb25zaXN0 ZW50IGZvcm1hdHRpbmcgYW5kIHByZXNlbnRhdGlvbiBvZiB0aGUgdGFncyB3aWxsIGFpZCB1 c2Vycy4NCiAgIFRoZSBmb3JtYXQgb2YgdGhlIHRhZ3MgYW5kIHN1YnRhZ3MgaW4gdGhlIHJl Z2lzdHJ5IGlzIFJFQ09NTUVOREVELg0KICAgSW4gdGhpcyBmb3JtYXQsIGFsbCBub24taW5p dGlhbCB0d28tbGV0dGVyIHN1YnRhZ3MgYXJlIHVwcGVyY2FzZSwgYWxsDQogICBub24taW5p dGlhbCBmb3VyLWxldHRlciBzdWJ0YWdzIGFyZSB0aXRsZWNhc2UsIGFuZCBhbGwgb3RoZXIg c3VidGFncw0KICAgYXJlIGxvd2VyY2FzZS4NCg0KICAgTm90ZSB0aGF0IGFsdGhvdWdoIFtS RkM0MjM0XSByZWZlcnMgdG8gb2N0ZXRzLCB0aGUgbGFuZ3VhZ2UgdGFncw0KICAgZGVzY3Jp YmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIHNlcXVlbmNlcyBvZiBjaGFyYWN0ZXJzIGZyb20g dGhlIFVTLQ0KICAgQVNDSUkgW0lTTzY0Nl0gcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3Mg TUFZIGJlIHVzZWQgaW4gZG9jdW1lbnRzDQogICBhbmQgYXBwbGljYXRpb25zIHRoYXQgdXNl IG90aGVyIGVuY29kaW5ncywgc28gbG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MNCiAgIHRoZSBV Uy1BU0NJSSByZXBlcnRvaXJlLiAgQW4gZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhN TCBkb2N1bWVudA0KICAgdGhhdCB1c2VzIHRoZSBVVEYtMTZMRSBbUkZDMjc4MV0gZW5jb2Rp bmcgb2YgW1VuaWNvZGVdLg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg IEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgIEFwcmlsIDIwMDcNCg0KDQoyLjIuICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBh bmQgSW50ZXJwcmV0YXRpb24NCg0KICAgVGhlIG5hbWVzcGFjZSBvZiBsYW5ndWFnZSB0YWdz IGFuZCB0aGVpciBzdWJ0YWdzIGlzIGFkbWluaXN0ZXJlZCBieQ0KICAgdGhlIEludGVybmV0 IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5n IHRvDQogICB0aGUgcnVsZXMgaW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBUaGUg TGFuZ3VhZ2UgU3VidGFnDQogICBSZWdpc3RyeSBtYWludGFpbmVkIGJ5IElBTkEgaXMgdGhl IHNvdXJjZSBmb3IgdmFsaWQgc3VidGFnczogb3RoZXINCiAgIHN0YW5kYXJkcyByZWZlcmVu Y2VkIGluIHRoaXMgc2VjdGlvbiBwcm92aWRlIHRoZSBzb3VyY2UgbWF0ZXJpYWwgZm9yDQog ICB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJtaW5vbG9neSB1c2VkIGluIHRoaXMgZG9jdW1l bnQ6DQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBsZXRlIGxhbmd1YWdl IHRhZywgc3VjaCBhcw0KICAgICAgInNyLUxhdG4tUlMiIG9yICJhei1BcmFiLUlSIi4gIEV4 YW1wbGVzIG9mIHRhZ3MgaW4gdGhpcyBkb2N1bWVudA0KICAgICAgYXJlIGVuY2xvc2VkIGlu IGRvdWJsZS1xdW90ZXMgKCJlbi1VUyIpLg0KDQogICBvICBTdWJ0YWcgcmVmZXJzIHRvIGEg c3BlY2lmaWMgc2VjdGlvbiBvZiBhIHRhZywgZGVsaW1pdGVkIGJ5IGh5cGhlbiwNCiAgICAg IHN1Y2ggYXMgdGhlIHN1YnRhZyAnSGFudCcgaW4gInpoLUhhbnQtQ04iLiAgRXhhbXBsZXMg b2Ygc3VidGFncyBpbg0KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4gc2lu Z2xlIHF1b3RlcyAoJ0hhbnQnKS4NCg0KICAgbyAgQ29kZSBvciBjb2RlcyByZWZlcnMgdG8g dmFsdWVzIGRlZmluZWQgaW4gZXh0ZXJuYWwgc3RhbmRhcmRzIChhbmQNCiAgICAgIHdoaWNo IGFyZSB1c2VkIGFzIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudCkuICBGb3IgZXhhbXBsZSwg J0hhbnQnDQogICAgICBpcyBhbiBbSVNPMTU5MjRdIHNjcmlwdCBjb2RlIHRoYXQgd2FzIHVz ZWQgdG8gZGVmaW5lIHRoZSAnSGFudCcNCiAgICAgIHNjcmlwdCBzdWJ0YWcgZm9yIHVzZSBp biBhIGxhbmd1YWdlIHRhZy4gIEV4YW1wbGVzIG9mIGNvZGVzIGluDQogICAgICB0aGlzIGRv Y3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnZW4nLCAnSGFudCcpLg0K DQogICBUaGUgZGVmaW5pdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5IHRvIHRoZSB2YXJp b3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0aGUgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRo aXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQ0KICAgImdyYW5kZmF0aGVyZWQiIHRhZ3Mg ZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44Lg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSBkZXNp Z25lZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgNCiAgIGFu ZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRlbnRpZmljYXRpb24gb2Yg dGhlIHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBjb250ZW50IG9m IHRoZSBzdWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93cyB0 YWdzIHRvIGJlIHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5jZSB0 byB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRo ZQ0KICAgSUFOQSByZWdpc3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9u IGhhbmRsaW5nIHdoZW4NCiAgIHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdz IGluIHRoZSBJQU5BIHJlZ2lzdHJ5IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5 aW5nDQogICBzdGFuZGFyZCBjYW4gb25seSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25z IGluIGEgdGFnLg0KICAgU3BlY2lmaWNhbGx5LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBvciBhcw0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQog ICBOb3RlIHRoYXQgc2VxdWVuY2VzIG9mIHByaXZhdGUgdXNlIGFuZCBleHRlbnNpb24gc3Vi dGFncyBNVVNUIG9jY3VyDQogICBhdCB0aGUgZW5kIG9mIHRoZSBzZXF1ZW5jZSBvZiBzdWJ0 YWdzIGFuZCBNVVNUIE5PVCBiZSBpbnRlcnNwZXJzZWQNCiAgIHdpdGggc3VidGFncyBkZWZp bmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBTaW5nbGUtbGV0dGVyIGFu ZCBzaW5nbGUtZGlnaXQgc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIGN1cnJlbnQgb3INCiAg IGZ1dHVyZSB1c2UuICBUaGVzZSBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgY3VycmVudCB1c2Vz Og0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICBvICBUaGUgc2luZ2xlLWxldHRlciBzdWJ0YWcgJ3gnIGlzIHJlc2VydmVkIHRvIGlu dHJvZHVjZSBhIHNlcXVlbmNlDQogICAgICBvZiBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVGhl IGludGVycHJldGF0aW9uIG9mIGFueSBwcml2YXRlIHVzZQ0KICAgICAgc3VidGFncyBpcyBk ZWZpbmVkIHNvbGVseSBieSBwcml2YXRlIGFncmVlbWVudCBhbmQgaXMgbm90IGRlZmluZWQN CiAgICAgIGJ5IHRoZSBydWxlcyBpbiB0aGlzIHNlY3Rpb24gb3IgaW4gYW55IHN0YW5kYXJk IG9yIHJlZ2lzdHJ5DQogICAgICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8g IEFsbCBvdGhlciBzaW5nbGUtbGV0dGVyIHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGludHJv ZHVjZQ0KICAgICAgc3RhbmRhcmRpemVkIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2VzIGFz IGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlvbiAzLjcuDQoNCiAgIFRoZSBzaW5nbGUtbGV0 dGVyIHN1YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdyYW5kZmF0aGVyZWQgdGFncywgc3Vj aA0KICAgYXMgImktZGVmYXVsdCIsIHdoZXJlIGl0IGFsd2F5cyBhcHBlYXJzIGluIHRoZSBm aXJzdCBwb3NpdGlvbiBhbmQNCiAgIGNhbm5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIGV4dGVu c2lvbi4NCg0KMi4yLjEuICBQcmltYXJ5IExhbmd1YWdlIFN1YnRhZw0KDQogICBUaGUgcHJp bWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMgdGhlIGZpcnN0IHN1YnRhZyBpbiBhIGxhbmd1YWdl IHRhZw0KICAgKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBwcml2YXRlIHVzZSBhbmQgY2VydGFp biBncmFuZGZhdGhlcmVkIHRhZ3MpDQogICBhbmQgY2Fubm90IGJlIG9taXR0ZWQuICBUaGUg Zm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBwcmltYXJ5DQogICBsYW5ndWFnZSBzdWJ0 YWc6DQoNCiAgIDEuICBBbGwgdHdvLWNoYXJhY3RlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRh Z3Mgd2VyZSBkZWZpbmVkIGluIHRoZQ0KICAgICAgIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5n IHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiB0aGUgc3RhbmRhcmQNCiAgICAgICBJU08g NjM5IFBhcnQgMSwgIklTTyA2MzktMToyMDAyLCBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0 aW9uIG9mDQogICAgICAgbmFtZXMgb2YgbGFuZ3VhZ2VzIC0tIFBhcnQgMTogQWxwaGEtMiBj b2RlIiBbSVNPNjM5LTFdLCBvciB1c2luZw0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVl bnRseSBtYWRlIGJ5IHRoZSBJU08gNjM5LTEgcmVnaXN0cmF0aW9uDQogICAgICAgYXV0aG9y aXR5IChSQSkgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDIu ICBBbGwgdGhyZWUtY2hhcmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRl ZmluZWQgaW4gdGhlDQogICAgICAgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFz c2lnbm1lbnRzIGZvdW5kIGluIGVpdGhlciBJU08NCiAgICAgICA2MzkgUGFydCAyLCAiSVNP IDYzOS0yOjE5OTggLSBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAg bmFtZXMgb2YgbGFuZ3VhZ2VzIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAx Ig0KICAgICAgIFtJU082MzktMl0sIElTTyA2MzkgUGFydCAzLCAiQ29kZXMgZm9yIHRoZSBy ZXByZXNlbnRhdGlvbiBvZg0KICAgICAgIG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0IDM6 IEFscGhhLTMgY29kZSBmb3IgY29tcHJlaGVuc2l2ZQ0KICAgICAgIGNvdmVyYWdlIG9mIGxh bmd1YWdlcyIgW0lTTzYzOS0zXSwgb3IgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5DQogICAg ICAgbWFkZSBieSB0aGUgcmVsZXZhbnQgSVNPIDYzOSByZWdpc3RyYXRpb24gYXV0aG9yaXRp ZXMgb3INCiAgICAgICBnb3Zlcm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAg My4gIFRoZSBzdWJ0YWdzIGluIHRoZSByYW5nZSAncWFhJyB0aHJvdWdoICdxdHonIGFyZSBy ZXNlcnZlZCBmb3INCiAgICAgICBwcml2YXRlIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhl c2Ugc3VidGFncyBjb3JyZXNwb25kIHRvIGNvZGVzDQogICAgICAgcmVzZXJ2ZWQgYnkgSVNP IDYzOS0yIGZvciBwcml2YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkDQogICAg ICAgZm9yIG5vbi1yZWdpc3RlcmVkIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyAoaW5zdGVh ZCBvZiB1c2luZw0KICAgICAgIHByaXZhdGUgdXNlIHN1YnRhZ3MgZm9sbG93aW5nICd4LScp LiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC41DQogICAgICAgZm9yIG1vcmUgaW5mb3Jt YXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgNC4gIEFsbCBmb3VyLWNoYXJh Y3RlciBsYW5ndWFnZSBzdWJ0YWdzIGFyZSByZXNlcnZlZCBmb3IgcG9zc2libGUNCiAgICAg ICBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIDUuICBBbGwgbGFuZ3VhZ2Ugc3VidGFn cyBvZiA1IHRvIDggY2hhcmFjdGVycyBpbiBsZW5ndGggaW4gdGhlIElBTkENCiAgICAgICBy ZWdpc3RyeSB3ZXJlIGRlZmluZWQgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBpbiBT ZWN0aW9uIDMuNQ0KICAgICAgIGFuZCBNQVkgYmUgdXNlZCB0byBmb3JtIHRoZSBwcmltYXJ5 IGxhbmd1YWdlIHN1YnRhZy4gIEF0IHRoZSB0aW1lDQogICAgICAgdGhpcyBkb2N1bWVudCB3 YXMgY3JlYXRlZCwgdGhlcmUgd2VyZSBubyBleGFtcGxlcyBvZiB0aGlzIGtpbmQgb2YNCiAg ICAgICBzdWJ0YWcgYW5kIGZ1dHVyZSByZWdpc3RyYXRpb25zIG9mIHRoaXMgdHlwZSB3aWxs IGJlIGRpc2NvdXJhZ2VkOg0KICAgICAgIHByaW1hcnkgbGFuZ3VhZ2VzIGFyZSBzdHJvbmds eSBSRUNPTU1FTkRFRCBmb3IgcmVnaXN0cmF0aW9uIHdpdGgNCiAgICAgICBJU08gNjM5LCBh bmQgcHJvcG9zYWxzIHJlamVjdGVkIGJ5IElTTyA2MzkvUkEgd2lsbCBiZSBjbG9zZWx5DQog ICAgICAgc2NydXRpbml6ZWQgYmVmb3JlIHRoZXkgYXJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5B Lg0KDQogICA2LiAgVGhlIHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFnICd4JyBhcyB0aGUgcHJp bWFyeSBzdWJ0YWcgaW5kaWNhdGVzDQogICAgICAgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIGNv bnNpc3RzIHNvbGVseSBvZiBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMNCiAgICAgICBkZWZp bmVkIGJ5IHByaXZhdGUgYWdyZWVtZW50LiAgRm9yIGV4YW1wbGUsIGluIHRoZSB0YWcgIngt ZnItQ0giLA0KICAgICAgIHRoZSBzdWJ0YWdzICdmcicgYW5kICdDSCcgU0hPVUxEIE5PVCBi ZSB0YWtlbiB0byByZXByZXNlbnQgdGhlDQogICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRo ZSBjb3VudHJ5IG9mIFN3aXR6ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgICBp biB0aGUgSUFOQSByZWdpc3RyeSkgdW5sZXNzIHRoZXJlIGlzIGEgcHJpdmF0ZSBhZ3JlZW1l bnQgaW4NCiAgICAgICBwbGFjZSB0byBkbyBzby4gIFNlZSBTZWN0aW9uIDQuNS4NCg0KICAg Ny4gIFRoZSBzaW5nbGUtY2hhcmFjdGVyIHN1YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdy YW5kZmF0aGVyZWQNCiAgICAgICB0YWdzIChzZWUgU2VjdGlvbiAyLjIuOCkgc3VjaCBhcyAi aS1rbGluZ29uIiBhbmQgImktYm5uIi4gIChPdGhlcg0KICAgICAgIGdyYW5kZmF0aGVyZWQg dGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaW4gdGhlaXIgZmlyc3QNCiAg ICAgICBwb3NpdGlvbi4pDQoNCiAgIDguICBPdGhlciB2YWx1ZXMgTVVTVCBOT1QgYmUgYXNz aWduZWQgdG8gdGhlIHByaW1hcnkgc3VidGFnIGV4Y2VwdCBieQ0KICAgICAgIHJldmlzaW9u IG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBOb3RlOiBGb3IgbGFuZ3VhZ2Vz IHRoYXQgaGF2ZSBib3RoIGFuIElTTyA2MzktMSB0d28tY2hhcmFjdGVyIGNvZGUNCiAgIGFu ZCBhIHRocmVlIGNoYXJhY3RlciBjb2RlIGFzc2lnbmVkIGJ5IGVpdGhlciBJU08gNjM5LTIg b3IgSVNPIDY5My0zLA0KICAgb25seSB0aGUgSVNPIDYzOS0xIHR3by1jaGFyYWN0ZXIgY29k ZSBpcyBkZWZpbmVkIGluIHRoZSBJQU5BDQogICByZWdpc3RyeS4NCg0KICAgTm90ZTogRm9y IGxhbmd1YWdlcyB0aGF0IGhhdmUgbm8gSVNPIDYzOS0xIHR3by1jaGFyYWN0ZXIgY29kZSBh bmQgZm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1QgKFRlcm1pbm9sb2d5KSBjb2RlIGFu ZCB0aGUgSVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGljKSBjb2RlcyBkaWZmZXIsIG9u bHkgdGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0KICAgdGhlIElBTkEgcmVn aXN0cnkuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCBhbGwNCiAg IGxhbmd1YWdlcyB0aGF0IGhhZCBib3RoIGtpbmRzIG9mIHRocmVlLWNoYXJhY3RlciBjb2Rl IHdlcmUgYWxzbw0KICAgYXNzaWduZWQgYSB0d28tY2hhcmFjdGVyIGNvZGU7IGl0IGlzIGV4 cGVjdGVkIHRoYXQgZnV0dXJlIGFzc2lnbm1lbnRzDQogICBvZiB0aGlzIG5hdHVyZSB3aWxs IG5vdCBvY2N1ci4NCg0KICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9u aW5nIGFuZCBzdWJ0YWcgY2hvaWNlIGFzDQogICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRy YW5zaXRpb24gYmV0d2VlbiBSRkMgMTc2NiBhbmQgUkZDIDMwNjYsIGFzDQogICB3ZWxsIGFz IHRoZSBjYW5vbmljYWwgbmF0dXJlIG9mIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3Vt ZW50LCB0aGUNCiAgIElTTyA2MzkgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZp c29yeSBDb21taXR0ZWUgKElTTyA2MzkvDQogICBSQS1KQUMpIGhhcyBpbmNsdWRlZCB0aGUg Zm9sbG93aW5nIHN0YXRlbWVudCBpbiBbaXNvNjM5LnByaW5dOg0KDQogICAgICAiQSBsYW5n dWFnZSBjb2RlIGFscmVhZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemlu ZyBJU08NCiAgICAgIDYzOS0xIHNoYWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJU08gNjM5 LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3Zl ciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0ZWQgaW4NCiAgICAgIEludGVybmV0IGFw cGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29kZSB3aGVuIGFuIGFscGhhLTIN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K ICAgICAgY29kZSBmb3IgdGhhdCBsYW5ndWFnZSBpcyBub3QgYXZhaWxhYmxlLiINCg0KICAg SW4gb3JkZXIgdG8gYXZvaWQgaW5zdGFiaWxpdHkgaW4gdGhlIGNhbm9uaWNhbCBmb3JtIG9m IHRhZ3MsIGlmIGENCiAgIHR3by1jaGFyYWN0ZXIgY29kZSBpcyBhZGRlZCB0byBJU08gNjM5 LTEgZm9yIGEgbGFuZ3VhZ2UgZm9yIHdoaWNoIGENCiAgIHRocmVlLWNoYXJhY3RlciBjb2Rl IHdhcyBhbHJlYWR5IGluY2x1ZGVkIGluIGVpdGhlciBJU08gNjM5LTIgb3IgSVNPDQogICA2 MzktMywgdGhlIHR3by1jaGFyYWN0ZXIgY29kZSBNVVNUIE5PVCBiZSByZWdpc3RlcmVkLiAg U2VlDQogICBTZWN0aW9uIDMuNC4NCg0KICAgRm9yIGV4YW1wbGUsIGlmIHNvbWUgY29udGVu dCB3ZXJlIHRhZ2dlZCB3aXRoICdoYXcnIChIYXdhaWlhbiksIHdoaWNoDQogICBjdXJyZW50 bHkgaGFzIG5vIHR3by1jaGFyYWN0ZXIgY29kZSwgdGhlIHRhZyB3b3VsZCBub3QgYmUgaW52 YWxpZGF0ZWQNCiAgIGlmIElTTyA2MzktMSB3ZXJlIHRvIGFzc2lnbiBhIHR3by1jaGFyYWN0 ZXIgY29kZSB0byB0aGUgSGF3YWlpYW4NCiAgIGxhbmd1YWdlIGF0IGEgbGF0ZXIgZGF0ZS4N Cg0KICAgTm90ZTogQW4gZXhhbXBsZSBvZiBpbmRlcGVuZGVudCBwcmltYXJ5IGxhbmd1YWdl IHN1YnRhZyByZWdpc3RyYXRpb24NCiAgIG1pZ2h0IGluY2x1ZGU6IG9uZSBvZiB0aGUgZ3Jh bmRmYXRoZXJlZCBJQU5BIHJlZ2lzdHJhdGlvbnMgaXMNCiAgICJpLWVub2NoaWFuIi4gIFRo ZSBzdWJ0YWcgJ2Vub2NoaWFuJyBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BDQog ICByZWdpc3RyeSBhcyBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWluZyB0aGF0 IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lzdGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3QpLCBt YWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1BUSIgYW5kDQogICAiZW5vY2hpYW4tTGF0 biIgdmFsaWQuDQoNCjIuMi4yLiAgRXh0ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncw0KDQogICBF eHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFyZSB1c2VkIHRvIGlkZW50aWZ5IGxhbmd1YWdl cyB0aGF0IGFyZQ0KICAgZW5jb21wYXNzZWQgYnkgYSAibWFjcm9sYW5ndWFnZSIuICBJU08g NjM5LTMgZGVmaW5lcyBjZXJ0YWluDQogICBsYW5ndWFnZXMgdG8gYmUgIm1hY3JvbGFuZ3Vh Z2VzIjsgdGhhdCBpcywgdGhleSBhcmUgZ3JvdXBzIG9mIHZlcnkNCiAgIGNsb3NlbHkgcmVs YXRlZCBsYW5ndWFnZXMgd2hpY2ggYXJlIHRyZWF0ZWQgYXMgYSBzaW5nbGUgbGFuZ3VhZ2Ug aW4NCiAgIGNlcnRhaW4gY29udGV4dHMuICBJbiBvcmRlciB0byBpbXByb3ZlIG1hdGNoaW5n IGJlaGF2aW9yIGFuZCB0YWdnaW5nDQogICBjb25zaXN0ZW5jeSwgZWFjaCBsYW5ndWFnZSBl bmNvbXBhc3NlZCBieSBhIElTTyA2OTMtMyBtYWNyb2xhbmd1YWdlDQogICBpcyByZXByZXNl bnRlZCBpbiB0aGUgSUFOQSByZWdpc3RyeSB1c2luZyBhbiBleHRlbmRlZCBsYW5ndWFnZQ0K ICAgc3VidGFnLCBwcm92aWRlZCB0aGF0IGl0IGlzIG5vdCBhbHJlYWR5IHJlcHJlc2VudGVk IHVzaW5nIGEgbGFuZ3VhZ2UNCiAgIHN1YnRhZy4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBw bHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoNCiAgIDEuICBUaGVzZSBz dWJ0YWdzIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8N CiAgICAgICBhc3NpZ25tZW50cyBmb3VuZCBpbiBJU08gNjM5IFBhcnQgMy4NCg0KICAgMi4g IEEgc2VxdWVuY2Ugb2YgdXAgdG8gdGhyZWUgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBN QVkgYXBwZWFyIGluDQogICAgICAgYSBsYW5ndWFnZSB0YWcuICBUaGlzIHNlcXVlbmNlIE1V U1QgZm9sbG93IHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFuZCBwcmVj ZWRlIGFueSBvdGhlciBzdWJ0YWdzLg0KDQogICAzLiAgRWFjaCBleHRlbmRlZCBsYW5ndWFn ZSBzdWJ0YWcgTVVTVCBvbmx5IGJlIHVzZWQgd2l0aCB0aGUgZXhhY3QNCiAgICAgICBzZXF1 ZW5jZSBvZiBzdWJ0YWdzIHRoYXQgYXBwZWFycyBpbiB0aGUgJ1ByZWZpeCcgZmllbGQgaW4g aXRzDQogICAgICAgcmVnaXN0cnkgcmVjb3JkLg0KDQogICA0LiAgVGhlcmUgTUFZIGJlIHVw IHRvIHRocmVlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MuDQoNCiAgIDUuICBPdGhlciB2 YWx1ZXMgTVVTVCBOT1QgYmUgYXNzaWduZWQgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1 YnRhZw0KICAgICAgIGV4Y2VwdCBieSByZXZpc2lvbiBvciB1cGRhdGUgb2YgdGhpcyBkb2N1 bWVudC4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIw MDcNCg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcmVjb3JkcyBNVVNUIGluY2x1 ZGUgZXhhY3RseSBvbmUgJ1ByZWZpeCcNCiAgIGZpZWxkIGluZGljYXRpbmcgYW4gYXBwcm9w cmlhdGUgc3VidGFnIG9yIHNlcXVlbmNlIG9mIHN1YnRhZ3MgZm9yDQogICB0aGF0IGV4dGVu ZGVkIGxhbmd1YWdlIHN1YnRhZy4NCg0KICAgRm9yIGV4YW1wbGUsIHRoZSAnZ2FuJyBhbmQg J2Ntbicgc3VidGFncyByZXByZXNlbnQgdGhlIGxhbmd1YWdlcyBHYW4NCiAgIENoaW5lc2Ug YW5kIE1hbmRhcmluIENoaW5lc2UuICBFYWNoIGlzIGVuY29tcGFzc2VkIGJ5IHRoZQ0KICAg bWFjcm9sYW5ndWFnZSAnemgnIChDaGluZXNlKS4gIFRoZXJlZm9yZSwgdGhleSBib3RoIGhh dmUgdGhlIHByZWZpeA0KICAgInpoIiBpbiB0aGVpciByZWdpc3RyeSByZWNvcmRzLiAgQ29u c2VxdWVudGx5LCBHYW4gQ2hpbmVzZSBpcw0KICAgcmVwcmVzZW50ZWQgYXMgInpoLWdhbiIg YW5kIE1hbmRhcmluIENoaW5lc2UgYXMgInpoLWNtbiIuICBUaGUNCiAgIGxhbmd1YWdlIHN1 YnRhZyAnemgnIGNhbiBzdGlsbCBiZSB1c2VkIHdpdGhvdXQgYW4gZXh0ZW5kZWQgbGFuZ3Vh Z2UNCiAgIHN1YnRhZyB0byBsYWJlbCBhIHJlc291cmNlIGFzIHNvbWUgdW5zcGVjaWZpZWQg dmFyaWV0eSBvZiBDaGluZXNlDQogICAod2hpY2ggaW4gcHJhY3RpY2Ugd2lsbCB1c3VhbGx5 IGJlIE1hbmRhcmluLCB0aGUgZG9taW5hbnQgdmFyaWV0eSBvZg0KICAgQ2hpbmVzZSwgYnV0 IG1pZ2h0IGFsc28gYmUgc29tZSBvdGhlciB2YXJpZXR5KS4NCg0KICAgTm93IHN1cHBvc2Ug dGhhdCwgaW4gdGhlIGZ1dHVyZSwgdGhlIElTTyA2MzktMyBSZWdpc3RyYXRpb24gQXV0aG9y aXR5DQogICB3ZXJlIHRvIGRlY2lkZSB0aGF0IEdhbiBDaGluZXNlIGlzIGFjdHVhbGx5IHR3 byBkaWZmZXJlbnQgY2xvc2VseQ0KICAgcmVsYXRlZCBsYW5ndWFnZXM6IGl0IG1pZ2h0IHJl Y2xhc3NpZnkgJ2dhbicgYXMgYSBtYWNyb2xhbmd1YWdlIGFuZA0KICAgaW50cm9kdWNlIHR3 byBuZXcgY29kZSBlbGVtZW50cy4gIEluIHRoYXQgY2FzZSwgdGhlc2UgY29kZSBlbGVtZW50 cw0KICAgd291bGQgYmUgYWRkZWQgdG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgZXh0ZW5kZWQg bGFuZ3VhZ2Ugc3VidGFncyB3aXRoDQogICBwcmVmaXhlcyBvZiAiemgtZ2FuIi4gIE5vIGNo YW5nZSB3b3VsZCBiZSBtYWRlIHRvIHRoZSByZWdpc3RyeSByZWNvcmQNCiAgIGZvciAnZ2Fu Jy4NCg0KMi4yLjMuICBTY3JpcHQgU3VidGFnDQoNCiAgIFNjcmlwdCBzdWJ0YWdzIGFyZSB1 c2VkIHRvIGluZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0NCiAgIHZhcmlh dGlvbnMgdGhhdCBkaXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBvZiBhIGxhbmd1YWdl IG9yIGl0cw0KICAgZGlhbGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRo ZSBzY3JpcHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCBmb3VyLWNoYXJhY3RlciBzdWJ0YWdz IHdlcmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29kZXMg Zm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRz IjogYWxwaGEtNCBzY3JpcHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0 aGUNCiAgICAgICBJU08gMTU5MjQgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBz dGFuZGFyZGl6YXRpb24gYm9kaWVzLA0KICAgICAgIGRlbm90aW5nIHRoZSBzY3JpcHQgb3Ig d3JpdGluZyBzeXN0ZW0gdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoDQogICAgICAgdGhpcyBs YW5ndWFnZS4NCg0KICAgMi4gIFNjcmlwdCBzdWJ0YWdzIE1VU1QgaW1tZWRpYXRlbHkgZm9s bG93IHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFuZCBhbGwgZXh0ZW5k ZWQgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUNCiAgICAgICBhbnkg b3RoZXIgdHlwZSBvZiBzdWJ0YWcgZGVzY3JpYmVkIGJlbG93Lg0KDQogICAzLiAgVGhlIHNj cmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBhcmUgcmVzZXJ2ZWQgZm9yIHBy aXZhdGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29y cmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAxNTkyNCBmb3IgcHJp dmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0KICAgICAgIHJl Z2lzdGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNSBm b3IgbW9yZQ0KICAgICAgIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoN CiAgIDQuICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIHVzaW5nIHRo ZSBwcm9jZXNzIGluDQogICAgICAgU2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudC4gIFZh cmlhbnQgc3VidGFncyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRp b24gZm9yIHRoYXQgcHVycG9zZS4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICBBcHJpbCAyMDA3DQoNCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUg c2NyaXB0IHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZywgYW5kDQogICAgICAgdGhlIHNjcmlw dCBzdWJ0YWcgU0hPVUxEIGJlIG9taXR0ZWQgd2hlbiBpdCBhZGRzIG5vDQogICAgICAgZGlz dGluZ3Vpc2hpbmcgdmFsdWUgdG8gdGhlIHRhZyBvciB3aGVuIHRoZSBwcmltYXJ5IGxhbmd1 YWdlDQogICAgICAgc3VidGFnJ3MgcmVjb3JkIGluY2x1ZGVzIGEgU3VwcHJlc3MtU2NyaXB0 IGZpZWxkIGxpc3RpbmcgdGhlDQogICAgICAgYXBwbGljYWJsZSBzY3JpcHQgc3VidGFnLg0K DQogICBFeGFtcGxlOiAic3ItTGF0biIgcmVwcmVzZW50cyBTZXJiaWFuIHdyaXR0ZW4gdXNp bmcgdGhlIExhdGluIHNjcmlwdC4NCg0KMi4yLjQuICBSZWdpb24gU3VidGFnDQoNCiAgIFJl Z2lvbiBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIGxpbmd1aXN0aWMgdmFyaWF0aW9u cyBhc3NvY2lhdGVkDQogICB3aXRoIG9yIGFwcHJvcHJpYXRlIHRvIGEgc3BlY2lmaWMgY291 bnRyeSwgdGVycml0b3J5LCBvciByZWdpb24uDQogICBUeXBpY2FsbHksIGEgcmVnaW9uIHN1 YnRhZyBpcyB1c2VkIHRvIGluZGljYXRlIHJlZ2lvbmFsIGRpYWxlY3RzIG9yDQogICB1c2Fn ZSwgb3IgcmVnaW9uLXNwZWNpZmljIHNwZWxsaW5nIGNvbnZlbnRpb25zLiAgQSByZWdpb24g c3VidGFnIGNhbg0KICAgYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgY29udGVudCBp cyBleHByZXNzZWQgaW4gYSB3YXkgdGhhdCBpcw0KICAgYXBwcm9wcmlhdGUgZm9yIHVzZSB0 aHJvdWdob3V0IGEgcmVnaW9uLCBmb3IgaW5zdGFuY2UsIFNwYW5pc2gNCiAgIGNvbnRlbnQg dGFpbG9yZWQgdG8gYmUgdXNlZnVsIHRocm91Z2hvdXQgTGF0aW4gQW1lcmljYS4NCg0KICAg VGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAg IDEuICBSZWdpb24gc3VidGFncyBNVVNUIGZvbGxvdyBhbnkgbGFuZ3VhZ2UsIGV4dGVuZGVk IGxhbmd1YWdlLCBvcg0KICAgICAgIHNjcmlwdCBzdWJ0YWdzIGFuZCBNVVNUIHByZWNlZGUg YWxsIG90aGVyIHN1YnRhZ3MuDQoNCiAgIDIuICBBbGwgdHdvLWNoYXJhY3RlciBzdWJ0YWdz IGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZQ0KICAgICAgIGRlZmluZWQgaW4g dGhlIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZA0K ICAgICAgIGluIFtJU08zMTY2LTFdICgiQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBv ZiBuYW1lcyBvZg0KICAgICAgIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0t IFBhcnQgMTogQ291bnRyeSBjb2RlcyIpIHVzaW5nDQogICAgICAgdGhlIGxpc3Qgb2YgYWxw aGEtMiBjb3VudHJ5IGNvZGVzLCBvciB1c2luZyBhc3NpZ25tZW50cw0KICAgICAgIHN1YnNl cXVlbnRseSBtYWRlIGJ5IHRoZSBJU08gMzE2NiBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292 ZXJuaW5nDQogICAgICAgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAgMy4gIEFsbCB0 aHJlZS1jaGFyYWN0ZXIgc3VidGFncyBjb25zaXN0aW5nIG9mIGRpZ2l0IChudW1lcmljKQ0K ICAgICAgIGNoYXJhY3RlcnMgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyB3ZXJlIGRl ZmluZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFz c2lnbm1lbnRzIGZvdW5kIGluIFVOIFN0YW5kYXJkDQogICAgICAgQ291bnRyeSBvciBBcmVh IENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UgW1VOX00uNDldIG9yDQogICAgICAgYXNzaWdu bWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIGdvdmVybmluZyBzdGFuZGFyZHMgYm9k eS4NCiAgICAgICBOb3RlIHRoYXQgbm90IGFsbCBvZiB0aGUgVU4gTS40OSBjb2RlcyBhcmUg ZGVmaW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5LiAgVGhlIGZvbGxvd2luZyBy dWxlcyBkZWZpbmUgd2hpY2ggY29kZXMgYXJlIGVudGVyZWQNCiAgICAgICBpbnRvIHRoZSBy ZWdpc3RyeSBhcyB2YWxpZCBzdWJ0YWdzOg0KDQogICAgICAgQS4gIFVOIG51bWVyaWMgY29k ZXMgYXNzaWduZWQgdG8gJ21hY3JvLWdlb2dyYXBoaWNhbA0KICAgICAgICAgICAoY29udGlu ZW50YWwpJyBvciBzdWItcmVnaW9ucyBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlDQogICAg ICAgICAgIHJlZ2lzdHJ5LiAgVGhlc2UgY29kZXMgYXJlIG5vdCBhc3NvY2lhdGVkIHdpdGgg YW4gYXNzaWduZWQNCiAgICAgICAgICAgSVNPIDMxNjYgYWxwaGEtMiBjb2RlIGFuZCByZXBy ZXNlbnQgc3VwcmEtbmF0aW9uYWwgYXJlYXMsDQogICAgICAgICAgIHVzdWFsbHkgY292ZXJp bmcgbW9yZSB0aGFuIG9uZSBuYXRpb24sIHN0YXRlLCBwcm92aW5jZSwgb3INCiAgICAgICAg ICAgdGVycml0b3J5Lg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBp cmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA3DQoNCg0KICAgICAgIEIuICBVTiBudW1lcmljIGNvZGVzIGZvciAnZWNv bm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXINCiAgICAgICAgICAgZ3JvdXBpbmdzJyBNVVNU IE5PVCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZA0KICAgICAgICAg ICBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEMu ICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2l0aCBhbWJpZ3Vv dXMgSVNPDQogICAgICAgICAgIDMxNjYgYWxwaGEtMiBjb2Rlcywgd2hlbiBlbnRlcmVkIGlu dG8gdGhlIHJlZ2lzdHJ5LCBNVVNUIGJlDQogICAgICAgICAgIGRlZmluZWQgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBpbiBTZWN0aW9uIDMuNCBhbmQgTVVTVCBiZQ0KICAgICAgICAgICB1 c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB0aGF0IHJlcHJlc2VudCB0aGUgY291bnRyeSBv cg0KICAgICAgICAgICByZWdpb24gZm9yIHdoaWNoIHRoZXkgYXJlIGRlZmluZWQuDQoNCiAg ICAgICBELiAgVU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIGZvciB3 aGljaCB0aGVyZSBpcyBhbg0KICAgICAgICAgICBhc3NvY2lhdGVkIElTTyAzMTY2IGFscGhh LTIgY29kZSBpbiB0aGUgcmVnaXN0cnkgTVVTVCBOT1QgYmUNCiAgICAgICAgICAgZW50ZXJl ZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtDQogICAg ICAgICAgIGxhbmd1YWdlIHRhZ3MuICBOb3RlIHRoYXQgdGhlIElTTyAzMTY2LWJhc2VkIHN1 YnRhZyBpbiB0aGUNCiAgICAgICAgICAgcmVnaXN0cnkgTVVTVCBhY3R1YWxseSBiZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIFVOIE0uNDkgY29kZSBpbg0KICAgICAgICAgICBxdWVzdGlvbi4N Cg0KICAgICAgIEUuICBVTiBudW1lcmljIGNvZGVzIGFuZCBJU08gMzE2NiBhbHBoYS0yIGNv ZGVzIGZvciBjb3VudHJpZXMgb3INCiAgICAgICAgICAgYXJlYXMgbGlzdGVkIGFzIGVsaWdp YmxlIGZvciByZWdpc3RyYXRpb24gaW4gW1JGQzQ2NDVdIGJ1dA0KICAgICAgICAgICBub3Qg cHJlc2VudGx5IHJlZ2lzdGVyZWQgTUFZIGJlIGVudGVyZWQgaW50byB0aGUgSUFOQQ0KICAg ICAgICAgICByZWdpc3RyeSB2aWEgdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24g My41LiAgT25jZQ0KICAgICAgICAgICByZWdpc3RlcmVkLCB0aGVzZSBjb2RlcyBNQVkgYmUg dXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQoNCiAgICAgICBGLiAgQWxsIG90aGVyIFVO IG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB0aGF0IGRvIG5vdA0KICAg ICAgICAgICBoYXZlIGFuIGFzc29jaWF0ZWQgSVNPIDMxNjYgYWxwaGEtMiBjb2RlIE1VU1Qg Tk9UIGJlIGVudGVyZWQNCiAgICAgICAgICAgaW50byB0aGUgcmVnaXN0cnkgYW5kIE1VU1Qg Tk9UIGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzLg0KICAgICAgICAgICBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGVzZSBjb2Rlcywgc2VlIFNlY3Rpb24gMy40Lg0KDQog ICA0LiAgTm90ZTogVGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRo ZSBVTiBkb2N1bWVudA0KICAgICAgIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUgcmVn aXN0cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8NCiAgICAgICBmb3JtIGxhbmd1YWdlIHRh Z3MuICAoQXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwNCiAgICAgICB0 aGVzZSB2YWx1ZXMgbWF0Y2hlZCB0aGUgSVNPIDMxNjYgYWxwaGEtMiBjb2Rlcy4pDQoNCiAg IDUuICBUaGVyZSBNVVNUIGJlIGF0IG1vc3Qgb25lIHJlZ2lvbiBzdWJ0YWcgaW4gYSBsYW5n dWFnZSB0YWcgYW5kIHRoZQ0KICAgICAgIHJlZ2lvbiBzdWJ0YWcgTUFZIGJlIG9taXR0ZWQs IGFzIHdoZW4gaXQgYWRkcyBubyBkaXN0aW5ndWlzaGluZw0KICAgICAgIHZhbHVlIHRvIHRo ZSB0YWcuDQoNCiAgIDYuICBUaGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywgJ1FNJy0nUVonLCAn WEEnLSdYWicsIGFuZCAnWlonIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBwcml2YXRlIHVz ZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncw0KICAgICAgIGNvcnJlc3BvbmQg dG8gY29kZXMgcmVzZXJ2ZWQgYnkgSVNPIDMxNjYgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UN CiAgICAgICBjb2RlcyBNQVkgYmUgdXNlZCBmb3IgcHJpdmF0ZSB1c2UgcmVnaW9uIHN1YnRh Z3MgKGluc3RlYWQgb2YNCiAgICAgICB1c2luZyBhIHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1 ZW5jZSkuICBQbGVhc2UgcmVmZXIgdG8NCiAgICAgICBTZWN0aW9uIDQuNSBmb3IgbW9yZSBp bmZvcm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0KDQogICAiZGUtQ0giIHJlcHJl c2VudHMgR2VybWFuICgnZGUnKSBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kICgnQ0gnKS4NCg0K ICAgInNyLUxhdG4tUlMiIHJlcHJlc2VudHMgU2VyYmlhbiAoJ3NyJykgd3JpdHRlbiB1c2lu ZyBMYXRpbiBzY3JpcHQNCiAgICgnTGF0bicpIGFzIHVzZWQgaW4gU2VyYmlhICgnUlMnKS4N Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K ICAgImVzLTQxOSIgcmVwcmVzZW50cyBTcGFuaXNoICgnZXMnKSBhcHByb3ByaWF0ZSB0byB0 aGUgVU4tZGVmaW5lZA0KICAgTGF0aW4gQW1lcmljYSBhbmQgQ2FyaWJiZWFuIHJlZ2lvbiAo JzQxOScpLg0KDQoyLjIuNS4gIFZhcmlhbnQgU3VidGFncw0KDQogICBWYXJpYW50IHN1YnRh Z3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgYWRkaXRpb25hbCwgd2VsbC1yZWNvZ25pemVkDQog ICB2YXJpYXRpb25zIHRoYXQgZGVmaW5lIGEgbGFuZ3VhZ2Ugb3IgaXRzIGRpYWxlY3RzIHRo YXQgYXJlIG5vdA0KICAgY292ZXJlZCBieSBvdGhlciBhdmFpbGFibGUgc3VidGFncy4gIFRo ZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlDQogICB2YXJpYW50IHN1YnRhZ3M6DQoN CiAgIDEuICBWYXJpYW50IHN1YnRhZ3MgYXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGV4 dGVybmFsIHN0YW5kYXJkLg0KICAgICAgIFZhcmlhbnQgc3VidGFncyBhbmQgdGhlaXIgbWVh bmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlDQogICAgICAgcmVnaXN0cmF0aW9uIHByb2Nlc3Mg ZGVmaW5lZCBpbiBTZWN0aW9uIDMuNS4NCg0KICAgMi4gIFZhcmlhbnQgc3VidGFncyBNVVNU IGZvbGxvdyBhbGwgb2YgdGhlIG90aGVyIGRlZmluZWQgc3VidGFncywgYnV0DQogICAgICAg cHJlY2VkZSBhbnkgZXh0ZW5zaW9uIG9yIHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMu DQoNCiAgIDMuICBNb3JlIHRoYW4gb25lIHZhcmlhbnQgTUFZIGJlIHVzZWQgdG8gZm9ybSB0 aGUgbGFuZ3VhZ2UgdGFnLg0KDQogICA0LiAgVmFyaWFudCBzdWJ0YWdzIE1VU1QgYmUgcmVn aXN0ZXJlZCB3aXRoIElBTkEgYWNjb3JkaW5nIHRvIHRoZQ0KICAgICAgIHJ1bGVzIGluIFNl Y3Rpb24gMy41IG9mIHRoaXMgZG9jdW1lbnQgYmVmb3JlIGJlaW5nIHVzZWQgdG8gZm9ybQ0K ICAgICAgIGxhbmd1YWdlIHRhZ3MuICBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCB2YXJpYW50 cyBmcm9tIG90aGVyIHR5cGVzDQogICAgICAgb2Ygc3VidGFncywgcmVnaXN0cmF0aW9ucyBN VVNUIG1lZXQgdGhlIGZvbGxvd2luZyBsZW5ndGggYW5kDQogICAgICAgY29udGVudCByZXN0 cmljdGlvbnM6DQoNCiAgICAgICAxLiAgVmFyaWFudCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0 aCBhIGxldHRlciAoYS16LCBBLVopIE1VU1QgYmUNCiAgICAgICAgICAgYXQgbGVhc3QgZml2 ZSBjaGFyYWN0ZXJzIGxvbmcuDQoNCiAgICAgICAyLiAgVmFyaWFudCBzdWJ0YWdzIHRoYXQg YmVnaW4gd2l0aCBhIGRpZ2l0ICgwLTkpIE1VU1QgYmUgYXQNCiAgICAgICAgICAgbGVhc3Qg Zm91ciBjaGFyYWN0ZXJzIGxvbmcuDQoNCiAgIFZhcmlhbnQgc3VidGFnIHJlY29yZHMgaW4g dGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBNQVkgaW5jbHVkZQ0KICAgb25lIG9yIG1v cmUgJ1ByZWZpeCcgZmllbGRzLCB3aGljaCBpbmRpY2F0ZSB0aGUgbGFuZ3VhZ2UgdGFnIG9y IHRhZ3MNCiAgIHRoYXQgd291bGQgbWFrZSBhIHN1aXRhYmxlIHByZWZpeCAod2l0aCBvdGhl ciBzdWJ0YWdzLCBhcw0KICAgYXBwcm9wcmlhdGUpIGluIGZvcm1pbmcgYSBsYW5ndWFnZSB0 YWcgd2l0aCB0aGUgdmFyaWFudC4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHN1YnRhZyAnbmVk aXMnIGhhcyBhIFByZWZpeCBvZiAic2wiLCBtYWtpbmcgaXQgc3VpdGFibGUNCiAgIHRvIGZv cm0gbGFuZ3VhZ2UgdGFncyBzdWNoIGFzICJzbC1uZWRpcyIgYW5kICJzbC1JVC1uZWRpcyIs IGJ1dCBub3QNCiAgIHN1aXRhYmxlIGZvciB1c2UgaW4gYSB0YWcgc3VjaCBhcyAiemgtbmVk aXMiIG9yICJpdC1JVC1uZWRpcyIuDQoNCiAgICJzbC1uZWRpcyIgcmVwcmVzZW50cyB0aGUg TmF0aXNvbmUgb3IgTmFkaXphIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLg0KDQogICAiZGUtQ0gt MTk5NiIgcmVwcmVzZW50cyBHZXJtYW4gYXMgdXNlZCBpbiBTd2l0emVybGFuZCBhbmQgYXMg d3JpdHRlbg0KICAgdXNpbmcgdGhlIHNwZWxsaW5nIHJlZm9ybSBiZWdpbm5pbmcgaW4gdGhl IHllYXIgMTk5NiBDLkUuDQoNCiAgIE1vc3QgdmFyaWFudHMgdGhhdCBzaGFyZSBhIHByZWZp eCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAgRm9yDQogICBleGFtcGxlLCB0aGUgR2VybWFu IG9ydGhvZ3JhcGhpYyB2YXJpYXRpb25zICcxOTk2JyBhbmQgJzE5MDEnIFNIT1VMRA0KICAg Tk9UIGJlIHVzZWQgaW4gdGhlIHNhbWUgdGFnLCBhcyB0aGV5IHJlcHJlc2VudCB0aGUgZGF0 ZXMgb2YgZGlmZmVyZW50DQogICBzcGVsbGluZyByZWZvcm1zLiAgQSB2YXJpYW50IHRoYXQg Y2FuIG1lYW5pbmdmdWxseSBiZSB1c2VkIGluDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxNV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIGNvbWJpbmF0aW9uIHdpdGggYW5vdGhl ciB2YXJpYW50IFNIT1VMRCBpbmNsdWRlIGEgJ1ByZWZpeCcgZmllbGQgaW4NCiAgIGl0cyBy ZWdpc3RyeSByZWNvcmQgdGhhdCBsaXN0cyB0aGF0IG90aGVyIHZhcmlhbnQuICBGb3IgZXhh bXBsZSwgaWYNCiAgIGFub3RoZXIgR2VybWFuIHZhcmlhbnQgJ2V4YW1wbGUnIHdlcmUgY3Jl YXRlZCB0aGF0IG1hZGUgc2Vuc2UgdG8gdXNlDQogICB3aXRoICcxOTk2JywgdGhlbiAnZXhh bXBsZScgc2hvdWxkIGluY2x1ZGUgdHdvIFByZWZpeCBmaWVsZHM6ICJkZSINCiAgIGFuZCAi ZGUtMTk5NiIuDQoNCjIuMi42LiAgRXh0ZW5zaW9uIFN1YnRhZ3MNCg0KICAgRXh0ZW5zaW9u cyBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciBleHRlbmRpbmcgbGFuZ3VhZ2UgdGFncyBmb3Ig dXNlIGluDQogICB2YXJpb3VzIGFwcGxpY2F0aW9ucy4gIFNlZSBTZWN0aW9uIDMuNy4gIFRo ZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8NCiAgIGV4dGVuc2lvbnM6DQoNCiAgIDEuICAg RXh0ZW5zaW9uIHN1YnRhZ3MgYXJlIHNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBzdWJ0YWdz IGRlZmluZWQNCiAgICAgICAgaW4gdGhpcyBkb2N1bWVudCBieSBhIHNpbmdsZS1jaGFyYWN0 ZXIgc3VidGFnICgic2luZ2xldG9uIikuDQogICAgICAgIFRoZSBzaW5nbGV0b24gTVVTVCBi ZSBvbmUgYWxsb2NhdGVkIHRvIGEgcmVnaXN0cmF0aW9uIGF1dGhvcml0eQ0KICAgICAgICB2 aWEgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjcgYW5kIE1VU1QgTk9U IGJlIHRoZQ0KICAgICAgICBsZXR0ZXIgJ3gnLCB3aGljaCBpcyByZXNlcnZlZCBmb3IgcHJp dmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlcy4NCg0KICAgMi4gICBOb3RlOiBQcml2YXRlIHVz ZSBzdWJ0YWcgc2VxdWVuY2VzIHN0YXJ0aW5nIHdpdGggdGhlIHNpbmdsZXRvbg0KICAgICAg ICBzdWJ0YWcgJ3gnIGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjIuNyBiZWxvdy4NCg0K ICAgMy4gICBBbiBleHRlbnNpb24gTVVTVCBmb2xsb3cgYXQgbGVhc3QgYSBwcmltYXJ5IGxh bmd1YWdlIHN1YnRhZy4NCiAgICAgICAgVGhhdCBpcywgYSBsYW5ndWFnZSB0YWcgY2Fubm90 IGJlZ2luIHdpdGggYW4gZXh0ZW5zaW9uLg0KICAgICAgICBFeHRlbnNpb25zIGV4dGVuZCBs YW5ndWFnZSB0YWdzLCB0aGV5IGRvIG5vdCBvdmVycmlkZSBvciByZXBsYWNlDQogICAgICAg IHRoZW0uICBGb3IgZXhhbXBsZSwgImEtdmFsdWUiIGlzIG5vdCBhIHdlbGwtZm9ybWVkIGxh bmd1YWdlIHRhZywNCiAgICAgICAgd2hpbGUgImRlLWEtdmFsdWUiIGlzLg0KDQogICA0LiAg IEVhY2ggc2luZ2xldG9uIHN1YnRhZyBNVVNUIGFwcGVhciBhdCBtb3N0IG9uZSB0aW1lIGlu IGVhY2ggdGFnDQogICAgICAgIChvdGhlciB0aGFuIGFzIGEgcHJpdmF0ZSB1c2Ugc3VidGFn KS4gIFRoYXQgaXMsIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJl cGVhdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVuLWEtYmJiLWEtDQogICAgICAgIGNj YyIgaXMgaW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2EnIGFwcGVhcnMgdHdpY2UuICBO b3RlIHRoYXQNCiAgICAgICAgdGhlIHRhZyAiZW4tYS1iYmIteC1hLWNjYyIgaXMgdmFsaWQg YmVjYXVzZSB0aGUgc2Vjb25kDQogICAgICAgIGFwcGVhcmFuY2Ugb2YgdGhlIHNpbmdsZXRv biAnYScgaXMgaW4gYSBwcml2YXRlIHVzZSBzZXF1ZW5jZS4NCg0KICAgNS4gICBFeHRlbnNp b24gc3VidGFncyBNVVNUIG1lZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0K ICAgICAgICBjb250ZW50IGFuZCBmb3JtYXQgb2Ygc3VidGFncyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQuDQoNCiAgIDYuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRl dmVyIHJlcXVpcmVtZW50cyBhcmUgc2V0IGJ5IHRoZQ0KICAgICAgICBkb2N1bWVudCB0aGF0 IGRlZmluZXMgdGhlaXIgc2luZ2xldG9uIHByZWZpeCBhbmQgd2hhdGV2ZXINCiAgICAgICAg cmVxdWlyZW1lbnRzIGFyZSBwcm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5 Lg0KDQogICA3LiAgIEVhY2ggZXh0ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRv IGVpZ2h0IGNoYXJhY3RlcnMgbG9uZw0KICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2Yg bGV0dGVycyBvciBkaWdpdHMsIHdpdGggZWFjaCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVk IGJ5IGEgc2luZ2xlICctJy4NCg0KICAgOC4gICBFYWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZv bGxvd2VkIGJ5IGF0IGxlYXN0IG9uZSBleHRlbnNpb24NCiAgICAgICAgc3VidGFnLiAgRm9y IGV4YW1wbGUsIHRoZSB0YWcgInRsaC1hLWItZm9vIiBpcyBpbnZhbGlkIGJlY2F1c2UNCiAg ICAgICAgdGhlIGZpcnN0IHNpbmdsZXRvbiAnYScgaXMgZm9sbG93ZWQgaW1tZWRpYXRlbHkg YnkgYW5vdGhlcg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmls IDIwMDcNCg0KDQogICAgICAgIHNpbmdsZXRvbiAnYicuDQoNCiAgIDkuICAgRXh0ZW5zaW9u 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 CiAgICAgICBvbiBwcml2YXRlIHVzZSBzdWJ0YWcgY2hvaWNlLg0KDQogICBGb3IgZXhhbXBs ZTogVXNlcnMgd2hvIHdpc2hlZCB0byB1dGlsaXplIGNvZGVzIGZyb20gdGhlIEV0aG5vbG9n dWUNCiAgIHB1YmxpY2F0aW9uIG9mIFNJTCBJbnRlcm5hdGlvbmFsIGZvciBsYW5ndWFnZSBp ZGVudGlmaWNhdGlvbiBtaWdodA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4 cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgIEFwcmlsIDIwMDcNCg0KDQogICBhZ3JlZSB0byBleGNoYW5nZSB0YWdzIHN1Y2ggYXMg ImF6LUFyYWIteC1BWkUtZGVyYmVuZCIuICBUaGlzIGV4YW1wbGUNCiAgIGNvbnRhaW5zIHR3 byBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVGhlIGZpcnN0IGlzICdBWkUnIGFuZCB0aGUgc2Vj b25kDQogICBpcyAnZGVyYmVuZCcuDQoNCjIuMi44LiAgR3JhbmRmYXRoZXJlZCBSZWdpc3Ry YXRpb25zDQoNCiAgIFByaW9yIHRvIFJGQyA0NjQ2LCB3aG9sZSBsYW5ndWFnZSB0YWdzIHdl cmUgcmVnaXN0ZXJlZCBhY2NvcmRpbmcgdG8NCiAgIHRoZSBydWxlcyBpbiBSRkMgMTc2NiBh bmQvb3IgUkZDIDMwNjYuICBUaGVzZSByZWdpc3RlcmVkIHRhZ3MNCiAgIG1haW50YWluIHRo ZWlyIHZhbGlkaXR5LiAgT2YgdGhvc2UgdGFncywgdGhvc2UgdGhhdCB3ZXJlIG1hZGUNCiAg IG9ic29sZXRlIG9yIHJlZHVuZGFudCBieSB0aGUgYWR2ZW50IG9mIFJGQyA0NjQ2LCBieSB0 aGlzIGRvY3VtZW50LCBvcg0KICAgYnkgc3Vic2VxdWVudCByZWdpc3RyYXRpb24gb2Ygc3Vi dGFncyBhcmUgbWFpbnRhaW5lZCBpbiB0aGUgcmVnaXN0cnkNCiAgIGluIHJlY29yZHMgYXMg InJlZHVuZGFudCIgcmVjb3Jkcy4gIFRob3NlIHRhZ3MgdGhhdCBkbyBub3QgbWF0Y2ggdGhl DQogICAnbGFuZ3RhZycgcHJvZHVjdGlvbiBpbiB0aGUgQUJORiBpbiB0aGlzIGRvY3VtZW50 IG9yIHRoYXQgY29udGFpbg0KICAgc3VidGFncyB0aGF0IGRvIG5vdCBpbmRpdmlkdWFsbHkg YXBwZWFyIGluIHRoZSByZWdpc3RyeSBhcmUNCiAgIG1haW50YWluZWQgaW4gdGhlIHJlZ2lz dHJ5IGluIHJlY29yZHMgb2YgdGhlICJncmFuZGZhdGhlcmVkIiB0eXBlLg0KDQogICBHcmFu ZGZhdGhlcmVkIHRhZ3MgY29udGFpbiBvbmUgb3IgbW9yZSBzdWJ0YWdzIHRoYXQgYXJlIG5v dCBkZWZpbmVkDQogICBpbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IChzZWUgU2Vj dGlvbiAzKS4gIFJlZHVuZGFudCB0YWdzDQogICBjb25zaXN0IGVudGlyZWx5IG9mIHN1YnRh Z3MgZGVmaW5lZCBhYm92ZSBhbmQgd2hvc2UgaW5kZXBlbmRlbnQNCiAgIHJlZ2lzdHJhdGlv biB3YXMgc3VwZXJzZWRlZCBieSBbUkZDNDY0Nl0uICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBz ZWUNCiAgIFNlY3Rpb24gMy44Lg0KDQogICBTb21lIGdyYW5kZmF0aGVyZWQgdGFncyBhcmUg InJlZ3VsYXIiIGluIHRoYXQgdGhleSBtYXRjaCB0aGUNCiAgICdsYW5ndGFnJyBwcm9kdWN0 aW9uIGluIEZpZ3VyZSAxLiAgSW4gc29tZSBjYXNlcywgdGhlc2UgdGFncyBjb3VsZA0KICAg YmVjb21lIHJlZHVuZGFudCBpZiB0aGVpciAoY3VycmVudCB1bnJlZ2lzdGVyZWQpIHN1YnRh Z3Mgd2VyZSB0byBiZQ0KICAgcmVnaXN0ZXJlZCAoYXMgdmFyaWFudHMsIGZvciBleGFtcGxl KS4gIEluIG90aGVyIGNhc2VzLCBhbHRob3VnaCB0aGUNCiAgIHN1YnRhZ3MgbWF0Y2ggdGhl IGxhbmd1YWdlIHRhZyBwYXR0ZXJuLCB0aGUgbWVhbmluZyBhc3NpZ25lZCB0byB0aGUNCiAg IHZhcmlvdXMgc3VidGFncyBpcyBwcm9oaWJpdGVkIGJ5IHJ1bGVzIGVsc2V3aGVyZSBpbiB0 aGlzIGRvY3VtZW50Lg0KICAgVGhvc2UgdGFncyBjYW4gbmV2ZXIgYmVjb21lIHJlZHVuZGFu dC4NCg0KICAgVGhlIHJlbWFpbmluZyBncmFuZGZhdGhlcmVkIHRhZ3MgYXJlICJpcnJlZ3Vs YXIiIGFuZCBkbyBub3QgbWF0Y2ggdGhlDQogICAnbGFuZ3RhZycgcHJvZHVjdGlvbi4gIFRo ZXNlIGFyZSBsaXN0ZWQgaW4gdGhlICdpcnJlZ3VsYXInIHByb2R1Y3Rpb24NCiAgIGluIEZp Z3VyZSAxLiAgVGhlc2UgZ3JhbmRmYXRoZXJlZCB0YWdzIGNhbiBuZXZlciBiZWNvbWUgcmVk dW5kYW50Lg0KICAgTWFueSBvZiB0aGVzZSB0YWdzIGhhdmUgYmVlbiBzdXBlcnNlZGVkIGJ5 IG90aGVyIHJlZ2lzdHJhdGlvbnM6IHRoZWlyDQogICByZWNvcmQgY29udGFpbnMgYSBQcmVm ZXJyZWQtVmFsdWUgZmllbGQgdGhhdCByZWFsbHkgb3VnaHQgdG8gYmUgdXNlZA0KICAgdG8g Zm9ybSBsYW5ndWFnZSB0YWdzIHJlcHJlc2VudGluZyB0aGF0IHZhbHVlLg0KDQoyLjIuOS4g IENsYXNzZXMgb2YgQ29uZm9ybWFuY2UNCg0KICAgSW1wbGVtZW50YXRpb25zIHNvbWV0aW1l cyBuZWVkIHRvIGRlc2NyaWJlIHRoZWlyIGNhcGFiaWxpdGllcyB3aXRoDQogICByZWdhcmQg dG8gdGhlIHJ1bGVzIGFuZCBwcmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQu ICBUYWdzDQogICBjYW4gYmUgY2hlY2tlZCBvciB2ZXJpZmllZCBpbiBhIG51bWJlciBvZiB3 YXlzLCBidXQgdHdvIHBhcnRpY3VsYXINCiAgIGNsYXNzZXMgb2YgdGFnIGNvbmZvcm1hbmNl IGFyZSBmb3JtYWxseSBkZWZpbmVkIGhlcmUuDQoNCiAgIEEgdGFnIGlzIGNvbnNpZGVyZWQg IndlbGwtZm9ybWVkIiBpZiBpdCBjb25mb3JtcyB0byB0aGUgQUJORg0KICAgKFNlY3Rpb24g Mi4xKS4gIE5vdGUgdGhhdCBpcnJlZ3VsYXIgZ3JhbmRmYXRoZXJlZCB0YWdzIGFyZSBub3cg bGlzdGVkDQogICBpbiB0aGUgJ2lycmVndWxhcicgcHJvZHVjdGlvbi4NCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAg ICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBBIHRhZyBp cyBjb25zaWRlcmVkICJ2YWxpZCIgaWYgaXQgd2VsbC1mb3JtZWQgYW5kIGl0IGFsc28gc2F0 aXNmaWVzDQogICB0aGVzZSBjb25kaXRpb25zOg0KDQogICBvICBUaGUgdGFnIGlzIGVpdGhl ciBhIGdyYW5kZmF0aGVyZWQgdGFnLCBvciBhbGwgb2YgaXRzIGxhbmd1YWdlLA0KICAgICAg ZXh0ZW5kZWQgbGFuZ3VhZ2UsIHNjcmlwdCwgcmVnaW9uLCBhbmQgdmFyaWFudCBzdWJ0YWdz IGFwcGVhciBpbg0KICAgICAgdGhlIElBTkEgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5IGFz IG9mIHRoZSBwYXJ0aWN1bGFyIHJlZ2lzdHJ5DQogICAgICBkYXRlLg0KDQogICBvICBUaGVy ZSBhcmUgbm8gZHVwbGljYXRlIHNpbmdsZXRvbiAoZXh0ZW5zaW9uKSBzdWJ0YWdzIGFuZCBu bw0KICAgICAgZHVwbGljYXRlIHZhcmlhbnQgc3VidGFncy4NCg0KICAgbyAgRm9yIGVhY2gg c3VidGFnIHRoYXQgaGFzIGEgJ1ByZWZpeCcgZmllbGQgaW4gdGhlIHJlZ2lzdHJ5LCB0aGUN CiAgICAgIFByZWZpeCBtYXRjaGVzIHRoZSBsYW5ndWFnZSB0YWcgdXNpbmcgRXh0ZW5kZWQg RmlsdGVyaW5nDQogICAgICBbUkZDNDY0N10uICBUaGF0IGlzLCBlYWNoIHN1YnRhZyBpbiB0 aGUgUHJlZml4IGlzIHByZXNlbnQgaW4gdGhlDQogICAgICB0YWcgYW5kIGluIHRoZSBzYW1l IG9yZGVyLiAgRm9yIGV4YW1wbGUsIHRoZSBQcmVmaXggInpoLVRXIg0KICAgICAgbWF0Y2hl cyB0aGUgdGFnICJ6aC1IYW50LVRXIi4NCg0KICAgTm90ZSB0aGF0IGEgdGFnJ3MgdmFsaWRp dHkgZGVwZW5kcyBvbiB0aGUgZGF0ZSBvZiB0aGUgcmVnaXN0cnkgdXNlZA0KICAgdG8gdmFs aWRhdGUgdGhlIHRhZy4gIEEgbW9yZS1yZWNlbnQgY29weSBvZiB0aGUgcmVnaXN0cnkgbWln aHQNCiAgIGNvbnRhaW4gYSBzdWJ0YWcgdGhhdCBhbiBvbGRlciB2ZXJzaW9uIGRvZXMgbm90 Lg0KDQogICBBIHRhZyBpcyBjb25zaWRlcmVkICJ2YWxpZCIgZm9yIGEgZ2l2ZW4gZXh0ZW5z aW9uIChTZWN0aW9uIDMuNykgKGFzDQogICBvZiBhIHBhcnRpY3VsYXIgdmVyc2lvbiwgcmV2 aXNpb24sIGFuZCBkYXRlKSBpZiBpdCBtZWV0cyB0aGUgY3JpdGVyaWENCiAgIGZvciAidmFs aWQiIGFib3ZlIGFuZCBhbHNvIHNhdGlzZmllcyB0aGlzIGNvbmRpdGlvbjoNCg0KICAgICAg RWFjaCBzdWJ0YWcgdXNlZCBpbiB0aGUgZXh0ZW5zaW9uIHBhcnQgb2YgdGhlIHRhZyBpcyB2 YWxpZA0KICAgICAgYWNjb3JkaW5nIHRvIHRoZSBleHRlbnNpb24uDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCjMuICBSZWdpc3RyeSBGb3JtYXQgYW5kIE1h aW50ZW5hbmNlDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmVnaXN0cnkgYW5kIHRoZSBtYWludGVuYW5jZQ0KICAgYW5kIHVwZGF0ZSBwcm9jZWR1 cmVzIGFzc29jaWF0ZWQgd2l0aCBpdCwgYXMgd2VsbCBhcyBhIHJlZ2lzdHJ5IGZvcg0KICAg ZXh0ZW5zaW9ucyB0byBsYW5ndWFnZSB0YWdzIChTZWN0aW9uIDMuNykuDQoNCiAgIFRoZSBM YW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgY29udGFpbnMgYSBjb21wcmVoZW5zaXZlIGxpc3Qg b2YgYWxsIG9mDQogICB0aGUgc3VidGFncyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLiAgVGhp cyBhbGxvd3MgaW1wbGVtZW50ZXJzIGENCiAgIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgcmVsaWFi bGUgd2F5IHRvIHZhbGlkYXRlIGxhbmd1YWdlIHRhZ3MuICBUaGUNCiAgIExhbmd1YWdlIFN1 YnRhZyBSZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28gdGhhdCwgZXhjZXB0IGZvcg0K ICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxlIHRvIHZhbGlkYXRlIGFsbCBv ZiB0aGUgc3VidGFncyB0aGF0DQogICBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcgdW5kZXIg dGhlIHByb3Zpc2lvbnMgb2YgdGhpcyBkb2N1bWVudCBvciBpdHMNCiAgIHJldmlzaW9ucyBv ciBzdWNjZXNzb3JzLiAgSW4gYWRkaXRpb24sIHRoZSBtZWFuaW5nIG9mIHRoZSB2YXJpb3Vz DQogICBzdWJ0YWdzIHdpbGwgYmUgdW5hbWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUu ICAoVGhlIG1lYW5pbmcgb2YNCiAgIHByaXZhdGUgdXNlIHN1YnRhZ3MsIG9mIGNvdXJzZSwg aXMgbm90IGRlZmluZWQgYnkgdGhlIElBTkEgcmVnaXN0cnkuKQ0KDQozLjEuICBGb3JtYXQg b2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFRoZSBJQU5BIExh bmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3RyeSIpIGNvbnNpc3RzIG9mIGEg dGV4dA0KICAgZmlsZSB0aGF0IGlzIG1hY2hpbmUgcmVhZGFibGUgaW4gdGhlIGZvcm1hdCBk ZXNjcmliZWQgaW4gdGhpcw0KICAgc2VjdGlvbiwgcGx1cyBjb3BpZXMgb2YgdGhlIHJlZ2lz dHJhdGlvbiBmb3JtcyBhcHByb3ZlZCBpbiBhY2NvcmRhbmNlDQogICB3aXRoIHRoZSBwcm9j ZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNS4gIFRoZSBleGlzdGluZyByZWdpc3RyYXRp b24NCiAgIGZvcm1zIGZvciBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncyB0YWtl biBmcm9tIFJGQyAzMDY2IHdpbGwNCiAgIGJlIG1haW50YWluZWQgYXMgcGFydCBvZiB0aGUg b2Jzb2xldGUgUkZDIDMwNjYgcmVnaXN0cnkuICBUaGUNCiAgIHJlbWFpbmluZyBzZXQgb2Yg aW5pdGlhbCBzdWJ0YWdzIHdpbGwgbm90IGhhdmUgcmVnaXN0cmF0aW9uIGZvcm1zDQogICBj cmVhdGVkIGZvciB0aGVtLg0KDQozLjEuMS4gIEZpbGUgRm9ybWF0DQoNCiAgIFRoZSByZWdp c3RyeSBpcyBpbiB0aGUgdGV4dCBmb3JtYXQgZGVzY3JpYmVkIGJlbG93LiAgVGhpcyBmb3Jt YXQgd2FzDQogICBiYXNlZCBvbiB0aGUgcmVjb3JkLWphciBmb3JtYXQgZGVzY3JpYmVkIGlu IFtyZWNvcmQtamFyXS4NCg0KICAgRWFjaCBsaW5lIG9mIHRleHQgaXMgbGltaXRlZCB0byA3 MiBjaGFyYWN0ZXJzLCBpbmNsdWRpbmcgYWxsDQogICB3aGl0ZXNwYWNlLiAgUmVjb3JkcyBh cmUgc2VwYXJhdGVkIGJ5IGxpbmVzIGNvbnRhaW5pbmcgb25seSB0aGUNCiAgIHNlcXVlbmNl ICIlJSIgKCV4MjUuMjUpLg0KDQogICBFYWNoIGZpZWxkIGNhbiBiZSB2aWV3ZWQgYXMgYSBz aW5nbGUsIGxvZ2ljYWwgbGluZSBvZiBBU0NJSQ0KICAgY2hhcmFjdGVycywgY29tcHJpc2lu ZyBhIGZpZWxkLW5hbWUgYW5kIGEgZmllbGQtYm9keSBzZXBhcmF0ZWQgYnkgYQ0KICAgQ09M T04gY2hhcmFjdGVyICgleDNBKS4gIEZvciBjb252ZW5pZW5jZSwgdGhlIGZpZWxkLWJvZHkg cG9ydGlvbiBvZg0KICAgdGhpcyBjb25jZXB0dWFsIGVudGl0eSBjYW4gYmUgc3BsaXQgaW50 byBhIG11bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2VudGF0aW9uOyB0aGlzIGlzIGNhbGxlZCAi Zm9sZGluZyIuICBUaGUgZm9ybWF0IG9mIHRoZSByZWdpc3RyeQ0KICAgaXMgZGVzY3JpYmVk IGJ5IHRoZSBmb2xsb3dpbmcgQUJORiAocGVyIFtSRkM0MjM0XSk6DQoNCg0KDQoNCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcg ICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAg IHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENSTEYgcmVjb3JkKQ0KICAgcmVjb3JkICAg ICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQIGZpZWxkLWJvZHkgQ1JMRiApDQogICBm aWVsZC1uYW1lID0gKEFMUEhBIC8gRElHSVQpIFsqKEFMUEhBIC8gRElHSVQgLyAiLSIpIChB TFBIQSAvIERJR0lUKV0NCiAgIGZpZWxkLWJvZHkgPSAqKEFTQ0NIQVIvTFdTUCkNCiAgIEFT Q0NIQVIgICAgPSAleDIxLTI1IC8gJXgyNy03RSAvIFVOSUNIQVIgOyBOb3RlOiBBTVBFUlNB TkQgaXMgJXgyNg0KICAgVU5JQ0hBUiAgICA9ICImI3giIDIqNkhFWERJRyAiOyINCg0KICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBSZWdpc3RyeSBGb3JtYXQgQUJORg0KDQog ICBUaGUgc2VxdWVuY2UgJy4uJyAoJXgyRS4yRSkgaW4gYSBmaWVsZC1ib2R5IGRlbm90ZXMg YSByYW5nZSBvZg0KICAgdmFsdWVzLiAgU3VjaCBhIHJhbmdlIHJlcHJlc2VudHMgYWxsIHN1 YnRhZ3Mgb2YgdGhlIHNhbWUgbGVuZ3RoIHRoYXQNCiAgIGFyZSBpbiBhbHBoYWJldGljIG9y IG51bWVyaWMgb3JkZXIgd2l0aGluIHRoYXQgcmFuZ2UsIGluY2x1ZGluZyB0aGUNCiAgIHZh bHVlcyBleHBsaWNpdGx5IG1lbnRpb25lZC4gIEZvciBleGFtcGxlICdhLi5jJyBkZW5vdGVz IHRoZSB2YWx1ZXMNCiAgICdhJywgJ2InLCBhbmQgJ2MnIGFuZCAnMTEuLjEzJyBkZW5vdGVz IHRoZSB2YWx1ZXMgJzExJywgJzEyJywgYW5kDQogICAnMTMnLg0KDQogICBDaGFyYWN0ZXJz IGZyb20gb3V0c2lkZSB0aGUgVVMtQVNDSUkgW0lTTzY0Nl0gcmVwZXJ0b2lyZSwgYXMgd2Vs bCBhcw0KICAgdGhlIEFNUEVSU0FORCBjaGFyYWN0ZXIgKCImIiwgJXgyNikgd2hlbiBpdCBv Y2N1cnMgaW4gYSBmaWVsZC1ib2R5LA0KICAgYXJlIHJlcHJlc2VudGVkIGJ5IGEgIk51bWVy aWMgQ2hhcmFjdGVyIFJlZmVyZW5jZSIgdXNpbmcgaGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9u IGluIHRoZSBzdHlsZSB1c2VkIGJ5IFtYTUwxMF0gKHNlZQ0KICAgPGh0dHA6Ly93d3cudzMu b3JnL1RSL1JFQy14bWwvI2R0LWNoYXJyZWY+KS4gIFRoaXMgY29uc2lzdHMgb2YgdGhlDQog ICBzZXF1ZW5jZSAiJiN4IiAoJXgyNi4yMy43OCkgZm9sbG93ZWQgYnkgYSBoZXhhZGVjaW1h bCByZXByZXNlbnRhdGlvbg0KICAgb2YgdGhlIGNoYXJhY3RlcidzIGNvZGUgcG9pbnQgaW4g W0lTTzEwNjQ2XSBmb2xsb3dlZCBieSBhIGNsb3NpbmcNCiAgIHNlbWljb2xvbiAoJXgzQiku ICBGb3IgZXhhbXBsZSwgdGhlIEVVUk8gU0lHTiwgVSsyMEFDLCB3b3VsZCBiZQ0KICAgcmVw cmVzZW50ZWQgYnkgdGhlIHNlcXVlbmNlICImI3gyMEFDOyIuICBOb3RlIHRoYXQgdGhlIGhl eGFkZWNpbWFsDQogICBub3RhdGlvbiBNQVkgaGF2ZSBiZXR3ZWVuIHR3byBhbmQgc2l4IGRp Z2l0cy4NCg0KICAgQWxsIGZpZWxkcyB3aG9zZSBmaWVsZC1ib2R5IGNvbnRhaW5zIGEgZGF0 ZSB2YWx1ZSB1c2UgdGhlICJmdWxsLWRhdGUiDQogICBmb3JtYXQgc3BlY2lmaWVkIGluIFtS RkMzMzM5XS4gIEZvciBleGFtcGxlOiAiMjAwNC0wNi0yOCIgcmVwcmVzZW50cw0KICAgSnVu ZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KMy4xLjIuICBSZWNv cmQgRGVmaW5pdGlvbnMNCg0KICAgVGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIHJlY29yZHMg aW4gdGhlIHJlZ2lzdHJ5OiAiRmlsZS1EYXRlIiwNCiAgICJTdWJ0YWciLCBhbmQgIlRhZyIg cmVjb3Jkcy4NCg0KICAgVGhlIGZpcnN0IHJlY29yZCBpbiB0aGUgcmVnaXN0cnkgaXMgYSAi RmlsZS1EYXRlIiByZWNvcmQuICBUaGlzDQogICByZWNvcmQgY29udGFpbnMgdGhlIHNpbmds ZSBmaWVsZCB3aG9zZSBmaWVsZC1uYW1lIGlzICJGaWxlLURhdGUiIChzZWUNCiAgIEZpZ3Vy ZSAyKS4gIFRoZSBmaWVsZC1ib2R5IG9mIHRoaXMgcmVjb3JkIGNvbnRhaW5zIHRoZSBsYXN0 DQogICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGlzIGNvcHkgb2YgdGhlIHJlZ2lzdHJ5LCBt YWtpbmcgaXQgcG9zc2libGUgdG8NCiAgIGNvbXBhcmUgZGlmZmVyZW50IHZlcnNpb25zIG9m IHRoZSByZWdpc3RyeS4gIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFOQQ0KICAgd2Vic2l0ZSBp cyB0aGUgbW9zdCBjdXJyZW50LiAgVmVyc2lvbnMgd2l0aCBhbiBvbGRlciBkYXRlIHRoYW4g dGhhdA0KICAgb25lIGFyZSBub3QgdXAtdG8tZGF0ZS4NCg0KICAgRmlsZS1EYXRlOiAyMDA0 LTA2LTI4DQogICAlJQ0KDQogICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFeGFtcGxlIG9m IHRoZSBGaWxlLURhdGUgUmVjb3JkDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIFN1YnNlcXVlbnQgcmVjb3JkcyByZXByZXNlbnQg ZWl0aGVyIHN1YnRhZ3Mgb3IgdGFncyBpbiB0aGUgcmVnaXN0cnkuDQogICAiU3VidGFnIiBy ZWNvcmRzIGNvbnRhaW4gYSBmaWVsZCB3aXRoIGEgZmllbGQtbmFtZSBvZiAiU3VidGFnIiwN CiAgIHdoaWxlLCB1bnN1cnByaXNpbmdseSwgIlRhZyIgcmVjb3JkcyBjb250YWluIGEgZmll bGQgd2l0aCBhIGZpZWxkLQ0KICAgbmFtZSBvZiAiVGFnIi4gIEVhY2ggb2YgdGhlIGZpZWxk cyBpbiBlYWNoIHJlY29yZCBNVVNUIG9jY3VyIG5vIG1vcmUNCiAgIHRoYW4gb25jZSwgdW5s ZXNzIG90aGVyd2lzZSBub3RlZCBiZWxvdy4gIEVhY2ggcmVjb3JkIE1VU1QgY29udGFpbg0K ICAgdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gICdUeXBlJw0KDQogICAgICAqICBU eXBlJ3MgZmllbGQtYm9keSBNVVNUIGNvbnNpc3Qgb2Ygb25lIG9mIHRoZSBmb2xsb3dpbmcg c3RyaW5nczoNCiAgICAgICAgICJsYW5ndWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJy ZWdpb24iLCAidmFyaWFudCIsDQogICAgICAgICAiZ3JhbmRmYXRoZXJlZCIsIGFuZCAicmVk dW5kYW50IiBhbmQgZGVub3RlcyB0aGUgdHlwZSBvZiB0YWcgb3INCiAgICAgICAgIHN1YnRh Zy4NCg0KICAgbyAgRWl0aGVyICdTdWJ0YWcnIG9yICdUYWcnDQoNCiAgICAgICogIFN1YnRh ZydzIGZpZWxkLWJvZHkgY29udGFpbnMgdGhlIHN1YnRhZyBiZWluZyBkZWZpbmVkLiAgVGhp cw0KICAgICAgICAgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIG9mIHdob3Nl ICdUeXBlJyBoYXMgb25lIG9mDQogICAgICAgICB0aGVzZSB2YWx1ZXM6ICJsYW5ndWFnZSIs ICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBvcg0KICAgICAgICAgInZhcmlhbnQi Lg0KDQogICAgICAqICBUYWcncyBmaWVsZC1ib2R5IGNvbnRhaW5zIGEgY29tcGxldGUgbGFu Z3VhZ2UgdGFnLiAgVGhpcyBmaWVsZA0KICAgICAgICAgTVVTVCBvbmx5IGFwcGVhciBpbiBy ZWNvcmRzIHdob3NlICdUeXBlJyBoYXMgb25lIG9mIHRoZXNlDQogICAgICAgICB2YWx1ZXM6 ICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50Ii4gIE5vdGUgdGhhdCB0aGUgZmllbGQt DQogICAgICAgICBib2R5IHdpbGwgYWx3YXlzIGZvbGxvdyB0aGUgJ2dyYW5kZmF0aGVyZWQn IHByb2R1Y3Rpb24gaW4gdGhlDQogICAgICAgICBBQk5GIGluIFNlY3Rpb24gMi4xDQoNCiAg IG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2NyaXB0aW9uJ3MgZmllbGQtYm9keSBj b250YWlucyBhIG5vbi1ub3JtYXRpdmUgZGVzY3JpcHRpb24NCiAgICAgICAgIG9mIHRoZSBz dWJ0YWcgb3IgdGFnLg0KDQogICBvICBBZGRlZA0KDQogICAgICAqICBBZGRlZCdzIGZpZWxk LWJvZHkgY29udGFpbnMgdGhlIGRhdGUgdGhlIHJlY29yZCB3YXMgYWRkZWQgdG8NCiAgICAg ICAgIHRoZSByZWdpc3RyeS4NCg0KICAgRWFjaCByZWNvcmQgTUFZIGFsc28gY29udGFpbiB0 aGUgZm9sbG93aW5nIGZpZWxkczoNCg0KICAgbyAgUHJlZmVycmVkLVZhbHVlDQoNCiAgICAg ICogIEZvciBmaWVsZHMgb2YgdHlwZSAnc2NyaXB0JywgJ3JlZ2lvbicsIGFuZCAndmFyaWFu dCcsDQogICAgICAgICAnUHJlZmVycmVkLVZhbHVlJyBjb250YWlucyB0aGUgc3VidGFnIG9m IHRoZSBzYW1lICdUeXBlJyB0aGF0DQogICAgICAgICBpcyBwcmVmZXJyZWQgZm9yIGZvcm1p bmcgdGhlIGxhbmd1YWdlIHRhZy4NCg0KICAgICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICds YW5ndWFnZScgYW5kICdleHRsYW5nJywgJ1ByZWZlcnJlZC1WYWx1ZScNCiAgICAgICAgIGNv bnRhaW5zIHRoZSBsYW5ndWFnZSBwcm9kdWN0aW9uIChzZWUgRmlndXJlIDEpIHRoYXQgaXMN CiAgICAgICAgIHByZWZlcnJlZCB3aGVuIGZvcm1pbmcgdGhlIGxhbmd1YWdlIHRhZy4gIFRo aXMgY2FuIGJlIHNpbXBseSBhDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICAgQXByaWwgMjAwNw0KDQoNCiAgICAgICAgICdsYW5ndWFnZScgc3VidGFnLCBvciBpdCBj YW4gYmUgYSAnbGFuZ3VhZ2UnIHN1YnRhZyBmb2xsb3dlZCBieQ0KICAgICAgICAgYW4gZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc2VxdWVuY2UuDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlw ZSAnZ3JhbmRmYXRoZXJlZCcgYW5kICdyZWR1bmRhbnQnLCBhIGNhbm9uaWNhbA0KICAgICAg ICAgbWFwcGluZyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZy4NCg0KICAgbyAgRGVwcmVj YXRlZA0KDQogICAgICAqICBEZXByZWNhdGVkJ3MgZmllbGQtYm9keSBjb250YWlucyB0aGUg ZGF0ZSB0aGUgcmVjb3JkIHdhcw0KICAgICAgICAgZGVwcmVjYXRlZC4NCg0KICAgbyAgUHJl Zml4DQoNCiAgICAgICogIFByZWZpeCdzIGZpZWxkLWJvZHkgY29udGFpbnMgYSBsYW5ndWFn ZSB0YWcgd2l0aCB3aGljaCB0aGlzDQogICAgICAgICBzdWJ0YWcgTUFZIGJlIHVzZWQgdG8g Zm9ybSBhIG5ldyBsYW5ndWFnZSB0YWcsIHBlcmhhcHMgd2l0aA0KICAgICAgICAgb3RoZXIg c3VidGFncyBhcyB3ZWxsLiAgVGhpcyBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29y ZHMNCiAgICAgICAgIHdob3NlICdUeXBlJyBmaWVsZC1ib2R5IGlzICd2YXJpYW50JyBvciAn ZXh0bGFuZycuICBGb3INCiAgICAgICAgIGV4YW1wbGUsIHRoZSAnUHJlZml4JyBmb3IgdGhl IHZhcmlhbnQgJ25lZGlzJyBpcyAnc2wnLCBtZWFuaW5nDQogICAgICAgICB0aGF0IHRoZSB0 YWdzICJzbC1uZWRpcyIgYW5kICJzbC1JVC1uZWRpcyIgbWlnaHQgYmUgYXBwcm9wcmlhdGUN CiAgICAgICAgIHdoaWxlIHRoZSB0YWcgImlzLW5lZGlzIiBpcyBub3QuDQoNCiAgIG8gIENv bW1lbnRzDQoNCiAgICAgICogIENvbW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIHN1YnRhZywgYXMNCiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0 ZSBmb3IgdW5kZXJzdGFuZGluZyB0aGUgcmVnaXN0cnkgYW5kDQogICAgICAgICBpbXBsZW1l bnRpbmcgbGFuZ3VhZ2UgdGFncyB1c2luZyB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAg U3VwcHJlc3MtU2NyaXB0DQoNCiAgICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250YWlucyBh IHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJlDQogICAgICAgICB1c2VkIHRvIGZv cm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UN CiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNv cmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQtYm9keSBpcyAnbGFuZ3VhZ2UnLiAg U2VlIFNlY3Rpb24gNC4xLg0KDQogICBGdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVu dCBtaWdodCBhZGQgYWRkaXRpb25hbCBmaWVsZHMgdG8gdGhlDQogICByZWdpc3RyeSwgc28g aW1wbGVtZW50YXRpb25zIFNIT1VMRCBpZ25vcmUgZmllbGRzIGZvdW5kIGluIHRoZQ0KICAg cmVnaXN0cnkgdGhhdCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KMy4x LjMuICBTdWJ0YWcgYW5kIFRhZyBGaWVsZHMNCg0KICAgVGhlICdTdWJ0YWcnIGZpZWxkIE1V U1QgdXNlIGxvd2VyY2FzZSBsZXR0ZXJzIHRvIGZvcm0gdGhlIHN1YnRhZywNCiAgIHdpdGgg dHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBpcyAnc2NyaXB0 JyAoaW4NCiAgIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDE1OTI0KSBN VVNUIHVzZSB0aXRsZWNhc2UuDQogICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBpcyAn cmVnaW9uJyAoaW4gb3RoZXIgd29yZHMsIHN1YnRhZ3MNCiAgIGRlZmluZWQgYnkgSVNPIDMx NjYpIE1VU1QgdXNlIHVwcGVyY2FzZS4gIFRoZXNlIGV4Y2VwdGlvbnMgbWlycm9yIHRoZQ0K ICAgdXNlIG9mIGNhc2UgaW4gdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzLg0KDQogICBFYWNo IHN1YnRhZyBpbiB0aGUgdGFncyBjb250YWluZWQgaW4gYSAnVGFnJyBmaWVsZCBNVVNUIGJl IGZvcm1hdHRlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmls IDIwMDcNCg0KDQogICB1c2luZyB0aGUgcnVsZXMgaW4gdGhlIHByZWNlZWRpbmcgcGFyYWdy YXBoLiAgVGhhdCBpcywgYWxsIHN1YnRhZ3MNCiAgIGFyZSBsb3dlcmNhc2UgZXhjZXB0IGZv ciBzdWJ0YWdzIHRoYXQgcmVwcmVzZW50IHNjcmlwdCBvciByZWdpb24NCiAgIGNvZGVzLg0K DQozLjEuNC4gIERlc2NyaXB0aW9uIEZpZWxkDQoNCiAgIFRoZSBmaWVsZCAnRGVzY3JpcHRp b24nIGNvbnRhaW5zIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRhZyBvciBzdWJ0YWcNCiAgIGlu IHRoZSByZWNvcmQuICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNQVkgYXBwZWFyIG1vcmUg dGhhbiBvbmNlIHBlcg0KICAgcmVjb3JkLCB0aGF0IGlzLCB0aGVyZSBjYW4gYmUgbXVsdGlw bGUgZGVzY3JpcHRpb25zIGZvciBhIGdpdmVuDQogICByZWNvcmQuICBBdCBsZWFzdCBvbmUg b2YgdGhlICdEZXNjcmlwdGlvbicgZmllbGRzIE1VU1QgYmUgd3JpdHRlbiBvcg0KICAgdHJh bnNjcmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyBhZGRpdGlvbmFsICdEZXNjcmlwdGlv bicgZmllbGRzDQogICBNQVkgYWxzbyBpbmNsdWRlIGEgZGVzY3JpcHRpb24gaW4gYSBub24t TGF0aW4gc2NyaXB0LiAgRWFjaA0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIGJlIHVu aXF1ZSwgYm90aCB3aXRoaW4gdGhlIHJlY29yZCBpbiB3aGljaA0KICAgaXQgYXBwZWFycyBh bmQgZm9yIHRoZSBjb2xsZWN0aW9uIG9mIHJlY29yZHMgb2YgdGhlIHNhbWUgdHlwZS4NCiAg IE1vcmVvdmVyLCBmb3JtYXR0aW5nIHZhcmlhdGlvbnMgb2YgdGhlIHNhbWUgZGVzY3JpcHRp b24gTVVTVCBOT1QNCiAgIG9jY3VyIGluIHRoYXQgc3BlY2lmaWMgcmVjb3JkIG9yIGluIGFu eSBvdGhlciByZWNvcmQgb2YgdGhlIHNhbWUNCiAgIHR5cGUuICBGb3IgZXhhbXBsZSwgd2hp bGUgdGhlIElTTyA2MzktMSBjb2RlICdmeScgY29udGFpbnMgYm90aCB0aGUNCiAgIGRlc2Ny aXB0aW9ucyAiV2VzdGVybiBGcmlzaWFuIiBhbmQgIkZyaXNpYW4sIFdlc3Rlcm4iLCBvbmx5 IG9uZSBvZg0KICAgdGhlc2UgZGVzY3JpcHRpb25zIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5 Lg0KDQogICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpcyB1c2VkIGZvciBpZGVudGlmaWNh dGlvbiBwdXJwb3NlcyBhbmQNCiAgIFNIT1VMRCBOT1QgYmUgdGFrZW4gdG8gcmVwcmVzZW50 IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlDQogICBsYW5ndWFnZSBvciB2YXJpYXRp b24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCiAgIEZvciByZWNv cmRzIHRha2VuIGZyb20gYSBzb3VyY2Ugc3RhbmRhcmQgKHN1Y2ggYXMgSVNPIDYzOSBvciBJ U08NCiAgIDMxNjYpLCB0aGUgJ0Rlc2NyaXB0aW9uJyB2YWx1ZShzKSBTSE9VTEQgYWxzbyBi ZSB0YWtlbiBmcm9tIHRoZQ0KICAgc291cmNlIHN0YW5kYXJkLiAgTXVsdGlwbGUgZGVzY3Jp cHRpb25zIGluIHRoZSBzb3VyY2Ugc3RhbmRhcmQgTVVTVA0KICAgYmUgc3BsaXQgaW50byBz ZXBhcmF0ZSAnRGVzY3JpcHRpb24nIGZpZWxkcy4gIFRoZSBzb3VyY2Ugc3RhbmRhcmQncw0K ICAgZGVzY3JpcHRpb25zIE1BWSBiZSBlZGl0ZWQsIGVpdGhlciBwcmlvciB0byBpbnNlcnRp b24gb3IgdmlhIHRoZQ0KICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBGb3IgZmllbGRzIG9m IHR5cGUgJ2xhbmd1YWdlJyBvciAnZXh0bGFuZycsDQogICB0aGUgZmlyc3QgJ0Rlc2NyaXB0 aW9uJyBmaWVsZCBhcHBlYXJpbmcgaW4gdGhlIFJlZ2lzdHJ5IGNvcnJlc3BvbmRzDQogICB0 byB0aGUgUmVmZXJlbmNlIE5hbWUgYXNzaWduZWQgYnkgSVNPIDYzOS0zLiAgVGhpcyBoZWxw cyBmYWNpbGl0YXRlDQogICBjcm9zcy1yZWZlcmVuY2luZyBiZXR3ZWVuIElTTyA2MzkgYW5k IHRoZSByZWdpc3RyeS4NCg0KICAgV2hlbiBjcmVhdGluZyBvciB1cGRhdGluZyBhIHJlY29y ZCBkdWUgdG8gdGhlIGFjdGlvbiBvZiBvbmUgb2YgdGhlDQogICBzb3VyY2Ugc3RhbmRhcmRz LCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIFNIT1VMRCByZW1vdmUNCiAgIGR1cGxp Y2F0ZSBvciByZWR1bmRhbnQgZGVzY3JpcHRpb25zIGFuZCBNQVkgZWRpdCBkZXNjcmlwdGlv bnMgdG8NCiAgIGNvcnJlY3QgaXJyZWd1bGFyaXRpZXMgaW4gZm9ybWF0dGluZyAoc3VjaCBh cyBtaXNzcGVsbGluZ3MsDQogICBpbmFwcHJvcHJpYXRlIGFwb3N0cm9waGVzIG9yIG90aGVy IHB1bmN0dWF0aW9uLCBvciBleGNlc3NpdmUgb3INCiAgIG1pc3Npbmcgc3BhY2VzKSBwcmlv ciB0byBzdWJtaXR0aW5nIHRoZSBwcm9wb3NlZCByZWNvcmQgdG8gdGhlIGlldGYtDQogICBs YW5ndWFnZXMgbGlzdC4NCg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJlZ2lzdHJ5IGVu dHJpZXMgdGhhdCBjb3JyZXNwb25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQsIElTTyAz MTY2LCBvciBVTiBNLjQ5IGNvZGVzIGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGljYXRlDQog ICB0aGUgbWVhbmluZyBvZiB0aGF0IGlkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0aGUgc291 cmNlIHN0YW5kYXJkIGF0DQogICB0aGUgdGltZSBpdCB3YXMgYWRkZWQgdG8gdGhlIHJlZ2lz dHJ5LiAgVGhlIGRlc2NyaXB0aW9uIGRvZXMgbm90DQogICByZXBsYWNlIHRoZSBjb250ZW50 IG9mIHRoZSBzb3VyY2Ugc3RhbmRhcmQgaXRzZWxmLiAgVGhlIGRlc2NyaXB0aW9ucw0KICAg YXJlIG5vdCBpbnRlbmRlZCB0byBiZSB0aGUgRW5nbGlzaCBsb2NhbGl6ZWQgbmFtZXMgZm9y IHRoZSBzdWJ0YWdzLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMg T2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFw cmlsIDIwMDcNCg0KDQogICBMb2NhbGl6YXRpb24gb3IgdHJhbnNsYXRpb24gb2YgbGFuZ3Vh Z2UgdGFnIGFuZCBzdWJ0YWcgZGVzY3JpcHRpb25zDQogICBpcyBvdXQgb2Ygc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4NCg0KMy4xLjUuICBEZXByZWNhdGVkIEZpZWxkDQoNCiAgIFRoZSBm aWVsZCAnRGVwcmVjYXRlZCcgTUFZIGJlIGFkZGVkIHRvIGFueSByZWNvcmQgdmlhIHRoZSBt YWludGVuYW5jZQ0KICAgcHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMgb3Igdmlh IHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41 LiAgVXN1YWxseSwgdGhlIGFkZGl0aW9uIG9mIGEgJ0RlcHJlY2F0ZWQnDQogICBmaWVsZCBp cyBkdWUgdG8gdGhlIGFjdGlvbiBvZiBvbmUgb2YgdGhlIHN0YW5kYXJkcyBib2RpZXMsIHN1 Y2ggYXMNCiAgIElTTyAzMTY2LCB3aXRoZHJhd2luZyBhIGNvZGUuICBJbiBzb21lIGhpc3Rv cmljYWwgY2FzZXMsIGl0IG1pZ2h0IG5vdA0KICAgaGF2ZSBiZWVuIHBvc3NpYmxlIHRvIHJl Y29uc3RydWN0IHRoZSBvcmlnaW5hbCBkZXByZWNhdGlvbiBkYXRlLiAgRm9yDQogICB0aGVz ZSBjYXNlcywgYW4gYXBwcm94aW1hdGUgZGF0ZSBhcHBlYXJzIGluIHRoZSByZWdpc3RyeS4g IEFsdGhvdWdoDQogICB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBzdWJ0YWdzIGFuZCB0YWdz IHdpdGggYSAnRGVwcmVjYXRlZCcgZmllbGQNCiAgIGFyZSBkZXByZWNhdGVkIGFuZCB2YWxp ZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVCBnZW5lcmF0ZSB0aGVzZQ0KICAgc3VidGFn cy4gIE5vdGUgdGhhdCBhIHJlY29yZCB0aGF0IGNvbnRhaW5zIGEgJ0RlcHJlY2F0ZWQnIGZp ZWxkIGFuZA0KICAgbm8gY29ycmVzcG9uZGluZyAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBo YXMgbm8gcmVwbGFjZW1lbnQgbWFwcGluZy4NCg0KMy4xLjYuICBQcmVmZXJyZWQtVmFsdWUg RmllbGQNCg0KICAgVGhlIGZpZWxkICdQcmVmZXJyZWQtVmFsdWUnIGNvbnRhaW5zIGEgbWFw cGluZyBiZXR3ZWVuIHRoZSByZWNvcmQgaW4NCiAgIHdoaWNoIGl0IGFwcGVhcnMgYW5kIGFu b3RoZXIgdGFnIG9yIHN1YnRhZy4gIFRoZSB2YWx1ZSBpbiB0aGlzIGZpZWxkDQogICBpcyBz dHJvbmdseSBSRUNPTU1FTkRFRCBhcyB0aGUgYmVzdCBjaG9pY2UgdG8gcmVwcmVzZW50IHRo ZSB2YWx1ZSBvZg0KICAgdGhpcyByZWNvcmQgd2hlbiBzZWxlY3RpbmcgYSBsYW5ndWFnZSB0 YWcuICBUaGVzZSB2YWx1ZXMgZm9ybSB0aHJlZQ0KICAgZ3JvdXBzOg0KDQogICAxLiAgSVNP IDYzOSBsYW5ndWFnZSBjb2RlcyB0aGF0IHdlcmUgbGF0ZXIgd2l0aGRyYXduIGluIGZhdm9y IG9mDQogICAgICAgb3RoZXIgY29kZXMuICBUaGVzZSB2YWx1ZXMgYXJlIG1vc3RseSBhIGhp c3RvcmljYWwgY3VyaW9zaXR5Lg0KDQogICAyLiAgSVNPIDMxNjYgcmVnaW9uIGNvZGVzIHRo YXQgaGF2ZSBiZWVuIHdpdGhkcmF3biBpbiBmYXZvciBvZiBhIG5ldw0KICAgICAgIGNvZGUu ICBUaGlzIHNvbWV0aW1lcyBoYXBwZW5zIHdoZW4gYSBjb3VudHJ5IGNoYW5nZXMgaXRzIG5h bWUgb3INCiAgICAgICBhZG1pbmlzdHJhdGlvbiBpbiBzdWNoIGEgd2F5IHRoYXQgd2FycmFu dHMgYSBuZXcgcmVnaW9uIGNvZGUuDQoNCiAgIDMuICBHcmFuZGZhdGhlcmVkIG9yIHJlZHVu ZGFudCB0YWdzIGZyb20gUkZDIDMwNjYuICBJbiBtYW55IGNhc2VzLA0KICAgICAgIHRoZXNl IHRhZ3MgaGF2ZSBiZWNvbWUgb2Jzb2xldGUgYmVjYXVzZSB0aGUgdmFsdWVzIHRoZXkgcmVw cmVzZW50DQogICAgICAgd2VyZSBsYXRlciBlbmNvZGVkIGJ5IElTTyA2MzkuDQoNCiAgIFJl Y29yZHMgdGhhdCBjb250YWluIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgTVVTVCBhbHNv IGhhdmUgYQ0KICAgJ0RlcHJlY2F0ZWQnIGZpZWxkLiAgVGhpcyBmaWVsZCBjb250YWlucyBh IGRhdGUgb2YgZGVwcmVjYXRpb24uDQogICBUaHVzLCBhIGxhbmd1YWdlIHRhZyBwcm9jZXNz b3IgY2FuIHVzZSB0aGUgcmVnaXN0cnkgdG8gY29uc3RydWN0IHRoZQ0KICAgdmFsaWQsIG5v bi1kZXByZWNhdGVkIHNldCBvZiBzdWJ0YWdzIGZvciBhIGdpdmVuIGRhdGUuICBJbiBhZGRp dGlvbiwNCiAgIGZvciBhbnkgZ2l2ZW4gdGFnLCBhIHByb2Nlc3NvciBjYW4gY29uc3RydWN0 IHRoZSBzZXQgb2YgdmFsaWQNCiAgIGxhbmd1YWdlIHRhZ3MgdGhhdCBjb3JyZXNwb25kIHRv IHRoYXQgdGFnIGZvciBhbGwgZGF0ZXMgdXAgdG8gdGhlDQogICBkYXRlIG9mIHRoZSByZWdp c3RyeS4gIFRoZSBhYmlsaXR5IHRvIGRvIHRoZXNlIG1hcHBpbmdzIE1BWSBiZQ0KICAgYmVu ZWZpY2lhbCB0byBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgbWF0Y2hpbmcsIHNlbGVjdGluZywg Zm9yDQogICBmaWx0ZXJpbmcgY29udGVudCBiYXNlZCBvbiBpdHMgbGFuZ3VhZ2UgdGFncy4N Cg0KICAgTm90ZSB0aGF0ICdQcmVmZXJyZWQtVmFsdWUnIG1hcHBpbmdzIGluIHJlY29yZHMg b2YgdHlwZSAncmVnaW9uJw0KICAgc29tZXRpbWVzIGRvIG5vdCByZXByZXNlbnQgZXhhY3Rs eSB0aGUgc2FtZSBtZWFuaW5nIGFzIHRoZSBvcmlnaW5hbA0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICB2YWx1ZS4gIFRoZXJlIGFy ZSBtYW55IHJlYXNvbnMgZm9yIGEgY291bnRyeSBjb2RlIHRvIGJlIGNoYW5nZWQsIGFuZA0K ICAgdGhlIGVmZmVjdCB0aGlzIGhhcyBvbiB0aGUgZm9ybWF0aW9uIG9mIGxhbmd1YWdlIHRh Z3Mgd2lsbCBkZXBlbmQgb24NCiAgIHRoZSBuYXR1cmUgb2YgdGhlIGNoYW5nZSBpbiBxdWVz dGlvbi4NCg0KICAgSW4gcGFydGljdWxhciwgdGhlICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxk IGRvZXMgbm90IGltcGx5IHJldGFnZ2luZw0KICAgY29udGVudCB0aGF0IHVzZXMgdGhlIGFm ZmVjdGVkIHN1YnRhZy4NCg0KICAgVGhlIGZpZWxkICdQcmVmZXJyZWQtVmFsdWUnIE1VU1Qg Tk9UIGJlIG1vZGlmaWVkIG9uY2UgY3JlYXRlZCBpbiB0aGUNCiAgIHJlZ2lzdHJ5LiAgVGhl IGZpZWxkIE1BWSBiZSBhZGRlZCB0byByZWNvcmRzIGFjY29yZGluZyB0byB0aGUgcnVsZXMN CiAgIGluIFNlY3Rpb24gMy4zLg0KDQogICBUaGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQg aW4gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIiBhbmQNCiAgICJyZWR1bmRhbnQi IGNvbnRhaW5zIHdob2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUgc3Ryb25nbHkNCiAgIFJF Q09NTUVOREVEIGZvciB1c2UgaW4gcGxhY2Ugb2YgdGhlIHJlY29yZCdzIHZhbHVlLiAgSW4g bWFueSBjYXNlcywNCiAgIHRoZSBtYXBwaW5ncyB3ZXJlIGNyZWF0ZWQgYnkgZGVwcmVjYXRp b24gb2YgdGhlIHRhZ3MgZHVyaW5nIHRoZQ0KICAgcGVyaW9kIGJlZm9yZSB0aGlzIGRvY3Vt ZW50IHdhcyBhZG9wdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgIm5vLQ0KICAgbnluIiB3 YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgSVNPIDYzOS0xLWRlZmluZWQgbGFuZ3Vh Z2UgY29kZQ0KICAgJ25uJy4NCg0KMy4xLjcuICBQcmVmaXggRmllbGQNCg0KICAgVGhlIGZp ZWxkIG9mIHR5cGUgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNv cmQuICBUaGUNCiAgIGZpZWxkLWJvZHkgZm9yIHRoaXMgdHlwZSBvZiBmaWVsZCBNVVNUIE5P VCBiZSBtb2RpZmllZC4NCg0KICAgVGhlIGZpZWxkLWJvZHkgb2YgdGhlICdQcmVmaXgnIGZp ZWxkIGNvbnNpc3RzIG9mIGEgbGFuZ3VhZ2UgdGFnIHdob3NlDQogICBzdWJ0YWdzIGFyZSBh cHByb3ByaWF0ZSB0byB1c2Ugd2l0aCB0aGlzIHN1YnRhZy4gIEZvciBleGFtcGxlLCB0aGUN CiAgIHZhcmlhbnQgc3VidGFnICcxOTk2JyBoYXMgYSAnUHJlZml4JyBmaWVsZCBvZiAiZGUi LiAgVGhpcyBtZWFucyB0aGF0DQogICB0YWdzIHN0YXJ0aW5nIHdpdGggdGhlIHNlcXVlbmNl ICJkZS0iIGFyZSBhcHByb3ByaWF0ZSB3aXRoIHRoaXMNCiAgIHN1YnRhZywgc28gImRlLUxh dGctMTk5NiIgYW5kICJkZS1DSC0xOTk2IiBhcmUgYm90aCBhY2NlcHRhYmxlLCB3aGlsZQ0K ICAgdGhlIHRhZyAiZnItMTk5NiIgaXMgYW4gaW5hcHByb3ByaWF0ZSBjaG9pY2UuDQoNCiAg IFJlY29yZHMgb2YgdHlwZSAndmFyaWFudCcgTUFZIGhhdmUgbW9yZSB0aGFuIG9uZSBmaWVs ZCBvZiB0eXBlDQogICAnUHJlZml4Jy4gIEFkZGl0aW9uYWwgZmllbGRzIG9mIHRoaXMgdHlw ZSBNQVkgYmUgYWRkZWQgdG8gYSAndmFyaWFudCcNCiAgIHJlY29yZCB2aWEgdGhlIHJlZ2lz dHJhdGlvbiBwcm9jZXNzLg0KDQogICBUaGUgZmllbGQtYm9keSBvZiB0aGUgJ1ByZWZpeCcg ZmllbGQgTVVTVCBOT1QgY29uZmxpY3Qgd2l0aCBhbnkNCiAgICdQcmVmaXgnIGFscmVhZHkg cmVnaXN0ZXJlZCBmb3IgYSBnaXZlbiByZWNvcmQuICBTdWNoIGEgY29uZmxpY3QNCiAgIHdv dWxkIG9jY3VyIHdoZW4gd2hlbiBubyB2YWxpZCB0YWcgY291bGQgYmUgY29uc3RydWN0ZWQg dGhhdCB3b3VsZA0KICAgY29udGFpbiB0aGUgcHJlZml4LCBzdWNoIGFzIHdoZW4gd2hlbiB0 d28gc3VidGFncyBlYWNoIGhhdmUgYQ0KICAgJ1ByZWZpeCcgdGhhdCBjb250YWlucyB0aGUg b3RoZXIgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHN1cHBvc2UgdGhhdA0KICAgdGhlIHN1YnRh ZyAnYXZhcmlhbnQnIGhhcyB0aGUgcHJlZml4ICJlcy1idmFyaWFudCIuICBUaGVuIHRoZSBz dWJ0YWcNCiAgICdidmFyaWFudCcgY2Fubm90IGdpdmVuIHRoZSBwcmVmaXggJ2F2YXJpYW50 JywgZm9yIHRoYXQgd291bGQgcmVxdWlyZQ0KICAgYSB0YWcgb2YgdGhlIGZvcm0gImVzLWF2 YXJpYW50LWJ2YXJpYW50LWF2YXJpYW50Iiwgd2hpY2ggd291bGQgbm90IGJlDQogICB2YWxp ZC4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhhdmUgX2V4YWN0bHlf IG9uZSAnUHJlZml4JyBmaWVsZC4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNw0KDQoNCjMuMS44LiAgQ29tbWVudHMgRmllbGQNCg0KICAg VGhlIGZpZWxkICdDb21tZW50cycgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25jZSBwZXIgcmVj b3JkLiAgVGhpcw0KICAgZmllbGQgTUFZIGJlIGluc2VydGVkIG9yIGNoYW5nZWQgdmlhIHRo ZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbmQgbm8NCiAgIGd1YXJhbnRlZSBvZiBzdGFiaWxp dHkgaXMgcHJvdmlkZWQuICBUaGUgY29udGVudCBvZiB0aGlzIGZpZWxkIGlzIG5vdA0KICAg cmVzdHJpY3RlZCwgZXhjZXB0IGJ5IHRoZSBuZWVkIHRvIHJlZ2lzdGVyIHRoZSBpbmZvcm1h dGlvbiwgdGhlDQogICBzdWl0YWJpbGl0eSBvZiB0aGUgcmVxdWVzdCwgYW5kIGJ5IHJlYXNv bmFibGUgcHJhY3RpY2FsIHNpemUNCiAgIGxpbWl0YXRpb25zLg0KDQozLjEuOS4gIFN1cHBy ZXNzLVNjcmlwdCBGaWVsZA0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVT VCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQtYm9keSBp cyAnbGFuZ3VhZ2UnLiAgVGhpcyBmaWVsZCBNVVNUIE5PVCBhcHBlYXIgbW9yZSB0aGFuIG9u ZQ0KICAgdGltZSBpbiBhIHJlY29yZC4gIFRoaXMgZmllbGQgaW5kaWNhdGVzIGEgc2NyaXB0 IHVzZWQgdG8gd3JpdGUgdGhlDQogICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgZG9jdW1l bnRzIGZvciB0aGUgZ2l2ZW4gbGFuZ3VhZ2UgYW5kIHRoYXQNCiAgIHRoZXJlZm9yZSBhZGRz IG5vIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uIHRvIGEgbGFuZ3VhZ2UgdGFnLiAgSXQN CiAgIGhlbHBzIGVuc3VyZSBncmVhdGVyIGNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGUgbGFu Z3VhZ2UgdGFncw0KICAgZ2VuZXJhdGVkIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gdGhp cyBkb2N1bWVudCBhbmQgbGFuZ3VhZ2UgdGFncw0KICAgYW5kIHRhZyBwcm9jZXNzb3JzIG9y IGNvbnN1bWVycyBiYXNlZCBvbiBSRkMgMzA2Ni4gIEZvciBleGFtcGxlLA0KICAgdmlydHVh bGx5IGFsbCBJY2VsYW5kaWMgZG9jdW1lbnRzIGFyZSB3cml0dGVuIGluIHRoZSBMYXRpbiBz Y3JpcHQsDQogICBtYWtpbmcgdGhlIHN1YnRhZyAnTGF0bicgcmVkdW5kYW50IGluIHRoZSB0 YWcgImlzLUxhdG4iLg0KDQogICBNYW55IGxhbmd1YWdlIHN1YnRhZyByZWNvcmRzIGRvIG5v dCBoYXZlIGEgU3VwcHJlc3MtU2NyaXB0IGZpZWxkLg0KICAgVGhlIGxhY2sgb2YgYSBTdXBw cmVzcy1TY3JpcHQgbWlnaHQgaW5kaWNhdGUgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMNCiAgIGN1 c3RvbWFyaWx5IHdyaXR0ZW4gaW4gbW9yZSB0aGFuIG9uZSBzY3JpcHQgb3IgdGhhdCB0aGUg bGFuZ3VhZ2UgaXMNCiAgIG5vdCBjdXN0b21hcmlseSB3cml0dGVuIGF0IGFsbC4gIEl0IG1p Z2h0IGFsc28gbWVhbiB0aGF0IHN1ZmZpY2llbnQNCiAgIGluZm9ybWF0aW9uIHdhcyBub3Qg YXZhaWxhYmxlIHdoZW4gdGhlIHJlY29yZCB3YXMgY3JlYXRlZCBhbmQgdGh1cw0KICAgcmVt YWlucyBhIGNhbmRpZGF0ZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbi4NCg0KMy4yLiAgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgbW9kZXJhdGVzIHRoZSBpZXRmLWxhbmd1YWdlcyBtYWlsaW5nDQogICBsaXN0LCByZXNw b25kcyB0byByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uLCBhbmQgcGVyZm9ybXMgdGhlIG90 aGVyDQogICByZWdpc3RyeSBtYWludGVuYW5jZSBkdXRpZXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy4zLiAgT25seSB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBpcyBwZXJt aXR0ZWQgdG8gcmVxdWVzdCBJQU5BIHRvIGNoYW5nZSwNCiAgIHVwZGF0ZSwgb3IgYWRkIHJl Y29yZHMgdG8gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIFRoZSBMYW5ndWFnZQ0K ICAgU3VidGFnIFJldmlld2VyIE1BWSBkZWxlZ2F0ZSBsaXN0IG1vZGVyYXRpb24gYW5kIG90 aGVyIGNsZXJpY2FsDQogICBkdXRpZXMgYXMgbmVlZGVkLg0KDQogICBUaGUgTGFuZ3VhZ2Ug U3VidGFnIFJldmlld2VyIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRyBmb3IgYW4NCiAgIGlu ZGVmaW5pdGUgdGVybSwgc3ViamVjdCB0byByZW1vdmFsIG9yIHJlcGxhY2VtZW50IGF0IHRo ZSBJRVNHJ3MNCiAgIGRpc2NyZXRpb24uICBUaGUgSUVTRyB3aWxsIHNvbGljaXQgbm9taW5l ZXMgZm9yIHRoZSBwb3NpdGlvbg0KICAgKGluaXRpYWxseSBvciB1cG9uIGEgdmFjYW5jeSkg YW5kIHNlZWsgdG8gYXNjZXJ0YWluIHRoZSBjYW5kaWRhdGVzJw0KICAgcXVhbGlmaWNhdGlv bnMuDQoNCiAgIFRoZSBzdWJzZXF1ZW50IHBlcmZvcm1hbmNlIG9yIGRlY2lzaW9ucyBvZiB0 aGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZXZpZXdlciBNQVkgYmUgYXBwZWFsZWQgdG8gdGhl IElFU0cgdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXINCiAgIElFVEYgZGVjaXNpb25z IChzZWUgW1JGQzIwMjZdKS4gIFRoZSBJRVNHIGNhbiByZXZlcnNlIG9yIG92ZXJ0dXJuIHRo ZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICBkZWNpc2lvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBwcm92aWRl IGd1aWRhbmNlLCBvciB0YWtlDQogICBvdGhlciBhcHByb3ByaWF0ZSBhY3Rpb25zLg0KDQoz LjMuICBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ugb2Yg dGhlIHJlZ2lzdHJ5IHJlcXVpcmVzIHRoYXQgYXMgY29kZXMgYXJlIGFzc2lnbmVkIG9yDQog ICB3aXRoZHJhd24gYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0u NDksIHRoZSBMYW5ndWFnZQ0KICAgU3VidGFnIFJldmlld2VyIE1VU1QgZXZhbHVhdGUgZWFj aCBjaGFuZ2UsIGRldGVybWluZSB3aGV0aGVyIGl0DQogICBjb25mbGljdHMgd2l0aCBleGlz dGluZyByZWdpc3RyeSBlbnRyaWVzLCBhbmQgc3VibWl0IHRoZSBpbmZvcm1hdGlvbg0KICAg dG8gSUFOQSBmb3IgaW5jbHVzaW9uIGluIHRoZSByZWdpc3RyeS4gIElmIGEgY2hhbmdlIHRh a2VzIHBsYWNlIGFuZA0KICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkb2VzIG5v dCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5lciwNCiAgIHRoZW4gYW55IGludGVyZXN0ZWQg cGFydHkgTUFZIHVzZSB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24gMy41IHRvDQogICByZWdp c3RlciB0aGUgYXBwcm9wcmlhdGUgdXBkYXRlLg0KDQogICBOb3RlOiBUaGUgcmVkdW5kYW50 IGFuZCBncmFuZGZhdGhlcmVkIGVudHJpZXMgdG9nZXRoZXIgYXJlIHRoZQ0KICAgY29tcGxl dGUgbGlzdCBvZiB0YWdzIHJlZ2lzdGVyZWQgdW5kZXIgW1JGQzMwNjZdLiAgVGhlIHJlZHVu ZGFudCB0YWdzDQogICBhcmUgdGhvc2UgdGhhdCBjYW4gbm93IGJlIGZvcm1lZCB1c2luZyB0 aGUgc3VidGFncyBkZWZpbmVkIGluIHRoZQ0KICAgcmVnaXN0cnkgdG9nZXRoZXIgd2l0aCB0 aGUgcnVsZXMgb2YgU2VjdGlvbiAyLjIuICBUaGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50cmll cyBpbmNsdWRlIHRob3NlIHRoYXQgY2FuIG5ldmVyIGJlIGxlZ2FsIHVuZGVyIHRob3NlIHNh bWUNCiAgIHByb3Zpc2lvbnMgcGx1cyB0aG9zZSB0YWdzIHRoYXQgY29udGFpbiBzdWJ0YWdz IG5vdCB5ZXQgcmVnaXN0ZXJlZA0KICAgb3IsIHBlcmhhcHMsIGluYXBwcm9wcmlhdGUgZm9y IHJlZ2lzdHJhdGlvbi4NCg0KICAgVGhlIHNldCBvZiByZWR1bmRhbnQgYW5kIGdyYW5kZmF0 aGVyZWQgdGFncyBpcyBwZXJtYW5lbnQgYW5kIHN0YWJsZToNCiAgIG5ldyBlbnRyaWVzIGlu IHRoaXMgc2VjdGlvbiBNVVNUIE5PVCBiZSBhZGRlZCBhbmQgZXhpc3RpbmcgZW50cmllcw0K ICAgTVVTVCBOT1QgYmUgcmVtb3ZlZC4gIFJlY29yZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJl ZCcgTUFZIGhhdmUgdGhlaXINCiAgIHR5cGUgY29udmVydGVkIHRvICdyZWR1bmRhbnQnOyBz ZWUgaXRlbSAxMiBpbiBTZWN0aW9uIDMuNiBmb3IgbW9yZQ0KICAgaW5mb3JtYXRpb24uICBU aGUgZGVjaXNpb24tbWFraW5nIHByb2Nlc3MgYWJvdXQgd2hpY2ggdGFncyB3ZXJlDQogICBp bml0aWFsbHkgZ3JhbmRmYXRoZXJlZCBhbmQgd2hpY2ggd2VyZSBtYWRlIHJlZHVuZGFudCBp cyBkZXNjcmliZWQgaW4NCiAgIFtSRkM0NjQ1XS4NCg0KICAgUkZDIDMwNjYgdGFncyB0aGF0 IHdlcmUgZGVwcmVjYXRlZCBwcmlvciB0byB0aGUgYWRvcHRpb24gb2YgW1JGQzQ2NDZdDQog ICBhcmUgcGFydCBvZiB0aGUgbGlzdCBvZiBncmFuZGZhdGhlcmVkIHRhZ3MsIGFuZCB0aGVp ciBjb21wb25lbnQNCiAgIHN1YnRhZ3Mgd2VyZSBub3QgaW5jbHVkZWQgYXMgcmVnaXN0ZXJl ZCB2YXJpYW50cyAoYWx0aG91Z2ggdGhleQ0KICAgcmVtYWluIGVsaWdpYmxlIGZvciByZWdp c3RyYXRpb24pLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImFydC1sb2piYW4iDQogICB3YXMg ZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnICdqYm8nLg0KDQog ICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgZW5zdXJlIHRoYXQgbmV3IHN1 YnRhZ3MgbWVldCB0aGUNCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQuMSBvciBzdWJt aXQgYW4gYXBwcm9wcmlhdGUgYWx0ZXJuYXRlIHN1YnRhZw0KICAgYXMgZGVzY3JpYmVkIGlu IHRoYXQgc2VjdGlvbi4gIFdoZW4gZWl0aGVyIGEgY2hhbmdlIG9yIGFkZGl0aW9uIHRvDQog ICB0aGUgcmVnaXN0cnkgaXMgbmVlZGVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2Vy IE1VU1QgcHJlcGFyZSB0aGUNCiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFsbCBm aWVsZHMsIGFuZCBmb3J3YXJkIGl0IHRvIElBTkEgZm9yDQogICBpbnNlcnRpb24gaW50byB0 aGUgcmVnaXN0cnkuICBFYWNoIHJlY29yZCBiZWluZyBtb2RpZmllZCBvciBpbnNlcnRlZA0K ICAgTVVTVCBiZSBmb3J3YXJkZWQgaW4gYSBzZXBhcmF0ZSBtZXNzYWdlLg0KDQogICBJZiBh IHJlY29yZCByZXByZXNlbnRzIGEgbmV3IHN1YnRhZyB0aGF0IGRvZXMgbm90IGN1cnJlbnRs eSBleGlzdCBpbg0KICAgdGhlIHJlZ2lzdHJ5LCB0aGVuIHRoZSBtZXNzYWdlJ3Mgc3ViamVj dCBsaW5lIE1VU1QgaW5jbHVkZSB0aGUgd29yZA0KICAgIklOU0VSVCIuICBJZiB0aGUgcmVj b3JkIHJlcHJlc2VudHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLA0KICAgdGhl biB0aGUgc3ViamVjdCBsaW5lIG9mIHRoZSBtZXNzYWdlIE1VU1QgaW5jbHVkZSB0aGUgd29y ZCAiTU9ESUZZIi4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9j dG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA3DQoNCg0KICAgVGhlIG1lc3NhZ2UgTVVTVCBjb250YWluIGJvdGggdGhlIHJlY29y ZCBmb3IgdGhlIHN1YnRhZyBiZWluZw0KICAgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgYW5kIHRo ZSBuZXcgRmlsZS1EYXRlIHJlY29yZC4gIEhlcmUgaXMgYW4NCiAgIGV4YW1wbGUgb2Ygd2hh dCB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZSBtaWdodCBjb250YWluOg0KDQogICBMQU5HVUFH RSBTVUJUQUcgTU9ESUZJQ0FUSU9ODQogICBGaWxlLURhdGU6IDIwMDUtMDEtMDINCiAgICUl DQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IG5lZGlzDQogICBEZXNjcmlwdGlvbjog TmF0aXNvbmUgZGlhbGVjdA0KICAgRGVzY3JpcHRpb246IE5hZGl6YSBkaWFsZWN0DQogICBB ZGRlZDogMjAwMy0xMC0wOQ0KICAgUHJlZml4OiBzbA0KICAgQ29tbWVudHM6IFRoaXMgaXMg YSBjb21tZW50IHNob3duDQogICAgIGFzIGFuIGV4YW1wbGUuDQogICAlJQ0KDQogICAgICAg ICBGaWd1cmUgNDogRXhhbXBsZSBvZiBhIExhbmd1YWdlIFN1YnRhZyBNb2RpZmljYXRpb24g Rm9ybQ0KDQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGlu IHRoZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFy dCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCBy ZWNlbnQgbW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhlIFtSRkMzMzM5XSAiZnVsbC1kYXRlIiBm b3JtYXQuDQoNCiAgIEJlZm9yZSBmb3J3YXJkaW5nIGEgbmV3IHJlZ2lzdHJhdGlvbiB0byBJ QU5BLCB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZXZpZXdlciBNVVNUIGVuc3VyZSB0aGF0 IHZhbHVlcyBpbiB0aGUgJ1N1YnRhZycgZmllbGQgbWF0Y2ggY2FzZQ0KICAgYWNjb3JkaW5n IHRvIHRoZSBkZXNjcmlwdGlvbiBpbiBTZWN0aW9uIDMuMS4NCg0KMy40LiAgU3RhYmlsaXR5 IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVudHJp ZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzDQogICBjcml0aWNhbCB0 byB0aGUgbG9uZy10ZXJtIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJ1bGVz IGluDQogICB0aGlzIHNlY3Rpb24gZ3VhcmFudGVlIHRoYXQgYSBzcGVjaWZpYyBsYW5ndWFn ZSB0YWcncyBtZWFuaW5nIGlzDQogICBzdGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5vdCBj aGFuZ2UuDQoNCiAgIFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBkZWFsIHdpdGggaG93IGNo YW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRp b24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAxNTkyNCwgSVNP IDMxNjYsIGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UN CiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1YWdl IFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxp dHkgcnVsZXM6DQoNCiAgIDEuICAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ1R5cGUnLCAnU3Vi dGFnJywgJ1RhZycsICdBZGRlZCcsDQogICAgICAgICdEZXByZWNhdGVkJyBhbmQgJ1ByZWZl cnJlZC1WYWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlDQogICAgICAgIGd1YXJh bnRlZWQgdG8gYmUgc3RhYmxlIG92ZXIgdGltZS4NCg0KICAgMi4gICBWYWx1ZXMgaW4gdGhl ICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBOT1QgYmUgY2hhbmdlZCBpbiBhIHdheQ0KICAg ICAgICB0aGF0IHdvdWxkIGludmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAg VGhleSBNQVkgYmUNCiAgICAgICAgYnJvYWRlbmVkIHNvbWV3aGF0IGluIHNjb3BlLCBjaGFu Z2VkIHRvIGFkZCBpbmZvcm1hdGlvbiwgb3INCiAgICAgICAgYWRhcHRlZCB0byB0aGUgbW9z dCBjb21tb24gbW9kZXJuIHVzYWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAg ICAgICAgICAgW1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICAg IG9jY2FzaW9uYWxseSBjaGFuZ2UgdGhlaXIgb2ZmaWNpYWwgbmFtZXM7IGEgaGlzdG9yaWNh bCBleGFtcGxlDQogICAgICAgIG9mIHRoaXMgd291bGQgYmUgIlVwcGVyIFZvbHRhIiBjaGFu Z2luZyB0byAiQnVya2luYSBGYXNvIi4NCg0KICAgMy4gICBWYWx1ZXMgaW4gdGhlIGZpZWxk ICdQcmVmaXgnIE1BWSBiZSBhZGRlZCB0byByZWNvcmRzIG9mIHR5cGUNCiAgICAgICAgJ3Zh cmlhbnQnIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBJZiBhIHByZWZpeCBpcyBh ZGRlZCB0bw0KICAgICAgICBhIHZhcmlhbnQgcmVjb3JkLCAnQ29tbWVudCcgZmllbGRzIFNI T1VMRCBiZSB1c2VkIHRvIGV4cGxhaW4NCiAgICAgICAgZGlmZmVyZW50IHVzYWdlcyB3aXRo IHRoZSB2YXJpb3VzIHByZWZpeGVzLg0KDQogICA0LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQg J1ByZWZpeCcgaW4gcmVjb3JkcyBvZiB0eXBlICd2YXJpYW50JyBNQVkgYmUNCiAgICAgICAg bW9kaWZpZWQsIHNvIGxvbmcgYXMgdGhlIG1vZGlmaWNhdGlvbnMgYnJvYWRlbiB0aGUgc2V0 IG9mDQogICAgICAgIHByZWZpeGVzLiAgVGhhdCBpcywgYSBwcmVmaXggTUFZIGJlIHJlcGxh Y2VkIGJ5IG9uZSBvZiBpdHMgb3duDQogICAgICAgIHByZWZpeGVzLiAgRm9yIGV4YW1wbGUs IHRoZSBwcmVmaXggImVuLVVTIiBjb3VsZCBiZSByZXBsYWNlZCBieQ0KICAgICAgICAiZW4i LCBidXQgbm90IGJ5IHRoZSBwcmVmaXhlcyAiZW4tTGF0biIsICJmciIsIG9yICJlbi1VUy1i b29udCIuDQogICAgICAgIElmIG9uZSBvZiB0aG9zZSBwcmVmaXhlcyB3ZXJlIG5lZWRlZCwg YSBuZXcgUHJlZml4IFNIT1VMRCBiZQ0KICAgICAgICByZWdpc3RlcmVkLg0KDQogICA1LiAg IFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgaW4gcmVjb3JkcyBvZiB0eXBlICdleHRs YW5nJyBNVVNUDQogICAgICAgIE5PVCBiZSBtb2RpZmllZC4NCg0KICAgNi4gICBWYWx1ZXMg aW4gdGhlIGZpZWxkICdQcmVmaXgnIE1VU1QgTk9UIGJlIHJlbW92ZWQuDQoNCiAgIDcuICAg VGhlIGZpZWxkICdDb21tZW50cycgTUFZIGJlIGFkZGVkLCBjaGFuZ2VkLCBtb2RpZmllZCwg b3IgcmVtb3ZlZA0KICAgICAgICB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIG9yIGFu eSBvZiB0aGUgcHJvY2Vzc2VzIG9yDQogICAgICAgIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJl ZCBpbiB0aGlzIHNlY3Rpb24uDQoNCiAgIDguICAgVGhlIGZpZWxkICdTdXBwcmVzcy1TY3Jp cHQnIE1BWSBiZSBhZGRlZCBvciByZW1vdmVkIHZpYSB0aGUNCiAgICAgICAgcmVnaXN0cmF0 aW9uIHByb2Nlc3MuDQoNCiAgIDkuICAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOS0xIHRo YXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAgdHdvLWxldHRlciBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgYW5kIHdoaWNoIGhhdmUgbm8NCiAgICAgICAgY29y cmVzcG9uZGluZyB0aHJlZS1sZXR0ZXIgcHJpbWFyeSBvciBleHRlbmRlZCBsYW5ndWFnZSBz dWJ0YWdzDQogICAgICAgIGRlZmluZWQgaW4gdGhlIHJlZ2lzdHJ5IGFyZSBlbnRlcmVkIGlu dG8gdGhlIElBTkEgcmVnaXN0cnkgYXMNCiAgICAgICAgbmV3IHJlY29yZHMgb2YgdHlwZSAn bGFuZ3VhZ2UnLg0KDQogICAxMC4gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzktMiB0aGF0 IGRvIG5vdCBjb25mbGljdCB3aXRoIGV4aXN0aW5nDQogICAgICAgIHRocmVlLWxldHRlciBw cmltYXJ5IG9yIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgYXJlIGVudGVyZWQNCiAgICAg ICAgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3JkcyBvZiB0eXBlICdsYW5n dWFnZScuDQoNCiAgIDExLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOS0zIHRoYXQgZG8g bm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAgdGhyZWUtbGV0dGVyIHByaW1h cnkgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgZW50ZXJlZA0KICAgICAgICBp bnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzLg0KDQogICAgICAgIDEuICBD b2RlcyB0aGF0IGhhdmUgYSBkZWZpbmVkICJtYWNyby1sYW5ndWFnZSIgbWFwcGluZyBhdCB0 aGUNCiAgICAgICAgICAgIHRpbWUgb2YgdGhlaXIgcmVnaXN0cmF0aW9uIE1VU1QgYmUgZW50 ZXJlZCBpbnRvIHRoZSByZWdpc3RyeQ0KICAgICAgICAgICAgYXMgcmVjb3JkcyBvZiB0eXBl ICdleHRsYW5nJyB3aXRoIGEgJ1ByZWZpeCcgZmllbGQNCiAgICAgICAgICAgIGNvbnRhaW5p bmcgdGhlIGFwcHJvcHJpYXRlIHByZWZpeCB0YWcuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgMzBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICAgIDIuICBDb2RlcyB0 aGF0IHJlcHJlc2VudCBzaWduIGxhbmd1YWdlcyBNVVNUIGJlIGVudGVyZWQgaW50byB0aGUN CiAgICAgICAgICAgIHJlZ2lzdHJ5IGFzIHJlY29yZCBvZiB0eXBlICdleHRsYW5nJyB3aXRo IGEgJ1ByZWZpeCcgZmllbGQNCiAgICAgICAgICAgIHRoYXQgbWF0Y2hlcyB0aGUgQmFzaWMg TGFuZ3VhZ2UgUmFuZ2UgInNnbiIgKHNlZSBTZWN0aW9uDQogICAgICAgICAgICAzLjMuMSAi QmFzaWMgRmlsdGVyaW5nIiBpbiBbUkZDNDY0N10pLg0KDQogICAgICAgIDMuICBBbGwgb3Ro ZXIgY29kZXMgTVVTVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFzIHJlY29yZHMN CiAgICAgICAgICAgIG9mIHR5cGUgJ2xhbmd1YWdlJy4NCg0KICAgMTIuICBBIHJlY29yZCBv ZiB0eXBlICdsYW5ndWFnZScgb3IgJ2V4dGxhbmcnIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQN CiAgICAgICAgaWYgdGhlcmUgZXhpc3RzIGEgcmVjb3JkIG9mIGVpdGhlciB0eXBlIHdpdGgg dGhlIHNhbWUgc3VidGFnDQogICAgICAgIHZhbHVlLiAgRm9yIGV4YW1wbGUsIGlmIGFuICdl eHRsYW5nJyBzdWJ0YWcgJ2ZvbycgZXhpc3RzIGluIHRoZQ0KICAgICAgICByZWdpc3RyeSwg YWxsIGF0dGVtcHRzIHRvIHJlZ2lzdGVyIGEgJ2xhbmd1YWdlJyBzdWJ0YWcgJ2ZvbycNCiAg ICAgICAgd2lsbCBiZSByZWplY3RlZC4NCg0KICAgMTMuICBDb2RlcyBhc3NpZ25lZCBieSBJ U08gMTU5MjQgYW5kIElTTyAzMTY2IHRoYXQgZG8gbm90IGNvbmZsaWN0DQogICAgICAgIHdp dGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlIGFuZCB3aG9zZSBt ZWFuaW5nDQogICAgICAgIGlzIG5vdCB0aGUgc2FtZSBhcyBhbiBleGlzdGluZyBzdWJ0YWcg b2YgdGhlIHNhbWUgdHlwZSBhcmUNCiAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJl Z2lzdHJ5IGFzIG5ldyByZWNvcmRzLg0KDQogICAxNC4gIENvZGVzIGFzc2lnbmVkIGJ5IElT TyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBhcmUNCiAgICAgICAgd2l0aGRy YXduIGJ5IHRoZWlyIHJlc3BlY3RpdmUgbWFpbnRlbmFuY2Ugb3IgcmVnaXN0cmF0aW9uDQog ICAgICAgIGF1dGhvcml0eSByZW1haW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIEEgJ0Rl cHJlY2F0ZWQnIGZpZWxkDQogICAgICAgIGNvbnRhaW5pbmcgdGhlIGRhdGUgb2Ygd2l0aGRy YXdhbCBNVVNUIGJlIGFkZGVkIHRvIHRoZSByZWNvcmQuDQogICAgICAgIElmIGEgbmV3IHJl Y29yZCBvZiB0aGUgc2FtZSB0eXBlIGlzIGFkZGVkIHRoYXQgcmVwcmVzZW50cyBhDQogICAg ICAgIHJlcGxhY2VtZW50IHZhbHVlLCB0aGVuIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQg TUFZIGFsc28gYmUNCiAgICAgICAgYWRkZWQuICBUaGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mg TUFZIGJlIHVzZWQgdG8gYWRkIGNvbW1lbnRzDQogICAgICAgIGFib3V0IHRoZSB3aXRoZHJh d2FsIG9mIHRoZSBjb2RlIGJ5IHRoZSByZXNwZWN0aXZlIHN0YW5kYXJkLg0KDQogICAgICAg IEV4YW1wbGUgIFRoZSByZWdpb24gY29kZSAnVEwnIHdhcyBhc3NpZ25lZCB0byB0aGUgY291 bnRyeQ0KICAgICAgICAgICAnVGltb3ItTGVzdGUnLCByZXBsYWNpbmcgdGhlIGNvZGUgJ1RQ JyAod2hpY2ggd2FzIGFzc2lnbmVkIHRvDQogICAgICAgICAgICdFYXN0IFRpbW9yJyB3aGVu IGl0IHdhcyB1bmRlciBhZG1pbmlzdHJhdGlvbiBieSBQb3J0dWdhbCkuDQogICAgICAgICAg IFRoZSBzdWJ0YWcgJ1RQJyByZW1haW5zIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIGJ1dCBp dHMNCiAgICAgICAgICAgcmVjb3JkIGNvbnRhaW5zIHRoZSBhICdQcmVmZXJyZWQtVmFsdWUn IG9mICdUTCcgYW5kIGl0cyBmaWVsZA0KICAgICAgICAgICAnRGVwcmVjYXRlZCcgY29udGFp bnMgdGhlIGRhdGUgdGhlIG5ldyBjb2RlIHdhcyBhc3NpZ25lZA0KICAgICAgICAgICAoJzIw MDQtMDctMDYnKS4NCg0KICAgMTUuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08g MTU5MjQsIG9yIElTTyAzMTY2IHRoYXQgY29uZmxpY3QNCiAgICAgICAgd2l0aCBleGlzdGlu ZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUsIGluY2x1ZGluZyBzdWJ0YWdzDQog ICAgICAgIHRoYXQgYXJlIGRlcHJlY2F0ZWQsIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0 aGUgcmVnaXN0cnkuICBUaGUNCiAgICAgICAgZm9sbG93aW5nIGFkZGl0aW9uYWwgY29uc2lk ZXJhdGlvbnMgYXBwbHkgdG8gc3VidGFnIHZhbHVlcyB0aGF0DQogICAgICAgIGFyZSByZWFz c2lnbmVkOg0KDQogICAgICAgIEEuICBGb3IgSVNPIDYzOSBjb2RlcywgaWYgdGhlIG5ld2x5 IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBub3QgcmVwcmVzZW50 ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZQ0KICAgICAgICAgICAg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUs IFNIQUxMDQogICAgICAgICAgICBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGlu IHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24NCiAgICAgICAgICAgIGFzIHByYWN0aWNhbCBh IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAgICAgICAg ICAgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVk IGxhbmd1YWdlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzMV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwg MjAwNw0KDQoNCiAgICAgICAgICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9u IG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAgICAgICAgIFJldmlld2VyIGFuZCBNVVNU IGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIGxhbmd1YWdlDQogICAgICAgICAg ICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgQi4gIEZvciBhbGwgc3Vi dGFncyB3aG9zZSBtZWFuaW5nIGlzIGRlcml2ZWQgZnJvbSBhbiBleHRlcm5hbA0KICAgICAg ICAgICAgc3RhbmRhcmQgKHRoYXQgaXMsIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgSVNPIDMx NjYsIG9yIFVODQogICAgICAgICAgICBNLjQ5KSwgaWYgYSBuZXcgbWVhbmluZyBpcyBhc3Np Z25lZCB0byBhbiBleGlzdGluZyBjb2RlIGFuZA0KICAgICAgICAgICAgdGhlIG5ldyBtZWFu aW5nIGJyb2FkZW5zIHRoZSBtZWFuaW5nIG9mIHRoYXQgY29kZSwgdGhlbiB0aGUNCiAgICAg ICAgICAgIG1lYW5pbmcgZm9yIHRoZSBhc3NvY2lhdGVkIHN1YnRhZyBNQVkgYmUgY2hhbmdl ZCB0byBtYXRjaC4NCiAgICAgICAgICAgIFRoZSBtZWFuaW5nIG9mIGEgc3VidGFnIE1VU1Qg Tk9UIGJlIG5hcnJvd2VkLCBob3dldmVyLCBhcw0KICAgICAgICAgICAgdGhpcyBjYW4gcmVz dWx0IGluIGFuIHVua25vd24gcHJvcG9ydGlvbiBvZiB0aGUgZXhpc3RpbmcNCiAgICAgICAg ICAgIHVzZXMgb2YgYSBzdWJ0YWcgYmVjb21pbmcgaW52YWxpZC4gIE5vdGU6IElTTyA2MzkN CiAgICAgICAgICAgIG1haW50ZW5hbmNlIGFnZW5jeS9yZWdpc3RyYXRpb24gYXV0aG9yaXR5 IChNQS9SQSkgaGFzDQogICAgICAgICAgICBhZG9wdGVkIGEgc2ltaWxhciBzdGFiaWxpdHkg cG9saWN5Lg0KDQogICAgICAgIEMuICBGb3IgSVNPIDE1OTI0IGNvZGVzLCBpZiB0aGUgbmV3 bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIG5vdCByZXByZXNl bnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlDQogICAgICAgICAg ICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu NSwgU0hBTEwNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcg aW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAgICAgYXMgcHJhY3RpY2Fs IGEgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAgICAg ICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJl ZCB2YXJpYW50DQogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlv biBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICAgICAgICAgICBSZXZpZXdlciBhbmQgTVVT VCBjb25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9ucyBvbiB2YXJpYW50DQogICAgICAgICAg ICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgRC4gIEZvciBJU08gMzE2 NiBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAg ICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgVU4gTS40OSBjb2RlIGFzIGFub3Ro ZXIgJ3JlZ2lvbicNCiAgICAgICAgICAgIHN1YnRhZywgdGhlbiB0aGUgZXhpc3RpbmcgcmVn aW9uIHN1YnRhZyByZW1haW5zIGFzIHRoZQ0KICAgICAgICAgICAgcHJlZmVycmVkIHZhbHVl IGZvciB0aGF0IHJlZ2lvbiBhbmQgbm8gbmV3IGVudHJ5IGlzIGNyZWF0ZWQuDQogICAgICAg ICAgICBBIGNvbW1lbnQgTUFZIGJlIGFkZGVkIHRvIHRoZSBleGlzdGluZyByZWdpb24gc3Vi dGFnDQogICAgICAgICAgICBpbmRpY2F0aW5nIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIG5l dyBJU08gMzE2NiBjb2RlLg0KDQogICAgICAgIEUuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlm IHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgYXNz b2NpYXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQgaXMgbm90IHJlcHJlc2VudGVkIGJ5 IGFuDQogICAgICAgICAgICBleGlzdGluZyByZWdpb24gc3VidGFnLCB0aGVuIHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmV2aWV3ZXIsDQogICAgICAgICAgICBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiAzLjUsIFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3INCiAgICAgICAgICAgIGVu dGVyaW5nIHRoZSBhcHByb3ByaWF0ZSBVTiBNLjQ5IGNvdW50cnkgY29kZSBhcyBhbiBlbnRy eSBpbg0KICAgICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgICAgICAgRi4gIEZv ciBJU08gMzE2NiBjb2RlcywgaWYgdGhlcmUgaXMgbm8gYXNzb2NpYXRlZCBVTiBudW1lcmlj DQogICAgICAgICAgICBjb2RlLCB0aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIg U0hBTEwgcGV0aXRpb24gdGhlDQogICAgICAgICAgICBVTiB0byBjcmVhdGUgb25lLiAgSWYg dGhlcmUgaXMgbm8gcmVzcG9uc2UgZnJvbSB0aGUgVU4NCiAgICAgICAgICAgIHdpdGhpbiBu aW5ldHkgZGF5cyBvZiB0aGUgcmVxdWVzdCBiZWluZyBzZW50LCB0aGUgTGFuZ3VhZ2UNCiAg ICAgICAgICAgIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9y IGVudGVyaW5nIGluIHRoZQ0KICAgICAgICAgICAgSUFOQSByZWdpc3RyeSBhcyBzb29uIGFz IHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgdmFyaWFudA0KICAgICAgICAgICAgc3VidGFnIGFz IGFuIGFsdGVybmF0ZSB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YNCiAg ICAgICAgICAgIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIHdpbGwgYmUgYXQgdGhl IGRpc2NyZXRpb24gb2YNCiAgICAgICAgICAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlcg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMzJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICAgICAgICByZXN0cmljdGlvbnMg b24gdmFyaWFudCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzDQogICAgICAgICAg ICBzaXR1YXRpb24gaXMgdmVyeSB1bmxpa2VseSB0byBldmVyIG9jY3VyLg0KDQogICAxNi4g IFVOIE0uNDkgaGFzIGNvZGVzIGZvciBib3RoIGNvdW50cmllcyBhbmQgYXJlYXMgKHN1Y2gg YXMgJzI3NicNCiAgICAgICAgZm9yIEdlcm1hbnkpIGFuZCBnZW9ncmFwaGljYWwgcmVnaW9u cyBhbmQgc3ViLXJlZ2lvbnMgKHN1Y2ggYXMNCiAgICAgICAgJzE1MCcgZm9yIEV1cm9wZSku ICBVTiBNLjQ5IGNvdW50cnkgb3IgYXJlYSBjb2RlcyBmb3Igd2hpY2gNCiAgICAgICAgdGhl cmUgaXMgbm8gY29ycmVzcG9uZGluZyBJU08gMzE2NiBjb2RlIFNIT1VMRCBOT1QgYmUNCiAg ICAgICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2 NiBjb2RlIHRoYXQgaXMNCiAgICAgICAgYmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBh biBleGlzdGluZyBzdWJ0YWcuICBJZiBzdWNoIGEgY29kZQ0KICAgICAgICBiZWNvbWVzIG5l Y2Vzc2FyeSwgdGhlbiB0aGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDMxNjYN CiAgICAgICAgU0hPVUxEIGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29kZSB0 byB0aGUgcmVnaW9uLiAgSWYNCiAgICAgICAgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUgYXNz aWdubWVudCBieSBJU08gMzE2NiBpcyByZWZ1c2VkIG9yIG5vdA0KICAgICAgICBhY3RlZCBv biBpbiBhIHRpbWVseSBtYW5uZXIsIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBkZXNjcmli ZWQNCiAgICAgICAgaW4gU2VjdGlvbiAzLjUgTUFZIHRoZW4gYmUgdXNlZCB0byByZWdpc3Rl ciB0aGUgY29ycmVzcG9uZGluZyBVTg0KICAgICAgICBNLjQ5IGNvZGUuICBUaGlzIHdheSwg VU4gTS40OSBjb2RlcyByZW1haW4gYXZhaWxhYmxlIGFzIHRoZQ0KICAgICAgICB2YWx1ZSBv ZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2NiByZWFzc2lnbnMgYQ0KICAg ICAgICBkZXByZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS4NCg0KICAgMTcuICBTdGFi aWxpdHkgcHJvdmlzaW9ucyBhcHBseSB0byBncmFuZGZhdGhlcmVkIHRhZ3Mgd2l0aCB0aGlz DQogICAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGNvbXBvc2Ug b25lIG9mIHRoZQ0KICAgICAgICBncmFuZGZhdGhlcmVkIHRhZ3MgZnJvbSByZWdpc3RlcmVk IHN1YnRhZ3MsIHRoZW4gdGhlIGZpZWxkDQogICAgICAgICdUeXBlJyBpbiB0aGF0IHJlY29y ZCBpcyBjaGFuZ2VkIGZyb20gJ2dyYW5kZmF0aGVyZWQnIHRvDQogICAgICAgICdyZWR1bmRh bnQnLiAgTm90ZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0IGxhbmd1YWdlIHRhZ3MgdGhh dA0KICAgICAgICBtYXRjaCB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcsIHNpbmNlIHRoZXNlIHRh Z3Mgd2lsbCBub3cgbWF0Y2gNCiAgICAgICAgdmFsaWQgZ2VuZXJhdGl2ZSBzdWJ0YWcgc2Vx dWVuY2VzLiAgRm9yIGV4YW1wbGUsIHRoaXMgZG9jdW1lbnQNCiAgICAgICAgY2F1c2VkIHRo ZSBJU08gNjM5LTMgY29kZSAnZ2FuJywgdXNlZCBpbiB0aGUgcmVkdW5kYW50IHRhZyAiemgt DQogICAgICAgIGdhbiIsIHRvIGJlIHJlZ2lzdGVyZWQgYXMgYW4gZXh0ZW5kZWQgbGFuZ3Vh Z2Ugc3VidGFnLiAgVGhlDQogICAgICAgIGZvcm1lcmx5LWdyYW5kZmF0aGVyZWQgdGFnICJ6 aC1nYW4iIGJlY2FtZSBhIHJlZHVuZGFudCB0YWcgYXMgYQ0KICAgICAgICByZXN1bHQgKGJ1 dCBleGlzdGluZyBjb250ZW50IG9yIGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSAiemgtDQog ICAgICAgIGdhbiIgcmVtYWluIHZhbGlkKS4NCg0KMy41LiAgUmVnaXN0cmF0aW9uIFByb2Nl ZHVyZSBmb3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUgTVVTVCBi ZSB1c2VkIGJ5IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3QgY3Vy cmVudGx5IGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAgT25s eSBzdWJ0YWdzIG9mIHR5cGUgJ2xhbmd1YWdlJyBhbmQgJ3ZhcmlhbnQnIHdpbGwgYmUgY29u c2lkZXJlZCBmb3INCiAgIGluZGVwZW5kZW50IHJlZ2lzdHJhdGlvbiBvZiBuZXcgc3VidGFn cy4gIEhhbmRsaW5nIG9mIHN1YnRhZ3MgbmVlZGVkDQogICBmb3Igc3RhYmlsaXR5IGFuZCBz dWJ0YWdzIG5lY2Vzc2FyeSB0byBrZWVwIHRoZSByZWdpc3RyeSBzeW5jaHJvbml6ZWQNCiAg IHdpdGggSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgd2l0aGlu IHRoZSBsaW1pdHMNCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhcmUgZGVzY3JpYmVk IGluIFNlY3Rpb24gMy4zLiAgU3RhYmlsaXR5DQogICBwcm92aXNpb25zIGFyZSBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIFRoaXMgcHJvY2VkdXJlIE1BWSBhbHNvIGJlIHVz ZWQgdG8gcmVnaXN0ZXIgb3IgYWx0ZXIgdGhlIGluZm9ybWF0aW9uDQogICBmb3IgdGhlICdE ZXNjcmlwdGlvbicsICdDb21tZW50cycsICdEZXByZWNhdGVkJywgJ1ByZWZpeCcsIG9yDQog ICAnU3VwcHJlc3MtU2NyaXB0JyBmaWVsZHMgaW4gYSBzdWJ0YWcncyByZWNvcmQgYXMgZGVz Y3JpYmVkIGluDQogICBTZWN0aW9uIDMuNC4gIENoYW5nZXMgdG8gYWxsIG90aGVyIGZpZWxk cyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcmUNCiAgIE5PVCBwZXJtaXR0ZWQuDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAg ICAgICAgICBbUGFnZSAzM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIFJlZ2lz dGVyaW5nIGEgbmV3IHN1YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlmaWNhdGlvbnMgdG8gYW4g ZXhpc3RpbmcNCiAgIHRhZyBvciBzdWJ0YWcgc3RhcnRzIHdpdGggdGhlIHJlcXVlc3RlciBm aWxsaW5nIG91dCB0aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtIHJlcHJvZHVjZWQgYmVsb3cu ICBOb3RlIHRoYXQgZWFjaCByZXNwb25zZSBpcyBub3QgbGltaXRlZCBpbg0KICAgc2l6ZSBz byB0aGF0IHRoZSByZXF1ZXN0IGNhbiBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRoZSByZWdpc3Ry YXRpb24uDQogICBUaGUgZmllbGRzIGluIHRoZSAiUmVjb3JkIFJlcXVlc3RlZCIgc2VjdGlv biBTSE9VTEQgZm9sbG93IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMy4xLg0K DQogICBMQU5HVUFHRSBTVUJUQUcgUkVHSVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUgb2Yg cmVxdWVzdGVyOg0KICAgMi4gRS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4g UmVjb3JkIFJlcXVlc3RlZDoNCg0KICAgICAgVHlwZToNCiAgICAgIFN1YnRhZzoNCiAgICAg IERlc2NyaXB0aW9uOg0KICAgICAgUHJlZml4Og0KICAgICAgUHJlZmVycmVkLVZhbHVlOg0K ICAgICAgRGVwcmVjYXRlZDoNCiAgICAgIFN1cHByZXNzLVNjcmlwdDoNCiAgICAgIENvbW1l bnRzOg0KDQogICA0LiBJbnRlbmRlZCBtZWFuaW5nIG9mIHRoZSBzdWJ0YWc6DQogICA1LiBS ZWZlcmVuY2UgdG8gcHVibGlzaGVkIGRlc2NyaXB0aW9uDQogICAgICBvZiB0aGUgbGFuZ3Vh Z2UgKGJvb2sgb3IgYXJ0aWNsZSk6DQogICA2LiBBbnkgb3RoZXIgcmVsZXZhbnQgaW5mb3Jt YXRpb246DQoNCiAgICAgICAgICAgICAgRmlndXJlIDU6IFRoZSBMYW5ndWFnZSBTdWJ0YWcg UmVnaXN0cmF0aW9uIEZvcm0NCg0KICAgVGhlIHN1YnRhZyByZWdpc3RyYXRpb24gZm9ybSBN VVNUIGJlIHNlbnQgdG8NCiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4gZm9yIGEgdHdv LXdlZWsgcmV2aWV3IHBlcmlvZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0ZWQgdG8g SUFOQS4gIChUaGlzIGlzIGFuIG9wZW4gbGlzdCBhbmQgY2FuIGJlIGpvaW5lZCBieQ0KICAg c2VuZGluZyBhIHJlcXVlc3QgdG8gPGlldGYtbGFuZ3VhZ2VzLXJlcXVlc3RAaWFuYS5vcmc+ LiAgVGhlIGxpc3QgY2FuDQogICBiZSBob3N0ZWQgYnkgSUFOQSBvciBieSBhbnkgdGhpcmQg cGFydHkgYXQgdGhlIHJlcXVlc3Qgb2YgSUVTRy4pDQoNCiAgIFZhcmlhbnQgc3VidGFncyBh cmUgdXN1YWxseSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIHBhcnRpY3VsYXINCiAgIHJh bmdlIG9mIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAncm96YWon IGlzIGludGVuZGVkDQogICBmb3IgdXNlIHdpdGggbGFuZ3VhZ2UgdGFncyB0aGF0IHN0YXJ0 IHdpdGggdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1YnRhZyAic2wiLCBzaW5jZSBSZXNp YW4gaXMgYSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4gIFRodXMsIHRoZQ0KICAgc3VidGFnICdy b3phaicgd291bGQgYmUgYXBwcm9wcmlhdGUgaW4gdGFncyBzdWNoIGFzICJzbC1MYXRuLXJv emFqIg0KICAgb3IgInNsLUlULXJvemFqIi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgc3RvcmVk IGluIHRoZSAnUHJlZml4JyBmaWVsZA0KICAgaW4gdGhlIHJlZ2lzdHJ5LiAgVmFyaWFudCBy ZWdpc3RyYXRpb24gcmVxdWVzdHMgU0hPVUxEIGluY2x1ZGUgYXQNCiAgIGxlYXN0IG9uZSAn UHJlZml4JyBmaWVsZCBpbiB0aGUgcmVnaXN0cmF0aW9uIGZvcm0uDQoNCiAgIEV4dGVuZGVk IGxhbmd1YWdlIHN1YnRhZ3MgTVVTVCBpbmNsdWRlIGV4YWN0bHkgb25lICdQcmVmaXgnIGZp ZWxkLg0KDQogICBUaGUgJ1ByZWZpeCcgZmllbGQgZm9yIGEgZ2l2ZW4gcmVnaXN0ZXJlZCBz dWJ0YWcgZXhpc3RzIGluIHRoZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVz YWdlLiAgQWRkaXRpb25hbCBwcmVmaXhlcyBNQVkgYmUgYWRkZWQgYnkNCiAgIGZpbGluZyBh biBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiBmb3JtLiAgSW4gdGhhdCBmb3JtLCB0aGUgIkFu eSBvdGhlcg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMzRdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIw MDcNCg0KDQogICByZWxldmFudCBpbmZvcm1hdGlvbjoiIGZpZWxkIE1VU1QgaW5kaWNhdGUg dGhhdCBpdCBpcyB0aGUgYWRkaXRpb24gb2YNCiAgIGEgcHJlZml4Lg0KDQogICBSZXF1ZXN0 cyB0byBhZGQgYSBwcmVmaXggdG8gYSB2YXJpYW50IHN1YnRhZyB0aGF0IGltcGx5IGEgZGlm ZmVyZW50DQogICBzZW1hbnRpYyBtZWFuaW5nIHdpbGwgcHJvYmFibHkgYmUgcmVqZWN0ZWQu ICBGb3IgZXhhbXBsZSwgYSByZXF1ZXN0DQogICB0byBhZGQgdGhlIHByZWZpeCAiZGUiIHRv IHRoZSBzdWJ0YWcgJ25lZGlzJyBzbyB0aGF0IHRoZSB0YWcgImRlLQ0KICAgbmVkaXMiIHJl cHJlc2VudGVkIHNvbWUgR2VybWFuIGRpYWxlY3Qgd291bGQgYmUgcmVqZWN0ZWQuICBUaGUN CiAgICduZWRpcycgc3VidGFnIHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIFNsb3ZlbmlhbiBk aWFsZWN0IGFuZCB0aGUNCiAgIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIHdvdWxkIGNoYW5n ZSB0aGUgc2VtYW50aWMgbWVhbmluZyBhc3NpZ25lZCB0bw0KICAgdGhlIHN1YnRhZy4gIEEg c2VwYXJhdGUgc3VidGFnIFNIT1VMRCBiZSBwcm9wb3NlZCBpbnN0ZWFkLg0KDQogICBUaGUg J0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIGNvbnRhaW4gYSBkZXNjcmlwdGlvbiBvZiB0aGUg dGFnIGJlaW5nDQogICByZWdpc3RlcmVkIHdyaXR0ZW4gb3IgdHJhbnNjcmliZWQgaW50byB0 aGUgTGF0aW4gc2NyaXB0OyBpdCBNQVkgYWxzbw0KICAgaW5jbHVkZSBhIGRlc2NyaXB0aW9u IGluIGEgbm9uLUxhdGluIHNjcmlwdC4gIE5vbi1BU0NJSSBjaGFyYWN0ZXJzDQogICBNVVNU IGJlIGVzY2FwZWQgdXNpbmcgdGhlIHN5bnRheCBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEu ICBUaGUNCiAgICdEZXNjcmlwdGlvbicgZmllbGQgaXMgdXNlZCBmb3IgaWRlbnRpZmljYXRp b24gcHVycG9zZXMgYW5kIGRvZXNuJ3QNCiAgIG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUg YWN0dWFsIG5hdGl2ZSBuYW1lIG9mIHRoZSBsYW5ndWFnZSBvcg0KICAgdmFyaWF0aW9uIG9y IHRvIGJlIGluIGFueSBwYXJ0aWN1bGFyIGxhbmd1YWdlLg0KDQogICBXaGlsZSB0aGUgJ0Rl c2NyaXB0aW9uJyBmaWVsZCBpdHNlbGYgaXMgbm90IGd1YXJhbnRlZWQgdG8gYmUgc3RhYmxl DQogICBhbmQgZXJyYXRhIGNvcnJlY3Rpb25zIE1BWSBiZSB1bmRlcnRha2VuIGZyb20gdGlt ZSB0byB0aW1lLCBhdHRlbXB0cw0KICAgdG8gcHJvdmlkZSB0cmFuc2xhdGlvbnMgb3IgdHJh bnNjcmlwdGlvbnMgb2YgZW50cmllcyBpbiB0aGUgcmVnaXN0cnkNCiAgIGl0c2VsZiB3aWxs IHByb2JhYmx5IGJlIGZyb3duZWQgdXBvbiBieSB0aGUgY29tbXVuaXR5IG9yIHJlamVjdGVk DQogICBvdXRyaWdodCwgYXMgY2hhbmdlcyBvZiB0aGlzIG5hdHVyZSBoYXZlIGFuIGltcGFj dCBvbiB0aGUgcHJvdmlzaW9ucw0KICAgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIFdoZW4gdGhl IHR3by13ZWVrIHBlcmlvZCBoYXMgcGFzc2VkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmll d2VyDQogICBNVVNUIHRha2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgYWN0aW9uczoNCg0KICAg ICAgRm9yd2FyZCB0aGUgcmVjb3JkIHRvIGJlIGluc2VydGVkIG9yIG1vZGlmaWVkIHRvIGlh bmFAaWFuYS5vcmcNCiAgICAgIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDMuMw0KDQogICAgICBFeHBsaWNpdGx5IHJlamVjdCB0aGUgcmVxdWVz dCBiZWNhdXNlIG9mIHNpZ25pZmljYW50IG9iamVjdGlvbnMNCiAgICAgIHJhaXNlZCBvbiB0 aGUgbGlzdCBvciBkdWUgdG8gcHJvYmxlbXMgd2l0aCBjb25zdHJhaW50cyBpbiB0aGlzDQog ICAgICBkb2N1bWVudCAod2hpY2ggTVVTVCBiZSBleHBsaWNpdGx5IGNpdGVkKQ0KDQogICAg ICBFeHRlbmQgdGhlIHJldmlldyBwZXJpb2QgYnkgZ3JhbnRpbmcgYW4gYWRkaXRpb25hbCB0 d28td2Vlaw0KICAgICAgaW5jcmVtZW50IHRvIHBlcm1pdCBmdXJ0aGVyIGRpc2N1c3Npb24u ICBBZnRlciBlYWNoIHR3by13ZWVrDQogICAgICBpbmNyZW1lbnQsIHRoZSBMYW5ndWFnZSBT dWJ0YWcgUmV2aWV3ZXIgTVVTVCBpbmRpY2F0ZSBvbiB0aGUgbGlzdA0KICAgICAgd2hldGhl ciB0aGUgcmVnaXN0cmF0aW9uIGhhcyBiZWVuIGFjY2VwdGVkLCByZWplY3RlZCwgb3IgZXh0 ZW5kZWQuDQoNCiAgIE5vdGUgdGhhdCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1B WSByYWlzZSBvYmplY3Rpb25zIG9uIHRoZQ0KICAgbGlzdCBpZiBoZSBvciBzaGUgc28gZGVz aXJlcy4gIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUNCiAgIG9iamVjdGlvbiBN VVNUIGJlIG1hZGUgcHVibGljbHkuDQoNCiAgIFRoZSBhcHBsaWNhbnQgaXMgZnJlZSB0byBt b2RpZnkgYSByZWplY3RlZCBhcHBsaWNhdGlvbiB3aXRoDQogICBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGFuZCBzdWJtaXQgaXQgYWdhaW47IHRoaXMgcmVzdGFydHMgdGhlIHR3by0NCiAg IHdlZWsgY29tbWVudCBwZXJpb2QuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzNV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIERlY2lzaW9ucyBtYWRlIGJ5IHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGJlIGFwcGVhbGVkIHRvIHRoZQ0KICAgSUVTRyBbUkZD MjAyOF0gdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXIgSUVURiBkZWNpc2lvbnMNCiAg IFtSRkMyMDI2XS4gIFRoaXMgaW5jbHVkZXMgYSBkZWNpc2lvbiB0byBleHRlbmQgdGhlIHJl dmlldyBwZXJpb2Qgb3INCiAgIHRoZSBmYWlsdXJlIHRvIGFubm91bmNlIGEgZGVjaXNpb24g aW4gYSBjbGVhciBhbmQgdGltZWx5IG1hbm5lci4NCg0KICAgQWxsIGFwcHJvdmVkIHJlZ2lz dHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUgZGlyZWN0b3J5DQog ICBodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFuZ3VhZ2VzIi4N 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 IGJlZm9yZSBpdA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMzZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmls IDIwMDcNCg0KDQogICAgICB3aWxsIGJlIHJlZ2lzdGVyZWQgYXMgYSBwcmltYXJ5IGxhbmd1 YWdlIHN1YnRhZyBpbiB0aGUgSUFOQQ0KICAgICAgcmVnaXN0cnkgKHRvIHRoZSBleHRlbnQg dGhhdCBpdCBpcyB2ZXJ5IHVubGlrZWx5IHRoYXQgYW55IHN1YnRhZ3MNCiAgICAgIHdpbGwg YmUgcmVnaXN0ZXJlZCBvZiB0aGlzIHR5cGUpLg0KDQogICBvICBEaWFsZWN0IG9yIG90aGVy 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 IFdhc2hpbmd0b24sIEQuQy4gMjA1NDAgVVNBDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzN10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIFBob25lOiArMSAyMDIgNzA3IDYyMzcg RmF4OiArMSAyMDIgNzA3IDAxMTUNCiAgIFVSTDogaHR0cDovL3d3dy5sb2MuZ292L3N0YW5k YXJkcy9pc282MzktMg0KDQogICBJU08gNjM5LTMgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFn ZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlzdCBvZiBs 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 IHVuZGVyc3RhbmQgbGFuZ3VhZ2UgdGFncy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDM4XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgVGhlIHN0cnVjdHVyZSBhbmQgZm9ybSBv ZiBleHRlbnNpb25zIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgc28NCiAgIHRoYXQg aW1wbGVtZW50YXRpb25zIGNhbiBiZSBjcmVhdGVkIHRoYXQgYXJlIGZvcndhcmQgY29tcGF0 aWJsZSB3aXRoDQogICBhcHBsaWNhdGlvbnMgdGhhdCBtaWdodCBiZSBjcmVhdGVkIHVzaW5n IHNpbmdsZXRvbnMgaW4gdGhlIGZ1dHVyZS4NCiAgIEluIGFkZGl0aW9uLCBkZWZpbmluZyBh IG1lY2hhbmlzbSBmb3IgbWFpbnRhaW5pbmcgc2luZ2xldG9ucyB3aWxsDQogICBsZW5kIHN0 YWJpbGl0eSB0byB0aGlzIGRvY3VtZW50IGJ5IHJlZHVjaW5nIHRoZSBsaWtlbHkgbmVlZCBm b3INCiAgIGZ1dHVyZSByZXZpc2lvbnMgb3IgdXBkYXRlcy4NCg0KICAgU2luZ2xlLWNoYXJh Y3RlciBzdWJ0YWdzIGFyZSBhc3NpZ25lZCBieSBJQU5BIHVzaW5nIHRoZSAiSUVURg0KICAg Q29uc2Vuc3VzIiBwb2xpY3kgZGVmaW5lZCBieSBbUkZDMjQzNF0uICBUaGlzIHBvbGljeSBy ZXF1aXJlcyB0aGUNCiAgIGRldmVsb3BtZW50IG9mIGFuIFJGQywgd2hpY2ggU0hBTEwgZGVm aW5lIHRoZSBuYW1lLCBwdXJwb3NlLA0KICAgcHJvY2Vzc2VzLCBhbmQgcHJvY2VkdXJlcyBm b3IgbWFpbnRhaW5pbmcgdGhlIHN1YnRhZ3MuICBUaGUNCiAgIG1haW50YWluaW5nIG9yIHJl Z2lzdGVyaW5nIGF1dGhvcml0eSwgaW5jbHVkaW5nIG5hbWUsIGNvbnRhY3QgZW1haWwsDQog ICBkaXNjdXNzaW9uIGxpc3QgZW1haWwsIGFuZCBVUkwgbG9jYXRpb24gb2YgdGhlIHJlZ2lz dHJ5LCBNVVNUIGJlDQogICBpbmRpY2F0ZWQgY2xlYXJseSBpbiB0aGUgUkZDLiAgVGhlIFJG QyBNVVNUIHNwZWNpZnkgb3IgaW5jbHVkZSBlYWNoDQogICBvZiB0aGUgZm9sbG93aW5nOg0K DQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIHJlZmVyZW5jZSB0aGUgc3BlY2lmaWMg dmVyc2lvbiBvciByZXZpc2lvbg0KICAgICAgb2YgdGhpcyBkb2N1bWVudCB0aGF0IGdvdmVy bnMgaXRzIGNyZWF0aW9uIGFuZCBNVVNUIHJlZmVyZW5jZSB0aGlzDQogICAgICBzZWN0aW9u IG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIGFuZCBhbGwg c3VidGFncyBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uDQogICAgICBNVVNUIGZvbGxv dyB0aGUgQUJORiBhbmQgb3RoZXIgcnVsZXMgZm9yIHRoZSBmb3JtYXRpb24gb2YgdGFncyBh bmQNCiAgICAgIHN1YnRhZ3MgYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFy dGljdWxhciwgaXQgTVVTVA0KICAgICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25p ZmljYW50IGFuZCB0aGF0IHN1YnRhZ3MgTVVTVCBOT1QNCiAgICAgIGV4Y2VlZCBlaWdodCBj aGFyYWN0ZXJzIGluIGxlbmd0aC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBz cGVjaWZ5IGEgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uLg0KDQogICBvICBUaGUgc3BlY2lm aWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIE1VU1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlDQog ICAgICBJbnRlcm5ldCBhbmQgYXQgbm8gY29zdC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRp b24gTVVTVCBiZSBpbiB0aGUgcHVibGljIGRvbWFpbiBvciBhdmFpbGFibGUgdmlhIGENCiAg ICAgIHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2VwdGFibGUgdG8gdGhlIElFVEYgYW5kIHNw ZWNpZmllZCBpbiB0aGUNCiAgICAgIFJGQy4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24g TVVTVCBiZSB2ZXJzaW9uZWQsIGFuZCBlYWNoIHZlcnNpb24gb2YgdGhlDQogICAgICBzcGVj aWZpY2F0aW9uIE1VU1QgYmUgbnVtYmVyZWQsIGRhdGVkLCBhbmQgc3RhYmxlLg0KDQogICBv ICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIHN0YWJsZS4gIFRoYXQgaXMsIGV4dGVuc2lv biBzdWJ0YWdzLA0KICAgICAgb25jZSBkZWZpbmVkIGJ5IGEgc3BlY2lmaWNhdGlvbiwgTVVT VCBOT1QgYmUgcmV0cmFjdGVkIG9yIGNoYW5nZQ0KICAgICAgaW4gbWVhbmluZyBpbiBhbnkg c3Vic3RhbnRpYWwgd2F5Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGluY2x1 ZGUgaW4gYSBzZXBhcmF0ZSBzZWN0aW9uIHRoZQ0KICAgICAgcmVnaXN0cmF0aW9uIGZvcm0g cmVwcm9kdWNlZCBpbiB0aGlzIHNlY3Rpb24gKGJlbG93KSB0byBiZSB1c2VkIGluDQogICAg ICByZWdpc3RlcmluZyB0aGUgZXh0ZW5zaW9uIHVwb24gcHVibGljYXRpb24gYXMgYW4gUkZD Lg0KDQogICBvICBJQU5BIE1VU1QgYmUgaW5mb3JtZWQgb2YgY2hhbmdlcyB0byB0aGUgY29u dGFjdCBpbmZvcm1hdGlvbiBhbmQNCiAgICAgIFVSTCBmb3IgdGhlIHNwZWNpZmljYXRpb24u DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIw MDcgICAgICAgICAgICAgICBbUGFnZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoN CiAgIElBTkEgd2lsbCBtYWludGFpbiBhIHJlZ2lzdHJ5IG9mIGFsbG9jYXRlZCBzaW5nbGUt Y2hhcmFjdGVyDQogICAoc2luZ2xldG9uKSBzdWJ0YWdzLiAgVGhpcyByZWdpc3RyeSBNVVNU IHVzZSB0aGUgcmVjb3JkLWphciBmb3JtYXQNCiAgIGRlc2NyaWJlZCBieSB0aGUgQUJORiBp biBTZWN0aW9uIDMuMS4gIFVwb24gcHVibGljYXRpb24gb2YgYW4NCiAgIGV4dGVuc2lvbiBh cyBhbiBSRkMsIHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkgZGVmaW5lZCBpbiB0aGUgUkZD DQogICBNVVNUIGZvcndhcmQgdGhpcyByZWdpc3RyYXRpb24gZm9ybSB0byBpZXNnQGlldGYu b3JnLCB3aG8gTVVTVA0KICAgZm9yd2FyZCB0aGUgcmVxdWVzdCB0byBpYW5hQGlhbmEub3Jn LiAgVGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBvZg0KICAgdGhlIGV4dGVuc2lvbiBNVVNU IG1haW50YWluIHRoZSBhY2N1cmFjeSBvZiB0aGUgcmVjb3JkIGJ5IHNlbmRpbmcgYW4NCiAg IHVwZGF0ZWQgZnVsbCBjb3B5IG9mIHRoZSByZWNvcmQgdG8gaWFuYUBpYW5hLm9yZyB3aXRo IHRoZSBzdWJqZWN0DQogICBsaW5lICJMQU5HVUFHRSBUQUcgRVhURU5TSU9OIFVQREFURSIg d2hlbmV2ZXIgY29udGVudCBjaGFuZ2VzLiAgT25seQ0KICAgdGhlICdDb21tZW50cycsICdD b250YWN0X0VtYWlsJywgJ01haWxpbmdfTGlzdCcsIGFuZCAnVVJMJyBmaWVsZHMgTUFZDQog ICBiZSBtb2RpZmllZCBpbiB0aGVzZSB1cGRhdGVzLg0KDQogICBGYWlsdXJlIHRvIG1haW50 YWluIHRoaXMgcmVjb3JkLCBtYWludGFpbiB0aGUgY29ycmVzcG9uZGluZyByZWdpc3RyeSwN CiAgIG9yIG1lZXQgb3RoZXIgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IHRoaXMgc2VjdGlvbiBv ZiB0aGlzIGRvY3VtZW50IE1BWQ0KICAgYmUgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQzIw MjhdIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYNCiAgIGRlY2lzaW9ucyAo c2VlIFtSRkMyMDI2XSkgYW5kIE1BWSByZXN1bHQgaW4gdGhlIGF1dGhvcml0eSB0byBtYWlu dGFpbg0KICAgdGhlIGV4dGVuc2lvbiBiZWluZyB3aXRoZHJhd24gb3IgcmVhc3NpZ25lZCBi eSB0aGUgSUVTRy4NCiAgICUlDQogICBJZGVudGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQog ICBDb21tZW50czoNCiAgIEFkZGVkOg0KICAgUkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29u dGFjdF9FbWFpbDoNCiAgIE1haWxpbmdfTGlzdDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBG aWd1cmUgNjogRm9ybWF0IG9mIFJlY29yZHMgaW4gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNp b25zIFJlZ2lzdHJ5DQoNCiAgICdJZGVudGlmaWVyJyBjb250YWlucyB0aGUgc2luZ2xlLWNo YXJhY3RlciBzdWJ0YWcgKHNpbmdsZXRvbikNCiAgIGFzc2lnbmVkIHRvIHRoZSBleHRlbnNp b24uICBUaGUgSW50ZXJuZXQtRHJhZnQgc3VibWl0dGVkIHRvIGRlZmluZQ0KICAgdGhlIGV4 dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGljaCBsZXR0ZXIgb3IgZGlnaXQgdG8gdXNlLCBh bHRob3VnaA0KICAgdGhlIElFU0cgTUFZIGNoYW5nZSB0aGUgYXNzaWdubWVudCB3aGVuIGFw cHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNvbnRhaW5zIHRoZSBuYW1l IGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQ29tbWVudHMnIGlz IGFuIE9QVElPTkFMIGZpZWxkIGFuZCBNQVkgY29udGFpbiBhIGJyb2FkZXIgZGVzY3JpcHRp b24NCiAgIG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29udGFpbnMgdGhlIGRh dGUgdGhlIFJGQyB3YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0 IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogMjAwNC0wNi0yOCByZXBy ZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0LCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0K DQogICAnUkZDJyBjb250YWlucyB0aGUgUkZDIG51bWJlciBhc3NpZ25lZCB0byB0aGUgZXh0 ZW5zaW9uLg0KDQogICAnQXV0aG9yaXR5JyBjb250YWlucyB0aGUgbmFtZSBvZiB0aGUgbWFp bnRhaW5pbmcgYXV0aG9yaXR5IGZvciB0aGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQwXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgZXh0ZW5zaW9uLg0KDQogICAnQ29udGFj dF9FbWFpbCcgY29udGFpbnMgdGhlIGVtYWlsIGFkZHJlc3MgdXNlZCB0byBjb250YWN0IHRo ZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICAnTWFpbGluZ19MaXN0JyBjb250 YWlucyB0aGUgVVJMIG9yIHN1YnNjcmlwdGlvbiBlbWFpbCBhZGRyZXNzIG9mIHRoZQ0KICAg bWFpbGluZyBsaXN0IHVzZWQgYnkgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAg J1VSTCcgY29udGFpbnMgdGhlIFVSTCBvZiB0aGUgcmVnaXN0cnkgZm9yIHRoaXMgZXh0ZW5z aW9uLg0KDQogICBUaGUgZGV0ZXJtaW5hdGlvbiBvZiB3aGV0aGVyIGFuIEludGVybmV0LURy YWZ0IG1lZXRzIHRoZSBhYm92ZQ0KICAgY29uZGl0aW9ucyBhbmQgdGhlIGRlY2lzaW9uIHRv IGdyYW50IG9yIHdpdGhob2xkIHN1Y2ggYXV0aG9yaXR5IHJlc3RzDQogICBzb2xlbHkgd2l0 aCB0aGUgSUVTRyBhbmQgaXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJldmlldyBhbmQgYXBw ZWFscw0KICAgcHJvY2VzcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJGQyBwcm9jZXNzLg0KDQog ICBFeHRlbnNpb24gYXV0aG9ycyBhcmUgc3Ryb25nbHkgY2F1dGlvbmVkIHRoYXQgbWFueSAo aW5jbHVkaW5nIG1vc3QNCiAgIHdlbGwtZm9ybWVkKSBwcm9jZXNzb3JzIHdpbGwgYmUgdW5h d2FyZSBvZiBhbnkgc3BlY2lhbCByZWxhdGlvbnNoaXBzDQogICBvciBtZWFuaW5nIGluaGVy ZW50IGluIHRoZSBvcmRlciBvZiBleHRlbnNpb24gc3VidGFncy4gIEV4dGVuc2lvbg0KICAg YXV0aG9ycyBTSE9VTEQgYXZvaWQgc3VidGFnIHJlbGF0aW9uc2hpcHMgb3IgY2Fub25pY2Fs aXphdGlvbg0KICAgbWVjaGFuaXNtcyB0aGF0IGludGVyZmVyZSB3aXRoIG1hdGNoaW5nIG9y IHdpdGggbGVuZ3RoIHJlc3RyaWN0aW9ucw0KICAgdGhhdCBzb21ldGltZXMgZXhpc3QgaW4g Y29tbW9uIHByb3RvY29scyB3aGVyZSB0aGUgZXh0ZW5zaW9uIGlzIHVzZWQuDQogICBJbiBw YXJ0aWN1bGFyLCBhcHBsaWNhdGlvbnMgTUFZIHRydW5jYXRlIHRoZSBzdWJ0YWdzIGluIGRv aW5nDQogICBtYXRjaGluZyBvciBpbiBmaXR0aW5nIGludG8gbGltaXRlZCBsZW5ndGhzLCBz byBpdCBpcyBSRUNPTU1FTkRFRA0KICAgdGhhdCB0aGUgbW9zdCBzaWduaWZpY2FudCBpbmZv cm1hdGlvbiBiZSBpbiB0aGUgbW9zdCBzaWduaWZpY2FudA0KICAgKGxlZnQtbW9zdCkgc3Vi dGFncyBhbmQgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBncmFjZWZ1bGx5IGhhbmRsZQ0KICAg dHJ1bmNhdGVkIHN1YnRhZ3MuDQoNCiAgIFdoZW4gYSBsYW5ndWFnZSB0YWcgaXMgdG8gYmUg dXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJvdG9jb2wsIGl0DQogICBpcyBSRUNPTU1F TkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBub3QgY29udGFpbiBleHRlbnNpb25z IG5vdA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBJbiBhZGRpdGlvbiwgbm90 ZSB0aGF0IHNvbWUgcHJvdG9jb2xzDQogICBNQVkgaW1wb3NlIHVwcGVyIGxpbWl0cyBvbiB0 aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIHVzZWQgdG8gc3RvcmUgb3INCiAgIHRyYW5zcG9y dCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQozLjguICBVcGRhdGUgb2YgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgdGhl IElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IHdpbGwNCiAgIG5lZWQgYW4gdXBkYXRl IHNvIHRoYXQgaXQgY29udGFpbnMgdGhlIGNvbXBsZXRlIHNldCBvZiBzdWJ0YWdzIHZhbGlk DQogICBpbiBhIGxhbmd1YWdlIHRhZy4gIFRoaXMgY29sbGVjdGlvbiBvZiBzdWJ0YWdzLCBh bG9uZyB3aXRoIGENCiAgIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9jZXNzIHVzZWQgdG8gY3Jl YXRlIGl0LCBpcyBkZXNjcmliZWQgYnkNCiAgIFtyZWdpc3RyeS11cGRhdGVdLiAgSUFOQSB3 aWxsIHB1Ymxpc2ggdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUNCiAgIHJlZ2lzdHJ5IGRl c2NyaWJlZCBieSB0aGlzIGRvY3VtZW50IHVzaW5nIHRoZSBpbnN0cnVjdGlvbnMgYW5kDQog ICBjb250ZW50IG9mIFtyZWdpc3RyeS11cGRhdGVdLiAgT25jZSBwdWJsaXNoZWQgYnkgSUFO QSwgdGhlDQogICBtYWludGVuYW5jZSBwcm9jZWR1cmVzLCBydWxlcywgYW5kIHJlZ2lzdHJh dGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkDQogICBpbiB0aGlzIGRvY3VtZW50IHdpbGwgYmUg YXZhaWxhYmxlIGZvciBuZXcgcmVnaXN0cmF0aW9ucyBvciB1cGRhdGVzLg0KDQogICBSZWdp c3RyYXRpb25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQg aW4NCiAgIFtSRkM0NjQ2XSB3aGVuIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBNVVNUIGJl IGNvbXBsZXRlZCB1bmRlciB0aGUNCiAgIHJ1bGVzIGNvbnRhaW5lZCBpbiB0aGlzIGRvY3Vt ZW50Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3 LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcN Cg0KDQo0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MNCg0K ICAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBob3cgdG8gdXNlIHRoZSBpbmZvcm1hdGlvbiBp biB0aGUgcmVnaXN0cnkNCiAgIHdpdGggdGhlIHRhZyBzeW50YXggdG8gY2hvb3NlLCBmb3Jt LCBhbmQgcHJvY2VzcyBsYW5ndWFnZSB0YWdzLg0KDQo0LjEuICBDaG9pY2Ugb2YgTGFuZ3Vh Z2UgVGFnDQoNCiAgIFRoZSBndWlkaW5nIHByaW5jaXBsZSBpbiBmb3JtaW5nIGxhbmd1YWdl IHRhZ3MgaXMgdG8gInRhZyBjb250ZW50DQogICB3aXNlbHkuIiAgVGhpcyBtZWFucyB0aGF0 IHNvbWV0aW1lcyB0aGVyZSBpcyBhIGNob2ljZSBiZXR3ZWVuIHNldmVyYWwNCiAgIHBvc3Np YmxlIHRhZ3MgZm9yIHRoZSBzYW1lIGNvbnRlbnQgYW5kIHRoYXQgdGhlIGNob2ljZSBvZiB3 aGljaCB0YWcNCiAgIHRvIHVzZSBkZXBlbmRzIG9uIHRoZSBjb250ZW50IGFuZCBhcHBsaWNh dGlvbiBpbiBxdWVzdGlvbi4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBpcyBiZXN0IHNlcnZl ZCB3aGVuIGFsbCB1c2VycyB1c2UgdGhlIHNhbWUgbGFuZ3VhZ2UNCiAgIHRhZyBpbiBvcmRl ciB0byByZXByZXNlbnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNhdGlvbiBo YXMNCiAgIHJlcXVpcmVtZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUgaW5hcHBsaWNh YmxlLCB0aGVuIHRoYXQNCiAgIGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5nIGludGVyb3Bl cmFiaWxpdHkuICBJdCBpcyBzdHJvbmdseQ0KICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBu b3QgZGVmaW5lIHRoZWlyIG93biBydWxlcyBmb3IgbGFuZ3VhZ2UgdGFnDQogICBjaG9pY2Uu DQoNCiAgIEEgc3VidGFnIFNIT1VMRCBvbmx5IGJlIHVzZWQgd2hlbiBpdCBhZGRzIHVzZWZ1 bCBkaXN0aW5ndWlzaGluZw0KICAgaW5mb3JtYXRpb24gdG8gdGhlIHRhZy4gIEV4dHJhbmVv dXMgc3VidGFncyBpbnRlcmZlcmUgd2l0aCB0aGUNCiAgIG1lYW5pbmcsIHVuZGVyc3RhbmRp bmcsIGFuZCBwcm9jZXNzaW5nIG9mIGxhbmd1YWdlIHRhZ3MuICBJbg0KICAgcGFydGljdWxh ciwgdXNlcnMgYW5kIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgZm9sbG93IHRoZSAnUHJlZml4 JyBhbmQNCiAgICdTdXBwcmVzcy1TY3JpcHQnIGZpZWxkcyBpbiB0aGUgcmVnaXN0cnkgKGRl ZmluZWQgaW4gU2VjdGlvbiAzLjEpOg0KICAgdGhlc2UgZmllbGRzIHByb3ZpZGUgZ3VpZGFu Y2Ugb24gd2hlbiBzcGVjaWZpYyBhZGRpdGlvbmFsIHN1YnRhZ3MNCiAgIFNIT1VMRCAoYW5k IFNIT1VMRCBOT1QpIGJlIHVzZWQgaW4gYSBsYW5ndWFnZSB0YWcuDQoNCiAgIE9mIHBhcnRp Y3VsYXIgbm90ZSwgbWFueSBhcHBsaWNhdGlvbnMgY2FuIGJlbmVmaXQgZnJvbSB0aGUgdXNl IG9mDQogICBzY3JpcHQgc3VidGFncyBpbiBsYW5ndWFnZSB0YWdzLCBhcyBsb25nIGFzIHRo ZSB1c2UgaXMgY29uc2lzdGVudCBmb3INCiAgIGEgZ2l2ZW4gY29udGV4dC4gIFNjcmlwdCBz dWJ0YWdzIGFyZSBuZXZlciBhcHByb3ByaWF0ZSBmb3IgdW53cml0dGVuDQogICBjb250ZW50 IChzdWNoIGFzIGF1ZGlvIHJlY29yZGluZ3MpLg0KDQogICBTY3JpcHQgc3VidGFncyB3ZXJl IG5vdCBmb3JtYWxseSBkZWZpbmVkIGluIFtSRkMzMDY2XSBhbmQgdGhlaXIgdXNlDQogICBj YW4gYWZmZWN0IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24gZm9yIGltcGxl bWVudGF0aW9ucyBvZg0KICAgUkZDIDMwNjYsIGFzIHRoZXNlIHN1YnRhZ3MgYXBwZWFyIGJl dHdlZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kDQogICByZWdpb24gc3VidGFncy4gIEZv ciBleGFtcGxlLCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBzZWxlY3RzIGNvbnRlbnQNCiAgIHVz aW5nIEJhc2ljIEZpbHRlcmluZyBbUkZDNDY0N10gKG9yaWdpbmFsbHkgZGVzY3JpYmVkIGlu IFNlY3Rpb24gMi41DQogICBvZiBbUkZDMzA2Nl0pIGFuZCB0aGUgdXNlciByZXF1ZXN0ZWQg dGhlIGxhbmd1YWdlIHJhbmdlICJlbi1VUyIsDQogICBjb250ZW50IGxhYmVsZWQgImVuLUxh dG4tVVMiIHdpbGwgbm90IG1hdGNoIHRoZSByZXF1ZXN0IGFuZCB0aHVzIG5vdA0KICAgYmUg c2VsZWN0ZWQuICBUaGVyZWZvcmUsIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdoZW4gc2Ny aXB0IHN1YnRhZ3MNCiAgIHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0aGV5 IG91Z2h0IG5vdCBiZSB1c2VkLiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNz LVNjcmlwdCBmaWVsZCBoZWxwcyBlbnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBi ZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzIGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMgU0hPVUxE DQogICBOT1QgaW5jbHVkZSBhIHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJp bWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0 YWdzICh0eXBlICdleHRsYW5nJyBpbiB0aGUgcmVnaXN0cnk7IHNlZQ0KICAgU2VjdGlvbiAz LjEpIGFsc28gYXBwZWFyIGJldHdlZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHN1YnNl cXVlbnQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg NywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3 DQoNCg0KICAgKHNjcmlwdCwgcmVnaW9uLCBvciB2YXJpYW50KSBzdWJ0YWdzLiAgQXBwbGlj YXRpb25zIHNvbWV0aW1lcyBiZW5lZml0DQogICBmcm9tIHRoZWlyIGp1ZGljaW91cyB1c2Ug aW4gZm9ybWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBTdGFuZGFyZHMsIHByb3RvY29scywg YW5kIGFwcGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50DQogICBub3Jt YXRpdmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBvbmVzIGdpdmVuIGlu IHRoaXMNCiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyB0aGUgcHJvY2VkdXJlIHZhcmll cyBmcm9tIHRoZSBvbmUgZ2l2ZW4NCiAgIGhlcmUuDQoNCiAgIFRoZSBjaG9pY2Ugb2Ygc3Vi dGFncyB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcgU0hPVUxEIGJlIGd1aWRlZCBieQ0K ICAgdGhlIGZvbGxvd2luZyBydWxlczoNCg0KICAgMS4gIFVzZSBhcyBwcmVjaXNlIGEgdGFn IGFzIHBvc3NpYmxlLCBidXQgbm8gbW9yZSBzcGVjaWZpYyB0aGFuIGlzDQogICAgICAganVz dGlmaWVkLiAgQXZvaWQgdXNpbmcgc3VidGFncyB0aGF0IGFyZSBub3QgaW1wb3J0YW50IGZv cg0KICAgICAgIGRpc3Rpbmd1aXNoaW5nIGNvbnRlbnQgaW4gYW4gYXBwbGljYXRpb24uDQoN CiAgICAgICAqICBGb3IgZXhhbXBsZSwgJ2RlJyBtaWdodCBzdWZmaWNlIGZvciB0YWdnaW5n IGFuIGVtYWlsIHdyaXR0ZW4NCiAgICAgICAgICBpbiBHZXJtYW4sIHdoaWxlICJkZS1DSC0x OTk2IiBpcyBwcm9iYWJseSB1bm5lY2Vzc2FyaWx5DQogICAgICAgICAgcHJlY2lzZSBmb3Ig c3VjaCBhIHRhc2suDQoNCiAgIDIuICBUaGUgc2NyaXB0IHN1YnRhZyBTSE9VTEQgTk9UIGJl IHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHVubGVzcw0KICAgICAgIHRoZSBzY3JpcHQg YWRkcyBzb21lIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uIHRvIHRoZSB0YWcuICBUaGUN CiAgICAgICBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBpbiB0aGUgcHJpbWFyeSBsYW5ndWFn ZSByZWNvcmQgaW4gdGhlDQogICAgICAgcmVnaXN0cnkgaW5kaWNhdGVzIHNjcmlwdCBzdWJ0 YWdzIHRoYXQgZG8gbm90IGFkZCBkaXN0aW5ndWlzaGluZw0KICAgICAgIGluZm9ybWF0aW9u IGZvciBtb3N0IGFwcGxpY2F0aW9ucy4gIEZvciBleGFtcGxlOg0KDQogICAgICAgKiAgVGhl IHN1YnRhZyAnTGF0bicgc2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlIHByaW1hcnkgbGFu Z3VhZ2UNCiAgICAgICAgICAnZW4nIGJlY2F1c2UgbmVhcmx5IGFsbCBFbmdsaXNoIGRvY3Vt ZW50cyBhcmUgd3JpdHRlbiBpbiB0aGUNCiAgICAgICAgICBMYXRpbiBzY3JpcHQgYW5kIGl0 IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24uDQogICAgICAgICAgSG93ZXZl ciwgaWYgYSBkb2N1bWVudCB3ZXJlIHdyaXR0ZW4gaW4gRW5nbGlzaCBtaXhpbmcgTGF0aW4N CiAgICAgICAgICBzY3JpcHQgd2l0aCBhbm90aGVyIHNjcmlwdCBzdWNoIGFzIEJyYWlsbGUg KCdCcmFpJyksIHRoZW4gaXQNCiAgICAgICAgICBtaWdodCBiZSBhcHByb3ByaWF0ZSB0byBj aG9vc2UgdG8gaW5kaWNhdGUgYm90aCBzY3JpcHRzIHRvIGFpZA0KICAgICAgICAgIGluIGNv bnRlbnQgc2VsZWN0aW9uLCBzdWNoIGFzIHRoZSBhcHBsaWNhdGlvbiBvZiBhIHN0eWxlDQog ICAgICAgICAgc2hlZXQuDQoNCiAgICAgICAqICBXaGVuIGxhYmVsaW5nIGNvbnRlbnQgdGhh dCBpcyB1bndyaXR0ZW4gKHN1Y2ggYXMgYSByZWNvcmRpbmcNCiAgICAgICAgICBvZiBodW1h biBzcGVlY2gpLCB0aGUgc2NyaXB0IHN1YnRhZyBzaG91bGQgbm90IGJlIHVzZWQsIGV2ZW4N CiAgICAgICAgICBpZiB0aGUgbGFuZ3VhZ2UgaXMgY3VzdG9tYXJpbHkgd3JpdHRlbiBpbiBz ZXZlcmFsIHNjcmlwdHMuDQogICAgICAgICAgVGh1cyB0aGUgc3VidGl0bGVzIHRvIGEgbW92 aWUgbWlnaHQgdXNlIHRoZSB0YWcgInpoLWNtbi1IYW50Ig0KICAgICAgICAgIChDaGluZXNl LCBNYW5kYXJpbiwgVHJhZGl0aW9uYWwgc2NyaXB0KSwgYnV0IHRoZSBhdWRpbyB0cmFjaw0K ICAgICAgICAgIGZvciB0aGUgc2FtZSBsYW5ndWFnZSB3b3VsZCBiZSB0YWdnZWQgInpoLWNt biIuDQoNCiAgIDMuICBVc2Ugc3BlY2lmaWMgbGFuZ3VhZ2Ugc3VidGFncyBvciBzdWJ0YWcg c2VxdWVuY2VzIGluIHByZWZlcmVuY2UNCiAgICAgICB0byBzdWJ0YWdzIGZvciBsYW5ndWFn ZSBjb2xsZWN0aW9ucy4gIEEgImxhbmd1YWdlIGNvbGxlY3Rpb24iIGlzDQogICAgICAgYSBz dWJ0YWcgZGVyaXZlZCBmcm9tIG9uZSBvZiB0aGUgSVNPIDYzOS0yIGNvZGVzIHRoYXQgcmVw cmVzZW50cw0KICAgICAgIG11bHRpcGxlIHJlbGF0ZWQgbGFuZ3VhZ2VzLiAgRm9yIGV4YW1w bGUsIHRoZSBjb2RlICdjbWMnDQogICAgICAgcmVwcmVzZW50cyAiQ2hhbWljIGxhbmd1YWdl cyIuICBUaGUgcmVnaXN0cnkgY29udGFpbnMgdmFsdWVzIGZvcg0KICAgICAgIGVhY2ggb2Yg dGhlIGFwcHJveGltYXRlbHkgdGVuIGluZGl2aWR1YWwgbGFuZ3VhZ2VzIHJlcHJlc2VudGVk IGJ5DQogICAgICAgdGhpcyBjb2xsZWN0aXZlIGNvZGUuICBGb3IgZXhhbXBsZSAnanJhJyAo SmFyYWkpIGFuZCAnY2phJw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNDNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg IEFwcmlsIDIwMDcNCg0KDQogICAgICAgKFdlc3Rlcm4gQ2hhbSkuDQoNCiAgIDQuICBJZiBh IHRhZyBvciBzdWJ0YWcgaGFzIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgaW4gaXRzIHJl Z2lzdHJ5DQogICAgICAgZW50cnksIHRoZW4gdGhlIHZhbHVlIG9mIHRoYXQgZmllbGQgU0hP VUxEIGJlIHVzZWQgdG8gZm9ybSB0aGUNCiAgICAgICBsYW5ndWFnZSB0YWcgaW4gcHJlZmVy ZW5jZSB0byB0aGUgdGFnIG9yIHN1YnRhZyBpbiB3aGljaCB0aGUNCiAgICAgICBwcmVmZXJy ZWQgdmFsdWUgYXBwZWFycy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCB1c2UgJ2hlJyBm b3IgSGVicmV3IGluIHByZWZlcmVuY2UgdG8gJ2l3Jy4NCg0KICAgNS4gIFRoZSAndW5kJyAo VW5kZXRlcm1pbmVkKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlDQog ICAgICAgdXNlZCB0byBsYWJlbCBjb250ZW50LCBldmVuIGlmIHRoZSBsYW5ndWFnZSBpcyB1 bmtub3duLiAgT21pdHRpbmcNCiAgICAgICB0aGUgbGFuZ3VhZ2UgdGFnIGFsdG9nZXRoZXIg aXMgcHJlZmVycmVkIHRvIHVzaW5nIGEgdGFnIHdpdGggYQ0KICAgICAgIHByaW1hcnkgbGFu Z3VhZ2Ugc3VidGFnIG9mICd1bmQnLiAgVGhlICd1bmQnIHN1YnRhZyBNQVkgYmUgdXNlZnVs DQogICAgICAgZm9yIHByb3RvY29scyB0aGF0IHJlcXVpcmUgYSBsYW5ndWFnZSB0YWcgdG8g YmUgcHJvdmlkZWQuICBUaGUNCiAgICAgICAndW5kJyBzdWJ0YWcgTUFZIGFsc28gYmUgdXNl ZnVsIHdoZW4gbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncyBpbg0KICAgICAgIGNlcnRhaW4gc2l0 dWF0aW9ucy4NCg0KICAgNi4gIFRoZSAnbXVsJyAoTXVsdGlwbGUpIHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZA0KICAgICAgIHdoZW5ldmVyIHRoZSBwcm90 b2NvbCBhbGxvd3MgdGhlIHNlcGFyYXRlIHRhZ3MgZm9yIG11bHRpcGxlDQogICAgICAgbGFu Z3VhZ2VzLCBhcyBpcyB0aGUgY2FzZSBmb3IgdGhlIENvbnRlbnQtTGFuZ3VhZ2UgaGVhZGVy IGluDQogICAgICAgSFRUUC4gIFRoZSAnbXVsJyBzdWJ0YWcgY29udmV5cyBsaXR0bGUgdXNl ZnVsIGluZm9ybWF0aW9uOg0KICAgICAgIGNvbnRlbnQgaW4gbXVsdGlwbGUgbGFuZ3VhZ2Vz IFNIT1VMRCBpbmRpdmlkdWFsbHkgdGFnIHRoZQ0KICAgICAgIGxhbmd1YWdlcyB3aGVyZSB0 aGV5IGFwcGVhciBvciBvdGhlcndpc2UgaW5kaWNhdGUgdGhlIGFjdHVhbA0KICAgICAgIGxh bmd1YWdlIGluIHByZWZlcmVuY2UgdG8gdGhlICdtdWwnIHN1YnRhZy4NCg0KICAgNy4gIFRo ZSBzYW1lIHZhcmlhbnQgc3VidGFnIE1VU1QgTk9UIGJlIHVzZWQgbW9yZSB0aGFuIG9uY2Ug d2l0aGluIGENCiAgICAgICBsYW5ndWFnZSB0YWcuDQoNCiAgICAgICAqICBGb3IgZXhhbXBs ZSwgdGhlIHRhZyAiZGUtREUtMTkwMS0xOTAxIiBpcyBub3QgdmFsaWQuDQoNCiAgIFRvIGVu c3VyZSBjb25zaXN0ZW50IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHRoaXMgZG9jdW1lbnQg Y29udGFpbnMNCiAgIHNldmVyYWwgcHJvdmlzaW9ucyB0byBhY2NvdW50IGZvciBwb3RlbnRp YWwgaW5zdGFiaWxpdHkgaW4gdGhlDQogICBzdGFuZGFyZHMgdXNlZCB0byBkZWZpbmUgdGhl IHN1YnRhZ3MgdGhhdCBtYWtlIHVwIGxhbmd1YWdlIHRhZ3MuDQogICBUaGVzZSBwcm92aXNp b25zIG1lYW4gdGhhdCBubyBsYW5ndWFnZSB0YWcgY3JlYXRlZCB1bmRlciB0aGUgcnVsZXMg aW4NCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBiZWNvbWUgb2Jzb2xldGUuDQoNCjQuMi4gIE1l YW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZw0KDQogICBUaGUgcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIHRhZyBhbmQgdGhlIGluZm9ybWF0aW9uIGl0IHJlbGF0ZXMgdG8gaXMNCiAgIGRl ZmluZWQgYnkgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRhZyBhcHBlYXJzLiAgQWNjb3Jk aW5nbHksIHRoaXMNCiAgIHNlY3Rpb24gZ2l2ZXMgb25seSBwb3NzaWJsZSBleGFtcGxlcyBv ZiBpdHMgdXNhZ2UuDQoNCiAgIG8gIEZvciBhIHNpbmdsZSBpbmZvcm1hdGlvbiBvYmplY3Qs IHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MNCiAgICAgIG1pZ2h0IGJlIGludGVycHJl dGVkIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHRoYXQgaXMgbmVjZXNzYXJ5IGZvcg0KICAg ICAgYSBjb21wbGV0ZSBjb21wcmVoZW5zaW9uIG9mIHRoZSBjb21wbGV0ZSBvYmplY3QuICBF eGFtcGxlOiBQbGFpbg0KICAgICAgdGV4dCBkb2N1bWVudHMuDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgNDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBvICBGb3IgYW4g YWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24gb2JqZWN0cywgdGhlIGFzc29jaWF0ZWQgbGFu Z3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFn ZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAgICAgb2YgdGhhdCBhZ2dyZWdhdGlvbi4g IEV4YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxpYnJhcmllcy4NCg0KICAgbyAgRm9y IGluZm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFsdGVy bmF0aXZlcywNCiAgICAgIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MgY291bGQgYmUg cmVnYXJkZWQgYXMgYSBoaW50IHRoYXQgdGhlDQogICAgICBjb250ZW50IGlzIHByb3ZpZGVk IGluIHNldmVyYWwgbGFuZ3VhZ2VzIGFuZCB0aGF0IG9uZSBoYXMgdG8NCiAgICAgIGluc3Bl Y3QgZWFjaCBvZiB0aGUgYWx0ZXJuYXRpdmVzIGluIG9yZGVyIHRvIGZpbmQgaXRzIGxhbmd1 YWdlIG9yDQogICAgICBsYW5ndWFnZXMuICBJbiB0aGlzIGNhc2UsIHRoZSBwcmVzZW5jZSBv ZiBtdWx0aXBsZSB0YWdzIG1pZ2h0IG5vdA0KICAgICAgbWVhbiB0aGF0IG9uZSBuZWVkcyB0 byBiZSBtdWx0aS1saW5ndWFsIHRvIGdldCBjb21wbGV0ZQ0KICAgICAgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgZG9jdW1lbnQuICBFeGFtcGxlOiBNSU1FIG11bHRpcGFydC8NCiAgICAgIGFs dGVybmF0aXZlLg0KDQogICBvICBJbiBtYXJrdXAgbGFuZ3VhZ2VzLCBzdWNoIGFzIEhUTUwg YW5kIFhNTCwgbGFuZ3VhZ2UgaW5mb3JtYXRpb24NCiAgICAgIGNhbiBiZSBhZGRlZCB0byBl YWNoIHBhcnQgb2YgdGhlIGRvY3VtZW50IGlkZW50aWZpZWQgYnkgdGhlIG1hcmt1cA0KICAg ICAgc3RydWN0dXJlIChpbmNsdWRpbmcgdGhlIHdob2xlIGRvY3VtZW50IGl0c2VsZikuICBG b3IgZXhhbXBsZSwgb25lDQogICAgICBjb3VsZCB3cml0ZSA8c3BhbiBsYW5nPSJmciI+Qydl c3QgbGEgdmllLjwvc3Bhbj4gaW5zaWRlIGENCiAgICAgIE5vcndlZ2lhbiBkb2N1bWVudDsg dGhlIE5vcndlZ2lhbi1zcGVha2luZyB1c2VyIGNvdWxkIHRoZW4gYWNjZXNzDQogICAgICBh IEZyZW5jaC1Ob3J3ZWdpYW4gZGljdGlvbmFyeSB0byBmaW5kIG91dCB3aGF0IHRoZSBtYXJr ZWQgc2VjdGlvbg0KICAgICAgbWVhbnQuICBJZiB0aGUgdXNlciB3ZXJlIGxpc3RlbmluZyB0 byB0aGF0IGRvY3VtZW50IHRocm91Z2ggYQ0KICAgICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRl cmZhY2UsIHRoaXMgZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsDQogICAgICB0 aGUgc3ludGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBseSBGcmVuY2ggdGV4dC10by1z cGVlY2gNCiAgICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8gdGhhdCBzcGFuIG9mIHRleHQs IGluc3RlYWQgb2YgYXBwbHlpbmcgdGhlDQogICAgICBpbmFwcHJvcHJpYXRlIE5vcndlZ2lh biBydWxlcy4NCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgcmVsYXRlZCB3aGVuIHRoZXkgY29u dGFpbiBhIHNpbWlsYXIgc2VxdWVuY2Ugb2YNCiAgIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwg aWYgYSBsYW5ndWFnZSB0YWcgQiBjb250YWlucyBsYW5ndWFnZSB0YWcgQSBhcw0KICAgYSBw cmVmaXgsIHRoZW4gQiBpcyB0eXBpY2FsbHkgIm5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZp YyIgdGhhbiBBLg0KICAgVGh1cywgInpoLUhhbnQtVFciIGlzIG1vcmUgc3BlY2lmaWMgdGhh biAiemgtSGFudCIuDQoNCiAgIFRoaXMgcmVsYXRpb25zaGlwIGlzIG5vdCBndWFyYW50ZWVk IGluIGFsbCBjYXNlczogc3BlY2lmaWNhbGx5LA0KICAgbGFuZ3VhZ2VzIHRoYXQgYmVnaW4g d2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QNCiAgIGd1YXJhbnRl ZWQgdG8gYmUgbXV0dWFsbHkgaW50ZWxsaWdpYmxlLCBhbHRob3VnaCB0aGV5IG1pZ2h0IGJl LiAgRm9yDQogICBleGFtcGxlLCB0aGUgdGFnICJheiIgc2hhcmVzIGEgcHJlZml4IHdpdGgg Ym90aCAiYXotTGF0biINCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBMYXRp biBzY3JpcHQpIGFuZCAiYXotQ3lybCINCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5n IHRoZSBDeXJpbGxpYyBzY3JpcHQpLiAgQSBwZXJzb24gZmx1ZW50IGluDQogICBvbmUgc2Ny aXB0IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHJlYWQgdGhlIG90aGVyLCBldmVuIHRob3VnaCB0 aGUgdGV4dA0KICAgbWlnaHQgYmUgaWRlbnRpY2FsLiAgQ29udGVudCB0YWdnZWQgYXMgImF6 IiBtb3N0IHByb2JhYmx5IGlzIHdyaXR0ZW4NCiAgIGluIGp1c3Qgb25lIHNjcmlwdCBhbmQg dGh1cyBtaWdodCBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIGEgcmVhZGVyDQogICBmYW1pbGlh ciB3aXRoIHRoZSBvdGhlciBzY3JpcHQuDQoNCjQuMy4gIExlbmd0aCBDb25zaWRlcmF0aW9u cw0KDQogICBUaGVyZSBpcyBubyBkZWZpbmVkIHVwcGVyIGxpbWl0IG9uIHRoZSBzaXplIG9m IGxhbmd1YWdlIHRhZ3MuICBXaGlsZQ0KICAgaGlzdG9yaWNhbGx5IG1vc3QgbGFuZ3VhZ2Ug dGFncyBoYXZlIGNvbnNpc3RlZCBvZiBsYW5ndWFnZSBhbmQgcmVnaW9uDQogICBzdWJ0YWdz IHdpdGggYSBjb21iaW5lZCB0b3RhbCBsZW5ndGggb2YgdXAgdG8gc2l4IGNoYXJhY3RlcnMs IGxhcmdlcg0KICAgdGFncyBoYXZlIGFsd2F5cyBiZWVuIGJvdGggcG9zc2libGUgYW5kIGFj dHVhbGx5IGFwcGVhcmVkIGluIHVzZS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNDVdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICBOZWl0aGVyIHRoZSBsYW5ndWFnZSB0YWcg c3ludGF4IG5vciBvdGhlciByZXF1aXJlbWVudHMgaW4gdGhpcw0KICAgZG9jdW1lbnQgaW1w b3NlIGEgZml4ZWQgdXBwZXIgbGltaXQgb24gdGhlIG51bWJlciBvZiBzdWJ0YWdzIGluIGEN CiAgIGxhbmd1YWdlIHRhZyAoYW5kIHRodXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHNpemUg b2YgYSB0YWcpLiAgVGhlDQogICBsYW5ndWFnZSB0YWcgc3ludGF4IHN1Z2dlc3RzIHRoYXQs IGRlcGVuZGluZyBvbiB0aGUgc3BlY2lmaWMNCiAgIGxhbmd1YWdlLCBtb3JlIHN1YnRhZ3Mg KGFuZCB0aHVzIGEgbG9uZ2VyIHRhZykgYXJlIHNvbWV0aW1lcw0KICAgbmVjZXNzYXJ5IHRv IGNvbXBsZXRlbHkgaWRlbnRpZnkgdGhlIGxhbmd1YWdlIGZvciBjZXJ0YWluDQogICBhcHBs aWNhdGlvbnM7IHRodXMsIGl0IGlzIHBvc3NpYmxlIHRvIGVudmlzaW9uIGxvbmcgb3IgY29t cGxleCBzdWJ0YWcNCiAgIHNlcXVlbmNlcy4NCg0KNC4zLjEuICBXb3JraW5nIHdpdGggTGlt aXRlZCBCdWZmZXIgU2l6ZXMNCg0KICAgU29tZSBhcHBsaWNhdGlvbnMgYW5kIHByb3RvY29s cyBhcmUgZm9yY2VkIHRvIGFsbG9jYXRlIGZpeGVkIGJ1ZmZlcg0KICAgc2l6ZXMgb3Igb3Ro ZXJ3aXNlIGxpbWl0IHRoZSBsZW5ndGggb2YgYSBsYW5ndWFnZSB0YWcuICBBIGNvbmZvcm1h bnQNCiAgIGltcGxlbWVudGF0aW9uIG9yIHNwZWNpZmljYXRpb24gTUFZIHJlZnVzZSB0byBz dXBwb3J0IHRoZSBzdG9yYWdlIG9mDQogICBsYW5ndWFnZSB0YWdzIHRoYXQgZXhjZWVkIGEg c3BlY2lmaWVkIGxlbmd0aC4gIEFueSBzdWNoIGxpbWl0YXRpb24NCiAgIFNIT1VMRCBiZSBj bGVhcmx5IGRvY3VtZW50ZWQsIGFuZCBzdWNoIGRvY3VtZW50YXRpb24gU0hPVUxEIGluY2x1 ZGUNCiAgIHdoYXQgaGFwcGVucyB0byBsb25nZXIgdGFncyAoZm9yIGV4YW1wbGUsIHdoZXRo ZXIgYW4gZXJyb3IgdmFsdWUgaXMNCiAgIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3VhZ2UgdGFn IGlzIHRydW5jYXRlZCkuICBBIHByb3RvY29sIHRoYXQgYWxsb3dzDQogICB0YWdzIHRvIGJl IHRydW5jYXRlZCBhdCBhbiBhcmJpdHJhcnkgbGltaXQsIHdpdGhvdXQgZ2l2aW5nIGFueQ0K ICAgaW5kaWNhdGlvbiBvZiB3aGF0IHRoYXQgbGltaXQgaXMsIGhhcyB0aGUgcG90ZW50aWFs IGZvciBjYXVzaW5nIGhhcm0NCiAgIGJ5IGNoYW5naW5nIHRoZSBtZWFuaW5nIG9mIHRhZ3Mg aW4gc3Vic3RhbnRpYWwgd2F5cy4NCg0KICAgSW4gcHJhY3RpY2UsIG1vc3QgbGFuZ3VhZ2Ug dGFncyBkbyBub3QgcmVxdWlyZSBtb3JlIHRoYW4gYSBmZXcNCiAgIHN1YnRhZ3MgYW5kIHdp bGwgbm90IGFwcHJvYWNoIHJlYXNvbmFibHkgc2l6ZWQgYnVmZmVyIGxpbWl0YXRpb25zOw0K ICAgc2VlIFNlY3Rpb24gNC4xLg0KDQogICBTb21lIHNwZWNpZmljYXRpb25zIG9yIHByb3Rv Y29scyBoYXZlIGxpbWl0cyBvbiB0YWcgbGVuZ3RoIGJ1dCBkbyBub3QNCiAgIGhhdmUgYSBm aXhlZCBsZW5ndGggbGltaXRhdGlvbi4gIEZvciBleGFtcGxlLCBbUkZDMjIzMV0gaGFzIG5v DQogICBleHBsaWNpdCBsZW5ndGggbGltaXRhdGlvbjogdGhlIGxlbmd0aCBhdmFpbGFibGUg Zm9yIHRoZSBsYW5ndWFnZSB0YWcNCiAgIGlzIGNvbnN0cmFpbmVkIGJ5IHRoZSBsZW5ndGgg b2Ygb3RoZXIgaGVhZGVyIGNvbXBvbmVudHMgKHN1Y2ggYXMgdGhlDQogICBjaGFyc2V0J3Mg bmFtZSkgY291cGxlZCB3aXRoIHRoZSA3Ni1jaGFyYWN0ZXIgbGltaXQgaW4gW1JGQzIwNDdd Lg0KICAgVGh1cywgdGhlICJsaW1pdCIgbWlnaHQgYmUgNTAgb3IgbW9yZSBjaGFyYWN0ZXJz LCBidXQgaXQgY291bGQNCiAgIHBvdGVudGlhbGx5IGJlIHF1aXRlIHNtYWxsLg0KDQogICBU aGUgY29uc2lkZXJhdGlvbnMgZm9yIGFzc2lnbmluZyBhIGJ1ZmZlciBsaW1pdCBhcmU6DQoN CiAgICAgIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgTk9UIHRydW5jYXRlIGxhbmd1YWdlIHRh Z3MgdW5sZXNzIHRoZQ0KICAgICAgbWVhbmluZyBvZiB0aGUgdGFnIGlzIHB1cnBvc2VmdWxs eSBiZWluZyBjaGFuZ2VkLCBvciB1bmxlc3MgdGhlDQogICAgICB0YWcgZG9lcyBub3QgZml0 IGludG8gYSBsaW1pdGVkIGJ1ZmZlciBzaXplIHNwZWNpZmllZCBieSBhDQogICAgICBwcm90 b2NvbCBmb3Igc3RvcmFnZSBvciB0cmFuc21pc3Npb24uDQoNCiAgICAgIEltcGxlbWVudGF0 aW9ucyBTSE9VTEQgd2FybiB0aGUgdXNlciB3aGVuIGEgdGFnIGlzIHRydW5jYXRlZCBzaW5j ZQ0KICAgICAgdHJ1bmNhdGlvbiBjaGFuZ2VzIHRoZSBzZW1hbnRpYyBtZWFuaW5nIG9mIHRo ZSB0YWcuDQoNCiAgICAgIEltcGxlbWVudGF0aW9ucyBvZiBwcm90b2NvbHMgb3Igc3BlY2lm aWNhdGlvbnMgdGhhdCBhcmUgc3BhY2UNCiAgICAgIGNvbnN0cmFpbmVkIGJ1dCBkbyBub3Qg aGF2ZSBhIGZpeGVkIGxpbWl0IFNIT1VMRCB1c2UgdGhlIGxvbmdlc3QNCiAgICAgIHBvc3Np YmxlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIHRydW5jYXRpb24uDQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAg IFtQYWdlIDQ2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgICAgUHJvdG9jb2xz IG9yIHNwZWNpZmljYXRpb25zIHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBm b3INCiAgICAgIGxhbmd1YWdlIHRhZ3MgTVVTVCBhbGxvdyBmb3IgbGFuZ3VhZ2UgdGFncyBv ZiB1cCB0byAzMyBjaGFyYWN0ZXJzLg0KDQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNh dGlvbnMgdGhhdCBzcGVjaWZ5IGxpbWl0ZWQgYnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFu Z3VhZ2UgdGFncyBTSE9VTEQgYWxsb3cgZm9yIGxhbmd1YWdlIHRhZ3Mgb2YgYXQgbGVhc3Qg NDINCiAgICAgIGNoYXJhY3RlcnMuDQoNCiAgIFRoZSBmb2xsb3dpbmcgaWxsdXN0cmF0aW9u IHNob3dzIGhvdyB0aGUgNDItY2hhcmFjdGVyIHJlY29tbWVuZGF0aW9uDQogICB3YXMgZGVy aXZlZC4gIFRoZSBjb21iaW5hdGlvbiBvZiBsYW5ndWFnZSBhbmQgZXh0ZW5kZWQgbGFuZ3Vh Z2UNCiAgIHN1YnRhZ3Mgd2FzIGNob3NlbiBmb3IgZnV0dXJlIGNvbXBhdGliaWxpdHkuICBB dCB1cCB0byAxNSBjaGFyYWN0ZXJzLA0KICAgdGhpcyBjb21iaW5hdGlvbiBpcyBsb25nZXIg dGhhbiB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBwcmltYXJ5IGxhbmd1YWdlDQogICBzdWJ0YWcg KDggY2hhcmFjdGVycyk6DQoNCiAgIGxhbmd1YWdlICAgICAgPSAgMyAoSVNPIDYzOS0yOyBJ U08gNjM5LTEgcmVxdWlyZXMgMikNCiAgIGV4dGxhbmcxICAgICAgPSAgNCAoZWFjaCBzdWJz ZXF1ZW50IHN1YnRhZyBpbmNsdWRlcyAnLScpDQogICBleHRsYW5nMiAgICAgID0gIDQgKHVu bGlrZWx5OiBuZWVkcyBwcmVmaXg9Imxhbmd1YWdlLWV4dGxhbmcxIikNCiAgIGV4dGxhbmcz ICAgICAgPSAgNCAoZXh0cmVtZWx5IHVubGlrZWx5KQ0KICAgc2NyaXB0ICAgICAgICA9ICA1 IChpZiBub3Qgc3VwcHJlc3NlZDogc2VlIFNlY3Rpb24gNC4xKQ0KICAgcmVnaW9uICAgICAg ICA9ICA0IChVTiBNLjQ5OyBJU08gMzE2NiByZXF1aXJlcyAzKQ0KICAgdmFyaWFudDEgICAg ICA9ICA5IChuZWVkcyAnbGFuZ3VhZ2UnIGFzIGEgcHJlZml4KQ0KICAgdmFyaWFudDIgICAg ICA9ICA5IChuZWVkcyAnbGFuZ3VhZ2UtdmFyaWFudDEnIGFzIGEgcHJlZml4KQ0KDQogICB0 b3RhbCAgICAgICAgID0gNDIgY2hhcmFjdGVycw0KDQogICAgICAgICAgICAgIEZpZ3VyZSA3 OiBEZXJpdmF0aW9uIG9mIHRoZSBMaW1pdCBvbiBUYWcgTGVuZ3RoDQoNCjQuMy4yLiAgVHJ1 bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFRydW5jYXRpb24gb2YgYSBsYW5ndWFn ZSB0YWcgYWx0ZXJzIHRoZSBtZWFuaW5nIG9mIHRoZSB0YWcsIGFuZCB0aHVzDQogICBTSE9V TEQgYmUgYXZvaWRlZC4gIEhvd2V2ZXIsIHRydW5jYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBp cyBzb21ldGltZXMNCiAgIG5lY2Vzc2FyeSBkdWUgdG8gbGltaXRlZCBidWZmZXIgc2l6ZXMu ICBTdWNoIHRydW5jYXRpb24gTVVTVCBOT1QNCiAgIHBlcm1pdCBhIHN1YnRhZyB0byBiZSBj aG9wcGVkIG9mZiBpbiB0aGUgbWlkZGxlIG9yIHRoZSBmb3JtYXRpb24gb2YNCiAgIGludmFs aWQgdGFncyAoZm9yIGV4YW1wbGUsIG9uZSBlbmRpbmcgd2l0aCB0aGUgIi0iIGNoYXJhY3Rl cikuDQoNCiAgIFRoaXMgbWVhbnMgdGhhdCBhcHBsaWNhdGlvbnMgb3IgcHJvdG9jb2xzIHRo YXQgdHJ1bmNhdGUgdGFncyBNVVNUIGRvDQogICBzbyBieSBwcm9ncmVzc2l2ZWx5IHJlbW92 aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBwcmVjZWRpbmcgIi0iDQogICBmcm9tIHRo ZSByaWdodCBzaWRlIG9mIHRoZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBpcyBzaG9y dCBlbm91Z2gNCiAgIGZvciB0aGUgZ2l2ZW4gYnVmZmVyLiAgSWYgdGhlIHJlc3VsdGluZyB0 YWcgZW5kcyB3aXRoIGEgc2luZ2xlLQ0KICAgY2hhcmFjdGVyIHN1YnRhZywgdGhhdCBzdWJ0 YWcgYW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZQ0KICAgcmVtb3ZlZC4gIEZv ciBleGFtcGxlOg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgVGFnIHRvIHRydW5jYXRlOiB6aC1MYXRu LUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlLXByaXZhdGUxDQogICAxLiB6aC1M YXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlDQogICAyLiB6aC1MYXRuLUNO LXZhcmlhbnQxLWEtZXh0ZW5kMQ0KICAgMy4gemgtTGF0bi1DTi12YXJpYW50MQ0KICAgNC4g emgtTGF0bi1DTg0KICAgNS4gemgtTGF0bg0KICAgNi4gemgNCg0KICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgODogRXhhbXBsZSBvZiBUYWcgVHJ1bmNhdGlvbg0KDQo0LjQuICBDYW5v bmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgU2luY2UgYSBwYXJ0aWN1bGFy IGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBtYW55IHByb2Nlc3NlcywNCiAg IGxhbmd1YWdlIHRhZ3MgU0hPVUxEIGFsd2F5cyBiZSBjcmVhdGVkIG9yIGdlbmVyYXRlZCBp biBhIGNhbm9uaWNhbA0KICAgZm9ybS4NCg0KICAgQSBsYW5ndWFnZSB0YWcgaXMgaW4gY2Fu b25pY2FsIGZvcm0gd2hlbjoNCg0KICAgMS4gIFRoZSB0YWcgaXMgd2VsbC1mb3JtZWQgYWNj b3JkaW5nIHRoZSBydWxlcyBpbiBTZWN0aW9uIDIuMSBhbmQNCiAgICAgICBTZWN0aW9uIDIu Mi4NCg0KICAgMi4gIFN1YnRhZ3Mgb2YgdHlwZSAnUmVnaW9uJyB0aGF0IGhhdmUgYSBQcmVm ZXJyZWQtVmFsdWUgbWFwcGluZyBpbg0KICAgICAgIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUg U2VjdGlvbiAzLjEpIFNIT1VMRCBiZSByZXBsYWNlZCB3aXRoIHRoZWlyDQogICAgICAgbWFw cGVkIHZhbHVlLiAgTm90ZTogSW4gcmFyZSBjYXNlcywgdGhlIG1hcHBlZCB2YWx1ZSB3aWxs IGFsc28NCiAgICAgICBoYXZlIGEgUHJlZmVycmVkLVZhbHVlLg0KDQogICAzLiAgUmVkdW5k YW50IG9yIGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUN CiAgICAgICBtYXBwaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEp IE1VU1QgYmUgcmVwbGFjZWQNCiAgICAgICB3aXRoIHRoZWlyIG1hcHBlZCB2YWx1ZS4gIFRo ZXNlIGl0ZW1zIGVpdGhlciBhcmUgZGVwcmVjYXRlZA0KICAgICAgIG1hcHBpbmdzIGNyZWF0 ZWQgYmVmb3JlIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IChzdWNoIGFzDQogICAg ICAgdGhlIG1hcHBpbmcgb2YgIm5vLW55biIgdG8gIm5uIiBvciAiaS1rbGluZ29uIiB0byAi dGxoIikgb3IgYXJlDQogICAgICAgdGhlIHJlc3VsdCBvZiBsYXRlciByZWdpc3RyYXRpb25z IG9yIGFkZGl0aW9ucyB0byB0aGlzIGRvY3VtZW50DQogICAgICAgKGZvciBleGFtcGxlLCAi emgtaGFra2EiIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBsYW5ndWFnZS0NCiAg ICAgICBleHRsYW5nIGNvbWJpbmF0aW9uICJ6aC1oYWsiIHdoZW4gdGhpcyBkb2N1bWVudCB3 YXMgYWRvcHRlZCkuDQoNCiAgIDQuICBPdGhlciBzdWJ0YWdzIHRoYXQgaGF2ZSBhIFByZWZl cnJlZC1WYWx1ZSBtYXBwaW5nIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgKHNlZSBT ZWN0aW9uIDMuMSkgTVVTVCBiZSByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBlZA0KICAgICAg IHZhbHVlLiAgVGhlc2UgaXRlbXMgY29uc2lzdCBlbnRpcmVseSBvZiBjbGVyaWNhbCBjb3Jy ZWN0aW9ucyB0bw0KICAgICAgIElTTyA2MzktMSBpbiB3aGljaCB0aGUgZGVwcmVjYXRlZCBz dWJ0YWdzIGhhdmUgYmVlbiBtYWludGFpbmVkDQogICAgICAgZm9yIGNvbXBhdGliaWxpdHkg cHVycG9zZXMuDQoNCiAgIDUuICBJZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcg c2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0ZW5zaW9uDQogICAgICAgc2VxdWVuY2VzIGFyZSBv cmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2ZSBBU0NJSSBvcmRlciBieQ0KICAgICAgIHNp bmdsZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcgImVuLUEt YWFhLUItY2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25pY2FsDQogICBmb3JtLCB3aGlsZSAi ZW4tQi1jY2MtYmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZvcm1lZCBidXQgbm90IGluDQog ICBjYW5vbmljYWwgZm9ybS4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBp cmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ4XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA3DQoNCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tQlUi IChFbmdsaXNoIGFzIHVzZWQgaW4gQnVybWEpIGlzIG5vdA0KICAgY2Fub25pY2FsIGJlY2F1 c2UgdGhlICdCVScgc3VidGFnIGhhcyBhIGNhbm9uaWNhbCBtYXBwaW5nIHRvICdNTScNCiAg IChNeWFubWFyKSwgYWx0aG91Z2ggdGhlIHRhZyAiZW4tQlUiIG1haW50YWlucyBpdHMgdmFs aWRpdHkuDQoNCiAgIENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5v dCBpbXBseSBhbnl0aGluZyBhYm91dCB0aGUNCiAgIHVzZSBvZiB1cHBlciBvciBsb3dlcmNh c2UgbGV0dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQogICBzdWJ0YWdzIChh bmQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gIEFsbCBjb21wYXJpc29ucyBNVVNU IGJlDQogICBwZXJmb3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlIG1hbm5lci4NCg0KICAg V2hlbiBwZXJmb3JtaW5nIGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncywgcHJv Y2Vzc29ycyBNQVkNCiAgIHJlZ3VsYXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1YnRhZ3MgKHRo YXQgaXMsIHRoaXMgcHJvY2VzcyBpcw0KICAgT1BUSU9OQUwpLCBmb2xsb3dpbmcgdGhlIGNh c2UgdXNlZCBpbiB0aGUgcmVnaXN0cnkuICBOb3RlIHRoYXQgdGhpcw0KICAgY29ycmVzcG9u ZHMgdG8gdGhlIGZvbGxvd2luZyBjYXNpbmcgcnVsZXM6IHVwcGVyY2FzZSBhbGwgbm9uLWlu aXRpYWwNCiAgIHR3by1sZXR0ZXIgc3VidGFnczsgdGl0bGVjYXNlIGFsbCBub24taW5pdGlh bCBmb3VyLWxldHRlciBzdWJ0YWdzOw0KICAgbG93ZXJjYXNlIGV2ZXJ5dGhpbmcgZWxzZS4N Cg0KICAgTm90ZTogQ2FzZSBmb2xkaW5nIG9mIEFTQ0lJIGxldHRlcnMgaW4gY2VydGFpbiBs b2NhbGVzLCB1bmxlc3MNCiAgIGNhcmVmdWxseSBoYW5kbGVkLCBzb21ldGltZXMgcHJvZHVj ZXMgbm9uLUFTQ0lJIGNoYXJhY3RlciB2YWx1ZXMuDQogICBUaGUgVW5pY29kZSBDaGFyYWN0 ZXIgRGF0YWJhc2UgZmlsZSAiU3BlY2lhbENhc2luZy50eHQiIGRlZmluZXMgdGhlDQogICBz cGVjaWZpYyBjYXNlcyB0aGF0IGFyZSBrbm93biB0byBjYXVzZSBwcm9ibGVtcyB3aXRoIHRo aXMuICBJbg0KICAgcGFydGljdWxhciwgdGhlIGxldHRlciAnaScgKFUrMDA2OSkgaW4gVHVy a2lzaCBhbmQgQXplcmJhaWphbmkgaXMNCiAgIHVwcGVyY2FzZWQgdG8gVSswMTMwIChMQVRJ TiBDQVBJVEFMIExFVFRFUiBJIFdJVEggRE9UIEFCT1ZFKS4NCiAgIEltcGxlbWVudGVycyBT SE9VTEQgc3BlY2lmeSBhIGxvY2FsZS1uZXV0cmFsIGNhc2luZyBvcGVyYXRpb24gdG8NCiAg IGVuc3VyZSB0aGF0IGNhc2UgZm9sZGluZyBvZiBzdWJ0YWdzIGRvZXMgbm90IHByb2R1Y2Ug dGhpcyB2YWx1ZSwNCiAgIHdoaWNoIGlzIGlsbGVnYWwgaW4gbGFuZ3VhZ2UgdGFncy4gIEZv ciBleGFtcGxlLCBpZiBvbmUgd2VyZSB0bw0KICAgdXBwZXJjYXNlIHRoZSByZWdpb24gc3Vi dGFnICdpbicgdXNpbmcgVHVya2lzaCBsb2NhbGUgcnVsZXMsIHRoZQ0KICAgc2VxdWVuY2Ug VSswMTMwIFUrMDA0RSB3b3VsZCByZXN1bHQgaW5zdGVhZCBvZiB0aGUgZXhwZWN0ZWQgJ0lO Jy4NCg0KICAgTm90ZTogaWYgdGhlIGZpZWxkICdEZXByZWNhdGVkJyBhcHBlYXJzIGluIGEg cmVnaXN0cnkgcmVjb3JkIHdpdGhvdXQNCiAgIGFuIGFjY29tcGFueWluZyAnUHJlZmVycmVk LVZhbHVlJyBmaWVsZCwgdGhlbiB0aGF0IHRhZyBvciBzdWJ0YWcgaXMNCiAgIGRlcHJlY2F0 ZWQgd2l0aG91dCBhIHJlcGxhY2VtZW50LiAgVmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VM RCBOT1QNCiAgIGdlbmVyYXRlIHRhZ3MgdGhhdCBpbmNsdWRlIHRoZXNlIHZhbHVlcywgYWx0 aG91Z2ggdGhlIHZhbHVlcyBhcmUNCiAgIGNhbm9uaWNhbCB3aGVuIHRoZXkgYXBwZWFyIGlu IGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBBbiBleHRlbnNpb24gTVVTVCBkZWZpbmUgYW55IHJl bGF0aW9uc2hpcHMgdGhhdCBleGlzdCBiZXR3ZWVuIHRoZQ0KICAgdmFyaW91cyBzdWJ0YWdz IGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMgTUFZIGRlZmluZSBhbiBhbHRlcm5hdGUNCiAg IGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncy4g IEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5z aW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQuICBGb3INCiAgIGV4YW1wbGUsIGFuIGV4 dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMgc3VidGFncyBhcmUgaW4gY2Fub25pY2Fs DQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFyZSBwbGFjZWQgaW50byBBU0NJSSBvcmRl cjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBvZiAiZW4tYS1j Y2MtYmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lvbiBtaWdodA0KICAgZGVmaW5lIHRoYXQg dGhlIG9yZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1ZW5jZXMgdGhlaXIgc2VtYW50aWMNCiAg IG1lYW5pbmcgKHNvIHRoYXQgImVuLWItY2NjLWJiYi1hYWEiIGhhcyBhIGRpZmZlcmVudCB2 YWx1ZSBmcm9tICJlbi1iLQ0KICAgYWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lv biBzcGVjaWZpY2F0aW9ucyBTSE9VTEQgYmUgZGVzaWduZWQNCiAgIHNvIHRoYXQgdGhleSBh cmUgdG9sZXJhbnQgb2YgdGhlIHR5cGljYWwgcHJvY2Vzc2VzIGRlc2NyaWJlZCBpbg0KICAg U2VjdGlvbiAzLjcuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNDldDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg IEFwcmlsIDIwMDcNCg0KDQo0LjUuICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2Ug U3VidGFncw0KDQogICBQcml2YXRlIHVzZSBzdWJ0YWdzLCBsaWtlIGFsbCBvdGhlciBzdWJ0 YWdzLCBNVVNUIGNvbmZvcm0gdG8gdGhlDQogICBmb3JtYXQgYW5kIGNvbnRlbnQgY29uc3Ry YWludHMgaW4gdGhlIEFCTkYuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGhhdmUNCiAgIG5vIG1l YW5pbmcgb3V0c2lkZSB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgcGFydGll cyB0aGF0DQogICBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdlIGxhbmd1YWdlIHRhZ3MgdGhh dCBlbXBsb3kgdGhlbS4gIFRoZSBzYW1lDQogICBzdWJ0YWdzIE1BWSBiZSB1c2VkIHdpdGgg YSBkaWZmZXJlbnQgbWVhbmluZyB1bmRlciBhIHNlcGFyYXRlIHByaXZhdGUNCiAgIGFncmVl bWVudC4gIFRoZXkgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZXJlIGFsdGVybmF0aXZlcyBleGlz dCBhbmQNCiAgIFNIT1VMRCBOT1QgYmUgdXNlZCBpbiBjb250ZW50IG9yIHByb3RvY29scyBp bnRlbmRlZCBmb3IgZ2VuZXJhbCB1c2UuDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJl IHNpbXBseSB1c2VsZXNzIGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZQ0KICAgd2l0aG91dCBw cmlvciBhcnJhbmdlbWVudC4gIFRoZSB2YWx1ZSBhbmQgc2VtYW50aWMgbWVhbmluZyBvZiBw cml2YXRlDQogICB1c2UgdGFncyBhbmQgb2YgdGhlIHN1YnRhZ3MgdXNlZCB3aXRoaW4gc3Vj aCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90DQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQu DQoNCiAgIFN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBoYXZpbmcg YSBzcGVjaWZpYyBwcml2YXRlIHVzZQ0KICAgbWVhbmluZyBjb252ZXkgbW9yZSBpbmZvcm1h dGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNlIHRhZw0KICAgcHJlZml4ZWQgYnkgdGhl IHNpbmdsZXRvbiBzdWJ0YWcgJ3gnLiAgRm9yIGFwcGxpY2F0aW9ucywgdGhpcw0KICAgYWRk aXRpb25hbCBpbmZvcm1hdGlvbiBNQVkgYmUgdXNlZnVsLg0KDQogICBGb3IgZXhhbXBsZSwg dGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdaWicsIGFuZCBpbiB0aGUgcmFuZ2VzDQogICAn UU0nLSdRWicgYW5kICdYQSctJ1haJyAoZGVyaXZlZCBmcm9tIElTTyAzMTY2IHByaXZhdGUg dXNlIGNvZGVzKSBNQVkNCiAgIGJlIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZy4gIEEg dGFnIHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMgYQ0KICAgZ3JlYXQgZGVhbCBvZiBw dWJsaWMsIGludGVyY2hhbmdlYWJsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2UN CiAgIG1hdGVyaWFsICh0aGF0IGl0IGlzIENoaW5lc2UgaW4gdGhlIHNpbXBsaWZpZWQgQ2hp bmVzZSBzY3JpcHQgYW5kIGlzDQogICBzdWl0YWJsZSBmb3Igc29tZSBnZW9ncmFwaGljIHJl Z2lvbiAnWFEnKS4gIFdoaWxlIHRoZSBwcmVjaXNlDQogICBnZW9ncmFwaGljIHJlZ2lvbiBp cyBub3Qga25vd24gb3V0c2lkZSBvZiBwcml2YXRlIGFncmVlbWVudCwgdGhlIHRhZw0KICAg Y29udmV5cyBmYXIgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIGFuIG9wYXF1ZSB0YWcgc3VjaCBh cyAieC1zb21lTGFuZyIsDQogICB3aGljaCBjb250YWlucyBubyBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIG9yIHNjcmlwdA0KICAgc3VidGFnIG91dHNpZGUgb2Yg dGhlIHByaXZhdGUgYWdyZWVtZW50Lg0KDQogICBIb3dldmVyLCBpbiBzb21lIGNhc2VzIGNv bnRlbnQgdGFnZ2VkIHdpdGggcHJpdmF0ZSB1c2Ugc3VidGFncyBNQVkNCiAgIGludGVyYWN0 IHdpdGggb3RoZXIgc3lzdGVtcyBpbiBhIGRpZmZlcmVudCBhbmQgcG9zc2libHkgdW5zdWl0 YWJsZQ0KICAgbWFubmVyIGNvbXBhcmVkIHRvIHRhZ3MgdGhhdCB1c2Ugb3BhcXVlLCBwcml2 YXRlbHkgZGVmaW5lZCBzdWJ0YWdzLA0KICAgc28gdGhlIGNob2ljZSBvZiB0aGUgYmVzdCBh cHByb2FjaCBzb21ldGltZXMgZGVwZW5kcyBvbiB0aGUNCiAgIHBhcnRpY3VsYXIgZG9tYWlu IGluIHF1ZXN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAg W1BhZ2UgNTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQo1LiAgSUFOQSBDb25zaWRl cmF0aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0aGUgcHJvY2Vzc2VzIGFu ZCByZXF1aXJlbWVudHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1bmRlcnRha2UgdG8g bWFpbnRhaW4gdGhlIHN1YnRhZyBhbmQgZXh0ZW5zaW9uIHJlZ2lzdHJpZXMgYXMNCiAgIGRl ZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSByZXF1 aXJlbWVudHMgb2YNCiAgIFtSRkMyNDM0XS4NCg0KICAgVGhlIGltcGFjdCBvbiB0aGUgSUFO QSBtYWludGFpbmVycyBvZiB0aGUgdHdvIHJlZ2lzdHJpZXMgZGVmaW5lZCBieQ0KICAgdGhp cyBkb2N1bWVudCB3aWxsIGJlIGEgc21hbGwgaW5jcmVhc2UgaW4gdGhlIGZyZXF1ZW5jeSBv ZiBuZXcNCiAgIGVudHJpZXMgb3IgdXBkYXRlcy4NCg0KNS4xLiAgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5DQoNCiAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCwgSUFOQSB3 aWxsIHVwZGF0ZSB0aGUgcmVnaXN0cnkgdXNpbmcNCiAgIGluc3RydWN0aW9ucyBhbmQgY29u dGVudCBwcm92aWRlZCBpbiBhIGNvbXBhbmlvbiBkb2N1bWVudDoNCiAgIFtyZWdpc3RyeS11 cGRhdGVdLiAgVGhlIGNyaXRlcmlhIGFuZCBwcm9jZXNzIGZvciBzZWxlY3RpbmcgdGhlDQog ICB1cGRhdGVkIHNldCBvZiByZWNvcmRzIGFyZSBkZXNjcmliZWQgaW4gdGhhdCBkb2N1bWVu dC4gIFRoZSB1cGRhdGVkDQogICBzZXQgb2YgcmVjb3JkcyByZXByZXNlbnRzIG5vIGltcGFj dCBvbiBJQU5BLCBzaW5jZSB0aGUgd29yayB0byBjcmVhdGUNCiAgIGl0IHdpbGwgYmUgcGVy Zm9ybWVkIGV4dGVybmFsbHkuDQoNCiAgIEZ1dHVyZSB3b3JrIG9uIHRoZSBMYW5ndWFnZSBT dWJ0YWcgUmVnaXN0cnkgaGFzIGJlZW4gbGltaXRlZCB0bw0KICAgaW5zZXJ0aW5nIG9yIHJl cGxhY2luZyB3aG9sZSByZWNvcmRzIHByZWZvcm1hdHRlZCBmb3IgSUFOQSBieSB0aGUNCiAg IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMg b2YgdGhpcyBkb2N1bWVudA0KICAgYW5kIGFyY2hpdmluZyB0aGUgZm9yd2FyZGVkIHJlZ2lz dHJhdGlvbiBmb3JtLg0KDQogICBFYWNoIHJlY29yZCBNVVNUIGJlIHNlbnQgdG8gaWFuYUBp YW5hLm9yZyB3aXRoIGEgc3ViamVjdCBsaW5lDQogICBpbmRpY2F0aW5nIHdoZXRoZXIgdGhl IGVuY2xvc2VkIHJlY29yZCBpcyBhbiBpbnNlcnRpb24gb2YgYSBuZXcNCiAgIHJlY29yZCAo aW5kaWNhdGVkIGJ5IHRoZSB3b3JkICJJTlNFUlQiIGluIHRoZSBzdWJqZWN0IGxpbmUpIG9y IGENCiAgIHJlcGxhY2VtZW50IG9mIGFuIGV4aXN0aW5nIHJlY29yZCAoaW5kaWNhdGVkIGJ5 IHRoZSB3b3JkICJNT0RJRlkiIGluDQogICB0aGUgc3ViamVjdCBsaW5lKS4gIFJlY29yZHMg TVVTVCBOT1QgYmUgZGVsZXRlZCBmcm9tIHRoZSByZWdpc3RyeS4NCiAgIElBTkEgTVVTVCBw bGFjZSBhbnkgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgcmVjb3JkcyBpbnRvIHRoZSBhcHByb3By aWF0ZQ0KICAgc2VjdGlvbiBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5LCBncm91 cGluZyB0aGUgcmVjb3JkcyBieQ0KICAgdGhlaXIgJ1R5cGUnIGZpZWxkLiAgSW5zZXJ0ZWQg cmVjb3JkcyBNQVkgYmUgcGxhY2VkIGFueXdoZXJlIGluIHRoZQ0KICAgYXBwcm9wcmlhdGUg c2VjdGlvbjsgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIG9mIHRoZSBvcmRlciBvZiB0aGUNCiAg IHJlY29yZHMgYmV5b25kIGdyb3VwaW5nIHRoZW0gdG9nZXRoZXIgYnkgJ1R5cGUnLiAgTW9k aWZpZWQgcmVjb3Jkcw0KICAgTVVTVCBvdmVyd3JpdGUgdGhlIHJlY29yZCB0aGV5IHJlcGxh Y2UuDQoNCiAgIEluY2x1ZGVkIGluIGFueSByZXF1ZXN0IHRvIGluc2VydCBvciBtb2RpZnkg cmVjb3JkcyBNVVNUIGJlIGEgbmV3DQogICBGaWxlLURhdGUgcmVjb3JkLiAgVGhpcyByZWNv cmQgTVVTVCBiZSBwbGFjZWQgZmlyc3QgaW4gdGhlIHJlZ2lzdHJ5Lg0KICAgSW4gdGhlIGV2 ZW50IHRoYXQgdGhlIEZpbGUtRGF0ZSByZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkg aGFzIGENCiAgIGxhdGVyIGRhdGUgdGhhbiB0aGUgcmVjb3JkIGJlaW5nIGluc2VydGVkIG9y IG1vZGlmaWVkLCB0aGUgZXhpc3RpbmcNCiAgIHJlY29yZCBNVVNUIGJlIHByZXNlcnZlZC4N Cg0KNS4yLiAgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4 dGVuc2lvbnMgUmVnaXN0cnkgY2FuIGNvbnRhaW4gYXQgbW9zdCAzNSByZWNvcmRzDQogICBh bmQgdGh1cyBjaGFuZ2VzIHRvIHRoaXMgcmVnaXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlIHZl cnkgaW5mcmVxdWVudC4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNTFdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg IEFwcmlsIDIwMDcNCg0KDQogICBGdXR1cmUgd29yayBieSBJQU5BIG9uIHRoZSBMYW5ndWFn ZSBUYWcgRXh0ZW5zaW9ucyBSZWdpc3RyeSBpcw0KICAgbGltaXRlZCB0byB0d28gY2FzZXMu ICBGaXJzdCwgdGhlIElFU0cgTUFZIHJlcXVlc3QgdGhhdCBuZXcgcmVjb3Jkcw0KICAgYmUg aW5zZXJ0ZWQgaW50byB0aGlzIHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0aW1lLiAgVGhlc2Ug cmVxdWVzdHMNCiAgIE1VU1QgaW5jbHVkZSB0aGUgcmVjb3JkIHRvIGluc2VydCBpbiB0aGUg ZXhhY3QgZm9ybWF0IGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjcuICBJbiBhZGRpdGlv biwgdGhlcmUgTUFZIGJlIG9jY2FzaW9uYWwgcmVxdWVzdHMgZnJvbSB0aGUNCiAgIG1haW50 YWluaW5nIGF1dGhvcml0eSBmb3IgYSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRo ZSBjb250YWN0DQogICBpbmZvcm1hdGlvbiBvciBVUkxzIGluIHRoZSByZWNvcmQuICBUaGVz ZSByZXF1ZXN0cyBNVVNUIGluY2x1ZGUgdGhlDQogICBjb21wbGV0ZSwgdXBkYXRlZCByZWNv cmQuICBJQU5BIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIGlu Zm9ybWF0aW9uIHByb3ZpZGVkLCBvbmx5IHRoYXQgaXQgaXMgcHJvcGVybHkgZm9ybWF0dGVk LiAgSXQgc2hvdWxkDQogICByZWFzb25hYmx5IGJlIHNlZW4gdG8gY29tZSBmcm9tIHRoZSBt YWludGFpbmluZyBhdXRob3JpdHkgbmFtZWQgaW4NCiAgIHRoZSByZWNvcmQgcHJlc2VudCBp biB0aGUgcmVnaXN0cnkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQ YWdlIDUyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KNi4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQoNCiAgIExhbmd1YWdlIHRhZ3MgdXNlZCBpbiBjb250ZW50IG5lZ290aWF0 aW9uLCBsaWtlIGFueSBvdGhlciBpbmZvcm1hdGlvbg0KICAgZXhjaGFuZ2VkIG9uIHRoZSBJ bnRlcm5ldCwgbWlnaHQgYmUgYSBzb3VyY2Ugb2YgY29uY2VybiBiZWNhdXNlIHRoZXkNCiAg IG1pZ2h0IGJlIHVzZWQgdG8gaW5mZXIgdGhlIG5hdGlvbmFsaXR5IG9mIHRoZSBzZW5kZXIs IGFuZCB0aHVzDQogICBpZGVudGlmeSBwb3RlbnRpYWwgdGFyZ2V0cyBmb3Igc3VydmVpbGxh bmNlLg0KDQogICBUaGlzIGlzIGEgc3BlY2lhbCBjYXNlIG9mIHRoZSBnZW5lcmFsIHByb2Js ZW0gdGhhdCBhbnl0aGluZyBzZW50IGlzDQogICB2aXNpYmxlIHRvIHRoZSByZWNlaXZpbmcg cGFydHkgYW5kIHBvc3NpYmx5IHRvIHRoaXJkIHBhcnRpZXMgYXMgd2VsbC4NCiAgIEl0IGlz IHVzZWZ1bCB0byBiZSBhd2FyZSB0aGF0IHN1Y2ggY29uY2VybnMgY2FuIGV4aXN0IGluIHNv bWUgY2FzZXMuDQoNCiAgIFRoZSBldmFsdWF0aW9uIG9mIHRoZSBleGFjdCBtYWduaXR1ZGUg b2YgdGhlIHRocmVhdCwgYW5kIGFueSBwb3NzaWJsZQ0KICAgY291bnRlcm1lYXN1cmVzLCBp cyBsZWZ0IHRvIGVhY2ggYXBwbGljYXRpb24gcHJvdG9jb2wgKHNlZSBCQ1AgNzINCiAgIFtS RkMzNTUyXSBmb3IgYmVzdCBjdXJyZW50IHByYWN0aWNlIGd1aWRhbmNlIG9uIHNlY3VyaXR5 IHRocmVhdHMgYW5kDQogICBkZWZlbnNlcykuDQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgYXNz b2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBpbmZvcm1hdGlvbiBpdGVtIGlzIG9mDQogICBu byBjb25zZXF1ZW5jZSB3aGF0c29ldmVyIGluIGRldGVybWluaW5nIHdoZXRoZXIgdGhhdCBj b250ZW50IG1pZ2h0DQogICBjb250YWluIHBvc3NpYmxlIGhvbW9ncmFwaHMuICBUaGUgZmFj dCB0aGF0IGEgdGV4dCBpcyB0YWdnZWQgYXMgYmVpbmcNCiAgIGluIG9uZSBsYW5ndWFnZSBv ciB1c2luZyBhIHBhcnRpY3VsYXIgc2NyaXB0IHN1YnRhZyBwcm92aWRlcyBubw0KICAgYXNz dXJhbmNlIHdoYXRzb2V2ZXIgdGhhdCBpdCBkb2VzIG5vdCBjb250YWluIGNoYXJhY3RlcnMg ZnJvbSBzY3JpcHRzDQogICBvdGhlciB0aGFuIHRoZSBvbmUocykgYXNzb2NpYXRlZCB3aXRo IG9yIHNwZWNpZmllZCBieSB0aGF0IGxhbmd1YWdlDQogICB0YWcuDQoNCiAgIFNpbmNlIHRo ZXJlIGlzIG5vIGxpbWl0IHRvIHRoZSBudW1iZXIgb2YgdmFyaWFudCwgcHJpdmF0ZSB1c2Us IGFuZA0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGFuZCBjb25zZXF1ZW50bHkgbm8gbGltaXQg b24gdGhlIHBvc3NpYmxlIGxlbmd0aA0KICAgb2YgYSB0YWcsIGltcGxlbWVudGF0aW9ucyBu ZWVkIHRvIGd1YXJkIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93DQogICBhdHRhY2tzLiAgU2Vl IFNlY3Rpb24gNC4zIGZvciBkZXRhaWxzIG9uIGxhbmd1YWdlIHRhZyB0cnVuY2F0aW9uLA0K ICAgd2hpY2ggY2FuIG9jY3VyIGFzIGEgY29uc2VxdWVuY2Ugb2YgZGVmZW5zZXMgYWdhaW5z dCBidWZmZXIgb3ZlcmZsb3cuDQoNCiAgIEFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIG9m IHZhbGlkIHN1YnRhZ3MgZm9yIGFuIGV4dGVuc2lvbiAoc2VlDQogICBTZWN0aW9uIDMuNykg TVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0aGUgSW50ZXJuZXQsIGltcGxlbWVudGF0aW9ucw0K ICAgU0hPVUxEIE5PVCBtZWNoYW5pY2FsbHkgZGVwZW5kIG9uIGl0IGJlaW5nIGFsd2F5cyBh Y2Nlc3NpYmxlLCB0bw0KICAgcHJldmVudCBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDUzXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KNy4gIENoYXJhY3RlciBTZXQgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlIHN5bnRheCBpbiB0aGlzIGRvY3VtZW50IHJlcXVpcmVzIHRoYXQg bGFuZ3VhZ2UgdGFncyB1c2Ugb25seSB0aGUNCiAgIGNoYXJhY3RlcnMgQS1aLCBhLXosIDAt OSwgYW5kIEhZUEhFTi1NSU5VUywgd2hpY2ggYXJlIHByZXNlbnQgaW4gbW9zdA0KICAgY2hh cmFjdGVyIHNldHMsIHNvIHRoZSBjb21wb3NpdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHNob3Vs ZCBub3QgaGF2ZQ0KICAgYW55IGNoYXJhY3RlciBzZXQgaXNzdWVzLg0KDQogICBSZW5kZXJp bmcgb2YgY2hhcmFjdGVycyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiBhIGxhbmd1YWdlIHRh ZyBpcyBub3QNCiAgIGFkZHJlc3NlZCBpbiB0aGlzIG1lbW8uICBIaXN0b3JpY2FsbHksIHNv bWUgbGFuZ3VhZ2VzIGhhdmUgcmVsaWVkIG9uDQogICB0aGUgdXNlIG9mIHNwZWNpZmljIGNo YXJhY3RlciBzZXRzIG9yIG90aGVyIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvDQogICBpbmZl ciBob3cgYSBzcGVjaWZpYyBjaGFyYWN0ZXIgc2hvdWxkIGJlIHJlbmRlcmVkIChub3RhYmx5 IHRoaXMNCiAgIGFwcGxpZXMgdG8gbGFuZ3VhZ2UtIGFuZCBjdWx0dXJlLXNwZWNpZmljIHZh cmlhdGlvbnMgb2YgSGFuDQogICBpZGVvZ3JhcGhzIGFzIHVzZWQgaW4gSmFwYW5lc2UsIENo aW5lc2UsIGFuZCBLb3JlYW4pLiAgV2hlbiBsYW5ndWFnZQ0KICAgdGFncyBhcmUgYXBwbGll ZCB0byBzcGFucyBvZiB0ZXh0LCByZW5kZXJpbmcgZW5naW5lcyBzb21ldGltZXMgdXNlDQog ICB0aGF0IGluZm9ybWF0aW9uIGluIGRlY2lkaW5nIHdoaWNoIGZvbnQgdG8gdXNlIGluIHRo ZSBhYnNlbmNlIG9mDQogICBvdGhlciBpbmZvcm1hdGlvbiwgcGFydGljdWxhcmx5IHdoZXJl IGxhbmd1YWdlcyB3aXRoIGRpc3RpbmN0IHdyaXRpbmcNCiAgIHRyYWRpdGlvbnMgdXNlIHRo ZSBzYW1lIGNoYXJhY3RlcnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDU0XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KOC4gIENoYW5nZXMgZnJvbSBSRkMgNDY0Ng0K DQogICBUaGUgbWFpbiBnb2FsIGZvciB0aGlzIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQg d2FzIHRvIGluY29ycG9yYXRlDQogICBJU08gNjM5LTMgYW5kIGl0cyBhdHRlbmRlbnQgc2V0 IG9mIGxhbmd1YWdlIGNvZGVzIGludG8gdGhlIElBTkENCiAgIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyeSwgcGVybWl0dGluZyB0aGUgaWRlbnRpZmljYXRpb24gb2YgbWFueSBtb3JlDQog ICBsYW5ndWFnZXMgYW5kIGRpYWxlY3RzIHRoYW4gcHJldmlvdXNseSBzdXBwb3J0ZWQuDQoN CiAgIFRoZSBzcGVjaWZpYyBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgdG8gbWVldCB0aGVz ZSBnb2FscyBhcmU6DQoNCiAgIG8gIERlZmluZXMgdGhlIGluY29ycG9yYXRpb24gb2YgSVNP IDYzOS0zIGNvZGVzIGFzIGxhbmd1YWdlIGFuZA0KICAgICAgZXh0bGFuZyBzdWJ0YWdzLiAg RXh0bGFuZ3MgYXJlIG5vdyBwZXJtaXR0ZWQgaW4gbGFuZ3VhZ2UgdGFncy4NCiAgICAgIFRo ZSBjaGFuZ2VzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIHRoaXMgd2VyZToNCg0KICAgICAgKiAg c29tZXRoaW5nDQoNCiAgIG8gIENoYW5nZWQgdGhlIEFCTkYgcmVsYXRlZCB0byBncmFuZGZh dGhlcmVkIHRhZ3MuICBUaGUgaXJyZWd1bGFyDQogICAgICB0YWdzIGFyZSBub3cgbGlzdGVk LiAgV2VsbC1mb3JtZWQgZ3JhbmRmYXRoZXJlZCB0YWdzIGFyZSBub3cNCiAgICAgIGRlc2Ny aWJlZCBieSB0aGUgJ2xhbmd0YWcnIHByb2R1Y3Rpb24gYW5kIHRoZSAnZ3JhbmRmYXRoZXJl ZCcNCiAgICAgIHByb2R1Y3Rpb24gd2FzIHJlbW92ZWQgYXMgYSByZXN1bHQuICBBbHNvOiBh ZGRlZCBkZXNjcmlwdGlvbiBvZg0KICAgICAgYm90aCB0eXBlcyBvZiBncmFuZGZhdGhlcmVk IHRhZ3MgdG8gU2VjdGlvbiAyLjIuOC4NCg0KICAgbyAgQWRkZWQgdGhlIHBhcmFncmFwaCBv biAiY29sbGVjdGlvbnMiIHRvIFNlY3Rpb24gNC4xLg0KDQogICBvICBDaGFuZ2VkIHRoZSBj YXBpdGFsaXphdGlvbiBydWxlcyBmb3IgJ1RhZycgZmllbGRzIGluIFNlY3Rpb24gMy4xLg0K DQogICBvICBTcGxpdCBzZWN0aW9uIDMuMSB1cCBpbnRvIHN1YnNlY3Rpb25zLg0KDQogICBv ICBNb2RpZmllZCBzZWN0aW9uIDMuNSB0byBhbGxvdyBTdXBwcmVzcy1TY3JpcHQgZmllbGRz IHRvIGJlIGFkZGVkLA0KICAgICAgbW9kaWZpZWQsIG9yIHJlbW92ZWQgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2Vzcy4gIFRoaXMgd2FzIGFuDQogICAgICBlcnJhdHVtIGZyb20gUkZD IDQ2NDYuDQoNCiAgIG8gIE1vZGlmaWVkIGV4YW1wbGVzIHRoYXQgdXNlZCByZWdpb24gY29k ZSAnQ1MnIChmb3JtZXJseSBTZXJiaWEgYW5kDQogICAgICBNb250ZW5lZ3JvKSB0byB1c2Ug J1JTJyAoU2VyYmlhKSBpbnN0ZWFkLg0KDQogICBvICBNb2RpZmllZCB0aGUgcnVsZXMgZm9y IGNyZWF0aW5nIGFuZCBtYWludGFpbmluZyByZWNvcmQNCiAgICAgICdEZXNjcmlwdGlvbicg ZmllbGRzIHRvIHByZXZlbnQgZHVwbGljYXRlcywgaW5jbHVkaW5nIGludmVydGVkDQogICAg ICBkdXBsaWNhdGVzLg0KDQogICBvICBSZW1vdmVkIHRoZSBsZW5ndGh5IGRlc2NyaXB0aW9u IG9mIHdoeSBSRkMgNDY0NiB3YXMgY3JlYXRlZCBmcm9tDQogICAgICB0aGlzIHNlY3Rpb24s IHdoaWNoIGFsc28gY2F1c2VkIHRoZSByZW1vdmFsIG9mIHRoZSByZWZlcmVuY2UgdG8NCiAg ICAgIFhNTCBTY2hlbWEuDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSB0ZXh0IGluIHNlY3Rpb24g Mi4xIHRvIHBsYWNlIG1vcmUgZW1waGFzaXMgb24gdGhlDQogICAgICBmYWN0IHRoYXQgbGFu Z3VhZ2UgdGFncyBhcmUgbm90IGNhc2Ugc2Vuc2l0aXZlLg0KDQogICBvICBSZXBsYWNlZCB0 aGUgZXhhbXBsZSAiZnItTGF0bi1DQSIgaW4gU2VjdGlvbiAyLjEgd2l0aCAic3ItTGF0bi1S UyINCiAgICAgIGFuZCAiYXotQXJhYi1JUiIgYmVjYXVzZSAiZnItTGF0bi1DQSIgZG9lc24n dCByZXNwZWN0IHRoZQ0KICAgICAgU3VwcHJlc3MtU2NyaXB0IG9uICdMYXRuJyB3aXRoICdm cicuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcs IDIwMDcgICAgICAgICAgICAgICBbUGFnZSA1NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCiAgIG8gIENoYW5nZWQgdGhlIHJlcXVpcmVtZW50cyBmb3Igd2VsbC1mb3JtZWRuZXNz IHRvIG1ha2Ugc2luZ2xldG9uDQogICAgICByZXBldGl0aW9uIGNoZWNraW5nIG9wdGlvbmFs IChpdCBpcyByZXF1aXJlZCBmb3IgdmFsaWRpdHkNCiAgICAgIGNoZWNraW5nKSBpbiBTZWN0 aW9uIDIuMi45Lg0KDQogICBvICBDaGFuZ2VkIHRoZSB0ZXh0IGluIFNlY3Rpb24gMi4yLjkg cmVmZXJpbmcgdG8gZ3JhbmRmYXRoZXJlZA0KICAgICAgY2hlY2tpbmcgdG8gbm90ZSB0aGF0 IHRoZSBsaXN0IGlzIG5vdyBpbmNsdWRlZCBpbiB0aGUgQUJORi4NCg0KICAgbyAgTW9kaWZp ZWQgYW5kIGFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjIuICBUaGUgam9iIGRlc2NyaXB0aW9u IHdhcw0KICAgICAgcGxhY2VkIGZpcnN0LiAgQSBub3RlIHdhcyBhZGRlZCBtYWtpbmcgY2xl YXIgdGhhdCB0aGUgTGFuZ3VhZ2UNCiAgICAgIFN1YnRhZyBSZXZpZXdlciBtYXkgZGVsZWdh dGUgdmFyaW91cyBub24tY3JpdGljYWwgZHV0aWVzLA0KICAgICAgaW5jbHVkaW5nIGxpc3Qg bW9kZXJhdGlvbi4gIEZpbmFsbHksIGFkZGl0aW9uYWwgdGV4dCB3YXMgYWRkZWQgdG8NCiAg ICAgIG1ha2UgdGhlIGFwcG9pbnRtZW50IHByb2Nlc3MgY2xlYXIgYW5kIHRvIGNsYXJpZnkg dGhhdCBkZWNpc2lvbnMNCiAgICAgIGFuZCBwZXJmb3JtYW5jZSBvZiB0aGUgcmV2aWV3ZXIg YXJlIGFwcGVhbGFibGUuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjUgY2xh cmlmeWluZyB0aGF0IHRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0DQogICAgICBpcyBvcGVyYXRl ZCBieSB3aG9tZXZlciB0aGUgSUVTRyBhcHBvaW50cy4NCg0KICAgbyAgQWRkZWQgdGV4dCB0 byBTZWN0aW9uIDMuMS40IGNsYXJpZnlpbmcgdGhhdCB0aGUgZmlyc3QgRGVzY3JpcHRpb24N CiAgICAgIGluIGEgJ2xhbmd1YWdlJyBvciAnZXh0bGFuZycgcmVjb3JkIG1hdGNoZXMgdGhl IGNvcnJlc3BvbmRpbmcNCiAgICAgIFJlZmVyZW5jZSBOYW1lIGZvciB0aGUgbGFuZ3VhZ2Ug aW4gSVNPIDYzOS0zLg0KDQogICBvICBNb2RpZmllZCBTZWN0aW9uIDIuMi45IHRvIGRlZmlu ZSBjbGFzc2VzIG9mIGNvbmZvcm1hbmNlIHJlbGF0ZWQgdG8NCiAgICAgIHNwZWNpZmljIHRh Z3MgKGZvcm1lcmx5ICd3ZWxsLWZvcm1lZCcgYW5kICd2YWxpZCcgcmVmZXJyZWQgdG8NCiAg ICAgIGltcGxlbWVudGF0aW9ucykuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gdGhlIGVuZCBv ZiBTZWN0aW9uIDMuMS4yIG5vdGluZyB0aGF0IGZ1dHVyZSB2ZXJzaW9ucw0KICAgICAgb2Yg dGhpcyBkb2N1bWVudCBtaWdodCBhZGQgbmV3IGZpZWxkIHR5cGVzIGFuZCByZWNvbW1lbmRp bmcgdGhhdA0KICAgICAgaW1wbGVtZW50YXRpb25zIGlnbm9yZSBhbnkgdW5yZWNvZ25pemVk IGZpZWxkcy4NCg0KICAgbyAgTW9kaWZpZWQgdGhlICdleHRsYW5nJyBleGFtcGxlcyBpbiBB cHBlbmRpeCBBIHRvIHVzZSB2YWxpZCBzdWJ0YWdzDQogICAgICBhbmQgcmVtb3ZlZCB0aGUg bm90ZSBzYXlpbmcgdGhhdCB0aGV5IHdlcmUgb25seSBleGFtcGxlcy4NCg0KICAgbyAgQWRk ZWQgdGV4dCBhYm91dCB3aGF0IHRoZSBsYWNrIG9mIGEgU3VwcHJlc3MtU2NyaXB0IGZpZWxk IG1lYW5zIGluDQogICAgICBhIHJlY29yZCB0byBTZWN0aW9uIDMuMS45Lg0KDQogICBvICBB ZGRlZCB0ZXh0IGFsbG93aW5nIHRoZSBjb3JyZWN0aW9uIG9mIG1pc3NwZWxsaW5ncyBhbmQg dHlwb2dyYXBoaWMNCiAgICAgIGVycm9ycyB0byBTZWN0aW9uIDMuMS40Lg0KDQogICBvICBB ZGRlZCB0ZXh0IHRvIFNlY3Rpb24gMy4xLjcgZGlzYWxsb3dpbmcgUHJlZml4IGZpZWxkIGNv bmZsaWN0cw0KICAgICAgKHN1Y2ggYXMgY2lyY3VsYXIgcHJlZml4IHJlZmVyZW5jZXMpLg0K DQogICBvICBNb2RpZmllZCB0ZXh0IGluIFNlY3Rpb24gMy41IHRvIHJlcXVpcmUgdGhlIHN1 YnRhZyByZXZpZXdlciB0bw0KICAgICAgYW5ub3VuY2UgaGlzL2hlciBkZWNpc2lvbiAob3Ig ZXh0ZW5zaW9uKSBmb2xsb3dpbmcgdGhlIHR3by13ZWVrDQogICAgICBwZXJpb2QuICBBbHNv IGNsYXJpZmllZCB0aGF0IGFueSBkZWNpc2lvbiBvciBmYWlsdXJlIHRvIGRlY2lkZSBjYW4N CiAgICAgIGJlIGFwcGVhbGVkLg0KDQogICBvICBNb2RpZmllZCB0ZXh0IGluIFNlY3Rpb24g NC4xIHRvIGluY2x1ZGUgdGhlIChoZXJldG9mb3JlIGFuZWNkb3RhbCkNCiAgICAgIGd1aWRp bmcgcHJpbmNpcGxlIG9mIHRhZyBjaG9pY2UsIGFuZCBjbGFyaWZ5aW5nIHRoZSBub24tdXNl IG9mDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcs IDIwMDcgICAgICAgICAgICAgICBbUGFnZSA1Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCiAgICAgIHNjcmlwdCBzdWJ0YWdzIGluIG5vbi13cml0dGVuIGFwcGxpY2F0aW9ucy4g IEFsc28gdXBkYXRlZCBleGFtcGxlcw0KICAgICAgaW4gdGhpcyBzZWN0aW9uIHRvIHVzZSBD aGFtaWMgbGFuZ3VhZ2VzIGFzIGFuIGV4YW1wbGUgb2YgbGFuZ3VhZ2UNCiAgICAgIGNvbGxl Y3Rpb25zLg0KDQogICBvICBQcm9oaWJpdGVkIG11bHRpcGxlIHVzZSBvZiB0aGUgc2FtZSB2 YXJpYW50IGluIGEgdGFnIChpLmUuICJkZS0NCiAgICAgIDE5MDEtMTkwMSIpLiAgUHJldmlv dXNseSB0aGlzIHdhcyBvbmx5IGEgcmVjb21tZW5kYXRpb24NCiAgICAgICgiU0hPVUxEIiku DQoNCiAgIG8gIFJlbW92ZWQgaW5hcHByb3ByaWF0ZSBbUkZDMjExOV0gbGFuZ3VhZ2UgZnJv bSB0aGUgaWxsdXN0cmF0aW9uIGluDQogICAgICBTZWN0aW9uIDQuMy4xLg0KDQogICBvICBS ZXBsYWNlZCB0aGUgZXhhbXBsZSBvZiAiemgtZ291eXUiIHdpdGggInpoLWhha2thIi0+Inpo LWhhayIgaW4NCiAgICAgIFNlY3Rpb24gNC40LCBub3RpbmcgdGhhdCBpdCB3YXMgdGhpcyBk b2N1bWVudCB0aGF0IGNhdXNlZCB0aGUNCiAgICAgIGNoYW5nZS4NCg0KICAgW1tFZC5Ob3Rl OiBPcGVuIGlzc3VlcyBpbiB0aGlzIHZlcnNpb246DQoNCiAgICAgIFdoZXRoZXIgZW5jb21w YXNzZWQgbGFuZ3VhZ2UgcnVsZXMgZm9yIHRoZSBjcmVhdGlvbiBvZiBleHRsYW5nDQogICAg ICByZWNvcmRzIGluIHRoZSByZWdpc3RyeSBzaG91bGQgYmUgcmV0YWluZWQgb3IgbW9kaWZp ZWQuDQoNCiAgICAgIE1vZGlmaWNhdGlvbiBvZiB0aGUgcmVnaXN0cnkgdG8gdXNlIFVURi04 IGFzIGl0cyBjaGFyYWN0ZXINCiAgICAgIGVuY29kaW5nLiAocmVtb3ZlZCBhbmQgYXBwYXJl bnRseSByZWplY3RlZCkNCg0KICAgICAgRGV0YWlscyBvZiB0aGUgYXBwb2ludG1lbnQsIHRl cm0gZHVyYXRpb24sIHBlcmZvcm1hbmNlIHJldmlldyBvZg0KICAgICAgdGhlIHN1YnRhZyBy ZXZpZXdlciBieSB0aGUgSUVTRy4gKGFkZHJlc3NlZD8pDQoNCiAgICAgIEluY2x1c2lvbiBv ZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gU3VwcHJlc3MtU2NyaXB0IGlu DQogICAgICB0aGUgcmVnaXN0cnkgKGUuZy4gdGhhdCBpdCB3YXNuJ3QgYXNzaWduZWQgb24g cHVycG9zZSkNCg0KICAgXV0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDU3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K OS4gIFJlZmVyZW5jZXMNCg0KOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0lT TzEwNjQ2XQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3Ig U3RhbmRhcmRpemF0aW9uLCAiSVNPL0lFQw0KICAgICAgICAgICAgICAxMDY0NjoyMDAzLiBJ bmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIFVuaXZlcnNhbCBNdWx0aXBsZS0NCiAgICAgICAg ICAgICAgT2N0ZXQgQ29kZWQgQ2hhcmFjdGVyIFNldCAoVUNTKSIsIDIwMDMuDQoNCiAgIFtJ U08xNTkyNF0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9y IFN0YW5kYXJkaXphdGlvbiwgIklTTw0KICAgICAgICAgICAgICAxNTkyNDoyMDA0LiBJbmZv cm1hdGlvbiBhbmQgZG9jdW1lbnRhdGlvbiAtLSBDb2RlcyBmb3IgdGhlDQogICAgICAgICAg ICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHMiLCBKYW51YXJ5IDIwMDQu DQoNCiAgIFtJU08zMTY2LTFdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5p emF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gMzE2Ni0NCiAgICAgICAgICAgICAg MToxOTk3LiBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50 cmllcw0KICAgICAgICAgICAgICBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTog Q291bnRyeSBjb2RlcyIsIDE5OTcuDQoNCiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAg SW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2 MzktDQogICAgICAgICAgICAgIDE6MjAwMi4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlv biBvZiBuYW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAgICAgICAgLS0gUGFydCAxOiBBbHBo YS0yIGNvZGUiLCAyMDAyLg0KDQogICBbSVNPNjM5LTJdDQogICAgICAgICAgICAgIEludGVy bmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0K ICAgICAgICAgICAgICAyOjE5OTguIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2Yg bmFtZXMgb2YgbGFuZ3VhZ2VzDQogICAgICAgICAgICAgIC0tIFBhcnQgMjogQWxwaGEtMyBj b2RlLCBmaXJzdCBlZGl0aW9uIiwgMTk5OC4NCg0KICAgW0lTTzYzOS0zXQ0KICAgICAgICAg ICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAi SVNPIDYzOS0NCiAgICAgICAgICAgICAgMzoyMDA3LiBDb2RlcyBmb3IgdGhlIHJlcHJlc2Vu dGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcw0KICAgICAgICAgICAgICAtLSBQYXJ0IDM6 IEFscGhhLTMgY29kZSBmb3IgY29tcHJlaGVuc2l2ZSBjb3ZlcmFnZSBvZg0KICAgICAgICAg ICAgICBsYW5ndWFnZXMiLCAyMDA3Lg0KDQogICBbSVNPNjQ2XSAgIEludGVybmF0aW9uYWwg T3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08vSUVDDQogICAgICAgICAg ICAgIDY0NjoxOTkxLCBJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIElTTyA3LWJpdCBjb2Rl ZA0KICAgICAgICAgICAgICBjaGFyYWN0ZXIgc2V0IGZvciBpbmZvcm1hdGlvbiBpbnRlcmNo YW5nZS4iLCAxOTkxLg0KDQogICBbUkZDMjAyNl0gIEJyYWRuZXIsIFMuLCAiVGhlIEludGVy bmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tIFJldmlzaW9uDQogICAgICAgICAgICAgIDMiLCBC Q1AgOSwgUkZDIDIwMjYsIE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQzIwMjhdICBIb3ZleSwg Ui4gYW5kIFMuIEJyYWRuZXIsICJUaGUgT3JnYW5pemF0aW9ucyBJbnZvbHZlZCBpbg0KICAg ICAgICAgICAgICB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2VzcyIsIEJDUCAxMSwgUkZDIDIw MjgsDQogICAgICAgICAgICAgIE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQzIxMTldICBCcmFk bmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2gg MTk5Ny4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg NywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDU4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3 DQoNCg0KICAgW1JGQzI0MzRdICBOYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3Vp ZGVsaW5lcyBmb3IgV3JpdGluZyBhbg0KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRp b25zIFNlY3Rpb24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDIDI0MzQsDQogICAgICAgICAgICAg IE9jdG9iZXIgMTk5OC4NCg0KICAgW1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwg Ri4sIGFuZCBNLiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBVbmRl cnN0YW5kaW5nIENvbmNlcm5pbmcgdGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAg ICAgICAgICBJbnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYw LCBKdW5lIDIwMDAuDQoNCiAgIFtSRkMzMzM5XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4s ICJEYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDoNCiAgICAgICAgICAgICAgVGltZXN0 YW1wcyIsIFJGQyAzMzM5LCBKdWx5IDIwMDIuDQoNCiAgIFtSRkM0MjM0XSAgQ3JvY2tlciwg RC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNDIzNCwgT2N0b2JlciAyMDA1Lg0K DQogICBbUkZDNDY0NV0gIEV3ZWxsLCBELiwgRWQuLCAiSW5pdGlhbCBMYW5ndWFnZSBTdWJ0 YWcgUmVnaXN0cnkiLA0KICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNiwgPGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjL3JmYzQ2NDUudHh0Pi4NCg0KICAgW1JGQzQ2NDddICBQaGlsbGlw cywgQS4sIEVkLiBhbmQgTS4gRGF2aXMsIEVkLiwgIk1hdGNoaW5nIG9mIExhbmd1YWdlDQog ICAgICAgICAgICAgIFRhZ3MiLCBTZXB0ZW1iZXIgMjAwNiwNCiAgICAgICAgICAgICAgPGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzQ2NDcudHh0Pi4NCg0KICAgW1VOX00uNDldICBT dGF0aXN0aWNzIERpdmlzaW9uLCBVbml0ZWQgTmF0aW9ucywgIlN0YW5kYXJkIENvdW50cnkg b3INCiAgICAgICAgICAgICAgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIiwgVU4g U3RhbmRhcmQgQ291bnRyeSBvcg0KICAgICAgICAgICAgICBBcmVhIENvZGVzIGZvciBTdGF0 aXN0aWNhbCBVc2UsIFJldmlzaW9uIDQgKFVuaXRlZCBOYXRpb25zDQogICAgICAgICAgICAg IHB1YmxpY2F0aW9uLCBTYWxlcyBOby4gOTguWFZJSS45LCBKdW5lIDE5OTkuDQoNCjkuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzE3NjZdICBBbHZlc3RyYW5kLCBI LiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5n dWFnZXMiLCBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0KICAgW1JGQzIwNDddICBNb29yZSwg Sy4sICJNSU1FIChNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zKQ0KICAg ICAgICAgICAgICBQYXJ0IFRocmVlOiBNZXNzYWdlIEhlYWRlciBFeHRlbnNpb25zIGZvciBO b24tQVNDSUkgVGV4dCIsDQogICAgICAgICAgICAgIFJGQyAyMDQ3LCBOb3ZlbWJlciAxOTk2 Lg0KDQogICBbUkZDMjIzMV0gIEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFt ZXRlciBWYWx1ZSBhbmQgRW5jb2RlZA0KICAgICAgICAgICAgICBXb3JkIEV4dGVuc2lvbnM6 IENoYXJhY3RlciBTZXRzLCBMYW5ndWFnZXMsIGFuZA0KICAgICAgICAgICAgICBDb250aW51 YXRpb25zIiwgUkZDIDIyMzEsIE5vdmVtYmVyIDE5OTcuDQoNCiAgIFtSRkMyNzgxXSAgSG9m Zm1hbiwgUC4gYW5kIEYuIFllcmdlYXUsICJVVEYtMTYsIGFuIGVuY29kaW5nIG9mIElTTw0K ICAgICAgICAgICAgICAxMDY0NiIsIFJGQyAyNzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBb UkZDMzA2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9u IG9mDQogICAgICAgICAgICAgIExhbmd1YWdlcyIsIEJDUCA0NywgUkZDIDMwNjYsIEphbnVh cnkgMjAwMS4NCg0KICAgW1JGQzM1NTJdICBSZXNjb3JsYSwgRS4gYW5kIEIuIEtvcnZlciwg Ikd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDDQogICAgICAgICAgICAgIFRleHQgb24gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAzNTUyLA0KICAgICAgICAgICAg ICBKdWx5IDIwMDMuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSA1OV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNw0KDQoNCiAgIFtSRkM0NjQ2XSAgUGhpbGxpcHMsIEEuLCBFZC4gYW5kIE0uIERh dmlzLCBFZC4sICJUYWdzIGZvciB0aGUNCiAgICAgICAgICAgICAgSWRlbnRpZmljYXRpb24g b2YgTGFuZ3VhZ2VzIiwgU2VwdGVtYmVyIDIwMDYsDQogICAgICAgICAgICAgIDxodHRwOi8v d3d3LmlldGYub3JnL3JmYy9yZmM0NjQ2LnR4dD4uDQoNCiAgIFtVbmljb2RlXSAgVW5pY29k ZSBDb25zb3J0aXVtLCAiVGhlIFVuaWNvZGUgQ29uc29ydGl1bS4gVGhlIFVuaWNvZGUNCiAg ICAgICAgICAgICAgU3RhbmRhcmQsIFZlcnNpb24gNS4wLCAoQm9zdG9uLCBNQSwgQWRkaXNv bi1XZXNsZXksIDIwMDMuDQogICAgICAgICAgICAgIElTQk4gMC0zMjEtNDkwODEtMCkiLCBK YW51YXJ5IDIwMDcuDQoNCiAgIFtYTUwxMF0gICAgQnJheSAoZXQgYWwpLCBULiwgIkV4dGVu c2libGUgTWFya3VwIExhbmd1YWdlIChYTUwpIDEuMCIsDQogICAgICAgICAgICAgIDAyIDIw MDQuDQoNCiAgIFtpc282MzkucHJpbl0NCiAgICAgICAgICAgICAgSVNPIDYzOSBKb2ludCBB ZHZpc29yeSBDb21taXR0ZWUsICJJU08gNjM5IEpvaW50IEFkdmlzb3J5DQogICAgICAgICAg ICAgIENvbW1pdHRlZTogIFdvcmtpbmcgcHJpbmNpcGxlcyBmb3IgSVNPIDYzOSBtYWludGVu YW5jZSIsDQogICAgICAgICAgICAgIE1hcmNoIDIwMDAsDQogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yLw0KICAgICAgICAgICAgICBpc282 MzlqYWNfbjNyLmh0bWw+Lg0KDQogICBbcmVjb3JkLWphcl0NCiAgICAgICAgICAgICAgUmF5 bW9uZCwgRS4sICJUaGUgQXJ0IG9mIFVuaXggUHJvZ3JhbW1pbmciLCAyMDAzLA0KICAgICAg ICAgICAgICA8dXJuOmlzYm46MC0xMy0xNDI5MDEtOT4uDQoNCiAgIFtyZWdpc3RyeS11cGRh dGVdDQogICAgICAgICAgICAgIEV3ZWxsLCBELiwgRWQuLCAiVXBkYXRlIHRvIHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkiLA0KICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNiwg PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtaW5pdGlhbC1yZWdpc3RyeS0wMC50eHQ+Lg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSA2 MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCkFwcGVuZGl4IEEuICBBY2tub3dsZWRn ZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNvbnRyaWJ1dG9ycyBpcyBib3VuZCB0byBiZSBp bmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0KICAgZm9sbG93aW5nIGFzIG9ubHkgYSBz ZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdobyBoYXZlDQogICBjb250cmli dXRlZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2RheS4NCg0KICAgVGhl IGNvbnRyaWJ1dG9ycyB0byBSRkMgNDY0NiwgUkZDIDQ2NDcsIFJGQyAzMDY2LCBhbmQgUkZD IDE3NjYsIHRoZQ0KICAgcHJlY3Vyc29ycyBvZiB0aGlzIGRvY3VtZW50LCBtYWRlIGVub3Jt b3VzIGNvbnRyaWJ1dGlvbnMgZGlyZWN0bHkgb3INCiAgIGluZGlyZWN0bHkgdG8gdGhpcyBk b2N1bWVudCBhbmQgYXJlIGdlbmVyYWxseSByZXNwb25zaWJsZSBmb3IgdGhlDQogICBzdWNj ZXNzIG9mIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIFRoZSBmb2xsb3dpbmcgcGVvcGxlIGNvbnRy aWJ1dGVkIHRvIHRoaXMgZG9jdW1lbnQ6DQoNCiAgIFN0ZXBoYW5lIEJvcnR6bWV5ZXIsIEth cmVuIEJyb29tZSwgUGV0ZXIgQ29uc3RhYmxlLCBKb2huIENvd2FuLA0KICAgTWFydGluIER1 ZXJzdCwgRnJhbmsgRWxsZXJtYW4sIERvdWcgRXdlbGwsIE1hcmlvbiBHdW5uLCBSYW5keQ0K ICAgUHJlc3VobiwgYW5kIG1hbnksIG1hbnkgb3RoZXJzLg0KDQogICBWZXJ5IHNwZWNpYWwg dGhhbmtzIG11c3QgZ28gdG8gSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQsIHdobw0KICAgb3Jp Z2luYXRlZCBSRkNzIDE3NjYgYW5kIDMwNjYsIGFuZCB3aXRob3V0IHdob20gdGhpcyBkb2N1 bWVudCB3b3VsZA0KICAgbm90IGhhdmUgYmVlbiBwb3NzaWJsZS4NCg0KICAgU3BlY2lhbCB0 aGFua3MgZ28gdG8gTWljaGFlbCBFdmVyc29uLCB3aG8gc2VydmVkIGFzIHRoZSBMYW5ndWFn ZSBUYWcNCiAgIFJldmlld2VyIGZvciBhbG1vc3QgdGhlIGVudGlyZSBSRkMgMTc2Ni9SRkMg MzA2NiBwZXJpb2QsIGFzIHdlbGwgYXMNCiAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgc2luY2UgdGhlIGFkb3B0aW9uIG9mIFJGQyA0NjQ2Lg0KDQogICBTcGVjaWFsIHRoYW5r cyBhbHNvIHRvIERvdWcgRXdlbGwsIGZvciBoaXMgcHJvZHVjdGlvbiBvZiB0aGUgZmlyc3QN CiAgIGNvbXBsZXRlIHN1YnRhZyByZWdpc3RyeSwgaGlzIHdvcmsgdG8gc3VwcG9ydCBhbmQg bWFpbnRhaW4gbmV3DQogICByZWdpc3RyYXRpb25zLCBhbmQgaGlzIGNhcmVmdWwgZWRpdG9y c2hpcCBvZiBib3RoIFJGQyA0NjQ1IGFuZA0KICAgW3JlZ2lzdHJ5LXVwZGF0ZV0uDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAgIFtQYWdl IDYxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KQXBwZW5kaXggQi4gIEV4YW1wbGVz IG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKQ0KDQogICBTaW1wbGUgbGFuZ3VhZ2Ug c3VidGFnOg0KDQogICAgICBkZSAoR2VybWFuKQ0KDQogICAgICBmciAoRnJlbmNoKQ0KDQog ICAgICBqYSAoSmFwYW5lc2UpDQoNCiAgICAgIGktZW5vY2hpYW4gKGV4YW1wbGUgb2YgYSBn cmFuZGZhdGhlcmVkIHRhZykNCg0KICAgTGFuZ3VhZ2Ugc3VidGFnIHBsdXMgU2NyaXB0IHN1 YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBUcmFk aXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAgemgtSGFucyAoQ2hpbmVzZSB3cml0 dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0KQ0KDQogICAgICBzci1D eXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkNCg0KICAg ICAgc3ItTGF0biAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpDQoN CiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb246DQoNCiAgICAgIHpoLUhhbnMtQ04gKENoaW5l c2Ugd3JpdHRlbiB1c2luZyB0aGUgU2ltcGxpZmllZCBzY3JpcHQgYXMgdXNlZCBpbg0KICAg ICAgbWFpbmxhbmQgQ2hpbmEpDQoNCiAgICAgIHNyLUxhdG4tUlMgKFNlcmJpYW4gd3JpdHRl biB1c2luZyB0aGUgTGF0aW4gc2NyaXB0IGFzIHVzZWQgaW4NCiAgICAgIFNlcmJpYSkNCg0K ICAgTGFuZ3VhZ2UtVmFyaWFudDoNCg0KICAgICAgc2wtcm96YWogKFJlc2lhbiBkaWFsZWN0 IG9mIFNsb3ZlbmlhbikNCg0KICAgICAgc2wtbmVkaXMgKE5hZGl6YSBkaWFsZWN0IG9mIFNs b3ZlbmlhbikNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAgICAgIGRlLUNI LTE5MDEgKEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIHVzaW5nIHRoZSAxOTAxIHZh cmlhbnQNCiAgICAgIFtvcnRob2dyYXBoeV0pDQoNCiAgICAgIHNsLUlULW5lZGlzIChTbG92 ZW5pYW4gYXMgdXNlZCBpbiBJdGFseSwgTmFkaXphIGRpYWxlY3QpDQoNCiAgIExhbmd1YWdl LVNjcmlwdC1SZWdpb24tVmFyaWFudDoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2Ug NjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICBoeS1MYXRuLUlULWFyZXZl bGEgKEVhc3Rlcm4gQXJtZW5pYW4gd3JpdHRlbiBpbiBMYXRpbiBzY3JpcHQsIGFzDQogICAg ICB1c2VkIGluIEl0YWx5KQ0KDQogICBMYW5ndWFnZS1SZWdpb246DQoNCiAgICAgIGRlLURF IChHZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAgIGVuLVVTIChFbmdsaXNoIGFzIHVzZWQg aW4gdGhlIFVuaXRlZCBTdGF0ZXMpDQoNCiAgICAgIGVzLTQxOSAoU3BhbmlzaCBhcHByb3By aWF0ZSBmb3IgdGhlIExhdGluIEFtZXJpY2EgYW5kIENhcmliYmVhbg0KICAgICAgcmVnaW9u IHVzaW5nIHRoZSBVTiByZWdpb24gY29kZSkNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFnczoN Cg0KICAgICAgZGUtQ0gteC1waG9uZWJrDQoNCiAgICAgIGF6LUFyYWIteC1BWkUtZGVyYmVu ZA0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzOg0KDQogICAgICB6aC1jbW4NCg0K ICAgICAgemgtY21uLUhhbnQtQ04NCg0KICAgUHJpdmF0ZSB1c2UgcmVnaXN0cnkgdmFsdWVz Og0KDQogICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVzZSB1c2luZyB0aGUgc2luZ2xldG9u ICd4JykNCg0KICAgICAgcWFhLVFhYWEtUU0teC1zb3V0aGVybiAoYWxsIHByaXZhdGUgdGFn cykNCg0KICAgICAgZGUtUWFhYSAoR2VybWFuLCB3aXRoIGEgcHJpdmF0ZSBzY3JpcHQpDQoN CiAgICAgIHNyLUxhdG4tUU0gKFNlcmJpYW4sIExhdGluLXNjcmlwdCwgcHJpdmF0ZSByZWdp b24pDQoNCiAgICAgIHNyLVFhYWEtUlMgKFNlcmJpYW4sIHByaXZhdGUgc2NyaXB0LCBmb3Ig U2VyYmlhKQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1wbGVzIE9OTFk6 IGV4dGVuc2lvbnMgTVVTVCBiZSBkZWZpbmVkDQogICBieSByZXZpc2lvbiBvciB1cGRhdGUg dG8gdGhpcyBkb2N1bWVudCBvciBieSBSRkMpOg0KDQogICAgICBlbi1VUy11LWlzbGFtQ2Fs DQoNCiAgICAgIHpoLUNOLWEtbXlFeHQteC1wcml2YXRlDQoNCiAgICAgIGVuLWEtbXlFeHQt Yi1hbm90aGVyDQoNCiAgIFNvbWUgSW52YWxpZCBUYWdzOg0KDQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNywgMjAwNyAgICAgICAgICAgICAg IFtQYWdlIDYzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgICAgZGUtNDE5LURF ICh0d28gcmVnaW9uIHRhZ3MpDQoNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmdsZS1jaGFy YWN0ZXIgc3VidGFnIGluIHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRoYXQgdGhl cmUgYXJlIGEgZmV3IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImktIiB0 aGF0DQogICAgICBhcmUgdmFsaWQpDQoNCiAgICAgIGFyLWEtYWFhLWItYmJiLWEtY2NjICh0 d28gZXh0ZW5zaW9ucyB3aXRoIHNhbWUgc2luZ2xlLWxldHRlcg0KICAgICAgcHJlZml4KQ0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDcsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSA2NF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNw0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBBZGRp c29uIFBoaWxsaXBzIChlZGl0b3IpDQogICBZYWhvbyEgSW5jLg0KDQogICBFbWFpbDogYWRk aXNvbkBpbnRlci1sb2NhbGUuY29tDQogICBVUkk6ICAgaHR0cDovL3d3dy5pbnRlci1sb2Nh bGUuY29tDQoNCg0KICAgTWFyayBEYXZpcyAoZWRpdG9yKQ0KICAgR29vZ2xlDQoNCiAgIEVt YWlsOiBtYXJrLmRhdmlzQG1hY2NoaWF0by5jb20gb3IgbWFyay5kYXZpc0Bnb29nbGUuY29t DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgIEV4cGly ZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNjVdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg IEFwcmlsIDIwMDcNCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJp Z2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zDQogICBj b250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0 aGUgYXV0aG9ycw0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCiAgIFRoaXMgZG9j dW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRl ZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JH QU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElG IEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQNCiAgIFRI RSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTDQogICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVE IFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YNCiAgIFRIRSBJTkZPUk1BVElPTiBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAg V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuDQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRG IHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2Yg YW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0 aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9j dW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJp Z2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBw cm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4g YmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBS IGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAg YXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJl c3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5z ZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJp Z2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlv biBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5 IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRl cyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0K ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhl ciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhh dCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxl YXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlw ckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUg UkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUgSUVURg0KICAgQWRtaW5p c3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA3LCAyMDA3ICAgICAgICAgICAgICAg W1BhZ2UgNjZdDQoMDQo= --------------010406030502090308080205 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 --------------010406030502090308080205-- From ltru-bounces@ietf.org Thu Apr 05 13:50: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 1HZW6a-0008P0-Of; Thu, 05 Apr 2007 13:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZW6Z-0008Ov-8z for ltru@ietf.org; Thu, 05 Apr 2007 13:50:39 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZW6W-0001Me-Tt for ltru@ietf.org; Thu, 05 Apr 2007 13:50:39 -0400 Received: from [10.72.76.144] (snvvpn2-10-72-76-c144.corp.yahoo.com [10.72.76.144]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l35HoVI7004811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2007 10:50:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=eBfSbPTUrtlO17Q8TPbngurvwxqXSMi5PCSoF7sRPDDDifQM4GRN38FaXsYb+RXw Message-ID: <461536E7.3070302@yahoo-inc.com> Date: Thu, 05 Apr 2007 10:50:31 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] draft-04 submitted... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I just submitted draft-04. Note that I'll be on vacation the next ten days or so. Mark will be tracking proposed changes. Not much of note here. I did incorporate John's suggested changes to the ABNF and the section on extlangs. The other big change is that I reorganized the section on the language subtag reviewer (I put the job description first) and added a proposal to deal with Mark's desire for greater "personnel selection detail". Y'all debate that while I'm gone...... inter-locale is updated and there is a link to the diff. http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-04.xml http://tinyurl.com/2hahqc (wdiff) Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 05 14:07: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 1HZWMh-0001JQ-Rj; Thu, 05 Apr 2007 14:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWMg-0001J8-QB for ltru@ietf.org; Thu, 05 Apr 2007 14:07:18 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWMf-0003mT-Ii for ltru@ietf.org; Thu, 05 Apr 2007 14:07:18 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HZWMe-0005XZ-UP; Thu, 05 Apr 2007 14:07:17 -0400 Date: Thu, 5 Apr 2007 14:07:16 -0400 To: Addison Phillips Subject: Re: [Ltru] draft-04 submitted... Message-ID: <20070405180716.GC20773@mercury.ccil.org> References: <461536E7.3070302@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461536E7.3070302@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > http://tinyurl.com/2hahqc (wdiff) TinyURL doesn't like this one: I created http://tinyurl.com/2ba77f as a replacement. -- John Cowan cowan@ccil.org http://ccil.org/~cowan It's the old, old story. Droid meets droid. Droid becomes chameleon. Droid loses chameleon, chameleon becomes blob, droid gets blob back again. It's a classic tale. --Kryten, Red Dwarf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 05 14:12: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 1HZWRN-0004ja-4O; Thu, 05 Apr 2007 14:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWRL-0004jV-Ie for ltru@ietf.org; Thu, 05 Apr 2007 14:12:07 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWRK-0004kc-2z for ltru@ietf.org; Thu, 05 Apr 2007 14:12:07 -0400 Received: from [10.72.76.144] (snvvpn2-10-72-76-c144.corp.yahoo.com [10.72.76.144]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l35IBo4e007448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 11:11:50 -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=z0oAoMym1WFMN9v1ENYKPxNAQmgp2oDT4OFG9odrWJTxN+g8OuwtIAs8mO+ZkqHy Message-ID: <46153BE5.8070509@yahoo-inc.com> Date: Thu, 05 Apr 2007 11:11:49 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] draft-04 submitted... References: <461536E7.3070302@yahoo-inc.com> <20070405180716.GC20773@mercury.ccil.org> In-Reply-To: <20070405180716.GC20773@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Argh. Thanks. Seems I got an extra bit of garbage into the URL. Addison John Cowan wrote: > Addison Phillips scripsit: > >> http://tinyurl.com/2hahqc (wdiff) > > TinyURL doesn't like this one: I created http://tinyurl.com/2ba77f > as a replacement. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 05 15:50: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 1HZXyo-0003Eo-MD; Thu, 05 Apr 2007 15:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyb-0002jQ-IY; Thu, 05 Apr 2007 15:50:33 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXyW-0004me-Kb; Thu, 05 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CBDE426F59; Thu, 5 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZXy6-00046c-Nr; Thu, 05 Apr 2007 15:50: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: Thu, 05 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4646bis-04.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-04.txt Pages : 66 Date : 2007-4-5 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-04.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-04.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-04.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-4-5143104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4646bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4646bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-5143104.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 Mon Apr 09 15:50: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 1Hazro-0004Ep-MJ; Mon, 09 Apr 2007 15:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hazrn-00049P-GU for ltru@ietf.org; Mon, 09 Apr 2007 15:49:31 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hazrl-000832-Mz for ltru@ietf.org; Mon, 09 Apr 2007 15:49:31 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 560BD4EF64; Mon, 9 Apr 2007 15:49:27 -0400 (EDT) From: "Richard Ishida" To: "'Mark Davis'" References: <004a01c77465$db00a540$6401a8c0@rishida> <00e401c7752e$64e96030$6401a8c0@rishida> <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> Date: Mon, 9 Apr 2007 20:50:06 +0100 Message-ID: <000301c77ae0$475a4630$6501a8c0@rishida> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1Ut2p2PgLOgykSuKMjG/ieymevgFjSOQg In-Reply-To: <30b660a20704021115u706eff0cn420e3319bcb349f7@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: 'WWW International' , 'Misha Wolf' , 'LTRU Working Group' Subject: [Ltru] RE: New web app: Searching for language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0236343334==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0236343334== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C77AE8.A91EAE30" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C77AE8.A91EAE30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I carved out some time to change the selection UI. Hopefully that's now = clearer. =20 http://people.w3.org/rishida/utils/subtags/index.php =20 RI =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) =20 http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ =20 =20 _____ =20 From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis Sent: 02 April 2007 19:15 To: Richard Ishida Cc: Misha Wolf; LTRU Working Group; WWW International Subject: Re: [Ltru] RE: New web app: Searching for language subtags I have a couple of usability suggestions. Example. Click on Regions, put in "France" in Search for: and click Show = Result. You get unexpected outcome. It isn't clear that the push button = only affects what the radio button says. And even after you know this, = it's clumsy, since you always have to switch the radio button, then hit = the push button.=20 Rather than the current interface, it would be faster and less confusing = to have pushbuttons for all of what you have as radio buttons, and = remove "Show Results". And retitle Descriptions and Subtags as "Search = Descriptions" and "Search Subtags".=20 Subtags isn't quite right either, since I can put in whole language tags = like "ar-Arab". So I'd suggest separating that as a separate button = "Search Tags". You don't test for invalid whole tags right now, so = "Arab-en". You document that, but it would be easy to fix. I have a = regex that tests validity and divides up the language tag into the = pieces, so you could use that if you want.=20 Mark On 4/2/07, Richard Ishida wrote:=20 Hmm. People who haven't been initiated into the arcane mysteries of BCP = 47 still have to use the registry to find subtags. If there are things they need to understand, we'd better help them there. Note that they no = longer=20 see redundant tags when searching for Chinese with my tool, and that I included a short explanation of redundant in the side notes. I hope = that will help. RI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead=20 W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Misha Wolf [mailto: Misha.Wolf@reuters.com = ] > Sent: 01 April 2007 15:14 > To: Richard Ishida; WWW International; LTRU Working Group > Subject: RE: New web app: Searching for language subtags > > Hi Richard, > > Having spent a few minutes playing with this, it seems to be > both useful and fun. > > My one concern is that people who haven't been initiated into > the arcane mysteries of BCP 47, might misunderstand the=20 > meaning of a heading like "redundant" in response to a search > for "Chinese". It needs to be made clear to people that this > is a tool for examining the registry, > *NOT* a tool for finding appropriate language tags. If it is=20 > meant to be used for the latter purpose, then some changes > are very much needed :-) > > Regards, > Misha > > > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > Sent: 01 April 2007 14:59 > To: 'WWW International'=20 > Subject: New web app: Searching for language subtags > > > You may find this of interest. It's purely a personal project. > > http://people.w3.org/rishida/utils/subtags/ > > > http://people.w3.org/rishida/blog/?p=3D90 says: > > This tool allows you to search for tags that have, say,=20 > 'french' in their description (there are currently 11), or to > find out what that mysterious 'ch' tag stands for (there are > 2 possibilities). Or you can simply list all current language=20 > tags, or script tags, or variants, etc. > > For months I've been wanting to write a small, Web-based tool > for finding things in the subtag registry without having to > work on the (for many people, intimidating) raw text file on=20 > the IANA site. > > Tom Gruner created an initial tool for pretty printing the > IANA list, which handled enough of the basics to allow me to > use the little time I have these days to add the search=20 > functionality on top. > > If you have JavaScript running, you are shown just the tags > and descriptions initially, but by clicking on those you can > reveal all additional information in the registry for a given=20 > tag. I also highlight tags that are deprecated, so you can > see that straight away. > > (PS: Some final tweaks to the code will come when I have a > spare moment for things like making the expanding list more=20 > accessible, etc.) > > RI > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > > This email was sent to you by Reuters, the global news and > information company.=20 > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the > individual sender, except where the sender specifically=20 > states them to be the views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of > which Reuters Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters=20 > Building, South Colonnade, Canary Wharf, London E14 5EP, > United Kingdom Registered No: 3296375 Registered in England and Wales > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=20 Mark=20 ------=_NextPart_000_0004_01C77AE8.A91EAE30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
I=20 carved out some time to change the selection UI.  Hopefully that's = now=20 clearer.
 
http://peop= le.w3.org/rishida/utils/subtags/index.php
 
RI
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Richard = Ishida
Internationalization = Lead
W3C (World Wide Web=20 Consortium)
 
http://www.w3.org/People/Ishida= /
http://www.w3.org/International= /
http://people.w3.org/rishida/= blog/
http://www.flickr.com/photo= s/ishida/
 
 

From: mark.edward.davis@gmail.com=20 [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark=20 Davis
Sent: 02 April 2007 19:15
To: Richard=20 Ishida
Cc: Misha Wolf; LTRU Working Group; WWW=20 International
Subject: Re: [Ltru] RE: New web app: Searching = for=20 language subtags

I have a couple of usability suggestions.

Example. = Click on=20 Regions, put in "France" in Search for: and = click=20 Show Result. You get unexpected outcome. = It=20 isn't clear that the push button only affects what the radio button = says. And=20 even after you know this, it's clumsy, since you always have to switch = the=20 radio button, then hit the push button.

Rather than the = current=20 interface, it would be faster and less confusing to have pushbuttons = for all=20 of what you have as radio buttons, and remove "Show Results". And = retitle=20 Descriptions and Subtags as "Search Descriptions" and "Search = Subtags".=20

Subtags isn't quite right either, since I can put in whole = language=20 tags like "ar-Arab". So I'd suggest separating that as a separate = button=20 "Search Tags". You don't test for invalid whole tags right now, so = "Arab-en".=20 You document that, but it would be easy to fix. I have a regex that = tests=20 validity and divides up the language tag into the pieces, so you could = use=20 that if you want.

Mark

On 4/2/07, Richard=20 Ishida <ishida@w3.org>=20 wrote:
Hmm.=20 People who haven't been initiated into the arcane mysteries of BCP=20 47
still have to use the registry to find subtags. If there are = things=20 they
need to understand, we'd better help them = there.  Note=20 that they no longer
see redundant tags when searching for = Chinese with=20 my tool, and that I
included a short explanation of redundant in = the side=20 notes.  I hope that
will=20 = help.

RI

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Richard=20 Ishida
Internationalization Lead
W3C (World Wide Web=20 Consortium)

http://www.w3.org/People/Ishida= /
http://www.w3.org/International= /
http://people.w3.org/rishida/= blog/
http://www.flickr.com/photo= s/ishida/



>=20 -----Original Message-----
> From: Misha Wolf [mailto: = Misha.Wolf@reuters.com]
>=20 Sent: 01 April 2007 15:14
> To: Richard Ishida; WWW = International;=20 LTRU Working Group
> Subject: RE: New web app: Searching for = language=20 subtags
>
> Hi Richard,
>
> Having spent a = few=20 minutes playing with this, it seems to be
> both useful and=20 fun.
>
> My one concern is that people who haven't been=20 initiated into
> the arcane mysteries of BCP 47, might = misunderstand=20 the
> meaning of a heading like "redundant" in response to a=20 search
> for "Chinese".  It needs to be made clear = to people=20 that this
> is a tool for examining the registry,
> = *NOT* a tool=20 for finding appropriate language tags.  If it is
> = meant to=20 be used for the latter purpose, then some changes
> are very = much=20 needed :-)
>
> Regards,
> = Misha
>
>
>=20 -----Original Message-----
> From: www-international-reques= t@w3.org
>=20 [mailto:www-international-reques= t@w3.org]=20 On Behalf Of Richard Ishida
> Sent: 01 April 2007 = 14:59
> To:=20 'WWW International'
> Subject: New web app: Searching for = language=20 subtags
>
>
> You may find this of=20 interest.  It's purely a personal project.
>
> = http://people.w3.org= /rishida/utils/subtags/
>
>
>=20 http://people.w3.org/r= ishida/blog/?p=3D90=20 says:
>
> This tool allows you to search for tags that = have,=20 say,
> 'french' in their description (there are currently = 11), or=20 to
> find out what that mysterious 'ch' tag stands for (there=20 are
> 2 possibilities). Or you can simply list all current = language=20
> tags, or script tags, or variants, etc.
>
> For = months=20 I've been wanting to write a small, Web-based tool
> for = finding=20 things in the subtag registry without having to
> work on the = (for=20 many people, intimidating) raw text file on
> the IANA=20 site.
>
> Tom Gruner created an initial tool for pretty = printing=20 the
> IANA list, which handled enough of the basics to allow = me=20 to
> use the little time I have these days to add the search =
>=20 functionality on top.
>
> If you have JavaScript = running, you=20 are shown just the tags
> and descriptions initially, but by = clicking=20 on those you can
> reveal all additional information in the = registry=20 for a given
> tag. I also highlight tags that are deprecated, = so you=20 can
> see that straight away.
>
> (PS: Some final = tweaks=20 to the code will come when I have a
> spare moment for things = like=20 making the expanding list more
> accessible, = etc.)
>
>=20 RI
>
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Richard Ishida
>=20 Internationalization Lead
> W3C (World Wide Web=20 Consortium)
>
> http://www.w3.org/People/Ishida= /
>=20 http://www.w3.org/International= /
>=20 http://people.w3.org/rishida/= blog/
>=20 http://www.flickr.com/photo= s/ishida/
>
>
>
>
>
>=20 This email was sent to you by Reuters, the global news and
>=20 information company.
> To find out more about Reuters visit = www.about.reuters.com
>>=20 Any views expressed in this message are those of the
> = individual=20 sender, except where the sender specifically
> states them to = be the=20 views of Reuters Limited.
>
> Reuters Limited is part of = the=20 Reuters Group of companies, of
> which Reuters Group PLC is = the=20 ultimate parent company.
> Reuters Group PLC - Registered = office=20 address: The Reuters
> Building, South Colonnade, Canary = Wharf,=20 London E14 5EP,
> United Kingdom Registered No: 3296375 = Registered in=20 England and=20 = Wales
>
>


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


--
Mark ------=_NextPart_000_0004_01C77AE8.A91EAE30-- --===============0236343334== 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 --===============0236343334==-- From ltru-bounces@ietf.org Wed Apr 11 05:22: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 1HbZ1X-0001RH-46; Wed, 11 Apr 2007 05:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZ1W-0001R1-3e for ltru@ietf.org; Wed, 11 Apr 2007 05:21:54 -0400 Received: from smtp802.mail.ird.yahoo.com ([217.146.188.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbZ1S-0002G2-I0 for ltru@ietf.org; Wed, 11 Apr 2007 05:21:54 -0400 Received: (qmail 80873 invoked from network); 11 Apr 2007 09:21:47 -0000 Received: from unknown (HELO DELL3) (brian.silver@btinternet.com@86.130.238.163 with login) by smtp802.mail.ird.yahoo.com with SMTP; 11 Apr 2007 09:21:47 -0000 X-YMail-OSG: XrzqeDUVM1nMk3tdV1gsbAx0ZckAV.gBSgN8Vgb4QriSdnSjlpXqysi5_ZzXeqzpmIMBD.cfVw-- Message-ID: <002f01c77c1a$d45f0760$0201a8c0@DELL3> From: "Stephen Silver" To: "Addison Phillips" References: <461536E7.3070302@yahoo-inc.com> Subject: Re: [Ltru] draft-04 submitted... Date: Wed, 11 Apr 2007 10:21:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I just submitted draft-04. I noticed a couple of typos: there are two occurrences of "ISO 693-3", which should be "ISO 639-3". -- Stephen Silver _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 11 17:19: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 1HbkEF-0001Vh-UE; Wed, 11 Apr 2007 17:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkEE-0001Vb-UH for ltru@ietf.org; Wed, 11 Apr 2007 17:19:47 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbkE9-0006e1-Fu for ltru@ietf.org; Wed, 11 Apr 2007 17:19:46 -0400 Received: by nz-out-0506.google.com with SMTP id z6so267865nzd for ; Wed, 11 Apr 2007 14:19:41 -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=ZvcIcH2+s5uYNMbi1zDluC/3Yh5a7Gog4t+373d/ebiQ5JN6qz9jHudIynS3Gq9qeHBpT9g+Q9lCoeQOgUp4uMICGgav5bGFsTds6IN8lm8QS20cPcMjgD+Xzn0M1R9WDtzSTna8UsT1zVYsTdXnFtge0Gj/jntL6nNWnPi2c8E= 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=PF7WwYd2IT0OIc6/PcGm2az3h/FUBRelN2T6/YmKga4llOzrCQICOy3gbeU1E4cIKX7EcLbzGJhl1AQw4ZPA6fR/YYSMyXM4j/jCbPTtH44uxBJneHCxQK+JnEWbwgd+g2M6oSXmp2kQse1nzAp42zCla3ZOierbW3uEiemwY2M= Received: by 10.114.197.1 with SMTP id u1mr454380waf.1176326380449; Wed, 11 Apr 2007 14:19:40 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 11 Apr 2007 14:19:40 -0700 (PDT) Message-ID: <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> Date: Wed, 11 Apr 2007 14:19:40 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <20070411202427.GH29567@mercury.ccil.org> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> X-Google-Sender-Auth: 697cc43976945cf3 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: LTRU Working Group , CE Whitehead , www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1563261653==" Errors-To: ltru-bounces@ietf.org --===============1563261653== Content-Type: multipart/alternative; boundary="----=_Part_22034_2974923.1176326380356" ------=_Part_22034_2974923.1176326380356 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Your conclusion from 639-2 I find extremely odd, since "zxx" is ALSO in a column that says "English name of language", so by your logic, "zxx" is also a language, just one with no linguistic content. What we have here is not a definitive situation, just a conflict between two standards, 639-3 and 639-2. And the important thing for xml:lang is BCP 47, which is based on 639-2. Reinterpreting "und" as being *only somewhat unknown* (that is, that it can't correctly be applied to non-linguistic content, even if you don't know that that content is non-linguistic) is definitely a breaking change for many applications, and I would be strongly opposed to making that change in BCP 47. In the real world, it is often very difficult or impossible to tell whether content is in an unknown language or whether the content is not in any language at all. Saying that an implementation or protocol is not compliant if it doesn't correctly make this determination is bizarre. What we have done in BCP 47 is to say that if the protocol allows it, then one should omit the language code entirely; otherwise one can use "und". CCing the LTRU group, since this is relevant to the next version of BCP 47. Mark On 4/11/07, John Cowan wrote: > > Mark Davis scripsit: > > > I believe that that is adding an interpretation to "und" which is not > > borne out by either the source standards, nor in common usage. > > ISO 639-2 says merely "Undetermined", but this is placed in a column > labeled "English name of language", so I think it's fair to read it > as "Undetermined language". But ISO 639-3 is, I think, definitive. > http://www.sil.org/iso639-3/scope.asp#S says (in part): > > The identifier [und] (undetermined) is provided for those > situations in which a language or languages must be indicated > but the *language* cannot be identified [emphasis added]. > > By contrast, "zxx" is explained in the next sentence thus: > > The identifier [zxx] (no linguistic content) may be applied in a > situation in which a language identifier is required by system > definition, but the item being described does not actually > contain linguistic content. > > In any case, the document I'm commenting on says that "zxx" is > non-linguistic content, and that "und" and "" are synonymous and > represent linguistic content. Whatever "und" may or may not mean, > I think there's no doubt that "" can be applied to both linguistic > and non-linguistic content. > > -- > You escaped them by the will-death John Cowan > and the Way of the Black Wheel. cowan@ccil.org > I could not. --Great-Souled Sam http://www.ccil.org/~cowan > -- Mark ------=_Part_22034_2974923.1176326380356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Your conclusion from 639-2 I find extremely odd, since "zxx" is ALSO in a column that says "English name of language", so by your logic, "zxx" is also a language, just one with no linguistic content. What we have here is not a definitive situation, just a conflict between two standards, 639-3 and 639-2. And the important thing for xml:lang is BCP 47, which is based on 639-2. Reinterpreting "und" as being *only somewhat unknown* (that is, that it can't correctly be applied to non-linguistic content, even if you don't know that that content is non-linguistic) is definitely a breaking change for many applications, and I would be strongly opposed to making that change in BCP 47.

In the real world, it is often very difficult or impossible to tell whether content is in an unknown language or whether the content is not in any language at all. Saying that an implementation or protocol is not compliant if it doesn't correctly make this determination is bizarre. What we have done in BCP 47 is to say that if the protocol allows it, then one should omit the language code entirely; otherwise one can use "und".

CCing the LTRU group, since this is relevant to the next version of BCP 47.

Mark

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

> I believe that that is adding an interpretation to "und" which is not
> borne out by either the source standards, nor in common usage.

ISO 639-2 says merely "Undetermined", but this is placed in a column
labeled "English name of language", so I think it's fair to read it
as "Undetermined language".  But ISO 639-3 is, I think, definitive.
http://www.sil.org/iso639-3/scope.asp#S says (in part):

        The identifier [und] (undetermined) is provided for those
        situations in which a language or languages must be indicated
        but the *language* cannot be identified [emphasis added].

By contrast, "zxx" is explained in the next sentence thus:

        The identifier [zxx] (no linguistic content) may be applied in a
        situation in which a language identifier is required by system
        definition, but the item being described does not actually
        contain linguistic content.

In any case, the document I'm commenting on says that "zxx" is
non-linguistic content, and that "und" and "" are synonymous and
represent linguistic content.  Whatever "und" may or may not mean,
I think there's no doubt that "" can be applied to both linguistic
and non-linguistic content.

--
You escaped them by the will-death              John Cowan
and the Way of the Black Wheel.                 cowan@ccil.org
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan



--
Mark ------=_Part_22034_2974923.1176326380356-- --===============1563261653== 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 --===============1563261653==-- From ltru-bounces@ietf.org Wed Apr 11 17:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkXI-0003Zs-7l; Wed, 11 Apr 2007 17:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkXG-0003Zl-Tq for ltru@ietf.org; Wed, 11 Apr 2007 17:39:27 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbkXF-00014k-N4 for ltru@ietf.org; Wed, 11 Apr 2007 17:39:26 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HbkX3-00034v-00; Wed, 11 Apr 2007 17:39:13 -0400 Date: Wed, 11 Apr 2007 17:39:12 -0400 To: Mark Davis Message-ID: <20070411213912.GB2656@mercury.ccil.org> References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group , CE Whitehead , www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Your conclusion from 639-2 I find extremely odd, since "zxx" is ALSO > in a column that says "English name of language", so by your logic, > "zxx" is also a language, just one with no linguistic content. Bah. I'll go no further with this. My basic point remains: whatever "und" means, "" can't mean "language is unknown", since it's equally suitable for non-linguistic content. XSLT documents don't have xml:lang attributes, but if they did, "" would be a sensible value. -- BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 11 18:52: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 1HblgF-0005cF-Ob; Wed, 11 Apr 2007 18:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HblgD-0005c9-KM for ltru@ietf.org; Wed, 11 Apr 2007 18:52:45 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HblgC-0005de-C0 for ltru@ietf.org; Wed, 11 Apr 2007 18:52:45 -0400 Received: by nz-out-0506.google.com with SMTP id z6so289319nzd for ; Wed, 11 Apr 2007 15:52:44 -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=p3zbrBhVhuTr7PsCQY9qkR9xcDFBRxlzoRB6g/3VcHbjkqFIXDyJqmE6cSakCaQJIkhmmQs6p99GtIX9UtU/Xb7zXVIGQq66la/Vr4CcTLag+YkJz0OAbr0p4pIy35Q9gHTNL+WIoNWEeQpJpQ6LyClxu0GHZpmwPS05NafzjQ0= 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=PEGCvGcAsWUDZJsunzWgw3cga621W5yQMbCIBcVYUbiLF9Tc2b51WO2o8Mggoaj6HcD1FrKVm5oyQ5sFlr7/bBSnLQC2DmyR7e7uAhjBvxWCjmZh08JSylbddNnjMKWgLsqVRASWh8BDf7A+9RQ9thWxoiD6fT7NfKCv9kZe+Ak= Received: by 10.115.58.1 with SMTP id l1mr488576wak.1176331963751; Wed, 11 Apr 2007 15:52:43 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 11 Apr 2007 15:52:43 -0700 (PDT) Message-ID: <30b660a20704111552n7f8eca5cp1640a95c77e8e0ad@mail.gmail.com> Date: Wed, 11 Apr 2007 15:52:43 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <20070411213912.GB2656@mercury.ccil.org> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> <20070411213912.GB2656@mercury.ccil.org> X-Google-Sender-Auth: 2c89b504ca27cc82 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: LTRU Working Group , CE Whitehead , www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0450899914==" Errors-To: ltru-bounces@ietf.org --===============0450899914== Content-Type: multipart/alternative; boundary="----=_Part_23682_12905645.1176331963673" ------=_Part_23682_12905645.1176331963673 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that "" should be treated as a sensible value, with the same meaning as "und"; that is, an undetermined / unspecified value. Mark On 4/11/07, John Cowan wrote: > > Mark Davis scripsit: > > > Your conclusion from 639-2 I find extremely odd, since "zxx" is ALSO > > in a column that says "English name of language", so by your logic, > > "zxx" is also a language, just one with no linguistic content. > > Bah. I'll go no further with this. My basic point remains: > whatever "und" means, "" can't mean "language is unknown", since it's > equally suitable for non-linguistic content. XSLT documents don't > have xml:lang attributes, but if they did, "" would be a sensible value. > > -- > BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org > BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan > -- Mark ------=_Part_23682_12905645.1176331963673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that "" should be treated as a sensible value, with the same meaning as "und"; that is, an undetermined / unspecified value.

Mark

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

> Your conclusion from 639-2 I find extremely odd, since "zxx" is ALSO
> in a column that says "English name of language", so by your logic,
> "zxx" is also a language, just one with no linguistic content.

Bah.  I'll go no further with this.  My basic point remains:
whatever "und" means, "" can't mean "language is unknown", since it's
equally suitable for non-linguistic content.  XSLT documents don't
have xml:lang attributes, but if they did, "" would be a sensible value.

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



--
Mark ------=_Part_23682_12905645.1176331963673-- --===============0450899914== 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 --===============0450899914==-- From ltru-bounces@ietf.org Thu Apr 12 06:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbwpb-0003Qp-4P; Thu, 12 Apr 2007 06:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwpY-0003IO-Ou for ltru@ietf.org; Thu, 12 Apr 2007 06:47:08 -0400 Received: from mail.arena1.com ([63.116.216.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbwpX-0006R2-Fp for ltru@ietf.org; Thu, 12 Apr 2007 06:47:08 -0400 Received: from UnknownHost [83.70.80.115] by mail.arena1.com with SMTP; Thu, 12 Apr 2007 06:46:50 -0400 Message-ID: <461E0DE9.6080304@hackcraft.net> Date: Thu, 12 Apr 2007 11:46:01 +0100 From: Jon Hanna User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: www-international@w3.org, LTRU Working Group References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> <20070411213912.GB2656@mercury.ccil.org> <30b660a20704111552n7f8eca5cp1640a95c77e8e0ad@mail.gmail.com> In-Reply-To: <30b660a20704111552n7f8eca5cp1640a95c77e8e0ad@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [83.70.80.115] X-Declude-Spoolname: 2102425255625.eml X-Declude-RefID: X-Declude-Note: Scanned by Declude 4.3.14 for spam. "http://www.declude.com/x-note.htm" X-Declude-Scan: Score [4] at 06:46:59 on 12 Apr 2007 X-Declude-Fail: Whitelisted X-Country-Chain: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To say that UND cannot apply to an item which *may* contain no linguistic data seems to be putting a bit of a limit on what "Undetermined" means. "Determined to be some sort of language, but just which language remains undetermined" is not the same as "undetermined". That cat is neither dead or alive. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 06: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 1Hbwpp-0003TZ-8m; Thu, 12 Apr 2007 06:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbwpn-0003TP-JH for ltru@ietf.org; Thu, 12 Apr 2007 06:47:23 -0400 Received: from mail.arena1.com ([63.116.216.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbwpm-0006T9-Cl for ltru@ietf.org; Thu, 12 Apr 2007 06:47:23 -0400 Received: from UnknownHost [83.70.80.115] by mail.arena1.com with SMTP; Thu, 12 Apr 2007 06:47:06 -0400 Message-ID: <461E0DF9.1080904@hackcraft.net> Date: Thu, 12 Apr 2007 11:46:17 +0100 From: Jon Hanna User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: www-international@w3.org, LTRU Working Group References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <30b660a20704111419o6d3bf87av85c6236fe687b9c5@mail.gmail.com> <20070411213912.GB2656@mercury.ccil.org> <30b660a20704111552n7f8eca5cp1640a95c77e8e0ad@mail.gmail.com> In-Reply-To: <30b660a20704111552n7f8eca5cp1640a95c77e8e0ad@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [83.70.80.115] X-Declude-Spoolname: 2102425255634.eml X-Declude-RefID: X-Declude-Note: Scanned by Declude 4.3.14 for spam. "http://www.declude.com/x-note.htm" X-Declude-Scan: Score [4] at 06:47:14 on 12 Apr 2007 X-Declude-Fail: Whitelisted X-Country-Chain: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To say that UND cannot apply to an item which *may* contain no linguistic data seems to be putting a bit of a limit on what "Undetermined" means. "Determined to be some sort of language, but just which language remains undetermined" is not the same as "undetermined". That cat is neither dead or alive until determined to be one or the other. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 10:34: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 1Hc0Nk-0000X4-58; Thu, 12 Apr 2007 10:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0Ni-0000Wl-RH for ltru@ietf.org; Thu, 12 Apr 2007 10:34:38 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc0Ng-0005wC-9q for ltru@ietf.org; Thu, 12 Apr 2007 10:34:38 -0400 Received: from rishida (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 4782A4EEB7; Thu, 12 Apr 2007 10:34:35 -0400 (EDT) From: "Richard Ishida" To: , "'LTRU Working Group'" References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> Date: Thu, 12 Apr 2007 15:35:15 +0100 Message-ID: <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <017101c77d0a$47c31260$6601a8c0@rishida> Thread-Index: Acd8d8TqHb7gjbNlREK7lTfPVNbjigAgvA4wAASuPhA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [Ltru] RE: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ok, I just found some additional emails between John and Mark that had been scooped into my LTRU folder by my mail client because [LTRU] was prepended to the subject. They shift the baseline for discussion and agreement. What I now see as the summary of where we are is: [a] Determined, and a language (for which a subtag exists): [b] Determined, and not a language: zxx [c] Determined, but not a language for which a subtag exists: ??? [d] Undetermined, and not sure whether it is a language or not: xml:lang="" if available, otherwise und I have revised the article at [1] to make it clearer that whether text is linguistic or not is unimportant wrt use of '' and und. I'm still troubled however by the passage in RFC 4646, however, so I'll repeat those comments here and copy the LTRU folks: I'm also a little worried about the wording in section 4.1 of RFC 4646[2] about und, which quite clearly says that you shouldn't use und unless the *protocol* demands it, or sometimes when matching tags. This doesn't make any distinction between specifying the language of a resource and turning off language declarations for a range of embedded text. It seems that this suggests a way in which xml:lang='' and xml:lang="und" are not equivalent, since there are no such restrictions on xml:lang="". In my opinion, the text of RFC 4646 needs some work, both to relax the use of und in scenarios where 'undefined text' occurs in a context with a defined language, and to clarify the relationship of und to xml:lang=''. RI [1] http://www.w3.org/International/questions/qa-no-language#answer [2] http://www.rfc-editor.org/rfc/rfc4646.txt ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > Sent: 12 April 2007 14:56 > To: www-international@w3.org > Subject: RE: For review: Tagging text with no language > > > So it seems the alternatives that John is suggesting are: > > Determined, and a language (for which a subtag exists): > Determined, and not a language: zxx > Determined, but not a language for which a subtag exists: ??? > > Undetermined, and not sure whether it is a language or not: > xml:lang="" (if > available) > Undetermined, but sure that it's a language: und > > The implications of this for X/HTML are that there is no way > to say that > text is undetermined if you are not sure whether it's a > language or not. > > This is very different from Jon Hanna's proposal at > http://lists.w3.org/Archives/Public/www-international/2007JanM ar/0178.html > > Can we please discuss this. I'm particularly hoping for > contributions from > John, Jon, Mark, Martin and Addison (though he's on vacation > at the moment). > > For my part, having experienced, even when trying to write > this email, how > difficult it is to succinctly talk about the difference > between something > that is unidentified and may or may not be a language, I'm a > little leery > about accepting the evidence in the mail below, John. Can we > be sure that > the people who drafted that text were conciously making the > distinction you > mention rather than just being a little imprecise in wording? > > I'm also a little worried about the wording in section 4.1 of > RFC 4646[1] > about und, which quite clearly says that you shouldn't use > und unless the > *protocol* demands it, or sometimes when matching tags. This > doesn't make > any distinction between specifying the language of a resource > and turning > off language declarations for a range of embedded text. It > seems that this > suggests another way in which xml:lang='' and xml:lang="und" are not > equivalent. In my opinion, either the text of RFC 4646 needs > some work, > either to relax the use of und in scenarios where undefined > text occurs in a > context that is defined, or to clarify the relationship of und to > xml:lang=''. > > RI > > > [1] http://www.rfc-editor.org/rfc/rfc4646.txt > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > -----Original Message----- > > From: www-international-request@w3.org > > [mailto:www-international-request@w3.org] On Behalf Of John Cowan > > Sent: 11 April 2007 21:24 > > To: Mark Davis > > Cc: John Cowan; CE Whitehead; www-international@w3.org > > Subject: Re: For review: Tagging text with no language > > > > > > Mark Davis scripsit: > > > > > I believe that that is adding an interpretation to "und" > > which is not > > > borne out by either the source standards, nor in common usage. > > > > ISO 639-2 says merely "Undetermined", but this is placed in a > > column labeled "English name of language", so I think it's > > fair to read it as "Undetermined language". But ISO 639-3 > > is, I think, definitive. > > http://www.sil.org/iso639-3/scope.asp#S says (in part): > > > > The identifier [und] (undetermined) is provided for those > > situations in which a language or languages must be indicated > > but the *language* cannot be identified [emphasis added]. > > > > By contrast, "zxx" is explained in the next sentence thus: > > > > The identifier [zxx] (no linguistic content) may be applied in a > > situation in which a language identifier is required by system > > definition, but the item being described does not actually > > contain linguistic content. > > > > In any case, the document I'm commenting on says that "zxx" > > is non-linguistic content, and that "und" and "" are > > synonymous and represent linguistic content. Whatever "und" > > may or may not mean, I think there's no doubt that "" can be > > applied to both linguistic and non-linguistic content. > > > > -- > > You escaped them by the will-death John Cowan > > and the Way of the Black Wheel. cowan@ccil.org > > I could not. --Great-Souled Sam > > http://www.ccil.org/~cowan > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 12:13: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 1Hc1v9-00076h-2f; Thu, 12 Apr 2007 12:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1v7-00076Q-SR for ltru@ietf.org; Thu, 12 Apr 2007 12:13:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc1v4-0005f3-SN for ltru@ietf.org; Thu, 12 Apr 2007 12:13:13 -0400 Received: by nz-out-0506.google.com with SMTP id z6so526140nzd for ; Thu, 12 Apr 2007 09:13:10 -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=AcN36Zd0f1UaIPPEC2DFbK/RfvdX0vgSx9DvfOK1q0aXCKzEyj67bcH3N+nl2v3h+yYZO6wctKZZPhtrPTUyXa6hrMC8Cbbbgpnls1WMg/C/0GdcD079JpYyzh7TjNIFOcsB1pQlaA3CSxvilxWPRoTxKqH8l8B7KPePfEcBt3I= 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=LTrKI4c4dyLkUAju3gwDY4hAaFPflwJVrq6Mo8+yQgs9j9CG+Od9+6MKHz8t+QWOkA9mvh534O5pVROC31Y5RbSMkVLJdbhDMxvXYPjYkkWWnETKDTXfm78h774iBgD3CP3JyeakI4gd647clevaU0GZvo8nrhYSyZbRPVUG7xE= Received: by 10.114.208.8 with SMTP id f8mr804277wag.1176394389669; Thu, 12 Apr 2007 09:13:09 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 09:13:09 -0700 (PDT) Message-ID: <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> Date: Thu, 12 Apr 2007 09:13:09 -0700 From: "Mark Davis" To: "Richard Ishida" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> X-Google-Sender-Auth: 4e0347d5af339a55 X-Spam-Score: 0.1 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: LTRU Working Group , www-international@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1424531130==" Errors-To: ltru-bounces@ietf.org --===============1424531130== Content-Type: multipart/alternative; boundary="----=_Part_38987_24800773.1176394389489" ------=_Part_38987_24800773.1176394389489 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The summary looks good. This discussion raises 2 items for the LTRU group. Q1. What tag should be used where it is definitely a language, but there is no code available yet? (This is an area where ISO 15924 is ahead of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) Q2. Clarify the wording around "und" vs "". Mark On 4/12/07, Richard Ishida wrote: > > Ok, I just found some additional emails between John and Mark that had > been > scooped into my LTRU folder by my mail client because [LTRU] was prepended > to the subject. They shift the baseline for discussion and agreement. > > What I now see as the summary of where we are is: > > [a] Determined, and a language (for which a subtag exists): > > [b] Determined, and not a language: zxx > > [c] Determined, but not a language for which a subtag exists: ??? > > [d] Undetermined, and not sure whether it is a language or not: > xml:lang="" > if available, otherwise und > > I have revised the article at [1] to make it clearer that whether text is > linguistic or not is unimportant wrt use of '' and und. > > > I'm still troubled however by the passage in RFC 4646, however, so I'll > repeat those comments here and copy the LTRU folks: > > I'm also a little worried about the wording in section 4.1 of RFC 4646[2] > about und, which quite clearly says that you shouldn't use und unless the > *protocol* demands it, or sometimes when matching tags. This doesn't make > any distinction between specifying the language of a resource and turning > off language declarations for a range of embedded text. It seems that > this > suggests a way in which xml:lang='' and xml:lang="und" are not equivalent, > since there are no such restrictions on xml:lang="". In my opinion, the > text > of RFC 4646 needs some work, both to relax the use of und in scenarios > where > 'undefined text' occurs in a context with a defined language, and to > clarify > the relationship of und to xml:lang=''. > > RI > > [1] http://www.w3.org/International/questions/qa-no-language#answer > > [2] http://www.rfc-editor.org/rfc/rfc4646.txt > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > > -----Original Message----- > > From: www-international-request@w3.org > > [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida > > Sent: 12 April 2007 14:56 > > To: www-international@w3.org > > Subject: RE: For review: Tagging text with no language > > > > > > So it seems the alternatives that John is suggesting are: > > > > Determined, and a language (for which a subtag exists): > > Determined, and not a language: zxx > > Determined, but not a language for which a subtag exists: ??? > > > > Undetermined, and not sure whether it is a language or not: > > xml:lang="" (if > > available) > > Undetermined, but sure that it's a language: und > > > > The implications of this for X/HTML are that there is no way > > to say that > > text is undetermined if you are not sure whether it's a > > language or not. > > > > This is very different from Jon Hanna's proposal at > > http://lists.w3.org/Archives/Public/www-international/2007JanM > ar/0178.html > > > > Can we please discuss this. I'm particularly hoping for > > contributions from > > John, Jon, Mark, Martin and Addison (though he's on vacation > > at the moment). > > > > For my part, having experienced, even when trying to write > > this email, how > > difficult it is to succinctly talk about the difference > > between something > > that is unidentified and may or may not be a language, I'm a > > little leery > > about accepting the evidence in the mail below, John. Can we > > be sure that > > the people who drafted that text were conciously making the > > distinction you > > mention rather than just being a little imprecise in wording? > > > > I'm also a little worried about the wording in section 4.1 of > > RFC 4646[1] > > about und, which quite clearly says that you shouldn't use > > und unless the > > *protocol* demands it, or sometimes when matching tags. This > > doesn't make > > any distinction between specifying the language of a resource > > and turning > > off language declarations for a range of embedded text. It > > seems that this > > suggests another way in which xml:lang='' and xml:lang="und" are not > > equivalent. In my opinion, either the text of RFC 4646 needs > > some work, > > either to relax the use of und in scenarios where undefined > > text occurs in a > > context that is defined, or to clarify the relationship of und to > > xml:lang=''. > > > > RI > > > > > > [1] http://www.rfc-editor.org/rfc/rfc4646.txt > > > > ============ > > Richard Ishida > > Internationalization Lead > > W3C (World Wide Web Consortium) > > > > http://www.w3.org/People/Ishida/ > > http://www.w3.org/International/ > > http://people.w3.org/rishida/blog/ > > http://www.flickr.com/photos/ishida/ > > > > > > > > > -----Original Message----- > > > From: www-international-request@w3.org > > > [mailto:www-international-request@w3.org] On Behalf Of John Cowan > > > Sent: 11 April 2007 21:24 > > > To: Mark Davis > > > Cc: John Cowan; CE Whitehead; www-international@w3.org > > > Subject: Re: For review: Tagging text with no language > > > > > > > > > Mark Davis scripsit: > > > > > > > I believe that that is adding an interpretation to "und" > > > which is not > > > > borne out by either the source standards, nor in common usage. > > > > > > ISO 639-2 says merely "Undetermined", but this is placed in a > > > column labeled "English name of language", so I think it's > > > fair to read it as "Undetermined language". But ISO 639-3 > > > is, I think, definitive. > > > http://www.sil.org/iso639-3/scope.asp#S says (in part): > > > > > > The identifier [und] (undetermined) is provided for those > > > situations in which a language or languages must be indicated > > > but the *language* cannot be identified [emphasis added]. > > > > > > By contrast, "zxx" is explained in the next sentence thus: > > > > > > The identifier [zxx] (no linguistic content) may be applied in a > > > situation in which a language identifier is required by system > > > definition, but the item being described does not actually > > > contain linguistic content. > > > > > > In any case, the document I'm commenting on says that "zxx" > > > is non-linguistic content, and that "und" and "" are > > > synonymous and represent linguistic content. Whatever "und" > > > may or may not mean, I think there's no doubt that "" can be > > > applied to both linguistic and non-linguistic content. > > > > > > -- > > > You escaped them by the will-death John Cowan > > > and the Way of the Black Wheel. cowan@ccil.org > > > I could not. --Great-Souled Sam > > > http://www.ccil.org/~cowan > > > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_38987_24800773.1176394389489 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The summary looks good. This discussion raises 2 items for the LTRU group.

Q1. What tag should be used where it is definitely a language, but there is no code available yet? (This is an area where ISO 15924 is ahead of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.)

Q2. Clarify the wording around "und" vs "".

Mark

On 4/12/07, Richard Ishida <ishida@w3.org > wrote:
Ok, I just found some additional emails between John and Mark that had been
scooped into my LTRU folder by my mail client because [LTRU] was prepended
to the subject. They shift the baseline for discussion and agreement.

What I now see as the summary of where we are is:

[a] Determined, and a language (for which a subtag exists): <subtag(s)>

[b] Determined, and not a language: zxx

[c] Determined, but not a language for which a subtag exists: ???

[d] Undetermined, and not sure whether it is a language or not: xml:lang=""
if available, otherwise und

I have revised the article at [1] to make it clearer that whether text is
linguistic or not is unimportant wrt use of '' and und.


I'm still troubled however by the passage in RFC 4646, however, so I'll
repeat those comments here and copy the LTRU folks:

I'm also a little worried about the wording in section 4.1 of RFC 4646[2]
about und, which quite clearly says that you shouldn't use und unless the
*protocol* demands it, or sometimes when matching tags.  This doesn't make
any distinction between specifying the language of a resource and turning
off language declarations for a range of embedded text.  It seems that this
suggests a way in which xml:lang='' and xml:lang="und" are not equivalent,
since there are no such restrictions on xml:lang="". In my opinion, the text
of RFC 4646 needs some work, both to relax the use of und in scenarios where
'undefined text' occurs in a context with a defined language, and to clarify
the relationship of und to xml:lang=''.

RI

[1] http://www.w3.org/International/questions/qa-no-language#answer

[2] http://www.rfc-editor.org/rfc/rfc4646.txt

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/



> -----Original Message-----
> From: www-international-request@w3.org
> [mailto:www-international-request@w3.org] On Behalf Of Richard Ishida
> Sent: 12 April 2007 14:56
> To: www-international@w3.org
> Subject: RE: For review: Tagging text with no language
>
>
> So it seems the alternatives that John is suggesting are:
>
> Determined, and a language (for which a subtag exists): <subtag(s)>
> Determined, and not a language: zxx
> Determined, but not a language for which a subtag exists: ???
>
> Undetermined, and not sure whether it is a language or not:
> xml:lang="" (if
> available)
> Undetermined, but sure that it's a language: und
>
> The implications of this for X/HTML are that there is no way
> to say that
> text is undetermined if you are not sure whether it's a
> language or not.
>
> This is very different from Jon Hanna's proposal at
> http://lists.w3.org/Archives/Public/www-international/2007JanM
ar/0178.html
>
> Can we please discuss this.  I'm particularly hoping for
> contributions from
> John, Jon, Mark, Martin and Addison (though he's on vacation
> at the moment).
>
> For my part, having experienced, even when trying to write
> this email, how
> difficult it is to succinctly talk about the difference
> between something
> that is unidentified and may or may not be a language, I'm a
> little leery
> about accepting the evidence in the mail below, John.  Can we
> be sure that
> the people who drafted that text were conciously making the
> distinction you
> mention rather than just being a little imprecise in wording?
>
> I'm also a little worried about the wording in section 4.1 of
> RFC 4646[1]
> about und, which quite clearly says that you shouldn't use
> und unless the
> *protocol* demands it, or sometimes when matching tags.  This
> doesn't make
> any distinction between specifying the language of a resource
> and turning
> off language declarations for a range of embedded text.  It
> seems that this
> suggests another way in which xml:lang='' and xml:lang="und" are not
> equivalent. In my opinion, either the text of RFC 4646 needs
> some work,
> either to relax the use of und in scenarios where undefined
> text occurs in a
> context that is defined, or to clarify the relationship of und to
> xml:lang=''.
>
> RI
>
>
> [1] http://www.rfc-editor.org/rfc/rfc4646.txt
>
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
>
> http://www.w3.org/People/Ishida/
> http://www.w3.org/International/
> http://people.w3.org/rishida/blog/
> http://www.flickr.com/photos/ishida/
>
>
>
> > -----Original Message-----
> > From: www-international-request@w3.org
> > [mailto: www-international-request@w3.org] On Behalf Of John Cowan
> > Sent: 11 April 2007 21:24
> > To: Mark Davis
> > Cc: John Cowan; CE Whitehead; www-international@w3.org
> > Subject: Re: For review: Tagging text with no language
> >
> >
> > Mark Davis scripsit:
> >
> > > I believe that that is adding an interpretation to "und"
> > which is not
> > > borne out by either the source standards, nor in common usage.
> >
> > ISO 639-2 says merely "Undetermined", but this is placed in a
> > column labeled "English name of language", so I think it's
> > fair to read it as "Undetermined language".  But ISO 639-3
> > is, I think, definitive.
> > http://www.sil.org/iso639-3/scope.asp#S says (in part):
> >
> >     The identifier [und] (undetermined) is provided for those
> >     situations in which a language or languages must be indicated
> >     but the *language* cannot be identified [emphasis added].
> >
> > By contrast, "zxx" is explained in the next sentence thus:
> >
> >     The identifier [zxx] (no linguistic content) may be applied in a
> >     situation in which a language identifier is required by system
> >     definition, but the item being described does not actually
> >     contain linguistic content.
> >
> > In any case, the document I'm commenting on says that "zxx"
> > is non-linguistic content, and that "und" and "" are
> > synonymous and represent linguistic content.  Whatever "und"
> > may or may not mean, I think there's no doubt that "" can be
> > applied to both linguistic and non-linguistic content.
> >
> > --
> > You escaped them by the will-death              John Cowan
> > and the Way of the Black Wheel.                 cowan@ccil.org
> > I could not.  --Great-Souled Sam
> > http://www.ccil.org/~cowan
> >
>
>


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



--
Mark ------=_Part_38987_24800773.1176394389489-- --===============1424531130== 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 --===============1424531130==-- From ltru-bounces@ietf.org Thu Apr 12 13:00: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 1Hc2eg-0007l0-H0; Thu, 12 Apr 2007 13:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2ef-0007hw-EJ for ltru@ietf.org; Thu, 12 Apr 2007 13:00:17 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc2ed-0003vv-SF for ltru@ietf.org; Thu, 12 Apr 2007 13:00:17 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hc2eb-0006jZ-Er; Thu, 12 Apr 2007 13:00:13 -0400 Date: Thu, 12 Apr 2007 13:00:13 -0400 To: Mark Davis Subject: Re: [Ltru] RE: For review: Tagging text with no language Message-ID: <20070412170013.GF16269@mercury.ccil.org> References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: www-international@w3.org, 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: > The summary looks good. This discussion raises 2 items for the LTRU > group. > > Q1. What tag should be used where it is definitely a language, but there > is no code available yet? (This is an area where ISO 15924 is ahead > of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) In principle, every natural-language item (text, audio, video) can be coded with some 639-2 code; if the language does not have a code of its own, it will belong to one of the 639-2 collections. For example, the language Tarifit (639-3 code 'rif') does not have a 639-2 code, but it is a Berber language; consequently, an item in Tarifit may be validly tagged 'ber', which represents the collection of Berber languages. Similarly, the language Zumbun (639-3 code 'jmb') does not have an 639-2 code, nor does it belong to any of the smaller 639-2 collections, but it does belong to the Afro-Asiatic language family; consequently, an item in Zumbun may be validly tagged 'afa', which represents the collection of Afro-Asiatic languages. If all else fails, as for the language isolate Burushaski (639-3 code 'bsk'), the 639-2 collection code 'mis', representing the collection of miscellaneous languages, may be applied. This is the ultimate fallback code, indicating that the language is known but nothing useful can be said about it using 639-2 codes. All of this lore, which represents the practice of the Library of Congress (the ultimate source of 639-2), can of course go away when RFC 4646bis goes into effect. If it is necessary to be more specific before then, and if strict compliance to 4646 is required, then rif-x-tarifit, afa-x-jumbun, and mis-x-burushas may also be used. > Q2. Clarify the wording around "und" vs "". "" is not a well-formed language tag according to RFC 4646, so there is nothing to say about it there. It is defined by the XML Recommendation as an extension to the set of language tags, and having the same significance as no language declaration at all. -- 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 Thu Apr 12 13:12: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 1Hc2qE-0008DN-EU; Thu, 12 Apr 2007 13:12:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2qD-0008DG-5v for ltru@ietf.org; Thu, 12 Apr 2007 13:12:13 -0400 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc2qA-0001JU-TQ for ltru@ietf.org; Thu, 12 Apr 2007 13:12:13 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l3CHAVqB015521 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Apr 2007 13:10:37 -0400 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.102.225] (account martin_hosken@sil.org HELO [192.168.1.101]) by mail.link77.net (CommuniGate Pro SMTP 5.1.7) with ESMTPSA id 142116974; Thu, 12 Apr 2007 13:06:23 -0400 Message-ID: <461E6709.2020601@sil.org> Date: Fri, 13 Apr 2007 00:06:17 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] RE: For review: Tagging text with no language References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> In-Reply-To: <20070412170013.GF16269@mercury.ccil.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group , www-international@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, >> Q1. What tag should be used where it is definitely a language, but there >> is no code available yet? (This is an area where ISO 15924 is ahead >> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) >> A related question is how to tag text that is definitely in a language but I don't know what the language is. (But I might know the script). Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 13:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2wO-0003iR-Vd; Thu, 12 Apr 2007 13:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2wN-0003iM-G4 for ltru@ietf.org; Thu, 12 Apr 2007 13:18:35 -0400 Received: from mail04.svc.cra.dublin.eircom.net ([159.134.118.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hc2wM-00045I-2q for ltru@ietf.org; Thu, 12 Apr 2007 13:18:35 -0400 Received: (qmail 74258 messnum 5266860 invoked from network[194.125.174.79/ts09-079.dublin.indigo.ie]); 12 Apr 2007 17:18:32 -0000 Received: from ts09-079.dublin.indigo.ie (HELO ?194.125.174.79?) (194.125.174.79) by mail04.svc.cra.dublin.eircom.net (qp 74258) with SMTP; 12 Apr 2007 17:18:32 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <461E6709.2020601@sil.org> References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <461E6709.2020601@sil.org> 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: For review: Tagging text with no language Date: Thu, 12 Apr 2007 18:19:49 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Good question, albeit not a new one.:-) mg On 12 Apr 2007, at 17:06, scr=EDobh Martin Hosken: > ... A related question is how to tag text that is definitely in a =20 > language > but I don't know what the language is. (But I might know the script). - - 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 Apr 12 13:23: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 1Hc31M-0005PK-TM; Thu, 12 Apr 2007 13:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc31K-0005P0-T2 for ltru@ietf.org; Thu, 12 Apr 2007 13:23:42 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc31J-00085w-Ko for ltru@ietf.org; Thu, 12 Apr 2007 13:23:42 -0400 Received: by nz-out-0506.google.com with SMTP id z6so551289nzd for ; Thu, 12 Apr 2007 10:23:41 -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=F2MjMKljBU+VqstOBnBu4Cx2xQ+cT8MIsUwuOZGpLjQ5I//b6RfGl+fs0wDJWIlXvEGpZfGFzVgGyMYJuvstseuPa1eSyN/7v15BJm7QofPxMWw/1kLoK6WrZHLDZlcFG8umxSDUCTtCteu7VDBnIp2PUGDX7/9MaIh3j8zCL0w= 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=JSO49z6oKJYPn9bx2ywjcEDzn0zJ/Z5332h3Va+CzHE4YJBRWU+4GGCWyYyK8vAyMXmOFS6BzFAVlnzkOPNGw/rTSk+9/h/r8DZqgFI3x3nRyjddGdMtvCuhjLxSg9W13KHsNU2JGmTyWji0BQnZaorKbvUNS8sKrpYhw3Fkq5o= Received: by 10.114.137.2 with SMTP id k2mr816030wad.1176398620917; Thu, 12 Apr 2007 10:23:40 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 10:23:40 -0700 (PDT) Message-ID: <30b660a20704121023s68658e6at7c08ac65de945e56@mail.gmail.com> Date: Thu, 12 Apr 2007 10:23:40 -0700 From: "Mark Davis" To: "Martin Hosken" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <461E6709.2020601@sil.org> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <461E6709.2020601@sil.org> X-Google-Sender-Auth: 9dde474d82d6d973 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: LTRU Working Group , www-international@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571984234==" Errors-To: ltru-bounces@ietf.org --===============0571984234== Content-Type: multipart/alternative; boundary="----=_Part_40719_25909238.1176398620790" ------=_Part_40719_25909238.1176398620790 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline For that, I'd suggest und-Latn (or whatever the script is). Since only languages would have scripts, that is sufficiently determinate. On 4/12/07, Martin Hosken wrote: > > Dear All, > > >> Q1. What tag should be used where it is definitely a language, but > there > >> is no code available yet? (This is an area where ISO 15924 is ahead > >> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) > >> > > A related question is how to tag text that is definitely in a language > but I don't know what the language is. (But I might know the script). > > Yours, > Martin > > -- Mark ------=_Part_40719_25909238.1176398620790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline For that, I'd suggest und-Latn (or whatever the script is). Since only languages would have scripts, that is sufficiently determinate.

On 4/12/07, Martin Hosken <martin_hosken@sil.org> wrote:
Dear All,

>> Q1. What tag should be used where it is definitely a language, but there
>> is no code available yet? (This is an area where ISO 15924 is ahead
>> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.)
>>

A related question is how to tag text that is definitely in a language
but I don't know what the language is. (But I might know the script).

Yours,
Martin




--
Mark ------=_Part_40719_25909238.1176398620790-- --===============0571984234== 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 --===============0571984234==-- From ltru-bounces@ietf.org Thu Apr 12 13:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc36v-0006sV-6u; Thu, 12 Apr 2007 13:29:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc36u-0006sI-CQ for ltru@ietf.org; Thu, 12 Apr 2007 13:29:28 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hc36m-0003kn-FQ for ltru@ietf.org; Thu, 12 Apr 2007 13:29:28 -0400 Received: from spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) by mail.cs.tut.fi (Postfix) with ESMTP id 323425473; Thu, 12 Apr 2007 20:29:19 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) (amavisd-maia, port 10024) with ESMTP id 28217-01-2; Thu, 12 Apr 2007 20:29:18 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 3513EAEE7; Thu, 12 Apr 2007 20:29:18 +0300 (EEST) Date: Thu, 12 Apr 2007 20:29:18 +0300 (EEST) From: "Jukka K. Korpela" To: LTRU Working Group Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <30b660a20704121023s68658e6at7c08ac65de945e56@mail.gmail.com> Message-ID: References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <461E6709.2020601@sil.org> <30b660a20704121023s68658e6at7c08ac65de945e56@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: www-international@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, 12 Apr 2007, Mark Davis wrote: [ about text that is in unknown language but known script ] > For that, I'd suggest und-Latn (or whatever the script is). Since only > languages would have scripts, that is sufficiently determinate. I'm not so sure about it; it depends on what "script" really means. If the data is "JuUiYTlajUJO", which is not in any language as far as I know, can't we still say that it is in the Latin script? -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 13:29: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 1Hc36w-0006tk-AP; Thu, 12 Apr 2007 13:29:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc36v-0006sQ-1k for ltru@ietf.org; Thu, 12 Apr 2007 13:29:29 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hc36p-0003kw-Vc for ltru@ietf.org; Thu, 12 Apr 2007 13:29:28 -0400 Received: by nz-out-0506.google.com with SMTP id z6so553153nzd for ; Thu, 12 Apr 2007 10:29:21 -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=sPpZg9gHLnI1g20O1zYuN+xHJnoUAUJWEd53sedFMEliGG0L3Hpn1zz4Z6Cw6RopWZP/kBHsPZUyb/KgNWKryV/E/T55BXEtlcL//jIC/UffuBiH9OVAVBmlUhmQZyL8yFRihPnpKxeaOI1fZNIjCwUxZDnEaJxlOxMzaHOWkgY= 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=uCCPEMjk8h4RZd5+XH28XDu0KHk8sL/RZpe4JgpRHw5/126ZWaOSs8Z1P2t0Mcj8bwxtsfbDeB01oLWjzpF5EL/cC8cqt7L0GsQx3rgxtqxwU6qliO0JmRQIVhUuWkygwcAwXglnMmqGW0e3B3AnYGP32sOe/5KLKedyHobHQLo= Received: by 10.114.151.13 with SMTP id y13mr821142wad.1176398960780; Thu, 12 Apr 2007 10:29:20 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 10:29:20 -0700 (PDT) Message-ID: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> Date: Thu, 12 Apr 2007 10:29:20 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <20070412170013.GF16269@mercury.ccil.org> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> X-Google-Sender-Auth: 59d017876091d2b2 X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: www-international@w3.org, 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="===============1761267969==" Errors-To: ltru-bounces@ietf.org --===============1761267969== Content-Type: multipart/alternative; boundary="----=_Part_40931_26873443.1176398960697" ------=_Part_40931_26873443.1176398960697 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Q1. I had missed the choice of "mis". I agree with that suggestion; we should incorporate that into 4646bis. The problem is ameliorated considerably once we add -3, but it doesn't disappear completely, so "mis" remains a good choice for dealing with that situation. Q2. The issue *does* remain, since we talk about "und" vs the absence of a language tag, which "" represents. Mark On 4/12/07, John Cowan wrote: > > Mark Davis scripsit: > > > The summary looks good. This discussion raises 2 items for the LTRU > > group. > > > > Q1. What tag should be used where it is definitely a language, but there > > is no code available yet? (This is an area where ISO 15924 is ahead > > of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) > > In principle, every natural-language item (text, audio, video) can be > coded with some 639-2 code; if the language does not have a code of its > own, it will belong to one of the 639-2 collections. > > For example, the language Tarifit (639-3 code 'rif') does not have a 639-2 > code, but it is a Berber language; consequently, an item in Tarifit may be > validly tagged 'ber', which represents the collection of Berber languages. > Similarly, the language Zumbun (639-3 code 'jmb') does not have an 639-2 > code, nor does it belong to any of the smaller 639-2 collections, but it > does belong to the Afro-Asiatic language family; consequently, an item > in Zumbun may be validly tagged 'afa', which represents the collection > of Afro-Asiatic languages. > > If all else fails, as for the language isolate Burushaski (639-3 code > 'bsk'), the 639-2 collection code 'mis', representing the collection of > miscellaneous languages, may be applied. This is the ultimate fallback > code, indicating that the language is known but nothing useful can be > said about it using 639-2 codes. > > All of this lore, which represents the practice of the Library of Congress > (the ultimate source of 639-2), can of course go away when RFC 4646bis > goes into effect. If it is necessary to be more specific before then, > and if strict compliance to 4646 is required, then rif-x-tarifit, > afa-x-jumbun, and mis-x-burushas may also be used. > > > Q2. Clarify the wording around "und" vs "". > > "" is not a well-formed language tag according to RFC 4646, so there is > nothing to say about it there. It is defined by the XML Recommendation as > an extension to the set of language tags, and having the same significance > as no language declaration at all. > > -- > Dream projects long deferred John Cowan > usually bite the wax tadpole. http://www.ccil.org/~cowan > --James Lileks > -- Mark ------=_Part_40931_26873443.1176398960697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Q1. I had missed the choice of "mis". I agree with that suggestion; we should incorporate that into 4646bis. The problem is ameliorated considerably once we add -3, but it doesn't disappear completely, so "mis" remains a good choice for dealing with that situation.

Q2. The issue *does* remain, since we talk about "und" vs the absence of a language tag, which "" represents.

Mark

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

> The summary looks good. This discussion raises 2 items for the LTRU
> group.
>
> Q1. What tag should be used where it is definitely a language, but there
> is no code available yet? (This is an area where ISO 15924 is ahead
> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.)

In principle, every natural-language item (text, audio, video) can be
coded with some 639-2 code; if the language does not have a code of its
own, it will belong to one of the 639-2 collections.

For example, the language Tarifit (639-3 code 'rif') does not have a 639-2
code, but it is a Berber language; consequently, an item in Tarifit may be
validly tagged 'ber', which represents the collection of Berber languages.
Similarly, the language Zumbun (639-3 code 'jmb') does not have an 639-2
code, nor does it belong to any of the smaller 639-2 collections, but it
does belong to the Afro-Asiatic language family; consequently, an item
in Zumbun may be validly tagged 'afa', which represents the collection
of Afro-Asiatic languages.

If all else fails, as for the language isolate Burushaski (639-3 code
'bsk'), the 639-2 collection code 'mis', representing the collection of
miscellaneous languages, may be applied.  This is the ultimate fallback
code, indicating that the language is known but nothing useful can be
said about it using 639-2 codes.

All of this lore, which represents the practice of the Library of Congress
(the ultimate source of 639-2), can of course go away when RFC 4646bis
goes into effect.  If it is necessary to be more specific before then,
and if strict compliance to 4646 is required, then rif-x-tarifit,
afa-x-jumbun, and mis-x-burushas may also be used.

> Q2. Clarify the wording around "und" vs "".

"" is not a well-formed language tag according to RFC 4646, so there is
nothing to say about it there.  It is defined by the XML Recommendation as
an extension to the set of language tags, and having the same significance
as no language declaration at all.

--
Dream projects long deferred             John Cowan < cowan@ccil.org>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
        --James Lileks



--
Mark ------=_Part_40931_26873443.1176398960697-- --===============1761267969== 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 --===============1761267969==-- From ltru-bounces@ietf.org Thu Apr 12 13:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3BX-0003U9-Pm; Thu, 12 Apr 2007 13:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3BX-0003U4-Fl for ltru@ietf.org; Thu, 12 Apr 2007 13:34:15 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3BW-0003ou-4P for ltru@ietf.org; Thu, 12 Apr 2007 13:34:15 -0400 Received: by nz-out-0506.google.com with SMTP id z6so554830nzd for ; Thu, 12 Apr 2007 10:34:13 -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=EPlkgd//Q1fX7kcFw+dl7lcpB47bCGtgajsnuoPBc3n3+IS0FT9/HtgDbBpT8U9xPTYmfX6xdKBPPSy1eehPv0UkojceFbltvzToB/6eDCpZa4bS0UDT56sbEngN+xobQeoyJMXGVOmkNudfufCPTG0fSPCBW3yRf1sNxbbPbv8= 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=ROagGVPA24IJyGAdPltGS3AocEkrq9rMqzVqYQaG7SjMd/nrF4YJSw92xuQIoOTNk1PuIwVFai9P04f4JzWsh15Fb1WF6rDK9RAQGQMvHSkbU2y7Y71xo09V9/vX1VHc2y5v3sQxRqSJY2ravBfzalmb8j+4RUpocx3AYkAVUu0= Received: by 10.114.52.1 with SMTP id z1mr818639waz.1176399253339; Thu, 12 Apr 2007 10:34:13 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 10:34:13 -0700 (PDT) Message-ID: <30b660a20704121034v66e6bfc4l4b44f7bb5a66aaf0@mail.gmail.com> Date: Thu, 12 Apr 2007 10:34:13 -0700 From: "Mark Davis" To: "Jukka K. Korpela" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <461E6709.2020601@sil.org> <30b660a20704121023s68658e6at7c08ac65de945e56@mail.gmail.com> X-Google-Sender-Auth: 7a50388e8f2879d8 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: www-international@w3.org, 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="===============1629423860==" Errors-To: ltru-bounces@ietf.org --===============1629423860== Content-Type: multipart/alternative; boundary="----=_Part_41071_18607130.1176399253239" ------=_Part_41071_18607130.1176399253239 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was answering the question "A related question is how to tag text that is definitely in a language but I don't know what the language is. (But I might know the script).", assuming that one knows the script. But after seeing John's suggestion, a better choice might be "mis-Latn" (if one knows that it is some language but not sure which or not able to encode, written in Latin) and "mis" if one knows that it is some language (but doesn't know the script). Mark On 4/12/07, Jukka K. Korpela wrote: > > On Thu, 12 Apr 2007, Mark Davis wrote: > > [ about text that is in unknown language but known script ] > > > For that, I'd suggest und-Latn (or whatever the script is). Since only > > languages would have scripts, that is sufficiently determinate. > > I'm not so sure about it; it depends on what "script" really means. If the > data is "JuUiYTlajUJO", which is not in any language as far as I know, > can't we still say that it is in the Latin script? > > -- > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_41071_18607130.1176399253239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was answering the question "A related question is how to tag text that is definitely in a language but I don't know what the language is. (But I might know the script).", assuming that one knows the script.

But after seeing John's suggestion, a better choice might be "mis-Latn" (if one knows that it is some language but not sure which or not able to encode, written in Latin) and "mis" if one knows that it is some language (but doesn't know the script).

Mark

On 4/12/07, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:
On Thu, 12 Apr 2007, Mark Davis wrote:

[ about text that is in unknown language but known script ]

> For that, I'd suggest und-Latn (or whatever the script is). Since only
> languages would have scripts, that is sufficiently determinate.

I'm not so sure about it; it depends on what "script" really means. If the
data is "JuUiYTlajUJO", which is not in any language as far as I know,
can't we still say that it is in the Latin script?

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/


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



--
Mark ------=_Part_41071_18607130.1176399253239-- --===============1629423860== 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 --===============1629423860==-- From ltru-bounces@ietf.org Thu Apr 12 14:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4TD-000592-1U; Thu, 12 Apr 2007 14:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4TC-00058v-GZ for ltru@ietf.org; Thu, 12 Apr 2007 14:56:34 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4TA-0006hT-IG for ltru@ietf.org; Thu, 12 Apr 2007 14:56:34 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hc4T7-0006xf-Ad; Thu, 12 Apr 2007 14:56:29 -0400 Date: Thu, 12 Apr 2007 14:56:29 -0400 To: Mark Davis Subject: Re: [Ltru] RE: For review: Tagging text with no language Message-ID: <20070412185629.GG16269@mercury.ccil.org> References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: www-international@w3.org, 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: > Q1. I had missed the choice of "mis". I agree with that suggestion; > we should incorporate that into 4646bis. The problem is ameliorated > considerably once we add -3, but it doesn't disappear completely, so > "mis" remains a good choice for dealing with that situation. I did not mean to suggest that "mis" is suitable in cases of ignorance about the language in use: it is not a fallback *language* code. Rather, it is a fallback language *collection* code, suitable for languages that don't appear in any other ISO 639-2 collection. By the Ethnologue's count, there are about 130 of these. So it would be an error to tag a language you didn't recognize as 'mis', because it is far more likely to be one of the non-'mis' languages, for the same reason that it would be incorrect to use 'en' or 'nds' or 'afa'. If you want a completely vague language tag, use 'und' (excluding for the moment the question of whether non-linguistic content not recognized as such can be tagged 'und'). > Q2. The issue *does* remain, since we talk about "und" vs the absence > of a language tag, which "" represents. I still don't see that there's anything more to say than we are saying already, which is just a special case of "Tag wisely". -- I now introduce Professor Smullyan, John Cowan who will prove to you that either cowan@ccil.org he doesn't exist or you don't exist, http://www.ccil.org/~cowan but you won't know which. --Melvin Fitting _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 17:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6lk-0001K2-R8; Thu, 12 Apr 2007 17:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6lj-0001Js-N5 for ltru@ietf.org; Thu, 12 Apr 2007 17:23:51 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc6lh-0007pm-DT for ltru@ietf.org; Thu, 12 Apr 2007 17:23:51 -0400 Received: from c83-248-98-249.bredband.comhem.se ([83.248.98.249]:1937 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hc6lf-0001gI-7V; Thu, 12 Apr 2007 23:23:47 +0200 From: "Kent Karlsson" To: "'John Cowan'" , "'Mark Davis'" References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> Subject: RE: [Ltru] RE: For review: Tagging text with no language Date: Thu, 12 Apr 2007 23:25:53 +0200 Message-ID: <004201c77d49$3502f7a0$f962f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070412185629.GG16269@mercury.ccil.org> Thread-Index: Acd9NKyMtFN4fhxsQFK6W01UbEBxKQAD10tg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hc6lf-0001gI-7V. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hc6lf-0001gI-7V 53178f0cd79b4dfe2dbb7723f4f7cbd2 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: www-international@w3.org, '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 FWIW, in CLDR 1.4 some of the translations for "und" has the word "language" (translated of course) in them, in accordance with John Cowan's original suggestion: da.xml: Sproget kan ikke bestemmes de.xml: Sprache nicht ermittelt it.xml: lingua imprecisata sv.xml: obestamt sprak (I would be to blame for the last one, but apparently I'm not the only one to (maybe) be misguided). Perhaps those ones should be retranslated not to refer to language, **if** "und" may apply also to "maybe not in any language". /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 18:06: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 1Hc7RK-0002nI-Mw; Thu, 12 Apr 2007 18:06:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7RI-0002mu-LA for ltru@ietf.org; Thu, 12 Apr 2007 18:06:48 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7RH-00072Y-UW for ltru@ietf.org; Thu, 12 Apr 2007 18:06:48 -0400 Received: by wr-out-0506.google.com with SMTP id 71so618664wri for ; Thu, 12 Apr 2007 15:06: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=emrJ93zk1w4mbh7p1gcIT/jvIXRT7b8Jzoaa6SGb6U8PL1mZzy9q50CGe2ev1q9SIPTz6u8ZzIM1WjUzcSo1VBaXgGtTOzmbkBXwcm5TDHjr3kKh4el0kD2O4PvRU7OyYSTEJAoBDgR2BmsrIfBEF7k8eIWeFXeCkiTaIiEfug4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=h+wIo1l9CVr/WGJbC9lIbercPlKwDhzQ1kTA3VOfETRG5Kk/j/Ny26b/jaOdg8VWdHmUJfBCdno7lX0piMObb8f429vVRnM6RnwMyMWwMI0u3o/gc5e2zhL6os9UbhulefWWdn2lNbqH7ad4fZk6hS03nors/ZC88Xrgtzhl7ek= Received: by 10.115.93.16 with SMTP id v16mr865681wal.1176415607226; Thu, 12 Apr 2007 15:06:47 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 15:06:47 -0700 (PDT) Message-ID: <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> Date: Thu, 12 Apr 2007 15:06:47 -0700 From: "Mark Davis" To: "Asmus Freytag" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <461EAA57.40108@ix.netcom.com> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> X-Google-Sender-Auth: f58e3ec6e98f3987 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: LTRU Working Group , CLDR list , www-international@w3.org, Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2004142582==" Errors-To: ltru-bounces@ietf.org --===============2004142582== Content-Type: multipart/alternative; boundary="----=_Part_46764_32701264.1176415607148" ------=_Part_46764_32701264.1176415607148 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Actually, we do have the ability to give fairly detailed messages based on regular expression matches on the XML path in a "zoomed" view, and soon we will have the ability to require people to go to the zoomed view before editing, and thus see those messages. So we can add specific clarifications on the use of "und" or other special cases. Mark On 4/12/07, Asmus Freytag wrote: > > On 4/12/2007 2:25 PM, Kent Karlsson wrote: > > > > FWIW, in CLDR 1.4 some of the translations for "und" has the word > "language" > > (translated of course) in them, in accordance with John Cowan's original > suggestion: > > > > da.xml: Sproget kan ikke > bestemmes > > de.xml: Sprache nicht > ermittelt > > it.xml: lingua > imprecisata > > sv.xml: obestamt > sprak > > > The sample translations show that there's general difficulty in agreeing > on the concept. The German translation says "no language (has been) > determined", while the Danish translation says that "no language could > be determined". In my reading the Swedish allows both possibilities, but > perhaps implies more strongly than the other two that assigning a > language to the contents would be meaningful. (The Italian translation > seems to most closely agree with the Swedish one to the extent of my > command of Italian) > > > (I would be to blame for the last one, but apparently I'm not the only > one to (maybe) > > be misguided). Perhaps those ones should be retranslated not to refer to > language, > > **if** "und" may apply also to "maybe not in any language". > > > > > The problem is that the scheme does not explicitly accounts for all the > types of edge conditions that you can get into when analyzing text for > language up front. Instead, labels are added here and there to handle > some of these as they become urgent enough to require attention. As a > result, all the translators have to go by is the shorthand English > description for the label. And that's not written with enough precision > to overcome the limitation of not having thought through all the > possible cases. > > A./ > > -- Mark ------=_Part_46764_32701264.1176415607148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Actually, we do have the ability to give fairly detailed messages based on regular expression matches on the XML path in a "zoomed" view, and soon we will have the ability to require people to go to the zoomed view before editing, and thus see those messages. So we can add specific clarifications on the use of "und" or other special cases.

Mark

On 4/12/07, Asmus Freytag <asmusf@ix.netcom.com> wrote:
On 4/12/2007 2:25 PM, Kent Karlsson wrote:
>
> FWIW, in CLDR 1.4 some of the translations for "und" has the word "language"
> (translated of course) in them, in accordance with John Cowan's original suggestion:
>
> da.xml:                       <language type="und">Sproget kan ikke bestemmes</language>
> de.xml:                       <language type="und">Sprache nicht ermittelt</language>
> it.xml:                       <language type="und">lingua imprecisata</language>
> sv.xml:                       <language type="und">obestamt sprak</language>
>
The sample translations show that there's general difficulty in agreeing
on the concept. The German translation says "no language (has been)
determined", while the Danish translation says that "no language could
be determined". In my reading the Swedish allows both possibilities, but
perhaps implies more strongly than the other two that assigning a
language to the contents would be meaningful. (The Italian translation
seems to most closely agree with the Swedish one to the extent of my
command of Italian)

> (I would be to blame for the last one, but apparently I'm not the only one to (maybe)
> be misguided). Perhaps those ones should be retranslated not to refer to language,
> **if** "und" may apply also to "maybe not in any language".
>
>
The problem is that the scheme does not explicitly accounts for all the
types of edge conditions that you can get into when analyzing text for
language up front. Instead, labels are added here and there to handle
some of these as they become urgent enough to require attention. As a
result, all the translators have to go by is the shorthand English
description for the label. And that's not written with enough precision
to overcome the limitation of not having thought through all the
possible cases.

A./




--
Mark ------=_Part_46764_32701264.1176415607148-- --===============2004142582== 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 --===============2004142582==-- From ltru-bounces@ietf.org Thu Apr 12 18:25: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 1Hc7jS-0005He-Bv; Thu, 12 Apr 2007 18:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7jQ-0005HX-MQ for ltru@lists.ietf.org; Thu, 12 Apr 2007 18:25:32 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7jP-0002Gc-8r for ltru@lists.ietf.org; Thu, 12 Apr 2007 18:25:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hc7e1-0001Az-7Z for ltru@lists.ietf.org; Fri, 13 Apr 2007 00:19:57 +0200 Received: from d253245.dialin.hansenet.de ([80.171.253.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:19:57 +0200 Received: from nobody by d253245.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:19:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 00:09:59 +0200 Organization: Lines: 36 Message-ID: <461EAE37.1C7A@xyzzy.claranet.de> References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253245.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > da.xml: Sproget kan ikke bestemmes > de.xml: Sprache nicht ermittelt > it.xml: lingua imprecisata > sv.xml: obestamt sprak For the German version I'd say that's "language not identified". = > Perhaps those ones should be retranslated not to refer to language, > **if** "und" may apply also to "maybe not in any language". I don't understand *_why_* anything about it should be changed. If the process to identify / determine a language failed so far, the final outcome can be still "no language at all", i.e. "zxx". And that's precisely what Richard needs for those cases where an empty string is (still) syntactically invalid, as in XHTML 1.0.
Our sole example of pure Black Speech, then, is the inscription on the Ring: Ash nazg durbatul=FBk, ash nazg gimbatul, ash nazg thrakatul=FBk agh burzum-ishi krimpatul. "One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the Darkness bind them." (LotR1/II ch. 2)
= John would likely have better ideas to tag this, but Richard's article is for ordinary users. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 19:24: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 1Hc8eG-0003c3-NY; Thu, 12 Apr 2007 19:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc8eF-0003by-HU for ltru@ietf.org; Thu, 12 Apr 2007 19:24:15 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc8eE-0003Y0-2q for ltru@ietf.org; Thu, 12 Apr 2007 19:24:15 -0400 Received: from c83-248-98-249.bredband.comhem.se ([83.248.98.249]:4854 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hc8e4-0005vg-8S; Fri, 13 Apr 2007 01:24:05 +0200 From: "Kent Karlsson" To: "'Stephen Deach'" , "'Mark Davis'" , "'Asmus Freytag'" References: <20070411183743.GA29567@mercury.ccil.org> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> Subject: RE: [Ltru] RE: For review: Tagging text with no language Date: Fri, 13 Apr 2007 01:26:29 +0200 Message-ID: <006101c77d5a$02c768a0$f962f853@streamserve.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> Thread-Index: Acd9UyA9hnZNmB8eTsONi9H8rQzoLQABq7aQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hc8e4-0005vg-8S. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hc8e4-0005vg-8S 9100dee64c89d85c68ffe2697d13885b X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: www-international@w3.org, 'CLDR list' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1808377817==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1808377817== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C77D6A.C65038A0" This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C77D6A.C65038A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stephen Deach wrote:=20 > sv.xml: obest=C3=A4mt = spr=C3=A5k I thought "obestamt" was "unstated".=20 "Obest=C3=A4mt" literally means "undetermined". "Unstated" would be = "osagt", "outtalat", or "ej angett" ("not given", closer to the current German translation). =20 Though I would agree that xml:lang=3D"" is closer to "unstated" than = "undetermined". I'm not sure that that nit-picking leads anywhere in this case. But "unstated" is not = the same as "undetermined"; it may well be determined, but just not stated... So maybe there is a = difference worth bothering about. =20 /kent k=20 =20 ------=_NextPart_000_0062_01C77D6A.C65038A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF Stephen Deach wrote: 
>=20 = sv.xml:           =            =20 <language type=3D"und">obest=C3=A4mt=20 spr=C3=A5k</language>

I thought "obestamt" was "unstated". 
"Obest=C3=A4mt" literally means "undetermined". = "Unstated" would=20 be "osagt", "outtalat", or "ej angett"
("not given", closer to the current German = translation).
 
Though I would agree that xml:lang=3D"" is = closer to=20 "unstated" than "undetermined". I'm not sure
that that nit-picking leads anywhere in this = case. But=20 "unstated" is not the same as "undetermined";
it may well be determined, but just not = stated... So maybe=20 there is a difference worth bothering about.
 
        = /kent = k 
  ------=_NextPart_000_0062_01C77D6A.C65038A0-- --===============1808377817== 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 --===============1808377817==-- From ltru-bounces@ietf.org Thu Apr 12 19:26: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 1Hc8g7-0004jL-28; Thu, 12 Apr 2007 19:26:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc8g6-0004gr-0G for ltru@lists.ietf.org; Thu, 12 Apr 2007 19:26:10 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc8g4-0005Sn-Ot for ltru@lists.ietf.org; Thu, 12 Apr 2007 19:26:09 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hc8g3-0003B6-Kd; Thu, 12 Apr 2007 19:26:07 -0400 Date: Thu, 12 Apr 2007 19:26:07 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: For review: Tagging text with no language Message-ID: <20070412232607.GA7353@mercury.ccil.org> References: <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAE37.1C7A@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <461EAE37.1C7A@xyzzy.claranet.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: >
> Our sole example of pure Black Speech, then, is the inscription > on the Ring: Ash nazg durbatulûk, > ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul. > "One Ring to rule them all, One Ring to find them, One Ring to > bring them all and in the Darkness bind them." (LotR1/II ch. 2) >
> > John would likely have better ideas to tag this, but Richard's > article is for ordinary users. For automated tagging, "und" is probably the best you can do indeed, unless you set up your automated tagger to detect precisely that word sequence. For manual tagging, I'd go with "art-x-bspeech" for now, or something like that. -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he cowan@ccil.org that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 21:15: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 1HcANX-0005tC-6z; Thu, 12 Apr 2007 21:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcANV-0005lB-9g for ltru@ietf.org; Thu, 12 Apr 2007 21:15:05 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcANT-0004T0-Po for ltru@ietf.org; Thu, 12 Apr 2007 21:15:05 -0400 Received: by nz-out-0506.google.com with SMTP id z6so676726nzd for ; Thu, 12 Apr 2007 18:15: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=DHVIa5RHltUQxaXSA4HTkfmCnJ0z8nSqoECLxGSo4LPLj/6/MaEP8ZH/iQ4ipxs9oVINjHn1dSJekmUabpTFkekH0uhNNDmm7RDPN4y86+sdxwIj+T3AwKEGht59iT42afbqiDbQk+NdNSop8hg9Sfwkc3irmjBbkgprdG1YBII= 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=IeYUBJbMkgJTQMo4ZXoQOIjQ72k61Utc5695MqMtCjD0QYnMptkZGu5O+cntSWFffJhdFY3+ie2OGlrkc6T3E14O7/FWu+bwzhDy43gTjmI47xVwQOQAPHjer197hoRA3z656oK1WDCkxL8pQijgjsTdwerPzg9bXwsj3vIpQbs= Received: by 10.114.125.2 with SMTP id x2mr883885wac.1176426902961; Thu, 12 Apr 2007 18:15:02 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 12 Apr 2007 18:15:02 -0700 (PDT) Message-ID: <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> Date: Thu, 12 Apr 2007 18:15:02 -0700 From: "Mark Davis" To: "Stephen Deach" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> MIME-Version: 1.0 References: <20070411183743.GA29567@mercury.ccil.org> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> X-Google-Sender-Auth: 06951edb7d04da0d X-Spam-Score: 0.1 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: LTRU Working Group , CLDR list , www-international@w3.org, Asmus Freytag , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775197353==" Errors-To: ltru-bounces@ietf.org --===============1775197353== Content-Type: multipart/alternative; boundary="----=_Part_49671_19238285.1176426902853" ------=_Part_49671_19238285.1176426902853 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBJIGFncmVlIHdpdGggeW91IGluIHNwaXJpdCwgYnV0IG5vdCBpbiBwcmVjaXNlIGRl dGFpbHMuIFRoZSB0YWcKInVuZCIgbWVhbnMgInVuZGV0ZXJtaW5lZCIsIHNvIHdoZW4gSSBlbmNv dW50ZXIgaXQgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhlCmNvbnRlbnQgY29udGFpbnMgb25lIGxh bmd1YWdlLCBtYW55IGxhbmd1YWdlcywgb3Igbm8gbGFuZ3VhZ2UuIFRoZSB0YWcgInp4eCIKd291 bGQgbWVhbiB0aGF0IHRoZXJlIGlzIG5vIGxhbmd1YWdlIGNvbnRlbnQsICJtaXMiIHdvdWxkIG1l YW4gdGhhdCB0aGVyZSBpcwphdCBsZWFzdCBzb21lIGxhbmd1YWdlIGNvbnRlbnQsIGFuZCAibXVs IiB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgaXMgbGFuZ3VhZ2UKY29udGVudCwgd2l0aCBtb3JlIHRo YW4gb25lIGxhbmd1YWdlLgoKSSB0aGluayB0byB0cnkgdG8gY29uc2lkZXIgd2hhdCB0aGUgbW90 aXZhdGlvbnMgb2YgdGhlIHRhZ2dlciBhcmUgbWF5IGxlYWQKdG8gbWlzbGVhZGluZyBpbXByZXNz aW9ucy4gQXNzdW1lIGZvciB0aGUgbW9tZW50IHRoYXQgdGhlIHRhZyBpcyBjb3JyZWN0LgpGcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgdGFnZ2VyLCB1c2luZyAidW5kIiBjb3VsZCBtZWFuLCBh cyB5b3Ugc2F5LCB0aGF0CnRoZSB0YWdnZXIgZG9lc24ndCBrbm93IG9yIGNhcmUgKG9yIHdhbnQg dG8gY29tbXVuaWNhdGUsIG9yIHdoYXQgdG8gc3BlbmQKdGhlIHRpbWUgdG8gZGV0ZXJtaW5lKSB3 aGF0IHRoZSBsYW5ndWFnZSBpcyBvciB3aGV0aGVyIHRoZXJlIGlzIGFueSBsYW5ndWFnZQpjb250 ZW50IHRoZXJlIGF0IGFsbC4gVGhlcmUgY291bGQgYmUgcXVpdGUgYSB2YXJpZXR5IG9mIG1vdGl2 YXRpb25zIGZvciB0aGUKdGFnZ2VyJ3MgdXNpbmcgInVuZCI7IHRoZSBrZXkgaXMgd2hhdCB0aGUg cmVhZGVyIG9mICJ1bmQiIGNhbiBhc3N1bWUgYWJvdXQKdGhlIGNvbnRlbnQsIHdoaWNoIGlzIGVz c2VudGlhbGx5IG5vdGhpbmcuIFdpdGggIm1pcyIsIHRoZSBzaXR1YXRpb24gaXMKc2ltaWxhciwg YnV0IHNsaWdodGx5IG5hcnJvd2VyLiBUaGUgdGFnZ2VyIG1heSBzdGlsbCBub3Qga25vdyBtdWNo LCBvciBjYXJlCm11Y2gsIGJ1dCBtYXliZSBjYXJlZCBlbm91Z2ggdG8gZGV0ZXJtaW5lIHRoYXQg dGhlcmUgd2FzIHNvbWV0aGluZyB0aGVyZSwgb3IKbWF5YmUgdGhlcmUgd2FzIGxhbmd1YWdlIGNv bnRlbnQgdGhlcmUsIGJ1dCB0aGVyZSBpcyBubyBsYW5ndWFnZSBjb2RlIHRoYXQKY29ycmVjdGx5 IG1hdGNoZXMgaXQgKHByb3RvZ2VybWFuaWMsIHBlcmhhcHMpLgoKU2ltaWxhcmx5LCB1c2luZyAi bWF5IG5vdCIgbGFuZ3VhZ2UgaXMgYSBiaXQgdG9vIHN0cm9uZyBpbiB5b3VyIHBocmFzZQoiV2hl cmVhcyB6eHggc2F5cyBJICdtYXkgbm90JyBhcHBseSBhbnkgb2YgdGhvc2UgbGFuZ3VhZ2UtYmFz ZWQgc2VydmljZXMKYmVjYXVzZSBpdCBpcyBub3QgYSAnbmF0dXJhbCcgbGFuZ3VhZ2UiLiBIYXZp bmcgY29udGVudCB0YWdnZWQgd2l0aCAienh4Igpkb2Vzbid0IHJlc3RyaWN0IG1lIGZyb20gZG9p bmcgYW55dGhpbmcgSSB3YW50IHRvOyBpdCBqdXN0IG1lYW5zIGlmIGl0IHdhcwp0YWdnZWQgY29y cmVjdGx5LCBpdCBkb2VzIG5vdCBjb250YWluIGFueSBsYW5ndWFnZSBjb250ZW50LiAoSSBtaWdo dCBkZWNpZGUKdGhhdCB0aGUgdGFnZ2VyIHdhcyBtaXN0YWtlbiAtLSB3aGVuIHdlIGF0IEdvb2ds ZSBsb29rIGF0IHRoZSB0YWdnaW5nIHBlb3BsZQphY3R1YWxseSBkbyBvZiB3ZWIgY29udGVudCwg dGhlcmUgaXMgYSBmYWlybHkgaGlnaCBwZXJjZW50YWdlIG9mIGJvdGgKaW52YWxpZCB0YWdzIGFu ZCB2YWxpZC1idXQtaW5jb3JyZWN0IHRhZ3MuKQoKTWFyawoKT24gNC8xMi8wNywgU3RlcGhlbiBE ZWFjaCA8c2RlYWNoQGFkb2JlLmNvbT4gd3JvdGU6Cj4KPiAgSSB0aGluayBtdWNoIG9mIHRoaXMg ZGlzY3Vzc2lvbiBpcyBkZWFsaW5nIHdpdGggdGVybWlub2xvZ3kgZGlmZmVyZW5jZXMKPiB0aGF0 IGFyZSBzbyBuYXJyb3cgdGhhdCBvbmUgaXMgZGlzY3Vzc2luZyAidGhlIG51bWJlciBvZiBhbmdl bHMgd2hvIGNhbgo+IGRhbmNlIG9uIHRoZSBoZWFkIG9mIGEgcGluIi4gKEluIG90aGVyIHdvcmRz IHdlIGFyZSBkZWJhdGluZyB0aGVvbG9neSwgbm90Cj4gcHJhY3RpY2UuKSBJbiByZWFsaXR5LCBz cGVjaWZpY2F0aW9ucyBhcmUgd29yZGVkIGFzIGNhcmVmdWxseSBhcyBwb3NzaWJsZSwKPiBidXQg aW50ZXJwcmV0YXRpb24gaXMgb3BlbiB0byB0aGUgcmVhZGVyJ3MgbW9zdCBjb21tb24KPiBkZWZp bml0aW9uL3JlZGVmaW5pdGlvbi90cmFuc2xhdGlvbiBvZiB0aGUgZXhhY3QgdGVybWlub2xvZ3ku ICAtLSBTbyByYXRoZXIKPiB0aGFuIGRlYmF0ZSB3aGF0IHRoZSAiZXhhY3QgbWVhbmluZyIgb2Yg YSB3b3JkL3BocmFzZSBpcyBpbiBlYWNoIG9mIHRoZXNlCj4gbGFuZ3VhZ2VzLCBtYXliZSB3ZSBz aG91bGQgdGFrZSBhIGxvb3NlciBpbnRlcnByZXRhdGlvbiBvZiB3aGF0IGlzIHdyaXR0ZW4KPiBh bmQgdGhlbiBjbGFyaWZ5IHRoZSBpbnRlbnQuCj4KPiBNeSByZWFkaW5nIG9mIHRoZSBJU08gc3Bl YyBpcyB0aGF0ICJ1bmQvdW5kZXRlcm1pbmVkIiBtZWFucyAiSSBkb24ndCBrbm93Cj4gKG9yIGNh cmUsIG9yIGFtIHVud2lsbGluZyB0byBzdGF0ZSkgd2hhdCB0aGUgbGFuZ3VhZ2UgaXMgKGFuZCBo YXZlIG5vIGNsb3Nlcgo+IGFsdGVybmF0aXZlIGxhbmd1YWdlIGlkZW50aWZpZXIgZ2l2ZW4gdGhl IGF2YWlsYWJsZSBvcHRpb25zKSIuIEZyb20gYQo+IHByYWN0aWNhbCB2aWV3cG9pbnQsICJ1bmQi IGluZGljYXRlcyBJIGNhbid0IGFzc3VtZSBhbnkgc3BlY2lmaWMvcHJlZmVycmVkCj4gbGluZ3Vp c3RpYyBkZWZpbml0aW9ucyBmb3Igd29yZHMgaW4gdGhlIGNvbnRlbnQsIG5vciBjYW4gSSBhc3N1 bWUgYW55Cj4gc3BlY2lmaWMvcHJlZmVycmVkIHByb251bmNpYXRpb24tLCBzcGVsbGluZy0sIGh5 cGhlbmF0aW9uLSwgYW5kL29yCj4gZ3JhbW1hci1ydWxlcyBvbiB0aGUgY29udGVudDsgdGhvdWdo IEkgYW0gYWxsb3dlZCB0byBhdHRlbXB0IG15IG93bgo+IGxpbmd1aXN0aWMgYW5hbHlzaXMgdG8g Z3Vlc3MgYXQgdGhlIGxhbmd1YWdlLiAoV2hlcmVhcyB6eHggc2F5cyBJICdtYXkgbm90Jwo+IGFw cGx5IGFueSBvZiB0aG9zZSBsYW5ndWFnZS1iYXNlZCBzZXJ2aWNlcyBiZWNhdXNlIGl0IGlzIG5v dCBhICduYXR1cmFsJwo+IGxhbmd1YWdlIGFuZCBzaG91bGQgbm90IGF0dGVtcHQgYW55IGxpbmd1 aXN0aWMgYW5hbHlzaXMgdG8gZ3Vlc3MgYXQgdGhlCj4gbGFuZ3VhZ2UuKSBJIGNhbid0IHNlZSBh bnkgcHJhY3RpY2FsIGRpZmZlcmVuY2UgYmV0d2VlbiAidW5kIiBhbmQgIiIgKGV4Y2VwdAo+IHRo YXQgIiIgaXMgZGlzYWxsb3dlZCBpbiBzb21lIHByb2Nlc3NpbmcgZW52aXJvbm1lbnRzKSBzbyB3 aHkgY2FuJ3QgdGhlCj4gZG9jdW1lbnRzIHNpbXBseSBzYXkgdGhhdCAnYSBtaXNzaW5nIHNwZWNp ZmljYXRpb24nIG9yICd4bWw6bGFuZz0iIicgKHNob3VsZAo+IGVpdGhlciBvY2N1ciksIHdpbGwg YmUgaW50ZXJwcmV0ZWQgYXMgInVuZCIuCj4KPgo+IEl0IGhhcyBiZWVuIGEgd2hpbGUgc2luY2Ug SSBjb25zaWRlcmVkIG15c2VsZiBmbHVlbnQgaW4gU3dlZGlzaCAoYW5kIEkKPiBpbnRlbnRpb25h bGx5IGlnbm9yZWQgdGhlIGxhY2sgb2YgdGhlIGRpZXJlc2lzIGluIHRoZSBvcmlnaW5hbCB0ZXh0 IGFzIGFuCj4gaW5kaWNhdGlvbiB0aGF0IHRoZSB0cmFuc2xhdGlvbnMgd2VyZSAibG9zc3kiKS4g SSBqdXN0IHRob3VnaHQgdGhhdCBzb21lCj4gY29tbWVudCB3b3VsZCBmb3JjZSB0aGUgbmVjZXNz YXJ5IGNsYXJpZmljYXRpb24gb2YgdGhlIHRyYW5zbGF0aW9ucy4KPgo+Cj4gQXQgMjAwNy4wNC4x My0wMToyNigrMDIwMCksIEtlbnQgS2FybHNzb24gd3JvdGU6Cj4KPiBTdGVwaGVuIERlYWNoIHdy b3RlOgo+Cj4gID4gc3YueG1sOiAgICAgICAgICAgICAgICAgICAgICAgPGxhbmd1YWdlIHR5cGU9 InVuZCI+b2Jlc3TDpG10Cj4gc3Byw6VrPC9sYW5ndWFnZT4KPgo+Cj4gSSB0aG91Z2h0ICJvYmVz dGFtdCIgd2FzICJ1bnN0YXRlZCIuCj4KPiAiT2Jlc3TDpG10IiBsaXRlcmFsbHkgbWVhbnMgInVu ZGV0ZXJtaW5lZCIuICJVbnN0YXRlZCIgd291bGQgYmUgIm9zYWd0IiwKPiAib3V0dGFsYXQiLCBv ciAiZWogYW5nZXR0Igo+ICgibm90IGdpdmVuIiwgY2xvc2VyIHRvIHRoZSBjdXJyZW50IEdlcm1h biB0cmFuc2xhdGlvbikuCj4KPiBUaG91Z2ggSSB3b3VsZCBhZ3JlZSB0aGF0IHhtbDpsYW5nPSIi IGlzIGNsb3NlciB0byAidW5zdGF0ZWQiIHRoYW4KPiAidW5kZXRlcm1pbmVkIi4gSSdtIG5vdCBz dXJlCj4gdGhhdCB0aGF0IG5pdC1waWNraW5nIGxlYWRzIGFueXdoZXJlIGluIHRoaXMgY2FzZS4g QnV0ICJ1bnN0YXRlZCIgaXMgbm90Cj4gdGhlIHNhbWUgYXMgInVuZGV0ZXJtaW5lZCI7Cj4gaXQg bWF5IHdlbGwgYmUgZGV0ZXJtaW5lZCwgYnV0IGp1c3Qgbm90IHN0YXRlZC4uLiBTbyBtYXliZSB0 aGVyZSBpcyBhCj4gZGlmZmVyZW5jZSB3b3J0aCBib3RoZXJpbmcgYWJvdXQuCj4KPiAgICAgICAg IC9rZW50IGsKPgo+Cj4KPiAtLS1TdGV2ZSBEZWFjaAo+ICAgIHNkZWFjaEBhZG9iZS5jb20KPgoK CgotLSAKTWFyawo= ------=_Part_49671_19238285.1176426902853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBJIGFncmVlIHdpdGggeW91IGluIHNwaXJpdCwgYnV0IG5vdCBpbiBwcmVjaXNlIGRl dGFpbHMuIFRoZSB0YWcgJnF1b3Q7dW5kJnF1b3Q7IG1lYW5zICZxdW90O3VuZGV0ZXJtaW5lZCZx dW90Oywgc28gd2hlbiBJIGVuY291bnRlciBpdCBJIGRvbiYjMzk7dCBrbm93IHdoZXRoZXIgdGhl IGNvbnRlbnQgY29udGFpbnMgb25lIGxhbmd1YWdlLCBtYW55IGxhbmd1YWdlcywgPHNwYW4gc3R5 bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPgpvciBubyBsYW5ndWFnZTwvc3Bhbj4uIFRoZSB0YWcg JnF1b3Q7enh4JnF1b3Q7IHdvdWxkIG1lYW4gdGhhdCB0aGVyZSBpcyBubyBsYW5ndWFnZSBjb250 ZW50LCAmcXVvdDttaXMmcXVvdDsgd291bGQgbWVhbiB0aGF0IHRoZXJlIGlzIGF0IGxlYXN0IHNv bWUgbGFuZ3VhZ2UgY29udGVudCwgYW5kICZxdW90O211bCZxdW90OyB3b3VsZCBtZWFuIHRoYXQg dGhlcmUgaXMgbGFuZ3VhZ2UgY29udGVudCwgd2l0aCBtb3JlIHRoYW4gb25lIGxhbmd1YWdlLgo8 YnI+PGJyPkkgdGhpbmsgdG8gdHJ5IHRvIGNvbnNpZGVyIHdoYXQgdGhlIG1vdGl2YXRpb25zIG9m IHRoZSB0YWdnZXIgYXJlIG1heSBsZWFkIHRvIG1pc2xlYWRpbmcgaW1wcmVzc2lvbnMuIEFzc3Vt ZSBmb3IgdGhlIG1vbWVudCB0aGF0IHRoZSB0YWcgaXMgY29ycmVjdC4gRnJvbSB0aGUgcGVyc3Bl Y3RpdmUgb2YgdGhlIHRhZ2dlciwgdXNpbmcgJnF1b3Q7dW5kJnF1b3Q7IGNvdWxkIG1lYW4sIGFz IHlvdSBzYXksIHRoYXQgdGhlCnRhZ2dlciBkb2VzbiYjMzk7dCBrbm93IG9yIGNhcmUgKG9yIHdh bnQgdG8gY29tbXVuaWNhdGUsIG9yIHdoYXQgdG8gc3BlbmQKdGhlIHRpbWUgdG8gZGV0ZXJtaW5l KSB3aGF0IHRoZSBsYW5ndWFnZSBpcyA8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IGZv bnQtc3R5bGU6IGl0YWxpYzsiPm9yIDwvc3Bhbj53aGV0aGVyCnRoZXJlIGlzIGFueSBsYW5ndWFn ZSBjb250ZW50IHRoZXJlIGF0IGFsbC4gVGhlcmUgY291bGQgYmUgcXVpdGUgYQp2YXJpZXR5IG9m IG1vdGl2YXRpb25zIGZvciB0aGUgdGFnZ2VyJiMzOTtzIHVzaW5nICZxdW90O3VuZCZxdW90Ozsg dGhlIGtleSBpcyB3aGF0CnRoZSByZWFkZXIgb2YgJnF1b3Q7dW5kJnF1b3Q7IGNhbiBhc3N1bWUg YWJvdXQgdGhlIGNvbnRlbnQsIHdoaWNoIGlzIGVzc2VudGlhbGx5IG5vdGhpbmcuIFdpdGggJnF1 b3Q7bWlzJnF1b3Q7LCB0aGUgc2l0dWF0aW9uIGlzIHNpbWlsYXIsIGJ1dCBzbGlnaHRseSBuYXJy b3dlci4gVGhlIHRhZ2dlciBtYXkgc3RpbGwgbm90IGtub3cgbXVjaCwgb3IgY2FyZSBtdWNoLCBi dXQgbWF5YmUgY2FyZWQgZW5vdWdoIHRvIGRldGVybWluZSB0aGF0IHRoZXJlIHdhcyBzb21ldGhp bmcgdGhlcmUsIG9yIG1heWJlIHRoZXJlIHdhcyBsYW5ndWFnZSBjb250ZW50IHRoZXJlLCBidXQg dGhlcmUgaXMgbm8gbGFuZ3VhZ2UgY29kZSB0aGF0IGNvcnJlY3RseSBtYXRjaGVzIGl0IChwcm90 b2dlcm1hbmljLCBwZXJoYXBzKS4KPGJyPjxicj5TaW1pbGFybHksIHVzaW5nICZxdW90O21heSBu b3QmcXVvdDsgbGFuZ3VhZ2UgaXMgYSBiaXQgdG9vIHN0cm9uZyBpbiB5b3VyIHBocmFzZSAmcXVv dDtXaGVyZWFzIHp4eCBzYXlzIEkgJiMzOTttYXkgbm90JiMzOTsgYXBwbHkgYW55IG9mIHRob3Nl Cmxhbmd1YWdlLWJhc2VkIHNlcnZpY2VzIGJlY2F1c2UgaXQgaXMgbm90IGEgJiMzOTtuYXR1cmFs JiMzOTsgbGFuZ3VhZ2UmcXVvdDsuIEhhdmluZyBjb250ZW50IHRhZ2dlZCB3aXRoICZxdW90O3p4 eCZxdW90OyBkb2VzbiYjMzk7dCByZXN0cmljdCBtZSBmcm9tIGRvaW5nIGFueXRoaW5nIEkgd2Fu dCB0bzsgaXQganVzdCBtZWFucyBpZiBpdCB3YXMgdGFnZ2VkIGNvcnJlY3RseSwgaXQgZG9lcyBu b3QgY29udGFpbiBhbnkgbGFuZ3VhZ2UgY29udGVudC4gKEkgbWlnaHQgZGVjaWRlIHRoYXQgdGhl IHRhZ2dlciB3YXMgbWlzdGFrZW4gLS0gd2hlbiB3ZSBhdCBHb29nbGUgbG9vayBhdCB0aGUgdGFn Z2luZyBwZW9wbGUgYWN0dWFsbHkgZG8gb2Ygd2ViIGNvbnRlbnQsIHRoZXJlIGlzIGEgZmFpcmx5 IGhpZ2ggcGVyY2VudGFnZSBvZiBib3RoIGludmFsaWQgdGFncyBhbmQgdmFsaWQtYnV0LWluY29y cmVjdCB0YWdzLikKPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gNC8xMi8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlN0ZXBoZW4gRGVh Y2g8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c2RlYWNoQGFkb2JlLmNvbSI+c2RlYWNoQGFkb2Jl LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2lu OiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCjxkaXY+CkkgdGhpbmsg bXVjaCBvZiB0aGlzIGRpc2N1c3Npb24gaXMgZGVhbGluZyB3aXRoIHRlcm1pbm9sb2d5IGRpZmZl cmVuY2VzCnRoYXQgYXJlIHNvIG5hcnJvdyB0aGF0IG9uZSBpcyBkaXNjdXNzaW5nICZxdW90O3Ro ZSBudW1iZXIgb2YgYW5nZWxzIHdobwpjYW4gZGFuY2Ugb24gdGhlIGhlYWQgb2YgYSBwaW4mcXVv dDsuIChJbiBvdGhlciB3b3JkcyB3ZSBhcmUgZGViYXRpbmcKdGhlb2xvZ3ksIG5vdCBwcmFjdGlj ZS4pIEluIHJlYWxpdHksIHNwZWNpZmljYXRpb25zIGFyZSB3b3JkZWQgYXMKY2FyZWZ1bGx5IGFz IHBvc3NpYmxlLCBidXQgaW50ZXJwcmV0YXRpb24gaXMgb3BlbiB0byB0aGUgcmVhZGVyJiMzOTtz IG1vc3QKY29tbW9uIGRlZmluaXRpb24vcmVkZWZpbml0aW9uL3RyYW5zbGF0aW9uIG9mIHRoZSBl eGFjdAp0ZXJtaW5vbG9neS4mbmJzcDsgLS0gU28gcmF0aGVyIHRoYW4gZGViYXRlIHdoYXQgdGhl ICZxdW90O2V4YWN0Cm1lYW5pbmcmcXVvdDsgb2YgYSB3b3JkL3BocmFzZSBpcyBpbiBlYWNoIG9m IHRoZXNlIGxhbmd1YWdlcywgbWF5YmUgd2UKc2hvdWxkIHRha2UgYSBsb29zZXIgaW50ZXJwcmV0 YXRpb24gb2Ygd2hhdCBpcyB3cml0dGVuIGFuZCB0aGVuIGNsYXJpZnkKdGhlIGludGVudC48YnI+ PGJyPgpNeSByZWFkaW5nIG9mIHRoZSBJU08gc3BlYyBpcyB0aGF0ICZxdW90O3VuZC91bmRldGVy bWluZWQmcXVvdDsgbWVhbnMKJnF1b3Q7SSBkb24mIzM5O3Qga25vdyAob3IgY2FyZSwgb3IgYW0g dW53aWxsaW5nIHRvIHN0YXRlKSB3aGF0IHRoZSBsYW5ndWFnZQppcyAoYW5kIGhhdmUgbm8gY2xv c2VyIGFsdGVybmF0aXZlIGxhbmd1YWdlIGlkZW50aWZpZXIgZ2l2ZW4gdGhlCmF2YWlsYWJsZSBv cHRpb25zKSZxdW90Oy4gRnJvbSBhIHByYWN0aWNhbCB2aWV3cG9pbnQsICZxdW90O3VuZCZxdW90 OwppbmRpY2F0ZXMgSSBjYW4mIzM5O3QgYXNzdW1lIGFueSBzcGVjaWZpYy9wcmVmZXJyZWQgbGlu Z3Vpc3RpYyBkZWZpbml0aW9ucwpmb3Igd29yZHMgaW4gdGhlIGNvbnRlbnQsIG5vciBjYW4gSSBh c3N1bWUgYW55IHNwZWNpZmljL3ByZWZlcnJlZApwcm9udW5jaWF0aW9uLSwgc3BlbGxpbmctLCBo eXBoZW5hdGlvbi0sIGFuZC9vciBncmFtbWFyLXJ1bGVzIG9uIHRoZQpjb250ZW50OyB0aG91Z2gg SSBhbSBhbGxvd2VkIHRvIGF0dGVtcHQgbXkgb3duIGxpbmd1aXN0aWMgYW5hbHlzaXMgdG8KZ3Vl c3MgYXQgdGhlIGxhbmd1YWdlLiAoV2hlcmVhcyB6eHggc2F5cyBJICYjMzk7bWF5IG5vdCYjMzk7 IGFwcGx5IGFueSBvZiB0aG9zZQpsYW5ndWFnZS1iYXNlZCBzZXJ2aWNlcyBiZWNhdXNlIGl0IGlz IG5vdCBhICYjMzk7bmF0dXJhbCYjMzk7IGxhbmd1YWdlIGFuZCBzaG91bGQKbm90IGF0dGVtcHQg YW55IGxpbmd1aXN0aWMgYW5hbHlzaXMgdG8gZ3Vlc3MgYXQgdGhlIGxhbmd1YWdlLikgSSBjYW4m IzM5O3QKc2VlIGFueSBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuICZxdW90O3VuZCZxdW90 OyBhbmQgJnF1b3Q7JnF1b3Q7CihleGNlcHQgdGhhdCAmcXVvdDsmcXVvdDsgaXMgZGlzYWxsb3dl ZCBpbiBzb21lIHByb2Nlc3NpbmcgZW52aXJvbm1lbnRzKQpzbyB3aHkgY2FuJiMzOTt0IHRoZSBk b2N1bWVudHMgc2ltcGx5IHNheSB0aGF0ICYjMzk7YSBtaXNzaW5nIHNwZWNpZmljYXRpb24mIzM5 OyBvcgomIzM5O3htbDpsYW5nPSZxdW90OyZxdW90OyYjMzk7IChzaG91bGQgZWl0aGVyIG9jY3Vy KSwgd2lsbCBiZSBpbnRlcnByZXRlZCBhcwomcXVvdDt1bmQmcXVvdDsuPGJyPjxicj4KPGJyPgpJ dCBoYXMgYmVlbiBhIHdoaWxlIHNpbmNlIEkgY29uc2lkZXJlZCBteXNlbGYgZmx1ZW50IGluIFN3 ZWRpc2ggKGFuZCBJCmludGVudGlvbmFsbHkgaWdub3JlZCB0aGUgbGFjayBvZiB0aGUgZGllcmVz aXMgaW4gdGhlIG9yaWdpbmFsIHRleHQgYXMgYW4KaW5kaWNhdGlvbiB0aGF0IHRoZSB0cmFuc2xh dGlvbnMgd2VyZSAmcXVvdDtsb3NzeSZxdW90OykuIEkganVzdCB0aG91Z2h0CnRoYXQgc29tZSBj b21tZW50IHdvdWxkIGZvcmNlIHRoZSBuZWNlc3NhcnkgY2xhcmlmaWNhdGlvbiBvZiB0aGUKdHJh bnNsYXRpb25zLjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExMWU4NTNjZTFmNGI1MmZfMSI+ PGJyPjxicj4KPGJyPgpBdCAyMDA3LjA0LjEzLTAxOjI2KCswMjAwKSwgS2VudCBLYXJsc3NvbiB3 cm90ZTo8YnI+CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Imh0dHA6Ly8iPgo8Zm9udCBm YWNlPSJ0YWhvbWEiIHNpemU9IjIiPlN0ZXBoZW4KRGVhY2g8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwZmYiIGZhY2U9IkFyaWFsIFVuaWNvZGUgTVMsIEhlbHZldGljYSIgc2l6ZT0iMiI+Cndyb3Rl Ogo8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PC9mb250PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNp dGU9Imh0dHA6Ly8iPgo8ZGw+CjxkbD4KPGRkPiZndDsKc3YueG1sOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OwombHQ7bGFuZ3VhZ2UgdHlwZT0mcXVvdDt1bmQmcXVvdDsmZ3Q7b2Jlc3TDpG10CnNwcsOlayZs dDsvbGFuZ3VhZ2UmZ3Q7PC9kZD48L2RsPjwvZGw+PC9ibG9ja3F1b3RlPgo8YnI+Cgo8ZGQ+SSB0 aG91Z2h0ICZxdW90O29iZXN0YW10JnF1b3Q7IHdhcwomcXVvdDt1bnN0YXRlZCZxdW90Oy48Zm9u dCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQXJpYWwgVW5pY29kZSBNUywgSGVsdmV0aWNhIiBzaXpl PSIyIj4KPGJyPgo8L2ZvbnQ+PGJyPgoKPGZvbnQgY29sb3I9IiMwMDAwZmYiIGZhY2U9IkFyaWFs IFVuaWNvZGUgTVMsIEhlbHZldGljYSIgc2l6ZT0iMiI+JnF1b3Q7T2Jlc3TDpG10JnF1b3Q7Cmxp dGVyYWxseSBtZWFucyAmcXVvdDt1bmRldGVybWluZWQmcXVvdDsuICZxdW90O1Vuc3RhdGVkJnF1 b3Q7IHdvdWxkIGJlCiZxdW90O29zYWd0JnF1b3Q7LCAmcXVvdDtvdXR0YWxhdCZxdW90Oywgb3Ig JnF1b3Q7ZWogYW5nZXR0JnF1b3Q7PGJyPgooJnF1b3Q7bm90IGdpdmVuJnF1b3Q7LCBjbG9zZXIg dG8gdGhlIGN1cnJlbnQgR2VybWFuIHRyYW5zbGF0aW9uKS48YnI+CjwvZm9udD4mbmJzcDs8YnI+ Cjxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJBcmlhbCBVbmljb2RlIE1TLCBIZWx2ZXRpY2Ei IHNpemU9IjIiPlRob3VnaCBJCndvdWxkIGFncmVlIHRoYXQgeG1sOmxhbmc9JnF1b3Q7JnF1b3Q7 IGlzIGNsb3NlciB0byAmcXVvdDt1bnN0YXRlZCZxdW90Owp0aGFuICZxdW90O3VuZGV0ZXJtaW5l ZCZxdW90Oy4gSSYjMzk7bSBub3Qgc3VyZTxicj4KdGhhdCB0aGF0IG5pdC1waWNraW5nIGxlYWRz IGFueXdoZXJlIGluIHRoaXMgY2FzZS4gQnV0CiZxdW90O3Vuc3RhdGVkJnF1b3Q7IGlzIG5vdCB0 aGUgc2FtZSBhcyAmcXVvdDt1bmRldGVybWluZWQmcXVvdDs7PGJyPgppdCBtYXkgd2VsbCBiZSBk ZXRlcm1pbmVkLCBidXQganVzdCBub3Qgc3RhdGVkLi4uIFNvIG1heWJlIHRoZXJlIGlzIGEKZGlm ZmVyZW5jZSB3b3J0aCBib3RoZXJpbmcgYWJvdXQuPGJyPgo8L2ZvbnQ+Jm5ic3A7PGJyPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPGZvbnQgY29sb3I9IiMwMDAw ZmYiIGZhY2U9IkFyaWFsIFVuaWNvZGUgTVMsIEhlbHZldGljYSIgc2l6ZT0iMiI+L2tlbnQgawo8 YnI+CiZuYnNwOzwvZm9udD48L2RkPjwvYmxvY2txdW90ZT4KPC9zcGFuPjwvZGl2PjxwPgo8c3Bh biBjbGFzcz0icSI+PGJyPgotLS1TdGV2ZSBEZWFjaDxicj4KJm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Im1haWx0bzpzZGVhY2hAYWRvYmUuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJu IHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnNkZWFjaEBhZG9iZS5jb208 L2E+PC9zcGFuPjwvcD48L2Rpdj4KCgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0i YWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_49671_19238285.1176426902853-- --===============1775197353== 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 --===============1775197353==-- From ltru-bounces@ietf.org Thu Apr 12 22:05: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 1HcB9t-0005Em-49; Thu, 12 Apr 2007 22:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcB9r-0005EX-HE for ltru@ietf.org; Thu, 12 Apr 2007 22:05:03 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcB9q-0007kN-9k for ltru@ietf.org; Thu, 12 Apr 2007 22:05:03 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcB9D-0006kZ-8O; Thu, 12 Apr 2007 22:04:23 -0400 Date: Thu, 12 Apr 2007 22:04:23 -0400 To: Mark Davis Subject: Re: [Ltru] RE: For review: Tagging text with no language Message-ID: <20070413020422.GC7353@mercury.ccil.org> References: <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group , CLDR list , www-international@w3.org, Asmus Freytag , Stephen Deach , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I think I agree with you in spirit, but not in precise details. The > tag "und" means "undetermined", so when I encounter it I don't know > whether the content contains one language, many languages, or no > language. The tag "zxx" would mean that there is no language content, > "mis" would mean that there is at least some language content, and "mul" > would mean that there is language content, with more than one language. I'm okay with all of this except "mis". "mis" is a collection code, as I explained, and means "languages that don't belong to any other collection." It is not the universal collection. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 12 23:11: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 1HcCBg-0004df-Gt; Thu, 12 Apr 2007 23:11:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcCBf-0004da-Up for ltru@lists.ietf.org; Thu, 12 Apr 2007 23:10:59 -0400 Received: from bay0-omc2-s5.bay0.hotmail.com ([65.54.246.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcCBe-0003RI-Iv for ltru@lists.ietf.org; Thu, 12 Apr 2007 23:10:59 -0400 Received: from hotmail.com ([65.54.169.26]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 12 Apr 2007 20:10:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Apr 2007 20:10:57 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Fri, 13 Apr 2007 03:10:57 GMT X-Originating-IP: [72.150.213.37] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <461EAE37.1C7A@xyzzy.claranet.de> From: "CE Whitehead" To: nobody@xyzzy.claranet.de, www-international@w3.org Bcc: Date: Thu, 12 Apr 2007 23:10:57 -0400 Mime-Version: 1.0 X-OriginalArrivalTime: 13 Apr 2007 03:10:57.0809 (UTC) FILETIME=[5B356810:01C77D79] X-Spam-Score: 1.9 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0859487160==" Errors-To: ltru-bounces@ietf.org --===============0859487160== Content-Type: text/html; format=flowed

Hi, my comments are below; I still sort of think that there may need to be some clarification about mis and und.

>
>Kent Karlsson wrote:
>
> > da.xml: <language type="und">Sproget kan ikke bestemmes</language>
> > de.xml: <language type="und">Sprache nicht ermittelt</language>
> > it.xml: <language type="und">lingua imprecisata</language>
> > sv.xml: <language type="und">obestamt sprak</language>
>
>For the German version I'd say that's "language not identified".
>
> > Perhaps those ones should be retranslated not to refer to language,
> > **if** "und" may apply also to "maybe not in any language".
>
>I don't understand *_why_* anything about it should be changed.
>
>If the process to identify / determine a language failed so far,
>the final outcome can be still "no language at all", i.e. "zxx".
>
>And that's precisely what Richard needs for those cases where an
>empty string is (still) syntactically invalid, as in XHTML 1.0.

Frank,  the question for me is still: when is und recommended over "zxx"?

(I personally still want a clearer meaning for und; the meaning of zxx is clear to me)

Also I have questions about mis (miscellaneous)  (I agree with John's definition of miscellanous; that's the English definition; but there is nothing in the registry to indicate that mis refers to any collection of languages--it's just a three-letter subtag--so I have to say that what I get for mis is exactly what Mark gets,  maybe some language content; if so and if zxx means no known language content, then und may be redundant (caution:  this is an outside opinion from someone with limited programming skills).

 

Here's the registration for mis:

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

Type: language

Subtag: mis

Description: Miscellaneous languages

Added: 2005-10-16

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

Mark Davis mark.davis@icu-project.org

> I think I agree with you in spirit, but not in precise details. The tag "und" means

> "undetermined", so when I encounter it I don't know whether the content contains > one language, many languages, or no language.

+1 that is what I get from this, too, exactly.

> The tag "zxx" would mean that

> there is no language content, "mis" would mean that there is at least some language > content, and "mul" would mean that there is language content, with more than one > language.

John Cowan http://www.ccil.org/~cowan

> I'm okay with all of this except "mis". "mis" is a collection code, as I explained, and means "languages that

> don't belong to any other collection." It is not the universal collection.


--C. E. Whitehead

cewcathar@hotmail.com


Exercise your brain! Try Flexicon. --===============0859487160== 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 --===============0859487160==-- From ltru-bounces@ietf.org Fri Apr 13 00:18: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 1HcDEk-00038n-0g; Fri, 13 Apr 2007 00:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcDEi-00038i-B6 for ltru@lists.ietf.org; Fri, 13 Apr 2007 00:18:12 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcDEg-0005ad-3X for ltru@lists.ietf.org; Fri, 13 Apr 2007 00:18:12 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcDEb-0007If-Eh; Fri, 13 Apr 2007 00:18:05 -0400 Date: Fri, 13 Apr 2007 00:18:05 -0400 To: CE Whitehead Subject: Re: [Ltru] Re: For review: Tagging text with no language Message-ID: <20070413041805.GD7353@mercury.ccil.org> References: <461EAE37.1C7A@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nobody@xyzzy.claranet.de, www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org CE Whitehead scripsit: > Also I have questions about mis (miscellaneous) > (I agree with John's definition of miscellanous; that's the English > definition; but there is nothing in the registry to indicate > that mis refers to any collection of languages--it's just a > three-letter subtag--so I have to say that what I get for mis is > exactly what Mark gets, maybe some language content; It comes from ISO 639-2, and when English names from 639-2 contain "languages" or "(Other)", then they are collections. See the normative text at http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1. Even though the registry doesn't contain semantics, the subtags there inherit their semantics from the corresponding ISO codes. -- Normally I can handle panic attacks on my own; John Cowan but panic is, at the moment, a way of life. http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 00:28: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 1HcDOW-0001Ln-VE; Fri, 13 Apr 2007 00:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcDOV-0001La-Mu for ltru@ietf.org; Fri, 13 Apr 2007 00:28:19 -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 1HcDOU-0007Gn-Cq for ltru@ietf.org; Fri, 13 Apr 2007 00:28:19 -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 <20070413042817.SZQG6560.mta15.adelphia.net@DGBP7M81> for ; Fri, 13 Apr 2007 00:28:17 -0400 Message-ID: <001101c77d84$2e4e0a90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Apr 2007 21:28:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 the one thing we want to *avoid* doing, as a result of this thread, is defining the empty string "" as a valid language tag or associating it with any particular meaning. "" is a placeholder, not a real language tag. -- 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 Apr 13 00:41: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 1HcDb5-0001Zi-T9; Fri, 13 Apr 2007 00:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcDb3-0001ZX-Ob for ltru@ietf.org; Fri, 13 Apr 2007 00:41:17 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcDb2-0000XZ-HL for ltru@ietf.org; Fri, 13 Apr 2007 00:41:17 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcDao-0000GI-N7; Fri, 13 Apr 2007 00:41:02 -0400 Date: Fri, 13 Apr 2007 00:41:02 -0400 To: Stephen Deach Subject: Re: [Ltru] RE: For review: Tagging text with no language Message-ID: <20070413044102.GG7353@mercury.ccil.org> References: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group , CLDR list , www-international@w3.org, Asmus Freytag , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephen Deach scripsit: > "mis" means it is "a language but I have no better identifier for it". Well, "a known language for which no better identifier exists". It would be, as I keep saying, an error to tag German ("de") or Kiowa ("nai" or "nai-x-kio" or "nai-x-kiowa") as "mis". > One can have a separate debate over whether "zxx" or "art" should be > used for computer-programming languages, or whether computer-programming > (as a group or individually) deserve their own tag(s); but that is > not an "Internationalization" issue. BCP 47 explicitly excludes computer languages from its scope, as do the ISO 639 family of standards. So "zxx" is the only available tag. -- John Cowan cowan@ccil.org http://ccil.org/~cowan It's the old, old story. Droid meets droid. Droid becomes chameleon. Droid loses chameleon, chameleon becomes blob, droid gets blob back again. It's a classic tale. --Kryten, Red Dwarf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 01:23: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 1HcEGG-0002T0-1v; Fri, 13 Apr 2007 01:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEGD-0002Sp-5s for ltru@ietf.org; Fri, 13 Apr 2007 01:23:49 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEGB-0000dC-B4 for ltru@ietf.org; Fri, 13 Apr 2007 01:23:49 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 12 Apr 2007 22:23:46 -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, 12 Apr 2007 22:23:46 -0700 From: Peter Constable To: Mark Davis , Martin Hosken Date: Thu, 12 Apr 2007 22:23:45 -0700 Subject: RE: [Ltru] RE: For review: Tagging text with no language Thread-Topic: [Ltru] RE: For review: Tagging text with no language Thread-Index: Acd9J1QvAWXNz1gSR3Op06PSj5x6CQAZIRdQ Message-ID: References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <461E6709.2020601@sil.org> <30b660a20704121023s68658e6at7c08ac65de945e56@mail.gmail.com> In-Reply-To: <30b660a20704121023s68658e6at7c08ac65de945e56@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: 8a4bcf8f67063cac573319207fe3db35 Cc: "www-international@w3.org" , 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="===============0202157280==" Errors-To: ltru-bounces@ietf.org --===============0202157280== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87CCNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87CCNAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed - seems pretty obvious to me. Peter ________________________________ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Thursday, April 12, 2007 10:24 AM To: Martin Hosken Cc: LTRU Working Group; www-international@w3.org Subject: Re: [Ltru] RE: For review: Tagging text with no language For that, I'd suggest und-Latn (or whatever the script is). Since only lang= uages would have scripts, that is sufficiently determinate. On 4/12/07, Martin Hosken > wrote: Dear All, >> Q1. What tag should be used where it is definitely a language, but there >> is no code available yet? (This is an area where ISO 15924 is ahead >> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) >> A related question is how to tag text that is definitely in a language but I don't know what the language is. (But I might know the script). Yours, Martin -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87CCNAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed – seems pretty obvious = to me.

 

 

Peter

 

From: Mark Dav= is [mailto:mark.davis@icu-project.org]
Sent: Thursday, April 12, 20= 07 10:24 AM
To: Martin Hosken
Cc: LTRU Working Group; www-international@w3.org
Subject: Re: [Ltru] RE: For review: Tagging text with no language

 

For that, I'd sug= gest und-Latn (or whatever the script is). Since only languages would have scrip= ts, that is sufficiently determinate.

On 4/12/07, = Martin Hosken <martin_hoske= n@sil.org> wrote:

Dear All,

>> Q1. What tag should be used where it is definitely a language, but there
>> is no code available yet? (This is an area where ISO 15924 is ahea= d
>> of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.= )
>>

A related question is how to tag text that is definitely in a language
but I don't know what the language is. (But I might know the script).

Yours,
Martin




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87CCNAEXMSGC117re_-- --===============0202157280== 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 --===============0202157280==-- From ltru-bounces@ietf.org Fri Apr 13 01:26: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 1HcEIb-0003f4-SR; Fri, 13 Apr 2007 01:26:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEIZ-0003ej-Uj for ltru@ietf.org; Fri, 13 Apr 2007 01:26:15 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEIY-0001IO-7q for ltru@ietf.org; Fri, 13 Apr 2007 01:26:15 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 12 Apr 2007 22:26:13 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 12 Apr 2007 22:26:13 -0700 From: Peter Constable To: Mark Davis , John Cowan Date: Thu, 12 Apr 2007 22:26:12 -0700 Subject: RE: [Ltru] RE: For review: Tagging text with no language Thread-Topic: [Ltru] RE: For review: Tagging text with no language Thread-Index: Acd9KCHbhlMMTQvbSRqUcvDInxh0UwAY9VKQ Message-ID: References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> In-Reply-To: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@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: fbe0995f04cc21309ef8614a2838e306 Cc: LTRU Working Group , "www-international@w3.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103905770==" Errors-To: ltru-bounces@ietf.org --===============2103905770== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87D0NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87D0NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a difference between 'no information provide', and 'information is= provided: this is unknown'. I don't see what the issue is; I guess I must have missed the start of this= thread. Peter ________________________________ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Thursday, April 12, 2007 10:29 AM To: John Cowan Cc: www-international@w3.org; LTRU Working Group Subject: Re: [Ltru] RE: For review: Tagging text with no language Q1. I had missed the choice of "mis". I agree with that suggestion; we shou= ld incorporate that into 4646bis. The problem is ameliorated considerably o= nce we add -3, but it doesn't disappear completely, so "mis" remains a good= choice for dealing with that situation. Q2. The issue *does* remain, since we talk about "und" vs the absence of a = language tag, which "" represents. Mark On 4/12/07, John Cowan > wrote: Mark Davis scripsit: > The summary looks good. This discussion raises 2 items for the LTRU > group. > > Q1. What tag should be used where it is definitely a language, but there > is no code available yet? (This is an area where ISO 15924 is ahead > of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.) In principle, every natural-language item (text, audio, video) can be coded with some 639-2 code; if the language does not have a code of its own, it will belong to one of the 639-2 collections. For example, the language Tarifit (639-3 code 'rif') does not have a 639-2 code, but it is a Berber language; consequently, an item in Tarifit may be validly tagged 'ber', which represents the collection of Berber languages. Similarly, the language Zumbun (639-3 code 'jmb') does not have an 639-2 code, nor does it belong to any of the smaller 639-2 collections, but it does belong to the Afro-Asiatic language family; consequently, an item in Zumbun may be validly tagged 'afa', which represents the collection of Afro-Asiatic languages. If all else fails, as for the language isolate Burushaski (639-3 code 'bsk'), the 639-2 collection code 'mis', representing the collection of miscellaneous languages, may be applied. This is the ultimate fallback code, indicating that the language is known but nothing useful can be said about it using 639-2 codes. All of this lore, which represents the practice of the Library of Congress (the ultimate source of 639-2), can of course go away when RFC 4646bis goes into effect. If it is necessary to be more specific before then, and if strict compliance to 4646 is required, then rif-x-tarifit, afa-x-jumbun, and mis-x-burushas may also be used. > Q2. Clarify the wording around "und" vs "". "" is not a well-formed language tag according to RFC 4646, so there is nothing to say about it there. It is defined by the XML Recommendation as an extension to the set of language tags, and having the same significance as no language declaration at all. -- Dream projects long deferred John Cowan < cowan@ccil.org> usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87D0NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is a difference between ‘= ;no information provide’, and ‘information is provided: this is unknown’.=

 

I don’t see what the issue is;= I guess I must have missed the start of this thread.=

 

 

Peter

 

From: Mark Dav= is [mailto:mark.davis@icu-project.org]
Sent: Thursday, April 12, 20= 07 10:29 AM
To: John Cowan
Cc: www-international@w3.org= ; LTRU Working Group
Subject: Re: [Ltru] RE: For review: Tagging text with no language

 

Q1. I had missed = the choice of "mis". I agree with that suggestion; we should incorpor= ate that into 4646bis. The problem is ameliorated considerably once we add -3, = but it doesn't disappear completely, so "mis" remains a good choice f= or dealing with that situation.

Q2. The issue *does* remain, since we talk about "und" vs the abs= ence of a language tag, which "" represents.

Mark

On 4/12/07, = John Cowan <cowan@ccil.org&g= t; wrote:

Mark Davis scripsit:

> The summary looks good. This discussion raises 2 items for the LTRU > group.
>
> Q1. What tag should be used where it is definitely a language, but the= re
> is no code available yet? (This is an area where ISO 15924 is ahead > of ISO 639 (and 3166), since it has Zzzz: Code for uncoded script.)
In principle, every natural-language item (text, audio, video) can be
coded with some 639-2 code; if the language does not have a code of its own, it will belong to one of the 639-2 collections.

For example, the language Tarifit (639-3 code 'rif') does not have a 639-2<= br> code, but it is a Berber language; consequently, an item in Tarifit may be =
validly tagged 'ber', which represents the collection of Berber languages.<= br> Similarly, the language Zumbun (639-3 code 'jmb') does not have an 639-2 code, nor does it belong to any of the smaller 639-2 collections, but it does belong to the Afro-Asiatic language family; consequently, an item
in Zumbun may be validly tagged 'afa', which represents the collection
of Afro-Asiatic languages.

If all else fails, as for the language isolate Burushaski (639-3 code
'bsk'), the 639-2 collection code 'mis', representing the collection of
miscellaneous languages, may be applied.  This is the ultimate fallback
code, indicating that the language is known but nothing useful can be
said about it using 639-2 codes.

All of this lore, which represents the practice of the Library of Congress<= br> (the ultimate source of 639-2), can of course go away when RFC 4646bis
goes into effect.  If it is necessary to be more specific before then,
and if strict compliance to 4646 is required, then rif-x-tarifit,
afa-x-jumbun, and mis-x-burushas may also be used.

> Q2. Clarify the wording around "und" vs "".

"" is not a well-formed language tag according to RFC 4646, so th= ere is
nothing to say about it there.  It is defined by the XML Recommendation as
an extension to the set of language tags, and having the same significance<= br> as no language declaration at all.

--
Dream projects long deferred           &= nbsp; John Cowan < cowan@ccil.org> usually bite the wax tadpole.           &= nbsp;http://www.ccil.org/~cowan
        --James Lileks




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87D0NAEXMSGC117re_-- --===============2103905770== 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 --===============2103905770==-- From ltru-bounces@ietf.org Fri Apr 13 01:27: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 1HcEK0-00047t-9N; Fri, 13 Apr 2007 01:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEJy-00046y-LR for ltru@ietf.org; Fri, 13 Apr 2007 01:27:42 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEJv-0001Qw-9j for ltru@ietf.org; Fri, 13 Apr 2007 01:27:42 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 12 Apr 2007 22:27:38 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Thu, 12 Apr 2007 22:27:38 -0700 From: Peter Constable To: John Cowan , Mark Davis Date: Thu, 12 Apr 2007 22:27:37 -0700 Subject: RE: [Ltru] RE: For review: Tagging text with no language Thread-Topic: [Ltru] RE: For review: Tagging text with no language Thread-Index: Acd9NFTJE9jRSy+oTTyFj67GVXev/gAWBlrw Message-ID: References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> In-Reply-To: <20070412185629.GG16269@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: LTRU Working Group , "www-international@w3.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Peter > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Thursday, April 12, 2007 11:56 AM > To: Mark Davis > Cc: www-international@w3.org; LTRU Working Group > Subject: Re: [Ltru] RE: For review: Tagging text with no language > > Mark Davis scripsit: > > > Q1. I had missed the choice of "mis". I agree with that suggestion; > > we should incorporate that into 4646bis. The problem is ameliorated > > considerably once we add -3, but it doesn't disappear completely, so > > "mis" remains a good choice for dealing with that situation. > > I did not mean to suggest that "mis" is suitable in cases of ignorance > about the language in use: it is not a fallback *language* code. Rather, > it is a fallback language *collection* code, suitable for languages that > don't appear in any other ISO 639-2 collection. By the Ethnologue's > count, there are about 130 of these. > > So it would be an error to tag a language you didn't recognize as 'mis', > because it is far more likely to be one of the non-'mis' languages, for > the same reason that it would be incorrect to use 'en' or 'nds' or 'afa'. > If you want a completely vague language tag, use 'und' (excluding for > the moment the question of whether non-linguistic content not recognized > as such can be tagged 'und'). > > > Q2. The issue *does* remain, since we talk about "und" vs the absence > > of a language tag, which "" represents. > > I still don't see that there's anything more to say than we are > saying already, which is just a special case of "Tag wisely". > > -- > I now introduce Professor Smullyan, John Cowan > who will prove to you that either cowan@ccil.org > he doesn't exist or you don't exist, http://www.ccil.org/~cowa= n > but you won't know which. --Melvin Fitting > > _______________________________________________ > 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 Apr 13 01:41: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 1HcEXe-0005lA-6W; Fri, 13 Apr 2007 01:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEXc-0005kx-DT for ltru@ietf.org; Fri, 13 Apr 2007 01:41:48 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEXb-0003sc-Bf for ltru@ietf.org; Fri, 13 Apr 2007 01:41:48 -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.685.24; Thu, 12 Apr 2007 22:41:46 -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, 12 Apr 2007 22:41:46 -0700 From: Peter Constable To: Stephen Deach , Mark Davis Date: Thu, 12 Apr 2007 22:41:45 -0700 Subject: RE: [Ltru] RE: For review: Tagging text with no language Thread-Topic: [Ltru] RE: For review: Tagging text with no language Thread-Index: Acd9e02zvIsvI2Y4RcWUaV0b6qkwGAAEitdg Message-ID: References: <20070411183743.GA29567@mercury.ccil.org> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> In-Reply-To: <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.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: 441502cf25997484ff0b8b79626c6b69 Cc: LTRU Working Group , CLDR list , "www-international@w3.org" , Asmus Freytag , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810026952==" Errors-To: ltru-bounces@ietf.org --===============0810026952== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87DDNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87DDNAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ISO 639 indicates that programming languages are out of scope. I interpret = that to mean that no programming language or group of programming languages= is positively represented - i.e. none of the entities represented (either = individually or as part of a group) is a programming language. I interpret = "zxx" to mean "the content so tagged is not any instance of the kind of ent= ities encompassed by this coding standard". That would entail that "zxx" co= uld appropriately be applied to content that is in a programming language w= ith as much appropriateness as applying it to a part number or random text = or an empty file or telemetry from a space probe: you may or may not be abl= e to interpret the content, but you certainly cannot interpret it in terms = of any human language. Peter ________________________________ From: www-international-request@w3.org [mailto:www-international-request@w3= .org] On Behalf Of Stephen Deach Sent: Thursday, April 12, 2007 8:23 PM To: Mark Davis; Stephen Deach Cc: Kent Karlsson; Asmus Freytag; John Cowan; Richard Ishida; LTRU Working = Group; www-international@w3.org; CLDR list Subject: Re: [Ltru] RE: For review: Tagging text with no language My point was intended to be that this started out as a debate on the interp= retation of "". I don't see that any existing tag other than "und" makes an= y sense as an alternate interpretation of "", so why the long debate and th= e discussion of the various re-translations of what "und" means in Danish, = Swedish, German, Italian, et al. (At the nuance level of this discussion, s= uch translations are ALWAYS imperfect.) I have no objection to your interpretations of what happens if someone ex= plicitly says "mis", "mul", etc. I woudl note that "und" makes no statement of whether the content is a si= ngle or several languages, only that any/all language information is "not d= efined" for the specified scope. If the user says nothing or says xml:lang=3D"", it can't mean anything othe= r than "undefined" (for which the tag is "und") or "unspecified" (for which= there is no tag; regardless of whether the user intent was "I don't know" = vs "I don't care" vs "I don't want to guess" vs "I don't want to say"; and = regardless of if it is all a single language or a mixture of several langua= ges). The tag "und" means that no input regarding the language is (language= s are) provided. Why not say no xml:lang specifier and xml:lang=3D"" are bo= th interpreted as xml:lang=3D"und" and be done with it. It is quite clear that "zxx" means "I know this is not a linguistic"; that = "art" means it is "an artificial language (invented or other non-natural la= nguage)"; that "mul" means "there are a mixture of languages which I may or= may not choose to identify at a lower level in the document"; and that "mi= s" means it is "a language but I have no better identifier for it". One can have a separate debate over whether "zxx" or "art" should be used f= or computer-programming languages, or whether computer-programming (as a gr= oup or individually) deserve their own tag(s); but that is not an "Internat= ionalization" issue. At 2007.04.12-18:15(-0700), Mark Davis wrote: I think I agree with you in spirit, but not in precise details. The tag "un= d" means "undetermined", so when I encounter it I don't know whether the co= ntent contains one language, many languages, or no language. The tag "zxx" = would mean that there is no language content, "mis" would mean that there i= s at least some language content, and "mul" would mean that there is langua= ge content, with more than one language. I think to try to consider what the motivations of the tagger are may lead = to misleading impressions. Assume for the moment that the tag is correct. F= rom the perspective of the tagger, using "und" could mean, as you say, that= the tagger doesn't know or care (or want to communicate, or what to spend = the time to determine) what the language is or whether there is any languag= e content there at all. There could be quite a variety of motivations for t= he tagger's using "und"; the key is what the reader of "und" can assume abo= ut the content, which is essentially nothing. With "mis", the situation is = similar, but slightly narrower. The tagger may still not know much, or care= much, but maybe cared enough to determine that there was something there, = or maybe there was language content there, but there is no language code th= at correctly matches it (protogermanic, perhaps). Similarly, using "may not" language is a bit too strong in your phrase "Whe= reas zxx says I 'may not' apply any of those language-based services becaus= e it is not a 'natural' language". Having content tagged with "zxx" doesn't= restrict me from doing anything I want to; it just means if it was tagged = correctly, it does not contain any language content. (I might decide that t= he tagger was mistaken -- when we at Google look at the tagging people actu= ally do of web content, there is a fairly high percentage of both invalid t= ags and valid-but-incorrect tags.) Mark On 4/12/07, Stephen Deach > wrote= : I think much of this discussion is dealing with terminology differences tha= t are so narrow that one is discussing "the number of angels who can dance = on the head of a pin". (In other words we are debating theology, not practi= ce.) In reality, specifications are worded as carefully as possible, but in= terpretation is open to the reader's most common definition/redefinition/tr= anslation of the exact terminology. -- So rather than debate what the "exa= ct meaning" of a word/phrase is in each of these languages, maybe we should= take a looser interpretation of what is written and then clarify the inten= t. My reading of the ISO spec is that "und/undetermined" means "I don't know (= or care, or am unwilling to state) what the language is (and have no closer= alternative language identifier given the available options)". From a prac= tical viewpoint, "und" indicates I can't assume any specific/preferred ling= uistic definitions for words in the content, nor can I assume any specific/= preferred pronunciation-, spelling-, hyphenation-, and/or grammar-rules on = the content; though I am allowed to attempt my own linguistic analysis to g= uess at the language. (Whereas zxx says I 'may not' apply any of those lang= uage-based services because it is not a 'natural' language and should not a= ttempt any linguistic analysis to guess at the language.) I can't see any p= ractical difference between "und" and "" (except that "" is disallowed in s= ome processing environments) so why can't the documents simply say that 'a = missing specification' or 'xml:lang=3D""' (should either occur), will be in= terpreted as "und". It has been a while since I considered myself fluent in Swedish (and I inte= ntionally ignored the lack of the dieresis in the original text as an indic= ation that the translations were "lossy"). I just thought that some comment= would force the necessary clarification of the translations. At 2007.04.13-01:26(+0200), Kent Karlsson wrote: Stephen Deach wrote: > sv.xml: obest=C3=A4mt spr=C3= =A5k I thought "obestamt" was "unstated". "Obest=C3=A4mt" literally means "undetermined". "Unstated" would be "osagt"= , "outtalat", or "ej angett" ("not given", closer to the current German translation). Though I would agree that xml:lang=3D"" is closer to "unstated" than "undet= ermined". I'm not sure that that nit-picking leads anywhere in this case. But "unstated" is not th= e same as "undetermined"; it may well be determined, but just not stated... So maybe there is a diffe= rence worth bothering about. /kent k ---Steve Deach sdeach@adobe.com -- Mar ---Steve Deach sdeach@adobe.com --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87DDNAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

ISO 639 indicates that programming l= anguages are out of scope. I interpret that to mean that no programming language or group of programming languages is positively represented – i.e. none = of the entities represented (either individually or as part of a group) is a programming language. I interpret “zxx= 221; to mean “the content so tagged is not any instance of the kind of ent= ities encompassed by this coding standard”. That would entail that “<= span class=3DSpellE>zxx” could appropriately be applied to content = that is in a programming language with as much appropriateness as applying it to= a part number or random text or an empty file or telemetry from a space probe= : you may or may not be able to interpret the content, but you certainly cann= ot interpret it in terms of any human language.

 

 

Peter

 

From: www-international-request@w3.org [mailto:www-international-request@w3.org] = On Behalf Of Stephen Deach
Sent: Thursday, April 12, 20= 07 8:23 PM
To: Mark Davis; Stephen Deac= h
Cc: Kent Karlsson; Asmus Fre= ytag; John Cowan; Richard Ishida; LTRU Working Group; www-international@w3.org; C= LDR list
Subject: Re: [Ltru] RE: For review: Tagging text with no language

 

My point was intended to be that this started out as a debate on th= e interpretation of "". I don't see that any existing tag other tha= n "und" makes any sense as an alternate interpretation of "&qu= ot;, so why the long debate and the discussion of the various re-translations of what "und" means in Danish, Swedish, German, Italian, et al. (At = the nuance level of this discussion, such translations are ALWAYS imperfect.) <= br>   I have no objection to your interpretations of what happens if someo= ne explicitly says "mis", "mul", etc.
  I woudl note that "und" makes no statement of whether the content is a single or several languages, only that any/all language information is "not defined" for the specified scope.

If the user says nothing or says xml:lang=3D"", it can't mean any= thing other than "undefined" (for which the tag is "und") or "unspecified" (for which there is no tag; regardless of whether t= he user intent was "I don't know" vs "I don't care" vs &qu= ot;I don't want to guess" vs "I don't want to say"; and regardles= s of if it is all a single language or a mixture of several languages). The tag "und" means that no input regarding the language is (languages ar= e) provided. Why not say no xml:lang specifier and xml:lang=3D"" are= both interpreted as xml:lang=3D"und" and be done with it.

It is quite clear that "zxx" means "I know this is not a linguistic"; that "art" means it is "an artificial lang= uage (invented or other non-natural language)"; that "mul" means "there are a mixture of languages which I may or may not choose to ide= ntify at a lower level in the document"; and that "mis" means it i= s "a language but I have no better identifier for it".

One can have a separate debate over whether "zxx" or "art&qu= ot; should be used for computer-programming languages, or whether computer-prog= ramming (as a group or individually) deserve their own tag(s); but that is not an "Internationalization" issue.


At 2007.04.12-18:15(-0700), Mark Davis wrote:

I think I agree with you in spirit, but not in precise details. The= tag "und" means "undetermined", so when I encounter it I do= n't know whether the content contains one language, many languages, or no langu= age. The tag "zxx" would mean that there is no language content, "mis" would mean that there is at least some language content, an= d "mul" would mean that there is language content, with more than o= ne language.

I think to try to consider what the motivations of the tagger are may lead = to misleading impressions. Assume for the moment that the tag is correct. From= the perspective of the tagger, using "und" could mean, as you say, th= at the tagger doesn't know or care (or want to communicate, or what to spend t= he time to determine) what the language is or whether there is any language content there at all. There could be quite a variety of motivations for the tagger's using "und"; the key is what the reader of "und&quo= t; can assume about the content, which is essentially nothing. With "mis", the situation is similar, but slightly narrower. The tagge= r may still not know much, or care much, but maybe cared enough to determine = that there was something there, or maybe there was language content there, but t= here is no language code that correctly matches it (protogermanic, perhaps).
Similarly, using "may not" language is a bit too strong in your phrase "Whereas zxx says I 'may not' apply any of those language-based services because it is not a 'natural' language". Having content tagge= d with "zxx" doesn't restrict me from doing anything I want to; it = just means if it was tagged correctly, it does not contain any language content.= (I might decide that the tagger was mistaken -- when we at Google look at the tagging people actually do of web content, there is a fairly high percentag= e of both invalid tags and valid-but-incorrect tags.)

Mark

On 4/12/07, Stephen Deach &l= t;sdeach@adobe.com> wrote:=

I think much of this discussion is dealing with terminology differences that are so narrow that one is discussing "the number of angels who can dance on the head of a pin". (In other words = we are debating theology, not practice.) In reality, specifications are worded= as carefully as possible, but interpretation is open to the reader's most comm= on definition/redefinition/translation of the exact terminology.  -- So rather than debate what the "exact meaning" of a word/phrase is i= n each of these languages, maybe we should take a looser interpretation of wh= at is written and then clarify the intent.

My reading of the ISO spec is that "und/undetermined" means "I don't know (or care, or am unwil= ling to state) what the language is (and have no closer alternative language identifier given the available options)". From a practical viewpoint, "und" indicates I can't assume any specific/preferred linguistic definitions for words in the content, nor can I assume any specific/preferr= ed pronunciation-, spelling-, hyphenation-, and/or grammar-rules on the conten= t; though I am allowed to attempt my own linguistic analysis to guess at the language. (Whereas zxx says I 'may not' apply any of those language-based services because it is not a 'natural' language and should not attempt any linguistic analysis to guess at the language.) I can't see any practical difference between "und" and "" (except that "&quo= t; is disallowed in some processing environments) so why can't the documents simply say that 'a missing specification' or 'xml:lang=3D""' (sho= uld either occur), will be interpreted as "und".

It has been a while since I considered myself fl= uent in Swedish (and I intentionally ignored the lack of the dieresis in the ori= ginal text as an indication that the translations were "lossy"). I just thought that some comment would force the necessary clarification of the translations.


At 2007.04.13-01:26(+0200), Kent Karlsson wrote:=

Stephen Deach wrote:

> sv.xml:           &n= bsp;           <language type=3D"und">obest=C3=A4mt spr=C3=A5k</languag= e>

 

I thought "obestamt" was "unstated".

"Obest=C3=A4mt" literally means "undetermined&qu= ot;. "Unstated" would be "osagt", "outtalat", or "ej angett"

("not given", closer to the current German translatio= n).

 

Though I would agree that xml:lang=3D"" is closer to "unstated" than "undetermined". I'm not sure=

that that nit-picking leads anywhere in this case. But "unstated" is not the same as "undetermined";

it may well be determined, but just not stated... So maybe ther= e is a difference worth bothering about.

 

        /kent k

 

 

---Steve Deach

   sdeach@adobe.com




--
Mar


---Steve Deach
   sdeach@adobe.com

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B87DDNAEXMSGC117re_-- --===============0810026952== 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 --===============0810026952==-- From ltru-bounces@ietf.org Fri Apr 13 06:53: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 1HcJOq-0003Fd-OT; Fri, 13 Apr 2007 06:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJOT-0002pr-3J for ltru@lists.ietf.org; Fri, 13 Apr 2007 06:52:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcJLv-0000Yf-Q8 for ltru@lists.ietf.org; Fri, 13 Apr 2007 06:50:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcJLs-0004II-9A for ltru@lists.ietf.org; Fri, 13 Apr 2007 12:50:00 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 12:50:00 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 12:50:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 12:48:23 +0200 Organization: Lines: 22 Message-ID: <461F5FF7.6A90@xyzzy.claranet.de> References: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> <20070413044102.GG7353@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > BCP 47 explicitly excludes computer languages from its scope, as do > the ISO 639 family of standards. So "zxx" is the only available tag. Tagging source code snippets as "zxx" would be barbaric. But it's a case where "" is clearly better than "und". Actually I think "" is always better than "und" unless I intend to flag something for later review. In the context of Richard's article and XML documents, for other purposes it might be different. The use of "und" in XHTML 1.0 is IMO only a temporary kludge until the DTD is fixed. Doug argued that "" is a placeholder, I think it's not in XML, it has a clear effect of breaking any inherited xml:lang, resetting anything interested in language tags (CSS, spell checkers, Web crawlers, etc.) to their default "no language specified" behaviour. It's IMO perfectly okay to have very different styles for "i-default", "und", "zxx", "art", "mul", etc. With "" meaning "none of those". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 07:05: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 1HcJab-0004TS-G8; Fri, 13 Apr 2007 07:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJaa-0004Qa-6A for ltru@lists.ietf.org; Fri, 13 Apr 2007 07:05:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcJaY-0007dN-TS for ltru@lists.ietf.org; Fri, 13 Apr 2007 07:05:12 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HcJaR-0007Tb-2C for ltru@lists.ietf.org; Fri, 13 Apr 2007 13:05:03 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 13:05:03 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 13:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 12:56:46 +0200 Organization: Lines: 11 Message-ID: <461F61EE.1BF@xyzzy.claranet.de> References: <461EAE37.1C7A@xyzzy.claranet.de> <20070413041805.GD7353@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf-languages@alvestrand.no Subject: [Ltru] mis (was: For review: Tagging text with no language) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Even though the registry doesn't contain semantics, the subtags > there inherit their semantics from the corresponding ISO codes. Your "mis" explanation sounded interesting enough to deserve a comment in the registry, something along the line of "whatever you think 'mis' is, it's most likely wrong". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 07:56: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 1HcKOA-0003kS-71; Fri, 13 Apr 2007 07:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKO9-0003kN-DC for ltru@lists.ietf.org; Fri, 13 Apr 2007 07:56:25 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKO8-0004Wa-33 for ltru@lists.ietf.org; Fri, 13 Apr 2007 07:56:25 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HcKMo-000184-Te for ltru@lists.ietf.org; Fri, 13 Apr 2007 13:55:02 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 13:55:02 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 13:55:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 13:52:41 +0200 Organization: Lines: 16 Message-ID: <461F6F09.51B8@xyzzy.claranet.de> References: <461EAE37.1C7A@xyzzy.claranet.de> <20070413041805.GD7353@mercury.ccil.org> <461F61EE.1BF@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf-languages@alvestrand.no Subject: [Ltru] "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Frank Ellermann 2. E-mail address of requester: nobody@xyzzy.claranet.de 3. Record Requested: Type: language Subtag: mis Description: Miscellaneous Languages Comments: A collection of languages which don't belong to any other collection 4. Intended meaning of the subtag: n/a (no change) 5. Reference to published description of the language (book or article): http://permalink.gmane.org/gmane.ietf.ltru/7478 6. Any other relevant information: n/a (comment added) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 09:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLpD-0004jf-Ap; Fri, 13 Apr 2007 09:28:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLpB-0004i5-Uq for ltru@lists.ietf.org; Fri, 13 Apr 2007 09:28:25 -0400 Received: from mail.arena1.com ([63.116.216.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLp9-0005SZ-Hb for ltru@lists.ietf.org; Fri, 13 Apr 2007 09:28:25 -0400 Received: from UnknownHost [83.70.80.115] by mail.arena1.com with SMTP; Fri, 13 Apr 2007 09:28:07 -0400 Message-ID: <461F8533.4070406@hackcraft.net> Date: Fri, 13 Apr 2007 14:27:15 +0100 From: Jon Hanna User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ltru@lists.ietf.org, www-international@w3.org References: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> <20070413044102.GG7353@mercury.ccil.org> <461F5FF7.6A90@xyzzy.claranet.de> In-Reply-To: <461F5FF7.6A90@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [83.70.80.115] X-Declude-Spoolname: 2102425332745.eml X-Declude-RefID: X-Declude-Note: Scanned by Declude 4.3.14 for spam. "http://www.declude.com/x-note.htm" X-Declude-Scan: Score [4] at 09:28:15 on 13 Apr 2007 X-Declude-Fail: Whitelisted X-Country-Chain: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Tagging source code snippets as "zxx" would be barbaric. Source code snippets often do contain no linguistic data. However the following is in English: alert("This is English");//This comment is English too. > Doug argued that "" is a placeholder, I think it's not in XML, it has > a clear effect of breaking any inherited xml:lang, resetting anything > interested in language tags (CSS, spell checkers, Web crawlers, etc.) > to their default "no language specified" behaviour. Agreed. > It's IMO perfectly okay to have very different styles for "i-default", > "und", "zxx", "art", "mul", etc. With "" meaning "none of those". I still don't buy that "" != "und". If "" != "und" then the RFC is buggy, since it clearly requires that the latter not be used if a protocol permits the former - a decision which only makes sense if they are equivalent. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 10:12: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 1HcMVr-0006mo-EL; Fri, 13 Apr 2007 10:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMVp-0006me-R9 for ltru@lists.ietf.org; Fri, 13 Apr 2007 10:12:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMVo-00041D-CK for ltru@lists.ietf.org; Fri, 13 Apr 2007 10:12:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcMVc-0003s5-QB for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:12:16 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 16:12:16 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 16:12:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 16:07:33 +0200 Organization: Lines: 54 Message-ID: <461F8EA5.3079@xyzzy.claranet.de> References: <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <6.1.1.1.2.20070412193301.02173618@namailhost.corp.adobe.com> <20070413044102.GG7353@mercury.ccil.org> <461F5FF7.6A90@xyzzy.claranet.de> <461F8533.4070406@hackcraft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jon Hanna wrote: >> Tagging source code snippets as "zxx" would be barbaric. > Source code snippets often do contain no linguistic data. > However the following is in English: > alert("This is English");//This comment is English too. Maybe. It also depends on what you're doing. If your task is "translation" then... alarm("Das is deutsch");//Dieser Kommentar ist auch deutsch ...is likely no working script anymore. Or in the case of ABNF in an Internet-Draft a translator better stays away from it, including comments. I'd use xml:lang="" or maybe -- if I could take advantage of it with XSLT -- xml:lang="i-default". Theoretical example, in practice I care only about the ASCII output at the moment, meta-data details are a waste of time for this output style. But it could interest translators, if they get hold of the XML source. > I still don't buy that "" != "und". I think it depends on the context. In a context where either "und" or "" are allowed they are semantically identical to their syntactically invalid counterpart. In a context where both are allowed you're free to assign a meaning to "und" slightly different from "" (roughly RESET). > If "" != "und" then the RFC is buggy, since it clearly > requires that the latter not be used if a protocol permits > the former - a decision which only makes sense if they are > equivalent. I think SHOULD NOT means that you need a very good excuse for using it anyway. One good excuse would be the NMTOKEN in the XHTML 1.0 DTDs, that's explicitly listed as MAY in the RFC. Another excuse could be "I need it for some CSS magic", but the RFC doesn't say that this is a _good_ excuse. Obviously a good excuse are old documents written before the NMTOKEN was replaced by a CDATA in some version of XML. Or any old tool designed to produce old XML. It's "only" a SHOULD NOT, so consumers are not permitted to crash and burn if somebody (ab)uses "und". With a MUST NOT I'd agree that "und" would be always wrong, and "abort with error" would be a perfect implementation for a consumer. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 10:57: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 1HcNDN-00024M-0y; Fri, 13 Apr 2007 10:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNDM-00024H-2z for ltru@ietf.org; Fri, 13 Apr 2007 10:57:28 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNDK-0008MI-MO for ltru@ietf.org; Fri, 13 Apr 2007 10:57:28 -0400 Received: by wr-out-0506.google.com with SMTP id 71so853058wri for ; Fri, 13 Apr 2007 07:57:26 -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=jhhvH3aDnT8iqpBk0HLA5Kp5zGLEVUE6trIeHYwdWk+JTmCkqIUg34mf7u9SwzdIrbfPLzySdDyd3WpMs9BsHmkbXgu7nYgTCmZpEpjJq4BENfO65HkkoSe4aHorLBVg15eAmbuE3KN42rH9fLTG9K/nkC45R2iRQWUJ/Ao7KIA= 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=AUpfGd48Xop7AnjCAT9ra3RmLTaNWIBqCiOw1ZyoaV1uE9FzDuNBQjBNxA5Xtd8tYG9zJ3sAlicTLbX8mtDSXkcJoQRro31WK3W7zr3cw8WkB6DqPx9GN9jayzN1e1cZKtZcgq2YZ+1CNfjKYS/XxaOEpXalQjL5gMZ4/U3Np3s= Received: by 10.115.107.1 with SMTP id j1mr981025wam.1176476245408; Fri, 13 Apr 2007 07:57:25 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 07:57:25 -0700 (PDT) Message-ID: <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> Date: Fri, 13 Apr 2007 07:57:25 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <20070413020422.GC7353@mercury.ccil.org> MIME-Version: 1.0 References: <20070412170013.GF16269@mercury.ccil.org> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <20070413020422.GC7353@mercury.ccil.org> X-Google-Sender-Auth: b8b633a003eafd86 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Asmus Freytag , LTRU Working Group , CLDR list , www-international@w3.org, Stephen Deach , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338646342==" Errors-To: ltru-bounces@ietf.org --===============0338646342== Content-Type: multipart/alternative; boundary="----=_Part_8975_24270150.1176476245280" ------=_Part_8975_24270150.1176476245280 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline "mis" is defined in 639-2 as "Miscellaneous languages". That does not mean that it is limited to "languages that don't belong to any other collection". You interpretation also breaks stability, since I could validly tag content today with "mis", which would become invalid under your interpretation at some point in the future. On http://www.loc.gov/standards/iso639-2/php/code_list.php it is not listed with "(other)", so it is not a collection. > I interpret "zxx" to mean "the content so tagged is not any instance of the kind of entities encompassed by this coding standard". That is not born out by the name on http://www.loc.gov/standards/iso639-2/php/code_list.php, which says " No linguistic content". It does not say "no linguistic content that could otherwise be represented by a code in this standard", a very different thing. Mark On 4/12/07, John Cowan wrote: > > Mark Davis scripsit: > > > I think I agree with you in spirit, but not in precise details. The > > tag "und" means "undetermined", so when I encounter it I don't know > > whether the content contains one language, many languages, or no > > language. The tag "zxx" would mean that there is no language content, > > "mis" would mean that there is at least some language content, and "mul" > > would mean that there is language content, with more than one language. > > I'm okay with all of this except "mis". "mis" is a collection code, > as I explained, and means "languages that don't belong to any other > collection." It is not the universal collection. > > -- > Mark Twain on Cecil Rhodes: John Cowan > I admire him, I freely admit it, http://www.ccil.org/~cowan > and when his time comes I shall cowan@ccil.org > buy a piece of the rope for a keepsake. > -- Mark ------=_Part_8975_24270150.1176476245280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline "mis" is defined in 639-2 as "Miscellaneous languages". That does not mean that it is limited to "languages that don't belong to any other collection". You interpretation also breaks stability, since I could validly tag content today with "mis", which would become invalid under your interpretation at some point in the future.

On http://www.loc.gov/standards/iso639-2/php/code_list.php it is not listed with "(other)", so it is not a collection.

> I interpret "zxx" to mean "the content so tagged is not any instance of the kind of entities encompassed by this coding standard".

That is not born out by the name on http://www.loc.gov/standards/iso639-2/php/code_list.php , which says " No linguistic content". It does not say "no linguistic content that could otherwise be represented by a code in this standard", a very different thing.


Mark

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

> I think I agree with you in spirit, but not in precise details. The
> tag "und" means "undetermined", so when I encounter it I don't know
> whether the content contains one language, many languages, or no
> language. The tag "zxx" would mean that there is no language content,
> "mis" would mean that there is at least some language content, and "mul"
> would mean that there is language content, with more than one language.

I'm okay with all of this except "mis".  "mis" is a collection code,
as I explained, and means "languages that don't belong to any other
collection."  It is not the universal collection.

--
Mark Twain on Cecil Rhodes:                    John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                 cowan@ccil.org
buy a piece of the rope for a keepsake.



--
Mark ------=_Part_8975_24270150.1176476245280-- --===============0338646342== 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 --===============0338646342==-- From ltru-bounces@ietf.org Fri Apr 13 12:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOZh-000198-Mp; Fri, 13 Apr 2007 12:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOZg-00018y-RU for ltru@ietf.org; Fri, 13 Apr 2007 12:24:36 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOZW-0000vz-Uu for ltru@ietf.org; Fri, 13 Apr 2007 12:24:36 -0400 Received: by nz-out-0506.google.com with SMTP id z6so849438nzd for ; Fri, 13 Apr 2007 09:24:26 -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:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=rIQNbc1vzbVuk0mG87e24WQZ9dQLDUCAVT2WOgvTJJOFG746667XoozOW1UIsx5luxKHs8DZuR/CIEUfEsB30gvNAKkykWnqMHRyxZz9BWn0dAgWiop9RNkrUtUTykNhIUOCnLjrlmicbzPEy+dfqx8ewEyI5KnW0HArQIyUAM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DVY+pcLsKbi+auRm0fD9WYFhLlifUb8SSNyDvuuDIwnofebyHOQPv5BER2ONXqS6iRGMNT+XNtBr0Ph19H9UDJVliJrsxeDnZZb+fzPWOPu830+GY/DhAGjfAtqJ6z4KVlitg0J8aQnzzn+3j2K4qJqsowjip+IpyWYT/JMBBSk= Received: by 10.115.106.7 with SMTP id i7mr1015300wam.1176481465685; Fri, 13 Apr 2007 09:24:25 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 09:24:25 -0700 (PDT) Message-ID: <30b660a20704130924y1d728373k87fda62ec69def38@mail.gmail.com> Date: Fri, 13 Apr 2007 09:24:25 -0700 From: "Mark Davis" To: "John Cowan" , "Stephen Deach" , "Kent Karlsson" , "Asmus Freytag" , "Richard Ishida" , "LTRU Working Group" , www-international@w3.org, "CLDR list" Subject: Re: [Ltru] RE: For review: Tagging text with no language In-Reply-To: <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> MIME-Version: 1.0 References: <20070412170013.GF16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <20070413020422.GC7353@mercury.ccil.org> <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> X-Google-Sender-Auth: 447f291fb53cc442 X-Spam-Score: 0.3 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0795538274==" Errors-To: ltru-bounces@ietf.org --===============0795538274== Content-Type: multipart/alternative; boundary="----=_Part_11029_18713874.1176481465563" ------=_Part_11029_18713874.1176481465563 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline IEkgYWx3YXlzIGxpa2UgdG8gdGhpbmsgb2YgdGhlc2Uga2luZHMgb2YgaXNzdWVzIGJ5IGxvb2tp bmcgYXQgZXhhbXBsZXMsCnNpbmNlIGl0IHRlbmRzIHRvIGZvY3VzIHRoZSBpc3N1ZXMgYW5kIG1h a2UgaXQgY2xlYXIgd2hlbiBwZW9wbGUgYXJlCm1pc2ludGVycHJldGluZyBvdGhlcnMnIHRlcm1p bm9sb2d5LiBJIHB1dCBvdXQgYmVsb3cgc29tZSBleGFtcGxlcyBvZiB3aGF0IGEKcHJvY2VzcyBz aG91bGQgZG8gaWYgZ2V0cyBhIHN0cmVhbSBvZiBpbmZvcm1hdGlvbiBhbmQgaXMgdG8gdGFnIGl0 LCB3aGVyZSB3ZQphc3N1bWUgdGhhdCBpdCBpcyBkb2luZyB0aGUgYmVzdCBqb2IgaXQgY2FuLiBQ ZW9wbGUgY2FuIGNvbW1lbnQgb24gdGhlc2Ugb3IKcHJvcG9zZSBvdGhlcnMuCgogICBDb250ZW50 CiBUYWcKIENvbW1lbnQKICBuL2EKIHVuZCwgb3IgZXF1aXZhbGVudGx5CiIiICwgaWYgdGhhdCBp cyBhdmFpbGFibGUgaW4gdGhlIHByb3RvY29sICBUaGUgdGFnIHdoZXJlIHRoZSBwcm9jZXNzIGlz IG5vdAplcXVpcHBlZCB0byBhbmFseXplIHRoZSB0ZXh0IGF0IGFsbC4gdW5kID0gIlVuZGV0ZXJt aW5lZCIKMTQza2w7dWZhKWlvcCgmdXdlaW9ycWhqa2wyMzQxbGtqI0AhJEprZGZqO2FmZSB6eHgK IENsZWFybHkgc29tZSBiaW5hcnkganVuay4genh4ID0gIk5vIGxpbmd1aXN0aWMgY29udGVudCIg ICBib2syMwogdW5kCiBNYXliZSBoYXMgbGluZ3Vpc3RpYyBjb250ZW50LCBtYXliZSBub3QuIENh bid0IHJlYWxseSBkZXRlcm1pbmUuCiAgY2hhdCAgbXVsLCBpZiB0aGUgcHJvdG9jb2wgb25seSBw ZXJtaXRzIGEgc2luZ2xlIHRhZwo8ZW4sIGZyPiBvdGhlcndpc2UgIG11bCA9ICJNdWx0aXBsZSBs YW5ndWFnZXMiCm1heWJlIGFsc28gb3RoZXJzLCBzaW5jZSAiY2hhdCIgaGFzIGVudGVyZWQgdGhl IHZvY2FidWxhcnkgb2YgbWFueSBsYW5ndWFnZXMKICBTdXp1a2kgIGphLUxhdG4KIG1heWJlIGFs c28gb3RoZXJzLCBzaW5jZSAiSSBib3VnaHQgYSBTdXp1a2kiIGlzIGEgcGVyZmVjdGx5IHJlYXNv bmFibGUKRW5nbGlzaCBzZW50ZW5jZS4gICBJZ29uZGEgZmxhdHVuaWNhaSB2Ymlua2xpPyAgbWlz ICBzb21lIGxhbmd1YWdlIHRoZQpwcm9jZXNzIHJlY29nbml6ZXMsIGJ1dCB3aGljaCBpcyBub3Qg aW4gQkNQIDQ3ICAgcG9kc3RhdG7DqSBqbcOpbm8gIG1pcwogc29tZXRoaW5nIHRoZSBwcm9jZXNz IHJlY29nbml6ZXMgYXMgaGF2aW5nIGxpbmd1aXN0aWMgY29udGVudCwgYW5kIG1pZ2h0IGJlCmlu IEJDUCA0NywgYnV0IGl0IGRvZXNuJ3Qga25vdyB3aGljaCBsYW5ndWFnZSBpdCBpcy4KICBpZiAo bXlJbnN0YW5jZS5nZXRUeXBlKCkgPT0gVHlwZS5VTktOT1dOKSB7IHRocm93IG5ldyBFeGNlcHRp b24oIiIpOyB9CiBhcnQ/CiB1bmNsZWFyIHdoZXRoZXIgImFydCIgY2FuIGluY2x1ZGUsIG9yIGlz IHJlc3RyaWN0ZWQgdG8gY2FzZXMgbGlrZSBLbGluZ29uCm9yIEVzcGVyYW50by4gYXJ0ID0gIkFy dGlmaWNpYWwgKE90aGVyKSIK ------=_Part_11029_18713874.1176481465563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGZvbnQgc2l6ZT0iMiI+CkkgYWx3YXlzIGxpa2UgdG8gdGhpbmsgb2YgdGhlc2Uga2luZHMgb2Yg aXNzdWVzIGJ5IGxvb2tpbmcgYXQgZXhhbXBsZXMsIHNpbmNlIGl0CnRlbmRzIHRvIGZvY3VzIHRo ZSBpc3N1ZXMgYW5kIG1ha2UgaXQgY2xlYXIgd2hlbiBwZW9wbGUgYXJlIG1pc2ludGVycHJldGlu ZwpvdGhlcnMmIzM5OyB0ZXJtaW5vbG9neS4gSSBwdXQgb3V0IGJlbG93IHNvbWUgZXhhbXBsZXMg b2Ygd2hhdCBhIHByb2Nlc3Mgc2hvdWxkIGRvCmlmIGdldHMgYSBzdHJlYW0gb2YgaW5mb3JtYXRp b24gYW5kIGlzIHRvIHRhZyBpdCwgd2hlcmUgd2UgYXNzdW1lIHRoYXQgaXQgaXMKZG9pbmcgdGhl IGJlc3Qgam9iIGl0IGNhbi4gUGVvcGxlIGNhbiBjb21tZW50IG9uIHRoZXNlIG9yIHByb3Bvc2Ug b3RoZXJzLjxicj48YnI+PC9mb250PgoKPGRpdj4KICA8dGFibGUgYm9yZGVyPSIxIiBjZWxscGFk ZGluZz0iMyIgY2VsbHNwYWNpbmc9IjAiPgogICAgPHRib2R5PgogICAgPHRyIGJnY29sb3I9IiNj Y2ZmZmYiPgogICAgICA8dGQ+PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgQ29udGVudDxicj48L2Zv bnQ+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZD48Zm9udCBzaXplPSIyIj4KICAgICAgICBUYWc8YnI+ PC9mb250PgogICAgICA8L3RkPgogICAgICA8dGQ+PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgQ29t bWVudDxicj48L2ZvbnQ+CiAgICAgIDwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICA8dGQ+ PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgbi9hPGJyPjwvZm9udD4KICAgICAgPC90ZD4KICAgICAg PHRkPjxmb250IHNpemU9IjIiPgogICAgICAgIHVuZCwgb3IgZXF1aXZhbGVudGx5PGJyPgogICAg ICAgICZxdW90OyZxdW90OyAsIGlmIHRoYXQgaXMgYXZhaWxhYmxlIGluIHRoZSBwcm90b2NvbAog ICAgICA8L2ZvbnQ+PC90ZD4KICAgICAgPHRkPjxmb250IHNpemU9IjIiPgogICAgICAgIFRoZSB0 YWcgd2hlcmUgdGhlIHByb2Nlc3MgaXMgbm90IGVxdWlwcGVkIHRvIGFuYWx5emUgdGhlIHRleHQg YXQgYWxsLgogICAgICAgIHVuZCA9ICZxdW90O1VuZGV0ZXJtaW5lZCZxdW90OwogICAgICA8L2Zv bnQ+PC90ZD4KICAgIDwvdHI+CiAgICA8dHI+CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxp Z246IHRvcDsiPjxmb250IHNpemU9IjIiPgogICAgICAgIDE0M2tsO3VmYSlpb3AoJmFtcDt1d2Vp b3JxaGprbDIzNDFsa2ojQCEkSmtkZmo7YWZlCiAgICAgIDwvZm9udD48L3RkPgogICAgICA8dGQg c3R5bGU9InZlcnRpY2FsLWFsaWduOiB0b3A7Ij48Zm9udCBzaXplPSIyIj4KICAgICAgICB6eHg8 YnI+PC9mb250PgogICAgICA8L3RkPgogICAgICA8dGQgc3R5bGU9InZlcnRpY2FsLWFsaWduOiB0 b3A7Ij48Zm9udCBzaXplPSIyIj4KICAgICAgICBDbGVhcmx5IHNvbWUgYmluYXJ5IGp1bmsuIHp4 eCA9ICZxdW90O05vIGxpbmd1aXN0aWMgY29udGVudCZxdW90OwogICAgICA8L2ZvbnQ+PC90ZD4K ICAgIDwvdHI+CiAgICA8dHI+CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsi Pjxmb250IHNpemU9IjIiPgogICAgICAgIGJvazIzPGJyPjwvZm9udD4KICAgICAgPC90ZD4KICAg ICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0iMiI+CiAgICAg ICAgdW5kPGJyPjwvZm9udD4KICAgICAgPC90ZD4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1h bGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgTWF5YmUgaGFzIGxpbmd1aXN0aWMg Y29udGVudCwgbWF5YmUgbm90LiBDYW4mIzM5O3QgcmVhbGx5IGRldGVybWluZS48YnI+PC9mb250 PgogICAgICA8L3RkPgogICAgPC90cj4KICAgIDx0cj4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNh bC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgY2hhdAogICAgICA8L2ZvbnQ+ PC90ZD4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0i MiI+CiAgICAgICAgbXVsLCBpZiB0aGUgcHJvdG9jb2wgb25seSBwZXJtaXRzIGEgc2luZ2xlIHRh Zzxicj4KICAgICAgICAmbHQ7ZW4sIGZyJmd0OyBvdGhlcndpc2UKICAgICAgPC9mb250PjwvdGQ+ CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsiPjxmb250IHNpemU9IjIiPgog ICAgICAgIG11bCA9ICZxdW90O011bHRpcGxlIGxhbmd1YWdlcyZxdW90Ozxicj4KICAgICAgICBt YXliZSBhbHNvIG90aGVycywgc2luY2UgJnF1b3Q7Y2hhdCZxdW90OyBoYXMgZW50ZXJlZCB0aGUg dm9jYWJ1bGFyeSBvZiBtYW55CiAgICAgICAgbGFuZ3VhZ2VzPGJyPjwvZm9udD4KICAgICAgPC90 ZD4KICAgIDwvdHI+CiAgICA8dHI+CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRv cDsiPjxmb250IHNpemU9IjIiPgogICAgICAgIFN1enVraQogICAgICA8L2ZvbnQ+PC90ZD4KICAg ICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0iMiI+CiAgICAg ICAgamEtTGF0bjxicj48L2ZvbnQ+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCBzdHlsZT0idmVydGlj YWwtYWxpZ246IHRvcDsiPjxmb250IHNpemU9IjIiPgogICAgICAgIG1heWJlIGFsc28gb3RoZXJz LCBzaW5jZSAmcXVvdDtJIGJvdWdodCBhIFN1enVraSZxdW90OyBpcyBhIHBlcmZlY3RseSByZWFz b25hYmxlCiAgICAgICAgRW5nbGlzaCBzZW50ZW5jZS4KICAgICAgPC9mb250PjwvdGQ+CiAgICA8 L3RyPgogICAgPHRyPgogICAgICA8dGQgc3R5bGU9InZlcnRpY2FsLWFsaWduOiB0b3A7Ij48Zm9u dCBzaXplPSIyIj4KICAgICAgICBJZ29uZGEgZmxhdHVuaWNhaSB2Ymlua2xpPwogICAgICA8L2Zv bnQ+PC90ZD4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6 ZT0iMiI+CiAgICAgICAgbWlzCiAgICAgIDwvZm9udD48L3RkPgogICAgICA8dGQgc3R5bGU9InZl cnRpY2FsLWFsaWduOiB0b3A7Ij48Zm9udCBzaXplPSIyIj4KICAgICAgICBzb21lIGxhbmd1YWdl IHRoZSBwcm9jZXNzIHJlY29nbml6ZXMsIGJ1dCB3aGljaCBpcyBub3QgaW4gQkNQIDQ3CiAgICAg IDwvZm9udD48L3RkPgogICAgPC90cj4KICAgIDx0cj4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNh bC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6ZT0iMiI+CiAgICAgICAgcG9kc3RhdG7DqSBqbcOpbm8K ICAgICAgPC9mb250PjwvdGQ+CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsi Pjxmb250IHNpemU9IjIiPgogICAgICAgIG1pczxicj48L2ZvbnQ+CiAgICAgIDwvdGQ+CiAgICAg IDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsiPjxmb250IHNpemU9IjIiPgogICAgICAg IHNvbWV0aGluZyB0aGUgcHJvY2VzcyByZWNvZ25pemVzIGFzIGhhdmluZyBsaW5ndWlzdGljIGNv bnRlbnQsIGFuZCBtaWdodAogICAgICAgIGJlIGluIEJDUCA0NywgYnV0IGl0IGRvZXNuJiMzOTt0 IGtub3cgd2hpY2ggbGFuZ3VhZ2UgaXQgaXMuPGJyPjwvZm9udD4KICAgICAgPC90ZD4KICAgIDwv dHI+CiAgICA8dHI+CiAgICAgIDx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsiPjxmb250 IHNpemU9IjIiPgogICAgICAgIGlmIChteUluc3RhbmNlLmdldFR5cGUoKSA9PSBUeXBlLlVOS05P V04pIHsgdGhyb3cgbmV3IEV4Y2VwdGlvbigmcXVvdDsmcXVvdDspOyB9PGJyPjwvZm9udD4KICAg ICAgPC90ZD4KICAgICAgPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PGZvbnQgc2l6 ZT0iMiI+CiAgICAgICAgYXJ0Pzxicj48L2ZvbnQ+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCBzdHls ZT0idmVydGljYWwtYWxpZ246IHRvcDsiPjxmb250IHNpemU9IjIiPgogICAgICAgIHVuY2xlYXIg d2hldGhlciAmcXVvdDthcnQmcXVvdDsgY2FuIGluY2x1ZGUsIG9yIGlzIHJlc3RyaWN0ZWQgdG8g Y2FzZXMgbGlrZQogICAgICAgIEtsaW5nb24gb3IgRXNwZXJhbnRvLiBhcnQgPSAmcXVvdDtBcnRp ZmljaWFsIChPdGhlcikmcXVvdDsKICAgICAgPC9mb250PjwvdGQ+CiAgICA8L3RyPgogICAgPC90 Ym9keT4KICA8L3RhYmxlPgo8L2Rpdj4K ------=_Part_11029_18713874.1176481465563-- --===============0795538274== 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 --===============0795538274==-- From ltru-bounces@ietf.org Fri Apr 13 13:17: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 1HcPOd-0002sR-TZ; Fri, 13 Apr 2007 13:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPOd-0002rv-5w for ltru@lists.ietf.org; Fri, 13 Apr 2007 13:17:15 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPOb-0001Uv-O3 for ltru@lists.ietf.org; Fri, 13 Apr 2007 13:17:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcPON-0001Y8-EE for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:16:59 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 19:16:59 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 19:16:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 19:16:08 +0200 Organization: Lines: 43 Message-ID: <461FBAD8.1A79@xyzzy.claranet.de> References: <20070412170013.GF16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> <461EAA57.40108@ix.netcom.com> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <20070413020422.GC7353@mercury.ccil.org> <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> <30b660a20704130924y1d728373k87fda62ec69def38@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > mul =3D "Multiple > mul, if the languages" > protocol only maybe also > chat permits a others, since > single tag "chat" has > entered the > otherwise vocabulary of > many languages Depends on the context. If the context is something in the direction of your comment it's fine. But if the context is = "I don't know if that's about a chat or a cat" I'd use "und". > some language > the process > Igonda flatunicai vbinkli? mis recognizes, but > which is not in > BCP 47 That would be wrong for almost all languages not yet in the registry belonging to another collection like "ger". > something the > process > recognizes as > having > linguistic > podstatn=C3=A9 jm=C3=A9no mis content, and > might be in BCP > 47, but it > doesn't know > which language > it is. If it doesn't know that it can use "und", abusing "mis" is no option. I think "art" is about artificial languages for humans or in fiction, not for programming languages. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 14: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 1HcQJx-0005go-M1; Fri, 13 Apr 2007 14:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7Ef-0001ze-32 for ltru@ietf.org; Thu, 12 Apr 2007 17:53:45 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7Ee-0008Vk-Re for ltru@ietf.org; Thu, 12 Apr 2007 17:53:45 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=E0ZrHozpn0JipDNa0jCdQWDkvdHY9dQGTOlNZwC9h6H5LOujpIps3EsTJABHiUi0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from dialup-4.242.15.79.dial1.seattle1.level3.net ([4.242.15.79] helo=[127.0.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hc7ER-0000DV-Qx; Thu, 12 Apr 2007 17:53:32 -0400 Message-ID: <461EAA57.40108@ix.netcom.com> Date: Thu, 12 Apr 2007 14:53:27 -0700 From: Asmus Freytag User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kent Karlsson Subject: Re: [Ltru] RE: For review: Tagging text with no language References: <20070411183743.GA29567@mercury.ccil.org> <20070411195206.GF29567@mercury.ccil.org> <30b660a20704111258x1b034d7fl85bcf4f612160828@mail.gmail.com> <20070411202427.GH29567@mercury.ccil.org> <017101c77d0a$47c31260$6601a8c0@rishida> <01a001c77d0f$c9c8ccf0$6601a8c0@rishida> <30b660a20704120913g2924f63dr2ca0d13f7b27a2ed@mail.gmail.com> <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121029s2c04f403n4e3cca83ec05e12b@mail.gmail.com> <20070412185629.GG16269@mercury.ccil.org> <004201c77d49$3502f7a0$f962f853@streamserve.com> In-Reply-To: <004201c77d49$3502f7a0$f962f853@streamserve.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 464f085de979d7246f36dc87813833b22c120543388a5fd760c3903857f77cb99dcec6e11198c8d9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.242.15.79 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Fri, 13 Apr 2007 14:16:27 -0400 Cc: www-international@w3.org, '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 On 4/12/2007 2:25 PM, Kent Karlsson wrote: > > FWIW, in CLDR 1.4 some of the translations for "und" has the word "language" > (translated of course) in them, in accordance with John Cowan's original suggestion: > > da.xml: Sproget kan ikke bestemmes > de.xml: Sprache nicht ermittelt > it.xml: lingua imprecisata > sv.xml: obestamt sprak > The sample translations show that there's general difficulty in agreeing on the concept. The German translation says "no language (has been) determined", while the Danish translation says that "no language could be determined". In my reading the Swedish allows both possibilities, but perhaps implies more strongly than the other two that assigning a language to the contents would be meaningful. (The Italian translation seems to most closely agree with the Swedish one to the extent of my command of Italian) > (I would be to blame for the last one, but apparently I'm not the only one to (maybe) > be misguided). Perhaps those ones should be retranslated not to refer to language, > **if** "und" may apply also to "maybe not in any language". > > The problem is that the scheme does not explicitly accounts for all the types of edge conditions that you can get into when analyzing text for language up front. Instead, labels are added here and there to handle some of these as they become urgent enough to require attention. As a result, all the translators have to go by is the shorthand English description for the label. And that's not written with enough precision to overcome the limitation of not having thought through all the possible cases. A./ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 14:49: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 1HcQq5-0001sU-R1; Fri, 13 Apr 2007 14:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQq4-0001pb-3L for ltru@ietf.org; Fri, 13 Apr 2007 14:49:40 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQq1-0007FF-Jl for ltru@ietf.org; Fri, 13 Apr 2007 14:49:40 -0400 Received: by wr-out-0506.google.com with SMTP id 71so920191wri for ; Fri, 13 Apr 2007 11:49:37 -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=mnhheV8phaeJAQ3oElRUObEmXbJMKw6JGIn+UkNZ7+SNoXoGUo1BDCbUdncTuHHh7jJoDxdiWfBxCerZ3hb+HyvlbHTH5bQD/wYHbz2XD3PYInHhBznVGQuqMVITiCu8HES0/7fzs1MijtAuNGmEK4J71dyVx5pmYZw677koSRg= 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=Oo7iYKb7zUgBOoj7Tk+GD0ql6ZUzMtrU6n4lW/wA6vcPhD2KVzK6SGWgkisw4XVbOmccEVox9CuaV26Kw4hi/0xP8C8ewD11xjR1xGjtI6idMBB2UAnwvzKkPJbwSFrO5ni239qOWOzsxS2bLAS1eGPlY4O6ZDra2BOfzKnBM7I= Received: by 10.114.167.2 with SMTP id p2mr1064287wae.1176490176845; Fri, 13 Apr 2007 11:49:36 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 11:49:36 -0700 (PDT) Message-ID: <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> Date: Fri, 13 Apr 2007 11:49:36 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <20070413175040.GM7353@mercury.ccil.org> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <461F92E0.72CC@xyzzy.claranet.de> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> X-Google-Sender-Auth: 03305cbe8f1aca72 X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Frank Ellermann , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0467006249==" Errors-To: ltru-bounces@ietf.org --===============0467006249== Content-Type: multipart/alternative; boundary="----=_Part_14112_18568551.1176490176713" ------=_Part_14112_18568551.1176490176713 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline You are right about number one; I concede that point fully -- I'd overlooked that phrasing, sorry. That means that in ISO 639-2 the following are collections: mul Multiple languages art Artificial (Other) plus more normal cases: afa Afro-Asiatic (Other) alg Algonquian languages ... and the following are not collections. und Undetermined zxx No linguistic content I disagree with your point number two. The only reason that I can conclude that "Miscellaneous Expenses" in a spreadsheet excludes the other listed categories is that I know that everything listed is intended to be a partition. The language codes clearly do not form a partition, since some collections encompass other codes. The collection codes that are tagged with (Other) are clearly meant to be the remainder of partitions, but for the collections that are not tagged with (Other) there is no evidence that they were intended to exclude other cases -- if anything, the contrary -- if they had meant to be the remainder of partitions, they would have said (Other). Moreover, while some may be perfectly willing to have stability go by the wayside, it is extremely important to us, and that is one of the guiding principles of and reasons for BCP 47. That means that if I validly and correctly tag content with "mis", that application cannot be made incorrect by any future change to BCP 47. That is why we can broaden the application of codes, but cannot narrow them. There is no evidence in BCP 47 that I cannot correctly tag the content "kind" with "mis". Now, of course, we all know that we should tag with as much information as we can, so I *should* tag that with "en" if I know I mean the English word, and "de" if I mean the German, or possibly others. If I don't know which one it is, if my protocol allows multiple tags I can use "en, de", and if not I am forced into a choice between "mul" or choosing the 'most likely' language of the set. Mark On 4/13/07, John Cowan wrote: > > Mark Davis scripsit: > > > Saying that mis is a collection is not breaking, but also not > > substantiated by ISO 639-2. > > It's just unfathomable to me how you can get that reading of the standard. > > > http://www.loc.gov/standards/iso639-2/normtext.html > > which says (section 4.1.1, second sentence): > > The words *languages* or *(other)* as part of a language name > in the following tables may be taken to indicate that a language > code is a collective language code. > > > http://www.loc.gov/standards/iso639-2/php/code_list.php > > which says (s.v. "mis") > > Miscellaneous languages > > Note the word *languages*. Game, set, and match (or Q, E, and D). > > > > Saying that "which don't belong to any other collection" is a breaking > > change, *and* is not substantiated by ISO 639-2 at the time the code was > > added to the registry (or even now). > > Come, come. Do you expect us, the members of this list, to suppose > that when a spreadsheet contains the line "Miscellaneous expenses" > you will find there charges for capital construction or salaries? > You will not. You will find expenses *that do not fit into any > other category* on the spreadsheet. > > -- > One art / There is John Cowan > No less / No more http://www.ccil.org/~cowan > All things / To do > With sparks / Galore -- Douglas Hofstadter > -- Mark ------=_Part_14112_18568551.1176490176713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline You are right about number one; I concede that point fully -- I'd overlooked that phrasing, sorry. That means that in ISO 639-2 the following are collections:

mul             Multiple languages
art             Artificial (Other)

plus more normal cases:

afa             Afro-Asiatic (Other)
alg             Algonquian languages
...

and the following are not collections.

und             Undetermined
zxx             No linguistic content


I disagree with your point number two. The only reason that I can conclude that "Miscellaneous Expenses" in a spreadsheet excludes the other listed categories is that I know that everything listed is intended to be a partition. The language codes clearly do not form a partition, since some collections encompass other codes. The collection codes that are tagged with (Other) are clearly meant to be the remainder of partitions, but for the collections that are not tagged with (Other) there is no evidence that they were intended to exclude other cases -- if anything, the contrary -- if they had meant to be the remainder of partitions, they would have said (Other).

Moreover, while some may be perfectly willing to have stability go by the wayside, it is extremely important to us, and that is one of the guiding principles of and reasons for BCP 47. That means that if I validly and correctly tag content with "mis", that application cannot be made incorrect by any future change to BCP 47. That is why we can broaden the application of codes, but cannot narrow them. There is no evidence in BCP 47 that I cannot correctly tag the content "kind" with "mis". Now, of course, we all know that we should tag with as much information as we can, so I *should* tag that with "en" if I know I mean the English word, and "de" if I mean the German, or possibly others. If I don't know which one it is, if my protocol allows multiple tags I can use "en, de", and if not I am forced into a choice between "mul" or choosing the 'most likely' language of the set.

Mark

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

> Saying that mis is a collection is not breaking, but also not
> substantiated by ISO 639-2.

It's just unfathomable to me how you can get that reading of the standard.

> http://www.loc.gov/standards/iso639-2/normtext.html

which says (section 4.1.1, second sentence):

        The words *languages* or *(other)* as part of a language name
        in the following tables may be taken to indicate that a language
        code is a collective language code.

> http://www.loc.gov/standards/iso639-2/php/code_list.php

which says (s.v. "mis")

        Miscellaneous languages

Note the word *languages*.  Game, set, and match (or Q, E, and D).


> Saying that "which don't belong to any other collection" is a breaking
> change, *and* is not substantiated by ISO 639-2 at the time the code was
> added to the registry (or even now).

Come, come.  Do you expect us, the members of this list, to suppose
that when a spreadsheet contains the line "Miscellaneous expenses"
you will find there charges for capital construction or salaries?
You will not.  You will find expenses *that do not fit into any
other category* on the spreadsheet.

--
One art / There is                      John Cowan < cowan@ccil.org>
No less / No more                       http://www.ccil.org/~cowan
All things / To do
With sparks / Galore                     -- Douglas Hofstadter



--
Mark ------=_Part_14112_18568551.1176490176713-- --===============0467006249== 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 --===============0467006249==-- From ltru-bounces@ietf.org Fri Apr 13 15: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 1HcRJV-0003dg-Pb; Fri, 13 Apr 2007 15:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRJU-0003bo-8s for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:20:04 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRJT-0001zt-1f for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:20:04 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=njWxTShtWXGYydWXhSKIM4v/6DxNc4bVry0eSyGih7GiKf610WXkDhay2GGTVj/l; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.203] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HcRJR-00019Z-Uq; Fri, 13 Apr 2007 15:20:02 -0400 Message-ID: <005001c77e00$fb1e1160$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20070413122917.GA25431@nic.fr> <461F92E0.72CC@xyzzy.claranet.de><461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr><461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> Subject: Re: [Ltru] Re: "mis" update review request Date: Fri, 13 Apr 2007 12:21:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7574bcceba087fc1f01da694e6a7ecfd0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.203 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - The thing that bothers me about the comment "A collection of languages which don't belong to any other collection" is that it isn't compatible with the possibility that one or more of those languages might eventually be included in another (possibly new) collection. If that langauage were left in the mis collection as well, the comment would be incorrect. If the language were removed from the mis collection, stability goes out the window. Either way, changing the comment wouldn't help the situation. However, unlike some other collections, I find it very difficult to imagine a case where "mis" would be useful in tagging data. Without a clear use case for "mis" in constructing a language tag, perhaps we could conclude that this whole debate is really academic, and that no action is needed. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 15:23: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 1HcRMb-0005AI-23; Fri, 13 Apr 2007 15:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRMZ-00058y-P4 for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:23:15 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound6-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRMU-0002es-Dd for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:23:15 -0400 Received: from outbound6-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-blu-R.bigfish.com (Postfix) with ESMTP id 40C3A1620081; Fri, 13 Apr 2007 19:23:08 +0000 (UTC) Received: from mail163-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound6-blu.bigfish.com (Postfix) with ESMTP id 35D82BE805A; Fri, 13 Apr 2007 19:23:08 +0000 (UTC) Received: from mail163-blu (localhost.localdomain [127.0.0.1]) by mail163-blu-R.bigfish.com (Postfix) with ESMTP id EF73A1BD817F; Fri, 13 Apr 2007 19:23:07 +0000 (UTC) X-BigFish: VP Received: by mail163-blu (MessageSwitch) id 1176492187235477_19542; Fri, 13 Apr 2007 19:23:07 +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 mail163-blu.bigfish.com (Postfix) with ESMTP id 9DB81D6004E; Fri, 13 Apr 2007 19:23:05 +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 2007041312230053-45760 ; Fri, 13 Apr 2007 12:23:00 -0700 In-Reply-To: <461F5FF7.6A90@xyzzy.claranet.de> To: Frank Ellermann 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, 13 Apr 2007 12:21:11 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/13/2007 12:21:12, Serialize complete at 04/13/2007 12:21:12, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 12:23:00 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 12:23:05 PM, Serialize complete at 04/13/2007 12:23:05 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: www-international@w3.org, ltru@lists.ietf.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0161178200==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0161178200== Content-Type: multipart/alternative; boundary="=_alternative 006A796D882572BC_=" This is a multipart message in MIME format. --=_alternative 006A796D882572BC_= Content-Type: text/plain; charset="US-ASCII" With respect to computer language snippets, isn't that what the tag is for -- at least in XHTML? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Frank Ellermann Sent by: www-international-request@w3.org 04/13/2007 03:48 AM To www-international@w3.org cc ltru@lists.ietf.org Subject Re: For review: Tagging text with no language John Cowan wrote: > BCP 47 explicitly excludes computer languages from its scope, as do > the ISO 639 family of standards. So "zxx" is the only available tag. Tagging source code snippets as "zxx" would be barbaric. But it's a case where "" is clearly better than "und". Actually I think "" is always better than "und" unless I intend to flag something for later review. In the context of Richard's article and XML documents, for other purposes it might be different. The use of "und" in XHTML 1.0 is IMO only a temporary kludge until the DTD is fixed. Doug argued that "" is a placeholder, I think it's not in XML, it has a clear effect of breaking any inherited xml:lang, resetting anything interested in language tags (CSS, spell checkers, Web crawlers, etc.) to their default "no language specified" behaviour. It's IMO perfectly okay to have very different styles for "i-default", "und", "zxx", "art", "mul", etc. With "" meaning "none of those". Frank --=_alternative 006A796D882572BC_= Content-Type: text/html; charset="US-ASCII"
With respect to computer language snippets, isn't that what the <code> tag is for -- at least in XHTML?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


Frank Ellermann <nobody@xyzzy.claranet.de>
Sent by: www-international-request@w3.org

04/13/2007 03:48 AM

To
www-international@w3.org
cc
ltru@lists.ietf.org
Subject
Re: For review: Tagging text with no language






John Cowan wrote:

> BCP 47 explicitly excludes computer languages from its scope, as do
> the ISO 639 family of standards.  So "zxx" is the only available tag.

Tagging source code snippets as "zxx" would be barbaric.  But it's a
case where "" is clearly better than "und".  Actually I think "" is
always better than "und" unless I intend to flag something for later
review.  In the context of Richard's article and XML documents, for
other purposes it might be different.  The use of "und" in XHTML 1.0
is IMO only a temporary kludge until the DTD is fixed.

Doug argued that "" is a placeholder, I think it's not in XML, it has
a clear effect of breaking any inherited xml:lang, resetting anything
interested in language tags (CSS, spell checkers, Web crawlers, etc.)
to their default "no language specified" behaviour.

It's IMO perfectly okay to have very different styles for "i-default",
"und", "zxx", "art", "mul", etc.   With "" meaning "none of those".

Frank
--=_alternative 006A796D882572BC_=-- --===============0161178200== 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 --===============0161178200==-- From ltru-bounces@ietf.org Fri Apr 13 15:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRh1-0004N9-8H; Fri, 13 Apr 2007 15:44:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRgz-0004N4-QO for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:44:21 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRgy-0000vf-D3 for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:44:21 -0400 Received: by nz-out-0506.google.com with SMTP id o37so991312nzf for ; Fri, 13 Apr 2007 12:44: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=iiJLWvpQ90/Qp2jWBBdtqVryJ745Aonf4qG5An9CyjwTHts4HkNNdJslirLHqkep7C+OOUskjobctVawoX3Bkafho96FGiYi2ycLgk56tjsRjlp/GC+xJQLYMudyDIcWHfmwD8UHpYF5ydbGIwCYNssFBZeVcxhmlgq5YBmQLIA= 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=sLTty/zWh5EviiHYcqKM3iW1RKHRmp5NiYWI7+He1REQKDF5U7XrTxg2Su4UZoBpPdRpuXASa7+tGciJhVVXCGI10G1IaQ7yZTl0SDj4JE9AvESHI1M1KAUxV8KaDyAgNcySbH6+sZukWLydwnx6xqNLFj1PDjsrft779+mbTBU= Received: by 10.115.54.1 with SMTP id g1mr1087607wak.1176493459585; Fri, 13 Apr 2007 12:44:19 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 12:44:19 -0700 (PDT) Message-ID: <30b660a20704131244t5194a566m3b92e7026cb96b74@mail.gmail.com> Date: Fri, 13 Apr 2007 12:44:19 -0700 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Re: For review: Tagging text with no language In-Reply-To: MIME-Version: 1.0 References: <461F5FF7.6A90@xyzzy.claranet.de> X-Google-Sender-Auth: 29b3d00f2f01c261 X-Spam-Score: 0.8 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Frank Ellermann , www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977890852==" Errors-To: ltru-bounces@ietf.org --===============0977890852== Content-Type: multipart/alternative; boundary="----=_Part_14985_6422359.1176493459423" ------=_Part_14985_6422359.1176493459423 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline HTML is not the only place that language tags are used.... On 4/13/07, Karen_Broome@spe.sony.com wrote: > > > With respect to computer language snippets, isn't that what the tag > is for -- at least in XHTML? > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > *Frank Ellermann * > Sent by: www-international-request@w3.org > > 04/13/2007 03:48 AM > To > www-international@w3.org cc > ltru@lists.ietf.org Subject > Re: For review: Tagging text with no language > > > > > > > > John Cowan wrote: > > > BCP 47 explicitly excludes computer languages from its scope, as do > > the ISO 639 family of standards. So "zxx" is the only available tag. > > Tagging source code snippets as "zxx" would be barbaric. But it's a > case where "" is clearly better than "und". Actually I think "" is > always better than "und" unless I intend to flag something for later > review. In the context of Richard's article and XML documents, for > other purposes it might be different. The use of "und" in XHTML 1.0 > is IMO only a temporary kludge until the DTD is fixed. > > Doug argued that "" is a placeholder, I think it's not in XML, it has > a clear effect of breaking any inherited xml:lang, resetting anything > interested in language tags (CSS, spell checkers, Web crawlers, etc.) > to their default "no language specified" behaviour. > > It's IMO perfectly okay to have very different styles for "i-default", > "und", "zxx", "art", "mul", etc. With "" meaning "none of those". > > Frank > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_14985_6422359.1176493459423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline HTML is not the only place that language tags are used....

On 4/13/07, Karen_Broome@spe.sony.com < Karen_Broome@spe.sony.com> wrote:

With respect to computer language snippets, isn't that what the <code> tag is for -- at least in XHTML?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


Frank Ellermann <nobody@xyzzy.claranet.de >
Sent by: www-international-request@w3.org

04/13/2007 03:48 AM

To
www-international@w3.org
cc
ltru@lists.ietf.org
Subject
Re: For review: Tagging text with no language








John Cowan wrote:

> BCP 47 explicitly excludes computer languages from its scope, as do
> the ISO 639 family of standards.  So "zxx" is the only available tag.

Tagging source code snippets as "zxx" would be barbaric.  But it's a
case where "" is clearly better than "und".  Actually I think "" is
always better than "und" unless I intend to flag something for later
review.  In the context of Richard's article and XML documents, for
other purposes it might be different.  The use of "und" in XHTML 1.0
is IMO only a temporary kludge until the DTD is fixed.

Doug argued that "" is a placeholder, I think it's not in XML, it has
a clear effect of breaking any inherited xml:lang, resetting anything
interested in language tags (CSS, spell checkers, Web crawlers, etc.)
to their default "no language specified" behaviour.

It's IMO perfectly okay to have very different styles for "i-default",
"und", "zxx", "art", "mul", etc.   With "" meaning "none of those".

Frank

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




--
Mark ------=_Part_14985_6422359.1176493459423-- --===============0977890852== 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 --===============0977890852==-- From ltru-bounces@ietf.org Fri Apr 13 15:52: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 1HcRoS-0001Bj-SM; Fri, 13 Apr 2007 15:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRoQ-00012z-PO for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:52:02 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRoQ-000324-3U for ltru@lists.ietf.org; Fri, 13 Apr 2007 15:52:02 -0400 Received: by py-out-1112.google.com with SMTP id f31so715732pyh for ; Fri, 13 Apr 2007 12:52:01 -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=mW76WlvsZrjDEM6XiSarPQVy7CmxT8SYPAmBIMQK0HL4pY20GAw/wS29o1SbPU7RH1HsWLa2k51QtW4iFFNJzSfHCJj3+0G55N3G+KIogibLmS5adcAfveWX1l7PvDbmNcdW78sRIfC856JSqK73MbccgO29xjjddGarU6FFYhQ= 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=MT2OamYlww1Mj+bVkrAcNPyLS21vclt8mrGDo/zhKmaUz1qmlzqabS21XLVKWiTianBYnP32wufd68AwRN9rVKrmDRSZ17pE2Sul/oGWBw5URfvz9P15zQzhV83Hly0PIb4CxkzsB68xC4pPBzSPyVb4pM52xH0gMymNhuyP09A= Received: by 10.114.202.15 with SMTP id z15mr1083918waf.1176493920878; Fri, 13 Apr 2007 12:52:00 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 12:52:00 -0700 (PDT) Message-ID: <30b660a20704131252h19b75709mea47be6cb5bccfa9@mail.gmail.com> Date: Fri, 13 Apr 2007 12:52:00 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: For review: Tagging text with no language In-Reply-To: <461FBAD8.1A79@xyzzy.claranet.de> MIME-Version: 1.0 References: <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <20070413020422.GC7353@mercury.ccil.org> <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> <30b660a20704130924y1d728373k87fda62ec69def38@mail.gmail.com> <461FBAD8.1A79@xyzzy.claranet.de> X-Google-Sender-Auth: b74d7b43ac58531b X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834946170==" Errors-To: ltru-bounces@ietf.org --===============0834946170== Content-Type: multipart/alternative; boundary="----=_Part_15129_28086253.1176493920693" ------=_Part_15129_28086253.1176493920693 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline T24gNC8xMy8wNywgRnJhbmsgRWxsZXJtYW5uIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+IHdy b3RlOgo+Cj4gTWFyayBEYXZpcyB3cm90ZToKPgo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG11bCA9ICJNdWx0aXBsZQo+ID4gICAgICAgICAgICAgICAgbXVsLCBpZiB0aGUg ICAgICAgIGxhbmd1YWdlcyIKPiA+ICAgICAgICAgICAgICAgIHByb3RvY29sIG9ubHkgICAgICBt YXliZSBhbHNvCj4gPiAgY2hhdCAgICAgICAgICBwZXJtaXRzIGEgICAgICAgICAgb3RoZXJzLCBz aW5jZQo+ID4gICAgICAgICAgICAgICAgc2luZ2xlIHRhZyAgICAgICAgICJjaGF0IiBoYXMKPiA+ ICAgICAgICAgICAgICAgIDxlbiwgZnI+ICAgICAgICAgICBlbnRlcmVkIHRoZQo+ID4gICAgICAg ICAgICAgICAgb3RoZXJ3aXNlICAgICAgICAgIHZvY2FidWxhcnkgb2YKPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBtYW55IGxhbmd1YWdlcwo+Cj4gRGVwZW5kcyBvbiB0aGUg Y29udGV4dC4gIElmIHRoZSBjb250ZXh0IGlzIHNvbWV0aGluZyBpbiB0aGUKPiBkaXJlY3Rpb24g b2YgeW91ciBjb21tZW50IGl0J3MgZmluZS4gIEJ1dCBpZiB0aGUgY29udGV4dCBpcwo+ICJJIGRv bid0IGtub3cgaWYgdGhhdCdzIGFib3V0IGEgY2hhdCBvciBhIGNhdCIgSSdkIHVzZSAidW5kIi4K CgondW5kJyBpcyBwb3NzaWJsZSwgYnV0IEkgdGhpbmsgdGhhdCBtdWwgY29udmV5cyBtb3JlIGlu Zm9ybWF0aW9uLgoKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZSBsYW5n dWFnZQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBwcm9jZXNzCj4g PiAgSWdvbmRhIGZsYXR1bmljYWkgdmJpbmtsaT8gIG1pcyAgcmVjb2duaXplcywgYnV0Cj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggaXMgbm90IGluCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkNQIDQ3Cj4KPiBUaGF0IHdvdWxkIGJlIHdy b25nIGZvciBhbG1vc3QgYWxsIGxhbmd1YWdlcyBub3QgeWV0IGluIHRoZQo+IHJlZ2lzdHJ5IGJl bG9uZ2luZyB0byBhbm90aGVyIGNvbGxlY3Rpb24gbGlrZSAiZ2VyIi4KCgpJdCdzIG5vdCB3cm9u Zy4gSSBhZ3JlZSB0aGF0IHdoZXJlIHBvc3NpYmxlLCBvbmUgJ3Nob3VsZCcgdGFnIGFzIHByZWNp c2VseQphcyBwb3NzaWJsZSwgYnV0IHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRvIGluIHRoZSBS RkMuIE1vcmVvdmVyLCBpcyB1bmNsZWFyCnRvIG1lIHRoYXQgZXZlcnkgaHVtYW4gbGFuZ3VhZ2Ug ZmFsbHMgdW5kZXIgZWl0aGVyIG9uZSBvZiB0aGUgZXhwbGljaXQgY29kZXMKb3IgaW50byBvbmUg b2YgdGhlIGNvbGxlY3Rpb25zLiBUaGF0IG1heSBiZSB0cnVlLCBJIGp1c3QgZG9uJ3Qga25vdyAt IFBldGVyCm1pZ2h0LgoKCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21l dGhpbmcgdGhlCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3MK PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb2duaXplcyBhcwo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZpbmcKPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbGluZ3Vpc3RpYwo+ID4gIHBvZHN0YXRuw6kgam3DqW5v ICAgICAgICAgICAgbWlzICBjb250ZW50LCBhbmQKPiA+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbWlnaHQgYmUgaW4gQkNQCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDQ3LCBidXQgaXQKPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZG9lc24ndCBrbm93Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdo aWNoIGxhbmd1YWdlCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0IGlz Lgo+Cj4gSWYgaXQgZG9lc24ndCBrbm93IHRoYXQgaXQgY2FuIHVzZSAidW5kIiwgYWJ1c2luZyAi bWlzIiBpcwo+IG5vIG9wdGlvbi4KCgpJIGRvbid0IHNlZSBob3cgaXQgaXMgYW4gYWJ1c2Ugb2Yg J21pcycuIElmIHlvdSBjb3VsZCBvdXRsaW5lIGZvciBtZSB0aGUKcmVhc29uaW5nLCBiYXNlZCBv biB0aGUgc3RhbmRhcmRzLCBiZWhpbmQgc2F5aW5nIHRoYXQgJ21pcycgaXMgbm90IGNvcnJlY3Qs CkknZCBhcHByZWNpYXRlIGl0LgoKSSB0aGluayAiYXJ0IiBpcyBhYm91dCBhcnRpZmljaWFsIGxh bmd1YWdlcyBmb3IKPiBodW1hbnMgb3IgaW4gZmljdGlvbiwgbm90IGZvciBwcm9ncmFtbWluZyBs YW5ndWFnZXMuCgoKVGhhdCBtYXkgd2VsbCBiZSwgaXQgaXMganVzdCBub3QgY2xlYXIgdG8gbWUg ZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4KCkZyYW5rCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0cnVA aWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4K CgoKLS0gCk1hcmsK ------=_Part_15129_28086253.1176493920693 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNC8xMy8wNywgPGIgY2xh c3M9ImdtYWlsX3NlbmRlcm5hbWUiPkZyYW5rIEVsbGVybWFubjwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGUiPm5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQg MHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KTWFyayBEYXZpcyB3cm90ZTo8YnI+ PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsID0gJnF1b3Q7TXVs dGlwbGU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO211bCwg aWYgdGhlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGFu Z3VhZ2VzJnF1b3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtwcm90b2NvbCBvbmx5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWF5YmUg YWxzbzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Y2hhdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Blcm1pdHMgYSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO290aGVycywgc2luY2UK PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzaW5nbGUgdGFn Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2No YXQmcXVvdDsgaGFzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbHQ7ZW4sIGZyJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBlbnRlcmVkIHRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3RoZXJ3aXNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dm9jYWJ1bGFyeSBvZjxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbnkgbGFuZ3VhZ2VzCjxicj48YnI+RGVw ZW5kcyBvbiB0aGUgY29udGV4dC4mbmJzcDsmbmJzcDtJZiB0aGUgY29udGV4dCBpcyBzb21ldGhp bmcgaW4gdGhlPGJyPmRpcmVjdGlvbiBvZiB5b3VyIGNvbW1lbnQgaXQmIzM5O3MgZmluZS4mbmJz cDsmbmJzcDtCdXQgaWYgdGhlIGNvbnRleHQgaXM8YnI+JnF1b3Q7SSBkb24mIzM5O3Qga25vdyBp ZiB0aGF0JiMzOTtzIGFib3V0IGEgY2hhdCBvciBhIGNhdCZxdW90OyBJJiMzOTtkIHVzZSAmcXVv dDt1bmQmcXVvdDsuCjwvYmxvY2txdW90ZT48ZGl2Pjxicj4mIzM5O3VuZCYjMzk7IGlzIHBvc3Np YmxlLCBidXQgSSB0aGluayB0aGF0IG11bCBjb252ZXlzIG1vcmUgaW5mb3JtYXRpb24uPGJyPjwv ZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVm dDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhl eDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzb21lIGxhbmd1YWdlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIHByb2Nlc3M8YnI+Jmd0OyZuYnNwOyZuYnNwO0lnb25kYSBmbGF0dW5pY2FpIHZiaW5r bGk/Jm5ic3A7Jm5ic3A7bWlzJm5ic3A7Jm5ic3A7cmVjb2duaXplcywgYnV0PGJyPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggaXMgbm90IGluCjxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJDUCA0Nzxicj48YnI+VGhhdCB3b3VsZCBi ZSB3cm9uZyBmb3IgYWxtb3N0IGFsbCBsYW5ndWFnZXMgbm90IHlldCBpbiB0aGU8YnI+cmVnaXN0 cnkgYmVsb25naW5nIHRvIGFub3RoZXIgY29sbGVjdGlvbiBsaWtlICZxdW90O2dlciZxdW90Oy48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+SXQmIzM5O3Mgbm90IHdyb25nLiBJIGFncmVlIHRoYXQgd2hl cmUgcG9zc2libGUsIG9uZSAmIzM5O3Nob3VsZCYjMzk7IHRhZyBhcyBwcmVjaXNlbHkgYXMgcG9z c2libGUsIGJ1dCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBpbiB0aGUgUkZDLiBNb3Jlb3Zl ciwgaXMgdW5jbGVhciB0byBtZSB0aGF0IGV2ZXJ5IGh1bWFuIGxhbmd1YWdlIGZhbGxzIHVuZGVy IGVpdGhlciBvbmUgb2YgdGhlIGV4cGxpY2l0IGNvZGVzIG9yIGludG8gb25lIG9mIHRoZSBjb2xs ZWN0aW9ucy4gVGhhdCBtYXkgYmUgdHJ1ZSwgSSBqdXN0IGRvbiYjMzk7dCBrbm93IC0gUGV0ZXIg bWlnaHQuCjxicj48YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzb21ldGhpbmcgdGhlPGJyPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcm9jZXNzCjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVjb2duaXplcyBh czxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aGF2 aW5nPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDts aW5ndWlzdGljPGJyPiZndDsmbmJzcDsmbmJzcDtwb2RzdGF0bsOpIGptw6lubyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO21pcyZuYnNwOyZuYnNwO2NvbnRlbnQsIGFuZDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWlnaHQgYmUgaW4gQkNQCjxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7NDcsIGJ1dCBpdDxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZG9lc24mIzM5O3Qg a25vdzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 d2hpY2ggbGFuZ3VhZ2U8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2l0IGlzLgo8YnI+PGJyPklmIGl0IGRvZXNuJiMzOTt0IGtub3cgdGhhdCBpdCBj YW4gdXNlICZxdW90O3VuZCZxdW90OywgYWJ1c2luZyAmcXVvdDttaXMmcXVvdDsgaXM8YnI+bm8g b3B0aW9uLjwvYmxvY2txdW90ZT48ZGl2Pjxicj5JIGRvbiYjMzk7dCBzZWUgaG93IGl0IGlzIGFu IGFidXNlIG9mICYjMzk7bWlzJiMzOTsuIElmIHlvdSBjb3VsZCBvdXRsaW5lIGZvciBtZSB0aGUg cmVhc29uaW5nLCBiYXNlZCBvbiB0aGUgc3RhbmRhcmRzLCBiZWhpbmQgc2F5aW5nIHRoYXQgJiMz OTttaXMmIzM5OyBpcyBub3QgY29ycmVjdCwgSSYjMzk7ZCBhcHByZWNpYXRlIGl0Lgo8YnI+PC9k aXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4 OyBwYWRkaW5nLWxlZnQ6IDFleDsiPkkgdGhpbmsgJnF1b3Q7YXJ0JnF1b3Q7IGlzIGFib3V0IGFy dGlmaWNpYWwgbGFuZ3VhZ2VzIGZvcjxicj5odW1hbnMgb3IgaW4gZmljdGlvbiwgbm90IGZvciBw cm9ncmFtbWluZyBsYW5ndWFnZXMuCjwvYmxvY2txdW90ZT48ZGl2Pjxicj5UaGF0IG1heSB3ZWxs IGJlLCBpdCBpcyBqdXN0IG5vdCBjbGVhciB0byBtZSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLiA8 YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpGcmFuazxicj48YnI+PGJyPjxicj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcg bGlzdDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48 YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo8L2E+PGJyPjwvYmxv Y2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFyawo= ------=_Part_15129_28086253.1176493920693-- --===============0834946170== 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 --===============0834946170==-- From ltru-bounces@ietf.org Fri Apr 13 16:04: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 1HcS0q-0000IB-57; Fri, 13 Apr 2007 16:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS0o-0000I5-CB for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:04:50 -0400 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcS0n-0002PD-RM for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:04:50 -0400 Received: by nz-out-0506.google.com with SMTP id o37so997103nzf for ; Fri, 13 Apr 2007 13:04:49 -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=hYhWv7VptgakHFPhCKPoh50nM18xesXdhn1j7BHzT3CCep3LRMhjxeuJdrYQ7Rm8WytGHkzXR1VIbGILVFfX4FYfrlekmPUKTDYtktrySB2d8xItS6kG4k46Yju++XPNCo6pzfVYerNYeF5X2+QPTL9sPR5KtwGifV5K1/yRH4U= 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=Q6qsqHk80AsAnDYuar+CO1LWXXnLBOFCCoNdZ7/5ESsjuGY4lEdHZCbazL/DBEeIka2QbZ8AaAYBjq1cOQ/8wfj5Ax6f8C+0SX+oY7+gVmEdmHd8nT1HM1Vmi7avPsf7RmsX4HYIwCzkrvN3i+TeWOu5LxP2LgYAu4l9C5lGNI8= Received: by 10.114.150.1 with SMTP id x1mr119413wad.1176494688911; Fri, 13 Apr 2007 13:04:48 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 13:04:48 -0700 (PDT) Message-ID: <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> Date: Fri, 13 Apr 2007 13:04:48 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <005001c77e00$fb1e1160$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> X-Google-Sender-Auth: 3b10c4b296b889d5 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ietf-languages@alvestrand.no, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1260779192==" Errors-To: ltru-bounces@ietf.org --===============1260779192== Content-Type: multipart/alternative; boundary="----=_Part_15409_5319228.1176494688831" ------=_Part_15409_5319228.1176494688831 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with you about the stability issue. I think part of the problem in communicating about this is that people may have somewhat different usage scenarios in mind. If you think of tagging as something that a person does with content that they originate or have control over, then it is (probably) fairly straightforward for that person to tag as specifically as possible. Another scenario is where you have incoming content, and you need to tag it for use by other components. This might be done, for example, in a search engine, where you fetch and process a page, and use that information later in doing searches. The tag serves to communicate language between the different components. In that case, you have far from perfect information about the content: what you have being typically the result of some level statistical analysis, plus other factors about the document. You need to tag with as much information as you have, *but no more*. It is in that case where you need to have the tags that indicate some level of imperfect knowledge about the source, such as "I have no idea what this is", or "It looks like linguistic content, but I don't know which language", or "it doesn't look like linguistic content". (You may also have more detailed knowledge, like that some document appears to have 70% English content (probability 95%) and 20% French content (probability 65%)). Both scenarios are equally valid use cases for BCP 47 (in fact, as a percentage of data flow on the web, I'd wager strongly that the second scenario completely swamps the first). Mark On 4/13/07, Randy Presuhn wrote: > > Hi - > > The thing that bothers me about the comment "A collection of languages > which > don't belong to any other collection" is that it isn't compatible with the > possibility that one or more of those languages might eventually be > included > in another (possibly new) collection. If that langauage were left in the > mis > collection as well, the comment would be incorrect. If the language were > removed from the mis collection, stability goes out the window. Either > way, > changing the comment wouldn't help the situation. > > However, unlike some other collections, I find it very difficult to > imagine > a case where "mis" would be useful in tagging data. Without a clear use > case > for "mis" in constructing a language tag, perhaps we could conclude that > this > whole debate is really academic, and that no action is needed. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_15409_5319228.1176494688831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with you about the stability issue.

I think part of the problem in communicating about this is that people may have somewhat different usage scenarios in mind. If you think of tagging as something that a person does with content that they originate or have control over, then it is (probably) fairly straightforward for that person to tag as specifically as possible.

Another scenario is where you have incoming content, and you need to tag it for use by other components. This might be done, for example, in a search engine, where you fetch and process a page, and use that information later in doing searches. The tag serves to communicate language between the different components.

In that case, you have far from perfect information about the content: what you have being typically the result of some level statistical analysis, plus other factors about the document. You need to tag with as much information as you have, *but no more*. It is in that case where you need to have the tags that indicate some level of imperfect knowledge about the source, such as "I have no idea what this is", or "It looks like linguistic content, but I don't know which language", or "it doesn't look like linguistic content". (You may also have more detailed knowledge, like that some document appears to have 70% English content (probability 95%) and 20% French content (probability 65%)).

Both scenarios are equally valid use cases for BCP 47 (in fact, as a percentage of data flow on the web, I'd wager strongly that the second scenario completely swamps the first).

Mark

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

The thing that bothers me about the comment "A collection of languages which
don't belong to any other collection" is that it isn't compatible with the
possibility that one or more of those languages might eventually be included
in another (possibly new) collection.  If that langauage were left in the mis
collection as well, the comment would be incorrect.  If the language were
removed from the mis collection, stability goes out the window.  Either way,
changing the comment wouldn't help the situation.

However, unlike some other collections, I find it very difficult to imagine
a case where "mis" would be useful in tagging data.  Without a clear use case
for "mis" in constructing a language tag, perhaps we could conclude that this
whole debate is really academic, and that no action is needed.

Randy


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



--
Mark ------=_Part_15409_5319228.1176494688831-- --===============1260779192== 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 --===============1260779192==-- From ltru-bounces@ietf.org Fri Apr 13 16:08: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 1HcS4W-0000oK-VX; Fri, 13 Apr 2007 16:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcS4V-0000oF-PB for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:08:39 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcS4U-0004no-65 for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:08:39 -0400 Received: from spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) by mail.cs.tut.fi (Postfix) with ESMTP id 174E5ADB7; Fri, 13 Apr 2007 23:08:35 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) (amavisd-maia, port 10024) with ESMTP id 23558-33; Fri, 13 Apr 2007 23:08:34 +0300 (EEST) Received: from hopeatilhi.cs.tut.fi (hopeatilhi.cs.tut.fi [130.230.4.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 4E9FCA56C; Fri, 13 Apr 2007 23:08:34 +0300 (EEST) Date: Fri, 13 Apr 2007 23:08:33 +0300 (EEST) From: "Jukka K. Korpela" To: www-international@w3.org Subject: Re: [Ltru] Re: For review: Tagging text with no language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote: > With respect to computer language snippets, isn't that what the tag > is for -- at least in XHTML? has been in HTML since the beginning, and it indeed indicates computer code, or "computer language". But to make things more difficult, computer code - such as program code, operating system commands, or markup - can be regarded as being in some human language(s) in the sense that the identifiers may have been formed from words in human languages and the comments are written in some human languages. Knowing the language of computer code can be relevant at least for two purposes: a) the understandability of the code to human readers depends on whether they understand the human language(s) used b) speech synthesis would benefit from the use of language information. Moreover, a checking program could e.g. check that the code follows the syntactic rules of the programming, command, or markup "language" _and_ check the comments using a suitable human language spelling checker. Thus, I would say that the human language some text and the role of that text as computer code are in a sense orthogonal. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 16: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 1HcSBR-0004CA-WC; Fri, 13 Apr 2007 16:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSBQ-0004Bt-MR for ltru@ietf.org; Fri, 13 Apr 2007 16:15:48 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSBO-0007PS-CT for ltru@ietf.org; Fri, 13 Apr 2007 16:15:48 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcSBJ-00071p-A1; Fri, 13 Apr 2007 16:15:41 -0400 Date: Fri, 13 Apr 2007 16:15:41 -0400 To: Mark Davis Message-ID: <20070413201541.GR7353@mercury.ccil.org> References: <461F92E0.72CC@xyzzy.claranet.de> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Frank Ellermann , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > That means that in ISO 639-2 the following are collections: > mul Multiple languages Yes, unfortunately. 639-3 takes a more sensible stand, and calls 'und', 'zxx', and 'mul' special (as distinct from individual language, macrolanguage, collection, or private-use). > The language codes clearly do not form a partition, since some > collections encompass other codes. True. The collection codes, however, form a rootless hierarchy, a rather flat one, of which "mis" is one top-level component. > The collection codes that are tagged with (Other) are clearly meant > to be the remainder of partitions, but for the collections that are > not tagged with (Other) there is no evidence that they were intended > to exclude other cases -- if anything, the contrary -- if they had > meant to be the remainder of partitions, they would have said (Other). I think that's reading too much into them; the entries are the work of many hands. FWIU, all the "(Other)" epithets are being removed, anyhow. > Moreover, while some may be perfectly willing to have stability go by > the wayside, it is extremely important to us, and that is one of the > guiding principles of and reasons for BCP 47. That means that if I > validly and correctly tag content with "mis", that application cannot > be made incorrect by any future change to BCP 47. That is why we can > broaden the application of codes, but cannot narrow them. +1 > There is no evidence in BCP 47 that I cannot correctly tag the content > "kind" with "mis". There is no *evidence* that you cannot tag "George slipped on a banana peel and fell down" as "fr". It's a quality of implementation issue. -- Eric Raymond is the Margaret Mead John Cowan of the Open Source movement. cowan@ccil.org --Bruce Perens, http://www.ccil.org/~cowan some years ago _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 16:21: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 1HcSHG-0005YJ-JU; Fri, 13 Apr 2007 16:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSHF-0005YD-Gl for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:21:49 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSHE-0001KN-9V for ltru@lists.ietf.org; Fri, 13 Apr 2007 16:21:49 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcSH7-0007PA-Cb; Fri, 13 Apr 2007 16:21:41 -0400 Date: Fri, 13 Apr 2007 16:21:41 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: For review: Tagging text with no language Message-ID: <20070413202141.GS7353@mercury.ccil.org> References: <461F5FF7.6A90@xyzzy.claranet.de> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Frank Ellermann , www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > With respect to computer language snippets, isn't that what the tag > is for -- at least in XHTML? Well, yes, but there is no standard way of saying *which* computer language it is. For one thing, there is no standard list of computer languages. -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; cowan@ccil.org Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 16:44: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 1HcSdP-0002bh-5Y; Fri, 13 Apr 2007 16:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSdO-0002bc-4X for ltru@ietf.org; Fri, 13 Apr 2007 16:44:42 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSdM-0001YZ-Lj for ltru@ietf.org; Fri, 13 Apr 2007 16:44:42 -0400 Received: by nz-out-0506.google.com with SMTP id z6so923931nzd for ; Fri, 13 Apr 2007 13:44:40 -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=NBOO9SkPEKfy0LMGrxIxpG54Uz8IBxXTM86jutOAcUkVJvE1ZMV+MPXE5GePywjYCY2uo3VRjhSSsDYL4AE8++ml/2kYpnkHJ6aPsd80QPdvuV8jMoFK5EALNzSHanRECQb9CJWC/hIc00ZTB57UUAkWbYp9SZSsut4VDR1zkLs= 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=Bqm2+n6kzkm9hzfYdiExZ8XpkelRpX1yAGaG+CIbvv9dAbKw32puvGGAg7xkHkRSUBouBZ+gnr3ZmH3tSqjjwV7ieV+OiPJl4sZktt9Ron1uSthpmvG1x2Qax1zZqMSnIyIbpyWseb9tipBP/FDrGH5pON8Uqdl1CDkF9jCJgo0= Received: by 10.114.171.1 with SMTP id t1mr1101353wae.1176497079979; Fri, 13 Apr 2007 13:44:39 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 13:44:39 -0700 (PDT) Message-ID: <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> Date: Fri, 13 Apr 2007 13:44:39 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <20070413201541.GR7353@mercury.ccil.org> MIME-Version: 1.0 References: <461F92E0.72CC@xyzzy.claranet.de> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> X-Google-Sender-Auth: d51d031a0f860672 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Frank Ellermann , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1164348728==" Errors-To: ltru-bounces@ietf.org --===============1164348728== Content-Type: multipart/alternative; boundary="----=_Part_15957_4421446.1176497079895" ------=_Part_15957_4421446.1176497079895 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/13/07, John Cowan wrote: > > Mark Davis scripsit: > > > That means that in ISO 639-2 the following are collections: > > > mul Multiple languages > > Yes, unfortunately. 639-3 takes a more sensible stand, and calls > 'und', 'zxx', and 'mul' special (as distinct from individual language, > macrolanguage, collection, or private-use). > > > The language codes clearly do not form a partition, since some > > collections encompass other codes. > > True. The collection codes, however, form a rootless hierarchy, > a rather flat one, of which "mis" is one top-level component. > > > The collection codes that are tagged with (Other) are clearly meant > > to be the remainder of partitions, but for the collections that are > > not tagged with (Other) there is no evidence that they were intended > > to exclude other cases -- if anything, the contrary -- if they had > > meant to be the remainder of partitions, they would have said (Other). > > I think that's reading too much into them; the entries are the work > of many hands. FWIU, all the "(Other)" epithets are being removed, > anyhow. What is in the specification is what we can use to establish the semantics of the code at introduction into BCP 47, which then determines whether any successive changes to the Description are allowed (broadenings) or not. > Moreover, while some may be perfectly willing to have stability go by > > the wayside, it is extremely important to us, and that is one of the > > guiding principles of and reasons for BCP 47. That means that if I > > validly and correctly tag content with "mis", that application cannot > > be made incorrect by any future change to BCP 47. That is why we can > > broaden the application of codes, but cannot narrow them. > > +1 > > > There is no evidence in BCP 47 that I cannot correctly tag the content > > "kind" with "mis". > > There is no *evidence* that you cannot tag "George slipped on a banana > peel and fell down" as "fr". It's a quality of implementation issue. I disagree. Any reasonable person with a knowledge of French and looking over the text of the standard would say that tagging that sentence with "fr" is a mistake. The same is not true of 'mis'. -- > Eric Raymond is the Margaret Mead John Cowan > of the Open Source movement. cowan@ccil.org > --Bruce Perens, http://www.ccil.org/~cowan > some years ago > -- Mark ------=_Part_15957_4421446.1176497079895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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

> That means that in ISO 639-2 the following are collections:

> mul             Multiple languages

Yes, unfortunately.  639-3 takes a more sensible stand, and calls
'und', 'zxx', and 'mul' special (as distinct from individual language,
macrolanguage, collection, or private-use).

> The language codes clearly do not form a partition, since some
> collections encompass other codes.

True.  The collection codes, however, form a rootless hierarchy,
a rather flat one, of which "mis" is one top-level component.

> The collection codes that are tagged with (Other) are clearly meant
> to be the remainder of partitions, but for the collections that are
> not tagged with (Other) there is no evidence that they were intended
> to exclude other cases -- if anything, the contrary -- if they had
> meant to be the remainder of partitions, they would have said (Other).

I think that's reading too much into them; the entries are the work
of many hands.  FWIU, all the "(Other)" epithets are being removed,
anyhow.

What is in the specification is what we can use to establish the semantics of the code at introduction into BCP 47, which then determines whether any successive changes to the Description are allowed (broadenings) or not.

> Moreover, while some may be perfectly willing to have stability go by
> the wayside, it is extremely important to us, and that is one of the
> guiding principles of and reasons for BCP 47. That means that if I
> validly and correctly tag content with "mis", that application cannot
> be made incorrect by any future change to BCP 47. That is why we can
> broaden the application of codes, but cannot narrow them.

+1

> There is no evidence in BCP 47 that I cannot correctly tag the content
> "kind" with "mis".

There is no *evidence* that you cannot tag "George slipped on a banana
peel and fell down" as "fr".  It's a quality of implementation issue.

I disagree. Any reasonable person with a knowledge of French and looking over the text of the standard would say that tagging that sentence with "fr" is a mistake. The same is not true of 'mis'.

--
Eric Raymond is the Margaret Mead               John Cowan
of the Open Source movement.                     cowan@ccil.org
        --Bruce Perens,                         http://www.ccil.org/~cowan
          some years ago



--
Mark ------=_Part_15957_4421446.1176497079895-- --===============1164348728== 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 --===============1164348728==-- From ltru-bounces@ietf.org Fri Apr 13 16:53: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 1HcSls-0000ev-LB; Fri, 13 Apr 2007 16:53:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSlr-0000cJ-2s for ltru@ietf.org; Fri, 13 Apr 2007 16:53:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HcSlp-0003Dn-Os for ltru@ietf.org; Fri, 13 Apr 2007 16:53:26 -0400 Received: by nz-out-0506.google.com with SMTP id z6so926270nzd for ; Fri, 13 Apr 2007 13:53:25 -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=dtfaO7bX71MnKeURGZrTuVH/TnC7RxN0gw20JtPFBsNhSZIODAi6b/0AAn2yv0QixyfjfI5GkgzVxFxel51ZalEqSHUTwJNCzN0sO/PatRyzxXJKYYAe1KFe+SJX7ziSl+OV9qLni5nwCqGCEiLl8/TFsC4uJDyPjkgzW2P4QPk= 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=Sn6D73QgKpJz+/kRKBvm8f0WBPC1K7VZWg3A+NwBKsHkO4XmSLBPmM5kDzsjqx4HFrs+GAAsqdpxQ/s/BQk+JRQnTf9TvCoIUm4ehxYiRag8+E6Wfi6MLtzpDeZVBPpKEjYKEM69CgIYuxS1K36ps4/l7x+0nLZvedpyeSi7iec= Received: by 10.114.145.1 with SMTP id s1mr1100764wad.1176497604761; Fri, 13 Apr 2007 13:53:24 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 13:53:24 -0700 (PDT) Message-ID: <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> Date: Fri, 13 Apr 2007 13:53:24 -0700 From: "Mark Davis" To: "John Cowan" In-Reply-To: <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> MIME-Version: 1.0 References: <461F92E0.72CC@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> X-Google-Sender-Auth: d80af64c7682ebb5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Frank Ellermann , LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0129612667==" Errors-To: ltru-bounces@ietf.org --===============0129612667== Content-Type: multipart/alternative; boundary="----=_Part_16217_6111809.1176497604357" ------=_Part_16217_6111809.1176497604357 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Also, True. The collection codes, however, form a rootless hierarchy, > > a rather flat one, of which "mis" is one top-level component. > > You might like this to be true, but I don't see any substantiation of it in the standard. If you could point me to that, I'd appreciate it. -- Mark ------=_Part_16217_6111809.1176497604357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Also,


True.  The collection codes, however, form a rootless hierarchy,
a rather flat one, of which "mis" is one top-level component.

You might like this to be true, but I don't see any substantiation of it in the standard. If you could point me to that, I'd appreciate it.

--
Mark ------=_Part_16217_6111809.1176497604357-- --===============0129612667== 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 --===============0129612667==-- From ltru-bounces@ietf.org Fri Apr 13 17:06: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 1HcSys-000319-RG; Fri, 13 Apr 2007 17:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSyr-000313-KQ for ltru@ietf.org; Fri, 13 Apr 2007 17:06:53 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSyp-00073w-Be for ltru@ietf.org; Fri, 13 Apr 2007 17:06:53 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcSyp-0002RK-00; Fri, 13 Apr 2007 17:06:51 -0400 Date: Fri, 13 Apr 2007 17:06:50 -0400 To: Mark Davis Message-ID: <20070413210650.GB29983@mercury.ccil.org> References: <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > You might like this to be true, but I don't see any substantiation of > it in the standard. If you could point me to that, I'd appreciate it. It seems rather self-evident to me that 'ber' is a subset of 'afa', and so on; but no, the standard doesn't say so. It does, however, say: A collective language code is not intended to be used when an individual language code or another more specific collective language code is available. http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1 I take that to mean that "afa" is unsuitable for a Berber language, and "ger" is unsuitable for English. A fortiori, "mis" is unsuitable for a language for which a better code is available. Questionless, this contradicts the desire for stability, but I don't see what's to be done about it. I tried at one point to get all language collection codes deprecated, but it was pointed out that there are good reasons for having them, as when insufficient evidence is available. -- John Cowan cowan@ccil.org http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 17:08: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 1HcT0A-0003cg-94; Fri, 13 Apr 2007 17:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT09-0003cZ-NH for ltru@lists.ietf.org; Fri, 13 Apr 2007 17:08:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcT09-0007Zr-CB for ltru@lists.ietf.org; Fri, 13 Apr 2007 17:08:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcSzv-0007Jq-QI for ltru@lists.ietf.org; Fri, 13 Apr 2007 23:08:00 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 23:07:59 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 23:07:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 23:06:37 +0200 Organization: Lines: 30 Message-ID: <461FF0DD.26E4@xyzzy.claranet.de> References: <20070413122917.GA25431@nic.fr> <461F92E0.72CC@xyzzy.claranet.de><461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr><461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf-languages@alvestrand.no Subject: [Ltru] mis, und, art (was: "mis" update review request) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > I find it very difficult to imagine a case where "mis" would > be useful in tagging data. Mark finds new wild and wonderful ways to (ab)use "mis" while we're talking. Based on exactly the same mis-conception I had until yesterday when John shed some light on it. There's a "high astonishing factor" in what "mis" really means, the very minimum is to document it, preventing further havoc. The only other alternative I see is to deprecate the "mis" tag either by convincing ISO 639, or with brute force in 4646bis. > perhaps we could conclude that this whole debate is really > academic, and that no action is needed. Strong NAK. Mark has also plausible ideas how to (ab)use "art", maybe that also deserves a comment in the registry. IMO less critical because 4646 is very clear that it's really not about programming languages. Last but not least Mark found a plausible way to use "und" as a kind of anchor for "whatever it is, I know the script", as in und-Latn. The SHOULD NOT in RFC 4646 is apparently wrong, und-Latn is an excellent use case. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 17:34: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 1HcTPy-0002mG-Hw; Fri, 13 Apr 2007 17:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTPx-0002m8-IV for ltru@lists.ietf.org; Fri, 13 Apr 2007 17:34:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTPw-0006yu-93 for ltru@lists.ietf.org; Fri, 13 Apr 2007 17:34:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcTPh-0003Pm-Op for ltru@lists.ietf.org; Fri, 13 Apr 2007 23:34:37 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 23:34:37 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 23:34:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Apr 2007 23:33:36 +0200 Organization: Lines: 19 Message-ID: <461FF730.2534@xyzzy.claranet.de> References: <461F5FF7.6A90@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > With respect to computer language snippets, isn't that what the > tag is for -- at least in XHTML? Yes, typically interpreted as switch to a monospaced font. But maybe not good enough to convince spell-checkers that they should skip this part, or to convince screenreaders that what follows might be not in the inherited xml:lang. While we're at it, IIRC you wanted a SHOULD NOT about script subtags for "no linguistic content". Mark's list of interesting examples also contains a "zxx" use case, and it's clearly a zxx-Latn example. Apparently the SHOULD NOT in RFC 4646 about "und" is already dubious, so better we don't add another shaky SHOULD NOT about scripts for "zxx". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 18:08:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTwP-0004pU-0r; Fri, 13 Apr 2007 18:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTwN-0004pK-Fq for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:08:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTwN-0007QR-1T for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:08:23 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcTw0-000285-Hk for ltru@lists.ietf.org; Sat, 14 Apr 2007 00:08:02 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 00:08:00 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 00:08:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Apr 2007 00:02:03 +0200 Organization: Lines: 61 Message-ID: <461FFDDB.57BC@xyzzy.claranet.de> References: <20070412170013.GF16269@mercury.ccil.org> <30b660a20704121506y1ec8d3ady259e13b356249e6e@mail.gmail.com> <6.1.1.1.2.20070412153325.021a5dc8@namailhost.corp.adobe.com> <006101c77d5a$02c768a0$f962f853@streamserve.com> <6.1.1.1.2.20070412164741.0221e5b0@namailhost.corp.adobe.com> <30b660a20704121815j59e854dxf7cf5f53a48ece21@mail.gmail.com> <20070413020422.GC7353@mercury.ccil.org> <30b660a20704130757v4857d64bqab05de27320f94c0@mail.gmail.com> <30b660a20704130924y1d728373k87fda62ec69def38@mail.gmail.com> <461FBAD8.1A79@xyzzy.claranet.de> <30b660a20704131252h19b75709mea47be6cb5bccfa9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: [chat] > 'und' is possible, but I think that mul conveys more information. This "more info" could be wrong if you're sure that it's either 'chat' or 'cat'. With "mul" you can justify 'en AND fr', arguably you can also justify 'en OR fr'. I'd draw the line at 'en XOR fr', that's not "mul". [Igonda flatunicai vbinkli?] >> That would be wrong for almost all languages not yet in the >> registry belonging to another collection like "ger". > It's not wrong. I agree that where possible, one 'should' tag as > precisely as possible, but there is no requirement to in the RFC. Using "mis" instead of "ger" is like using "fr" instead of "en", it's plain wrong based on John's explanations and the sources he has cited. The RFC doesn't forbid wrong or misleading tags, but the registry also shouldn't encourage wrong or misleading tags. Obviously I was like you also misled by "mis", it doesn't mean that it belongs to "miscellaneous languages" from the POV of a tagger. It means that it belongs to a clearly defined set of "miscellaneous languages" defined by ISO 639. Above all a volatile set, all these collections (including "mis") could be changed by ISO 639 whenever they find new evidence justifying it. That's about as horrible as your now long dead EU proposal, where complete countries and territories on all continents could be added (= minor problem) or removed (= major issue for stability). This "mis" collection is IMO dangerous. It's worse than generic variants. The least we can do is discourage its (ab)use. All registry users could have the same mis-conception about "mis" if we do nothing. > If you could outline for me the reasoning, based on the standards, > behind saying that 'mis' is not correct, I'd appreciate it. Your 2nd example sounds like Polish for me, and no language remotely related to Polish belongs to the weird "mis" collection. Trying "ger" would be clearly wrong, but not as wrong as "mis". >> I think "art" is about artificial languages for humans or in >> fiction, not for programming languages. > That may well be, it is just not clear to me from the specification. [A. Phillips, Ed. Yahoo! Inc. M. Davis, Ed. Google September 2006] | 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. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 18: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 1HcUA4-0006Wr-Fj; Fri, 13 Apr 2007 18:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUA2-0006Te-DA for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:22:30 -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 1HcU9x-0005MA-GU for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:22:30 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id B247314F3691; Fri, 13 Apr 2007 22:22:23 +0000 (UTC) Received: from mail32-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 856BB528054; Fri, 13 Apr 2007 22:22:23 +0000 (UTC) Received: from mail32-sin (localhost.localdomain [127.0.0.1]) by mail32-sin-R.bigfish.com (Postfix) with ESMTP id 5CB3A2F040D; Fri, 13 Apr 2007 22:22:23 +0000 (UTC) X-BigFish: VP Received: by mail32-sin (MessageSwitch) id 1176502943302436_2482; Fri, 13 Apr 2007 22:22:23 +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 mail32-sin.bigfish.com (Postfix) with ESMTP id CB358A1806A; Fri, 13 Apr 2007 22:22:22 +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 2007041315221701-53816 ; Fri, 13 Apr 2007 15:22:17 -0700 In-Reply-To: To: "Jukka K. Korpela" Subject: Re: [Ltru] Re: For review: Tagging text with no language 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, 13 Apr 2007 15:20:28 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/13/2007 15:20:28, Serialize complete at 04/13/2007 15:20:28, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 03:22:17 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 03:22:22 PM, Serialize complete at 04/13/2007 03:22:22 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1575426949==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1575426949== Content-Type: multipart/alternative; boundary="=_alternative 007AE398882572BC_=" This is a multipart message in MIME format. --=_alternative 007AE398882572BC_= Content-Type: text/plain; charset="US-ASCII" I agree with you. I would also say that indicating that computer languages have "no linguistic content" is not quite accurate for the same reasons you cite below and disagrees with the origin of the zxx tag, which was to indicate a total absence of language, not content which is not in a natural language. Karen Broome www-international-request@w3.org wrote on 04/13/2007 01:08:33 PM: > > On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote: > > > With respect to computer language snippets, isn't that what the tag > > is for -- at least in XHTML? > > has been in HTML since the beginning, and it indeed indicates > computer code, or "computer language". > > But to make things more difficult, computer code - such as program code, > operating system commands, or markup - can be regarded as being in some > human language(s) in the sense that the identifiers may have been formed > from words in human languages and the comments are written in some human > languages. Knowing the language of computer code can be relevant at least > for two purposes: > a) the understandability of the code to human readers depends on whether > they understand the human language(s) used > b) speech synthesis would benefit from the use of language information. > Moreover, a checking program could e.g. check that the code follows the > syntactic rules of the programming, command, or markup "language" _and_ > check the comments using a suitable human language spelling checker. > > Thus, I would say that the human language some text and the role of that > text as computer code are in a sense orthogonal. > > -- > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ > > > --=_alternative 007AE398882572BC_= Content-Type: text/html; charset="US-ASCII"
I agree with you. I would also say that indicating that computer languages have "no linguistic content" is not quite accurate for the same reasons you cite below and disagrees with the origin of the zxx tag, which was to indicate a total absence of language, not content which is not in a natural language.  

Karen Broome

www-international-request@w3.org wrote on 04/13/2007 01:08:33 PM:

>
> On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote:
>
> > With respect to computer language snippets, isn't that what the <code> tag
> > is for -- at least in XHTML?
>
> <code> has been in HTML since the beginning, and it indeed indicates
> computer code, or "computer language".
>
> But to make things more difficult, computer code - such as program code,
> operating system commands, or markup - can be regarded as being in some
> human language(s) in the sense that the identifiers may have been formed
> from words in human languages and the comments are written in some human
> languages. Knowing the language of computer code can be relevant at least
> for two purposes:
> a) the understandability of the code to human readers depends on whether
>     they understand the human language(s) used
> b) speech synthesis would benefit from the use of language information.
> Moreover, a checking program could e.g. check that the code follows the
> syntactic rules of the programming, command, or markup "language" _and_
> check the comments using a suitable human language spelling checker.
>
> Thus, I would say that the human language some text and the role of that
> text as computer code are in a sense orthogonal.
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
>
--=_alternative 007AE398882572BC_=-- --===============1575426949== 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 --===============1575426949==-- From ltru-bounces@ietf.org Fri Apr 13 18:26: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 1HcUDT-0007tJ-9P; Fri, 13 Apr 2007 18:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUDS-0007tE-5Z for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:26:02 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUDQ-000672-RW for ltru@lists.ietf.org; Fri, 13 Apr 2007 18:26:02 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcUDP-0008Ti-Hy; Fri, 13 Apr 2007 18:25:59 -0400 Date: Fri, 13 Apr 2007 18:25:59 -0400 To: Randy Presuhn Message-ID: <20070413222559.GF29983@mercury.ccil.org> References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c77e00$fb1e1160$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ietf-languages@alvestrand.no, ltru@lists.ietf.org Subject: [Ltru] Collection tags considered problematic (was: "mis" update review request) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > The thing that bothers me about the comment "A collection of languages > which don't belong to any other collection" is that it isn't compatible > with the possibility that one or more of those languages might > eventually be included in another (possibly new) collection. If that > langauage were left in the mis collection as well, the comment would > be incorrect. If the language were removed from the mis collection, > stability goes out the window. Either way, changing the comment > wouldn't help the situation. That's true, but it's also true of all other collection subtags. "Mis" is a particularly bad case, but it's not hard to devise other problematic situations; I've changed the Subject: line accordingly. For example, today Slobbovian (hypothetical) might be considered a Slavic language with a heavy Germanic substrate, but tomorrow Thingummy might be able to show conclusively that it was really a Germanic language with a heavy Slavic superstrate. That would invalidate the old "sla" tag for the Slobbovian Declaration of Independence in favor of a "ger" one, but since collections are not and cannot in practice be defined by enumeration, such things can't be avoided. I think we must accept that there is some risk of instability when language collection subtags are used; that's a tradeoff against their convenience. Bullet point 3 of section 4.1 of rfc-4646-04 currently says: Use specific language subtags or subtag sequences in preference to subtags for language collections. A "language collection" is a subtag derived from one of the ISO 639-2 codes that represents multiple related languages. For example, the code 'cmc' represents "Chamic languages". The registry contains values for each of the approximately ten individual languages represented by this collective code. For example 'jra' (Jarai) and 'cja' (Western Cham). I suggest adding the following additional text: Using a collective language code may often be convenient or necessary when detailed information is not available. However, collections are defined not by enumerating specific languages, but by genetic or other criteria, and so a specific language may be moved out of a given collection if further information about the language becomes available. Thus collective language codes are inherently more unstable. For guidance in interpreting these suggestions, I think we now need to include the 639-3 scope information in language subtags: "individual language", "macrolanguage", "collective" or "private use". -- John Cowan http://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 19:03: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 1HcUng-0005oy-7h; Fri, 13 Apr 2007 19:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUne-0005oq-S4 for ltru@ietf.org; Fri, 13 Apr 2007 19:03:26 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUnd-00028i-47 for ltru@ietf.org; Fri, 13 Apr 2007 19:03:26 -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.685.24; Fri, 13 Apr 2007 16:03:24 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 13 Apr 2007 16:03:24 -0700 From: Peter Constable To: LTRU Working Group , "ietf-languages@alvestrand.no" Date: Fri, 13 Apr 2007 16:03:20 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd9/ICz9aCBochCTaK8CWWL9+DRHQAIa1dA Message-ID: References: <20070413122917.GA25431@nic.fr> <461F92E0.72CC@xyzzy.claranet.de> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> In-Reply-To: <30b660a20704131149u6ad624feke9d5840ed49d9c4a@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.1 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454009578==" Errors-To: ltru-bounces@ietf.org --===============1454009578== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA0NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA0NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's my impression that, in MARC, the categories were considered to be an e= xception. At this point in ISO 639, I think the collections cannot be treat= ed as partitions: the additions in 639-3 basically undermine that assumptio= n. However, it might still be possible to treat the *collections* as a part= ition. None of that changes the intention of mis in MARC, which I'd have to say is= the same intention in ISO 639: mis is the "else" case - i.e. none of the o= ther coded categories fits. The problem with mis is one of maintainability:= any time a new entry is added in ISO 639, some documents tagged with mis m= ay suddenly become inappropriately tagged. Peter From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Friday, April 13, 2007 11:50 AM To: John Cowan Cc: Frank Ellermann; LTRU Working Group; ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request You are right about number one; I concede that point fully -- I'd overlooke= d that phrasing, sorry. That means that in ISO 639-2 the following are coll= ections: mul Multiple languages art Artificial (Other) plus more normal cases: afa Afro-Asiatic (Other) alg Algonquian languages ... and the following are not collections. und Undetermined zxx No linguistic content I disagree with your point number two. The only reason that I can conclude = that "Miscellaneous Expenses" in a spreadsheet excludes the other listed ca= tegories is that I know that everything listed is intended to be a partitio= n. The language codes clearly do not form a partition, since some collectio= ns encompass other codes. The collection codes that are tagged with (Other)= are clearly meant to be the remainder of partitions, but for the collectio= ns that are not tagged with (Other) there is no evidence that they were int= ended to exclude other cases -- if anything, the contrary -- if they had me= ant to be the remainder of partitions, they would have said (Other). Moreover, while some may be perfectly willing to have stability go by the w= ayside, it is extremely important to us, and that is one of the guiding pri= nciples of and reasons for BCP 47. That means that if I validly and correct= ly tag content with "mis", that application cannot be made incorrect by any= future change to BCP 47. That is why we can broaden the application of cod= es, but cannot narrow them. There is no evidence in BCP 47 that I cannot co= rrectly tag the content "kind" with "mis". Now, of course, we all know that= we should tag with as much information as we can, so I *should* tag that w= ith "en" if I know I mean the English word, and "de" if I mean the German, = or possibly others. If I don't know which one it is, if my protocol allows = multiple tags I can use "en, de", and if not I am forced into a choice betw= een "mul" or choosing the 'most likely' language of the set. Mark On 4/13/07, John Cowan > wrote: Mark Davis scripsit: > Saying that mis is a collection is not breaking, but also not > substantiated by ISO 639-2. It's just unfathomable to me how you can get that reading of the standard. > http://www.loc.gov/standards/iso639-2/normtext.html which says (section 4.1.1, second sentence): The words *languages* or *(other)* as part of a language name in the following tables may be taken to indicate that a language code is a collective language code. > http://www.loc.gov/standards/iso639-2/php/code_list.php which says (s.v. "mis") Miscellaneous languages Note the word *languages*. Game, set, and match (or Q, E, and D). > Saying that "which don't belong to any other collection" is a breaking > change, *and* is not substantiated by ISO 639-2 at the time the code was > added to the registry (or even now). Come, come. Do you expect us, the members of this list, to suppose that when a spreadsheet contains the line "Miscellaneous expenses" you will find there charges for capital construction or salaries? You will not. You will find expenses *that do not fit into any other category* on the spreadsheet. -- One art / There is John Cowan < cowan@ccil.org> No less / No more http://www.ccil.org/~cowan All things / To do With sparks / Galore -- Douglas Hofstadter -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA0NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s my impression that, in MARC, the categories were considered to be an exception. At this point in ISO 639, I think the collections cannot be treated as partitions: the additions in 639-3 basical= ly undermine that assumption. However, it might still be possible to treat the= *collections* as a partition.

 

None of that changes the intention of mis in MARC, which I&#= 8217;d have to say is the same intention in ISO 639: mis is the “else” case – i.e. none of the other coded categories fits. The problem with= mis is one of maintainability: any time a new entry is added in ISO 639, some documents tagged with mis may suddenly become inappropriately tagged.<= /o:p>

 

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Friday, April 13, 2007 11:50 AM
To: John Cowan
Cc: Frank Ellermann; LTRU Working Group; ietf-languages@alvestrand.n= o
Subject: [Ltru] Re: "mis" update review request=

 

You are right about num= ber one; I concede that point fully -- I'd overlooked that phrasing, sorry. That mea= ns that in ISO 639-2 the following are collections:

mul             Multiple langu= ages
art             Artificial (Ot= her)

plus more normal cases:

afa             Afro-Asiatic (Other)
alg             Algonquian languages
...

and the following are not collections.

und             Undetermined zxx             No linguistic content


I disagree with your point number two. The only reason that I can conclude = that "Miscellaneous Expenses" in a spreadsheet excludes the other list= ed categories is that I know that everything listed is intended to be a partit= ion. The language codes clearly do not form a partition, since some collections encompass other codes. The collection codes that are tagged with (Other) ar= e clearly meant to be the remainder of partitions, but for the collections th= at are not tagged with (Other) there is no evidence that they were intended to exclude other cases -- if anything, the contrary -- if they had meant to be= the remainder of partitions, they would have said (Other).

Moreover, while some may be perfectly willing to have stability go by the wayside, it is extremely important to us, and that is one of the guiding principles of and reasons for BCP 47. That means that if I validly and correctly tag content with "mis", that application cannot be made incorrect by any future change to BCP 47. That is why we can broaden the application of codes, but cannot narrow them. There is no evidence in BCP 4= 7 that I cannot correctly tag the content "kind" with "mis&quo= t;. Now, of course, we all know that we should tag with as much information as = we can, so I *should* tag that with "en" if I know I mean the Englis= h word, and "de" if I mean the German, or possibly others. If I don= 't know which one it is, if my protocol allows multiple tags I can use "e= n, de", and if not I am forced into a choice between "mul" or choosing the 'most likely' language of the set.

Mark

On 4/13/07, John Cowan= <cowan@ccil.org> wrote:

Mark Davis scripsit:

> Saying that mis is a collection is not breaking, but also not
> substantiated by ISO 639-2.

It's just unfathomable to me how you can get that reading of the standard.<= br>
> http:/= /www.loc.gov/standards/iso639-2/normtext.html

which says (section 4.1.1, second sentence):

        The words *languages* or *(other)* as part of a language name
        in the following tables may= be taken to indicate that a language
        code is a collective langua= ge code.

> ht= tp://www.loc.gov/standards/iso639-2/php/code_list.php

which says (s.v. "mis")

        Miscellaneous languages

Note the word *languages*.  Game, set, and match (or Q, E, and D)= .


> Saying that "which don't belong to any other collection" is = a breaking
> change, *and* is not substantiated by ISO 639-2 at the time the code w= as
> added to the registry (or even now).

Come, come.  Do you expect us, the members of this list, to suppo= se
that when a spreadsheet contains the line "Miscellaneous expenses"= ;
you will find there charges for capital construction or salaries?
You will not.  You will find expenses *that do not fit into any other category* on the spreadsheet.

--
One art / There is            &= nbsp;         John Cowan < cowan@ccil.org>
No less / No more            = ;           http://www.ccil.org/~cowan
All things / To do
With sparks / Galore         &= nbsp;           -- Douglas Hofstadter




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA0NAEXMSGC117re_-- --===============1454009578== 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 --===============1454009578==-- From ltru-bounces@ietf.org Fri Apr 13 19:03: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 1HcUo6-00061O-KN; Fri, 13 Apr 2007 19:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUo5-000619-9g for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:03:53 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound2-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUo4-0002TD-NX for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:03:53 -0400 Received: from outbound2-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-fra-R.bigfish.com (Postfix) with ESMTP id 1700A7D0065; Fri, 13 Apr 2007 23:03:52 +0000 (UTC) Received: from mail11-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound2-fra.bigfish.com (Postfix) with ESMTP id 14D45738058; Fri, 13 Apr 2007 23:03:52 +0000 (UTC) Received: from mail11-fra (localhost.localdomain [127.0.0.1]) by mail11-fra-R.bigfish.com (Postfix) with ESMTP id 0733B170059; Fri, 13 Apr 2007 23:03:52 +0000 (UTC) X-BigFish: VP Received: by mail11-fra (MessageSwitch) id 1176505430955863_13196; Fri, 13 Apr 2007 23:03:50 +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 mail11-fra.bigfish.com (Postfix) with ESMTP id BE881AE0059; Fri, 13 Apr 2007 23:03: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 2007041316034789-56013 ; Fri, 13 Apr 2007 16:03:47 -0700 In-Reply-To: <461FF730.2534@xyzzy.claranet.de> To: Frank Ellermann Subject: Re: [Ltru] Re: For review: Tagging text with no language 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, 13 Apr 2007 16:01:59 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/13/2007 16:01:59, Serialize complete at 04/13/2007 16:01:59, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 04:03:47 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 04:03:50 PM, Serialize complete at 04/13/2007 04:03:50 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0346324223==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0346324223== Content-Type: multipart/alternative; boundary="=_alternative 007EB0A1882572BC_=" This is a multipart message in MIME format. --=_alternative 007EB0A1882572BC_= Content-Type: text/plain; charset="US-ASCII" Well, if the code section is delimited with a consistent tag, you know to treat what's in there differently than the rest of the text. I used to edit technical tutorials for O'Reilly, so trust me, the tag and I are old friends. On that site the code tag drives style sheets, but it is really a semantic delimiter -- not a design element -- and can potentially be used for a lot more. I'm a bit leery of spellcheckers for code. But as long as the code section is delimited, you can write spellcheckers or screenreaders that will handle that text differently. I did not request a SHOULD NOT with "no linguistic content." My request was that script tags SHOULD NOT be used with linguistic *audio* content because spoken language, by definition, is not written down. I really don't have much use for the zxx tag. I saw a use case that related to und-Latn that made sense, but zxx-Latn makes no sense to me. Did I miss that thread or is that a typo? Regards, Karen Broome Frank Ellermann 04/13/2007 02:33 PM To ltru@lists.ietf.org cc www-international@w3.org Subject [Ltru] Re: For review: Tagging text with no language Karen_Broome@spe.sony.com wrote: > With respect to computer language snippets, isn't that what the > tag is for -- at least in XHTML? Yes, typically interpreted as switch to a monospaced font. But maybe not good enough to convince spell-checkers that they should skip this part, or to convince screenreaders that what follows might be not in the inherited xml:lang. While we're at it, IIRC you wanted a SHOULD NOT about script subtags for "no linguistic content". Mark's list of interesting examples also contains a "zxx" use case, and it's clearly a zxx-Latn example. Apparently the SHOULD NOT in RFC 4646 about "und" is already dubious, so better we don't add another shaky SHOULD NOT about scripts for "zxx". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 007EB0A1882572BC_= Content-Type: text/html; charset="US-ASCII"
Well, if the code section is delimited with a consistent tag, you know to treat what's in there differently than the rest of the text. I used to edit technical tutorials for O'Reilly, so trust me, the <code> tag and I are old friends. On that site the code tag drives style sheets, but it is really a semantic delimiter -- not a design element -- and can potentially be used for a lot more. I'm a bit leery of spellcheckers for code.

But as long as the code section is delimited, you can write spellcheckers or screenreaders that  will handle that text differently.

I did not request a SHOULD NOT with "no linguistic content." My request was that script tags SHOULD NOT be used with linguistic *audio* content because spoken language, by definition, is not written down. I really don't have much use for the zxx tag.  I saw a use case that related to und-Latn that made sense, but zxx-Latn makes no sense to me. Did I miss that thread or is that a typo?

Regards,

Karen Broome


Frank Ellermann <nobody@xyzzy.claranet.de>

04/13/2007 02:33 PM

To
ltru@lists.ietf.org
cc
www-international@w3.org
Subject
[Ltru] Re: For review: Tagging text with no language





Karen_Broome@spe.sony.com wrote:

> With respect to computer language snippets, isn't that what the <code>
> tag is for -- at least in XHTML?

Yes, typically interpreted as switch to a monospaced font.  But maybe
not good enough to convince spell-checkers that they should skip this
part, or to convince screenreaders that what follows might be not in
the inherited xml:lang.

While we're at it, IIRC you wanted a SHOULD NOT about script subtags
for "no linguistic content".  Mark's list of interesting examples also
contains a "zxx" use case, and it's clearly a zxx-Latn example.

Apparently the SHOULD NOT in RFC 4646 about "und" is already dubious,
so better we don't add another shaky SHOULD NOT about scripts for "zxx".

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 007EB0A1882572BC_=-- --===============0346324223== 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 --===============0346324223==-- From ltru-bounces@ietf.org Fri Apr 13 19:10: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 1HcUuU-0000IH-1S; Fri, 13 Apr 2007 19:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUuS-0000Hp-Uw for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:10:28 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUqE-0003oR-Q3 for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:06:07 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 16:06:06 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Fri, 13 Apr 2007 16:06:06 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 13 Apr 2007 16:06:04 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd+BwcHSuvuA7vJQbCIHdLgZzx6QAAGSILQ Message-ID: References: <20070413122917.GA25431@nic.fr> <461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> In-Reply-To: <30b660a20704131304j5ccaeceev87b86cfdc84cf459@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.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2018659788==" Errors-To: ltru-bounces@ietf.org --===============2018659788== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA3NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA3NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the imperfect-knowledge scenario you describe where the process ends wi= th an "I don't know" conclusion, und is the appropriate tag, not mis. Peter From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Friday, April 13, 2007 1:05 PM To: Randy Presuhn Cc: ietf-languages@alvestrand.no; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request I agree with you about the stability issue. I think part of the problem in communicating about this is that people may = have somewhat different usage scenarios in mind. If you think of tagging as= something that a person does with content that they originate or have cont= rol over, then it is (probably) fairly straightforward for that person to t= ag as specifically as possible. Another scenario is where you have incoming content, and you need to tag it= for use by other components. This might be done, for example, in a search = engine, where you fetch and process a page, and use that information later = in doing searches. The tag serves to communicate language between the diffe= rent components. In that case, you have far from perfect information about the content: what= you have being typically the result of some level statistical analysis, pl= us other factors about the document. You need to tag with as much informati= on as you have, *but no more*. It is in that case where you need to have th= e tags that indicate some level of imperfect knowledge about the source, su= ch as "I have no idea what this is", or "It looks like linguistic content, = but I don't know which language", or "it doesn't look like linguistic conte= nt". (You may also have more detailed knowledge, like that some document ap= pears to have 70% English content (probability 95%) and 20% French content = (probability 65%)). Both scenarios are equally valid use cases for BCP 47 (in fact, as a percen= tage of data flow on the web, I'd wager strongly that the second scenario c= ompletely swamps the first). Mark On 4/13/07, Randy Presuhn > wrote: Hi - The thing that bothers me about the comment "A collection of languages whic= h don't belong to any other collection" is that it isn't compatible with the possibility that one or more of those languages might eventually be include= d in another (possibly new) collection. If that langauage were left in the m= is collection as well, the comment would be incorrect. If the language were removed from the mis collection, stability goes out the window. Either way= , changing the comment wouldn't help the situation. However, unlike some other collections, I find it very difficult to imagine a case where "mis" would be useful in tagging data. Without a clear use ca= se for "mis" in constructing a language tag, perhaps we could conclude that th= is whole debate is really academic, and that no action is needed. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA3NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the imperfect-knowledge scenario you describe where the process ends with an “I don’t know” conclusion, und is th= e appropriate tag, not mis.

 

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Friday, April 13, 2007 1:05 PM
To: Randy Presuhn
Cc: ietf-languages@alvestrand.no; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update review request

 

I agree with you about = the stability issue.

I think part of the problem in communicating about this is that people may = have somewhat different usage scenarios in mind. If you think of tagging as something that a person does with content that they originate or have contr= ol over, then it is (probably) fairly straightforward for that person to tag a= s specifically as possible.

Another scenario is where you have incoming content, and you need to tag it= for use by other components. This might be done, for example, in a search engin= e, where you fetch and process a page, and use that information later in doing searches. The tag serves to communicate language between the different components.

In that case, you have far from perfect information about the content: what= you have being typically the result of some level statistical analysis, plus ot= her factors about the document. You need to tag with as much information as you have, *but no more*. It is in that case where you need to have the tags tha= t indicate some level of imperfect knowledge about the source, such as "= I have no idea what this is", or "It looks like linguistic content,= but I don't know which language", or "it doesn't look like linguistic content". (You may also have more detailed knowledge, like that some document appears to have 70% English content (probability 95%) and 20% Fren= ch content (probability 65%)).

Both scenarios are equally valid use cases for BCP 47 (in fact, as a percen= tage of data flow on the web, I'd wager strongly that the second scenario comple= tely swamps the first).

Mark

On 4/13/07, Randy Presuhn<= /b> <randy_presuhn@mindspring.com> wrote:

Hi -

The thing that bothers me about the comment "A collection of languages which
don't belong to any other collection" is that it isn't compatible with= the
possibility that one or more of those languages might eventually be include= d
in another (possibly new) collection.  If that langauage were lef= t in the mis
collection as well, the comment would be incorrect.  If the langu= age were
removed from the mis collection, stability goes out the window.  Either way,
changing the comment wouldn't help the situation.

However, unlike some other collections, I find it very difficult to imagine=
a case where "mis" would be useful in tagging data.  Without a clear use case
for "mis" in constructing a language tag, perhaps we could conclu= de that this
whole debate is really academic, and that no action is needed.

Randy


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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8BA3NAEXMSGC117re_-- --===============2018659788== 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 --===============2018659788==-- From ltru-bounces@ietf.org Fri Apr 13 19:10: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 1HcUun-0000Kj-D1; Fri, 13 Apr 2007 19:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUum-0000KT-Gd for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:10:48 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUui-0004dM-61 for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:10:48 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcUuh-0003M9-SJ; Fri, 13 Apr 2007 19:10:43 -0400 Date: Fri, 13 Apr 2007 19:10:43 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: For review: Tagging text with no language Message-ID: <20070413231043.GG29983@mercury.ccil.org> References: <461FF730.2534@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > I did not request a SHOULD NOT with "no linguistic content." My request > was that script tags SHOULD NOT be used with linguistic *audio* content > because spoken language, by definition, is not written down. I really > don't have much use for the zxx tag. I saw a use case that related to > und-Latn that made sense, but zxx-Latn makes no sense to me. Did I miss > that thread or is that a typo? No, it makes sense: kj;lqwe4ropiuasfgpoiu243poiuq3p4okjasl;jk. -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 19:17: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 1HcV1W-0004wI-Gc; Fri, 13 Apr 2007 19:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcV1V-0004wD-HC for ltru@ietf.org; Fri, 13 Apr 2007 19:17:45 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcV1V-0006r1-5p for ltru@ietf.org; Fri, 13 Apr 2007 19:17:45 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 16:17:44 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 13 Apr 2007 16:17:44 -0700 From: Peter Constable To: LTRU Working Group , "ietf-languages@alvestrand.no" Date: Fri, 13 Apr 2007 16:17:42 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd+D6uVdNlEqU9tRiaD/e/O+VQ+jAAEbRjA Message-ID: References: <20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> In-Reply-To: <20070413210650.GB29983@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 ISO 639-2 is clear that the most specific category should be used. = That principle is implicit in the "(Other)" collections. I also think that = principle in combination with collections creates maintenance problems. (Wh= ich is why I suggested that all the "(Other)" entries should just be "langu= ages" entries.) (Btw, I think I suggested some time ago it might not be a bad thing to depr= ecate use of collection IDs in IETF language tags.) Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Friday, April 13, 2007 2:07 PM To: Mark Davis Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request Mark Davis scripsit: > You might like this to be true, but I don't see any substantiation of > it in the standard. If you could point me to that, I'd appreciate it. It seems rather self-evident to me that 'ber' is a subset of 'afa', and so on; but no, the standard doesn't say so. It does, however, say: A collective language code is not intended to be used when an individual language code or another more specific collective language code is available. http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1 I take that to mean that "afa" is unsuitable for a Berber language, and "ger" is unsuitable for English. A fortiori, "mis" is unsuitable for a language for which a better code is available. Questionless, this contradicts the desire for stability, but I don't see what's to be done about it. I tried at one point to get all language collection codes deprecated, but it was pointed out that there are good reasons for having them, as when insufficient evidence is available. -- John Cowan cowan@ccil.org http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940 _______________________________________________ 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 Apr 13 19:21: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 1HcV4x-00082i-3f; Fri, 13 Apr 2007 19:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcV4v-00081y-Cm for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:21:17 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcV4u-0000CK-47 for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:21:17 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 16:21:15 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Fri, 13 Apr 2007 16:21:15 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 13 Apr 2007 16:21:13 -0700 Subject: RE: [Ltru] mis, und, art (was: "mis" update review request) Thread-Topic: [Ltru] mis, und, art (was: "mis" update review request) Thread-Index: Acd+D91y8Y4mI2A8QAqzR1bbxZ1HKAAEiqJg Message-ID: References: <20070413122917.GA25431@nic.fr> <461F92E0.72CC@xyzzy.claranet.de><461F9828.46DB@xyzzy.claranet.de> <20070413150440.GA1780@nic.fr><461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <461FF0DD.26E4@xyzzy.claranet.de> In-Reply-To: <461FF0DD.26E4@xyzzy.claranet.de> 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: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > The only other alternative I see is to deprecate the "mis" tag > either by convincing ISO 639, or with brute force in 4646bis. I don't think it would be appropriate for ISO 639 to deprecate mis. It is a= ssumed that a large set of coded categories are provided and that particula= r applications may wish to use a "profile" -- i.e. some subset of the inven= tory. In the context of a particular application context using some particu= lar profile, mis may be appropriate as the "else" category. But it would be= up to that application to determine appropriate usage, including how to de= al with maintenance issues. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 19:34: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 1HcVHg-0007gI-4Y; Fri, 13 Apr 2007 19:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVHf-0007eE-Ht for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:34:27 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVHe-0004av-B6 for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:34:27 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcVHX-0004wp-1V; Fri, 13 Apr 2007 19:34:19 -0400 Date: Fri, 13 Apr 2007 19:34:19 -0400 To: Stephen Deach Subject: Re: [Ltru] Re: For review: Tagging text with no language Message-ID: <20070413233418.GH29983@mercury.ccil.org> References: <461FF730.2534@xyzzy.claranet.de> <20070413231043.GG29983@mercury.ccil.org> <6.1.1.1.2.20070413161725.0216bf90@namailhost.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20070413161725.0216bf90@namailhost.corp.adobe.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: www-international@w3.org, Karen_Broome@spe.sony.com, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephen Deach scripsit: > Is your intent to say: > "zxx: This string has no linguistic meaning, no-'language' (do not > apply grammar, spelling, hyphenation, word recognition, or other > language-based services)" Yes. > "Latn: format it as if it were a Latn script". "However, a Latin-only font will suffice to render it." -- "But I am the real Strider, fortunately," John Cowan he said, looking down at them with his face cowan@ccil.org softened by a sudden smile. "I am Aragorn son http://www.ccil.org/~cowan of Arathorn, and if by life or death I can save you, I will." --LotR Book I Chapter 10 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 19:50: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 1HcVXM-0000Im-It; Fri, 13 Apr 2007 19:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVXK-0000Ie-PW for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:50:38 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound3-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVXG-0002gt-LA for ltru@lists.ietf.org; Fri, 13 Apr 2007 19:50:38 -0400 Received: from outbound3-cpk.bigfish.com (localhost [127.0.0.1]) by outbound3-cpk-R.bigfish.com (Postfix) with ESMTP id 25909991A22; Fri, 13 Apr 2007 23:50:34 +0000 (UTC) Received: from mail64-cpk-R.bigfish.com (unknown [10.2.40.3]) by outbound3-cpk.bigfish.com (Postfix) with ESMTP id 23FAC80004D; Fri, 13 Apr 2007 23:50:34 +0000 (UTC) Received: from mail64-cpk (localhost [127.0.0.1]) by mail64-cpk-R.bigfish.com (Postfix) with ESMTP id 16D1577030D; Fri, 13 Apr 2007 23:50:34 +0000 (UTC) X-BigFish: VP Received: by mail64-cpk (MessageSwitch) id 11765082332809_28048; Fri, 13 Apr 2007 23:50: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 mail64-cpk.bigfish.com (Postfix) with ESMTP id E235D1B0055; Fri, 13 Apr 2007 23:50:32 +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 2007041316503016-58070 ; Fri, 13 Apr 2007 16:50:30 -0700 In-Reply-To: <6.1.1.1.2.20070413161725.0216bf90@namailhost.corp.adobe.com> To: Stephen Deach Subject: Re: [Ltru] Re: For review: Tagging text with no language 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, 13 Apr 2007 16:48:42 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/13/2007 16:48:41, Serialize complete at 04/13/2007 16:48:41, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 04:50:30 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/13/2007 04:50:32 PM, Serialize complete at 04/13/2007 04:50:32 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862698553==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1862698553== Content-Type: multipart/alternative; boundary="=_alternative 0082F75A882572BC_=" This is a multipart message in MIME format. --=_alternative 0082F75A882572BC_= Content-Type: text/plain; charset="US-ASCII" Hmm. How can you tell the "junk text" below isn't encrypted or encoded in some way? I think it's "und-Latn." Karen www-international-request@w3.org wrote on 04/13/2007 04:23:12 PM: > > At 2007.04.13-19:10(-0400), John Cowan wrote: > > >Karen_Broome@spe.sony.com scripsit: > > > > > I did not request a SHOULD NOT with "no linguistic content." My request > > > was that script tags SHOULD NOT be used with linguistic *audio* content > > > because spoken language, by definition, is not written down. I really > > > don't have much use for the zxx tag. I saw a use case that related to > > > und-Latn that made sense, but zxx-Latn makes no sense to me. Did I miss > > > that thread or is that a typo? > > > >No, it makes sense: > > > >kj;lqwe4ropiuasfgpoiu243poiuq3p4okjasl;jk. > > Is your intent to say: > "zxx: This string has no linguistic meaning, no-'language' (do not apply > grammar, spelling, hyphenation, word recognition, or other language-based > services)" > - > "Latn: format it as if it were a Latn script". > > > >-- > >John Cowan http://ccil.org/~cowan cowan@ccil.org > >In might the Feanorians / that swore the unforgotten oath > >brought war into Arvernien / with burning and with broken troth. > >and Elwing from her fastness dim / then cast her in the waters wide, > >but like a mew was swiftly borne, / uplifted o'er the roaring tide. > > --the Earendillinwe > > > ---Steve Deach > sdeach@adobe.com > > > --=_alternative 0082F75A882572BC_= Content-Type: text/html; charset="US-ASCII"
Hmm. How can you tell the "junk text" below isn't encrypted or encoded in some way? I think it's "und-Latn."  

Karen

www-international-request@w3.org wrote on 04/13/2007 04:23:12 PM:

>
> At 2007.04.13-19:10(-0400), John Cowan wrote:
>
> >Karen_Broome@spe.sony.com scripsit:
> >
> > > I did not request a SHOULD NOT with "no linguistic content." My request
> > > was that script tags SHOULD NOT be used with linguistic *audio* content
> > > because spoken language, by definition, is not written down. I really
> > > don't have much use for the zxx tag.  I saw a use case that related to
> > > und-Latn that made sense, but zxx-Latn makes no sense to me. Did I miss
> > > that thread or is that a typo?
> >
> >No, it makes sense:
> >
> ><span xml:lang="zxx-Latn">kj;lqwe4ropiuasfgpoiu243poiuq3p4okjasl;jk</span>.
>
> Is your intent to say:
>    "zxx: This string has no linguistic meaning, no-'language' (do not apply
> grammar, spelling, hyphenation, word recognition, or other language-based
> services)"
>    -
>    "Latn: format it as if it were a Latn script".
>
>
> >--
> >John Cowan   http://ccil.org/~cowan    cowan@ccil.org
> >In might the Feanorians / that swore the unforgotten oath
> >brought war into Arvernien / with burning and with broken troth.
> >and Elwing from her fastness dim / then cast her in the waters wide,
> >but like a mew was swiftly borne, / uplifted o'er the roaring tide.
> >         --the Earendillinwe
>
>
> ---Steve Deach
>     sdeach@adobe.com
>
>
>
--=_alternative 0082F75A882572BC_=-- --===============1862698553== 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 --===============1862698553==-- From ltru-bounces@ietf.org Fri Apr 13 20:20: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 1HcW01-0001FM-EU; Fri, 13 Apr 2007 20:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcW00-0001FB-4j for ltru@ietf.org; Fri, 13 Apr 2007 20:20:16 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVzy-0003GB-K8 for ltru@ietf.org; Fri, 13 Apr 2007 20:20:16 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1090147wxd for ; Fri, 13 Apr 2007 17:20: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=lzYm91yd2hi0fLABPzDS9KqLHb9hC/kWspgPHCaXdAzK8QcmewJzf4vGcyAN5mrVX6oye+cq2jwuwM1o1+959wI2e3XNtny5ktoSZ3EBui7sW+wQm/aQtu1fnPIXQNZPmdjI8i/mflNsYyChv34VJifJQFgh3u0mnT7CtSipcYw= 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=Wx5nOEj2WYy/nzhgWtAvlmDsy4b2FlancYmmBFJ5gyovsC5y3CbXhXygrnxMlT/jVSdy93f/crLZeoMX0Q9FKKW8ttE0SsiluT6jRp3265xvXGfs7xSIR7OwpxY1El/iDhEFcxECL8a7cuNfzuBW17MOmAPiORD8nKnrmteqFaE= Received: by 10.115.17.1 with SMTP id u1mr1158323wai.1176510013699; Fri, 13 Apr 2007 17:20:13 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 17:20:13 -0700 (PDT) Message-ID: <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> Date: Fri, 13 Apr 2007 17:20:13 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413150440.GA1780@nic.fr> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> X-Google-Sender-Auth: cfc001c2de1714d7 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: LTRU Working Group , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1469689044==" Errors-To: ltru-bounces@ietf.org --===============1469689044== Content-Type: multipart/alternative; boundary="----=_Part_18003_5007891.1176510013577" ------=_Part_18003_5007891.1176510013577 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline That, I think, we are all in agreement on. And that follows what we do in BCP 47, which is that we say that people *should* tag as specifically as possible. So if I know that content is "en-US", I *should* say "en-US" and not just "en". But I *can* also use "en". It might not be the best choice, but it is a legitimate usage (although not optimal) usage. However, it is a perfectly reasonable choice if I don't know whether it is "en-US" or "en-CA", or it could be both. So what about "mis"? Once again, I *should* tag more specifically, if I have the information. No argument at all there. The question is whether it is non-conformant to BCP 47 to tag "kind" as "mis". For that, we need to establish whether there is sufficient grounds in the text and data of ISO 639-2 as of the time that "mis" was taken into BCP 47 to conclusively determine that "mis" is disjoint from other language codes. I don't see a conclusive case from what you and John have said so far, unless I'm missing something. I would not at all be adverse to saying that you shouldn't use "und" or "mis" or "mul" or any collections if you have any more specific information about the content. And I think it is clear that we need much more guidance in BCP 47 as to intended usage. Mark On 4/13/07, Peter Constable wrote: > > I think ISO 639-2 is clear that the most specific category should be used. > That principle is implicit in the "(Other)" collections. I also think that > principle in combination with collections creates maintenance problems. > (Which is why I suggested that all the "(Other)" entries should just be > "languages" entries.) > > (Btw, I think I suggested some time ago it might not be a bad thing to > deprecate use of collection IDs in IETF language tags.) > > > Peter > > > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Friday, April 13, 2007 2:07 PM > To: Mark Davis > Cc: LTRU Working Group; ietf-languages@alvestrand.no > Subject: [Ltru] Re: "mis" update review request > > Mark Davis scripsit: > > > You might like this to be true, but I don't see any substantiation of > > it in the standard. If you could point me to that, I'd appreciate it. > > It seems rather self-evident to me that 'ber' is a subset of 'afa', > and so on; but no, the standard doesn't say so. It does, however, say: > > A collective language code is not intended to be used when an > individual language code or another more specific collective > language code is available. > > http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1 > > I take that to mean that "afa" is unsuitable for a Berber language, and > "ger" is unsuitable for English. A fortiori, "mis" is unsuitable for > a language for which a better code is available. > > Questionless, this contradicts the desire for stability, but I don't > see what's to be done about it. I tried at one point to get all > language collection codes deprecated, but it was pointed out that > there are good reasons for having them, as when insufficient evidence > is available. > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > I must confess that I have very little notion of what [s. 4 of the British > Trade Marks Act, 1938] is intended to convey, and particularly the > sentence > of 253 words, as I make them, which constitutes sub-section 1. I doubt if > the entire statute book could be successfully searched for a sentence of > equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940 > > _______________________________________________ > 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_18003_5007891.1176510013577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That, I think, we are all in agreement on. And that follows what we do in BCP 47, which is that we say that people *should* tag as specifically as possible. So if I know that content is "en-US", I *should* say "en-US" and not just "en". But I *can* also use "en". It might not be the best choice, but it is a legitimate usage (although not optimal) usage. However, it is a perfectly reasonable choice if I don't know whether it is "en-US" or "en-CA", or it could be both.

So what about "mis"? Once again, I *should* tag more specifically, if I have the information. No argument at all there. The question is whether it is non-conformant to BCP 47 to tag "kind" as "mis". For that, we need to establish whether there is sufficient grounds in the text and data of ISO 639-2 as of the time that "mis" was taken into BCP 47 to conclusively determine that "mis" is disjoint from other language codes. I don't see a conclusive case from what you and John have said so far, unless I'm missing something.

I would not at all be adverse to saying that you shouldn't use "und" or "mis" or "mul" or any collections if you have any more specific information about the content. And I think it is clear that we need much more guidance in BCP 47 as to intended usage.

Mark

On 4/13/07, Peter Constable <petercon@microsoft.com> wrote:
I think ISO 639-2 is clear that the most specific category should be used. That principle is implicit in the "(Other)" collections. I also think that principle in combination with collections creates maintenance problems. (Which is why I suggested that all the "(Other)" entries should just be "languages" entries.)

(Btw, I think I suggested some time ago it might not be a bad thing to deprecate use of collection IDs in IETF language tags.)


Peter


-----Original Message-----
From: John Cowan [mailto: cowan@ccil.org]
Sent: Friday, April 13, 2007 2:07 PM
To: Mark Davis
Cc: LTRU Working Group; ietf-languages@alvestrand.no
Subject: [Ltru] Re: "mis" update review request

Mark Davis scripsit:

> You might like this to be true, but I don't see any substantiation of
> it in the standard. If you could point me to that, I'd appreciate it.

It seems rather self-evident to me that 'ber' is a subset of 'afa',
and so on; but no, the standard doesn't say so.  It does, however, say:

        A collective language code is not intended to be used when an
        individual language code or another more specific collective
        language code is available.

http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1

I take that to mean that "afa" is unsuitable for a Berber language, and
"ger" is unsuitable for English.  A fortiori, "mis" is unsuitable for
a language for which a better code is available.

Questionless, this contradicts the desire for stability, but I don't
see what's to be done about it.  I tried at one point to get all
language collection codes deprecated, but it was pointed out that
there are good reasons for having them, as when insufficient evidence
is available.

--
John Cowan   cowan@ccil.org   http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940

_______________________________________________
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_18003_5007891.1176510013577-- --===============1469689044== 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 --===============1469689044==-- From ltru-bounces@ietf.org Fri Apr 13 20:33: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 1HcWCO-0006qw-6n; Fri, 13 Apr 2007 20:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWCN-0006qF-Oa for ltru@lists.ietf.org; Fri, 13 Apr 2007 20:33:03 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWCM-0000oX-6Z for ltru@lists.ietf.org; Fri, 13 Apr 2007 20:33:03 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1057693nzf for ; Fri, 13 Apr 2007 17:33:01 -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=FQfDN9jUELmJ1VOTvN37N0xsCpcpA47LVRUF6MMWwb+MDdQjMkNMuMx2DoIjSEbRyA9zDMnoZcajkJ6ixOzgPWdZtPq8KBVHy9TF9tAgVJkONs7tjfdnV3ml5lFM81ZnJAi6kWRJVPDm3Sqp2swBDYXn1Q6vFqAcZ8p0XhEz6Uc= 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=Kgkv8Ph07Iv4lFa5iUCXRfocdlNqoouXsH23BHgV8Li7ji46OFc/YgmYK0aTBUtF9mDFZjn4XFn8SuK27pyJJxN2dSKrmCHgv4Ls2uoC2URK+ZqQpqmh8bb3pnUDqJFUUKMip4FiA55iBNSpzwK9gsOvH+sJC5vqgsHd0TBhV1Q= Received: by 10.114.201.1 with SMTP id y1mr1160557waf.1176510781376; Fri, 13 Apr 2007 17:33:01 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 13 Apr 2007 17:33:01 -0700 (PDT) Message-ID: <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> Date: Fri, 13 Apr 2007 17:33:01 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Collection tags considered problematic (was: "mis" update review request) In-Reply-To: <20070413222559.GF29983@mercury.ccil.org> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> X-Google-Sender-Auth: 678404cd25454d6f X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ietf-languages@alvestrand.no, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0604444962==" Errors-To: ltru-bounces@ietf.org --===============0604444962== Content-Type: multipart/alternative; boundary="----=_Part_18196_7964910.1176510781312" ------=_Part_18196_7964910.1176510781312 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What is truly unfortunate is that ISO defined these (Other) items by exclusion. If they had defined the tag "ger" to simply meant Germanic, it would remain valid indefinitely. They would then behave like macrolanguages. In LTRU what we need to decide is whether we bail on stability, or we impose stability. We can do the latter by deciding, like we do with other unstable ISO codes, that the meaning of the tag "ger" is set at the time we add it to the registry, and can only be narrowed, not broadened. Then if ISO decides to add a new code for a Germanic language "gxx", it then simply overlaps with "ger". It is then a strong SHOULD to use "gxx" in preference to "ger" where it applies, but it doesn't invalidate previous usage. Mark > Randy Presuhn scripsit: > > > The thing that bothers me about the comment "A collection of languages > > which don't belong to any other collection" is that it isn't compatible > > with the possibility that one or more of those languages might > > eventually be included in another (possibly new) collection. If that > > langauage were left in the mis collection as well, the comment would > > be incorrect. If the language were removed from the mis collection, > > stability goes out the window. Either way, changing the comment > > wouldn't help the situation. > > That's true, but it's also true of all other collection subtags. "Mis" > is a particularly bad case, but it's not hard to devise other problematic > situations; I've changed the Subject: line accordingly. > > For example, today Slobbovian (hypothetical) might be considered a Slavic > language with a heavy Germanic substrate, but tomorrow Thingummy might > be able to show conclusively that it was really a Germanic language > with a heavy Slavic superstrate. That would invalidate the old "sla" > tag for the Slobbovian Declaration of Independence in favor of a "ger" > one, but since collections are not and cannot in practice be defined by > enumeration, such things can't be avoided. > > I think we must accept that there is some risk of instability when > language collection subtags are used; that's a tradeoff against their > convenience. > > Bullet point 3 of section 4.1 of rfc-4646-04 currently says: > > Use specific language subtags or subtag sequences in preference > to subtags for language collections. A "language collection" > is a subtag derived from one of the ISO 639-2 codes that > represents multiple related languages. For example, the code 'cmc' > represents "Chamic languages". The registry contains values for > each of the approximately ten individual languages represented > by this collective code. For example 'jra' (Jarai) and 'cja' > (Western Cham). > > I suggest adding the following additional text: > > Using a collective language code may often be convenient or > necessary when detailed information is not available. However, > collections are defined not by enumerating specific languages, > but by genetic or other criteria, and so a specific language may > be moved out of a given collection if further information about > the language becomes available. Thus collective language codes > are inherently more unstable. > > For guidance in interpreting these suggestions, I think we now > need to include the 639-3 scope information in language subtags: > "individual language", "macrolanguage", "collective" or "private use". > > > -- > John Cowan > http://www.ccil.org/~cowan > .e'osai ko sarji la lojban. > Please support Lojban! http://www.lojban.org > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_18196_7964910.1176510781312 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What is truly unfortunate is that ISO defined these (Other) items by exclusion. If they had defined the tag "ger" to simply meant Germanic, it would remain valid indefinitely. They would then behave like macrolanguages.

In LTRU what we need to decide is whether we bail on stability, or we impose stability. We can do the latter by deciding, like we do with other unstable ISO codes, that the meaning of the tag "ger" is set at the time we add it to the registry, and can only be narrowed, not broadened. Then if ISO decides to add a new code for a Germanic language "gxx", it then simply overlaps with "ger". It is then a strong SHOULD to use "gxx" in preference to "ger" where it applies, but it doesn't invalidate previous usage.

Mark
Randy Presuhn scripsit:

> The thing that bothers me about the comment "A collection of languages
> which don't belong to any other collection" is that it isn't compatible
> with the possibility that one or more of those languages might
> eventually be included in another (possibly new) collection.  If that
> langauage were left in the mis collection as well, the comment would
> be incorrect.  If the language were removed from the mis collection,
> stability goes out the window.  Either way, changing the comment
> wouldn't help the situation.

That's true, but it's also true of all other collection subtags.  "Mis"
is a particularly bad case, but it's not hard to devise other problematic
situations; I've changed the Subject: line accordingly.

For example, today Slobbovian (hypothetical) might be considered a Slavic
language with a heavy Germanic substrate, but tomorrow Thingummy might
be able to show conclusively that it was really a Germanic language
with a heavy Slavic superstrate.  That would invalidate the old "sla"
tag for the Slobbovian Declaration of Independence in favor of a "ger"
one, but since collections are not and cannot in practice be defined by
enumeration, such things can't be avoided.

I think we must accept that there is some risk of instability when
language collection subtags are used; that's a tradeoff against their
convenience.

Bullet point 3 of section 4.1 of rfc-4646-04 currently says:

        Use specific language subtags or subtag sequences in preference
        to subtags for language collections. A "language collection"
        is a subtag derived from one of the ISO 639-2 codes that
        represents multiple related languages. For example, the code 'cmc'
        represents "Chamic languages". The registry contains values for
        each of the approximately ten individual languages represented
        by this collective code. For example 'jra' (Jarai) and 'cja'
        (Western Cham).

I suggest adding the following additional text:

        Using a collective language code may often be convenient or
        necessary when detailed information is not available.  However,
        collections are defined not by enumerating specific languages,
        but by genetic or other criteria, and so a specific language may
        be moved out of a given collection if further information about
        the language becomes available.  Thus collective language codes
        are inherently more unstable.

For guidance in interpreting these suggestions, I think we now
need to include the 639-3 scope information in language subtags:
"individual language", "macrolanguage", "collective" or "private use".


--
John Cowan                              <cowan@ccil.org>
            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org

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



--
Mark ------=_Part_18196_7964910.1176510781312-- --===============0604444962== 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 --===============0604444962==-- From ltru-bounces@ietf.org Fri Apr 13 21:05: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 1HcWhL-0000UV-PM; Fri, 13 Apr 2007 21:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWhK-0000UP-MI for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:05:02 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWhJ-0007hy-CZ for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:05:02 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcWf4-0001WX-SK for ltru@lists.ietf.org; Sat, 14 Apr 2007 03:02:42 +0200 Received: from d254059.dialin.hansenet.de ([80.171.254.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 03:02:42 +0200 Received: from nobody by d254059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 03:02:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Apr 2007 02:58:30 +0200 Organization: Lines: 23 Message-ID: <46202736.718A@xyzzy.claranet.de> References: <461FF730.2534@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > I did not request a SHOULD NOT with "no linguistic content." My > request was that script tags SHOULD NOT be used with linguistic > *audio* content Sorry, I confused it. No problem with a SHOULD NOT for scripts in audio content. > I really don't have much use for the zxx tag. Maybe for (printed) utterances like #?%zok##$%~boom!3<\# or ASCII art. IMO an example of zxx-Latn, whatever that means. > zxx-Latn makes no sense to me. Did I miss that thread Mark's table with interesting examples contained a zxx row: 43kl;ufa)iop(&uweiorqhjkl2341lkj#@!$Jkdfj;afe It could be a code, I guessed that it's zxx-Latn Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 21:11: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 1HcWnf-00052V-FO; Fri, 13 Apr 2007 21:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWnc-000527-13 for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:11:33 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWna-0001lV-PT for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:11:32 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcWnV-0003h1-6Z; Fri, 13 Apr 2007 21:11:25 -0400 Date: Fri, 13 Apr 2007 21:11:25 -0400 To: Mark Davis Subject: Re: [Ltru] Collection tags considered problematic (was: "mis" update review request) Message-ID: <20070414011125.GA4817@mercury.ccil.org> References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf-languages@alvestrand.no, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > What is truly unfortunate is that ISO defined these (Other) items > by exclusion. If they had defined the tag "ger" to simply meant > Germanic, it would remain valid indefinitely. They would then behave > like macrolanguages. Well, unless a language were to be reclassified. Very unlikely for Germanic, but not so unlikely for some of the others. In any case, the "(Other)" is, IIRC, in the process of being removed. > In LTRU what we need to decide is whether we bail on stability, or > we impose stability. We can do the latter by deciding, like we do > with other unstable ISO codes, that the meaning of the tag "ger" is > set at the time we add it to the registry, and can only be narrowed, > not broadened. The trouble is that we don't really know the extensional definition of these collective language tags: they are defined purely intensionally. So they change when the literature says they change. > Then if ISO decides to add a new code for a Germanic language "gxx", > it then simply overlaps with "ger". It is then a strong SHOULD to use > "gxx" in preference to "ger" where it applies, but it doesn't invalidate > previous usage. Again, what happens if a language is found *not* to belong to some collection in which it had been included until now? How do we even know about such an event? -- John Cowan cowan@ccil.org I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 21: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 1HcWxu-0003K1-JK; Fri, 13 Apr 2007 21:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWxt-0003Jw-1Q for ltru@ietf.org; Fri, 13 Apr 2007 21:22:09 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWxr-000759-6L for ltru@ietf.org; Fri, 13 Apr 2007 21:22:09 -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.685.24; Fri, 13 Apr 2007 18:22:06 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 13 Apr 2007 18:22:05 -0700 From: Peter Constable To: LTRU Working Group , "ietf-languages@alvestrand.no" Date: Fri, 13 Apr 2007 18:22:03 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd+Kq5ZJoNa/j9VTmuGzOmZ/sCRGAABv2cA Message-ID: References: <20070413150440.GA1780@nic.fr> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> In-Reply-To: <30b660a20704131720s41dac33el65004e35c8234be6@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.1 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0459456789==" Errors-To: ltru-bounces@ietf.org --===============0459456789== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C66NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C66NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Is "kind" meant to be a word in English, a word in some other language, or= a reference to something else? I assume the first.) I don't think we can say it is *non-conformant* to tag "hello" as mis any m= ore than we can say it is non-conformant to tag "hello" as fr. It's just ba= d tagging. That's comparable to a spelling checker correcting "helo" as "ho= lp" - it may not be useful, that that doesn't make it non-conformant to Uni= code. Non-conformance to BCP 47 would be to see fr and apply an English spe= lling checker. But that's a different question from how (or if) people should use mis. IMO= we should say that implementers of BCP 47 SHOULD NOT use mis except if the= y have an immediate need to apply a language subtag and have determined tha= t there is no available language subtag encompassing the language of the gi= ven content. E.g. I know it's Martian and there's no ISO 639 ID for Martian= . (Hypothetical example assumes Martians exist and that this is not encompa= ssed within art.) Of course, in many cases people/processes may not know en= ough about every language to be able to rule out all the available possibil= ities, but in that case the appropriate thing to use would be und. Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Friday, April 13, 2007 5:20 PM To: Peter Constable Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: Re: [Ltru] Re: "mis" update review request That, I think, we are all in agreement on. And that follows what we do in B= CP 47, which is that we say that people *should* tag as specifically as pos= sible. So if I know that content is "en-US", I *should* say "en-US" and not= just "en". But I *can* also use "en". It might not be the best choice, but= it is a legitimate usage (although not optimal) usage. However, it is a pe= rfectly reasonable choice if I don't know whether it is "en-US" or "en-CA",= or it could be both. So what about "mis"? Once again, I *should* tag more specifically, if I hav= e the information. No argument at all there. The question is whether it is = non-conformant to BCP 47 to tag "kind" as "mis". For that, we need to estab= lish whether there is sufficient grounds in the text and data of ISO 639-2 = as of the time that "mis" was taken into BCP 47 to conclusively determine t= hat "mis" is disjoint from other language codes. I don't see a conclusive c= ase from what you and John have said so far, unless I'm missing something. I would not at all be adverse to saying that you shouldn't use "und" or "mi= s" or "mul" or any collections if you have any more specific information ab= out the content. And I think it is clear that we need much more guidance in= BCP 47 as to intended usage. Mark On 4/13/07, Peter Constable > wrote: I think ISO 639-2 is clear that the most specific category should be used. = That principle is implicit in the "(Other)" collections. I also think that = principle in combination with collections creates maintenance problems. (Wh= ich is why I suggested that all the "(Other)" entries should just be "langu= ages" entries.) (Btw, I think I suggested some time ago it might not be a bad thing to depr= ecate use of collection IDs in IETF language tags.) Peter -----Original Message----- From: John Cowan [mailto: cowan@ccil.org] Sent: Friday, April 13, 2007 2:07 PM To: Mark Davis Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request Mark Davis scripsit: > You might like this to be true, but I don't see any substantiation of > it in the standard. If you could point me to that, I'd appreciate it. It seems rather self-evident to me that 'ber' is a subset of 'afa', and so on; but no, the standard doesn't say so. It does, however, say: A collective language code is not intended to be used when an individual language code or another more specific collective language code is available. http://www.loc.gov/standards/iso639-2/normtext.html section 4.1.1 I take that to mean that "afa" is unsuitable for a Berber language, and "ger" is unsuitable for English. A fortiori, "mis" is unsuitable for a language for which a better code is available. Questionless, this contradicts the desire for stability, but I don't see what's to be done about it. I tried at one point to get all language collection codes deprecated, but it was pointed out that there are good reasons for having them, as when insufficient evidence is available. -- John Cowan cowan@ccil.org http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940 _______________________________________________ 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 --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C66NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Is “kind” meant to be a word in English, a word= in some other language, or a reference to something else? I assume the first.)=

 

I don’t think we can say it is *non-conformant*= to tag “hello” as mis any more than we can say it is non-conforman= t to tag “hello” as fr. It’s just bad tagging. That’s comparable to a spelling checker correcting “helo” as “ho= lp” – it may not be useful, that that doesn’t make it non-conforman= t to Unicode. Non-conformance to BCP 47 would be to see fr and apply an English = spelling checker.

 

But that’s a different question from how (or if) peopl= e should use mis. IMO we should say that implementers of BCP 47 SHOULD NOT us= e mis except if they have an immediate need to apply a language subtag and ha= ve determined that there is no available language subtag encompassing the language of the given content. E.g. I know it’s Martian and there’s no ISO 639 = ID for Martian. (Hypothetical example assumes Martians exist and that this is = not encompassed within art.) Of course, in many cases people/processes may not = know enough about every language to be able to rule out all the available possibilities, but in that case the appropriate thing to use would be und.<= o:p>

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Friday, April 13, 2007 5:20 PM
To: Peter Constable
Cc: LTRU Working Group; ietf-languages@alvestrand.no
Subject: Re: [Ltru] Re: "mis" update review request

 

That, I think, we are a= ll in agreement on. And that follows what we do in BCP 47, which is that we say t= hat people *should* tag as specifically as possible. So if I know that content = is "en-US", I *should* say "en-US" and not just "en". But I *can* also use "en". It might not be the be= st choice, but it is a legitimate usage (although not optimal) usage. However,= it is a perfectly reasonable choice if I don't know whether it is "en-US&= quot; or "en-CA", or it could be both.

So what about "mis"? Once again, I *should* tag more specifically= , if I have the information. No argument at all there. The question is whether i= t is non-conformant to BCP 47 to tag "kind" as "mis". For th= at, we need to establish whether there is sufficient grounds in the text and da= ta of ISO 639-2 as of the time that "mis" was taken into BCP 47 to conclusively determine that "mis" is disjoint from other language codes. I don't see a conclusive case from what you and John have said so fa= r, unless I'm missing something.

I would not at all be adverse to saying that you shouldn't use "und&qu= ot; or "mis" or "mul" or any collections if you have any mo= re specific information about the content. And I think it is clear that we nee= d much more guidance in BCP 47 as to intended usage.

Mark

On 4/13/07, Peter Constabl= e <petercon@microsoft.com>= ; wrote:

I think ISO 639-2 is clear that the most specific cate= gory should be used. That principle is implicit in the "(Other)" collections. I also think that principle in combination with collections creates maintenance problems. (Which is why I suggested that all the "(Other)" entries should just be "languages" entries.) =

(Btw, I think I suggested some time ago it might not be a bad thing to deprecate use of collection IDs in IETF language tags.)


Peter


-----Original Message-----
From: John Cowan [mailto: cowan@ccil.org<= /a>]
Sent: Friday, April 13, 2007 2:07 PM
To: Mark Davis
Cc: LTRU Working Group; iet= f-languages@alvestrand.no
Subject: [Ltru] Re: "mis" update review request

Mark Davis scripsit:

> You might like this to be true, but I don't see any substantiation of<= br> > it in the standard. If you could point me to that, I'd appreciate it.<= br>
It seems rather self-evident to me that 'ber' is a subset of 'afa',
and so on; but no, the standard doesn't say so.  It does, however= , say:

        A collective language code = is not intended to be used when an
        individual language code or another more specific collective
        language code is available.=

http://www.= loc.gov/standards/iso639-2/normtext.html section 4.1.1

I take that to mean that "afa" is unsuitable for a Berber languag= e, and
"ger" is unsuitable for English.  A fortiori, "mis" is unsuitable for
a language for which a better code is available.

Questionless, this contradicts the desire for stability, but I don't
see what's to be done about it.  I tried at one point to get all<= br> language collection codes deprecated, but it was pointed out that
there are good reasons for having them, as when insufficient evidence
is available.

--
John Cowan   cowan@ccil.org=    http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British<= br> Trade Marks Act, 1938] is intended to convey, and particularly the sentence=
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ltru

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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C66NAEXMSGC117re_-- --===============0459456789== 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 --===============0459456789==-- From ltru-bounces@ietf.org Fri Apr 13 21:25: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 1HcX1F-0004uS-R2; Fri, 13 Apr 2007 21:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcX1D-0004tz-PH for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:25:35 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcX1C-0000WY-CG for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:25:35 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 18:25:33 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Fri, 13 Apr 2007 18:25:32 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 13 Apr 2007 18:25:30 -0700 Subject: RE: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Topic: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Index: Acd+LIh2pIytqvo4Rja/G6RnQBGiCgABu1cg Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> In-Reply-To: <30b660a20704131733g71d2b643pa30d4284492c4616@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: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317748734==" Errors-To: ltru-bounces@ietf.org --===============1317748734== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C6ANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C6ANAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@a= lvestrand.no] On Behalf Of Mark Davis > What is truly unfortunate is that ISO defined these (Other) items by excl= usion. I am pushing for these to be generalized with the exclusions removed - all = cases of "Foo (Other)" changed to "Foo languages". > We can do the latter by deciding, like we do with other unstable ISO code= s, > that the meaning of the tag "ger" is set at the time we add it to the reg= istry, > and can only be narrowed, not broadened. I think you mean, "...can only be broadened, not narrowed. Peter --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C6ANAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Mark Davi= s

> What is trul= y unfortunate is that ISO defined these (Other) items by exclusion.

 

I am pushing for these to be generalized with the exclusions removed – all cases of “Foo (Other)” changed to “Fo= o languages”.

 

 =

> We can do th= e latter by deciding, like we do with other unstable ISO codes,

> that the meaning of the tag "ger" is s= et at the time we add it to the registry, <= /o:p>

> and can only be narrowed, not broadened.

 

I think you mean, “…can only be broadened, not n= arrowed.

 

 =

Peter<= /p>

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955D038B8C6ANAEXMSGC117re_-- --===============1317748734== 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 --===============1317748734==-- From ltru-bounces@ietf.org Fri Apr 13 21:29: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 1HcX5P-0007jI-I1; Fri, 13 Apr 2007 21:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcX5O-0007jD-Pe for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:29:54 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcX5N-00012Y-HN for ltru@lists.ietf.org; Fri, 13 Apr 2007 21:29:54 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 18:29:52 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Fri, 13 Apr 2007 18:29:52 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 13 Apr 2007 18:29:51 -0700 Subject: RE: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Topic: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Index: Acd+Mdlv0Ya/LIF1TZuKI1UPlzI2qwAAgb4w Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> <20070414011125.GA4817@mercury.ccil.org> In-Reply-To: <20070414011125.GA4817@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org] > The trouble is that we don't really know the extensional > definition of these collective language tags: they are > defined purely intensionally. At one point early in our involvement with ISO 639, Gary Simons and I sugge= sted that the collections be given extensional definitions, as has been don= e with macrolanguages (in the macrolanguage mapping table). But as our inte= rest was in coverage for individual languages and no in the collections, we= didn't take any interest in pursuing either evaluating the merits or getti= ng that implemented. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 21:38: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 1HcXDe-0001WE-Ly; Fri, 13 Apr 2007 21:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXDd-0001W9-In for ltru@ietf.org; Fri, 13 Apr 2007 21:38:25 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXDc-00034D-A5 for ltru@ietf.org; Fri, 13 Apr 2007 21:38:25 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcXDb-0005CE-Bh; Fri, 13 Apr 2007 21:38:23 -0400 Date: Fri, 13 Apr 2007 21:38:23 -0400 To: Peter Constable Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070414013823.GC4817@mercury.ccil.org> References: <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ietf-languages@iana.org, 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 Peter Constable scripsit: > (Is "kind" meant to be a word in English, a word in some other language, > or a reference to something else? I assume the first.) I think Mark's point was that "kind" is ambiguously English or Dutch (or German, if you discount the lower-case "k"). The normative text of ISO 639-2 says (section 4.1.2): The language code mul (for multiple languages) should be applied when several languages are used and it is not practical to specify all the appropriate language codes. I think that is meant to cover mixed-language documents, not documents whose language is ambiguous, but I don't want to start yet another hooraw. > But that's a different question from how (or if) people should use > mis. IMO we should say that implementers of BCP 47 SHOULD NOT use mis > except if they have an immediate need to apply a language subtag and > have determined that there is no available language subtag encompassing > the language of the given content. E.g. I know it's Martian and there's > no ISO 639 ID for Martian. (Hypothetical example assumes Martians > exist and that this is not encompassed within art.) Or, until 639-3 codes are available in BCP 47, any language that doesn't have its own 639-2 code or plausible covering collection. -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 22:07: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 1HcXfJ-0002Yq-Gc; Fri, 13 Apr 2007 22:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXfI-0002Yl-Ci for ltru@lists.ietf.org; Fri, 13 Apr 2007 22:07:00 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXfH-00073G-4r for ltru@lists.ietf.org; Fri, 13 Apr 2007 22:07:00 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcXfE-0007M5-Vy; Fri, 13 Apr 2007 22:06:57 -0400 Date: Fri, 13 Apr 2007 22:06:56 -0400 To: Peter Constable Subject: Re: [Ltru] Collection tags considered problematic (was: "mis" update review request) Message-ID: <20070414020656.GD4817@mercury.ccil.org> References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> <20070414011125.GA4817@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > At one point early in our involvement with ISO 639, Gary Simons and > I suggested that the collections be given extensional definitions, > as has been done with macrolanguages (in the macrolanguage mapping > table). But as our interest was in coverage for individual languages > and no in the collections, we didn't take any interest in pursuing > either evaluating the merits or getting that implemented. Your obsolete-but-still-interesting cut at that is still online at www.ethnologue.com/14/iso639 . Reminder: in addition to replacing "(Other)" with "languages", 'bih' and 'him' should be updated to add "languages". -- Cash registers don't really add and subtract; John Cowan they only grind their gears. cowan@ccil.org But then they don't really grind their gears, either; they only obey the laws of physics. --Unknown _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 22:12: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 1HcXkg-0005zA-Ct; Fri, 13 Apr 2007 22:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXkf-0005z5-HZ for ltru@ietf.org; Fri, 13 Apr 2007 22:12:33 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXke-0008SM-94 for ltru@ietf.org; Fri, 13 Apr 2007 22:12:33 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcXkc-0007bK-84; Fri, 13 Apr 2007 22:12:30 -0400 Date: Fri, 13 Apr 2007 22:12:30 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070414021230.GE4817@mercury.ccil.org> References: <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > So what about "mis"? Once again, I *should* tag more specifically, > if I have the information. No argument at all there. The question is > whether it is non-conformant to BCP 47 to tag "kind" as "mis". For that, > we need to establish whether there is sufficient grounds in the text > and data of ISO 639-2 as of the time that "mis" was taken into BCP 47 to > conclusively determine that "mis" is disjoint from other language codes. In order to determine the semantics of 639-2, we must look to the MARC list and the practice of the Library of Congress (just as to determine the semantics of 639-3, we must look to the Ethnologue). Peter gave us the list of languages and language groups which MARC tags using 'mis': see http://www.loc.gov/marc/languages/lang_l2n.html . There may not be 100% agreement between this list and 639-2, but it's the best we have right now, especially when supplemented with http://www.ethnologue.com/14/show_iso639.asp?code=mis . -- In my last lifetime, John Cowan I believed in reincarnation; http://www.ccil.org/~cowan in this lifetime, cowan@ccil.org I don't. --Thiagi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 13 22:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcYBo-0003hf-9H; Fri, 13 Apr 2007 22:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcYBn-0003ha-7J for ltru@ietf.org; Fri, 13 Apr 2007 22:40:35 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcYBl-0005US-Sw for ltru@ietf.org; Fri, 13 Apr 2007 22:40:35 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 13 Apr 2007 19:40:33 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Fri, 13 Apr 2007 19:40:33 -0700 From: Peter Constable To: "ltru@ietf.org" , "ietf-languages@iana.org" Date: Fri, 13 Apr 2007 19:40:31 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd+NZje7TD0yYl7S/eI5xOMrz39kgABie/w Message-ID: References: <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <20070413201541.GR7353@mercury.ccil.org> <30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com> <30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com> <20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> <20070414013823.GC4817@mercury.ccil.org> In-Reply-To: <20070414013823.GC4817@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org] > I think Mark's point was that "kind" is ambiguously English or Dutch... In a case like "kind" where there's ambiguity and you don't know the specif= ic language, the appropriate tag would be und. > The normative text of ISO 639-2 says (section 4.1.2): The language code mul (for multiple languages) should be applied when several languages are used and it is not practical to specify all the appropriate language codes. > I think that is meant to cover mixed-language documents, not documents > whose language is ambiguous Correct. >> But that's a different question from how (or if) people should use >> mis. IMO we should say that implementers of BCP 47 SHOULD NOT use mis >> except if they have an immediate need to apply a language subtag and >> have determined that there is no available language subtag encompassing >> the language of the given content. E.g. I know it's Martian and there's >> no ISO 639 ID for Martian. (Hypothetical example assumes Martians >> exist and that this is not encompassed within art.) > > Or, until 639-3 codes are available in BCP 47, any language that doesn't > have its own 639-2 code or plausible covering collection. Sure; the determination can be made based on what's available at the time t= he determination is being made. That presents a stability issue, but I don'= t see how that can be avoided if you want to use mis. The other option is t= o simply use und on the assumption that the conclusion being made is "I don= 't know how I can possibly tag it using the available tags". That's stable,= though it is making a different statement. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 00:43: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 1Hca77-0004jT-Gl; Sat, 14 Apr 2007 00:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hca75-0004jK-Vl for ltru@lists.ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hca75-0002iE-Ne for ltru@lists.ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=me5wnparVevQXha+59WKp18f8gkpVMBnxUq/PVQh6+2yMa9DGQjuAaCfpth/VL+C; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.219] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hca73-000372-3v; Sat, 14 Apr 2007 00:43:49 -0400 Message-ID: <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20070413122917.GA25431@nic.fr> <461F9828.46DB@xyzzy.claranet.de><20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> Subject: Re: [Ltru] Re: "mis" update review request Date: Fri, 13 Apr 2007 21:21: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd73b2a593796e8cfa621a4bdc5408c0b7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.219 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: ; > Sent: Friday, April 13, 2007 1:04 PM > Subject: Re: [Ltru] Re: "mis" update review request ... > Another scenario is where you have incoming content, and you need to tag it > for use by other components. This might be done, for example, in a search > engine, where you fetch and process a page, and use that information later > in doing searches. The tag serves to communicate language between the > different components. > > In that case, you have far from perfect information about the content: what > you have being typically the result of some level statistical analysis, plus > other factors about the document. You need to tag with as much information > as you have, *but no more*. It is in that case where you need to have the > tags that indicate some level of imperfect knowledge about the source, such > as "I have no idea what this is", or "It looks like linguistic content, but > I don't know which language", or "it doesn't look like linguistic content". > (You may also have more detailed knowledge, like that some document appears > to have 70% English content (probability 95%) and 20% French content > (probability 65%)). ... I agree that groupings are useful, and have argued for them in the past. I'm not going to argue that we should exclude "mis", but I doubt that it would be terribly useful. I find it very hard to believe that a reasonable analysis (whether done by human or machine) would classify a text a being "mis" without being able to recognize which of the languages in that grouping the text belonged to. I can believe someone could look at text and say "it's a slavic language, but I'm not sure which one." Do we really think someone or something would look at some text and say "it's Ainu, Andamanese, or Etruscan, but I can't tell which, so I'll tag it 'mis'"? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 00:43: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 1Hca77-0004jP-DD; Sat, 14 Apr 2007 00:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hca75-0004jF-K2 for ltru@ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hca74-0002ga-9i for ltru@ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JjAZF3GkFywcllhp109FW6zprZ2WXlfNqkghiC2eKXIip/uhssvBG/E2p72FLwOz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.219] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hca73-000372-NN for ltru@ietf.org; Sat, 14 Apr 2007 00:43:50 -0400 Message-ID: <017c01c77e4f$be2720e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20070413150440.GA1780@nic.fr> <461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><20070413201541.GR7353@mercury.ccil.org><30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com><30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com><20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> Date: Fri, 13 Apr 2007 21:45:33 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd748ffa3c80f48f34e7351c66b8ad79344350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.219 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] As specifically as possible? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Peter Constable" > Cc: "LTRU Working Group" ; > Sent: Friday, April 13, 2007 5:20 PM > Subject: Re: [Ltru] Re: "mis" update review request > > That, I think, we are all in agreement on. And that follows what we do in > BCP 47, which is that we say that people *should* tag as specifically as > possible. So if I know that content is "en-US", I *should* say "en-US" and > not just "en". But I *can* also use "en". It might not be the best choice, > but it is a legitimate usage (although not optimal) usage. However, it is a > perfectly reasonable choice if I don't know whether it is "en-US" or > "en-CA", or it could be both. What provision in BCP 47 recommends that text should be tagged "as specifically as possible"? That seems quite a stretch from the spirit of "tag wisely", and to be contrary to the section 4.1's statement that "A subtag SHOULD only be used when it adds useful distinguishing information to the tag." Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 00:43: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 1Hca77-0004jT-Gl; Sat, 14 Apr 2007 00:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hca75-0004jK-Vl for ltru@lists.ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hca75-0002iE-Ne for ltru@lists.ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=me5wnparVevQXha+59WKp18f8gkpVMBnxUq/PVQh6+2yMa9DGQjuAaCfpth/VL+C; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.219] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hca73-000372-3v; Sat, 14 Apr 2007 00:43:49 -0400 Message-ID: <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20070413122917.GA25431@nic.fr> <461F9828.46DB@xyzzy.claranet.de><20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> Subject: Re: [Ltru] Re: "mis" update review request Date: Fri, 13 Apr 2007 21:21: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd73b2a593796e8cfa621a4bdc5408c0b7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.219 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: ; > Sent: Friday, April 13, 2007 1:04 PM > Subject: Re: [Ltru] Re: "mis" update review request ... > Another scenario is where you have incoming content, and you need to tag it > for use by other components. This might be done, for example, in a search > engine, where you fetch and process a page, and use that information later > in doing searches. The tag serves to communicate language between the > different components. > > In that case, you have far from perfect information about the content: what > you have being typically the result of some level statistical analysis, plus > other factors about the document. You need to tag with as much information > as you have, *but no more*. It is in that case where you need to have the > tags that indicate some level of imperfect knowledge about the source, such > as "I have no idea what this is", or "It looks like linguistic content, but > I don't know which language", or "it doesn't look like linguistic content". > (You may also have more detailed knowledge, like that some document appears > to have 70% English content (probability 95%) and 20% French content > (probability 65%)). ... I agree that groupings are useful, and have argued for them in the past. I'm not going to argue that we should exclude "mis", but I doubt that it would be terribly useful. I find it very hard to believe that a reasonable analysis (whether done by human or machine) would classify a text a being "mis" without being able to recognize which of the languages in that grouping the text belonged to. I can believe someone could look at text and say "it's a slavic language, but I'm not sure which one." Do we really think someone or something would look at some text and say "it's Ainu, Andamanese, or Etruscan, but I can't tell which, so I'll tag it 'mis'"? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 00:43: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 1Hca77-0004jP-DD; Sat, 14 Apr 2007 00:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hca75-0004jF-K2 for ltru@ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hca74-0002ga-9i for ltru@ietf.org; Sat, 14 Apr 2007 00:43:51 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JjAZF3GkFywcllhp109FW6zprZ2WXlfNqkghiC2eKXIip/uhssvBG/E2p72FLwOz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.219] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hca73-000372-NN for ltru@ietf.org; Sat, 14 Apr 2007 00:43:50 -0400 Message-ID: <017c01c77e4f$be2720e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20070413150440.GA1780@nic.fr> <461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><20070413201541.GR7353@mercury.ccil.org><30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com><30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com><20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> Date: Fri, 13 Apr 2007 21:45:33 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd748ffa3c80f48f34e7351c66b8ad79344350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.219 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] As specifically as possible? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Peter Constable" > Cc: "LTRU Working Group" ; > Sent: Friday, April 13, 2007 5:20 PM > Subject: Re: [Ltru] Re: "mis" update review request > > That, I think, we are all in agreement on. And that follows what we do in > BCP 47, which is that we say that people *should* tag as specifically as > possible. So if I know that content is "en-US", I *should* say "en-US" and > not just "en". But I *can* also use "en". It might not be the best choice, > but it is a legitimate usage (although not optimal) usage. However, it is a > perfectly reasonable choice if I don't know whether it is "en-US" or > "en-CA", or it could be both. What provision in BCP 47 recommends that text should be tagged "as specifically as possible"? That seems quite a stretch from the spirit of "tag wisely", and to be contrary to the section 4.1's statement that "A subtag SHOULD only be used when it adds useful distinguishing information to the tag." Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 01:25: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 1Hcal7-0002OX-QP; Sat, 14 Apr 2007 01:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcal6-0002IE-Ms for ltru@ietf.org; Sat, 14 Apr 2007 01:25:12 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcagO-0004Ky-2O for ltru@ietf.org; Sat, 14 Apr 2007 01:20:21 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HcagN-0001wC-Dh; Sat, 14 Apr 2007 01:20:19 -0400 Date: Sat, 14 Apr 2007 01:20:19 -0400 To: Randy Presuhn Subject: Re: [Ltru] As specifically as possible? Message-ID: <20070414052019.GC24951@mercury.ccil.org> References: <20070413150440.GA1780@nic.fr> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> <017c01c77e4f$be2720e0$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017c01c77e4f$be2720e0$6601a8c0@oemcomputer> 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 Randy Presuhn scripsit: > What provision in BCP 47 recommends that text should be tagged > "as specifically as possible"? That seems quite a stretch from > the spirit of "tag wisely", and to be contrary to the section 4.1's > statement that "A subtag SHOULD only be used when it adds useful > distinguishing information to the tag." We are talking about language subtags specifically, not other kinds; see section 4.1, bullet point 3, of the current 4646bis draft, which prefers language subtags to language-collection subtags, and more specific collections to less specific ones. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 03:14: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 1HccT2-0007OJ-Ar; Sat, 14 Apr 2007 03:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HccT0-0007OC-Fo for ltru@lists.ietf.org; Sat, 14 Apr 2007 03:14:38 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HccSz-00021i-63 for ltru@lists.ietf.org; Sat, 14 Apr 2007 03:14:38 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 14 Apr 2007 00:14:36 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Sat, 14 Apr 2007 00:14:36 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Sat, 14 Apr 2007 00:13:55 -0700 Subject: RE: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Topic: [Ltru] Collection tags considered problematic (was: "mis" update review request) Thread-Index: Acd+OZW/E9In6naSSQSxwduNNmC7pAAKmtAQ Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <20070413222559.GF29983@mercury.ccil.org> <30b660a20704131733g71d2b643pa30d4284492c4616@mail.gmail.com> <20070414011125.GA4817@mercury.ccil.org> <20070414020656.GD4817@mercury.ccil.org> In-Reply-To: <20070414020656.GD4817@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have not forgotten bih and him; they are among the last handful of issues= I intend to present to the JAC for some resolution to complete the integra= tion of the Ethnologue 15 inventory with the existing inventory of ISO 639-= 2. I am simply waiting for them to wrap up decision regarding Aramaic varie= ties, and then Tibetan before I present the short list of remaining issues,= all have to do with South Asian varieties. Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Friday, April 13, 2007 7:07 PM To: Peter Constable Cc: ietf-languages@alvestrand.no; ltru@lists.ietf.org Subject: Re: [Ltru] Collection tags considered problematic (was: "mis" upda= te review request) Peter Constable scripsit: > At one point early in our involvement with ISO 639, Gary Simons and > I suggested that the collections be given extensional definitions, > as has been done with macrolanguages (in the macrolanguage mapping > table). But as our interest was in coverage for individual languages > and no in the collections, we didn't take any interest in pursuing > either evaluating the merits or getting that implemented. Your obsolete-but-still-interesting cut at that is still online at www.ethnologue.com/14/iso639 . Reminder: in addition to replacing "(Other)" with "languages", 'bih' and 'him' should be updated to add "languages". -- Cash registers don't really add and subtract; John Cowan they only grind their gears. cowan@ccil.org But then they don't really grind their gears, either; they only obey the laws of physics. --Unknown _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 03:21: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 1HccZa-0001bW-3k; Sat, 14 Apr 2007 03:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HccZZ-0001bR-NT for ltru@lists.ietf.org; Sat, 14 Apr 2007 03:21:25 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HccZY-0003ih-F1 for ltru@lists.ietf.org; Sat, 14 Apr 2007 03:21:25 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 14 Apr 2007 00:21:23 -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; Sat, 14 Apr 2007 00:21:23 -0700 From: Peter Constable To: "ietf-languages@iana.org" Date: Sat, 14 Apr 2007 00:20:44 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: Acd+T4Ogg/XesL9rTe6v9PQ/wRQmgAAFUdGA Message-ID: References: <20070413122917.GA25431@nic.fr> <461F9828.46DB@xyzzy.claranet.de><20070413150440.GA1780@nic.fr> <461FA716.7D35@xyzzy.claranet.de><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> In-Reply-To: <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> 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.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the lan= guage identity is not determined, and the appropriate tag for that is und. = Appropriate use of mis does not require that one know the language of the c= ontent; it does, however, require that one know it is *not* a language cove= red by any of the available tags. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 07:28: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 1HcgR4-0006di-UY; Sat, 14 Apr 2007 07:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcgR3-0006dX-BW for ltru@lists.ietf.org; Sat, 14 Apr 2007 07:28:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcgR2-0001S2-14 for ltru@lists.ietf.org; Sat, 14 Apr 2007 07:28:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcgQt-0006oJ-Lm for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:28:43 +0200 Received: from d252172.dialin.hansenet.de ([80.171.252.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 13:28:43 +0200 Received: from nobody by d252172.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 13:28:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Apr 2007 13:28:05 +0200 Organization: Lines: 17 Message-ID: <4620BAC5.1C0A@xyzzy.claranet.de> References: <20070413150440.GA1780@nic.fr> <461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><20070413201541.GR7353@mercury.ccil.org><30b660a20704131344r51b51ce7l2ec980001bdd6e6f@mail.gmail.com><30b660a20704131353k4b7d5373x5a54094e1a07569d@mail.gmail.com><20070413210650.GB29983@mercury.ccil.org> <30b660a20704131720s41dac33el65004e35c8234be6@mail.gmail.com> <017c01c77e4f$be2720e0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252172.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: As specifically as possible? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > What provision in BCP 47 recommends that text should be tagged > "as specifically as possible"? That seems quite a stretch from > the spirit of "tag wisely", and to be contrary to the section 4.1's > statement that "A subtag SHOULD only be used when it adds useful > distinguishing information to the tag." Yes, I was also puzzled by Mark's statement, but missed what you have quoted when I tried to check it. I found the SHOULD NOT for script subtags, confirming the general line of "tag wisely". IMO that's both: not too unspecific, but also not too specific. And above all don't lie. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 08:35: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 1HchTs-0002j6-Ge; Sat, 14 Apr 2007 08:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HchTr-0002j1-9x for ltru@ietf.org; Sat, 14 Apr 2007 08:35:51 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HchTp-0006Mk-PX for ltru@ietf.org; Sat, 14 Apr 2007 08:35:51 -0400 Received: from c83-248-99-2.bredband.comhem.se ([83.248.99.2]:3157 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HchTo-0002aA-7O; Sat, 14 Apr 2007 14:35:48 +0200 From: "Kent Karlsson" To: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> Date: Sat, 14 Apr 2007 14:38:07 +0200 Message-ID: <01eb01c77e91$c78246f0$f962f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> Thread-Index: Acd+YCLZ2iH8PUPiTDOSSsjCzKG3xwALjyDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HchTo-0002aA-7O. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HchTo-0002aA-7O 91e94c0e7370e9d265a0520c74321807 X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'LTRU Working Group' Subject: [Ltru] RE: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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'll dare a crosspost here, since most of this debate is crossposted already...) Doug Ewell wrote: > I suspect this whole debate over "mis" is more of a thought-experiment, I think so too. But while we're at it... I'm not too keen on the word "miscellaneous", which seem more appropriate to what you can find on a shelf of books (these books are in miscellaneous languages, that no-body here has cared to divide up) than for tagging a single document, or part of a document. For a single document or portion of a document, "mis" *seems* to be saying the same as "mul", which I don't think was the intention. I would rather see "mis" as saying "linguistic content" (but not specified which language), opposite to "no linguistic content", but quite close to "und" (which seems to cover both "no linguistic content" and "linguistic content" and maybe also 'mul', II understand the debate so far). I don't think that ny of the collection codes, 'mis' included, are intended to cover 'mul', though 'und' could well cover 'mul'. But I agree that while the current interpretation (as per MARC at least) would be "other lingustic content", but I agree that the "other" in that interpretation is problematic (as for many other collection codes). /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 12:19:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HckyA-00081y-Ji; Sat, 14 Apr 2007 12:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcky9-00080s-Vs for ltru@ietf.org; Sat, 14 Apr 2007 12:19:21 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcky8-00086M-N1 for ltru@ietf.org; Sat, 14 Apr 2007 12:19:21 -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.0.685.24; Sat, 14 Apr 2007 09:19:20 -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; Sat, 14 Apr 2007 09:19:20 -0700 From: Peter Constable To: "ietf-languages@iana.org" , 'LTRU Working Group' Date: Sat, 14 Apr 2007 09:18:41 -0700 Subject: RE: [Ltru] RE: "mis" update review request Thread-Topic: [Ltru] RE: "mis" update review request Thread-Index: Acd+YCLZ2iH8PUPiTDOSSsjCzKG3xwALjyDgAAgtUaA= Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> In-Reply-To: <01eb01c77e91$c78246f0$f962f853@streamserve.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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > I would rather see "mis" as saying "linguistic content" > (but not specified which language), opposite to "no > linguistic content", but quite close to "und" (which > seems to cover both "no linguistic content" and "linguistic > content" and maybe also 'mul', II understand the debate > so far). "" means 'I'm giving no information.' und means 'I have not determined what the language attribute is of this inf= ormation object.' mul means 'I have detected that this information object contains at least o= ne portion X in some language Lx and a different portion Y in some differen= t language Ly.' mis means 'I have determined that this information object is in a language = other than the set of languages covered by the available identifiers.' zxx means 'I have determined that this information object is not expressed = in terms of a human language.' None of these mean the same thing as any other or IMO is close in meaning t= o any other. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 12: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 1Hcl7U-00047a-Dc; Sat, 14 Apr 2007 12:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcl7T-00047V-Fy for ltru@lists.ietf.org; Sat, 14 Apr 2007 12:28:59 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcl7Q-0002nJ-Tx for ltru@lists.ietf.org; Sat, 14 Apr 2007 12:28:59 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 14 Apr 2007 09:28:56 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Sat, 14 Apr 2007 09:28:56 -0700 From: Peter Constable To: "www-international@w3.org" , "ltru@lists.ietf.org" Date: Sat, 14 Apr 2007 09:28:17 -0700 Subject: RE: [Ltru] Re: For review: Tagging text with no language Thread-Topic: [Ltru] Re: For review: Tagging text with no language Thread-Index: Acd+Gjw4jo0rkE0fQvCcBGdSHWfruQAloNaw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529494706==" Errors-To: ltru-bounces@ietf.org --===============1529494706== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBAED6NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBAED6NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The meaning of zxx must be interpreted in terms of the coding standard of w= hich it is a part. ISO 639 is explicitly about coding human languages. "No = linguistic content" in the case of zxx means 'no content in any human langu= age'. If a language tag must be applied to something like "ifdef DEBUG", th= en the appropriate language subtag would be zxx. ISO 639 cares not if an IE= TF tag zxx-Latn or zxx-progrmng is constructed; but consistency with ISO 63= 9 would imply that the language subtag zxx be used. Peter From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: Friday, April 13, 2007 3:20 PM To: Jukka K. Korpela Cc: www-international@w3.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: For review: Tagging text with no language I agree with you. I would also say that indicating that computer languages = have "no linguistic content" is not quite accurate for the same reasons you= cite below and disagrees with the origin of the zxx tag, which was to indi= cate a total absence of language, not content which is not in a natural lan= guage. Karen Broome www-international-request@w3.org wrote on 04/13/2007 01:08:33 PM: > > On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote: > > > With respect to computer language snippets, isn't that what the = tag > > is for -- at least in XHTML? > > has been in HTML since the beginning, and it indeed indicates > computer code, or "computer language". > > But to make things more difficult, computer code - such as program code, > operating system commands, or markup - can be regarded as being in some > human language(s) in the sense that the identifiers may have been formed > from words in human languages and the comments are written in some human > languages. Knowing the language of computer code can be relevant at least > for two purposes: > a) the understandability of the code to human readers depends on whether > they understand the human language(s) used > b) speech synthesis would benefit from the use of language information. > Moreover, a checking program could e.g. check that the code follows the > syntactic rules of the programming, command, or markup "language" _and_ > check the comments using a suitable human language spelling checker. > > Thus, I would say that the human language some text and the role of that > text as computer code are in a sense orthogonal. > > -- > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ > > > --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBAED6NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The meaning of zxx must be interpreted in terms of the codin= g standard of which it is a part. ISO 639 is explicitly about coding human languages. = “No linguistic content” in the case of zxx means ‘no content in any human language’. If a language tag must be applied to something like = “ifdef DEBUG”, then the appropriate language subtag would be zxx. ISO 639 ca= res not if an IETF tag zxx-Latn or zxx-progrmng is constructed; but consistency with ISO 639 would imply that the language subtag zxx be used.

 

 

Peter

 

From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: Friday, April 13, 2007 3:20 PM
To: Jukka K. Korpela
Cc: www-international@w3.org; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: For review: Tagging text with no language

 


I agree w= ith you. I would also say that indicating that computer languages have "no linguistic content" is not quite accurate for the same reasons you cit= e below and disagrees with the origin of the zxx tag, which was to indicate a total absence of language, not content which is not in a natural language.  

Karen Bro= ome

www-international-request@w3.org wrote= on 04/13/2007 01:08:33 PM:

>
> On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote:
>
> > With respect to computer language snippets, isn't that what t= he <code> tag
> > is for -- at least in XHTML?
>
> <code> has been in HTML since the beginning, and it indeed indicates
> computer code, or "computer language".
>
> But to make things more difficult, computer code - such as program code,
> operating system commands, or markup - can be regarded as being in some
> human language(s) in the sense that the identifiers may have been formed
> from words in human languages and the comments are written in some human
> languages. Knowing the language of computer code can be relevant a= t least
> for two purposes:
> a) the understandability of the code to human readers depends on whether
>     they understand the human language(s) used
> b) speech synthesis would benefit from the use of language information.
> Moreover, a checking program could e.g. check that the code follow= s the
> syntactic rules of the programming, command, or markup "language" _and_
> check the comments using a suitable human language spelling checke= r.
>
> Thus, I would say that the human language some text and the role o= f that
> text as computer code are in a sense orthogonal.
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
>

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBAED6NAEXMSGC117re_-- --===============1529494706== 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 --===============1529494706==-- From ltru-bounces@ietf.org Sat Apr 14 12:41: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 1HclJM-0002Bu-3K; Sat, 14 Apr 2007 12:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HclJK-0002Bn-3Y for ltru@ietf.org; Sat, 14 Apr 2007 12:41:14 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HclJI-00062n-PI for ltru@ietf.org; Sat, 14 Apr 2007 12:41:14 -0400 Received: from spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) by mail.cs.tut.fi (Postfix) with ESMTP id C83D210D4; Sat, 14 Apr 2007 19:41:11 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) (amavisd-maia, port 10024) with ESMTP id 20475-30; Sat, 14 Apr 2007 19:41:11 +0300 (EEST) Received: from hopeatilhi.cs.tut.fi (hopeatilhi.cs.tut.fi [130.230.4.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 3C59ACD8; Sat, 14 Apr 2007 19:41:11 +0300 (EEST) Date: Sat, 14 Apr 2007 19:41:10 +0300 (EEST) From: "Jukka K. Korpela" To: "ietf-languages@iana.org" Subject: RE: [Ltru] RE: "mis" update review request In-Reply-To: Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.5 (/) 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 On Sat, 14 Apr 2007, Peter Constable wrote: > "" means 'I'm giving no information.' Does that apply to its use in xml:lang="" too? That's different from omitting xml:lang. If you have an XML document with xml:lang="en" for the root element, then any subelement is assumed to be in English by default. The attribute xml:lang="" is the recommended way of breaking such inheritance. In practical terms, it seems to say 'I'm not telling the language of the content is but I'm saying it's not English'. Or should it be interpreted as saying 'I'm giving no information except that you should not assume that the language of the content is the same as declared for its parent'? -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 13:09: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 1HclkI-0007QI-31; Sat, 14 Apr 2007 13:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HclkH-0007QD-Bl for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:09:05 -0400 Received: from bay0-omc2-s12.bay0.hotmail.com ([65.54.246.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HclkG-0004Sz-Vv for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:09:05 -0400 Received: from hotmail.com ([65.54.169.38]) by bay0-omc2-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 10:09:04 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 10:09:04 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 17:09:01 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <30b660a20704131252h19b75709mea47be6cb5bccfa9@mail.gmail.com> From: "CE Whitehead" To: mark.davis@icu-project.org, nobody@xyzzy.claranet.de Bcc: Subject: Re: [Ltru] Re: For review: Tagging text with no language Date: Sat, 14 Apr 2007 13:09:01 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Apr 2007 17:09:04.0136 (UTC) FILETIME=[9A9BB880:01C77EB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: www-international@w3.org, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, my comment is below; I understand that mul is for where you know there is content from more than one language. Otherwise the code for content which you are sure is in some language where you do not know how many languages are involved is mis. Is that right?? --C. E. Whitehead cewcathar@hotmail.com Mark Davis On 4/13/07, Frank Ellermann wrote: Mark Davis wrote: > > mul = "Multiple > > > mul, if the languages" > > > protocol only maybe also > > > chat permits a others, since > > > single tag "chat" has > > > entered the > > > otherwise vocabulary of > > > many languages > > Depends on the context. If the context is something in the > > direction of your comment it's fine. But if the context is > > "I don't know if that's about a chat or a cat" I'd use "und". >'und' is possible, but I think that mul conveys more information. 'mul' only works I think if you are sure there is more than one language; otherwise 'mis' or 'und' but und thus is being used rather freely I guess-- it seems to me. That's what I gather. > >> some language >> > the process >> > Igonda flatunicai vbinkli? mis recognizes, but >> > which is not in >> > BCP 47 >> >>That would be wrong for almost all languages not yet in the >>registry belonging to another collection like "ger". > > >It's not wrong. I agree that where possible, one 'should' tag as precisely >as possible, but there is no requirement to in the RFC. Moreover, is >unclear >to me that every human language falls under either one of the explicit >codes >or into one of the collections. That may be true, I just don't know - Peter >might. > > >> something the >> > process >> > recognizes as >> > having >> > linguistic >> > podstatné jméno mis content, and >> > might be in BCP >> > 47, but it >> > doesn't know >> > which language >> > it is. >> >>If it doesn't know that it can use "und", abusing "mis" is >>no option. > > >I don't see how it is an abuse of 'mis'. If you could outline for me the >reasoning, based on the standards, behind saying that 'mis' is not correct, >I'd appreciate it. > >I think "art" is about artificial languages for >>humans or in fiction, not for programming languages. > > >That may well be, it is just not clear to me from the specification. > >Frank >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> > > > >-- >Mark _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 13:12: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 1HclnL-0000Sh-8Q; Sat, 14 Apr 2007 13:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HclnK-0000Sc-Bt for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:12:14 -0400 Received: from bay0-omc2-s10.bay0.hotmail.com ([65.54.246.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HclnH-0004sJ-Ke for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:12:14 -0400 Received: from hotmail.com ([65.54.169.30]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 10:12:11 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 10:12:11 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 17:12:06 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com From: "CE Whitehead" To: petercon@microsoft.com, www-international@w3.org, ltru@lists.ietf.org Bcc: Subject: RE: [Ltru] Re: For review: Tagging text with no language Date: Sat, 14 Apr 2007 13:12:06 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Apr 2007 17:12:11.0083 (UTC) FILETIME=[0A0991B0:01C77EB8] X-Spam-Score: 0.7 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >The meaning of zxx must be interpreted in terms of the coding standard of >which it is a part. ISO 639 is explicitly about coding human languages. "No >linguistic content" in the case of zxx means 'no content in any human >language'. If a language tag must be applied to something like "ifdef >DEBUG", then the appropriate language subtag would be zxx. ISO 639 cares >not if an IETF tag zxx-Latn or zxx-progrmng is constructed; but consistency >with ISO 639 would imply that the language subtag zxx be used. > > >Peter Hi, Peter, I would only really disagree with what you say if there were programming languages where the words used to control the code were in other languages in use, so that one language say made use of "while" and another of "lorsque" but otherwise, zxx I gather keeps the spelling checker from checking the language of the code, but as authors embed alerts, which are in one language, in code where the keywords or whatever are in quite another language, one might want a way to turn off the zxx code or to include a second code too and there is none that I know of. (Example: you might have the programming language in English and the alert in German. I guess it would be tough to pick a language identifier in that case. I do not know what the spelling checkers do with mis or mul either . . . though I know that zxx is the only subtag recommended so what the spelling checkers do is irrelevant if everyone uses zxx You have to check the content language of alerts separately I guess) --C. E. Whitehead cewcathar@hotmail.com > >From: Karen_Broome@spe.sony.com >To: Jukka K. Korpela > > >I agree with you. I would also say that indicating that computer languages >have "no linguistic content" is not quite accurate for the same reasons you >cite below and disagrees with the origin of the zxx tag, which was to >indicate a total absence of language, not content which is not in a natural >language. > >Karen Broome > >www-international-request@w3.org wrote on 04/13/2007 01:08:33 PM: > > > > > On Fri, 13 Apr 2007, Karen_Broome@spe.sony.com wrote: > > > > > With respect to computer language snippets, isn't that what the >tag > > > is for -- at least in XHTML? > > > > has been in HTML since the beginning, and it indeed indicates > > computer code, or "computer language". > > > > But to make things more difficult, computer code - such as program code, > > operating system commands, or markup - can be regarded as being in some > > human language(s) in the sense that the identifiers may have been formed > > from words in human languages and the comments are written in some human > > languages. Knowing the language of computer code can be relevant at >least > > for two purposes: > > a) the understandability of the code to human readers depends on whether > > they understand the human language(s) used > > b) speech synthesis would benefit from the use of language information. > > Moreover, a checking program could e.g. check that the code follows the > > syntactic rules of the programming, command, or markup "language" _and_ > > check the comments using a suitable human language spelling checker. > > > > Thus, I would say that the human language some text and the role of that > > text as computer code are in a sense orthogonal. > > > > -- > > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ > > > > > > _________________________________________________________________ Mortgage rates near historic lows. Refinance $200,000 loan for as low as $771/month* https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 13:36: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 1HcmAS-0003cX-79; Sat, 14 Apr 2007 13:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcmAR-0003cR-79 for ltru@ietf.org; Sat, 14 Apr 2007 13:36:07 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcmAO-00052N-Sb for ltru@ietf.org; Sat, 14 Apr 2007 13:36:07 -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.685.24; Sat, 14 Apr 2007 10:36:04 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Sat, 14 Apr 2007 10:36:03 -0700 From: Peter Constable To: "ietf-languages@iana.org" Date: Sat, 14 Apr 2007 10:35:26 -0700 Subject: RE: [Ltru] RE: "mis" update review request Thread-Topic: [Ltru] RE: "mis" update review request Thread-Index: Acd+s7oGTKFRSsU0QD6AtEVSk5L9PwABzpzA Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.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.5 (/) 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 It doesn't mean "it's not English"; it means, "I'm not telling you." Probab= ly it's a safe assumption to suppose that the content isn't English, but th= at's an inference, not an explicit statement or a deduction. Peter -----Original Message----- From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] Sent: Saturday, April 14, 2007 9:41 AM To: ietf-languages@iana.org Cc: 'LTRU Working Group' Subject: RE: [Ltru] RE: "mis" update review request On Sat, 14 Apr 2007, Peter Constable wrote: > "" means 'I'm giving no information.' Does that apply to its use in xml:lang=3D"" too? That's different from omitting xml:lang. If you have an XML document with xml:lang=3D"en" for the root element, then any subelement is assumed to be in English by default. The attribute xml:lang=3D"" is the recommended way of breaking such inheritance. In practical terms, it seems to say 'I'm not telling the language of the content is but I'm saying it's not English'. Or should it be interpreted as saying 'I'm giving no information except that you should not assume that the language of the content is the same as declared for its parent'? -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 13:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcmFG-0007Oe-Jo; Sat, 14 Apr 2007 13:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcmFG-0007OZ-5l for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:41:06 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcmFE-0005uM-Tz for ltru@lists.ietf.org; Sat, 14 Apr 2007 13:41:06 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 14 Apr 2007 10:41:04 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Sat, 14 Apr 2007 10:41:04 -0700 From: Peter Constable To: "www-international@w3.org" , "ltru@lists.ietf.org" Date: Sat, 14 Apr 2007 10:40:26 -0700 Subject: RE: [Ltru] Re: For review: Tagging text with no language Thread-Topic: [Ltru] Re: For review: Tagging text with no language Thread-Index: Acd+t51HxONCzM4vQ72hzDNz2cJI/QAA/rMQ Message-ID: References: <30b660a20704131252h19b75709mea47be6cb5bccfa9@mail.gmail.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: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: CE Whitehead [mailto:cewcathar@hotmail.com] > Otherwise the code for content which you are sure is > in some language where you do not know how many > languages are involved is mis. > > Is that right?? No! If you don't know how many languages are involved, then you have not ma= de any determinations and the correct tag is und. This would be completely = inappropriate use of mis. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 14:17: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 1HcmoR-00078o-AR; Sat, 14 Apr 2007 14:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcmoP-00078i-Ur for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:17:25 -0400 Received: from bay0-omc2-s23.bay0.hotmail.com ([65.54.246.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcmoO-0005v7-Jo for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:17:25 -0400 Received: from hotmail.com ([65.54.169.33]) by bay0-omc2-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 11:17:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 11:17:24 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 18:17:21 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: From: "CE Whitehead" To: petercon@microsoft.com, www-international@w3.org, ltru@lists.ietf.org Bcc: Subject: RE: [Ltru] Re: For review: Tagging text with no language Date: Sat, 14 Apr 2007 14:17:21 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Apr 2007 18:17:24.0297 (UTC) FILETIME=[267EA390:01C77EC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >From: CE Whitehead [mailto:cewcathar@hotmail.com] > > > Otherwise the code for content which you are sure is > > in some language where you do not know how many > > languages are involved is mis. > > > > Is that right?? > >No! If you don't know how many languages are involved, then you have not >made any determinations and the correct tag is und. This would be >completely inappropriate use of mis. > > > >Peter > > Well, mul I think is when you are sure there is more than one; is that wrong? Thanks. --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 14:24: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 1Hcmv1-0002Y6-1O; Sat, 14 Apr 2007 14:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcmuz-0002Xu-Lk for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:24:13 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcmuy-0007P1-CX for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:24:13 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 14 Apr 2007 11:24:12 -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; Sat, 14 Apr 2007 11:24:11 -0700 From: Peter Constable To: CE Whitehead , "www-international@w3.org" , "ltru@lists.ietf.org" Date: Sat, 14 Apr 2007 11:23:34 -0700 Subject: RE: [Ltru] Re: For review: Tagging text with no language Thread-Topic: [Ltru] Re: For review: Tagging text with no language Thread-Index: Acd+wScE8hcQqiJLTNy+fReP7/U5twAAJljA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org If you know there are multiple languages (as in 'this is deutsch', not Mark= 's ambiguous 'kind' cases), then that would be an acceptable place to use m= ul (if you find that useful for some purpose). Peter -----Original Message----- From: CE Whitehead [mailto:cewcathar@hotmail.com] Sent: Saturday, April 14, 2007 11:17 AM To: Peter Constable; www-international@w3.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: For review: Tagging text with no language > >From: CE Whitehead [mailto:cewcathar@hotmail.com] > > > Otherwise the code for content which you are sure is > > in some language where you do not know how many > > languages are involved is mis. > > > > Is that right?? > >No! If you don't know how many languages are involved, then you have not >made any determinations and the correct tag is und. This would be >completely inappropriate use of mis. > > > >Peter > > Well, mul I think is when you are sure there is more than one; is that wrong? Thanks. --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=3D660600&bcd=3DEMAILFOOT= ERAVERAGE _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 14:40:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnAi-0001Q3-Um; Sat, 14 Apr 2007 14:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnAi-0001Py-Ez for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:40:28 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcnAh-0002xu-5u for ltru@lists.ietf.org; Sat, 14 Apr 2007 14:40:28 -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.0.685.24; Sat, 14 Apr 2007 11:40:26 -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; Sat, 14 Apr 2007 11:40:26 -0700 From: Peter Constable To: "www-international@w3.org" , "ltru@lists.ietf.org" Date: Sat, 14 Apr 2007 11:39:48 -0700 Subject: RE: [Ltru] Re: For review: Tagging text with no language Thread-Topic: [Ltru] Re: For review: Tagging text with no language Thread-Index: Acd+uArpqrwy9kF/RtGQPqMv5oY7nwACf7SA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: CE Whitehead [mailto:cewcathar@hotmail.com] >> If a language tag must be applied to something like "ifdef >> DEBUG", then the appropriate language subtag would be zxx... > I would only really disagree with what you say if there were > programming languages where the words used to control the code > were in other languages in use, Excluding operators and such, which clearly are not words of English, the M= icrosoft C compiler recognizes this vocabulary: #define #error #import #undef #elif #if #include #else #ifdef #line #endif #ifndef #pragma auto double int struct break else long switch case enum register typedef char extern return union const float short unsigned continue for signed void default goto sizeof volatile do if static while __asm dllimport2 __int8 naked2 __based1 __except __int16 __stdcall __cdecl __fastcall __int32 thread2 __declspec __finally __int64 __try dllexport2 __inline __leave Some of those may be borrowings from English, but this is not English. Not that I expect everyone to differentiate every different element in thei= r document. If I discussing differences between the i607 and SMT5600 phones= in an email, I'm probably not going to bother tagging the part numbers as = zxx. But if I were editing a long document with lots of content of that nat= ure, I might. > zxx I gather keeps the spelling checker from checking > the language of the code, That is one possible reason for using such a tag among several. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 15:17: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 1HcnkO-0001di-2V; Sat, 14 Apr 2007 15:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcnkN-0001da-6j for ltru@lists.ietf.org; Sat, 14 Apr 2007 15:17:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcnkL-0002Ie-TH for ltru@lists.ietf.org; Sat, 14 Apr 2007 15:17:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcnkC-0004ry-9q for ltru@lists.ietf.org; Sat, 14 Apr 2007 21:17:08 +0200 Received: from d252172.dialin.hansenet.de ([80.171.252.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 21:17:08 +0200 Received: from nobody by d252172.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 21:17:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Apr 2007 21:14:26 +0200 Organization: Lines: 26 Message-ID: <46212812.5F2@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252172.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The meaning of zxx must be interpreted in terms of the coding standard > of which it is a part. ISO 639 is explicitly about coding human > languages. ?No linguistic content? in the case of zxx means ?no > content in any human language?. If a language tag must be applied to > something like ?ifdef DEBUG?, then the appropriate language subtag > would be zxx. Okay, that's very important for Mark's table, Richard's aricle, and IMO it deserves a comment for "zxx" in the language subtag registry: art = artificial human language, no programming language zxx = no linguistic content wrt. human languages, but it can be a programming language Ignoring those real (non-fictional) alien languages for the moment. So in a context where I can't use xml:lang="" I'd pick xml:lang="und" if I don't know what it is, and it's likely a human language. And I'd pick xml:lang="zxx" for a programming language if tools need to know that it's certainly not in the otherwise inherited xml:lang. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 15:41: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 1Hco7I-000612-Rt; Sat, 14 Apr 2007 15:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hco7H-00060s-Is for ltru@ietf.org; Sat, 14 Apr 2007 15:40:59 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hco7G-0000x4-BP for ltru@ietf.org; Sat, 14 Apr 2007 15:40:59 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hco7F-0003w1-Ha; Sat, 14 Apr 2007 15:40:57 -0400 Date: Sat, 14 Apr 2007 15:40:57 -0400 To: Peter Constable Subject: Re: [Ltru] RE: "mis" update review request Message-ID: <20070414194057.GG24951@mercury.ccil.org> References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > und means 'I have not determined what the language attribute is of > this information object.' > > mul means 'I have detected that this information object contains at > least one portion X in some language Lx and a different portion Y in > some different language Ly.' > > mis means 'I have determined that this information object is in a > language other than the set of languages covered by the available > identifiers.' > > zxx means 'I have determined that this information object is not > expressed in terms of a human language.' IMHO this language should go into 4646bis, of course made more formal. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 17:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcq5m-0008F9-Fn; Sat, 14 Apr 2007 17:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcq5k-0008F4-U5 for ltru@ietf.org; Sat, 14 Apr 2007 17:47:32 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcq5j-0004Pa-GZ for ltru@ietf.org; Sat, 14 Apr 2007 17:47:32 -0400 Received: from c83-248-96-45.bredband.comhem.se ([83.248.96.45]:2391 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hcq5i-0002mx-65; Sat, 14 Apr 2007 23:47:31 +0200 From: "Kent Karlsson" To: "'Peter Constable'" , , "'LTRU Working Group'" References: <20070413200501.EB832259791@eikenes.alvestrand.no><001901c77e60$152d9ee0$6401a8c0@DGBP7M81><01eb01c77e91$c78246f0$f962f853@streamserve.com> Subject: RE: [Ltru] RE: "mis" update review request Date: Sat, 14 Apr 2007 23:49:51 +0200 Message-ID: <020701c77ede$da079d00$f962f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acd+YCLZ2iH8PUPiTDOSSsjCzKG3xwALjyDgAAgtUaAACotGsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hcq5i-0002mx-65. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Hcq5i-0002mx-65 753db4718c0993288f8f42077a8479e4 X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > > > I would rather see "mis" as saying "linguistic content" > > (but not specified which language), opposite to "no > > linguistic content", but quite close to "und" (which > > seems to cover both "no linguistic content" and "linguistic > > content" and maybe also 'mul', II understand the debate > > so far). > > "" means 'I'm giving no information.' Agreed, but if one removes the subjective parts here, then "" and "und" are then very much the same. The content can (appropriately) be in any (human) language or languages, or maybe have no linguistic content. Both would cover all and any (human) language or languages as well as have no linguistic content. > und means 'I have not determined what the language attribute > is of this information object.' I'm not too keen on the subjectiveness ("I") here. It assumes that the "I" (or "we") is somehow known or knowable for a use instance. > mul means 'I have detected that this information object > contains at least one portion X in some language Lx and a > different portion Y in some different language Ly.' ok. > mis means 'I have determined that this information object is > in a language other than the set of languages covered by the > available identifiers.' That would be "other (human) language". But you want to remove the "other" from the collection names, and I guess that means a semantic change too. "mis" would then include all languages in-scope, not just the ones without a code (or more specific collection code) of their own. If you include the "other" part here, "mis" in a 639-3 setting is the empty set of languages (at least until a new in-scope language is discovered/invented). Assuming instead a "mis" without the "other" part, "mis" would say "any one (human) language", almost the same as "und" and "" except that "mis" would not cover "mul" nor "zxx". But "mis" with and without "other" are quite different: empty set (w.r.t. 639-3) vs. the set of all individual languages. > zxx means 'I have determined that this information object is > not expressed in terms of a human language.' Ok (and some subjectiveness must remain...). /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 18:15: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 1HcqWq-0004TE-Id; Sat, 14 Apr 2007 18:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcqWp-0004Mf-6E for ltru@ietf.org; Sat, 14 Apr 2007 18:15:31 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcqWn-0006KR-TK for ltru@ietf.org; Sat, 14 Apr 2007 18:15:31 -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 <20070414221528.XOSM14403.mta9.adelphia.net@DGBP7M81> for ; Sat, 14 Apr 2007 18:15:28 -0400 Message-ID: <000301c77ee2$6ebc6ea0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 14 Apr 2007 15:15:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Peter Constable scripsit: > >> und means 'I have not determined what the language attribute is of >> this information object.' >> >> mul means 'I have detected that this information object contains at >> least one portion X in some language Lx and a different portion Y in >> some different language Ly.' >> >> mis means 'I have determined that this information object is in a >> language other than the set of languages covered by the available >> identifiers.' >> >> zxx means 'I have determined that this information object is not >> expressed in terms of a human language.' > > IMHO this language should go into 4646bis, of course made more formal. +1. Doing this would be preferable to annotating "mis" and friends 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 Sat Apr 14 18:33: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 1Hcqo0-00047T-N1; Sat, 14 Apr 2007 18:33:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcqnz-00047O-7e for ltru@lists.ietf.org; Sat, 14 Apr 2007 18:33:15 -0400 Received: from bay0-omc1-s32.bay0.hotmail.com ([65.54.246.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcqny-0000h9-Rx for ltru@lists.ietf.org; Sat, 14 Apr 2007 18:33:15 -0400 Received: from hotmail.com ([65.54.169.39]) by bay0-omc1-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 14 Apr 2007 15:33:14 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 14 Apr 2007 15:33:14 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Sat, 14 Apr 2007 22:33:10 GMT X-Originating-IP: [72.150.213.37] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <46212812.5F2@xyzzy.claranet.de> From: "CE Whitehead" To: nobody@xyzzy.claranet.de, www-international@w3.org Bcc: Date: Sat, 14 Apr 2007 18:33:10 -0400 Mime-Version: 1.0 X-OriginalArrivalTime: 14 Apr 2007 22:33:14.0197 (UTC) FILETIME=[E3BF8050:01C77EE4] X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@lists.ietf.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============2054537018==" Errors-To: ltru-bounces@ietf.org --===============2054537018== Content-Type: text/html; format=flowed


Hi,

More on tagging code:

From reading  "Internationalization Best Practices"

http://www.w3.org/International/geo/html-tech/tech-lang.html#ri20050128.175100333

if you have an element in HTML of XML code with an attribute value such as "Swedish" (for a title or something)

(here's the example from Internationalization Best Practices":

<p title="Swedish"><a xml:lang="sv" lang="sv" href="http://www.w3.org/International/geo/html-tech/index.sv.html">svenska</a></p>

then you do need to tag the language of that attribute value;

you do so by inserting in your document a second element if necessary (which serves to enclose the HTML or XML element, and set it off from the rest of the text).

 But you only need to do this if the language of the attribute value is different from that of the text content elsewhere in the document.

But you never apparently tag the language of the attribute itself, the attribute "title" in this case, which is clearly English ( HTML and XML code are derived from English).  Just the language of the value!

Thus, if your title value were 'suédois' instead of 'Swedish,' you'd have to tag the language of this piece of code as French rather than as English,
in spite of the fact that title is an English word!
 
(if I understood the Best Practices document correctly)


>Peter Constable wrote:
>
> > The meaning of zxx must be interpreted in terms of the coding standard
> > of which it is a part. ISO 639 is explicitly about coding human
> > languages. ?No linguistic content? in the case of zxx means ?no
> > content in any human language?. If a language tag must be applied to
> > something like ?ifdef DEBUG?, then the appropriate language subtag
> > would be zxx.
>
>Okay, that's very important for Mark's table, Richard's aricle, and
>IMO it deserves a comment for "zxx" in the language subtag registry:
>
>art   = artificial human language, no programming language
>zxx   = no linguistic content wrt. human languages, but it can be a
>         programming language
>

(Still distraught as John C. has told me that there are now programming languages which make use of keywords in different languages.

So maybe just a note--programming languages are tagged as zxx even though of course code is derived from real languages; and maybe a reference to the existence of a few non-English programming language

but if no one else thinks this is proper, I'll withdraw my suggestion

)
>Ignoring those real (non-fictional) alien languages for the moment.
>
>So in a context where I can't use xml:lang="" I'd pick xml:lang="und"
>if I don't know what it is, and it's likely a human language.
>
>And I'd pick xml:lang="zxx" for a programming language if tools need
>to know that it's certainly not in the otherwise inherited xml:lang.
>
>Frank
>
>
>


The average US Credit Score is 675. The cost to see yours: $0 by Experian. --===============2054537018== 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 --===============2054537018==-- From ltru-bounces@ietf.org Sat Apr 14 18:42: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 1Hcqwh-0007qK-JL; Sat, 14 Apr 2007 18:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcqwg-0007qF-Nn for ltru@ietf.org; Sat, 14 Apr 2007 18:42:14 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcqwf-0002OE-Dj for ltru@ietf.org; Sat, 14 Apr 2007 18:42:14 -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.0.685.24; Sat, 14 Apr 2007 15:42:12 -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; Sat, 14 Apr 2007 15:42:12 -0700 From: Peter Constable To: "ietf-languages@iana.org" , 'LTRU Working Group' Date: Sat, 14 Apr 2007 15:42:06 -0700 Subject: RE: [Ltru] RE: "mis" update review request Thread-Topic: [Ltru] RE: "mis" update review request Thread-Index: Acd+YCLZ2iH8PUPiTDOSSsjCzKG3xwALjyDgAAgtUaAACotGsAAC03QA Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no><001901c77e60$152d9ee0$6401a8c0@DGBP7M81><01eb01c77e91$c78246f0$f962f853@streamserve.com> <020701c77ede$da079d00$f962f853@streamserve.com> In-Reply-To: <020701c77ede$da079d00$f962f853@streamserve.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: 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 From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] >> "" means 'I'm giving no information.' > > Agreed, but if one removes the subjective parts here, then > "" and "und" are then very much the same. The only difference is that with "und" you can infer that the tagger evalua= ted the content made a conscious choice to use "und", whereas with "" you k= now nothing about the tagger's decision process. In terms of processing you= can do on content so tagged, I don't think there's a difference. >> und means 'I have not determined what the language attribute >> is of this information object.' > > I'm not too keen on the subjectiveness ("I") here. It assumes > that the "I" (or "we") is somehow known or knowable for a use > instance. Replace "I" with "whomever/whatever process tagged this content. >> mis means 'I have determined that this information object is >> in a language other than the set of languages covered by the >> available identifiers.' > > That would be "other (human) language". But you want to remove the "other" from the collection names It is a special case, the one case where "other" is OK. > Assuming instead a "mis" without the "other" part, "mis" would > say "any one (human) language", almost the same as "und" and > "" except that "mis" would not cover "mul" nor "zxx". No good: "mis" without "other" is no long the same "mis". Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 20:05: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 1HcsEx-0003JK-Lu; Sat, 14 Apr 2007 20:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsEw-0003JF-8C for ltru@lists.ietf.org; Sat, 14 Apr 2007 20:05:10 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsEu-0000uA-UD for ltru@lists.ietf.org; Sat, 14 Apr 2007 20:05:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YLYHsoOLPWzDv9wppfNRZqPUzV9mh6KRcjKjoDkiBuuG+bma0y8ftKWcTQpbMqif; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.219] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HcsEu-0006II-G1; Sat, 14 Apr 2007 20:05:08 -0400 Message-ID: <006301c77ef1$fbca3660$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: For review: Tagging text with no language Date: Sat, 14 Apr 2007 17:06:56 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd788d016fb8d77157da4a887375136eded350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.219 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "CE Whitehead" > To: ; > Cc: > Sent: Saturday, April 14, 2007 3:33 PM > Subject: [Ltru] Re: For review: Tagging text with no language ... > But you never apparently tag the language of the attribute itself, > the attribute "title" in this case, which is clearly English ( HTML > and XML code are derived from English). Just the language > of the value! ... That's because HTML and XML are no more English than C, ALGOL, FORTRAN or Ada. There are lots of borrowings, to be sure,but they are no more English than English is French. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 14 21:17: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 1HctMX-0002N6-Sj; Sat, 14 Apr 2007 21:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HctMV-0002Mt-Q5 for ltru@lists.ietf.org; Sat, 14 Apr 2007 21:17:03 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HctMS-0003ta-6v for ltru@lists.ietf.org; Sat, 14 Apr 2007 21:17:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HctMM-0003Pz-Va for ltru@lists.ietf.org; Sun, 15 Apr 2007 03:16:54 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 03:16:54 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 03:16:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 15 Apr 2007 03:16:22 +0200 Organization: Lines: 16 Message-ID: <46217CE6.200B@xyzzy.claranet.de> References: <000301c77ee2$6ebc6ea0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> IMHO this language should go into 4646bis, of course made more formal. > +1. Doing this would be preferable to annotating "mis" and friends in > the Registry. No, users including taggers read at best the registry record, not the specification. A warning about such dangerously misleading tags like "mis" needs to be in the registry. Or we exclude "mis" from 4645bis. Stability is no issue, a tag where nobody (maybe minus John and Peter) knows or agrees what it means is anyway hopeless. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 15 23:18: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 1HdHjY-0006hC-1o; Sun, 15 Apr 2007 23:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHjW-0006h4-FC for ltru@ietf.org; Sun, 15 Apr 2007 23:18:26 -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 1HdHjV-0004dn-4L for ltru@ietf.org; Sun, 15 Apr 2007 23:18:26 -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 <20070416031824.DTWT6560.mta15.adelphia.net@DGBP7M81> for ; Sun, 15 Apr 2007 23:18:24 -0400 Message-ID: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 15 Apr 2007 20:18:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Doug Ewell wrote: > >>> IMHO this language should go into 4646bis, of course made more >>> formal. >> >> +1. Doing this would be preferable to annotating "mis" and friends >> in the Registry. > > No, users including taggers read at best the registry record, not the > specification. A warning about such dangerously misleading tags like > "mis" needs to be in the registry. Or we exclude "mis" from 4645bis. There are lots of details about RFC 4646(bis) that would be missed by someone who reads only the Registry. Should we design a specification under the assumption that people will not read it? Is anyone else uncomfortable with this approach? > Stability is no issue, a tag where nobody (maybe minus John and Peter) > knows or agrees what it means is anyway hopeless. That's why I agree with John that Peter's explanation, or a formalized version thereof, should be added to the spec. -- 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 Apr 16 11:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTQD-0004Y4-Od; Mon, 16 Apr 2007 11:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTQC-0004Xx-Iq for ltru@ietf.org; Mon, 16 Apr 2007 11:47:16 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTQB-0007ik-8w for ltru@ietf.org; Mon, 16 Apr 2007 11:47:16 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 08:47:14 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Mon, 16 Apr 2007 08:47:14 -0700 From: Peter Constable To: "ietf-languages@iana.org" , 'LTRU Working Group' Date: Mon, 16 Apr 2007 08:47:10 -0700 Subject: RE: [Ltru] RE: "mis" update review request Thread-Topic: [Ltru] RE: "mis" update review request Thread-Index: AceAJdMn/Q7sLe3/QhqOgdNOQRbHTgAF/3Gg Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> <462370FB.9000608@hpl.hp.com> In-Reply-To: <462370FB.9000608@hpl.hp.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Jeremy Carroll [mailto:jjc@hpl.hp.com] > Peter Constable wrote: >> Does that apply to its use in xml:lang=3D"" too? That's different from >> omitting xml:lang... I didn't write all the stuff you quoted as being from me; *you* wrote it. > I don't think xml:lang=3D"" should be given any semantics other than a > processing one My statement was that "" means 'no information'. I think we're saying the s= ame thing. > On the wider topic, I wonder if there is a compromise comment that can > be added to the mis definition, that suggests that, when tagging, other > more specific correct tags should be used in preference, but when > reading, no such assumption can be made, due to the inherent instability > of such usage. This would not invalidate any prior use, but would > suggest that the more conservative approach was preferred. Users need to understand that mis is inherently unstable wrt semantics. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 16 12:15: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 1HdTrO-0008Fl-6n; Mon, 16 Apr 2007 12:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTrM-0008Ff-TR for ltru@ietf.org; Mon, 16 Apr 2007 12:15:20 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTrL-0008Vj-IO for ltru@ietf.org; Mon, 16 Apr 2007 12:15:20 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HdTr3-0002A4-OD; Mon, 16 Apr 2007 12:15:01 -0400 Date: Mon, 16 Apr 2007 12:15:01 -0400 To: Jeremy Carroll Subject: Re: [Ltru] RE: "mis" update review request Message-ID: <20070416161501.GC10816@mercury.ccil.org> References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> <462370FB.9000608@hpl.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462370FB.9000608@hpl.hp.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "ietf-languages@iana.org" , '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 Jeremy Carroll scripsit: > In practice xml:lang="" is most likely to arise when merging information > from multiple xml documents. Indeed, IIRC it was originally introduced by the XML Core WG (to which I belong, but which I am *not* speaking for) in connection with the development of XInclude, which is designed precisely to merge multiple XML documents into a single one. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan|cowan@ccil.org|ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 16 13:23: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 1HdUvH-0007tn-Ie; Mon, 16 Apr 2007 13:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUvG-0007ti-7b for ltru@ietf.org; Mon, 16 Apr 2007 13:23:26 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUvE-00038N-SN for ltru@ietf.org; Mon, 16 Apr 2007 13:23:26 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 10:23:24 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon, 16 Apr 2007 10:23:23 -0700 From: Peter Constable To: "ietf-languages@iana.org" , 'LTRU Working Group' Date: Mon, 16 Apr 2007 10:23:20 -0700 Subject: RE: [Ltru] RE: "mis" update review request Thread-Topic: [Ltru] RE: "mis" update review request Thread-Index: AceAJdMn/Q7sLe3/QhqOgdNOQRbHTgAF/3GgAAOCLtA= Message-ID: References: <20070413200501.EB832259791@eikenes.alvestrand.no> <001901c77e60$152d9ee0$6401a8c0@DGBP7M81> <01eb01c77e91$c78246f0$f962f853@streamserve.com> <462370FB.9000608@hpl.hp.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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My apologies: Jukka wrote the text Jeremy attributed to me. Peter -----Original Message----- From: Peter Constable [mailto:petercon@microsoft.com] Sent: Monday, April 16, 2007 8:47 AM To: ietf-languages@iana.org; 'LTRU Working Group' Subject: RE: [Ltru] RE: "mis" update review request From: Jeremy Carroll [mailto:jjc@hpl.hp.com] > Peter Constable wrote: >> Does that apply to its use in xml:lang=3D"" too? That's different from >> omitting xml:lang... I didn't write all the stuff you quoted as being from me; *you* wrote it. > I don't think xml:lang=3D"" should be given any semantics other than a > processing one My statement was that "" means 'no information'. I think we're saying the s= ame thing. > On the wider topic, I wonder if there is a compromise comment that can > be added to the mis definition, that suggests that, when tagging, other > more specific correct tags should be used in preference, but when > reading, no such assumption can be made, due to the inherent instability > of such usage. This would not invalidate any prior use, but would > suggest that the more conservative approach was preferred. Users need to understand that mis is inherently unstable wrt semantics. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 16 14:56: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 1HdWNf-0001qO-79; Mon, 16 Apr 2007 14:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWNd-0001p7-Ax for ltru@lists.ietf.org; Mon, 16 Apr 2007 14:56:49 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound7-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWNa-0004e4-CJ for ltru@lists.ietf.org; Mon, 16 Apr 2007 14:56:49 -0400 Received: from outbound7-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-blu-R.bigfish.com (Postfix) with ESMTP id 1A51421279F; Mon, 16 Apr 2007 18:56:46 +0000 (UTC) Received: from mail175-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound7-blu.bigfish.com (Postfix) with ESMTP id EE402163008B; Mon, 16 Apr 2007 18:56:45 +0000 (UTC) Received: from mail175-blu (localhost.localdomain [127.0.0.1]) by mail175-blu-R.bigfish.com (Postfix) with ESMTP id B0B91AA8212; Mon, 16 Apr 2007 18:56:45 +0000 (UTC) X-BigFish: VP Received: by mail175-blu (MessageSwitch) id 1176749805657860_24613; Mon, 16 Apr 2007 18:56:45 +0000 (UCT) Received: from usccimta01.spe.sony.com (unknown [64.14.251.195]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail175-blu.bigfish.com (Postfix) with ESMTP id 351DC8A8064; Mon, 16 Apr 2007 18:56:45 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usccimta01.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007041611301541-1733740 ; Mon, 16 Apr 2007 11:30:15 -0700 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] Re: For review: Tagging text with no language 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, 16 Apr 2007 11:28:20 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/16/2007 11:28:26, Serialize complete at 04/16/2007 11:28:26, Itemize by SMTP Server on USCCiMTA01/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/16/2007 11:30:15 AM, Serialize by Router on USCCiMTA01/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/16/2007 11:56:45 AM, Serialize complete at 04/16/2007 11:56:45 AM X-Spam-Score: 0.7 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: "www-international@w3.org" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966115741==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0966115741== Content-Type: multipart/alternative; boundary="=_alternative 0065A2F6882572BF_=" This is a multipart message in MIME format. --=_alternative 0065A2F6882572BF_= Content-Type: text/plain; charset="US-ASCII" Peter wrote: > Excluding operators and such, which clearly are not words of > English, the Microsoft C compiler recognizes this vocabulary: > > #define #error #import #undef #elif #if #include > #else #ifdef #line #endif #ifndef #pragma > auto double int struct break else long switch > case enum register typedef char extern return union > const float short unsigned continue for signed void > default goto sizeof volatile do if static while > __asm dllimport2 __int8 naked2 __based1 __except > __int16 __stdcall __cdecl __fastcall __int32 > thread2 __declspec __finally __int64 __try > dllexport2 __inline __leave > > Some of those may be borrowings from English, but this is not English. Let's look at a real use case. Would you say this page is in "en" and "zxx" and that the sections of code have no linguistic value even though they are clearly intended to be read by humans and not machines? Or does context matter? http://www.xml.com/pub/a/2000/11/29/schemas/part1.html?page=7 Interpreting "no linguistic content" as "not a human language, could be a programming language" could cause some problems. There may be a use case for programming languages to have their own tag if this is deemed appropriate for the 639 standards or IANA registry, and these languages are different than say, instrumental music in the Library of Congress or a sound effects track in a film (both zxx, I'd say). I think programming languages have specific identification and parsing needs and as such need to be treated differently. The code in the article above should be rendered in Braille, for example, so it must be parsed. This makes it different from non-linguistic content. Are we sure we want to lump programming languages in with the "zxx" semantic? More and more people use programming language terms in their everyday speech. How would you classify the page I cite? Regards, Karen Broome --=_alternative 0065A2F6882572BF_= Content-Type: text/html; charset="US-ASCII"
Peter wrote:

> Excluding operators and such, which clearly are not words of
> English, the Microsoft C compiler recognizes this vocabulary:
>
> #define #error #import #undef #elif #if #include
> #else #ifdef #line #endif #ifndef #pragma
> auto double int struct break else long switch
> case enum register typedef char extern return union
> const float short unsigned continue for signed void
> default goto sizeof volatile do if static while
> __asm dllimport2 __int8 naked2 __based1 __except
> __int16 __stdcall __cdecl __fastcall __int32
> thread2 __declspec __finally __int64 __try
> dllexport2 __inline __leave
>
> Some of those may be borrowings from English, but this is not English.
Let's look at a real use case. Would you say this page is in "en" and "zxx" and that the sections of code have no linguistic value even though they are clearly intended to be read by humans and not machines? Or does context matter?

http://www.xml.com/pub/a/2000/11/29/schemas/part1.html?page=7

Interpreting "no linguistic content" as "not a human language, could be a programming language" could cause some problems. There may be a use case for programming languages to have their own tag if this is deemed appropriate for the 639 standards or IANA registry, and these languages are different than say, instrumental music in the Library of Congress or a sound effects track in a film (both zxx, I'd say).

I think programming languages have specific identification and parsing needs and as such need to be treated differently. The code in the article above should be rendered in Braille, for example, so it must be parsed. This makes it different from non-linguistic content.

Are we sure we want to lump programming languages in with the "zxx" semantic? More and more people use programming language terms in their everyday speech.

How would you classify the page I cite?

Regards,

Karen Broome --=_alternative 0065A2F6882572BF_=-- --===============0966115741== 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 --===============0966115741==-- From ltru-bounces@ietf.org Mon Apr 16 18:49: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 1Hda0f-0003sc-4Z; Mon, 16 Apr 2007 18:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hda0e-0003sX-Nj for ltru@lists.ietf.org; Mon, 16 Apr 2007 18:49:20 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hda0b-0001qy-5Q for ltru@lists.ietf.org; Mon, 16 Apr 2007 18:49:20 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1594204nzf for ; Mon, 16 Apr 2007 15:49:16 -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=Xv676jsYfFcdP9YM2sp+MNMqY1zOB4jDQ+Lalvbzf7j7i+g51aZhuVGbLAsCt776YNxCsa7jVGK9rezhm477BkAG8BUl3yBeTlBPxb9DM1rK5kumyLTRswc5TTNjwCwR9oPOJV1QfO6V1FdS58aN58eEdUggtXG997rixTy3MoY= 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=mx+rrBWWbDhebNXnZAodfXgk1cMs7qD7LzOdg0E0JEtsXq8KbbzrArmZWSW9f5nQj2PI38AZgRHbIg0B4h2BYlQQYUxKnYKyeD6fafo7Q5frxpvT5wNMCmKIcyF4lF5MxnLq+gwBAqCektkifSv3iJWDskHrSHOfQB4SU67nzMY= Received: by 10.115.74.1 with SMTP id b1mr314888wal.1176763756147; Mon, 16 Apr 2007 15:49:16 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 16 Apr 2007 15:49:16 -0700 (PDT) Message-ID: <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> Date: Mon, 16 Apr 2007 15:49:16 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> X-Google-Sender-Auth: 0860787571499e1c X-Spam-Score: 0.5 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: "ietf-languages@iana.org" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1587685502==" Errors-To: ltru-bounces@ietf.org --===============1587685502== Content-Type: multipart/alternative; boundary="----=_Part_62432_29610093.1176763756022" ------=_Part_62432_29610093.1176763756022 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. I think we have to be very careful here. The meaning of a standard like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's mind. It is established by the wording in the standard, and how reasonable people could interpret it. The fact that "mis" was incorporated in order to account for MARC codes is interesting, but is not in the text of the standard. We can't expect users of BCP 47 to all be able to read Peter's mind before tagging. 2. When we are looking at stability, that is very important: our goal is that once content is correctly tagged, people can depend on the fact that we will not change the meaning of a tag out from under them. So clarifications that we add in future versions of 4646 or the registry are fine, as long as they do not narrow the range of reasonable interpretations. We can broaden them. So in the case of "mis", a proposed narrowing to include just the MARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time that "mis" was added to the language registry (the BCP 47 semantics are established at the time we add the code). That is one of the key principles of BCP 47, is to isolate us where necessary from instabilities in the source standards. (The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.) 3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having - aus Australian languages means any of the languages on http://www.ethnologue.com/show_family.asp?subid=90498 - bat Baltic (Other) => Baltic languages, means any of the languages on http://www.ethnologue.com/show_family.asp?subid=90207 - mis Miscellaneous languages, essentially the root for http://www.ethnologue.com/family_index.asp and so on. This is useful on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In the ideal case, we would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as http://www.ethnologue.com/show_lang_family.asp?code=eng we'd have codes for each of the parent groupings, not just some of them, like "Australian languages".) 3. Randy raised the issue as to whether "mis" in the broad sense is useful (as something that has linguistic content, but I don't know what it is). It very much follows the model in #3. There are times when detection can only determine that it looks like there is some linguistic content -- it is not just binary data -- but current detection can't really determine what it might be. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx". 4. I'm leery of using zxx for programming languages, instead of just binary. There is clearly some linguistic content in "if (content == null) { /* remove the item in the lookup table */ ...}". Maybe we need another code for this, something different than either 'art' or 'zxx'. Mark On 4/14/07, Peter Constable wrote: > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > > > I find it very hard to believe that a reasonable analysis > > (whether done by human or machine) would classify a text a > > being "mis" without being able to recognize which of the > > languages in that grouping the text belonged to. I can > > believe someone could look at text and say "it's a slavic > > language, but I'm not sure which one." Do we really think > > someone or something would look at some text and say "it's > > Ainu, Andamanese, or Etruscan, but I can't tell which, so > > I'll tag it 'mis'"? > > If someone were so tempted, I would argue that would be inappropriate use > of mis. Since they do not know what it is, their declaration is that the > language identity is not determined, and the appropriate tag for that is > und. Appropriate use of mis does not require that one know the language of > the content; it does, however, require that one know it is *not* a language > covered by any of the available tags. > > > > Peter > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_62432_29610093.1176763756022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. I think we have to be very careful here. The meaning of a standard like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's mind. It is established by the wording in the standard, and how reasonable people could interpret it. The fact that "mis" was incorporated in order to account for MARC codes is interesting, but is not in the text of the standard. We can't expect users of BCP 47 to all be able to read Peter's mind before tagging.

2. When we are looking at stability, that is very important: our goal is that once content is correctly tagged, people can depend on the fact that we will not change the meaning of a tag out from under them. So clarifications that we add in future versions of 4646 or the registry are fine, as long as they do not narrow the range of reasonable interpretations. We can broaden them. So in the case of "mis", a proposed narrowing to include just the MARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time that "mis" was added to the language registry (the BCP 47 semantics are established at the time we add the code). That is one of the key principles of BCP 47, is to isolate us where necessary from instabilities in the source standards.

(The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.)

3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having
and so on. This is useful on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In the ideal case, we would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as http://www.ethnologue.com/show_lang_family.asp?code=eng we'd have codes for each of the parent groupings, not just some of them, like "Australian languages".)

3. Randy raised the issue as to whether "mis" in the broad sense is useful (as something that has linguistic content, but I don't know what it is). It very much follows the model in #3. There are times when detection can only determine that it looks like there is some linguistic content -- it is not just binary data -- but current detection can't really determine what it might be. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".

4. I'm leery of using zxx for programming languages, instead of just binary. There is clearly some linguistic content in "if (content == null) { /* remove the item in the lookup table */ ...}". Maybe we need another code for this, something different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter Constable <petercon@microsoft.com> wrote:
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]


> I find it very hard to believe that a reasonable analysis
> (whether done by human or machine) would classify a text a
> being "mis" without being able to recognize which of the
> languages in that grouping the text belonged to.  I can
> believe someone could look at text and say "it's a slavic
> language, but I'm not sure which one."  Do we really think
> someone or something would look at some text and say "it's
> Ainu, Andamanese, or Etruscan, but I can't tell which, so
> I'll tag it 'mis'"?

If someone were so tempted, I would argue that would be inappropriate use of mis. Since they do not know what it is, their declaration is that the language identity is not determined, and the appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, require that one know it is *not* a language covered by any of the available tags.



Peter

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



--
Mark ------=_Part_62432_29610093.1176763756022-- --===============1587685502== 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 --===============1587685502==-- From ltru-bounces@ietf.org Mon Apr 16 20:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdbP3-0004gN-93; Mon, 16 Apr 2007 20:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdbP1-0004gI-S8 for ltru@lists.ietf.org; Mon, 16 Apr 2007 20:18:35 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdbOy-0000v7-LL for ltru@lists.ietf.org; Mon, 16 Apr 2007 20:18:35 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 17:18:32 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 16 Apr 2007 17:18:31 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Mon, 16 Apr 2007 17:18:30 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQ Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> In-Reply-To: <30b660a20704161549h254f9bfdo1ce3e87ea3737305@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: 1.3 (+) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064004760==" Errors-To: ltru-bounces@ietf.org --===============2064004760== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB533NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB533NAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis is = bound to be in MARC, and (b) any existing usage would assume the context of= ISO 639-2 (i.e. mis in existing usage is the exception list for ISO 639-2)= . Re 2: The mis collection is inherently unstable - unavoidably so. Prior to = 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content a= s mis; after that date, an implementation of ISO 639-2 would have tagged Ai= nu content as ain; existing content tagged before that date would not get r= etrieved by request for ain, and it would be conformant to suppose that req= uests for mis would not return Ainu content. The mis collection is ugly, pu= re and simple. So, I don't see what the point is of getting worried over wh= ether we're making mis unstable: it's been that way for some time. (Note: mis is badly defined from a stability perspective, though I don't th= ink there's much question of how it's defined.) Re 3(b): "There are times when detection can only determine that it looks l= ike there is some linguistic content -- it is not just binary data -- but c= urrent detection can't really determine what it might be. That is, a code t= hat means "according to our best available detection methods this doesn't l= ook like it is zxx"." If you want to use mis for that, I would argue that t= hat is significantly changing the semantics of mis. (Even though mis is uns= table, it is unstable on a qualitative level; this is a categorical change.= ) I definitely oppose that. If you want an ID for "undetermined human langu= age", then that should be proposed. We should not usurp an existing ID for = that purpose. Re 4: I don't see how your example differs from this: "Nous avons une phras= e en fran=E7ais (but this is in English)". The fact that the parenthetical = text is in English doesn't change the fact that the other text is in French= . Similarly, in your example, the fact that there is a comment in English d= oes not change the fact that the rest of the text is not in a human languag= e. Do we create tags for "French with embedded bits of English"? Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request 1. I think we have to be very careful here. The meaning of a standard like = ISO 639-2 is established not by what we wish it would have said, nor by wha= t we would find out if we were able to read Peter's mind. It is established= by the wording in the standard, and how reasonable people could interpret = it. The fact that "mis" was incorporated in order to account for MARC codes= is interesting, but is not in the text of the standard. We can't expect us= ers of BCP 47 to all be able to read Peter's mind before tagging. 2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we = will not change the meaning of a tag out from under them. So clarifications= that we add in future versions of 4646 or the registry are fine, as long a= s they do not narrow the range of reasonable interpretations. We can broade= n them. So in the case of "mis", a proposed narrowing to include just the M= ARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 a= t the time that "mis" was added to the language registry (the BCP 47 semant= ics are established at the time we add the code). That is one of the key pr= inciples of BCP 47, is to isolate us where necessary from instabilities in = the source standards. (The one exception we might be able to make is where something is so badly = defined that most reasonable people couldn't come up with any consistent de= finition for it.) 3. Now, I think there are steps that can be taken to make the above moot. I= think Peter's suggestion for ISO 639-X of broadening all of the Collection= s to remove the (Other) is exactly the right strategy, and if this can be d= one before 4646bis is issued, all the better. So having * aus Australian languages means any of the languages on http://www.e= thnologue.com/show_family.asp?subid=3D90498 * bat Baltic (Other) =3D> Baltic languages, means any of the language= s on http://www.ethnologue.com/show_family.asp?subid=3D90207 * mis Miscellaneous languages, essentially the root for http://www.et= hnologue.com/family_index.asp and so on. This is useful on a number of levels; it resolves a number of pr= oblems in the interpretation of language codes, and makes the source standa= rds themselves more stable. (In the ideal case, we would have codes for eac= h of the possible "decision points" in the language tree. That is, if we lo= ok at any language code such as http://www.ethnologue.com/show_lang_family.= asp?code=3Deng we'd have codes for each of the parent groupings, not just s= ome of them, like "Australian languages".) 3. Randy raised the issue as to whether "mis" in the broad sense is useful = (as something that has linguistic content, but I don't know what it is). It= very much follows the model in #3. There are times when detection can only= determine that it looks like there is some linguistic content -- it is not= just binary data -- but current detection can't really determine what it m= ight be. That is, a code that means "according to our best available detect= ion methods this doesn't look like it is zxx". 4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) { /= * remove the item in the lookup table */ ...}". Maybe we need another code = for this, something different than either 'art' or 'zxx'. Mark On 4/14/07, Peter Constable > wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the lan= guage identity is not determined, and the appropriate tag for that is und. = Appropriate use of mis does not require that one know the language of the c= ontent; it does, however, require that one know it is *not* a language cove= red by any of the available tags. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB533NAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re 1: Yes, be careful: (a) the majority of existing legacy u= sage of mis is bound to be in MARC, and (b) any existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the exception list for = ISO 639-2).

 

Re 2: The mis collection is inherently unstable – unav= oidably so. Prior to 2005-08-16, an implementation of ISO 639-2 would have tagged A= inu content as mis; after that date, an implementation of ISO 639-2 would have tagged Ainu content as ain; existing content tagged before that date would = not get retrieved by request for ain, and it would be conformant to suppose tha= t requests for mis would not return Ainu content. The mis collection is ugly, pure and simple. So, I don’t see what the point is of getting worried over whether we’re making mis unstable: it’s been that way for = some time.

 

(Note: mis is badly defined from a stability perspective, th= ough I don’t think there’s much question of how it’s defined.)=

 

Re 3(b): “There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".” If you want to us= e mis for that, I would argue that that is significantly changing the semanti= cs of mis. (Even though mis is unstable, it is unstable on a qualitative level= ; this is a categorical change.) I definitely oppose that. If you want an ID for &= #8220;undetermined human language”, then that should be proposed. We should not usurp an existing ID for that purpose.

 

Re 4: I don’t see how your example differs from this: = “Nous avons une phrase en fran=E7ais (but this is in English)”. The fact th= at the parenthetical text is in English doesn’t change the fact that the oth= er text is in French. Similarly, in your example, the fact that there is a comment = in English does not change the fact that the rest of the text is not in a huma= n language. Do we create tags for “French with embedded bits of English= ”?

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, April 16, 2007 3:49 PM
To: Peter Constable
Cc: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update review request

 

1. I think we have to be very careful here. The meanin= g of a standard like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's mind. It is established by the wording in the standard, and how reasona= ble people could interpret it. The fact that "mis" was incorporated i= n order to account for MARC codes is interesting, but is not in the text of t= he standard. We can't expect users of BCP 47 to all be able to read Peter's mi= nd before tagging.

2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we wil= l not change the meaning of a tag out from under them. So clarifications that= we add in future versions of 4646 or the registry are fine, as long as they do= not narrow the range of reasonable interpretations. We can broaden them. So in = the case of "mis", a proposed narrowing to include just the MARC code= s is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time th= at "mis" was added to the language registry (the BCP 47 semantics ar= e established at the time we add the code). That is one of the key principles= of BCP 47, is to isolate us where necessary from instabilities in the source standards.

(The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.)

3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections= to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having

and so on. This is usef= ul on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In = the ideal case, we would have codes for each of the possible "decision poi= nts" in the language tree. That is, if we look at any language code such as http://w= ww.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them, li= ke "Australian languages".)

3. Randy raised the issue as to whether "mis" in the broad sense = is useful (as something that has linguistic content, but I don't know what it = is). It very much follows the model in #3. There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".

4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) = { /* remove the item in the lookup table */ ...}". Maybe we need another co= de for this, something different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter Constabl= e <petercon@microsoft.com>= ; wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]


> I find it very hard to believe that a reasonable analysis
> (whether done by human or machine) would classify a text a
> being "mis" without being able to recognize which of the
> languages in that grouping the text belonged to.  I can
> believe someone could look at text and say "it's a slavic
> language, but I'm not sure which one."  Do we really th= ink
> someone or something would look at some text and say "it's
> Ainu, Andamanese, or Etruscan, but I can't tell which, so
> I'll tag it 'mis'"?

If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the langu= age identity is not determined, and the appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, require that one know it is *not* a language cov= ered by any of the available tags.



Peter

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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB533NAEXMSGC117re_-- --===============2064004760== 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 --===============2064004760==-- From ltru-bounces@ietf.org Mon Apr 16 20:38: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 1Hdbia-0007Cs-Ih; Mon, 16 Apr 2007 20:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdbiZ-0007Cn-N3 for ltru@lists.ietf.org; Mon, 16 Apr 2007 20:38:47 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdbiZ-0004Y4-CS for ltru@lists.ietf.org; Mon, 16 Apr 2007 20:38:47 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 17:38:46 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon, 16 Apr 2007 17:38:46 -0700 From: Peter Constable To: "ltru@lists.ietf.org" , "www-international@w3.org" Date: Mon, 16 Apr 2007 17:38:45 -0700 Subject: RE: [Ltru] Re: For review: Tagging text with no language Thread-Topic: [Ltru] Re: For review: Tagging text with no language Thread-Index: AceAWP9E1iqEkUGkTxWEtfVcBx60KgALRi9g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Let's look at a real use case. Would you say this page > is in "en" and "zxx" and that the sections of code > have no linguistic value even though they are clearly > intended to be read by humans and not machines? Or does > context matter? You're asking to have one tag that covers an entire document even though th= at document is mixed. What if I insert a quotation in Spanish in this mail?= =BFQue vamos a hacer? It's no different. If you must use a single tag for = the whole thing, then clearly this is predominantly in English. I don't kno= w what you'd do if it were closer to 50-50. > Interpreting "no linguistic content" as "not a human > language, could be a programming language" could cause > some problems. There may be a use case for programming > languages to have their own tag if this is deemed > appropriate for the 639 standards or IANA registry, and > these languages are different than say, instrumental > music in the Library of Congress or a sound effects > track in a film (both zxx, I'd say). Your argument is akin to someone saying that someone may want to code audio= in Unicode. ISO 639 has defined a scope, human languages. Programming lang= uages, electrical schematics, dance notation, bridge-hand notation, math fo= rmulas and engineering drawings are all graphic content that can be interpr= eted by humans. Some of these can be represented in text, but that does not= change the fact that they are not a form of the kind of things coded by IS= O 639, human languages. > I think programming languages have specific > identification and parsing needs and as such need to > be treated differently. As I suggested earlier, the scope defined by ISO 639 does not force RFC 464= 6bis to be limited to the same scope -- in fact, it cannot be. ("Language t= ags" already code things other than linguistic variety, written form in par= ticular.) So, if you want to propose variant subtags to differentiate progr= amming code from music notation, then I don't see why that couldn't be done= . But it would be out of scope for ISO 639 to code such a distinction, and it= would be a non-conforming re-interpretation to say that zxx does not apply= programming languages. > The code in the article above should be rendered in > Braille, for example, so it must be parsed. This makes > it different from non-linguistic content. You're confusing the language of content with the representation mode in so= me communicative technology. English content in Braille is still English, a= nd so clearly different from zxx. That is not in any way comparable to disc= ussing code in a programming language. > How would you classify the page I cite? As I mentioned above, this question is no different than asking how to come= up with one tag for a page that contains content in both English and Spani= sh. On a *practical* level, I would tag that article as en and ignore the f= act that it contains XML code snippets; but if someone was being careful to= tag elements within the document correctly, then the code snippets should = be tagged zxx. (That is, unless you want to register variant subtags to dif= ferentiate between different kinds of non-linguistic content.) Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 16 21:51: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 1HdcrL-00029e-8J; Mon, 16 Apr 2007 21:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdcrJ-00029Y-LR for ltru@lists.ietf.org; Mon, 16 Apr 2007 21:51:53 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdcrH-0006ww-Od for ltru@lists.ietf.org; Mon, 16 Apr 2007 21:51:53 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1625619nzf for ; Mon, 16 Apr 2007 18:51:51 -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=dyHKkul7wxe/GdTjcvojKjC0fW+5+uIAZVu5pE2teeGMCEOMUp30nVIrJSmeFTUzuAXAy73ryhMZbH/UsvIC7DzqeK1QOXjAhPU0C9QqEz2IcPVCaSGxmSv53QLCcv09If6OrWjJlMAk7Na24MAbc4QyHvkTxtNgc1rdi9zN5z8= 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=eGfMXDpOndvLVJd5jjgK0vtjQ//JWiy+knqRCM3dLOMrPU3tTcs7rDlWM0xSiMYzRRMkUzBoC8FP9rJsY33xt02VTvRtlSGbiWh7yYqPaQL8zYhIwRC9twVHLcSmcXpn5vib6KOuBuC6c+DIJInnyPztWy0YFAbmZhgWPHWS5LQ= Received: by 10.114.52.1 with SMTP id z1mr2178144waz.1176774710907; Mon, 16 Apr 2007 18:51:50 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 16 Apr 2007 18:51:50 -0700 (PDT) Message-ID: <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> Date: Mon, 16 Apr 2007 18:51:50 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> X-Google-Sender-Auth: 221fac246ae1598f X-Spam-Score: 0.1 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: "ietf-languages@iana.org" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067000330==" Errors-To: ltru-bounces@ietf.org --===============2067000330== Content-Type: multipart/alternative; boundary="----=_Part_65032_6558980.1176774710756" ------=_Part_65032_6558980.1176774710756 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline T24gNC8xNi8wNywgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90 ZToKPgo+ICBSZSAxOiBZZXMsIGJlIGNhcmVmdWw6IChhKSB0aGUgbWFqb3JpdHkgb2YgZXhpc3Rp bmcgbGVnYWN5IHVzYWdlIG9mIG1pcwo+IGlzIGJvdW5kIHRvIGJlIGluIE1BUkMsIGFuZCAoYikg YW55IGV4aXN0aW5nIHVzYWdlIHdvdWxkIGFzc3VtZSB0aGUgY29udGV4dAo+IG9mIElTTyA2Mzkt MiAoaS5lLiBtaXMgaW4gZXhpc3RpbmcgdXNhZ2UgaXMgdGhlIGV4Y2VwdGlvbiBsaXN0IGZvciBJ U08KPiA2MzktMikuCj4KPgo+Cj4gUmUgMjogVGhlIG1pcyBjb2xsZWN0aW9uIGlzIGluaGVyZW50 bHkgdW5zdGFibGUg4oCTIHVuYXZvaWRhYmx5IHNvLiBQcmlvciB0bwo+IDIwMDUtMDgtMTYsIGFu IGltcGxlbWVudGF0aW9uIG9mIElTTyA2MzktMiB3b3VsZCBoYXZlIHRhZ2dlZCBBaW51IGNvbnRl bnQgYXMKPiBtaXM7IGFmdGVyIHRoYXQgZGF0ZSwgYW4gaW1wbGVtZW50YXRpb24gb2YgSVNPIDYz OS0yIHdvdWxkIGhhdmUgdGFnZ2VkIEFpbnUKPiBjb250ZW50IGFzIGFpbjsgZXhpc3RpbmcgY29u dGVudCB0YWdnZWQgYmVmb3JlIHRoYXQgZGF0ZSB3b3VsZCBub3QgZ2V0Cj4gcmV0cmlldmVkIGJ5 IHJlcXVlc3QgZm9yIGFpbiwgYW5kIGl0IHdvdWxkIGJlIGNvbmZvcm1hbnQgdG8gc3VwcG9zZSB0 aGF0Cj4gcmVxdWVzdHMgZm9yIG1pcyB3b3VsZCBub3QgcmV0dXJuIEFpbnUgY29udGVudC4gVGhl IG1pcyBjb2xsZWN0aW9uIGlzIHVnbHksCj4gcHVyZSBhbmQgc2ltcGxlLiBTbywgSSBkb24ndCBz ZWUgd2hhdCB0aGUgcG9pbnQgaXMgb2YgZ2V0dGluZyB3b3JyaWVkIG92ZXIKPiB3aGV0aGVyIHdl J3JlIG1ha2luZyBtaXMgdW5zdGFibGU6IGl0J3MgYmVlbiB0aGF0IHdheSBmb3Igc29tZSB0aW1l Lgo+CgpXaGF0IEknbSBzYXlpbmcgaXMgdGhhdAoKICAgMS4gUmlnaHQgbm93IGluIElTTyA2Mzkt Miwgd2UgaGF2ZSBhIG51bWJlciBvZiBjb2xsZWN0aW9ucyBkZWZpbmVkIGJ5CiAgIGV4Y2x1c2lv biwgd2hlcmUgWFhYIChPdGhlcikgbWVhbnMgYW55IFhYWCB0aGF0IGlzIG5vdCBhbHJlYWR5IGRl ZmluZWQuIFRodXMKICAgImJhdCIgbWVhbnMgIkFueSBCYWx0aWMgbGFuZ3VhZ2UgdGhhdCBkb2Vz bid0IGFscmVhZHkgaGF2ZSBhIGNvZGUiLgogICAyLiBUaG9zZSBjb2xsZWN0aW9ucyBhcmUgaW5o ZXJlbnRseSB1bnN0YWJsZSBpbiBJU08gNjM5LTIsIHNpbmNlIHRoZXkKICAgY29udHJhY3QgZWFj aCB0aW1lIGEgbmV3IFhYWCBsYW5ndWFnZSBpcyBhZGRlZC4KICAgMy4gVGhlIHdheSB0byBtYWtl IGFuIGNvbGxlY3Rpb24gY29kZSBYWFggbm90IHVuc3RhYmxlIGlzIHRvIG1ha2UgaXQKICAgbm90 IGJlIG5vdCBkZWZpbmVkIGFzIGFuIGV4Y2x1c2lvbjogcmVtb3ZpbmcgdGhlIChPdGhlcikuIFt5 b3VyIHByb3Bvc2FsXQogICA0LiBUaGVuIFhYWCBpcyBzdGFibGUgaW50byB0aGUgZnV0dXJlLCBz aW5jZSBhZGRpbmcgYSBuZXcgbGFuZ3VhZ2Ugb2YKICAgdGhlIHR5cGUgWFhYIGRvZXNuJ3QgYWZm ZWN0IGl0LgogICA1LiBUaHVzIGlmIHdlIGNoYW5nZSAiYmF0IiBmcm9tIEJhbHRpYyAoT3RoZXIp IiBpbnRvICJCYWx0aWMiLCBtZWFuaW5nCiAgIGFueSBvZiB0aGUgQmFsdGljIGxhbmd1YWdlcywg aXQgYmVjb21lcyBzdGFibGUuCiAgIDYuIFN1Y2ggYSBjaGFuZ2UsIGJlaW5nIGEgYnJvYWRlbmlu ZywgY2FuIGJlIGNhcnJpZWQgaW50byBCQ1AgNDcuCiAgIDcuIFdlIGNhbiBhcHBseSB0aGUgc2Ft ZSBtZXRob2RvbG9neSB0byAibWlzIi4gVGhhdCB3b3VsZCBjaGFuZ2UgaXQKICAgZnJvbSB0aGUg ZmFpcmx5IHVzZWxlc3MgLS0gYW5kIHVuc3RhYmxlIC0tICJBbnkgTGFuZ3VhZ2Ugbm90IG90aGVy d2lzZQogICBlbmNvZGVkIiwgaW50byAiQW55IGxhbmd1YWdlIi4KICAgOC4gSXQgdGhlbiBiZWNv bWVzIHN0YWJsZSwgYW5kIHVzZWZ1bC4KCihOb3RlOiBtaXMgaXMgYmFkbHkgZGVmaW5lZCBmcm9t IGEgc3RhYmlsaXR5IHBlcnNwZWN0aXZlLCB0aG91Z2ggSSBkb24ndAo+IHRoaW5rIHRoZXJlJ3Mg bXVjaCBxdWVzdGlvbiBvZiBob3cgaXQncyBkZWZpbmVkLikKPgoKSSBhZ3JlZSB0aGF0IHRoYXQg aXMgbm90IHRoZSBjdXJyZW50IGRlZmluaXRpb24gb2YgIm1pcyIgKHNlZSBiZWxvdykuCgpSZSAz KGIpOiAiVGhlcmUgYXJlIHRpbWVzIHdoZW4gZGV0ZWN0aW9uIGNhbiBvbmx5IGRldGVybWluZSB0 aGF0IGl0IGxvb2tzCj4gbGlrZSB0aGVyZSBpcyBzb21lIGxpbmd1aXN0aWMgY29udGVudCAtLSBp dCBpcyBub3QganVzdCBiaW5hcnkgZGF0YSAtLSBidXQKPiBjdXJyZW50IGRldGVjdGlvbiBjYW4n dCByZWFsbHkgZGV0ZXJtaW5lIHdoYXQgaXQgbWlnaHQgYmUuIFRoYXQgaXMsIGEgY29kZQo+IHRo YXQgbWVhbnMgImFjY29yZGluZyB0byBvdXIgYmVzdCBhdmFpbGFibGUgZGV0ZWN0aW9uIG1ldGhv ZHMgdGhpcyBkb2Vzbid0Cj4gbG9vayBsaWtlIGl0IGlzIHp4eCIuIiBJZiB5b3Ugd2FudCB0byB1 c2UgbWlzIGZvciB0aGF0LCBJIHdvdWxkIGFyZ3VlIHRoYXQKPiB0aGF0IGlzIHNpZ25pZmljYW50 bHkgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiBtaXMuIChFdmVuIHRob3VnaCBtaXMgaXMKPiB1 bnN0YWJsZSwgaXQgaXMgdW5zdGFibGUgb24gYSBxdWFsaXRhdGl2ZSBsZXZlbDsgdGhpcyBpcyBh IGNhdGVnb3JpY2FsCj4gY2hhbmdlLikgSSBkZWZpbml0ZWx5IG9wcG9zZSB0aGF0LiBJZiB5b3Ug d2FudCBhbiBJRCBmb3IgInVuZGV0ZXJtaW5lZCBodW1hbgo+IGxhbmd1YWdlIiwgdGhlbiB0aGF0 IHNob3VsZCBiZSBwcm9wb3NlZC4gV2Ugc2hvdWxkIG5vdCB1c3VycCBhbiBleGlzdGluZyBJRAo+ IGZvciB0aGF0IHB1cnBvc2UuCj4KCkl0IGlzIGEgc2lnbmlmaWNhbnQgYnJvYWRlbmluZyBvZiB0 aGUgc2VtYW50aWNzLiBBbmQgSSdtIG5vdCBmaXhlZCBvbiB0aGF0LgpJdCBqdXN0IHNlZW1zIHRo YXQgZG9pbmcgdGhhdCBicm9hZGVuaW5nIGlzIGNvbmdydWVudCB3aXRoIHRoZSByZW1vdmFsIG9m CiIoT3RoZXIpIiB0aGF0IHlvdSd2ZSBwcm9wb3NlZCBpbiBvdGhlciBjYXNlcywgYW5kIHRyYW5z Zm9ybXMgYSB1c2VsZXNzIGFuZApkYW5nZXJvdXMgKGZvciBzdGFiaWxpdHkpIGNvZGUgaW50byBh IHVzZWZ1bCBjb2RlLiBBbmQgc2luY2UgaXQgaXMgYQpicm9hZGVuaW5nLCBpdCBpcyBjb25zaXN0 ZW50IHdpdGggQkNQIDQ3LgoKSG93ZXZlciwgaWYgdGhhdCBpcyB0b28gYmlnIGEgc3RlcCB0byBz dG9tYWNoLCB0aGUgYWx0ZXJuYXRpdmUgaXMgdG8Kc3Ryb25nbHkgcmVjb21tZW5kIHRoYXQgcGVv cGxlIG5ldmVyIHVzZSAibWlzIiwgYW5kIHByb3Bvc2UgYSBuZXcgY29kZSBmb3IKSVNPIDYzOS0y IHRoYXQgaGFzIHRoZSBtZWFuaW5nIG9mICJBbnkgbGFuZ3VhZ2UiLgoKUmUgNDogSSBkb24ndCBz ZWUgaG93IHlvdXIgZXhhbXBsZSBkaWZmZXJzIGZyb20gdGhpczogIk5vdXMgYXZvbnMgdW5lIHBo cmFzZQo+IGVuIGZyYW7Dp2FpcyAoYnV0IHRoaXMgaXMgaW4gRW5nbGlzaCkiLiBUaGUgZmFjdCB0 aGF0IHRoZSBwYXJlbnRoZXRpY2FsIHRleHQKPiBpcyBpbiBFbmdsaXNoIGRvZXNuJ3QgY2hhbmdl IHRoZSBmYWN0IHRoYXQgdGhlIG90aGVyIHRleHQgaXMgaW4gRnJlbmNoLgo+IFNpbWlsYXJseSwg aW4geW91ciBleGFtcGxlLCB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgY29tbWVudCBpbiBFbmds aXNoIGRvZXMKPiBub3QgY2hhbmdlIHRoZSBmYWN0IHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHRleHQg aXMgbm90IGluIGEgaHVtYW4gbGFuZ3VhZ2UuIERvCj4gd2UgY3JlYXRlIHRhZ3MgZm9yICJGcmVu Y2ggd2l0aCBlbWJlZGRlZCBiaXRzIG9mIEVuZ2xpc2giPwo+CgpZb3UgaGF2ZSBhIGdvb2QgcG9p bnQuIEFnYWluLCBJJ20gbm90IGhhcmQgYW5kIGZhc3QgYWJvdXQgdGhpcyBpc3N1ZSwgYnV0IEkK dGhpbmsgdGhlcmUgaXMgZGVmaW5pdGVseSBhIHNpZ25pZmljYW50IGRpc3RpbmN0aW9uIGluIHVz YWdlIGJldHdlZW4gInRoaXMKaXMgYSBjaHVuayBvZiBzdHVmZiB0aGF0IGxvb2tzIGxpa2UgcmFu ZG9tIGJpbmFyeSBkYXRhLCBsaWtlIGEgSlBFRyIsIGFuZAoidGhpcyBpcyBzdHVmZiB0aGF0IGxv b2tzIGxpa2UgaXQgbWlnaHQgYmUgd3JpdHRlbiBhIHByb2dyYW1taW5nIGxhbmd1YWdlLiIsCmEg ZGlzdGluY3Rpb24gdGhhdCBJIHRoaW5rIHdvdWxkIGJlIHVzZWZ1bCB0byBwcm92aWRlIGZvciBp biBCQ1AgNDcuIE9uIHRoZQpkZXRlY3Rpb24gZnJvbnQsIGl0IGlzIG11Y2ggZWFzaWVyIHRvIGRl dGVybWluZSAidGhpcyBpcyByYW5kb20gYmluYXJ5IiwKd2hpbGUgbm90IG5lY2Vzc2FyaWx5IHZl cnkgZWFzeSB0byBkZXRlcm1pbmUgInRoaXMgaXMgYSBwcm9ncmFtbWluZyBsYW5ndWFnZQpmcmFn bWVudCIuCgpQZXRlcgo+Cj4KPgo+ICpGcm9tOiogbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29t IFttYWlsdG86bWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tXSAqT24KPiBCZWhhbGYgT2YgKk1h cmsgRGF2aXMKPiAqU2VudDoqIE1vbmRheSwgQXByaWwgMTYsIDIwMDcgMzo0OSBQTQo+ICpUbzoq IFBldGVyIENvbnN0YWJsZQo+ICpDYzoqIGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnOyBsdHJ1QGxp c3RzLmlldGYub3JnCj4gKlN1YmplY3Q6KiBSZTogW0x0cnVdIFJlOiAibWlzIiB1cGRhdGUgcmV2 aWV3IHJlcXVlc3QKPgo+Cj4KPiAxLiBJIHRoaW5rIHdlIGhhdmUgdG8gYmUgdmVyeSBjYXJlZnVs IGhlcmUuIFRoZSBtZWFuaW5nIG9mIGEgc3RhbmRhcmQgbGlrZQo+IElTTyA2MzktMiBpcyBlc3Rh Ymxpc2hlZCBub3QgYnkgKndoYXQgd2Ugd2lzaCBpdCB3b3VsZCBoYXZlIHNhaWQsICpub3IgYnkK PiAqd2hhdCB3ZSB3b3VsZCBmaW5kIG91dCBpZiB3ZSB3ZXJlIGFibGUgdG8gcmVhZCBQZXRlcidz IG1pbmQuKiBJdCBpcwo+IGVzdGFibGlzaGVkIGJ5IHRoZSB3b3JkaW5nIGluIHRoZSBzdGFuZGFy ZCwgYW5kIGhvdyByZWFzb25hYmxlIHBlb3BsZSBjb3VsZAo+IGludGVycHJldCBpdC4gVGhlIGZh Y3QgdGhhdCAibWlzIiB3YXMgaW5jb3Jwb3JhdGVkIGluIG9yZGVyIHRvIGFjY291bnQgZm9yCj4g TUFSQyBjb2RlcyBpcyBpbnRlcmVzdGluZywgYnV0IGlzIG5vdCBpbiB0aGUgdGV4dCBvZiB0aGUg c3RhbmRhcmQuIFdlIGNhbid0Cj4gZXhwZWN0IHVzZXJzIG9mIEJDUCA0NyB0byBhbGwgYmUgYWJs ZSB0byByZWFkIFBldGVyJ3MgbWluZCBiZWZvcmUgdGFnZ2luZy4KPgo+IDIuIFdoZW4gd2UgYXJl IGxvb2tpbmcgYXQgc3RhYmlsaXR5LCB0aGF0IGlzIHZlcnkgaW1wb3J0YW50OiBvdXIgZ29hbCBp cwo+IHRoYXQgb25jZSBjb250ZW50IGlzIGNvcnJlY3RseSB0YWdnZWQsIHBlb3BsZSBjYW4gZGVw ZW5kIG9uIHRoZSBmYWN0IHRoYXQgd2UKPiB3aWxsIG5vdCBjaGFuZ2UgdGhlIG1lYW5pbmcgb2Yg YSB0YWcgb3V0IGZyb20gdW5kZXIgdGhlbS4gU28gY2xhcmlmaWNhdGlvbnMKPiB0aGF0IHdlIGFk ZCBpbiBmdXR1cmUgdmVyc2lvbnMgb2YgNDY0NiBvciB0aGUgcmVnaXN0cnkgYXJlIGZpbmUsIGFz IGxvbmcgYXMKPiB0aGV5IGRvIG5vdCBuYXJyb3cgdGhlIHJhbmdlIG9mIHJlYXNvbmFibGUgaW50 ZXJwcmV0YXRpb25zLiBXZSBjYW4gYnJvYWRlbgo+IHRoZW0uIFNvIGluIHRoZSBjYXNlIG9mICJt aXMiLCBhIHByb3Bvc2VkIG5hcnJvd2luZyB0byBpbmNsdWRlIGp1c3QgdGhlIE1BUkMKPiBjb2Rl cyBpcyBjbGVhcmx5IGRpc2FsbG93ZWQsIHNpbmNlIGl0IHdhcyBub3doZXJlIHN0YXRlZCBpbiBJ U08gNjM5LTIgYXQgdGhlCj4gdGltZSB0aGF0ICJtaXMiIHdhcyBhZGRlZCB0byB0aGUgbGFuZ3Vh Z2UgcmVnaXN0cnkgKHRoZSBCQ1AgNDcgc2VtYW50aWNzIGFyZQo+IGVzdGFibGlzaGVkIGF0IHRo ZSB0aW1lIHdlIGFkZCB0aGUgY29kZSkuIFRoYXQgaXMgb25lIG9mIHRoZSBrZXkgcHJpbmNpcGxl cwo+IG9mIEJDUCA0NywgaXMgdG8gaXNvbGF0ZSB1cyB3aGVyZSBuZWNlc3NhcnkgZnJvbSBpbnN0 YWJpbGl0aWVzIGluIHRoZSBzb3VyY2UKPiBzdGFuZGFyZHMuCj4KPiAoVGhlIG9uZSBleGNlcHRp b24gd2UgbWlnaHQgYmUgYWJsZSB0byBtYWtlIGlzIHdoZXJlIHNvbWV0aGluZyBpcyBzbyBiYWRs eQo+IGRlZmluZWQgdGhhdCBtb3N0IHJlYXNvbmFibGUgcGVvcGxlIGNvdWxkbid0IGNvbWUgdXAg d2l0aCBhbnkgY29uc2lzdGVudAo+IGRlZmluaXRpb24gZm9yIGl0LikKPgo+IDMuIE5vdywgSSB0 aGluayB0aGVyZSBhcmUgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gbWFrZSB0aGUgYWJvdmUg bW9vdC4KPiBJIHRoaW5rIFBldGVyJ3Mgc3VnZ2VzdGlvbiBmb3IgSVNPIDYzOS1YIG9mIGJyb2Fk ZW5pbmcgYWxsIG9mIHRoZQo+IENvbGxlY3Rpb25zIHRvIHJlbW92ZSB0aGUgKE90aGVyKSBpcyBl eGFjdGx5IHRoZSByaWdodCBzdHJhdGVneSwgYW5kIGlmIHRoaXMKPiBjYW4gYmUgZG9uZSBiZWZv cmUgNDY0NmJpcyBpcyBpc3N1ZWQsIGFsbCB0aGUgYmV0dGVyLiBTbyBoYXZpbmcKPgo+ICAgIC0g YXVzICAgIEF1c3RyYWxpYW4gbGFuZ3VhZ2VzIG1lYW5zIGFueSBvZiB0aGUgbGFuZ3VhZ2VzIG9u Cj4gICAgaHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9zaG93X2ZhbWlseS5hc3A/c3ViaWQ9OTA0 OTgKPiAgICAtIGJhdCAgICBCYWx0aWMgKE90aGVyKSA9PiBCYWx0aWMgbGFuZ3VhZ2VzLCBtZWFu cyBhbnkgb2YgdGhlCj4gICAgbGFuZ3VhZ2VzIG9uIGh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20v c2hvd19mYW1pbHkuYXNwP3N1YmlkPTkwMjA3Cj4gICAgLSBtaXMgICAgTWlzY2VsbGFuZW91cyBs YW5ndWFnZXMsIGVzc2VudGlhbGx5IHRoZSByb290IGZvcgo+ICAgIGh0dHA6Ly93d3cuZXRobm9s b2d1ZS5jb20vZmFtaWx5X2luZGV4LmFzcAo+Cj4gYW5kIHNvIG9uLiBUaGlzIGlzIHVzZWZ1bCBv biBhIG51bWJlciBvZiBsZXZlbHM7IGl0IHJlc29sdmVzIGEgbnVtYmVyIG9mCj4gcHJvYmxlbXMg aW4gdGhlIGludGVycHJldGF0aW9uIG9mIGxhbmd1YWdlIGNvZGVzLCBhbmQgbWFrZXMgdGhlIHNv dXJjZQo+IHN0YW5kYXJkcyB0aGVtc2VsdmVzIG1vcmUgc3RhYmxlLiAoSW4gdGhlIGlkZWFsIGNh c2UsIHdlIHdvdWxkIGhhdmUgY29kZXMKPiBmb3IgZWFjaCBvZiB0aGUgcG9zc2libGUgImRlY2lz aW9uIHBvaW50cyIgaW4gdGhlIGxhbmd1YWdlIHRyZWUuIFRoYXQgaXMsIGlmCj4gd2UgbG9vayBh dCBhbnkgbGFuZ3VhZ2UgY29kZSBzdWNoIGFzCj4gaHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9z aG93X2xhbmdfZmFtaWx5LmFzcD9jb2RlPWVuZyB3ZSdkIGhhdmUgY29kZXMKPiBmb3IgZWFjaCBv ZiB0aGUgcGFyZW50IGdyb3VwaW5ncywgbm90IGp1c3Qgc29tZSBvZiB0aGVtLCBsaWtlICJBdXN0 cmFsaWFuCj4gbGFuZ3VhZ2VzIi4pCj4KPiAzLiBSYW5keSByYWlzZWQgdGhlIGlzc3VlIGFzIHRv IHdoZXRoZXIgIm1pcyIgaW4gdGhlIGJyb2FkIHNlbnNlIGlzIHVzZWZ1bAo+IChhcyBzb21ldGhp bmcgdGhhdCBoYXMgbGluZ3Vpc3RpYyBjb250ZW50LCBidXQgSSBkb24ndCBrbm93IHdoYXQgaXQg aXMpLiBJdAo+IHZlcnkgbXVjaCBmb2xsb3dzIHRoZSBtb2RlbCBpbiAjMy4gVGhlcmUgYXJlIHRp bWVzIHdoZW4gZGV0ZWN0aW9uIGNhbiBvbmx5Cj4gZGV0ZXJtaW5lIHRoYXQgaXQgbG9va3MgbGlr ZSB0aGVyZSBpcyBzb21lIGxpbmd1aXN0aWMgY29udGVudCAtLSBpdCBpcyBub3QKPiBqdXN0IGJp bmFyeSBkYXRhIC0tIGJ1dCBjdXJyZW50IGRldGVjdGlvbiBjYW4ndCByZWFsbHkgZGV0ZXJtaW5l IHdoYXQgaXQKPiBtaWdodCBiZS4gVGhhdCBpcywgYSBjb2RlIHRoYXQgbWVhbnMgImFjY29yZGlu ZyB0byBvdXIgYmVzdCBhdmFpbGFibGUKPiBkZXRlY3Rpb24gbWV0aG9kcyB0aGlzIGRvZXNuJ3Qg bG9vayBsaWtlIGl0IGlzIHp4eCIuCj4KPiA0LiBJJ20gbGVlcnkgb2YgdXNpbmcgenh4IGZvciBw cm9ncmFtbWluZyBsYW5ndWFnZXMsIGluc3RlYWQgb2YganVzdAo+IGJpbmFyeS4gVGhlcmUgaXMg Y2xlYXJseSBzb21lIGxpbmd1aXN0aWMgY29udGVudCBpbiAiaWYgKGNvbnRlbnQgPT0gbnVsbCkg ewo+IC8qIHJlbW92ZSB0aGUgaXRlbSBpbiB0aGUgbG9va3VwIHRhYmxlICovIC4uLn0iLiBNYXli ZSB3ZSBuZWVkIGFub3RoZXIgY29kZQo+IGZvciB0aGlzLCBzb21ldGhpbmcgZGlmZmVyZW50IHRo YW4gZWl0aGVyICdhcnQnIG9yICd6eHgnLgo+Cj4gTWFyawo+Cj4gT24gNC8xNC8wNywgKlBldGVy IENvbnN0YWJsZSogPHBldGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gRnJvbTogUmFu ZHkgUHJlc3VobiBbbWFpbHRvOnJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb21dCj4KPgo+ID4g SSBmaW5kIGl0IHZlcnkgaGFyZCB0byBiZWxpZXZlIHRoYXQgYSByZWFzb25hYmxlIGFuYWx5c2lz Cj4gPiAod2hldGhlciBkb25lIGJ5IGh1bWFuIG9yIG1hY2hpbmUpIHdvdWxkIGNsYXNzaWZ5IGEg dGV4dCBhCj4gPiBiZWluZyAibWlzIiB3aXRob3V0IGJlaW5nIGFibGUgdG8gcmVjb2duaXplIHdo aWNoIG9mIHRoZQo+ID4gbGFuZ3VhZ2VzIGluIHRoYXQgZ3JvdXBpbmcgdGhlIHRleHQgYmVsb25n ZWQgdG8uICBJIGNhbgo+ID4gYmVsaWV2ZSBzb21lb25lIGNvdWxkIGxvb2sgYXQgdGV4dCBhbmQg c2F5ICJpdCdzIGEgc2xhdmljCj4gPiBsYW5ndWFnZSwgYnV0IEknbSBub3Qgc3VyZSB3aGljaCBv bmUuIiAgRG8gd2UgcmVhbGx5IHRoaW5rCj4gPiBzb21lb25lIG9yIHNvbWV0aGluZyB3b3VsZCBs b29rIGF0IHNvbWUgdGV4dCBhbmQgc2F5ICJpdCdzCj4gPiBBaW51LCBBbmRhbWFuZXNlLCBvciBF dHJ1c2NhbiwgYnV0IEkgY2FuJ3QgdGVsbCB3aGljaCwgc28KPiA+IEknbGwgdGFnIGl0ICdtaXMn Ij8KPgo+IElmIHNvbWVvbmUgd2VyZSBzbyB0ZW1wdGVkLCBJIHdvdWxkIGFyZ3VlIHRoYXQgd291 bGQgYmUgaW5hcHByb3ByaWF0ZSB1c2UKPiBvZiBtaXMuIFNpbmNlIHRoZXkgZG8gbm90IGtub3cg d2hhdCBpdCBpcywgdGhlaXIgZGVjbGFyYXRpb24gaXMgdGhhdCB0aGUKPiBsYW5ndWFnZSBpZGVu dGl0eSBpcyBub3QgZGV0ZXJtaW5lZCwgYW5kIHRoZSBhcHByb3ByaWF0ZSB0YWcgZm9yIHRoYXQg aXMKPiB1bmQuIEFwcHJvcHJpYXRlIHVzZSBvZiBtaXMgZG9lcyBub3QgcmVxdWlyZSB0aGF0IG9u ZSBrbm93IHRoZSBsYW5ndWFnZSBvZgo+IHRoZSBjb250ZW50OyBpdCBkb2VzLCBob3dldmVyLCBy ZXF1aXJlIHRoYXQgb25lIGtub3cgaXQgaXMgKm5vdCogYSBsYW5ndWFnZQo+IGNvdmVyZWQgYnkg YW55IG9mIHRoZSBhdmFpbGFibGUgdGFncy4KPgo+Cj4KPiBQZXRlcgo+Cj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+ IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1Cj4KPgo+Cj4KPiAtLQo+IE1hcmsKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cj4KCgotLSAKTWFy awo= ------=_Part_65032_6558980.1176774710756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNC8xNi8wNywgPGIgY2xh c3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBldGVyIENvbnN0YWJsZTwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJv cmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQg MHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4KCjxkaXY+Cgo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJlIDE6IFllcywgYmUgY2Fy ZWZ1bDogKGEpIHRoZSBtYWpvcml0eSBvZiBleGlzdGluZyBsZWdhY3kgdXNhZ2UKb2YgbWlzIGlz IGJvdW5kIHRvIGJlIGluIE1BUkMsIGFuZCAoYikgYW55IGV4aXN0aW5nIHVzYWdlIHdvdWxkIGFz c3VtZSB0aGUKY29udGV4dCBvZiBJU08gNjM5LTIgKGkuZS4gbWlzIGluIGV4aXN0aW5nIHVzYWdl IGlzIHRoZSBleGNlcHRpb24gbGlzdCBmb3IgSVNPCjYzOS0yKS48L3NwYW4+PC9wPgoKPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJz cDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij5SZSAyOiBUaGUgbWlzIGNvbGxlY3Rpb24gaXMgaW5oZXJlbnRseSB1 bnN0YWJsZSDigJMgdW5hdm9pZGFibHkKc28uIFByaW9yIHRvIDIwMDUtMDgtMTYsIGFuIGltcGxl bWVudGF0aW9uIG9mIElTTyA2MzktMiB3b3VsZCBoYXZlIHRhZ2dlZCBBaW51CmNvbnRlbnQgYXMg bWlzOyBhZnRlciB0aGF0IGRhdGUsIGFuIGltcGxlbWVudGF0aW9uIG9mIElTTyA2MzktMiB3b3Vs ZCBoYXZlCnRhZ2dlZCBBaW51IGNvbnRlbnQgYXMgYWluOyBleGlzdGluZyBjb250ZW50IHRhZ2dl ZCBiZWZvcmUgdGhhdCBkYXRlIHdvdWxkIG5vdApnZXQgcmV0cmlldmVkIGJ5IHJlcXVlc3QgZm9y IGFpbiwgYW5kIGl0IHdvdWxkIGJlIGNvbmZvcm1hbnQgdG8gc3VwcG9zZSB0aGF0CnJlcXVlc3Rz IGZvciBtaXMgd291bGQgbm90IHJldHVybiBBaW51IGNvbnRlbnQuIFRoZSBtaXMgY29sbGVjdGlv biBpcyB1Z2x5LApwdXJlIGFuZCBzaW1wbGUuIFNvLCBJIGRvbid0IHNlZSB3aGF0IHRoZSBwb2lu dCBpcyBvZiBnZXR0aW5nIHdvcnJpZWQKb3ZlciB3aGV0aGVyIHdlJ3JlIG1ha2luZyBtaXMgdW5z dGFibGU6IGl0J3MgYmVlbiB0aGF0IHdheSBmb3Igc29tZQp0aW1lLjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPldoYXQgSSYjMzk7bSBzYXlpbmcgaXMgdGhhdCA8 YnI+PG9sPjxsaT5SaWdodCBub3cgaW4gSVNPIDYzOS0yLCB3ZSBoYXZlIGEgbnVtYmVyIG9mIGNv bGxlY3Rpb25zIGRlZmluZWQgYnkgZXhjbHVzaW9uLCB3aGVyZSBYWFggKE90aGVyKSBtZWFucyBh bnkgWFhYIHRoYXQgaXMgbm90IGFscmVhZHkgZGVmaW5lZC4gVGh1cyAmcXVvdDtiYXQmcXVvdDsg bWVhbnMgJnF1b3Q7QW55IEJhbHRpYyBsYW5ndWFnZSB0aGF0IGRvZXNuJiMzOTt0IGFscmVhZHkg aGF2ZSBhIGNvZGUmcXVvdDsuCjxicj48L2xpPjxsaT5UaG9zZSBjb2xsZWN0aW9ucyBhcmUgaW5o ZXJlbnRseSB1bnN0YWJsZSBpbiBJU08gNjM5LTIsIHNpbmNlIHRoZXkgY29udHJhY3QgZWFjaCB0 aW1lIGEgbmV3IFhYWCBsYW5ndWFnZSBpcyBhZGRlZC48L2xpPjxsaT5UaGUgd2F5IHRvIG1ha2Ug YW4gY29sbGVjdGlvbiBjb2RlIFhYWCBub3QgdW5zdGFibGUgaXMgdG8gbWFrZSBpdCBub3QgYmUg bm90IGRlZmluZWQgYXMgYW4gZXhjbHVzaW9uOiByZW1vdmluZyB0aGUgKE90aGVyKS4gW3lvdXIg cHJvcG9zYWxdCjxicj48L2xpPjxsaT5UaGVuIFhYWCBpcyBzdGFibGUgaW50byB0aGUgZnV0dXJl LCBzaW5jZSBhZGRpbmcgYSBuZXcgbGFuZ3VhZ2Ugb2YgdGhlIHR5cGUgWFhYIGRvZXNuJiMzOTt0 IGFmZmVjdCBpdC48L2xpPjxsaT5UaHVzIGlmIHdlIGNoYW5nZSAmcXVvdDtiYXQmcXVvdDsgZnJv bSBCYWx0aWMgKE90aGVyKSZxdW90OyBpbnRvICZxdW90O0JhbHRpYyZxdW90OywgbWVhbmluZyBh bnkgb2YgdGhlIEJhbHRpYyBsYW5ndWFnZXMsIGl0IGJlY29tZXMgc3RhYmxlLgo8L2xpPjxsaT5T dWNoIGEgY2hhbmdlLCBiZWluZyBhIGJyb2FkZW5pbmcsIGNhbiBiZSBjYXJyaWVkIGludG8gQkNQ IDQ3Ljxicj48L2xpPjxsaT5XZSBjYW4gYXBwbHkgdGhlIHNhbWUgbWV0aG9kb2xvZ3kgdG8gJnF1 b3Q7bWlzJnF1b3Q7LiBUaGF0IHdvdWxkIGNoYW5nZSBpdCBmcm9tIHRoZSBmYWlybHkgdXNlbGVz cyAtLSBhbmQgdW5zdGFibGUgLS0gJnF1b3Q7QW55IExhbmd1YWdlIG5vdCBvdGhlcndpc2UgZW5j b2RlZCZxdW90OywgaW50byAmcXVvdDtBbnkgbGFuZ3VhZ2UmcXVvdDsuCjwvbGk+PGxpPkl0IHRo ZW4gYmVjb21lcyBzdGFibGUsIGFuZCB1c2VmdWwuPGJyPjwvbGk+PC9vbD48L2Rpdj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij48ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4KPGRp dj48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPihOb3RlOiBtaXMgaXMgYmFkbHkgZGVmaW5lZCBmcm9tIGEgc3RhYmlsaXR5IHBlcnNwZWN0 aXZlLCB0aG91Z2gKSSBkb24ndCB0aGluayB0aGVyZSdzIG11Y2ggcXVlc3Rpb24gb2YgaG93IGl0 J3MgZGVmaW5lZC4pPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ SSBhZ3JlZSB0aGF0IHRoYXQgaXMgbm90IHRoZSBjdXJyZW50IGRlZmluaXRpb24gb2YgJnF1b3Q7 bWlzJnF1b3Q7IChzZWUgYmVsb3cpLiA8YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy MDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2 IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj48ZGl2PjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+UmUgMyhiKTog Ijwvc3Bhbj5UaGVyZSBhcmUgdGltZXMgd2hlbiBkZXRlY3Rpb24gY2FuIG9ubHkKZGV0ZXJtaW5l IHRoYXQgaXQgbG9va3MgbGlrZSB0aGVyZSBpcyBzb21lIGxpbmd1aXN0aWMgY29udGVudCAtLSBp dCBpcyBub3QganVzdApiaW5hcnkgZGF0YSAtLSBidXQgY3VycmVudCBkZXRlY3Rpb24gY2FuJiMz OTt0IHJlYWxseSBkZXRlcm1pbmUgd2hhdCBpdCBtaWdodCBiZS4KVGhhdCBpcywgYSBjb2RlIHRo YXQgbWVhbnMgJnF1b3Q7YWNjb3JkaW5nIHRvIG91ciBiZXN0IGF2YWlsYWJsZSBkZXRlY3Rpb24K bWV0aG9kcyB0aGlzIGRvZXNuJiMzOTt0IGxvb2sgbGlrZSBpdCBpcyB6eHgmcXVvdDsuPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4iIElmIHlv dSB3YW50IHRvIHVzZQptaXMgZm9yIHRoYXQsIEkgd291bGQgYXJndWUgdGhhdCB0aGF0IGlzIHNp Z25pZmljYW50bHkgY2hhbmdpbmcgdGhlIHNlbWFudGljcwpvZiBtaXMuIChFdmVuIHRob3VnaCBt aXMgaXMgdW5zdGFibGUsIGl0IGlzIHVuc3RhYmxlIG9uIGEgcXVhbGl0YXRpdmUgbGV2ZWw7IHRo aXMKaXMgYSBjYXRlZ29yaWNhbCBjaGFuZ2UuKSBJIGRlZmluaXRlbHkgb3Bwb3NlIHRoYXQuIElm IHlvdSB3YW50IGFuIElEIGZvciAidW5kZXRlcm1pbmVkCmh1bWFuIGxhbmd1YWdlIiwgdGhlbiB0 aGF0IHNob3VsZCBiZSBwcm9wb3NlZC4gV2Ugc2hvdWxkIG5vdCB1c3VycCBhbgpleGlzdGluZyBJ RCBmb3IgdGhhdCBwdXJwb3NlLjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxk aXY+PGJyPkl0IGlzIGEgc2lnbmlmaWNhbnQgYnJvYWRlbmluZyBvZiB0aGUgc2VtYW50aWNzLiBB bmQgSSYjMzk7bSBub3QgZml4ZWQgb24gdGhhdC4gSXQganVzdCBzZWVtcyB0aGF0IGRvaW5nIHRo YXQgYnJvYWRlbmluZyBpcyBjb25ncnVlbnQgd2l0aCB0aGUgcmVtb3ZhbCBvZiAmcXVvdDsoT3Ro ZXIpJnF1b3Q7IHRoYXQgeW91JiMzOTt2ZSBwcm9wb3NlZCBpbiBvdGhlciBjYXNlcywgYW5kIHRy YW5zZm9ybXMgYSB1c2VsZXNzIGFuZCBkYW5nZXJvdXMgKGZvciBzdGFiaWxpdHkpIGNvZGUgaW50 byBhIHVzZWZ1bCBjb2RlLiBBbmQgc2luY2UgaXQgaXMgYSBicm9hZGVuaW5nLCBpdCBpcyBjb25z aXN0ZW50IHdpdGggQkNQIDQ3Lgo8YnI+PGJyPkhvd2V2ZXIsIGlmIHRoYXQgaXMgdG9vIGJpZyBh IHN0ZXAgdG8gc3RvbWFjaCwgdGhlIGFsdGVybmF0aXZlIGlzIHRvIHN0cm9uZ2x5IHJlY29tbWVu ZCB0aGF0IHBlb3BsZSBuZXZlciB1c2UgJnF1b3Q7bWlzJnF1b3Q7LCBhbmQgcHJvcG9zZSBhIG5l dyBjb2RlIGZvciBJU08gNjM5LTIgdGhhdCBoYXMgdGhlIG1lYW5pbmcgb2YgJnF1b3Q7QW55IGxh bmd1YWdlJnF1b3Q7Lgo8YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJn aW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPjxkaXYgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iRU4tVVMiPjxkaXY+PHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4KUmUgNDogSSBkb24ndCBzZWUg aG93IHlvdXIgZXhhbXBsZSBkaWZmZXJzIGZyb20gdGhpczogIk5vdXMKYXZvbnMgdW5lIHBocmFz ZSBlbiBmcmFuw6dhaXMgKGJ1dCB0aGlzIGlzIGluIEVuZ2xpc2gpIi4gVGhlIGZhY3QgdGhhdCB0 aGUKcGFyZW50aGV0aWNhbCB0ZXh0IGlzIGluIEVuZ2xpc2ggZG9lc24ndCBjaGFuZ2UgdGhlIGZh Y3QgdGhhdCB0aGUgb3RoZXIgdGV4dAppcyBpbiBGcmVuY2guIFNpbWlsYXJseSwgaW4geW91ciBl eGFtcGxlLCB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgY29tbWVudCBpbgpFbmdsaXNoIGRvZXMg bm90IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHRoZSByZXN0IG9mIHRoZSB0ZXh0IGlzIG5vdCBpbiBh IGh1bWFuCmxhbmd1YWdlLiBEbyB3ZSBjcmVhdGUgdGFncyBmb3IgIkZyZW5jaCB3aXRoIGVtYmVk ZGVkIGJpdHMgb2YgRW5nbGlzaCI/PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+ PGRpdj48YnI+WW91IGhhdmUgYSBnb29kIHBvaW50LiBBZ2FpbiwgSSYjMzk7bSBub3QgaGFyZCBh bmQgZmFzdCBhYm91dCB0aGlzIGlzc3VlLCBidXQgSSB0aGluayB0aGVyZSBpcyBkZWZpbml0ZWx5 IGEgc2lnbmlmaWNhbnQgZGlzdGluY3Rpb24gaW4gdXNhZ2UgYmV0d2VlbiAmcXVvdDt0aGlzIGlz IGEgY2h1bmsgb2Ygc3R1ZmYgdGhhdCBsb29rcyBsaWtlIHJhbmRvbSBiaW5hcnkgZGF0YSwgbGlr ZSBhIEpQRUcmcXVvdDssIGFuZCAmcXVvdDt0aGlzIGlzIHN0dWZmIHRoYXQgbG9va3MgbGlrZSBp dCBtaWdodCBiZSB3cml0dGVuIGEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UuJnF1b3Q7LCBhIGRpc3Rp bmN0aW9uIHRoYXQgSSB0aGluayB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSBmb3IgaW4gQkNQ IDQ3LiBPbiB0aGUgZGV0ZWN0aW9uIGZyb250LCBpdCBpcyBtdWNoIGVhc2llciB0byBkZXRlcm1p bmUgJnF1b3Q7dGhpcyBpcyByYW5kb20gYmluYXJ5JnF1b3Q7LCB3aGlsZSBub3QgbmVjZXNzYXJp bHkgdmVyeSBlYXN5IHRvIGRldGVybWluZSAmcXVvdDt0aGlzIGlzIGEgcHJvZ3JhbW1pbmcgbGFu Z3VhZ2UgZnJhZ21lbnQmcXVvdDsuCjxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIw NCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+PGRpdj48cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPgpQZXRlcjwvc3Bh bj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNv bGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMykgLW1vei11c2Ut dGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yOyBib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0g bWVkaXVtOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPgoKPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyI+CjxhIGhyZWY9Im1haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSI+bWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cm1hcmsuZWR3 YXJkLmRhdmlzQGdtYWlsLmNvbTwvYT5dIDxiPk9uIEJlaGFsZgpPZiA8L2I+TWFyayBEYXZpczxi cj4KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTYsIDIwMDcgMzo0OSBQTTxicj4KPGI+VG86 PC9iPiBQZXRlciBDb25zdGFibGU8YnI+CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlldGYt bGFuZ3VhZ2VzQGlhbmEub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5q cy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlldGYtbGFuZ3VhZ2VzQGlhbmEub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmx0cnVAbGlzdHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+ Cmx0cnVAbGlzdHMuaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9InEiPjxicj4KPGI+U3ViamVjdDo8 L2I+IFJlOiBbTHRydV0gUmU6ICZxdW90O21pcyZxdW90OyB1cGRhdGUgcmV2aWV3IHJlcXVlc3Q8 L3NwYW4+PC9zcGFuPjwvcD4KCjwvZGl2PgoKPHA+Jm5ic3A7PC9wPjxkaXY+PHNwYW4gY2xhc3M9 ImUiIGlkPSJxXzExMWZjZTdkNDBlZmEwNTVfMyI+Cgo8cD4xLiBJIHRoaW5rIHdlIGhhdmUgdG8g YmUgdmVyeSBjYXJlZnVsIGhlcmUuIFRoZSBtZWFuaW5nIG9mIGEKc3RhbmRhcmQgbGlrZSBJU08g NjM5LTIgaXMgZXN0YWJsaXNoZWQgbm90IGJ5IDxpPndoYXQgd2Ugd2lzaCBpdCB3b3VsZCBoYXZl CnNhaWQsIDwvaT5ub3IgYnkgPGk+d2hhdCB3ZSB3b3VsZCBmaW5kIG91dCBpZiB3ZSB3ZXJlIGFi bGUgdG8gcmVhZCBQZXRlciYjMzk7cwptaW5kLjwvaT4gSXQgaXMgZXN0YWJsaXNoZWQgYnkgdGhl IHdvcmRpbmcgaW4gdGhlIHN0YW5kYXJkLCBhbmQgaG93IHJlYXNvbmFibGUKcGVvcGxlIGNvdWxk IGludGVycHJldCBpdC4gVGhlIGZhY3QgdGhhdCAmcXVvdDttaXMmcXVvdDsgd2FzIGluY29ycG9y YXRlZCBpbgpvcmRlciB0byBhY2NvdW50IGZvciBNQVJDIGNvZGVzIGlzIGludGVyZXN0aW5nLCBi dXQgaXMgbm90IGluIHRoZSB0ZXh0IG9mIHRoZQpzdGFuZGFyZC4gV2UgY2FuJiMzOTt0IGV4cGVj dCB1c2VycyBvZiBCQ1AgNDcgdG8gYWxsIGJlIGFibGUgdG8gcmVhZCBQZXRlciYjMzk7cyBtaW5k CmJlZm9yZSB0YWdnaW5nLiA8YnI+Cjxicj4KMi4gV2hlbiB3ZSBhcmUgbG9va2luZyBhdCBzdGFi aWxpdHksIHRoYXQgaXMgdmVyeSBpbXBvcnRhbnQ6IG91ciBnb2FsIGlzIHRoYXQKb25jZSBjb250 ZW50IGlzIGNvcnJlY3RseSB0YWdnZWQsIHBlb3BsZSBjYW4gZGVwZW5kIG9uIHRoZSBmYWN0IHRo YXQgd2Ugd2lsbApub3QgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIGEgdGFnIG91dCBmcm9tIHVuZGVy IHRoZW0uIFNvIGNsYXJpZmljYXRpb25zIHRoYXQgd2UKYWRkIGluIGZ1dHVyZSB2ZXJzaW9ucyBv ZiA0NjQ2IG9yIHRoZSByZWdpc3RyeSBhcmUgZmluZSwgYXMgbG9uZyBhcyB0aGV5IGRvIG5vdApu YXJyb3cgdGhlIHJhbmdlIG9mIHJlYXNvbmFibGUgaW50ZXJwcmV0YXRpb25zLiBXZSBjYW4gYnJv YWRlbiB0aGVtLiBTbyBpbiB0aGUKY2FzZSBvZiAmcXVvdDttaXMmcXVvdDssIGEgcHJvcG9zZWQg bmFycm93aW5nIHRvIGluY2x1ZGUganVzdCB0aGUgTUFSQyBjb2RlcyBpcwpjbGVhcmx5IGRpc2Fs bG93ZWQsIHNpbmNlIGl0IHdhcyBub3doZXJlIHN0YXRlZCBpbiBJU08gNjM5LTIgYXQgdGhlIHRp bWUgdGhhdAomcXVvdDttaXMmcXVvdDsgd2FzIGFkZGVkIHRvIHRoZSBsYW5ndWFnZSByZWdpc3Ry eSAodGhlIEJDUCA0NyBzZW1hbnRpY3MgYXJlCmVzdGFibGlzaGVkIGF0IHRoZSB0aW1lIHdlIGFk ZCB0aGUgY29kZSkuIFRoYXQgaXMgb25lIG9mIHRoZSBrZXkgcHJpbmNpcGxlcyBvZgpCQ1AgNDcs IGlzIHRvIGlzb2xhdGUgdXMgd2hlcmUgbmVjZXNzYXJ5IGZyb20gaW5zdGFiaWxpdGllcyBpbiB0 aGUgc291cmNlCnN0YW5kYXJkcy4gPGJyPgo8YnI+CihUaGUgb25lIGV4Y2VwdGlvbiB3ZSBtaWdo dCBiZSBhYmxlIHRvIG1ha2UgaXMgd2hlcmUgc29tZXRoaW5nIGlzIHNvIGJhZGx5CmRlZmluZWQg dGhhdCBtb3N0IHJlYXNvbmFibGUgcGVvcGxlIGNvdWxkbiYjMzk7dCBjb21lIHVwIHdpdGggYW55 IGNvbnNpc3RlbnQKZGVmaW5pdGlvbiBmb3IgaXQuKTxicj4KPGJyPgozLiBOb3csIEkgdGhpbmsg dGhlcmUgYXJlIHN0ZXBzIHRoYXQgY2FuIGJlIHRha2VuIHRvIG1ha2UgdGhlIGFib3ZlIG1vb3Qu IEkKdGhpbmsgUGV0ZXImIzM5O3Mgc3VnZ2VzdGlvbiBmb3IgSVNPIDYzOS1YIG9mIGJyb2FkZW5p bmcgYWxsIG9mIHRoZSBDb2xsZWN0aW9ucyB0bwpyZW1vdmUgdGhlIChPdGhlcikgaXMgZXhhY3Rs eSB0aGUgcmlnaHQgc3RyYXRlZ3ksIGFuZCBpZiB0aGlzIGNhbiBiZSBkb25lCmJlZm9yZSA0NjQ2 YmlzIGlzIGlzc3VlZCwgYWxsIHRoZSBiZXR0ZXIuIFNvIGhhdmluZyA8L3A+Cgo8dWwgdHlwZT0i ZGlzYyI+CiA8bGk+YXVzJm5ic3A7Jm5ic3A7Jm5ic3A7IEF1c3RyYWxpYW4gbGFuZ3VhZ2VzIG1l YW5zCiAgICAgYW55IG9mIHRoZSBsYW5ndWFnZXMgb24gPGEgaHJlZj0iaHR0cDovL3d3dy5ldGhu b2xvZ3VlLmNvbS9zaG93X2ZhbWlseS5hc3A/c3ViaWQ9OTA0OTgiIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0 cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9zaG93X2ZhbWlseS5hc3A/c3ViaWQ9OTA0OTg8L2E+Cjwv bGk+CiA8bGk+YmF0Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhbHRpYyAoT3RoZXIpID0mZ3Q7IEJhbHRp YwogICAgIGxhbmd1YWdlcywgbWVhbnMgYW55IG9mIHRoZSBsYW5ndWFnZXMgb24gPGEgaHJlZj0i aHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9zaG93X2ZhbWlseS5hc3A/c3ViaWQ9OTAyMDciIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+aHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9zaG93X2ZhbWlseS5hc3A/c3Vi aWQ9OTAyMDcKPC9hPjwvbGk+CiA8bGk+bWlzJm5ic3A7Jm5ic3A7Jm5ic3A7IE1pc2NlbGxhbmVv dXMgbGFuZ3VhZ2VzLAogICAgIGVzc2VudGlhbGx5IHRoZSByb290IGZvciA8YSBocmVmPSJodHRw Oi8vd3d3LmV0aG5vbG9ndWUuY29tL2ZhbWlseV9pbmRleC5hc3AiIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0 cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9mYW1pbHlfaW5kZXguYXNwPC9hPjwvbGk+CjwvdWw+Cgo8 cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPmFuZCBzbyBvbi4gVGhpcyBpcyB1c2VmdWwg b24gYQpudW1iZXIgb2YgbGV2ZWxzOyBpdCByZXNvbHZlcyBhIG51bWJlciBvZiBwcm9ibGVtcyBp biB0aGUgaW50ZXJwcmV0YXRpb24gb2YKbGFuZ3VhZ2UgY29kZXMsIGFuZCBtYWtlcyB0aGUgc291 cmNlIHN0YW5kYXJkcyB0aGVtc2VsdmVzIG1vcmUgc3RhYmxlLiAoSW4gdGhlCmlkZWFsIGNhc2Us IHdlIHdvdWxkIGhhdmUgY29kZXMgZm9yIGVhY2ggb2YgdGhlIHBvc3NpYmxlICZxdW90O2RlY2lz aW9uIHBvaW50cyZxdW90OwppbiB0aGUgbGFuZ3VhZ2UgdHJlZS4gVGhhdCBpcywgaWYgd2UgbG9v ayBhdCBhbnkgbGFuZ3VhZ2UgY29kZSBzdWNoIGFzIDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRobm9s b2d1ZS5jb20vc2hvd19sYW5nX2ZhbWlseS5hc3A/Y29kZT1lbmciIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0 cDovL3d3dy5ldGhub2xvZ3VlLmNvbS9zaG93X2xhbmdfZmFtaWx5LmFzcD9jb2RlPWVuZwo8L2E+ CndlJiMzOTtkIGhhdmUgY29kZXMgZm9yIGVhY2ggb2YgdGhlIHBhcmVudCBncm91cGluZ3MsIG5v dCBqdXN0IHNvbWUgb2YgdGhlbSwgbGlrZQomcXVvdDtBdXN0cmFsaWFuIGxhbmd1YWdlcyZxdW90 Oy4pIDxicj4KPGJyPgozLiBSYW5keSByYWlzZWQgdGhlIGlzc3VlIGFzIHRvIHdoZXRoZXIgJnF1 b3Q7bWlzJnF1b3Q7IGluIHRoZSBicm9hZCBzZW5zZSBpcwp1c2VmdWwgKGFzIHNvbWV0aGluZyB0 aGF0IGhhcyBsaW5ndWlzdGljIGNvbnRlbnQsIGJ1dCBJIGRvbiYjMzk7dCBrbm93IHdoYXQgaXQg aXMpLgpJdCB2ZXJ5IG11Y2ggZm9sbG93cyB0aGUgbW9kZWwgaW4gIzMuIFRoZXJlIGFyZSB0aW1l cyB3aGVuIGRldGVjdGlvbiBjYW4gb25seQpkZXRlcm1pbmUgdGhhdCBpdCBsb29rcyBsaWtlIHRo ZXJlIGlzIHNvbWUgbGluZ3Vpc3RpYyBjb250ZW50IC0tIGl0IGlzIG5vdCBqdXN0CmJpbmFyeSBk YXRhIC0tIGJ1dCBjdXJyZW50IGRldGVjdGlvbiBjYW4mIzM5O3QgcmVhbGx5IGRldGVybWluZSB3 aGF0IGl0IG1pZ2h0IGJlLgpUaGF0IGlzLCBhIGNvZGUgdGhhdCBtZWFucyAmcXVvdDthY2NvcmRp bmcgdG8gb3VyIGJlc3QgYXZhaWxhYmxlIGRldGVjdGlvbgptZXRob2RzIHRoaXMgZG9lc24mIzM5 O3QgbG9vayBsaWtlIGl0IGlzIHp4eCZxdW90Oy4gPGJyPgo8YnI+CjQuIEkmIzM5O20gbGVlcnkg b2YgdXNpbmcgenh4IGZvciBwcm9ncmFtbWluZyBsYW5ndWFnZXMsIGluc3RlYWQgb2YganVzdCBi aW5hcnkuClRoZXJlIGlzIGNsZWFybHkgc29tZSBsaW5ndWlzdGljIGNvbnRlbnQgaW4gJnF1b3Q7 aWYgKGNvbnRlbnQgPT0gbnVsbCkgeyAvKgpyZW1vdmUgdGhlIGl0ZW0gaW4gdGhlIGxvb2t1cCB0 YWJsZSAqLyAuLi59JnF1b3Q7LiBNYXliZSB3ZSBuZWVkIGFub3RoZXIgY29kZQpmb3IgdGhpcywg c29tZXRoaW5nIGRpZmZlcmVudCB0aGFuIGVpdGhlciAmIzM5O2FydCYjMzk7IG9yICYjMzk7enh4 JiMzOTsuIDxicj4KPGJyPgpNYXJrPC9wPgoKPGRpdj4KCjxwPjxzcGFuPk9uIDQvMTQvMDcsIDxi PlBldGVyIENvbnN0YWJsZTwvYj4KJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlcmNvbkBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiPnBldGVyY29uQG1pY3Jvc29mdC5jb208L2E+Jmd0Owp3cm90 ZTo8L3NwYW4+PC9wPgoKPHA+RnJvbTogUmFuZHkgUHJlc3VobiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnJhbmR5X3By ZXN1aG5AbWluZHNwcmluZy5jb208L2E+XTxicj4KPGJyPgo8YnI+CiZndDsgSSBmaW5kIGl0IHZl cnkgaGFyZCB0byBiZWxpZXZlIHRoYXQgYSByZWFzb25hYmxlIGFuYWx5c2lzPGJyPgomZ3Q7ICh3 aGV0aGVyIGRvbmUgYnkgaHVtYW4gb3IgbWFjaGluZSkgd291bGQgY2xhc3NpZnkgYSB0ZXh0IGEg PGJyPgomZ3Q7IGJlaW5nICZxdW90O21pcyZxdW90OyB3aXRob3V0IGJlaW5nIGFibGUgdG8gcmVj b2duaXplIHdoaWNoIG9mIHRoZTxicj4KJmd0OyBsYW5ndWFnZXMgaW4gdGhhdCBncm91cGluZyB0 aGUgdGV4dCBiZWxvbmdlZCB0by4mbmJzcDsmbmJzcDtJIGNhbjxicj4KJmd0OyBiZWxpZXZlIHNv bWVvbmUgY291bGQgbG9vayBhdCB0ZXh0IGFuZCBzYXkgJnF1b3Q7aXQmIzM5O3MgYSBzbGF2aWM8 YnI+CiZndDsgbGFuZ3VhZ2UsIGJ1dCBJJiMzOTttIG5vdCBzdXJlIHdoaWNoIG9uZS4mcXVvdDsm bmJzcDsmbmJzcDtEbyB3ZSByZWFsbHkgdGhpbmsgPGJyPgomZ3Q7IHNvbWVvbmUgb3Igc29tZXRo aW5nIHdvdWxkIGxvb2sgYXQgc29tZSB0ZXh0IGFuZCBzYXkgJnF1b3Q7aXQmIzM5O3M8YnI+CiZn dDsgQWludSwgQW5kYW1hbmVzZSwgb3IgRXRydXNjYW4sIGJ1dCBJIGNhbiYjMzk7dCB0ZWxsIHdo aWNoLCBzbzxicj4KJmd0OyBJJiMzOTtsbCB0YWcgaXQgJiMzOTttaXMmIzM5OyZxdW90Oz88YnI+ Cjxicj4KSWYgc29tZW9uZSB3ZXJlIHNvIHRlbXB0ZWQsIEkgd291bGQgYXJndWUgdGhhdCB3b3Vs ZCBiZSBpbmFwcHJvcHJpYXRlIHVzZSBvZgptaXMuIFNpbmNlIHRoZXkgZG8gbm90IGtub3cgd2hh dCBpdCBpcywgdGhlaXIgZGVjbGFyYXRpb24gaXMgdGhhdCB0aGUgbGFuZ3VhZ2UKaWRlbnRpdHkg aXMgbm90IGRldGVybWluZWQsIGFuZCB0aGUgYXBwcm9wcmlhdGUgdGFnIGZvciB0aGF0IGlzIHVu ZC4KQXBwcm9wcmlhdGUgdXNlIG9mIG1pcyBkb2VzIG5vdCByZXF1aXJlIHRoYXQgb25lIGtub3cg dGhlIGxhbmd1YWdlIG9mIHRoZQpjb250ZW50OyBpdCBkb2VzLCBob3dldmVyLCByZXF1aXJlIHRo YXQgb25lIGtub3cgaXQgaXMgKm5vdCogYSBsYW5ndWFnZSBjb3ZlcmVkCmJ5IGFueSBvZiB0aGUg YXZhaWxhYmxlIHRhZ3MuIDxicj4KPGJyPgo8YnI+Cjxicj4KUGV0ZXI8YnI+Cjxicj4KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Ckx0cnUgbWFpbGlu ZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5M dHJ1QGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1CjwvYT48L3A+Cgo8L2Rpdj4KCjxwPjxicj4KPGJyIGNsZWFyPSJh bGwiPgo8YnI+Ci0tIDxicj4KTWFyayA8L3A+Cgo8L3NwYW4+PC9kaXY+PC9kaXY+Cgo8L2Rpdj4K Cgo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ THRydSBtYWlsaW5nIGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGll dGYub3JnPC9hPjxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPgpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sdHJ1PC9hPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9 ImFsbCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_65032_6558980.1176774710756-- --===============2067000330== 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 --===============2067000330==-- From ltru-bounces@ietf.org Mon Apr 16 22:47: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 1HddjE-0003Sn-Ff; Mon, 16 Apr 2007 22:47:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddjD-0003Si-B9 for ltru@lists.ietf.org; Mon, 16 Apr 2007 22:47:35 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HddjA-00022b-QD for ltru@lists.ietf.org; Mon, 16 Apr 2007 22:47:35 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 19:47:32 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 16 Apr 2007 19:47:31 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Mon, 16 Apr 2007 19:47:29 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAkvju+7INaJZRSKiSOC8zd0aN7QABeGiA Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> In-Reply-To: <30b660a20704161851j4ac4d394r5f303aa33e0720b1@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: 1.3 (+) X-Scan-Signature: 4aebf168d9e8ffd581566781707b1a5b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2035987592==" Errors-To: ltru-bounces@ietf.org --===============2035987592== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB5E4NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB5E4NAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I get - and agree with - what you're saying about changing things like bat = from "Baltic (Other)" to "Baltic Languages". But to change mis from its cur= rent intensional meaning to "any language" is not just broadening - it's to= change it into something completely different altogether. It could appropr= iately be named "Other Languages" - and getting rid of "other" changes it u= tterly. It is one case where getting rid of the "other" aspect is not appro= priate because that is *the* defining criterion of the concept it represent= s. I would have little difficulty with the idea that we tell people not to use= mis. (Naturally -- again, at some point I suggested we not even allow coll= ections of any kind in IETF tags.) We could deprecate it in the registry, o= r put a clear SHOULD NOT (if we think just maybe there are some application= scenarios in which informed and consenting adults might have a reasonable = use for it). I'd have no problem with a request to the ISO 639 JAC for a special-case ID= for "any language" or "some unspecified language". (We'd need to clarify f= or them the difference between this and und - which may or may not actually= be a human language.) For programming languages, I think a zxx variant would be a reasonable solu= tion. Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, April 16, 2007 6:52 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request On 4/16/07, Peter Constable > wrote: Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis is = bound to be in MARC, and (b) any existing usage would assume the context of= ISO 639-2 (i.e. mis in existing usage is the exception list for ISO 639-2)= . Re 2: The mis collection is inherently unstable - unavoidably so. Prior to = 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content a= s mis; after that date, an implementation of ISO 639-2 would have tagged Ai= nu content as ain; existing content tagged before that date would not get r= etrieved by request for ain, and it would be conformant to suppose that req= uests for mis would not return Ainu content. The mis collection is ugly, pu= re and simple. So, I don't see what the point is of getting worried over wh= ether we're making mis unstable: it's been that way for some time. What I'm saying is that 1. Right now in ISO 639-2, we have a number of collections defined by exc= lusion, where XXX (Other) means any XXX that is not already defined. Thus "= bat" means "Any Baltic language that doesn't already have a code". 2. Those collections are inherently unstable in ISO 639-2, since they con= tract each time a new XXX language is added. 3. The way to make an collection code XXX not unstable is to make it not = be not defined as an exclusion: removing the (Other). [your proposal] 4. Then XXX is stable into the future, since adding a new language of the= type XXX doesn't affect it. 5. Thus if we change "bat" from Baltic (Other)" into "Baltic", meaning an= y of the Baltic languages, it becomes stable. 6. Such a change, being a broadening, can be carried into BCP 47. 7. We can apply the same methodology to "mis". That would change it from = the fairly useless -- and unstable -- "Any Language not otherwise encoded",= into "Any language". 8. It then becomes stable, and useful. (Note: mis is badly defined from a stability perspective, though I don't th= ink there's much question of how it's defined.) I agree that that is not the current definition of "mis" (see below). Re 3(b): "There are times when detection can only determine that it looks l= ike there is some linguistic content -- it is not just binary data -- but c= urrent detection can't really determine what it might be. That is, a code t= hat means "according to our best available detection methods this doesn't l= ook like it is zxx"." If you want to use mis for that, I would argue that t= hat is significantly changing the semantics of mis. (Even though mis is uns= table, it is unstable on a qualitative level; this is a categorical change.= ) I definitely oppose that. If you want an ID for "undetermined human langu= age", then that should be proposed. We should not usurp an existing ID for = that purpose. It is a significant broadening of the semantics. And I'm not fixed on that.= It just seems that doing that broadening is congruent with the removal of = "(Other)" that you've proposed in other cases, and transforms a useless and= dangerous (for stability) code into a useful code. And since it is a broad= ening, it is consistent with BCP 47. However, if that is too big a step to stomach, the alternative is to strong= ly recommend that people never use "mis", and propose a new code for ISO 63= 9-2 that has the meaning of "Any language". Re 4: I don't see how your example differs from this: "Nous avons une phras= e en fran=E7ais (but this is in English)". The fact that the parenthetical = text is in English doesn't change the fact that the other text is in French= . Similarly, in your example, the fact that there is a comment in English d= oes not change the fact that the rest of the text is not in a human languag= e. Do we create tags for "French with embedded bits of English"? You have a good point. Again, I'm not hard and fast about this issue, but I= think there is definitely a significant distinction in usage between "this= is a chunk of stuff that looks like random binary data, like a JPEG", and = "this is stuff that looks like it might be written a programming language."= , a distinction that I think would be useful to provide for in BCP 47. On t= he detection front, it is much easier to determine "this is random binary",= while not necessarily very easy to determine "this is a programming langua= ge fragment". Peter From: mark.edward.davis@gmail.com [mail= to: mark.edward.davis@gmail.com] On Beh= alf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.iet= f.org Subject: Re: [Ltru] Re: "mis" update review request 1. I think we have to be very careful here. The meaning of a standard like = ISO 639-2 is established not by what we wish it would have said, nor by wha= t we would find out if we were able to read Peter's mind. It is established= by the wording in the standard, and how reasonable people could interpret = it. The fact that "mis" was incorporated in order to account for MARC codes= is interesting, but is not in the text of the standard. We can't expect us= ers of BCP 47 to all be able to read Peter's mind before tagging. 2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we = will not change the meaning of a tag out from under them. So clarifications= that we add in future versions of 4646 or the registry are fine, as long a= s they do not narrow the range of reasonable interpretations. We can broade= n them. So in the case of "mis", a proposed narrowing to include just the M= ARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 a= t the time that "mis" was added to the language registry (the BCP 47 semant= ics are established at the time we add the code). That is one of the key pr= inciples of BCP 47, is to isolate us where necessary from instabilities in = the source standards. (The one exception we might be able to make is where something is so badly = defined that most reasonable people couldn't come up with any consistent de= finition for it.) 3. Now, I think there are steps that can be taken to make the above moot. I= think Peter's suggestion for ISO 639-X of broadening all of the Collection= s to remove the (Other) is exactly the right strategy, and if this can be d= one before 4646bis is issued, all the better. So having * aus Australian languages means any of the languages on http://www.e= thnologue.com/show_family.asp?subid=3D90498 * bat Baltic (Other) =3D> Baltic languages, means any of the language= s on http://www.ethnologue.com/show_family.asp?subid=3D90207 * mis Miscellaneous languages, essentially the root for http://www.et= hnologue.com/family_index.asp and so on. This is useful on a number of levels; it resolves a number of pr= oblems in the interpretation of language codes, and makes the source standa= rds themselves more stable. (In the ideal case, we would have codes for eac= h of the possible "decision points" in the language tree. That is, if we lo= ok at any language code such as http://www.ethnologue.com/show_lang_family.= asp?code=3Deng we'd have codes for each of the parent groupings, not just s= ome of them, like "Australian languages".) 3. Randy raised the issue as to whether "mis" in the broad sense is useful = (as something that has linguistic content, but I don't know what it is). It= very much follows the model in #3. There are times when detection can only= determine that it looks like there is some linguistic content -- it is not= just binary data -- but current detection can't really determine what it m= ight be. That is, a code that means "according to our best available detect= ion methods this doesn't look like it is zxx". 4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) { /= * remove the item in the lookup table */ ...}". Maybe we need another code = for this, something different than either 'art' or 'zxx'. Mark On 4/14/07, Peter Constable > wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the lan= guage identity is not determined, and the appropriate tag for that is und. = Appropriate use of mis does not require that one know the language of the c= ontent; it does, however, require that one know it is *not* a language cove= red by any of the available tags. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB5E4NAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I get – and agree with – what you’re sayin= g about changing things like bat from “Baltic (Other)” to “= Baltic Languages”. But to change mis from its current intensional meaning to= “any language” is not just broadening – it’s to change it into something completely different altogether. It could appropriately be named = “Other Languages” – and getting rid of “other” changes it utterly. It is one case where getting rid of the “other” aspect= is not appropriate because that is *the* defining criterion of the conc= ept it represents.

 

I would have little difficulty with the idea that we tell pe= ople not to use mis. (Naturally -- again, at some point I suggested we not even allow collections of any kind in IETF tags.) We could deprecate it in the registry, or put a clear SHOULD NOT (if we think just maybe there are some application scenarios in which informed and consenting adults might have a reasonable use for it).

 

I’d have no problem with a request to the ISO 639 JAC = for a special-case ID for “any language” or “some unspecified language”. (We’d need to clarify for them the difference betwee= n this and und – which may or may not actually be a human language.)

 

For programming languages, I think a zxx variant would be a reasonable solution.

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, April 16, 2007 6:52 PM
To: Peter Constable
Cc: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update review request

 

 

On 4/16/07, Peter Constabl= e <petercon@microsoft.com>= ; wrote:

Re 1: Yes, be careful: (a= ) the majority of existing legacy usage of mis is bound to be in MARC, and (b) an= y existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the exception list for ISO 639-2).

 <= /p>

Re 2: The mis collection = is inherently unstable – unavoidably so. Prior to 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content as mis; after th= at date, an implementation of ISO 639-2 would have tagged Ainu content as ain; existing content tagged before that date would not get retrieved by request= for ain, and it would be conformant to suppose that requests for mis would not return Ainu content. The mis collection is ugly, pure and simple. So, I don= 't see what the point is of getting worried over whether we're making mis unstable: it's been that way for some time.


What I'm saying is that

  1. Right now in ISO 639-2, we have a number of collections defined by exclusion, where XXX (Other) means any XXX that= is not already defined. Thus "bat" means "Any Baltic langu= age that doesn't already have a code".
  2. Those collections are inherently unstable in = ISO 639-2, since they contract each time a new XXX language is added.=
  3. The way to make an collection code XXX not unstable is to make it not be not defined as an exclusion: removing th= e (Other). [your proposal]
  4. Then XXX is stable into the future, since add= ing a new language of the type XXX doesn't affect it.
  5. Thus if we change "bat" from Baltic (Other)" into "Baltic", meaning any of the Baltic languages, it becomes stable.
  6. Such a change, being a broadening, can be car= ried into BCP 47.
  7. We can apply the same methodology to "mis". That would change it from the fairly useless -- and unstable -- "Any Language not otherwise encoded", into "= ;Any language".
  8. It then becomes stable, and useful.

(Note: mis is badly defin= ed from a stability perspective, though I don't think there's much question of= how it's defined.)


I agree that that is not the current definition of "mis" (see bel= ow).

 

Re 3(b): "The= re are times when detection can only determine that it looks like there is some linguistic content -- it is not just binary data -- but current detection c= an't really determine what it might be. That is, a code that means "accordi= ng to our best available detection methods this doesn't look like it is zxx&qu= ot;." If you want to use mis for = that, I would argue that that is significantly changing the semantics of mis. (Ev= en though mis is unstable, it is unstable on a qualitative level; this is a categorical change.) I definitely oppose that. If you want an ID for "undetermined human language", then that should be proposed. We should not usurp an existing ID for that purpose.


It is a significant broadening of the semantics. And I'm not fixed on that.= It just seems that doing that broadening is congruent with the removal of "(Other)" that you've proposed in other cases, and transforms a useless and dangerous (for stability) code into a useful code. And since it= is a broadening, it is consistent with BCP 47.

However, if that is too big a step to stomach, the alternative is to strong= ly recommend that people never use "mis", and propose a new code for= ISO 639-2 that has the meaning of "Any language".

 

Re 4: I don't see how you= r example differs from this: "Nous avons une phrase en fran=E7ais (but t= his is in English)". The fact that the parenthetical text is in English doesn= 't change the fact that the other text is in French. Similarly, in your exampl= e, the fact that there is a comment in English does not change the fact that t= he rest of the text is not in a human language. Do we create tags for "Fr= ench with embedded bits of English"?


You have a good point. Again, I'm not hard and fast about this issue, but I think there is definitely a significant distinction in usage between "= this is a chunk of stuff that looks like random binary data, like a JPEG", = and "this is stuff that looks like it might be written a programming langu= age.", a distinction that I think would be useful to provide for in BCP 47. On the detection front, it is much easier to determine "this is random binary", while not necessarily very easy to determine "this is a programming language fragment".

 

Peter

 <= /p>

From: m= ark.edward.davis@gmail.com [mailto: mark.edward.davis@gmail.com] On Behalf Of Mark Davis
Sent: Monday, April 16, 2007 3:49 PM
To: Peter Constable
Cc: iet= f-languages@iana.org; ltru@lists.ietf.or= g
Subject: Re: [Ltru] Re: "mis" update revie= w request

 

1. I think we have to be very careful here. The meaning of a standard li= ke ISO 639-2 is established not by what we wish it would have said, nor= by what we would find out if we were able to read Peter's mind. It is establish= ed by the wording in the standard, and how reasonable people could interpret i= t. The fact that "mis" was incorporated in order to account for MARC codes is interesting, but is not in the text of the standard. We can't expe= ct users of BCP 47 to all be able to read Peter's mind before tagging.

2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we wil= l not change the meaning of a tag out from under them. So clarifications that= we add in future versions of 4646 or the registry are fine, as long as they do= not narrow the range of reasonable interpretations. We can broaden them. So in = the case of "mis", a proposed narrowing to include just the MARC code= s is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time th= at "mis" was added to the language registry (the BCP 47 semantics ar= e established at the time we add the code). That is one of the key principles= of BCP 47, is to isolate us where necessary from instabilities in the source standards.

(The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.)

3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections= to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having

and so on. This is useful on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In the ideal case, we would have codes for each of the possible "decision points&qu= ot; in the language tree. That is, if we look at any language code such as http://www.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them= , like "Australian languages".)

3. Randy raised the issue as to whether "mis" in the broad sense = is useful (as something that has linguistic content, but I don't know what it = is). It very much follows the model in #3. There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection = methods this doesn't look like it is zxx".

4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) = { /* remove the item in the lookup table */ ...}". Maybe we need another co= de for this, something different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter Constable <petercon@microsoft= .com> wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]


> I find it very hard to believe that a reasonable analysis
> (whether done by human or machine) would classify a text a
> being "mis" without being able to recognize which of the
> languages in that grouping the text belonged to.  I can
> believe someone could look at text and say "it's a slavic
> language, but I'm not sure which one."  Do we really th= ink
> someone or something would look at some text and say "it's
> Ainu, Andamanese, or Etruscan, but I can't tell which, so
> I'll tag it 'mis'"?

If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the langu= age identity is not determined, and the appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, require that one know it is *not* a language cov= ered by any of the available tags.



Peter

_______________________________________________
Ltru mailing list
Ltru@ietf.org
h= ttps://www1.ietf.org/mailman/listinfo/ltru




--
Mark


_______________________________________________
Ltru mailing list
Ltru@ietf.org
h= ttps://www1.ietf.org/mailman/listinfo/ltru




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB5E4NAEXMSGC117re_-- --===============2035987592== 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 --===============2035987592==-- From ltru-bounces@ietf.org Mon Apr 16 23:40: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 1HdeYM-0004cd-Sk; Mon, 16 Apr 2007 23:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdeYL-0004cQ-9c for ltru@lists.ietf.org; Mon, 16 Apr 2007 23:40: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 1HdeYK-00050M-0N for ltru@lists.ietf.org; Mon, 16 Apr 2007 23:40:25 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ElRSXZg0B0gAhNsfFsaJUm/9hLL3Yh8KreaDT/VjALH0Si91Osr/yIBxWe92Wka5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.4.222] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HdeYJ-0000kf-Dv for ltru@lists.ietf.org; Mon, 16 Apr 2007 23:40:23 -0400 Message-ID: <006801c780a2$6516d180$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20070413122917.GA25431@nic.fr><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> Date: Mon, 16 Apr 2007 20:42:14 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7110606a35556e2dd1c9ae501ffc41802350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.4.222 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] zxx variants for programming languages? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Peter Constable" > To: ; > Sent: Monday, April 16, 2007 7:47 PM > Subject: RE: [Ltru] Re: "mis" update review request ... > For programming languages, I think a zxx variant would be a reasonable solution. ... Recall that long ago, the consensus of the ltru WG (issue #955) was to keep programming languages out of scope. Are you proposing that this should be revisited? Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 01:16: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 1Hdg3b-0003hm-1r; Tue, 17 Apr 2007 01:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdg3a-0003hh-M9 for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:16:46 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdg3Y-0004c3-Cv for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:16:46 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hdg3S-0006RC-Uj; Tue, 17 Apr 2007 01:16:38 -0400 Date: Tue, 17 Apr 2007 01:16:38 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070417051638.GA31410@mercury.ccil.org> References: <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "ietf-languages@iana.org" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > 3. The way to make an collection code XXX not unstable is to make it > not be not defined as an exclusion: removing the (Other). [your proposal] > 4. Then XXX is stable into the future, since adding a new language of > the type XXX doesn't affect it. > 5. Thus if we change "bat" from Baltic (Other)" into "Baltic", meaning > any of the Baltic languages, it becomes stable. As I've pointed out repeatedly, this simply isn't true. If scholars decide that language X is not a Baltic language after all, then the denotation of "bat" changes whether we like it or not. Granted, this isn't likely to happen with Baltic, but a lot of the other language families aren't so well understood. Short of defining each collection by extension, which no one has undertaken to do (the Ethnologue 14th edition is halfway there), no blanket stability guarantees can be offered. > However, if that is too big a step to stomach, the alternative is to > strongly recommend that people never use "mis", and propose a new code for > ISO 639-2 that has the meaning of "Any language". That suits me much better. -- 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 Tue Apr 17 01:20: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 1Hdg7N-0005N9-Rv; Tue, 17 Apr 2007 01:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdg7N-0005N3-AO for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:20:41 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdg7L-00072D-VR for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:20:41 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 22:20:39 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Mon, 16 Apr 2007 22:20:39 -0700 From: Peter Constable To: Randy Presuhn , "ltru@lists.ietf.org" Date: Mon, 16 Apr 2007 22:20:33 -0700 Subject: RE: [Ltru] zxx variants for programming languages? Thread-Topic: [Ltru] zxx variants for programming languages? Thread-Index: AceAoiRr4k3eStasSkWZKUAAJDzG9AADceeA Message-ID: References: <20070413122917.GA25431@nic.fr><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> <006801c780a2$6516d180$6601a8c0@oemcomputer> In-Reply-To: <006801c780a2$6516d180$6601a8c0@oemcomputer> 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: 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 Sorry; if that's a decision that was already made, then I don't mean to re-= open it. I'll stick with "It's out of scope for ISO 639, and zxx would appl= y." Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, April 16, 2007 8:42 PM To: ltru@lists.ietf.org Subject: [Ltru] zxx variants for programming languages? Hi - > From: "Peter Constable" > To: ; > Sent: Monday, April 16, 2007 7:47 PM > Subject: RE: [Ltru] Re: "mis" update review request ... > For programming languages, I think a zxx variant would be a reasonable so= lution. ... Recall that long ago, the consensus of the ltru WG (issue #955) was to keep programming languages out of scope. Are you proposing that this should be revisited? Randy ltru co-chair _______________________________________________ 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 Apr 17 01:23: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 1Hdg9o-0007SP-PG; Tue, 17 Apr 2007 01:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdg9n-0007SK-Nq for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:23:11 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdg9m-0007zW-Cl for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:23:11 -0400 Received: by wx-out-0506.google.com with SMTP id h31so2018799wxd for ; Mon, 16 Apr 2007 22:23:10 -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=Huqw8qI5R2k+uDCcW/2XORlO1C+kio8RntcpkUajx30rX0It2CG5jqCmiZp2ukjdyU8Vu5O56Ct/Bmb8rxP5pS/fIl6np7f+ovHjM9acN4b3Bsvn1tP29lEwz8/SAKmoZDHDaB1bp3OLYgzDvowX48rrq+8v0Np2VL7usoHuTvU= 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=ck8LTErgiJZR5T3IFF33B5DNp9+XI0yejdQA3ezoS30blUTfK2Buy/keTTe4MCGbgEKmfkLFehvWQPooKKfZwrWAd/A1lwwy3QO6W8/1XymnpIbwNcoox0oHwoRJ9fTaBRPoOk7FlmYyZrT7CmCXabO+n6MBcAjpWcNWOkodha4= Received: by 10.114.152.17 with SMTP id z17mr2244943wad.1176787385358; Mon, 16 Apr 2007 22:23:05 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 16 Apr 2007 22:23:05 -0700 (PDT) Message-ID: <30b660a20704162223t6290d6dbq2105701b492f3eec@mail.gmail.com> Date: Mon, 16 Apr 2007 22:23:05 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] zxx variants for programming languages? In-Reply-To: <006801c780a2$6516d180$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> <006801c780a2$6516d180$6601a8c0@oemcomputer> X-Google-Sender-Auth: 2370f9aa4c4a088e X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682776335==" Errors-To: ltru-bounces@ietf.org --===============1682776335== Content-Type: multipart/alternative; boundary="----=_Part_67949_31440336.1176787385303" ------=_Part_67949_31440336.1176787385303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think there are two somewhat different questions. 1. Should we have tags for individual programming languages (I think not). 2. How should we best tag content that happens to be in a programming language (und?, art?, zxx?, other?). It is this latter question we've been discussing. Mark On 4/16/07, Randy Presuhn wrote: > > Hi - > > > From: "Peter Constable" > > To: ; < ltru@lists.ietf.org> > > Sent: Monday, April 16, 2007 7:47 PM > > Subject: RE: [Ltru] Re: "mis" update review request > ... > > For programming languages, I think a zxx variant would be a reasonable > solution. > ... > > Recall that long ago, the consensus of the ltru WG (issue #955) was to > keep programming languages out of scope. Are you proposing that > this should be revisited? > > Randy > ltru co-chair > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_67949_31440336.1176787385303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think there are two somewhat different questions.

1. Should we have tags for individual programming languages (I think not).
2. How should we best tag content that happens to be in a programming language (und?, art?, zxx?, other?). It is this latter question we've been discussing.

Mark

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

> From: "Peter Constable" <petercon@microsoft.com>
> To: < ietf-languages@iana.org>; < ltru@lists.ietf.org>
> Sent: Monday, April 16, 2007 7:47 PM
> Subject: RE: [Ltru] Re: "mis" update review request
...
> For programming languages, I think a zxx variant would be a reasonable solution.
...

Recall that long ago, the consensus of the ltru WG (issue #955) was to
keep programming languages out of scope.  Are you proposing that
this should be revisited?

Randy
ltru co-chair






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



--
Mark ------=_Part_67949_31440336.1176787385303-- --===============1682776335== 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 --===============1682776335==-- From ltru-bounces@ietf.org Tue Apr 17 01:59: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 1Hdgiu-0007sN-4H; Tue, 17 Apr 2007 01:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgis-0007sI-Sv for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:59:26 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdgir-0002ta-C3 for ltru@lists.ietf.org; Tue, 17 Apr 2007 01:59:26 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 16 Apr 2007 22:59:24 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Mon, 16 Apr 2007 22:59:24 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Mon, 16 Apr 2007 22:59:18 -0700 Subject: RE: [Ltru] zxx variants for programming languages? Thread-Topic: [Ltru] zxx variants for programming languages? Thread-Index: AceAsH+7Rds4gv3zTy6qF3HpwdUD8QABK9HQ Message-ID: References: <20070413122917.GA25431@nic.fr> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <30b660a20704161851j4ac4d394r5f303aa33e0720b1@mail.gmail.com> <006801c780a2$6516d180$6601a8c0@oemcomputer> <30b660a20704162223t6290d6dbq2105701b492f3eec@mail.gmail.com> In-Reply-To: <30b660a20704162223t6290d6dbq2105701b492f3eec@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: 1.6 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913715792==" Errors-To: ltru-bounces@ietf.org --===============0913715792== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB63DNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB63DNAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the answer to the first question is No, then there's no real issue wrt t= he second question: it's none of the things we tag, hence zxx. Peter From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Monday, April 16, 2007 10:23 PM To: Randy Presuhn Cc: ltru@lists.ietf.org Subject: Re: [Ltru] zxx variants for programming languages? I think there are two somewhat different questions. 1. Should we have tags for individual programming languages (I think not). 2. How should we best tag content that happens to be in a programming langu= age (und?, art?, zxx?, other?). It is this latter question we've been discu= ssing. Mark On 4/16/07, Randy Presuhn < randy_presuhn@mindspring.com> wrote: Hi - > From: "Peter Constable" > > To: < ietf-languages@iana.org>; < ltru@li= sts.ietf.org> > Sent: Monday, April 16, 2007 7:47 PM > Subject: RE: [Ltru] Re: "mis" update review request ... > For programming languages, I think a zxx variant would be a reasonable so= lution. ... Recall that long ago, the consensus of the ltru WG (issue #955) was to keep programming languages out of scope. Are you proposing that this should be revisited? Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB63DNAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the answer to the first question is No, then there’= s no real issue wrt the second question: it’s none of the things we tag, hence = zxx.

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Monday, April 16, 2007 10:23 PM
To: Randy Presuhn
Cc: ltru@lists.ietf.org
Subject: Re: [Ltru] zxx variants for programming languages?

 

I think there are two s= omewhat different questions.

1. Should we have tags for individual programming languages (I think not).<= br> 2. How should we best tag content that happens to be in a programming langu= age (und?, art?, zxx?, other?). It is this latter question we've been discussin= g.

Mark

On 4/16/07, Randy Presuhn<= /b> < randy_presuhn@mindspring.com> wrote:

Hi -

> From: "Peter Constable" <petercon@microsoft= .com>
> To: < ietf-languages@iana.org>; < ltru@lists.ietf.org>
> Sent: Monday, April 16, 2007 7:47 PM
> Subject: RE: [Ltru] Re: "mis" update review request
...
> For programming languages, I think a zxx variant would be a reasonable solution.
...

Recall that long ago, the consensus of the ltru WG (issue #955) was to
keep programming languages out of scope.  Are you proposing that<= br> this should be revisited?

Randy
ltru co-chair






_______________________________________________
Ltru mailing list
Ltru@ietf.org
h= ttps://www1.ietf.org/mailman/listinfo/ltru




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBB63DNAEXMSGC117re_-- --===============0913715792== 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 --===============0913715792==-- From ltru-bounces@ietf.org Tue Apr 17 11:54: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 1Hdq0s-0006gT-Ln; Tue, 17 Apr 2007 11:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq0r-0006gJ-NX for ltru@lists.ietf.org; Tue, 17 Apr 2007 11:54:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdq0p-0007Sv-A1 for ltru@lists.ietf.org; Tue, 17 Apr 2007 11:54:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hdq0f-0005HE-CJ for ltru@lists.ietf.org; Tue, 17 Apr 2007 17:54:25 +0200 Received: from d255054.dialin.hansenet.de ([80.171.255.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 17:54:25 +0200 Received: from nobody by d255054.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 17:54:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 17 Apr 2007 17:53:51 +0200 Organization: Lines: 35 Message-ID: <4624ED8F.50C8@xyzzy.claranet.de> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255054.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > There are lots of details about RFC 4646(bis) that would be missed by > someone who reads only the Registry. It could be only me, but I fear it's not. Of course I looked into the spec. for reviews, while checking the ABNF etc., and again before my registratioin requests. Otherwise I was always far more interested in the raw registry data, or in the corresponding parts of your drafts. > Should we design a specification under the assumption that people > will not read it? Admittedly I hoped that the expert reviewer would read it. Ordinary users might just imitate what they see elsewhere in their tags, and somebody looking into the registry is a nerd. And for readers of the spec. I fear that they're a proper subset of the folks posting here or on the review list. > Is anyone else uncomfortable with this approach? Humans are lazy. The rules are mainly for those trying to enforce or implement them, IANA, IESG, Michael, you, any anybody who intends to disagree with you. > I agree with John that Peter's explanation, or a formalized version > thereof, should be added to the spec. I've no problem with that idea. But I also want John's short and IMO clear "mis" explanation as comment in the registry, it's the polite form of a "DO NOT USE" for readers of the registry with a minimum of good will and common sense. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 12:18: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 1HdqOG-0002KK-4K; Tue, 17 Apr 2007 12:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqOF-0002KC-H3 for ltru@lists.ietf.org; Tue, 17 Apr 2007 12:18:47 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdqOF-0006am-3A for ltru@lists.ietf.org; Tue, 17 Apr 2007 12:18:47 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1852844wra for ; Tue, 17 Apr 2007 09:18:46 -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=RIlr4oW1fS+68fIKotNDkFA5lwUkY3V6IP9rRfOkomazSDu/9fiudX+MASjwcxfCyCAcrqzw44mpMmEEKN1d1bN7UbJFsucUa/daeyRxtQqx+K3D1sORkgvQNNcPzjw07VkUPYK1slswzPPR+Dfjr6ysxksBogruCX1PFBDMJfg= 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=hU2HBGJF4HI3Vdm++cFhreFkdMsQzc7ASs657yDUo1smjUueu3vgqPZdSGPaZ+ws18aKPOFpq4ltICEoeDA5AhQrnSn9IMc0JEUtjNdWONzwbCCvD0+IV/eMSRUNldP7vf9NgiFLKDO8oD5kZxS4ucaUufm1IpJ6qGWjDbeUaa8= Received: by 10.114.25.3 with SMTP id 3mr2494885way.1176826726276; Tue, 17 Apr 2007 09:18:46 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 09:18:45 -0700 (PDT) Message-ID: <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> Date: Tue, 17 Apr 2007 09:18:45 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <4624ED8F.50C8@xyzzy.claranet.de> MIME-Version: 1.0 References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> X-Google-Sender-Auth: c8906c552d3ee3f2 X-Spam-Score: 0.5 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1676956856==" Errors-To: ltru-bounces@ietf.org --===============1676956856== Content-Type: multipart/alternative; boundary="----=_Part_79232_31853114.1176826725387" ------=_Part_79232_31853114.1176826725387 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think we are nearly consensus on what to do with a number of these special items: und, art, mis, zxx, etc. But I don't think we are quite there yet. Because they are interrelated, I don't think we want any comments added until we are sure that we have a complete picture for all of them. Once that is the case, then adding comments would be good. Moreover, it would be really good to add some comments at the very top with a warning that many of the items cannot be understood simply from the data file, and point people to the URL for more discussion. Mark On 4/17/07, Frank Ellermann wrote: > > Doug Ewell wrote: > > > There are lots of details about RFC 4646(bis) that would be missed by > > someone who reads only the Registry. > > It could be only me, but I fear it's not. Of course I looked into the > spec. for reviews, while checking the ABNF etc., and again before my > registratioin requests. Otherwise I was always far more interested in > the raw registry data, or in the corresponding parts of your drafts. > > > Should we design a specification under the assumption that people > > will not read it? > > Admittedly I hoped that the expert reviewer would read it. Ordinary > users might just imitate what they see elsewhere in their tags, and > somebody looking into the registry is a nerd. And for readers of the > spec. I fear that they're a proper subset of the folks posting here > or on the review list. > > > Is anyone else uncomfortable with this approach? > > Humans are lazy. The rules are mainly for those trying to enforce or > implement them, IANA, IESG, Michael, you, any anybody who intends to > disagree with you. > > > I agree with John that Peter's explanation, or a formalized version > > thereof, should be added to the spec. > > I've no problem with that idea. But I also want John's short and IMO > clear "mis" explanation as comment in the registry, it's the polite > form of a "DO NOT USE" for readers of the registry with a minimum of > good will and common sense. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_79232_31853114.1176826725387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think we are nearly consensus on what to do with a number of these special items: und, art, mis, zxx, etc. But I don't think we are quite there yet.

Because they are interrelated, I don't think we want any comments added until we are sure that we have a complete picture for all of them. Once that is the case, then adding comments would be good.

Moreover, it would be really good to add some comments at the very top with a warning that many of the items cannot be understood simply from the data file, and point people to the URL for more discussion.

Mark

On 4/17/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Doug Ewell wrote:

> There are lots of details about RFC 4646(bis) that would be missed by
> someone who reads only the Registry.

It could be only me, but I fear it's not.  Of course I looked into the
spec. for reviews, while checking the ABNF etc., and again before my
registratioin requests.  Otherwise I was always far more interested in
the raw registry data, or in the corresponding parts of your drafts.

> Should we design a specification under the assumption that people
> will not read it?

Admittedly I hoped that the expert reviewer would read it.  Ordinary
users might just imitate what they see elsewhere in their tags, and
somebody looking into the registry is a nerd.  And for readers of the
spec. I fear that they're a proper  subset of the folks posting here
or on the review list.

> Is anyone else uncomfortable with this approach?

Humans are lazy.  The rules are mainly for those trying to enforce or
implement them, IANA, IESG, Michael, you, any anybody who intends to
disagree with you.

> I agree with John that Peter's explanation, or a formalized version
> thereof, should be added to the spec.

I've no problem with that idea.  But I also want John's short and IMO
clear "mis" explanation as comment in the registry, it's the polite
form of a "DO NOT USE" for readers of the registry with a minimum of
good will and common sense.

Frank



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



--
Mark ------=_Part_79232_31853114.1176826725387-- --===============1676956856== 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 --===============1676956856==-- From ltru-bounces@ietf.org Tue Apr 17 12:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqOa-0002Pi-VM; Tue, 17 Apr 2007 12:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqOZ-0002NK-8t for ltru@lists.ietf.org; Tue, 17 Apr 2007 12:19:07 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdqOX-0006cK-Ni for ltru@lists.ietf.org; Tue, 17 Apr 2007 12:19:07 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1809246nzf for ; Tue, 17 Apr 2007 09:19:05 -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=jOfCWzONMCEOplFysrFgvegw4ydGsIT0BvIEvDF1NK/v/iGhNEc55NBQ7fakhIaLshcaOE/pSsDoB2eZturIpWlqztsoOD7ySd+aIfAOErF/uN4KWZAOPAlsrtGOZ1YC3TYwQFpR+xmv/n4FHf6RnWrrlWMcWbdOcLK1R5ai9zw= 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=FN2gnGTXAabOrk961fFidgSimDXD5/Lk0gzteD8gPEBhOFh1lOxHB5v10AQTroRGY7fDO5/9I9PrH7txVq6cRTm4Yg5Q2BIb8Pm5ax9sT+MKE4Qx01LRCOlGeiN47/sJ7cOHGDeVsrN+5pa1kDwGA4vsdRZo12oncGK1KGn89Os= Received: by 10.114.26.1 with SMTP id 1mr2491190waz.1176826742602; Tue, 17 Apr 2007 09:19:02 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 09:19:02 -0700 (PDT) Message-ID: <30b660a20704170919l3f8d333egccc3be840ca3669c@mail.gmail.com> Date: Tue, 17 Apr 2007 09:19:02 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> MIME-Version: 1.0 References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> X-Google-Sender-Auth: 5ce7673b0de3147b X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145764314==" Errors-To: ltru-bounces@ietf.org --===============0145764314== Content-Type: multipart/alternative; boundary="----=_Part_79244_14503657.1176826742097" ------=_Part_79244_14503657.1176826742097 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline nearly=>nearing On 4/17/07, Mark Davis wrote: > > I think we are nearly consensus on what to do with a number of these > special items: und, art, mis, zxx, etc. But I don't think we are quite there > yet. > > Because they are interrelated, I don't think we want any comments added > until we are sure that we have a complete picture for all of them. Once that > is the case, then adding comments would be good. > > Moreover, it would be really good to add some comments at the very top > with a warning that many of the items cannot be understood simply from the > data file, and point people to the URL for more discussion. > > Mark > > On 4/17/07, Frank Ellermann wrote: > > > > Doug Ewell wrote: > > > > > There are lots of details about RFC 4646(bis) that would be missed by > > > someone who reads only the Registry. > > > > It could be only me, but I fear it's not. Of course I looked into the > > spec. for reviews, while checking the ABNF etc., and again before my > > registratioin requests. Otherwise I was always far more interested in > > the raw registry data, or in the corresponding parts of your drafts. > > > > > Should we design a specification under the assumption that people > > > will not read it? > > > > Admittedly I hoped that the expert reviewer would read it. Ordinary > > users might just imitate what they see elsewhere in their tags, and > > somebody looking into the registry is a nerd. And for readers of the > > spec. I fear that they're a proper subset of the folks posting here > > or on the review list. > > > > > Is anyone else uncomfortable with this approach? > > > > Humans are lazy. The rules are mainly for those trying to enforce or > > implement them, IANA, IESG, Michael, you, any anybody who intends to > > disagree with you. > > > > > I agree with John that Peter's explanation, or a formalized version > > > thereof, should be added to the spec. > > > > I've no problem with that idea. But I also want John's short and IMO > > clear "mis" explanation as comment in the registry, it's the polite > > form of a "DO NOT USE" for readers of the registry with a minimum of > > good will and common sense. > > > > Frank > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > Mark -- Mark ------=_Part_79244_14503657.1176826742097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline nearly=>nearing

On 4/17/07, Mark Davis <mark.davis@icu-project.org> wrote:
I think we are nearly consensus on what to do with a number of these special items: und, art, mis, zxx, etc. But I don't think we are quite there yet.

Because they are interrelated, I don't think we want any comments added until we are sure that we have a complete picture for all of them. Once that is the case, then adding comments would be good.

Moreover, it would be really good to add some comments at the very top with a warning that many of the items cannot be understood simply from the data file, and point people to the URL for more discussion.

Mark


On 4/17/07, Frank Ellermann < nobody@xyzzy.claranet.de> wrote:
Doug Ewell wrote:

> There are lots of details about RFC 4646(bis) that would be missed by
> someone who reads only the Registry.

It could be only me, but I fear it's not.  Of course I looked into the
spec. for reviews, while checking the ABNF etc., and again before my
registratioin requests.  Otherwise I was always far more interested in
the raw registry data, or in the corresponding parts of your drafts.

> Should we design a specification under the assumption that people
> will not read it?

Admittedly I hoped that the expert reviewer would read it.  Ordinary
users might just imitate what they see elsewhere in their tags, and
somebody looking into the registry is a nerd.  And for readers of the
spec. I fear that they're a proper  subset of the folks posting here
or on the review list.

> Is anyone else uncomfortable with this approach?

Humans are lazy.  The rules are mainly for those trying to enforce or
implement them, IANA, IESG, Michael, you, any anybody who intends to
disagree with you.

> I agree with John that Peter's explanation, or a formalized version
> thereof, should be added to the spec.

I've no problem with that idea.  But I also want John's short and IMO
clear "mis" explanation as comment in the registry, it's the polite
form of a "DO NOT USE" for readers of the registry with a minimum of
good will and common sense.

Frank



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



--
Mark



--
Mark ------=_Part_79244_14503657.1176826742097-- --===============0145764314== 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 --===============0145764314==-- From ltru-bounces@ietf.org Tue Apr 17 13: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 1Hdr9o-0002PO-6u; Tue, 17 Apr 2007 13:07:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr9m-0002PH-UA for ltru@ietf.org; Tue, 17 Apr 2007 13:07:54 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdr9k-0007fD-LU for ltru@ietf.org; Tue, 17 Apr 2007 13:07:54 -0400 Received: (qmail 1676 messnum 11074426 invoked from network[194.125.174.35/ts09-035.dublin.indigo.ie]); 17 Apr 2007 17:07:49 -0000 Received: from ts09-035.dublin.indigo.ie (HELO ?194.125.174.35?) (194.125.174.35) by mail11.svc.cra.dublin.eircom.net (qp 1676) with SMTP; 17 Apr 2007 17:07:49 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> References: <20070413122917.GA25431@nic.fr> <30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com> <461FB58B.648F@xyzzy.claranet.de> <30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com> <20070413175040.GM7353@mercury.ccil.org> <30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <792EB849-D397-41FD-91E2-DDF4D394EDF4@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: "mis" update review request Date: Tue, 17 Apr 2007 18:09:26 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) 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 Me, too. We do. And after that, to make an ISO standard for =20 cataloguing computer languages - which couldn't take long to do at =20 all, compared to the long-drawn-out efforts to catalogue human =20 languages. mg On 16 Apr 2007, at 22:49, scr=EDobh Mark Davis: > ... > > 4. I'm leery of using zxx for programming languages, instead of =20 > just binary. There is clearly some linguistic content in "if =20 > (content =3D=3D null) { /* remove the item in the lookup table =20 > */ ...}". Maybe we need another code for this, something different =20 > than either 'art' or 'zxx'. - - 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 Apr 17 13:22: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 1HdrO8-0000Bo-41; Tue, 17 Apr 2007 13:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrO7-0000Bj-EQ for ltru@ietf.org; Tue, 17 Apr 2007 13:22:43 -0400 Received: from mail09.svc.cra.dublin.eircom.net ([159.134.118.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdrO6-0004Ov-3W for ltru@ietf.org; Tue, 17 Apr 2007 13:22:43 -0400 Received: (qmail 62355 messnum 2884166 invoked from network[194.125.174.35/ts09-035.dublin.indigo.ie]); 17 Apr 2007 17:22:40 -0000 Received: from ts09-035.dublin.indigo.ie (HELO ?194.125.174.35?) (194.125.174.35) by mail09.svc.cra.dublin.eircom.net (qp 62355) with SMTP; 17 Apr 2007 17:22:40 -0000 Mime-Version: 1.0 (Apple Message framework v728) To: LTRU Working Group Message-Id: From: Marion Gunn Date: Tue, 17 Apr 2007 18:24:17 +0000 X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ltru] changing personal list options X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0566449765==" Errors-To: ltru-bounces@ietf.org --===============0566449765== Content-Type: multipart/alternative; boundary=Apple-Mail-14-958561517 --Apple-Mail-14-958561517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On IETF another user has helpfully pointed to a webpage for changing =20= user-specific options. I know that, although IETF and LTRU are sister-=20= lists, they sometimes operate in different ways, so would someone be =20 kind enough to point to where one can find the online facility for =20 changing LTRU options similar to that indicated below? mg On 16 Apr 2007, at 13:02, scr=EDobh Jeremy Carroll: > ... > http://www.alvestrand.no/mailman/options/ietf-languages/... - - 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-14-958561517 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On IETF=A0 another user has = helpfully pointed to a webpage for changing user-specific options. I = know that, although IETF and LTRU are sister-lists, they sometimes = operate in different ways, so would someone be kind enough to point to = where one can find the online facility for changing LTRU options similar = to that indicated below?
mg

On 16 Apr 2007, at = 13:02, scr=EDobh Jeremy Carroll:
...


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

= --Apple-Mail-14-958561517-- --===============0566449765== 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 --===============0566449765==-- From ltru-bounces@ietf.org Tue Apr 17 13:34: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 1HdrZx-0006aa-9m; Tue, 17 Apr 2007 13:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrZw-0006aU-2y for ltru@lists.ietf.org; Tue, 17 Apr 2007 13:34:56 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrZu-0007iH-NN for ltru@lists.ietf.org; Tue, 17 Apr 2007 13:34:56 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HdrZo-0006rI-1M; Tue, 17 Apr 2007 13:34:48 -0400 Date: Tue, 17 Apr 2007 13:34:48 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070417173447.GA3783@mercury.ccil.org> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I think we are nearly consensus on what to do with a number of these special > items: und, art, mis, zxx, etc. But I don't think we are quite there yet. +1 > Because they are interrelated, I don't think we want any comments added > until we are sure that we have a complete picture for all of them. Once that > is the case, then adding comments would be good. +1 > Moreover, it would be really good to add some comments at the very top with > a warning that many of the items cannot be understood simply from the data > file, and point people to the URL for more discussion. Unfortunately the format makes no provision for such comments. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when cowan@ccil.org he has reached ground encumbers him with help? --Samuel Johnson _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 13:48: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 1HdrnN-0005zO-V6; Tue, 17 Apr 2007 13:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrnN-0005zJ-6B for ltru@ietf.org; Tue, 17 Apr 2007 13:48:49 -0400 Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdrnL-00066c-UJ for ltru@ietf.org; Tue, 17 Apr 2007 13:48:49 -0400 Received: (qmail 74820 messnum 4225145 invoked from network[194.125.174.35/ts09-035.dublin.indigo.ie]); 17 Apr 2007 17:48:46 -0000 Received: from ts09-035.dublin.indigo.ie (HELO ?194.125.174.35?) (194.125.174.35) by mail13.svc.cra.dublin.eircom.net (qp 74820) with SMTP; 17 Apr 2007 17:48:46 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070417173447.GA3783@mercury.ccil.org> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> 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: "mis" update review request Date: Tue, 17 Apr 2007 18:50:21 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It is wisely said that those who forge the chains are most likely to =20 shackle themselves. Is it truly too late to change the format in the =20 respect outlined below? mg On 17 Apr 2007, at 17:34, scr=EDobh John Cowan: >> Mark Davis scripsit: >> ... Moreover, it would be really good to add some comments at the =20 >> very top with >> a warning that many of the items cannot be understood simply from =20 >> the data >> file, and point people to the URL for more discussion. >> > > Unfortunately the format makes no provision for such comments. - - 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 Apr 17 14:59: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 1Hdsu4-00029v-6a; Tue, 17 Apr 2007 14:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsu2-00029p-M9 for ltru@lists.ietf.org; Tue, 17 Apr 2007 14:59:46 -0400 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdsu1-0004qr-1C for ltru@lists.ietf.org; Tue, 17 Apr 2007 14:59:46 -0400 Received: from hotmail.com ([65.54.169.46]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 17 Apr 2007 11:59:44 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Apr 2007 11:59:44 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Tue, 17 Apr 2007 18:59:39 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: From: "CE Whitehead" To: petercon@microsoft.com, ltru@lists.ietf.org, www-international@w3.org Bcc: Subject: RE: [Ltru] Re: For review: Tagging text with no language Date: Tue, 17 Apr 2007 14:59:39 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Apr 2007 18:59:44.0142 (UTC) FILETIME=[8F997AE0:01C78122] X-Spam-Score: 0.7 (/) 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 > > >From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > > > Let's look at a real use case. Would you say this page > > is in "en" and "zxx" and that the sections of code > > have no linguistic value even though they are clearly > > intended to be read by humans and not machines? Or does > > context matter? Such as comments in programming code. I do personally happen to think that maybe there is a use for a variant of zxx that indicates it is a programming language (not a math formula or whatever) and then there is a use to allow some additional identification of the language(s) involved (clearly the basic code could be in one language, English, but user-defined functions might make use of French or German abbreviations and then the comments would actually be in French or German). In the meantime, one thing that might help for tagging code snippets in a page is have an outer paragraph or whatever lang="en" (or "fr" or "de" or what have you, the language that is closest to the language in which the code is based) with maybe a short header or something in the appropriate language and just inside this a section pre which is where the code is you could define the language of pre as zxx Just my two cents' worth. --C. E. Whitehead cewcathar@hotmail.com > >You're asking to have one tag that covers an entire document even though >that document is mixed. What if I insert a quotation in Spanish in this >mail? ¿Que vamos a hacer? It's no different. If you must use a single tag >for the whole thing, then clearly this is predominantly in English. I don't >know what you'd do if it were closer to 50-50. > > > > Interpreting "no linguistic content" as "not a human > > language, could be a programming language" could cause > > some problems. There may be a use case for programming > > languages to have their own tag if this is deemed > > appropriate for the 639 standards or IANA registry, and > > these languages are different than say, instrumental > > music in the Library of Congress or a sound effects > > track in a film (both zxx, I'd say). > >Your argument is akin to someone saying that someone may want to code audio >in Unicode. ISO 639 has defined a scope, human languages. Programming >languages, electrical schematics, dance notation, bridge-hand notation, >math formulas and engineering drawings are all graphic content that can be >interpreted by humans. Some of these can be represented in text, but that >does not change the fact that they are not a form of the kind of things >coded by ISO 639, human languages. > > > I think programming languages have specific > > identification and parsing needs and as such need to > > be treated differently. > >As I suggested earlier, the scope defined by ISO 639 does not force RFC >4646bis to be limited to the same scope -- in fact, it cannot be. >("Language tags" already code things other than linguistic variety, written >form in particular.) So, if you want to propose variant subtags to >differentiate programming code from music notation, then I don't see why >that couldn't be done. > >But it would be out of scope for ISO 639 to code such a distinction, and it >would be a non-conforming re-interpretation to say that zxx does not apply >programming languages. > > > > The code in the article above should be rendered in > > Braille, for example, so it must be parsed. This makes > > it different from non-linguistic content. > >You're confusing the language of content with the representation mode in >some communicative technology. English content in Braille is still English, >and so clearly different from zxx. That is not in any way comparable to >discussing code in a programming language. > > > > How would you classify the page I cite? > >As I mentioned above, this question is no different than asking how to come >up with one tag for a page that contains content in both English and >Spanish. On a *practical* level, I would tag that article as en and ignore >the fact that it contains XML code snippets; but if someone was being >careful to tag elements within the document correctly, then the code >snippets should be tagged zxx. (That is, unless you want to register >variant subtags to differentiate between different kinds of non-linguistic >content.) > > >Peter One might want to do so. > _________________________________________________________________ Mortgage rates near historic lows. Refinance $200,000 loan for as low as $771/month* https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 15:07: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 1Hdt1q-0006Yh-S6; Tue, 17 Apr 2007 15:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdt1p-0006Yc-MC for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:07:49 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdt1n-0007wS-DI for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:07:49 -0400 Received: from c83-248-99-122.bredband.comhem.se ([83.248.99.122]:3983 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hdt1k-0008DV-5p; Tue, 17 Apr 2007 21:07:47 +0200 From: "Kent Karlsson" To: "'Peter Constable'" , , References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> Subject: RE: [Ltru] Re: "mis" update review request Date: Tue, 17 Apr 2007 21:09:59 +0200 Message-ID: <00a201c78124$0713eaa0$7a63f853@streamserve.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyA= In-Reply-To: X-Scan-Result: No virus found in message 1Hdt1k-0008DV-5p. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Hdt1k-0008DV-5p 88bbcdbb50137df6aa90e80d9c60d28c X-Spam-Score: 1.8 (+) X-Scan-Signature: b4c10eaa27436d806c79842272125a2a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766028829==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0766028829== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A3_01C78134.CA9CBAA0" This is a multi-part message in MIME format. ------=_NextPart_000_00A3_01C78134.CA9CBAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable on 1: =20 I don't see why 'mis' would have to be an exception when doing a = semantic change of removing (implicit or explicit) "other" for various language codes. Doing so is equally much a semantic change for = 'tai' (or any other "other" collection), and of exactly the same kind, so if it is not ok for 'mis' it would not be ok for 'tai' = either. (If you prefer another acronym, say 'any' instead of 'mis', that is another ball-game.) =20 Furthermore, since 'mul' is the only code intended for multiple = languages (when it is not practical to list which languages, per fragment of the document preferably), all of the "languages" codes = should instead refer to "language" in singular. This would not be a semantic change, just referring to each of the items that may be = tagged, not a set of items [book shelf...] so tagged. =20 on 4: =20 Programming languages of various sorts are out of scope (like 'zxx', but = unlike 'art'), but I may agree that they are out of scope in a different way than 'zxx'. Perhaps "formal language" ('for'), with = no further subdivision (they are still out of scope). =20 /kent k _____ =20 From: Peter Constable [mailto:petercon@microsoft.com]=20 Sent: Tuesday, April 17, 2007 2:19 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis = is bound to be in MARC, and (b) any existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the = exception list for ISO 639-2). =20 Re 2: The mis collection is inherently unstable =96 unavoidably so. = Prior to 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content as mis; after that date, an implementation of ISO = 639-2 would have tagged Ainu content as ain; existing content tagged before that date would not get retrieved by request for ain, and = it would be conformant to suppose that requests for mis would not return Ainu content. The mis collection is ugly, pure and = simple. So, I don=92t see what the point is of getting worried over whether we=92re making mis unstable: it=92s been that way for some = time. =20 (Note: mis is badly defined from a stability perspective, though I = don=92t think there=92s much question of how it=92s defined.) =20 Re 3(b): =93There are times when detection can only determine that it = looks like there is some linguistic content -- it is not just binary data -- but current detection can't really determine what it = might be. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".=94 If you = want to use mis for that, I would argue that that is significantly changing the semantics of mis. (Even though mis is = unstable, it is unstable on a qualitative level; this is a categorical change.) I definitely oppose that. If you want an ID for = =93undetermined human language=94, then that should be proposed. We should not usurp an existing ID for that purpose. =20 Re 4: I don=92t see how your example differs from this: =93Nous avons = une phrase en fran=E7ais (but this is in English)=94. The fact that the parenthetical text is in English doesn=92t change the fact that the = other text is in French. Similarly, in your example, the fact that there is a comment in English does not change the fact that the = rest of the text is not in a human language. Do we create tags for =93French with embedded bits of English=94? =20 =20 Peter =20 From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request =20 1. I think we have to be very careful here. The meaning of a standard = like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's = mind. It is established by the wording in the standard, and how reasonable people could interpret it. The fact that "mis" was = incorporated in order to account for MARC codes is interesting, but is not in the text of the standard. We can't expect users of BCP 47 = to all be able to read Peter's mind before tagging.=20 2. When we are looking at stability, that is very important: our goal is = that once content is correctly tagged, people can depend on the fact that we will not change the meaning of a tag out from under = them. So clarifications that we add in future versions of 4646 or the registry are fine, as long as they do not narrow the range of = reasonable interpretations. We can broaden them. So in the case of "mis", a proposed narrowing to include just the MARC codes is clearly = disallowed, since it was nowhere stated in ISO 639-2 at the time that "mis" was added to the language registry (the BCP 47 semantics = are established at the time we add the code). That is one of the key principles of BCP 47, is to isolate us where necessary from = instabilities in the source standards.=20 (The one exception we might be able to make is where something is so = badly defined that most reasonable people couldn't come up with any consistent definition for it.) 3. Now, I think there are steps that can be taken to make the above = moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections to remove the (Other) is exactly the right strategy, = and if this can be done before 4646bis is issued, all the better. So having=20 * aus Australian languages means any of the languages on = http://www.ethnologue.com/show_family.asp?subid=3D90498=20 * bat Baltic (Other) =3D> Baltic languages, means any of the = languages on http://www.ethnologue.com/show_family.asp?subid=3D90207=20 * mis Miscellaneous languages, essentially the root for = http://www.ethnologue.com/family_index.asp=20 and so on. This is useful on a number of levels; it resolves a number of = problems in the interpretation of language codes, and makes the source standards themselves more stable. (In the ideal case, we = would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as = http://www.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them, like = "Australian languages".)=20 3. Randy raised the issue as to whether "mis" in the broad sense is = useful (as something that has linguistic content, but I don't know what it is). It very much follows the model in #3. There are times = when detection can only determine that it looks like there is some linguistic content -- it is not just binary data -- but current = detection can't really determine what it might be. That is, a code that means "according to our best available detection methods = this doesn't look like it is zxx".=20 4. I'm leery of using zxx for programming languages, instead of just = binary. There is clearly some linguistic content in "if (content =3D=3D null) { /* remove the item in the lookup table */ ...}". = Maybe we need another code for this, something different than either 'art' or 'zxx'.=20 Mark On 4/14/07, Peter Constable wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a=20 > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think=20 > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate = use of mis. Since they do not know what it is, their declaration is that the language identity is not determined, and the = appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, = require that one know it is *not* a language covered by any of the available tags.=20 Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru = =20 --=20 Mark=20 ------=_NextPart_000_00A3_01C78134.CA9CBAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
on=20 1:
 
I don't see=20 why 'mis' would have to be an exception when doing a semantic change of = removing=20 (implicit or explicit) "other" for various language codes. Doing so is = equally=20 much a semantic change for 'tai' (or any other "other" collection), and = of=20 exactly the same kind, so if it is not ok for 'mis' it would not be ok = for 'tai'=20 either. (If you prefer another acronym, say 'any' instead of 'mis', that = is=20 another ball-game.)
 
Furthermore,=20 since 'mul' is the only code intended for multiple languages (when it is = not=20 practical to list which languages, per fragment of the document = preferably), all=20 of the "languages" codes should instead refer to = "language" in=20 singular. This would not be a semantic change, just referring = to each=20 of the items that may be tagged, not a set of items [book shelf...] so=20 tagged.
 
on=20 4:
 
Programming=20 languages of various sorts are out of scope (like 'zxx', but unlike = 'art'), but=20 I may agree that they are out of scope in a different way than 'zxx'. = Perhaps=20 "formal language" ('for'), with no further subdivision (they are still = out of=20 scope).
 

From: Peter Constable=20 [mailto:petercon@microsoft.com]
Sent: Tuesday, April 17, = 2007 2:19=20 AM
To: ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update = review=20 request

Re=20 1: Yes, be careful: (a) the majority of existing legacy usage of mis = is bound=20 to be in MARC, and (b) any existing usage would assume the context of = ISO=20 639-2 (i.e. mis in existing usage is the exception list for ISO=20 639-2).

 

Re=20 2: The mis collection is inherently unstable =96 unavoidably so. Prior = to=20 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu = content as=20 mis; after that date, an implementation of ISO 639-2 would have tagged = Ainu=20 content as ain; existing content tagged before that date would not get = retrieved by request for ain, and it would be conformant to suppose = that=20 requests for mis would not return Ainu content. The mis collection is = ugly,=20 pure and simple. So, I don=92t see what the point is of getting = worried over=20 whether we=92re making mis unstable: it=92s been that way for some=20 time.

 

(Note:=20 mis is badly defined from a stability perspective, though I don=92t = think=20 there=92s much question of how it=92s defined.)

 

Re=20 3(b): =93There are times when detection can only determine that = it looks=20 like there is some linguistic content -- it is not just binary data -- = but=20 current detection can't really determine what it might be. That is, a = code=20 that means "according to our best available detection methods this = doesn't=20 look like it is zxx".=94=20 If you want to use mis for that, I would argue that that is = significantly=20 changing the semantics of mis. (Even though mis is unstable, it is = unstable on=20 a qualitative level; this is a categorical change.) I definitely = oppose that.=20 If you want an ID for =93undetermined human language=94, then that = should be=20 proposed. We should not usurp an existing ID for that=20 purpose.

 

Re=20 4: I don=92t see how your example differs from this: =93Nous avons une = phrase en=20 fran=E7ais (but this is in English)=94. The fact that the = parenthetical text is in=20 English doesn=92t change the fact that the other text is in French. = Similarly,=20 in your example, the fact that there is a comment in English does not = change=20 the fact that the rest of the text is not in a human language. Do we = create=20 tags for =93French with embedded bits of = English=94?

 

 

Peter

 

From:=20 mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On = Behalf=20 Of Mark Davis
Sent: Monday, April 16, 2007 3:49 = PM
To:=20 Peter Constable
Cc: ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update = review=20 request

 

1. I think we have to be very careful here. The = meaning of=20 a standard like ISO 639-2 is established not by what we wish it = would have=20 said, nor by what we would find out if we were able to read = Peter's=20 mind. It is established by the wording in the standard, and how = reasonable=20 people could interpret it. The fact that "mis" was incorporated in = order to=20 account for MARC codes is interesting, but is not in the text of the = standard.=20 We can't expect users of BCP 47 to all be able to read Peter's mind = before=20 tagging.

2. When we are looking at stability, that is very = important:=20 our goal is that once content is correctly tagged, people can depend = on the=20 fact that we will not change the meaning of a tag out from under them. = So=20 clarifications that we add in future versions of 4646 or the registry = are=20 fine, as long as they do not narrow the range of reasonable = interpretations.=20 We can broaden them. So in the case of "mis", a proposed narrowing to = include=20 just the MARC codes is clearly disallowed, since it was nowhere stated = in ISO=20 639-2 at the time that "mis" was added to the language registry (the = BCP 47=20 semantics are established at the time we add the code). That is one of = the key=20 principles of BCP 47, is to isolate us where necessary from = instabilities in=20 the source standards.

(The one exception we might be able to = make is=20 where something is so badly defined that most reasonable people = couldn't come=20 up with any consistent definition for it.)

3. Now, I think = there are=20 steps that can be taken to make the above moot. I think Peter's = suggestion for=20 ISO 639-X of broadening all of the Collections to remove the (Other) = is=20 exactly the right strategy, and if this can be done before 4646bis is = issued,=20 all the better. So having

  • aus   =20 Australian languages means any of the languages on http://w= ww.ethnologue.com/show_family.asp?subid=3D90498=20
  • bat   =20 Baltic (Other) =3D> Baltic languages, means any of the languages = on http://w= ww.ethnologue.com/show_family.asp?subid=3D90207=20
  • mis   =20 Miscellaneous languages, essentially the root for http://www.ethnologue= .com/family_index.asp=20

and so on. This is = useful on a=20 number of levels; it resolves a number of problems in the = interpretation of=20 language codes, and makes the source standards themselves more stable. = (In the=20 ideal case, we would have codes for each of the possible "decision = points" in=20 the language tree. That is, if we look at any language code such as http:/= /www.ethnologue.com/show_lang_family.asp?code=3Deng=20 we'd have codes for each of the parent groupings, not just some of = them, like=20 "Australian languages".)

3. Randy raised the issue as to = whether "mis"=20 in the broad sense is useful (as something that has linguistic = content, but I=20 don't know what it is). It very much follows the model in #3. There = are times=20 when detection can only determine that it looks like there is some = linguistic=20 content -- it is not just binary data -- but current detection can't = really=20 determine what it might be. That is, a code that means "according to = our best=20 available detection methods this doesn't look like it is zxx". =

4. I'm=20 leery of using zxx for programming languages, instead of just binary. = There is=20 clearly some linguistic content in "if (content =3D=3D null) { /* = remove the item=20 in the lookup table */ ...}". Maybe we need another code for this, = something=20 different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter = Constable=20 <petercon@microsoft.com>=20 wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com= ]


>=20 I find it very hard to believe that a reasonable analysis
> = (whether=20 done by human or machine) would classify a text a
> being "mis" = without=20 being able to recognize which of the
> languages in that = grouping the=20 text belonged to.  I can
> believe someone could look = at text=20 and say "it's a slavic
> language, but I'm not sure which=20 one."  Do we really think
> someone or something = would look=20 at some text and say "it's
> Ainu, Andamanese, or Etruscan, but = I can't=20 tell which, so
> I'll tag it 'mis'"?

If someone were so = tempted,=20 I would argue that would be inappropriate use of mis. Since they do = not know=20 what it is, their declaration is that the language identity is not = determined,=20 and the appropriate tag for that is und. Appropriate use of mis does = not=20 require that one know the language of the content; it does, however, = require=20 that one know it is *not* a language covered by any of the available = tags.=20 =



Peter

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




--
Mark=20

        /kent=20 k
------=_NextPart_000_00A3_01C78134.CA9CBAA0-- --===============0766028829== 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 --===============0766028829==-- From ltru-bounces@ietf.org Tue Apr 17 15:35: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 1HdtSs-00024k-Uy; Tue, 17 Apr 2007 15:35:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtSr-00024e-UT for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:35:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtSo-0005hG-KO for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:35:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdtSe-0007Hr-DA for ltru@lists.ietf.org; Tue, 17 Apr 2007 21:35:32 +0200 Received: from d255054.dialin.hansenet.de ([80.171.255.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 21:35:32 +0200 Received: from nobody by d255054.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 21:35:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 17 Apr 2007 21:34:16 +0200 Organization: Lines: 10 Message-ID: <46252138.6771@xyzzy.claranet.de> References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255054.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] OT (was: "mis" update review request) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > @font-face { font-family: Wingdings; } @font-face { font-family: > SimSun; } @font-face { font-family: Cambria Math; } @font-face { > font-family: Calibri; } @font-face { font-family: Tahoma; } @font-face > { font-family: @SimSun; } @page Section1 {size: 8.5in 11.0in; margin: And so on, followed by top-posting. Is this a kind of joke wrt "zxx", or did Mark's HTML trigger the "use same format" default of some UAs ? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 15:56: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 1HdtmS-0000yU-0H; Tue, 17 Apr 2007 15:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtmR-0000yP-57 for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:55:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtmP-00043G-Qw for ltru@lists.ietf.org; Tue, 17 Apr 2007 15:55:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdtmF-0002AC-LF for ltru@lists.ietf.org; Tue, 17 Apr 2007 21:55:47 +0200 Received: from d255054.dialin.hansenet.de ([80.171.255.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 21:55:47 +0200 Received: from nobody by d255054.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Apr 2007 21:55:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 17 Apr 2007 21:53:04 +0200 Organization: Lines: 19 Message-ID: <462525A0.6B9@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255054.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: changing personal list options X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > would someone be kind enough to point to where one can find the > online facility for changing LTRU options Look into the header, minus "mailto:" links (also working for this purpose, maybe check out the List-Help: address) I find: | List-Id: Language Tag Registry Update working group discussion list | | List-Unsubscribe: | List-Archive: | List-Subscribe: The "mailman" links are what you want (you'll need your password). BTW, as far as I know Harald is not the author of "mailman". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 16:44: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 1HduXR-0004A0-EN; Tue, 17 Apr 2007 16:44:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduXQ-00049t-FS for ltru@lists.ietf.org; Tue, 17 Apr 2007 16:44:32 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HduXO-0001aq-8J for ltru@lists.ietf.org; Tue, 17 Apr 2007 16:44:32 -0400 Received: from [10.72.72.44] (snvvpn1-10-72-72-c44.corp.yahoo.com [10.72.72.44]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3HKi4Mo049881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 13:44: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=XeR49ovw+ErxEzrXo+sH+T1hTBSeJmFv4CZfWkm4ETJ6nDp7ZqRpudx3kWjlQCbT Message-ID: <46253193.3070503@yahoo-inc.com> Date: Tue, 17 Apr 2007 13:44:03 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: "mis" update review request References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> In-Reply-To: <20070417173447.GA3783@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Moreover, it would be really good to add some comments at the very top with >> a warning that many of the items cannot be understood simply from the data >> file, and point people to the URL for more discussion. > > Unfortunately the format makes no provision for such comments. > But there is no reason that this cannot be rectified, perhaps by borrowing the text from draft-phillips-record-jar. I still don't know why there was opposition to file-level commenting in the 3066bis era. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 17:26: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 1HdvBk-0005Nv-JR; Tue, 17 Apr 2007 17:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvBj-0005Mi-LI for ltru@lists.ietf.org; Tue, 17 Apr 2007 17:26:11 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdvBi-0007w3-Ay for ltru@lists.ietf.org; Tue, 17 Apr 2007 17:26:11 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1947073wra for ; Tue, 17 Apr 2007 14:26:10 -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=cLk6a2vb++2tEwbFzC+otcs1K2Jp3Wpu0htyMtX419iSIsWKu6RFd3sF23cEk+d3hJCEe6v67mZ/Q9NNfPstVw4VTRhoQr03edBK02fSHCQamAzjZj2MrxEh1/9aGCYDaceUj1xuLpYo68fWOYZbV6wNIqyTJB8bxVq5i0oLW4s= 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=k33VQzRV6ZDPO3jVlWHTQvVZjY8JQ6SAx9LptK8Qk0U3VYX+XXAeUVDcqA0LnQJAGsNKFFO7hjuH3h2nIf6w7GwkwCTXxspNX9TtO6GyZhKFrOhYeEYQeVEh/qD5cBTpRLmj2xp3GuxCLQOgt9ByeWgTXlBKaOCTSn87H7hVv8s= Received: by 10.114.204.13 with SMTP id b13mr523266wag.1176845168862; Tue, 17 Apr 2007 14:26:08 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 14:26:08 -0700 (PDT) Message-ID: <30b660a20704171426w7883380av10a9127dac3c98d3@mail.gmail.com> Date: Tue, 17 Apr 2007 14:26:08 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <46253193.3070503@yahoo-inc.com> MIME-Version: 1.0 References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> <46253193.3070503@yahoo-inc.com> X-Google-Sender-Auth: d7d20e08330d4fbe X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0287296266==" Errors-To: ltru-bounces@ietf.org --===============0287296266== Content-Type: multipart/alternative; boundary="----=_Part_86363_25491254.1176845168189" ------=_Part_86363_25491254.1176845168189 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On 4/17/07, Addison Phillips wrote: > > > > John Cowan wrote: > >> Moreover, it would be really good to add some comments at the very top > with > >> a warning that many of the items cannot be understood simply from the > data > >> file, and point people to the URL for more discussion. > > > > Unfortunately the format makes no provision for such comments. > > > > But there is no reason that this cannot be rectified, perhaps by > borrowing the text from draft-phillips-record-jar. I still don't know > why there was opposition to file-level commenting in the 3066bis era. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > -- Mark ------=_Part_86363_25491254.1176845168189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1

On 4/17/07, Addison Phillips <addison@yahoo-inc.com> wrote:


John Cowan wrote:
>> Moreover, it would be really good to add some comments at the very top with
>> a warning that many of the items cannot be understood simply from the data
>> file, and point people to the URL for more discussion.
>
> Unfortunately the format makes no provision for such comments.
>

But there is no reason that this cannot be rectified, perhaps by
borrowing the text from draft-phillips-record-jar. I still don't know
why there was opposition to file-level commenting in the 3066bis era.

Addison

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

Internationalization is an architecture.
It is not a feature.



--
Mark ------=_Part_86363_25491254.1176845168189-- --===============0287296266== 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 --===============0287296266==-- From ltru-bounces@ietf.org Tue Apr 17 17:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvaq-0001uL-KS; Tue, 17 Apr 2007 17:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvao-0001uD-T4 for ltru@lists.ietf.org; Tue, 17 Apr 2007 17:52:06 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdvan-0000sO-Js for ltru@lists.ietf.org; Tue, 17 Apr 2007 17:52:06 -0400 Received: from c83-248-99-122.bredband.comhem.se ([83.248.99.122]:4580 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hdvam-000883-9V; Tue, 17 Apr 2007 23:52:05 +0200 From: "Kent Karlsson" To: "'Frank Ellermann'" , References: <462525A0.6B9@xyzzy.claranet.de> Subject: RE: [Ltru] Re: changing personal list options Date: Tue, 17 Apr 2007 23:54:26 +0200 Message-ID: <000301c7813a$fbd05810$7a63f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <462525A0.6B9@xyzzy.claranet.de> Thread-Index: AceBKmz1omQzfH/KRiesN5Fvj6LHdgAD/D4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hdvam-000883-9V. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hdvam-000883-9V 96d247647f4a6e8eaa65235e0982e234 X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Tuesday, April 17, 2007 9:53 PM > To: ltru@lists.ietf.org > Subject: [Ltru] Re: changing personal list options > > (I think some spam filter somewhere is blanking out the content of several emails I get (better than deleting them altogether, but still), not just the ones on the LTRU list. So, quoting from the archive instead) Kent Karlsson wrote: > @font-face { font-family: Wingdings; } @font-face { font-family: > SimSun; } @font-face { font-family: Cambria Math; } @font-face { > font-family: Calibri; } @font-face { font-family: Tahoma; } @font-face > { font-family: @SimSun; } @page Section1 {size: 8.5in 11.0in; margin: And so on, followed by top-posting. Is this a kind of joke wrt "zxx", or did Mark's HTML trigger the "use same format" default of some UAs ? -------------- Eeh, no joke. Both Mark's and my email were HTML e-mails, and yes to the latter. I just did "reply" and started replying... /k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 17 20:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy77-0002G9-Qh; Tue, 17 Apr 2007 20:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy77-0002G4-6Z for ltru@lists.ietf.org; Tue, 17 Apr 2007 20:33:37 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdy74-0006Q9-VQ for ltru@lists.ietf.org; Tue, 17 Apr 2007 20:33:37 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 17 Apr 2007 17:33:34 -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; Tue, 17 Apr 2007 17:33:33 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Tue, 17 Apr 2007 17:33:27 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoA== Message-ID: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> In-Reply-To: <00a201c78124$0713eaa0$7a63f853@streamserve.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: f1d8e5e632fcbbb13bf46ebb1d552b4e Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1150088459==" Errors-To: ltru-bounces@ietf.org --===============1150088459== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBB6ANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBB6ANAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 1: I disagree: taking "other" out of mis is a categorical change - it cr= eates a completely different concept, because the heart of the concept of m= is is "other". On 1b ("language" vs. "languages"): I disagree: while the content tagged is= in a single language, the concept that the ID represents is a collection o= f languages. The ID represents that concept, not the content; we associate = the ID with the content to indicate an association of the concept with the = content. On 4: Again, I disagree. This is like saying, "It's out of scope, mostly bu= t not completely." Either it's in scope or it's out of scope. Peter From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] Sent: Tuesday, April 17, 2007 12:10 PM To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request on 1: I don't see why 'mis' would have to be an exception when doing a semantic c= hange of removing (implicit or explicit) "other" for various language codes= . Doing so is equally much a semantic change for 'tai' (or any other "other= " collection), and of exactly the same kind, so if it is not ok for 'mis' i= t would not be ok for 'tai' either. (If you prefer another acronym, say 'an= y' instead of 'mis', that is another ball-game.) Furthermore, since 'mul' is the only code intended for multiple languages (= when it is not practical to list which languages, per fragment of the docum= ent preferably), all of the "languages" codes should instead refer to "lang= uage" in singular. This would not be a semantic change, just referring to e= ach of the items that may be tagged, not a set of items [book shelf...] so = tagged. on 4: Programming languages of various sorts are out of scope (like 'zxx', but un= like 'art'), but I may agree that they are out of scope in a different way = than 'zxx'. Perhaps "formal language" ('for'), with no further subdivision = (they are still out of scope). /kent k ________________________________ From: Peter Constable [mailto:petercon@microsoft.com] Sent: Tuesday, April 17, 2007 2:19 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis is = bound to be in MARC, and (b) any existing usage would assume the context of= ISO 639-2 (i.e. mis in existing usage is the exception list for ISO 639-2)= . Re 2: The mis collection is inherently unstable - unavoidably so. Prior to = 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content a= s mis; after that date, an implementation of ISO 639-2 would have tagged Ai= nu content as ain; existing content tagged before that date would not get r= etrieved by request for ain, and it would be conformant to suppose that req= uests for mis would not return Ainu content. The mis collection is ugly, pu= re and simple. So, I don't see what the point is of getting worried over wh= ether we're making mis unstable: it's been that way for some time. (Note: mis is badly defined from a stability perspective, though I don't th= ink there's much question of how it's defined.) Re 3(b): "There are times when detection can only determine that it looks l= ike there is some linguistic content -- it is not just binary data -- but c= urrent detection can't really determine what it might be. That is, a code t= hat means "according to our best available detection methods this doesn't l= ook like it is zxx"." If you want to use mis for that, I would argue that t= hat is significantly changing the semantics of mis. (Even though mis is uns= table, it is unstable on a qualitative level; this is a categorical change.= ) I definitely oppose that. If you want an ID for "undetermined human langu= age", then that should be proposed. We should not usurp an existing ID for = that purpose. Re 4: I don't see how your example differs from this: "Nous avons une phras= e en fran=E7ais (but this is in English)". The fact that the parenthetical = text is in English doesn't change the fact that the other text is in French= . Similarly, in your example, the fact that there is a comment in English d= oes not change the fact that the rest of the text is not in a human languag= e. Do we create tags for "French with embedded bits of English"? Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request 1. I think we have to be very careful here. The meaning of a standard like = ISO 639-2 is established not by what we wish it would have said, nor by wha= t we would find out if we were able to read Peter's mind. It is established= by the wording in the standard, and how reasonable people could interpret = it. The fact that "mis" was incorporated in order to account for MARC codes= is interesting, but is not in the text of the standard. We can't expect us= ers of BCP 47 to all be able to read Peter's mind before tagging. 2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we = will not change the meaning of a tag out from under them. So clarifications= that we add in future versions of 4646 or the registry are fine, as long a= s they do not narrow the range of reasonable interpretations. We can broade= n them. So in the case of "mis", a proposed narrowing to include just the M= ARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 a= t the time that "mis" was added to the language registry (the BCP 47 semant= ics are established at the time we add the code). That is one of the key pr= inciples of BCP 47, is to isolate us where necessary from instabilities in = the source standards. (The one exception we might be able to make is where something is so badly = defined that most reasonable people couldn't come up with any consistent de= finition for it.) 3. Now, I think there are steps that can be taken to make the above moot. I= think Peter's suggestion for ISO 639-X of broadening all of the Collection= s to remove the (Other) is exactly the right strategy, and if this can be d= one before 4646bis is issued, all the better. So having * aus Australian languages means any of the languages on http://www.e= thnologue.com/show_family.asp?subid=3D90498 * bat Baltic (Other) =3D> Baltic languages, means any of the language= s on http://www.ethnologue.com/show_family.asp?subid=3D90207 * mis Miscellaneous languages, essentially the root for http://www.et= hnologue.com/family_index.asp and so on. This is useful on a number of levels; it resolves a number of pr= oblems in the interpretation of language codes, and makes the source standa= rds themselves more stable. (In the ideal case, we would have codes for eac= h of the possible "decision points" in the language tree. That is, if we lo= ok at any language code such as http://www.ethnologue.com/show_lang_family.= asp?code=3Deng we'd have codes for each of the parent groupings, not just s= ome of them, like "Australian languages".) 3. Randy raised the issue as to whether "mis" in the broad sense is useful = (as something that has linguistic content, but I don't know what it is). It= very much follows the model in #3. There are times when detection can only= determine that it looks like there is some linguistic content -- it is not= just binary data -- but current detection can't really determine what it m= ight be. That is, a code that means "according to our best available detect= ion methods this doesn't look like it is zxx". 4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) { /= * remove the item in the lookup table */ ...}". Maybe we need another code = for this, something different than either 'art' or 'zxx'. Mark On 4/14/07, Peter Constable > wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the lan= guage identity is not determined, and the appropriate tag for that is und. = Appropriate use of mis does not require that one know the language of the c= ontent; it does, however, require that one know it is *not* a language cove= red by any of the available tags. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBB6ANAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On 1: I disagree: taking “other” out of mis is a categorical change – it creates a completely different concept, becau= se the heart of the concept of mis is “other”.

 

On 1b (“language” vs. “languages”): = I disagree: while the content tagged is in a single language, the concept tha= t the ID represents is a collection of languages. The ID represents that conc= ept, not the content; we associate the ID with the content to indicate an associ= ation of the concept with the content.

 

On 4: Again, I disagree. This is like saying, “It̵= 7;s out of scope, mostly but not completely.” Either it’s in scope = or it’s out of scope.

 

 

Peter

 

From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]
Sent: Tuesday, April 17, 2007 12:10 PM
To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request

 

on 1:

 

I don't see why 'mis' would have to be an exception when doing a semantic cha= nge of removing (implicit or explicit) "other" for various language codes. Doing so is equally much a semantic change for 'tai' (or any other "other" collection), and of exactly the same kind, so if it is no= t ok for 'mis' it would not be ok for 'tai' either. (If you prefer another acron= ym, say 'any' instead of 'mis', that is another ball-game.)

 

Furthermore, since 'mul' is the only code intended for multiple languages (when it is no= t practical to list which languages, per fragment of the document preferably)= , all of the "languages" codes should instead refer to "language" in singular. Thi= s would not be a semantic change, just referring to each of the items that ma= y be tagged, not a set of items [book shelf...] so tagged.

 

on 4:

 

Programming languages of various sorts are out of scope (like 'zxx', but unlike 'art'),= but I may agree that they are out of scope in a different way than 'zxx'. Perha= ps "formal language" ('for'), with no further subdivision (they are still out of scope).

 

 = ;       /kent k

 

From: Peter Constable [mailto:petercon@microsoft.com]
Sent: Tuesday, April 17, 2007 2:19 AM
To: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update review request=

Re 1: Yes, be careful: (a) the majority of existing legacy u= sage of mis is bound to be in MARC, and (b) any existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the exception list for = ISO 639-2).

 

Re 2: The mis collection is inherently unstable – unavoidably so. Prior to 2005-08-16, an implementation of ISO 639-2 would h= ave tagged Ainu content as mis; after that date, an implementation of ISO 639-2 would have tagged Ainu content as ain; existing content tagged before that = date would not get retrieved by request for ain, and it would be conformant to suppose that requests for mis would not return Ainu content. The mis collec= tion is ugly, pure and simple. So, I don’t see what the point is of gettin= g worried over whether we’re making mis unstable: it’s been that = way for some time.

 

(Note: mis is badly defined from a stability perspective, th= ough I don’t think there’s much question of how it’s defined.)=

 

Re 3(b): “There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection = methods this doesn't look like it is zxx".” If you want to us= e mis for that, I would argue that that is significantly changing the semanti= cs of mis. (Even though mis is unstable, it is unstable on a qualitative level= ; this is a categorical change.) I definitely oppose that. If you want an ID = for “undetermined human language”, then that should be proposed. We should not usurp an existing ID for that purpose.

 

Re 4: I don’t see how your example differs from this: “Nous avons une phrase en fran=E7ais (but this is in English)”.= The fact that the parenthetical text is in English doesn’t change the fac= t that the other text is in French. Similarly, in your example, the fact that there is a comment in English does not change the fact that the rest of the= text is not in a human language. Do we create tags for “French with embedd= ed bits of English”?

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, April 16, 2007 3:49 PM
To: Peter Constable
Cc: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update review request

 

1. I think we have to be very careful here. The meanin= g of a standard like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's mind. It is established by the wording in the standard, and how reasona= ble people could interpret it. The fact that "mis" was incorporated i= n order to account for MARC codes is interesting, but is not in the text of t= he standard. We can't expect users of BCP 47 to all be able to read Peter's mi= nd before tagging.

2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we wil= l not change the meaning of a tag out from under them. So clarifications that= we add in future versions of 4646 or the registry are fine, as long as they do= not narrow the range of reasonable interpretations. We can broaden them. So in = the case of "mis", a proposed narrowing to include just the MARC code= s is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time th= at "mis" was added to the language registry (the BCP 47 semantics ar= e established at the time we add the code). That is one of the key principles= of BCP 47, is to isolate us where necessary from instabilities in the source standards.

(The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.)

3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections= to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having

and so on. This is usef= ul on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In = the ideal case, we would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as http://www.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them, li= ke "Australian languages".)

3. Randy raised the issue as to whether "mis" in the broad sense = is useful (as something that has linguistic content, but I don't know what it = is). It very much follows the model in #3. There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".

4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) = { /* remove the item in the lookup table */ ...}". Maybe we need another co= de for this, something different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter Constabl= e <petercon@microsoft.com>= ; wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]


> I find it very hard to believe that a reasonable analysis
> (whether done by human or machine) would classify a text a
> being "mis" without being able to recognize which of the
> languages in that grouping the text belonged to.  I can
> believe someone could look at text and say "it's a slavic
> language, but I'm not sure which one."  Do we really th= ink
> someone or something would look at some text and say "it's
> Ainu, Andamanese, or Etruscan, but I can't tell which, so
> I'll tag it 'mis'"?

If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the langu= age identity is not determined, and the appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, require that one know it is *not* a language cov= ered by any of the available tags.



Peter

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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBB6ANAEXMSGC117re_-- --===============1150088459== 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 --===============1150088459==-- From ltru-bounces@ietf.org Tue Apr 17 22:24: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 1HdzqB-0005QH-EJ; Tue, 17 Apr 2007 22:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdzq9-0005MG-Pj for ltru@lists.ietf.org; Tue, 17 Apr 2007 22:24:13 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdzq8-0003X5-CS for ltru@lists.ietf.org; Tue, 17 Apr 2007 22:24:13 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 17 Apr 2007 19:24:11 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Tue, 17 Apr 2007 19:24:11 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Tue, 17 Apr 2007 19:24:06 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAD3ZeA Message-ID: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0528493620==" Errors-To: ltru-bounces@ietf.org --===============0528493620== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBBC7NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBBC7NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I continue to see comments in this thread in which people are trying to str= etch the semantic of mis or zxx or und to cover some pet scenario. As long = as we keep stretching these to mean concepts that are slightly (or entirely= ) different from what they were intended to be - semantics that IMO are fai= rly straight forward once stated - then we're going to continue debating wh= at that should mean, and that portends that users will *never understand ou= r intent and use them consistently. We should simply take them for what they are. If we need concepts that are = different, then we can consider identifiers to represent those concepts. Peter --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBBC7NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I continue to see comments in this thread in which people ar= e trying to stretch the semantic of mis or zxx or und to cover some pet scena= rio. As long as we keep stretching these to mean concepts that are slightly (or entirely) different from what they were intended to be – semantics th= at IMO are fairly straight forward once stated – then we’re going = to continue debating what that should mean, and that portends that users will = *never understand our intent and use them consistently.

 

We should simply take them for what they are. If we need concepts that are different, then we can consider identifiers to represent those concepts.

 

 

Peter

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBBC7NAEXMSGC117re_-- --===============0528493620== 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 --===============0528493620==-- From ltru-bounces@ietf.org Tue Apr 17 22:37: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 1He03G-00032M-8M; Tue, 17 Apr 2007 22:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He03E-00032H-Qy for ltru@lists.ietf.org; Tue, 17 Apr 2007 22:37:44 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He03D-0005EP-Fi for ltru@lists.ietf.org; Tue, 17 Apr 2007 22:37:44 -0400 Received: by wr-out-0506.google.com with SMTP id 76so12229wra for ; Tue, 17 Apr 2007 19:37:42 -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=Q250OGTNEsDyCnURWIfWtLZnhDrlrLgWt+HbT8i0Lo0BjEd2L0iVJJ7Bfnk7uzkNb8TWyPt98aWlezvLd5mdA6mrSmH3pNEPesehvrQBkryquNAcoLIGkNwXseHsYr3GFrxrfnDYJvytk4+8pseOOIyA7aNHmmKMVOOD19qq12k= 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=OGe1IN+fwmD14bf+utBWjf3Y6/SfUo3Aiuavy61DJmjqQuPZoWNsRNeFSR0dlOyuMpF+iZul2LCYMGbvDxaK5ShnJYNSqnc55qDVduogkrwnHk6oH+A+/1hogvccJTvKGbcsmYX+uHN8/GGix/M8Luv4+aohdyHCx678VNAXdSk= Received: by 10.114.185.8 with SMTP id i8mr19905waf.1176863862229; Tue, 17 Apr 2007 19:37:42 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 19:37:41 -0700 (PDT) Message-ID: <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> Date: Tue, 17 Apr 2007 19:37:41 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> X-Google-Sender-Auth: 55b6efc1d6fd6ad5 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "ietf-languages@iana.org" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649043745==" Errors-To: ltru-bounces@ietf.org --===============0649043745== Content-Type: multipart/alternative; boundary="----=_Part_90607_29915986.1176863861913" ------=_Part_90607_29915986.1176863861913 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline QXMgbG9uZyBhcyAid2hhdCB0aGV5IGFyZSIgbWVhbnMgYW55IHJlYXNvbmFibGUgaW50ZXJwcmV0 YXRpb24gZ2l2ZW4gYnkgYQpyZWFkaW5nIG9mIHRoZSBzdGFuZGFyZHMgaW52b2x2ZWQsIEknbSBp biBjb21wbGV0ZSBhZ3JlZW1lbnQuIElmICJ3aGF0IHRoZXkKYXJlIiBtZWFucyBhbnl0aGluZyBv dXRzaWRlIG9mIHRoZSB0ZXh0IG9mIHRoZSBzdGFuZGFyZCwgSSdkIGRpc2FncmVlLgoKVGhhdCBi ZWluZyBzYWlkLCBJIHJlY29nbml6ZSB0aGF0IGJyb2FkZW5pbmcgJ21pcycgd291bGQgYmUgYSBj aGFuZ2UgZnJvbQp0aGUgY3VycmVudCBzdGFuZGFyZCwgYW5kIHdoaWxlIGFsbG93YWJsZSwgYXMg SSBzYWlkIEknbSB3aWxsaW5nIHRvIGdpdmUgdXAKb24gdGhhdC4gKEhvd2V2ZXIsIHlvdXIgdXNp bmcgInBldCBzY2VuYXJpbyIgdG8gY2hhcmFjdGVyaXplIHNvbWV0aGluZyB0aGF0CkkgYW5kIG1h bnkgb3RoZXJzIGNvbnNpZGVyICJpbXBvcnRhbnQgc2NlbmFyaW8iLCBsaWtlIGxhbmd1YWdlIGRl dGVjdGlvbiwgaXMKdW5uZWNlc3NhcnkuKQoKTWFyawoKT24gNC8xNy8wNywgUGV0ZXIgQ29uc3Rh YmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToKPgo+ICBJIGNvbnRpbnVlIHRvIHNl ZSBjb21tZW50cyBpbiB0aGlzIHRocmVhZCBpbiB3aGljaCBwZW9wbGUgYXJlIHRyeWluZyB0bwo+ IHN0cmV0Y2ggdGhlIHNlbWFudGljIG9mIG1pcyBvciB6eHggb3IgdW5kIHRvIGNvdmVyIHNvbWUg cGV0IHNjZW5hcmlvLiBBcwo+IGxvbmcgYXMgd2Uga2VlcCBzdHJldGNoaW5nIHRoZXNlIHRvIG1l YW4gY29uY2VwdHMgdGhhdCBhcmUgc2xpZ2h0bHkgKG9yCj4gZW50aXJlbHkpIGRpZmZlcmVudCBm cm9tIHdoYXQgdGhleSB3ZXJlIGludGVuZGVkIHRvIGJlIOKAkyBzZW1hbnRpY3MgdGhhdCBJTU8K PiBhcmUgZmFpcmx5IHN0cmFpZ2h0IGZvcndhcmQgb25jZSBzdGF0ZWQg4oCTIHRoZW4gd2UncmUg Z29pbmcgdG8gY29udGludWUKPiBkZWJhdGluZyB3aGF0IHRoYXQgc2hvdWxkIG1lYW4sIGFuZCB0 aGF0IHBvcnRlbmRzIHRoYXQgdXNlcnMgd2lsbCAqbmV2ZXIKPiB1bmRlcnN0YW5kIG91ciBpbnRl bnQgYW5kIHVzZSB0aGVtIGNvbnNpc3RlbnRseS4KPgo+Cj4KPiBXZSBzaG91bGQgc2ltcGx5IHRh a2UgdGhlbSBmb3Igd2hhdCB0aGV5IGFyZS4gSWYgd2UgbmVlZCBjb25jZXB0cyB0aGF0IGFyZQo+ IGRpZmZlcmVudCwgdGhlbiB3ZSBjYW4gY29uc2lkZXIgaWRlbnRpZmllcnMgdG8gcmVwcmVzZW50 IHRob3NlIGNvbmNlcHRzLgo+Cj4KPgo+Cj4KPiBQZXRlcgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0cnVA aWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4K PgoKCi0tIApNYXJrCg== ------=_Part_90607_29915986.1176863861913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QXMgbG9uZyBhcyAmcXVvdDt3aGF0IHRoZXkgYXJlJnF1b3Q7IG1lYW5zIGFueSByZWFzb25hYmxl IGludGVycHJldGF0aW9uIGdpdmVuIGJ5IGEgcmVhZGluZyBvZiB0aGUgc3RhbmRhcmRzIGludm9s dmVkLCBJJiMzOTttIGluIGNvbXBsZXRlIGFncmVlbWVudC4gSWYgJnF1b3Q7d2hhdCB0aGV5IGFy ZSZxdW90OyBtZWFucyBhbnl0aGluZyBvdXRzaWRlIG9mIHRoZSB0ZXh0IG9mIHRoZSBzdGFuZGFy ZCwgSSYjMzk7ZCBkaXNhZ3JlZS4KPGJyPjxicj5UaGF0IGJlaW5nIHNhaWQsIEkgcmVjb2duaXpl IHRoYXQgYnJvYWRlbmluZyAmIzM5O21pcyYjMzk7IHdvdWxkIGJlIGEgY2hhbmdlIGZyb20gdGhl IGN1cnJlbnQgc3RhbmRhcmQsIGFuZCB3aGlsZSBhbGxvd2FibGUsIGFzIEkgc2FpZCBJJiMzOTtt IHdpbGxpbmcgdG8gZ2l2ZSB1cCBvbiB0aGF0LiAoSG93ZXZlciwgeW91ciB1c2luZyAmcXVvdDtw ZXQgc2NlbmFyaW8mcXVvdDsgdG8gY2hhcmFjdGVyaXplIHNvbWV0aGluZyB0aGF0IEkgYW5kIG1h bnkgb3RoZXJzIGNvbnNpZGVyICZxdW90O2ltcG9ydGFudCBzY2VuYXJpbyZxdW90OywgbGlrZSBs YW5ndWFnZSBkZXRlY3Rpb24sIGlzIHVubmVjZXNzYXJ5LikKPGJyPjxicj5NYXJrPGJyPjxicj48 ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNC8xNy8wNywgPGIgY2xhc3M9ImdtYWls X3NlbmRlcm5hbWUiPlBldGVyIENvbnN0YWJsZTwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRl cmNvbkBtaWNyb3NvZnQuY29tIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4 OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiIGxhbmc9IkVOLVVTIj4KCjxkaXY+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkkgY29udGludWUgdG8gc2VlIGNvbW1lbnRz IGluIHRoaXMgdGhyZWFkIGluIHdoaWNoIHBlb3BsZSBhcmUKdHJ5aW5nIHRvIHN0cmV0Y2ggdGhl IHNlbWFudGljIG9mIG1pcyBvciB6eHggb3IgdW5kIHRvIGNvdmVyIHNvbWUgcGV0IHNjZW5hcmlv LgpBcyBsb25nIGFzIHdlIGtlZXAgc3RyZXRjaGluZyB0aGVzZSB0byBtZWFuIGNvbmNlcHRzIHRo YXQgYXJlIHNsaWdodGx5IChvcgplbnRpcmVseSkgZGlmZmVyZW50IGZyb20gd2hhdCB0aGV5IHdl cmUgaW50ZW5kZWQgdG8gYmUg4oCTIHNlbWFudGljcyB0aGF0CklNTyBhcmUgZmFpcmx5IHN0cmFp Z2h0IGZvcndhcmQgb25jZSBzdGF0ZWQg4oCTIHRoZW4gd2UncmUgZ29pbmcgdG8KY29udGludWUg ZGViYXRpbmcgd2hhdCB0aGF0IHNob3VsZCBtZWFuLCBhbmQgdGhhdCBwb3J0ZW5kcyB0aGF0IHVz ZXJzIHdpbGwgKm5ldmVyCnVuZGVyc3RhbmQgb3VyIGludGVudCBhbmQgdXNlIHRoZW0gY29uc2lz dGVudGx5Ljwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPldlIHNob3VsZCBzaW1w bHkgdGFrZSB0aGVtIGZvciB3aGF0IHRoZXkgYXJlLiBJZiB3ZSBuZWVkCmNvbmNlcHRzIHRoYXQg YXJlIGRpZmZlcmVudCwgdGhlbiB3ZSBjYW4gY29uc2lkZXIgaWRlbnRpZmllcnMgdG8gcmVwcmVz ZW50CnRob3NlIGNvbmNlcHRzLjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZu YnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiPlBldGVyPC9zcGFuPjwvcD4KCjwvZGl2PgoKPC9kaXY+CgoKPGJy Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkx0cnUg bWFpbGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9y ZzwvYT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZl bnQsdGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUiIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydTwvYT48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwi Pjxicj4tLSA8YnI+TWFyawo= ------=_Part_90607_29915986.1176863861913-- --===============0649043745== 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 --===============0649043745==-- From ltru-bounces@ietf.org Wed Apr 18 01:17: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 1He2Xy-0005Jp-D3; Wed, 18 Apr 2007 01:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2Xw-0005Ic-MH for ltru@ietf.org; Wed, 18 Apr 2007 01:17:36 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2Wc-00084T-Tu for ltru@ietf.org; Wed, 18 Apr 2007 01:16:16 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1He2Wc-0005Xz-Kr; Wed, 18 Apr 2007 01:16:14 -0400 Date: Wed, 18 Apr 2007 01:16:14 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070418051614.GB22912@mercury.ccil.org> References: <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > As long as "what they are" means any reasonable interpretation given > by a reading of the standards involved, I'm in complete agreement. If > "what they are" means anything outside of the text of the standard, > I'd disagree. Not *any* reasonable interpretation, and the nature of ISO 639 (and 3166 and 15924) is that the semantics of the code elements mostly lies outside the standard. -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; cowan@ccil.org Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 01:18: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 1He2YJ-0005Ll-TA; Wed, 18 Apr 2007 01:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2YI-0005Lb-2w for ltru@lists.ietf.org; Wed, 18 Apr 2007 01:17:58 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2VG-0007D8-7T for ltru@lists.ietf.org; Wed, 18 Apr 2007 01:14:51 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1He2V6-0005N1-8i; Wed, 18 Apr 2007 01:14:40 -0400 Date: Wed, 18 Apr 2007 01:14:40 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070418051440.GA22912@mercury.ccil.org> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> <46253193.3070503@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46253193.3070503@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > But there is no reason that this cannot be rectified, perhaps by > borrowing the text from draft-phillips-record-jar. I still don't know > why there was opposition to file-level commenting in the 3066bis era. It's not clear how to maintain it vis-a-vis IANA. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 02:50: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 1He3zd-0008Qo-GO; Wed, 18 Apr 2007 02:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3zc-0008QU-49 for ltru@ietf.org; Wed, 18 Apr 2007 02:50:16 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He3zZ-00037s-My for ltru@ietf.org; Wed, 18 Apr 2007 02:50:16 -0400 Received: by wr-out-0506.google.com with SMTP id 71so49360wri for ; Tue, 17 Apr 2007 23:50:13 -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=TR7BBg2ZJaYSYm0vzlJBRbXot2lUHH/dqcVq8MosKn0RlmCuBybE/7a8jl4iOCBN1dVK9A5HzKI8nhyMhJDIZDz7mb0ESSAardiNTmp18ltsyiIPP8OY+Lz5/Ep62ijf8n5b244Yiqk+G0P5zcHrTfVG0ugTGzSVcIlZTKpaH/s= 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=ugM+trpU+b5jAj7Iwhy1tK7FQXZSVeQsAdnSvmDJ687VvXkzUu+Wjv77z/8bHfAWPAx+B6goPjLovHSZ8cvbFaEPd+46UebL0/rZu5q2Fu1/HL0uU6ytas8J9iocL6Yo1aWpSv/tEJMsDabyfQfEwE63Q77Lxw7diy1piUpE5X0= Received: by 10.114.137.2 with SMTP id k2mr59219wad.1176879012958; Tue, 17 Apr 2007 23:50:12 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 23:50:12 -0700 (PDT) Message-ID: <30b660a20704172350n1728045eh38b4ac339724ff09@mail.gmail.com> Date: Tue, 17 Apr 2007 23:50:12 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <20070418051614.GB22912@mercury.ccil.org> MIME-Version: 1.0 References: <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <20070418051614.GB22912@mercury.ccil.org> X-Google-Sender-Auth: f1b6d9ef6ffa3515 X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1825198608==" Errors-To: ltru-bounces@ietf.org --===============1825198608== Content-Type: multipart/alternative; boundary="----=_Part_93623_22914701.1176879012550" ------=_Part_93623_22914701.1176879012550 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I said "standards involved". With an "s". That includes the source standards. And I mean "any reasonable interpretation", not "any interpretation, reasonable or unreasonable", not an "average interpretation", not a "misinformed interpretation". The customary norms for interpretation of contracts, standards, and other formal documents is based on what a "reasonable" person could interpret the text as meaning. I really don't understand your position on this. When I say that I follow a standard, like the XML standard, I have to follow what the standard actually says, not what someone wishes it had said. If it says "[#x7F-#x84]" that's what it means. A stance that I can just interpret the standard according to what I think the authors had in mind, rather than what the text actually says, makes any notion of compliance -- even in good faith -- completely meaningless. If that were the case we might as well write any damn thing we want in 4646bis, since users of the standard could interpret it pretty much any way they would want to anyway. If the standard (in this case, ISO 639-2) says "Baltic languages", that's what it means. Not "Other Baltic languages", not "Baltic languages except for ones starting with the letter L", but "Baltic languages". And if I see "Baltic languages (Other)" that is clearly meant to be an exclusion of some kind. That doesn't mean that a standard is holy writ. There are always mistakes, and always corrections and clarifications that may be added to a future version. But whenever the new text narrows the interpretation from what it could reasonably be interpreted as in the previous version, then that is a compatibility breakage. It needs to be recognized as such. And any decision to take such a step that breaks backwards compatibility has to be a deliberate, considered decision -- especially when one of of the primary goals of a standard like BCP 47 is stability. Mark On 4/17/07, John Cowan wrote: > Mark Davis scripsit: > > > As long as "what they are" means any reasonable interpretation given > > by a reading of the standards involved, I'm in complete agreement. If > > "what they are" means anything outside of the text of the standard, > > I'd disagree. > > Not *any* reasonable interpretation, and the nature of ISO 639 (and > 3166 and 15924) is that the semantics of the code elements mostly > lies outside the standard. > > -- > Knowledge studies others / Wisdom is self-known; John Cowan > Muscle masters brothers / Self-mastery is bone; cowan@ccil.org > Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan > Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) > -- Mark ------=_Part_93623_22914701.1176879012550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I said "standards involved". With an "s". That includes the source standards. And I mean "any reasonable interpretation", not "any interpretation, reasonable or unreasonable", not an "average interpretation", not a "misinformed interpretation". The customary norms for interpretation of contracts, standards, and other formal documents is based on what a "reasonable" person could interpret the text as meaning.

I really don't understand your position on this. When I say that I follow a standard, like the XML standard, I have to follow what the standard actually says, not what someone wishes it had said. If it says "[#x7F-#x84]" that's what it means. A stance that I can just interpret the standard according to what I think the authors had in mind, rather than what the text actually says, makes any notion of compliance -- even in good faith -- completely meaningless. If that were the case we might as well write any damn thing we want in 4646bis, since users of the standard could interpret it pretty much any way they would want to anyway.

If the standard (in this case, ISO 639-2) says "Baltic languages", that's what it means. Not "Other Baltic languages", not "Baltic languages except for ones starting with the letter L", but "Baltic languages". And if I see "Baltic languages (Other)" that is clearly meant to be an exclusion of some kind.

That doesn't mean that a standard is holy writ. There are always mistakes, and always corrections and clarifications that may be added to a future version. But whenever the new text narrows the interpretation from what it could reasonably be interpreted as in the previous version, then that is a compatibility breakage. It needs to be recognized as such. And any decision to take such a step that breaks backwards compatibility has to be a deliberate, considered decision -- especially when one of of the primary goals of a standard like BCP 47 is stability.

Mark

On 4/17/07, John Cowan <cowan@ccil.org > wrote:
> Mark Davis scripsit:
>
> > As long as "what they are" means any reasonable interpretation given
> > by a reading of the standards involved, I'm in complete agreement. If
> > "what they are" means anything outside of the text of the standard,
> > I'd disagree.
>
> Not *any* reasonable interpretation, and the nature of ISO 639 (and
> 3166 and 15924) is that the semantics of the code elements mostly
> lies outside the standard.
>
> --
> Knowledge studies others / Wisdom is self-known;      John Cowan
> Muscle masters brothers / Self-mastery is bone;       cowan@ccil.org
> Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
> Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)
>



--
Mark ------=_Part_93623_22914701.1176879012550-- --===============1825198608== 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 --===============1825198608==-- From ltru-bounces@ietf.org Wed Apr 18 04:14: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 1He5JB-0003Kb-SD; Wed, 18 Apr 2007 04:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5J9-0003H5-Vv for ltru@lists.ietf.org; Wed, 18 Apr 2007 04:14:31 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5J6-0008Ii-Br for ltru@lists.ietf.org; Wed, 18 Apr 2007 04:14:31 -0400 Received: from c83-248-96-194.bredband.comhem.se ([83.248.96.194]:3630 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1He5J2-00050P-7O; Wed, 18 Apr 2007 10:14:27 +0200 From: "Kent Karlsson" To: "'Peter Constable'" , , References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><00a201c78124$0713eaa0$7a63f853@streamserve.com> Subject: RE: [Ltru] Re: "mis" update review request Date: Wed, 18 Apr 2007 10:16:39 +0200 Message-ID: <005001c78191$ec1468b0$7a63f853@streamserve.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAPTTEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1He5J2-00050P-7O. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1He5J2-00050P-7O 087571a2ff9464eafa65a910d372da5e X-Spam-Score: 1.8 (+) X-Scan-Signature: eda4528ec6326d3504ad3a985d220c76 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1706682721==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1706682721== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C781A2.AF9D38B0" This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C781A2.AF9D38B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1a: It is just as much a categorical change for 'tai', 'gem', etc. But = it is a change that I support, since without such a change, almost all of the collection codes would have an empty set of applicable = languages in the context of 639-3. However, if 'mis' is deprecated and replaced by a code for 'any language' (rather than = handling 'mis' like all of the other "other" codes) in the process of doing this, I'm not going to complain. To be nit-picking, all of the = collection codes should then also be replaced (but I'm not going to complain if they are not so replaced when removing the "other" = part of the semantics). Of course, it would be helpful if the standard defining the collection codes (639-4?) also gave an = explicit hierarchy of the codes (like "'tai' covers ..., ..., ..., and any Tai language not given a code"). Maybe that is the case already = (I haven't seen a draft). =20 1b: A document (or text fragment) tagged as e.g. 'tai' is supposed to be = in ONE 'tai' language, not in several 'tai' languages. So in each individual application, a collection code refers to one language, not several languages, even though the set = of languages covered by a collection code usually has more than one element (or no elements... see 1a). =20 4: So why is there a code for 'zxx' if it is out of scope? Furthermore, = 'zxx' is supposed to mean "no linguistic content", not "out of scope". =20 /kent k =20 _____ =20 From: Peter Constable [mailto:petercon@microsoft.com]=20 Sent: Wednesday, April 18, 2007 2:33 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request On 1: I disagree: taking =93other=94 out of mis is a categorical change = =96 it creates a completely different concept, because the heart of the concept of mis is =93other=94. =20 On 1b (=93language=94 vs. =93languages=94): I disagree: while the = content tagged is in a single language, the concept that the ID = represents is a collection of languages. The ID represents that concept, not the = content; we associate the ID with the content to indicate an association of the concept with the content. =20 On 4: Again, I disagree. This is like saying, =93It=92s out of scope, = mostly but not completely.=94 Either it=92s in scope or it=92s out of scope. =20 =20 Peter =20 From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]=20 Sent: Tuesday, April 17, 2007 12:10 PM To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request =20 on 1: =20 I don't see why 'mis' would have to be an exception when doing a = semantic change of removing (implicit or explicit) "other" for various language codes. Doing so is equally much a semantic change for = 'tai' (or any other "other" collection), and of exactly the same kind, so if it is not ok for 'mis' it would not be ok for 'tai' = either. (If you prefer another acronym, say 'any' instead of 'mis', that is another ball-game.) =20 Furthermore, since 'mul' is the only code intended for multiple = languages (when it is not practical to list which languages, per fragment of the document preferably), all of the "languages" codes = should instead refer to "language" in singular. This would not be a semantic change, just referring to each of the items that may be = tagged, not a set of items [book shelf...] so tagged. =20 on 4: =20 Programming languages of various sorts are out of scope (like 'zxx', but = unlike 'art'), but I may agree that they are out of scope in a different way than 'zxx'. Perhaps "formal language" ('for'), with = no further subdivision (they are still out of scope). =20 /kent k =20 _____ =20 From: Peter Constable [mailto:petercon@microsoft.com]=20 Sent: Tuesday, April 17, 2007 2:19 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis = is bound to be in MARC, and (b) any existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the = exception list for ISO 639-2). =20 Re 2: The mis collection is inherently unstable =96 unavoidably so. = Prior to 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content as mis; after that date, an implementation of ISO = 639-2 would have tagged Ainu content as ain; existing content tagged before that date would not get retrieved by request for ain, and = it would be conformant to suppose that requests for mis would not return Ainu content. The mis collection is ugly, pure and = simple. So, I don=92t see what the point is of getting worried over whether we=92re making mis unstable: it=92s been that way for some = time. =20 (Note: mis is badly defined from a stability perspective, though I = don=92t think there=92s much question of how it=92s defined.) =20 Re 3(b): =93There are times when detection can only determine that it = looks like there is some linguistic content -- it is not just binary data -- but current detection can't really determine what it = might be. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".=94 If you = want to use mis for that, I would argue that that is significantly changing the semantics of mis. (Even though mis is = unstable, it is unstable on a qualitative level; this is a categorical change.) I definitely oppose that. If you want an ID for = =93undetermined human language=94, then that should be proposed. We should not usurp an existing ID for that purpose. =20 Re 4: I don=92t see how your example differs from this: =93Nous avons = une phrase en fran=E7ais (but this is in English)=94. The fact that the parenthetical text is in English doesn=92t change the fact that the = other text is in French. Similarly, in your example, the fact that there is a comment in English does not change the fact that the = rest of the text is not in a human language. Do we create tags for =93French with embedded bits of English=94? =20 =20 Peter =20 From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request =20 1. I think we have to be very careful here. The meaning of a standard = like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's = mind. It is established by the wording in the standard, and how reasonable people could interpret it. The fact that "mis" was = incorporated in order to account for MARC codes is interesting, but is not in the text of the standard. We can't expect users of BCP 47 = to all be able to read Peter's mind before tagging.=20 2. When we are looking at stability, that is very important: our goal is = that once content is correctly tagged, people can depend on the fact that we will not change the meaning of a tag out from under = them. So clarifications that we add in future versions of 4646 or the registry are fine, as long as they do not narrow the range of = reasonable interpretations. We can broaden them. So in the case of "mis", a proposed narrowing to include just the MARC codes is clearly = disallowed, since it was nowhere stated in ISO 639-2 at the time that "mis" was added to the language registry (the BCP 47 semantics = are established at the time we add the code). That is one of the key principles of BCP 47, is to isolate us where necessary from = instabilities in the source standards.=20 (The one exception we might be able to make is where something is so = badly defined that most reasonable people couldn't come up with any consistent definition for it.) 3. Now, I think there are steps that can be taken to make the above = moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections to remove the (Other) is exactly the right strategy, = and if this can be done before 4646bis is issued, all the better. So having=20 * aus Australian languages means any of the languages on = http://www.ethnologue.com/show_family.asp?subid=3D90498=20 * bat Baltic (Other) =3D> Baltic languages, means any of the = languages on http://www.ethnologue.com/show_family.asp?subid=3D90207=20 * mis Miscellaneous languages, essentially the root for = http://www.ethnologue.com/family_index.asp=20 and so on. This is useful on a number of levels; it resolves a number of = problems in the interpretation of language codes, and makes the source standards themselves more stable. (In the ideal case, we = would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as = http://www.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them, like = "Australian languages".)=20 3. Randy raised the issue as to whether "mis" in the broad sense is = useful (as something that has linguistic content, but I don't know what it is). It very much follows the model in #3. There are times = when detection can only determine that it looks like there is some linguistic content -- it is not just binary data -- but current = detection can't really determine what it might be. That is, a code that means "according to our best available detection methods = this doesn't look like it is zxx".=20 4. I'm leery of using zxx for programming languages, instead of just = binary. There is clearly some linguistic content in "if (content =3D=3D null) { /* remove the item in the lookup table */ ...}". = Maybe we need another code for this, something different than either 'art' or 'zxx'.=20 Mark On 4/14/07, Peter Constable wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a=20 > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think=20 > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate = use of mis. Since they do not know what it is, their declaration is that the language identity is not determined, and the = appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, = require that one know it is *not* a language covered by any of the available tags.=20 Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru = =20 --=20 Mark=20 ------=_NextPart_000_0051_01C781A2.AF9D38B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1a: It is just as much a categorical change for 'tai', 'gem',=20 etc. But it is a change that I support, since without such a = change, almost=20 all of the collection codes would have an empty set of applicable = languages in=20 the context of 639-3. However, if 'mis' is deprecated and replaced = by a=20 code for 'any language' (rather than handling 'mis' like all of the = other=20 "other" codes) in the process of doing this, I'm not going to complain. = To be=20 nit-picking, all of the collection codes should then also be replaced = (but I'm=20 not going to complain if they are not so replaced when removing the = "other" part=20 of the semantics). Of course, it would be helpful if the standard = defining the=20 collection codes (639-4?) also gave an explicit hierarchy of the codes = (like=20 "'tai' covers ..., ..., ..., and any Tai language not given a = code"). Maybe=20 that is the case already (I haven't seen a draft).
 
1b: A document (or text fragment) tagged as e.g. 'tai' is = supposed=20 to be in ONE 'tai' language, not in several 'tai' languages. So in each=20 individual application, a collection
code refers to one language, not several languages, even though = the set=20 of languages covered by a collection code usually has more than one = element (or=20 no elements... see 1a).
 
4: So why is there a code for 'zxx' if it is out of scope? = Furthermore,=20 'zxx' is supposed to mean "no linguistic content", not "out of=20 scope".
 
       =20 /kent = k
 

From: Peter Constable=20 [mailto:petercon@microsoft.com]
Sent: Wednesday, April 18, = 2007=20 2:33 AM
To: ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update = review=20 request

On=20 1: I disagree: taking =93other=94 out of mis is a categorical change = =96 it creates=20 a completely different concept, because the heart of the concept of = mis is=20 =93other=94.

 

On=20 1b (=93language=94 vs. =93languages=94): I disagree: while the content = tagged is in a=20 single language, the concept that the ID represents is a collection of = languages. The ID represents that concept, not the content; we = associate the=20 ID with the content to indicate an association of the concept with the = content.

 

On=20 4: Again, I disagree. This is like saying, =93It=92s out of scope, = mostly but not=20 completely.=94 Either it=92s in scope or it=92s out of = scope.

 

 

Peter

 

From: Kent = Karlsson=20 [mailto:kent.karlsson14@comhem.se]
Sent: Tuesday, April 17, = 2007=20 12:10 PM
To: Peter Constable; ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update = review=20 request

 

on=20 1:

 

I don't see = why 'mis'=20 would have to be an exception when doing a semantic change of removing = (implicit or explicit) "other" for various language codes. Doing so is = equally=20 much a semantic change for 'tai' (or any other "other" collection), = and of=20 exactly the same kind, so if it is not ok for 'mis' it would not be ok = for=20 'tai' either. (If you prefer another acronym, say 'any' instead of = 'mis', that=20 is another ball-game.)

 

Furthermore, = since=20 'mul' is the only code intended for multiple languages (when it is not = practical to list which languages, per fragment of the document = preferably),=20 all of the "languages" codes should instead refer to=20 "language" in singular. This would not be a = semantic=20 change, just referring to each of the items that may be tagged, not a = set of=20 items [book shelf...] so tagged.

 

on=20 4:

 

Programming = languages=20 of various sorts are out of scope (like 'zxx', but unlike 'art'), but = I may=20 agree that they are out of scope in a different way than 'zxx'. = Perhaps=20 "formal language" ('for'), with no further subdivision (they are still = out of=20 scope).

 

       =20 /kent k

 

From: Peter = Constable=20 [mailto:petercon@microsoft.com]
Sent: Tuesday, April 17, = 2007=20 2:19 AM
To: ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update = review=20 request

Re=20 1: Yes, be careful: (a) the majority of existing legacy usage of mis = is=20 bound to be in MARC, and (b) any existing usage would assume the = context of=20 ISO 639-2 (i.e. mis in existing usage is the exception list for ISO=20 639-2).

 

Re=20 2: The mis collection is inherently unstable =96 unavoidably so. = Prior to=20 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu = content as=20 mis; after that date, an implementation of ISO 639-2 would have = tagged Ainu=20 content as ain; existing content tagged before that date would not = get=20 retrieved by request for ain, and it would be conformant to suppose = that=20 requests for mis would not return Ainu content. The mis collection = is ugly,=20 pure and simple. So, I don=92t see what the point is of getting = worried over=20 whether we=92re making mis unstable: it=92s been that way for some=20 time.

 

(Note:=20 mis is badly defined from a stability perspective, though I don=92t = think=20 there=92s much question of how it=92s = defined.)

 

Re=20 3(b): =93There are times when detection can only determine = that it=20 looks like there is some linguistic content -- it is not just binary = data --=20 but current detection can't really determine what it might be. That = is, a=20 code that means "according to our best available detection methods = this=20 doesn't look like it is zxx".=94=20 If you want to use mis for that, I would argue that that is = significantly=20 changing the semantics of mis. (Even though mis is unstable, it is = unstable=20 on a qualitative level; this is a categorical change.) I definitely = oppose=20 that. If you want an ID for =93undetermined human language=94, then = that should=20 be proposed. We should not usurp an existing ID for that=20 purpose.

 

Re=20 4: I don=92t see how your example differs from this: =93Nous avons = une phrase en=20 fran=E7ais (but this is in English)=94. The fact that the = parenthetical text is=20 in English doesn=92t change the fact that the other text is in = French.=20 Similarly, in your example, the fact that there is a comment in = English does=20 not change the fact that the rest of the text is not in a human = language. Do=20 we create tags for =93French with embedded bits of=20 English=94?

 

 

Peter

 

From:=20 mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On=20 Behalf Of Mark Davis
Sent: Monday, April 16, 2007 3:49 = PM
To: Peter Constable
Cc: = ietf-languages@iana.org;=20 ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update = review=20 request

 

1. I think we have to be very careful here. The = meaning=20 of a standard like ISO 639-2 is established not by what we wish = it would=20 have said, nor by what we would find out if we were able to = read=20 Peter's mind. It is established by the wording in the standard, = and how=20 reasonable people could interpret it. The fact that "mis" was = incorporated=20 in order to account for MARC codes is interesting, but is not in the = text of=20 the standard. We can't expect users of BCP 47 to all be able to read = Peter's=20 mind before tagging.

2. When we are looking at stability, = that is=20 very important: our goal is that once content is correctly tagged, = people=20 can depend on the fact that we will not change the meaning of a tag = out from=20 under them. So clarifications that we add in future versions of 4646 = or the=20 registry are fine, as long as they do not narrow the range of = reasonable=20 interpretations. We can broaden them. So in the case of "mis", a = proposed=20 narrowing to include just the MARC codes is clearly disallowed, = since it was=20 nowhere stated in ISO 639-2 at the time that "mis" was added to the = language=20 registry (the BCP 47 semantics are established at the time we add = the code).=20 That is one of the key principles of BCP 47, is to isolate us where=20 necessary from instabilities in the source standards.

(The = one=20 exception we might be able to make is where something is so badly = defined=20 that most reasonable people couldn't come up with any consistent = definition=20 for it.)

3. Now, I think there are steps that can be taken to = make=20 the above moot. I think Peter's suggestion for ISO 639-X of = broadening all=20 of the Collections to remove the (Other) is exactly the right = strategy, and=20 if this can be done before 4646bis is issued, all the better. So = having=20

  • aus   =20 Australian languages means any of the languages on http://w= ww.ethnologue.com/show_family.asp?subid=3D90498=20
  • bat   =20 Baltic (Other) =3D> Baltic languages, means any of the = languages on http://w= ww.ethnologue.com/show_family.asp?subid=3D90207=20
  • mis   =20 Miscellaneous languages, essentially the root for http://www.ethnologue= .com/family_index.asp=20

and so on. This = is useful on=20 a number of levels; it resolves a number of problems in the = interpretation=20 of language codes, and makes the source standards themselves more = stable.=20 (In the ideal case, we would have codes for each of the possible = "decision=20 points" in the language tree. That is, if we look at any language = code such=20 as http:/= /www.ethnologue.com/show_lang_family.asp?code=3Deng=20 we'd have codes for each of the parent groupings, not just some of = them,=20 like "Australian languages".)

3. Randy raised the issue as = to=20 whether "mis" in the broad sense is useful (as something that has = linguistic=20 content, but I don't know what it is). It very much follows the = model in #3.=20 There are times when detection can only determine that it looks like = there=20 is some linguistic content -- it is not just binary data -- but = current=20 detection can't really determine what it might be. That is, a code = that=20 means "according to our best available detection methods this = doesn't look=20 like it is zxx".

4. I'm leery of using zxx for programming=20 languages, instead of just binary. There is clearly some linguistic = content=20 in "if (content =3D=3D null) { /* remove the item in the lookup = table */ ...}".=20 Maybe we need another code for this, something different than either = 'art'=20 or 'zxx'.

Mark

On 4/14/07, Peter = Constable=20 <petercon@microsoft.com>=20 wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com= ]


>=20 I find it very hard to believe that a reasonable analysis
> = (whether=20 done by human or machine) would classify a text a
> being = "mis"=20 without being able to recognize which of the
> languages in = that=20 grouping the text belonged to.  I can
> believe = someone=20 could look at text and say "it's a slavic
> language, but I'm = not sure=20 which one."  Do we really think
> someone or = something=20 would look at some text and say "it's
> Ainu, Andamanese, or = Etruscan,=20 but I can't tell which, so
> I'll tag it 'mis'"?

If = someone=20 were so tempted, I would argue that would be inappropriate use of = mis. Since=20 they do not know what it is, their declaration is that the language = identity=20 is not determined, and the appropriate tag for that is und. = Appropriate use=20 of mis does not require that one know the language of the content; = it does,=20 however, require that one know it is *not* a language covered by any = of the=20 available tags.=20 =



Peter

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




--
Mark=20

------=_NextPart_000_0051_01C781A2.AF9D38B0-- --===============1706682721== 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 --===============1706682721==-- From ltru-bounces@ietf.org Wed Apr 18 04:54: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 1He5w5-0000wp-Lx; Wed, 18 Apr 2007 04:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5w4-0000wh-3c for ltru@lists.ietf.org; Wed, 18 Apr 2007 04:54:44 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5w1-0002u1-Kv for ltru@lists.ietf.org; Wed, 18 Apr 2007 04:54:44 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 01:54:40 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Wed, 18 Apr 2007 01:54:40 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Wed, 18 Apr 2007 01:54:32 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAPTTEgAAHhTfA= Message-ID: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><00a201c78124$0713eaa0$7a63f853@streamserve.com> <005001c78191$ec1468b0$7a63f853@streamserve.com> In-Reply-To: <005001c78191$ec1468b0$7a63f853@streamserve.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9b6e42e65bba3d0b96e4bd7de98a7873 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201240275==" Errors-To: ltru-bounces@ietf.org --===============1201240275== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBC3BNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBC3BNAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You don't seem to be grasping: mis is fundamentally different from every ot= her collection. They are all defined in terms of membership in some set; mi= s is defined in terms of exclusion from everything else. The change to 'tai= ' is not a categorical change: the essence of the category remains membersh= ip in a particular language family. But the suggested change to mis is abso= lutely categorical: from exclusion from all other sets to inclusion in ever= y set. Zxx is a special-case identifier to indicate, "whatever content is here, it= doesn't have an in-scope attribute". Zxx is no more in-scope than und - wh= ich is why these are deemed special cases. I don't see what the problem is.= In terms of ISO 639, the coded concepts of the standard are the things tha= t linguists refer to as "natural languages" or "human languages" - the thin= gs that humans speak. If content has meaning expressed in some form of comm= unication *other than* one of these things, then that content would be cons= idered non-linguistic, and the form of communication would be considered ou= t of scope. The two characterizations, 'non-linguistic' and 'out of scope' = correlate. Peter From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] Sent: Wednesday, April 18, 2007 1:17 AM To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request 1a: It is just as much a categorical change for 'tai', 'gem', etc. But it i= s a change that I support, since without such a change, almost all of the c= ollection codes would have an empty set of applicable languages in the cont= ext of 639-3. However, if 'mis' is deprecated and replaced by a code for 'a= ny language' (rather than handling 'mis' like all of the other "other" code= s) in the process of doing this, I'm not going to complain. To be nit-picki= ng, all of the collection codes should then also be replaced (but I'm not g= oing to complain if they are not so replaced when removing the "other" part= of the semantics). Of course, it would be helpful if the standard defining= the collection codes (639-4?) also gave an explicit hierarchy of the codes= (like "'tai' covers ..., ..., ..., and any Tai language not given a code")= . Maybe that is the case already (I haven't seen a draft). 1b: A document (or text fragment) tagged as e.g. 'tai' is supposed to be in= ONE 'tai' language, not in several 'tai' languages. So in each individual = application, a collection code refers to one language, not several languages, even though the set of = languages covered by a collection code usually has more than one element (o= r no elements... see 1a). 4: So why is there a code for 'zxx' if it is out of scope? Furthermore, 'zx= x' is supposed to mean "no linguistic content", not "out of scope". /kent k ________________________________ From: Peter Constable [mailto:petercon@microsoft.com] Sent: Wednesday, April 18, 2007 2:33 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request On 1: I disagree: taking "other" out of mis is a categorical change - it cr= eates a completely different concept, because the heart of the concept of m= is is "other". On 1b ("language" vs. "languages"): I disagree: while the content tagged is= in a single language, the concept that the ID represents is a collection o= f languages. The ID represents that concept, not the content; we associate = the ID with the content to indicate an association of the concept with the = content. On 4: Again, I disagree. This is like saying, "It's out of scope, mostly bu= t not completely." Either it's in scope or it's out of scope. Peter From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] Sent: Tuesday, April 17, 2007 12:10 PM To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request on 1: I don't see why 'mis' would have to be an exception when doing a semantic c= hange of removing (implicit or explicit) "other" for various language codes= . Doing so is equally much a semantic change for 'tai' (or any other "other= " collection), and of exactly the same kind, so if it is not ok for 'mis' i= t would not be ok for 'tai' either. (If you prefer another acronym, say 'an= y' instead of 'mis', that is another ball-game.) Furthermore, since 'mul' is the only code intended for multiple languages (= when it is not practical to list which languages, per fragment of the docum= ent preferably), all of the "languages" codes should instead refer to "lang= uage" in singular. This would not be a semantic change, just referring to e= ach of the items that may be tagged, not a set of items [book shelf...] so = tagged. on 4: Programming languages of various sorts are out of scope (like 'zxx', but un= like 'art'), but I may agree that they are out of scope in a different way = than 'zxx'. Perhaps "formal language" ('for'), with no further subdivision = (they are still out of scope). /kent k ________________________________ From: Peter Constable [mailto:petercon@microsoft.com] Sent: Tuesday, April 17, 2007 2:19 AM To: ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request Re 1: Yes, be careful: (a) the majority of existing legacy usage of mis is = bound to be in MARC, and (b) any existing usage would assume the context of= ISO 639-2 (i.e. mis in existing usage is the exception list for ISO 639-2)= . Re 2: The mis collection is inherently unstable - unavoidably so. Prior to = 2005-08-16, an implementation of ISO 639-2 would have tagged Ainu content a= s mis; after that date, an implementation of ISO 639-2 would have tagged Ai= nu content as ain; existing content tagged before that date would not get r= etrieved by request for ain, and it would be conformant to suppose that req= uests for mis would not return Ainu content. The mis collection is ugly, pu= re and simple. So, I don't see what the point is of getting worried over wh= ether we're making mis unstable: it's been that way for some time. (Note: mis is badly defined from a stability perspective, though I don't th= ink there's much question of how it's defined.) Re 3(b): "There are times when detection can only determine that it looks l= ike there is some linguistic content -- it is not just binary data -- but c= urrent detection can't really determine what it might be. That is, a code t= hat means "according to our best available detection methods this doesn't l= ook like it is zxx"." If you want to use mis for that, I would argue that t= hat is significantly changing the semantics of mis. (Even though mis is uns= table, it is unstable on a qualitative level; this is a categorical change.= ) I definitely oppose that. If you want an ID for "undetermined human langu= age", then that should be proposed. We should not usurp an existing ID for = that purpose. Re 4: I don't see how your example differs from this: "Nous avons une phras= e en fran=E7ais (but this is in English)". The fact that the parenthetical = text is in English doesn't change the fact that the other text is in French= . Similarly, in your example, the fact that there is a comment in English d= oes not change the fact that the rest of the text is not in a human languag= e. Do we create tags for "French with embedded bits of English"? Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, April 16, 2007 3:49 PM To: Peter Constable Cc: ietf-languages@iana.org; ltru@lists.ietf.org Subject: Re: [Ltru] Re: "mis" update review request 1. I think we have to be very careful here. The meaning of a standard like = ISO 639-2 is established not by what we wish it would have said, nor by wha= t we would find out if we were able to read Peter's mind. It is established= by the wording in the standard, and how reasonable people could interpret = it. The fact that "mis" was incorporated in order to account for MARC codes= is interesting, but is not in the text of the standard. We can't expect us= ers of BCP 47 to all be able to read Peter's mind before tagging. 2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we = will not change the meaning of a tag out from under them. So clarifications= that we add in future versions of 4646 or the registry are fine, as long a= s they do not narrow the range of reasonable interpretations. We can broade= n them. So in the case of "mis", a proposed narrowing to include just the M= ARC codes is clearly disallowed, since it was nowhere stated in ISO 639-2 a= t the time that "mis" was added to the language registry (the BCP 47 semant= ics are established at the time we add the code). That is one of the key pr= inciples of BCP 47, is to isolate us where necessary from instabilities in = the source standards. (The one exception we might be able to make is where something is so badly = defined that most reasonable people couldn't come up with any consistent de= finition for it.) 3. Now, I think there are steps that can be taken to make the above moot. I= think Peter's suggestion for ISO 639-X of broadening all of the Collection= s to remove the (Other) is exactly the right strategy, and if this can be d= one before 4646bis is issued, all the better. So having * aus Australian languages means any of the languages on http://www.e= thnologue.com/show_family.asp?subid=3D90498 * bat Baltic (Other) =3D> Baltic languages, means any of the language= s on http://www.ethnologue.com/show_family.asp?subid=3D90207 * mis Miscellaneous languages, essentially the root for http://www.et= hnologue.com/family_index.asp and so on. This is useful on a number of levels; it resolves a number of pr= oblems in the interpretation of language codes, and makes the source standa= rds themselves more stable. (In the ideal case, we would have codes for eac= h of the possible "decision points" in the language tree. That is, if we lo= ok at any language code such as http://www.ethnologue.com/show_lang_family.= asp?code=3Deng we'd have codes for each of the parent groupings, not just s= ome of them, like "Australian languages".) 3. Randy raised the issue as to whether "mis" in the broad sense is useful = (as something that has linguistic content, but I don't know what it is). It= very much follows the model in #3. There are times when detection can only= determine that it looks like there is some linguistic content -- it is not= just binary data -- but current detection can't really determine what it m= ight be. That is, a code that means "according to our best available detect= ion methods this doesn't look like it is zxx". 4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) { /= * remove the item in the lookup table */ ...}". Maybe we need another code = for this, something different than either 'art' or 'zxx'. Mark On 4/14/07, Peter Constable > wrote: From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > I find it very hard to believe that a reasonable analysis > (whether done by human or machine) would classify a text a > being "mis" without being able to recognize which of the > languages in that grouping the text belonged to. I can > believe someone could look at text and say "it's a slavic > language, but I'm not sure which one." Do we really think > someone or something would look at some text and say "it's > Ainu, Andamanese, or Etruscan, but I can't tell which, so > I'll tag it 'mis'"? If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the lan= guage identity is not determined, and the appropriate tag for that is und. = Appropriate use of mis does not require that one know the language of the c= ontent; it does, however, require that one know it is *not* a language cove= red by any of the available tags. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBC3BNAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You don’t seem to be grasping: mis is fundamentally different from every other collection. They are all defined in terms of membership in some set; mis is defined in terms of exclusion from everythin= g else. The change to ‘tai’ is not a categorical change: the esse= nce of the category remains membership in a particular language family. But the su= ggested change to mis is absolutely categorical: from exclusion from all other sets= to inclusion in every set.

 

Zxx is a special-case identifier to indicate, “whateve= r content is here, it doesn’t have an in-scope attribute”. Zxx is= no more in-scope than und – which is why these are deemed special cases.= I don’t see what the problem is. In terms of ISO 639, the coded concept= s of the standard are the things that linguists refer to as “natural langu= ages” or “human languages” – the things that humans speak. If c= ontent has meaning expressed in some form of communication *other than* one= of these things, then that content would be considered non-linguistic, and the form of communication would be considered out of scope. The two characterizations, ‘non-linguistic’ and ‘out of scopeR= 17; correlate.

 

Peter

 

From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]
Sent: Wednesday, April 18, 2007 1:17 AM
To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request

 

1a: It is just as much a categorical change for 'tai', 'gem', etc. But it is a change that I support, since without such a change, almost all of the collection codes would have an empty set of applicable languages in the context of 639-3. However, if 'mis' is deprecated and replaced by a code for 'any language' (rather than handling 'mis' like all = of the other "other" codes) in the process of doing this, I'm not go= ing to complain. To be nit-picking, all of the collection codes should then als= o be replaced (but I'm not going to complain if they are not so replaced when removing the "other" part of the semantics). Of course, it would = be helpful if the standard defining the collection codes (639-4?) also gave an explicit hierarchy of the codes (like "'tai' covers ..., ..., ..., and any Tai language not given a code"). Maybe that is the c= ase already (I haven't seen a draft).

 

1b: A document (or text fragment) tagged as e.g. 'tai' is supposed to be in ONE 'tai' language, not in several 'tai' languages. So in each individual application, a collection

code refers to one language, not several languages, even though= the set of languages covered by a collection code usually has more than one ele= ment (or no elements... see 1a).

 

4: So why is there a code for 'zxx' if it is out of scope? Furthermore, 'zxx' is supposed to mean "no linguistic content", n= ot "out of scope".

 

        /kent k

 

 

From: Peter Constable [mailto:petercon@microsoft.com]
Sent: Wednesday, April 18, 2007 2:33 AM
To: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update review request=

On 1: I disagree: taking “other” out of mis is a categorical change – it creates a completely different concept, becau= se the heart of the concept of mis is “other”.

 

On 1b (“language” vs. “languages”): = I disagree: while the content tagged is in a single language, the concept tha= t the ID represents is a collection of languages. The ID represents that conc= ept, not the content; we associate the ID with the content to indicate an association of the concept with the content.

 

On 4: Again, I disagree. This is like saying, “It̵= 7;s out of scope, mostly but not completely.” Either it’s in scope = or it’s out of scope.

 

 

Peter

 

From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]
Sent: Tuesday, April 17, 2007 12:10 PM
To: Peter Constable; ietf-languages@iana.org; ltru@lists.ietf.org Subject: RE: [Ltru] Re: "mis" update review request

 

on 1:

 

I don't see why 'mis' would have to be an exception when doing a semantic cha= nge of removing (implicit or explicit) "other" for various language codes. Doing so is equally much a semantic change for 'tai' (or any other "other" collection), and of exactly the same kind, so if it is no= t ok for 'mis' it would not be ok for 'tai' either. (If you prefer another acron= ym, say 'any' instead of 'mis', that is another ball-game.)

 

Furthermore, since 'mul' is the only code intended for multiple languages (when it is no= t practical to list which languages, per fragment of the document preferably)= , all of the "languages" codes should instead refer to "language" in singular. Thi= s would not be a semantic change, just referring to each of the items that ma= y be tagged, not a set of items [book shelf...] so tagged.

 

on 4:

 

Programming languages of various sorts are out of scope (like 'zxx', but unlike 'art'),= but I may agree that they are out of scope in a different way than 'zxx'. Perha= ps "formal language" ('for'), with no further subdivision (they are still out of scope).

 

 = ;       /kent k

 

From: Peter Constable [mailto:petercon@microsoft.com]
Sent: Tuesday, April 17, 2007 2:19 AM
To: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: RE: [Ltru] Re: "mis" update review request=

Re 1: Yes, be careful: (a) the majority of existing legacy u= sage of mis is bound to be in MARC, and (b) any existing usage would assume the context of ISO 639-2 (i.e. mis in existing usage is the exception list for = ISO 639-2).

 

Re 2: The mis collection is inherently unstable – unavoidably so. Prior to 2005-08-16, an implementation of ISO 639-2 would h= ave tagged Ainu content as mis; after that date, an implementation of ISO 639-2 would have tagged Ainu content as ain; existing content tagged before that = date would not get retrieved by request for ain, and it would be conformant to suppose that requests for mis would not return Ainu content. The mis collec= tion is ugly, pure and simple. So, I don’t see what the point is of gettin= g worried over whether we’re making mis unstable: it’s been that = way for some time.

 

(Note: mis is badly defined from a stability perspective, th= ough I don’t think there’s much question of how it’s defined.)=

 

Re 3(b): “There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".” If you want to us= e mis for that, I would argue that that is significantly changing the semanti= cs of mis. (Even though mis is unstable, it is unstable on a qualitative level= ; this is a categorical change.) I definitely oppose that. If you want an ID = for “undetermined human language”, then that should be proposed. We should not usurp an existing ID for that purpose.

 

Re 4: I don’t see how your example differs from this: “Nous avons une phrase en fran=E7ais (but this is in English)”.= The fact that the parenthetical text is in English doesn’t change the fac= t that the other text is in French. Similarly, in your example, the fact that there is a comment in English does not change the fact that the rest of the text is not in a human language. Do we create tags for “French with embedded bits of English”?

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, April 16, 2007 3:49 PM
To: Peter Constable
Cc: ietf-languages@iana.org; ltru@lists.ietf.org
Subject: Re: [Ltru] Re: "mis" update review request

 

1. I think we have to be very careful here. The meanin= g of a standard like ISO 639-2 is established not by what we wish it would have said, nor by what we would find out if we were able to read Peter's mind. It is established by the wording in the standard, and how reasona= ble people could interpret it. The fact that "mis" was incorporated i= n order to account for MARC codes is interesting, but is not in the text of t= he standard. We can't expect users of BCP 47 to all be able to read Peter's mi= nd before tagging.

2. When we are looking at stability, that is very important: our goal is th= at once content is correctly tagged, people can depend on the fact that we wil= l not change the meaning of a tag out from under them. So clarifications that= we add in future versions of 4646 or the registry are fine, as long as they do= not narrow the range of reasonable interpretations. We can broaden them. So in = the case of "mis", a proposed narrowing to include just the MARC code= s is clearly disallowed, since it was nowhere stated in ISO 639-2 at the time th= at "mis" was added to the language registry (the BCP 47 semantics ar= e established at the time we add the code). That is one of the key principles= of BCP 47, is to isolate us where necessary from instabilities in the source standards.

(The one exception we might be able to make is where something is so badly defined that most reasonable people couldn't come up with any consistent definition for it.)

3. Now, I think there are steps that can be taken to make the above moot. I think Peter's suggestion for ISO 639-X of broadening all of the Collections= to remove the (Other) is exactly the right strategy, and if this can be done before 4646bis is issued, all the better. So having

and so on. This is usef= ul on a number of levels; it resolves a number of problems in the interpretation of language codes, and makes the source standards themselves more stable. (In = the ideal case, we would have codes for each of the possible "decision points" in the language tree. That is, if we look at any language code such as http://www.ethnologue.com/show_lang_family.asp?code=3Deng we'd have codes for each of the parent groupings, not just some of them, li= ke "Australian languages".)

3. Randy raised the issue as to whether "mis" in the broad sense = is useful (as something that has linguistic content, but I don't know what it = is). It very much follows the model in #3. There are times when detection can on= ly determine that it looks like there is some linguistic content -- it is not = just binary data -- but current detection can't really determine what it might b= e. That is, a code that means "according to our best available detection methods this doesn't look like it is zxx".

4. I'm leery of using zxx for programming languages, instead of just binary= . There is clearly some linguistic content in "if (content =3D=3D null) = { /* remove the item in the lookup table */ ...}". Maybe we need another co= de for this, something different than either 'art' or 'zxx'.

Mark

On 4/14/07, Peter Constabl= e <petercon@microsoft.com>= ; wrote:

From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]


> I find it very hard to believe that a reasonable analysis
> (whether done by human or machine) would classify a text a
> being "mis" without being able to recognize which of the
> languages in that grouping the text belonged to.  I can
> believe someone could look at text and say "it's a slavic
> language, but I'm not sure which one."  Do we really th= ink
> someone or something would look at some text and say "it's
> Ainu, Andamanese, or Etruscan, but I can't tell which, so
> I'll tag it 'mis'"?

If someone were so tempted, I would argue that would be inappropriate use o= f mis. Since they do not know what it is, their declaration is that the langu= age identity is not determined, and the appropriate tag for that is und. Appropriate use of mis does not require that one know the language of the content; it does, however, require that one know it is *not* a language cov= ered by any of the available tags.



Peter

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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33BBBC3BNAEXMSGC117re_-- --===============1201240275== 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 --===============1201240275==-- From ltru-bounces@ietf.org Wed Apr 18 09: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 1HeAVJ-0006Yd-6W; Wed, 18 Apr 2007 09:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAVH-0006YV-Vr for ltru@ietf.org; Wed, 18 Apr 2007 09:47:23 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAVG-0000iK-NC for ltru@ietf.org; Wed, 18 Apr 2007 09:47: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 <20070418134721.JFUF14403.mta9.adelphia.net@DGBP7M81>; Wed, 18 Apr 2007 09:47:21 -0400 Message-ID: <006601c781c0$16cc2510$6401a8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: Date: Wed, 18 Apr 2007 06:47: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Guys, Please try to resist: 1. cross-posting this thread to ietf-languages and LTRU 2. quoting hundreds of lines of historical material with every post Thanks, -- 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 Apr 18 11:49: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 1HeCPv-0007Bx-Bd; Wed, 18 Apr 2007 11:49:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCPt-0007Bl-BY for ltru@lists.ietf.org; Wed, 18 Apr 2007 11:49:57 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeCPr-00037u-Se for ltru@lists.ietf.org; Wed, 18 Apr 2007 11:49:57 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HeCPY-0003CG-1o for ltru@lists.ietf.org; Wed, 18 Apr 2007 17:49:36 +0200 Received: from d254163.dialin.hansenet.de ([80.171.254.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 17:49:36 +0200 Received: from nobody by d254163.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 17:49:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 18 Apr 2007 17:43:26 +0200 Organization: Lines: 21 Message-ID: <46263C9E.1906@xyzzy.claranet.de> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> <46253193.3070503@yahoo-inc.com> <20070418051440.GA22912@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254163.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> But there is no reason that this cannot be rectified, perhaps by >> borrowing the text from draft-phillips-record-jar. I still don't >> know why there was opposition to file-level commenting in the >> 3066bis era. > It's not clear how to maintain it vis-a-vis IANA. It won't help with issues for individual subtags like "mis". A good example how records can be used is Richard's "registry explorer", it shows complete records. I think IANA would have no problem with a revised ABNF. But a new syntax could obsolete some / many / most existing tools for the 4646 format. If 4646bis tries this the reasons should be compelling, and then we'd have to consider the complete wish list again, from UTF-8 and/or XML over ISO 639-3 status fields up to file-level comments. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 11:56: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 1HeCWV-0003OA-HK; Wed, 18 Apr 2007 11:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCWU-0003O4-JB for ltru@lists.ietf.org; Wed, 18 Apr 2007 11:56:46 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCWS-0002qP-7Q for ltru@lists.ietf.org; Wed, 18 Apr 2007 11:56:46 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HeCWQ-0007Ct-VV; Wed, 18 Apr 2007 11:56:43 -0400 Date: Wed, 18 Apr 2007 11:56:42 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070418155642.GC24360@mercury.ccil.org> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> <46253193.3070503@yahoo-inc.com> <20070418051440.GA22912@mercury.ccil.org> <46263C9E.1906@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46263C9E.1906@xyzzy.claranet.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > I think IANA would have no problem with a revised ABNF. But a new > syntax could obsolete some / many / most existing tools for the 4646 > format. If 4646bis tries this the reasons should be compelling, and > then we'd have to consider the complete wish list again, from UTF-8 > and/or XML over ISO 639-3 status fields up to file-level comments. This wouldn't be a *complete* change of syntax, just adding comment fields to the first (File-Date) record. As things stand, though, IANA manages that record themselves, directly; adding comments creates a mixture of IANA-controlled and list-controlled content in a single record, which is administratively problematic. -- MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS John Cowan cowan@ccil.org http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 14:07: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 1HeEYn-0005xz-Sn; Wed, 18 Apr 2007 14:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEYm-0005xm-Ct for ltru@ietf.org; Wed, 18 Apr 2007 14:07:16 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEYk-0002gD-VR for ltru@ietf.org; Wed, 18 Apr 2007 14:07:16 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HeEYh-00007g-3A; Wed, 18 Apr 2007 14:07:11 -0400 Date: Wed, 18 Apr 2007 14:07:11 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070418180711.GE24360@mercury.ccil.org> References: <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <20070418051614.GB22912@mercury.ccil.org> <30b660a20704172350n1728045eh38b4ac339724ff09@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704172350n1728045eh38b4ac339724ff09@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I really don't understand your position on this. I think we have been talking past one another, and I think I see why. > When I say that I follow a standard, like the XML standard, I have > to follow what the standard actually says, not what someone wishes it > had said. If it says "[#x7F-#x84]" that's what it means. The XML standard is very different in kind from the ISO standards we are dealing with here. If you read the XML standard and the other standards it normatively references, like Unicode, you know everything you need to know about determining what is and what is not an XML document. However, ISO 639 tells you only that "en" is a code for the language named "English". It does not tell you which documents are and are not English. It also gives you the code "bal" for Baltic languages, but it does not say which those languages might be, still less which documents are and are not in a Baltic language. Indeed, the formal name of 639 tells us that it is, strictly speaking, not a code for languages as such, but for their names (ditto 3166 and 15924). (This remark will draw a troll from HWMNBN, but I won't see it because it'll be in my spam bucket.) In order to avoid the Scylla of "'en' means 'English' and nothing more" and the Charybdis of "'en' means whatever I want it to mean", we can, indeed must, look behind the mere text of the standard to the encyclopedic non-ISO standards from which the ISO versions are abstracted: MARC, Ethnologue, UNSD, Unicode. That's what's happening here: Peter is telling you the way these tags have been used in the central community of practice. > A stance that I can just interpret the standard according to what I > think the authors had in mind, rather than what the text actually says, As I note above, this is a false dichotomy. -- Only do what only you can do. John Cowan --Edsger W. Dijkstra's advice to a student in search of a thesis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 14:52: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 1HeFGg-00074g-Dj; Wed, 18 Apr 2007 14:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFGe-000735-8i for ltru@lists.ietf.org; Wed, 18 Apr 2007 14:52:36 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound3-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFGY-0004k7-Jp for ltru@lists.ietf.org; Wed, 18 Apr 2007 14:52:36 -0400 Received: from outbound3-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-fra-R.bigfish.com (Postfix) with ESMTP id 10ED41115AA; Wed, 18 Apr 2007 18:51:12 +0000 (UTC) Received: from mail1-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound3-fra.bigfish.com (Postfix) with ESMTP id 0F4739B8051; Wed, 18 Apr 2007 18:51:12 +0000 (UTC) Received: from mail1-fra (localhost.localdomain [127.0.0.1]) by mail1-fra-R.bigfish.com (Postfix) with ESMTP id 01BC966819B; Wed, 18 Apr 2007 18:51:12 +0000 (UTC) X-BigFish: VP Received: by mail1-fra (MessageSwitch) id 1176922271929403_4341; Wed, 18 Apr 2007 18:51:11 +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 mail1-fra.bigfish.com (Postfix) with ESMTP id B890E740018; Wed, 18 Apr 2007 18:51:11 +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 2007041811510907-109801 ; Wed, 18 Apr 2007 11:51:09 -0700 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] Re: zxx 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, 18 Apr 2007 11:49:18 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/18/2007 11:49:19, Serialize complete at 04/18/2007 11:49:19, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 11:51:09 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 11:51:11 AM, Serialize complete at 04/18/2007 11:51:11 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0986411466==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0986411466== Content-Type: multipart/alternative; boundary="=_alternative 00678ED9882572C1_=" This is a multipart message in MIME format. --=_alternative 00678ED9882572C1_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" UGV0ZXIgd3JvdGU6DQoNCj4gWnh4IGlzIGEgc3BlY2lhbC1jYXNlIGlkZW50aWZpZXIgdG8gaW5k aWNhdGUsIOKAnHdoYXRldmVyIGNvbnRlbnQgaXMgDQo+IGhlcmUsIGl0IGRvZXNu4oCZdCBoYXZl IGFuIGluLXNjb3BlIGF0dHJpYnV0ZeKAnS4gWnh4IGlzIG5vIG1vcmUgaW4tDQo+IHNjb3BlIHRo YW4gdW5kIOKAkyB3aGljaCBpcyB3aHkgdGhlc2UgYXJlIGRlZW1lZCBzcGVjaWFsIGNhc2VzLiBJ IGRvbuKAmQ0KPiB0IHNlZSB3aGF0IHRoZSBwcm9ibGVtIGlzLiBJbiB0ZXJtcyBvZiBJU08gNjM5 LCB0aGUgY29kZWQgY29uY2VwdHMgDQo+IG9mIHRoZSBzdGFuZGFyZCBhcmUgdGhlIHRoaW5ncyB0 aGF0IGxpbmd1aXN0cyByZWZlciB0byBhcyDigJxuYXR1cmFsIA0KPiBsYW5ndWFnZXPigJ0gb3Ig 4oCcaHVtYW4gbGFuZ3VhZ2Vz4oCdIOKAkyB0aGUgdGhpbmdzIHRoYXQgaHVtYW5zIHNwZWFrLiAN Cg0KSWYgSVNPIDYzOSB3YXMgcHJpbWFyaWx5IGFpbWVkIGF0IHNwb2tlbiBsYW5ndWFnZXMsIGl0 IHdvdWxkbid0IGhhdmUgdGFrZW4gDQp0aGlzIGxvbmcgdG8gZ2V0IGNvZGVzIGZvciBNYW5kYXJp biwgQ2FudG9uZXNlLCBvciBTd2lzcyBHZXJtYW4uIA0KDQpJJ20gbXVjaCBtb3JlIGNvbWZvcnRh YmxlIHdpdGggIndoYXRldmVyIGNvbnRlbnQgaXMgaW4gaGVyZSwgaXQgZG9lc24ndCANCmhhdmUg YW4gaW4tc2NvcGUgYXR0cmlidXRlIiB0aGFuIGFkZGluZyB0aGUgcGhyYXNlICJjb3VsZCBiZSBh IHByb2dyYW1taW5nIA0KbGFuZ3VhZ2UuIiBJJ2QgYWdyZWUgdGhhdCBjb2RlIGlzIG5vdCBnZW5l cmFsbHkgYSBzcG9rZW4gaHVtYW4gbGFuZ3VhZ2UgDQphbmQgaXMgb3V0IG9mIHNjb3BlIGlmIElT TyA2MzkgaW50ZW5kcyB0byBpZGVudGlmeSBzcG9rZW4gaHVtYW4gbGFuZ3VhZ2VzLiANCg0KDQpI b3dldmVyLCBBbWF6b24uY29tIGN1cnJlbnRseSBoYXMgNDQsMDAwIHRpdGxlcyBvbiBKYXZhIGFs b25lLiBUaGVzZSANCnRlY2huaWNhbCBib29rcyBhcmUgaGVhdmlseSB3ZWlnaHRlZCB3aXRoIGNv ZGUgc25pcHBldHMgdGhhdCBhcmUgKndyaXR0ZW4qIA0KYnkgb25lIGh1bWFuIGZvciBjb21tdW5p Y2F0aW9uIHdpdGggYW5vdGhlci4gVGhpcyBjb2RlIGlzIG5ldmVyIHJlYWQgYnkgDQptYWNoaW5l cywgaXQncyByZWFkIGJ5IGh1bWFucy4gVGhlcmUgaXMgYSBuZWVkIHRvIG1hcmsgdGhlc2UgY29k ZSBzZWN0aW9ucyANCnNlcGFyYXRlIGZyb20gdGhlIEVuZ2xpc2ggbGFuZ3VhZ2UgdGV4dCBhcyBp cyBzZWVuIG9uIHRoZSBzaXRlIGxpbmsgSSBzZW50IA0KYmVmb3JlLCB3aGljaCBpcyBoZWF2aWx5 IG1hcmtlZCB1cCB3aXRoIDxjb2RlPiBhbmQgPHByZT4gdGFncy4gVGhlIHNhbWUgaXMgDQp0cnVl IGZvciB0ZWNobmljYWwgYm9va3Mgc2l0dGluZyBvbiB5b3VyIHNoZWx2ZXMgYW5kIHRha2luZyBv dmVyIGxhcmdlIA0Kc2VjdGlvbnMgb2YgeW91ciBsb2NhbCBib29rc3RvcmUuIFRoYXQgZG9lc24n dCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgDQp4bWw6bGFuZyB0YWdzIGFyZSB0aGUgYmVzdCB3YXkg dG8gaW5kaWNhdGUgdGhpcyBjb2RlLiBUaGVyZSBhcmUgYWxyZWFkeSANCnJlY29tbWVuZGVkIHdh eXMgdG8gZG8gdGhpcyBpbiBIVE1MIGFuZCBYSFRNTCB0aGF0IGRvIG5vdCBpbmNsdWRlIHRoZSAN CnhtbDpsYW5nIHRhZy4gV2Ugc2hvdWxkIG5vdCBpbXBseSB0aGF0IHRoZSB4bWw6bGFuZyB0YWcg YW5kICJ6eHgiIHJlcGxhY2UgDQp0aGVzZSB1c2VzLg0KDQpGb3IgdGhlIHNha2Ugb2YgYXJndW1l bnQsIGRvbid0IG1vc3Qgb2YgdXMgcmVhZCBhdCBsZWFzdCBzb21lIHR5cGUgb2YgY29kZSANCmFz IGEgd3JpdHRlbiBsYW5ndWFnZT8gSXQgbWF5IG5vdCBoYXZlIHRoZSBzYW1lIHByb3BlcnRpZXMg YXMgb3RoZXIgaHVtYW4gDQpsYW5ndWFnZSwgYW5kIEknbGwgYWdyZWUgdGhpcyBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGUgNjM5IHN0YW5kYXJkcyANCmFjY29yZGluZyB0byB0aGUgZG9jdW1l bnQgdGV4dC4gQnV0IHRvIGNhbGwgY29kZSAibm9uLWxpbmd1aXN0aWMiIHN0aWxsIA0KanVzdCBz dHJpa2VzIG1lIGFzIHdyb25nLg0KDQpSZWdhcmRzLA0KDQpLYXJlbiBCcm9vbWUNCg0K --=_alternative 00678ED9882572C1_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="UTF-8" DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QZXRlciB3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgWnh4IGlzIGEgc3BlY2lhbC1jYXNlIGlkZW50aWZpZXIg dG8gaW5kaWNhdGUsDQrigJx3aGF0ZXZlciBjb250ZW50IGlzIDxicj4NCiZndDsgaGVyZSwgaXQg ZG9lc27igJl0IGhhdmUgYW4gaW4tc2NvcGUgYXR0cmlidXRl4oCdLiBaeHggaXMgbm8gbW9yZSBp bi08YnI+DQomZ3Q7IHNjb3BlIHRoYW4gdW5kIOKAkyB3aGljaCBpcyB3aHkgdGhlc2UgYXJlIGRl ZW1lZCBzcGVjaWFsIGNhc2VzLiBJIGRvbuKAmTxicj4NCiZndDsgdCBzZWUgd2hhdCB0aGUgcHJv YmxlbSBpcy4gSW4gdGVybXMgb2YgSVNPIDYzOSwgdGhlIGNvZGVkIGNvbmNlcHRzDQo8YnI+DQom Z3Q7IG9mIHRoZSBzdGFuZGFyZCBhcmUgdGhlIHRoaW5ncyB0aGF0IGxpbmd1aXN0cyByZWZlciB0 byBhcyDigJxuYXR1cmFsDQo8YnI+DQomZ3Q7IGxhbmd1YWdlc+KAnSBvciDigJxodW1hbiBsYW5n dWFnZXPigJ0g4oCTIHRoZSB0aGluZ3MgdGhhdCBodW1hbnMgc3BlYWsuDQo8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPklmIElTTyA2Mzkgd2FzIHByaW1hcmlseSBhaW1l ZCBhdCBzcG9rZW4gbGFuZ3VhZ2VzLA0KaXQgd291bGRuJ3QgaGF2ZSB0YWtlbiB0aGlzIGxvbmcg dG8gZ2V0IGNvZGVzIGZvciBNYW5kYXJpbiwgQ2FudG9uZXNlLA0Kb3IgU3dpc3MgR2VybWFuLiA8 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkknbSBtdWNoIG1vcmUgY29t Zm9ydGFibGUgd2l0aCAmcXVvdDt3aGF0ZXZlciBjb250ZW50DQppcyBpbiBoZXJlLCBpdCBkb2Vz bid0IGhhdmUgYW4gaW4tc2NvcGUgYXR0cmlidXRlJnF1b3Q7IHRoYW4gYWRkaW5nIHRoZQ0KcGhy YXNlICZxdW90O2NvdWxkIGJlIGEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UuJnF1b3Q7IEknZCBhZ3Jl ZSB0aGF0IGNvZGUNCmlzIG5vdCBnZW5lcmFsbHkgYSBzcG9rZW4gaHVtYW4gbGFuZ3VhZ2UgYW5k IGlzIG91dCBvZiBzY29wZSBpZiBJU08gNjM5DQppbnRlbmRzIHRvIGlkZW50aWZ5IHNwb2tlbiBo dW1hbiBsYW5ndWFnZXMuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ SG93ZXZlciwgQW1hem9uLmNvbSBjdXJyZW50bHkgaGFzIDQ0LDAwMCB0aXRsZXMgb24NCkphdmEg YWxvbmUuIFRoZXNlIHRlY2huaWNhbCBib29rcyBhcmUgaGVhdmlseSB3ZWlnaHRlZCB3aXRoIGNv ZGUgc25pcHBldHMNCnRoYXQgYXJlICp3cml0dGVuKiBieSBvbmUgaHVtYW4gZm9yIGNvbW11bmlj YXRpb24gd2l0aCBhbm90aGVyLiBUaGlzIGNvZGUNCmlzIG5ldmVyIHJlYWQgYnkgbWFjaGluZXMs IGl0J3MgcmVhZCBieSBodW1hbnMuIFRoZXJlIGlzIGEgbmVlZCB0byBtYXJrDQp0aGVzZSBjb2Rl IHNlY3Rpb25zIHNlcGFyYXRlIGZyb20gdGhlIEVuZ2xpc2ggbGFuZ3VhZ2UgdGV4dCBhcyBpcyBz ZWVuDQpvbiB0aGUgc2l0ZSBsaW5rIEkgc2VudCBiZWZvcmUsIHdoaWNoIGlzIGhlYXZpbHkgbWFy a2VkIHVwIHdpdGggJmx0O2NvZGUmZ3Q7DQphbmQgJmx0O3ByZSZndDsgdGFncy4gVGhlIHNhbWUg aXMgdHJ1ZSBmb3IgdGVjaG5pY2FsIGJvb2tzIHNpdHRpbmcgb24geW91cg0Kc2hlbHZlcyBhbmQg dGFraW5nIG92ZXIgbGFyZ2Ugc2VjdGlvbnMgb2YgeW91ciBsb2NhbCBib29rc3RvcmUuIFRoYXQg ZG9lc24ndA0KbmVjZXNzYXJpbHkgbWVhbiB0aGF0IHhtbDpsYW5nIHRhZ3MgYXJlIHRoZSBiZXN0 IHdheSB0byBpbmRpY2F0ZSB0aGlzIGNvZGUuDQpUaGVyZSBhcmUgYWxyZWFkeSByZWNvbW1lbmRl ZCB3YXlzIHRvIGRvIHRoaXMgaW4gSFRNTCBhbmQgWEhUTUwgdGhhdCBkbw0Kbm90IGluY2x1ZGUg dGhlIHhtbDpsYW5nIHRhZy4gV2Ugc2hvdWxkIG5vdCBpbXBseSB0aGF0IHRoZSB4bWw6bGFuZyB0 YWcNCmFuZCAmcXVvdDt6eHgmcXVvdDsgcmVwbGFjZSB0aGVzZSB1c2VzLjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Rm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50LCBkb24n dCBtb3N0IG9mIHVzIHJlYWQgYXQNCmxlYXN0IHNvbWUgdHlwZSBvZiBjb2RlIGFzIGEgd3JpdHRl biBsYW5ndWFnZT8gSXQgbWF5IG5vdCBoYXZlIHRoZSBzYW1lDQpwcm9wZXJ0aWVzIGFzIG90aGVy IGh1bWFuIGxhbmd1YWdlLCBhbmQgSSdsbCBhZ3JlZSB0aGlzIGlzIG91dHNpZGUgdGhlDQpzY29w ZSBvZiB0aGUgNjM5IHN0YW5kYXJkcyBhY2NvcmRpbmcgdG8gdGhlIGRvY3VtZW50IHRleHQuIEJ1 dCB0byBjYWxsDQpjb2RlICZxdW90O25vbi1saW5ndWlzdGljJnF1b3Q7IHN0aWxsIGp1c3Qgc3Ry aWtlcyBtZSBhcyB3cm9uZy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PlJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5LYXJlbiBC cm9vbWU8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 00678ED9882572C1_=-- --===============0986411466== 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 --===============0986411466==-- From ltru-bounces@ietf.org Wed Apr 18 15:12: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 1HeFZR-000499-Al; Wed, 18 Apr 2007 15:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFZQ-000491-2l for ltru@lists.ietf.org; Wed, 18 Apr 2007 15:12:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFZO-0002VI-PI for ltru@lists.ietf.org; Wed, 18 Apr 2007 15:12:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HeFG6-0000ib-JV for ltru@lists.ietf.org; Wed, 18 Apr 2007 20:52:02 +0200 Received: from d254163.dialin.hansenet.de ([80.171.254.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 20:52:02 +0200 Received: from nobody by d254163.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Apr 2007 20:52:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 18 Apr 2007 20:33:52 +0200 Organization: Lines: 33 Message-ID: <46266490.70DD@xyzzy.claranet.de> References: <000b01c77fd5$ea903770$6401a8c0@DGBP7M81> <4624ED8F.50C8@xyzzy.claranet.de> <30b660a20704170918r27ed61besd364059f6068f809@mail.gmail.com> <20070417173447.GA3783@mercury.ccil.org> <46253193.3070503@yahoo-inc.com> <20070418051440.GA22912@mercury.ccil.org> <46263C9E.1906@xyzzy.claranet.de> <20070418155642.GC24360@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254163.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > This wouldn't be a *complete* change of syntax, just adding comment > fields to the first (File-Date) record. As things stand, though, > IANA manages that record themselves, directly; adding comments > creates a mixture of IANA-controlled and list-controlled content > in a single record, which is administratively problematic. They manage the body of the File-Date field in the first record, or in plain English the timestamp. There are no other fields in this record at the moment. Just for fun I tested a file starting with: | File-Date: 2007-03-06 | Comment: crash and burn | %% | Type: language | Subtag: aa | Description: Afar [...] My silly gawk scripts simply ignore the comment (no output). But my REXX script to check cross references etc. directly did exactly what the comment says: | +++ OS/2 COMMAND F:\BIN\projects\ltru\scripts.cmd | +++ trap: 2 Comment: crash and burn | 69 *-* otherwise exit TRAP( LINE REC ) Okay, that's no realistic / fair test, this REXX script was designed to detect obscure oddities in Doug's drafts before the 4645 WGLC. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 16:48: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 1HeH4b-0005mQ-UR; Wed, 18 Apr 2007 16:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH4a-0005m5-5P for ltru@ietf.org; Wed, 18 Apr 2007 16:48:16 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH4Y-0004dk-Ug for ltru@ietf.org; Wed, 18 Apr 2007 16:48:16 -0400 Received: by wx-out-0506.google.com with SMTP id h31so342129wxd for ; Wed, 18 Apr 2007 13:48: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:mime-version:content-type:x-google-sender-auth; b=FZv8gT6c/cV/6Mnmqf+d5PbJc9wBy7u+MGlNB/DL4bi+G+PKIM+aK77OUeE9kB66jlnvo3HigfDqOfSuHbQHZ1aaw3dN3PJK6nIgOzz5fyDRuUSlVyIAkEcQWoD8imEd4Zv9SsTjSF01OMBe9R0Ua4LpCx6ElpKkXb7KoqJaNQg= 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=l/GGtuOScvAFJljHtzLZ8uHIxE7Q0adSbQKJoW+y0MjhnzprhVq2rMtCfXtNzuGwklZm+k5WyjPhwHwMSnXf5drJ/nigbiP2ER7hRGvLG4GgIXI1joExWDjGAPfuf8dA7ow4KzFQPA1/gX9AIFw6MH07IB1tdYCaEvqzA9rqGUQ= Received: by 10.115.92.2 with SMTP id u2mr385930wal.1176929294159; Wed, 18 Apr 2007 13:48:14 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 18 Apr 2007 13:48:14 -0700 (PDT) Message-ID: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> Date: Wed, 18 Apr 2007 13:48:14 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 631b252c3ab97311 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0629418434==" Errors-To: ltru-bounces@ietf.org --===============0629418434== Content-Type: multipart/alternative; boundary="----=_Part_109643_23139757.1176929294088" ------=_Part_109643_23139757.1176929294088 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I revised the examples I circulated earlier in light of the discussion, and posted at http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 (everyone should be able to get to that document -- let me know if you have trouble.) -- Mark ------=_Part_109643_23139757.1176929294088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I revised the examples I circulated earlier in light of the discussion, and posted at

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

(everyone should be able to get to that document -- let me know if you have trouble.)

--
Mark ------=_Part_109643_23139757.1176929294088-- --===============0629418434== 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 --===============0629418434==-- From ltru-bounces@ietf.org Wed Apr 18 18:19: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 1HeIVJ-0005W0-3S; Wed, 18 Apr 2007 18:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIVH-0005Vt-UG for ltru@ietf.org; Wed, 18 Apr 2007 18:19:55 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound3-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIVD-0002du-CT for ltru@ietf.org; Wed, 18 Apr 2007 18:19:55 -0400 Received: from outbound3-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-fra-R.bigfish.com (Postfix) with ESMTP id C088611149A; Wed, 18 Apr 2007 22:19:50 +0000 (UTC) Received: from mail55-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound3-fra.bigfish.com (Postfix) with ESMTP id BEF3E9B8043; Wed, 18 Apr 2007 22:19:50 +0000 (UTC) Received: from mail55-fra (localhost.localdomain [127.0.0.1]) by mail55-fra-R.bigfish.com (Postfix) with ESMTP id B1CD525010B; Wed, 18 Apr 2007 22:19:50 +0000 (UTC) X-BigFish: VP Received: by mail55-fra (MessageSwitch) id 1176934790659941_15452; Wed, 18 Apr 2007 22:19:50 +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-fra.bigfish.com (Postfix) with ESMTP id 4AAC82D0052; Wed, 18 Apr 2007 22:19: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 2007041815182583-5344 ; Wed, 18 Apr 2007 15:18:25 -0700 In-Reply-To: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] Language Tag Special Cases 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, 18 Apr 2007 15:16:35 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/18/2007 15:16:36, Serialize complete at 04/18/2007 15:16:36, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 03:18:26 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 03:19:50 PM, Serialize complete at 04/18/2007 03:19:50 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757136488==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0757136488== Content-Type: multipart/alternative; boundary="=_alternative 007A8911882572C1_=" This is a multipart message in MIME format. --=_alternative 007A8911882572C1_= Content-Type: text/plain; charset="US-ASCII" The last use case seems problematic. If "zxx" is non-linguistic, it's not a language so there is only one language present. Also, the text in that mystery image may very well be in German -- you can't tell by looking at the binary. The binary and tags are not intended to be read by a human and would not appear in a browser, but text that occurs in tags in XHTML is. That's a distinction I think a parser would need to make. Does anyone have a real use case for zxx applied to code where a tag wouldn't do? I don't think the text cited would realistically occur anywhere except in HTML and the presentation layer of HTML is what needs tagging, not the source code. It seems to me the most common use case for "zxx" is something like the Library of Congress where musical works may or may not be associated with a language tag. If instrumental, then "zxx." Or the silent film scenario that resulted in the tag. I think these are better use cases and less likely to confuse users familiar with the code tag and HTML/XHTML standards. Regards, Karen Broome "Mark Davis" wrote on 04/18/2007 01:48:14 PM: > I revised the examples I circulated earlier in light of the > discussion, and posted at > > http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 > > (everyone should be able to get to that document -- let me know if > you have trouble.) > > -- > Mark _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 007A8911882572C1_= Content-Type: text/html; charset="US-ASCII"
The last use case seems problematic. If "zxx" is non-linguistic, it's not a language so there is only one language present.  Also, the text in that mystery image may very well be in German -- you can't tell by looking at the binary.  The binary and <image> tags are not intended to be read by a human and would not appear in a browser, but text that occurs in <code> tags in XHTML is. That's a distinction I think a parser would need to make.

Does anyone have a real use case for zxx applied to code where a <code> tag wouldn't do? I don't think the text cited would realistically occur anywhere except in HTML and the presentation layer of HTML is what needs tagging, not the source code.

It seems to me the most common use case for "zxx" is something like the Library of Congress where musical works may or may not be associated with a language tag. If instrumental, then "zxx." Or the silent film scenario that resulted in the tag. I think these are better use cases and less likely to confuse users familiar with the code tag and HTML/XHTML standards.

Regards,

Karen Broome

"Mark Davis" <mark.davis@icu-project.org> wrote on 04/18/2007 01:48:14 PM:

> I revised the examples I circulated earlier in light of the
> discussion, and posted at
>
> http://docs.google.com/Doc?id=dfqr8rd5_11g425c9
>
> (everyone should be able to get to that document -- let me know if
> you have trouble.)
>
> --
> Mark _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
 --=_alternative 007A8911882572C1_=-- --===============0757136488== 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 --===============0757136488==-- From ltru-bounces@ietf.org Wed Apr 18 19:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJUt-0004JU-3m; Wed, 18 Apr 2007 19:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJUs-0004JP-KB for ltru@ietf.org; Wed, 18 Apr 2007 19:23:34 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJUq-00031q-62 for ltru@ietf.org; Wed, 18 Apr 2007 19:23:34 -0400 Received: by wr-out-0506.google.com with SMTP id 71so300415wri for ; Wed, 18 Apr 2007 16:23: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:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KUgDINQNGVw+mG40UD98GDmAvuBeakU6PYgoRa0v/OPj9k6WXku7lxdl3yRqWbFa2XVwMDi+1XxJFbtVZdrkMOojkTNHlm9B3BLFB+hqUoNuN6r31Q27O5g0o2D16vSA89Nv4UZ97KKmAw5gcjbYs1oGU6UxBzaCLenxKkY+7Uk= 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=GFcMk6UzdesIQ5sM3O5xnxM/xsg5ZsbtVLhQT6rdmKSL47zfdDnIYspxNm7di/Kh/eeBtz7tnN6p0WErulODIdi+ulkkNFI8sWTtdXxiH0NMYOPu6y0cSV/mWkuHi2dlqdMCWljyzlYybdd0wYJpJU3pAfbqS+iaN5N/QWElUIQ= Received: by 10.114.161.11 with SMTP id j11mr464185wae.1176938611390; Wed, 18 Apr 2007 16:23:31 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 18 Apr 2007 16:23:31 -0700 (PDT) Message-ID: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> Date: Wed, 18 Apr 2007 16:23:31 -0700 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Language Tag Special Cases In-Reply-To: MIME-Version: 1.0 References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> X-Google-Sender-Auth: 6b87049e3e5351b0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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="===============1141858271==" Errors-To: ltru-bounces@ietf.org --===============1141858271== Content-Type: multipart/alternative; boundary="----=_Part_111978_4228308.1176938611315" ------=_Part_111978_4228308.1176938611315 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline comments below. On 4/18/07, Karen_Broome@spe.sony.com wrote: > > > The last use case seems problematic. If "zxx" is non-linguistic, it's not > a language so there is only one language present. That's a possible interpretation. If we have a protocol that allows multiple codes, I would tag it as , indicating that it has both kinds of content. If we don't, then I don't know what we should do. BTW, I numbered the examples to make them easier to reference. Also, the text in that mystery image may very well be in German -- you can't > tell by looking at the binary. The binary and tags are not intended > to be read by a human and would not appear in a browser, but text that > occurs in tags in XHTML is. That's a distinction I think a parser > would need to make. The intent for the binary in the example is to not have content. Does anyone have a real use case for zxx applied to code where a tag > wouldn't do? Yes. I said before, *not every environment is HTML/XML". Language tags are not just limited to HTML or XML. I don't think the text cited would realistically occur anywhere except in > HTML and the presentation layer of HTML is what needs tagging, not the > source code. > > It seems to me the most common use case for "zxx" is something like the > Library of Congress where musical works may or may not be associated with a > language tag. If instrumental, then "zxx." Or the silent film scenario that > resulted in the tag. I think these are better use cases and less likely to > confuse users familiar with the code tag and HTML/XHTML standards. That's a reasonable example, I'll add it. Regards, > > Karen Broome > > > "Mark Davis" wrote on 04/18/2007 01:48:14 PM: > > > I revised the examples I circulated earlier in light of the > > discussion, and posted at > > > > http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 > > > > (everyone should be able to get to that document -- let me know if > > you have trouble.) > > > > -- > > Mark _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_111978_4228308.1176938611315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline comments below.

On 4/18/07, Karen_Broome@spe.sony.com <Karen_Broome@spe.sony.com > wrote:

The last use case seems problematic. If "zxx" is non-linguistic, it's not a language so there is only one language present.  

That's a possible interpretation. If we have a protocol that allows multiple codes, I would tag it as  <en, zxx>, indicating that it has both kinds of content. If we don't, then I don't know what we should do.

BTW, I numbered the examples to make them easier to reference.

Also, the text in that mystery image may very well be in German -- you can't tell by looking at the binary.  The binary and <image> tags are not intended to be read by a human and would not appear in a browser, but text that occurs in <code> tags in XHTML is. That's a distinction I think a parser would need to make.

The intent for the binary in the example is to not have content.

Does anyone have a real use case for zxx applied to code where a <code> tag wouldn't do?

Yes. I said before, *not every environment is HTML/XML". Language tags are not just limited to HTML or XML.

I don't think the text cited would realistically occur anywhere except in HTML and the presentation layer of HTML is what needs tagging, not the source code.

It seems to me the most common use case for "zxx" is something like the Library of Congress where musical works may or may not be associated with a language tag. If instrumental, then "zxx." Or the silent film scenario that resulted in the tag. I think these are better use cases and less likely to confuse users familiar with the code tag and HTML/XHTML standards.

That's a reasonable example, I'll add it.

Regards,

Karen Broome

"Mark Davis" <mark.davis@icu-project.org> wrote on 04/18/2007 01:48:14 PM:


> I revised the examples I circulated earlier in light of the
> discussion, and posted at
>
> http://docs.google.com/Doc?id=dfqr8rd5_11g425c9
>
> (everyone should be able to get to that document -- let me know if
> you have trouble.)
>
> --
> Mark _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru



--
Mark ------=_Part_111978_4228308.1176938611315-- --===============1141858271== 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 --===============1141858271==-- From ltru-bounces@ietf.org Wed Apr 18 19:35: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 1HeJgi-0004hI-V8; Wed, 18 Apr 2007 19:35:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJgh-0004h9-Lh for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:35:47 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJgf-0006Dl-6K for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:35:47 -0400 Received: from c83-248-98-120.bredband.comhem.se ([83.248.98.120]:2761 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HeJgd-000483-6W for ltru@lists.ietf.org; Thu, 19 Apr 2007 01:35:43 +0200 From: "Kent Karlsson" To: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><00a201c78124$0713eaa0$7a63f853@streamserve.com><005001c78191$ec1468b0$7a63f853@streamserve.com> Subject: RE: [Ltru] Re: "mis" update review request Date: Thu, 19 Apr 2007 01:38:10 +0200 Message-ID: <007501c78212$a01ac680$7862f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAPTTEgAAHhTfAAHWGbIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HeJgd-000483-6W. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HeJgd-000483-6W ff9700f7ea9a1c244f8f5bbc367ccf17 X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 curtsey to Frank I converted this email to plain text. However, I = may well respond to HTML format emails in HTML format in future as well.) Peter Constable wrote: > You don=92t seem to be grasping: mis is fundamentally different from = every other collection. > They are all defined in terms of membership in some set; mis is = defined in terms of > exclusion from everything else. Indeed I don't grasp that, especially since your interpretation is not = supported by the normative text of 639-2 as given at = http://www.loc.gov/standards/iso639-2/normtext.html. Only und and mul are listed as "special" (subclause 4.1.2, which I guess = has not been updated when zxx was added, which is admittedly "special"). The = collective codes are covered by the text in subclause 4.1.1. And they are all given as = semi-inclusive/semi-exclusive. || The words languages or (other) as part of a language name in the = following tables || may be taken to indicate that a language code is a collective = language code. || A collective language code is not intended to be used when an = individual language code || or another more specific collective language code is available. So it does not matter whether the word "languages" or the word "other" = is used, the semantics is the same at the meta-level. "mis", "tai", "gem", and other collective = codes are on an equal standing. But the text does not say "shall not be used when...", = not even "should not...", but just a feeble "not intended to...". Thus it is fully conformant with = 639-2 to use all and any of the collective codes ("mis" included) as inclusive, and only = have a recommendation to use a more specific code "is available". Note that also the "is = available" part is weak. Is available where? In the 639-2 code list? In the 639-3 code list? In = some arbitrary selection of the codes? Ok, the latter does not really matter, since the = recommendation to use a more specific code is not even a weak "should", it's not there = at all, its just a *usage recommendation*, **not** a coverage limitation. Thus "mis" = already covers all languages, there is no exclusion in coverage, just an "avoid use = when possible" recommendation. The word "other" is thus just misleading when it comes = to the coverage definition as is the pluralness of "languages"; both should be replaced = by "language". That would just be a clarification, not a semantic change (as it turns = out, reading the normative text of the standard). Ok, so the text in 639-2 isn't the best standardese ever written, but I = think it is clear enough on these points: "mis" is already "any language" (with a = **weak** recommendation to use a more specific code "when available", similar to = the "tag wisely" recommendation in 4646). "und" is even more general, covering all of = "mis", as well as "mul" and the new "zxx". The "may be taken" part (see quote above) is = unnecessarily weak, though. B.t.w. an image may well contain linguistic data: not just photographs = of text, but generated from scratch as well (instead of generating, say, a PDF = document, one can generate a series of images of the pages). Images of text, as = well as sound tracks, may perfectly well be language tagged with ordinary = (non-zxx, and preferably as specific as possible among the 639-x language codes) = language tags. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 19:38: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 1HeJjG-0005Hu-TX; Wed, 18 Apr 2007 19:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJjG-0005Hm-2r for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:38:26 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJjF-0007IQ-04 for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:38:25 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 16:38:24 -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; Wed, 18 Apr 2007 16:38:23 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Wed, 18 Apr 2007 16:38:22 -0700 Subject: RE: [Ltru] Re: zxx Thread-Topic: [Ltru] Re: zxx Thread-Index: AceB6rsJtsRA/RXcSkWzkIsE9wUMdwAJyTZw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0322953773==" Errors-To: ltru-bounces@ietf.org --===============0322953773== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B1FNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B1FNAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > I'm much more comfortable with "whatever content is in here, > it doesn't have an in-scope attribute" than adding the phrase > "could be a programming language." I'd agree that code is not > generally a spoken human language and is out of scope if ISO > 639 intends to identify spoken human languages. ISO 639 is explicit: programming languages are out of scope. > That doesn't necessarily mean that xml:lang tags are the best > way to indicate this code. There are already recommended ways > to do this in HTML and XHTML that do not include the xml:lang > tag. We should not imply that the xml:lang tag and "zxx" > replace these uses. I completely agree. All I have said is that, if someone must (for whatever = reason) tag programming code with an ISO 639 ID, then zxx is the appropriat= e choice. > For the sake of argument, don't most of us read at least some > type of code as a written language? It may not have the same > properties as other human language, and I'll agree this is > outside the scope of the 639 standards according to the document > text. But to call code "non-linguistic" still just strikes me > as wrong. ISO 639 treats "linguistic" as those things that are in scope for coding in= that standard. That may not align exactly with everyone's idea of "linguis= tic", but that is not a problem for ISO 639. It is clear about what it does= and does not code. Peter --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B1FNAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]

> I'm muc= h more comfortable with "whatever content is in here,

> it doe= sn't have an in-scope attribute" than adding the phrase

> "= could be a programming language." I'd agree that code is not

> genera= lly a spoken human language and is out of scope if ISO

>  = 639 intends to identify spoken human languages.

 

ISO 639 is explicit: programming languages are out of scope.=



> That doesn't necessarily mean that xml:lang tag= s are the best

> way to indicate this code. There are already recommended ways

> to do = this in HTML and XHTML that do not include the xml:lang

> tag. W= e should not imply that the xml:lang tag and "zxx"

> replac= e these uses.

 

I completely agree. All I have said is that, if someone must= (for whatever reason) tag programming code with an ISO 639 ID, then zxx is the appropriate choice.



> For the sake of argument, don't most of us read = at least some

> type o= f code as a written language? It may not have the same

>= ; properties as other human language, and I'll agr= ee this is

>= ; outside the scope of the 639 standards according= to the document

> text. = But to call code "non-linguistic" still just strikes me

>= ; as wrong.

ISO 639 treats “li= nguistic” as those things that are in scope for coding in that standard. That may not al= ign exactly with everyone’s idea of “linguistic”, but that is= not a problem for ISO 639. It is clear about what it does and does not code.

 

 

Peter

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B1FNAEXMSGC117re_-- --===============0322953773== 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 --===============0322953773==-- From ltru-bounces@ietf.org Wed Apr 18 19:46: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 1HeJqp-0005sI-BG; Wed, 18 Apr 2007 19:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJqn-0005qq-CX for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:46:13 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJmz-0000Cx-Ie for ltru@lists.ietf.org; Wed, 18 Apr 2007 19:42:18 -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.685.24; Wed, 18 Apr 2007 16:42:17 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Wed, 18 Apr 2007 16:42:13 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@lists.ietf.org" Date: Wed, 18 Apr 2007 16:42:12 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceBYoqlCUcwMO4SRSy42gTlFKlvQQAsDKag Message-ID: References: <20070413122917.GA25431@nic.fr> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> In-Reply-To: <30b660a20704171937j4c62c409jd07a290ef1498612@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: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0788443778==" Errors-To: ltru-bounces@ietf.org --===============0788443778== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B2ANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B2ANAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis > However, your using "pet scenario" to characterize something that I and > many others consider "important scenario", like language detection, is > unnecessary.) I was not referring to tasks like language detection. I was referring to ca= ses like "content is programming code which I perceive to be in some way li= nguistic". Such individual perceptions are entirely valid as just that - in= dividual perceptions - but have no direct connection to the concepts coded = in ISO 639 and should not be confused with them. Peter --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B2ANAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis

> However, you= r using "pet scenario" to characterize something that I and

> many others consider "important scenario&qu= ot;, like language detection, is

> unnecessary.)

I was not referring to tasks like language detection. I was referring to cases like “content is programming code= which I perceive to be in some way linguistic”. Such individual perceptions a= re entirely valid as just that – individual perceptions – but have no direc= t connection to the concepts coded in ISO 639 and should not be confused with them.

 =

 =

 =

Peter<= /p>

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96B2ANAEXMSGC117re_-- --===============0788443778== 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 --===============0788443778==-- From ltru-bounces@ietf.org Wed Apr 18 20:22:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKPs-0003cz-Dx; Wed, 18 Apr 2007 20:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKPr-0003Yk-6e for ltru@ietf.org; Wed, 18 Apr 2007 20:22:27 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound3-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeKPn-0008H3-NZ for ltru@ietf.org; Wed, 18 Apr 2007 20:22:27 -0400 Received: from outbound3-dub.bigfish.com (localhost [127.0.0.1]) by outbound3-dub-R.bigfish.com (Postfix) with ESMTP id 2E73B10A0D1F; Thu, 19 Apr 2007 00:22:23 +0000 (UTC) Received: from mail193-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound3-dub.bigfish.com (Postfix) with ESMTP id 14A441F804D; Thu, 19 Apr 2007 00:22:23 +0000 (UTC) Received: from mail193-dub (localhost [127.0.0.1]) by mail193-dub-R.bigfish.com (Postfix) with ESMTP id C3B01161011C; Thu, 19 Apr 2007 00:22:22 +0000 (UTC) X-BigFish: VP Received: by mail193-dub (MessageSwitch) id 1176942142726939_16502; Thu, 19 Apr 2007 00:22:22 +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 mail193-dub.bigfish.com (Postfix) with ESMTP id 6F8E2AC804D; Thu, 19 Apr 2007 00:22:22 +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 2007041817222058-12131 ; Wed, 18 Apr 2007 17:22:20 -0700 In-Reply-To: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] Language Tag Special Cases 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, 18 Apr 2007 17:20:30 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/18/2007 17:20:31, Serialize complete at 04/18/2007 17:20:31, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 05:22:20 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/18/2007 05:22:22 PM, Serialize complete at 04/18/2007 05:22:22 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: LTRU Working Group , mark.edward.davis@gmail.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: , Content-Type: multipart/mixed; boundary="===============0028023657==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0028023657== Content-Type: multipart/alternative; boundary="=_alternative 00020B33882572C2_=" This is a multipart message in MIME format. --=_alternative 00020B33882572C2_= Content-Type: text/plain; charset="US-ASCII" Mark, Yes, I understand that there are worlds other than XHTML and HTML, but I can't come up with a use case (for identifying programming code with zxx) outside of those instances. And I can see a danger in suggesting these codes for use in XHTML and HTML code markup -- not an insignificant consideration. The "code snippet" scenario seems most frequent in technical tutorials and books where code is intended to be read. In an instance of running code, you might identify the language of a "language snippet" but not the code around it. Isn't most code self-identifying? Honestly, I just don't see the real-life scenario here. Please enlighten me. I'm not saying there isn't a use case. I'm just saying I can't think of one and don't think your example is realistic or useful. If you updated the example to include other scenarios, that helps. I'd just like to get away from thinking of this tag as being synonymous with code or binary junk. There are other more likely uses for the esteemed zxx tag. Regards, Karen Broome --=_alternative 00020B33882572C2_= Content-Type: text/html; charset="US-ASCII"
Mark,

Yes, I understand that there are worlds other than XHTML and HTML, but I can't come up with a use case (for identifying programming code with zxx) outside of those instances.   And I can see a danger in suggesting these codes for use in XHTML and HTML code markup -- not an insignificant consideration.

The "code snippet" scenario seems most frequent in technical tutorials and books where code is intended to be read. In an instance of running code, you might identify the language of a "language snippet" but not the code around it. Isn't most code self-identifying?

Honestly, I just don't see the real-life scenario here. Please enlighten me. I'm not saying there isn't a use case. I'm just saying I can't think of one and don't think your example is realistic or useful. If you updated the example to include other scenarios, that helps.  I'd just like to get away from thinking of this tag as being synonymous with code or binary junk. There are other more likely uses for the esteemed zxx tag.

Regards,

Karen Broome

--=_alternative 00020B33882572C2_=-- --===============0028023657== 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 --===============0028023657==-- From ltru-bounces@ietf.org Wed Apr 18 21:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeLn7-0001ed-5c; Wed, 18 Apr 2007 21:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeLn5-0001ap-Vd for ltru@lists.ietf.org; Wed, 18 Apr 2007 21:50:31 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeLn3-0000wl-MH for ltru@lists.ietf.org; Wed, 18 Apr 2007 21:50:31 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HeLn2-0001Rw-OI; Wed, 18 Apr 2007 21:50:28 -0400 Date: Wed, 18 Apr 2007 21:50:28 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070419015028.GA1262@mercury.ccil.org> References: <007501c78212$a01ac680$7862f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c78212$a01ac680$7862f853@streamserve.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > (As a curtsey to Frank I converted this email to plain text. However, > I may well respond to HTML format emails in HTML format in future > as well.) As a courtesy to me and everyone else, please don't do so, but convert all your list emails to plain text. > Indeed I don't grasp that, especially since your interpretation > is not supported by the normative text of 639-2 as given at > http://www.loc.gov/standards/iso639-2/normtext.html. Normatively, then, you can use any other code element for anything at all? Or is it that you can use "se" for any language(s) you choose to call "Swedish", however much the rest of us may prefer the term "Fulani"? > So it does not matter whether the word "languages" or the word "other" [long rant snipped] > That would just be a clarification, not a semantic change (as it turns > out, reading the normative text of the standard). This is a marvelous illustration of why, in the case of 639, the standard alone does not suffice. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 18 23:55: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 1HeNjc-0004rV-Es; Wed, 18 Apr 2007 23:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeNjb-0004rK-Nv for ltru@ietf.org; Wed, 18 Apr 2007 23:55:03 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeNjZ-0007JJ-Pq for ltru@ietf.org; Wed, 18 Apr 2007 23:55:03 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 20:55:01 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Wed, 18 Apr 2007 20:55:00 -0700 From: Peter Constable To: Mark Davis , LTRU Working Group Date: Wed, 18 Apr 2007 20:54:55 -0700 Subject: RE: [Ltru] Language Tag Special Cases Thread-Topic: [Ltru] Language Tag Special Cases Thread-Index: AceB+uXFtFMin1qwS+6xR8t3uQkiIQAOqeyQ Message-ID: References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> In-Reply-To: <30b660a20704181348g194439b6sefa511e16211a901@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: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469350850==" Errors-To: ltru-bounces@ietf.org --===============1469350850== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96C36NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96C36NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the context of BCP 47, it's about as appropriate to tag "What?" as mis a= s it is to tag it fr. In *some* application of ISO 639, mis might be approp= riate, but I would not consider BCP 47 to be such a case. Peter From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Wednesday, April 18, 2007 1:48 PM To: LTRU Working Group Subject: [Ltru] Language Tag Special Cases I revised the examples I circulated earlier in light of the discussion, and= posted at http://docs.google.com/Doc?id=3Ddfqr8rd5_11g425c9 (everyone should be able to get to that document -- let me know if you have= trouble.) -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96C36NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the context of BCP 47, it’s about as appropriate to= tag “What?” as mis as it is to tag it fr. In *some* applicat= ion of ISO 639, mis might be appropriate, but I would not consider BCP 47 to be such a case.

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Wednesday, April 18, 2007 1:48 PM
To: LTRU Working Group
Subject: [Ltru] Language Tag Special Cases

 

I revised the examples I circulated earlier in light o= f the discussion, and posted at

http://docs.google.com/Doc?id=3Ddfqr8rd5_11g425c9=

(everyone should be able to get to that document -- let me know if you have trouble.)

--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F96C36NAEXMSGC117re_-- --===============1469350850== 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 --===============1469350850==-- From ltru-bounces@ietf.org Thu Apr 19 00: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 1HeO1C-0004my-4V; Thu, 19 Apr 2007 00:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeO1A-0004mc-J0 for ltru@lists.ietf.org; Thu, 19 Apr 2007 00:13:12 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeO17-00039h-Qd for ltru@lists.ietf.org; Thu, 19 Apr 2007 00:13:12 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 18 Apr 2007 21:13:09 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Wed, 18 Apr 2007 21:13:08 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Wed, 18 Apr 2007 21:13:04 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAPTTEgAAHhTfAAHWGbIAAK+gLQ Message-ID: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><00a201c78124$0713eaa0$7a63f853@streamserve.com><005001c78191$ec1468b0$7a63f853@streamserve.com> <007501c78212$a01ac680$7862f853@streamserve.com> In-Reply-To: <007501c78212$a01ac680$7862f853@streamserve.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.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > Indeed I don't grasp that, especially since your > interpretation is not supported by the normative text > of 639-2 as given at http://www.loc.gov/standards/iso639-2/normtext.html. All your words and careful attempt to make logical deductions from the norm= ative text of ISO 639-2 does not change the origin, legacy, intended meanin= g and most-representative existing usage of mis. > Only und and mul are listed as "special" Because the people that prepared the text for ISO 639-2 did not think throu= gh and analyze the code set in any formally-rigourous way -- they weren't p= aying anywhere as close attention as you just did in your message to the de= tails of what they were doing. > So it does not matter whether the word "languages" or > the word "other" is used, the semantics is the same at > the meta-level. "mis", "tai", "gem", and other collective > codes are on an equal standing. In terms of what the authors intended, I believe that's not the case: IIUC,= the "other" collections were assumed to be cases in which there was at lea= st one individual-language member of the general category that was coded, w= hile for the "languages" collection it was assumed there was not. Careful e= xamination reveals that those principles do not hold up, but that was still= the intent and assumption of the authors. (Note that, in ISO 639-3, where I was trying to ensure a good measure of fo= rmal rigour, we did not differentiate two different sub-types of collection= scope.) > Thus it is fully conformant with 639-2 to use all and any of > the collective codes ("mis" included) as inclusive... Thus "mis" > already covers all languages, there is no exclusion in coverage, > just an "avoid use when possible" Again, all your words and logic don't change what original sources, existin= g usage, etc. tell us about the semantic of mis, which clearly is not as yo= u're describing. The source standard from which mis was taken into ISO 639-= 2 is quite clear: mis is not used for just any language, but for a relative= handful -- I enumerated them in mail last week. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 00:59: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 1HeOjh-0006dB-4C; Thu, 19 Apr 2007 00:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOjf-0006cz-UA for ltru@ietf.org; Thu, 19 Apr 2007 00:59:11 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeOjf-0000nS-GC for ltru@ietf.org; Thu, 19 Apr 2007 00:59:11 -0400 Received: by nz-out-0506.google.com with SMTP id z6so379244nzd for ; Wed, 18 Apr 2007 21:59: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=lc5UJLZnFe14dgR4Sx87c1OmEUaIVVkArIczOk7h8kYISIJFfN+Ylbq7ftxXOKF+rmHQVaZ5ke2EMR2xTSLBq3z6HsXhW3WX0umv9l1KlkBaSy7aZqM6bmT2Ga5VB5/2ZUfuXtf6XYj3TWwX6y3JcLKdjzfA5UQ4C/ORROWGkXI= 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=fop4Be2l+PbYDdthb+1eEsQ3TKNh9HDLutmtEHUM3mBI/M4QRS92++sEGe2zlHGnXyyOkRFGuvN5mjhBW8ZJhfv29QC3S6SBmRmGvsXA35SQJZ13MGGKRIeJw9z/0iegzjC5wCSIzJcfnlQinsYeDUfAy1s1mWkKpwLeihTOJAM= Received: by 10.115.106.7 with SMTP id i7mr546757wam.1176958750849; Wed, 18 Apr 2007 21:59:10 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 18 Apr 2007 21:59:10 -0700 (PDT) Message-ID: <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> Date: Wed, 18 Apr 2007 21:59:10 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Language Tag Special Cases In-Reply-To: MIME-Version: 1.0 References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> X-Google-Sender-Auth: a8c2c4f002830558 X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============1814907378==" Errors-To: ltru-bounces@ietf.org --===============1814907378== Content-Type: multipart/alternative; boundary="----=_Part_115723_18391322.1176958750794" ------=_Part_115723_18391322.1176958750794 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I disagree. As far as the ISO 639-2 standard is concerned, the only thing defining "mis" is that it is the phrase "Miscellaneous languages", and the phrasing clarifying that "languages" means it is a collection. Nothing else. Nada. Zilch. It is, of course, woefully underspecified, but there is no particular reason in the ISO 639-2 standard to think that it applies to English any more or less than that it applies to Ainu or that it applies to Kamchadal, or any of the others you listed. It may in fact be true that "mis" was intended to mean something else before it got into the ISO standard, but that doesn't matter: it doesn't change the fact that as defined in the ISO 639-2 standard which is the basis for the BCP 47 codes, it applies equally well to any of the three above. One could argue that "mis" is so badly specified that we should just discourage its use. I mention that possibility in my document, and at this point, that may just be the best approach. Now separately, I think it would be useful to have a special code, special in the same sense as zxx and und, that just meant the opposite of zxx: that is "some (unspecified) linguistic content". And it had seemed to me that "mis" fit the bill, or with slight broadening could fit that bill, and is otherwise pretty useless anyway. But it appears so contentious to push for this interpretation of "mis" that despite the utility of taking this approach, it is probably not worth it. I think what is more important is to follow up on your suggestion, and remove the exclusionary nature of the "(Other)" collections, preferably in ISO 639-2 (but failing that, in 4646bis) so that we have a much more useful and consistent approach to collections overall. Mark On 4/18/07, Peter Constable wrote: > > In the context of BCP 47, it's about as appropriate to tag "What?" as mis > as it is to tag it fr. In **some** application of ISO 639, mis might be > appropriate, but I would not consider BCP 47 to be such a case. > > > > Peter > > > > *From:* Mark Davis [mailto:mark.davis@icu-project.org] > *Sent:* Wednesday, April 18, 2007 1:48 PM > *To:* LTRU Working Group > *Subject:* [Ltru] Language Tag Special Cases > > > > I revised the examples I circulated earlier in light of the discussion, > and posted at > > http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 > > (everyone should be able to get to that document -- let me know if you > have trouble.) > > -- > Mark > -- Mark ------=_Part_115723_18391322.1176958750794 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I disagree. As far as the ISO 639-2 standard is concerned, the only thing defining "mis" is that it is the phrase "Miscellaneous languages", and the phrasing clarifying that "languages" means it is a collection. Nothing else. Nada. Zilch.

It is, of course, woefully underspecified, but there is no particular reason in the ISO 639-2 standard to think that it applies to English any more or less than that it applies to Ainu or that it applies to Kamchadal, or any of the others you listed. It may in fact be true that "mis" was intended to mean something else before it got into the ISO standard, but that doesn't matter: it doesn't change the fact that as defined in the ISO 639-2 standard which is the basis for the BCP 47 codes, it applies equally well to any of the three above.

One could argue that "mis" is so badly specified that we should just discourage its use. I mention that possibility in my document, and at this point, that may just be the best approach.

Now separately, I think it would be useful to have a special code, special in the same sense as zxx and und, that just meant the opposite of zxx: that is "some (unspecified) linguistic content". And it had seemed to me that "mis" fit the bill, or with slight broadening could fit that bill, and is otherwise pretty useless anyway. But it appears so contentious to push for this interpretation of "mis" that despite the utility of taking this approach, it is probably not worth it.

I think what is more important is to follow up on your suggestion, and remove the exclusionary nature of the "(Other)" collections, preferably in ISO 639-2 (but failing that, in 4646bis) so that we have a much more useful and consistent approach to collections overall.

Mark

On 4/18/07, Peter Constable <petercon@microsoft.com> wrote:

In the context of BCP 47, it's about as appropriate to tag "What?" as mis as it is to tag it fr. In *some* application of ISO 639, mis might be appropriate, but I would not consider BCP 47 to be such a case.

 

Peter

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Wednesday, April 18, 2007 1:48 PM
To: LTRU Working Group
Subject: [Ltru] Language Tag Special Cases

 

I revised the examples I circulated earlier in light of the discussion, and posted at

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

(everyone should be able to get to that document -- let me know if you have trouble.)

--
Mark




--
Mark ------=_Part_115723_18391322.1176958750794-- --===============1814907378== 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 --===============1814907378==-- From ltru-bounces@ietf.org Thu Apr 19 01:53: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 1HePaJ-0006ll-76; Thu, 19 Apr 2007 01:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HePaH-0006lY-9N for ltru@ietf.org; Thu, 19 Apr 2007 01:53:33 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HePaG-0008JW-1f for ltru@ietf.org; Thu, 19 Apr 2007 01:53:33 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HePaF-0001Kp-CB; Thu, 19 Apr 2007 01:53:31 -0400 Date: Thu, 19 Apr 2007 01:53:31 -0400 To: Mark Davis Subject: Re: [Ltru] Language Tag Special Cases Message-ID: <20070419055331.GF1262@mercury.ccil.org> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I disagree. As far as the ISO 639-2 standard is concerned, the > only thing defining "mis" is that it is the phrase "Miscellaneous > languages", and the phrasing clarifying that "languages" means it is > a collection. Nothing else. Nada. Zilch. And as far as the ISO 639-2 standard is concerned, the only thing defining "bal" is the phrase "Baltic (Other)", which means anything tagged by it is in a language belonging to the "Baltic" collection. So I decide that "Baltic" means the Baltic Sea, and therefore that Swedish, Finnish, Danish, German, Russian, and Polish are "Baltic (Other)" and it's perfectly legitimate to tag them "bal". One gerrymandered interpretation of a short ambiguous phrase is as good as another. -- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 03:04: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 1HeQhG-0000ry-Ft; Thu, 19 Apr 2007 03:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQhE-0000qp-QV for ltru@ietf.org; Thu, 19 Apr 2007 03:04:48 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeQhD-0000t6-Gv for ltru@ietf.org; Thu, 19 Apr 2007 03:04:48 -0400 Received: from [10.76.37.195] (wifi-postauth195.london.corp.yahoo.com [10.76.37.195]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3J74TYP056885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2007 00:04:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=pNfiI4kjpv5QLkpLySJoUxOk4Vnw6CEwmVCcAUQ9XYQ9usDXZQiUDBmBodO5tLla Message-ID: <4627147C.6030104@yahoo-inc.com> Date: Thu, 19 Apr 2007 08:04:28 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Language Tag Special Cases References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> <20070419055331.GF1262@mercury.ccil.org> In-Reply-To: <20070419055331.GF1262@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> I disagree. As far as the ISO 639-2 standard is concerned, the >> only thing defining "mis" is that it is the phrase "Miscellaneous >> languages", and the phrasing clarifying that "languages" means it is >> a collection. Nothing else. Nada. Zilch. > > And as far as the ISO 639-2 standard is concerned, the only thing defining > "bal" is the phrase "Baltic (Other)", which means anything tagged by it > is in a language belonging to the "Baltic" collection. So I decide that > "Baltic" means the Baltic Sea, and therefore that Swedish, Finnish, > Danish, German, Russian, and Polish are "Baltic (Other)" and it's > perfectly legitimate to tag them "bal". > > One gerrymandered interpretation of a short ambiguous phrase is as good > as another. > +1 "mis" means "here's some otherwise uncategorized language". I'm sure that the librarians (see: ISO 639-2/B) quite frequently have a use for this code in their card catalogs (for manuscripts in various languages not otherwise given a code). The usefulness of this code in other information systems (such as Mark or I work on) is *quite* limited (i.e. non-existent), but clearly there is a use for tagging/finding "stuff not otherwise cataloged". In many ways, the relative ambiguity/underspecification of the codes is useful. Rather than having dense arguments about where (say) German stops and some dialect of German begins, we are free to tag most recognizably German documents with "de" and have done. We provide several means of applying more specificity (especially with the advent of ISO 639-3). But we still can usually get by with the vagueness of "de" quite frequently (substitute your favorite language here). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 04:26: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 1HeRyR-0003nf-9J; Thu, 19 Apr 2007 04:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRyP-0003ej-Jq for ltru@ietf.org; Thu, 19 Apr 2007 04:26:37 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeRyO-00063e-AM for ltru@ietf.org; Thu, 19 Apr 2007 04:26:37 -0400 Received: from c83-248-99-207.bredband.comhem.se ([83.248.99.207]:3952 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HeRyM-0007Rr-6A; Thu, 19 Apr 2007 10:26:35 +0200 From: "Kent Karlsson" To: "'Mark Davis'" , "'Peter Constable'" References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> Subject: RE: [Ltru] Language Tag Special Cases Date: Thu, 19 Apr 2007 10:28:59 +0200 Message-ID: <00b801c7825c$c98d20e0$7862f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> Thread-Index: AceCP3uBJVnZEp0LQWOqnRENRdg6twAGZMGw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HeRyM-0007Rr-6A. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HeRyM-0007Rr-6A e9e39737782315b2a075553e86b63a28 X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I disagree. As far as the ISO 639-2 standard is concerned, the only thing > defining "mis" is that it is the phrase "Miscellaneous languages", and > the phrasing clarifying that "languages" means it is a collection. Nothing > else. Nada. Zilch. I mostly agree with Mark here. (The standard does say a little bit more, and there are indeed a lot left open for the collections, esp. what the hierarchy really is.) > I think what is more important is to follow up on your suggestion, > and remove the exclusionary nature of the "(Other)" collections, preferably > in ISO 639-2 (but failing that, in 4646bis) so that we have a much more > useful and consistent approach to collections overall. The standard itself does not support any "exclusionary nature" interpretation, though that seems to be suggested by the use of the word "other". /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 04:27: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 1HeRyu-0004ib-QU; Thu, 19 Apr 2007 04:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRyt-0004iQ-F9 for ltru@lists.ietf.org; Thu, 19 Apr 2007 04:27:07 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeRys-0006Cj-1o for ltru@lists.ietf.org; Thu, 19 Apr 2007 04:27:07 -0400 Received: from c83-248-99-207.bredband.comhem.se ([83.248.99.207]:3964 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HeRyq-00083D-6F; Thu, 19 Apr 2007 10:27:05 +0200 From: "Kent Karlsson" To: "'John Cowan'" References: <007501c78212$a01ac680$7862f853@streamserve.com> <20070419015028.GA1262@mercury.ccil.org> Subject: RE: [Ltru] Re: "mis" update review request Date: Thu, 19 Apr 2007 10:29:19 +0200 Message-ID: <00b901c7825c$db724650$7862f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070419015028.GA1262@mercury.ccil.org> Thread-Index: AceCJSKlZ3t5rPWHTA+CTAvuf21A8AANE1yA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HeRyq-00083D-6F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HeRyq-00083D-6F 8cd04bd69ab6f660c3e25d0871c4f661 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > (As a curtsey to Frank I converted this email to plain text. However, > > I may well respond to HTML format emails in HTML format in future > > as well.) > > As a courtesy to me and everyone else, please don't do so, but convert > all your list emails to plain text. But it's a pain and entails lots of manual editing of quoted texts. (No, I do NOT want to change any default setting or anything.) Why am I the only one to be complained upon for sending HTML mails? Mark and Peter send such mails regularly. > > Indeed I don't grasp that, especially since your interpretation > > is not supported by the normative text of 639-2 as given at > > http://www.loc.gov/standards/iso639-2/normtext.html. > > Normatively, then, you can use any other code element for > anything at all? > Or is it that you can use "se" for any language(s) you choose to > call "Swedish", however much the rest of us may prefer the > term "Fulani"? I haven't got the foggiest idea what you are trying to say here. (Esp. since se is "northern Sami", but even disregarding that I cannot make any sense of what you say here.) > > So it does not matter whether the word "languages" or the > word "other" > > [long rant snipped] The text of 639-2 DOES lend itself to being interpreted, and I gave an interpretation (which I do not think is in any way at all "gerrymandered", but instead rather straight-forward). That you and Peter don't agree with it is another matter, but I don't see how your or Peter's interpretations (as given in previous emails) can at all be supported by the text of 639-2 (without "gerrymandering"). > > That would just be a clarification, not a semantic change (as it turns > > out, reading the normative text of the standard). > > This is a marvelous illustration of why, in the case of 639, > the standard alone does not suffice. Indeed it does not suffice, but still there is no way it can be interpreted the way you and Peter want to. Your interpretations are in quite distinct non-conformity with the 639-2 standard itself. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 07:37: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 1HeUxG-0001OM-Sz; Thu, 19 Apr 2007 07:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUxF-0001O5-FF for ltru@ietf.org; Thu, 19 Apr 2007 07:37:37 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeUxE-0001IM-5Z for ltru@ietf.org; Thu, 19 Apr 2007 07:37:37 -0400 Received: from c83-248-99-207.bredband.comhem.se ([83.248.99.207]:1793 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HeUxC-0001d9-9I for ltru@ietf.org; Thu, 19 Apr 2007 13:37:35 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com><30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> <00b801c7825c$c98d20e0$7862f853@streamserve.com> Subject: RE: [Ltru] Language Tag Special Cases Date: Thu, 19 Apr 2007 13:40:03 +0200 Message-ID: <00c101c78277$7893f4f0$7862f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <00b801c7825c$c98d20e0$7862f853@streamserve.com> Thread-Index: AceCP3uBJVnZEp0LQWOqnRENRdg6twAGZMGwAAcrvmA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HeUxC-0001d9-9I. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HeUxC-0001d9-9I 8cbfd2da3d7ad009270b99dc4d52ad2a X-Spam-Score: 0.5 (/) 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 I wrote: > The standard itself does not support any "exclusionary nature" interpretation, > though that seems to be suggested by the use of the word "other". Indeed, the sentence (from the normative text of 639-2) "A collective language code is not intended to be used when an individual language code or another more specific collective language code is available." does not even make sense unless there is an inclusion (specificity) relationship between the coverages of the collection codes. If "other" really was exclusionary, that would effectively remove all and any inclusionary relationships. So, as I suggested earlier, I think that the names should be clarified by removing the word "other" (replacing it by "language" if not already there, as well as clarifying "languages to "language" (adding it where missing, but it is really a collection). Both of these changes would be purely clarifications, no semantic change, as all of the collection codes are already inclusive w.r.t. coverage. E.g. 'tai' covers all Tai languages (one at the time), 'gem' covers all Germanic languages (one at the time), and 'mis' covers all languages (one at the time). A usage recommendation is not the same as coverage. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 19 10:36: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 1HeXk9-0004kP-NW; Thu, 19 Apr 2007 10:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXk8-0004k9-2s for ltru@lists.ietf.org; Thu, 19 Apr 2007 10:36:16 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXk5-0003dw-OK for ltru@lists.ietf.org; Thu, 19 Apr 2007 10:36:16 -0400 Received: from [10.76.37.213] (wifi-postauth213.london.corp.yahoo.com [10.76.37.213]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3JEZwtl028454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2007 07:36:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=k+CCPKZtO4/PQ5ssEuf181Rnwk7Y2HqlhVhx9/etSWxYdlE76XdSSE3b0fwgHrzr Message-ID: <46277E4F.6080705@yahoo-inc.com> Date: Thu, 19 Apr 2007 15:35:59 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: zxx 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: 8abaac9e10c826e8252866cbe6766464 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > > ISO 639 is explicit: programming languages are out of scope. So is BCP 47. Specifically, Section 2 clearly states: -- 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. -- > > I completely agree. All I have said is that, if someone must (for > whatever reason) tag programming code with an ISO 639 ID, then zxx is > the appropriate choice. +1, although you SHOULD NOT use a language tag for programming code. The use of 'zxx' for programming code or other non-linguistic data is only when one is *forced* to, unavoidably, provide a language tag. Personally, I was always much more fond of the empty string for this in XML. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 07:00: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 1HeqqZ-0006Q5-08; Fri, 20 Apr 2007 07:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqqW-0006Pz-Uo for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:00:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeqqV-0005Mm-HM for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:00:08 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HeqqQ-0005uf-Lm for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:00:02 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:00:02 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:00:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 12:57:58 +0200 Organization: Lines: 23 Message-ID: <46289CB6.3C97@xyzzy.claranet.de> References: <20070413122917.GA25431@nic.fr> <005001c77e00$fb1e1160$6601a8c0@oemcomputer> <30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com> <017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> However, your using "pet scenario" to characterize something that I >> and many others consider "important scenario", like language detection, >> is unnecessary. > I was not referring to tasks like language detection. I was referring > to cases like "content is programming code which I perceive to be in > some way linguistic". Such individual perceptions are entirely valid > as just that "individual perceptions" but have no direct connection > to the concepts coded in ISO 639 and should not be confused with them. [Quote marks edited by me, keeping LTRU on the CC list, but actually I think this can be solved on the subtag review list under BCP 47 rules.] I said "zxx for code is barbaric" based on its description "no linguistic content". While I agree that this is an "individual perception" and not covered by BCP 47 I also propose that we need a short comment in the "zxx" record stating that this tag can be used for code. The description "no linguistic content" is misleading in the case of code. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 07:16: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 1Her6C-0004By-VJ; Fri, 20 Apr 2007 07:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Her6B-0004BU-R5 for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:16:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Her6B-0002Fo-Ge for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:16:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Her5z-0008N1-9b for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:16:07 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:16:07 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:16:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 13:15:35 +0200 Organization: Lines: 17 Message-ID: <4628A0D7.491D@xyzzy.claranet.de> References: <46277E4F.6080705@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: zxx X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > you SHOULD NOT use a language tag for programming code. The use of > 'zxx' for programming code or other non-linguistic data is only > when one is *forced* to, unavoidably, provide a language tag. > Personally, I was always much more fond of the empty string for > this in XML. +1 for the latter. I'd also consider "i-default" if forced to use a tag for all programming languages I know. Do we have one tag too much for this situation ? Admittedly "zxx" is more flexible, it can have scripts, extensions (in theory), and annotations in the style x-whatever. OTOH we might not like this "zxx" flexibility. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 07:39: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 1HerT1-000671-T4; Fri, 20 Apr 2007 07:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerT0-00064o-QC for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:39:54 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HerSz-00077W-IL for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:39:54 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HerSz-00034P-1W; Fri, 20 Apr 2007 07:39:53 -0400 Date: Fri, 20 Apr 2007 07:39:53 -0400 To: Frank Ellermann Message-ID: <20070420113952.GS1262@mercury.ccil.org> References: <46277E4F.6080705@yahoo-inc.com> <4628A0D7.491D@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4628A0D7.491D@xyzzy.claranet.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@lists.ietf.org Subject: [Ltru] i-default (was: zxx) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > I'd also consider "i-default" if forced to use a tag for all programming > languages I know. i-default is defined very carefully by RFC 2277, section 4.5; it's not a programming language. Here's the relevant text: 4.5. Default Language When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language. Default Language is assigned the tag "i-default" according to the procedures of RFC 1766. It is not a specific language, but rather identifies the condition where the language preferences of the user cannot be established. Messages in Default Language MUST be understandable by an English- speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers. Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations. In many cases, using only English text is reasonable; in some cases, the English text may be augumented by text in other languages. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 07:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerVV-0001WP-B9; Fri, 20 Apr 2007 07:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerVT-0001WJ-Q7 for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:42:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HerVQ-0007jT-C3 for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:42:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HerVG-000446-LY for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:42:14 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:42:14 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:42:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 13:41:09 +0200 Organization: Lines: 36 Message-ID: <4628A6D5.64D5@xyzzy.claranet.de> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: = > http://docs.google.com/Doc?id=3Ddfqr8rd5_11g425c9 = > everyone should be able to get to that document > -- let me know if you have trouble. It works with "mozilla 3" Netscape 3 and Lynx 2.8.5. ACK for 1, 2, 3, 5, 6, 8, 10, (11), 12, 13, 14 = NAK for 4, "What?" isn't "mis". = INCONCLUSIVE for 7, "und" and "und-Latn" are fine, but "mis-Latn" is utter dubious at best. NAK for 9, "und" is possible, but "zxx" ia also possible, while "mis" is clearly mis-leading. ACK for 11, in the sense of stability it would be odd to force worldwide re-tagging of "ger" as "gsw" after its introduction for Schwyzerd=FCtsch. INCONCLUSIVE for 15, is a tag "en-Zxxx" allowed ? Clearly "en" is no "unwritten language", only the content is unwritten in this video/audio example. Maybe add "i-default" to the discussion of case 9, or add a new case where "i-default" is appropriate. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 07:56: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 1HerjE-0006EC-3s; Fri, 20 Apr 2007 07:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerjC-0006Ae-U7 for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:56:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HerjB-0003H0-KX for ltru@lists.ietf.org; Fri, 20 Apr 2007 07:56:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Herj9-00063j-Hl for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:56:35 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:56:35 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 13:56:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 13:56:01 +0200 Organization: Lines: 17 Message-ID: <4628AA51.5049@xyzzy.claranet.de> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <30b660a20704182159x640aa0a6p81ae5b141947ea83@mail.gmail.com> <20070419055331.GF1262@mercury.ccil.org> <4627147C.6030104@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > we are free to tag most recognizably German documents with "de" and > have done. We provide several means of applying more specificity > (especially with the advent of ISO 639-3). But we still can usually > get by with the vagueness of "de" quite frequently (substitute your > favorite language here). -1 For the purpose of matching it's quite important not to confuse "de" with "ger" while talking about something that should be actually "gsw", "nds", or "nl". Likewise it's harmful to confuse "mis" with "*" or "und". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 08:11: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 1HerxH-00068O-LP; Fri, 20 Apr 2007 08:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerxG-00068J-Mu for ltru@lists.ietf.org; Fri, 20 Apr 2007 08:11:10 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Herx0-0008Pp-Cq for ltru@lists.ietf.org; Fri, 20 Apr 2007 08:11:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Herwz-0008Qb-Jp for ltru@lists.ietf.org; Fri, 20 Apr 2007 14:10:53 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 14:10:53 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 14:10:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 14:10:06 +0200 Organization: Lines: 17 Message-ID: <4628AD9E.3CFD@xyzzy.claranet.de> References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > I understand that there are worlds other than XHTML and HTML, but > I can't come up with a use case (for identifying programming code > with zxx) outside of those instances. You could add code as inline text/plain part of a MIME message, and an IMO "mis"-guided implementation could decide that it "must" use some odd heuristics to determine a Content-Language header field (instead of simply not using this header field). There are other uses of language tags with MIME, see also RFC 2231. I don't think that "MIME or XML or HTML" is a complete enumeration of all use cases for language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 11:08: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 1HeuiX-0005XX-5Z; Fri, 20 Apr 2007 11:08:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuiW-0005VZ-CP for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:08:08 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuiT-0004Ge-06 for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:08:08 -0400 Received: by nz-out-0506.google.com with SMTP id o37so895151nzf for ; Fri, 20 Apr 2007 08:08: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=o926CUUZ7xyR2JccHTShMYi4kehZMrnMb59w3WqXMDBXmTR6P9sLONA33Ule1yWEbHzMOw8woK/a4oR+ESerQEAhbldXFbZpOLAOfsmA5PUrU1yMB2x1LM2rtFxM6lp0txwWt1/1zM73HENT7M93Bl7BX4kZQ43/vpDQ6vOC++4= 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=i56dZec9EBZpxkIieQ8/6kEjleDT8aOxf3ykbaXNP7kjz1BsacmDqQApiz6hQGhNWG3u4KhMFXAmPmd+Jn6vJZ33ZDOKKLS4wgeYzqeAtdGn0QdRyOXatHuf1YUfRcRyH9nWy78diWWhb0+T4mrS3RLzZ4WLgX2DOTESN1fvb3Q= Received: by 10.115.77.1 with SMTP id e1mr490124wal.1177081684162; Fri, 20 Apr 2007 08:08:04 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 08:08:02 -0700 (PDT) Message-ID: <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> Date: Fri, 20 Apr 2007 08:08:02 -0700 From: "Mark Davis" To: "Frank Ellermann" In-Reply-To: <46289CB6.3C97@xyzzy.claranet.de> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> X-Google-Sender-Auth: 321045c7066ae422 X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ietf-languages@alvestrand.no, ltru@lists.ietf.org Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0991169209==" Errors-To: ltru-bounces@ietf.org --===============0991169209== Content-Type: multipart/alternative; boundary="----=_Part_146187_26169630.1177081682928" ------=_Part_146187_26169630.1177081682928 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree, although I consider it bizarre rather than barbaric ;-) As in example #9 of http://docs.google.com/Doc?id=dfqr8rd5_11g425c9, to think that the following contains "no linguistic content" is bizarre. It obviously contains linguistic content. if (linguisticContent == null) { throw new Exception(""); } Mark On 4/20/07, Frank Ellermann wrote: > > Peter Constable wrote: > > >> However, your using "pet scenario" to characterize something that I > >> and many others consider "important scenario", like language detection, > >> is unnecessary. > > > I was not referring to tasks like language detection. I was referring > > to cases like "content is programming code which I perceive to be in > > some way linguistic". Such individual perceptions are entirely valid > > as just that "individual perceptions" but have no direct connection > > to the concepts coded in ISO 639 and should not be confused with them. > > [Quote marks edited by me, keeping LTRU on the CC list, but actually I > think this can be solved on the subtag review list under BCP 47 rules.] > > I said "zxx for code is barbaric" based on its description "no linguistic > content". While I agree that this is an "individual perception" and not > covered by BCP 47 I also propose that we need a short comment in the > "zxx" record stating that this tag can be used for code. The description > "no linguistic content" is misleading in the case of code. > > Frank > > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > -- Mark ------=_Part_146187_26169630.1177081682928 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree, although I consider it bizarre rather than barbaric ;-)

As in example #9 of http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 , to think that the following contains "no linguistic content" is bizarre. It obviously contains linguistic content.

if (linguisticContent == null) { throw new Exception(""); }

Mark

On 4/20/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Peter Constable wrote:

>> However, your using "pet scenario" to characterize something that I
>> and many others consider "important scenario", like language detection,
>> is unnecessary.

> I was not referring to tasks like language detection. I was referring
> to cases like "content is programming code which I perceive to be in
> some way linguistic". Such individual perceptions are entirely valid
> as just that "individual perceptions" but have no direct connection
> to the concepts coded in ISO 639 and should not be confused with them.

[Quote marks edited by me, keeping LTRU on the CC list, but actually I
think this can be solved on the subtag review list under BCP 47 rules.]

I said "zxx for code is barbaric" based on its description "no linguistic
content".  While I agree that this is an "individual perception" and not
covered by BCP 47 I also propose that we need a short comment in the
"zxx" record stating that this tag can be used for code.  The description
"no linguistic content" is misleading in the case of code.

Frank


_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages



--
Mark ------=_Part_146187_26169630.1177081682928-- --===============0991169209== 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 --===============0991169209==-- From ltru-bounces@ietf.org Fri Apr 20 11:24: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 1HeuyU-0007hl-0w; Fri, 20 Apr 2007 11:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuyS-0007hd-Fu for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:24:36 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuyQ-0007Zk-1c for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:24:36 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 20 Apr 2007 08:24:33 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Fri, 20 Apr 2007 08:24:33 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 20 Apr 2007 08:24:31 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceDXbXXB+/qz/4kQhGGbIg+Fwcv2gAAdskg Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> In-Reply-To: <30b660a20704200808v67cac397te33954143817955e@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: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0271109810==" Errors-To: ltru-bounces@ietf.org --===============0271109810== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F97217NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F97217NAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KDQo+ IEFzIGluIGV4YW1wbGUgIzkgb2YgaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhy ZDVfMTFnNDI1YzkgLA0KPiB0byB0aGluayB0aGF0IHRoZSBmb2xsb3dpbmcgY29udGFpbnMgIm5v IGxpbmd1aXN0aWMgY29udGVudCIgaXMgYml6YXJyZS4NCj4gSXQgb2J2aW91c2x5IGNvbnRhaW5z IGxpbmd1aXN0aWMgY29udGVudC4NCmlmIChsaW5ndWlzdGljQ29udGVudCA9PSBudWxsKSB7IHRo cm93IG5ldyBFeGNlcHRpb24oIiIpOyB9DQoNCg0KDQpZb3UgY291bGQgc2F5IHRoZSBzYW1lIG9m IHRoaXM6DQpNWsKQDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgw7/DvyAgwrggICAgICAgQCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgw6ANCsKtwroNCiDCtCAgICAgICAgICAgIMONIcK4TMON IVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0KJCAgICAgICBUYsOv4oC6 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHDiA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCsKBw4gNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQrCgcOIN8OFw6/DiBENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrCgcOIN8OF w7zDiBINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrCgcOIN8OFw7rDiA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsKBw4gNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQrigqzDiMOJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K woHDiDfDhcOsw4gzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHDiDfDhcO9 w4gRDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHDiDfDhcO5w4gRDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHDiFJpY2gNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQrCgcOIDQoNCldlIGNvdWxkIHByb2JhYmx5IGNvbWUgdXAgd2l0aCBh bGwga2luZHMgb2YgYm91bmRhcnkgY2FzZXMgZm9yIHdoaWNoIHRoZXJlIGlzIG5vIOKAnHJpZ2h0 4oCdIGFuc3dlci4gSSBkb27igJl0IGtub3cgd2hhdCB1c2UgaXQgd291bGQgYmUuDQpQZXRlcg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F97217NAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBh cmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5nbWFpbHF1b3RlDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsX3F1b3RlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0K LS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBNYXJrIERhdmlzDQpbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXSA8YnI+ DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+ PC9iPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz4mZ3Q7IDwvc3Bhbj48L2I+QXMgaW4gZXhhbXBsZSAjOSBvZiA8YQ0KaHJlZj0iaHR0 cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1YzkiIHRhcmdldD0iX2Js YW5rIg0KaWQ9cHVibGlzaGVkRG9jdW1lbnRVcmw+aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/ aWQ9ZGZxcjhyZDVfMTFnNDI1YzkgPC9hPiwgPHNwYW4NCnN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+Jmd0OyA8L3NwYW4+dG8gdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGNvbnRh aW5zICZxdW90O25vDQpsaW5ndWlzdGljIGNvbnRlbnQmcXVvdDsgaXMgYml6YXJyZS4gPHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5JdCBvYnZpb3Vz bHkgY29udGFpbnMgbGluZ3Vpc3RpYyBjb250ZW50LjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0xIGNlbGxzcGFjaW5nPTAgY2Vs bHBhZGRpbmc9MD4NCiA8dHI+DQogIDx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjEuOTVw dCAxLjk1cHQgMS45NXB0IDEuOTVwdCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbD5pZiAobGluZ3Vp c3RpY0NvbnRlbnQgPT0gbnVsbCkgeyB0aHJvdyBuZXcNCiAgRXhjZXB0aW9uKCZxdW90OyZxdW90 Oyk7IH08bzpwPjwvbzpwPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Zb3UgY291bGQgc2F5IHRoZSBzYW1lIG9m IHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TVo8L3NwYW4+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wpAgDQoNCjxociBhbGlnbj1sZWZ0IHNpemU9MSB3aWR0 aD0iMzMlIj4NCg0KwqDCoCANCg0KPGhyIGFsaWduPWxlZnQgc2l6ZT0xPg0KDQrCoMKgIMO/w7/C oCDCuMKgwqDCoMKgwqDCoCBAwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgw6DCoMKgIDxiciBjbGVhcj1hbGw+DQrCrcK6 PGJyIGNsZWFyPWFsbD4NCsKgwrTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIMONIcK4TMONIVRoaXMg cHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiTCoMKgwqDCoMKgwqAgVGLDr+KAug0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9 IjMzJSI+DQoNCjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+woHDiA0KDQo8aHIgYWxp Z249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCsKBw4gNCg0KPGhyIGFsaWduPWxlZnQgc2l6 ZT0xIHdpZHRoPSIzMyUiPg0KDQrCgcOIN8OFw6/DiBENCg0KPGhyIGFsaWduPWxlZnQgc2l6ZT0x IHdpZHRoPSIzMyUiPg0KDQrCgcOIN8OFw7zDiBINCg0KPGhyIGFsaWduPWxlZnQgc2l6ZT0xIHdp ZHRoPSIzMyUiPg0KDQrCgcOIN8OFw7rDiDxicj4NCg0KPGhyIGFsaWduPWxlZnQgc2l6ZT0xIHdp ZHRoPSIzMyUiPg0KDQrCgcOIDQoNCjxociBhbGlnbj1sZWZ0IHNpemU9MSB3aWR0aD0iMzMlIj4N Cg0K4oKsw4jDiQ0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCsKBw4g3 w4XDrMOIMw0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCsKBw4g3w4XD vcOIEQ0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCsKBw4g3w4XDucOI EQ0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCsKBw4hSaWNoDQoNCjxo ciBhbGlnbj1sZWZ0IHNpemU9MSB3aWR0aD0iMzMlIj4NCg0KwoHDiMKgwqDCoMKgwqDCoCA8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5XZSBjb3VsZCBwcm9iYWJseSBjb21lIHVwDQp3aXRoIGFsbCBraW5kcyBv ZiBib3VuZGFyeSBjYXNlcyBmb3Igd2hpY2ggdGhlcmUgaXMgbm8g4oCccmlnaHTigJ0gYW5zd2Vy LiBJIGRvbuKAmXQNCmtub3cgd2hhdCB1c2UgaXQgd291bGQgYmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F97217NAEXMSGC117re_-- --===============0271109810== 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 --===============0271109810==-- From ltru-bounces@ietf.org Fri Apr 20 11:59: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 1HevW2-0002k1-Uo; Fri, 20 Apr 2007 11:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevW1-0002jw-Iy for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:59:17 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HevW1-0000vt-5f for ltru@lists.ietf.org; Fri, 20 Apr 2007 11:59:17 -0400 Received: by wr-out-0506.google.com with SMTP id 76so968884wra for ; Fri, 20 Apr 2007 08:59:17 -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=nOW17gNd/GborekugYwRUzWZE/HIX6C8FufQ6eS9aBid4J9JmxKqyYv5TMZWcr+yADcS31lDbHQ/1Z/TBLVM4SRBB9ISOCZB+vEJkNkm63InR2BHHBUe9lmuWpyyLqrZ6sHwXlhkx5ZkvX+MbhgwYoIfEOp42yKEJEAAt+GlP+g= 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=S2lz+V0l7KilaAZe/ZTny7jgXt46VREs46NikMHk7WidkGW/bBDb6/dOK2AIpkcz/Z7YRgJKxMU60EPYSzjTkkkNPMmWF+0EsCoe1BQ+mCNCI7DgDq8/8bEkItwgb21qWe81cbP/i/kBPwJiHy4OddzWZlme/tPPRvprd9/WIjc= Received: by 10.115.49.16 with SMTP id b16mr1287485wak.1177084755897; Fri, 20 Apr 2007 08:59:15 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 08:59:15 -0700 (PDT) Message-ID: <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> Date: Fri, 20 Apr 2007 08:59:15 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> X-Google-Sender-Auth: c4a9e2d149b38baf X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591626539==" Errors-To: ltru-bounces@ietf.org --===============0591626539== Content-Type: multipart/alternative; boundary="----=_Part_147578_33267205.1177084755688" ------=_Part_147578_33267205.1177084755688 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24ndCB0aGluayB0aGUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgZnJhZ21lbnQgaXMgcmVhbGx5 IGEgYm91bmRhcnkKY29uZGl0aW9uLiBNb3N0IGNvZGUgc291cmNlIG5vd2FkYXlzIGFyZSBub3Qg anVzdCByYW5kb20gaGV4LCB0aGVyZQp0eXBpY2FsbHksIG5vdCBleGNlcHRpb25hbGx5LCBzb21l IHJlYWwgbGluZ3Vpc3RpYyBjb250ZW50LiBJIHdvdWxkIGFncmVlCndpdGggeW91IHRoYXQgYSBo ZXggZHVtcCBvZiBhIGNvbXBpbGVkIHByb2dyYW0sIHN1Y2ggYXMgcGVyaGFwcyB5b3UgdXNlZCBm b3IKeW91ciBleGFtcGxlLCBpcyBzZW5zaWJsZSB0byB0YWcgYXMgenh4LCBidXQgYmFzZWQgb24g dGhlIHdvcmRpbmcgb2YgdGhlCnN0YW5kYXJkcywgSSBkb24ndCB0aGluayB3ZSBjYW4gZXhwZWN0 IHp4eCB0byBhcHBseSB0byB0eXBpY2FsIGNvZGUgc291cmNlLgpZZXQsIHdoaWxlIHRoZXJlIG1h eSBiZSBpcyBzb21lIGVtYmVkZGVkIEVuZ2xpc2gsIHdlIGRvbid0IHdhbnQgdG8gY2FsbCBpdAoi ZW4iIGVpdGhlci4KCkl0IGxvb2tzIHRvIG1lIGxpa2UgdGhlIGJlc3QgY2hvaWNlIGN1cnJlbnRs eSB3b3VsZCBiZSAidW5kIjsgYXMgSSBzYWlkLCBJCnRoaW5rIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0 byBoYXZlIGEgc3BlY2lhbCB0YWcgZm9yIHRoaXMganVzdCBiZWNhdXNlIGl0IGlzIGEKcmVhc29u YWJseSBjb21tb24gY2FzZSB0aGF0IGlzIG90aGVyd2lzZSBkaWZmaWN1bHQgdG8gY2F0ZWdvcml6 ZS4gQW4KYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gZXhwbGljaXRseSBicm9hZGVuIHRoZSBkZXNj cmlwdGlvbiBvZiAienh4IiB0byBiZQoibm8gbGluZ3Vpc3RpYyBjb250ZW50LCBvciBwcm9ncmFt bWluZyBzb3VyY2UgY29kZSIuIFRoYXQgd291bGQgYmUgYQpjb21wYXRpYmxlIGNoYW5nZSB0byA0 NjQ2YmlzLCBzaW5jZSBpdCBpcyBhIGJyb2FkZW5pbmcuCgpNYXJrCgpPbiA0LzIwLzA3LCBQZXRl ciBDb25zdGFibGUgPHBldGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gICAqRnJvbToq IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10KPgo+ICoqCj4K PiAqPiAqQXMgaW4gZXhhbXBsZSAjOSBvZiBodHRwOi8vZG9jcy5nb29nbGUuY29tL0RvYz9pZD1k ZnFyOHJkNV8xMWc0MjVjOSAsCj4KPiA+IHRvIHRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyBjb250 YWlucyAibm8gbGluZ3Vpc3RpYyBjb250ZW50IiBpcyBiaXphcnJlLgo+Cj4KPiA+IEl0IG9idmlv dXNseSBjb250YWlucyBsaW5ndWlzdGljIGNvbnRlbnQuCj4KPiBpZiAobGluZ3Vpc3RpY0NvbnRl bnQgPT0gbnVsbCkgeyB0aHJvdyBuZXcgRXhjZXB0aW9uKCIiKTsgfQo+Cj4KPgo+ICBZb3UgY291 bGQgc2F5IHRoZSBzYW1lIG9mIHRoaXM6Cj4KPiBNWsKQCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAgICDDv8O/ICDC uCAgICAgICBAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDDoAo+IMKtwroKPiAg wrQgICAgICAgICAgICDDjSHCuEzDjSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1Mg bW9kZS4KPgo+ICQgICAgICAgVGLDr+KAugo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+IMKBw4gKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiDCgcOICj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gwoHDiDfDhcOvw4gRCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4gwoHDiDfDhcO8w4gSCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4gwoHDiDfDhcO6w4gKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiDC gcOICj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g4oKsw4jDiQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IMKBw4g3w4XDrMOIMwo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+IMKBw4g3w4XDvcOIEQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+IMKBw4g3w4XDucOIEQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IMKB w4hSaWNoCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gwoHDiAo+Cj4KPgo+IFdl IGNvdWxkIHByb2JhYmx5IGNvbWUgdXAgd2l0aCBhbGwga2luZHMgb2YgYm91bmRhcnkgY2FzZXMg Zm9yIHdoaWNoIHRoZXJlCj4gaXMgbm8gInJpZ2h0IiBhbnN3ZXIuIEkgZG9uJ3Qga25vdyB3aGF0 IHVzZSBpdCB3b3VsZCBiZS4KPgo+IFBldGVyCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9y Zwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+CgoKLS0g Ck1hcmsK ------=_Part_147578_33267205.1177084755688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24mIzM5O3QgdGhpbmsgdGhlIHByb2dyYW1taW5nIGxhbmd1YWdlIGZyYWdtZW50IGlzIHJl YWxseSBhIGJvdW5kYXJ5IGNvbmRpdGlvbi4gTW9zdCBjb2RlIHNvdXJjZSBub3dhZGF5cyBhcmUg bm90IGp1c3QgcmFuZG9tIGhleCwgdGhlcmUgdHlwaWNhbGx5LCBub3QgZXhjZXB0aW9uYWxseSwg c29tZSByZWFsIGxpbmd1aXN0aWMgY29udGVudC4gSSB3b3VsZCBhZ3JlZSB3aXRoIHlvdSB0aGF0 IGEgaGV4IGR1bXAgb2YgYSAKPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPmNvbXBp bGVkPC9zcGFuPiBwcm9ncmFtLCBzdWNoIGFzIHBlcmhhcHMgeW91IHVzZWQgZm9yIHlvdXIgZXhh bXBsZSwgaXMgc2Vuc2libGUgdG8gdGFnIGFzIHp4eCwgYnV0IGJhc2VkIG9uIHRoZSB3b3JkaW5n IG9mIHRoZSBzdGFuZGFyZHMsIEkgZG9uJiMzOTt0IHRoaW5rIHdlIGNhbiBleHBlY3Qgenh4IHRv IGFwcGx5IHRvIHR5cGljYWwgY29kZSBzb3VyY2UuIFlldCwgd2hpbGUgdGhlcmUgbWF5IGJlIGlz IHNvbWUgZW1iZWRkZWQgRW5nbGlzaCwgd2UgZG9uJiMzOTt0IHdhbnQgdG8gY2FsbCBpdCAmcXVv dDtlbiZxdW90OyBlaXRoZXIuCjxicj48YnI+SXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgYmVzdCBj aG9pY2UgPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPmN1cnJlbnRseSA8L3NwYW4+ d291bGQgYmUgJnF1b3Q7dW5kJnF1b3Q7OyBhcyBJIHNhaWQsIEkgdGhpbmsgaXQgbWlnaHQgYmUg dXNlZnVsIHRvIGhhdmUgYSBzcGVjaWFsIHRhZyBmb3IgdGhpcyBqdXN0IGJlY2F1c2UgaXQgaXMg YSByZWFzb25hYmx5IGNvbW1vbiBjYXNlIHRoYXQgaXMgb3RoZXJ3aXNlIGRpZmZpY3VsdCB0byBj YXRlZ29yaXplLiBBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byAKPHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IGl0YWxpYzsiPmV4cGxpY2l0bHkgPC9zcGFuPmJyb2FkZW4gdGhlIGRlc2NyaXB0aW9u IG9mICZxdW90O3p4eCZxdW90OyB0byBiZSAmcXVvdDtubyBsaW5ndWlzdGljIGNvbnRlbnQsIG9y IHByb2dyYW1taW5nIHNvdXJjZSBjb2RlJnF1b3Q7LiBUaGF0IHdvdWxkIGJlIGEgY29tcGF0aWJs ZSBjaGFuZ2UgdG8gNDY0NmJpcywgc2luY2UgaXQgaXMgYSBicm9hZGVuaW5nLgo8YnI+PGJyPk1h cms8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA0LzIwLzA3LCA8YiBj bGFzcz0iZ21haWxfc2VuZGVybmFtZSI+UGV0ZXIgQ29uc3RhYmxlPC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iPnBldGVyY29uQG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i Ym9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4KCjxkaXY+Cgo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIy MykgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yOyBib3JkZXItd2lkdGg6 IDFwdCBtZWRpdW0gbWVkaXVtOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPgoKPHA+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyI+IE1hcmsgRGF2aXMKW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFyay5k YXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5kYXZpc0BpY3UtcHJvamVj dC5vcmc8L2E+XSA8YnI+Cjxicj4KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+PC9zcGFuPjwvYj48L3NwYW4+PC9wPjxzcGFuIGNsYXNzPSJxIj4KCjxwPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8 L3NwYW4+PC9iPkFzIGluIGV4YW1wbGUgIzkgb2YgPGEgaHJlZj0iaHR0cDovL2RvY3MuZ29vZ2xl LmNvbS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1YzkiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cmh0dHA6Ly9kb2Nz Lmdvb2dsZS5jb20vRG9jP2lkPWRmcXI4cmQ1XzExZzQyNWM5IDwvYT4sIDxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZndDsgPC9zcGFuPnRvIHRo aW5rIHRoYXQgdGhlIGZvbGxvd2luZyBjb250YWlucyAmcXVvdDtubwpsaW5ndWlzdGljIGNvbnRl bnQmcXVvdDsgaXMgYml6YXJyZS4gPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8L3NwYW4+SXQgb2J2aW91c2x5IGNvbnRhaW5zIGxpbmd1 aXN0aWMgY29udGVudC48L3A+Cgo8L3NwYW4+PC9kaXY+PHNwYW4gY2xhc3M9InEiPgoKPHRhYmxl IGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4KIDx0Ym9keT48dHI+ CiAgPHRkIHN0eWxlPSJwYWRkaW5nOiAxLjk1cHQ7IiB2YWxpZ249InRvcCI+CiAgPHA+aWYgKGxp bmd1aXN0aWNDb250ZW50ID09IG51bGwpIHsgdGhyb3cgbmV3CiAgRXhjZXB0aW9uKCZxdW90OyZx dW90Oyk7IH08L3A+CiAgPC90ZD4KIDwvdHI+CjwvdGJvZHk+PC90YWJsZT4KCjxwIHN0eWxlPSJt YXJnaW4tYm90dG9tOiAxMnB0OyI+PGJyPgo8YnI+CjwvcD48L3NwYW4+Cgo8cCBzdHlsZT0ibWFy Z2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+WW91IGNvdWxkIHNheSB0aGUgc2FtZSBvZiB0aGlzOjwvc3Bhbj48 L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+TVo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij7CkCAKCjxociBhbGln bj0ibGVmdCIgc2l6ZT0iMSIgd2lkdGg9IjMzJSI+CgombmJzcDsmbmJzcDsgCgo8aHIgYWxpZ249 ImxlZnQiIHNpemU9IjEiPgoKJm5ic3A7Jm5ic3A7IMO/w78mbmJzcDsgwrgmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDDoCZuYnNwOyZuYnNwOyA8YnIgY2xlYXI9ImFsbCI+CsKtwro8YnIgY2xlYXI9ImFsbCI+CiZu YnNwO8K0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IMONIcK4TMONIVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERP UyBtb2RlLjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PC9zcGFu PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4kJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRiw6/igLoKCjxociBhbGlnbj0ibGVmdCIgc2l6ZT0iMSIgd2lk dGg9IjMzJSI+Cgo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij7CgcOICgo8aHIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdpZHRoPSIz MyUiPgoKwoHDiAoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCsKBw4g3 w4XDr8OIEQoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCsKBw4g3w4XD vMOIEgoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCsKBw4g3w4XDusOI PGJyPgoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCsKBw4gKCjxociBh bGlnbj0ibGVmdCIgc2l6ZT0iMSIgd2lkdGg9IjMzJSI+CgrigqzDiMOJCgo8aHIgYWxpZ249Imxl ZnQiIHNpemU9IjEiIHdpZHRoPSIzMyUiPgoKwoHDiDfDhcOsw4gzCgo8aHIgYWxpZ249ImxlZnQi IHNpemU9IjEiIHdpZHRoPSIzMyUiPgoKwoHDiDfDhcO9w4gRCgo8aHIgYWxpZ249ImxlZnQiIHNp emU9IjEiIHdpZHRoPSIzMyUiPgoKwoHDiDfDhcO5w4gRCgo8aHIgYWxpZ249ImxlZnQiIHNpemU9 IjEiIHdpZHRoPSIzMyUiPgoKwoHDiFJpY2gKCjxociBhbGlnbj0ibGVmdCIgc2l6ZT0iMSIgd2lk dGg9IjMzJSI+CgrCgcOIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFy Z2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90 dG9tOiAxMnB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5XZSBjb3VsZCBwcm9iYWJseSBjb21lIHVwCndpdGggYWxsIGtpbmRzIG9mIGJv dW5kYXJ5IGNhc2VzIGZvciB3aGljaCB0aGVyZSBpcyBubyAicmlnaHQiIGFuc3dlci4gSSBkb24n dAprbm93IHdoYXQgdXNlIGl0IHdvdWxkIGJlLjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2lu LWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+UGV0ZXI8L3NwYW4+PC9wPgoKPC9kaXY+Cgo8L2Rpdj4KCgo8YnI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWls aW5nIGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9h Pjxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSIgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSIg dGFyZ2V0PSJfYmxhbmsiPgpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1PC9hPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJy Pi0tIDxicj5NYXJrCg== ------=_Part_147578_33267205.1177084755688-- --===============0591626539== 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 --===============0591626539==-- From ltru-bounces@ietf.org Fri Apr 20 12:15: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 1Hevll-0004UJ-KU; Fri, 20 Apr 2007 12:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevlk-0004UC-DG for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:15:32 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevli-0008TH-01 for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:15:32 -0400 Received: from [10.76.37.218] (wifi-postauth218.london.corp.yahoo.com [10.76.37.218]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3KGF6wK034571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 09:15:10 -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=fQ+Xm7f8fmULpRotXYmT59d5SKaFWTT2N9zt4BokSBmZVpUxXD5n5f8VfXIcAt3x Message-ID: <4628E709.4030300@yahoo-inc.com> Date: Fri, 20 Apr 2007 17:15:05 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request References: <20070413122917.GA25431@nic.fr> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> In-Reply-To: <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Most code source nowadays are not just random hex, there > typically, not exceptionally, some real linguistic content. I would > agree with you that a hex dump of a compiled program, such as perhaps > you used for your example, is sensible to tag as zxx, but based on the > wording of the standards, I don't think we can expect zxx to apply to > typical code source. Yet, while there may be is some embedded English, > we don't want to call it "en" either. I don't understand. Why is this really a problem? BCP 47 has always said, quite clearly, that programming languages are not what we mean by "languages". The following fragment is utterly perverse (but not illegal): --- Content-Type: application/javascript Content-Language: zxx, en function init() { var stdmenu = new widget.Menu('stditems', { position:'static' }); var menuitems = stdmenu.getItemGroups(); for (var x=0; x Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevo3-0005Ab-P8; Fri, 20 Apr 2007 12:17:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevo2-0005AV-9y for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:17:54 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevo0-0000Za-VD for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:17:54 -0400 Received: from [10.76.37.218] (wifi-postauth218.london.corp.yahoo.com [10.76.37.218]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3KGHc9j034806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 09:17: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=G58dtFh0L7fE47vpo9yIO6oaK/W7D72D8me9NLGAhHfSPCAg3YbKW+97Vuocq0AV Message-ID: <4628E7A2.3030509@yahoo-inc.com> Date: Fri, 20 Apr 2007 17:17:38 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Language Tag Special Cases References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> In-Reply-To: <4628AD9E.3CFD@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So if I understand the proposal, it is to deal with the different "special case" codes assigned by ISO 639. To paraphrase what 4646 contains (plus my interpretation of the additions): "mul" is used to identify content in multiple languages. It SHOULD NOT be used when a list of languages (such as Content-Language) can be used instead and it SHOULD NOT be used for individual content items (such as a single

element in an XHTML document). "und" is used to identify linguistic content whose language cannot be determined. It SHOULD NOT be used unless a language tag is required and the language cannot be determined. "zxx" is used to identify non-lingusitic content. It SHOULD NOT be used unless a language tag is required by some application or protocol for some non-human language content item. "mis" is used to identify linguistic content whose language is known but cannot otherwise be identified. It is commonly used when the range of language tags is constrained (for example, to ISO 639-2, as in MARC, for example) or for languages not otherwise categorized. It SHOULD NOT be used unless a language tag is required and no other means of identifying the language is available. In all cases, where permitted, omitting the language tag is preferable to using these codes. Language tags SHOULD NOT incorporate these subtags as a prefix under any circumstances. This covers all of the cases except that where the language is known and can be identified using a regular subtag. Any other cases? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 12:23: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 1Hevtu-0001Rs-7o; Fri, 20 Apr 2007 12:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevts-0001Q3-NZ for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:23:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevts-0001mZ-Au for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:23:56 -0400 Received: by nz-out-0506.google.com with SMTP id o37so920718nzf for ; Fri, 20 Apr 2007 09:23:55 -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=luo1SmxawfUBlDRoYTqzQ08YAHg89hrZZ8AvMY9Yce015g1AzF4VNzhLs09I6qRykMz8JgLIXx9cuU7iT0Si67332I5/VAy6Jna2wKGN9GoH7DAJLEb9HN+nQxCPui58GLnR6swgu20COwI3jJy2YQ4v6jAw/Xa1Bis2Rbdpx0E= 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=ixc3oVMzyyFvdtwbtXgxs2fgBLwlNHM8oOAfvyLXoBHsji+A/cbieOCzSLSP0cz6QlgFcbtOIGDdkYZ9Rb59RkYTeAHD7VufrI/67ysbSM08+rOJvvxqDH/w+b5QQy6B0pDOSPBsUdxgAvrlK/q+MkIejKatAGeHX/9JdgObhj8= Received: by 10.114.179.1 with SMTP id b1mr1313062waf.1177086235155; Fri, 20 Apr 2007 09:23:55 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 09:23:55 -0700 (PDT) Message-ID: <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> Date: Fri, 20 Apr 2007 09:23:55 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Language Tag Special Cases In-Reply-To: <4628A6D5.64D5@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> X-Google-Sender-Auth: a56a333f38df3756 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896835255==" Errors-To: ltru-bounces@ietf.org --===============0896835255== Content-Type: multipart/alternative; boundary="----=_Part_148118_5375377.1177086235078" ------=_Part_148118_5375377.1177086235078 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Y29tbWVudHMgYmVsb3cuIEJUVywgbm90IGV2ZXJ5b25lIHdpbGwgYmUgZmFtaWxpYXIgd2l0aCBB Q0sgYW5kIE5BSy4KCk9uIDQvMjAvMDcsIEZyYW5rIEVsbGVybWFubiA8bm9ib2R5QHh5enp5LmNs YXJhbmV0LmRlPiB3cm90ZToKPgo+IE1hcmsgRGF2aXMgd3JvdGU6Cj4KPiA+IGh0dHA6Ly9kb2Nz Lmdvb2dsZS5jb20vRG9jP2lkPWRmcXI4cmQ1XzExZzQyNWM5Cj4KPiA+IGV2ZXJ5b25lIHNob3Vs ZCBiZSBhYmxlIHRvIGdldCB0byB0aGF0IGRvY3VtZW50Cj4gPiAtLSBsZXQgbWUga25vdyBpZiB5 b3UgaGF2ZSB0cm91YmxlLgo+Cj4gSXQgd29ya3Mgd2l0aCAibW96aWxsYSAzIiBOZXRzY2FwZSAz IGFuZCBMeW54IDIuOC41Lgo+Cj4gQUNLIGZvciAxLCAyLCAzLCA1LCA2LCA4LCAxMCwgKDExKSwg MTIsIDEzLCAxNAo+Cj4gTkFLIGZvciA0LCAiV2hhdD8iIGlzbid0ICJtaXMiLgoKCkFzIEkgc2Fp ZCBpbiBlbWFpbCwgSSBzZWUgbm90aGluZyBpbiB0aGUgc3RhbmRhcmQgdGhhdCBpbmRpY2F0ZXMg dGhhdCAibWlzIgppcyBub3QgdmFsaWQgZm9yIEVuZ2xpc2gsIGJ1dCB2YWxpZCBmb3IsIHNheSwg QWludSBvciBhbnl0aGluZyBlbHNlLiAoSQphZGRlZCBhIG5vdGUgdG8gdGhlIGV4YW1wbGVzKSBJ ZiB5b3UgY2FuIGRlbW9uc3RyYXRlIHRoYXQsIGJ5IHF1b3RpbmcgZnJvbQp0aGUgSVNPIDYzOSBz dGFuZGFyZCBvciBkYXRhLCBJJ2QgYXBwcmVjaWF0ZSBpdC4KCklOQ09OQ0xVU0lWRSBmb3IgNywg InVuZCIgYW5kICJ1bmQtTGF0biIgYXJlIGZpbmUsCj4gYnV0ICJtaXMtTGF0biIgaXMgdXR0ZXIg ZHViaW91cyBhdCBiZXN0Lgo+Cj4gTkFLIGZvciA5LCAidW5kIiBpcyBwb3NzaWJsZSwgYnV0ICJ6 eHgiIGlhIGFsc28KPiBwb3NzaWJsZSwgd2hpbGUgIm1pcyIgaXMgY2xlYXJseSBtaXMtbGVhZGlu Zy4KPgo+IEFDSyBmb3IgMTEsIGluIHRoZSBzZW5zZSBvZiBzdGFiaWxpdHkgaXQgd291bGQgYmUK PiBvZGQgdG8gZm9yY2Ugd29ybGR3aWRlIHJlLXRhZ2dpbmcgb2YgImdlciIgYXMgImdzdyIKPiBh ZnRlciBpdHMgaW50cm9kdWN0aW9uIGZvciBTY2h3eXplcmTDvHRzY2guCgoKQWdyZWVkLgoKSU5D T05DTFVTSVZFIGZvciAxNSwgaXMgYSB0YWcgImVuLVp4eHgiIGFsbG93ZWQgPwo+IENsZWFybHkg ImVuIiBpcyBubyAidW53cml0dGVuIGxhbmd1YWdlIiwgb25seSB0aGUKPiBjb250ZW50IGlzIHVu d3JpdHRlbiBpbiB0aGlzIHZpZGVvL2F1ZGlvIGV4YW1wbGUuCgoKSXQgY2VydGFpbmx5IG1ha2Vz IHNlbnNlIHRvIHNheSB0aGF0IGEgdmlkZW8gb2YgQnVncyBCdW5ueSBoYXMgbm8gd3JpdHRlbgps YW5ndWFnZSBjb250ZW50LCBhbmQgdGhhdCdzIGhvdyB3ZSBpbnRlcnByZXQgWnh4eC4KKFp4eHgg aGFzIG5vIHVzZSBvdGhlcndpc2UuIEl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBz Y3JpcHQgdGFnCnRoYXQgY291bGQgb25seSBiZSBhcHBsaWVkIHRvIGNvbnRlbnQgaW4gbGFuZ3Vh Z2VzIHdoaWNoIGFyZSBjdXJyZW50bHkKdW53cml0dGVuLCBzaW5jZSB5b3Uga25vdyB0aGF0IGZy b20gdGhlIGxhbmd1YWdlIGFueXdheSwgYW5kIHN1Y2ggYW4KaW50ZXJwcmV0YXRpb24gd291bGQg bWFrZSBCQ1AgNDcgYnkgZGVmaW5pdGlvbiB1bnN0YWJsZSAtLSBpdCBpcyBhbHdheXMKcG9zc2li bGUgdG8gZGV2ZWxvcCB3cml0dGVuIGZvcm0gb2YgdGhhdCBsYW5ndWFnZSB3aGljaCB3b3VsZCBp bnZhbGlkYXRlIHRoZQp0YWcuKQpBZGRlZCBub3RlIHRvIGRvY3VtZW50LgoKTWF5YmUgYWRkICJp LWRlZmF1bHQiIHRvIHRoZSBkaXNjdXNzaW9uIG9mIGNhc2UgOSwKPiBvciBhZGQgYSBuZXcgY2Fz ZSB3aGVyZSAiaS1kZWZhdWx0IiBpcyBhcHByb3ByaWF0ZS4KCgpJIGFkZGVkICJpLWRlZmF1bHQi IGF0IHRoZSB0b3AsIHNpbmNlIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBpdCBpcwplc3NlbnRpYWxs eSBlcXVpdmFsZW50IHRvICJ1bmQiIG9yIG1heWJlICJtaXMiLiBJIHRoaW5rIHdlIHNob3VsZCBk aXNjb3VyYWdlCml0LCBteXNlbGYsIHNpbmNlIGl0IGlzIGdyYW5kZmF0aGVyZWQgYW5kIGNhbm5v dCBiZSBjb21iaW5lZC4KCkZyYW5rCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0cnVAaWV0Zi5vcmcK PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4KCgoKLS0gCk1h cmsK ------=_Part_148118_5375377.1177086235078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Y29tbWVudHMgYmVsb3cuIEJUVywgbm90IGV2ZXJ5b25lIHdpbGwgYmUgZmFtaWxpYXIgd2l0aCBB Q0sgYW5kIE5BSy48YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA0LzIw LzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+RnJhbmsgRWxsZXJtYW5uPC9iPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZSI+bm9ib2R5QHh5enp5LmNs YXJhbmV0LmRlCjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsg bWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5NYXJrIERhdmlz IHdyb3RlOjxicj48YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vZG9jcy5nb29nbGUuY29tL0RvYz9p ZD1kZnFyOHJkNV8xMWc0MjVjOSI+Cmh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vRG9jP2lkPWRmcXI4 cmQ1XzExZzQyNWM5PC9hPjxicj48YnI+Jmd0OyBldmVyeW9uZSBzaG91bGQgYmUgYWJsZSB0byBn ZXQgdG8gdGhhdCBkb2N1bWVudDxicj4mZ3Q7IC0tIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIHRy b3VibGUuPGJyPjxicj5JdCB3b3JrcyB3aXRoICZxdW90O21vemlsbGEgMyZxdW90OyBOZXRzY2Fw ZSAzIGFuZCBMeW54IDIuOC41Ci48YnI+PGJyPkFDSyBmb3IgMSwgMiwgMywgNSwgNiwgOCwgMTAs ICgxMSksIDEyLCAxMywgMTQ8YnI+PGJyPk5BSyBmb3IgNCwgJnF1b3Q7V2hhdD8mcXVvdDsgaXNu JiMzOTt0ICZxdW90O21pcyZxdW90Oy48L2Jsb2NrcXVvdGU+PGRpdj48YnI+QXMgSSBzYWlkIGlu IGVtYWlsLCBJIHNlZSBub3RoaW5nIGluIHRoZSBzdGFuZGFyZCB0aGF0IGluZGljYXRlcyB0aGF0 ICZxdW90O21pcyZxdW90OyBpcyBub3QgdmFsaWQgZm9yIEVuZ2xpc2gsIGJ1dCB2YWxpZCBmb3Is IHNheSwgQWludSBvciBhbnl0aGluZyBlbHNlLiAoSSBhZGRlZCBhIG5vdGUgdG8gdGhlIGV4YW1w bGVzKSBJZiB5b3UgY2FuIGRlbW9uc3RyYXRlIHRoYXQsIGJ5IHF1b3RpbmcgZnJvbSB0aGUgSVNP IDYzOSBzdGFuZGFyZCBvciBkYXRhLCBJJiMzOTtkIGFwcHJlY2lhdGUgaXQuCjxicj48L2Rpdj48 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFw eCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBh ZGRpbmctbGVmdDogMWV4OyI+SU5DT05DTFVTSVZFIGZvciA3LCAmcXVvdDt1bmQmcXVvdDsgYW5k ICZxdW90O3VuZC1MYXRuJnF1b3Q7IGFyZSBmaW5lLDxicj5idXQgJnF1b3Q7bWlzLUxhdG4mcXVv dDsgaXMgdXR0ZXIgZHViaW91cyBhdCBiZXN0Lgo8YnI+PGJyPk5BSyBmb3IgOSwgJnF1b3Q7dW5k JnF1b3Q7IGlzIHBvc3NpYmxlLCBidXQgJnF1b3Q7enh4JnF1b3Q7IGlhIGFsc288YnI+cG9zc2li bGUsIHdoaWxlICZxdW90O21pcyZxdW90OyBpcyBjbGVhcmx5IG1pcy1sZWFkaW5nLjxicj48YnI+ QUNLIGZvciAxMSwgaW4gdGhlIHNlbnNlIG9mIHN0YWJpbGl0eSBpdCB3b3VsZCBiZTxicj5vZGQg dG8gZm9yY2Ugd29ybGR3aWRlIHJlLXRhZ2dpbmcgb2YgJnF1b3Q7Z2VyJnF1b3Q7IGFzICZxdW90 O2dzdyZxdW90Owo8YnI+YWZ0ZXIgaXRzIGludHJvZHVjdGlvbiBmb3IgU2Nod3l6ZXJkw7x0c2No LjwvYmxvY2txdW90ZT48ZGl2Pjxicj5BZ3JlZWQuIDxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0 LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyI+SU5DT05DTFVTSVZFIGZvciAxNSwgaXMgYSB0YWcgJnF1b3Q7ZW4tWnh4eCZxdW90OyBhbGxv d2VkID8KPGJyPkNsZWFybHkgJnF1b3Q7ZW4mcXVvdDsgaXMgbm8gJnF1b3Q7dW53cml0dGVuIGxh bmd1YWdlJnF1b3Q7LCBvbmx5IHRoZTxicj5jb250ZW50IGlzIHVud3JpdHRlbiBpbiB0aGlzIHZp ZGVvL2F1ZGlvIGV4YW1wbGUuPC9ibG9ja3F1b3RlPjxkaXY+PGJyPkl0IGNlcnRhaW5seSBtYWtl cyBzZW5zZSB0byBzYXkgdGhhdCBhIHZpZGVvIG9mIEJ1Z3MgQnVubnkgaGFzIG5vIHdyaXR0ZW4g bGFuZ3VhZ2UgY29udGVudCwgYW5kIHRoYXQmIzM5O3MgaG93IHdlIGludGVycHJldCBaeHh4Lgo8 YnI+CihaeHh4IGhhcyBubyB1c2Ugb3RoZXJ3aXNlLiBJdCB3b3VsZCBub3QgbWFrZSBzZW5zZSB0 byBoYXZlIGEgc2NyaXB0CnRhZwp0aGF0IGNvdWxkIG9ubHkgYmUgYXBwbGllZCB0byBjb250ZW50 IGluIGxhbmd1YWdlcyB3aGljaCBhcmUgY3VycmVudGx5CnVud3JpdHRlbiwgc2luY2UgeW91IGtu b3cgdGhhdCBmcm9tIHRoZSBsYW5ndWFnZSBhbnl3YXksIGFuZCBzdWNoIGFuCmludGVycHJldGF0 aW9uIHdvdWxkIG1ha2UgQkNQIDQ3IGJ5IGRlZmluaXRpb24gdW5zdGFibGUgLS0gaXQgaXMgYWx3 YXlzCnBvc3NpYmxlIHRvIGRldmVsb3Agd3JpdHRlbiBmb3JtIG9mIHRoYXQgbGFuZ3VhZ2Ugd2hp Y2ggd291bGQKaW52YWxpZGF0ZSB0aGUgdGFnLik8YnI+QWRkZWQgbm90ZSB0byBkb2N1bWVudC48 YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPk1heWJlIGFkZCAmcXVvdDtpLWRlZmF1bHQmcXVv dDsgdG8gdGhlIGRpc2N1c3Npb24gb2YgY2FzZSA5LAo8YnI+b3IgYWRkIGEgbmV3IGNhc2Ugd2hl cmUgJnF1b3Q7aS1kZWZhdWx0JnF1b3Q7IGlzIGFwcHJvcHJpYXRlLjwvYmxvY2txdW90ZT48ZGl2 Pjxicj5JIGFkZGVkICZxdW90O2ktZGVmYXVsdCZxdW90OyBhdCB0aGUgdG9wLCBzaW5jZSBhcyBm YXIgYXMgSSBjYW4gdGVsbCwgaXQgaXMgZXNzZW50aWFsbHkgZXF1aXZhbGVudCB0byAmcXVvdDt1 bmQmcXVvdDsgb3IgbWF5YmUgJnF1b3Q7bWlzJnF1b3Q7LiBJIHRoaW5rIHdlIHNob3VsZCBkaXNj b3VyYWdlIGl0LCBteXNlbGYsIHNpbmNlIGl0IGlzIGdyYW5kZmF0aGVyZWQgYW5kIGNhbm5vdCBi ZSBjb21iaW5lZC4KPGJyPjwvZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2lu OiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5GcmFuazxicj48YnI+PGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5M dHJ1IG1haWxpbmcgbGlzdAo8YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2x0cnUiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8 L2E+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+ TWFyawo= ------=_Part_148118_5375377.1177086235078-- --===============0896835255== 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 --===============0896835255==-- From ltru-bounces@ietf.org Fri Apr 20 12:40: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 1Hew9T-0001da-Tc; Fri, 20 Apr 2007 12:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hew9T-0001dV-0N for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:40:03 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hew9R-00055n-FK for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:40:02 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:4784 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hew9P-0000zI-6S for ltru@lists.ietf.org; Fri, 20 Apr 2007 18:40:00 +0200 From: "Kent Karlsson" To: References: <20070413122917.GA25431@nic.fr><30b660a20704130927x1e5c4960i4a850f62466d93d7@mail.gmail.com><461FB58B.648F@xyzzy.claranet.de><30b660a20704131006g4d64e469hb15e620324b09064@mail.gmail.com><20070413175040.GM7353@mercury.ccil.org><30b660a20704131149u6ad624feke9d5840ed49d9c4a@mail.gmail.com><005001c77e00$fb1e1160$6601a8c0@oemcomputer><30b660a20704131304j5ccaeceev87b86cfdc84cf459@mail.gmail.com><017b01c77e4f$bdc26ba0$6601a8c0@oemcomputer><30b660a20704161549h254f9bfdo1ce3e87ea3737305@mail.gmail.com><00a201c78124$0713eaa0$7a63f853@streamserve.com><005001c78191$ec1468b0$7a63f853@streamserve.com><007501c78212$a01ac680$7862f853@streamserve.com> Subject: RE: [Ltru] Re: "mis" update review request Date: Fri, 20 Apr 2007 18:42:27 +0200 Message-ID: <005101c7836a$e18d14c0$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceAeXz1W7RUC5RoQe29kmze5DQ/gAACWFwQABdbjyAAHA1PoAAPTTEgAAHhTfAAHWGbIAAK+gLQADvs8SA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hew9P-0000zI-6S. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hew9P-0000zI-6S d7ac90582583021a5649bf71fcbff3c3 X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > From: Kent Karlsson > > Indeed I don't grasp that, especially since your > > interpretation is not supported by the normative text > > of 639-2 as given at http://www.loc.gov/standards/iso639-2/normtext.html. > > All your words and careful attempt to make logical deductions from the > normative text of ISO 639-2 does not change the origin, legacy, intended > meaning and most-representative existing usage of mis. My conlusions are in no way in contrast with that. It is just that "coverage" and "recommended use" aren't the same thing, but has been mixed somewhat in 639-2, especially when it comes to the "other" designations. The "other" refers to the recommended use, not the coverage. > > Only und and mul are listed as "special" > > Because the people that prepared the text for ISO 639-2 did not think > through and analyze the code set in any formally-rigourous way -- > they > weren't paying anywhere as close attention as you just did in your > message to the details of what they were doing. Though I agree that the formulations could be improved, I think you are giving too little credit to the authors of the 639-2 text. (Any one of the authors listening in on this list?) The formulations are quite logical as they are, and I do think that they had a difference between coverage and recommended use in mind, though I agree that wasn't as *clearly* and directly formulated as one might wish. But still I think that is the only logical way of reading the 639-2 text. > > So it does not matter whether the word "languages" or > > the word "other" is used, the semantics is the same at > > the meta-level. "mis", "tai", "gem", and other collective > > codes are on an equal standing. > > In terms of what the authors intended, I believe that's not the case: > IIUC, the "other" collections were assumed to be cases in which there > was at least one individual-language member of the general category that > was coded, while for the "languages" collection it was assumed there > was not. Careful examination reveals that those principles do not hold up, > but that was still the intent and assumption of the authors. Again, _coverage_ and _recommended use_ **do not coinside** for the collection codes, and they cannot coinside for a reasonable reading of 639-2. > (Note that, in ISO 639-3, where I was trying to ensure a good measure > of formal rigour, we did not differentiate two different sub-types > of collection scope.) "two different sub-types of collection scope"?? I'm not sure what you are referring to here. 639-2 and 639-3 seem to be in agreement w.r.t. collection codes ('mis' also) as 639-3 just refers back to 639-2 on collection codes, as well as "special codes" (just that 639-3 mentions the **new** special code "zxx" which the normative text of 639-2 hasn't cought up with yet). [I've been looking at http://www.sil.org/iso639-3/scope.asp, which I think is an excerpt of the 639-3 text.] > > Thus it is fully conformant with 639-2 to use all and any of > > the collective codes ("mis" included) as inclusive... Thus "mis" > > already covers all languages, there is no exclusion in coverage, > > just an "avoid use when possible" > > Again, all your words and logic don't change what original sources, > existing usage, etc. tell us about the semantic of mis, which clearly > is not as you're describing. The source standard from which mis was > taken into ISO 639-2 is quite clear: mis is not used for just any > language, but for a relative handful -- I enumerated them in mail last week. (Not quite sure which enumaration you refer to here.) Again, _coverage_ and _recommended use_ **do not coinside** for the collection codes, and they cannot coinside for a reasonable reading of 639-2. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 12: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 1Hew9c-0001h3-1a; Fri, 20 Apr 2007 12:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hew9a-0001gy-LI for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:40:10 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hew9a-00056Y-5g for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:40:10 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:4799 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hew9Z-00018I-7P for ltru@lists.ietf.org; Fri, 20 Apr 2007 18:40:09 +0200 From: "Kent Karlsson" To: References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Fri, 20 Apr 2007 18:42:37 +0200 Message-ID: <005201c7836a$e7a6d170$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceDQPoSvVmczS5UQCyBWHy7n3YGKQAGBDcg In-Reply-To: <4628A6D5.64D5@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hew9Z-00018I-7P. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hew9Z-00018I-7P af342177e4ceeeb15fc09adf58064497 X-Spam-Score: 0.5 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >=20 > ACK for 1, 2, 3, 5, 6, 8, 10, (11), 12, 13, 14 > =20 > NAK for 4, "What?" isn't "mis". =20 >=20 > INCONCLUSIVE for 7, "und" and "und-Latn" are fine, > but "mis-Latn" is utter dubious at best. >=20 > NAK for 9, "und" is possible, but "zxx" ia also > possible, while "mis" is clearly mis-leading. >=20 > ACK for 11, in the sense of stability it would be > odd to force worldwide re-tagging of "ger" as "gsw" > after its introduction for Schwyzerd=FCtsch. >=20 > INCONCLUSIVE for 15, is a tag "en-Zxxx" allowed ? > Clearly "en" is no "unwritten language", only the > content is unwritten in this video/audio example. My take on Mark's examples list: 1. Ok. 2. Depends, if that is actually some image with text in some language or a sound snippet in some language, then clearly a language tag can be applied. However, in practice I don't expect many images to be language tagged, especially not if the text is incidental. 3. From a "bottom-up language derivation" point of view, ok (maybe a human tagger knows the language, perhaps from context). 4. 'en' is very much recommended over 'mis', though 'en' is covered by 'mis'. One should only use 'mis' if a more specific tag is not available (say for example that one only uses tags for individual languages in the 'tai' family, 'en' would not be available, so use 'mis' for content that is actually 'en'). 5. I would side with Peter on "predominant language" of the text. Minor digressions (short quotes) should not lead to 'mul' tagging; ideally the quote fragment should be tagged as 'de' (if possible), while the full sentence would have a (usually inherited) 'en' tag. (But in practive I would not expect people writing quotes in another language than the main text of the document to actually language tag each little quote.) 6. Ok. 7. The key here is that the "process" (or human) *recognises*=20 the text as being in a language it (she) "knows". If there is no more specific tag for that language, then use 'mis' (which covers any language), not 'und'. 8. 'und' or 'mis' or 'mul' (depending). Best bet is probably 'und'. 9. "" (if allowed as an extension), 'zxx', or 'und'; NOT 'art', NOT 'mis', (NOT i-default in a BCP 47 context). 10. 'de', but 'gem' can be used if one for some reason does not have access to using 'de' (in a BCP 47 context we do have access to using 'de'...). Note: there is no 'ger' tag, so I used 'gem' here, which I think was the intent. 11. Ok, but 'gsw' is recommended over 'gem' (when one has access to using the 'gsw' code). Note: there is no 'ger' tag, so I used 'gem' here, which I think was the intent. 12. Ok, but 'sa' is recommended over 'pra' (when one has access to using the 'sa' code). 13. See my comments on cases 2 and 5 above. Just because one has images in/with the text does not make the 'mul' tag appropriate. 'zxx' is a kind of neutral here. 14. Ok. 15. 'en', not 'en-Zxxx' (in a BCP 47 context). I don't think 'Zxxx' was intended for such a case. Zxxx does NOT mean "no script content". OTOH, I'm not sure when it *is* appropriate to use. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 12:44: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 1HewDx-0007Wf-Ow; Fri, 20 Apr 2007 12:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HewDw-0007WZ-GR for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:44:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HewDu-0006My-0x for ltru@lists.ietf.org; Fri, 20 Apr 2007 12:44:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HewDi-0006CI-J2 for ltru@lists.ietf.org; Fri, 20 Apr 2007 18:44:26 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 18:44:26 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 18:44:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 18:41:29 +0200 Organization: Lines: 31 Message-ID: <4628ED39.33F@xyzzy.claranet.de> References: <20070413122917.GA25431@nic.fr> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf-languages@alvestrand.no Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > An alternative would be to explicitly broaden the description of > "zxx" to be "no linguistic content, or programming source code". > That would be a compatible change to 4646bis, since it is a > broadening. I'd like the proposed "zxx" comment for rather different reasons: IMO it is _not_ changing the existing "zxx" semantics in any way. By definition BCP 47 claims to be only about human languages, and draws the line roughly with "art". Anything outside of this field is considered as "zxx", and programming languages are explicitly mentioned in BCP 47. So if they get any language tag at all "zxx" was and is possible, only the description is "mis"-leading when read outside of its BCP 47 context, i.e. in the "zxx" record in the raw registry data. Adding a comment to reenforce the intended context doesn't change or broaden the meaning, it clarifies what "zxx" is. Same idea as for the proposed "mis" comment: Comments added to subtags adopted from ISO standards or from UN region numbers should IMO never change, restrict, or broaden the real meaning in those sources, but they can reflect or clarify this meaning when the description "mis"-erably fails to do this. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 13:15: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 1Hewi1-0006dd-Tc; Fri, 20 Apr 2007 13:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewi0-0006dQ-JK for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:15:44 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound7-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hewhy-0003GI-36 for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:15:44 -0400 Received: from outbound7-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-blu-R.bigfish.com (Postfix) with ESMTP id A8253213A7B; Fri, 20 Apr 2007 17:15:41 +0000 (UTC) Received: from mail231-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound7-blu.bigfish.com (Postfix) with ESMTP id 8CF01163008A; Fri, 20 Apr 2007 17:15:41 +0000 (UTC) Received: from mail231-blu (localhost.localdomain [127.0.0.1]) by mail231-blu-R.bigfish.com (Postfix) with ESMTP id 33CDA14D83DA; Fri, 20 Apr 2007 17:15:41 +0000 (UTC) X-BigFish: VP Received: by mail231-blu (MessageSwitch) id 1177089340984610_5629; Fri, 20 Apr 2007 17:15:40 +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 mail231-blu.bigfish.com (Postfix) with ESMTP id BEC6D5C006C; Fri, 20 Apr 2007 17:15:40 +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 2007042010153897-95501 ; Fri, 20 Apr 2007 10:15:38 -0700 In-Reply-To: <005201c7836a$e7a6d170$5072f853@streamserve.com> To: "Kent Karlsson" Subject: RE: [Ltru] Re: Language Tag Special Cases 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, 20 Apr 2007 10:13:47 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/20/2007 10:13:49, Serialize complete at 04/20/2007 10:13:49, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:15:38 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:15:40 AM, Serialize complete at 04/20/2007 10:15:40 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0654753187==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0654753187== Content-Type: multipart/alternative; boundary="=_alternative 005ED09A882572C3_=" This is a multipart message in MIME format. --=_alternative 005ED09A882572C3_= Content-Type: text/plain; charset="US-ASCII" Kent wrote: > 1. Ok. > > 2. Depends, if that is actually some image with text in some > language or a sound snippet in some language, then clearly a > language tag can be applied. However, in practice I don't > expect many images to be language tagged, especially not if > the text is incidental. Advertisements, animations, header images, and marketing graphics frequently have text that is not incidental. A very common use case. Karen Broome --=_alternative 005ED09A882572C3_= Content-Type: text/html; charset="US-ASCII"
Kent wrote:

 
> 1. Ok.
>
> 2. Depends, if that is actually some image with text in some
> language or a sound snippet in some language, then clearly a
> language tag can be applied. However, in practice I don't
> expect many images to be language tagged, especially not if
> the text is incidental.

Advertisements, animations, header images, and marketing graphics frequently have text that is not incidental. A very common use case.

Karen Broome


--=_alternative 005ED09A882572C3_=-- --===============0654753187== 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 --===============0654753187==-- From ltru-bounces@ietf.org Fri Apr 20 13:22: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 1Hewo4-0005cO-KB; Fri, 20 Apr 2007 13:22:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewo3-0005cJ-JS for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:21:59 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hewo2-0007D8-AN for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:21:59 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:2262 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hewo1-0008VA-87 for ltru@lists.ietf.org; Fri, 20 Apr 2007 19:21:57 +0200 From: "Kent Karlsson" To: References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Fri, 20 Apr 2007 19:24:25 +0200 Message-ID: <005c01c78370$be904450$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceDZ3TuXrjJv3eOSTKL3KIuq2qLsgACDd6A In-Reply-To: <4628E7A2.3030509@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hewo1-0008VA-87. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hewo1-0008VA-87 eaa3d61a3a14dd2e2bf2d270b94a45b2 X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > So if I understand the proposal, it is to deal with the different > "special case" codes assigned by ISO 639. To paraphrase what 4646 ... > "mis" [...] 'mis' is NOT a "special" code in the 639 sense. It is a collection code (among many other collection codes). The only thing "special" about it is that it is the "top level" collection (in the inclusion hierarchy), but that does not make it "special" in the ISO 639 sense. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 13:26: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 1HewsG-0001U8-EA; Fri, 20 Apr 2007 13:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HewsF-0001Tf-7z for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:26:19 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound6-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HewsD-00006Z-Lc for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:26:19 -0400 Received: from outbound6-dub.bigfish.com (localhost [127.0.0.1]) by outbound6-dub-R.bigfish.com (Postfix) with ESMTP id 1EA9631805C; Fri, 20 Apr 2007 17:26:17 +0000 (UTC) Received: from mail123-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound6-dub.bigfish.com (Postfix) with ESMTP id 0F7C15004E; Fri, 20 Apr 2007 17:26:17 +0000 (UTC) Received: from mail123-dub (localhost [127.0.0.1]) by mail123-dub-R.bigfish.com (Postfix) with ESMTP id D10452C815B; Fri, 20 Apr 2007 17:26:16 +0000 (UTC) X-BigFish: VP Received: by mail123-dub (MessageSwitch) id 1177089976743215_31682; Fri, 20 Apr 2007 17:26:16 +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 mail123-dub.bigfish.com (Postfix) with ESMTP id EC1D416D8063; Fri, 20 Apr 2007 17:26:15 +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 2007042010261214-96081 ; Fri, 20 Apr 2007 10:26:12 -0700 In-Reply-To: <4628AD9E.3CFD@xyzzy.claranet.de> To: Frank Ellermann Subject: Re: [Ltru] Re: Language Tag Special Cases 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, 20 Apr 2007 10:24:21 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/20/2007 10:24:22, Serialize complete at 04/20/2007 10:24:22, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:26:12 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:26:16 AM, Serialize complete at 04/20/2007 10:26:16 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0078966782==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0078966782== Content-Type: multipart/alternative; boundary="=_alternative 005FC80B882572C3_=" This is a multipart message in MIME format. --=_alternative 005FC80B882572C3_= Content-Type: text/plain; charset="US-ASCII" I think this is a broadening of the definition and perhaps the scope of ISO 639. To say "or programming source code" makes a positive statement of identification that is outside the bounds of the standard. The Zxxx script tag and Zxx tag would have been better defined as "Not Applicable" which is the semantic suggested below. The concepts of "non-linguistic language" and "unwritten script" are oxymoronic. Regards, Karen Broome Frank Ellermann 04/20/2007 05:10 AM To ltru@lists.ietf.org cc Subject [Ltru] Re: Language Tag Special Cases Karen_Broome@spe.sony.com wrote: > I understand that there are worlds other than XHTML and HTML, but > I can't come up with a use case (for identifying programming code > with zxx) outside of those instances. You could add code as inline text/plain part of a MIME message, and an IMO "mis"-guided implementation could decide that it "must" use some odd heuristics to determine a Content-Language header field (instead of simply not using this header field). There are other uses of language tags with MIME, see also RFC 2231. I don't think that "MIME or XML or HTML" is a complete enumeration of all use cases for language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 005FC80B882572C3_= Content-Type: text/html; charset="US-ASCII"
I think this is a broadening of the definition and perhaps the scope of ISO 639. To say "or programming source code" makes a positive statement of identification that is outside the bounds of the standard.

The Zxxx script tag and Zxx tag would have been better defined as "Not Applicable" which is the semantic suggested below. The concepts of "non-linguistic language" and "unwritten script" are oxymoronic.

Regards,

Karen Broome




Frank Ellermann <nobody@xyzzy.claranet.de>

04/20/2007 05:10 AM

To
ltru@lists.ietf.org
cc
Subject
[Ltru] Re: Language Tag Special Cases





Karen_Broome@spe.sony.com wrote:

> I understand that there are worlds other than XHTML and HTML, but
> I can't come up with a use case (for identifying programming code
> with zxx) outside of those instances.

You could add code as inline text/plain part of a MIME message, and
an IMO "mis"-guided implementation could decide that it "must" use
some odd heuristics to determine a Content-Language header field
(instead of simply not using this header field).

There are other uses of language tags with MIME, see also RFC 2231.
I don't think that "MIME or XML or HTML" is a complete enumeration
of all use cases for language tags.

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 005FC80B882572C3_=-- --===============0078966782== 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 --===============0078966782==-- From ltru-bounces@ietf.org Fri Apr 20 13:41: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 1Hex6j-0003ry-GR; Fri, 20 Apr 2007 13:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hex6i-0003rr-9b for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:41:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hex6g-0005UW-Os for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:41:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hex6a-00029M-Pt for ltru@lists.ietf.org; Fri, 20 Apr 2007 19:41:08 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 19:41:08 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 19:41:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 19:37:47 +0200 Organization: Lines: 78 Message-ID: <4628FA6B.679F@xyzzy.claranet.de> References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > So if I understand the proposal, it is to deal with the different > "special case" codes assigned by ISO 639. Is "the proposal" Mark's table with examples ? I hope we identify some cases where subtags aren't intuitively clear (based on their registry records), and fix this by adding comments, and/or text to 4646bis, and/or publish a "final table" on Stephane's site as part of the BCP 47 FAQ, and/or ask Richard to add this table or a link to his article. Last but not least I guess that Mark has his own idea what to with this or a "final" table for CLDR. > To paraphrase what 4646 contains (plus my interpretation of the > additions): > "mul" is used to identify content in multiple languages. It SHOULD NOT > be used when a list of languages (such as Content-Language) can be used > instead and it SHOULD NOT be used for individual content items (such as > a single

element in an XHTML document). The 4646 4.1 bullet 5 explanation for "mul" is okay. I don't get what you're saying here, why would a

be falsch eller verboten if nada est autrefois acquit

? > "und" is used to identify linguistic content whose language cannot be > determined. It SHOULD NOT be used unless a language tag is required > and the language cannot be determined. Yes, that's better than 4646 4.1 bullet 4, it allows und-Latn. s/cannot/could not/ At the time when it was attempted it turned out to be too difficult. It's not necessarily forever impossible to determine the language (or its absence in the form of "zxx"). > "zxx" is used to identify non-lingusitic content. It SHOULD NOT be used > unless a language tag is required by some application or protocol for > some non-human language content item. +1, maybe add programming languages as example. But it's probably better to tackle this case in a comment directly in the registry. > "mis" is used to identify linguistic content whose language is > known but cannot otherwise be identified. It is commonly used when > the range of language tags is constrained (for example, to ISO 639-2, > as in MARC, for example) or for languages not otherwise categorized. > It SHOULD NOT be used unless a language tag is required and no other > means of identifying the language is available. Yes, s/, as in MARC, for example// unless you intend to create fresh informative references with "acronym expansion on first use". We're not yet directly supporting restricted subsets of the subtag registry, and "mis" isn't important enough to start this major task. How about: | "mis" is used to identify linguistic content whose language is | known but cannot otherwise be identified. It is commonly used for | languages not otherwise categorized. It SHOULD NOT be used unless | a language tag is required and no other means of identifying the | language is available. After looking at I'd really prefer to stay OUT of this minefield. It has "beware of ratholes" all over the simple page. > In all cases, where permitted, omitting the language tag is > preferable to using these codes. Language tags SHOULD NOT > incorporate these subtags as a prefix under any circumstances. NAK, Mark's und-Latn was at least possible. And some of his other examples could be tagged as "zxx-Latn" if the tagger really wants this. > Any other cases? i-default with a reference to RFC 2277. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 13:50: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 1HexG3-0007qt-Cr; Fri, 20 Apr 2007 13:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HexG2-0007ql-U9 for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:50:54 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound5-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HexG2-0000Lq-HD for ltru@lists.ietf.org; Fri, 20 Apr 2007 13:50:54 -0400 Received: from outbound5-blu.bigfish.com (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound5-blu-R.bigfish.com (Postfix) with ESMTP id 40444E42F57; Fri, 20 Apr 2007 17:50:54 +0000 (UTC) Received: from mail21-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound5-blu.bigfish.com (Postfix) with ESMTP id 2B4C1B3004B; Fri, 20 Apr 2007 17:50:54 +0000 (UTC) Received: from mail21-blu (localhost.localdomain [127.0.0.1]) by mail21-blu-R.bigfish.com (Postfix) with ESMTP id 06F4C122816F; Fri, 20 Apr 2007 17:50:53 +0000 (UTC) X-BigFish: VP Received: by mail21-blu (MessageSwitch) id 1177091453719461_14816; Fri, 20 Apr 2007 17:50:53 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail21-blu.bigfish.com (Postfix) with ESMTP id 4BABE19006E; Fri, 20 Apr 2007 17:50:53 +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 2007042010505060-97463 ; Fri, 20 Apr 2007 10:50:50 -0700 In-Reply-To: <4628AD9E.3CFD@xyzzy.claranet.de> To: Frank Ellermann Subject: Re: [Ltru] Re: Language Tag Special Cases 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, 20 Apr 2007 10:49:00 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 04/20/2007 10:49:00, Serialize complete at 04/20/2007 10:49:00, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:50:50 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 04/20/2007 10:50:53 AM, Serialize complete at 04/20/2007 10:50:53 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1557577420==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1557577420== Content-Type: multipart/alternative; boundary="=_alternative 006209B5882572C3_=" This is a multipart message in MIME format. --=_alternative 006209B5882572C3_= Content-Type: text/plain; charset="US-ASCII" Hmm. Seems like a rather unlikely use case. In the example below, how would tagging the MIME text as "zxx" help this misguided implementation? Could it be potentially misleading to tag this content as non-linguistic? I think the case below is "und". (Again, I never implied that lang tags are only used in HTML and XHTML. I don't even use lang tags in those contexts in my current work! I am specifically talking about use cases for the zxx tag used in reference to a code snippet. That's it.) Thanks for the example, Frank. Karen Broome Frank Ellermann 04/20/2007 05:10 AM To ltru@lists.ietf.org cc Subject [Ltru] Re: Language Tag Special Cases Karen_Broome@spe.sony.com wrote: > I understand that there are worlds other than XHTML and HTML, but > I can't come up with a use case (for identifying programming code > with zxx) outside of those instances. You could add code as inline text/plain part of a MIME message, and an IMO "mis"-guided implementation could decide that it "must" use some odd heuristics to determine a Content-Language header field (instead of simply not using this header field). There are other uses of language tags with MIME, see also RFC 2231. I don't think that "MIME or XML or HTML" is a complete enumeration of all use cases for language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006209B5882572C3_= Content-Type: text/html; charset="US-ASCII"
Hmm. Seems like a rather unlikely use case.  In the example below, how would tagging the MIME text as "zxx" help this misguided implementation? Could it be potentially misleading to tag this content as non-linguistic? I think the case below is "und".

(Again, I never implied that lang tags are only used in HTML and XHTML. I don't even use lang tags in those contexts in my current work! I am specifically talking about use cases for the zxx tag used in reference to a code snippet. That's it.)

Thanks for the example, Frank.

Karen Broome



Frank Ellermann <nobody@xyzzy.claranet.de>

04/20/2007 05:10 AM

To
ltru@lists.ietf.org
cc
Subject
[Ltru] Re: Language Tag Special Cases





Karen_Broome@spe.sony.com wrote:

> I understand that there are worlds other than XHTML and HTML, but
> I can't come up with a use case (for identifying programming code
> with zxx) outside of those instances.

You could add code as inline text/plain part of a MIME message, and
an IMO "mis"-guided implementation could decide that it "must" use
some odd heuristics to determine a Content-Language header field
(instead of simply not using this header field).

There are other uses of language tags with MIME, see also RFC 2231.
I don't think that "MIME or XML or HTML" is a complete enumeration
of all use cases for language tags.

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 006209B5882572C3_=-- --===============1557577420== 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 --===============1557577420==-- From ltru-bounces@ietf.org Fri Apr 20 14:31: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 1HextQ-0001zS-D1; Fri, 20 Apr 2007 14:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HextP-0001zK-3m for ltru@lists.ietf.org; Fri, 20 Apr 2007 14:31:35 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HextN-00037F-OV for ltru@lists.ietf.org; Fri, 20 Apr 2007 14:31:35 -0400 Received: from [10.76.37.212] (wifi-postauth212.london.corp.yahoo.com [10.76.37.212]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3KIVDbT048699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 11:31: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=VXfFEjcZAddDqc+TY7sPFC+rrA0DlgdUUCORgJlIXxRkI40XxomF1Xg1FONbhEYV Message-ID: <462906EF.9040905@yahoo-inc.com> Date: Fri, 20 Apr 2007 19:31:11 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kent Karlsson Subject: Re: [Ltru] Re: Language Tag Special Cases References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> In-Reply-To: <005c01c78370$be904450$5072f853@streamserve.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You're right. My bad. Looking at the actual definition (which I finally got around to---this list generated a ton of very long emails in the 10 days I was offline) helps a lot. 'mis' includes exactly 133 specific "miscellaneous" languages and doesn't include the definition I supplied in the previous message. Addison Kent Karlsson wrote: > > Addison Phillips wrote: >> So if I understand the proposal, it is to deal with the different >> "special case" codes assigned by ISO 639. To paraphrase what 4646 > ... >> "mis" [...] > > > 'mis' is NOT a "special" code in the 639 sense. It is a collection > code (among many other collection codes). The only thing "special" > about it is that it is the "top level" collection (in the inclusion > hierarchy), but that does not make it "special" in the ISO 639 sense. > > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 15:17: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 1Heybm-0002IN-3P; Fri, 20 Apr 2007 15:17:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heybk-0002Gb-5C for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:17:24 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heybj-0001lS-Pq for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:17:24 -0400 Received: by nz-out-0506.google.com with SMTP id o37so966067nzf for ; Fri, 20 Apr 2007 12:17:23 -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=kBA9b2HehibteMhWKT9fQQ65dEohSX2EnimDs624hYxZU3uCi+Jgb4pTGv5+Emazju/ORmiGBXXi0ieCogM3wIH+cESGkUxMYBEYSuIDc0gHqSp+9G30URlhV8GDM8PufMPtQ1jmRv/FV8LZun9f7TZ4+wXx7N3k3gs3IuDETL0= 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=rrt2+AOiKHpszzsq1OnU7avqjHpHccTuv8uYrG34j5oa2ntnkQlJ9HvyfWw5jpXiCm4G9tQ881hGimgwX6zl5DhA408pvITgbCdZmYv/DWmf7utR3AHdrMBs/yHs0XcKhqCdOvZlsoR02/2QLRjK4CkSZq4lftN1x4DQaFSLn50= Received: by 10.114.77.1 with SMTP id z1mr1379454waa.1177096642907; Fri, 20 Apr 2007 12:17:22 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 12:17:22 -0700 (PDT) Message-ID: <30b660a20704201217p2f29b69bh275aa2b4dcf234f1@mail.gmail.com> Date: Fri, 20 Apr 2007 12:17:22 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: <4628E709.4030300@yahoo-inc.com> MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> <4628E709.4030300@yahoo-inc.com> X-Google-Sender-Auth: 63805a0c6b048e10 X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2042881545==" Errors-To: ltru-bounces@ietf.org --===============2042881545== Content-Type: multipart/alternative; boundary="----=_Part_151178_1902049.1177096642730" ------=_Part_151178_1902049.1177096642730 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It is clear that they aren't natural languages (although one could make a case for them being human -- after all, martians didn't write the code you included ;-). The question is what to tag them with in circumstances where you need to have them tagged. My conclusion is that according to 4646, zxx is not appropriate, which leaves someone with "und". ( http://docs.google.com/Doc?id=dfqr8rd5_11g425c9) Mark On 4/20/07, Addison Phillips wrote: > > > Most code source nowadays are not just random hex, there > > typically, not exceptionally, some real linguistic content. I would > > agree with you that a hex dump of a compiled program, such as perhaps > > you used for your example, is sensible to tag as zxx, but based on the > > wording of the standards, I don't think we can expect zxx to apply to > > typical code source. Yet, while there may be is some embedded English, > > we don't want to call it "en" either. > > I don't understand. Why is this really a problem? BCP 47 has always > said, quite clearly, that programming languages are not what we mean by > "languages". The following fragment is utterly perverse (but not illegal): > > --- > > Content-Type: application/javascript > Content-Language: zxx, en > > function init() { > > var stdmenu = new widget.Menu('stditems', { position:'static' }); > var menuitems = stdmenu.getItemGroups(); > > for (var x=0; x stdmenu.getItem(x).mouseOverEvent.subscribe(doMouseEvent); > stdmenu.getItem(x).keyDownEvent.subscribe(doMouseEvent); > } > > stdmenu.render(); > stdmenu.show(); > } > --- > > Note that there are no "English" words above (except, possibly, the > keyword "static"). Calling programming language keywords or variable > names "English" is mostly daft or especially pedantic. > > Really, of course, it probably makes more sense to say what BCP 47 has > always said: (BCP 47) "... excludes languages not intended primarily for > human communication, such as programming languages..." and leave it at > that. Allowing the use of 'zxx' for programming languages when utterly > required I have no problem with, but why break out programming languages > as anything other than an example? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > -- Mark ------=_Part_151178_1902049.1177096642730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It is clear that they aren't natural languages (although one could make a case for them being human -- after all, martians didn't write the code you included ;-). The question is what to tag them with in circumstances where you need to have them tagged. My conclusion is that according to 4646, zxx is not appropriate, which leaves someone with "und". ( http://docs.google.com/Doc?id=dfqr8rd5_11g425c9)

Mark

On 4/20/07, Addison Phillips <addison@yahoo-inc.com> wrote:
> Most code source nowadays are not just random hex, there
> typically, not exceptionally, some real linguistic content. I would
> agree with you that a hex dump of a compiled program, such as perhaps
> you used for your example, is sensible to tag as zxx, but based on the
> wording of the standards, I don't think we can expect zxx to apply to
> typical code source. Yet, while there may be is some embedded English,
> we don't want to call it "en" either.

I don't understand. Why is this really a problem? BCP 47 has always
said, quite clearly, that programming languages are not what we mean by
"languages". The following fragment is utterly perverse (but not illegal):

---

Content-Type: application/javascript
Content-Language: zxx, en

function init() {

    var stdmenu = new widget.Menu('stditems', { position:'static' });
    var menuitems = stdmenu.getItemGroups();

    for (var x=0; x<menuitems.length; x++) {
       stdmenu.getItem(x).mouseOverEvent.subscribe(doMouseEvent);
       stdmenu.getItem(x).keyDownEvent.subscribe(doMouseEvent);
    }

    stdmenu.render();
    stdmenu.show();
}
---

Note that there are no "English" words above (except, possibly, the
keyword "static"). Calling programming language keywords or variable
names "English" is mostly daft or especially pedantic.

Really, of course, it probably makes more sense to say what BCP 47 has
always said: (BCP 47) "... excludes languages not intended primarily for
human communication, such as programming languages..." and leave it at
that. Allowing the use of 'zxx' for programming languages when utterly
required I have no problem with, but why break out programming languages
as anything other than an example?

Addison

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

Internationalization is an architecture.
It is not a feature.



--
Mark ------=_Part_151178_1902049.1177096642730-- --===============2042881545== 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 --===============2042881545==-- From ltru-bounces@ietf.org Fri Apr 20 15:23: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 1Heyh9-0000YD-Pe; Fri, 20 Apr 2007 15:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heyh8-0000U2-Gd for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:22:58 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heyh6-0002zT-Qb for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:22:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Heyh3-0001WM-31 for ltru@lists.ietf.org; Fri, 20 Apr 2007 21:22:53 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 21:22:53 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 21:22:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 21:17:38 +0200 Organization: Lines: 78 Message-ID: <462911D2.280F@xyzzy.claranet.de> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > BTW, not everyone will be familiar with ACK and NAK. After a good result with "define:MARC" I now also checked out "define NAK" (with or without colon has different effects), it works as designed. >> NAK for 4, "What?" isn't "mis". > As I said in email, I see nothing in the standard that indicates > that "mis" is not valid for English, but valid for, say, Ainu or > anything else. Yes, you said this, but I found John's explanations, supported by Peter to some degree, far more convincing. Roughly a set of other languages not belonging to any other registered set of languages. For our purposes they got the name "mis" wrong. The semantics is okay, once you know what it's supposed to be. It has the decent charme of UM in country codes, a better name could have been "mol", minor outlying languages. > If you can demonstrate that, by quoting from the ISO 639 standard > or data, I'd appreciate it. The LOC pages don't work with my browser, I'm not inclined to check why. There's a reason why copying such lists to a public ASCII text file in a reasaonable format hosted by IANA is a very good thing. I'm also not going to pay CHF 64 for an obscure 639-5, a PDF with 356 KB, that's likely three pages DIN A4, and nobody knows what version of "proprietary data format" it needs. I trust that John and Peter know what they're talking about when it passes my subjective plausibility checks. The "mis" issue was plausible, it makes sense to have a set of items not belonging to any other set in an enumeration of sets. Your concept of a set of all items also makes sense, but I'd expect a name like "all" or "any" for this purpose, not "mis". Some of my most important local directories have names like "misc" or "etc", in both cases this isn't the root. If you feel that you must have an "any" tag go for it. But IMO you're free to (ab)use "mis" as it pleases you, locally, just don't use your local "mis" on public pages where it could confuse tag consumers with another idea about the non-existing "any" tag. > INCONCLUSIVE for 15, is a tag "en-Zxxx" allowed ? > Clearly "en" is no "unwritten language", only the > content is unwritten in this video/audio example. > It certainly makes sense to say that a video of Bugs Bunny has no > written language content, and that's how we interpret Zxxx. > (Zxxx has no use otherwise Maybe the Zxxx description "code for unwritten language" should also get a comment and paragraph in 4646bis then: Your use case is apparently "none", not only "n/a". We have "zxx" for "not a (human) language", and then "Zxxx" for "not a script" fits. But "not a script" isn't exactly the same as "unwritten", it's a border case. Maybe Addison can copy the proposed "zxx" paragraph into a "Zxxx" paragraph, using the same normative SHOULD NOT clauses. > I added "i-default" at the top, since as far as I can tell, it > is essentially equivalent to "und" or maybe "mis". John's RFC 2277 quote was a bit more specific than "und", it's related to "en" with a touch of "und". > I think we should discourage it Yes, the source (RFC 2277) already does this. We could add a comment "see BCP 18 (RFC 2277)" to the BCP 47 registry. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 15:47: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 1Hez5I-0001jS-PQ; Fri, 20 Apr 2007 15:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez5G-0001YC-T2 for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:47:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hez5F-0006sK-Sw for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:47:54 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1025569wra for ; Fri, 20 Apr 2007 12:47:53 -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=IjUZ6gWkrdt26wxnaM0u9UD+X4V+gSDYMAYFgAFWawDyz4qeCaoa8+GI5vi4wYBToChBhPPKg8AJ5m4QYmqWkEIBeWq4TlahvU9iy8igcWs/NPumwMMrQBXDjnGMnShY5En4kXpgE3jbaiAGn9RoKa0CF3FHyiKuVqtPAIU3jPU= 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=EvEWxNTeQhPVkuhUHeZGMc8GDXQyChnZ/aavw9ryPMnfZ/yMoW9+FsXE2TMjKcKgeyr26fs31tmjAzpyBthKLDLPLW8IKKEmqMaKYI9ybAISVYOJODUcwnQHkAewRFCC20DcebFDGlfGAflNUlkJHgE4Wjk20B3Uh6FIAipMVTI= Received: by 10.114.179.1 with SMTP id b1mr1392551waf.1177098472774; Fri, 20 Apr 2007 12:47:52 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 12:47:52 -0700 (PDT) Message-ID: <30b660a20704201247k5ae895acg59c282dadbd83b3b@mail.gmail.com> Date: Fri, 20 Apr 2007 12:47:52 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Language Tag Special Cases In-Reply-To: <462911D2.280F@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> <462911D2.280F@xyzzy.claranet.de> X-Google-Sender-Auth: 41b92fd90e947949 X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1681990703==" Errors-To: ltru-bounces@ietf.org --===============1681990703== Content-Type: multipart/alternative; boundary="----=_Part_151846_19936909.1177098472687" ------=_Part_151846_19936909.1177098472687 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/20/07, Frank Ellermann > wrote: > > Mark Davis wrote: > > > BTW, not everyone will be familiar with ACK and NAK. > > After a good result with "define:MARC" I now also checked out > "define NAK" (with or without colon has different effects), > it works as designed. > > >> NAK for 4, "What?" isn't "mis". > > > As I said in email, I see nothing in the standard that indicates > > that "mis" is not valid for English, but valid for, say, Ainu or > > anything else. > > Yes, you said this, but I found John's explanations, supported by > Peter to some degree, far more convincing. Roughly a set of other > languages not belonging to any other registered set of languages. That is one interpretation, but it is not supported by the text. It would be a bad interpretation, since it breaks stability. As I say, I think the best thing we could do at this point would be to strongly discourage the use of "mis" in 4646bis because the semantics are unclear. For our purposes they got the name "mis" wrong. The semantics is > okay, once you know what it's supposed to be. But we don't know that that is the only interpretation, according to the text it could be a variety of things. It has the decent > charme of UM in country codes, a better name could have been "mol", > minor outlying languages. > > > If you can demonstrate that, by quoting from the ISO 639 standard > > or data, I'd appreciate it. > > The LOC pages don't work with my browser, I'm not inclined > to check why. There's a reason why copying such lists to a public > ASCII text file in a reasaonable format hosted by IANA is a very > good thing. I'm also not going to pay CHF 64 for an obscure 639-5, > a PDF with 356 KB, that's likely three pages DIN A4, and nobody > knows what version of "proprietary data format" it needs. Pick a different browser. The text doesn't , as far as I can see, support the contention, and I haven't seen anything from John or Peter to contradict that. Much as I respect their judgments on a whole variety of subjects, on this one I think they are interpreting the text as they think it should have been written, not as it is. Again, if we can agree to discourage "mis", then we don't have to keep having this discussion. I trust that John and Peter know what they're talking about when > it passes my subjective plausibility checks. The "mis" issue was > plausible, it makes sense to have a set of items not belonging to > any other set in an enumeration of sets. Your concept of a set of > all items also makes sense, but I'd expect a name like "all" or > "any" for this purpose, not "mis". > > Some of my most important local directories have names like "misc" > or "etc", in both cases this isn't the root. If you feel that you > must have an "any" tag go for it. But IMO you're free to (ab)use > "mis" as it pleases you, locally, just don't use your local "mis" > on public pages where it could confuse tag consumers with another > idea about the non-existing "any" tag. "Misc" as exclusionary makes sense any time you are in an environment that forces a disjunctive partition. But ISO 639 does not require a partition. It's not abusing a code if there is no text in ISO 639-2 that would lead one to think that one is abusing it. > INCONCLUSIVE for 15, is a tag "en-Zxxx" allowed ? > > Clearly "en" is no "unwritten language", only the > > content is unwritten in this video/audio example. > > > It certainly makes sense to say that a video of Bugs Bunny has no > > written language content, and that's how we interpret Zxxx. > > (Zxxx has no use otherwise > > Maybe the Zxxx description "code for unwritten language" should > also get a comment and paragraph in 4646bis then: Your use case > is apparently "none", not only "n/a". > > We have "zxx" for "not a (human) language", and then "Zxxx" for > "not a script" fits. But "not a script" isn't exactly the same > as "unwritten", it's a border case. Maybe Addison can copy the > proposed "zxx" paragraph into a "Zxxx" paragraph, using the same > normative SHOULD NOT clauses. I disagree. Zxxx fits a perfectly legitimate need; it clearly applies to languages. There are two possible interpretations that could be given to an application of it to content. 1. content that is not written 2. content that cannot be written The second one I find incoherent. > I added "i-default" at the top, since as far as I can tell, it > > is essentially equivalent to "und" or maybe "mis". > > John's RFC 2277 quote was a bit more specific than "und", it's > related to "en" with a touch of "und". Yes, there are some nuanced differences between them, but when I look at examples, it looks really hard to say what the difference would be between them in terms of tagging content. Perhaps I'm just missing something. > I think we should discourage it > > Yes, the source (RFC 2277) already does this. We could add a > comment "see BCP 18 (RFC 2277)" to the BCP 47 registry. Or even better yet, a comment in the registry and the text explicitly discouraging it. Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_151846_19936909.1177098472687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 4/20/07, Frank Ellermann < nobody@xyzzy.claranet.de> wrote:
Mark Davis wrote:

> BTW, not everyone will be familiar with ACK and NAK.

After a good result with "define:MARC" I now also checked out
"define NAK" (with or without colon has different effects),
it works as designed.

>> NAK for 4, "What?" isn't "mis".

> As I said in email, I see nothing in the standard that indicates
> that "mis" is not valid for English, but valid for, say, Ainu or
> anything else.

Yes, you said this, but I found John's explanations, supported by
Peter to some degree, far more convincing.  Roughly a set of other
languages not belonging to any other registered set of languages.

That is one interpretation, but it is not supported by the text. It would be a bad interpretation, since it breaks stability. As I say, I think the best thing we could do at this point would be to strongly discourage the use of "mis" in 4646bis because the semantics are unclear.

For our purposes they got the name "mis" wrong.  The semantics is
okay, once you know what it's supposed to be. 

But we don't know that that is the only interpretation, according to the text it could be a variety of things.

 It has the decent
charme of UM in country codes, a better name could have been "mol",
minor outlying languages.

> If you can demonstrate that, by quoting from the ISO 639 standard
> or data, I'd appreciate it.

<rant> The LOC pages don't work with my browser, I'm not inclined
to check why.  There's a reason why copying such lists to a public
ASCII text file in a reasaonable format hosted by IANA is a very
good thing.  I'm also not going to pay CHF 64 for an obscure 639-5,
a PDF with 356 KB, that's likely three pages DIN A4, and nobody
knows what version of "proprietary data format" it needs. </rant>

Pick a different browser. The text doesn't , as far as I can see, support the contention, and I haven't seen anything from John or Peter to contradict that. Much as I respect their judgments on a whole variety of subjects, on this one I think they are interpreting the text as they think it should have been written, not as it is.

Again, if we can agree to discourage "mis", then we don't have to keep having this discussion.

I trust that John and Peter know what they're talking about when
it passes my subjective plausibility checks.  The "mis" issue was
plausible, it makes sense to have a set of items not belonging to
any other set in an enumeration of sets.  Your concept of a set of
all items also makes sense, but I'd expect a name like "all" or
"any" for this purpose, not "mis".

Some of my most important local directories have names like "misc"
or "etc", in both cases this isn't the root.  If you feel that you
must have an "any" tag go for it.  But IMO you're free to (ab)use
"mis" as it pleases you, locally, just don't use your local "mis"
on public pages where it could confuse tag consumers with another
idea about the non-existing "any" tag.

"Misc" as exclusionary makes sense any time you are in an environment that forces a disjunctive partition. But ISO 639 does not require a partition.

It's not abusing a code if there is no text in ISO 639-2 that would lead one to think that one is abusing it.

>      INCONCLUSIVE for 15, is a tag "en-Zxxx" allowed ?
>      Clearly "en" is no "unwritten language", only the
>      content is unwritten in this video/audio example.

> It certainly makes sense to say that a video of Bugs Bunny has no
> written language content, and that's how we interpret Zxxx.
> (Zxxx has no use otherwise

Maybe the Zxxx description "code for unwritten language" should
also get a comment and paragraph in 4646bis then:  Your use case
is apparently "none", not only "n/a".

We have "zxx" for "not a (human) language", and then "Zxxx" for
"not a script" fits.  But "not a script" isn't exactly the same
as "unwritten", it's a border case.  Maybe Addison can copy the
proposed "zxx" paragraph into a "Zxxx" paragraph, using the same
normative SHOULD NOT clauses.

I disagree. Zxxx fits a perfectly legitimate need; it clearly applies to languages. There are two possible interpretations that could be given to an application of it to content.
  1. content that is not written
  2. content that cannot be written
The second one I find incoherent.

> I added "i-default" at the top, since as far as I can tell, it
> is essentially equivalent to "und" or maybe "mis".

John's RFC 2277 quote was a bit more specific than "und", it's
related to "en" with a touch of "und".

Yes, there are some nuanced differences between them, but when I look at examples, it looks really hard to say what the difference would be between them in terms of tagging content. Perhaps I'm just missing something.

> I think we should discourage it

Yes, the source (RFC 2277) already does this.  We could add a
comment "see BCP 18 (RFC 2277)" to the BCP 47 registry.

Or even better yet, a comment in the registry and the text explicitly discouraging it.

Frank



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



--
Mark  ------=_Part_151846_19936909.1177098472687-- --===============1681990703== 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 --===============1681990703==-- From ltru-bounces@ietf.org Fri Apr 20 15: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 1HezGt-00080S-3f; Fri, 20 Apr 2007 15:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezGr-00080K-OG for ltru@ietf.org; Fri, 20 Apr 2007 15:59:53 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezGq-0004MN-8u for ltru@ietf.org; Fri, 20 Apr 2007 15:59:53 -0400 Received: by ik-out-1112.google.com with SMTP id c21so1147728ika for ; Fri, 20 Apr 2007 12:59:51 -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=B/lxIjSXZqU9mXLHOP8vwWal7iya6QMnN/xTGgVMYoUQleZtXAdPfsNjj5KbGNwaCyFm4/7Rj362hBUx5RigN4K10ja/F8v0/jBhqiY6kVA8Uw17RQk8rGurnTgdHN1EDWX+9nj5nx0RYIYLdgzE1XGCoOUVtsnyjqu9qzjy020= 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=cM++8MOQ0CC+HIS0IvSXqHR9NqsdQP1uHvzKC2ZNGBvNkilT8gfuseFVPVWNSDJvG23ELyHeGphKkYJ1ZycNYLo+rD3bCAeO+7oGOZo61wpWDXNmLad08j64+aUbtBr18ihZvaAAOl0jtt5cvJHzagtgMuhOjJNWiTqEkE8iyVA= Received: by 10.114.57.1 with SMTP id f1mr1409207waa.1177099190107; Fri, 20 Apr 2007 12:59:50 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 12:59:49 -0700 (PDT) Message-ID: <30b660a20704201259t60c072a2p3acb98df85bfdb2a@mail.gmail.com> Date: Fri, 20 Apr 2007 12:59:49 -0700 From: "Mark Davis" To: "Richard Ishida" In-Reply-To: <012301c77c34$3244ecf0$6601a8c0@rishida> MIME-Version: 1.0 References: <012301c77c34$3244ecf0$6601a8c0@rishida> X-Google-Sender-Auth: b0ce9a249108aebd X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: LTRU Working Group , www-international@w3.org Subject: [Ltru] Re: For review: Tagging text with no language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0133980263==" Errors-To: ltru-bounces@ietf.org --===============0133980263== Content-Type: multipart/alternative; boundary="----=_Part_152106_16897995.1177099189706" ------=_Part_152106_16897995.1177099189706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard, getting back to the topic of XML, it sounds like we have three cases, illustrated by the following example:

There are three cases: foo, foo, foo

In the first foo construction, we are saying that it inherits the language "en". The second and third construction are equivalent: we are overriding the "en" setting, and saying that foo is undetermined with regard to language. The difference between them is that: - the second construction can't be used in XHTML (or any other case where a DTD or schema requires a value). - the third construction can always be used, but shouldn't be used if the second can be. Mark On 4/11/07, Richard Ishida wrote: > > > > > http://www.w3.org/International/questions/qa-no-language > > Comments are being sought on this FAQ-based article prior to final > release. Please send any comments to www-international@w3.org. We expect > to publish a final version in one to two weeks. > > > > ============ > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ > > > > -- Mark ------=_Part_152106_16897995.1177099189706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard, getting back to the topic of XML, it sounds like we have three cases, illustrated by the following example:

<p xml:lang="en">There are three cases:
  <span>foo</span>,
  <span xml:lang="">foo</span>,
  <span xml:lang="und">foo</span>
</p>

In the first foo construction, we are saying that it inherits the language "en". The second and third construction are equivalent: we are overriding the "en" setting, and saying that foo is undetermined with regard to language. The difference between them is that:
  • the second construction can't be used in XHTML (or any other case where a DTD or schema requires a value).
  • the third construction can always be used, but shouldn't be used if the second can be.
Mark

On 4/11/07, Richard Ishida <ishida@w3.org> wrote:



http://www.w3.org/International/questions/qa-no-language

Comments are being sought on this FAQ-based article prior to final release. Please send any comments to www-international@w3.org. We expect to publish a final version in one to two weeks.



============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/






--
Mark ------=_Part_152106_16897995.1177099189706-- --===============0133980263== 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 --===============0133980263==-- From ltru-bounces@ietf.org Fri Apr 20 16:10: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 1HezRM-0001gJ-F3; Fri, 20 Apr 2007 16:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezDF-00066z-O9 for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:56:10 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezDD-0001jM-KM for ltru@lists.ietf.org; Fri, 20 Apr 2007 15:56:08 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:2705 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HezDB-00042R-9Z; Fri, 20 Apr 2007 21:56:06 +0200 From: "Kent Karlsson" To: "'Addison Phillips'" References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Fri, 20 Apr 2007 21:58:32 +0200 Message-ID: <005d01c78386$46d15a10$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceDeiAI6vGZp9KoSm+/oa8udYgaiAACFX7g In-Reply-To: <462906EF.9040905@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HezDB-00042R-9Z. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HezDB-00042R-9Z b3a10f2bda4d6101f8192fa37415715e X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > You're right. My bad. Looking at the actual definition (which > I finally > got around to---this list generated a ton of very long emails > in the 10 > days I was offline) helps a lot. 'mis' includes exactly 133 specific > "miscellaneous" languages [...] Not quite. 'mis' is a collection code, and as such is more vaguely specified than the individual language codes. The only reasonable interpretation of 'mis', I maintain, is that it covers all an any languages, but that is should not be used ("not intended for") *when there is a more specific language code (collection or individual) "available"*. In a 639-3 setting there would thus be very little use for 'mis', even though it covers all (any, really) language(s). However, in a hypothetical setting of just having access to say some of the codes covered by the 'fiu' collection, as well as 'mis' of course, one would use 'mis' for, among many other languages, English. I have no idea where you got the list of 133 specific languages from. As far as I can tell, it appears to have no normative connection with the 639 standards themselves. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 16:26: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 1HezgF-0006hE-4V; Fri, 20 Apr 2007 16:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezgE-0006h2-Ay for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:26:06 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hezg4-00023N-Me for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:26:06 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 20 Apr 2007 13:25:56 -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; Fri, 20 Apr 2007 13:25:55 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Fri, 20 Apr 2007 13:25:54 -0700 Subject: RE: [Ltru] Re: Language Tag Special Cases Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceDZ34V0zmdB4GtSBeJktcH6ARqiQAIo76Q Message-ID: References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> In-Reply-To: <4628E7A2.3030509@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.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: Friday, April 20, 2007 9:18 AM To: Frank Ellermann Cc: ltru@lists.ietf.org Subject: Re: [Ltru] Re: Language Tag Special Cases So if I understand the proposal, it is to deal with the different "special case" codes assigned by ISO 639. To paraphrase what 4646 contains (plus my interpretation of the additions): "mul" is used to identify content in multiple languages. It SHOULD NOT be used when a list of languages (such as Content-Language) can be used instead and it SHOULD NOT be used for individual content items (such as a single

element in an XHTML document). "und" is used to identify linguistic content whose language cannot be determined. It SHOULD NOT be used unless a language tag is required and the language cannot be determined. "zxx" is used to identify non-lingusitic content. It SHOULD NOT be used unless a language tag is required by some application or protocol for some non-human language content item. "mis" is used to identify linguistic content whose language is known but cannot otherwise be identified. It is commonly used when the range of language tags is constrained (for example, to ISO 639-2, as in MARC, for example) or for languages not otherwise categorized. It SHOULD NOT be used unless a language tag is required and no other means of identifying the language is available. In all cases, where permitted, omitting the language tag is preferable to using these codes. Language tags SHOULD NOT incorporate these subtags as a prefix under any circumstances. This covers all of the cases except that where the language is known and can be identified using a regular subtag. Any other cases? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 16: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 1HezuP-0003Xa-84; Fri, 20 Apr 2007 16:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezuN-0003Mm-Qy for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:40:44 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezuM-0005kd-Bx for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:40:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hezu0-00055j-Ge for ltru@lists.ietf.org; Fri, 20 Apr 2007 22:40:20 +0200 Received: from 1cust43.tnt7.hbg2.deu.da.uu.net ([149.225.100.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 22:40:20 +0200 Received: from nobody by 1cust43.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 22:40:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Apr 2007 22:37:19 +0200 Organization: Lines: 63 Message-ID: <4629247F.1DC5@xyzzy.claranet.de> References: <4628AD9E.3CFD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Seems like a rather unlikely use case. In the example below, > how would tagging the MIME text as "zxx" help this misguided > implementation? Speculation, the implementation could be designed to use some heuristics to guess the language of plain text files. Mark reported that they use a statistical approach for the identification of languages, because language tags in the wild are more often wrong than anything else. > Could it be potentially misleading to tag this content as > non-linguistic? I think the case below is "und". Depends on implementation details. It could recognize some MIME types, and look "into" the file for known types, and at some point it might decide "programming language X" (somehow http://code.google.com has to work, after all, even if they don't yet support REXX as my favourite "missing language" :-) At this point it's possible that a smart procedure says "it's REXX", and a dumb caller then decides, "okay, if it's not 'en' I use 'zxx'". We could say that this is a bug, and Addison's proposal "SHOULD NOT use 'zxx'" confirms this theory, but it can take some time until somebody fixes this plausible bug in a hypothetical application adding Content-Language tags to all inline MIME text parts, even where that's a bad idea. All we can do is say "SHOULD NOT" in 4646bis, and hope that implementors get the idea. And implementations based on 4646 or 3066 have an excuse to violate this future "SHOULD NOT", it isn't obvious. > I am specifically talking about use cases for the zxx tag > used in reference to a code snippet. That's it. RFC 3282 updates RFC 1766. Somehow RFC 4646 managed to have no reference to RFC 3282 and RFC 2277. IMHO we should fix that in 4646bis, these RFCs are really relevant. A very important example in RFC 3282 is this: | Content-type: multipart/alternative | Content-Language: da, de, el, en, fr, it Content-Language can be used with multipart/alternative, here for alternative parts in the languages da, de, el, en, fr, it. Maybe it can be also used with other multipart/* or message/* subtypes, and then the question is, do all individual MIME parts "inherit" the Content-Language, unless they specify their own Content-Language ? That would be exactly the same situation as a or a similar tag containing an element that's clearly not "en". One thing is sure, the syntax is "one or more tags" in RFC 3282, there's no xml:lang="" trick for Content-Language header fields. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 16:44: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 1Hezxi-0000OX-Ul; Fri, 20 Apr 2007 16:44:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezxh-0000OR-RE for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:44:09 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hezxh-0006NA-3i for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:44:09 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 20 Apr 2007 13:44:08 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 20 Apr 2007 13:44:08 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 20 Apr 2007 13:44:06 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceDZNpBoxmAMOOwToKNJrLKvfX+ZQAJyvHg Message-ID: References: <20070413122917.GA25431@nic.fr> <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> In-Reply-To: <30b660a20704200859l4d3d097dld9890a1fccfa5011@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: 1.2 (+) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1425578194==" Errors-To: ltru-bounces@ietf.org --===============1425578194== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F973DANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F973DANAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzYXkgeW91ciBwcm9ncmFtbWluZyBjb2RlIGV4YW1wbGUgaXMgYSBib3VuZGFyeSBjYXNlIGlu IHRoZSBzZW5zZSB0aGF0IEkgZG9u4oCZdCBleHBlY3QgdG8gc2VlIC5jeHgsIC5oLCBldGMuIGZp bGVzIHRhZ2dlZCB3aXRoIGxhbmd1YWdlIHRhZ3MgYW55IHRpbWUgc29vbiwgYW5kIEkgZG9u4oCZ dCBleHBlY3QgdG8gc2VlIGEgYm9vayBvbiBwcm9ncmFtbWluZyBjb25jZXB0cyB0YWdnZWQgYXMg YW55dGhpbmcgb3RoZXIgdGhhbiBlbiwgbm8gbWF0dGVyIGhvdyBtYW55IHBhZ2VzIG9mIHNvdXJj ZSBjb2RlIHNhbXBsZXMgaXQgaGFzLg0KDQooR3JhbnRlZCwgaW4gYW4gWE1MIHJlcHJlc2VudGF0 aW9uIG9mIHRoYXQgYm9vayB0aGVyZSBtYXkgYmUgYSBxdWVzdGlvbiBhcyB0byBob3cgaW5kaXZp ZHVhbCBlbGVtZW50cyBzaG91bGQgYmUgdGFnZ2VkLCBidXQgaXTigJlzIG5vdCBjbGVhciB0byBt ZSBpbiB0aGF0IHNjZW5hcmlvIHdoYXQgZGlmZmVyZW5jZSBpdCByZWFsbHkgbWFrZXMgd2hldGhl ciB5b3UgaGF2ZSA8Y29kZSBzYW1wbGUgeG1sOmxhbmc94oCdZW7igJ0+IG9yIDxjb2RlIHNhbXBs ZSB4bWw6bGFuZz3igJ16eHjigJ0+IG9yIDxjb2RlIHNhbXBsZSB4bWw6bGFuZz3igJ11bmTigJ0+ IG9yIDxjb2RlIHNhbXBsZSB4bWw6bGFuZz3igJ3igJ0+IG9yIHdoYXRldmVyLikNCg0KDQpQZXRl cg0KDQpGcm9tOiBtYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20gW21haWx0bzptYXJrLmVkd2Fy ZC5kYXZpc0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBNYXJrIERhdmlzDQpTZW50OiBGcmlkYXks IEFwcmlsIDIwLCAyMDA3IDg6NTkgQU0NClRvOiBQZXRlciBDb25zdGFibGUNCkNjOiBpZXRmLWxh bmd1YWdlc0BhbHZlc3RyYW5kLm5vOyBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBSZTog W0x0cnVdIFJlOiAibWlzIiB1cGRhdGUgcmV2aWV3IHJlcXVlc3QNCg0KSSBkb24ndCB0aGluayB0 aGUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgZnJhZ21lbnQgaXMgcmVhbGx5IGEgYm91bmRhcnkgY29u ZGl0aW9uLiBNb3N0IGNvZGUgc291cmNlIG5vd2FkYXlzIGFyZSBub3QganVzdCByYW5kb20gaGV4 LCB0aGVyZSB0eXBpY2FsbHksIG5vdCBleGNlcHRpb25hbGx5LCBzb21lIHJlYWwgbGluZ3Vpc3Rp YyBjb250ZW50LiBJIHdvdWxkIGFncmVlIHdpdGggeW91IHRoYXQgYSBoZXggZHVtcCBvZiBhIGNv bXBpbGVkIHByb2dyYW0sIHN1Y2ggYXMgcGVyaGFwcyB5b3UgdXNlZCBmb3IgeW91ciBleGFtcGxl LCBpcyBzZW5zaWJsZSB0byB0YWcgYXMgenh4LCBidXQgYmFzZWQgb24gdGhlIHdvcmRpbmcgb2Yg dGhlIHN0YW5kYXJkcywgSSBkb24ndCB0aGluayB3ZSBjYW4gZXhwZWN0IHp4eCB0byBhcHBseSB0 byB0eXBpY2FsIGNvZGUgc291cmNlLiBZZXQsIHdoaWxlIHRoZXJlIG1heSBiZSBpcyBzb21lIGVt YmVkZGVkIEVuZ2xpc2gsIHdlIGRvbid0IHdhbnQgdG8gY2FsbCBpdCAiZW4iIGVpdGhlci4NCg0K SXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgYmVzdCBjaG9pY2UgY3VycmVudGx5IHdvdWxkIGJlICJ1 bmQiOyBhcyBJIHNhaWQsIEkgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGhhdmUgYSBzcGVj aWFsIHRhZyBmb3IgdGhpcyBqdXN0IGJlY2F1c2UgaXQgaXMgYSByZWFzb25hYmx5IGNvbW1vbiBj YXNlIHRoYXQgaXMgb3RoZXJ3aXNlIGRpZmZpY3VsdCB0byBjYXRlZ29yaXplLiBBbiBhbHRlcm5h dGl2ZSB3b3VsZCBiZSB0byBleHBsaWNpdGx5IGJyb2FkZW4gdGhlIGRlc2NyaXB0aW9uIG9mICJ6 eHgiIHRvIGJlICJubyBsaW5ndWlzdGljIGNvbnRlbnQsIG9yIHByb2dyYW1taW5nIHNvdXJjZSBj b2RlIi4gVGhhdCB3b3VsZCBiZSBhIGNvbXBhdGlibGUgY2hhbmdlIHRvIDQ2NDZiaXMsIHNpbmNl IGl0IGlzIGEgYnJvYWRlbmluZy4NCg0KTWFyaw0KT24gNC8yMC8wNywgUGV0ZXIgQ29uc3RhYmxl IDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPG1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQoNCkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0 Lm9yZzxtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc+XQ0KDQo+IEFzIGluIGV4YW1w bGUgIzkgb2YgaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1Yzkg LA0KDQo+IHRvIHRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyBjb250YWlucyAibm8gbGluZ3Vpc3Rp YyBjb250ZW50IiBpcyBiaXphcnJlLg0KDQo+IEl0IG9idmlvdXNseSBjb250YWlucyBsaW5ndWlz dGljIGNvbnRlbnQuDQoNCmlmIChsaW5ndWlzdGljQ29udGVudCA9PSBudWxsKSB7IHRocm93IG5l dyBFeGNlcHRpb24oIiIpOyB9DQoNCg0KDQoNCllvdSBjb3VsZCBzYXkgdGhlIHNhbWUgb2YgdGhp czoNCg0KTVrCkA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgw7/DvyAgwrggICAgICAgQCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgw6ANCsKtwroNCiDCtCAgICAgICAgICAgIMONIcK4TMON IVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0KDQokICAgICAgIFRiw6/i gLoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsKBw4gNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQrCgcOIDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KwoHDiDfDhcOvw4gRDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHD iDfDhcO8w4gSDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwoHDiDfDhcO6w4gN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrCgcOIDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0K4oKsw4jDiQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCsKBw4g3w4XDrMOIMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsKBw4g3 w4XDvcOIEQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsKBw4g3w4XDucOIEQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsKBw4hSaWNoDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KwoHDiA0KDQoNCg0KV2UgY291bGQgcHJvYmFibHkgY29tZSB1 cCB3aXRoIGFsbCBraW5kcyBvZiBib3VuZGFyeSBjYXNlcyBmb3Igd2hpY2ggdGhlcmUgaXMgbm8g InJpZ2h0IiBhbnN3ZXIuIEkgZG9uJ3Qga25vdyB3aGF0IHVzZSBpdCB3b3VsZCBiZS4NCg0KUGV0 ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkx0 cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnPG1haWx0bzpMdHJ1QGlldGYub3JnPg0KaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQoNCg0KLS0NCk1hcmsN Cg== --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F973DANAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQx LUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEz LTAwQUEwMEMxNDg4MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0 IiB4bWxuczp6PSIjUm93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpwdWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9l bnZlbG9wZS8iIHhtbG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5t aWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJo dHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxL1hNTFNjaGVtYSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEtaW5zdGFuY2UiIHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2Rh dGEvdWRjL3htbGZpbGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54 bWxmb3JtYXRzLm9yZy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOmV4MTJ0PSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYvdHlwZXMi IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxt ZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBt ZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250 IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5nbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsX3F1b3RlO30NCnNwYW4ucQ0K CXttc28tc3R5bGUtbmFtZTpxO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0K LS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+SSBzYXkgeW91ciBwcm9ncmFtbWluZyBjb2RlIGV4YW1wbGUg aXMgYSBib3VuZGFyeSBjYXNlIGluIHRoZQ0Kc2Vuc2UgdGhhdCBJIGRvbuKAmXQgZXhwZWN0IHRv IHNlZSAuY3h4LCAuaCwgZXRjLiBmaWxlcyB0YWdnZWQgd2l0aCBsYW5ndWFnZSB0YWdzDQphbnkg dGltZSBzb29uLCBhbmQgSSBkb27igJl0IGV4cGVjdCB0byBzZWUgYSBib29rIG9uIHByb2dyYW1t aW5nIGNvbmNlcHRzIHRhZ2dlZA0KYXMgYW55dGhpbmcgb3RoZXIgdGhhbiBlbiwgbm8gbWF0dGVy IGhvdyBtYW55IHBhZ2VzIG9mIHNvdXJjZSBjb2RlIHNhbXBsZXMgaXQNCmhhcy4gPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4oR3JhbnRlZCwgaW4gYW4gWE1MIHJlcHJlc2VudGF0aW9u IG9mIHRoYXQgYm9vayB0aGVyZSBtYXkgYmUgYQ0KcXVlc3Rpb24gYXMgdG8gaG93IGluZGl2aWR1 YWwgZWxlbWVudHMgc2hvdWxkIGJlIHRhZ2dlZCwgYnV0IGl04oCZcyBub3QgY2xlYXIgdG8NCm1l IGluIHRoYXQgc2NlbmFyaW8gd2hhdCBkaWZmZXJlbmNlIGl0IHJlYWxseSBtYWtlcyB3aGV0aGVy IHlvdSBoYXZlICZsdDtjb2RlIHNhbXBsZQ0KeG1sOmxhbmc94oCdZW7igJ0mZ3Q7IG9yICZsdDtj b2RlIHNhbXBsZSB4bWw6bGFuZz3igJ16eHjigJ0mZ3Q7IG9yICZsdDtjb2RlIHNhbXBsZQ0KeG1s Omxhbmc94oCddW5k4oCdJmd0OyBvciAmbHQ7Y29kZSBzYW1wbGUgeG1sOmxhbmc94oCd4oCdJmd0 OyBvciB3aGF0ZXZlci4pPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4NCm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNv bSBbbWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbV0gPGI+T24gQmVoYWxmDQpPZiA8 L2I+TWFyayBEYXZpczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDIwLCAyMDA3IDg6 NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IFBldGVyIENvbnN0YWJsZTxicj4NCjxiPkNjOjwvYj4gaWV0 Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubzsgbHRydUBsaXN0cy5pZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0x0cnVdIFJlOiAmcXVvdDttaXMmcXVvdDsgdXBkYXRlIHJldmlldyBy ZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz5JIGRvbid0IHRoaW5rIHRoZSBwcm9ncmFtbWluZw0KbGFuZ3Vh Z2UgZnJhZ21lbnQgaXMgcmVhbGx5IGEgYm91bmRhcnkgY29uZGl0aW9uLiBNb3N0IGNvZGUgc291 cmNlIG5vd2FkYXlzIGFyZQ0Kbm90IGp1c3QgcmFuZG9tIGhleCwgdGhlcmUgdHlwaWNhbGx5LCBu b3QgZXhjZXB0aW9uYWxseSwgc29tZSByZWFsIGxpbmd1aXN0aWMNCmNvbnRlbnQuIEkgd291bGQg YWdyZWUgd2l0aCB5b3UgdGhhdCBhIGhleCBkdW1wIG9mIGEgPGk+Y29tcGlsZWQ8L2k+IHByb2dy YW0sDQpzdWNoIGFzIHBlcmhhcHMgeW91IHVzZWQgZm9yIHlvdXIgZXhhbXBsZSwgaXMgc2Vuc2li bGUgdG8gdGFnIGFzIHp4eCwgYnV0IGJhc2VkDQpvbiB0aGUgd29yZGluZyBvZiB0aGUgc3RhbmRh cmRzLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBleHBlY3Qgenh4IHRvIGFwcGx5IHRvIHR5cGljYWwN CmNvZGUgc291cmNlLiBZZXQsIHdoaWxlIHRoZXJlIG1heSBiZSBpcyBzb21lIGVtYmVkZGVkIEVu Z2xpc2gsIHdlIGRvbid0IHdhbnQgdG8NCmNhbGwgaXQgJnF1b3Q7ZW4mcXVvdDsgZWl0aGVyLiA8 YnI+DQo8YnI+DQpJdCBsb29rcyB0byBtZSBsaWtlIHRoZSBiZXN0IGNob2ljZSA8aT5jdXJyZW50 bHkgPC9pPndvdWxkIGJlICZxdW90O3VuZCZxdW90OzsNCmFzIEkgc2FpZCwgSSB0aGluayBpdCBt aWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBhIHNwZWNpYWwgdGFnIGZvciB0aGlzIGp1c3QNCmJlY2F1 c2UgaXQgaXMgYSByZWFzb25hYmx5IGNvbW1vbiBjYXNlIHRoYXQgaXMgb3RoZXJ3aXNlIGRpZmZp Y3VsdCB0bw0KY2F0ZWdvcml6ZS4gQW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gPGk+ZXhwbGlj aXRseSA8L2k+YnJvYWRlbiB0aGUNCmRlc2NyaXB0aW9uIG9mICZxdW90O3p4eCZxdW90OyB0byBi ZSAmcXVvdDtubyBsaW5ndWlzdGljIGNvbnRlbnQsIG9yDQpwcm9ncmFtbWluZyBzb3VyY2UgY29k ZSZxdW90Oy4gVGhhdCB3b3VsZCBiZSBhIGNvbXBhdGlibGUgY2hhbmdlIHRvIDQ2NDZiaXMsDQpz aW5jZSBpdCBpcyBhIGJyb2FkZW5pbmcuIDxicj4NCjxicj4NCk1hcms8bzpwPjwvbzpwPjwvcD4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWdtYWlscXVvdGU+T24g NC8yMC8wNywgPGI+UGV0ZXIgQ29uc3RhYmxlPC9iPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRl cmNvbkBtaWNyb3NvZnQuY29tIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZndDsNCndyb3Rl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47DQpib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVz ZS10ZXh0LWNvbG9yJz4NCg0KPHAgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+IE1hcmsgRGF2aXMgW21haWx0bzo8YQ0KaHJlZj0ibWFpbHRvOm1h cmsuZGF2aXNAaWN1LXByb2plY3Qub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFyay5kYXZpc0BpY3Ut cHJvamVjdC5vcmc8L2E+XQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj48L2I+QXMg aW4NCmV4YW1wbGUgIzkgb2YgPGEgaHJlZj0iaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9 ZGZxcjhyZDVfMTFnNDI1YzkiDQp0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RvY3MuZ29vZ2xlLmNv bS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1YzkgPC9hPiwgPG86cD48L286cD48L3A+DQoNCjxwPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPnRv IHRoaW5rIHRoYXQgdGhlDQpmb2xsb3dpbmcgY29udGFpbnMgJnF1b3Q7bm8gbGluZ3Vpc3RpYyBj b250ZW50JnF1b3Q7IGlzIGJpemFycmUuIDxvOnA+PC9vOnA+PC9wPg0KDQo8cD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5JdCBvYnZpb3Vz bHkNCmNvbnRhaW5zIGxpbmd1aXN0aWMgY29udGVudC48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MSBjZWxsc3BhY2luZz0wIGNl bGxwYWRkaW5nPTA+DQogPHRyPg0KICA8dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzoxLjk1 cHQgMS45NXB0IDEuOTVwdCAxLjk1cHQnPg0KICA8cD5pZiAobGluZ3Vpc3RpY0NvbnRlbnQgPT0g bnVsbCkgeyB0aHJvdyBuZXcgRXhjZXB0aW9uKCZxdW90OyZxdW90Oyk7IH08bzpwPjwvbzpwPjwv cD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPHAgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5Zb3UN CmNvdWxkIHNheSB0aGUgc2FtZSBvZiB0aGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEJz5NWsKQDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qn Pg0KDQo8aHIgc2l6ZT0xIHdpZHRoPSIzMyUiIGFsaWduPWxlZnQ+DQoNCjwvc3Bhbj48L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qn Pg0KDQo8aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1sZWZ0Pg0KDQo8L3NwYW4+PC9kaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEJz4mbmJzcDsmbmJzcDsNCsO/w78mbmJzcDsgwrgmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCkAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCsOg Jm5ic3A7Jm5ic3A7IDxiciBjbGVhcj1hbGw+DQrCrcK6PGJyIGNsZWFyPWFsbD4NCiZuYnNwO8K0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQrDjSHCuEzDjSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9k ZS48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+JCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVGLDr+KAuiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QnPg0KDQo8aHIgc2l6ZT0xIHdpZHRoPSIzMyUiIGFsaWduPWxlZnQ+DQoN Cjwvc3Bhbj48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPsKBw4ggPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 ZGl2IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEJz4NCg0KPGhyIHNpemU9MSB3aWR0aD0iMzMlIiBhbGlnbj1sZWZ0Pg0KDQo8L3NwYW4+ PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEJz7CgcOIIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+ DQoNCjxociBzaXplPTEgd2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCc+woHDiDfDhcOvw4gRIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+ DQoNCjxociBzaXplPTEgd2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCc+woHDiDfDhcO8w4gSIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+ DQoNCjxociBzaXplPTEgd2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCc+woHDiDfDhcO6w4g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPg0K DQo8aHIgc2l6ZT0xIHdpZHRoPSIzMyUiIGFsaWduPWxlZnQ+DQoNCjwvc3Bhbj48L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QnPsKBw4ggPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4NCg0KPGhyIHNp emU9MSB3aWR0aD0iMzMlIiBhbGlnbj1sZWZ0Pg0KDQo8L3NwYW4+PC9kaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz7i gqzDiMOJIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+DQoNCjxociBzaXplPTEg d2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+woHDiDfD hcOsw4gzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+DQoNCjxociBzaXplPTEg d2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+woHDiDfD hcO9w4gRIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+DQoNCjxociBzaXplPTEg d2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+woHDiDfD hcO5w4gRIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+DQoNCjxociBzaXplPTEg d2lkdGg9IjMzJSIgYWxpZ249bGVmdD4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+woHDiFJp Y2ggPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4NCg0KPGhyIHNpemU9MSB3aWR0 aD0iMzMlIiBhbGlnbj1sZWZ0Pg0KDQo8L3NwYW4+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz7CgcOIJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPldlDQpjb3VsZCBw cm9iYWJseSBjb21lIHVwIHdpdGggYWxsIGtpbmRzIG9mIGJvdW5kYXJ5IGNhc2VzIGZvciB3aGlj aCB0aGVyZSBpcyBubw0KJnF1b3Q7cmlnaHQmcXVvdDsgYW5zd2VyLiBJIGRvbid0IGtub3cgd2hh dCB1c2UgaXQgd291bGQgYmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QnPlBldGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTHRydSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydTwvYT48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48YnI+DQo8YnIgY2xlYXI9YWxsPg0KPGJyPg0KLS0gPGJyPg0KTWFyayA8bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F973DANAEXMSGC117re_-- --===============1425578194== 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 --===============1425578194==-- From ltru-bounces@ietf.org Fri Apr 20 16:53: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 1Hf06L-0004UH-3T; Fri, 20 Apr 2007 16:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf06I-0004G8-2c for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:53:02 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf06G-0000XD-EL for ltru@lists.ietf.org; Fri, 20 Apr 2007 16:53:02 -0400 Received: by wr-out-0506.google.com with SMTP id 76so1039755wra for ; Fri, 20 Apr 2007 13:53:00 -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=mEgWKwLss+HONKfyPHOTXcMVJL6QrN/3aeKdEDwEXk7PSjxSIXkTLlzrCANcRU5u+KYN1kPB09j540vGFN5jw8ZM1Dlo6aYHVMewNGSDu00wXj9kpt2QA69IrAcbVImL5p69PvKGJjvYNIS7rSWToJ8uUdl12/cInm1dRcxLcDI= 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=gkpYWkfowY2/TKlgNOYdzFiycKld//7HJD5KSyJRn7gbREF4NVAlA6ehzcU+NJA0HGUlIfJrHMJRQDNEMby1UVzWRr9zvexvYt4FroDdz1qGOKXJUt7KGw9Nb2WQpNelooWLH/l7/a3VhC5VhjfRV2AeTQnjfx8HsQgPCae+HN8= Received: by 10.114.152.17 with SMTP id z17mr1418994wad.1177102379473; Fri, 20 Apr 2007 13:52:59 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 13:52:59 -0700 (PDT) Message-ID: <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> Date: Fri, 20 Apr 2007 13:52:59 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> X-Google-Sender-Auth: 06ee5a1878abbc8c X-Spam-Score: 0.3 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0997234161==" Errors-To: ltru-bounces@ietf.org --===============0997234161== Content-Type: multipart/alternative; boundary="----=_Part_152993_19551685.1177102379189" ------=_Part_152993_19551685.1177102379189 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline PiBJIGRvbid0IGV4cGVjdCB0byBzZWUgLmN4eCwgLmgsIGV0Yy4gZmlsZXMgdGFnZ2VkIHdpdGgg bGFuZ3VhZ2UgdGFncyBhbnkKdGltZSBzb29uCgpXZWxsLCBldmVyeSBmaWxlIGF2YWlsYWJsZSBv biB0aGUgd2ViLCBsaWtlCmh0dHA6Ly93d3cuY3MuZHVrZS5lZHUvY3NlZC90YXBlc3RyeS93aW4v ZGF0ZS5oIChjaG9zZW4gYXQgcmFuZG9tKSBnZXRzIHNvbWUKbGFuZ3VhZ2UgdGFnIHdoZW4gcHJv Y2Vzc2VkIGF0IEdvb2dsZSAoSSBjYW4ndCBzYXkgd2hhdCBNU04sIFlhaG9vLCBhbmQKb3RoZXIg c2VhcmNoIGVuZ2luZXMgZG8pLiBTbyByaWdodCB1bmRlciB5b3VyIG5vc2UgbWlsbGlvbnMgb2Yg cGFnZXMgb2YKc291cmNlIGNvZGUgYXJlIGdldHRpbmcgdGFnZ2VkLCBhbGwgdGhlIHRpbWUuIFdl IGFyZSBmYWNlZCB3aXRoIHRoZQpwcmFjdGljYWwgcHJvYmxlbSBvZiB3aGF0IHRoZSBiZXN0IHRo aW5nIHRvIGRvIGlzIGFjY29yZGluZyB0byB0aGUgc3RhbmRhcmQuCgpNYXJrCgpPbiA0LzIwLzA3 LCBQZXRlciBDb25zdGFibGUgPHBldGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gIEkg c2F5IHlvdXIgcHJvZ3JhbW1pbmcgY29kZSBleGFtcGxlIGlzIGEgYm91bmRhcnkgY2FzZSBpbiB0 aGUgc2Vuc2UgdGhhdAo+IEkgZG9uJ3QgZXhwZWN0IHRvIHNlZSAuY3h4LCAuaCwgZXRjLiBmaWxl cyB0YWdnZWQgd2l0aCBsYW5ndWFnZSB0YWdzIGFueQo+IHRpbWUgc29vbiwgYW5kIEkgZG9uJ3Qg ZXhwZWN0IHRvIHNlZSBhIGJvb2sgb24gcHJvZ3JhbW1pbmcgY29uY2VwdHMgdGFnZ2VkCj4gYXMg YW55dGhpbmcgb3RoZXIgdGhhbiBlbiwgbm8gbWF0dGVyIGhvdyBtYW55IHBhZ2VzIG9mIHNvdXJj ZSBjb2RlIHNhbXBsZXMKPiBpdCBoYXMuCj4KPgo+Cj4gKEdyYW50ZWQsIGluIGFuIFhNTCByZXBy ZXNlbnRhdGlvbiBvZiB0aGF0IGJvb2sgdGhlcmUgbWF5IGJlIGEgcXVlc3Rpb24gYXMKPiB0byBo b3cgaW5kaXZpZHVhbCBlbGVtZW50cyBzaG91bGQgYmUgdGFnZ2VkLCBidXQgaXQncyBub3QgY2xl YXIgdG8gbWUgaW4KPiB0aGF0IHNjZW5hcmlvIHdoYXQgZGlmZmVyZW5jZSBpdCByZWFsbHkgbWFr ZXMgd2hldGhlciB5b3UgaGF2ZSA8Y29kZSBzYW1wbGUKPiB4bWw6bGFuZz0iZW4iPiBvciA8Y29k ZSBzYW1wbGUgeG1sOmxhbmc9Inp4eCI+IG9yIDxjb2RlIHNhbXBsZQo+IHhtbDpsYW5nPSJ1bmQi PiBvciA8Y29kZSBzYW1wbGUgeG1sOmxhbmc9IiI+IG9yIHdoYXRldmVyLikKPgo+Cj4KPgo+Cj4g UGV0ZXIKPgo+Cj4KPiAqRnJvbToqIG1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSBbbWFpbHRv Om1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbV0gKk9uCj4gQmVoYWxmIE9mICpNYXJrIERhdmlz Cj4gKlNlbnQ6KiBGcmlkYXksIEFwcmlsIDIwLCAyMDA3IDg6NTkgQU0KPiAqVG86KiBQZXRlciBD b25zdGFibGUKPiAqQ2M6KiBpZXRmLWxhbmd1YWdlc0BhbHZlc3RyYW5kLm5vOyBsdHJ1QGxpc3Rz LmlldGYub3JnCj4gKlN1YmplY3Q6KiBSZTogW0x0cnVdIFJlOiAibWlzIiB1cGRhdGUgcmV2aWV3 IHJlcXVlc3QKPgo+Cj4KPiBJIGRvbid0IHRoaW5rIHRoZSBwcm9ncmFtbWluZyBsYW5ndWFnZSBm cmFnbWVudCBpcyByZWFsbHkgYSBib3VuZGFyeQo+IGNvbmRpdGlvbi4gTW9zdCBjb2RlIHNvdXJj ZSBub3dhZGF5cyBhcmUgbm90IGp1c3QgcmFuZG9tIGhleCwgdGhlcmUKPiB0eXBpY2FsbHksIG5v dCBleGNlcHRpb25hbGx5LCBzb21lIHJlYWwgbGluZ3Vpc3RpYyBjb250ZW50LiBJIHdvdWxkIGFn cmVlCj4gd2l0aCB5b3UgdGhhdCBhIGhleCBkdW1wIG9mIGEgKmNvbXBpbGVkKiBwcm9ncmFtLCBz dWNoIGFzIHBlcmhhcHMgeW91IHVzZWQKPiBmb3IgeW91ciBleGFtcGxlLCBpcyBzZW5zaWJsZSB0 byB0YWcgYXMgenh4LCBidXQgYmFzZWQgb24gdGhlIHdvcmRpbmcgb2YgdGhlCj4gc3RhbmRhcmRz LCBJIGRvbid0IHRoaW5rIHdlIGNhbiBleHBlY3Qgenh4IHRvIGFwcGx5IHRvIHR5cGljYWwgY29k ZSBzb3VyY2UuCj4gWWV0LCB3aGlsZSB0aGVyZSBtYXkgYmUgaXMgc29tZSBlbWJlZGRlZCBFbmds aXNoLCB3ZSBkb24ndCB3YW50IHRvIGNhbGwgaXQKPiAiZW4iIGVpdGhlci4KPgo+IEl0IGxvb2tz IHRvIG1lIGxpa2UgdGhlIGJlc3QgY2hvaWNlICpjdXJyZW50bHkgKndvdWxkIGJlICJ1bmQiOyBh cyBJIHNhaWQsCj4gSSB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBhIHNwZWNpYWwg dGFnIGZvciB0aGlzIGp1c3QgYmVjYXVzZSBpdCBpcwo+IGEgcmVhc29uYWJseSBjb21tb24gY2Fz ZSB0aGF0IGlzIG90aGVyd2lzZSBkaWZmaWN1bHQgdG8gY2F0ZWdvcml6ZS4gQW4KPiBhbHRlcm5h dGl2ZSB3b3VsZCBiZSB0byAqZXhwbGljaXRseSAqYnJvYWRlbiB0aGUgZGVzY3JpcHRpb24gb2Yg Inp4eCIgdG8KPiBiZSAibm8gbGluZ3Vpc3RpYyBjb250ZW50LCBvciBwcm9ncmFtbWluZyBzb3Vy Y2UgY29kZSIuIFRoYXQgd291bGQgYmUgYQo+IGNvbXBhdGlibGUgY2hhbmdlIHRvIDQ2NDZiaXMs IHNpbmNlIGl0IGlzIGEgYnJvYWRlbmluZy4KPgo+IE1hcmsKPgo+IE9uIDQvMjAvMDcsICpQZXRl ciBDb25zdGFibGUqIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToKPgo+ICpGcm9tOiog TWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQo+Cj4gKj4gKkFz IGluIGV4YW1wbGUgIzkgb2YgaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhyZDVf MTFnNDI1YzkgLAo+Cj4gPiB0byB0aGluayB0aGF0IHRoZSBmb2xsb3dpbmcgY29udGFpbnMgIm5v IGxpbmd1aXN0aWMgY29udGVudCIgaXMgYml6YXJyZS4KPgo+Cj4gPiBJdCBvYnZpb3VzbHkgY29u dGFpbnMgbGluZ3Vpc3RpYyBjb250ZW50Lgo+Cj4gaWYgKGxpbmd1aXN0aWNDb250ZW50ID09IG51 bGwpIHsgdGhyb3cgbmV3IEV4Y2VwdGlvbigiIik7IH0KPgo+Cj4KPiBZb3UgY291bGQgc2F5IHRo ZSBzYW1lIG9mIHRoaXM6Cj4KPiBNWsKQCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiAgICDDv8O/ICDCuCAg ICAgICBAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDDoAo+IMKtwroKPiAgwrQg ICAgICAgICAgICDDjSHCuEzDjSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9k ZS4KPgo+ICQgICAgICAgVGLDr+KAugo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pgo+IMKBw4gKPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiDCgcOICj4gIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gwoHDiDfDhcOvw4gRCj4gIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gwoHDiDfDhcO8w4gSCj4gIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQo+Cj4gwoHDiDfDhcO6w4gKPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4KPiDCgcOICj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4g 4oKsw4jDiQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IMKBw4g3w4XDrMOI Mwo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IMKBw4g3w4XDvcOIEQo+ICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IMKBw4g3w4XDucOIEQo+ICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IMKBw4hSaWNoCj4gIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+Cj4gwoHDiAo+Cj4KPgo+IFdlIGNvdWxkIHByb2JhYmx5IGNvbWUgdXAg d2l0aCBhbGwga2luZHMgb2YgYm91bmRhcnkgY2FzZXMgZm9yIHdoaWNoIHRoZXJlCj4gaXMgbm8g InJpZ2h0IiBhbnN3ZXIuIEkgZG9uJ3Qga25vdyB3aGF0IHVzZSBpdCB3b3VsZCBiZS4KPgo+IFBl dGVyCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cj4KPgo+Cj4gLS0KPiBNYXJrCj4KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBs aXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2x0cnUKPgo+CgoKLS0gCk1hcmsK ------=_Part_152993_19551685.1177102379189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PHNwYW4+Jmd0OyBJIGRvbid0IGV4cGVjdCB0byBzZWUgLmN4eCwgLmgsIGV0Yy4gZmlsZXMgdGFn Z2VkIHdpdGggbGFuZ3VhZ2UgdGFncyBhbnkgdGltZSBzb29uPGJyPjxicj5XZWxsLCBldmVyeSBm aWxlIGF2YWlsYWJsZSBvbiB0aGUgd2ViLCBsaWtlIDxhIGhyZWY9Imh0dHA6Ly93d3cuY3MuZHVr ZS5lZHUvY3NlZC90YXBlc3RyeS93aW4vZGF0ZS5oIj5odHRwOi8vd3d3LmNzLmR1a2UuZWR1L2Nz ZWQvdGFwZXN0cnkvd2luL2RhdGUuaAo8L2E+IChjaG9zZW4gYXQgcmFuZG9tKSBnZXRzIHNvbWUg bGFuZ3VhZ2UgdGFnIHdoZW4gcHJvY2Vzc2VkIGF0IEdvb2dsZSAoSSBjYW4mIzM5O3Qgc2F5IHdo YXQgTVNOLCBZYWhvbywgYW5kIG90aGVyIHNlYXJjaCBlbmdpbmVzIGRvKS4gU28gcmlnaHQgdW5k ZXIgeW91ciBub3NlIG1pbGxpb25zIG9mIHBhZ2VzIG9mIHNvdXJjZSBjb2RlIGFyZSBnZXR0aW5n IHRhZ2dlZCwgYWxsIHRoZSB0aW1lLiBXZSBhcmUgZmFjZWQgd2l0aCB0aGUgcHJhY3RpY2FsIHBy b2JsZW0gb2Ygd2hhdCB0aGUgYmVzdCB0aGluZyB0byBkbyBpcyBhY2NvcmRpbmcgdG8gdGhlIHN0 YW5kYXJkLgo8YnI+PGJyPk1hcms8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PC9zcGFuPjxicj48ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gNC8yMC8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBl dGVyIENvbnN0YWJsZTwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQu Y29tIj4KcGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4KCgoKCgoKCgoKCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0i RU4tVVMiPgoKPGRpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+SSBzYXkgeW91ciBwcm9ncmFtbWluZyBjb2RlIGV4YW1wbGUgaXMg YSBib3VuZGFyeSBjYXNlIGluIHRoZQpzZW5zZSB0aGF0IEkgZG9uJ3QgZXhwZWN0IHRvIHNlZSAu Y3h4LCAuaCwgZXRjLiBmaWxlcyB0YWdnZWQgd2l0aCBsYW5ndWFnZSB0YWdzCmFueSB0aW1lIHNv b24sIGFuZCBJIGRvbid0IGV4cGVjdCB0byBzZWUgYSBib29rIG9uIHByb2dyYW1taW5nIGNvbmNl cHRzIHRhZ2dlZAphcyBhbnl0aGluZyBvdGhlciB0aGFuIGVuLCBubyBtYXR0ZXIgaG93IG1hbnkg cGFnZXMgb2Ygc291cmNlIGNvZGUgc2FtcGxlcyBpdApoYXMuIDwvc3Bhbj48L3A+Cgo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNw Ozwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPihHcmFudGVkLCBpbiBhbiBYTUwgcmVwcmVzZW50YXRpb24gb2YgdGhh dCBib29rIHRoZXJlIG1heSBiZSBhCnF1ZXN0aW9uIGFzIHRvIGhvdyBpbmRpdmlkdWFsIGVsZW1l bnRzIHNob3VsZCBiZSB0YWdnZWQsIGJ1dCBpdCdzIG5vdCBjbGVhciB0bwptZSBpbiB0aGF0IHNj ZW5hcmlvIHdoYXQgZGlmZmVyZW5jZSBpdCByZWFsbHkgbWFrZXMgd2hldGhlciB5b3UgaGF2ZSAm bHQ7Y29kZSBzYW1wbGUKeG1sOmxhbmc9ImVuIiZndDsgb3IgJmx0O2NvZGUgc2FtcGxlIHhtbDps YW5nPSJ6eHgiJmd0OyBvciAmbHQ7Y29kZSBzYW1wbGUKeG1sOmxhbmc9InVuZCImZ3Q7IG9yICZs dDtjb2RlIHNhbXBsZSB4bWw6bGFuZz0iIiZndDsgb3Igd2hhdGV2ZXIuKTwvc3Bhbj48L3A+Cgo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlBldGVyPC9zcGFuPjwv cD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQg bm9uZSBub25lOyBib3JkZXItY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKSAtbW96LXVzZS10ZXh0 LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3I7IGJvcmRlci13aWR0aDogMXB0IG1lZGl1bSBtZWRp dW07IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+Cgo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij4K PGEgaHJlZj0ibWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5tYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KbWFyay5lZHdhcmQu ZGF2aXNAZ21haWwuY29tPC9hPl0gPGI+T24gQmVoYWxmCk9mIDwvYj5NYXJrIERhdmlzPGJyPgo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyMCwgMjAwNyA4OjU5IEFNPGJyPgo8Yj5Ubzo8L2I+ IFBldGVyIENvbnN0YWJsZTxicj4KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWV0Zi1sYW5n dWFnZXNAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5pZXRmLWxhbmd1YWdlc0BhbHZlc3Ry YW5kLm5vPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmx0cnVAbGlzdHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSI+Cmx0cnVAbGlzdHMuaWV0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtM dHJ1XSBSZTogJnF1b3Q7bWlzJnF1b3Q7IHVwZGF0ZSByZXZpZXcgcmVxdWVzdDwvc3Bhbj48L3A+ Cgo8L2Rpdj4KCjxwPiZuYnNwOzwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+ SSBkb24mIzM5O3QgdGhpbmsgdGhlIHByb2dyYW1taW5nCmxhbmd1YWdlIGZyYWdtZW50IGlzIHJl YWxseSBhIGJvdW5kYXJ5IGNvbmRpdGlvbi4gTW9zdCBjb2RlIHNvdXJjZSBub3dhZGF5cyBhcmUK bm90IGp1c3QgcmFuZG9tIGhleCwgdGhlcmUgdHlwaWNhbGx5LCBub3QgZXhjZXB0aW9uYWxseSwg c29tZSByZWFsIGxpbmd1aXN0aWMKY29udGVudC4gSSB3b3VsZCBhZ3JlZSB3aXRoIHlvdSB0aGF0 IGEgaGV4IGR1bXAgb2YgYSA8aT5jb21waWxlZDwvaT4gcHJvZ3JhbSwKc3VjaCBhcyBwZXJoYXBz IHlvdSB1c2VkIGZvciB5b3VyIGV4YW1wbGUsIGlzIHNlbnNpYmxlIHRvIHRhZyBhcyB6eHgsIGJ1 dCBiYXNlZApvbiB0aGUgd29yZGluZyBvZiB0aGUgc3RhbmRhcmRzLCBJIGRvbiYjMzk7dCB0aGlu ayB3ZSBjYW4gZXhwZWN0IHp4eCB0byBhcHBseSB0byB0eXBpY2FsCmNvZGUgc291cmNlLiBZZXQs IHdoaWxlIHRoZXJlIG1heSBiZSBpcyBzb21lIGVtYmVkZGVkIEVuZ2xpc2gsIHdlIGRvbiYjMzk7 dCB3YW50IHRvCmNhbGwgaXQgJnF1b3Q7ZW4mcXVvdDsgZWl0aGVyLiA8YnI+Cjxicj4KSXQgbG9v a3MgdG8gbWUgbGlrZSB0aGUgYmVzdCBjaG9pY2UgPGk+Y3VycmVudGx5IDwvaT53b3VsZCBiZSAm cXVvdDt1bmQmcXVvdDs7CmFzIEkgc2FpZCwgSSB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgdG8g aGF2ZSBhIHNwZWNpYWwgdGFnIGZvciB0aGlzIGp1c3QKYmVjYXVzZSBpdCBpcyBhIHJlYXNvbmFi bHkgY29tbW9uIGNhc2UgdGhhdCBpcyBvdGhlcndpc2UgZGlmZmljdWx0IHRvCmNhdGVnb3JpemUu IEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIDxpPmV4cGxpY2l0bHkgPC9pPmJyb2FkZW4gdGhl CmRlc2NyaXB0aW9uIG9mICZxdW90O3p4eCZxdW90OyB0byBiZSAmcXVvdDtubyBsaW5ndWlzdGlj IGNvbnRlbnQsIG9yCnByb2dyYW1taW5nIHNvdXJjZSBjb2RlJnF1b3Q7LiBUaGF0IHdvdWxkIGJl IGEgY29tcGF0aWJsZSBjaGFuZ2UgdG8gNDY0NmJpcywKc2luY2UgaXQgaXMgYSBicm9hZGVuaW5n LiA8YnI+Cjxicj4KTWFyazwvcD4KCjxkaXY+Cgo8cD48c3Bhbj5PbiA0LzIwLzA3LCA8Yj5QZXRl ciBDb25zdGFibGU8L2I+CiZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZndDsKd3JvdGU6PC9z cGFuPjwvcD4KCjxkaXY+Cgo8ZGl2PgoKPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBu b25lIG5vbmU7IGJvcmRlci1jb2xvcjogLW1vei11c2UtdGV4dC1jb2xvcjsgYm9yZGVyLXdpZHRo OiAxcHQgbWVkaXVtIG1lZGl1bTsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4KCjxwIHN0eWxlPSJt YXJnaW4tYm90dG9tOiAxMnB0OyI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+IE1hcmsgRGF2aXMg W21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+Cm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPC9hPl0KPC9zcGFuPjwvcD4KCjxw PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+Jmd0OyA8L3NwYW4+PC9iPkFzIGluCmV4YW1wbGUgIzkgb2YgPGEgaHJlZj0iaHR0cDovL2Rv Y3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1YzkiIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0 cDovL2RvY3MuZ29vZ2xlLmNvbS9Eb2M/aWQ9ZGZxcjhyZDVfMTFnNDI1YzkgPC9hPiwgPC9wPgoK PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij4mZ3Q7IDwvc3Bhbj50byB0aGluayB0aGF0IHRoZQpmb2xsb3dpbmcgY29udGFpbnMgJnF1b3Q7 bm8gbGluZ3Vpc3RpYyBjb250ZW50JnF1b3Q7IGlzIGJpemFycmUuIDwvcD4KCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jmd0OyA8L3Nw YW4+SXQgb2J2aW91c2x5CmNvbnRhaW5zIGxpbmd1aXN0aWMgY29udGVudC48L3A+Cgo8L2Rpdj4K Cjx0YWJsZSBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+CiA8dGJv ZHk+PHRyPgogIDx0ZCBzdHlsZT0icGFkZGluZzogMS45NXB0OyIgdmFsaWduPSJ0b3AiPgogIDxw PmlmIChsaW5ndWlzdGljQ29udGVudCA9PSBudWxsKSB7IHRocm93IG5ldyBFeGNlcHRpb24oJnF1 b3Q7JnF1b3Q7KTsgfTwvcD4KICA8L3RkPgogPC90cj4KPC90Ym9keT48L3RhYmxlPgoKPHAgc3R5 bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij4mbmJzcDs8L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJv dHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+WW91CmNvdWxkIHNheSB0aGUgc2FtZSBvZiB0aGlzOjwvc3Bhbj48L3A+Cgo8 cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+TVrCkAo8L3NwYW4+PC9wPgoKPGRpdj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPgoKPGhy IGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCjwvc3Bhbj48L2Rpdj4KCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3A+Cgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Cgo8aHIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdp ZHRoPSIxMDAlIj4KCjwvc3Bhbj48L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7Jm5ic3A7CsO/w78mbmJzcDsgwrgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKQCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOwrDoCZuYnNwOyZuYnNwOyA8YnIgY2xlYXI9ImFsbCI+CsKtwro8YnIgY2xl YXI9ImFsbCI+CiZuYnNwO8K0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CsONIcK4TMONIVRoaXMgcHJvZ3JhbSBjYW5ub3Qg YmUgcnVuIGluIERPUyBtb2RlLjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTog MTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+JCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwpUYsOv4oC6IDwvc3Bh bj48L3A+Cgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+Cgo8aHIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdpZHRoPSIzMyUiPgoKPC9z cGFuPjwvZGl2PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij7CgcOIIDwvc3Bhbj48L3A+Cgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Cgo8aHIgYWxpZ249ImxlZnQiIHNp emU9IjEiIHdpZHRoPSIzMyUiPgoKPC9zcGFuPjwvZGl2PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij7CgcOIIDwvc3Bhbj48L3A+Cgo8 ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+Cgo8aHIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdpZHRoPSIzMyUiPgoKPC9zcGFuPjwvZGl2 PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7Ij7CgcOIN8OFw6/DiBEgPC9zcGFuPjwvcD4KCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4KCjxociBhbGlnbj0ibGVmdCIgc2l6 ZT0iMSIgd2lkdGg9IjMzJSI+Cgo8L3NwYW4+PC9kaXY+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPsKBw4g3w4XDvMOIEiA8L3NwYW4+ PC9wPgoKPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPgoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCjwvc3Bh bj48L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+woHDiDfDhcO6w4g8L3NwYW4+PC9wPgoKPGRpdj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPgoKPGhyIGFsaWduPSJsZWZ0 IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCjwvc3Bhbj48L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+woHDiCA8L3NwYW4+PC9w PgoKPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPgoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4KCjwvc3Bhbj48 L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+4oKsw4jDiSA8L3NwYW4+PC9wPgoKPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPgoKPGhyIGFsaWduPSJsZWZ0IiBzaXpl PSIxIiB3aWR0aD0iMzMlIj4KCjwvc3Bhbj48L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+woHDiDfDhcOsw4gzIDwvc3Bhbj48 L3A+Cgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+Cgo8aHIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdpZHRoPSIzMyUiPgoKPC9zcGFu PjwvZGl2PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij7CgcOIN8OFw73DiBEgPC9zcGFuPjwvcD4KCjxkaXY+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4KCjxociBhbGlnbj0ibGVm dCIgc2l6ZT0iMSIgd2lkdGg9IjMzJSI+Cgo8L3NwYW4+PC9kaXY+Cgo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPsKBw4g3w4XDucOIESA8 L3NwYW4+PC9wPgoKPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPgoKPGhyIGFsaWduPSJsZWZ0IiBzaXplPSIxIiB3aWR0aD0iMzMlIj4K Cjwvc3Bhbj48L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+woHDiFJpY2ggPC9zcGFuPjwvcD4KCjxkaXY+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4KCjxociBhbGlnbj0i bGVmdCIgc2l6ZT0iMSIgd2lkdGg9IjMzJSI+Cgo8L3NwYW4+PC9kaXY+Cgo8cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPsKBw4gmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3Nw YW4+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPldlCmNvdWxkIHByb2JhYmx5 IGNvbWUgdXAgd2l0aCBhbGwga2luZHMgb2YgYm91bmRhcnkgY2FzZXMgZm9yIHdoaWNoIHRoZXJl IGlzIG5vCiZxdW90O3JpZ2h0JnF1b3Q7IGFuc3dlci4gSSBkb24mIzM5O3Qga25vdyB3aGF0IHVz ZSBpdCB3b3VsZCBiZS48L3NwYW4+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PlBldGVyPC9zcGFuPjwvcD4KCjwvZGl2PgoKPC9kaXY+PHNwYW4gY2xhc3M9InEiPgoKPHAgc3R5 bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPgpMdHJ1IG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0i bWFpbHRvOkx0cnVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+THRydUBpZXRmLm9yZzwvYT48YnI+ CjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwv YT48L3A+Cgo8L3NwYW4+PC9kaXY+Cgo8cD48YnI+CjxiciBjbGVhcj0iYWxsIj4KPGJyPgotLSA8 YnI+Ck1hcmsgPC9wPgoKPC9kaXY+Cgo8L2Rpdj4KCgo8YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3Q8YnI+PGEgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9 Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPgpo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxicj48YnI+PC9i bG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_152993_19551685.1177102379189-- --===============0997234161== 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 --===============0997234161==-- From ltru-bounces@ietf.org Fri Apr 20 17:57: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 1Hf16u-000608-89; Fri, 20 Apr 2007 17:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf16s-000602-Su for ltru@lists.ietf.org; Fri, 20 Apr 2007 17:57:42 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf16r-0004yG-Fz for ltru@lists.ietf.org; Fri, 20 Apr 2007 17:57:42 -0400 Received: from [10.72.77.36] (snvvpn2-10-72-77-c36.corp.yahoo.com [10.72.77.36]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3KLvVvj028721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 14:57:35 -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=mjmTJ7VOnfniFk8YRb6nyAcUOYDODTn5pSLKrCI/le74/pUc5WeCa5T5bNhmiBYR Message-ID: <46293749.5060208@yahoo-inc.com> Date: Fri, 20 Apr 2007 22:57:29 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Language Tag Special Cases References: <4628AD9E.3CFD@xyzzy.claranet.de> <4629247F.1DC5@xyzzy.claranet.de> In-Reply-To: <4629247F.1DC5@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > > Speculation, the implementation could be designed to use some > heuristics to guess the language of plain text files. (laughing) This is, in practice, the case for most Web content today: even when language tags are right, heuristics are still generally used to determine the language. > > Mark reported that they use a statistical approach for the > identification of languages, because language tags in the wild > are more often wrong than anything else. The more direct problem is that language tags tend to be rare. When >80% of your data has to be scanned heuristically for language and a significant proportion scanned heuristically for character encoding and/or format, it is usually more optimal to pass 100% of your data to the scanner than to supply costly additional looks to see if there is some embedded metadata. And then Mark's not wrong about the prevalence of "wrong" tags. There is another problem as well: lots of data is tagged with an inconvenient tag (either too long or too short) requiring additional scanning to remediate. > > At this point it's possible that a smart procedure says "it's > REXX", and a dumb caller then decides, "okay, if it's not 'en' > I use 'zxx'". We could say that this is a bug, and Addison's > proposal "SHOULD NOT use 'zxx'" confirms this theory, but it > can take some time until somebody fixes this plausible bug in > a hypothetical application adding Content-Language tags to all > inline MIME text parts, even where that's a bad idea. I purposefully proposed SHOULD NOT: we cannot ban the usage and there are valid use cases for it. But we should be as direct and stringent as practical to prevent the majority of taggers for using it for actual natural language tagging. Actually, if you want to tag a file full of code with a language tag, the tag should probably match the language used for the comments (you comment your code, right?) or for the variable names (you have variables with names other than 'x' or 's3', right?). If a lot of these turn out to be "en-x-hacker", so be it. Embedded binary junk or embedded programming junk are just noise. > > All we can do is say "SHOULD NOT" in 4646bis, and hope that > implementors get the idea. And implementations based on 4646 > or 3066 have an excuse to violate this future "SHOULD NOT", it > isn't obvious. The recommendations on tag choice really should guide users of any of these older implementations. Remember: we're talking about tag *choice* here. Tags that uses these subtags, even junk like "zxx-Hant-AQ-x-foolish", are well-formed and valid. > > RFC 3282 updates RFC 1766. Somehow RFC 4646 managed to have no > reference to RFC 3282 and RFC 2277. IMHO we should fix that in > 4646bis, these RFCs are really relevant. Actually, I think I proposed it but it was turned down as inconvenient. I agree we should obsolete 3282 (by updating it) or at least reference it. > > A very important example in RFC 3282 is this: > > | Content-type: multipart/alternative > | Content-Language: da, de, el, en, fr, it > > Content-Language can be used with multipart/alternative, here > for alternative parts in the languages da, de, el, en, fr, it. > ACK :-) > > One thing is sure, the syntax is "one or more tags" in RFC 3282, > there's no xml:lang="" trick for Content-Language header fields. Yes there is: it's called "no Content-Language header present". Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 20 19:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf2cS-0002uJ-7o; Fri, 20 Apr 2007 19:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf2cQ-0002uE-O3 for ltru@lists.ietf.org; Fri, 20 Apr 2007 19:34:22 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf2cP-0005RB-4H for ltru@lists.ietf.org; Fri, 20 Apr 2007 19:34:22 -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.685.24; Fri, 20 Apr 2007 16:34:20 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 20 Apr 2007 16:34:20 -0700 From: Peter Constable To: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" Date: Fri, 20 Apr 2007 16:34:17 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceDjeTj13GUzzWoRGucS6Fc0Kb61wAE5lpA Message-ID: References: <20070413122917.GA25431@nic.fr> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> In-Reply-To: <30b660a20704201352r187a3eb7l6054cf88701a306@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: 1.2 (+) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0202056701==" Errors-To: ltru-bounces@ietf.org --===============0202056701== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F974DANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F974DANAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis >> I don't expect to see .cxx, .h, etc. files tagged with language tags any= time soon > > Well, every file available on the web, like > http://www.cs.duke.edu/csed/tapestry/win/date.h (chosen at random) gets > some language tag when processed at Google (I can't say what MSN, > Yahoo, and other search engines do). So right under your nose millions of > pages of source code are getting tagged, all the time. We are faced with = the > practical problem of what the best thing to do is according to the standa= rd. Well, I suppose you have to decide: when an English user does a search on "= date", what's the likelihood that the content in a file date.h is going to = be of interest to them. All I've said all along is that the only appropriate language tag in ISO 63= 9 for programming languages (when you have determined the content is in a p= rogramming language) is "zxx". That refers to content such as "#ifndef _DAT= E_H", not content such as "// a class for manipulating dates". Deciding how= Google should tag a file like date.h is an entirely different question. Ab= sent any context, there is no right or wrong answer about how to tag *as a = whole* a file like date.h: clearly there is about as much English content i= n that file as there is C (or whatever prog lang it is). In a given applica= tion context, such as how Google should tag that file as a whole, there may= be good reasons to tag it one way or another. But that's a question to be = worked out in the context of that application; IMO it is not a question tha= t should be answered in BCP 47. If you want to add text suggesting that different things may be done in dif= ferent application scenarios, including tagging programming-code content wi= th English comments or string literals as "en" when that provides the attri= bute most useful for implementation and user experience, I have no problem = with that. But a *general* statement along lines such as that using an IETF= language tag/ISO 639 ID "en" for such programming code is appropriate or t= hat the appropriate tag for your example 9 would be "und" is, IMO, not some= thing that should appear in BCP 47. Peter --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F974DANAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis

>> I don't = expect to see .cxx, .h, etc. files tagged with language tags any time soon
>
> Well, every file available on the= web, like

> http://www.cs.duke= .edu/csed/tapestry/win/date.h (chosen at random) gets

> some language tag when processed at Google (I ca= n't say what MSN,

> Yahoo, and other search engines do). So right un= der your nose millions of

> pages of source code are getting tagged, all the time. We are faced with the

> practical problem of what the best thing to do i= s according to the standard. =

 

Well, I suppose you have to decide: when an English user doe= s a search on “date”, what’s the likelihood that the content = in a file date.h is going to be of interest to them.

 

All I’ve said all along is that the only appropriate l=
anguage tag in ISO 639 for programming languages (when you have determined =
the content is in a programming language) is “zxx”. That refers=
 to content such as “#ifndef _DATE_H”, not content such as “// a class for manipulating dat=
es”. Deciding how Google should tag a file like date.h is an entirely =
different question. Absent any context, there is no right or wrong answer a=
bout how to tag *as a whole* a file like date.h: clearly there is ab=
out as much English content in that file as there is C (or whatever prog la=
ng it is). In a given application context, such as how Google should tag th=
at file as a whole, there may be good reasons to tag it one way or another.=
 But that’s a question to be worked out in the context of that applic=
ation; IMO it is not a question that should be answered in BCP 47. <=
o:p>

 

If you want to add text suggesting that different things may= be done in different application scenarios, including tagging programming-code content with English comments or string literals as “en” when t= hat provides the attribute most useful for implementation and user experience, I have no problem with that. But a *general* statement along lines such as tha= t using an IETF language tag/ISO 639 ID “en” for such programming code = is appropriate or that the appropriate tag for your example 9 would be “= und” is, IMO, not something that should appear in BCP 47.

 

 

Peter



--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955E33F974DANAEXMSGC117re_-- --===============0202056701== 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 --===============0202056701==-- From ltru-bounces@ietf.org Fri Apr 20 20:28: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 1Hf3Sb-00061q-KJ; Fri, 20 Apr 2007 20:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf3Sa-00061b-Bp for ltru@lists.ietf.org; Fri, 20 Apr 2007 20:28:16 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf3SY-0006vx-Pw for ltru@lists.ietf.org; Fri, 20 Apr 2007 20:28:16 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1025750nzf for ; Fri, 20 Apr 2007 17:28: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=rLPwC52srtv6N4TiHO6voBvxRV4MmVlTniPTCJ+I8zeDL5bCcAoFCCNC+FbfWro/wZTBWwzvuXanWSST64wyD/fweRpvzrFYsKCvpaDIe3yYQj0WZdBywogch7RDpYsPh9nSR/KPgCyv8WVHZ9afQSJ8elw6V5MjDiN4msNpaZo= 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=YDC/VQ+YcQDahsXxyS+TOBmv+20Bw4Y0lNSaKvkXMp1vS+sNByVs8hVaen5QDpVvC27sjDeI+CIiM5sJP7+1YX5mH0puDKUyBhaK1G4uK7bfZrJFzJmhIRXr7c44HOXgK+5vYaRSL2MdgAXE7QaN+lL4aMLPYdo/j4CqA1OXe98= Received: by 10.114.159.1 with SMTP id h1mr1457221wae.1177115294060; Fri, 20 Apr 2007 17:28:14 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 17:28:13 -0700 (PDT) Message-ID: <30b660a20704201728i74df1342ib85cfefe53846e68@mail.gmail.com> Date: Fri, 20 Apr 2007 17:28:13 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: "mis" update review request In-Reply-To: MIME-Version: 1.0 References: <20070413122917.GA25431@nic.fr> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> X-Google-Sender-Auth: b38028620820f54d X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: "ietf-languages@alvestrand.no" , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740882014==" Errors-To: ltru-bounces@ietf.org --===============1740882014== Content-Type: multipart/alternative; boundary="----=_Part_155164_14135938.1177115293998" ------=_Part_155164_14135938.1177115293998 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline And as a *general* statement about applying zxx to programming languages, I think that unless and until we add ", or programming languages" to the Description, it is unsuitable for application to programming languages. I don't think we are that far apart here -- we both agree that zxx ought to be the right thing. Where we disagree is that you think it already has that meaning, and I can't see it at all in the standard. But since it is a broadening, we can make a change and then both of us would be happy (or at least happier). So what do you say we agree on that, and be done with this part of the issue? Mark On 4/20/07, Peter Constable wrote: > > *From:* mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] > *On Behalf Of *Mark Davis > > ** > > >> I don't expect to see .cxx, .h, etc. files tagged with language tags > any time soon > > > > Well, every file available on the web, like > > > http://www.cs.duke.edu/csed/tapestry/win/date.h (chosen at random) gets > > > some language tag when processed at Google (I can't say what MSN, > > > Yahoo, and other search engines do). So right under your nose millions > of > > > pages of source code are getting tagged, all the time. We are faced with > the > > > practical problem of what the best thing to do is according to the > standard. > > > > Well, I suppose you have to decide: when an English user does a search on > "date", what's the likelihood that the content in a file date.h is going > to be of interest to them. > > > > All I've said all along is that the only appropriate language tag in ISO 639 for programming languages (when you have determined the content is in a programming language) is "zxx". That refers to content such as "#ifndef _DATE_H", not content such as "// a class for manipulating dates". Deciding how Google should tag a file like date.h is an entirely different question. Absent any context, there is no right or wrong answer about how to tag **as a whole** a file like date.h: clearly there is about as much English content in that file as there is C (or whatever prog lang it is). In a given application context, such as how Google should tag that file as a whole, there may be good reasons to tag it one way or another. But that's a question to be worked out in the context of that application; IMO it is not a question that should be answered in BCP 47. > > > > If you want to add text suggesting that different things may be done in > different application scenarios, including tagging programming-code content > with English comments or string literals as "en" when that provides the > attribute most useful for implementation and user experience, I have no > problem with that. But a **general** statement along lines such as that > using an IETF language tag/ISO 639 ID "en" for such programming code is > appropriate or that the appropriate tag for your example 9 would be "und" > is, IMO, not something that should appear in BCP 47. > > > > > > Peter > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_155164_14135938.1177115293998 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline And as a *general* statement about applying zxx to programming languages, I think that unless and until we add ", or programming languages" to the Description, it is unsuitable for application to programming languages. I don't think we are that far apart here -- we both agree that zxx ought to be the right thing. Where we disagree is that you think it already has that meaning, and I can't see it at all in the standard.

But since it is a broadening, we can make a change and then both of us would be happy (or at least happier). So what do you say we agree on that, and be done with this part of the issue?

Mark

On 4/20/07, Peter Constable <petercon@microsoft.com> wrote:

From: mark.edward.davis@gmail.com [mailto: mark.edward.davis@gmail.com] On Behalf Of Mark Davis

>> I don't expect to see .cxx, .h, etc. files tagged with language tags any time soon
>
> Well, every file available on the web, like

> http://www.cs.duke.edu/csed/tapestry/win/date.h (chosen at random) gets

> some language tag when processed at Google (I can't say what MSN,

> Yahoo, and other search engines do). So right under your nose millions of

> pages of source code are getting tagged, all the time. We are faced with the

> practical problem of what the best thing to do is according to the standard.

 

Well, I suppose you have to decide: when an English user does a search on "date", what's the likelihood that the content in a file date.h is going to be of interest to them.

 

All I've said all along is that the only appropriate language tag in ISO 639 for programming languages (when you have determined the content is in a programming language) is "zxx". That refers to content such as "
#ifndef _DATE_H", not content such as "// a class for manipulating dates". Deciding how Google should tag a file like 
date.h is an entirely different question. Absent any context, there is no right or wrong answer about how to tag *as a whole* a file like date.h: clearly there is about as much English content in that file as there is C (or whatever prog lang it is). In a given application context, such as how Google should tag that file as a whole, there may be good reasons to tag it one way or another. But that's a question to be worked out in the context of that application; IMO it is not a question that should be answered in BCP 47.

 

If you want to add text suggesting that different things may be done in different application scenarios, including tagging programming-code content with English comments or string literals as "en" when that provides the attribute most useful for implementation and user experience, I have no problem with that. But a *general* statement along lines such as that using an IETF language tag/ISO 639 ID "en" for such programming code is appropriate or that the appropriate tag for your example 9 would be "und" is, IMO, not something that should appear in BCP 47.

 

 

Peter




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




--
Mark ------=_Part_155164_14135938.1177115293998-- --===============1740882014== 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 --===============1740882014==-- From ltru-bounces@ietf.org Fri Apr 20 20:36: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 1Hf3aV-000751-Ix; Fri, 20 Apr 2007 20:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf3aU-00074F-18 for ltru@lists.ietf.org; Fri, 20 Apr 2007 20:36:26 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf3aS-0008Pa-Av for ltru@lists.ietf.org; Fri, 20 Apr 2007 20:36:26 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1026689nzf for ; Fri, 20 Apr 2007 17:36:24 -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=UpyDUgednuoAc5moRt8csKBUdbt4aZI7hX0siVReZXoZlhETuMbqBA3A4qMAd5NCEzAs6XWlA1QuGvZfKSxclLp2h68ROMLGOLNwWTLvxSPup7ZrtfifhSGiTEqBybIpqUGi/uesejZLvUwsax7e+bbTsd+GdHoz1pciqmHMGvw= 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=YFAbqWCOqB3iFmwVlFR7Sl1JMcQXheUYt5YVgtDB7j0ZMAapzwWqFvGOj8QWfy3FMJkl0O3WM6Em43nAp9QIzPuaPHcy+jq0Gr5p18qBqf8Qq5stYK0vwYhwQas6hStndlyfSm4/q7CUJ1iqTMvrTV4kHijfZYiAcY6kMbbwKdQ= Received: by 10.114.80.4 with SMTP id d4mr1484382wab.1177115783638; Fri, 20 Apr 2007 17:36:23 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 20 Apr 2007 17:36:23 -0700 (PDT) Message-ID: <30b660a20704201736t5e64c614l21c994717c619db0@mail.gmail.com> Date: Fri, 20 Apr 2007 17:36:23 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Language Tag Special Cases In-Reply-To: <4628E7A2.3030509@yahoo-inc.com> MIME-Version: 1.0 References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> X-Google-Sender-Auth: 9a6acbd603491261 X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0725947834==" Errors-To: ltru-bounces@ietf.org --===============0725947834== Content-Type: multipart/alternative; boundary="----=_Part_155300_6147105.1177115783539" ------=_Part_155300_6147105.1177115783539 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/20/07, Addison Phillips > wrote: > > So if I understand the proposal, it is to deal with the different > "special case" codes assigned by ISO 639. To paraphrase what 4646 > contains (plus my interpretation of the additions): > > "mul" is used to identify content in multiple languages. It SHOULD NOT > be used when a list of languages (such as Content-Language) can be used agreed instead and it SHOULD NOT be used for individual content items (such as > a single

element in an XHTML document). BCP 47 is silent on this point, so I don't think this is a good paraphrase. "und" is used to identify linguistic content whose language cannot be > determined. It SHOULD NOT be used unless a language tag is required agreed. and > the language cannot be determined. BCP 47 is silent on this point, so I don't think this is a good paraphrase. Also, the most we could require in a future version is "is not determined", not "cannot be determined". "zxx" is used to identify non-lingusitic content. It SHOULD NOT be used > unless a language tag is required by some application or protocol for > some non-human language content item. BCP 47 contains no instance of 'zxx'. Thus the above is not a paraphrase of BCP 47. Moreover, I disagree that it should not be used. "mis" is used to identify linguistic content whose language is known but > cannot otherwise be identified. It is commonly used when the range of > language tags is constrained (for example, to ISO 639-2, as in MARC, for > example) or for languages not otherwise categorized. It SHOULD NOT be > used unless a language tag is required and no other means of identifying > the language is available. The above is not a paraphrase of BCP 47, or of ISO 639-2. It may be your own opinion of what we should say in 4646bis (and I agree with part of it), but is not justifiable on the basis of the current standard. In all cases, where permitted, omitting the language tag is preferable > to using these codes. Language tags SHOULD NOT incorporate these subtags > as a prefix under any circumstances. Also not a paraphrase of BCP 47, but your own addition. Moreover, I disagree strongly with this. "und-Latn" is a perfectly reasonable code, that conveys useful information. So is "zxx". If I have He showed me a picture of 143kl;ufa) iop(&uweiorqhjkl2341l kj#@!$Jkdfj;afe and said Igonda flatunicai vbinkli? then according to your proposal, I SHOULD nuke various information and be left with: He showed me a picture of 143kl;ufa) iop(&uweiorqhjkl2341l kj#@!$Jkdfj;afe and said Igonda flatunicai vbinkli? I don't see where this is a good thing. I do think, which is maybe the direction you are headed, that we should have language that says that you SHOULD tag with more specific primary language tags than collections or specials, where possible. This covers all of the cases except that where the language is known and > can be identified using a regular subtag. > > Any other cases? I added some notes to http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 on these issues. I don't think you cover all the cases (and I disagree with your approach in some cases). Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_155300_6147105.1177115783539 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 4/20/07, Addison Phillips < addison@yahoo-inc.com> wrote:
So if I understand the proposal, it is to deal with the different
"special case" codes assigned by ISO 639. To paraphrase what 4646
contains (plus my interpretation of the additions):

"mul" is used to identify content in multiple languages. It SHOULD NOT
be used when a list of languages (such as Content-Language) can be used

agreed

instead and it SHOULD NOT be used for individual content items (such as
a single <p> element in an XHTML document).

BCP 47 is silent on this point, so I don't think this is a good paraphrase.

"und" is used to identify linguistic content whose language cannot be
determined. It SHOULD NOT be used unless a language tag is required

agreed.

and
the language cannot be determined.

BCP 47 is silent on this point, so I don't think this is a good paraphrase. Also, the most we could require in a future version is "is not determined", not "cannot be determined".


"zxx" is used to identify non-lingusitic content. It SHOULD NOT be used
unless a language tag is required by some application or protocol for
some non-human language content item.

BCP 47 contains no instance of 'zxx'. Thus the above is not a paraphrase of BCP 47. Moreover, I disagree that it should not be used.

"mis" is used to identify linguistic content whose language is known but
cannot otherwise be identified. It is commonly used when the range of
language tags is constrained (for example, to ISO 639-2, as in MARC, for
example) or for languages not otherwise categorized. It SHOULD NOT be
used unless a language tag is required and no other means of identifying
the language is available.

The above is not a paraphrase of BCP 47, or of ISO 639-2. It may be your own opinion of what we should say in 4646bis (and I agree with part of it), but is not justifiable on the basis of the current standard.

In all cases, where permitted, omitting the language tag is preferable
to using these codes. Language tags SHOULD NOT incorporate these subtags
as a prefix under any circumstances.

Also not a paraphrase of BCP 47, but your own addition. Moreover, I disagree strongly with this. "und-Latn" is a perfectly reasonable code, that conveys useful information. So is "zxx". If I have

<content xml:lang="en">He showed me a picture of </content><content xml:lang="zxx">143kl;ufa) iop(&uweiorqhjkl2341l kj#@!$Jkdfj;afe</content><content xml:lang="en"> and said </content><content xml:lang="mis">Igonda flatunicai vbinkli?<content>

then according to your proposal, I SHOULD nuke various  information and be left with:

<content xml:lang="en">He showed me a picture of </content><content>143kl;ufa) iop(&uweiorqhjkl2341l kj#@!$Jkdfj;afe</content><content xml:lang="en"> and said </content><content>Igonda flatunicai vbinkli?<content>

I don't see where this is a good thing. I do think, which is maybe the direction you are headed, that we should have language that says that you SHOULD tag with more specific primary language tags than collections or specials, where possible.  

This covers all of the cases except that where the language is known and
can be identified using a regular subtag.

Any other cases?

I added some notes to http://docs.google.com/Doc?id=dfqr8rd5_11g425c9 on these issues. I don't think you cover all the cases (and I disagree with your approach in some cases). 

Addison

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

Internationalization is an architecture.
It is not a feature.

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



--
Mark ------=_Part_155300_6147105.1177115783539-- --===============0725947834== 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 --===============0725947834==-- From ltru-bounces@ietf.org Sat Apr 21 00:45: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 1Hf7Ti-00020n-Bk; Sat, 21 Apr 2007 00:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf7Tg-00020d-NJ for ltru@lists.ietf.org; Sat, 21 Apr 2007 00:45:40 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf7Tf-0003X7-B2 for ltru@lists.ietf.org; Sat, 21 Apr 2007 00:45:40 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf7TY-00050o-HA; Sat, 21 Apr 2007 00:45:32 -0400 Date: Sat, 21 Apr 2007 00:45:32 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070421044532.GU1262@mercury.ccil.org> References: <00a201c78124$0713eaa0$7a63f853@streamserve.com> <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "ltru@lists.ietf.org" , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I don't think the programming language fragment is really a boundary > condition. Most code source nowadays are not just random hex, there > typically, not exceptionally, some real linguistic content. That's a matter of definition: taggers must draw the line somewhere, and ISO 639 by its nature gives no help. Is this email in English? Yes. Is the OED written in English? Unquestionably. Is a mere wordlist like /usr/share/dict/words in English? Probably. What about a shorter list of English words which on inspection turns out to be the reserved words of Cobol-68? Perhaps. What about the text of _Finnegans Wake_? Scholars disagree, though several translations have been made. What about the source of TeX, which is a complex admixture of English prose (well beyond line-by-line comments) and Pascal code fragments? I don't know. A document in English may be represented in a computer as text or as a graphic; in either case "en" is applicable. How large a contribution to the graphic must letterforms make before "en" is reasonable? Is a photograph with some English text shown in the image (on a sign, for example) a reasonable instance of "en"? What about a subtitle embedded in the image? What about a copyright notice using the word "Copyright", which is an English word but can be used, by international agreement, in any copyright notice in place of the copyright symbol? What if "Copr." is used, which is also equivalent to the copyright symbol? There is "en" and there is "cpe", which represents the collection of pidgin and creole languages with an English lexifier. 639-3 provides 30 such languages, or 32 if you count Bislama and Tok Pisin, which have their own 639-2 code elements. However, in classifying spoken-word documents (whether recordings or transcriptions) made where a creole language is spoken, one generally finds that they contain an extraordinarily complex mixture of the local variety of English and of the creole, with the proportions and details of the mixture varying with the speaker, the audience, the subject matter, and a host of other factors. The behavior of "en" and "sco" both in speech and in writing is essentially similar. It is and always will be a matter of judgement whether to use "en", "cpe" (or "sco"), or "mul" in such situations. In short, "English" is not a bright-line notion. Formally, all that ISO 639 tells us is that if you have something that you believe to be English, you may tag it "en", and a counterparty may reconstruct the fact that you believe it to be English. There is a large class of documents where all will agree that the language is English and that the "en" tag is appropriate, and another large class where all will agree that it is inappropriate. In between there are judgement calls. > but based on the wording of the standards, I don't think we can expect > zxx to apply to typical code source. Yet, while there may be is some > embedded English, we don't want to call it "en" either. Maybe we do, maybe we don't; it depends on our inividual purposes. > It looks to me like the best choice currently would be "und"; "und" is always a correct choice, as it is a formal expression of ignorance or indifference or both. > I think it might be useful to have a special tag for this just > because it is a reasonably common case that is otherwise difficult > to categorize. I don't think you will make any progress with 639/RA on that one, nor is it appropriate for BCP 47 to add tags for entirely new purposes, nor do you seem to have much traction from this mailing list for doing so. A private-use tag, perhaps based on zxx, perhaps not, is surely suitable for Google's private purposes. > alternative would be to explicitly broaden the description of "zxx" to be > "no linguistic content, or programming source code". That would be a > compatible change to 4646bis, since it is a broadening. It may or may not be a broadening, depending on whether you think programming source code has linguistic content or not. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 00:51: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 1Hf7Z4-0005PL-E2; Sat, 21 Apr 2007 00:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf7Z3-0005PG-9z for ltru@lists.ietf.org; Sat, 21 Apr 2007 00:51:13 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf7Z2-0005Od-2I for ltru@lists.ietf.org; Sat, 21 Apr 2007 00:51:13 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf7Yz-0005GB-RL; Sat, 21 Apr 2007 00:51:09 -0400 Date: Sat, 21 Apr 2007 00:51:09 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070421045109.GV1262@mercury.ccil.org> References: <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "ltru@lists.ietf.org" , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Well, every file available on the web, like > http://www.cs.duke.edu/csed/tapestry/win/date.h (chosen at random) > gets some language tag when processed at Google (I can't say what MSN, > Yahoo, and other search engines do). So right under your nose millions > of pages of source code are getting tagged, all the time. We are faced > with the practical problem of what the best thing to do is according > to the standard. Is "we" Google here, or the WG? I don't think the WG is faced with any such problem, though I agree that Google is; however, Google has a variety of moves (including ignoring the issue, using "zxx", using a private tag, or using a 'zxx' language subtag with a private subtag. Without wishing to induce a breach of the rules of Fight Club, I'd be interested to know what Google does currently, and whether it recognizes such a file as C source or not. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan|cowan@ccil.org|ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 01:00: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 1Hf7iN-0003gc-Oy; Sat, 21 Apr 2007 01:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf7iN-0003gX-BV for ltru@lists.ietf.org; Sat, 21 Apr 2007 01:00:51 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf7iM-0000tT-1s for ltru@lists.ietf.org; Sat, 21 Apr 2007 01:00:51 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf7iJ-0005hH-OV; Sat, 21 Apr 2007 01:00:47 -0400 Date: Sat, 21 Apr 2007 01:00:47 -0400 To: Mark Davis Subject: Re: [Ltru] Re: "mis" update review request Message-ID: <20070421050047.GW1262@mercury.ccil.org> References: <30b660a20704171937j4c62c409jd07a290ef1498612@mail.gmail.com> <46289CB6.3C97@xyzzy.claranet.de> <30b660a20704200808v67cac397te33954143817955e@mail.gmail.com> <30b660a20704200859l4d3d097dld9890a1fccfa5011@mail.gmail.com> <30b660a20704201352r187a3eb7l6054cf88701a306@mail.gmail.com> <30b660a20704201728i74df1342ib85cfefe53846e68@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704201728i74df1342ib85cfefe53846e68@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "ltru@lists.ietf.org" , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > And as a *general* statement about applying zxx to programming > languages, I think that unless and until we add ", or programming > languages" to the Description, it is unsuitable for application to > programming languages. That would only be true if there were a clear and convincing argument, acceptable to all, that code is written in a natural language. Otherwise, it is a mere judgement about a class of borderline cases. > don't think we are that far apart here -- we both agree that zxx ought > to be the right thing. Where we disagree is that you think it already > has that meaning, and I can't see it at all in the standard. All the standard says is "Non-linguistic content". So to assert that code is not "zxx", you must say that it is linguistic content, though you are unwilling to apply "en" (or, presumably, any other specific or collective language tag). What is this linguistic content that is not in any language? You have for whatever reason decided that reading and writing code (presumably exclusive of comments, which are unquestionably in English or French or Japanese or what have you) is linguistic behavior, but why? Learning to program is very unlike either acquiring French or Esperanto as a first language, or learning them as a second language, though admittedly more like the latter than the former. Are you also willing to say that mathematical formulae embedded in a math paper in English, French, German, Russian, or what have you are linguistic content, though certainly not in any of those languages? > But since it is a broadening, we can make a change and then both of > us would be happy (or at least happier). So what do you say we agree > on that, and be done with this part of the issue? Because it is not clear that it is a broadening, and it is very colorably an out-of-scope extension. Why not mention musical notation (of instrumental compositions, where there are no lyrics to muddy the waters) as well? -- I am expressing my opinion. When my John Cowan honorable and gallant friend is called, cowan@ccil.org he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 02:02: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 1Hf8fs-0001gc-Ga; Sat, 21 Apr 2007 02:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf8fr-0001gX-GY for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:02:19 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf8fq-0006oj-8k for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:02:19 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf8fo-0001J3-CA; Sat, 21 Apr 2007 02:02:16 -0400 Date: Sat, 21 Apr 2007 02:02:16 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Language Tag Special Cases Message-ID: <20070421060216.GY1262@mercury.ccil.org> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > It certainly makes sense to say that a video of Bugs Bunny has no > written language content, and that's how we interpret Zxxx. (Zxxx has > no use otherwise. It would not make sense to have a script tag that > could only be applied to content in languages which are currently > unwritten, since you know that from the language anyway, and such > an interpretation would make BCP 47 by definition unstable -- it is > always possible to develop written form of that language which would > invalidate the tag.) +1, and I have posted an ISO 15924 change request to this effect. > I added "i-default" at the top, since as far as I can tell, it is > essentially equivalent to "und" or maybe "mis". I think we should > discourage it, myself, since it is grandfathered and cannot be combined. It makes no sense to tag a received document "i-default", as i-default represents an abstraction. It makes sense to request an i-default version of a document, which may contain English only or may be multilanguage. It must include English, but need not be the same as the English version (if there is one) of the document. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 02:11: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 1Hf8oe-0002vb-Tb; Sat, 21 Apr 2007 02:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf8od-0002g6-5A for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:11:23 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf8lM-0008NH-DA for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:08:01 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf8lJ-0001Wn-TL; Sat, 21 Apr 2007 02:07:57 -0400 Date: Sat, 21 Apr 2007 02:07:57 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Language Tag Special Cases Message-ID: <20070421060757.GZ1262@mercury.ccil.org> References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> <005d01c78386$46d15a10$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005d01c78386$46d15a10$5072f853@streamserve.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > I have no idea where you got the list of 133 specific languages from. http://www.ethnologue.com/14/show_iso639.asp?code=mis , probably. > As far as I can tell, it appears to have no normative connection > with the 639 standards themselves. True. As I have been arguing, however, the normative text and tables of ISO 639 capture only part of its meaning: it is normative that "en" means "English", but there is no normative definition of "English", nor is there ever likely to be one. -- 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 Sat Apr 21 02: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 1Hf8uS-0000zB-Vo; Sat, 21 Apr 2007 02:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf8uS-0000z5-B1 for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:17:24 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf8uQ-00013A-L4 for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:17:24 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf8uP-0001wW-9s; Sat, 21 Apr 2007 02:17:21 -0400 Date: Sat, 21 Apr 2007 02:17:21 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Language Tag Special Cases Message-ID: <20070421061721.GA1262@mercury.ccil.org> References: <30b660a20704181348g194439b6sefa511e16211a901@mail.gmail.com> <4628A6D5.64D5@xyzzy.claranet.de> <30b660a20704200923i6d43622bh6fe42f809481eec6@mail.gmail.com> <462911D2.280F@xyzzy.claranet.de> <30b660a20704201247k5ae895acg59c282dadbd83b3b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704201247k5ae895acg59c282dadbd83b3b@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > That is one interpretation, but it is not supported by the text. As I have argued repeatedly, the normative content of ISO 639 is insufficient to properly interpret it. > I think the best thing we could do at this point would be to strongly > discourage the use of "mis" in 4646bis +1, as there will be a sufficient number of specific language codes for almost anything, and "und" is satisfactory as a representation of ignorance or indifference. > The text doesn't, as far as I can see, support the contention, and I > haven't seen anything from John or Peter to contradict that. Much as > I respect their judgments on a whole variety of subjects, on this one > I think they are interpreting the text as they think it should have > been written, not as it is. I am not interpreting the text at all: I am relaying the established interpretive tradition. By its very nature, an interpretive tradition is outside the text. > "Mis" as exclusionary makes sense any time you are in an environment > that forces a disjunctive partition. The partition need not be fully disjunctive; a hierarchical partition works fine too, with "mis" as one of the top-level partitions, the one which includes everything not included elsewhere. > But ISO 639 does not require a partition. It has traditionally been interpreted as one. > >Yes, the source (RFC 2277) already does this. We could add a > >comment "see BCP 18 (RFC 2277)" to the BCP 47 registry. +1 > Or even better yet, a comment in the registry and the text explicitly > discouraging it. There is no reason to discourage "i-default" in its proper context. For example, given a document available in French only, a request for "i-default" might return the text "This document is available in French only." Alternatively, the "i-default" version of a document also available in English might use simpler words or constructions so as to be understood by a wider range of English-speakers. -- Only do what only you can do. John Cowan --Edsger W. Dijkstra's advice to a student in search of a thesis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 02:41: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 1Hf9Hy-000427-Oe; Sat, 21 Apr 2007 02:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf9Hx-00041z-T5 for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:41:41 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf9Hw-0004gn-Kb for ltru@lists.ietf.org; Sat, 21 Apr 2007 02:41:41 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hf9Hu-0003Bc-LK; Sat, 21 Apr 2007 02:41:38 -0400 Date: Sat, 21 Apr 2007 02:41:38 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Language Tag Special Cases Message-ID: <20070421064138.GB1262@mercury.ccil.org> References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628AD9E.3CFD@xyzzy.claranet.de> <4628E7A2.3030509@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4628E7A2.3030509@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > "mul" is used to identify content in multiple languages. It SHOULD NOT > be used when a list of languages (such as Content-Language) can be used > instead and it SHOULD NOT be used for individual content items (such as > a single

element in an XHTML document). > > "und" is used to identify linguistic content whose language cannot be > determined. It SHOULD NOT be used unless a language tag is required and > the language cannot be determined. > > "zxx" is used to identify non-lingusitic content. It SHOULD NOT be used > unless a language tag is required by some application or protocol for > some non-human language content item. > > "mis" is used to identify linguistic content whose language is known but > cannot otherwise be identified. It is commonly used when the range of > language tags is constrained (for example, to ISO 639-2, as in MARC, for > example) or for languages not otherwise categorized. It SHOULD NOT be > used unless a language tag is required and no other means of identifying > the language is available. > > In all cases, where permitted, omitting the language tag is preferable > to using these codes. Language tags SHOULD NOT incorporate these subtags > as a prefix under any circumstances. > > This covers all of the cases except that where the language is known and > can be identified using a regular subtag. With the addition of i-default, I think that sums things up admirably, and should be added to the next draft of 4646bis. -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 05:26: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 1HfBri-0003kb-RR; Sat, 21 Apr 2007 05:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfBrh-0003kT-Io for ltru@lists.ietf.org; Sat, 21 Apr 2007 05:26:45 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfBrg-000416-5C for ltru@lists.ietf.org; Sat, 21 Apr 2007 05:26:45 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1739 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfBra-0005HG-6z; Sat, 21 Apr 2007 11:26:40 +0200 From: "Kent Karlsson" To: "'John Cowan'" References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> <005d01c78386$46d15a10$5072f853@streamserve.com> <20070421060757.GZ1262@mercury.ccil.org> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 11:28:50 +0200 Message-ID: <001801c783f7$81d46690$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070421060757.GZ1262@mercury.ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceD23D8+7K14OKETDW2hWh2RWYBwwAEKeog X-Scan-Result: No virus found in message 1HfBra-0005HG-6z. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HfBra-0005HG-6z fc8e2cdc4e9a60ca56ba34c88cab9868 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Kent Karlsson scripsit: > > > I have no idea where you got the list of 133 specific > languages from. > > http://www.ethnologue.com/14/show_iso639.asp?code=mis , probably. That is just a snapshot of what was 'mis' but not "otherwise catalogued" in a particular setting at a particular point in time. It's not the definition of 'mis' in ISO 639 by any account. > > As far as I can tell, it appears to have no normative connection > > with the 639 standards themselves. > > True. As I have been arguing, however, the normative text and > tables of ISO 639 capture only part of its meaning: it is normative > that "en" means "English", but there is no normative definition > of "English", nor is there ever likely to be one. True. And I would not expect that to ever happen for the individual languages. But an explicit coverage list (admittedly with an implicit "or any other variety that is not explicitly listed") is already given for the "macrolanguages" (a concept not yet in ISO 639-2) for 639-3. Are similar coverage lists (with implicit "or any other language in this group not explicitly listed") planned for ISO 639-5? The "macrolanguages" and "collections" are quite similar in the sense that for both of them they cover all of the individual languages (and for the collection, also all of the more specific collections) that are (by convention) in their respective groups. One of the differences between "macrolanguages" and "collections", however, is that for "macrolanguages" it is quite ok to use the macrolanguage code for any of the "sublanguages" covered, whereas for "collections", the collection code *should not* be used (even though it could) if there is a more specific code "available". This goes for 'mis' too, as it is just one of the collection codes, albeit the top level collection code. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 05:27: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 1HfBsB-0004ir-9e; Sat, 21 Apr 2007 05:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfBsA-0004im-MA for ltru@ietf.org; Sat, 21 Apr 2007 05:27:14 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfBs9-00043w-8r for ltru@ietf.org; Sat, 21 Apr 2007 05:27:14 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1764 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfBs8-000146-3n for ltru@ietf.org; Sat, 21 Apr 2007 11:27:12 +0200 From: "Kent Karlsson" To: Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 11:29:39 +0200 Message-ID: <001901c783f7$96183c80$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceD95WLtQ30jKyaR3aTcS9i6LTznQ== X-Scan-Result: No virus found in message 1HfBs8-000146-3n. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfBs8-000146-3n 091b76d1d0ab734f1da96605c4e9a66a X-Spam-Score: 0.5 (/) 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 John Cowan wrote: > Mark Davis scripsit: > > > That is one interpretation, but it is not supported by the text. > > As I have argued repeatedly, the normative content of ISO 639 is > insufficient to properly interpret it. Well, 'mis' is the only collection code that CAN be fully interpreted from the text of ISO 639-2 alone (as I have shown). But it is (or at least seems to be) flexible in that different sets of other classifications may be available in different settings. > > I think the best thing we could do at this point would be to strongly > > discourage the use of "mis" in 4646bis > > +1, as there will be a sufficient number of specific language codes > for almost anything, and "und" is satisfactory as a representation of > ignorance or indifference. I would tend to agree, but then by implication this holds for ALL of the collection codes in a 4646bis setting (which covers all known individual (modern or semimodern) "natural" languages of this planet). So if you want to strongly discourage the use of 'mis', then also strongly discourage the use of 'tai', 'fiu', etc. collection codes. > > The text doesn't, as far as I can see, support the contention, and I > > haven't seen anything from John or Peter to contradict that. Much as > > I respect their judgments on a whole variety of subjects, on this one > > I think they are interpreting the text as they think it should have > > been written, not as it is. > > I am not interpreting the text at all: I am relaying the established > interpretive tradition. By its very nature, an interpretive tradition > is outside the text. > > > "Mis" as exclusionary makes sense any time you are in an environment > > that forces a disjunctive partition. > > The partition need not be fully disjunctive; a hierarchical partition > works fine too, with "mis" as one of the top-level partitions, the one > which includes everything not included elsewhere. And that is what ISO 639-2 says, however with a vague "available", which depends on the setting. In a 4646bis (full ISO 639-3) setting, there is just about always a more specific code available, even down to individual language. > > But ISO 639 does not require a partition. > > It has traditionally been interpreted as one. "Miscellaneous" does mean "anything". But it is an "anything" for things not otherwise classified. *coverage* (everything) vs. *recommended use* (not otherwise classified). /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 05:28: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 1HfBtf-0005lQ-Vk; Sat, 21 Apr 2007 05:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfBte-0005lG-KK for ltru@ietf.org; Sat, 21 Apr 2007 05:28:46 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfBtd-0004jh-Bj for ltru@ietf.org; Sat, 21 Apr 2007 05:28:46 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1922 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfBtc-0002iB-5r for ltru@ietf.org; Sat, 21 Apr 2007 11:28:44 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Re: "mis" update review request Date: Sat, 21 Apr 2007 11:31:12 +0200 Message-ID: <001a01c783f7$cd4ee910$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceD91lxWhG6PAGsRyiBT7gRGRXlww== X-Scan-Result: No virus found in message 1HfBtc-0002iB-5r. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfBtc-0002iB-5r 8cd77dd08373499b988351cc766c15a7 X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I say your programming code example is a boundary case in the sense = that > I don't expect to see .cxx, .h, etc. files tagged with language tags = any > time soon, and I don=C3=A2t expect to see a book on programming = concepts tagged > as anything other than en, no matter how many pages of source code = samples it has.=20 Nit: There are many books on programming written in other languages than = English. /k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 06:21: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 1HfCiq-0005Aj-Sr; Sat, 21 Apr 2007 06:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfCip-0005Aa-SB for ltru@lists.ietf.org; Sat, 21 Apr 2007 06:21:39 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfCio-0002OK-K2 for ltru@lists.ietf.org; Sat, 21 Apr 2007 06:21:39 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HfCik-0007pU-Dl; Sat, 21 Apr 2007 06:21:34 -0400 Date: Sat, 21 Apr 2007 06:21:34 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Language Tag Special Cases Message-ID: <20070421102134.GE1262@mercury.ccil.org> References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> <005d01c78386$46d15a10$5072f853@streamserve.com> <20070421060757.GZ1262@mercury.ccil.org> <001801c783f7$81d46690$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c783f7$81d46690$5072f853@streamserve.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > Are similar coverage lists (with implicit "or any other language in > this group not explicitly listed") planned for ISO 639-5? Not as of the last time I saw a 639-5 draft, nor have I heard anything to suggest it. Which means that figuring out what a "Tai language" is will depend on encyclopedic information outside the standard, just as figuring out what "English" is. FWIW, that draft is harmonized with 639-2, but does not have any "(Other)" strings, so it takes the inclusive view of collections. > for "collections", the collection code *should not* be used > (even though it could) if there is a more specific code "available". Collection codes are useful for certain kinds of partial ignorance, however. For example, if you are classifying documents, you may know that a particular document is written in some Saami language, but may lack the resources to figure out which one. In that case, the collection code "smi" is appropriate. > This goes for 'mis' too, as it is just one of the collection codes, > albeit the top level collection code. On that view of "mis" it represents total ignorance, which is already well-represented by "und". -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 06:47: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 1HfD7v-00031C-TW; Sat, 21 Apr 2007 06:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfD7v-00030q-Dj for ltru@lists.ietf.org; Sat, 21 Apr 2007 06:47:35 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfD7t-000157-VW for ltru@lists.ietf.org; Sat, 21 Apr 2007 06:47:35 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1487 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfD7q-00084B-7f; Sat, 21 Apr 2007 12:47:30 +0200 From: "Kent Karlsson" To: "'John Cowan'" References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> <005d01c78386$46d15a10$5072f853@streamserve.com> <20070421060757.GZ1262@mercury.ccil.org> <001801c783f7$81d46690$5072f853@streamserve.com> <20070421102134.GE1262@mercury.ccil.org> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 12:49:58 +0200 Message-ID: <000001c78402$ce466770$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070421102134.GE1262@mercury.ccil.org> Thread-Index: AceD/t8GyO+Xc8j1SyaZNwv3/jUNXgAAkMsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfD7q-00084B-7f. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HfD7q-00084B-7f 90f0cfc98df154e37bfa620ed2253fc3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Kent Karlsson scripsit: > > > Are similar coverage lists (with implicit "or any other language in > > this group not explicitly listed") planned for ISO 639-5? > > Not as of the last time I saw a 639-5 draft, nor have I heard anything > to suggest it. Which means that figuring out what a "Tai language" is > will depend on encyclopedic information outside the standard, just as > figuring out what "English" is. > > FWIW, that draft is harmonized with 639-2, but does not have any > "(Other)" strings, so it takes the inclusive view of collections. Hmm, the "(Other)" has no semantic significance as ISO 639-2 is written. So the coverages for ISO 639-2 collection codes would be the same as for the corresponding (i.e. same) collection codes of ISO 639-5. > > for "collections", the collection code *should not* be used > > (even though it could) if there is a more specific code "available". > > Collection codes are useful for certain kinds of partial ignorance, > however. For example, if you are classifying documents, you > may know that a particular document is written in some Saami > language, but may lack the resources to figure out which one. > In that case, the collection code "smi" is appropriate. That I think may be fine, given that "available" is also interpreted along the dimension of "partial ignorance". Though that dimension of "available" is not clear, as many other details, from the text of ISO 639-2. > > This goes for 'mis' too, as it is just one of the collection codes, > > albeit the top level collection code. > > On that view of "mis" it represents total ignorance, which is > already well-represented by "und". Though not formally a collection code, if one wants to see it as a collection code, 'und' is more encompassing than 'mis', as 'und' covers not only what 'mis' covers, but it also covers 'zxx' and 'mul' which are not covered by 'mis'. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 11:29: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 1HfHX5-00041K-CG; Sat, 21 Apr 2007 11:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHX4-00041F-K9 for ltru@lists.ietf.org; Sat, 21 Apr 2007 11:29:50 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfHX3-0003IA-BC for ltru@lists.ietf.org; Sat, 21 Apr 2007 11:29:50 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 21 Apr 2007 08:29:48 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Sat, 21 Apr 2007 08:29:48 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Sat, 21 Apr 2007 08:29:44 -0700 Subject: RE: [Ltru] Re: Language Tag Special Cases Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceD23D8+7K14OKETDW2hWh2RWYBwwAEKeogAA9WKSA= Message-ID: References: <30b660a20704181623wdfbaafdk343466691a31c7d@mail.gmail.com> <4628E7A2.3030509@yahoo-inc.com> <005c01c78370$be904450$5072f853@streamserve.com> <462906EF.9040905@yahoo-inc.com> <005d01c78386$46d15a10$5072f853@streamserve.com> <20070421060757.GZ1262@mercury.ccil.org> <001801c783f7$81d46690$5072f853@streamserve.com> In-Reply-To: <001801c783f7$81d46690$5072f853@streamserve.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.5 (/) 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 From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] >> > I have no idea where you got the list of 133 specific >> languages from. >> >> http://www.ethnologue.com/14/show_iso639.asp?code=3Dmis , probably. > > That is just a snapshot of what was 'mis' but not "otherwise catalogued" > in a particular setting at a particular point in time. It's not the > definition of 'mis' in ISO 639 by any account. It isn't a normative definition, but it certainly is an analysis at that po= int in time that is consistent with the established interpretative traditio= n (as John so aptly put it). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 11:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHhK-0005cc-JV; Sat, 21 Apr 2007 11:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHhJ-0005cX-NZ for ltru@ietf.org; Sat, 21 Apr 2007 11:40:25 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfHhI-0006hK-F0 for ltru@ietf.org; Sat, 21 Apr 2007 11:40:25 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 21 Apr 2007 08:40:23 -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; Sat, 21 Apr 2007 08:40:23 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Sat, 21 Apr 2007 08:40:18 -0700 Subject: RE: [Ltru] Re: Language Tag Special Cases Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceD95WLtQ30jKyaR3aTcS9i6LTznQAMocGA Message-ID: References: <001901c783f7$96183c80$5072f853@streamserve.com> In-Reply-To: <001901c783f7$96183c80$5072f853@streamserve.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.5 (/) 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 From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > "Miscellaneous" does mean "anything". But it is an "anything" > for things not otherwise classified. *coverage* (everything) > vs. *recommended use* (not otherwise classified). I don't think I'd express things the way you do, but I start to think that,= in practical terms, our views are similar. Using an example, an application of ISO 639 could choose to use as its inve= ntory {eng, fra, deu, und, zxx, mis}, in which case mis would encompass Swe= dish and Italian and several thousand other languages *in that application = context*. I think you'd agree with that. In the context of BCP47, mis would encompass only a very small set of langu= ages (once 639-3 is included, a very small set indeed). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 11:41: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 1HfHiA-0007AJ-CU; Sat, 21 Apr 2007 11:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHi8-0007A9-TR for ltru@ietf.org; Sat, 21 Apr 2007 11:41:16 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfHi7-00077m-K5 for ltru@ietf.org; Sat, 21 Apr 2007 11:41:16 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 21 Apr 2007 08:41:15 -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; Sat, 21 Apr 2007 08:41:14 -0700 From: Peter Constable To: Kent Karlsson , "ltru@ietf.org" Date: Sat, 21 Apr 2007 08:41:10 -0700 Subject: RE: [Ltru] Re: "mis" update review request Thread-Topic: [Ltru] Re: "mis" update review request Thread-Index: AceD91lxWhG6PAGsRyiBT7gRGRXlwwANAlrg Message-ID: References: <001a01c783f7$cd4ee910$5072f853@streamserve.com> In-Reply-To: <001a01c783f7$cd4ee910$5072f853@streamserve.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Quite true. I had intended to write "a book in English on programming conce= pts". My mistake. Peter -----Original Message----- From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] Sent: Saturday, April 21, 2007 2:31 AM To: ltru@ietf.org Subject: RE: [Ltru] Re: "mis" update review request Peter Constable wrote: > I say your programming code example is a boundary case in the sense that > I don't expect to see .cxx, .h, etc. files tagged with language tags any > time soon, and I don=E2t expect to see a book on programming concepts tag= ged > as anything other than en, no matter how many pages of source code sample= s it has. Nit: There are many books on programming written in other languages than En= glish. /k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 16:25: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 1HfM96-0002co-UL; Sat, 21 Apr 2007 16:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfM95-0002ch-PG for ltru@ietf.org; Sat, 21 Apr 2007 16:25:23 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfM94-00087m-Fr for ltru@ietf.org; Sat, 21 Apr 2007 16:25:23 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:2953 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfM93-00006w-3g for ltru@ietf.org; Sat, 21 Apr 2007 22:25:21 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 22:27:47 +0200 Message-ID: <00d501c78453$86a23d80$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceEU4X6JcgZZIzgQrqkoRJplMZvnA== X-Scan-Result: No virus found in message 1HfM93-00006w-3g. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfM93-00006w-3g 4896059bc304ec1cbeee84dc4a00f5e3 X-Spam-Score: 0.5 (/) 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 Peter Constable wrote: > From: Kent Karlsson > > > "Miscellaneous" does mean "anything". But it is an "anything" > > for things not otherwise classified. *coverage* (everything) > > vs. *recommended use* (not otherwise classified). > > I don't think I'd express things the way you do, but I start > to think that, in practical terms, our views are similar. > > Using an example, an application of ISO 639 could choose to use > as its inventory {eng, fra, deu, und, zxx, mis}, in which case > mis would encompass Swedish and Italian and several thousand other > languages *in that application context*. Yes. > I think you'd agree with that. > > In the context of BCP47, mis would encompass only a very small set of > languages (once 639-3 is included, a very small set indeed). Yes, modulo the possibility that 'mis' and other collection codes maybe (as John Cowan suggested) could be used for a partial information scenario. E.g. 'smi' - this has been determined (or deemed) to have a Saami language content, but have not determined (yet) which Saami language; 'mis' - this has been determined (or deemed) to have content in a (one) natural language, but have not determined (yet) which one; 'und' - no determination made (yet), may be in one or more natural languages, or may (predominantly) be something else. But that is not clear from the text of 639-2, nor IIRC from the much longer and intricate BCP47 text, that collection codes can be used like that, just that 'und' can be used like that. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 17:03: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 1HfMkN-0000gG-3f; Sat, 21 Apr 2007 17:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfMkL-0000fy-MI for ltru@ietf.org; Sat, 21 Apr 2007 17:03:53 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfMkK-00053Z-Do for ltru@ietf.org; Sat, 21 Apr 2007 17:03:53 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 21 Apr 2007 14:03:51 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Sat, 21 Apr 2007 14:03:51 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Sat, 21 Apr 2007 14:03:39 -0700 Subject: RE: [Ltru] Re: Language Tag Special Cases Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceEU4X6JcgZZIzgQrqkoRJplMZvnAABGT6w Message-ID: References: <00d501c78453$86a23d80$5072f853@streamserve.com> In-Reply-To: <00d501c78453$86a23d80$5072f853@streamserve.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.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > 'mis' - this has been determined (or deemed) to have content in a (one) > natural language, but have not determined (yet) which one; This is where we depart. Here, I'd use 'und'. Again, in the context of BCP4= 7, I consider mis to encompass a fairly small set of languages. I don't hav= e a big problem with 'smi' when the confidence level is at the level of "it= 's a Saami language", but I still maintain that 'mis' is for the exceptions= not covered by available IDs, and 'und' is for the general "don't know" ca= se. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 17:14: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 1HfMv1-00011L-DT; Sat, 21 Apr 2007 17:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfMv1-00011G-4I for ltru@ietf.org; Sat, 21 Apr 2007 17:14:55 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfMuz-00011t-Hk for ltru@ietf.org; Sat, 21 Apr 2007 17:14: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 <20070421211453.XFYB14403.mta9.adelphia.net@DGBP7M81>; Sat, 21 Apr 2007 17:14:53 -0400 Message-ID: <00bb01c7845a$1ac96dc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <20070421100003.4EFBF259764@eikenes.alvestrand.no> Date: Sat, 21 Apr 2007 14:14:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Re: "mis" update review request X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (Cross-posted as an exception to my usual practice.) John Cowan wrote: > You have for whatever reason decided that reading and writing code > (presumably exclusive of comments, which are unquestionably in English > or French or Japanese or what have you) is linguistic behavior, but > why? Learning to program is very unlike either acquiring French or > Esperanto as a first language, or learning them as a second language, > though admittedly more like the latter than the former. Are you also > willing to say that mathematical formulae embedded in a math paper in > English, French, German, Russian, or what have you are linguistic > content, though certainly not in any of those languages? While I continue not to lose any sleep over this, I agree completely with the content and tone of this posting and John's others. Programming languages have always been out of scope for BCP 47. Asserting that source code (e.g.) needs to be provided with a BCP 47 tag is not just a question of broadening one subtag or another, but of redefining the scope of BCP 47. We could easily find ourselves embroiled in the whole Morse code, dance notation, smoke signals debate, which I'm fairly sure is not what most of us want. I suggest: x-src-c x-src-pascal x-src-fortran x-src-sql x-src-postscrp and so forth, but only if absolutely necessary. -- 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 Apr 21 17:23: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 1HfN3b-0001bQ-Ip; Sat, 21 Apr 2007 17:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfN3a-0001bL-K3 for ltru@ietf.org; Sat, 21 Apr 2007 17:23:46 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfN3Z-0003EO-9W for ltru@ietf.org; Sat, 21 Apr 2007 17:23:46 -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 <20070421212343.DTLM13783.mta13.adelphia.net@DGBP7M81> for ; Sat, 21 Apr 2007 17:23:43 -0400 Message-ID: <00c901c7845b$56f89310$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 21 Apr 2007 14:23: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > 'mis' is NOT a "special" code in the 639 sense. It is a collection > code (among many other collection codes). The only thing "special" > about it is that it is the "top level" collection (in the inclusion > hierarchy), but that does not make it "special" in the ISO 639 sense. It is a special code from the standpoint of RFC 4646, and it is *not* just like all the other collections. As John tried to point out some time ago, the concept of "miscellaneous" generally implies "does not fit into any other category," and does not imply "fits into all categories." -- 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 Apr 21 17:39: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 1HfNJ7-0002Gy-9R; Sat, 21 Apr 2007 17:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfNJ6-0002ED-PD for ltru@ietf.org; Sat, 21 Apr 2007 17:39:48 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfNJ5-0000Ta-GC for ltru@ietf.org; Sat, 21 Apr 2007 17:39:48 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1679 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfNJ4-0007Nz-3m; Sat, 21 Apr 2007 23:39:46 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 23:42:09 +0200 Message-ID: <00d901c7845d$ebde5530$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00c901c7845b$56f89310$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceEW1suMyjTeWNgT4qfBJ8ivBdUGQAAaPog X-Scan-Result: No virus found in message 1HfNJ4-0007Nz-3m. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfNJ4-0007Nz-3m 6fd2910cdfb068358589b4146f18c72d X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: > Kent Karlsson wrote: > > > 'mis' is NOT a "special" code in the 639 sense. It is a collection > > code (among many other collection codes). The only thing "special" > > about it is that it is the "top level" collection (in the inclusion > > hierarchy), but that does not make it "special" in the ISO 639 sense. > > It is a special code from the standpoint of RFC 4646, and it is *not* > just like all the other collections. That is not true. 'mis' is not taken out as a special case in 4646, nor should it be. It thus works just like in 639-*, and there it is one of the collection codes, and work just like all the other collection codes. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 18:30: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 1HfO66-0005gQ-9V; Sat, 21 Apr 2007 18:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfO66-0005gL-0U for ltru@ietf.org; Sat, 21 Apr 2007 18:30:26 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfO64-0003wo-Ni for ltru@ietf.org; Sat, 21 Apr 2007 18:30:25 -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 <20070421223022.KKQA16517.mta11.adelphia.net@DGBP7M81>; Sat, 21 Apr 2007 18:30:22 -0400 Message-ID: <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81> <00d901c7845d$ebde5530$5072f853@streamserve.com> Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 15:30: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: >>> 'mis' is NOT a "special" code in the 639 sense. It is a collection >>> code (among many other collection codes). The only thing "special" >>> about it is that it is the "top level" collection (in the inclusion >>> hierarchy), but that does not make it "special" in the ISO 639 >>> sense. >> >> It is a special code from the standpoint of RFC 4646, and it is *not* >> just like all the other collections. > > That is not true. 'mis' is not taken out as a special case in 4646, > nor should it be. It thus works just like in 639-*, and there it is > one of the collection codes, and work just like all the other > collection codes. Peter has repeatedly tried to show that the intent of "mis", going back to its MARC origin, has always been to mean "languages not covered by any other individual or collection code." -- 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 Apr 21 19:19: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 1HfOrb-0007Nd-I4; Sat, 21 Apr 2007 19:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfOra-0007NY-OD for ltru@ietf.org; Sat, 21 Apr 2007 19:19:30 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfOrZ-0000GY-ER for ltru@ietf.org; Sat, 21 Apr 2007 19:19:30 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ITpbBozchSSf9CHODk4x7eDHQdW0lcBZaIpKJqC/NuWrYHkDCAIfv8eRPhJ8+zlk; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.199] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HfOrY-0006yS-Mh for ltru@ietf.org; Sat, 21 Apr 2007 19:19:28 -0400 Message-ID: <001001c7846b$cdebd3a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 16:21: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7e12bca79392eb1dff85c0e1f8dae2244350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.199 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Kent Karlsson" > Sent: Saturday, April 21, 2007 3:30 PM > Subject: Re: [Ltru] Re: Language Tag Special Cases ... > Peter has repeatedly tried to show that the intent of "mis", going back > to its MARC origin, has always been to mean "languages not covered by > any other individual or collection code." ... The cases where "mis" would be of use for our purposes seem to be vanishingly small. If the recognizer can identify the language(s) of the material, there are three possibilities that seem practical to me: (1) an existing language code (2) a meaningful collection code (3) a private-use code until a tag for the language in question has been registered The members of the set of languages in "mis" are so scattered that I'd really be surprised if anyone built a recognizer that would be able to figure out "it's one of the mis languages, but I can't say which one". If the recognizer doesn't recognize the language of the material, "mis" isn't appropriate. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 19:35:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfP73-0002aS-3e; Sat, 21 Apr 2007 19:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfP72-0002aN-Cp for ltru@ietf.org; Sat, 21 Apr 2007 19:35:28 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfP71-0004aB-47 for ltru@ietf.org; Sat, 21 Apr 2007 19:35:28 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:2321 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfP70-0005hd-4T; Sun, 22 Apr 2007 01:35:26 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sun, 22 Apr 2007 01:37:50 +0200 Message-ID: <000001c7846e$145ee1e0$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceEZKyPhtRPE0BDSK6bKXBn76PiqwAAh4Eg In-Reply-To: <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfP70-0005hd-4T. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfP70-0005hd-4T 2123636fc3630dd0ab6e2a202db86e5a X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think you should catch up on your LTRU email backlog... Peter and I are actually in agreement, it seems. (Not that I have changed my mind in any way, after reading the ISO 639-2 text.) /kent k > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Sunday, April 22, 2007 12:30 AM > To: LTRU Working Group > Cc: Kent Karlsson > Subject: Re: [Ltru] Re: Language Tag Special Cases ... > Peter has repeatedly tried to show that the intent of "mis", > going back > to its MARC origin, has always been to mean "languages not covered by > any other individual or collection code." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 19:48: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 1HfPJH-000721-RW; Sat, 21 Apr 2007 19:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPJG-0006zJ-J7 for ltru@ietf.org; Sat, 21 Apr 2007 19:48:06 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfPJF-000708-AS for ltru@ietf.org; Sat, 21 Apr 2007 19:48: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 <20070421234804.QDLL16517.mta11.adelphia.net@DGBP7M81>; Sat, 21 Apr 2007 19:48:04 -0400 Message-ID: <00e901c7846f$819720f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> <000001c7846e$145ee1e0$5072f853@streamserve.com> Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 16:48:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > I think you should catch up on your LTRU email backlog... > Peter and I are actually in agreement, it seems. (Not that > I have changed my mind in any way, after reading the > ISO 639-2 text.) On Sat, 21 Apr 2007 08:40:18 -0700, Peter Constable wrote: > Using an example, an application of ISO 639 could choose to use as its > inventory {eng, fra, deu, und, zxx, mis}, in which case mis would > encompass Swedish and Italian and several thousand other languages *in > that application context*. > > I think you'd agree with that. > > In the context of BCP47, mis would encompass only a very small set of > languages (once 639-3 is included, a very small set indeed). -- 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 Apr 21 19:52: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 1HfPNz-0001zT-89; Sat, 21 Apr 2007 19:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPNx-0001ta-W7 for ltru@ietf.org; Sat, 21 Apr 2007 19:52:58 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfPNw-0008P8-Hd for ltru@ietf.org; Sat, 21 Apr 2007 19:52:57 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:2907 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfPNv-0005lu-5S; Sun, 22 Apr 2007 01:52:56 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> <000001c7846e$145ee1e0$5072f853@streamserve.com> <00e901c7846f$819720f0$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sun, 22 Apr 2007 01:55:21 +0200 Message-ID: <000201c78470$85c3e540$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceEb4t/7Kziz9V9Qz69+9PwEs/LRQAAIVMg In-Reply-To: <00e901c7846f$819720f0$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfPNv-0005lu-5S. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HfPNv-0005lu-5S 78f50bd8e1c5b5c07b1bf496d3940302 X-Spam-Score: 0.5 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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, Since you still don't seem to have caught up with your backlog, I'd better repeat my reply to Peter on the email you just copied (I seem to have to repeat myself quite a lot): > -----Original Message----- > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > Sent: Saturday, April 21, 2007 10:28 PM > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language Tag Special Cases > > Peter Constable wrote: > > From: Kent Karlsson > > > > > "Miscellaneous" does mean "anything". But it is an "anything" > > > for things not otherwise classified. *coverage* (everything) > > > vs. *recommended use* (not otherwise classified). > > > > I don't think I'd express things the way you do, but I start > > to think that, in practical terms, our views are similar. > > > > Using an example, an application of ISO 639 could choose to use > > as its inventory {eng, fra, deu, und, zxx, mis}, in which case > > mis would encompass Swedish and Italian and several thousand other > > languages *in that application context*. > > Yes. > > > I think you'd agree with that. > > > > In the context of BCP47, mis would encompass only a very small set of > > languages (once 639-3 is included, a very small set indeed). > > Yes, modulo the possibility that 'mis' and other collection codes > maybe (as John Cowan suggested) could be used for a partial > information > scenario. E.g. > > 'smi' - this has been determined (or deemed) to have a Saami language > content, but have not determined (yet) which Saami language; > > 'mis' - this has been determined (or deemed) to have content > in a (one) > natural language, but have not determined (yet) which one; > > 'und' - no determination made (yet), may be in one or more natural > languages, or may (predominantly) be something else. > > But that is not clear from the text of 639-2, nor IIRC from the > much longer and intricate BCP47 text, that collection codes can > be used like that, just that 'und' can be used like that. > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 19:59: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 1HfPUf-0007b3-Gr; Sat, 21 Apr 2007 19:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPUd-0007ax-ME for ltru@ietf.org; Sat, 21 Apr 2007 19:59:51 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfPUc-00022t-EG for ltru@ietf.org; Sat, 21 Apr 2007 19:59:51 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 21 Apr 2007 16:59:49 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Sat, 21 Apr 2007 16:59:49 -0700 From: Peter Constable To: 'LTRU Working Group' Date: Sat, 21 Apr 2007 16:59:43 -0700 Subject: RE: [Ltru] Re: Language Tag Special Cases Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceEb4t/7Kziz9V9Qz69+9PwEs/LRQAAIVMgAAA5XjA= Message-ID: References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> <000001c7846e$145ee1e0$5072f853@streamserve.com> <00e901c7846f$819720f0$6401a8c0@DGBP7M81> <000201c78470$85c3e540$5072f853@streamserve.com> In-Reply-To: <000201c78470$85c3e540$5072f853@streamserve.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: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > Since you still don't seem to have caught up with your backlog, > I'd better repeat my reply to Peter on the email you just copied Actually, you also are not caught up. I agree with you on some points, but = I do not agree with you on all, including how mis should be used in the BCP= 47 context. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 20:08: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 1HfPcx-0007aP-QP; Sat, 21 Apr 2007 20:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPcw-0007Yk-QP for ltru@ietf.org; Sat, 21 Apr 2007 20:08:26 -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 1HfPcv-0004Cj-FQ for ltru@ietf.org; Sat, 21 Apr 2007 20:08:26 -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 <20070422000824.HGIF26916.mta16.adelphia.net@DGBP7M81>; Sat, 21 Apr 2007 20:08:24 -0400 Message-ID: <00f101c78472$58c45af0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com> <00dd01c78464$a66966f0$6401a8c0@DGBP7M81> <000001c7846e$145ee1e0$5072f853@streamserve.com> <00e901c7846f$819720f0$6401a8c0@DGBP7M81> <000201c78470$85c3e540$5072f853@streamserve.com> Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 17:08:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > Since you still don't seem to have caught up with your backlog, > I'd better repeat my reply to Peter on the email you just copied > (I seem to have to repeat myself quite a lot): I subscribe to the digest, and only received your most recent exchange with Peter a minute ago. You wrote: > 'mis' - this has been determined (or deemed) to have content in a > (one) natural language, but have not determined (yet) which one; and Peter replied: > This is where we depart. Here, I'd use 'und'. Again, in the context of > BCP47, I consider mis to encompass a fairly small set of languages. I > don't have a big problem with 'smi' when the confidence level is at > the level of "it's a Saami language", but I still maintain that 'mis' > is for the exceptions not covered by available IDs, and 'und' is for > the general "don't know" case. I wonder which one of us needs to catch up. -- 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 Apr 21 20: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 1HfPld-0007Zr-Er; Sat, 21 Apr 2007 20:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfPlb-0007Zm-RC for ltru@ietf.org; Sat, 21 Apr 2007 20:17:23 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfPlb-0006Iv-IC for ltru@ietf.org; Sat, 21 Apr 2007 20:17:23 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SUgwNe1u5uRFqw5J5ePltQnS1dmAD6uHazXkk12t82xOJqSxhAe7zS2bEgJ6YkF1; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.199] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HfPla-0005qC-Qg for ltru@ietf.org; Sat, 21 Apr 2007 20:17:23 -0400 Message-ID: <01af01c78473$e460c0c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <00c901c7845b$56f89310$6401a8c0@DGBP7M81><00d901c7845d$ebde5530$5072f853@streamserve.com><00dd01c78464$a66966f0$6401a8c0@DGBP7M81><000001c7846e$145ee1e0$5072f853@streamserve.com><00e901c7846f$819720f0$6401a8c0@DGBP7M81> <000201c78470$85c3e540$5072f853@streamserve.com> Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sat, 21 Apr 2007 17:19:27 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd71a4a85f5d3ce472b1e0636ca62c860c4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.199 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Kent Karlsson" > To: "'Doug Ewell'" > Cc: "'LTRU Working Group'" > Sent: Saturday, April 21, 2007 4:55 PM > Subject: RE: [Ltru] Re: Language Tag Special Cases > > Doug, > > Since you still don't seem to have caught up with your backlog, > I'd better repeat my reply to Peter on the email you just copied > (I seem to have to repeat myself quite a lot): I must admit to sharing in Doug's bewilderment. See below. > > > -----Original Message----- > > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > > Sent: Saturday, April 21, 2007 10:28 PM > > To: ltru@ietf.org > > Subject: RE: [Ltru] Re: Language Tag Special Cases > > > > Peter Constable wrote: > > > From: Kent Karlsson > > > > > > > "Miscellaneous" does mean "anything". But it is an "anything" > > > > for things not otherwise classified. *coverage* (everything) > > > > vs. *recommended use* (not otherwise classified). > > > > > > I don't think I'd express things the way you do, but I start > > > to think that, in practical terms, our views are similar. > > > > > > Using an example, an application of ISO 639 could choose to use > > > as its inventory {eng, fra, deu, und, zxx, mis}, in which case > > > mis would encompass Swedish and Italian and several thousand other > > > languages *in that application context*. > > > > Yes. > > > > > I think you'd agree with that. > > > > > > In the context of BCP47, mis would encompass only a very small set of > > > languages (once 639-3 is included, a very small set indeed). > > > > Yes, modulo the possibility that 'mis' and other collection codes > > maybe (as John Cowan suggested) could be used for a partial > > information > > scenario. E.g. > > > > 'smi' - this has been determined (or deemed) to have a Saami language > > content, but have not determined (yet) which Saami language; > > > > 'mis' - this has been determined (or deemed) to have content > > in a (one) > > natural language, but have not determined (yet) which one; I disagree. mis is appropriate only if the language is known to be a language not covered by any other grouping, and the tagger has decided for some perverse reason that using that language's code would be inappropriate. The case you describe would be more appropriately handled by 'und'. > > 'und' - no determination made (yet), may be in one or more natural > > languages, or may (predominantly) be something else. > > > > But that is not clear from the text of 639-2, nor IIRC from the > > much longer and intricate BCP47 text, that collection codes can > > be used like that, just that 'und' can be used like that. The RFC 4646 text seems quite clear about the use of 'und': 4. The 'und' (Undetermined) primary language subtag SHOULD NOT be used to label content, even if the language is unknown. Omitting the language tag altogether is preferred to using a tag with a primary language subtag of 'und'. The 'und' subtag MAY be useful for protocols that require a language tag to be provided. The 'und' subtag MAY also be useful when matching language tags in certain situations. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 21 21:19: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 1HfQjU-0002CB-0F; Sat, 21 Apr 2007 21:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfQjT-0002C5-05 for ltru@ietf.org; Sat, 21 Apr 2007 21:19:15 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfQjP-0003Hy-N6 for ltru@ietf.org; Sat, 21 Apr 2007 21:19:14 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id E6CD81E136D for ; Sat, 21 Apr 2007 18:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at sharplabs.com Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWpAQSZEACrM for ; Sat, 21 Apr 2007 18:19:05 -0700 (PDT) Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8]) by mail2.sharplabs.com (Postfix) with ESMTP id 19BB31E1355 for ; Sat, 21 Apr 2007 18:19:05 -0700 (PDT) Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 18:19:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Apr 2007 18:19:04 -0700 Message-ID: <811D382F92501D4EB5F748D2BF9EFBB92B9C55@wabex2.sharpamericas.com> In-Reply-To: <01af01c78473$e460c0c0$6601a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Language Tag Special Cases Thread-Index: AceEc54ye1BNP+M2TTqLtjwvRGouyAAEGdDA From: "McDonald, Ira" To: "LTRU Working Group" X-OriginalArrivalTime: 22 Apr 2007 01:19:05.0086 (UTC) FILETIME=[37D4E9E0:01C7847C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: Language Tag Special Cases X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0049839380==" Errors-To: ltru-bounces@ietf.org --===============0049839380== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBtZWFuaW5nIG9mICdtaXMnIChpbiBJU08gNjM5LSopIGlzIG9idmlvdXNseSBn b2luZyB0bw0KY2hhbmdlIG92ZXIgdGltZS4gIFRoZXJlIGlzIG5vIHBvc3NpYmxlICpzYWZlKiB1 c2Ugb2YgJ21pcycNCmluIHRoZSBCQ1A0NyBjb250ZXh0Lg0KDQpSRkM0NjQ2YmlzIHNob3VsZCBl eHBsaWNpdGx5IHByb2hpYml0IHRoZSB1c2Ugb2YgJ21pcycuDQoNCkRpZ2l0YWwgaW5rIGlzIGNo ZWFwLCBidXQgcmVhbGx5IGZvbGtzIHRoaXMgaXMgZmFyIHRvbyBtdWNoDQpvZiBhIHdhc3RlIG9m IGV2ZXJ5b25lJ3MgdGltZS4NCg0KQ2hlZXJzLA0KLSBJcmENCg0KSXJhIE1jRG9uYWxkIChNdXNp Y2lhbiAvIFNvZnR3YXJlIEFyY2hpdGVjdCkNCkNoYWlyIC0gTGludXggRm91bmRhdGlvbiBPcGVu IFByaW50aW5nIFdHDQpCbHVlIFJvb2YgTXVzaWMgLyBIaWdoIE5vcnRoIEluYw0KUE8gQm94IDIy MSAgR3JhbmQgTWFyYWlzLCBNSSAgNDk4MzkNCnBob25lOiArMS05MDYtNDk0LTI0MzQNCmVtYWls OiBpbWNkb25hbGRAc2hhcnBsYWJzLmNvbQ0KDQpObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG91dGdv aW5nIG1lc3NhZ2UuDQpDaGVja2VkIGJ5IEFWRyBGcmVlIEVkaXRpb24uIA0KVmVyc2lvbjogNy41 LjQ2MyAvIFZpcnVzIERhdGFiYXNlOiAyNjkuNS43Lzc3MSAtIFJlbGVhc2UgRGF0ZTogNC8yMS8y MDA3IDExOjU2IEFNDQogDQo= --===============0049839380== 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 --===============0049839380==-- From ltru-bounces@ietf.org Sun Apr 22 06:54: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 1HfZhh-0003NZ-Ot; Sun, 22 Apr 2007 06:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZhg-0003KD-7I for ltru@ietf.org; Sun, 22 Apr 2007 06:54:00 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfZhf-0007zx-Ol for ltru@ietf.org; Sun, 22 Apr 2007 06:54:00 -0400 Received: from c83-248-114-80.bredband.comhem.se ([83.248.114.80]:1967 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfZhd-0002Av-7i; Sun, 22 Apr 2007 12:53:57 +0200 From: "Kent Karlsson" To: "'McDonald, Ira'" , "'Doug Ewell'" References: <01af01c78473$e460c0c0$6601a8c0@oemcomputer> <811D382F92501D4EB5F748D2BF9EFBB92B9C55@wabex2.sharpamericas.com> Subject: RE: [Ltru] Re: Language Tag Special Cases Date: Sun, 22 Apr 2007 12:56:17 +0200 Message-ID: <001801c784cc$dec0ca80$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceEc54ye1BNP+M2TTqLtjwvRGouyAAEGdDAABC+3uA= In-Reply-To: <811D382F92501D4EB5F748D2BF9EFBB92B9C55@wabex2.sharpamericas.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfZhd-0002Av-7i. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HfZhd-0002Av-7i bad2a3dcb00d8b63b2e44012020f5f08 X-Spam-Score: 2.3 (++) 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 (Catching up ;-) Peter Constable wrote: > > 'mis' - this has been determined (or deemed) to have content in a (one) > > natural language, but have not determined (yet) which one; > This is where we depart. Actually, using collection tags (not just the special code 'und') this way was John Cowan's suggestion. (And recall that according to 639, 'mis' is just a collection tag, there is nothing special or exceptional about it standardswise.) > Here, I'd use 'und'. One can use 'und', but 'und' is even more undetermined than 'mis' (if you allow collection codes for the partial information scenario). > Again, in the context of BCP47, > I consider mis to encompass a fairly small set of languages. The recommended use would be very small, yes. EXACTLY THE SAME goes for ALL of the collection codes in a 4646bis context which has a separate code for each (known, semi-modern, natural) language. > I don't have a > big problem with 'smi' when the confidence level is at the level > of "it's a Saami language", If you take the recommended use restriction strictly, 'smi' "can"/ "should" only be used for Saami languages that have no code of their own (in a 4646bis context, or even a 4646 context, as both provide several more specific Saami codes). As another example: In a 4646 (and current registry content), 'cpp' is the only recommended available code for Cap Verdian (Kabuverdianu). But in a 4646bis context (given the draft registry) 'kea' would be the only recommended available code for Cap Verdian. 'cpp', and indeed 'mis', as well as the special code 'und', are still valid for Kabuverdianu, as the coverage (of course) does not change, but the recommended use changes as the more specific code 'kea' becomes available. > but I still maintain that 'mis' is for the exceptions not > covered by available IDs, and 'und' is for the general "don't know" case. There is no exception in principle between 'mis' and the other collection codes, neither in 639, nor in 4646, nor should there be in 4646bis. 'mis' covers all natural languages, but the recommended use would be to only use it for languages for which "an individual language code or another more specific collective language code is available" does not hold. Note again that this phrase, quoted from the 639-2 standard, does not even make sense for 'mis' if 'mis' does not COVER ALL languages. There is a difference between COVERAGE on one hand, and RECOMMENDED USE on the other. The 639-2 standard itself does not seem to favour a partial information interpretation for any of the collection codes, only for 'und'. But if you allow a partial information scenario, as John Cowan suggested (not at all clear that the normative text of 639-2 covers such use), there is no reason to take out 'mis' as a special case. Taking two different approaches at the same time (one for some collection codes, another for another set of collection codes) would be inconsistent. ============================================================= McDonald, Ira wrote: > The meaning of 'mis' (in ISO 639-*) is obviously going to > change over time. There is no possible *safe* use of 'mis' > in the BCP47 context. The *coverage* of 'mis' does not really change over time, the coverage of 'mis' is the scope of the 639 standards. Likewise, the *coverage* of 'smi' does not change much over time (language development and diversification is slow), but the *recommended use* for any of the collection codes may change in an instant (if one takes aboard another Saami language code not previously used in that 639 use context). The *recommended use*, however, not only may change over time, but also over each application context of 639 (see above). > RFC4646bis should explicitly prohibit the use of 'mis'. Either we prohibit all of the collection codes, or none of them (in 4646bis). Or allow for a partial information interpretation for all of the collection codes, in a consistent manner, or for none of the collection codes. > Digital ink is cheap, but really folks this is far too much > of a waste of everyone's time. Well, I think we need to flesh this out, so that the interpretation and possible (or not) use of collection codes is made clear. (Though I do think 639(-2) is rather clear on 'mis'; it's not all that hard, strange, or exceptional at all. But it is very succinctly formulated in 639-2.) /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 22 09:42: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 1HfcKN-0000ev-Fx; Sun, 22 Apr 2007 09:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfcKL-0000dq-A6 for ltru@ietf.org; Sun, 22 Apr 2007 09:42:05 -0400 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfcKK-0002iz-0D for ltru@ietf.org; Sun, 22 Apr 2007 09:42:05 -0400 Received: (qmail 82004 messnum 6418262 invoked from network[194.125.174.98/ts09-098.dublin.indigo.ie]); 22 Apr 2007 13:42:01 -0000 Received: from ts09-098.dublin.indigo.ie (HELO ?194.125.174.98?) (194.125.174.98) by mail00.svc.cra.dublin.eircom.net (qp 82004) with SMTP; 22 Apr 2007 13:42:01 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Message-Id: <11633FB7-31A8-45A4-8F46-749C489CF519@egt.ie> From: Marion Gunn Subject: Re: [Ltru] Re: Language Tag Special Cases Date: Sun, 22 Apr 2007 14:43:35 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308056711==" Errors-To: ltru-bounces@ietf.org --===============0308056711== Content-Type: multipart/alternative; boundary=Apple-Mail-2--770163596 --Apple-Mail-2--770163596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed I agree with what Karen says below. Even without the 'oxy-'.:-) Having received 62 LTRU msgs in 24 hrs, all but 2 from the US, I only =20= read her 2 (not because I expect the others to be relatively info-=20 empty, but because non-US msgs are tending towards more favourable =20 noise-2-content ratios recently). mg On 20 Apr 2007, at 17:24, scr=EDobh Karen_Broome@spe.sony.com: > ... > The Zxxx script tag and Zxx tag would have been better defined as =20 > "Not Applicable" which is the semantic suggested below. The =20 > concepts of "non-linguistic language" and "unwritten script" are =20 > oxymoronic. - - 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--770163596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I agree with what Karen says = below.=A0


Even = without the 'oxy-'.:-)

Having received 62 LTRU = msgs in 24 hrs, all but 2 from the US, I only read her 2 (not because I = expect the others to be relatively info-empty, but because non-US msgs = are tending towards more favourable noise-2-content ratios = recently).
mg

On 20 Apr 2007, at 17:24, = scr=EDobh Karen_Broome@spe.sony.com:
...
The Zxxx = script tag and Zxx tag would have been better defined as "Not = Applicable" which is the semantic suggested below. The concepts of = "non-linguistic language" and "unwritten script" are = oxymoronic.

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

= --Apple-Mail-2--770163596-- --===============0308056711== 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 --===============0308056711==-- From ltru-bounces@ietf.org Sun Apr 22 11:22:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfdtc-0006lK-Qx; Sun, 22 Apr 2007 11:22:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfdtb-0006lD-Lo for ltru@ietf.org; Sun, 22 Apr 2007 11:22:35 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfdta-0007al-72 for ltru@ietf.org; Sun, 22 Apr 2007 11:22:35 -0400 Received: from [10.76.40.54] (UNKNOWN-10-76-40-54.yahoo.com [10.76.40.54] (may be forged)) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3MFMOB6066511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Apr 2007 08:22:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=2g0RnnlSxrOVhunWBhosV4VoxhDypMmaxta5jajRBrZnUwGOGlwS6G7/EpYvCMNB Message-ID: <462B7DAF.2010405@yahoo-inc.com> Date: Sun, 22 Apr 2007 16:22:23 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Ltru] updated editor's copy to deal with 'mis', etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I have posted an updated editor's copy (draft-05) to my web site incorporating my proposed text to deal with the 'mis' mess. I haven't submitted it yet (I still need to run the various tools on it, etc.). http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.xml http://tinyurl.com/2kctcy (wdiff) In particular, it differs from my informal proposal as follows: 1. Some minor wordsmithing to deal with Mark's observations about my use of "cannot be determined" wrt the 'und' subtag. 2. Some additions to allow the use of 'und', etc. as a prefix when the additional information is useful. 3. The addition of "i-default" to the list of items deal with (per John Cowan). 4. The addition of the MARC 21 reference. I also took the examples for 'zxx' from MARC 21's equivalent code (which is three spaces). Note that this includes Frank's desire to allow program source code to be identified (although the text obliquely uses the phrase "machine language"). Here is the resulting text: -- 5. [ISO639-2] has defined several codes included in the subtag registry that have special meaning in the context of a language tag. In cases where omitting the language tag is permitted, such omission preferable to using these codes. Language tags SHOULD NOT incorporate these subtags as a prefix, unless the additional information conveys some value to the application. 1. The 'mul' (Multiple) primary language subtag is used to identify content in multiple languages. It SHOULD NOT be used when a list of languages (such as Content-Language) or individual tags for each content element can be used instead. 2. The "und' (Undetermined) primary language subtag is used to identify linguistic content whose language is not known. It SHOULD NOT be used unless a language tag is required and language information is not available or cannot be determined. Omitting the language tag (where permitted) is preferred. The 'und' subtag MAY be useful for protocols that require a language tag to be provided. The 'und' subtag MAY also be useful when matching language tags in certain situations. 3. The 'zxx' (Non-Linguistic) primary language subtag is used to identify content that has no language. Some examples might include instrumental or electronic music; sound recordings consisting of nonverbal sounds; audiovisual materials with no narration, printed titles, or subtitles; machine-readable data files consisting of machine languages or character codes. It SHOULD NOT be used unless a language tag is required by some application or protocol and the content is non-linguistic. 4. The 'mis' (Miscellaneous) primary language subtag is used to identify linguistic content whose language is known but cannot otherwise be identified. It is commonly used when the range of language tags is constrained (for example, to the set defined for use in the [MARC21] standard, for example) or for languages not otherwise categorized. It SHOULD NOT be used unless a language tag is required and no other means of identifying the language is available. 5. The grandfathered tag "i-default" (Default Language) was originally registered according to [RFC1766] to meet the needs of [RFC2277]. It is used to indicate not a specific language, but rather, it identifies the condition or content used where the language preferences of the user cannot be established. It SHOULD NOT be used except as a means of labeling the default content for applications or protocols that require default language content to be labeled with that specific tag. It MAY also be used by an application or protocol to identify when the default language content is being returned. -- Comments? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 22 11:39: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 1HfeAM-00055J-E7; Sun, 22 Apr 2007 11:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfeAL-00055E-8P for ltru@ietf.org; Sun, 22 Apr 2007 11:39:53 -0400 Received: from smtp809.mail.ird.yahoo.com ([217.146.188.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfeAJ-0007fE-Ks for ltru@ietf.org; Sun, 22 Apr 2007 11:39:53 -0400 Received: (qmail 67832 invoked from network); 22 Apr 2007 15:39:50 -0000 Received: from unknown (HELO DELL3) (brian.silver@btinternet.com@86.137.193.18 with login) by smtp809.mail.ird.yahoo.com with SMTP; 22 Apr 2007 15:39:50 -0000 X-YMail-OSG: celi5BkVM1l1YH3j7zwMOyHFmMAarrOq3NDP2OLTCeqOBm2fYXTUrAKBwXyiqX2Z..vqcNfPIQ-- Message-ID: <001601c784f4$76acc7f0$0201a8c0@DELL3> From: "Stephen Silver" To: Date: Sun, 22 Apr 2007 16:39:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] recommended case of language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There is a minor problem related to the recommended case of language tags. (This is not new - the paragraphs in question are unchanged from RFC 4646.) Section 2.1 says: 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. So, for example, here are three grandfathered tags in recommended format: sgn-BE-fr sgn-BE-nl sgn-CH-de Section 2.1 continues: In this format, all non-initial two-letter subtags are uppercase, But this is incorrect for the three tags cited above. (I think these three tags are the only ones where such a problem occurs.) The error is repeated in section 4.4: When performing canonicalization of language tags, processors MAY regularize the case of the subtags (that is, this process is OPTIONAL), following the case used in the registry. Note that this corresponds to the following casing rules: uppercase all non-initial two-letter subtags; titlecase all non-initial four-letter subtags; lowercase everything else. -- Stephen Silver _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 22 13: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 1Hffjh-0004IZ-Us; Sun, 22 Apr 2007 13:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hffjh-0004HA-8o for ltru@ietf.org; Sun, 22 Apr 2007 13:20:29 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hffjf-0005S9-UC for ltru@ietf.org; Sun, 22 Apr 2007 13:20: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 <20070422172027.YOHR19599.mta10.adelphia.net@DGBP7M81> for ; Sun, 22 Apr 2007 17:20:27 +0000 Message-ID: <011001c78502$856a6640$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 22 Apr 2007 10:20:27 -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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Ltru] Re: recommended case of language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephen Silver wrote: > There is a minor problem related to the recommended case of language > tags. (This is not new - the paragraphs in question are unchanged > from RFC 4646.) The wording in sections 2.1 and 4.4 about "recommended" casing does not really apply to grandfathered tags, which were cased the way they were for particular reasons. It also should not apply to private-use tags. We should consider adding a statement to 4646bis that clarifies this. > Section 2.1 says: > > 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. > > So, for example, here are three grandfathered tags in recommended > format: > > sgn-BE-fr > sgn-BE-nl > sgn-CH-de > > Section 2.1 continues: > > In this format, all non-initial two-letter subtags are uppercase, > > But this is incorrect for the three tags cited above. (I think these > three tags are the only ones where such a problem occurs.) > > The error is repeated in section 4.4: > > When performing canonicalization of language tags, processors MAY > regularize the case of the subtags (that is, this process is > OPTIONAL), following the case used in the registry. Note that this > corresponds to the following casing rules: uppercase all non-initial > two-letter subtags; titlecase all non-initial four-letter subtags; > lowercase everything else. -- 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 Apr 22 13:46: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 1Hfg8r-0001Bd-P2; Sun, 22 Apr 2007 13:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfg8q-0001BW-0j for ltru@ietf.org; Sun, 22 Apr 2007 13:46:28 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfg8n-0005UW-PL for ltru@ietf.org; Sun, 22 Apr 2007 13:46:27 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hfg8n-0003cS-EC; Sun, 22 Apr 2007 13:46:25 -0400 Date: Sun, 22 Apr 2007 13:46:25 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: recommended case of language tags Message-ID: <20070422174625.GE23794@mercury.ccil.org> References: <011001c78502$856a6640$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011001c78502$856a6640$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > > sgn-BE-fr > > sgn-BE-nl > > sgn-CH-de In any case, all of these will be deprecated in the 4646bis regime. -- 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 Sun Apr 22 13:56: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 1HfgIa-0000JE-7B; Sun, 22 Apr 2007 13:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfgIZ-0000J9-1r for ltru@ietf.org; Sun, 22 Apr 2007 13:56:31 -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 1HfgIX-0006ra-Nx for ltru@ietf.org; Sun, 22 Apr 2007 13:56:31 -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 <20070422175627.MDUH26916.mta16.adelphia.net@DGBP7M81> for ; Sun, 22 Apr 2007 13:56:27 -0400 Message-ID: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 22 Apr 2007 10:56:27 -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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ltru] Re: updated editor's copy to deal with 'mis', etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 4. The 'mis' (Miscellaneous) primary language subtag is used to > identify linguistic content whose language is known but > cannot otherwise be identified. It is commonly used when the > range of language tags is constrained (for example, to the > set defined for use in the [MARC21] standard, for example) or > for languages not otherwise categorized. It SHOULD NOT be > used unless a language tag is required and no other means of > identifying the language is available. Good. I hope this is satisfactory to everyone. > 5. The grandfathered tag "i-default" (Default Language) was > originally registered according to [RFC1766] to meet the > needs of [RFC2277]. It is used to indicate not a specific > language, but rather, it identifies the condition or content > used where the language preferences of the user cannot be > established. The copy editor in me is having trouble with this sentence. How about: "It is used to identify the condition or content used where the language preferences of the user cannot be established, in accordance with [RFC2277], not to indicate a specific language." In addition to the grammatical changes, note the additional hammer-the-point-home reference to RFC 2277. > It SHOULD NOT be used except as a means of > labeling the default content for applications or protocols > that require default language content to be labeled with that > specific tag. It MAY also be used by an application or > protocol to identify when the default language content is > being returned. Good. > Comments? One general question: Are all of the basic premises of RFC 4646bis (e.g. extlangs as they were originally understood) stabilized to the point where I can submit another draft of RFC 4645bis, possibly even for WG Last Call? -- 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 Apr 22 16:21: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 1HfiZ5-0003L0-3T; Sun, 22 Apr 2007 16:21:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfiZ3-0003Kr-He for ltru@ietf.org; Sun, 22 Apr 2007 16:21:41 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfiZ2-0004ZC-8M for ltru@ietf.org; Sun, 22 Apr 2007 16:21:41 -0400 Received: from c83-248-108-76.bredband.comhem.se ([83.248.108.76]:1789 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfiYz-0003XI-7v; Sun, 22 Apr 2007 22:21:37 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" References: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: updated editor's copy to deal with 'mis', etc. Date: Sun, 22 Apr 2007 22:24:02 +0200 Message-ID: <003e01c7851c$2bde35b0$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceFB5EpR8dIf7deRhuqkVmQ+HF9IAAE5pOg In-Reply-To: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfiYz-0003XI-7v. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HfiYz-0003XI-7v 9b836aea1dc5d4bfe35dc254d2ad80a5 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Doug Ewell' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Addison Phillips wrote: > > > 4. The 'mis' (Miscellaneous) primary language subtag is used to > > identify linguistic content whose language is known but > > cannot otherwise be identified. It is commonly used when the > > range of language tags is constrained (for example, to the > > set defined for use in the [MARC21] standard, for example) or > > for languages not otherwise categorized. It SHOULD NOT be > > used unless a language tag is required and no other means of > > identifying the language is available. > > Good. I hope this is satisfactory to everyone. 1) I don't see a particular need to reference the MARC set of codes here. 2) Please generalise the formulation to apply to ALL of the collection codes. 'mis' is not and should not be a special case. I really don't want to see any principled difference among the collection codes. 639 does not do any such principled difference among the collection codes, and I see no need to depart from that. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 22 17:35: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 1HfjiP-00019R-SV; Sun, 22 Apr 2007 17:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjiO-00013h-PB for ltru@ietf.org; Sun, 22 Apr 2007 17:35:24 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfjiN-00078S-GU for ltru@ietf.org; Sun, 22 Apr 2007 17:35:24 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070422213523.UAEU14403.mta9.adelphia.net@DGBP7M81>; Sun, 22 Apr 2007 17:35:23 -0400 Message-ID: <013001c78526$2253fed0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> <003e01c7851c$2bde35b0$5072f853@streamserve.com> Subject: Re: [Ltru] Re: updated editor's copy to deal with 'mis', etc. Date: Sun, 22 Apr 2007 14:35:22 -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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > 2) Please generalise the formulation to apply to ALL of the collection > codes. 'mis' is not and should not be a special case. I really don't > want to see any principled difference among the collection codes. > 639 does not do any such principled difference among the collection > codes, and I see no need to depart from that. I fundamentally disagree with Kent on this point, and will say no more about it, on either this list or ietf-languages. Let the WG do what it will. -- 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 Apr 22 18:27: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 1HfkWj-0004Uo-SO; Sun, 22 Apr 2007 18:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfkWj-0004Uj-CO for ltru@ietf.org; Sun, 22 Apr 2007 18:27:25 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfkWh-0003CV-VT for ltru@ietf.org; Sun, 22 Apr 2007 18:27:25 -0400 Received: from c83-248-108-76.bredband.comhem.se ([83.248.108.76]:1767 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HfkWg-00086h-6e; Mon, 23 Apr 2007 00:27:22 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" , "'LTRU Working Group'" References: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> <003e01c7851c$2bde35b0$5072f853@streamserve.com> <013001c78526$2253fed0$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: updated editor's copy to deal with 'mis', etc. Date: Mon, 23 Apr 2007 00:29:48 +0200 Message-ID: <004e01c7852d$bc98c6e0$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceFJigETmo75S8DRMyMQlHg4kNKpQAAYG6Q In-Reply-To: <013001c78526$2253fed0$6401a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HfkWg-00086h-6e. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HfkWg-00086h-6e bb444fd205a6d289efff9638b700c50e X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Kent Karlsson wrote: > > > 2) Please generalise the formulation to apply to ALL of the collection > > codes. 'mis' is not and should not be a special case. I really don't > > want to see any principled difference among the collection codes. > > 639 does not do any such principled difference among the collection > > codes, and I see no need to depart from that. > > I fundamentally disagree with Kent on this point, and will say no more > about it, on either this list or ietf-languages. Let the WG do what it > will. There is no support in ISO 639 for making any kind of principled difference between any of the collection codes, and 'mis' is most definitely an ordinary collection code (I see absolutely no reason to change that). If you want to replace the 'mis' code by another one meaning the same as 'mis', then do so in one way or another, though I don't see that as meaningful. RFC 4646 and predecessors have made no principled difference between the collection code (or even mentioned them at all). I see no problem in mentioning or recommending something about collection codes, as long as the mentioning and recommending is in principle (at the meta-level, if you like) the same for all of the collection code. But singling out one (or some) collection code(s) and treat that (those) in any way differently from the others would be a new and bad thing. And whatever the recommendation is, it must not be in direct conflict with the recommendation in 639-2 w.r.t. collection codes. As long as that is fulfilled, I happy to go along with anything from deprecating all of the collection codes (with no replacements) for 4646bis as all (known, modern or nearly modern, natural) languages will have their own code, to allowing them for some purpose (e.g. partial information) also for "new" use. "Old" documents may of course be using collection codes, even if they are deprecated in 4646bis. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 04:31: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 1Hftxj-0004mo-0f; Mon, 23 Apr 2007 04:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hftxh-0004mg-KR for ltru@ietf.org; Mon, 23 Apr 2007 04:31:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hftxd-0004mH-W2 for ltru@ietf.org; Mon, 23 Apr 2007 04:31:53 -0400 Received: from [10.76.37.195] (wifi-postauth195.london.corp.yahoo.com [10.76.37.195]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3N8VesC005412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 01:31:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=W5Mx3gAoQA4lFAKLpNW6p6Zr1fvBo5CIsMGBHlvkGs8HOpz42MT6TfE6bmbiLcxs Message-ID: <462C6EEB.1040607@yahoo-inc.com> Date: Mon, 23 Apr 2007 09:31:39 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: updated editor's copy to deal with 'mis', etc. References: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> In-Reply-To: <011a01c78507$8cf35110$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > >> 5. The grandfathered tag "i-default" (Default Language) was >> originally registered according to [RFC1766] to meet the >> needs of [RFC2277]. It is used to indicate not a specific >> language, but rather, it identifies the condition or content >> used where the language preferences of the user cannot be >> established. > > The copy editor in me is having trouble with this sentence. How about: > > "It is used to identify the condition or content used where the language > preferences of the user cannot be established, in accordance with > [RFC2277], not to indicate a specific language." The copy editor in me doesn't like that sentence either: I lifted it nearly intact from RFC 2277. Your version is superior. > >> Comments? > > One general question: Are all of the basic premises of RFC 4646bis > (e.g. extlangs as they were originally understood) stabilized to the > point where I can submit another draft of RFC 4645bis, possibly even for > WG Last Call? > AFAICT, they are, although I note that what has happened, essentially, is that the discussion on extlangs has been on hiatus and has not reached a conclusion. Mark still believes (I think) that we should promote the enclosed languages to primary language subtags and basically forget extlangs for now. I still believe that his reasons for wanting to do this can be overcome (and I've done so primarily by modifying the behavior of my lookup implementation). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 05:56: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 1HfvI1-00054V-8L; Mon, 23 Apr 2007 05:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvI0-00054Q-5m for ltru@ietf.org; Mon, 23 Apr 2007 05:56:56 -0400 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfvHy-0001fw-SQ for ltru@ietf.org; Mon, 23 Apr 2007 05:56:56 -0400 Received: (qmail 93415 messnum 3685171 invoked from network[194.125.174.112/ts09-112.dublin.indigo.ie]); 23 Apr 2007 09:56:53 -0000 Received: from ts09-112.dublin.indigo.ie (HELO ?194.125.174.112?) (194.125.174.112) by mail16.svc.cra.dublin.eircom.net (qp 93415) with SMTP; 23 Apr 2007 09:56:53 -0000 In-Reply-To: <001401c7856b$50044340$6601a8c0@oemcomputer> References: <11633FB7-31A8-45A4-8F46-749C489CF519@egt.ie> <001401c7856b$50044340$6601a8c0@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: <0724CBA5-7F5D-40F8-99A6-C733E6C6AD38@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases) Date: Mon, 23 Apr 2007 10:58:23 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Randy, I am responding publicly to your off-list warning (below), because I =20 am moved to make a public apology to any fellow-members of this list =20 who found my msg below in any way offensive, as you have clearly =20 found it so. The feeling here in the office was that the comment =20 (below) is a witty way of pointing out how tiresome it is for some of =20= us to be asked to tolerate so many msgs from one single country on a =20 topic not related to cataloguing human languages (instead of many =20 msgs from many different countries on topics which are). mg On 23 Apr 2007, at 05:50, scr=EDobh Randy Presuhn: > Hi - > > Please refrain from unprofessional commentary. > See RFC 3934 for the procedural details. > If necessary, your next warning may be public, > followed by suspension if bad behaviour continues. > > Randy > ltru co-chair > > >> From: "Marion Gunn" >> To: "LTRU Working Group" >> Sent: Sunday, April 22, 2007 7:43 AM >> Subject: Re: [Ltru] Re: Language Tag Special Cases >> >> > > >> I agree with what Karen says below. >> >> Even without the 'oxy-'.:-) >> >> Having received 62 LTRU msgs in 24 hrs, all but 2 from the US, I only >> read her 2 (not because I expect the others to be relatively info- >> empty, but because non-US msgs are tending towards more favourable >> noise-2-content ratios recently). >> On 20 Apr 2007, at 17:24, scr=EDobh Karen_Broome@spe.sony.com: >> ... >> The Zxxx script tag and Zxx tag would have been better defined as =20 >> "Not Applicable" which is the semantic suggested below. The =20 >> concepts of "non-linguistic language" and "unwritten script" are =20 >> oxymoronic. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 06:52: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 1Hfw9M-00068l-Kp; Mon, 23 Apr 2007 06:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfw9K-00068f-Hu for ltru@ietf.org; Mon, 23 Apr 2007 06:52:02 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfw9J-0006jy-VH for ltru@ietf.org; Mon, 23 Apr 2007 06:52:02 -0400 Received: from [86.146.3.154] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 95477233; Mon, 23 Apr 2007 11:51:59 +0100 From: "David Dalby" To: "'Marion Gunn'" , "'LTRU Working Group'" Subject: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases) Date: Mon, 23 Apr 2007 11:51:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceFjbsl8OqtoRxySXWO2VwB501A+QABiXhA In-Reply-To: <0724CBA5-7F5D-40F8-99A6-C733E6C6AD38@egt.ie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, I have refrained recently from responding to matters discussed on this = and its parallel forum, because I have felt so out-of-place among largely trans-Atlantic experts in the rules of program(m)ing. =20 Marion's humorous response is entirely appropriate and "on-topic", and I look forward to the day when the coding of the world's languages may be discussed and resolved by many more linguists and by many more speakers = of different languages from around the world. Please forgive my intruding onto the bridge. I shall return to the boiler-room. Best wishes to all, David _____________________________________________________ =20 David Dalby l'Observatoire Linguistique / the Linguasphere Observatory Hebron, Whitland, Wales SA34 0XT =20 Tel: +44 (0)1994 419660 =20 -----Original Message----- From: Marion Gunn [mailto:mgunn@egt.ie]=20 Sent: 23 April 2007 11:58 To: LTRU Working Group Subject: Re: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases) Dear Randy, I am responding publicly to your off-list warning (below), because I =20 am moved to make a public apology to any fellow-members of this list =20 who found my msg below in any way offensive, as you have clearly =20 found it so. The feeling here in the office was that the comment =20 (below) is a witty way of pointing out how tiresome it is for some of =20 us to be asked to tolerate so many msgs from one single country on a =20 topic not related to cataloguing human languages (instead of many =20 msgs from many different countries on topics which are). mg On 23 Apr 2007, at 05:50, scr=EDobh Randy Presuhn: > Hi - > > Please refrain from unprofessional commentary. > See RFC 3934 for the procedural details. > If necessary, your next warning may be public, > followed by suspension if bad behaviour continues. > > Randy > ltru co-chair > > >> From: "Marion Gunn" >> To: "LTRU Working Group" >> Sent: Sunday, April 22, 2007 7:43 AM >> Subject: Re: [Ltru] Re: Language Tag Special Cases >> >> > > >> I agree with what Karen says below. >> >> Even without the 'oxy-'.:-) >> >> Having received 62 LTRU msgs in 24 hrs, all but 2 from the US, I only >> read her 2 (not because I expect the others to be relatively info- >> empty, but because non-US msgs are tending towards more favourable >> noise-2-content ratios recently). >> On 20 Apr 2007, at 17:24, scr=EDobh Karen_Broome@spe.sony.com: >> ... >> The Zxxx script tag and Zxx tag would have been better defined as =20 >> "Not Applicable" which is the semantic suggested below. The =20 >> concepts of "non-linguistic language" and "unwritten script" are =20 >> oxymoronic. - - 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 Mon Apr 23 08:32: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 1HfxiC-0003lG-1A; Mon, 23 Apr 2007 08:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxiA-0003aa-6i for ltru@ietf.org; Mon, 23 Apr 2007 08:32:06 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound1-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfxi7-0005ym-TM for ltru@ietf.org; Mon, 23 Apr 2007 08:32:06 -0400 Received: from outbound1-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-blu-R.bigfish.com (Postfix) with ESMTP id B7FF5128924A for ; Mon, 23 Apr 2007 12:32:03 +0000 (UTC) Received: from mail42-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound1-blu.bigfish.com (Postfix) with ESMTP id A7E2712E004A for ; Mon, 23 Apr 2007 12:32:03 +0000 (UTC) Received: from mail42-blu (localhost.localdomain [127.0.0.1]) by mail42-blu-R.bigfish.com (Postfix) with ESMTP id 827C71481F0 for ; Mon, 23 Apr 2007 12:32:03 +0000 (UTC) X-BigFish: VP Received: by mail42-blu (MessageSwitch) id 1177331523489002_6501; Mon, 23 Apr 2007 12:32:03 +0000 (UCT) Received: from lonsmime02.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail42-blu.bigfish.com (Postfix) with ESMTP id 0CC771BE806E for ; Mon, 23 Apr 2007 12:32:02 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Mon, 23 Apr 2007 12:32:01 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JGY00JHOATE16@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 23 Apr 2007 12:32:02 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.1830); Mon, 23 Apr 2007 13:32:02 +0100 Date: Mon, 23 Apr 2007 13:29:25 +0100 From: Misha Wolf Subject: OT: Attracting wider participation [was: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases)] In-reply-to: To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: OT: Attracting wider participation [was: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases ) ] Thread-Index: AceFjbsl8OqtoRxySXWO2VwB501A+QABiXhAAANiFiA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 Apr 2007 12:32:02.0268 (UTC) FILETIME=[64EBB1C0:01C785A3] X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 David, I'm divided as to the wisdom of replying. If this has = reached you, then the urge to do so overcame the urge = not to do so. It seems self-evident that if you want people who are = not currently on this list to join it in order to = participate, you should be addressing yourself to them, = rather than to the existing members of the list. You = could suggest the creation of a list not-ltru@ietf.org, = whose membership would consist of those persons who are = *not* members of the existing list. You could then use = the new forum to encourage them to join the ltru list. Yours transatlantically, Misha London, UK -----Original Message----- From: David Dalby [mailto:daviddalby@linguasphere.info] = Sent: 23 April 2007 11:52 To: 'Marion Gunn'; 'LTRU Working Group' Subject: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases) Dear All, I have refrained recently from responding to matters discussed on this and its parallel forum, because I have felt so out-of-place among largely trans-Atlantic experts in the rules of program(m)ing. = Marion's humorous response is entirely appropriate and "on-topic", and I look forward to the day when the coding of the world's languages may be discussed and resolved by many more linguists and by many more speakers of different languages from around the world. Please forgive my intruding onto the bridge. I shall return to the boiler-room. Best wishes to all, David This email was sent to you by Reuters, the global news and information comp= any. = To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, = except where the sender specifically states them to be the views of Reuters= Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters= Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South = Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 10:16: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 1HfzL1-0004C6-K1; Mon, 23 Apr 2007 10:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzL0-0004Bw-EO for ltru@ietf.org; Mon, 23 Apr 2007 10:16:18 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzKz-0003Au-4H for ltru@ietf.org; Mon, 23 Apr 2007 10:16:18 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8A8541C00EE; Mon, 23 Apr 2007 16:16:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 857351C00EB; Mon, 23 Apr 2007 16:16:15 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 77B0C58EBC5; Mon, 23 Apr 2007 16:16:15 +0200 (CEST) Date: Mon, 23 Apr 2007 16:16:15 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20070423141615.GA13303@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf-languages@iana.org Subject: [Ltru] Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Copied to ietf-languages because it is related to the registration process.] RFC 4646 says in "3.5. Registration Procedure for Subtags": > All approved registration forms are available online in the > directory http://www.iana.org/numbers.html under "languages". [And this is also in draft-ietf-ltru-4646bis-04] At the specified address, you can find the language subtag registry but not the actual registration forms. Do I read the RFC the wrong way? Is it IANA's fault? This is a problem because, now that we've registered several variants, people who want to know more about them have nowhere to find out. When you want to know more about a language, you can go to the Ethnologue or to the ISO standard but, for variants, nothing is written down but the registration form. The registry entry is not sufficient since "the registry is not an encyclopedia". References are omitted, for instance. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 10:47: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 1HfzpY-0005Km-1u; Mon, 23 Apr 2007 10:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzpW-0005EI-FY for ltru@ietf.org; Mon, 23 Apr 2007 10:47:50 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzpV-0005i3-3n for ltru@ietf.org; Mon, 23 Apr 2007 10:47:50 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B57C31C00E6; Mon, 23 Apr 2007 16:47:48 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B013F1C00E4; Mon, 23 Apr 2007 16:47:47 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A3D0358EBC5; Mon, 23 Apr 2007 16:47:47 +0200 (CEST) Date: Mon, 23 Apr 2007 16:47:47 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20070423144747.GA2100@nic.fr> References: <20070423141615.GA13303@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070423141615.GA13303@nic.fr> 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: 08170828343bcf1325e4a0fb4584481c Cc: ietf-languages@iana.org Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Apr 23, 2007 at 04:16:15PM +0200, Stephane Bortzmeyer wrote a message of 27 lines which said: > At the specified address, you can find the language subtag registry > but not the actual registration forms. This is specially annoying since, apparently, the "official" registration form, the one which was sent to the IANA, does not seem to be always publically available. For instance, the form for the variant "baku1926" did not appear in ietf-languages (to find out what it looked like, you have to read several messages and to integrate the various patches proposed and accepted). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 11:02: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 1Hg03s-0003cj-68; Mon, 23 Apr 2007 11:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg03q-0003cd-Rd for ltru@ietf.org; Mon, 23 Apr 2007 11:02:38 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg03p-0004Hk-G2 for ltru@ietf.org; Mon, 23 Apr 2007 11:02:38 -0400 Received: from [10.76.37.195] (wifi-postauth195.london.corp.yahoo.com [10.76.37.195]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3NF2KKW022779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 08:02: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=hyh+2gKpchOUITW1d9Iyn+/Y0f1avSCO07JPHDre19nvu4OCO7A7RrJaji2ZwU3B Message-ID: <462CCA7B.50501@yahoo-inc.com> Date: Mon, 23 Apr 2007 16:02:19 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Archival of registration forms References: <20070423141615.GA13303@nic.fr> <20070423144747.GA2100@nic.fr> In-Reply-To: <20070423144747.GA2100@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf-languages@iana.org, 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 RFC 4646 was written to mirror RFC 3066 (and before), with separate storage of the forms. The forms could be aggregated into a single file, etc. I don't know why IANA isn't archiving the forms currently. I too find it questionable when the final registered format is not sent to the list prior to forwarding (or at least as part of forwarding) to IANA. In fact, I suspect that, given the stability guarantees and rules in RFC 4646, such registrations can be appealed if they differ from the requested record. Addison Stephane Bortzmeyer wrote: > On Mon, Apr 23, 2007 at 04:16:15PM +0200, > Stephane Bortzmeyer wrote > a message of 27 lines which said: > >> At the specified address, you can find the language subtag registry >> but not the actual registration forms. > > This is specially annoying since, apparently, the "official" > registration form, the one which was sent to the IANA, does not seem > to be always publically available. For instance, the form for the > variant "baku1926" did not appear in ietf-languages (to find out what > it looked like, you have to read several messages and to integrate the > various patches proposed and accepted). > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 11:10: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 1Hg0B3-0000T0-Bz; Mon, 23 Apr 2007 11:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0B3-0000Sp-0T for ltru@ietf.org; Mon, 23 Apr 2007 11:10:05 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0B1-0005nx-FR for ltru@ietf.org; Mon, 23 Apr 2007 11:10:04 -0400 Received: from host58-40.arin-xix.arin.net ([208.234.47.58]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l3NFA0J9006777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Apr 2007 08:10:02 -0700 Received: from [127.0.0.1] by host58-40.arin-xix.arin.net (PGP Universal service); Mon, 23 Apr 2007 08:10:00 -0700 X-PGP-Universal: processed; by host58-40.arin-xix.arin.net on Mon, 23 Apr 2007 08:10:00 -0700 In-Reply-To: <20070423141615.GA13303@nic.fr> References: <20070423141615.GA13303@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <04C79A15-E242-4B94-A064-60A56F5880D6@icann.org> From: David Conrad Subject: Re: [Ltru] Archival of registration forms Date: Mon, 23 Apr 2007 08:09:56 -0700 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-languages@iana.org, 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 Hi, I'm looking into this. The reference in 4646 is almost certainly wrong as that URL points to the list of the registries IANA maintains and does not generally contain references to forms. I'll let folks here know as I find out more. Rgds, -drc On Apr 23, 2007, at 7:16 AM, Stephane Bortzmeyer wrote: > [Copied to ietf-languages because it is related to the registration > process.] > > RFC 4646 says in "3.5. Registration Procedure for Subtags": > >> All approved registration forms are available online in the >> directory http://www.iana.org/numbers.html under "languages". > > [And this is also in draft-ietf-ltru-4646bis-04] > > At the specified address, you can find the language subtag registry > but not the actual registration forms. Do I read the RFC the wrong > way? Is it IANA's fault? > > This is a problem because, now that we've registered several variants, > people who want to know more about them have nowhere to find out. When > you want to know more about a language, you can go to the Ethnologue > or to the ISO standard but, for variants, nothing is written down but > the registration form. > > The registry entry is not sufficient since "the registry is not an > encyclopedia". References are omitted, for instance. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 12:57: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 1Hg1rE-0001ve-I9; Mon, 23 Apr 2007 12:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1rD-0001vU-6z for ltru@ietf.org; Mon, 23 Apr 2007 12:57:43 -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 1Hg1rA-0000Jg-7I for ltru@ietf.org; Mon, 23 Apr 2007 12:57:43 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id BFD7913F9865 for ; Mon, 23 Apr 2007 16:56:15 +0000 (UTC) Received: from mail83-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 6A8DF528052 for ; Mon, 23 Apr 2007 16:56:15 +0000 (UTC) Received: from mail83-sin (localhost.localdomain [127.0.0.1]) by mail83-sin-R.bigfish.com (Postfix) with ESMTP id ED980F30320 for ; Mon, 23 Apr 2007 16:56:14 +0000 (UTC) X-BigFish: VP Received: by mail83-sin (MessageSwitch) id 1177347374896243_16519; Mon, 23 Apr 2007 16:56:14 +0000 (UCT) Received: from lonsmime02.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail83-sin.bigfish.com (Postfix) with ESMTP id D0D331550075 for ; Mon, 23 Apr 2007 16:56:12 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Mon, 23 Apr 2007 16:56:10 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JGY006FPN1MAJ@eupig2.dtc.lon.ime.reuters.com>; Mon, 23 Apr 2007 16:56:10 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 23 Apr 2007 17:56:10 +0100 Date: Mon, 23 Apr 2007 17:53:33 +0100 From: Misha Wolf In-reply-to: <462CDF8D.9000309@sandsoft.com> To: "Elisa F. Kendall" , Gauri.Salokhe@FAO.ORG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Fwd: Language Ontology] Thread-Index: AceFxS368pAxjmZiRi+g7IJfnAHL6QAAnPlQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 Apr 2007 16:56:10.0495 (UTC) FILETIME=[4B3338F0:01C785C8] X-Spam-Score: 0.4 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: LTRU Working Group , Semantic web list , WWW International Subject: [Ltru] RE: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0605596788==" Errors-To: ltru-bounces@ietf.org --===============0605596788== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C785C8.4AFE0FE4" Content-class: urn:content-classes:message ------_=_NextPart_001_01C785C8.4AFE0FE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This sounds very worrying as you don't seem to be aware of BCP 47. = Misha ________________________________ From: www-international-request@w3.org [mailto:www-international-request@w3= .org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 17:32 To: Gauri.Salokhe@FAO.ORG Cc: 'WWW International'; Semantic web list Subject: Re: [Fwd: Language Ontology] Hi Gauri, We've done this for some of our government customers, using essentially the= second approach you cite. We're also in the process of relating the ontol= ogy to another one we've built to represent ISO 3166, which includes the ad= ministrative languages used by countries and non-sovereign territories rep= resented in that standard. If you can hang out for a few days, we (Sandpiper) are just finalizing a ve= rsion that includes both ISO 639-1 and 639-2. The approach is more of a hyb= rid of the two you present, based on customer needs. It includes a fragmen= t of ISO 1087, and also some inverse relations since there is a one-to-one = correspondence between languages and codes. We elected to create a 'Langua= ge' class, rather than 'LanguageCode', which we reuse in other applications= ; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, fr= om ISO 5127, with instances of these codes as first class individuals. We u= se literals (via datatype properties) to represent the set of English, Fren= ch, and in the case of 639-1 Indigenous names. We've also created subclass= es of Alpha-3Code to support distinctions between bibliographic and termino= logic, collective, and special identifiers, with individual and macrolangua= ges to support 639-3. A subsequent release will include all of the languag= es described in ISO 639-3, as well as additions to support at least some of= the subtagging that Dan mentions, fyi. Our intent is to publish it on a n= ew portal that will become part of a new service offered by the Ontology PS= IG in the OMG, since we've been asked to publish several ontologies in rece= nt RFPs. I'll be happy to send our preliminary version when it's "baked an= d tested", and follow up with an announcement of the new portal (where a re= vision using OMG URIs will be posted) once that's available. It may be a c= ouple of months before we're ready to make that announcement, but we're hop= ing that the service will be useful to many of us in the Semantic Web commu= nity. Best regards, Elisa Dan Brickley wrote: = Forwarding from the Dublin Core list, in case folk here can advise. = = Gauri, one thing I'd suggest as useful would be to take the concepts impli= cit in RFC 4646, = = http://www.rfc-editor.org/rfc/rfc4646.txt = see also http://www.w3.org/International/articles/language-tags/Overview.e= n.php = = ...and in particular the subtag mechanism, script, region, variant etc. = = It would be great to have those expressed explicitly. = = cheers, = = Dan = = = ________________________________ Subject: = Language Ontology From: = "Salokhe, Gauri (KCEW)" = Date: = Mon, 23 Apr 2007 17:28:39 +0200 To: = DC-GENERAL@JISCMAIL.AC.UK To: = DC-GENERAL@JISCMAIL.AC.UK Dear All, = = We are working on creating Ontology for languages. The need came up as we tried to convert our XML metadata files into OWL. In our metadata (XML) records, we have three types of occurrences of language information. = = En eng English = = We have two options for modelling the language ontology: = 1) Create a class for each language, assign URI to it and add all the othe= r lexical variations, ISO codes (create datatype property) as follows: = OWL:Thing |_ Class:Language |_ Instance:URI1 |_ rdfs:label xml:lang=3D"en" English |_ rdfs:label xml:lang=3D"es" Ingl=E9s |_ rdfs:label xml:lang=3D"it" Inglese |_ rdfs:label xml:lang=3D"fr" Anglais |_ etc. |_ property:hasISO639-1Code en (string) |_ property:hasISO639-2Code eng (string) |_ etc. |_ Instance:URI2 |_ Instance:URI3 |_ Instance:URI4 = = 2) Create Classes called Language and Language code and make links between= instances of Language and Language Codes as follows: = = OWL:Thing |_ Class:Language |_ Instance:URI1 |_ property:hasCode en (link to the en instance of Class ISO639-1 below) |_ property:hasCode eng (link to the eng instance of Class ISO639-1 below) = |_ Class:LanguageCode |_ SubClass ISO639-1 |_ Instance:en |_ Instance:fr |_ etc. |_ SubClass ISO639-2 |_ Instance:eng |_ Instance:fra |_ etc. |_ etc. = Does anyone have similar experience with modelling in OWL? Any suggestions= on which model is better and (extensible)? Does an ontology already exist tha= t we can reuse? = Than you, = Gauri = This email was sent to you by Reuters, the global news and information comp= any. = To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, = except where the sender specifically states them to be the views of Reuters= Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters= Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South = Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales ------_=_NextPart_001_01C785C8.4AFE0FE4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This sounds very worrying as you don't seem to = be aware of BCP 47.
 
Misha

From: www-international-request@w3.org = [mailto:www-international-request@w3.org] On Behalf Of Elisa F. = Kendall
Sent: 23 April 2007 17:32
To: = Gauri.Salokhe@FAO.ORG
Cc: 'WWW International'; Semantic web = list
Subject: Re: [Fwd: Language Ontology]

Hi Gauri,

We've done this for some of our government = customers, using essentially the second approach you cite.  We're also= in = the process of relating the ontology to another one we've built to represen= t ISO = 3166, which includes the administrative languages used by countries and = non-sovereign territories  represented in that standard.

If you= can = hang out for a few days, we (Sandpiper) are just finalizing a version that = includes both ISO 639-1 and 639-2. The approach is more of a hybrid of the = two = you present, based on customer needs.  It includes a fragment of ISO 1= 087, = and also some inverse relations since there is a one-to-one correspondence = between languages and codes.  We elected to create a 'Language' class,= = rather than 'LanguageCode', which we reuse in other applications; classes f= or = Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, w= ith = instances of these codes as first class individuals. We use literals (via = datatype properties) to represent the set of English, French, and in the ca= se of = 639-1 Indigenous names.  We've also created subclasses of Alpha-3Code = to = support distinctions between bibliographic and terminologic, collective, an= d = special identifiers, with individual and macrolanguages to support 639-3.&n= bsp; = A subsequent release will include all of the languages described in ISO 639= -3, as well as additions to support at least some of the subtagging that Dan = mentions, fyi.  Our intent is to publish it on a new portal that will = become part of a new service offered by the Ontology PSIG in the OMG, since= = we've been asked to publish several ontologies in recent RFPs.  I'll b= e = happy to send our preliminary version when it's "baked and tested", and fol= low = up with an announcement of the new portal (where a revision using OMG URIs = will = be posted) once that's available.  It may be a couple of months before= = we're ready to make that announcement, but we're hoping that the service wi= ll be = useful to many of us in the Semantic Web community.

Best = regards,

Elisa

Dan Brickley wrote: =

Forward= ing = from the Dublin Core list, in case folk here can advise.

Gauri, o= ne = thing I'd suggest as useful would be to take the concepts implicit in RFC= = 4646,

http://www.rfc-editor.= org/rfc/rfc4646.txt =
see also http://www.w3.org/International/articles/language-tags/Overview.en.p= hp =

...and in particular the subtag mechanism, script, region, varian= t = etc.

It would be great to have those expressed explicitly. =

cheers,

Dan


Subject: =
Language Ontology
From: =
"Salokhe, Gauri (KCEW)" <Gauri.Salokhe@FAO.ORG>=
Date: Mon, 23 = Apr 2007 17:28:39 +0200
To:
= DC-GENERAL@JISCMAIL.AC.UK=
To:
= DC-GENERAL@JISCMAIL.AC.UK= 

Dear All, =


We are working on creating Ontology for languages. The need came up as we
tried to convert our XML metadata files into OWL. In our metadata (XML)
records, we have three types of occurrences of language information. =


<dc:language scheme=3D"ags:ISO639-1">En</dc:language>
<dc:language scheme=3D"dcterms:ISO639-2">eng</dc:language>
<dc:language>English</dc:language>


We have two options for modelling the language ontology:

1) Create a class for each language, assign URI to it and add all the other=

lexical variations, ISO codes (create datatype property) as follows:

OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ rdfs:label xml:l=
ang=3D"en" English
		|_ rdfs:label xml:l=
ang=3D"es" Ingl=E9s
		|_ rdfs:label xml:l=
ang=3D"it" Inglese
		|_ rdfs:label xml:l=
ang=3D"fr" Anglais
		|_ etc.
		|_ property:hasISO639-1Code  en (string)
		|_ property:hasISO639-2Code  eng (string)
		|_ etc.
	|_ Instance:URI2
	|_ Instance:URI3
	|_ Instance:URI4


2) Create Classes called Language and Language code and make links between
instances of Language and Language Codes as follows:


OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ property:hasCode  en  (link to the en instance of Class
ISO639-1 below)
		|_ property:hasCode  eng  (link to the eng instance of Class
ISO639-1 below)

|_ Class:LanguageCode
	|_ SubClass ISO639-1
		|_ Instance:en
		|_ Instance:fr
		|_ etc.
	|_ SubClass ISO639-2
		|_ Instance:eng
		|_ Instance:fra
		|_ etc.
	|_ etc.

Does anyone have similar experience with modelling in OWL? Any suggestions =
on
which model is better and (extensible)? Does an ontology already exist that=

we can reuse?

Than you, =

Gauri

This email was sent to you by Reuters= , the global news and information company.
=0D To find out more about Reuters visit www.about.reuters.com=0D

=0D Any views expressed in this message are those of the individual sender, =0D= except where the sender specifically states them to be the views of Reuters= Limited.=0D

=0D Reuters Limited is part of the Reuters Group of companies, of which Reuters= Group PLC is the ultimate parent company.=0D Reuters Group PLC - Registered office address: The Reuters Building, South = Colonnade, Canary Wharf, London E14 5EP, United Kingdom
=0D Registered No: 3296375
=0D Registered in England and Wales ------_=_NextPart_001_01C785C8.4AFE0FE4-- --===============0605596788== 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 --===============0605596788==-- From ltru-bounces@ietf.org Mon Apr 23 13:16: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 1Hg29C-0001oN-3P; Mon, 23 Apr 2007 13:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg29A-0001oI-10 for ltru@ietf.org; Mon, 23 Apr 2007 13:16:16 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg298-0005W9-Ab for ltru@ietf.org; Mon, 23 Apr 2007 13:16:16 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1533808wri for ; Mon, 23 Apr 2007 10:16: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=eFjvhHK4+qR35AFXSE5JKgkiT74oL7iOflP5FeU/ThvQWj9z1FrWvxuHYOaVNxW10amWC67FOLh0rxm8TljOf1TKVF/K+vM9kHDxnuJxeA6jAmkRTCqJGAKnBOHSiRFXEWr/4Of0bJsR3k3wtsSU5+T19Ilnyv/iRuxp2DroczY= 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=tA39ivZz/3sDwuvoJYJ7FKTk8I0j683YCXArWp+Lhd2xIsPpipRsRMV6T8MfG2RNXKcu51GhXhTRtKPDzQMWnWINFLxIO6W18VXknkRPK6+sSYs6uHODzjQNVAaWstspsbIn2aC7eLG5aUVBacuA1NCa8t1JlUmb39XuiqF3lWI= Received: by 10.114.36.1 with SMTP id j1mr2624546waj.1177348572095; Mon, 23 Apr 2007 10:16:12 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 23 Apr 2007 10:16:11 -0700 (PDT) Message-ID: <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> Date: Mon, 23 Apr 2007 10:16:11 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] updated editor's copy to deal with 'mis', etc. In-Reply-To: <462B7DAF.2010405@yahoo-inc.com> MIME-Version: 1.0 References: <462B7DAF.2010405@yahoo-inc.com> X-Google-Sender-Auth: d0ccbe5b669c49e4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============1262836766==" Errors-To: ltru-bounces@ietf.org --===============1262836766== Content-Type: multipart/alternative; boundary="----=_Part_3032_26643202.1177348571995" ------=_Part_3032_26643202.1177348571995 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this is the right direction. Some suggested changes below. On 4/22/07, Addison Phillips wrote: > > All, > > I have posted an updated editor's copy (draft-05) to my web site > incorporating my proposed text to deal with the 'mis' mess. I haven't > submitted it yet (I still need to run the various tools on it, etc.). > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.html > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.xml > http://tinyurl.com/2kctcy (wdiff) > > In particular, it differs from my informal proposal as follows: > > 1. Some minor wordsmithing to deal with Mark's observations about my use > of "cannot be determined" wrt the 'und' subtag. > > 2. Some additions to allow the use of 'und', etc. as a prefix when the > additional information is useful. > > 3. The addition of "i-default" to the list of items deal with (per John > Cowan). > > 4. The addition of the MARC 21 reference. I also took the examples for > 'zxx' from MARC 21's equivalent code (which is three spaces). Note that > this includes Frank's desire to allow program source code to be > identified (although the text obliquely uses the phrase "machine > language"). > > Here is the resulting text: > > -- > 5. [ISO639-2] has defined several codes included in the subtag > registry that have special meaning in the context of a language > tag. In cases where omitting the language tag is permitted, such > omission preferable to using these codes. Language tags SHOULD > NOT incorporate these subtags as a prefix, unless the additional > information conveys some value to the application. > > 1. The 'mul' (Multiple) primary language subtag is used to > identify content in multiple languages. It SHOULD NOT be > used when a list of languages (such as Content-Language) or > individual tags for each content element can be used instead. > > 2. The "und' (Undetermined) primary language subtag is used to > identify linguistic content whose language is not known. => whose linguistic status is not expressed: it may contain no linguistic content, or content in one or more languages. It > SHOULD NOT be used unless a language tag is required and > language information is not available or cannot be > determined. Omitting the language tag (where permitted) is > preferred. The 'und' subtag MAY be useful for protocols that > require a language tag to be provided. Add: or where a primary subtag is required, such as "und-Latn". The 'und' subtag MAY > also be useful when matching language tags in certain > situations. > > 3. The 'zxx' (Non-Linguistic) primary language subtag is used to > identify content that has no language. Some examples might > include instrumental or electronic music; sound recordings > consisting of nonverbal sounds; audiovisual materials with no > narration, printed titles, or subtitles; machine-readable > data files consisting of machine languages or character > codes. Add: or programming language source code. Note: where there are fragments of linguistic content, such as programming contents written in English, the tag zxx may still be used to indicate the primary status of the content, just as "en" can be applied to text that may contain some French words as well. It SHOULD NOT be used unless a language tag is > required by some application or protocol and the content is > non-linguistic. Remove this SHOULD NOT, since it is already covered by the blanket prohibition. Add here (and renumber). 3a. Certain primary language subtags are distinguished as collections, such as Germanic ("ger") or Algonquian languages ("alg") . For stability, these codes are interpreted inclusively, thus content that is "en" or "de" or "gsw" is also "ger". However, content SHOULD NOT be tagged with collections unless the more specific information as to the language is not known. Queries SHOULD NOT use collections to indicate a request for content in any of the languages they encompass, unless the matching software handles them in that way rather than just as literal matches. [We may want to put a note on Queries on the other items as well, for clarity.] 4. The 'mis' (Miscellaneous) primary language subtag is used to is a special collection code used to identify linguistic content whose language is known but > cannot otherwise be identified. It is commonly used when the > range of language tags is constrained (for example, to the > set defined for use in the [MARC21] standard, for example) or > for languages not otherwise categorized. I think the first sentence is sufficient, and we could drop the sentence containing MARC21. But I don't feel strongly. It SHOULD NOT be > used unless a language tag is required and no other means of > identifying the language is available. > > 5. The grandfathered tag "i-default" (Default Language) was > originally registered according to [RFC1766] to meet the > needs of [RFC2277]. It is used to indicate not a specific > language, but rather, it identifies the condition or content > used where the language preferences of the user cannot be > established. It SHOULD NOT be used except as a means of > labeling the default content for applications or protocols > that require default language content to be labeled with that > specific tag. It MAY also be used by an application or > protocol to identify when the default language content is > being returned. > > -- > > Comments? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_3032_26643202.1177348571995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this is the right direction. Some suggested changes below.

On 4/22/07, Addison Phillips < addison@yahoo-inc.com> wrote:
All,

I have posted an updated editor's copy (draft-05) to my web site
incorporating my proposed text to deal with the 'mis' mess. I haven't
submitted it yet (I still need to run the various tools on it, etc.).

   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.txt
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.html
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-05.xml
   http://tinyurl.com/2kctcy  (wdiff)

In particular, it differs from my informal proposal as follows:

1. Some minor wordsmithing to deal with Mark's observations about my use
of "cannot be determined" wrt the 'und' subtag.

2. Some additions to allow the use of 'und', etc. as a prefix when the
additional information is useful.

3. The addition of "i-default" to the list of items deal with (per John
Cowan).

4. The addition of the MARC 21 reference. I also took the examples for
'zxx' from MARC 21's equivalent code (which is three spaces). Note that
this includes Frank's desire to allow program source code to be
identified (although the text obliquely uses the phrase "machine language").

Here is the resulting text:

--
    5.  [ISO639-2] has defined several codes included in the subtag
        registry that have special meaning in the context of a language
        tag.  In cases where omitting the language tag is permitted, such
        omission preferable to using these codes.  Language tags SHOULD
        NOT incorporate these subtags as a prefix, unless the additional
        information conveys some value to the application.

        1.  The 'mul' (Multiple) primary language subtag is used to
            identify content in multiple languages.  It SHOULD NOT be
            used when a list of languages (such as Content-Language) or
            individual tags for each content element can be used instead.

        2.  The "und' (Undetermined) primary language subtag is used to
            identify linguistic content whose language is not known. 

=> whose linguistic status is not expressed: it may contain no linguistic content, or content in one or more languages.

 It
            SHOULD NOT be used unless a language tag is required and
            language information is not available or cannot be
            determined.  Omitting the language tag (where permitted) is
            preferred.  The 'und' subtag MAY be useful for protocols that
            require a language tag to be provided.  

Add: or where a primary subtag is required, such as "und-Latn".

The 'und' subtag MAY
            also be useful when matching language tags in certain
            situations.

        3.  The 'zxx' (Non-Linguistic) primary language subtag is used to
            identify content that has no language.  Some examples might
            include instrumental or electronic music; sound recordings
            consisting of nonverbal sounds; audiovisual materials with no
            narration, printed titles, or subtitles; machine-readable
            data files consisting of machine languages or character
            codes.  

Add: or programming language source code. Note: where there are fragments of linguistic content, such as programming contents written in English, the tag zxx may still be used to indicate the primary status of the content, just as "en" can be applied to text that may contain some French words as well.

It SHOULD NOT be used unless a language tag is
            required by some application or protocol and the content is
            non-linguistic.

Remove this SHOULD NOT, since it is already covered by the blanket prohibition.

Add here (and renumber).

3a. Certain primary language subtags are distinguished as collections, such as Germanic ("ger") or Algonquian languages ("alg") . For stability, these codes are interpreted inclusively, thus content that is "en" or "de" or "gsw" is also "ger". However, content SHOULD NOT be tagged with collections unless the more specific information as to the language is not known. Queries SHOULD NOT use collections to indicate a request for content in any of the languages they encompass, unless the matching software handles them in that way rather than just as literal matches.

[We may want to put a note on Queries on the other items as well, for clarity.]

        4.  The 'mis' (Miscellaneous) primary language subtag is used to

is a special collection code used to

            identify linguistic content whose language is known but
            cannot otherwise be identified.

 

It is commonly used when the
            range of language tags is constrained (for example, to the
            set defined for use in the [MARC21] standard, for example) or
            for languages not otherwise categorized.  

I think the first sentence is sufficient, and we could drop the sentence containing MARC21. But I don't feel strongly.

It SHOULD NOT be
            used unless a language tag is required and no other means of
            identifying the language is available.

        5.  The grandfathered tag "i-default" (Default Language) was
            originally registered according to [RFC1766] to meet the
            needs of [RFC2277].  It is used to indicate not a specific
            language, but rather, it identifies the condition or content
            used where the language preferences of the user cannot be
            established.  It SHOULD NOT be used except as a means of
            labeling the default content for applications or protocols
            that require default language content to be labeled with that
            specific tag.  It MAY also be used by an application or
            protocol to identify when the default language content is
            being returned.

--

Comments?

Addison

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

Internationalization is an architecture.
It is not a feature.

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



--
Mark ------=_Part_3032_26643202.1177348571995-- --===============1262836766== 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 --===============1262836766==-- From ltru-bounces@ietf.org Mon Apr 23 14:23: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 1Hg3CM-0005aJ-QB; Mon, 23 Apr 2007 14:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3CL-0005We-AP for ltru@ietf.org; Mon, 23 Apr 2007 14:23:37 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3CF-0004tZ-7t for ltru@ietf.org; Mon, 23 Apr 2007 14:23:37 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FTnReoQTx9E+umxCmGdITnKJXqa4a0PCOg1JtAsL5LqkLk1737XPZUFYXGSInwB/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.134] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hg3CE-0003Kb-Hy for ltru@ietf.org; Mon, 23 Apr 2007 14:23:30 -0400 Message-ID: <007c01c785d4$ccb31d80$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <11633FB7-31A8-45A4-8F46-749C489CF519@egt.ie><001401c7856b$50044340$6601a8c0@oemcomputer> <0724CBA5-7F5D-40F8-99A6-C733E6C6AD38@egt.ie> Date: Mon, 23 Apr 2007 11:25:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7bf4f05f412293edb24cb15a267d8b297350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.134 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [Ltru] Public RFC 3934 warning X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Marion - You were warned privately. This message constitutes a public warning. Such unprofessional commentary as is in your "apology" has no place in an IETF discussion. As you well know, participation in the IETF is by individuals, not by national representatives. If bad behaviour continues, your posting privileges to the ltru WG mailing list may be suspended. See RFC 3934 for the procedural details. Randy ltru co-chair ================================================================ Status: U Return-Path: Received: from megatron.ietf.org ([156.154.16.145]) by cave.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1hFVi1C63Nl3pX2 for ; Mon, 23 Apr 2007 05:56:57 -0400 (EDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvI1-00054V-93; Mon, 23 Apr 2007 05:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvI0-00054Q-5m for ltru@ietf.org; Mon, 23 Apr 2007 05:56:56 -0400 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfvHy-0001fw-SQ for ltru@ietf.org; Mon, 23 Apr 2007 05:56:56 -0400 Received: (qmail 93415 messnum 3685171 invoked from network[194.125.174.112/ts09-112.dublin.indigo.ie]); 23 Apr 2007 09:56:53 -0000 Received: from ts09-112.dublin.indigo.ie (HELO ?194.125.174.112?) (194.125.174.112) by mail16.svc.cra.dublin.eircom.net (qp 93415) with SMTP; 23 Apr 2007 09:56:53 -0000 In-Reply-To: <001401c7856b$50044340$6601a8c0@oemcomputer> References: <11633FB7-31A8-45A4-8F46-749C489CF519@egt.ie> <001401c7856b$50044340$6601a8c0@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: <0724CBA5-7F5D-40F8-99A6-C733E6C6AD38@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases) Date: Mon, 23 Apr 2007 10:58:23 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org X-ELNK-Info: spv=0; X-ELNK-AV: 0 X-ELNK-Info: sbv=0; sbrc=.0; sbf=00; sbw=000; Dear Randy, I am responding publicly to your off-list warning (below), because I =20 am moved to make a public apology to any fellow-members of this list =20 who found my msg below in any way offensive, as you have clearly =20 found it so. The feeling here in the office was that the comment =20 (below) is a witty way of pointing out how tiresome it is for some of =20= us to be asked to tolerate so many msgs from one single country on a =20 topic not related to cataloguing human languages (instead of many =20 msgs from many different countries on topics which are). mg On 23 Apr 2007, at 05:50, scr=EDobh Randy Presuhn: > Hi - > > Please refrain from unprofessional commentary. > See RFC 3934 for the procedural details. > If necessary, your next warning may be public, > followed by suspension if bad behaviour continues. > > Randy > ltru co-chair > > >> From: "Marion Gunn" >> To: "LTRU Working Group" >> Sent: Sunday, April 22, 2007 7:43 AM >> Subject: Re: [Ltru] Re: Language Tag Special Cases >> >> > > >> I agree with what Karen says below. >> >> Even without the 'oxy-'.:-) >> >> Having received 62 LTRU msgs in 24 hrs, all but 2 from the US, I only >> read her 2 (not because I expect the others to be relatively info- >> empty, but because non-US msgs are tending towards more favourable >> noise-2-content ratios recently). >> On 20 Apr 2007, at 17:24, scr=EDobh Karen_Broome@spe.sony.com: >> ... >> The Zxxx script tag and Zxx tag would have been better defined as =20 >> "Not Applicable" which is the semantic suggested below. The =20 >> concepts of "non-linguistic language" and "unwritten script" are =20 >> oxymoronic. - - 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 Mon Apr 23 14:50: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 1Hg3cb-0003J2-70; Mon, 23 Apr 2007 14:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3cZ-0003Is-V4 for ltru@ietf.org; Mon, 23 Apr 2007 14:50:43 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3cY-00053Q-La for ltru@ietf.org; Mon, 23 Apr 2007 14:50:43 -0400 Received: from c83-248-107-65.bredband.comhem.se ([83.248.107.65]:2963 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hg3cX-0008Re-4W; Mon, 23 Apr 2007 20:50:41 +0200 From: "Kent Karlsson" To: "'Mark Davis'" , "'Addison Phillips'" References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> Subject: RE: [Ltru] updated editor's copy to deal with 'mis', etc. Date: Mon, 23 Apr 2007 20:53:04 +0200 Message-ID: <009a01c785d8$a251d2d0$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceFyx3oq4oUFIhES7q96UpAkrEtWgAA8RXw In-Reply-To: <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hg3cX-0008Re-4W. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Hg3cX-0008Re-4W cb563429d830865c23647fb3aaa0ca84 X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 largely agree with Mark's edits (though as I said, I'm flexible as the deprecation/use of collection codes, as long as all collection codes are treated the same). Some comments below. Mark Davis wrote: > Add here (and renumber). > 3a. Certain primary language subtags are distinguished > as collections, such as Germanic ("ger") or Algonquian 'ger' -> 'gem' > languages ("alg") . For stability, these codes are interpreted > inclusively, thus content that is "en" or "de" or "gsw" is also "ger". "'ger'." -> "'gem', 'ine', and 'mis'." > However, content SHOULD NOT be tagged with collections unless the "collections" -> "a collection code" > more specific information as to the language is not known. Queries > SHOULD NOT use collections to indicate a request for content in > any of the languages they encompass, unless the matching software > handles them in that way rather than just as literal matches. > > 4. The 'mis' (Miscellaneous) primary language subtag is used to > > is a special collection code used to Remove "special" (which is incorrect), or replace "special" by "top level" or similar. I don't mind an extra explanation (as long as it does not try to treat 'mis' differently from the other collection codes). > identify linguistic content whose language is known but > cannot otherwise be identified. I would prefer to have much shortened "4." merged into "3a.". I think it would actually be sufficient to remove "4.", and just have "'ger'." -> "'gem', 'ine', and 'mis'." in "3a.". /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 17:44: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 1Hg6KO-0003r4-Dz; Mon, 23 Apr 2007 17:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6KM-0003qq-Mq for ltru@ietf.org; Mon, 23 Apr 2007 17:44:06 -0400 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6KM-0004J5-8y for ltru@ietf.org; Mon, 23 Apr 2007 17:44:06 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1559018nzd for ; Mon, 23 Apr 2007 14:44:05 -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=rrC/IQeYwZkkKPqAuc6SfEnEEXIWHvu+rKgPzO4Qk4NcMziBvgHlKIifbHVAfiz6VPwfbIjcKQpFhLYCntxTbnCJNPsq2IPasyCAqaNTG70x3jll81cCbNk71TqWgUAS+7Jo4+evXXXKqh9acJOr4Om69FDg2g9+ilo5rWaC3yY= 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=PcWlIAQtHi32j1cF6JYrJGgn2xDUKtUkVbD0/ga/Ask25pkFENFG2rrqmYLvA0LCLRCpAy76yX6/LqJufHTfUpnvkaUI9W5+wuhIzJ9y85QhAGtTswVmjfW5aReB+8gVIdd64/mc44RiaZEX6Syr8/Dq2geKwT4PThaqKB5LDIk= Received: by 10.114.95.1 with SMTP id s1mr2720233wab.1177364645387; Mon, 23 Apr 2007 14:44:05 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 23 Apr 2007 14:44:05 -0700 (PDT) Message-ID: <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> Date: Mon, 23 Apr 2007 14:44:05 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] updated editor's copy to deal with 'mis', etc. In-Reply-To: <009a01c785d8$a251d2d0$5072f853@streamserve.com> MIME-Version: 1.0 References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> X-Google-Sender-Auth: dfb49d06cd3a29e6 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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="===============0008391581==" Errors-To: ltru-bounces@ietf.org --===============0008391581== Content-Type: multipart/alternative; boundary="----=_Part_9386_1084736.1177364645254" ------=_Part_9386_1084736.1177364645254 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/23/07, Kent Karlsson wrote: > > > I largely agree with Mark's edits (though as I said, I'm flexible > as the deprecation/use of collection codes, as long as all > collection codes are treated the same). > > Some comments below. > > > Mark Davis wrote: > > > Add here (and renumber). > > > 3a. Certain primary language subtags are distinguished > > as collections, such as Germanic ("ger") or Algonquian > > 'ger' -> 'gem' Good catch, I missed that. > languages ("alg") . For stability, these codes are interpreted > > inclusively, thus content that is "en" or "de" or "gsw" is also "ger". > > "'ger'." -> "'gem', 'ine', and 'mis'." ok, although on rereading it, they should be spelled out for ease of reading. So => inclusively, thus content that is English ("en") or German ("de") or Swiss German ("gsw") is also Germanic ("gem"), and Indo-European ("ine") and Miscellaneous ("mis"). > However, content SHOULD NOT be tagged with collections unless the > > "collections" -> "a collection code" ok > more specific information as to the language is not known. Queries > > SHOULD NOT use collections to indicate a request for content in > > any of the languages they encompass, unless the matching software > > handles them in that way rather than just as literal matches. > > > > 4. The 'mis' (Miscellaneous) primary language subtag is used to > > > > is a special collection code used to > > Remove "special" (which is incorrect), or replace "special" by > "top level" or similar. I don't mind an extra explanation (as long > as it does not try to treat 'mis' differently from the other > collection codes). I don't see a need to change from "special", which tells the user that there is something particular about it, and there is. > identify linguistic content whose language is known but > > cannot otherwise be identified. > > I would prefer to have much shortened "4." merged into "3a.". > I think it would actually be sufficient to remove "4.", > and just have "'ger'." -> "'gem', 'ine', and 'mis'." in "3a.". I disagree. I think "mis" is sufficiently different as to be worth calling out for clarity. But I care more about the text than the numbering,. /kent k > > -- Mark ------=_Part_9386_1084736.1177364645254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 4/23/07, Kent Karlsson <kent.karlsson14@comhem.se> wrote:

I largely agree with Mark's edits (though as I said, I'm flexible
as the deprecation/use of collection codes, as long as all
collection codes are treated the same).

Some comments below.


Mark Davis wrote:

> Add here (and renumber).

> 3a. Certain primary language subtags are distinguished
> as collections, such as Germanic ("ger") or Algonquian

'ger' -> 'gem'

Good catch, I missed that.

> languages ("alg") . For stability, these codes are interpreted
> inclusively, thus content that is "en" or "de" or "gsw" is also "ger".

"'ger'." -> "'gem', 'ine', and 'mis'."

ok, although on rereading it, they should be spelled out for ease of reading. So

=>
inclusively, thus content that is English ("en") or German ("de") or Swiss German ("gsw")
is also Germanic ("gem"), and Indo-European ("ine") and Miscellaneous ("mis").

> However, content SHOULD NOT be tagged with collections unless the

"collections" -> "a collection code"

ok

> more specific information as to the language is not known. Queries
> SHOULD NOT use collections to indicate a request for content in
> any of the languages they encompass, unless the matching software
> handles them in that way rather than just as literal matches.

> > 4.  The 'mis' (Miscellaneous) primary language subtag is used to
>
> is a special collection code used to

Remove "special" (which is incorrect), or replace "special" by
"top level" or similar. I don't mind an extra explanation (as long
as it does not try to treat 'mis' differently from the other
collection codes).

I don't see a need to change from "special", which tells the user that there is something particular about it, and there is.

> identify linguistic content whose language is known but
> cannot otherwise be identified.

I would prefer to have much shortened "4." merged into "3a.".
I think it would actually be sufficient to remove "4.",
and just have  "'ger'." -> "'gem', 'ine', and 'mis'."  in "3a.".

I disagree. I think "mis" is sufficiently different as to be worth calling out for clarity. But I care more about the text than the numbering,.

                /kent k




--
Mark ------=_Part_9386_1084736.1177364645254-- --===============0008391581== 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 --===============0008391581==-- From ltru-bounces@ietf.org Mon Apr 23 18:49: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 1Hg7Lb-0001pR-IL; Mon, 23 Apr 2007 18:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg7La-0001pM-Ef for ltru@ietf.org; Mon, 23 Apr 2007 18:49:26 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg7LY-0006HC-5M for ltru@ietf.org; Mon, 23 Apr 2007 18:49:26 -0400 Received: from c83-248-107-65.bredband.comhem.se ([83.248.107.65]:2922 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Hg7LW-0005oX-7U; Tue, 24 Apr 2007 00:49:23 +0200 From: "Kent Karlsson" To: "'Mark Davis'" References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> Subject: RE: [Ltru] updated editor's copy to deal with 'mis', etc. Date: Tue, 24 Apr 2007 00:51:44 +0200 Message-ID: <00c201c785f9$fa17e790$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceF8IrC2lgQHaCFRAmjamCEjstaPwABgBSw In-Reply-To: <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1Hg7LW-0005oX-7U. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Hg7LW-0005oX-7U fa2b3b1f1c41d5d755717e06d21fe620 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ok, except for one thing: Mark Davis wrote: > > Remove "special" (which is incorrect), or replace "special" by > > "top level" or similar. I don't mind an extra explanation (as long > > as it does not try to treat 'mis' differently from the other > > collection codes). > > I don't see a need to change from "special", which tells the user > that there is something particular about it, and there is. In plain English, yes. But "special" is used in a technical meaning in 639: only 'mul', 'und', and now 'zxx' are "special codes". 'mis' is not special in that sense, and "special collection code" seem to mix the concepts. Ok, one could say that "'mis' is a special case among the collection codes" without any greater fear that that is misread. Though what is special about it is that it is top level... /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 18:54: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 1Hg7Qp-000436-Q3; Mon, 23 Apr 2007 18:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg7Qo-000431-6d for ltru@ietf.org; Mon, 23 Apr 2007 18:54:50 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg7Qn-0000I8-6z for ltru@ietf.org; Mon, 23 Apr 2007 18:54:50 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Mon, 23 Apr 2007 23:54:48 +0100 From: "Debbie Garside" To: "'Elisa F. Kendall'" , "'Misha Wolf'" Date: Mon, 23 Apr 2007 23:54:52 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceFzLku2q6BFIlcQ6GL9+IdH6v5eQALZrCA In-Reply-To: <462CEBF7.2070106@sandsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.4 (/) X-Scan-Signature: 8279e2b0006e70acac79ca9454596384 Cc: 'WWW International' , 'Semantic web list' , Gauri.Salokhe@FAO.ORG, 'LTRU Working Group' Subject: [Ltru] RE: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1305946159==" Errors-To: ltru-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1305946159== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F8_01C78602.C967AD20" This is a multi-part message in MIME format. ------=_NextPart_000_03F8_01C78602.C967AD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please be very careful with the use of the "Administrative Language" information from ISO 3166-1. It is incomplete and therefore not good = data. =20 For example, it shows only two "Administrative Languages" for India = where there are at least twenty-two. I am hoping that this information will = be taken out of the standard in the near future. I am currently writing an = ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion of this data. =20 Best regards =20 Debbie Garside Editor ISO DIS 639-6 www.geolang.com =20 _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 18:25 To: Misha Wolf Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group Subject: Re: [Fwd: Language Ontology] Hi Misha, We are very aware of it, and have been following the work, but I failed = to mention it in the email. I should say that our ontology was developed = for offline use in an internal system, as an initial requirement. Having = said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology. Our approach is compatible with the RFCs = but adds capabilities that support co-reference resolution, for example, in target application. Best, Elisa Misha Wolf wrote: This sounds very worrying as you don't seem to be aware of BCP 47. =20 Misha _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 17:32 To: Gauri.Salokhe@FAO.ORG Cc: 'WWW International'; Semantic web list Subject: Re: [Fwd: Language Ontology] Hi Gauri, We've done this for some of our government customers, using essentially = the second approach you cite. We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which = includes the administrative languages used by countries and non-sovereign = territories represented in that standard. If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of = a hybrid of the two you present, based on customer needs. It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes. We elected to = create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the = set of English, French, and in the case of 639-1 Indigenous names. We've = also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, = with individual and macrolanguages to support 639-3. A subsequent release = will include all of the languages described in ISO 639-3, as well as = additions to support at least some of the subtagging that Dan mentions, fyi. Our = intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to = publish several ontologies in recent RFPs. I'll be happy to send our = preliminary version when it's "baked and tested", and follow up with an announcement = of the new portal (where a revision using OMG URIs will be posted) once = that's available. It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many = of us in the Semantic Web community. Best regards, Elisa Dan Brickley wrote:=20 Forwarding from the Dublin Core list, in case folk here can advise.=20 Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646,=20 http://www.rfc-editor.org/rfc/rfc4646.txt=20 see also http://www.w3.org/International/articles/language-tags/Overview.en.php=20 ...and in particular the subtag mechanism, script, region, variant etc.=20 It would be great to have those expressed explicitly.=20 cheers,=20 Dan=20 _____ =20 Subject:=20 Language Ontology From:=20 "Salokhe, Gauri (KCEW)" Date:=20 Mon, 23 Apr 2007 17:28:39 +0200 To:=20 DC-GENERAL@JISCMAIL.AC.UK To:=20 DC-GENERAL@JISCMAIL.AC.UK Dear All,=20 We are working on creating Ontology for languages. The need came up as = we tried to convert our XML metadata files into OWL. In our metadata (XML) records, we have three types of occurrences of language information.=20 En eng English We have two options for modelling the language ontology: 1) Create a class for each language, assign URI to it and add all the = other lexical variations, ISO codes (create datatype property) as follows: OWL:Thing |_ Class:Language |_ Instance:URI1 |_ rdfs:label xml:lang=3D"en" English |_ rdfs:label xml:lang=3D"es" Ingl=E9s |_ rdfs:label xml:lang=3D"it" Inglese |_ rdfs:label xml:lang=3D"fr" Anglais |_ etc. |_ property:hasISO639-1Code en (string) |_ property:hasISO639-2Code eng (string) |_ etc. |_ Instance:URI2 |_ Instance:URI3 |_ Instance:URI4 2) Create Classes called Language and Language code and make links = between instances of Language and Language Codes as follows: OWL:Thing |_ Class:Language |_ Instance:URI1 |_ property:hasCode en (link to the en instance of Class ISO639-1 below) |_ property:hasCode eng (link to the eng instance of Class ISO639-1 below) |_ Class:LanguageCode |_ SubClass ISO639-1 |_ Instance:en |_ Instance:fr |_ etc. |_ SubClass ISO639-2 |_ Instance:eng |_ Instance:fra |_ etc. |_ etc. Does anyone have similar experience with modelling in OWL? Any = suggestions on which model is better and (extensible)? Does an ontology already exist = that we can reuse? Than you,=20 Gauri =20 This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of = Reuters Limited.=20 Reuters Limited is part of the Reuters Group of companies, of which = Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, = London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales=20 ------=_NextPart_000_03F8_01C78602.C967AD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please=20 be very careful with the use of the "Administrative Language" = information from=20 ISO 3166-1.  It is incomplete and therefore not good=20 data.
 
For example, it shows only two = "Administrative=20 Languages" for India where there are at least twenty-two.  I am = hoping that=20 this information will be taken out of the standard in the near = future.  I=20 am currently writing an ISO NWIP for a revision of ISO 3166-1 which = will=20 include a proposal for the deletion of this=20 data.
 
Best=20 regards
 
Debbie=20 Garside
Editor=20 ISO DIS 639-6
www.geolang.com=20


From: = www-international-request@w3.org=20 [mailto:www-international-request@w3.org] On Behalf Of Elisa F. = Kendall
Sent: 23 April 2007 18:25
To: Misha=20 Wolf
Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic = web=20 list; LTRU Working Group
Subject: Re: [Fwd: Language=20 Ontology]

Hi Misha,

We are very aware of it, and have been = following=20 the work, but I failed to mention it in the email.  I should say = that our=20 ontology was developed for offline use in an internal system, as an = initial=20 requirement.  Having said that, if you look at the RFCs, they = only=20 describe tags, not an RDF vocabulary or OWL ontology.  Our = approach is=20 compatible with the RFCs but adds capabilities that support = co-reference=20 resolution, for example, in target=20 application.

Best,

Elisa

Misha Wolf wrote:
This sounds very worrying as you don't seem = to=20 be aware of BCP 47.
 
Misha

From: www-international-reques= t@w3.org=20 [mailto:www-international= -request@w3.org]=20 On Behalf Of Elisa F. Kendall
Sent: 23 April 2007=20 17:32
To: Gauri.Salokhe@FAO.ORG
Cc:= =20 'WWW International'; Semantic web list
Subject: Re: [Fwd: = Language=20 Ontology]

Hi Gauri,

We've done this for = some of=20 our government customers, using essentially the second approach you=20 cite.  We're also in the process of relating the ontology to = another=20 one we've built to represent ISO 3166, which includes the = administrative=20 languages used by countries and non-sovereign territories  = represented=20 in that standard.

If you can hang out for a few days, we = (Sandpiper)=20 are just finalizing a version that includes both ISO 639-1 and = 639-2. The=20 approach is more of a hybrid of the two you present, based on = customer=20 needs.  It includes a fragment of ISO 1087, and also some = inverse=20 relations since there is a one-to-one correspondence between = languages and=20 codes.  We elected to create a 'Language' class, rather than=20 'LanguageCode', which we reuse in other applications; classes for=20 Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO = 5127,=20 with instances of these codes as first class individuals. We use = literals=20 (via datatype properties) to represent the set of English, French, = and in=20 the case of 639-1 Indigenous names.  We've also created = subclasses of=20 Alpha-3Code to support distinctions between bibliographic and = terminologic,=20 collective, and special identifiers, with individual and = macrolanguages to=20 support 639-3.  A subsequent release will include all of the = languages=20 described in ISO 639-3, as well as additions to support at least = some of the=20 subtagging that Dan mentions, fyi.  Our intent is to publish it = on a=20 new portal that will become part of a new service offered by the = Ontology=20 PSIG in the OMG, since we've been asked to publish several = ontologies in=20 recent RFPs.  I'll be happy to send our preliminary version = when it's=20 "baked and tested", and follow up with an announcement of the new = portal=20 (where a revision using OMG URIs will be posted) once that's=20 available.  It may be a couple of months before we're ready to = make=20 that announcement, but we're hoping that the service will be useful = to many=20 of us in the Semantic Web community.

Best=20 regards,

Elisa

Dan Brickley wrote:=20

Forwarding=20 from the Dublin Core list, in case folk here can advise. =

Gauri,=20 one thing I'd suggest as useful would be to take the concepts = implicit in=20 RFC 4646,

http://www.rfc-editor.= org/rfc/rfc4646.txt=20
see also http://www.w3.org/International/articles/language-tags/Overview.en= .php=20

...and in particular the subtag mechanism, script, region, = variant=20 etc.

It would be great to have those expressed explicitly. =

cheers,

Dan


Subject:=20
Language Ontology
From:=20
"Salokhe, Gauri (KCEW)" <Gauri.Salokhe@FAO.ORG>
Date:=20
Mon, 23 Apr 2007 17:28:39 +0200
To: =
DC-GENERAL@JISCMAIL.AC.UK
To: =
DC-GENERAL@JISCMAIL.AC.UK

Dear All,=20

We are working on creating Ontology for languages. The need came up as =
we
tried to convert our XML metadata files into OWL. In our metadata (XML)
records, we have three types of occurrences of language information.=20

<dc:language scheme=3D"ags:ISO639-1">En</dc:language>
<dc:language scheme=3D"dcterms:ISO639-2">eng</dc:language>
<dc:language>English</dc:language>


We have two options for modelling the language ontology:

1) Create a class for each language, assign URI to it and add all the =
other
lexical variations, ISO codes (create datatype property) as follows:

OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ rdfs:label xml:lang=3D"en" English
		|_ rdfs:label xml:lang=3D"es" Ingl=E9s
		|_ rdfs:label xml:lang=3D"it" Inglese
		|_ rdfs:label xml:lang=3D"fr" Anglais
		|_ etc.
		|_ property:hasISO639-1Code  en (string)
		|_ property:hasISO639-2Code  eng (string)
		|_ etc.
	|_ Instance:URI2
	|_ Instance:URI3
	|_ Instance:URI4


2) Create Classes called Language and Language code and make links =
between
instances of Language and Language Codes as follows:


OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ property:hasCode  en  (link to the en instance of Class
ISO639-1 below)
		|_ property:hasCode  eng  (link to the eng instance of Class
ISO639-1 below)

|_ Class:LanguageCode
	|_ SubClass ISO639-1
		|_ Instance:en
		|_ Instance:fr
		|_ etc.
	|_ SubClass ISO639-2
		|_ Instance:eng
		|_ Instance:fra
		|_ etc.
	|_ etc.

Does anyone have similar experience with modelling in OWL? Any =
suggestions on
which model is better and (extensible)? Does an ontology already exist =
that
we can reuse?

Than you,=20
Gauri

This email was sent to you by = Reuters,=20 the global news and information company.
To find out more about = Reuters=20 visit www.about.reuters.com=20

Any views expressed in this message are those of the individual = sender,=20 except where the sender specifically states them to be the views of = Reuters=20 Limited.

Reuters Limited is part of the Reuters Group of companies, of = which=20 Reuters Group PLC is the ultimate parent company. Reuters Group PLC = -=20 Registered office address: The Reuters Building, South Colonnade, = Canary=20 Wharf, London E14 5EP, United Kingdom
Registered No:=20 3296375
Registered in England and Wales=20

------=_NextPart_000_03F8_01C78602.C967AD20-- --===============1305946159== 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 --===============1305946159==-- From ltru-bounces@ietf.org Mon Apr 23 21:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9qO-0004f3-6z; Mon, 23 Apr 2007 21:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9qN-0004ex-FM for ltru@ietf.org; Mon, 23 Apr 2007 21:29:23 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9qM-0007ZP-8G for ltru@ietf.org; Mon, 23 Apr 2007 21:29:23 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hg9qJ-0003uc-HY; Mon, 23 Apr 2007 21:29:19 -0400 Date: Mon, 23 Apr 2007 21:29:19 -0400 To: Kent Karlsson Subject: Re: [Ltru] updated editor's copy to deal with 'mis', etc. Message-ID: <20070424012919.GJ9522@mercury.ccil.org> References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> <00c201c785f9$fa17e790$5072f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c201c785f9$fa17e790$5072f853@streamserve.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > In plain English, yes. But "special" is used in a technical meaning > in 639: only 'mul', 'und', and now 'zxx' are "special codes". 'mis' > is not special in that sense, and "special collection code" seem to > mix the concepts. Ok, one could say that "'mis' is a special case > among the collection codes" without any greater fear that that is > misread. +1 -- But you, Wormtongue, you have done what you could for your true master. Some reward you have earned at least. Yet Saruman is apt to overlook his bargains. I should advise you to go quickly and remind him, lest he forget your faithful service. --Gandalf John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 23 21:35: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 1Hg9vv-0007Yk-2t; Mon, 23 Apr 2007 21:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9vu-0007Yc-8i for ltru@ietf.org; Mon, 23 Apr 2007 21:35:06 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9vs-0008NP-W5 for ltru@ietf.org; Mon, 23 Apr 2007 21:35:06 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1674486wri for ; Mon, 23 Apr 2007 18:35: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=HkJ84hh+68k4d9DeXg+m49FdhpoXYrgGQyU/HQfuwGwnG+Vc//Go7pV1KMM7qASxgud9FRqiHxV8NPrGHoYbz/CDCcRa18R763KmVJtPD1OIQr75Ab8BW1HIy+/Pnl+av+qvUduR83ASE4BR9TiqCp3SbNQ8vJ2O6Pq3m8hFDuA= 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=NhYSoQNBeppJJX/srPonZbb7l5f3SZwA5EkxK9zj06EOTgi4qalq1uvVVZC8f3dP7W/OhM4JACIrHnexTls4+EzJMrbuDSyFY9QnEudvpPmPiOUGAElT83++Jtbd9qbfcuUZNouzjSCfqy+faqFrzvBUY0mQ/u+QScI/A1Pj18c= Received: by 10.114.155.1 with SMTP id c1mr2808595wae.1177378504227; Mon, 23 Apr 2007 18:35:04 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 23 Apr 2007 18:35:04 -0700 (PDT) Message-ID: <30b660a20704231835j5e87db13v2486e03b8134b861@mail.gmail.com> Date: Mon, 23 Apr 2007 18:35:04 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] updated editor's copy to deal with 'mis', etc. In-Reply-To: <20070424012919.GJ9522@mercury.ccil.org> MIME-Version: 1.0 References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> <00c201c785f9$fa17e790$5072f853@streamserve.com> <20070424012919.GJ9522@mercury.ccil.org> X-Google-Sender-Auth: 0f088a6d2ac1ff70 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: LTRU Working Group , Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0184047594==" Errors-To: ltru-bounces@ietf.org --===============0184047594== Content-Type: multipart/alternative; boundary="----=_Part_12259_5291143.1177378504149" ------=_Part_12259_5291143.1177378504149 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, beaten into submission. How about: 4. The 'mis' (Miscellaneous) primary language subtag is a particular collection code used to Mark On 4/23/07, John Cowan wrote: > > Kent Karlsson scripsit: > > > In plain English, yes. But "special" is used in a technical meaning > > in 639: only 'mul', 'und', and now 'zxx' are "special codes". 'mis' > > is not special in that sense, and "special collection code" seem to > > mix the concepts. Ok, one could say that "'mis' is a special case > > among the collection codes" without any greater fear that that is > > misread. > > +1 > > -- > But you, Wormtongue, you have done what you could for your true > master. Some > reward you have earned at least. Yet Saruman is apt to overlook his > bargains. > I should advise you to go quickly and remind him, lest he forget your > faithful > service. --Gandalf John Cowan > -- Mark ------=_Part_12259_5291143.1177378504149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok, beaten into submission. How about:

4.  The 'mis' (Miscellaneous) primary language subtag
is a particular collection code used to

Mark

On 4/23/07, John Cowan <cowan@ccil.org> wrote:
Kent Karlsson scripsit:

> In plain English, yes. But "special" is used in a technical meaning
> in 639: only 'mul', 'und', and now 'zxx' are "special codes". 'mis'
> is not special in that sense, and "special collection code" seem to
> mix the concepts. Ok, one could say that "'mis' is a special case
> among the collection codes" without any greater fear that that is
> misread.

+1

--
But you, Wormtongue, you have done what you could for your true master.  Some
reward you have earned at least.  Yet Saruman is apt to overlook his bargains.
I should advise you to go quickly and remind him, lest he forget your faithful
service.  --Gandalf             John Cowan <cowan@ccil.org>



--
Mark ------=_Part_12259_5291143.1177378504149-- --===============0184047594== 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 --===============0184047594==-- From ltru-bounces@ietf.org Tue Apr 24 01:54: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 1HgDyv-0001vg-7p; Tue, 24 Apr 2007 01:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgDyt-0001mi-4x for ltru@ietf.org; Tue, 24 Apr 2007 01:54:27 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgDyr-0000RJ-Pm for ltru@ietf.org; Tue, 24 Apr 2007 01:54: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 <20070424055425.OIIV19599.mta10.adelphia.net@DGBP7M81>; Tue, 24 Apr 2007 05:54:25 +0000 Message-ID: <002401c78635$041f5760$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: Date: Mon, 23 Apr 2007 22:54: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> At the specified address, you can find the language subtag registry >> but not the actual registration forms. > > This is specially annoying since, apparently, the "official" > registration form, the one which was sent to the IANA, does not seem > to be always publically available. For instance, the form for the > variant "baku1926" did not appear in ietf-languages (to find out what > it looked like, you have to read several messages and to integrate the > various patches proposed and accepted). This would be easier if we could require the proposer to be responsible for updating his or her own form, and resubmitting it as necessary to reflect changes required by the Reviewer or recommended by the list. Some registration forms over the past year have required major clarification or other cleanup before they were well-defined enough to go into the Registry. I've always thought we were doing the proposer a service by considering and registering their subtags based on incomplete or vague forms plus a lot of discussion. Probably this was misguided. Those of you who have experience with proposals for ISO, ANSI, BSI, WG2, Unicode, etc., either at the submitting or evaluating end, can probably share the pros and cons of the approaches taken by those bodies, and suggest a better way forward for us. Addison Phillips wrote: > I too find it questionable when the final registered format is not > sent to the list prior to forwarding (or at least as part of > forwarding) to IANA. In fact, I suspect that, given the stability > guarantees and rules in RFC 4646, such registrations can be appealed > if they differ from the requested record. I agree that the final record that is sent to IANA should be cc'd to ietf-languages (not LTRU). I would not tend to agree that it should be sent *before* final submission to IANA; that is what the review period is for. -- 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 Apr 24 02:10: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 1HgEED-00079W-S9; Tue, 24 Apr 2007 02:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgEED-00079O-A9 for ltru@ietf.org; Tue, 24 Apr 2007 02:10:17 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEEB-00084F-1A for ltru@ietf.org; Tue, 24 Apr 2007 02:10:17 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HgEEA-0005qF-4f; Tue, 24 Apr 2007 02:10:14 -0400 Date: Tue, 24 Apr 2007 02:10:14 -0400 To: Doug Ewell Message-ID: <20070424061013.GO9522@mercury.ccil.org> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c78635$041f5760$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > This would be easier if we could require the proposer to be responsible > for updating his or her own form, and resubmitting it as necessary to > reflect changes required by the Reviewer or recommended by the list. > Some registration forms over the past year have required major > clarification or other cleanup before they were well-defined enough to > go into the Registry. This is true but addresses a different point. It's too hard to find the final registration form afterwards, which after all is the fullest available definition of the variant. It needs to go to IANA as well as the record. These are the equivalent of the forms that currently appear for 1766/3066 in http://www.iana.org/assignments/lang-tags/ . -- Principles. You can't say A is John Cowan made of B or vice versa. All mass http://www.ccil.org/~cowan is interaction. --Richard Feynman _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 02:16: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 1HgEK5-0003C6-KR; Tue, 24 Apr 2007 02:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgEK4-0003C1-W1 for ltru@ietf.org; Tue, 24 Apr 2007 02:16:20 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEK3-0001zQ-LU for ltru@ietf.org; Tue, 24 Apr 2007 02:16:20 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RUNP3K5uEmTAYRBpUiEkNoiYCASZMI5WbjnNxaE/rmwM3yXfXAiZ9jT3fTZw3LVs; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.134] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HgEK2-0007GC-Uf for ltru@ietf.org; Tue, 24 Apr 2007 02:16:19 -0400 Message-ID: <006901c78638$62279400$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002401c78635$041f5760$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Archival of registration forms Date: Mon, 23 Apr 2007 23:18: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7019285366d599346df63413326189560350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.134 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" ; > Sent: Monday, April 23, 2007 10:54 PM > Subject: [Ltru] Re: Archival of registration forms > > Stephane Bortzmeyer wrote: > > >> At the specified address, you can find the language subtag registry > >> but not the actual registration forms. A longstanding problem which needs to be fixed. RFC 4646 section 3.5 requires the approved registration forms (as submitted to IANA by the language subtag reviewer, in my reading) to be available. ... > I've always thought we were doing the proposer a service by considering > and registering their subtags based on incomplete or vague forms plus a > lot of discussion. Probably this was misguided. I don't think so. IANA needs to retain and make available copies of the registration forms submitted by the language subtag reviewer. Do we need to add words to make that clearer? Are the updated registration form not currently making it to IANA, or is IANA not making available the registration forms it receiveds? ... > I agree that the final record that is sent to IANA should be cc'd to > ietf-languages (not LTRU). I would not tend to agree that it should be > sent *before* final submission to IANA; that is what the review period > is for. ... IANA needs more than the final record. IANA also needs to receive the corresponding registration request for its records, to meet the requirements of RFC 4646 section 3.5 Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 02:51: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 1HgEsU-0002U5-Q0; Tue, 24 Apr 2007 02:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgEsT-0002Te-FX for ltru@ietf.org; Tue, 24 Apr 2007 02:51:53 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEsN-0004e3-Dp for ltru@ietf.org; Tue, 24 Apr 2007 02:51:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 5E2A64D77; Tue, 24 Apr 2007 15:51:42 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro.w3.mag.keio.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQL1kMGpOpcn; Tue, 24 Apr 2007 15:51:42 +0900 (JST) Received: from [127.0.0.1] (p4036-ipad508marunouchi.tokyo.ocn.ne.jp [222.148.91.36]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id F2DFA4CBC; Tue, 24 Apr 2007 15:51:41 +0900 (JST) Message-ID: <462DA8F7.1080209@w3.org> Date: Tue, 24 Apr 2007 15:51:35 +0900 From: Felix Sasaki User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Elisa F. Kendall" References: <462D455B.1030602@sandsoft.com> In-Reply-To: <462D455B.1030602@sandsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: 'LTRU Working Group' , 'Semantic web list' , 'WWW International' , Debbie Garside Subject: [Ltru] Re: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Elisa, Elisa F. Kendall wrote: > Hi Debbie, > > Thanks for the warning. We did know that it was incomplete, but are=20 > interested in representations of place names in local languages, so=20 > having a structure for capturing this information, even if incomplete,=20 > is useful. Debbie might expect that I point you to this: CLDR [1] already has such=20 as structure, and the structure is filled with region (and other) names=20 in many "locales". See an excerpt of locale display names for English bel= ow: [...] German [...] [...] Germany [...] Traditional German orthography German orthography of 1996=20 [...] you might want to see if this is useful for your efforts. Regards, Felix. [1] http://unicode.org/cldr/index.html > We're also looking at other government and research community=20 > resources to assist with both structure and content. If you have=20 > suggestions for references, that would be helpful. > > Best regards, > > Elisa > > Debbie Garside wrote: >> Please be very careful with the use of the "Administrative Language"=20 >> information from ISO 3166-1. It is incomplete and therefore not good=20 >> data. >> =20 >> For example, it shows only two "Administrative Languages" for India=20 >> where there are at least twenty-two. I am hoping that this=20 >> information will be taken out of the standard in the near future. I=20 >> am currently writing an ISO NWIP for a revision of ISO 3166-1 which=20 >> will include a proposal for the deletion of this data. >> =20 >> Best regards >> =20 >> Debbie Garside >> Editor ISO DIS 639-6 >> www.geolang.com >> >> ------------------------------------------------------------------= ------ >> *From:* www-international-request@w3.org >> [mailto:www-international-request@w3.org] *On Behalf Of *Elisa F. >> Kendall >> *Sent:* 23 April 2007 18:25 >> *To:* Misha Wolf >> *Cc:* Gauri.Salokhe@FAO.ORG; WWW International; Semantic web >> list; LTRU Working Group >> *Subject:* Re: [Fwd: Language Ontology] >> >> Hi Misha, >> >> We are very aware of it, and have been following the work, but I >> failed to mention it in the email. I should say that our >> ontology was developed for offline use in an internal system, as >> an initial requirement. Having said that, if you look at the >> RFCs, they only describe tags, not an RDF vocabulary or OWL >> ontology. Our approach is compatible with the RFCs but adds >> capabilities that support co-reference resolution, for example, >> in target application. >> >> Best, >> >> Elisa >> >> Misha Wolf wrote: >>> This sounds very worrying as you don't seem to be aware of BCP 47= . >>> =20 >>> Misha >>> >>> -----------------------------------------------------------------= ------- >>> *From:* www-international-request@w3.org >>> [mailto:www-international-request@w3.org] *On Behalf Of *Elisa >>> F. Kendall >>> *Sent:* 23 April 2007 17:32 >>> *To:* Gauri.Salokhe@FAO.ORG >>> *Cc:* 'WWW International'; Semantic web list >>> *Subject:* Re: [Fwd: Language Ontology] >>> >>> Hi Gauri, >>> >>> We've done this for some of our government customers, using >>> essentially the second approach you cite. We're also in the >>> process of relating the ontology to another one we've built to >>> represent ISO 3166, which includes the administrative languages >>> used by countries and non-sovereign territories represented in >>> that standard. >>> >>> If you can hang out for a few days, we (Sandpiper) are just >>> finalizing a version that includes both ISO 639-1 and 639-2. The >>> approach is more of a hybrid of the two you present, based on >>> customer needs. It includes a fragment of ISO 1087, and also >>> some inverse relations since there is a one-to-one >>> correspondence between languages and codes. We elected to >>> create a 'Language' class, rather than 'LanguageCode', which we >>> reuse in other applications; classes for Alpha-2Code and >>> Alpha-3Code are subclasses of CodeElement, from ISO 5127, with >>> instances of these codes as first class individuals. We use >>> literals (via datatype properties) to represent the set of >>> English, French, and in the case of 639-1 Indigenous names.=20 >>> We've also created subclasses of Alpha-3Code to support >>> distinctions between bibliographic and terminologic, collective, >>> and special identifiers, with individual and macrolanguages to >>> support 639-3. A subsequent release will include all of the >>> languages described in ISO 639-3, as well as additions to >>> support at least some of the subtagging that Dan mentions, fyi.=20 >>> Our intent is to publish it on a new portal that will become >>> part of a new service offered by the Ontology PSIG in the OMG, >>> since we've been asked to publish several ontologies in recent >>> RFPs. I'll be happy to send our preliminary version when it's >>> "baked and tested", and follow up with an announcement of the >>> new portal (where a revision using OMG URIs will be posted) once >>> that's available. It may be a couple of months before we're >>> ready to make that announcement, but we're hoping that the >>> service will be useful to many of us in the Semantic Web communit= y. >>> >>> Best regards, >>> >>> Elisa >>> >>> Dan Brickley wrote: >>>> >>>> Forwarding from the Dublin Core list, in case folk here can >>>> advise. >>>> >>>> Gauri, one thing I'd suggest as useful would be to take the >>>> concepts implicit in RFC 4646, >>>> >>>> http://www.rfc-editor.org/rfc/rfc4646.txt >>>> see also >>>> http://www.w3.org/International/articles/language-tags/Overview.= en.php >>>> >>>> >>>> ...and in particular the subtag mechanism, script, region, >>>> variant etc. >>>> >>>> It would be great to have those expressed explicitly. >>>> >>>> cheers, >>>> >>>> Dan >>>> >>>> ----------------------------------------------------------------= -------- >>>> >>>> Subject: >>>> Language Ontology >>>> From: >>>> "Salokhe, Gauri (KCEW)" >>>> Date: >>>> Mon, 23 Apr 2007 17:28:39 +0200 >>>> To: >>>> DC-GENERAL@JISCMAIL.AC.UK >>>> >>>> To: >>>> DC-GENERAL@JISCMAIL.AC.UK >>>> >>>> >>>> Dear All,=20 >>>> >>>> We are working on creating Ontology for languages. The need came= up as we >>>> tried to convert our XML metadata files into OWL. In our metadat= a (XML) >>>> records, we have three types of occurrences of language informat= ion.=20 >>>> >>>> En >>>> eng >>>> English >>>> >>>> >>>> We have two options for modelling the language ontology: >>>> >>>> 1) Create a class for each language, assign URI to it and add al= l the other >>>> lexical variations, ISO codes (create datatype property) as foll= ows: >>>> >>>> OWL:Thing >>>> |_ Class:Language >>>> |_ Instance:URI1 >>>> |_ rdfs:label xml:lang=3D"en" English >>>> |_ rdfs:label xml:lang=3D"es" Ingl=E9s >>>> |_ rdfs:label xml:lang=3D"it" Inglese >>>> |_ rdfs:label xml:lang=3D"fr" Anglais >>>> |_ etc. >>>> |_ property:hasISO639-1Code en (string) >>>> |_ property:hasISO639-2Code eng (string) >>>> |_ etc. >>>> |_ Instance:URI2 >>>> |_ Instance:URI3 >>>> |_ Instance:URI4 >>>> >>>> >>>> 2) Create Classes called Language and Language code and make lin= ks between >>>> instances of Language and Language Codes as follows: >>>> >>>> >>>> OWL:Thing >>>> |_ Class:Language >>>> |_ Instance:URI1 >>>> |_ property:hasCode en (link to the en instance of Class >>>> ISO639-1 below) >>>> |_ property:hasCode eng (link to the eng instance of Class >>>> ISO639-1 below) >>>> >>>> |_ Class:LanguageCode >>>> |_ SubClass ISO639-1 >>>> |_ Instance:en >>>> |_ Instance:fr >>>> |_ etc. >>>> |_ SubClass ISO639-2 >>>> |_ Instance:eng >>>> |_ Instance:fra >>>> |_ etc. >>>> |_ etc. >>>> >>>> Does anyone have similar experience with modelling in OWL? Any s= uggestions on >>>> which model is better and (extensible)? Does an ontology already= exist that >>>> we can reuse? >>>> >>>> Than you,=20 >>>> Gauri >>>> =20 >>> >>> This email was sent to you by Reuters, the global news and >>> information company. >>> To find out more about Reuters visit www.about.reuters.com >>> >>> Any views expressed in this message are those of the individual >>> sender, except where the sender specifically states them to be >>> the views of Reuters Limited. >>> >>> Reuters Limited is part of the Reuters Group of companies, of >>> which Reuters Group PLC is the ultimate parent company. Reuters >>> Group PLC - Registered office address: The Reuters Building, >>> South Colonnade, Canary Wharf, London E14 5EP, United Kingdom >>> Registered No: 3296375 >>> Registered in England and Wales >>> _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 03:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFWq-0007gw-7B; Tue, 24 Apr 2007 03:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFWn-0007gW-GQ for ltru@ietf.org; Tue, 24 Apr 2007 03:33:34 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFWl-0005vZ-3C for ltru@ietf.org; Tue, 24 Apr 2007 03:33:33 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 99ED91C00F6; Tue, 24 Apr 2007 09:33:30 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 94B1C1C00F3; Tue, 24 Apr 2007 09:33:29 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 907B158EBC5; Tue, 24 Apr 2007 09:33:29 +0200 (CEST) Date: Tue, 24 Apr 2007 09:33:29 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20070424073329.GA31358@nic.fr> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c78635$041f5760$6401a8c0@DGBP7M81> 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-languages@iana.org Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Apr 23, 2007 at 10:54:25PM -0700, Doug Ewell wrote a message of 52 lines which said: > This would be easier if we could require the proposer to be > responsible for updating his or her own form, I do not see why. By definition, *someone* (probably the LSR) edits the final form (the one sent to IANA). So, it is simply a matter of copying it. > Some registration forms over the past year have required major > clarification or other cleanup before they were well-defined enough > to go into the Registry. That's precisely why it is important to have the final form: understanding "valencia" or "1926baku" currently requires reading many messages in the ietf-languages archive. 12 months from now, it will be quite difficult and problems already discussed on ietf-languages may surface again. > I've always thought we were doing the proposer a service by > considering and registering their subtags based on incomplete or > vague forms plus a lot of discussion. Probably this was misguided. Not at all. This is perfectly right. I never suggested that the registration forms be accepted "as is" or flatly rejected. Patching them is fine, as long as the final form (which, I repeat, already exists, I do not suggest to increase the amount of work for the LSR) is publically available. > I agree that the final record that is sent to IANA should be cc'd to > ietf-languages (not LTRU). It is not what the RFC currently says (section 3.5 which I quoted at the beginning of the thread). Your proposal has merits but, in that case, please suggest a change in draft-ietf-ltru-4646bis-04 to the LTRU working group. I would suggest that, in that case, a link to the archived message is added in the Comments field of the registry. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 03:38: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 1HgFbP-0003Im-FB; Tue, 24 Apr 2007 03:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFbO-0003Hx-PD for ltru@ietf.org; Tue, 24 Apr 2007 03:38:18 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFbN-0007Vt-Gi for ltru@ietf.org; Tue, 24 Apr 2007 03:38:18 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 2CD221C00F3; Tue, 24 Apr 2007 09:38:17 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 278ED1C00F1; Tue, 24 Apr 2007 09:38:15 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 24C6F58EBC5; Tue, 24 Apr 2007 09:38:15 +0200 (CEST) Date: Tue, 24 Apr 2007 09:38:15 +0200 From: Stephane Bortzmeyer To: David Conrad Message-ID: <20070424073815.GB31358@nic.fr> References: <20070423141615.GA13303@nic.fr> <04C79A15-E242-4B94-A064-60A56F5880D6@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04C79A15-E242-4B94-A064-60A56F5880D6@icann.org> 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: 79899194edc4f33a41f49410777972f8 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Apr 23, 2007 at 08:09:56AM -0700, David Conrad wrote a message of 41 lines which said: > The reference in 4646 is almost certainly wrong as that URL points > to the list of the registries IANA maintains and does not generally > contain references to forms. Do note that the IANA considerations of RFC 4646 mandates IANA to: Future work on the Language Subtag Registry SHALL be limited to inserting or replacing whole records preformatted for IANA by the Language Subtag Reviewer as described in Section 3.3 of this document and archiving the forwarded registration form. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But "archiving" perhaps does not imply "making publically available". Do you think it should be more precise in 4646bis? If so, I can suggest a wording. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 03:54: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 1HgFrI-0004QN-I9; Tue, 24 Apr 2007 03:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFrG-0004Jj-Uo for ltru@ietf.org; Tue, 24 Apr 2007 03:54:42 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFrF-0002gv-NH for ltru@ietf.org; Tue, 24 Apr 2007 03:54:42 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HgFrD-0003cz-2I; Tue, 24 Apr 2007 03:54:39 -0400 Date: Tue, 24 Apr 2007 03:54:39 -0400 To: Stephane Bortzmeyer Message-ID: <20070424075438.GS9522@mercury.ccil.org> References: <20070423141615.GA13303@nic.fr> <04C79A15-E242-4B94-A064-60A56F5880D6@icann.org> <20070424073815.GB31358@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070424073815.GB31358@nic.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > But "archiving" perhaps does not imply "making publically > available". Do you think it should be more precise in 4646bis? If so, > I can suggest a wording. I think greater precision is obviously needed; also, IANA needs to take corrective action. Doug, has IANA actually been *getting* the whole form, or do they just get the new or changed record? -- John Cowan http://ccil.org/~cowan cowan@ccil.org There are books that are at once excellent and boring. Those that at once leap to the mind are Thoreau's Walden, Emerson's Essays, George Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 03:55: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 1HgFsU-0004nr-Ki; Tue, 24 Apr 2007 03:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFsS-0004nl-Hp for ltru@ietf.org; Tue, 24 Apr 2007 03:55:57 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFsR-0002uG-8u for ltru@ietf.org; Tue, 24 Apr 2007 03:55:56 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id E5E911C00F3; Tue, 24 Apr 2007 09:55:54 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E15791C00F1; Tue, 24 Apr 2007 09:55:53 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DE4A458EBC5; Tue, 24 Apr 2007 09:55:53 +0200 (CEST) Date: Tue, 24 Apr 2007 09:55:53 +0200 From: Stephane Bortzmeyer To: Randy Presuhn Message-ID: <20070424075553.GA31533@nic.fr> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <006901c78638$62279400$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006901c78638$62279400$6601a8c0@oemcomputer> 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: LTRU Working Group Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Apr 23, 2007 at 11:18:31PM -0700, Randy Presuhn wrote a message of 49 lines which said: > A longstanding problem which needs to be fixed. RFC 4646 section > 3.5 requires the approved registration forms (as submitted to IANA > by the language subtag reviewer, in my reading) to be available. Yes. Whatever the reason of the lack of availability (remember that David Conrad, IANA director, wrote he is searching why) IMHO, it should be fixed. But for LTRU, it may also be time to consider a change to make this obligation clearer in 4646bis? > Are the updated registration form not currently making it to IANA, That would be strange since they receive the registration requests and they act on it. > or is IANA not making available the registration forms it receiveds? My guess is that the need to distribute the registration forms was overlooked. Now that several variants have been registered, we notice the problem. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 04:17: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 1HgGDO-0007Th-1O; Tue, 24 Apr 2007 04:17:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGDM-0007TW-QS for ltru@lists.ietf.org; Tue, 24 Apr 2007 04:17:32 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgGDK-0008Ea-BH for ltru@lists.ietf.org; Tue, 24 Apr 2007 04:17:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HgGDC-0007ZP-SV for ltru@lists.ietf.org; Tue, 24 Apr 2007 10:17:22 +0200 Received: from 1cust218.tnt5.hbg2.deu.da.uu.net ([149.225.16.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Apr 2007 10:17:22 +0200 Received: from nobody by 1cust218.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Apr 2007 10:17:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 24 Apr 2007 10:16:57 +0200 Organization: Lines: 12 Message-ID: <462DBCF9.1720@xyzzy.claranet.de> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <20070424061013.GO9522@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust218.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > These are the equivalent of the forms that currently appear > for 1766/3066 in http://www.iana.org/assignments/lang-tags/ . Yes, that's the place where the registration templates should be collectedd + published. At most one file per registered subtag is enough. And of course no file for subtags created by a bulk update like 4645 or 4645bis. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 04:18: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 1HgGDy-0007o9-AC; Tue, 24 Apr 2007 04:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Ht-0000kb-VF for ltru@ietf.org; Mon, 23 Apr 2007 13:25:17 -0400 Received: from smtp111.sbc.mail.mud.yahoo.com ([68.142.198.210]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg2Hs-0007Rn-0w for ltru@ietf.org; Mon, 23 Apr 2007 13:25:17 -0400 Received: (qmail 66234 invoked from network); 23 Apr 2007 17:25:15 -0000 Received: from unknown (HELO ?192.168.1.2?) (e.kendall@sbcglobal.net@75.24.196.98 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 23 Apr 2007 17:25:14 -0000 Message-ID: <462CEBF7.2070106@sandsoft.com> Date: Mon, 23 Apr 2007 10:25:11 -0700 From: "Elisa F. Kendall" Organization: Sandpiper Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax; nscd1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Misha Wolf References: In-Reply-To: X-Spam-Score: 0.3 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 X-Mailman-Approved-At: Tue, 24 Apr 2007 04:18:08 -0400 Cc: WWW International , Semantic web list , Gauri.Salokhe@FAO.ORG, LTRU Working Group Subject: [Ltru] Re: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1233803151==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1233803151== Content-Type: multipart/alternative; boundary="------------010902060102050204040705" This is a multi-part message in MIME format. --------------010902060102050204040705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Misha, We are very aware of it, and have been following the work, but I failed to mention it in the email. I should say that our ontology was developed for offline use in an internal system, as an initial requirement. Having said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology. Our approach is compatible with the RFCs but adds capabilities that support co-reference resolution, for example, in target application. Best, Elisa Misha Wolf wrote: > This sounds very worrying as you don't seem to be aware of BCP 47. > > Misha > > ------------------------------------------------------------------------ > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall > Sent: 23 April 2007 17:32 > To: Gauri.Salokhe@FAO.ORG > Cc: 'WWW International'; Semantic web list > Subject: Re: [Fwd: Language Ontology] > > Hi Gauri, > > We've done this for some of our government customers, using > essentially the second approach you cite. We're also in the process > of relating the ontology to another one we've built to represent ISO > 3166, which includes the administrative languages used by countries > and non-sovereign territories represented in that standard. > > If you can hang out for a few days, we (Sandpiper) are just finalizing > a version that includes both ISO 639-1 and 639-2. The approach is more > of a hybrid of the two you present, based on customer needs. It > includes a fragment of ISO 1087, and also some inverse relations since > there is a one-to-one correspondence between languages and codes. We > elected to create a 'Language' class, rather than 'LanguageCode', > which we reuse in other applications; classes for Alpha-2Code and > Alpha-3Code are subclasses of CodeElement, from ISO 5127, with > instances of these codes as first class individuals. We use literals > (via datatype properties) to represent the set of English, French, and > in the case of 639-1 Indigenous names. We've also created subclasses > of Alpha-3Code to support distinctions between bibliographic and > terminologic, collective, and special identifiers, with individual and > macrolanguages to support 639-3. A subsequent release will include > all of the languages described in ISO 639-3, as well as additions to > support at least some of the subtagging that Dan mentions, fyi. Our > intent is to publish it on a new portal that will become part of a new > service offered by the Ontology PSIG in the OMG, since we've been > asked to publish several ontologies in recent RFPs. I'll be happy to > send our preliminary version when it's "baked and tested", and follow > up with an announcement of the new portal (where a revision using OMG > URIs will be posted) once that's available. It may be a couple of > months before we're ready to make that announcement, but we're hoping > that the service will be useful to many of us in the Semantic Web > community. > > Best regards, > > Elisa > > Dan Brickley wrote: > >> >> Forwarding from the Dublin Core list, in case folk here can advise. >> >> Gauri, one thing I'd suggest as useful would be to take the concepts >> implicit in RFC 4646, >> >> http://www.rfc-editor.org/rfc/rfc4646.txt >> see also >> http://www.w3.org/International/articles/language-tags/Overview.en.php >> >> ...and in particular the subtag mechanism, script, region, variant etc. >> >> It would be great to have those expressed explicitly. >> >> cheers, >> >> Dan >> >> ------------------------------------------------------------------------ >> >> Subject: >> Language Ontology >> From: >> "Salokhe, Gauri (KCEW)" >> Date: >> Mon, 23 Apr 2007 17:28:39 +0200 >> To: >> DC-GENERAL@JISCMAIL.AC.UK >> >> To: >> DC-GENERAL@JISCMAIL.AC.UK >> >> >>Dear All, >> >>We are working on creating Ontology for languages. The need came up as we >>tried to convert our XML metadata files into OWL. In our metadata (XML) >>records, we have three types of occurrences of language information. >> >>En >>eng >>English >> >> >>We have two options for modelling the language ontology: >> >>1) Create a class for each language, assign URI to it and add all the other >>lexical variations, ISO codes (create datatype property) as follows: >> >>OWL:Thing >>|_ Class:Language >> |_ Instance:URI1 >> |_ rdfs:label xml:lang="en" English >> |_ rdfs:label xml:lang="es" Inglés >> |_ rdfs:label xml:lang="it" Inglese >> |_ rdfs:label xml:lang="fr" Anglais >> |_ etc. >> |_ property:hasISO639-1Code en (string) >> |_ property:hasISO639-2Code eng (string) >> |_ etc. >> |_ Instance:URI2 >> |_ Instance:URI3 >> |_ Instance:URI4 >> >> >>2) Create Classes called Language and Language code and make links between >>instances of Language and Language Codes as follows: >> >> >>OWL:Thing >>|_ Class:Language >> |_ Instance:URI1 >> |_ property:hasCode en (link to the en instance of Class >>ISO639-1 below) >> |_ property:hasCode eng (link to the eng instance of Class >>ISO639-1 below) >> >>|_ Class:LanguageCode >> |_ SubClass ISO639-1 >> |_ Instance:en >> |_ Instance:fr >> |_ etc. >> |_ SubClass ISO639-2 >> |_ Instance:eng >> |_ Instance:fra >> |_ etc. >> |_ etc. >> >>Does anyone have similar experience with modelling in OWL? Any suggestions on >>which model is better and (extensible)? Does an ontology already exist that >>we can reuse? >> >>Than you, >>Gauri >> >> > > This email was sent to you by Reuters, the global news and information > company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be the > views of Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of which > Reuters Group PLC is the ultimate parent company. Reuters Group PLC - > Registered office address: The Reuters Building, South Colonnade, > Canary Wharf, London E14 5EP, United Kingdom > Registered No: 3296375 > Registered in England and Wales > --------------010902060102050204040705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Misha,

We are very aware of it, and have been following the work, but I failed to mention it in the email.  I should say that our ontology was developed for offline use in an internal system, as an initial requirement.  Having said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology.  Our approach is compatible with the RFCs but adds capabilities that support co-reference resolution, for example, in target application.

Best,

Elisa

Misha Wolf wrote:
This sounds very worrying as you don't seem to be aware of BCP 47.
 
Misha

From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall
Sent: 23 April 2007 17:32
To: Gauri.Salokhe@FAO.ORG
Cc: 'WWW International'; Semantic web list
Subject: Re: [Fwd: Language Ontology]

Hi Gauri,

We've done this for some of our government customers, using essentially the second approach you cite.  We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which includes the administrative languages used by countries and non-sovereign territories  represented in that standard.

If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of a hybrid of the two you present, based on customer needs.  It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes.  We elected to create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the set of English, French, and in the case of 639-1 Indigenous names.  We've also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, with individual and macrolanguages to support 639-3.  A subsequent release will include all of the languages described in ISO 639-3, as well as additions to support at least some of the subtagging that Dan mentions, fyi.  Our intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to publish several ontologies in recent RFPs.  I'll be happy to send our preliminary version when it's "baked and tested", and follow up with an announcement of the new portal (where a revision using OMG URIs will be posted) once that's available.  It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many of us in the Semantic Web community.

Best regards,

Elisa

Dan Brickley wrote:

Forwarding from the Dublin Core list, in case folk here can advise.

Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646,

http://www.rfc-editor.org/rfc/rfc4646.txt
see also http://www.w3.org/International/articles/language-tags/Overview.en.php

...and in particular the subtag mechanism, script, region, variant etc.

It would be great to have those expressed explicitly.

cheers,

Dan


Subject:
Language Ontology
From:
"Salokhe, Gauri (KCEW)" <Gauri.Salokhe@FAO.ORG>
Date:
Mon, 23 Apr 2007 17:28:39 +0200
To:
DC-GENERAL@JISCMAIL.AC.UK
To:
DC-GENERAL@JISCMAIL.AC.UK		 

Dear All, 

We are working on creating Ontology for languages. The need came up as we
tried to convert our XML metadata files into OWL. In our metadata (XML)
records, we have three types of occurrences of language information. 

<dc:language scheme="ags:ISO639-1">En</dc:language>
<dc:language scheme="dcterms:ISO639-2">eng</dc:language>
<dc:language>English</dc:language>


We have two options for modelling the language ontology:

1) Create a class for each language, assign URI to it and add all the other
lexical variations, ISO codes (create datatype property) as follows:

OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ rdfs:label xml:lang="en" English
		|_ rdfs:label xml:lang="es" Inglés
		|_ rdfs:label xml:lang="it" Inglese
		|_ rdfs:label xml:lang="fr" Anglais
		|_ etc.
		|_ property:hasISO639-1Code  en (string)
		|_ property:hasISO639-2Code  eng (string)
		|_ etc.
	|_ Instance:URI2
	|_ Instance:URI3
	|_ Instance:URI4


2) Create Classes called Language and Language code and make links between
instances of Language and Language Codes as follows:


OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ property:hasCode  en  (link to the en instance of Class
ISO639-1 below)
		|_ property:hasCode  eng  (link to the eng instance of Class
ISO639-1 below)

|_ Class:LanguageCode
	|_ SubClass ISO639-1
		|_ Instance:en
		|_ Instance:fr
		|_ etc.
	|_ SubClass ISO639-2
		|_ Instance:eng
		|_ Instance:fra
		|_ etc.
	|_ etc.

Does anyone have similar experience with modelling in OWL? Any suggestions on
which model is better and (extensible)? Does an ontology already exist that
we can reuse?

Than you, 
Gauri

This email was sent to you by Reuters, the global news and information company.
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales

--------------010902060102050204040705-- --===============1233803151== 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 --===============1233803151==-- From ltru-bounces@ietf.org Tue Apr 24 04:18: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 1HgGDy-0007q0-GS; Tue, 24 Apr 2007 04:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8F2-0006ld-PT for ltru@ietf.org; Mon, 23 Apr 2007 19:46:44 -0400 Received: from smtp113.sbc.mail.mud.yahoo.com ([68.142.198.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg8F0-0007dG-Ne for ltru@ietf.org; Mon, 23 Apr 2007 19:46:44 -0400 Received: (qmail 52288 invoked from network); 23 Apr 2007 23:46:42 -0000 Received: from unknown (HELO ?192.168.1.2?) (e.kendall@sbcglobal.net@75.24.196.98 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 23 Apr 2007 23:46:41 -0000 X-YMail-OSG: rPxrpdQVM1lhq60AFZhKRYIDkeil1u3geTkgMxsS7ZPKTqifwCJYqfO_EHUS.c6TzYVLVtyvwn35BZYDLu6JQ4jffwKbT6.tsVVz_7GO_ddOTSV4t6h8J.BjceIyGg-- Message-ID: <462D455B.1030602@sandsoft.com> Date: Mon, 23 Apr 2007 16:46:35 -0700 From: "Elisa F. Kendall" Organization: Sandpiper Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax; nscd1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Debbie Garside X-Spam-Score: 0.4 (/) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 X-Mailman-Approved-At: Tue, 24 Apr 2007 04:18:08 -0400 Cc: 'LTRU Working Group' , 'Semantic web list' , 'WWW International' Subject: [Ltru] Re: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0466313286==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0466313286== Content-Type: multipart/alternative; boundary="------------020405010903000202080103" This is a multi-part message in MIME format. --------------020405010903000202080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Debbie, Thanks for the warning. We did know that it was incomplete, but are interested in representations of place names in local languages, so having a structure for capturing this information, even if incomplete, is useful. We're also looking at other government and research community resources to assist with both structure and content. If you have suggestions for references, that would be helpful. Best regards, Elisa Debbie Garside wrote: > Please be very careful with the use of the "Administrative Language" > information from ISO 3166-1. It is incomplete and therefore not good > data. > > For example, it shows only two "Administrative Languages" for India > where there are at least twenty-two. I am hoping that this > information will be taken out of the standard in the near future. I > am currently writing an ISO NWIP for a revision of ISO 3166-1 which > will include a proposal for the deletion of this data. > > Best regards > > Debbie Garside > Editor ISO DIS 639-6 > www.geolang.com > > ------------------------------------------------------------------------ > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of Elisa F. > Kendall > Sent: 23 April 2007 18:25 > To: Misha Wolf > Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; > LTRU Working Group > Subject: Re: [Fwd: Language Ontology] > > Hi Misha, > > We are very aware of it, and have been following the work, but I > failed to mention it in the email. I should say that our ontology > was developed for offline use in an internal system, as an initial > requirement. Having said that, if you look at the RFCs, they only > describe tags, not an RDF vocabulary or OWL ontology. Our > approach is compatible with the RFCs but adds capabilities that > support co-reference resolution, for example, in target application. > > Best, > > Elisa > > Misha Wolf wrote: > >> This sounds very worrying as you don't seem to be aware of BCP 47. >> >> Misha >> >> ------------------------------------------------------------------------ >> From: www-international-request@w3.org >> [mailto:www-international-request@w3.org] On Behalf Of Elisa F. >> Kendall >> Sent: 23 April 2007 17:32 >> To: Gauri.Salokhe@FAO.ORG >> Cc: 'WWW International'; Semantic web list >> Subject: Re: [Fwd: Language Ontology] >> >> Hi Gauri, >> >> We've done this for some of our government customers, using >> essentially the second approach you cite. We're also in the >> process of relating the ontology to another one we've built to >> represent ISO 3166, which includes the administrative languages >> used by countries and non-sovereign territories represented in >> that standard. >> >> If you can hang out for a few days, we (Sandpiper) are just >> finalizing a version that includes both ISO 639-1 and 639-2. The >> approach is more of a hybrid of the two you present, based on >> customer needs. It includes a fragment of ISO 1087, and also >> some inverse relations since there is a one-to-one correspondence >> between languages and codes. We elected to create a 'Language' >> class, rather than 'LanguageCode', which we reuse in other >> applications; classes for Alpha-2Code and Alpha-3Code are >> subclasses of CodeElement, from ISO 5127, with instances of these >> codes as first class individuals. We use literals (via datatype >> properties) to represent the set of English, French, and in the >> case of 639-1 Indigenous names. We've also created subclasses of >> Alpha-3Code to support distinctions between bibliographic and >> terminologic, collective, and special identifiers, with >> individual and macrolanguages to support 639-3. A subsequent >> release will include all of the languages described in ISO 639-3, >> as well as additions to support at least some of the subtagging >> that Dan mentions, fyi. Our intent is to publish it on a new >> portal that will become part of a new service offered by the >> Ontology PSIG in the OMG, since we've been asked to publish >> several ontologies in recent RFPs. I'll be happy to send our >> preliminary version when it's "baked and tested", and follow up >> with an announcement of the new portal (where a revision using >> OMG URIs will be posted) once that's available. It may be a >> couple of months before we're ready to make that announcement, >> but we're hoping that the service will be useful to many of us in >> the Semantic Web community. >> >> Best regards, >> >> Elisa >> >> Dan Brickley wrote: >> >>> >>> Forwarding from the Dublin Core list, in case folk here can advise. >>> >>> Gauri, one thing I'd suggest as useful would be to take the >>> concepts implicit in RFC 4646, >>> >>> http://www.rfc-editor.org/rfc/rfc4646.txt >>> see also >>> http://www.w3.org/International/articles/language-tags/Overview.en.php >>> >>> >>> ...and in particular the subtag mechanism, script, region, >>> variant etc. >>> >>> It would be great to have those expressed explicitly. >>> >>> cheers, >>> >>> Dan >>> >>> ------------------------------------------------------------------------ >>> >>> Subject: >>> Language Ontology >>> From: >>> "Salokhe, Gauri (KCEW)" >>> Date: >>> Mon, 23 Apr 2007 17:28:39 +0200 >>> To: >>> DC-GENERAL@JISCMAIL.AC.UK >>> >>> To: >>> DC-GENERAL@JISCMAIL.AC.UK >>> >>> >>>Dear All, >>> >>>We are working on creating Ontology for languages. The need came up as we >>>tried to convert our XML metadata files into OWL. In our metadata (XML) >>>records, we have three types of occurrences of language information. >>> >>>En >>>eng >>>English >>> >>> >>>We have two options for modelling the language ontology: >>> >>>1) Create a class for each language, assign URI to it and add all the other >>>lexical variations, ISO codes (create datatype property) as follows: >>> >>>OWL:Thing >>>|_ Class:Language >>> |_ Instance:URI1 >>> |_ rdfs:label xml:lang="en" English >>> |_ rdfs:label xml:lang="es" Inglés >>> |_ rdfs:label xml:lang="it" Inglese >>> |_ rdfs:label xml:lang="fr" Anglais >>> |_ etc. >>> |_ property:hasISO639-1Code en (string) >>> |_ property:hasISO639-2Code eng (string) >>> |_ etc. >>> |_ Instance:URI2 >>> |_ Instance:URI3 >>> |_ Instance:URI4 >>> >>> >>>2) Create Classes called Language and Language code and make links between >>>instances of Language and Language Codes as follows: >>> >>> >>>OWL:Thing >>>|_ Class:Language >>> |_ Instance:URI1 >>> |_ property:hasCode en (link to the en instance of Class >>>ISO639-1 below) >>> |_ property:hasCode eng (link to the eng instance of Class >>>ISO639-1 below) >>> >>>|_ Class:LanguageCode >>> |_ SubClass ISO639-1 >>> |_ Instance:en >>> |_ Instance:fr >>> |_ etc. >>> |_ SubClass ISO639-2 >>> |_ Instance:eng >>> |_ Instance:fra >>> |_ etc. >>> |_ etc. >>> >>>Does anyone have similar experience with modelling in OWL? Any suggestions on >>>which model is better and (extensible)? Does an ontology already exist that >>>we can reuse? >>> >>>Than you, >>>Gauri >>> >>> >> >> This email was sent to you by Reuters, the global news and >> information company. >> To find out more about Reuters visit www.about.reuters.com >> >> Any views expressed in this message are those of the individual >> sender, except where the sender specifically states them to be >> the views of Reuters Limited. >> >> Reuters Limited is part of the Reuters Group of companies, of >> which Reuters Group PLC is the ultimate parent company. Reuters >> Group PLC - Registered office address: The Reuters Building, >> South Colonnade, Canary Wharf, London E14 5EP, United Kingdom >> Registered No: 3296375 >> Registered in England and Wales >> --------------020405010903000202080103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Debbie,

Thanks for the warning.  We did know that it was incomplete, but are interested in representations of place names in local languages, so having a structure for capturing this information, even if incomplete, is useful.  We're also looking at other government and research community resources to assist with both structure and content.  If you have suggestions for references, that would be helpful.

Best regards,

Elisa

Debbie Garside wrote:
Please be very careful with the use of the "Administrative Language" information from ISO 3166-1.  It is incomplete and therefore not good data.
 
For example, it shows only two "Administrative Languages" for India where there are at least twenty-two.  I am hoping that this information will be taken out of the standard in the near future.  I am currently writing an ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion of this data.
 
Best regards
 
Debbie Garside
Editor ISO DIS 639-6

From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall
Sent: 23 April 2007 18:25
To: Misha Wolf
Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group
Subject: Re: [Fwd: Language Ontology]

Hi Misha,

We are very aware of it, and have been following the work, but I failed to mention it in the email.  I should say that our ontology was developed for offline use in an internal system, as an initial requirement.  Having said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology.  Our approach is compatible with the RFCs but adds capabilities that support co-reference resolution, for example, in target application.

Best,

Elisa

Misha Wolf wrote:
This sounds very worrying as you don't seem to be aware of BCP 47.
 
Misha

From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall
Sent: 23 April 2007 17:32
To: Gauri.Salokhe@FAO.ORG
Cc: 'WWW International'; Semantic web list
Subject: Re: [Fwd: Language Ontology]

Hi Gauri,

We've done this for some of our government customers, using essentially the second approach you cite.  We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which includes the administrative languages used by countries and non-sovereign territories  represented in that standard.

If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of a hybrid of the two you present, based on customer needs.  It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes.  We elected to create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the set of English, French, and in the case of 639-1 Indigenous names.  We've also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, with individual and macrolanguages to support 639-3.  A subsequent release will include all of the languages described in ISO 639-3, as well as additions to support at least some of the subtagging that Dan mentions, fyi.  Our intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to publish several ontologies in recent RFPs.  I'll be happy to send our preliminary version when it's "baked and tested", and follow up with an announcement of the new portal (where a revision using OMG URIs will be posted) once that's available.  It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many of us in the Semantic Web community.

Best regards,

Elisa

Dan Brickley wrote:

Forwarding from the Dublin Core list, in case folk here can advise.

Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646,

http://www.rfc-editor.org/rfc/rfc4646.txt
see also http://www.w3.org/International/articles/language-tags/Overview.en.php

...and in particular the subtag mechanism, script, region, variant etc.

It would be great to have those expressed explicitly.

cheers,

Dan


Subject:
Language Ontology
From:
"Salokhe, Gauri (KCEW)" <Gauri.Salokhe@FAO.ORG>
Date:
Mon, 23 Apr 2007 17:28:39 +0200
To:
DC-GENERAL@JISCMAIL.AC.UK
To:
DC-GENERAL@JISCMAIL.AC.UK		 

Dear All, 

We are working on creating Ontology for languages. The need came up as we
tried to convert our XML metadata files into OWL. In our metadata (XML)
records, we have three types of occurrences of language information. 

<dc:language scheme="ags:ISO639-1">En</dc:language>
<dc:language scheme="dcterms:ISO639-2">eng</dc:language>
<dc:language>English</dc:language>


We have two options for modelling the language ontology:

1) Create a class for each language, assign URI to it and add all the other
lexical variations, ISO codes (create datatype property) as follows:

OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ rdfs:label xml:lang="en" English
		|_ rdfs:label xml:lang="es" Inglés
		|_ rdfs:label xml:lang="it" Inglese
		|_ rdfs:label xml:lang="fr" Anglais
		|_ etc.
		|_ property:hasISO639-1Code  en (string)
		|_ property:hasISO639-2Code  eng (string)
		|_ etc.
	|_ Instance:URI2
	|_ Instance:URI3
	|_ Instance:URI4


2) Create Classes called Language and Language code and make links between
instances of Language and Language Codes as follows:


OWL:Thing
|_ Class:Language
	|_ Instance:URI1
		|_ property:hasCode  en  (link to the en instance of Class
ISO639-1 below)
		|_ property:hasCode  eng  (link to the eng instance of Class
ISO639-1 below)

|_ Class:LanguageCode
	|_ SubClass ISO639-1
		|_ Instance:en
		|_ Instance:fr
		|_ etc.
	|_ SubClass ISO639-2
		|_ Instance:eng
		|_ Instance:fra
		|_ etc.
	|_ etc.

Does anyone have similar experience with modelling in OWL? Any suggestions on
which model is better and (extensible)? Does an ontology already exist that
we can reuse?

Than you, 
Gauri

This email was sent to you by Reuters, the global news and information company.
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales

--------------020405010903000202080103-- --===============0466313286== 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 --===============0466313286==-- From ltru-bounces@ietf.org Tue Apr 24 04:18: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 1HgGDy-0007sO-U3; Tue, 24 Apr 2007 04:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgEMM-0005qq-Hu for ltru@ietf.org; Tue, 24 Apr 2007 02:18:42 -0400 Received: from mail-proxy-be-01.sunrise.ch ([194.158.229.48] helo=smtp-auth-be-04.sunrise.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEML-0003Cy-4l for ltru@ietf.org; Tue, 24 Apr 2007 02:18:42 -0400 Received: from [192.168.1.33] (adsl-89-217-153-139.adslplus.ch [89.217.153.139]) by smtp-auth-be-04.sunrise.ch (8.13.1/8.13.5) with ESMTP id l3O6IFaZ018321; Tue, 24 Apr 2007 08:18:15 +0200 Message-ID: <462DA123.2000409@geonames.org> Date: Tue, 24 Apr 2007 08:18:11 +0200 From: Marc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: "Elisa F. Kendall" References: <462D455B.1030602@sandsoft.com> In-Reply-To: <462D455B.1030602@sandsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 24 Apr 2007 04:18:08 -0400 Cc: 'LTRU Working Group' , 'Semantic web list' , 'WWW International' , Debbie Garside Subject: [Ltru] Re: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Elisa A huge resource for place names in local languages is the geonames.org project [1]. The countryInfo in the export section includes the official languages per country and official languages for first order administrative divisions or even finer granularity should soon be available. Best regards Marc Wick www.geonames.org [1] http://www.geonames.org/export/ Elisa F. Kendall wrote: > Hi Debbie, > > Thanks for the warning. We did know that it was incomplete, but are > interested in representations of place names in local languages, so > having a structure for capturing this information, even if incomplete, > is useful. We're also looking at other government and research > community resources to assist with both structure and content. If you > have suggestions for references, that would be helpful. > > Best regards, > > Elisa _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 04:18: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 1HgGDz-0007u5-5N; Tue, 24 Apr 2007 04:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFgj-00023E-Ma for ltru@ietf.org; Tue, 24 Apr 2007 03:43:49 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFgh-0008Hl-U2 for ltru@ietf.org; Tue, 24 Apr 2007 03:43:49 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 24 Apr 2007 08:43:46 +0100 From: "Debbie Garside" To: "'Felix Sasaki'" , "'Elisa F. Kendall'" Date: Tue, 24 Apr 2007 08:43:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceGPVKVlMJiKfmEQAGjQccVsrOjiAABpSPA In-Reply-To: <462DA8F7.1080209@w3.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 X-Mailman-Approved-At: Tue, 24 Apr 2007 04:18:08 -0400 Cc: 'LTRU Working Group' , 'Semantic web list' , 'WWW International' Subject: [Ltru] RE: [Fwd: Language Ontology] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Message-Id: Felix wrote: > Debbie might expect that I point you to this: CLDR [1]=20 > already has such as structure, and the structure is filled=20 > with region (and other) names in many "locales".=20 Indeed! :-) Debbie > -----Original Message----- > From: www-international-request@w3.org=20 > [mailto:www-international-request@w3.org] On Behalf Of Felix Sasaki > Sent: 24 April 2007 07:52 > To: Elisa F. Kendall > Cc: Debbie Garside; 'WWW International'; 'Semantic web list';=20 > 'LTRU Working Group' > Subject: Re: [Fwd: Language Ontology] >=20 >=20 > Hello Elisa, >=20 > Elisa F. Kendall wrote: > > Hi Debbie, > > > > Thanks for the warning. We did know that it was=20 > incomplete, but are=20 > > interested in representations of place names in local languages, so=20 > > having a structure for capturing this information, even if=20 > incomplete,=20 > > is useful. >=20 > Debbie might expect that I point you to this: CLDR [1]=20 > already has such as structure, and the structure is filled=20 > with region (and other) names in many "locales". See an=20 > excerpt of locale display names for English below: >=20 > > [...] > > > > German [...] > > [...] > > Germany [...]=20 > > > Traditional German=20 > orthography > German orthography of=20 > 1996 [...] > >=20 > you might want to see if this is useful for your efforts. >=20 > Regards, Felix. >=20 > [1] http://unicode.org/cldr/index.html >=20 > > We're also looking at other government and research community=20 > > resources to assist with both structure and content. If you have=20 > > suggestions for references, that would be helpful. > > > > Best regards, > > > > Elisa > > > > Debbie Garside wrote: > >> Please be very careful with the use of the "Administrative=20 > Language"=20 > >> information from ISO 3166-1. It is incomplete and=20 > therefore not good=20 > >> data. > >> =20 > >> For example, it shows only two "Administrative Languages"=20 > for India=20 > >> where there are at least twenty-two. I am hoping that this=20 > >> information will be taken out of the standard in the near=20 > future. I=20 > >> am currently writing an ISO NWIP for a revision of ISO=20 > 3166-1 which=20 > >> will include a proposal for the deletion of this data. > >> =20 > >> Best regards > >> =20 > >> Debbie Garside > >> Editor ISO DIS 639-6 > >> www.geolang.com > >> > >> =20 > -------------------------------------------------------------- > ---------- > >> *From:* www-international-request@w3.org > >> [mailto:www-international-request@w3.org] *On Behalf=20 > Of *Elisa F. > >> Kendall > >> *Sent:* 23 April 2007 18:25 > >> *To:* Misha Wolf > >> *Cc:* Gauri.Salokhe@FAO.ORG; WWW International; Semantic web > >> list; LTRU Working Group > >> *Subject:* Re: [Fwd: Language Ontology] > >> > >> Hi Misha, > >> > >> We are very aware of it, and have been following the=20 > work, but I > >> failed to mention it in the email. I should say that our > >> ontology was developed for offline use in an internal=20 > system, as > >> an initial requirement. Having said that, if you look at the > >> RFCs, they only describe tags, not an RDF vocabulary or OWL > >> ontology. Our approach is compatible with the RFCs but adds > >> capabilities that support co-reference resolution, for example, > >> in target application. > >> > >> Best, > >> > >> Elisa > >> > >> Misha Wolf wrote: > >>> This sounds very worrying as you don't seem to be=20 > aware of BCP 47. > >>> =20 > >>> Misha > >>> > >>> =20 > -------------------------------------------------------------- > ---------- > >>> *From:* www-international-request@w3.org > >>> [mailto:www-international-request@w3.org] *On Behalf Of *Elisa > >>> F. Kendall > >>> *Sent:* 23 April 2007 17:32 > >>> *To:* Gauri.Salokhe@FAO.ORG > >>> *Cc:* 'WWW International'; Semantic web list > >>> *Subject:* Re: [Fwd: Language Ontology] > >>> > >>> Hi Gauri, > >>> > >>> We've done this for some of our government customers, using > >>> essentially the second approach you cite. We're also in the > >>> process of relating the ontology to another one we've built to > >>> represent ISO 3166, which includes the administrative=20 > languages > >>> used by countries and non-sovereign territories =20 > represented in > >>> that standard. > >>> > >>> If you can hang out for a few days, we (Sandpiper) are just > >>> finalizing a version that includes both ISO 639-1 and=20 > 639-2. The > >>> approach is more of a hybrid of the two you present, based on > >>> customer needs. It includes a fragment of ISO 1087, and also > >>> some inverse relations since there is a one-to-one > >>> correspondence between languages and codes. We elected to > >>> create a 'Language' class, rather than=20 > 'LanguageCode', which we > >>> reuse in other applications; classes for Alpha-2Code and > >>> Alpha-3Code are subclasses of CodeElement, from ISO 5127, with > >>> instances of these codes as first class individuals. We use > >>> literals (via datatype properties) to represent the set of > >>> English, French, and in the case of 639-1 Indigenous names.=20 > >>> We've also created subclasses of Alpha-3Code to support > >>> distinctions between bibliographic and terminologic,=20 > collective, > >>> and special identifiers, with individual and macrolanguages to > >>> support 639-3. A subsequent release will include all of the > >>> languages described in ISO 639-3, as well as additions to > >>> support at least some of the subtagging that Dan=20 > mentions, fyi.=20 > >>> Our intent is to publish it on a new portal that will become > >>> part of a new service offered by the Ontology PSIG in the OMG, > >>> since we've been asked to publish several ontologies in recent > >>> RFPs. I'll be happy to send our preliminary version when it's > >>> "baked and tested", and follow up with an announcement of the > >>> new portal (where a revision using OMG URIs will be=20 > posted) once > >>> that's available. It may be a couple of months before we're > >>> ready to make that announcement, but we're hoping that the > >>> service will be useful to many of us in the Semantic=20 > Web community. > >>> > >>> Best regards, > >>> > >>> Elisa > >>> > >>> Dan Brickley wrote: > >>>> > >>>> Forwarding from the Dublin Core list, in case folk here can > >>>> advise. > >>>> > >>>> Gauri, one thing I'd suggest as useful would be to take the > >>>> concepts implicit in RFC 4646, > >>>> > >>>> http://www.rfc-editor.org/rfc/rfc4646.txt > >>>> see also > >>>> =20 > >>>>=20 > http://www.w3.org/International/articles/language-tags/Overview.en. > >>>> php > >>>> > >>>> > >>>> ...and in particular the subtag mechanism, script, region, > >>>> variant etc. > >>>> > >>>> It would be great to have those expressed explicitly. > >>>> > >>>> cheers, > >>>> > >>>> Dan > >>>> > >>>> =20 > >>>>=20 > ------------------------------------------------------------------- > >>>> ----- > >>>> > >>>> Subject: > >>>> Language Ontology > >>>> From: > >>>> "Salokhe, Gauri (KCEW)" > >>>> Date: > >>>> Mon, 23 Apr 2007 17:28:39 +0200 > >>>> To: > >>>> DC-GENERAL@JISCMAIL.AC.UK > >>>> > >>>> To: > >>>> DC-GENERAL@JISCMAIL.AC.UK > >>>> > >>>> > >>>> Dear All, > >>>> > >>>> We are working on creating Ontology for languages.=20 > The need came up as we > >>>> tried to convert our XML metadata files into OWL. In=20 > our metadata (XML) > >>>> records, we have three types of occurrences of=20 > language information.=20 > >>>> > >>>> En > >>>> eng > >>>> English > >>>> > >>>> > >>>> We have two options for modelling the language ontology: > >>>> > >>>> 1) Create a class for each language, assign URI to=20 > it and add all the other > >>>> lexical variations, ISO codes (create datatype=20 > property) as follows: > >>>> > >>>> OWL:Thing > >>>> |_ Class:Language > >>>> |_ Instance:URI1 > >>>> |_ rdfs:label xml:lang=3D"en" English > >>>> |_ rdfs:label xml:lang=3D"es" Ingl=E9s > >>>> |_ rdfs:label xml:lang=3D"it" Inglese > >>>> |_ rdfs:label xml:lang=3D"fr" Anglais > >>>> |_ etc. > >>>> |_ property:hasISO639-1Code en (string) > >>>> |_ property:hasISO639-2Code eng (string) > >>>> |_ etc. > >>>> |_ Instance:URI2 > >>>> |_ Instance:URI3 > >>>> |_ Instance:URI4 > >>>> > >>>> > >>>> 2) Create Classes called Language and Language code=20 > and make links between > >>>> instances of Language and Language Codes as follows: > >>>> > >>>> > >>>> OWL:Thing > >>>> |_ Class:Language > >>>> |_ Instance:URI1 > >>>> |_ property:hasCode en (link to the=20 > en instance of Class > >>>> ISO639-1 below) > >>>> |_ property:hasCode eng (link to the=20 > eng instance of Class > >>>> ISO639-1 below) > >>>> > >>>> |_ Class:LanguageCode > >>>> |_ SubClass ISO639-1 > >>>> |_ Instance:en > >>>> |_ Instance:fr > >>>> |_ etc. > >>>> |_ SubClass ISO639-2 > >>>> |_ Instance:eng > >>>> |_ Instance:fra > >>>> |_ etc. > >>>> |_ etc. > >>>> > >>>> Does anyone have similar experience with modelling=20 > in OWL? Any suggestions on > >>>> which model is better and (extensible)? Does an=20 > ontology already exist that > >>>> we can reuse? > >>>> > >>>> Than you,=20 > >>>> Gauri > >>>> =20 > >>> > >>> This email was sent to you by Reuters, the global news and > >>> information company. > >>> To find out more about Reuters visit www.about.reuters.com > >>> > >>> Any views expressed in this message are those of the=20 > individual > >>> sender, except where the sender specifically states them to be > >>> the views of Reuters Limited. > >>> > >>> Reuters Limited is part of the Reuters Group of companies, of > >>> which Reuters Group PLC is the ultimate parent=20 > company. Reuters > >>> Group PLC - Registered office address: The Reuters Building, > >>> South Colonnade, Canary Wharf, London E14 5EP, United Kingdom > >>> Registered No: 3296375 > >>> Registered in England and Wales > >>> >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 06:01: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 1HgHq1-0006o3-S4; Tue, 24 Apr 2007 06:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHq0-0006ny-Pj for ltru@ietf.org; Tue, 24 Apr 2007 06:01:32 -0400 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgHpz-0001Se-Hg for ltru@ietf.org; Tue, 24 Apr 2007 06:01:32 -0400 Received: (qmail 22315 messnum 2892579 invoked from network[194.125.174.32/ts09-032.dublin.indigo.ie]); 24 Apr 2007 10:01:29 -0000 Received: from ts09-032.dublin.indigo.ie (HELO ?194.125.174.32?) (194.125.174.32) by mail07.svc.cra.dublin.eircom.net (qp 22315) with SMTP; 24 Apr 2007 10:01:29 -0000 In-Reply-To: <007c01c785d4$ccb31d80$6601a8c0@oemcomputer> References: <11633FB7-31A8-45A4-8F46-749C489CF519@egt.ie><001401c7856b$50044340$6601a8c0@oemcomputer> <0724CBA5-7F5D-40F8-99A6-C733E6C6AD38@egt.ie> <007c01c785d4$ccb31d80$6601a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <770F2193-F505-48BF-8873-9A29A07B2E9F@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Public RFC 3934 warning Date: Tue, 24 Apr 2007 11:02:59 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I again offer my apology (without further comment) for your acceptance. mg On 23 Apr 2007, at 18:25, scr=EDobh Randy Presuhn: > Hi Marion - > > You were warned privately. This message constitutes a public warning. > Such unprofessional commentary as is in your "apology" has > no place in an IETF discussion. As you well know, participation > in the IETF is by individuals, not by national representatives. > > If bad behaviour continues, your posting privileges to the > ltru WG mailing list may be suspended. See RFC 3934 > for the procedural details. > > Randy > ltru co-chair - - 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 Apr 24 06:15: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 1HgI32-0001Pp-Jg; Tue, 24 Apr 2007 06:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgI32-0001NK-5V for ltru@ietf.org; Tue, 24 Apr 2007 06:15:00 -0400 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgI30-0005Ks-Sf for ltru@ietf.org; Tue, 24 Apr 2007 06:15:00 -0400 Received: (qmail 49609 messnum 5147627 invoked from network[194.125.174.32/ts09-032.dublin.indigo.ie]); 24 Apr 2007 10:08:17 -0000 Received: from ts09-032.dublin.indigo.ie (HELO ?194.125.174.32?) (194.125.174.32) by mail17.svc.cra.dublin.eircom.net (qp 49609) with SMTP; 24 Apr 2007 10:08:17 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <00c201c785f9$fa17e790$5072f853@streamserve.com> References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> <00c201c785f9$fa17e790$5072f853@streamserve.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <05BF9AA4-04F7-40AD-8D5D-2DA000F511D6@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] updated editor's copy to deal with 'mis', etc. Date: Tue, 24 Apr 2007 11:09:49 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Whether "special" or "top level" is used, such words are ambiguous in =20= English the extent that the relevant term(s) needs to be included in =20 the list of definitions, I believe. mg On 23 Apr 2007, at 22:51, scr=EDobh Kent Karlsson: > Ok, except for one thing: > > Mark Davis wrote: > > >>> Remove "special" (which is incorrect), or replace "special" by >>> "top level" or similar. I don't mind an extra explanation (as long >>> as it does not try to treat 'mis' differently from the other >>> collection codes). >>> >> >> I don't see a need to change from "special", which tells the user >> that there is something particular about it, and there is. >> > > In plain English, yes. But "special" is used in a technical meaning > in 639: only 'mul', 'und', and now 'zxx' are "special codes". 'mis' > is not special in that sense, and "special collection code" seem to > mix the concepts. Ok, one could say that "'mis' is a special case > among the collection codes" without any greater fear that that is > misread. Though what is special about it is that it is top level... > > /kent k > - - 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 Apr 24 07:04: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 1HgIpJ-0003r0-3I; Tue, 24 Apr 2007 07:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIpI-0003qs-G9 for ltru@ietf.org; Tue, 24 Apr 2007 07:04:52 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgIpH-00006w-5J for ltru@ietf.org; Tue, 24 Apr 2007 07:04:52 -0400 Received: from [10.76.37.234] (wifi-postauth234.london.corp.yahoo.com [10.76.37.234]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3OB4aQs011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 04:04: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=ArF1UQ0xGYdEjDEumLRQanrFgigKN0bj9s8M9NX/oHpLIJvlxwaqRmGMz8/RPh12 Message-ID: <462DE444.1030205@yahoo-inc.com> Date: Tue, 24 Apr 2007 12:04:36 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Archival of registration forms References: <002401c78635$041f5760$6401a8c0@DGBP7M81> In-Reply-To: <002401c78635$041f5760$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf-languages@iana.org, 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 that the final record that is sent to IANA should be cc'd to > ietf-languages (not LTRU). I would not tend to agree that it should be > sent *before* final submission to IANA; that is what the review period > is for. Actually, I interpret Section 3.5 to mean that submitting a changed registration request opens a review period. The fact that the original requester did not submit the specific email isn't that important. What's important is that *any* registration request has a review period on the list. The subtag reviewer then makes an explicit decision regarding the request. If you're changing the form, you are creating a change that might provoke potential objection. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 09:22: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 1HgKyh-0004Sw-SP; Tue, 24 Apr 2007 09:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKyf-0004SX-Q6 for ltru@ietf.org; Tue, 24 Apr 2007 09:22:42 -0400 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKyd-0005Bq-Ce for ltru@ietf.org; Tue, 24 Apr 2007 09:22:41 -0400 Received: (qmail 2231 invoked from network); 24 Apr 2007 08:22:38 -0500 Received: from pool-71-252-104-97.washdc.east.verizon.net (HELO IBM92AA25595C4) (71.252.104.97) by 72.32.229.137 with SMTP; 24 Apr 2007 08:22:38 -0500 From: "Don Osborn" To: "'Misha Wolf'" , "'LTRU Working Group'" References: In-Reply-To: Subject: RE: Attracting wider participation [was: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special Cases)] Date: Tue, 24 Apr 2007 09:22:33 -0400 Message-ID: <00b601c78673$9e849ac0$db8dd040$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceFjbsl8OqtoRxySXWO2VwB501A+QABiXhAAANiFiAAMjpSIA== Content-Language: en-us X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 understand David's point to be that there might be better outreach to increase the level of involvement of experts with a range of language expertise (and authority). To take the case of sub-Saharan African languages, I find that I am practically the only person actively trying to focus on what the implications of a lot of the discussions are for them, and what their needs might imply for the form of language tagging. Not the only person to think about it, and basically I know enough to know how little I really know, but one of the very few to consistently raise African language issues. Africa deserves better. The simple answer to invite colleagues is sometimes too simple: some African language/linguistics experts (wherever they are from or based) are clueless about language tags. One (an American professor) recently asked on behalf of colleagues who are setting up a workshop, "We don't know what is ISO-639?" Outreach is more than just getting people on the wagon to take them to the polling station (or whatever metaphor one may prefer). How can potentially interested experts be educated about the language tagging issues from the bottom up, in a succinct way, to facilitate their participation and input? They know the languages and the issues, and could add important dimensions to the discussions and decisions that we are missing. Problem is that outreach requires some effort and resources, and here, like the case with Unicode, there is no such. So, the system remains largely North American and West European. The problem with regard to Africa is a larger one. ISO published last year a short document on increasing African government capacities and involvement in ISO standards processes.* This is all ISO standards, not just language or ICT related. But as a general rule, African involvement in language and ICT standards is very low, especially taking into account LTRU, IETF-languages etc. I'm not sure what the answer is (again, the problem of lack of resources and time usually cut such discussions short), but it is an issue that shouldn't be lightly dismissed. And it does seem to be most appropriately addressed to the kind of people who are already on ltru@ietf.org . Don Osborn * International Organization for Standardization. 2006. "ISO and Africa." June 2006. http://www.iso.org/iso/en/comms-markets/developingcountries/pdf/iso_and_afri ca.pdf > -----Original Message----- > From: Misha Wolf [mailto:Misha.Wolf@reuters.com] > Sent: Monday, April 23, 2007 8:29 AM > To: LTRU Working Group > Subject: OT: Attracting wider participation [was: RE: Off-list RFC 3934 > warning ([Ltru] Re: Language Tag Special Cases)] > > Hi David, > > I'm divided as to the wisdom of replying. If this has > reached you, then the urge to do so overcame the urge > not to do so. > > It seems self-evident that if you want people who are > not currently on this list to join it in order to > participate, you should be addressing yourself to them, > rather than to the existing members of the list. You > could suggest the creation of a list not-ltru@ietf.org, > whose membership would consist of those persons who are > *not* members of the existing list. You could then use > the new forum to encourage them to join the ltru list. > > Yours transatlantically, > Misha > London, UK > > > -----Original Message----- > From: David Dalby [mailto:daviddalby@linguasphere.info] > Sent: 23 April 2007 11:52 > To: 'Marion Gunn'; 'LTRU Working Group' > Subject: RE: Off-list RFC 3934 warning ([Ltru] Re: Language Tag Special > Cases) > > Dear All, > I have refrained recently from responding to matters discussed on this > and > its parallel forum, because I have felt so out-of-place among largely > trans-Atlantic experts in the rules of program(m)ing. > Marion's humorous response is entirely appropriate and "on-topic", and > I > look forward to the day when the coding of the world's languages may be > discussed and resolved by many more linguists and by many more speakers > of > different languages from around the world. > Please forgive my intruding onto the bridge. I shall return to the > boiler-room. > Best wishes to all, > David > > This email was sent to you by Reuters, the global news and information > company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender, > except where the sender specifically states them to be the views of > Reuters Limited. > > Reuters Limited is part of the Reuters Group of companies, of which > Reuters Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters Building, > South Colonnade, Canary Wharf, London E14 5EP, United Kingdom > Registered No: 3296375 > Registered in England and Wales > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 11:03: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 1HgMYK-0007hw-6m; Tue, 24 Apr 2007 11:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMYJ-0007hq-MA for ltru@ietf.org; Tue, 24 Apr 2007 11:03:35 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMYI-00089v-9r for ltru@ietf.org; Tue, 24 Apr 2007 11:03:35 -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 <20070424150333.XVFA16517.mta11.adelphia.net@DGBP7M81>; Tue, 24 Apr 2007 11:03:33 -0400 Message-ID: <010501c78681$bab05550$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: Date: Tue, 24 Apr 2007 08:03:33 -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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Language Subtag Registration Form, originally submitted by the proposer for additions and changes NOT triggered by change to the core standards, is shown in Figure 5 of RFC 4646 (Section 3.5, page 30 in the plain-text version). This form has NOT been sent to IANA thus far. What we have been sending to IANA is the Language Subtag Modification Form shown in Figure 4 (Section 3.3, page 25 in the plain-text version). My understanding was that the Registration Form was intended for the proposer to present the new subtag and explain its usage and context and history and references to the ietf-languages list, to help the Reviewer and other list members evaluate the subtag and raise questions. I further understood that the *record* to be added or changed in the Registry was what was to be sent to IANA: "When the two-week period has passed, the Language Subtag Reviewer either forwards the record to be inserted or modified to iana@iana.org according to the procedure described in Section 3.3, or rejects the request because of significant objections raised on the list or due to problems with constraints in this document (which MUST be explicitly cited)." (Section 3.5) "When either a change or addition to the registry is needed, the Language Subtag Reviewer MUST prepare the complete record, including all fields, and forward it to IANA for insertion into the registry. Each record being modified or inserted MUST be forwarded in a separate message." (Section 3.3) It was thought that sending additional information to IANA that was not intended for insertion into the Registry, such as the requester's name and e-mail address and extensive bibliographic references, would result in confusion on the part of IANA and possible errors in the Registry. I recognize that this conflicts with the wording in in Section 3.5 which spurred this thread: "All approved registration forms are available online in the directory http://www.iana.org/numbers.html under 'languages'." It seems to me that if IANA needs to archive (which I assume also means "make publicly available") the original registration forms, then there is substantial duplication between the two forms in Figure 4 and Figure 5 that needs to be resolved. It needs to be clear to IANA which information is to be added to the Registry and which is not. I think this is an ideal time to review the two forms and possibly consolidate them for RFC 4646bis. If desired, I can go through the ietf-languages archives and find the original Registration Forms for changes made since the launch date (October 2005). It is important to realize that we have *not* been making changes to the original form, much less requiring the original submitter to make them, to reflect changes to the request that have resulted from list discussion. We will need to decide how to resolve any differences, if at all, and we should probably do all of this on the list to ensure transparency and openness and avoid disputes, as Addison pointed out. I want to emphasize that any deviations from RFC 4646 for which I am responsible, as Michael's unofficial golf caddy, have been in the interest of getting the requester's subtags registered and maintaining the intended form and function of Registry entries as I understand it. Michael and I did edit down the Comments field in ReÅŸat's recenty approved subtag, to reduce the number of words while keeping all of the alternative names he listed. I imagine that with IANA archiving of the registration forms, for past and future registrations, the perceived need to put all of this in the Registry may be reduced. -- 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 Apr 24 11:07:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMbu-0008V4-Tj; Tue, 24 Apr 2007 11:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMbu-0008Uz-9O for ltru@ietf.org; Tue, 24 Apr 2007 11:07:18 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMbs-0000Mh-WB for ltru@ietf.org; Tue, 24 Apr 2007 11:07:18 -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 <20070424150712.YLVC19599.mta10.adelphia.net@DGBP7M81>; Tue, 24 Apr 2007 15:07:12 +0000 Message-ID: <010701c78682$3cf8b070$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <462DE444.1030205@yahoo-inc.com> Subject: Re: [Ltru] Re: Archival of registration forms Date: Tue, 24 Apr 2007 08:07:12 -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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> I agree that the final record that is sent to IANA should be cc'd to >> ietf-languages (not LTRU). I would not tend to agree that it should >> be sent *before* final submission to IANA; that is what the review >> period is for. > > Actually, I interpret Section 3.5 to mean that submitting a changed > registration request opens a review period. The fact that the original > requester did not submit the specific email isn't that important. > What's important is that *any* registration request has a review > period on the list. The subtag reviewer then makes an explicit > decision regarding the request. If you're changing the form, you are > creating a change that might provoke potential objection. If the registration request has been changed, then I agree with you (while noting that we have not always done this). If there has been no change, then I feel there should be no need to confirm the request after the review period elapses, but before sending material to IANA. We should definitely take this up as part of the RFC 4646bis effort. -- 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 Apr 24 12:28: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 1HgNsX-0006HJ-KG; Tue, 24 Apr 2007 12:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNsV-0006DY-VX for ltru@ietf.org; Tue, 24 Apr 2007 12:28:31 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNsU-0004kL-71 for ltru@ietf.org; Tue, 24 Apr 2007 12:28:31 -0400 Received: from [10.76.37.138] (wifi-postauth138.london.corp.yahoo.com [10.76.37.138]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3OGSHu0030572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 09:28: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=oIFG32RaRLX3zygVveuygTx6FtbXGenPO7bHPY0F76OF7PQToB54twWuCQLII1Uv Message-ID: <462E3021.1000301@yahoo-inc.com> Date: Tue, 24 Apr 2007 17:28:17 +0100 From: Addison Phillips User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Archival of registration forms References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <462DE444.1030205@yahoo-inc.com> <010701c78682$3cf8b070$6401a8c0@DGBP7M81> In-Reply-To: <010701c78682$3cf8b070$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, 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 the registration request has been changed, then I agree with you > (while noting that we have not always done this). If there has been no > change, then I feel there should be no need to confirm the request after > the review period elapses, but before sending material to IANA. > +1 I agree that this is only necessary when a change takes place. Otherwise, there is no need to repost the item. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 13:07: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 1HgOTZ-0001YN-Rx; Tue, 24 Apr 2007 13:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOTY-0001Xi-DR for ltru@ietf.org; Tue, 24 Apr 2007 13:06:48 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOTX-00068G-4k for ltru@ietf.org; Tue, 24 Apr 2007 13:06:48 -0400 Received: from c83-248-111-179.bredband.comhem.se ([83.248.111.179]:3698 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HgOTV-0002rV-6D; Tue, 24 Apr 2007 19:06:46 +0200 From: "Kent Karlsson" To: "'Mark Davis'" References: <462B7DAF.2010405@yahoo-inc.com> <30b660a20704231016k36c6e8dcsb49cf890cf67c615@mail.gmail.com> <009a01c785d8$a251d2d0$5072f853@streamserve.com> <30b660a20704231444p60e726f1qe0e710af799b5c57@mail.gmail.com> <00c201c785f9$fa17e790$5072f853@streamserve.com> <20070424012919.GJ9522@mercury.ccil.org> <30b660a20704231835j5e87db13v2486e03b8134b861@mail.gmail.com> Subject: RE: [Ltru] updated editor's copy to deal with 'mis', etc. Date: Tue, 24 Apr 2007 19:09:12 +0200 Message-ID: <002101c78693$47dbf360$b36ff853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20704231835j5e87db13v2486e03b8134b861@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceGEM/2fjGNHJGnS5iZM9oIJ7ilxQAXRtEg X-Scan-Result: No virus found in message 1HgOTV-0002rV-6D. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HgOTV-0002rV-6D 12f09b8338c0f35e4f069d437237b62e X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis > [...] How about: > > 4. The 'mis' (Miscellaneous) primary language subtag > is a particular collection code used to I have no objection to that. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 24 13:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgP9w-0006BR-TX; Tue, 24 Apr 2007 13:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgP9u-00068R-57 for ltru@ietf.org; Tue, 24 Apr 2007 13:50:34 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgP6r-0008Sg-LQ for ltru@ietf.org; Tue, 24 Apr 2007 13:47:27 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=R0quUr3xShJR5FQymDY1bzMqI6BgVp1RcoDWOJ/XMO/sJuxPsiB0344Aj3E+2Hd8; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.243] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HgP6r-0000xa-3b for ltru@ietf.org; Tue, 24 Apr 2007 13:47:25 -0400 Message-ID: <006101c78698$ee78e5c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 24 Apr 2007 10:49:38 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005E_01C7865E.416A93E0" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd722b5590e78dd62462056f3bcb49e3ea4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.243 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ltru] search engine for Iltru mailinglist archives X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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. ------=_NextPart_000_005E_01C7865E.416A93E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi - Readers of this mailing list may find this search tool helpful for finding things in the ltru WG archive. Randy > From: "Lars Eggert" > To: "IETF discussion list" > Cc: "Jari Arkko" > Sent: Tuesday, April 24, 2007 5:28 AM > Subject: message for ietf-announce: search engine for IETF and IRTF mailinglist archives ... http://www.google.com/coop/cse?cx=006728497408158459967%3Aybxjdw-bjjw ... ------=_NextPart_000_005E_01C7865E.416A93E0 Content-Type: text/plain; name="ATT00088.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00088.txt" Hi, we've put together a search engine for IETF and IRTF mailing list archives using the Google co-op tool. At this time, it indexes all currently-active WG and RG mailing list archives(*) as well as selected related and historic lists. You can access the search engine at: http://www.google.com/coop/cse?cx=006728497408158459967%3Aybxjdw- bjjw Please send comments and suggestions to lars.eggert@nokia.com Thanks, Lars (*) modulo archives that aren't HTML-ified or inaccessible due to robots.txt, etc. ------=_NextPart_000_005E_01C7865E.416A93E0 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_000_005E_01C7865E.416A93E0-- From ltru-bounces@ietf.org Wed Apr 25 01: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 1HgZpO-0006On-1c; Wed, 25 Apr 2007 01:14:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgZpN-0006Og-48 for ltru@ietf.org; Wed, 25 Apr 2007 01:14:05 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgZpL-0006AD-RI for ltru@ietf.org; Wed, 25 Apr 2007 01:14:05 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HgZpK-0002gG-OZ; Wed, 25 Apr 2007 01:14:02 -0400 Date: Wed, 25 Apr 2007 01:14:02 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Archival of registration forms Message-ID: <20070425051402.GX9522@mercury.ccil.org> References: <010501c78681$bab05550$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010501c78681$bab05550$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf-languages@iana.org, 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: > It was thought that sending additional information to IANA that was not > intended for insertion into the Registry, such as the requester's name > and e-mail address and extensive bibliographic references, would result > in confusion on the part of IANA and possible errors in the Registry. They seemed to manage it all right in the 1766/3066 era, keeping both short explanations at http://www.iana.org/assignments/language-tags and full registration forms with name, email, and biblio at the directory http://www.iana.org/assignments/lang-tags/ . It's true that the former is technically redundant with the latter, but both are useful. The LSR correspons to the latter, but nothing corresponds to the former, and we may need the contents of it in future. > It seems to me that if IANA needs to archive (which I assume also means > "make publicly available") the original registration forms, then there > is substantial duplication between the two forms in Figure 4 and Figure > 5 that needs to be resolved. It needs to be clear to IANA which > information is to be added to the Registry and which is not. I think > this is an ideal time to review the two forms and possibly consolidate > them for RFC 4646bis. +1 -- John Cowan cowan@ccil.org http://ccil.org/~cowan Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 25 01:55: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 1HgaTv-0000ml-5M; Wed, 25 Apr 2007 01:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgaTu-0000mc-2e for ltru@ietf.org; Wed, 25 Apr 2007 01:55:58 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgaTs-000446-Nb for ltru@ietf.org; Wed, 25 Apr 2007 01:55:58 -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 <20070425055556.EEJS13783.mta13.adelphia.net@DGBP7M81>; Wed, 25 Apr 2007 01:55:56 -0400 Message-ID: <004201c786fe$64569700$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <010501c78681$bab05550$6401a8c0@DGBP7M81> <20070425051402.GX9522@mercury.ccil.org> Subject: Re: [Ltru] Re: Archival of registration forms Date: Tue, 24 Apr 2007 22:55:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: >> It was thought that sending additional information to IANA that was >> not intended for insertion into the Registry, such as the requester's >> name and e-mail address and extensive bibliographic references, would >> result in confusion on the part of IANA and possible errors in the >> Registry. > > They seemed to manage it all right in the 1766/3066 era, keeping both > short explanations at http://www.iana.org/assignments/language-tags > and full registration forms with name, email, and biblio at the > directory http://www.iana.org/assignments/lang-tags/ . I was always singularly unimpressed with the level of maintenance of the 1766/3066 files. The summary file and the directory of reg forms didn't always keep pace with each other; even to this day you will not find the registration forms for "el-Latn" and "sgn-NI" and "sl-nedis" in the directory although they are listed in the summary file. The names didn't always match either: for "i-default" the registration form has "Default Language" but on the summary file it is listed as "Default Language Context." (How much of a battle would a minor discrepancy like that cause today, when a new registration is being delayed over a single word in a comment!) Actually there were three reference sources at the time, if you count the page on Michael's Web site, which didn't match either of the IANA sources exactly. It's partly because of the lackadaisical maintenance of the 3066 registration forms that I was so strongly in favor of a single, all-inclusive registry back when it was first proposed in 2004. -- 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 Apr 25 05:08: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 1HgdUB-00009i-JN; Wed, 25 Apr 2007 05:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdU9-00009X-QP for ltru@ietf.org; Wed, 25 Apr 2007 05:08:25 -0400 Received: from customermail2.easily.co.uk ([212.53.64.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdU7-0008MJ-8X for ltru@ietf.org; Wed, 25 Apr 2007 05:08:25 -0400 Received: from [86.146.3.154] (account ya7to240sqpm HELO Laptop) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with ESMTP id 95785353; Wed, 25 Apr 2007 10:08:19 +0100 From: "David Dalby" To: "'Debbie Garside'" , "'Elisa F. Kendall'" , "'Misha Wolf'" Subject: RE: [Ltru] RE: [Fwd: Language Ontology] Date: Wed, 25 Apr 2007 10:08:10 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceFzLku2q6BFIlcQ6GL9+IdH6v5eQALZrCAAERm0hA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 35b3af3416a6d11f1eee5b96bdee48c4 Cc: Gauri.Salokhe@FAO.ORG, 'Semantic web list' , 'WWW International' , '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="===============0441852442==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0441852442== Content-Type: multipart/alternative; boundary="----=_NextPart_000_014C_01C78721.A119C680" This is a multi-part message in MIME format. ------=_NextPart_000_014C_01C78721.A119C680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is unfortunate that a business-person well-versed in ICT, in = marketing techniques and in the workings of ISO, should make such an ungracious = and ill-informed remark about the important standard ISO 3166-1. Such a = comment is particularly unhelpful in a field requiring international = co-operation and linguistic precision, since it is made by a representative of the British Standards Institution and of the team in charge of the related = ISO 639 standard. =20 The argument that incomplete data are =93not good data=94 is of course = nonsense. ISO 3166 has made an important step forward in making available for the first time standardised data on the administrative use of specific = languages at the level of national states. To propose the deletion of that data, = on the basis of a single (ill-chosen) example, leads one to ponder the = motives for such a proposal. =20 =20 I hope that this working group may be informed at once of all the other reasons which are prompting the UK to make such an extraordinary = request, in the form of D.Garside=92s proposed ISO NWIP (New Work Item Proposal). =20 At present, the only accusation (based on inadequate understanding of a complex situation) is that ISO 3166-1 =93shows only two Administrative Languages for India where there are at least twenty-two=94. In fact, = Hindi and English are the languages used for the federal administration of = India (and are thus relevant to the listing of administrative languages in ISO 3166-1) whereas the many other official languages are used either at the level of individual states or union territories, or in communications between those individual states (or territories) and the central = government (and will thus be relevant to the further listing of administrative languages in ISO 3166-2, covering sub-divisions of countries). I hope = that any member of the working group will correct me, if my summary of the = Indian situation is itself too simplified. =20 David Dalby =20 _____________________________________________________ =20 Dr David Dalby Director =20 L=92Observatoire linguistique / The Linguasphere Observatory Hebron Whitland Wales SA34 0XT _____ =20 From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]=20 Sent: 23 April 2007 23:55 To: 'Elisa F. Kendall'; 'Misha Wolf' Cc: 'WWW International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; = 'LTRU Working Group' Subject: [Ltru] RE: [Fwd: Language Ontology] =20 Please be very careful with the use of the "Administrative Language" information from ISO 3166-1. It is incomplete and therefore not good = data. =20 For example, it shows only two "Administrative Languages" for India = where there are at least twenty-two. I am hoping that this information will = be taken out of the standard in the near future. I am currently writing an = ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion of this data. =20 Best regards =20 Debbie Garside Editor ISO DIS 639-6 www.geolang.com =20 =20 =20 _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 18:25 To: Misha Wolf Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group Subject: Re: [Fwd: Language Ontology] Hi Misha, We are very aware of it, and have been following the work, but I failed = to mention it in the email. I should say that our ontology was developed = for offline use in an internal system, as an initial requirement. Having = said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology. Our approach is compatible with the RFCs = but adds capabilities that support co-reference resolution, for example, in target application. Best, Elisa Misha Wolf wrote: This sounds very worrying as you don't seem to be aware of BCP 47. =20 Misha =20 _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 17:32 To: Gauri.Salokhe@FAO.ORG Cc: 'WWW International'; Semantic web list Subject: Re: [Fwd: Language Ontology] Hi Gauri, We've done this for some of our government customers, using essentially = the second approach you cite. We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which = includes the administrative languages used by countries and non-sovereign = territories represented in that standard. If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of = a hybrid of the two you present, based on customer needs. It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes. We elected to = create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the = set of English, French, and in the case of 639-1 Indigenous names. We've = also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, = with individual and macrolanguages to support 639-3. A subsequent release = will include all of the languages described in ISO 639-3, as well as = additions to support at least some of the subtagging that Dan mentions, fyi. Our = intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to = publish several ontologies in recent RFPs. I'll be happy to send our = preliminary version when it's "baked and tested", and follow up with an announcement = of the new portal (where a revision using OMG URIs will be posted) once = that's available. It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many = of us in the Semantic Web community. Best regards, Elisa Dan Brickley wrote:=20 Forwarding from the Dublin Core list, in case folk here can advise.=20 Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646,=20 http://www.rfc-editor.org/rfc/rfc4646.txt=20 see also http://www.w3.org/International/articles/language-tags/Overview.en.php=20 ...and in particular the subtag mechanism, script, region, variant etc.=20 It would be great to have those expressed explicitly.=20 cheers,=20 Dan=20 _____ =20 =20 Subject:=20 Language Ontology From:=20 "Salokhe, Gauri (KCEW)" Date:=20 Mon, 23 Apr 2007 17:28:39 +0200 To:=20 DC-GENERAL@JISCMAIL.AC.UK =20 To:=20 DC-GENERAL@JISCMAIL.AC.UK Dear All,=20 =20 We are working on creating Ontology for languages. The need came up as = we tried to convert our XML metadata files into OWL. In our metadata (XML) records, we have three types of occurrences of language information.=20 =20 En eng English =20 =20 We have two options for modelling the language ontology: =20 1) Create a class for each language, assign URI to it and add all the = other lexical variations, ISO codes (create datatype property) as follows: =20 OWL:Thing |_ Class:Language |_ Instance:URI1 |_ rdfs:label xml:lang=3D"en" English |_ rdfs:label xml:lang=3D"es" Ingl=E9s |_ rdfs:label xml:lang=3D"it" Inglese |_ rdfs:label xml:lang=3D"fr" Anglais |_ etc. |_ property:hasISO639-1Code en (string) |_ property:hasISO639-2Code eng (string) |_ etc. |_ Instance:URI2 |_ Instance:URI3 |_ Instance:URI4 =20 =20 2) Create Classes called Language and Language code and make links = between instances of Language and Language Codes as follows: =20 =20 OWL:Thing |_ Class:Language |_ Instance:URI1 |_ property:hasCode en (link to the en instance of Class ISO639-1 below) |_ property:hasCode eng (link to the eng instance of = Class ISO639-1 below) =20 |_ Class:LanguageCode |_ SubClass ISO639-1 |_ Instance:en |_ Instance:fr |_ etc. |_ SubClass ISO639-2 |_ Instance:eng |_ Instance:fra |_ etc. |_ etc. =20 Does anyone have similar experience with modelling in OWL? Any = suggestions on which model is better and (extensible)? Does an ontology already exist = that we can reuse? =20 Than you,=20 Gauri =20 This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of = Reuters Limited.=20 Reuters Limited is part of the Reuters Group of companies, of which = Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, = London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales=20 ------=_NextPart_000_014C_01C78721.A119C680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is unfortunate that a = business-person well-versed in ICT, in marketing techniques and in the workings of ISO, = should make such an ungracious and ill-informed remark about the important standard = ISO 3166-1.=A0 Such a comment is particularly unhelpful in a field requiring international co-operation and linguistic precision, since it is made by = a representative of the British Standards Institution and of the team in charge of the = related ISO 639 standard.

 

The argument that incomplete data = are “not good data” is of course nonsense. =A0ISO 3166 has made an = important step forward in making available for the first time standardised data on the administrative use of specific languages at the level of national = states.=A0 To propose the deletion of that data, on the basis of a single (ill-chosen) = example, leads one to ponder the motives for such a proposal. = =A0

 

I hope that this working group may = be informed at once of all the other reasons which are prompting the = UK = to make such an extraordinary request, in the form of D.Garside’s proposed ISO = NWIP (New Work Item Proposal).

 

At present, the only accusation = (based on inadequate understanding of a complex situation) is that ISO 3166-1 = “shows only two Administrative Languages for India where there are at = least twenty-two”.=A0 In fact, Hindi and English are the languages used = for the federal administration of India (and are thus relevant to the listing of administrative languages in ISO 3166-1) whereas the many other official = languages are used either at the level of individual states or union territories, = or in communications between those individual states (or territories) and the = central government (and will thus be relevant to the further listing of = administrative languages in ISO 3166-2, covering sub-divisions of countries). =A0=A0I = hope that any member of the working group will correct me, if my summary of the = Indian situation is itself too simplified.

 

David = Dalby

 

 __________________________= ___________________________

 

Dr David = Dalby

Director

 

L’Observatoire linguistique = / The Linguasphere Observatory

Hebron

Whitland

Wales

SA34 = 0XT

From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] =
Sent: 23 April 2007 = 23:55
To: 'Elisa F. Kendall'; = 'Misha Wolf'
Cc: 'WWW International'; = 'Semantic web list'; Gauri.Salokhe@FAO.ORG; 'LTRU Working Group'
Subject: [Ltru] RE: [Fwd: = Language Ontology]

 

Please be very careful with the use = of the "Administrative Language" information from ISO 3166-1.  = It is incomplete and therefore not good data.

 

For example, it shows only two "Administrative Languages" for India where there are at = least twenty-two.  I am hoping that this information will be taken out of = the standard in the near future.  I am currently writing an = ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion = of this data.

 

Best = regards

 

Debbie = Garside

Editor ISO DIS = 639-6

 

 

From: www-international-request@w3.org = [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall
Sent: 23 April 2007 = 18:25
To: Misha Wolf
Cc: = Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group
Subject: Re: [Fwd: = Language Ontology]

Hi Misha,

We are very aware of it, and have been following the work, but I failed = to mention it in the email.  I should say that our ontology was = developed for offline use in an internal system, as an initial requirement.  = Having said that, if you look at the RFCs, they only describe tags, not an RDF = vocabulary or OWL ontology.  Our approach is compatible with the RFCs but adds capabilities that support co-reference resolution, for example, in = target application.

Best,

Elisa

Misha Wolf wrote:

This sounds very worrying as you = don't seem to be aware of BCP 47.

 

Misha

=

 

From: www-international-reques= t@w3.org [mailto:www-international= -request@w3.org] On Behalf Of Elisa F. = Kendall
Sent: 23 April 2007 = 17:32
To: Gauri.Salokhe@FAO.ORG
Cc: 'WWW International'; = Semantic web list
Subject: Re: [Fwd: = Language Ontology]

Hi Gauri,

We've done this for some of our government customers, using essentially = the second approach you cite.  We're also in the process of relating = the ontology to another one we've built to represent ISO 3166, which = includes the administrative languages used by countries and non-sovereign = territories  represented in that standard.

If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of = a hybrid of the two you present, based on customer needs.  It = includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes.  We elected = to create a 'Language' class, rather than 'LanguageCode', which we reuse in = other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the = set of English, French, and in the case of 639-1 Indigenous names.  We've = also created subclasses of Alpha-3Code to support distinctions between = bibliographic and terminologic, collective, and special identifiers, with individual = and macrolanguages to support 639-3.  A subsequent release will include = all of the languages described in ISO 639-3, as well as additions to support at = least some of the subtagging that Dan mentions, fyi.  Our intent is to = publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to publish several = ontologies in recent RFPs.  I'll be happy to send our preliminary version when = it's "baked and tested", and follow up with an announcement of the = new portal (where a revision using OMG URIs will be posted) once that's available.  It may be a couple of months before we're ready to make = that announcement, but we're hoping that the service will be useful to many = of us in the Semantic Web community.

Best regards,

Elisa

Dan Brickley wrote:


Forwarding from the Dublin Core list, in case folk here can advise.

Gauri, one thing I'd suggest as useful would be to take the concepts = implicit in RFC 4646,

http://www.rfc-editor.= org/rfc/rfc4646.txt
see also http://www.w3.org/International/articles/language-tags/Overview.en= .php

...and in particular the subtag mechanism, script, region, variant etc. =

It would be great to have those expressed explicitly.

cheers,

Dan

 

Subject:

Language = Ontology

From:

"Salokhe, Gauri (KCEW)" <Gauri.Salokhe@FAO.ORG>

Date:

Mon, 23 Apr 2007 17:28:39 = +0200

To:

DC-GENERAL@JISCMAIL.AC.UK

 

To:

DC-GENERAL@JISCMAIL.AC.UK

 



Dear All, =

 
We are working on creating Ontology for =
languages. The need came up as =
we
tried to convert our XML metadata files into =
OWL. In our metadata (XML)
records, we have three types of occurrences =
of language information. 
 
<dc:language =
scheme=3D"ags:ISO639-1">En</dc:language>
<dc:language =
scheme=3D"dcterms:ISO639-2">eng</dc:language>
<dc:language>English</dc:language>=

 
 
We have two options for modelling the =
language ontology:
 
1) Create a class for each language, assign =
URI to it and add all the other
lexical variations, ISO codes (create =
datatype property) as follows:
 
OWL:Thing
<=
font
size=3D2 color=3Dblack face=3D"Courier New">|_ =
Class:Language
=A0=A0=A0=A0=A0 |_ =
Instance:URI1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
rdfs:label xml:lang=3D"en" =
English
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
rdfs:label xml:lang=3D"es" =
Ingl=E9s
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
rdfs:label xml:lang=3D"it" =
Inglese
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
rdfs:label xml:lang=3D"fr" =
Anglais
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
etc.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
property:hasISO639-1Code=A0 en =
(string)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
property:hasISO639-2Code=A0 eng =
(string)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
etc.
=A0=A0=A0=A0=A0 |_ =
Instance:URI2
=A0=A0=A0=A0=A0 |_ =
Instance:URI3
=A0=A0=A0=A0=A0 |_ =
Instance:URI4
 
 
2) Create Classes called Language and =
Language code and make links =
between
instances of Language and Language Codes as =
follows:
 
 
OWL:Thing
<=
font
size=3D2 color=3Dblack face=3D"Courier New">|_ =
Class:Language
=A0=A0=A0=A0=A0 |_ =
Instance:URI1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
property:hasCode=A0 en=A0 (link to the en instance of =
Class
ISO639-1 =
below)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
property:hasCode=A0 eng=A0 (link to the eng instance of =
Class
ISO639-1 =
below)
 
|_ =
Class:LanguageCode
=A0=A0=A0=A0=A0 |_ SubClass =
ISO639-1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
Instance:en
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
Instance:fr
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
etc.
=A0=A0=A0=A0=A0 |_ SubClass =
ISO639-2
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
Instance:eng
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
Instance:fra
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |_ =
etc.
=A0=A0=A0=A0=A0 |_ =
etc.
 
Does anyone have similar experience with =
modelling in OWL? Any suggestions =
on
which model is better and (extensible)? Does =
an ontology already exist that
we can =
reuse?
 
Than you, =

Gauri
=A0


This email was sent to you by Reuters, the global news and information = company.
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, = except where the sender specifically states them to be the views of Reuters = Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters = Group PLC is the ultimate parent company. Reuters Group PLC - Registered office = address: The Reuters Building, South Colonnade, Canary Wharf, London E14 = 5EP, United = Kingdom
Registered No: 3296375
Registered in England and Wales =

------=_NextPart_000_014C_01C78721.A119C680-- --===============0441852442== 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 --===============0441852442==-- From ltru-bounces@ietf.org Wed Apr 25 05:44: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 1Hge2d-0007H7-5R; Wed, 25 Apr 2007 05:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge2a-00076F-7I for ltru@ietf.org; Wed, 25 Apr 2007 05:44:00 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hge2X-0006JM-D2 for ltru@ietf.org; Wed, 25 Apr 2007 05:44:00 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 25 Apr 2007 10:43:54 +0100 From: "Debbie Garside" To: , "'Elisa F. Kendall'" , "'Misha Wolf'" Subject: RE: [Ltru] RE: [Fwd: Language Ontology] Date: Wed, 25 Apr 2007 10:43:48 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-index: AceFzLku2q6BFIlcQ6GL9+IdH6v5eQALZrCAAERm0hAABCBAwA== X-Spam-Score: 0.8 (/) X-Scan-Signature: 722e61efe02e5383d7f8ce1c4b5666e6 Cc: Gauri.Salokhe@FAO.ORG, 'Semantic web list' , 'WWW International' , '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="===============0671239556==" Errors-To: ltru-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0671239556== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C78726.9B4A3FF0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C78726.9B4A3FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David =20 I will not respond to personal attacks in public or private or indeed = enter into any further dialog with you where it is obvious that your motives = are to discredit rather than to participate in this forum. Do not = misinterpret this response as being through a lack of knowledge of the subject = matter. =20 That is my last word. I will respond to you no further. Please also = desist from emailing me privately. =20 Debbie _____ =20 From: David Dalby [mailto:daviddalby@linguasphere.info]=20 Sent: 25 April 2007 10:08 To: 'Debbie Garside'; 'Elisa F. Kendall'; 'Misha Wolf' Cc: 'WWW International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; = 'LTRU Working Group' Subject: RE: [Ltru] RE: [Fwd: Language Ontology] It is unfortunate that a business-person well-versed in ICT, in = marketing techniques and in the workings of ISO, should make such an ungracious = and ill-informed remark about the important standard ISO 3166-1. Such a = comment is particularly unhelpful in a field requiring international = co-operation and linguistic precision, since it is made by a representative of the British Standards Institution and of the team in charge of the related = ISO 639 standard. =20 The argument that incomplete data are =93not good data=94 is of course = nonsense. ISO 3166 has made an important step forward in making available for the first time standardised data on the administrative use of specific = languages at the level of national states. To propose the deletion of that data, = on the basis of a single (ill-chosen) example, leads one to ponder the = motives for such a proposal. =20 =20 I hope that this working group may be informed at once of all the other reasons which are prompting the UK to make such an extraordinary = request, in the form of D.Garside=92s proposed ISO NWIP (New Work Item Proposal). =20 At present, the only accusation (based on inadequate understanding of a complex situation) is that ISO 3166-1 =93shows only two Administrative Languages for India where there are at least twenty-two=94. In fact, = Hindi and English are the languages used for the federal administration of = India (and are thus relevant to the listing of administrative languages in ISO 3166-1) whereas the many other official languages are used either at the level of individual states or union territories, or in communications between those individual states (or territories) and the central = government (and will thus be relevant to the further listing of administrative languages in ISO 3166-2, covering sub-divisions of countries). I hope = that any member of the working group will correct me, if my summary of the = Indian situation is itself too simplified. =20 David Dalby =20 _____________________________________________________ =20 Dr David Dalby Director =20 L=92Observatoire linguistique / The Linguasphere Observatory Hebron Whitland Wales SA34 0XT _____ =20 From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]=20 Sent: 23 April 2007 23:55 To: 'Elisa F. Kendall'; 'Misha Wolf' Cc: 'WWW International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; = 'LTRU Working Group' Subject: [Ltru] RE: [Fwd: Language Ontology] =20 Please be very careful with the use of the "Administrative Language" information from ISO 3166-1. It is incomplete and therefore not good = data. =20 For example, it shows only two "Administrative Languages" for India = where there are at least twenty-two. I am hoping that this information will = be taken out of the standard in the near future. I am currently writing an = ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion of this data. =20 Best regards =20 Debbie Garside Editor ISO DIS 639-6 www.geolang.com =20 =20 =20 _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 18:25 To: Misha Wolf Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group Subject: Re: [Fwd: Language Ontology] Hi Misha, We are very aware of it, and have been following the work, but I failed = to mention it in the email. I should say that our ontology was developed = for offline use in an internal system, as an initial requirement. Having = said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology. Our approach is compatible with the RFCs = but adds capabilities that support co-reference resolution, for example, in target application. Best, Elisa Misha Wolf wrote: This sounds very worrying as you don't seem to be aware of BCP 47. =20 Misha =20 _____ =20 From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall Sent: 23 April 2007 17:32 To: Gauri.Salokhe@FAO.ORG Cc: 'WWW International'; Semantic web list Subject: Re: [Fwd: Language Ontology] Hi Gauri, We've done this for some of our government customers, using essentially = the second approach you cite. We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which = includes the administrative languages used by countries and non-sovereign = territories represented in that standard. If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of = a hybrid of the two you present, based on customer needs. It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes. We elected to = create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the = set of English, French, and in the case of 639-1 Indigenous names. We've = also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, = with individual and macrolanguages to support 639-3. A subsequent release = will include all of the languages described in ISO 639-3, as well as = additions to support at least some of the subtagging that Dan mentions, fyi. Our = intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to = publish several ontologies in recent RFPs. I'll be happy to send our = preliminary version when it's "baked and tested", and follow up with an announcement = of the new portal (where a revision using OMG URIs will be posted) once = that's available. It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many = of us in the Semantic Web community. Best regards, Elisa Dan Brickley wrote:=20 Forwarding from the Dublin Core list, in case folk here can advise.=20 Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646,=20 http://www.rfc-editor.org/rfc/rfc4646.txt=20 see also http://www.w3.org/International/articles/language-tags/Overview.en.php=20 ...and in particular the subtag mechanism, script, region, variant etc.=20 It would be great to have those expressed explicitly.=20 cheers,=20 Dan=20 _____ =20 =20 Subject:=20 Language Ontology From:=20 "Salokhe, Gauri (KCEW)" Date:=20 Mon, 23 Apr 2007 17:28:39 +0200 To:=20 DC-GENERAL@JISCMAIL.AC.UK =20 To:=20 DC-GENERAL@JISCMAIL.AC.UK Dear All,=20 =20 We are working on creating Ontology for languages. The need came up as = we tried to convert our XML metadata files into OWL. In our metadata (XML) records, we have three types of occurrences of language information.=20 =20 En eng English =20 =20 We have two options for modelling the language ontology: =20 1) Create a class for each language, assign URI to it and add all the = other lexical variations, ISO codes (create datatype property) as follows: =20 OWL:Thing |_ Class:Language |_ Instance:URI1 |_ rdfs:label xml:lang=3D"en" English |_ rdfs:label xml:lang=3D"es" Ingl=E9s |_ rdfs:label xml:lang=3D"it" Inglese |_ rdfs:label xml:lang=3D"fr" Anglais |_ etc. |_ property:hasISO639-1Code en (string) |_ property:hasISO639-2Code eng (string) |_ etc. |_ Instance:URI2 |_ Instance:URI3 |_ Instance:URI4 =20 =20 2) Create Classes called Language and Language code and make links = between instances of Language and Language Codes as follows: =20 =20 OWL:Thing |_ Class:Language |_ Instance:URI1 |_ property:hasCode en (link to the en instance of Class ISO639-1 below) |_ property:hasCode eng (link to the eng instance of = Class ISO639-1 below) =20 |_ Class:LanguageCode |_ SubClass ISO639-1 |_ Instance:en |_ Instance:fr |_ etc. |_ SubClass ISO639-2 |_ Instance:eng |_ Instance:fra |_ etc. |_ etc. =20 Does anyone have similar experience with modelling in OWL? Any = suggestions on which model is better and (extensible)? Does an ontology already exist = that we can reuse? =20 Than you,=20 Gauri =20 This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of = Reuters Limited.=20 Reuters Limited is part of the Reuters Group of companies, of which = Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, = London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales=20 ------=_NextPart_000_0021_01C78726.9B4A3FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
David
 
I will=20 not respond to personal attacks in public or private or indeed enter = into any=20 further dialog with you where it is obvious that your motives are to = discredit=20 rather than to participate in this forum.  Do not misinterpret this = response as being through a lack of knowledge of the subject=20 matter.
 
That=20 is my last word. I will respond to you no further. Please also desist = from=20 emailing me privately.
 
Debbie

From: David Dalby=20 [mailto:daviddalby@linguasphere.info]
Sent: 25 April 2007=20 10:08
To: 'Debbie Garside'; 'Elisa F. Kendall'; 'Misha=20 Wolf'
Cc: 'WWW International'; 'Semantic web list';=20 Gauri.Salokhe@FAO.ORG; 'LTRU Working Group'
Subject: RE: = [Ltru] RE:=20 [Fwd: Language Ontology]

It is = unfortunate=20 that a business-person well-versed in ICT, in marketing techniques and = in the=20 workings of ISO, should make such an ungracious and ill-informed = remark about=20 the important standard ISO 3166-1.  Such a comment is = particularly=20 unhelpful in a field requiring international co-operation and = linguistic=20 precision, since it is made by a representative of the British = Standards=20 Institution and of the team in charge of the related ISO 639=20 standard.

 

The = argument that=20 incomplete data are =93not good data=94 is of course nonsense. =  ISO 3166 has=20 made an important step forward in making available for the first time=20 standardised data on the administrative use of specific languages at = the level=20 of national states.  To propose the deletion of that data, on the = basis=20 of a single (ill-chosen) example, leads one to ponder the motives for = such a=20 proposal.  

 

I hope that = this=20 working group may be informed at once of all the other reasons which = are=20 prompting the UK to make = such an=20 extraordinary request, in the form of D.Garside=92s proposed ISO NWIP = (New Work=20 Item Proposal).

 

At present, = the only=20 accusation (based on inadequate understanding of a complex situation) = is that=20 ISO 3166-1 =93shows only two Administrative Languages for = India where = there are at=20 least twenty-two=94.  In fact, Hindi and English are the = languages used for=20 the federal administration of India (and are thus relevant to the = listing of=20 administrative languages in ISO 3166-1) whereas the many other = official=20 languages are used either at the level of individual states or union=20 territories, or in communications between those individual states (or=20 territories) and the central government (and will thus be relevant to = the=20 further listing of administrative languages in ISO 3166-2, covering=20 sub-divisions of countries).   I hope that any member of the = working=20 group will correct me, if my summary of the Indian situation is itself = too=20 simplified.

 

David=20 Dalby

 

 _____________________________________________________

 

Dr David=20 Dalby

Director

 

L=92Observatoire linguistique / = The=20 Linguasphere Observatory

Hebron

Whitland

Wales

SA34 = 0XT

From: = Debbie=20 Garside [mailto:debbie@ictmarketing.co.uk]
Sent: 23 April 2007 = 23:55
To: 'Elisa F. Kendall'; 'Misha=20 Wolf'
Cc: 'WWW=20 International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; 'LTRU = Working=20 Group'
Subject: = [Ltru] RE:=20 [Fwd: Language Ontology]

 

Please be = very=20 careful with the use of the "Administrative Language" information from = ISO=20 3166-1.  It is incomplete and therefore not good=20 data.

 

For = example, it shows=20 only two "Administrative Languages" for India where = there are at=20 least twenty-two.  I am hoping that this information will be = taken out of=20 the standard in the near future.  I am currently writing an = ISO NWIP=20 for a revision of ISO 3166-1 which will include a proposal for the = deletion of=20 this data.

 

Best=20 regards

 

Debbie=20 Garside

Editor ISO = DIS=20 639-6

www.geolang.com=20

 

 

From:=20 www-international-request@w3.org = [mailto:www-international-request@w3.org]=20 On Behalf Of Elisa = F.=20 Kendall
Sent: 23 = April 2007=20 18:25
To: Misha=20 Wolf
Cc:=20 Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU = Working=20 Group
Subject: = Re: [Fwd:=20 Language Ontology]

Hi Misha,

We are very aware of it, = and have=20 been following the work, but I failed to mention it in the = email.  I=20 should say that our ontology was developed for offline use in an = internal=20 system, as an initial requirement.  Having said that, if you = look at=20 the RFCs, they only describe tags, not an RDF vocabulary or OWL=20 ontology.  Our approach is compatible with the RFCs but adds=20 capabilities that support co-reference resolution, for example, in = target=20 application.

Best,

Elisa

Misha Wolf=20 wrote:

This = sounds very=20 worrying as you don't seem to be aware of BCP=20 47.

 

Misha

 

From: www-international-reques= t@w3.org=20 [mailto:www-international= -request@w3.org]=20 On Behalf Of Elisa = F.=20 Kendall
Sent: 23 = April 2007=20 17:32
To: Gauri.Salokhe@FAO.ORG
Cc: 'WWW International'; = Semantic web=20 list
Subject: Re: = [Fwd:=20 Language Ontology]

Hi Gauri,

We've done this for some = of our=20 government customers, using essentially the second approach you = cite. =20 We're also in the process of relating the ontology to another one = we've=20 built to represent ISO 3166, which includes the administrative = languages=20 used by countries and non-sovereign territories  represented in = that=20 standard.

If you can hang out for a few days, we (Sandpiper) = are just=20 finalizing a version that includes both ISO 639-1 and 639-2. The = approach is=20 more of a hybrid of the two you present, based on customer = needs.  It=20 includes a fragment of ISO 1087, and also some inverse relations = since there=20 is a one-to-one correspondence between languages and codes.  We = elected=20 to create a 'Language' class, rather than 'LanguageCode', which we = reuse in=20 other applications; classes for Alpha-2Code and Alpha-3Code are = subclasses=20 of CodeElement, from ISO 5127, with instances of these codes as = first class=20 individuals. We use literals (via datatype properties) to represent = the set=20 of English, French, and in the case of 639-1 Indigenous names.  = We've=20 also created subclasses of Alpha-3Code to support distinctions = between=20 bibliographic and terminologic, collective, and special identifiers, = with=20 individual and macrolanguages to support 639-3.  A subsequent = release=20 will include all of the languages described in ISO 639-3, as well as = additions to support at least some of the subtagging that Dan = mentions,=20 fyi.  Our intent is to publish it on a new portal that will = become part=20 of a new service offered by the Ontology PSIG in the OMG, since = we've been=20 asked to publish several ontologies in recent RFPs.  I'll be = happy to=20 send our preliminary version when it's "baked and tested", and = follow up=20 with an announcement of the new portal (where a revision using OMG = URIs will=20 be posted) once that's available.  It may be a couple of months = before=20 we're ready to make that announcement, but we're hoping that the = service=20 will be useful to many of us in the Semantic Web = community.

Best=20 regards,

Elisa

Dan Brickley wrote:=20


Forwarding from the=20 Dublin Core list, in case folk here can advise.

Gauri, one = thing I'd=20 suggest as useful would be to take the concepts implicit in RFC = 4646,=20

http://www.rfc-editor.= org/rfc/rfc4646.txt=20
see also http://www.w3.org/International/articles/language-tags/Overview.en= .php=20

...and in particular the subtag mechanism, script, region, = variant=20 etc.

It would be great to have those expressed explicitly.=20

cheers,

Dan

 

Subject:=20

Language=20 Ontology

From:=20

"Salokhe, Gauri = (KCEW)" <Gauri.Salokhe@FAO.ORG>

Date:=20

Mon, 23 Apr 2007 = 17:28:39=20 +0200

To:=20

DC-GENERAL@JISCMAIL.AC.UK

 

To:=20

DC-GENERAL@JISCMAIL.AC.UK



Dear All, =

 
We are =
working on creating Ontology for languages. The need came up as =
we
tried to convert =
our XML metadata files into OWL. In our metadata =
(XML)
records, we have =
three types of occurrences of language information. =

 
<dc:language =
scheme=3D"ags:ISO639-1">En</dc:language>
<dc:language =
scheme=3D"dcterms:ISO639-2">eng</dc:language><=
/FONT>
<dc:language>English</dc:language>
 
 
We have two =
options for modelling the language =
ontology:
 
1) Create a =
class for each language, assign URI to it and add all the =
other
lexical =
variations, ISO codes (create datatype property) as =
follows:
 
OWL:Thing
|_ =
Class:Language
      |_ =
Instance:URI1
           &=
nbsp;  |_ rdfs:label xml:lang=3D"en" =
English
           &=
nbsp;  |_ rdfs:label xml:lang=3D"es" =
Ingl=E9s
           &=
nbsp;  |_ rdfs:label xml:lang=3D"it" =
Inglese
           &=
nbsp;  |_ rdfs:label xml:lang=3D"fr" =
Anglais
           &=
nbsp;  |_ etc.
           &=
nbsp;  |_ property:hasISO639-1Code  en =
(string)
           &=
nbsp;  |_ property:hasISO639-2Code  eng =
(string)
           &=
nbsp;  |_ etc.
      |_ =
Instance:URI2
      |_ =
Instance:URI3
      |_ =
Instance:URI4
 
 
2) Create =
Classes called Language and Language code and make links =
between
instances of =
Language and Language Codes as =
follows:
 
 
OWL:Thing
|_ =
Class:Language
      |_ =
Instance:URI1
           &=
nbsp;  |_ property:hasCode  en  (link to the en instance =
of Class
ISO639-1 =
below)
           &=
nbsp;  |_ property:hasCode  eng  (link to the eng =
instance of Class
ISO639-1 below)
 
|_ =
Class:LanguageCode
      |_ SubClass =
ISO639-1
           &=
nbsp;  |_ Instance:en
           &=
nbsp;  |_ Instance:fr
           &=
nbsp;  |_ etc.
      |_ SubClass =
ISO639-2
           &=
nbsp;  |_ Instance:eng
           &=
nbsp;  |_ Instance:fra
           &=
nbsp;  |_ etc.
      |_ =
etc.
 
Does anyone =
have similar experience with modelling in OWL? Any suggestions =
on
which model is =
better and (extensible)? Does an ontology already exist =
that
we can =
reuse?
 
Than you, =

Gauri
  =


This email was sent to you = by Reuters,=20 the global news and information company.
To find out more about = Reuters=20 visit www.about.reuters.com=20

Any views expressed in this message are = those of the=20 individual sender, except where the sender specifically states them = to be=20 the views of Reuters Limited.

Reuters Limited is part of the Reuters = Group of=20 companies, of which Reuters Group PLC is the ultimate parent = company.=20 Reuters Group PLC - Registered office address: The Reuters Building, = South=20 Colonnade, Canary = Wharf, London E14=20 5EP, United=20 Kingdom
Registered No:=20 3296375
Registered in England and Wales=20 =

------=_NextPart_000_0021_01C78726.9B4A3FF0-- --===============0671239556== 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 --===============0671239556==-- From ltru-bounces@ietf.org Wed Apr 25 05:48: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 1Hge6j-00010n-5Q; Wed, 25 Apr 2007 05:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge6i-00010i-7n for ltru@ietf.org; Wed, 25 Apr 2007 05:48:16 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hge6e-0008D0-Dw for ltru@ietf.org; Wed, 25 Apr 2007 05:48:16 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l3P9m92C011402 for ; Wed, 25 Apr 2007 18:48:09 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4b97_12f71378_f312_11db_88d6_0014221f2a2d; Wed, 25 Apr 2007 18:48:08 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50906) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 25 Apr 2007 18:46:50 +0900 Message-Id: <6.0.0.20.2.20070425162231.09ba9ab0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 25 Apr 2007 16:31:39 +0900 To: "Doug Ewell" , "LTRU Working Group" , From: Martin Duerst Subject: Re: [Ltru] Re: Archival of registration forms In-Reply-To: <002401c78635$041f5760$6401a8c0@DGBP7M81> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 14:54 07/04/24, Doug Ewell wrote: >Stephane Bortzmeyer wrote: > >>> At the specified address, you can find the language subtag registry but not the actual registration forms. >> >> This is specially annoying since, apparently, the "official" registration form, the one which was sent to the IANA, does not seem to be always publically available. For instance, the form for the variant "baku1926" did not appear in ietf-languages (to find out what it looked like, you have to read several messages and to integrate the various patches proposed and accepted). Based on the experience with other registrations, I think it is good if the reviewer can request the proposer to resubmit, but it is also good if the reviewer can go ahead and move on without waiting for resubmission. Too reasons for the above: 1) IETF traditionally tries to use a lightweight and flexible process. 2) Requesters often forget to do a resubmission. The typical case is registrations where the requester has to submit the proposal to IANA two weeks after the review; most requesters simply forget that. >This would be easier if we could require the proposer to be responsible for updating his or her own form, and resubmitting it as necessary to reflect changes required by the Reviewer or recommended by the list. Some registration forms over the past year have required major clarification or other cleanup before they were well-defined enough to go into the Registry. > >I've always thought we were doing the proposer a service by considering and registering their subtags based on incomplete or vague forms plus a lot of discussion. Probably this was misguided. If completing the form can be done easily, that's a very valuable and not misguided service. But the right to request a resubmission should be available. >Those of you who have experience with proposals for ISO, ANSI, BSI, WG2, Unicode, etc., either at the submitting or evaluating end, can probably share the pros and cons of the approaches taken by those bodies, and suggest a better way forward for us. Make sure we stay flexible. >Addison Phillips wrote: > >> I too find it questionable when the final registered format is not sent to the list prior to forwarding (or at least as part of forwarding) to IANA. In fact, I suspect that, given the stability guarantees and rules in RFC 4646, such registrations can be appealed if they differ from the requested record. > >I agree that the final record that is sent to IANA should be cc'd to ietf-languages (not LTRU). I would not tend to agree that it should be sent *before* final submission to IANA; that is what the review period is for. Agreed. 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 Apr 25 05:48: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 1Hge6l-00011x-8z; Wed, 25 Apr 2007 05:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge6j-00011p-La for ltru@ietf.org; Wed, 25 Apr 2007 05:48:17 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hge6g-0008D8-2Y for ltru@ietf.org; Wed, 25 Apr 2007 05:48:17 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l3P9mCXF011414 for ; Wed, 25 Apr 2007 18:48:12 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4ba8_15432144_f312_11db_97c6_0014221f2a2d; Wed, 25 Apr 2007 18:48:12 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50906) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 25 Apr 2007 18:46:54 +0900 Message-Id: <6.0.0.20.2.20070425163202.09baad70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 25 Apr 2007 16:40:54 +0900 To: Addison Phillips , Doug Ewell From: Martin Duerst Subject: Re: [Ltru] Re: Archival of registration forms In-Reply-To: <462DE444.1030205@yahoo-inc.com> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <462DE444.1030205@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-languages@iana.org, 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 20:04 07/04/24, Addison Phillips wrote: >Actually, I interpret Section 3.5 to mean that submitting a changed registration request opens a review period. The fact that the original requester did not submit the specific email isn't that important. What's important is that *any* registration request has a review period on the list. The subtag reviewer then makes an explicit decision regarding the request. If you're changing the form, you are creating a change that might provoke potential objection. For significant changes, I agree. However, we have to be careful that we don't create an endless loop or an opportunity for a denial of service attack (resubmit -> minor comments -> resubmit -> minor comments -> ...). 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 Apr 25 06:29: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 1HgekB-0002oS-NS; Wed, 25 Apr 2007 06:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgekA-0002nF-Ov for ltru@ietf.org; Wed, 25 Apr 2007 06:29:02 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgek8-0005ZQ-Ga for ltru@ietf.org; Wed, 25 Apr 2007 06:29:02 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l3PASwEo019814 for ; Wed, 25 Apr 2007 19:28:58 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 51bf_c6f07b94_f317_11db_8c3d_0014221fa3c9; Wed, 25 Apr 2007 19:28:58 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52607) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 25 Apr 2007 19:27:32 +0900 Message-Id: <6.0.0.20.2.20070425191121.0b04d790@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 25 Apr 2007 19:27:39 +0900 To: "Debbie Garside" , , "'Elisa F. Kendall'" , "'Misha Wolf'" From: Martin Duerst Subject: RE: [Ltru] RE: [Fwd: Language Ontology] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: 'WWW International' , 'Semantic web list' , Gauri.Salokhe@FAO.ORG, '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 LTRU WG co-chair hat and W3C Internationalization IG chair hats on: David, Debbie (and everybody else, of course, too): Please refrain from any kinds of personal accusations and attacks. LTRU WG co-chair hat on: Everybody, please don't cross-post unrelated followups. The LTRU WG mailing list serves the advancement of the LTRU charter. Occasional announcements are okay, but when discussions shifts to items unrelated to the actual WG work (in this case, administrative languages of countries in ISO 3166), please make sure you remove ltru@ietf.org from the To: or Cc:. With kind regards, Martin. At 18:43 07/04/25, Debbie Garside wrote: >"urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:st1 = "urn:schemas-microsoft-com:office:smarttags"> >David > >I will not respond to personal attacks in public or private or indeed enter into any further dialog with you where it is obvious that your motives are to discredit rather than to participate in this forum. Do not misinterpret this response as being through a lack of knowledge of the subject matter. > >That is my last word. I will respond to you no further. Please also desist from emailing me privately. > >Debbie > > >---------- >From: David Dalby [mailto:daviddalby@linguasphere.info] >Sent: 25 April 2007 10:08 >To: 'Debbie Garside'; 'Elisa F. Kendall'; 'Misha Wolf' >Cc: 'WWW International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; 'LTRU Working Group' >Subject: RE: [Ltru] RE: [Fwd: Language Ontology] > >It is unfortunate that a business-person well-versed in ICT, in marketing techniques and in the workings of ISO, should make such an ungracious and ill-informed remark about the important standard ISO 3166-1. Such a comment is particularly unhelpful in a field requiring international co-operation and linguistic precision, since it is made by a representative of the British Standards Institution and of the team in charge of the related ISO 639 standard. > > > >The argument that incomplete data are $BEO(Bot good data$BG(Bis of course nonsense. ISO 3166 has made an important step forward in making available for the first time standardised data on the administrative use of specific languages at the level of national states. To propose the deletion of that data, on the basis of a single (ill-chosen) example, leads one to ponder the motives for such a proposal. > > > >I hope that this working group may be informed at once of all the other reasons which are prompting the UK to make such an extraordinary request, in the form of D.Garside$BCT(B proposed ISO NWIP (New Work Item Proposal). > > > >At present, the only accusation (based on inadequate understanding of a complex situation) is that ISO 3166-1 $BET(Bhows only two Administrative Languages for India where there are at least twenty-two$BG(B In fact, Hindi and English are the languages used for the federal administration of India (and are thus relevant to the listing of administrative languages in ISO 3166-1) whereas the many other official languages are used either at the level of individual states or union territories, or in communications between those individual states (or territories) and the central government (and will thus be relevant to the further listing of administrative languages in ISO 3166-2, covering sub-divisions of countries). I hope that any member of the working group will correct me, if my summary of the Indian situation is itself too simplified. > > > >David Dalby > > > > _____________________________________________________ > > > >Dr David Dalby > >Director > > > >L$BC0(Bbservatoire linguistique / The Linguasphere Observatory > >Hebron > >Whitland > >Wales > >SA34 0XT > >---------- >From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] >Sent: 23 April 2007 23:55 >To: 'Elisa F. Kendall'; 'Misha Wolf' >Cc: 'WWW International'; 'Semantic web list'; Gauri.Salokhe@FAO.ORG; 'LTRU Working Group' >Subject: [Ltru] RE: [Fwd: Language Ontology] > > > >Please be very careful with the use of the "Administrative Language" information from ISO 3166-1. It is incomplete and therefore not good data. > > > >For example, it shows only two "Administrative Languages" for India where there are at least twenty-two. I am hoping that this information will be taken out of the standard in the near future. I am currently writing an ISO NWIP for a revision of ISO 3166-1 which will include a proposal for the deletion of this data. > > > >Best regards > > > >Debbie Garside > >Editor ISO DIS 639-6 > >www.geolang.com > > > > > >---------- >From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall >Sent: 23 April 2007 18:25 >To: Misha Wolf >Cc: Gauri.Salokhe@FAO.ORG; WWW International; Semantic web list; LTRU Working Group >Subject: Re: [Fwd: Language Ontology] > >Hi Misha, > >We are very aware of it, and have been following the work, but I failed to mention it in the email. I should say that our ontology was developed for offline use in an internal system, as an initial requirement. Having said that, if you look at the RFCs, they only describe tags, not an RDF vocabulary or OWL ontology. Our approach is compatible with the RFCs but adds capabilities that support co-reference resolution, for example, in target application. > >Best, > >Elisa > >Misha Wolf wrote: > >This sounds very worrying as you don't seem to be aware of BCP 47. > > > >Misha > > > >---------- >From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Elisa F. Kendall >Sent: 23 April 2007 17:32 >To: Gauri.Salokhe@FAO.ORG >Cc: 'WWW International'; Semantic web list >Subject: Re: [Fwd: Language Ontology] > >Hi Gauri, > >We've done this for some of our government customers, using essentially the second approach you cite. We're also in the process of relating the ontology to another one we've built to represent ISO 3166, which includes the administrative languages used by countries and non-sovereign territories represented in that standard. > >If you can hang out for a few days, we (Sandpiper) are just finalizing a version that includes both ISO 639-1 and 639-2. The approach is more of a hybrid of the two you present, based on customer needs. It includes a fragment of ISO 1087, and also some inverse relations since there is a one-to-one correspondence between languages and codes. We elected to create a 'Language' class, rather than 'LanguageCode', which we reuse in other applications; classes for Alpha-2Code and Alpha-3Code are subclasses of CodeElement, from ISO 5127, with instances of these codes as first class individuals. We use literals (via datatype properties) to represent the set of English, French, and in the case of 639-1 Indigenous names. We've also created subclasses of Alpha-3Code to support distinctions between bibliographic and terminologic, collective, and special identifiers, with individual and macrolanguages to support 639-3. A subsequent release will include all of the languages described in ISO 639-3, as well as additions to support at least some of the subtagging that Dan mentions, fyi. Our intent is to publish it on a new portal that will become part of a new service offered by the Ontology PSIG in the OMG, since we've been asked to publish several ontologies in recent RFPs. I'll be happy to send our preliminary version when it's "baked and tested", and follow up with an announcement of the new portal (where a revision using OMG URIs will be posted) once that's available. It may be a couple of months before we're ready to make that announcement, but we're hoping that the service will be useful to many of us in the Semantic Web community. > >Best regards, > >Elisa > >Dan Brickley wrote: > > >Forwarding from the Dublin Core list, in case folk here can advise. > >Gauri, one thing I'd suggest as useful would be to take the concepts implicit in RFC 4646, > >http://www.rfc-editor.org/rfc/rfc4646.txt >see also http://www.w3.org/International/articles/language-tags/Overview.en.php > >...and in particular the subtag mechanism, script, region, variant etc. > >It would be great to have those expressed explicitly. > >cheers, > >Dan > > > >Subject: > >Language Ontology > >From: > >"Salokhe, Gauri (KCEW)" > >Date: > >Mon, 23 Apr 2007 17:28:39 +0200 > >To: > >DC-GENERAL@JISCMAIL.AC.UK > > > >To: > >DC-GENERAL@JISCMAIL.AC.UK > > > > >Dear All, > > > >We are working on creating Ontology for languages. The need came up as we > >tried to convert our XML metadata files into OWL. In our metadata (XML) > >records, we have three types of occurrences of language information. > > > >En > >eng > >English > > > > > >We have two options for modelling the language ontology: > > > >1) Create a class for each language, assign URI to it and add all the other > >lexical variations, ISO codes (create datatype property) as follows: > > > >OWL:Thing > >|_ Class:Language > > |_ Instance:URI1 > > |_ rdfs:label xml:lang="en" English > > |_ rdfs:label xml:lang="es" Ingl$BqT(B > > |_ rdfs:label xml:lang="it" Inglese > > |_ rdfs:label xml:lang="fr" Anglais > > |_ etc. > > |_ property:hasISO639-1Code en (string) > > |_ property:hasISO639-2Code eng (string) > > |_ etc. > > |_ Instance:URI2 > > |_ Instance:URI3 > > |_ Instance:URI4 > > > > > >2) Create Classes called Language and Language code and make links between > >instances of Language and Language Codes as follows: > > > > > >OWL:Thing > >|_ Class:Language > > |_ Instance:URI1 > > |_ property:hasCode en (link to the en instance of Class > >ISO639-1 below) > > |_ property:hasCode eng (link to the eng instance of Class > >ISO639-1 below) > > > >|_ Class:LanguageCode > > |_ SubClass ISO639-1 > > |_ Instance:en > > |_ Instance:fr > > |_ etc. > > |_ SubClass ISO639-2 > > |_ Instance:eng > > |_ Instance:fra > > |_ etc. > > |_ etc. > > > >Does anyone have similar experience with modelling in OWL? Any suggestions on > >which model is better and (extensible)? Does an ontology already exist that > >we can reuse? > > > >Than you, > >Gauri > > > >This email was sent to you by Reuters, the global news and information company. >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. > >Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom >Registered No: 3296375 >Registered in England and Wales > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# 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 Apr 25 07:44: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 1Hgfuq-0008PJ-DU; Wed, 25 Apr 2007 07:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgfup-0008PD-EJ for ltru@ietf.org; Wed, 25 Apr 2007 07:44:07 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgful-000076-1B for ltru@ietf.org; Wed, 25 Apr 2007 07:44:07 -0400 Received: from [10.76.37.227] (wifi-postauth227.london.corp.yahoo.com [10.76.37.227]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3PBhhYA013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 04: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=lEV2rC0vgGTWa0ofqpa4/Hi/Mxj8i/HI64CxB3l+q8FSgMjUfj+03pgHB7mnE6xB Message-ID: <462F3EEF.4050801@yahoo-inc.com> Date: Wed, 25 Apr 2007 12:43:43 +0100 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: Archival of registration forms References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <462DE444.1030205@yahoo-inc.com> <6.0.0.20.2.20070425163202.09baad70@localhost> In-Reply-To: <6.0.0.20.2.20070425163202.09baad70@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ietf-languages@iana.org, 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 No, the language subtag reviewer is empowered to decide whether to proceed with a given registration (or to reject the application). However, the record to be sent to IANA *must* appear on list at some point prior to submission so that comments (major or minor) can be made. Michael is empowered to ignore spurious or minor comments. There is no requirement to resubmit the record if it is unchanged. However, if he picks up a minor comment and modifies the record, he really needs to provide an opportunity for the list the see the full, comprehensive record. This avoids Stephane's original complaint---that you have to read many emails of a period of time to figure out what the record actually will be. Addison Martin Duerst wrote: > At 20:04 07/04/24, Addison Phillips wrote: > >> Actually, I interpret Section 3.5 to mean that submitting a changed registration request opens a review period. The fact that the original requester did not submit the specific email isn't that important. What's important is that *any* registration request has a review period on the list. The subtag reviewer then makes an explicit decision regarding the request. If you're changing the form, you are creating a change that might provoke potential objection. > > For significant changes, I agree. However, we have to be careful that we > don't create an endless loop or an opportunity for a denial of service attack > (resubmit -> minor comments -> resubmit -> minor comments -> ...). > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 25 15:00: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 1Hgmix-0000OU-Dz; Wed, 25 Apr 2007 15:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmiv-0000OL-Kq for ltru@lists.ietf.org; Wed, 25 Apr 2007 15:00:17 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgmiv-0001Ya-1E for ltru@lists.ietf.org; Wed, 25 Apr 2007 15:00:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OBVE2YdgqOOw1aWZf+rQbOFlr/jBoeouxt9JMoXIqTZmdDeTReKc5ZtlUiKFhCia; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.155] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hgmiu-0006lx-41 for ltru@lists.ietf.org; Wed, 25 Apr 2007 15:00:16 -0400 Message-ID: <00ec01c7876c$47ca3380$6601a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Wed, 25 Apr 2007 12:02:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd7a450546badea92eaa64d07ddfb84a3c4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.155 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: Subject: [Ltru] Fw: 69th IETF - Working Group/BOF Scheduling X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - There are currently no plans to schedule an ltru WG session for the IETF meeting in Chicago. If you think a face-to-face meeting would be necessary, please post your proposed agenda items to the ltru@ietf.org mailing list. Randy ltru co-chair > From: "IETF Agenda" > To: ; ; > Sent: Monday, April 23, 2007 12:31 PM > Subject: 69th IETF - Working Group/BOF Scheduling > > ----------------------------------------------------------------- > 69th IETF - Chicago, IL USA > Meeting Dates: July 22-27, 2007 > ----------------------------------------------------------------- > > We will be accepting scheduling requests for all Working Groups and BOFs > starting today, Monday, April 23, 2007. The milestones and deadlines for > scheduling-related activities are as follows: > > -- Cut-off date for requesting a Working Group session and for > preliminary BOF proposals to ADs: Monday, May 21 at 17:00 ET (21:00 > UTC/GMT). > -- Cut-off date for requests to schedule BoFs: Monday, June 11 at 17:00 ET > (21:00 UTC/GMT). > -- Preliminary agenda published for comment: Friday, June 15 by midnight > ET. > -- Cut-off date for requests to reschedule a session: Wednesday, June 27 > at 09:00 ET (13:00 UTC/GMT). > -- Final agenda published: Monday, July 2 before midnight ET. > -- Draft Working Group agendas due: Wednesday, July 11 at 17:00 ET (21:00 > UTC/GMT). > -- Revised Working Group agendas due: Monday, June 16 at 12:00 ET (16:00 > UTC/GMT), upload using IETF Meeting Materials Management Tool > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the message, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 11 by 17:00 ET (21:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > July 16 at 12:00 ET (16:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 69 Meeting Materials" Web page is: > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=69 > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools. > If you are a BOF chair who is not also a Working Group chair, then you > will be given an account on the "IETF Meeting Materials Management Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =============================================================== > For your convenience, comprehensive information on requesting meeting > sessions at IETF 69 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, based > on availability, after Wednesday, June 27 at 09:00 ET (13:00 UTC/GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 68th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Chris Newman > > Internet Area (int) > Jari Arkko > Mark Townsley > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Jon Peterson > > Routing Area (rtg) > Ross Callon > David Ward > > Security Area (sec) > Sam Hartman > William Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =========================================================== > 68th IETF Meeting Attendance Number > > 16ng 119 > 16ng (2nd session) 46 > 6lowpan 57 > adslmib 8 > ancp 33 > apparea 74 > autoconf 53 > avt 80 > avt (2nd session) 62 > behave 43 > bfd 65 > bliss 171 > bmwg 29 > btns 51 > calsify 18 > capwap 39 > ccamp 109 > ccamp (2nd session) 94 > dccp 37 > dhc 61 > dime 26 > dkim 46 > dna 14 > dnsext 89 > dnsop 107 > eai 59 > ecrit 91 > emu 48 > enum 106 > fecframe 22 > forces 28 > fsm 41 > geopriv 84 > hiprg NI > hokey 96 > idr 69 > ifare 60 > intarea 250 > ipdvb 18 > ipfix NI > ippm 40 > ipr 30 > isis 34 > isms 36 > keyprov 42 > krb-wg 27 > krb-wg (2nd session) 30 > l1vpn 51 > l2vpn 114 > l3vpn 106 > lemonade 28 > lemonade (2nd session) 24 > ltans 28 > manet 104 > mboned 57 > mediactrl 48 > mip4 48 > mip6 140 > mipshop 123 > mipshop (2nd session) 94 > mmusic 128 > mobopts 59 > monami6 115 > mpls 114 > nea 55 > nemo 135 > netconf 50 > netlmm 129 > nfsv4 NI > nmrg 32 > nsis 53 > ntp 28 > opsares 101 > opsarea (2nd session) 65 > ospf 83 > p2psip 183 > pana 30 > pce 77 > pcn 74 > pim 49 > pkix 48 > pwe3 103 > radext 23 > rmt 25 > rtgarea 196 > rptsec 154 > saag 74 > sasl 29 > sava 156 > sidr 77 > sieve 20 > simple 90 > sip 154 > sip (2nd session) 160 > sipping 177 > sipping (2nd session) 134 > smime 22 > softwire 59 > speermint 122 > tcpm 46 > tictoc 113 > tls 53 > trill 48 > tsvarea 110 > tsvwg 88 > tsvwg (2nd session) 65 > v6ops 141 > xcon 82 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 25 23:53: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 1Hgv2T-00073Q-H9; Wed, 25 Apr 2007 23:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgv2S-00073H-HS for ltru@ietf.org; Wed, 25 Apr 2007 23:53:00 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgv2Q-0008O2-7E for ltru@ietf.org; Wed, 25 Apr 2007 23:53:00 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=i6P4yzb2t9/WLQoQ1tCdKrDJ6y3Wz4OxqgdJGrg7S2ve0BruwiZ24QMqo4DnfJQv; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.155] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hgv2P-0002FY-7c for ltru@ietf.org; Wed, 25 Apr 2007 23:52:57 -0400 Message-ID: <001f01c787b6$b2604640$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 25 Apr 2007 20:55:13 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd777172e60908df5942af0349439d9924d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.155 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Transliteration of reference titles X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded from ietf-languages@iana.org, and given a new subject line. As a technical contributor, I fully agree with the sentiment. However, I leave it to others to decide whether championing sich a change makes sense at this time. Randy > From: "Michael Everson" > To: > Sent: Wednesday, April 25, 2007 3:08 PM > Subject: Re: Re[2]: be-tarask > > At 11:06 -0700 2007-04-25, Randy Presuhn wrote: > > >(Even if I would like it better if it were not transliterated. :-) > > The point of the entry is to enable people to find the book. I did > not like Birlәşdirilmiş and I still don't. If the > entries were in proper HTML with charset headers it would be one > thing. They're not, and I'd really rather stick with ASCII since > that's how primitive the registry format is. > > Now there's something useful LTRU could chew on. > -- > Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 00:59: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 1Hgw4P-0002dy-Tg; Thu, 26 Apr 2007 00:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgw4P-0002aj-3l for ltru@ietf.org; Thu, 26 Apr 2007 00:59:05 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgw4N-0003Rx-Sb for ltru@ietf.org; Thu, 26 Apr 2007 00:59:05 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Hgw4K-0006CZ-JD; Thu, 26 Apr 2007 00:59:00 -0400 Date: Thu, 26 Apr 2007 00:59:00 -0400 To: Randy Presuhn Subject: Re: [Ltru] Transliteration of reference titles Message-ID: <20070426045900.GF4592@mercury.ccil.org> References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01c787b6$b2604640$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Forwarded from ietf-languages@iana.org, and given a new > subject line. As a technical contributor, I fully agree with the > sentiment. However, I leave it to others to decide whether > championing sich a change makes sense at this time. The only way to make that work would be to re-express the whole registry as an HTML or XML file; I would be stronly opposed to such a redesign at this time. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 05:07: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 1Hgzwx-0000aN-Rc; Thu, 26 Apr 2007 05:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgzww-0000aE-4y for ltru@ietf.org; Thu, 26 Apr 2007 05:07:38 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgzwu-0001VA-Nc for ltru@ietf.org; Thu, 26 Apr 2007 05:07:38 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 12D6A1C00ED for ; Thu, 26 Apr 2007 11:07:36 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0E6501C00E3 for ; Thu, 26 Apr 2007 11:07:36 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0B3C158ED1F for ; Thu, 26 Apr 2007 11:07:36 +0200 (CEST) Date: Thu, 26 Apr 2007 11:07:36 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20070426090736.GA24220@nic.fr> References: <010501c78681$bab05550$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010501c78681$bab05550$6401a8c0@DGBP7M81> 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: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [ietf-languages suppressed since we embark in actual changes to 4646bis] On Tue, Apr 24, 2007 at 08:03:33AM -0700, Doug Ewell wrote a message of 78 lines which said: > This form has NOT been sent to IANA thus far. ... > My understanding was that the Registration Form was intended for the > proposer to present the new subtag and explain its usage and context ... > It was thought that sending additional information to IANA that was not > intended for insertion into the Registry, such as the requester's name > and e-mail address and extensive bibliographic references, would result > in confusion on the part of IANA and possible errors in the Registry. > > I recognize that this conflicts with the wording in in Section 3.5 which > spurred this thread: OK, so, how I see it after this discussion is that there are several ways to resolve the discrepancy between what's is in RFC 4646 and the reality. Before I start submitting patches to 4646bis, I would like to collect opinions on the following strategies for LTRU: 1) Small modification to 4646bis, section 3.5, to make clear that IANA does not receive the form (and therefore does not archive it) but only the record (which will go "as is" in the registry). If I understand well, that's Doug Ewell's opinion. 2) Same as 1) *plus* an obligation for the LSR or the submitter to post the *final* form on ietf-languages so it is archived and accessible (without involving IANA). 3) Modification to 4646bis, section 3.3 and 3.5 to make crystal-clear that IANA receives the *form*, not just the record and make it available, both in the registry and in a to-be-determined repository. (Apparently the way it was supposed to work in RFC 3066). My personal preference goes to 3), with 2) as a reasonable backup. Opinions? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 14:35: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 1Hh8oS-0004je-3R; Thu, 26 Apr 2007 14:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8oR-0004iw-5S for ltru@ietf.org; Thu, 26 Apr 2007 14:35:27 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8oP-0005rl-Gf for ltru@ietf.org; Thu, 26 Apr 2007 14:35:27 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X2Ki6M1hcxwUaHbSqfhb8O/OG/yQdsr0eGbHGd1dUynCl/YRJ1g0rR+ZerpaxPIn; 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.78.92] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hh8oO-0003YM-SJ for ltru@ietf.org; Thu, 26 Apr 2007 14:35:25 -0400 Message-ID: <000c01c78831$f94b86c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <010501c78681$bab05550$6401a8c0@DGBP7M81> <20070426090736.GA24220@nic.fr> Subject: Re: [Ltru] Re: Archival of registration forms Date: Thu, 26 Apr 2007 11:37:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd73560fdd28dc34d27ab2c841fd905f7ff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.92 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Stephane Bortzmeyer" > To: "LTRU Working Group" > Sent: Thursday, April 26, 2007 2:07 AM > Subject: [Ltru] Re: Archival of registration forms ... > OK, so, how I see it after this discussion is that there are several > ways to resolve the discrepancy between what's is in RFC 4646 and the > reality. Before I start submitting patches to 4646bis, I would like to > collect opinions on the following strategies for LTRU: > > 1) Small modification to 4646bis, section 3.5, to make clear that IANA > does not receive the form (and therefore does not archive it) but only > the record (which will go "as is" in the registry). If I understand > well, that's Doug Ewell's opinion. > > 2) Same as 1) *plus* an obligation for the LSR or the submitter to > post the *final* form on ietf-languages so it is archived and > accessible (without involving IANA). > > 3) Modification to 4646bis, section 3.3 and 3.5 to make crystal-clear > that IANA receives the *form*, not just the record and make it > available, both in the registry and in a to-be-determined > repository. (Apparently the way it was supposed to work in RFC 3066). > > My personal preference goes to 3), with 2) as a reasonable backup. > > Opinions? As a technical contributor, I prefer option (3), since it preserves the intent of what was written in RFC 4646. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 15:57: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 1HhA5i-0000nW-O5; Thu, 26 Apr 2007 15:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhA5h-0000nA-EC for ltru@lists.ietf.org; Thu, 26 Apr 2007 15:57:21 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhA5d-0007hv-10 for ltru@lists.ietf.org; Thu, 26 Apr 2007 15:57:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HhA5P-0000H3-Jx for ltru@lists.ietf.org; Thu, 26 Apr 2007 21:57:03 +0200 Received: from 1cust160.tnt4.hbg2.deu.da.uu.net ([149.225.70.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 21:57:03 +0200 Received: from nobody by 1cust160.tnt4.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 21:57:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 26 Apr 2007 21:56:28 +0200 Organization: Lines: 9 Message-ID: <463103EC.1CAC@xyzzy.claranet.de> References: <010501c78681$bab05550$6401a8c0@DGBP7M81> <20070426090736.GA24220@nic.fr> <000c01c78831$f94b86c0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust160.tnt4.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > As a technical contributor, I prefer option (3), since it preserves > the intent of what was written in RFC 4646. Same here. If Doug or IANA hate it something like (2) is also okay. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 16:07: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 1HhAFl-0003UF-1C; Thu, 26 Apr 2007 16:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAFk-0003U2-D1 for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:07:44 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAFj-0001JV-3C for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:07:44 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HhAFV-00025u-PT for ltru@lists.ietf.org; Thu, 26 Apr 2007 22:07:29 +0200 Received: from 1cust160.tnt4.hbg2.deu.da.uu.net ([149.225.70.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 22:07:29 +0200 Received: from nobody by 1cust160.tnt4.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 22:07:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 26 Apr 2007 22:03:25 +0200 Organization: Lines: 18 Message-ID: <4631058D.7C69@xyzzy.claranet.de> References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust160.tnt4.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: Transliteration of reference titles X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Forwarded from ietf-languages@iana.org It got two replies there so far, Archived-At: How about declaring this issue as "closed" unless some evidence about the worldwide adoption of UTF-8 before Harald's deadline as specified in RFC 2277 is posted ? Frank -- Negotiating a charset may be regarded as an interim mechanism that is to be supported until support for interchange of UTF-8 is prevalent; however, the timeframe of "interim" may be at least 50 years [BCP 18] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 16: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 1HhAgI-0005Nx-D5; Thu, 26 Apr 2007 16:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAgH-0005Nh-23 for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:35:09 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAgD-0007YI-31 for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:35:08 -0400 Received: by nz-out-0506.google.com with SMTP id o37so1054703nzf for ; Thu, 26 Apr 2007 13:35: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=HuaU+7l8eT/1TwvCsC/OmP8edNfgZCJS+LJ2tO6CcD0dl1E/B2jEOJVWmzOxBiY+lBzkx3vill7iWvfx1Rj212GuZBQhMdrRWHXTVF6iIexa3D2HzxwIuk9CXibdXfY0sSbWYBLsJTCD2XnjXeVBrKw+5DU/cMMgT9FISc/i8tc= 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=bW6XTYMRuRK/kpG3PfGCsZvYmKIIk7saqL2QapS6d5IKTJ/JyB6w5wmtw6f0m3bZK+ri2ncx9OSeOdkGb7/C4PUSw/sTXoJfBJE29G4fDm0UvNROSMv3/lr8xm2T4+gqQSJlKiw1gpjhyAJqkT0fTm7pDPsQzR+TkSUf3srUCLY= Received: by 10.114.197.1 with SMTP id u1mr727914waf.1177619704471; Thu, 26 Apr 2007 13:35:04 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 26 Apr 2007 13:35:04 -0700 (PDT) Message-ID: <30b660a20704261335jf4bdde9s551f0feab72a3a7e@mail.gmail.com> Date: Thu, 26 Apr 2007 13:35:04 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Transliteration of reference titles In-Reply-To: <4631058D.7C69@xyzzy.claranet.de> MIME-Version: 1.0 References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> <4631058D.7C69@xyzzy.claranet.de> X-Google-Sender-Auth: 9c39fb1f610451cd X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0947780502==" Errors-To: ltru-bounces@ietf.org --===============0947780502== Content-Type: multipart/alternative; boundary="----=_Part_78517_27193767.1177619704390" ------=_Part_78517_27193767.1177619704390 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnkgcXVlc3Rpb24gdGhhdCBVVEYtOCBpcyBzdWZmaWNp ZW50bHkgdW5pdmVyc2FsCnRoYXQgdGhlIHZhc3QgbWFqb3JpdHkgb2YgcGVvcGxlIGNhbiBoYW5k bGUgaXQgd2l0aG91dCBhbnkgcHJvYmxlbSBhdCBhbGwsCmFuZCBhbnlvbmUgZWxzZSBjYW4gaGFu ZGxlIGl0IHdpdGggYSBzbWFsbCBhbW91bnQgb2YgZWZmb3J0IGlmIHRoZXkgd2FudCB0by4KQnV0 IHRoZSByZWFsIGlzc3VlIGlzLCB3aGljaCBvZiB0aGUgZm9sbG93aW5nIGlzICptb3JlKiB1bml2 ZXJzYWwgaW4gYQpwbGFpbnRleHQgZmlsZToKCk9wdGlvbiAxLiBCaXJsJiN4NEQ5OyYjeDE1Rjtk aXJpbG1pJiN4MTVGOwogIG9yCk9wdGlvbiAyLiBCaXJs05nFn2RpcmlsbWnFnwoKTWFyawoKT24g NC8yNi8wNywgRnJhbmsgRWxsZXJtYW5uIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+IHdyb3Rl Ogo+Cj4gUmFuZHkgUHJlc3VobiB3cm90ZToKPgo+ID4gRm9yd2FyZGVkIGZyb20gaWV0Zi1sYW5n dWFnZXNAaWFuYS5vcmcKPgo+IEl0IGdvdCB0d28gcmVwbGllcyB0aGVyZSBzbyBmYXIsIEFyY2hp dmVkLUF0Ogo+IDxodHRwOi8vcGVybWFsaW5rLmdtYW5lLm9yZy9nbWFuZS5pZXRmLmxhbmd1YWdl cy80NjMyPgo+IDxodHRwOi8vcGVybWFsaW5rLmdtYW5lLm9yZy9nbWFuZS5pZXRmLmxhbmd1YWdl cy80NjMzPgo+Cj4gSG93IGFib3V0IGRlY2xhcmluZyB0aGlzIGlzc3VlIGFzICJjbG9zZWQiIHVu bGVzcyBzb21lCj4gZXZpZGVuY2UgYWJvdXQgdGhlIHdvcmxkd2lkZSBhZG9wdGlvbiBvZiBVVEYt OCBiZWZvcmUKPiBIYXJhbGQncyBkZWFkbGluZSBhcyBzcGVjaWZpZWQgaW4gUkZDIDIyNzcgaXMg cG9zdGVkID8KPgo+IEZyYW5rCj4gLS0KPiBOZWdvdGlhdGluZyBhIGNoYXJzZXQgbWF5IGJlIHJl Z2FyZGVkIGFzIGFuIGludGVyaW0gbWVjaGFuaXNtIHRoYXQgaXMKPiB0byBiZSBzdXBwb3J0ZWQg dW50aWwgc3VwcG9ydCBmb3IgaW50ZXJjaGFuZ2Ugb2YgVVRGLTggaXMgcHJldmFsZW50Owo+IGhv d2V2ZXIsIHRoZSB0aW1lZnJhbWUgb2YgImludGVyaW0iIG1heSBiZSBhdCBsZWFzdCA1MCB5ZWFy cyBbQkNQIDE4XQo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+CgoKCi0tIApNYXJrCg== ------=_Part_78517_27193767.1177619704390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24mIzM5O3QgdGhpbmsgdGhlcmUgaXMgYW55IHF1ZXN0aW9uIHRoYXQgVVRGLTggaXMgc3Vm ZmljaWVudGx5IHVuaXZlcnNhbCB0aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHBlb3BsZSBjYW4g aGFuZGxlIGl0IHdpdGhvdXQgYW55IHByb2JsZW0gYXQgYWxsLCBhbmQgYW55b25lIGVsc2UgY2Fu IGhhbmRsZSBpdCB3aXRoIGEgc21hbGwgYW1vdW50IG9mIGVmZm9ydCBpZiB0aGV5IHdhbnQgdG8u IEJ1dCB0aGUgcmVhbCBpc3N1ZSBpcywgd2hpY2ggb2YgdGhlIGZvbGxvd2luZyBpcyAqbW9yZSog dW5pdmVyc2FsIGluIGEgcGxhaW50ZXh0IGZpbGU6Cjxicj48YnI+T3B0aW9uIDEuIEJpcmwmYW1w OyN4NEQ5OyZhbXA7I3gxNUY7ZGlyaWxtaSZhbXA7I3gxNUY7PGJyPiZuYnNwOyBvcjxicj4KCk9w dGlvbiAyLiBCaXJs05nFn2RpcmlsbWnFnzxicj4KCjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFu IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNC8yNi8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5h bWUiPkZyYW5rIEVsbGVybWFubjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpub2JvZHlAeHl6enku Y2xhcmFuZXQuZGUiPm5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTwvYT4mZ3Q7IHdyb3RlOjwvc3Bh bj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4 IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFk ZGluZy1sZWZ0OiAxZXg7Ij4KUmFuZHkgUHJlc3VobiB3cm90ZTo8YnI+PGJyPiZndDsgRm9yd2Fy ZGVkIGZyb20gPGEgaHJlZj0ibWFpbHRvOmlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnIj5pZXRmLWxh bmd1YWdlc0BpYW5hLm9yZzwvYT48YnI+PGJyPkl0IGdvdCB0d28gcmVwbGllcyB0aGVyZSBzbyBm YXIsIEFyY2hpdmVkLUF0Ojxicj4mbHQ7PGEgaHJlZj0iaHR0cDovL3Blcm1hbGluay5nbWFuZS5v cmcvZ21hbmUuaWV0Zi5sYW5ndWFnZXMvNDYzMiI+Cmh0dHA6Ly9wZXJtYWxpbmsuZ21hbmUub3Jn L2dtYW5lLmlldGYubGFuZ3VhZ2VzLzQ2MzI8L2E+Jmd0Ozxicj4mbHQ7PGEgaHJlZj0iaHR0cDov L3Blcm1hbGluay5nbWFuZS5vcmcvZ21hbmUuaWV0Zi5sYW5ndWFnZXMvNDYzMyI+aHR0cDovL3Bl cm1hbGluay5nbWFuZS5vcmcvZ21hbmUuaWV0Zi5sYW5ndWFnZXMvNDYzMzwvYT4mZ3Q7PGJyPjxi cj5Ib3cgYWJvdXQgZGVjbGFyaW5nIHRoaXMgaXNzdWUgYXMgJnF1b3Q7Y2xvc2VkJnF1b3Q7IHVu bGVzcyBzb21lCjxicj5ldmlkZW5jZSBhYm91dCB0aGUgd29ybGR3aWRlIGFkb3B0aW9uIG9mIFVU Ri04IGJlZm9yZTxicj5IYXJhbGQmIzM5O3MgZGVhZGxpbmUgYXMgc3BlY2lmaWVkIGluIFJGQyAy Mjc3IGlzIHBvc3RlZCA/PGJyPjxicj5GcmFuazxicj4tLTxicj5OZWdvdGlhdGluZyBhIGNoYXJz ZXQgbWF5IGJlIHJlZ2FyZGVkIGFzIGFuIGludGVyaW0gbWVjaGFuaXNtIHRoYXQgaXM8YnI+dG8g YmUgc3VwcG9ydGVkIHVudGlsIHN1cHBvcnQgZm9yIGludGVyY2hhbmdlIG9mIFVURi04IGlzIHBy ZXZhbGVudDsKPGJyPmhvd2V2ZXIsIHRoZSB0aW1lZnJhbWUgb2YgJnF1b3Q7aW50ZXJpbSZxdW90 OyBtYXkgYmUgYXQgbGVhc3QgNTAgeWVhcnMgW0JDUCAxOF08YnI+PGJyPjxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5n IGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+ PGJyPgo8YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxicj48L2Js b2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_78517_27193767.1177619704390-- --===============0947780502== 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 --===============0947780502==-- From ltru-bounces@ietf.org Thu Apr 26 16:51:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAw7-000224-KI; Thu, 26 Apr 2007 16:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAw5-0001z1-KU for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:51:29 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAw4-0002m1-D6 for ltru@lists.ietf.org; Thu, 26 Apr 2007 16:51:29 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HhAw2-0002Cv-QL; Thu, 26 Apr 2007 16:51:26 -0400 Date: Thu, 26 Apr 2007 16:51:26 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Transliteration of reference titles Message-ID: <20070426205126.GK4592@mercury.ccil.org> References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> <4631058D.7C69@xyzzy.claranet.de> <30b660a20704261335jf4bdde9s551f0feab72a3a7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20704261335jf4bdde9s551f0feab72a3a7e@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I don't think there is any question that UTF-8 is sufficiently universal > that the vast majority of people can handle it without any problem at > all, On the Web, yes. In email (and email is an essential part of the registration process), no. > Option 1. Birlәşdirilmiş > or > Option 2. Birl????dirilmi?? Well, that's what they look like in my email client. Both are illegible, but only the first is reconstructible. If we want to keep things like the above version of Option 2 out of the registry, we either need to bypass email entirely, or we need to stick with what we've got. -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? cowan@ccil.org --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 17:21: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 1HhBPO-0003dx-H9; Thu, 26 Apr 2007 17:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBPN-0003dl-QY for ltru@lists.ietf.org; Thu, 26 Apr 2007 17:21:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBPM-0000ye-Bi for ltru@lists.ietf.org; Thu, 26 Apr 2007 17:21:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HhBPB-0006Y4-G0 for ltru@lists.ietf.org; Thu, 26 Apr 2007 23:21:33 +0200 Received: from 1cust160.tnt4.hbg2.deu.da.uu.net ([149.225.70.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 23:21:33 +0200 Received: from nobody by 1cust160.tnt4.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 23:21:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 26 Apr 2007 23:21:07 +0200 Organization: Lines: 11 Message-ID: <463117C2.DBB@xyzzy.claranet.de> References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> <4631058D.7C69@xyzzy.claranet.de> <30b660a20704261335jf4bdde9s551f0feab72a3a7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust160.tnt4.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: Transliteration of reference titles X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: = > Option 1. Birlәşdirilmiş > or > Option 2. Birl=D3=99=C5=9Fdirilmi=C5=9F I pick option 1 for obvious reasons... :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 26 17:26: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 1HhBUM-00005v-Tr; Thu, 26 Apr 2007 17:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBUM-00005l-6x for ltru@lists.ietf.org; Thu, 26 Apr 2007 17:26:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBUK-0001hu-Sf for ltru@lists.ietf.org; Thu, 26 Apr 2007 17:26:54 -0400 Received: by wr-out-0506.google.com with SMTP id 76so754579wra for ; Thu, 26 Apr 2007 14:26:52 -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=RXiE+C5ZjQ+15m/V5w18cBO+iqub/HcWQ8pAURZJDgR+njK3DggGneqBdbFK3JF2ygE8nzBfn9i885EhU8a5ZxopHXStEQ+erIL4bqWlTze0nADm2jPS/qpTSxEI77OksYsy+LGP3x51kjaKfMLUlIFu9tUbZWGpxQ2AyS9yS5c= 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=mqECOZGA9MDzlAo5MtkKJKn9pDOduyrGw2D0qFwpzDDeqpg1fi5RKkR03M365Hl6VKVrSlsDdW9F2+9Y6ZTOLSUvUUZS4TCI/RKSHpF6a/homB56RnytoBWiYxtPiJHs6Ai07AQ8GbiR5wbUJ0+qU/zOX6Y2717cUKKMPmdDXIQ= Received: by 10.114.133.1 with SMTP id g1mr774122wad.1177622812144; Thu, 26 Apr 2007 14:26:52 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 26 Apr 2007 14:26:52 -0700 (PDT) Message-ID: <30b660a20704261426h26cb942byf516b675af5c9139@mail.gmail.com> Date: Thu, 26 Apr 2007 14:26:52 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Transliteration of reference titles In-Reply-To: <20070426205126.GK4592@mercury.ccil.org> MIME-Version: 1.0 References: <001f01c787b6$b2604640$6601a8c0@oemcomputer> <4631058D.7C69@xyzzy.claranet.de> <30b660a20704261335jf4bdde9s551f0feab72a3a7e@mail.gmail.com> <20070426205126.GK4592@mercury.ccil.org> X-Google-Sender-Auth: 2fda657744e81889 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Frank Ellermann , Michael Everson , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0715031509==" Errors-To: ltru-bounces@ietf.org --===============0715031509== Content-Type: multipart/alternative; boundary="----=_Part_79399_32166262.1177622812079" ------=_Part_79399_32166262.1177622812079 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VHJ1ZSwgZW1haWwgaXMgdGhlIGJpZyBob2xkb3V0LCBub3RhYmx5IGhvdG1haWwgYW5kIEV1ZG9y YS4gVGhlcmUgYXJlIHR3bwpvdGhlciBwb3NzaWJpbGl0aWVzIHRoYXQgcGVvcGxlIG1lbnRpb25l ZC4KCiAgIDEuIFVzZSBlbWFpbCwgYnV0IHJlcXVpcmUgYW55IGZvcm1zIHdpdGggVVRGLTggdG8g YmUgYXR0YWNobWVudHMsIG5vdAogICBpbmxpbmUuCiAgIDIuIFVzZSB0aGUgY3VycmVudCBmb3Jt YXQgaW4gc3VibWlzc2lvbiBmb3JtcywgYnV0IGhhdmUgdGhlIHJlc3VsdCBiZQogICBjb252ZXJ0 ZWQgdG8gVVRGLTgsIGVpdGhlciBiZWZvcmUgc2VuZGluZyB0byBJQU5BIChpbiBhbiBhdHRhY2ht ZW50KSwgb3IgYnkKICAgSUFOQSBiZWZvcmUgcG9zdGluZy4KCiBJJ2xsIGNjIE1pY2hhZWwsIHNp bmNlIGhlIGlzIGludm9sdmVkIGluIHRoaXMuCgpNYXJrCgpCVFcsIEknbSBub3QgcHVzaGluZyBz dHJvbmdseSBmb3IgdGhpcywgc2luY2UgdGhlIGN1cnJlbnQgc2l0dWF0aW9uIGlzCndvcmthYmxl LCB0aG91Z2ggbm90IG5vdCBvcHRpbWFsLiBPbmUgZXhhbXBsZSBvZiB3aHkgaXQgaXMgbm90IG9w dGltYWwgaXMKdGhhdCBZYWhvbywgR29vZ2xlLCBldGMuIGRvbid0IHRoaW5rIHRoYXQgdGhlIGxh bmd1YWdlIHN1YnRhZyByZWdpc3RyeQpjb250YWlucyB3b3JkcyBsaWtlIEJva23DpWwuIFRyeSBh IEdvb2dsZSBvciBZYWhvbyBzZWFyY2ggZm9yCgogIGlhbmEgbGFuZ3VhZ2Utc3VidGFnLXJlZ2lz dHJ5IEJva23DpWwKCk9uIDQvMjYvMDcsIEpvaG4gQ293YW4gPGNvd2FuQGNjaWwub3JnPiB3cm90 ZToKPgo+IE1hcmsgRGF2aXMgc2NyaXBzaXQ6Cj4KPiA+IEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMg YW55IHF1ZXN0aW9uIHRoYXQgVVRGLTggaXMgc3VmZmljaWVudGx5IHVuaXZlcnNhbAo+ID4gdGhh dCB0aGUgdmFzdCBtYWpvcml0eSBvZiBwZW9wbGUgY2FuIGhhbmRsZSBpdCB3aXRob3V0IGFueSBw cm9ibGVtIGF0Cj4gPiBhbGwsCj4KPiBPbiB0aGUgV2ViLCB5ZXMuICBJbiBlbWFpbCAoYW5kIGVt YWlsIGlzIGFuIGVzc2VudGlhbCBwYXJ0IG9mIHRoZQo+IHJlZ2lzdHJhdGlvbiBwcm9jZXNzKSwg bm8uCj4KPiA+IE9wdGlvbiAxLiBCaXJsJiN4NEQ5OyYjeDE1RjtkaXJpbG1pJiN4MTVGOwo+ID4g IG9yCj4gPiBPcHRpb24gMi4gQmlybD8/Pz9kaXJpbG1pPz8KPgo+IFdlbGwsIHRoYXQncyB3aGF0 IHRoZXkgbG9vayBsaWtlIGluIG15IGVtYWlsIGNsaWVudC4gIEJvdGggYXJlIGlsbGVnaWJsZSwK PiBidXQgb25seSB0aGUgZmlyc3QgaXMgcmVjb25zdHJ1Y3RpYmxlLiAgSWYgd2Ugd2FudCB0byBr ZWVwIHRoaW5ncyBsaWtlIHRoZQo+IGFib3ZlIHZlcnNpb24gb2YgT3B0aW9uIDIgb3V0IG9mIHRo ZSByZWdpc3RyeSwgd2UgZWl0aGVyIG5lZWQgdG8gYnlwYXNzCj4gZW1haWwgZW50aXJlbHksIG9y IHdlIG5lZWQgdG8gc3RpY2sgd2l0aCB3aGF0IHdlJ3ZlIGdvdC4KPgo+IC0tCj4gV2hhdCBoYXMg Zm91ciBwYWlycyBvZiBwYW50cywgbGl2ZXMgICAgICAgICAgICAgSm9obiBDb3dhbgo+IGluIFBo aWxhZGVscGhpYSwgYW5kIGl0IG5ldmVyIHJhaW5zICAgICAgICAgICAgIGh0dHA6Ly93d3cuY2Np bC5vcmcvfmNvd2FuCj4gYnV0IGl0IHBvdXJzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY293YW5AY2NpbC5vcmcKPiAgICAgICAgIC0tUnVmdXMgVC4gRmlyZWZseQo+CgoKCi0t IApNYXJrCg== ------=_Part_79399_32166262.1177622812079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VHJ1ZSwgZW1haWwgaXMgdGhlIGJpZyBob2xkb3V0LCBub3RhYmx5IGhvdG1haWwgYW5kIEV1ZG9y YS4gVGhlcmUgYXJlIHR3byBvdGhlciBwb3NzaWJpbGl0aWVzIHRoYXQgcGVvcGxlIG1lbnRpb25l ZC48YnI+PG9sPjxsaT5Vc2UgZW1haWwsIGJ1dCByZXF1aXJlIGFueSBmb3JtcyB3aXRoIFVURi04 IHRvIGJlIGF0dGFjaG1lbnRzLCBub3QgaW5saW5lLjwvbGk+PGxpPlVzZSB0aGUgY3VycmVudCBm b3JtYXQgaW4gc3VibWlzc2lvbiBmb3JtcywgYnV0IGhhdmUgdGhlIHJlc3VsdCBiZSBjb252ZXJ0 ZWQgdG8gVVRGLTgsIGVpdGhlciBiZWZvcmUgc2VuZGluZyB0byBJQU5BIChpbiBhbiBhdHRhY2ht ZW50KSwgb3IgYnkgSUFOQSBiZWZvcmUgcG9zdGluZy4KPGJyPjwvbGk+PC9vbD4mbmJzcDtJJiMz OTtsbCBjYyBNaWNoYWVsLCBzaW5jZSBoZSBpcyBpbnZvbHZlZCBpbiB0aGlzLjxicj48YnI+TWFy azxicj48YnI+QlRXLCBJJiMzOTttIG5vdCBwdXNoaW5nIHN0cm9uZ2x5IGZvciB0aGlzLCBzaW5j ZSB0aGUgY3VycmVudCBzaXR1YXRpb24gaXMgd29ya2FibGUsIHRob3VnaCBub3Qgbm90IG9wdGlt YWwuIE9uZSBleGFtcGxlIG9mIHdoeSBpdCBpcyBub3Qgb3B0aW1hbCBpcyB0aGF0IFlhaG9vLCBH b29nbGUsIGV0Yy4gZG9uJiMzOTt0IHRoaW5rIHRoYXQgdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdp c3RyeSBjb250YWlucyB3b3JkcyBsaWtlIEJva23DpWwuIFRyeSBhIEdvb2dsZSBvciBZYWhvbyBz ZWFyY2ggZm9yCjxicj48YnI+Jm5ic3A7IGlhbmEgbGFuZ3VhZ2Utc3VidGFnLXJlZ2lzdHJ5IEJv a23DpWw8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA0LzI2LzA3LCA8 YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9obiBDb3dhbjwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpjb3dhbkBjY2lsLm9yZyI+Y293YW5AY2NpbC5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBz b2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRp bmctbGVmdDogMWV4OyI+Ck1hcmsgRGF2aXMgc2NyaXBzaXQ6PGJyPjxicj4mZ3Q7IEkgZG9uJiMz OTt0IHRoaW5rIHRoZXJlIGlzIGFueSBxdWVzdGlvbiB0aGF0IFVURi04IGlzIHN1ZmZpY2llbnRs eSB1bml2ZXJzYWw8YnI+Jmd0OyB0aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHBlb3BsZSBjYW4g aGFuZGxlIGl0IHdpdGhvdXQgYW55IHByb2JsZW0gYXQ8YnI+Jmd0OyBhbGwsPGJyPjxicj5PbiB0 aGUgV2ViLCB5ZXMuJm5ic3A7Jm5ic3A7SW4gZW1haWwgKGFuZCBlbWFpbCBpcyBhbiBlc3NlbnRp YWwgcGFydCBvZiB0aGUKPGJyPnJlZ2lzdHJhdGlvbiBwcm9jZXNzKSwgbm8uPGJyPjxicj4mZ3Q7 IE9wdGlvbiAxLiBCaXJsJmFtcDsjeDREOTsmYW1wOyN4MTVGO2RpcmlsbWkmYW1wOyN4MTVGOzxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7b3I8YnI+Jmd0OyBPcHRpb24gMi4gQmlybD8/Pz9kaXJpbG1pPz88 YnI+PGJyPldlbGwsIHRoYXQmIzM5O3Mgd2hhdCB0aGV5IGxvb2sgbGlrZSBpbiBteSBlbWFpbCBj bGllbnQuJm5ic3A7Jm5ic3A7Qm90aCBhcmUgaWxsZWdpYmxlLAo8YnI+YnV0IG9ubHkgdGhlIGZp cnN0IGlzIHJlY29uc3RydWN0aWJsZS4mbmJzcDsmbmJzcDtJZiB3ZSB3YW50IHRvIGtlZXAgdGhp bmdzIGxpa2UgdGhlPGJyPmFib3ZlIHZlcnNpb24gb2YgT3B0aW9uIDIgb3V0IG9mIHRoZSByZWdp c3RyeSwgd2UgZWl0aGVyIG5lZWQgdG8gYnlwYXNzPGJyPmVtYWlsIGVudGlyZWx5LCBvciB3ZSBu ZWVkIHRvIHN0aWNrIHdpdGggd2hhdCB3ZSYjMzk7dmUgZ290Ljxicj4KPGJyPi0tPGJyPldoYXQg aGFzIGZvdXIgcGFpcnMgb2YgcGFudHMsIGxpdmVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpvaG4gQ293YW48 YnI+aW4gUGhpbGFkZWxwaGlhLCBhbmQgaXQgbmV2ZXIgcmFpbnMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cDovL3d3dy5jY2lsLm9yZy9+Y293YW4iPmh0dHA6Ly93d3cuY2NpbC5vcmcvfmNv d2FuPC9hPjxicj5idXQgaXQgcG91cnM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAo8YSBocmVmPSJtYWlsdG86Y293YW5AY2NpbC5vcmciPmNvd2FuQGNjaWwub3JnPC9hPjxicj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLVJ1ZnVzIFQu IEZpcmVmbHk8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0t IDxicj5NYXJrCg== ------=_Part_79399_32166262.1177622812079-- --===============0715031509== 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 --===============0715031509==-- From ltru-bounces@ietf.org Fri Apr 27 00:15: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 1HhHsA-0001cq-O4; Fri, 27 Apr 2007 00:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHs9-0001ck-44 for ltru@lists.ietf.org; Fri, 27 Apr 2007 00:15:53 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhHs7-00071A-Gn for ltru@lists.ietf.org; Fri, 27 Apr 2007 00:15:53 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id AD0101E12FA; Thu, 26 Apr 2007 21:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at sharplabs.com Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnOnkx3zqY-Y; Thu, 26 Apr 2007 21:15:46 -0700 (PDT) Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8]) by mail2.sharplabs.com (Postfix) with ESMTP id 3A4FF1E131E; Thu, 26 Apr 2007 21:15:20 -0700 (PDT) Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 21:15:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Transliteration of reference titles Date: Thu, 26 Apr 2007 21:15:19 -0700 Message-ID: In-Reply-To: <30b660a20704261426h26cb942byf516b675af5c9139@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Transliteration of reference titles Thread-Index: AceISaF7W51dbeS6Rm+j8aciQTDYzgAQIyDg From: "McDonald, Ira" To: "Mark Davis" , "John Cowan" X-OriginalArrivalTime: 27 Apr 2007 04:15:20.0092 (UTC) FILETIME=[AB1785C0:01C78882] X-Spam-Score: 0.7 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Frank Ellermann , Michael Everson , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0115834773==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0115834773== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78882.AAF36B3B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78882.AAF36B3B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQogDQpSZWFsaXR5IGNoZWNrOg0KIA0KRW1haWwgYWNjZXNzIGNsaWVudHMgYXJlbid0IHRo ZSBiaWcgcHJvYmxlbSAtIGVtYWlsIGJhY2tib25lDQppbmZyYXN0cnVjdHVyZSBpcyBzdGlsbCBm cmFnbWVudGVkLCBmbGFreSwgYW5kIG5vd2hlcmUgbmVhcg0KdW5pdmVyc2FsbHkgVVRGLTggc2Fm ZS4NCiANCkFsc28sIG5vdCBldmVyeSBjb21wdXRlciB1c2VyIChvciBldmVuIHRoZSB2YXN0IG1h am9yaXR5KQ0KaGFwcGVuIHRvIGJlIHByaXZpbGVnZWQgdG8gY29uc3RhbnRseSBoYXZlIHRoZSBs YXRlc3QgaGFyZHdhcmUNCmFuZCBzb2Z0d2FyZS4NCiANCkhhcm9sZCdzIDUwIHllYXJzICdpbnRl cmltJyBrZWVwcyBsb29raW5nIG1vcmUgYW5kIG1vcmUNCnJlYWxpc3RpYyBhbmQgbGVzcyBhbmQg bGVzcyBsaWtlIHRoZSBoeXBlcmJvbGUgdGhhdCBJIG9yaWdpbmFsbHkNCnJlYWQgaW50byBpdC4N CiANCkFuZCB0aGUgSUVURiBwcm9jZXNzIChmb3IgQUxMIElFVEYgd29ya2luZyBncm91cHMpIGRl cGVuZHMNCmNlbnRyYWxseSBvbiBlbWFpbCBhbmQgb25seSBtb2Rlc3RseSBvbiB3ZWIgaW50ZXJm YWNlcy4NCiANCkNoZWVycywNCi0gSXJhDQogDQpJcmEgTWNEb25hbGQgKE11c2ljaWFuIC8gU29m dHdhcmUgQXJjaGl0ZWN0KQ0KQ2hhaXIgLSBMaW51eCBGb3VuZGF0aW9uIE9wZW4gUHJpbnRpbmcg V0cNCkJsdWUgUm9vZiBNdXNpYyAvIEhpZ2ggTm9ydGggSW5jDQpQTyBCb3ggMjIxICBHcmFuZCBN YXJhaXMsIE1JICA0OTgzOQ0KcGhvbmU6ICsxLTkwNi00OTQtMjQzNA0KZW1haWw6IGltY2RvbmFs ZEBzaGFycGxhYnMuY29tIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsg RGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NClNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAyNiwgMjAwNyA0OjI3IFBNDQpUbzogSm9obiBDb3dhbg0KQ2M6IEZyYW5rIEVsbGVy bWFubjsgTWljaGFlbCBFdmVyc29uOyBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBSZTog W0x0cnVdIFJlOiBUcmFuc2xpdGVyYXRpb24gb2YgcmVmZXJlbmNlIHRpdGxlcw0KDQoNClRydWUs IGVtYWlsIGlzIHRoZSBiaWcgaG9sZG91dCwgbm90YWJseSBob3RtYWlsIGFuZCBFdWRvcmEuIFRo ZXJlIGFyZSB0d28gb3RoZXIgcG9zc2liaWxpdGllcyB0aGF0IHBlb3BsZSBtZW50aW9uZWQuDQoN Cg0KMS4JVXNlIGVtYWlsLCBidXQgcmVxdWlyZSBhbnkgZm9ybXMgd2l0aCBVVEYtOCB0byBiZSBh dHRhY2htZW50cywgbm90IGlubGluZS4gDQoNCjIuCVVzZSB0aGUgY3VycmVudCBmb3JtYXQgaW4g c3VibWlzc2lvbiBmb3JtcywgYnV0IGhhdmUgdGhlIHJlc3VsdCBiZSBjb252ZXJ0ZWQgdG8gVVRG LTgsIGVpdGhlciBiZWZvcmUgc2VuZGluZyB0byBJQU5BIChpbiBhbiBhdHRhY2htZW50KSwgb3Ig YnkgSUFOQSBiZWZvcmUgcG9zdGluZy4gDQoNCg0KIEknbGwgY2MgTWljaGFlbCwgc2luY2UgaGUg aXMgaW52b2x2ZWQgaW4gdGhpcy4NCg0KTWFyaw0KDQpCVFcsIEknbSBub3QgcHVzaGluZyBzdHJv bmdseSBmb3IgdGhpcywgc2luY2UgdGhlIGN1cnJlbnQgc2l0dWF0aW9uIGlzIHdvcmthYmxlLCB0 aG91Z2ggbm90IG5vdCBvcHRpbWFsLiBPbmUgZXhhbXBsZSBvZiB3aHkgaXQgaXMgbm90IG9wdGlt YWwgaXMgdGhhdCBZYWhvbywgR29vZ2xlLCBldGMuIGRvbid0IHRoaW5rIHRoYXQgdGhlIGxhbmd1 YWdlIHN1YnRhZyByZWdpc3RyeSBjb250YWlucyB3b3JkcyBsaWtlIEJva23DpWwuIFRyeSBhIEdv b2dsZSBvciBZYWhvbyBzZWFyY2ggZm9yIA0KDQogIGlhbmEgbGFuZ3VhZ2Utc3VidGFnLXJlZ2lz dHJ5IEJva23DpWwNCg0KDQpPbiA0LzI2LzA3LCBKb2huIENvd2FuIDwgSFlQRVJMSU5LICJtYWls dG86Y293YW5AY2NpbC5vcmciY293YW5AY2NpbC5vcmc+IHdyb3RlOiANCg0KTWFyayBEYXZpcyBz Y3JpcHNpdDoNCg0KPiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBxdWVzdGlvbiB0aGF0IFVU Ri04IGlzIHN1ZmZpY2llbnRseSB1bml2ZXJzYWwNCj4gdGhhdCB0aGUgdmFzdCBtYWpvcml0eSBv ZiBwZW9wbGUgY2FuIGhhbmRsZSBpdCB3aXRob3V0IGFueSBwcm9ibGVtIGF0DQo+IGFsbCwNCg0K T24gdGhlIFdlYiwgeWVzLiAgSW4gZW1haWwgKGFuZCBlbWFpbCBpcyBhbiBlc3NlbnRpYWwgcGFy dCBvZiB0aGUgDQpyZWdpc3RyYXRpb24gcHJvY2VzcyksIG5vLg0KDQo+IE9wdGlvbiAxLiBCaXJs JiN4NEQ5OyYjeDE1RjtkaXJpbG1pJiN4MTVGOw0KPiAgb3INCj4gT3B0aW9uIDIuIEJpcmw/Pz8/ ZGlyaWxtaT8/DQoNCldlbGwsIHRoYXQncyB3aGF0IHRoZXkgbG9vayBsaWtlIGluIG15IGVtYWls IGNsaWVudC4gIEJvdGggYXJlIGlsbGVnaWJsZSwgDQpidXQgb25seSB0aGUgZmlyc3QgaXMgcmVj b25zdHJ1Y3RpYmxlLiAgSWYgd2Ugd2FudCB0byBrZWVwIHRoaW5ncyBsaWtlIHRoZQ0KYWJvdmUg dmVyc2lvbiBvZiBPcHRpb24gMiBvdXQgb2YgdGhlIHJlZ2lzdHJ5LCB3ZSBlaXRoZXIgbmVlZCB0 byBieXBhc3MNCmVtYWlsIGVudGlyZWx5LCBvciB3ZSBuZWVkIHRvIHN0aWNrIHdpdGggd2hhdCB3 ZSd2ZSBnb3QuDQoNCi0tDQpXaGF0IGhhcyBmb3VyIHBhaXJzIG9mIHBhbnRzLCBsaXZlcyAgICAg ICAgICAgICBKb2huIENvd2FuDQppbiBQaGlsYWRlbHBoaWEsIGFuZCBpdCBuZXZlciByYWlucyAg ICAgICAgICAgICBIWVBFUkxJTksgImh0dHA6Ly93d3cuY2NpbC5vcmcvfmNvd2FuImh0dHA6Ly93 d3cuY2NpbC5vcmcvfmNvd2FuDQpidXQgaXQgcG91cnM/ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBIWVBFUkxJTksgIm1haWx0bzpjb3dhbkBjY2lsLm9yZyJjb3dhbkBjY2lsLm9y Zw0KICAgICAgICAtLVJ1ZnVzIFQuIEZpcmVmbHkNCg0KDQoNCg0KDQotLSANCk1hcmsgDQoNCk5v IHZpcnVzIGZvdW5kIGluIHRoaXMgb3V0Z29pbmcgbWVzc2FnZS4NCkNoZWNrZWQgYnkgQVZHIEZy ZWUgRWRpdGlvbi4gDQpWZXJzaW9uOiA3LjUuNDYzIC8gVmlydXMgRGF0YWJhc2U6IDI2OS42LjEv Nzc2IC0gUmVsZWFzZSBEYXRlOiA0LzI1LzIwMDcgMTI6MTkgUE0NCiANCg== ------_=_NextPart_001_01C78882.AAF36B3B Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI4MDAuMTU4OSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxT UEFOIGNsYXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgDQpzaXplPTQ+SGksPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTcx MDYwOTA1LTI3MDQyMDA3PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9ND48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz01NzEwNjA5MDUtMjcw NDIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT00PlJlYWxpdHkgY2hl Y2s6PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTcxMDYwOTA1LTI3MDQy MDA3PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9ND48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz01NzEwNjA5MDUtMjcwNDIwMDc+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9ND5FbWFpbCANCmFjY2VzcyBjbGllbnRzIGFy ZW4ndCB0aGUgYmlnIHByb2JsZW0gLSBlbWFpbCBiYWNrYm9uZTwvRk9OVD48L1NQQU4+PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgDQpzaXplPTQ+aW5mcmFzdHJ1Y3R1cmUgaXMgc3RpbGwgZnJhZ21lbnRlZCwg Zmxha3ksIGFuZCBub3doZXJlIA0KbmVhcjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQpzaXplPTQ+dW5pdmVyc2FsbHkgVVRGLTggc2FmZS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz01NzEwNjA5MDUtMjcwNDIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0Kc2l6ZT00PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT00PkFsc28sIA0Kbm90IGV2ZXJ5IGNvbXB1dGVyIHVzZXIgKG9yIGV2ZW4gdGhlIHZhc3QgbWFq b3JpdHkpPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTcxMDYwOTA1LTI3 MDQyMDA3PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTQ+aGFwcGVuIA0KdG8g YmUgcHJpdmlsZWdlZCB0byBjb25zdGFudGx5IGhhdmUgdGhlIGxhdGVzdCBoYXJkd2FyZTwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT00PmFuZCANCnNvZnR3YXJlLjwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9NTcxMDYwOTA1LTI3MDQyMDA3PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9ND5IYXJvbGQncyA1MCB5ZWFycyAnaW50ZXJpbScga2VlcHMg bG9va2luZyBtb3JlIGFuZCANCm1vcmU8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz01NzEwNjA5MDUtMjcwNDIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K c2l6ZT00PnJlYWxpc3RpYyBhbmQgbGVzcyBhbmQgbGVzcyBsaWtlIHRoZSBoeXBlcmJvbGUgdGhh dCBJIA0Kb3JpZ2luYWxseTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTU3 MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT00PnJl YWQgDQppbnRvIGl0LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTU3MTA2 MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTQ+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTcxMDYwOTA1LTI3MDQy MDA3PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTQ+QW5kIA0KdGhlIElFVEYg cHJvY2VzcyAoZm9yIEFMTCBJRVRGIHdvcmtpbmcgZ3JvdXBzKSBkZXBlbmRzPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTcxMDYwOTA1LTI3MDQyMDA3PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9ND5jZW50cmFsbHkgb24gZW1haWwgYW5kIG9ubHkg bW9kZXN0bHkgb24gd2ViIA0KaW50ZXJmYWNlcy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz01NzEwNjA5MDUtMjcwNDIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIA0Kc2l6ZT00PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNz PTU3MTA2MDkwNS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXpl PTQ+Q2hlZXJzLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTU3MTA2MDkw NS0yNzA0MjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT00Pi0gDQpJcmE8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz01NzEwNjA5MDUtMjcwNDIwMDc+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT00PjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JcmEgTWNEb25hbGQgKE11c2ljaWFuIC8gU29m dHdhcmUgQXJjaGl0ZWN0KTxCUj5DaGFpciAtIExpbnV4IA0KRm91bmRhdGlvbiBPcGVuIFByaW50 aW5nIFdHPEJSPkJsdWUgUm9vZiBNdXNpYyAvIEhpZ2ggTm9ydGggSW5jPEJSPlBPIEJveCANCjIy MSZuYnNwOyBHcmFuZCBNYXJhaXMsIE1JJm5ic3A7IDQ5ODM5PEJSPnBob25lOiArMS05MDYtNDk0 LTI0MzQ8QlI+ZW1haWw6IA0KaW1jZG9uYWxkQHNoYXJwbGFicy5jb208L0ZPTlQ+IDwvRElWPg0K PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQg ZmFjZT1UYWhvbWEgDQpzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJv bTo8L0I+IE1hcmsgRGF2aXMgDQpbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXTxC Uj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEFwcmlsIDI2LCAyMDA3IA0KNDoyNyBQTTxCUj48Qj5U bzo8L0I+IEpvaG4gQ293YW48QlI+PEI+Q2M6PC9CPiBGcmFuayBFbGxlcm1hbm47IE1pY2hhZWwg RXZlcnNvbjsgDQpsdHJ1QGxpc3RzLmlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogW0x0 cnVdIFJlOiBUcmFuc2xpdGVyYXRpb24gb2YgDQpyZWZlcmVuY2UgdGl0bGVzPEJSPjxCUj48L0ZP TlQ+PC9ESVY+VHJ1ZSwgZW1haWwgaXMgdGhlIGJpZyBob2xkb3V0LCBub3RhYmx5IA0KaG90bWFp bCBhbmQgRXVkb3JhLiBUaGVyZSBhcmUgdHdvIG90aGVyIHBvc3NpYmlsaXRpZXMgdGhhdCBwZW9w bGUgbWVudGlvbmVkLjxCUj4NCjxPTD4NCiAgPExJPlVzZSBlbWFpbCwgYnV0IHJlcXVpcmUgYW55 IGZvcm1zIHdpdGggVVRGLTggdG8gYmUgYXR0YWNobWVudHMsIG5vdCBpbmxpbmUuDQogIDxMST5V c2UgdGhlIGN1cnJlbnQgZm9ybWF0IGluIHN1Ym1pc3Npb24gZm9ybXMsIGJ1dCBoYXZlIHRoZSBy ZXN1bHQgYmUgDQogIGNvbnZlcnRlZCB0byBVVEYtOCwgZWl0aGVyIGJlZm9yZSBzZW5kaW5nIHRv IElBTkEgKGluIGFuIGF0dGFjaG1lbnQpLCBvciBieSANCiAgSUFOQSBiZWZvcmUgcG9zdGluZy4g PEJSPjwvTEk+PC9PTD4mbmJzcDtJJ2xsIGNjIE1pY2hhZWwsIHNpbmNlIGhlIGlzIGludm9sdmVk IA0KaW4gdGhpcy48QlI+PEJSPk1hcms8QlI+PEJSPkJUVywgSSdtIG5vdCBwdXNoaW5nIHN0cm9u Z2x5IGZvciB0aGlzLCBzaW5jZSB0aGUgDQpjdXJyZW50IHNpdHVhdGlvbiBpcyB3b3JrYWJsZSwg dGhvdWdoIG5vdCBub3Qgb3B0aW1hbC4gT25lIGV4YW1wbGUgb2Ygd2h5IGl0IGlzIA0Kbm90IG9w dGltYWwgaXMgdGhhdCBZYWhvbywgR29vZ2xlLCBldGMuIGRvbid0IHRoaW5rIHRoYXQgdGhlIGxh bmd1YWdlIHN1YnRhZyANCnJlZ2lzdHJ5IGNvbnRhaW5zIHdvcmRzIGxpa2UgQm9rbcOlbC4gVHJ5 IGEgR29vZ2xlIG9yIFlhaG9vIHNlYXJjaCBmb3IgDQo8QlI+PEJSPiZuYnNwOyBpYW5hIGxhbmd1 YWdlLXN1YnRhZy1yZWdpc3RyeSBCb2ttw6VsPEJSPjxCUj4NCjxESVY+PFNQQU4gY2xhc3M9Z21h aWxfcXVvdGU+T24gNC8yNi8wNywgPEIgY2xhc3M9Z21haWxfc2VuZGVybmFtZT5Kb2huIA0KQ293 YW48L0I+ICZsdDs8QSBocmVmPSJtYWlsdG86Y293YW5AY2NpbC5vcmciPmNvd2FuQGNjaWwub3Jn PC9BPiZndDsgDQp3cm90ZTo8L1NQQU4+DQo8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSAN CnN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHQgMHB0IDBwdCAwLjhleDsgQk9S REVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkIj5NYXJrIA0KICBEYXZpcyBzY3Jp cHNpdDo8QlI+PEJSPiZndDsgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnkgcXVlc3Rpb24gdGhh dCBVVEYtOCBpcyANCiAgc3VmZmljaWVudGx5IHVuaXZlcnNhbDxCUj4mZ3Q7IHRoYXQgdGhlIHZh c3QgbWFqb3JpdHkgb2YgcGVvcGxlIGNhbiBoYW5kbGUgaXQgDQogIHdpdGhvdXQgYW55IHByb2Js ZW0gYXQ8QlI+Jmd0OyBhbGwsPEJSPjxCUj5PbiB0aGUgV2ViLCB5ZXMuJm5ic3A7Jm5ic3A7SW4g DQogIGVtYWlsIChhbmQgZW1haWwgaXMgYW4gZXNzZW50aWFsIHBhcnQgb2YgdGhlIDxCUj5yZWdp c3RyYXRpb24gcHJvY2VzcyksIA0KICBuby48QlI+PEJSPiZndDsgT3B0aW9uIDEuIA0KICBCaXJs JmFtcDsjeDREOTsmYW1wOyN4MTVGO2RpcmlsbWkmYW1wOyN4MTVGOzxCUj4mZ3Q7Jm5ic3A7Jm5i c3A7b3I8QlI+Jmd0OyANCiAgT3B0aW9uIDIuIEJpcmw/Pz8/ZGlyaWxtaT8/PEJSPjxCUj5XZWxs LCB0aGF0J3Mgd2hhdCB0aGV5IGxvb2sgbGlrZSBpbiBteSANCiAgZW1haWwgY2xpZW50LiZuYnNw OyZuYnNwO0JvdGggYXJlIGlsbGVnaWJsZSwgPEJSPmJ1dCBvbmx5IHRoZSBmaXJzdCBpcyANCiAg cmVjb25zdHJ1Y3RpYmxlLiZuYnNwOyZuYnNwO0lmIHdlIHdhbnQgdG8ga2VlcCB0aGluZ3MgbGlr ZSB0aGU8QlI+YWJvdmUgDQogIHZlcnNpb24gb2YgT3B0aW9uIDIgb3V0IG9mIHRoZSByZWdpc3Ry eSwgd2UgZWl0aGVyIG5lZWQgdG8gYnlwYXNzPEJSPmVtYWlsIA0KICBlbnRpcmVseSwgb3Igd2Ug bmVlZCB0byBzdGljayB3aXRoIHdoYXQgd2UndmUgZ290LjxCUj48QlI+LS08QlI+V2hhdCBoYXMg Zm91ciANCiAgcGFpcnMgb2YgcGFudHMsIA0KICBsaXZlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgSm9o biBDb3dhbjxCUj5pbiBQaGlsYWRlbHBoaWEsIGFuZCBpdCBuZXZlciANCiAgcmFpbnMmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIDxBIGhyZWY9Imh0dHA6Ly93d3cuY2NpbC5vcmcvfmNvd2FuIj5odHRwOi8v d3d3LmNjaWwub3JnL35jb3dhbjwvQT48QlI+YnV0IGl0IA0KICBwb3Vycz8mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxBIA0KICBocmVmPSJtYWlsdG86Y293YW5AY2NpbC5v cmciPmNvd2FuQGNjaWwub3JnPC9BPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstLVJ1ZnVzIA0KICBULiBGaXJlZmx5PEJSPjwvQkxPQ0tRVU9URT48 L0RJVj48QlI+PEJSIGNsZWFyPWFsbD48QlI+LS0gPEJSPk1hcmsgDQo8L0JPRFk+PC9IVE1MPg0K PEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+Tm8gdmlydXMgZm91bmQgaW4gdGhpcyBvdXRnb2luZyBt ZXNzYWdlLjxCUj4NCkNoZWNrZWQgYnkgQVZHIEZyZWUgRWRpdGlvbi48QlI+DQpWZXJzaW9uOiA3 LjUuNDYzIC8gVmlydXMgRGF0YWJhc2U6IDI2OS42LjEvNzc2IC0gUmVsZWFzZSBEYXRlOiA0LzI1 LzIwMDcgMTI6MTkgUE08QlI+DQo8L0ZPTlQ+IDwvUD4NCg== ------_=_NextPart_001_01C78882.AAF36B3B-- --===============0115834773== 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 --===============0115834773==-- From ltru-bounces@ietf.org Fri Apr 27 02:28: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 1HhJvz-0006v0-MP; Fri, 27 Apr 2007 02:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJvy-0006uv-KZ for ltru@ietf.org; Fri, 27 Apr 2007 02:27:58 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJvx-0006ao-AR for ltru@ietf.org; Fri, 27 Apr 2007 02:27:58 -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 <20070427062756.LUTM13783.mta13.adelphia.net@DGBP7M81> for ; Fri, 27 Apr 2007 02:27:56 -0400 Message-ID: <002501c78895$31a5e9d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 26 Apr 2007 23: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ltru] Re: Archival of registration forms X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 1) Small modification to 4646bis, section 3.5, to make clear that IANA > does not receive the form (and therefore does not archive it) but only > the record (which will go "as is" in the registry). If I understand > well, that's Doug Ewell's opinion. I don't recall having stated an opinion, and I certainly don't "hate" the idea of sending the registration forms to IANA as Frank implied. I did say that Michael and I had been sending only the new or changed record, and that this was in accordance with some (though not all) of RFC 4646, but not necessarily that that was the best option. In fact, one advantage to having the registration forms is that proposers will be more willing to have lengthy bibliographic citations appear there, instead of filling the Registry with them. My main concern is that the set of archived registration forms must match *exactly* the set of subtags registered by user request since the Registry went live in October 2005. That will require going back and reconstructing some forms. To do otherwise is essentially to have two conflicting resources, the Registry and something else, just like we had in the RFC 3066 era, and *that* is something I would hate. > 2) Same as 1) *plus* an obligation for the LSR or the submitter to > post the *final* form on ietf-languages so it is archived and > accessible (without involving IANA). > > 3) Modification to 4646bis, section 3.3 and 3.5 to make crystal-clear > that IANA receives the *form*, not just the record and make it > available, both in the registry and in a to-be-determined repository. > (Apparently the way it was supposed to work in RFC 3066). > > Opinions? In decreasing order of preference: 3, 1, 2. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 28 14:26: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 1HhrcQ-0004lv-SM; Sat, 28 Apr 2007 14:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhrcP-0004lp-PC for ltru@ietf.org; Sat, 28 Apr 2007 14:26:01 -0400 Received: from smtp801.mail.ird.yahoo.com ([217.146.188.61]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhrcO-0006Of-6a for ltru@ietf.org; Sat, 28 Apr 2007 14:26:01 -0400 Received: (qmail 3296 invoked from network); 28 Apr 2007 18:25:59 -0000 Received: from unknown (HELO DELL3) (brian.silver@btinternet.com@81.156.78.228 with login) by smtp801.mail.ird.yahoo.com with SMTP; 28 Apr 2007 18:25:59 -0000 X-YMail-OSG: UwZHv90VM1naWqYX.0qZp61l8OZ.uoewNPs9IfH1a0PeXNFMQJZ._gWzqWBaY4TZKIBZ7KBpRA-- Message-ID: <000801c789c2$ac16bae0$0201a8c0@DELL3> From: "Stephen Silver" To: "LTRU Working Group" Date: Sat, 28 Apr 2007 19:25:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ltru] modification of Prefix fields X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 current draft of 4646bis disagrees with itself on the question of whether 'Prefix' fields can be modified. In section 3.1.7, it says: The field of type 'Prefix' MUST NOT be removed from any record. The field-body for this type of field MUST NOT be modified. But in section 3.4, bullet 4, it says: 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. -- Stephen Silver _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 29 15: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 1HiEge-0004m1-5z; Sun, 29 Apr 2007 15:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiEgc-0004ls-7k for ltru@ietf.org; Sun, 29 Apr 2007 15:03:54 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiEga-0004kK-V2 for ltru@ietf.org; Sun, 29 Apr 2007 15:03:54 -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 <20070429190352.HZEL16517.mta11.adelphia.net@DGBP7M81> for ; Sun, 29 Apr 2007 15:03:52 -0400 Message-ID: <003c01c78a91$205ff8c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 29 Apr 2007 12:03: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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: modification of Prefix fields X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephen Silver wrote: > The current draft of 4646bis disagrees with itself on the question of > whether 'Prefix' fields can be modified. > > In section 3.1.7, it says: > > The field of type 'Prefix' MUST NOT be removed from any record. > The field-body for this type of field MUST NOT be modified. > > But in section 3.4, bullet 4, it says: > > 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. Good catch. This wording was carried over from RFC 4646, where we in LTRU started out thinking that no modifications should be allowed, and then came to understand the potential for multiple prefixes or broadening changes. We need to change the first passage to match the second. -- 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 Apr 30 12:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYW7-0004nP-4S; Mon, 30 Apr 2007 12:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYW6-0004nK-40 for ltru@ietf.org; Mon, 30 Apr 2007 12:14:22 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYW4-0006x9-N4 for ltru@ietf.org; Mon, 30 Apr 2007 12:14:22 -0400 Received: from [10.72.72.38] (snvvpn1-10-72-72-c38.corp.yahoo.com [10.72.72.38]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3UGEBtQ011578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 09:14:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=advduoqFGlbGl6Fa3gNE0YDtW4xWSn2rqcflVk+WXN20Z682qagGZXpK+f/ox9rN Message-ID: <463615D3.5020908@yahoo-inc.com> Date: Mon, 30 Apr 2007 09:14:11 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: modification of Prefix fields References: <003c01c78a91$205ff8c0$6401a8c0@DGBP7M81> In-Reply-To: <003c01c78a91$205ff8c0$6401a8c0@DGBP7M81> 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 I changed the first instance to read: 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). Addison Doug Ewell wrote: > Stephen Silver wrote: > >> The current draft of 4646bis disagrees with itself on the question of >> whether 'Prefix' fields can be modified. >> >> In section 3.1.7, it says: >> >> The field of type 'Prefix' MUST NOT be removed from any record. >> The field-body for this type of field MUST NOT be modified. >> >> But in section 3.4, bullet 4, it says: >> >> 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. > > Good catch. This wording was carried over from RFC 4646, where we in > LTRU started out thinking that no modifications should be allowed, and > then came to understand the potential for multiple prefixes or > broadening changes. We need to change the first passage to match the > second. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 30 12:31: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 1HiYmC-0006ds-Fo; Mon, 30 Apr 2007 12:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYmB-0006dn-KI for ltru@ietf.org; Mon, 30 Apr 2007 12:30:59 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYmA-00013Z-5D for ltru@ietf.org; Mon, 30 Apr 2007 12:30:59 -0400 Received: from [10.72.72.38] (snvvpn1-10-72-72-c38.corp.yahoo.com [10.72.72.38]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3UGUqLM013250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 09:30:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=EGT/sBzIqqYJ+4NNhkEtxVbqgVBIpUOn4nXa6fxKvhqXiyNPkegkY+Yvqpic23iD Message-ID: <463619BB.8000405@yahoo-inc.com> Date: Mon, 30 Apr 2007 09:30:51 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Archival of registration forms References: <002501c78895$31a5e9d0$6401a8c0@DGBP7M81> In-Reply-To: <002501c78895$31a5e9d0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 To address at least part of this problem (the appearance of the final form on-list), I have made the following change in section 3.5, from this: -- The applicant is free to modify a rejected application with additional information and submit it again; this restarts the two- week comment period. -- To this: Sometimes the requested record 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 request, 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. Addison Doug Ewell wrote: > Stephane Bortzmeyer wrote: > >> 1) Small modification to 4646bis, section 3.5, to make clear that IANA >> does not receive the form (and therefore does not archive it) but only >> the record (which will go "as is" in the registry). If I understand >> well, that's Doug Ewell's opinion. > > I don't recall having stated an opinion, and I certainly don't "hate" > the idea of sending the registration forms to IANA as Frank implied. I > did say that Michael and I had been sending only the new or changed > record, and that this was in accordance with some (though not all) of > RFC 4646, but not necessarily that that was the best option. > > In fact, one advantage to having the registration forms is that > proposers will be more willing to have lengthy bibliographic citations > appear there, instead of filling the Registry with them. > > My main concern is that the set of archived registration forms must > match *exactly* the set of subtags registered by user request since the > Registry went live in October 2005. That will require going back and > reconstructing some forms. To do otherwise is essentially to have two > conflicting resources, the Registry and something else, just like we had > in the RFC 3066 era, and *that* is something I would hate. > >> 2) Same as 1) *plus* an obligation for the LSR or the submitter to >> post the *final* form on ietf-languages so it is archived and >> accessible (without involving IANA). >> >> 3) Modification to 4646bis, section 3.3 and 3.5 to make crystal-clear >> that IANA receives the *form*, not just the record and make it >> available, both in the registry and in a to-be-determined repository. >> (Apparently the way it was supposed to work in RFC 3066). >> >> Opinions? > > In decreasing order of preference: 3, 1, 2. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 30 12:42: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 1HiYxF-0004o7-Sy; Mon, 30 Apr 2007 12:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYxE-0004ni-B2; Mon, 30 Apr 2007 12:42:24 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYx6-0002Ta-SA; Mon, 30 Apr 2007 12:42:24 -0400 Received: from [10.72.72.38] (snvvpn1-10-72-72-c38.corp.yahoo.com [10.72.72.38]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3UGg4QK014490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 09:42:04 -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:content-type; b=Ya8uzvVwZ46U7xCHacszShJpShFa9Dk+1A9X6x0eCdQBgLVeJv/TB4UysWHCJTeM Message-ID: <46361C5B.4080106@yahoo-inc.com> Date: Mon, 30 Apr 2007 09:42:03 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------080700050806030009050507" X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1d92b4bbfb1e0304211fd694235e4b20 Cc: 'LTRU Working Group' Subject: [Ltru] submission: draft-ietf-ltru-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 This is a multi-part message in MIME format. --------------080700050806030009050507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Editors, Please find attached in text format, draft-05 of draft-ietf-ltru-4646bis. Best Regards, Addison (for the editors) -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. --------------080700050806030009050507 Content-Type: text/plain; name="draft-ietf-ltru-4646bis-05.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ltru-4646bis-05.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWFob28hIEluYy4NCk9ic29sZXRl czogNDY0NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4g RGF2aXMsIEVkLg0KSW50ZW5kZWQgc3RhdHVzOiBCZXN0IEN1cnJlbnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlDQpQcmFjdGljZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMzAsIDIwMDcNCkV4 cGlyZXM6IE5vdmVtYmVyIDEsIDIwMDcNCg0KDQogICAgICAgICAgICAgICAgICAgICBUYWdz IGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMDUNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2Vu dHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMg b2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBk aXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJl IHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJD UCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0 aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0K ICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQog ICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz IHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg IndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0 Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQg U2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBOb3ZlbWJlciAxLCAyMDA3Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENv cHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3 ICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQpB YnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgc3RydWN0dXJlLCBj b250ZW50LCBjb25zdHJ1Y3Rpb24sIGFuZA0KICAgc2VtYW50aWNzIG9mIGxhbmd1YWdlIHRh Z3MgZm9yIHVzZSBpbiBjYXNlcyB3aGVyZSBpdCBpcyBkZXNpcmFibGUgdG8NCiAgIGluZGlj YXRlIHRoZSBsYW5ndWFnZSB1c2VkIGluIGFuIGluZm9ybWF0aW9uIG9iamVjdC4gIEl0IGFs c28NCiAgIGRlc2NyaWJlcyBob3cgdG8gcmVnaXN0ZXIgdmFsdWVzIGZvciB1c2UgaW4gbGFu Z3VhZ2UgdGFncyBhbmQgdGhlDQogICBjcmVhdGlvbiBvZiB1c2VyLWRlZmluZWQgZXh0ZW5z aW9ucyBmb3IgcHJpdmF0ZSBpbnRlcmNoYW5nZS4NCg0KDQpUYWJsZSBvZiBDb250ZW50cw0K DQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDIuICBUaGUgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjEuICBT eW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA1DQogICAgIDIuMi4gIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnBy ZXRhdGlvbiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgICAgICAyLjIuMS4gIFByaW1hcnkgTGFu Z3VhZ2UgU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAg IDIuMi4yLiAgRXh0ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDExDQogICAgICAgMi4yLjMuICBTY3JpcHQgU3VidGFnICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgICAgICAyLjIuNC4gIFJlZ2lv biBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0K ICAgICAgIDIuMi41LiAgVmFyaWFudCBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE1DQogICAgICAgMi4yLjYuICBFeHRlbnNpb24gU3VidGFncyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgICAyLjIuNy4g IFByaXZhdGUgVXNlIFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNw0KICAgICAgIDIuMi44LiAgR3JhbmRmYXRoZXJlZCBSZWdpc3RyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAgICAgMi4yLjkuICBDbGFzc2VzIG9mIENv bmZvcm1hbmNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgIDMuICBS ZWdpc3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyMA0KICAgICAzLjEuICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3Vi dGFnIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIDIwDQogICAgICAgMy4xLjEuICBGaWxlIEZv cm1hdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjANCiAg ICAgICAzLjEuMi4gIFJlY29yZCBEZWZpbml0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyMQ0KICAgICAgIDMuMS4zLiAgU3VidGFnIGFuZCBUYWcgRmllbGRz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICAgICAgMy4xLjQuICBE ZXNjcmlwdGlvbiBGaWVsZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjQNCiAgICAgICAzLjEuNS4gIERlcHJlY2F0ZWQgRmllbGQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0KICAgICAgIDMuMS42LiAgUHJlZmVycmVkLVZhbHVl IEZpZWxkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgICAgMy4x LjcuICBQcmVmaXggRmllbGQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjYNCiAgICAgICAzLjEuOC4gIENvbW1lbnRzIEZpZWxkIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNw0KICAgICAgIDMuMS45LiAgU3VwcHJlc3Mt U2NyaXB0IEZpZWxkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DQogICAg IDMuMi4gIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjcNCiAgICAgMy4zLiAgTWFpbnRlbmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0KICAgICAzLjQuICBTdGFiaWxp dHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5 DQogICAgIDMuNS4gIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUgZm9yIFN1YnRhZ3MgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMzMNCiAgICAgMy42LiAgUG9zc2liaWxpdGllcyBmb3IgUmVn aXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNw0KICAgICAzLjcuICBF eHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM5DQogICAgIDMuOC4gIFVwZGF0ZSBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDINCiAgIDQuICBGb3JtYXRpb24gYW5kIFByb2Nl c3Npbmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mw0KICAgICA0 LjEuICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDQzDQogICAgIDQuMi4gIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcNCiAgICAgNC4zLiAgTGVuZ3RoIENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0OA0K ICAgICAgIDQuMy4xLiAgV29ya2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNpemVzICAuIC4g LiAuIC4gLiAuIC4gLiAuIDQ4DQogICAgICAgNC4zLjIuICBUcnVuY2F0aW9uIG9mIExhbmd1 YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDkNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAg ICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgICA0LjQuICBDYW5v bmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDUwDQogICAgIDQuNS4gIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdz IC4gLiAuIC4gLiAuIC4gLiAuIC4gNTINCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Mw0KICAgICA1LjEu ICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUzDQogICAgIDUuMi4gIEV4dGVuc2lvbnMgUmVnaXN0cnkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTMNCiAgIDYuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NQ0KICAg Ny4gIENoYXJhY3RlciBTZXQgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDU2DQogICA4LiAgQ2hhbmdlcyBmcm9tIFJGQyA0NjQ2ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcNCiAgIDkuICBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2 MA0KICAgICA5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDYwDQogICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjENCiAgIEFwcGVuZGl4 IEEuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA2Mw0KICAgQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKElu Zm9ybWF0aXZlKSAuIC4gLiAuIC4gLiAuIDY0DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcNCiAgIElu dGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAu IC4gLiAuIC4gLiA2OA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEh1bWFu IGJlaW5ncyBvbiBvdXIgcGxhbmV0IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBu dW1iZXIgb2YNCiAgIGxhbmd1YWdlcy4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IG9u ZSB3b3VsZCB3YW50IHRvIGlkZW50aWZ5IHRoZQ0KICAgbGFuZ3VhZ2UgdXNlZCB3aGVuIHBy ZXNlbnRpbmcgb3IgcmVxdWVzdGluZyBpbmZvcm1hdGlvbi4NCg0KICAgQSB1c2VyJ3MgbGFu Z3VhZ2UgcHJlZmVyZW5jZXMgb2Z0ZW4gbmVlZCB0byBiZSBpZGVudGlmaWVkIHNvIHRoYXQN CiAgIGFwcHJvcHJpYXRlIHByb2Nlc3NpbmcgY2FuIGJlIGFwcGxpZWQuICBGb3IgZXhhbXBs ZSwgdGhlIHVzZXIncw0KICAgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgaW4gYSBXZWIgYnJvd3Nl ciBjYW4gYmUgdXNlZCB0byBzZWxlY3QgV2ViIHBhZ2VzDQogICBhcHByb3ByaWF0ZWx5LiAg TGFuZ3VhZ2UgcHJlZmVyZW5jZXMgY2FuIGFsc28gYmUgdXNlZCB0byBzZWxlY3QgYW1vbmcN CiAgIHRvb2xzIChzdWNoIGFzIGRpY3Rpb25hcmllcykgdG8gYXNzaXN0IGluIHRoZSBwcm9j ZXNzaW5nIG9yDQogICB1bmRlcnN0YW5kaW5nIG9mIGNvbnRlbnQgaW4gZGlmZmVyZW50IGxh bmd1YWdlcy4NCg0KICAgSW4gYWRkaXRpb24sIGtub3dsZWRnZSBhYm91dCB0aGUgcGFydGlj dWxhciBsYW5ndWFnZSB1c2VkIGJ5IHNvbWUNCiAgIHBpZWNlIG9mIGluZm9ybWF0aW9uIGNv bnRlbnQgbWlnaHQgYmUgdXNlZnVsIG9yIGV2ZW4gcmVxdWlyZWQgYnkgc29tZQ0KICAgdHlw ZXMgb2YgcHJvY2Vzc2luZzsgZm9yIGV4YW1wbGUsIHNwZWxsLWNoZWNraW5nLCBjb21wdXRl ci0NCiAgIHN5bnRoZXNpemVkIHNwZWVjaCwgQnJhaWxsZSB0cmFuc2NyaXB0aW9uLCBvciBo aWdoLXF1YWxpdHkgcHJpbnQNCiAgIHJlbmRlcmluZ3MuDQoNCiAgIE9uZSBtZWFucyBvZiBp bmRpY2F0aW5nIHRoZSBsYW5ndWFnZSB1c2VkIGlzIGJ5IGxhYmVsaW5nIHRoZQ0KICAgaW5m b3JtYXRpb24gY29udGVudCB3aXRoIGFuIGlkZW50aWZpZXIgb3IgInRhZyIuICBUaGVzZSB0 YWdzIGNhbiBiZQ0KICAgdXNlZCB0byBzcGVjaWZ5IHVzZXIgcHJlZmVyZW5jZXMgd2hlbiBz ZWxlY3RpbmcgaW5mb3JtYXRpb24gY29udGVudCwNCiAgIG9yIGZvciBsYWJlbGluZyBhZGRp dGlvbmFsIGF0dHJpYnV0ZXMgb2YgY29udGVudCBhbmQgYXNzb2NpYXRlZA0KICAgcmVzb3Vy Y2VzLg0KDQogICBUYWdzIGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5kaWNhdGUgYWRkaXRpb25h bCBsYW5ndWFnZSBhdHRyaWJ1dGVzIG9mDQogICBjb250ZW50LiAgRm9yIGV4YW1wbGUsIGlu ZGljYXRpbmcgc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQogICBkaWFsZWN0LCB3 cml0aW5nIHN5c3RlbSwgb3Igb3J0aG9ncmFwaHkgdXNlZCBpbiBhIGRvY3VtZW50IG9yDQog ICByZXNvdXJjZSBtYXkgZW5hYmxlIHRoZSB1c2VyIHRvIG9idGFpbiBpbmZvcm1hdGlvbiBp biBhIGZvcm0gdGhhdA0KICAgdGhleSBjYW4gdW5kZXJzdGFuZCwgb3IgaXQgY2FuIGJlIGlt cG9ydGFudCBpbiBwcm9jZXNzaW5nIG9yDQogICByZW5kZXJpbmcgdGhlIGdpdmVuIGNvbnRl bnQgaW50byBhbiBhcHByb3ByaWF0ZSBmb3JtIG9yIHN0eWxlLg0KDQogICBUaGlzIGRvY3Vt ZW50IHNwZWNpZmllcyBhIHBhcnRpY3VsYXIgaWRlbnRpZmllciBtZWNoYW5pc20gKHRoZQ0K ICAgbGFuZ3VhZ2UgdGFnKSBhbmQgYSByZWdpc3RyYXRpb24gZnVuY3Rpb24gZm9yIHZhbHVl cyB0byBiZSB1c2VkIHRvDQogICBmb3JtIHRhZ3MuICBJdCBhbHNvIGRlZmluZXMgYSBtZWNo YW5pc20gZm9yIHByaXZhdGUgdXNlIHZhbHVlcyBhbmQNCiAgIGZ1dHVyZSBleHRlbnNpb24u DQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVwbGFjZXMgW1JGQzQ2NDZdLCB3aGljaCByZXBsYWNl ZCBbUkZDMzA2Nl0gYW5kIGl0cw0KICAgcHJlZGVjZXNzb3IgW1JGQzE3NjZdLiAgRm9yIGEg bGlzdCBvZiBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQsIHNlZQ0KICAgU2VjdGlvbiA4Lg0K DQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01N RU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K Mi4gIFRoZSBMYW5ndWFnZSBUYWcNCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgdXNlZCB0byBo ZWxwIGlkZW50aWZ5IGxhbmd1YWdlcywgd2hldGhlciBzcG9rZW4sDQogICB3cml0dGVuLCBz aWduZWQsIG9yIG90aGVyd2lzZSBzaWduYWxlZCwgZm9yIHRoZSBwdXJwb3NlIG9mDQogICBj b21tdW5pY2F0aW9uLiAgVGhpcyBpbmNsdWRlcyBjb25zdHJ1Y3RlZCBhbmQgYXJ0aWZpY2lh bCBsYW5ndWFnZXMsDQogICBidXQgZXhjbHVkZXMgbGFuZ3VhZ2VzIG5vdCBpbnRlbmRlZCBw cmltYXJpbHkgZm9yIGh1bWFuDQogICBjb21tdW5pY2F0aW9uLCBzdWNoIGFzIHByb2dyYW1t aW5nIGxhbmd1YWdlcy4NCg0KMi4xLiAgU3ludGF4DQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcg aXMgY29tcG9zZWQgb2Ygb25lIG9yIG1vcmUgcGFydHMsIGtub3duIGFzDQogICAic3VidGFn cyIuICBFYWNoIHN1YnRhZyBjb25zaXN0cyBvZiBhIHNlcXVlbmNlIG9mIGFscGhhbnVtZXJp Yw0KICAgY2hhcmFjdGVycy4gIFN1YnRhZ3MgYXJlIGRpc3Rpbmd1aXNoZWQgYW5kIHNlcGFy YXRlZCBmcm9tIG9uZSBhbm90aGVyDQogICBieSBhIGh5cGhlbiAoIi0iLCBBQk5GIFtSRkM0 MjM0XSAleDJEKS4gIEEgbGFuZ3VhZ2UgdGFnIGNvbnNpc3RzIG9mIGENCiAgICJwcmltYXJ5 IGxhbmd1YWdlIiBzdWJ0YWcgYW5kIGEgKHBvc3NpYmx5IGVtcHR5KSBzZXJpZXMgb2Ygc3Vi c2VxdWVudA0KICAgc3VidGFncywgZWFjaCBvZiB3aGljaCByZWZpbmVzIG9yIG5hcnJvd3Mg dGhlIHJhbmdlIG9mIGxhbmd1YWdlcw0KICAgaWRlbnRpZmllZCBieSB0aGUgb3ZlcmFsbCB0 YWcuDQoNCiAgIFVzdWFsbHksIGVhY2ggdHlwZSBvZiBzdWJ0YWcgaXMgZGlzdGluZ3Vpc2hl ZCBieSBsZW5ndGgsIHBvc2l0aW9uIGluDQogICB0aGUgdGFnLCBhbmQgY29udGVudDogc3Vi dGFncyBjYW4gYmUgcmVjb2duaXplZCBzb2xlbHkgYnkgdGhlc2UNCiAgIGZlYXR1cmVzLiAg VGhlIG9ubHkgZXhjZXB0aW9uIHRvIHRoaXMgaXMgYSBmaXhlZCBsaXN0IG9mDQogICBncmFu ZGZhdGhlcmVkIHRhZ3MgcmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NiBbUkZDMzA2Nl0uICBU aGlzIG1ha2VzDQogICBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdCBj YW4gZXh0cmFjdCBhbmQgYXNzaWduIHNvbWUNCiAgIHNlbWFudGljIGluZm9ybWF0aW9uIHRv IHRoZSBzdWJ0YWdzLCBldmVuIGlmIHRoZSBzcGVjaWZpYyBzdWJ0YWcNCiAgIHZhbHVlcyBh cmUgbm90IHJlY29nbml6ZWQuICBUaHVzLCBhIHBhcnNlciBuZWVkIG5vdCBoYXZlIGFuIHVw LXRvLQ0KICAgZGF0ZSBjb3B5IChvciBhbnkgY29weSBhdCBhbGwpIG9mIHRoZSBzdWJ0YWcg cmVnaXN0cnkgdG8gcGVyZm9ybSBtb3N0DQogICBzZWFyY2hpbmcgYW5kIG1hdGNoaW5nIG9w ZXJhdGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcg ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAg IFRoZSBzeW50YXggb2YgdGhlIGxhbmd1YWdlIHRhZyBpbiBBQk5GIFtSRkM0MjM0XSBpczoN Cg0KICAgTGFuZ3VhZ2UtVGFnICA9IGxhbmd0YWcNCiAgICAgICAgICAgICAgICAgLyBwcml2 YXRldXNlICAgICAgICAgICAgIDsgcHJpdmF0ZSB1c2UgdGFnDQogICAgICAgICAgICAgICAg IC8gaXJyZWd1bGFyICAgICAgICAgICAgICA7IHRhZ3MgZ3JhbmRmYXRoZXJlZCBieSBydWxl DQoNCiAgIGxhbmd0YWcgICAgICAgPSAobGFuZ3VhZ2UNCiAgICAgICAgICAgICAgICAgICAg WyItIiBzY3JpcHRdDQogICAgICAgICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAgICAg ICAgICAgICAgICAgICAqKCItIiB2YXJpYW50KQ0KICAgICAgICAgICAgICAgICAgICAqKCIt IiBleHRlbnNpb24pDQogICAgICAgICAgICAgICAgICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQoN CiAgIGxhbmd1YWdlICAgICAgPSAoMiozQUxQSEEgWyBleHRsYW5nIF0pIDsgc2hvcnRlc3Qg SVNPIDYzOSBjb2RlDQogICAgICAgICAgICAgICAgIC8gNEFMUEhBICAgICAgICAgICAgICAg ICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlDQogICAgICAgICAgICAgICAgIC8gNSo4QUxQ SEEgICAgICAgICAgICAgICA7IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnDQoNCiAgIGV4 dGxhbmcgICAgICAgPSAqMygiLSIgM0FMUEhBKSAgICAgICAgIDsgc3BlY2lmaWMgSVNPIDYz OS0zIGNvZGVzDQoNCiAgIHNjcmlwdCAgICAgICAgPSA0QUxQSEEgICAgICAgICAgICAgICAg IDsgSVNPIDE1OTI0IGNvZGUNCg0KICAgcmVnaW9uICAgICAgICA9IDJBTFBIQSAgICAgICAg ICAgICAgICAgOyBJU08gMzE2NiBjb2RlDQogICAgICAgICAgICAgICAgIC8gM0RJR0lUICAg ICAgICAgICAgICAgICA7IFVOIE0uNDkgY29kZQ0KDQogICB2YXJpYW50ICAgICAgID0gNSo4 YWxwaGFudW0gICAgICAgICAgICA7IHJlZ2lzdGVyZWQgdmFyaWFudHMNCiAgICAgICAgICAg ICAgICAgLyAoRElHSVQgM2FscGhhbnVtKQ0KDQogICBleHRlbnNpb24gICAgID0gc2luZ2xl dG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KDQogICBzaW5nbGV0b24gICAgID0gJXg0MS01 NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lUDQogICAgICAgICAgICAg ICAgIDsgImEiLSJ3IiAvICJ5Ii0ieiIgLyAiQSItIlciIC8gIlkiLSJaIiAvICIwIi0iOSIN CiAgICAgICAgICAgICAgICAgOyBTaW5nbGUgYWxwaGFudW1lcmljcw0KICAgICAgICAgICAg ICAgICA7ICJ4IiBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UNCg0KICAgcHJpdmF0ZXVz ZSAgICA9ICJ4IiAxKigiLSIgKDEqOGFscGhhbnVtKSkNCg0KICAgaXJyZWd1bGFyICAgICA9 ICJlbi1HQi1vZWQiIC8gImktYW1pIiAvICJpLWJubiIgLyAiaS1kZWZhdWx0Ig0KICAgICAg ICAgICAgICAgICAvICJpLWVub2NoaWFuIiAvICJpLWhhayIgLyAiaS1rbGluZ29uIiAvICJp LWx1eCINCiAgICAgICAgICAgICAgICAgLyAiaS1taW5nbyIgLyAiaS1uYXZham8iIC8gImkt cHduIiAvICJpLXRhbyINCiAgICAgICAgICAgICAgICAgLyAiaS10YXkiIC8gImktdHN1IiAv ICJzZ24tQkUtZnIiIC8gInNnbi1CRS1ubCINCiAgICAgICAgICAgICAgICAgLyAic2duLUNI LWRlIg0KDQogICBhbHBoYW51bSAgICAgID0gKEFMUEhBIC8gRElHSVQpICAgICAgIDsgbGV0 dGVycyBhbmQgbnVtYmVycw0KDQogICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTog TGFuZ3VhZ2UgVGFnIEFCTkYNCg0KICAgQWxsIHN1YnRhZ3MgaGF2ZSBhIG1heGltdW0gbGVu Z3RoIG9mIGVpZ2h0IGNoYXJhY3RlcnMgYW5kIHdoaXRlc3BhY2UNCiAgIGlzIG5vdCBwZXJt aXR0ZWQgaW4gYSBsYW5ndWFnZSB0YWcuICBUaGVyZSBpcyBhIHN1YnRsZXR5IGluIHRoZSBB Qk5GDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCiAgIHByb2R1Y3Rpb24gJ3ZhcmlhbnQnOiB2YXJpYW50cyBzdGFydGluZyB3aXRoIGEg ZGlnaXQgTUFZIGJlIGZvdXINCiAgIGNoYXJhY3RlcnMgbG9uZywgd2hpbGUgdGhvc2Ugc3Rh cnRpbmcgd2l0aCBhIGxldHRlciBNVVNUIGJlIGF0IGxlYXN0DQogICBmaXZlIGNoYXJhY3Rl cnMgbG9uZy4gIEZvciBleGFtcGxlcyBvZiBsYW5ndWFnZSB0YWdzLCBzZWUgQXBwZW5kaXgg Qi4NCg0KICAgTm90ZSBXZWxsOiB0aGUgQUJORiBzeW50YXggZG9lcyBub3QgZGlzdGluZ3Vp c2ggYmV0d2VlbiB1cHBlciBhbmQNCiAgIGxvd2VyY2FzZS4gIFRoZSBhcHBlYXJhbmNlIG9m IHVwcGVyIGFuZCBsb3dlcmNhc2UgbGV0dGVycyBpbiB0aGUNCiAgIHZhcm91cyBBQk5GIHBy b2R1Y3Rpb25zIGFib3ZlIGRvIG5vdCBhZmZlY3QgaG93IGltcGxlbWVudGF0aW9ucw0KICAg aW50ZXJwcmV0IHRhZ3MuICBUaGF0IGlzLCB0aGUgdGFnICJJLUFNSSIgbWF0Y2hlcyB0aGUg aXRlbSAiaS1hbWkiIGluDQogICB0aGUgJ2lycmVndWxhcicgcHJvZHVjdGlvbi4gIEF0IGFs bCB0aW1lcywgdGhlIHRhZ3MgYW5kIHRoZWlyDQogICBzdWJ0YWdzLCBpbmNsdWRpbmcgcHJp dmF0ZSB1c2UgYW5kIGV4dGVuc2lvbnMsIGFyZSB0byBiZSB0cmVhdGVkIGFzDQogICBjYXNl IGluc2Vuc2l0aXZlOiB0aGVyZSBleGlzdCBjb252ZW50aW9ucyBmb3IgdGhlIGNhcGl0YWxp emF0aW9uIG9mDQogICBzb21lIG9mIHRoZSBzdWJ0YWdzLCBidXQgdGhlc2UgTVVTVCBOT1Qg YmUgdGFrZW4gdG8gY2FycnkgbWVhbmluZy4NCg0KICAgRm9yIGV4YW1wbGU6DQoNCiAgIG8g IFtJU082MzktMV0gcmVjb21tZW5kcyB0aGF0IGxhbmd1YWdlIGNvZGVzIGJlIHdyaXR0ZW4g aW4gbG93ZXJjYXNlDQogICAgICAoJ21uJyBNb25nb2xpYW4pLg0KDQogICBvICBbSVNPMzE2 Ni0xXSByZWNvbW1lbmRzIHRoYXQgY291bnRyeSBjb2RlcyBiZSBjYXBpdGFsaXplZCAoJ01O Jw0KICAgICAgTW9uZ29saWEpLg0KDQogICBvICBbSVNPMTU5MjRdIHJlY29tbWVuZHMgdGhh dCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyY2FzZSB3aXRoIHRoZQ0KICAgICAgaW5pdGlhbCBs ZXR0ZXIgY2FwaXRhbGl6ZWQgKCdDeXJsJyBDeXJpbGxpYykuDQoNCiAgIEhvd2V2ZXIsIGlu IHRoZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlIHVwcGVyY2FzZSBVUy1B U0NJSQ0KICAgbGV0dGVycyBpbiB0aGUgcmFuZ2UgJ0EnIHRocm91Z2ggJ1onIGFyZSBjb25z aWRlcmVkIGVxdWl2YWxlbnQgYW5kDQogICBtYXBwZWQgZGlyZWN0bHkgdG8gdGhlaXIgVVMt QVNDSUkgbG93ZXJjYXNlIGVxdWl2YWxlbnRzIGluIHRoZSByYW5nZQ0KICAgJ2EnIHRocm91 Z2ggJ3onLiAgVGh1cywgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZy b20NCiAgICJNTi1jWVJMLW1uIiBvciAibU4tY1lyTC1NbiIgKG9yIGFueSBvdGhlciBjb21i aW5hdGlvbiksIGFuZCBlYWNoIG9mDQogICB0aGVzZSB2YXJpYXRpb25zIGNvbnZleXMgdGhl IHNhbWUgbWVhbmluZzogTW9uZ29saWFuIHdyaXR0ZW4gaW4gdGhlDQogICBDeXJpbGxpYyBz Y3JpcHQgYXMgdXNlZCBpbiBNb25nb2xpYS4NCg0KICAgQWx0aG91Z2ggY2FzZSBkaXN0aW5j dGlvbnMgZG8gbm90IGNhcnJ5IG1lYW5pbmcgaW4gbGFuZ3VhZ2UgdGFncywNCiAgIGNvbnNp c3RlbnQgZm9ybWF0dGluZyBhbmQgcHJlc2VudGF0aW9uIG9mIHRoZSB0YWdzIHdpbGwgYWlk IHVzZXJzLg0KICAgVGhlIGZvcm1hdCBvZiB0aGUgdGFncyBhbmQgc3VidGFncyBpbiB0aGUg cmVnaXN0cnkgaXMgUkVDT01NRU5ERUQuDQogICBJbiB0aGlzIGZvcm1hdCwgYWxsIG5vbi1p bml0aWFsIHR3by1sZXR0ZXIgc3VidGFncyBhcmUgdXBwZXJjYXNlLCBhbGwNCiAgIG5vbi1p bml0aWFsIGZvdXItbGV0dGVyIHN1YnRhZ3MgYXJlIHRpdGxlY2FzZSwgYW5kIGFsbCBvdGhl ciBzdWJ0YWdzDQogICBhcmUgbG93ZXJjYXNlLg0KDQogICBOb3RlIHRoYXQgYWx0aG91Z2gg W1JGQzQyMzRdIHJlZmVycyB0byBvY3RldHMsIHRoZSBsYW5ndWFnZSB0YWdzDQogICBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgc2VxdWVuY2VzIG9mIGNoYXJhY3RlcnMgZnJv bSB0aGUgVVMtDQogICBBU0NJSSBbSVNPNjQ2XSByZXBlcnRvaXJlLiAgTGFuZ3VhZ2UgdGFn cyBNQVkgYmUgdXNlZCBpbiBkb2N1bWVudHMNCiAgIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCB1 c2Ugb3RoZXIgZW5jb2RpbmdzLCBzbyBsb25nIGFzIHRoZXNlIGVuY29tcGFzcw0KICAgdGhl IFVTLUFTQ0lJIHJlcGVydG9pcmUuICBBbiBleGFtcGxlIG9mIHRoaXMgd291bGQgYmUgYW4g WE1MIGRvY3VtZW50DQogICB0aGF0IHVzZXMgdGhlIFVURi0xNkxFIFtSRkMyNzgxXSBlbmNv ZGluZyBvZiBbVW5pY29kZV0uDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNw0KDQoNCjIuMi4gIExhbmd1YWdlIFN1YnRhZyBTb3VyY2Vz IGFuZCBJbnRlcnByZXRhdGlvbg0KDQogICBUaGUgbmFtZXNwYWNlIG9mIGxhbmd1YWdlIHRh Z3MgYW5kIHRoZWlyIHN1YnRhZ3MgaXMgYWRtaW5pc3RlcmVkIGJ5DQogICB0aGUgSW50ZXJu ZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIFtSRkMyODYwXSBhY2NvcmRp bmcgdG8NCiAgIHRoZSBydWxlcyBpbiBTZWN0aW9uIDUgb2YgdGhpcyBkb2N1bWVudC4gIFRo ZSBMYW5ndWFnZSBTdWJ0YWcNCiAgIFJlZ2lzdHJ5IG1haW50YWluZWQgYnkgSUFOQSBpcyB0 aGUgc291cmNlIGZvciB2YWxpZCBzdWJ0YWdzOiBvdGhlcg0KICAgc3RhbmRhcmRzIHJlZmVy ZW5jZWQgaW4gdGhpcyBzZWN0aW9uIHByb3ZpZGUgdGhlIHNvdXJjZSBtYXRlcmlhbCBmb3IN CiAgIHRoYXQgcmVnaXN0cnkuDQoNCiAgIFRlcm1pbm9sb2d5IHVzZWQgaW4gdGhpcyBkb2N1 bWVudDoNCg0KICAgbyAgVGFnIG9yIHRhZ3MgcmVmZXJzIHRvIGEgY29tcGxldGUgbGFuZ3Vh Z2UgdGFnLCBzdWNoIGFzDQogICAgICAic3ItTGF0bi1SUyIgb3IgImF6LUFyYWItSVIiLiAg RXhhbXBsZXMgb2YgdGFncyBpbiB0aGlzIGRvY3VtZW50DQogICAgICBhcmUgZW5jbG9zZWQg aW4gZG91YmxlLXF1b3RlcyAoImVuLVVTIikuDQoNCiAgIG8gIFN1YnRhZyByZWZlcnMgdG8g YSBzcGVjaWZpYyBzZWN0aW9uIG9mIGEgdGFnLCBkZWxpbWl0ZWQgYnkgaHlwaGVuLA0KICAg ICAgc3VjaCBhcyB0aGUgc3VidGFnICdIYW50JyBpbiAiemgtSGFudC1DTiIuICBFeGFtcGxl cyBvZiBzdWJ0YWdzIGluDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBz aW5nbGUgcXVvdGVzICgnSGFudCcpLg0KDQogICBvICBDb2RlIG9yIGNvZGVzIHJlZmVycyB0 byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5hbCBzdGFuZGFyZHMgKGFuZA0KICAgICAgd2hp Y2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50KS4gIEZvciBleGFtcGxl LCAnSGFudCcNCiAgICAgIGlzIGFuIFtJU08xNTkyNF0gc2NyaXB0IGNvZGUgdGhhdCB3YXMg dXNlZCB0byBkZWZpbmUgdGhlICdIYW50Jw0KICAgICAgc2NyaXB0IHN1YnRhZyBmb3IgdXNl IGluIGEgbGFuZ3VhZ2UgdGFnLiAgRXhhbXBsZXMgb2YgY29kZXMgaW4NCiAgICAgIHRoaXMg ZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluIHNpbmdsZSBxdW90ZXMgKCdlbicsICdIYW50Jyku DQoNCiAgIFRoZSBkZWZpbml0aW9ucyBpbiB0aGlzIHNlY3Rpb24gYXBwbHkgdG8gdGhlIHZh cmlvdXMgc3VidGFncyB3aXRoaW4NCiAgIHRoZSBsYW5ndWFnZSB0YWdzIGRlZmluZWQgYnkg dGhpcyBkb2N1bWVudCwgZXhjZXB0aW5nIHRob3NlDQogICAiZ3JhbmRmYXRoZXJlZCIgdGFn cyBkZWZpbmVkIGluIFNlY3Rpb24gMi4yLjguDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIGRl c2lnbmVkIHNvIHRoYXQgZWFjaCBzdWJ0YWcgdHlwZSBoYXMgdW5pcXVlIGxlbmd0aA0KICAg YW5kIGNvbnRlbnQgcmVzdHJpY3Rpb25zLiAgVGhlc2UgbWFrZSBpZGVudGlmaWNhdGlvbiBv ZiB0aGUgc3VidGFnJ3MNCiAgIHR5cGUgcG9zc2libGUsIGV2ZW4gaWYgdGhlIGNvbnRlbnQg b2YgdGhlIHN1YnRhZyBpdHNlbGYgaXMNCiAgIHVucmVjb2duaXplZC4gIFRoaXMgYWxsb3dz IHRhZ3MgdG8gYmUgcGFyc2VkIGFuZCBwcm9jZXNzZWQgd2l0aG91dA0KICAgcmVmZXJlbmNl IHRvIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMgb3Ig dGhlDQogICBJQU5BIHJlZ2lzdHJ5IGFuZCBtYWtlcyB0aGUgYXNzb2NpYXRlZCBleGNlcHRp b24gaGFuZGxpbmcgd2hlbg0KICAgcGFyc2luZyB0YWdzIHNpbXBsZXIuDQoNCiAgIFN1YnRh Z3MgaW4gdGhlIElBTkEgcmVnaXN0cnkgdGhhdCBkbyBub3QgY29tZSBmcm9tIGFuIHVuZGVy bHlpbmcNCiAgIHN0YW5kYXJkIGNhbiBvbmx5IGFwcGVhciBpbiBzcGVjaWZpYyBwb3NpdGlv bnMgaW4gYSB0YWcuDQogICBTcGVjaWZpY2FsbHksIHRoZXkgY2FuIG9ubHkgb2NjdXIgYXMg cHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIG9yIGFzDQogICB2YXJpYW50IHN1YnRhZ3MuDQoN CiAgIE5vdGUgdGhhdCBzZXF1ZW5jZXMgb2YgcHJpdmF0ZSB1c2UgYW5kIGV4dGVuc2lvbiBz dWJ0YWdzIE1VU1Qgb2NjdXINCiAgIGF0IHRoZSBlbmQgb2YgdGhlIHNlcXVlbmNlIG9mIHN1 YnRhZ3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0KICAgd2l0aCBzdWJ0YWdzIGRl ZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFNpbmdsZS1sZXR0ZXIg YW5kIHNpbmdsZS1kaWdpdCBzdWJ0YWdzIGFyZSByZXNlcnZlZCBmb3IgY3VycmVudCBvcg0K ICAgZnV0dXJlIHVzZS4gIFRoZXNlIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjdXJyZW50IHVz ZXM6DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCiAgIG8gIFRoZSBzaW5nbGUtbGV0dGVyIHN1YnRhZyAneCcgaXMgcmVzZXJ2ZWQgdG8g aW50cm9kdWNlIGEgc2VxdWVuY2UNCiAgICAgIG9mIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBU aGUgaW50ZXJwcmV0YXRpb24gb2YgYW55IHByaXZhdGUgdXNlDQogICAgICBzdWJ0YWdzIGlz IGRlZmluZWQgc29sZWx5IGJ5IHByaXZhdGUgYWdyZWVtZW50IGFuZCBpcyBub3QgZGVmaW5l ZA0KICAgICAgYnkgdGhlIHJ1bGVzIGluIHRoaXMgc2VjdGlvbiBvciBpbiBhbnkgc3RhbmRh cmQgb3IgcmVnaXN0cnkNCiAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAg byAgQWxsIG90aGVyIHNpbmdsZS1sZXR0ZXIgc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gaW50 cm9kdWNlDQogICAgICBzdGFuZGFyZGl6ZWQgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZXMg YXMgZGVzY3JpYmVkIGluDQogICAgICBTZWN0aW9uIDMuNy4NCg0KICAgVGhlIHNpbmdsZS1s ZXR0ZXIgc3VidGFnICdpJyBpcyB1c2VkIGJ5IHNvbWUgZ3JhbmRmYXRoZXJlZCB0YWdzLCBz dWNoDQogICBhcyAiaS1kZWZhdWx0Iiwgd2hlcmUgaXQgYWx3YXlzIGFwcGVhcnMgaW4gdGhl IGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2VkIHdpdGggYW4gZXh0 ZW5zaW9uLg0KDQoyLjIuMS4gIFByaW1hcnkgTGFuZ3VhZ2UgU3VidGFnDQoNCiAgIFRoZSBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpcyB0aGUgZmlyc3Qgc3VidGFnIGluIGEgbGFuZ3Vh Z2UgdGFnDQogICAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIHByaXZhdGUgdXNlIGFuZCBjZXJ0 YWluIGdyYW5kZmF0aGVyZWQgdGFncykNCiAgIGFuZCBjYW5ub3QgYmUgb21pdHRlZC4gIFRo ZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHByaW1hcnkNCiAgIGxhbmd1YWdlIHN1 YnRhZzoNCg0KICAgMS4gIEFsbCB0d28tY2hhcmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFncyB3ZXJlIGRlZmluZWQgaW4gdGhlDQogICAgICAgSUFOQSByZWdpc3RyeSBhY2NvcmRp bmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZA0KICAgICAgIElT TyA2MzkgUGFydCAxLCAiSVNPIDYzOS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50 YXRpb24gb2YNCiAgICAgICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBoYS0y IGNvZGUiIFtJU082MzktMV0sIG9yIHVzaW5nDQogICAgICAgYXNzaWdubWVudHMgc3Vic2Vx dWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzktMSByZWdpc3RyYXRpb24NCiAgICAgICBhdXRo b3JpdHkgKFJBKSBvciBnb3Zlcm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAg Mi4gIEFsbCB0aHJlZS1jaGFyYWN0ZXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUg ZGVmaW5lZCBpbiB0aGUNCiAgICAgICBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUg YXNzaWdubWVudHMgZm91bmQgaW4gZWl0aGVyIElTTw0KICAgICAgIDYzOSBQYXJ0IDIsICJJ U08gNjM5LTI6MTk5OCAtIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICAg ICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAyOiBBbHBoYS0zIGNvZGUgLSBlZGl0aW9u IDEiDQogICAgICAgW0lTTzYzOS0yXSwgSVNPIDYzOSBQYXJ0IDMsICJDb2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAgbmFtZXMgb2YgbGFuZ3VhZ2VzIC0tIFBhcnQg MzogQWxwaGEtMyBjb2RlIGZvciBjb21wcmVoZW5zaXZlDQogICAgICAgY292ZXJhZ2Ugb2Yg bGFuZ3VhZ2VzIiBbSVNPNjM5LTNdLCBvciBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkNCiAg ICAgICBtYWRlIGJ5IHRoZSByZWxldmFudCBJU08gNjM5IHJlZ2lzdHJhdGlvbiBhdXRob3Jp dGllcyBvcg0KICAgICAgIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQog ICAzLiAgVGhlIHN1YnRhZ3MgaW4gdGhlIHJhbmdlICdxYWEnIHRocm91Z2ggJ3F0eicgYXJl IHJlc2VydmVkIGZvcg0KICAgICAgIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBU aGVzZSBzdWJ0YWdzIGNvcnJlc3BvbmQgdG8gY29kZXMNCiAgICAgICByZXNlcnZlZCBieSBJ U08gNjM5LTIgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMgTUFZIGJlIHVzZWQNCiAg ICAgICBmb3Igbm9uLXJlZ2lzdGVyZWQgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIChpbnN0 ZWFkIG9mIHVzaW5nDQogICAgICAgcHJpdmF0ZSB1c2Ugc3VidGFncyBmb2xsb3dpbmcgJ3gt JykuICBQbGVhc2UgcmVmZXIgdG8gU2VjdGlvbiA0LjUNCiAgICAgICBmb3IgbW9yZSBpbmZv cm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0KDQogICA0LiAgQWxsIGZvdXItY2hh cmFjdGVyIGxhbmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBwb3NzaWJsZQ0KICAg ICAgIGZ1dHVyZSBzdGFuZGFyZGl6YXRpb24uDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBzdWJ0 YWdzIG9mIDUgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAg IHJlZ2lzdHJ5IHdlcmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGlu IFNlY3Rpb24gMy41DQogICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1h cnkgbGFuZ3VhZ2Ugc3VidGFnLiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50 IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0K ICAgICAgIHN1YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdp bGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAgcHJpbWFyeSBsYW5ndWFnZXMgYXJlIHN0cm9u Z2x5IFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRpb24gd2l0aA0KICAgICAgIElTTyA2Mzks IGFuZCBwcm9wb3NhbHMgcmVqZWN0ZWQgYnkgSVNPIDYzOS9SQSB3aWxsIGJlIGNsb3NlbHkN CiAgICAgICBzY3J1dGluaXplZCBiZWZvcmUgdGhleSBhcmUgcmVnaXN0ZXJlZCB3aXRoIElB TkEuDQoNCiAgIDYuICBUaGUgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnIGFzIHRoZSBw cmltYXJ5IHN1YnRhZyBpbmRpY2F0ZXMNCiAgICAgICB0aGF0IHRoZSBsYW5ndWFnZSB0YWcg Y29uc2lzdHMgc29sZWx5IG9mIHN1YnRhZ3Mgd2hvc2UgbWVhbmluZyBpcw0KICAgICAgIGRl ZmluZWQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBGb3IgZXhhbXBsZSwgaW4gdGhlIHRhZyAi eC1mci1DSCIsDQogICAgICAgdGhlIHN1YnRhZ3MgJ2ZyJyBhbmQgJ0NIJyBTSE9VTEQgTk9U IGJlIHRha2VuIHRvIHJlcHJlc2VudCB0aGUNCiAgICAgICBGcmVuY2ggbGFuZ3VhZ2Ugb3Ig dGhlIGNvdW50cnkgb2YgU3dpdHplcmxhbmQgKG9yIGFueSBvdGhlciB2YWx1ZQ0KICAgICAg IGluIHRoZSBJQU5BIHJlZ2lzdHJ5KSB1bmxlc3MgdGhlcmUgaXMgYSBwcml2YXRlIGFncmVl bWVudCBpbg0KICAgICAgIHBsYWNlIHRvIGRvIHNvLiAgU2VlIFNlY3Rpb24gNC41Lg0KDQog ICA3LiAgVGhlIHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFnICdpJyBpcyB1c2VkIGJ5IHNvbWUg Z3JhbmRmYXRoZXJlZA0KICAgICAgIHRhZ3MgKHNlZSBTZWN0aW9uIDIuMi44KSBzdWNoIGFz ICJpLWtsaW5nb24iIGFuZCAiaS1ibm4iLiAgKE90aGVyDQogICAgICAgZ3JhbmRmYXRoZXJl ZCB0YWdzIGhhdmUgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGVpciBmaXJzdA0K ICAgICAgIHBvc2l0aW9uLikNCg0KICAgOC4gIE90aGVyIHZhbHVlcyBNVVNUIE5PVCBiZSBh c3NpZ25lZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0IGJ5DQogICAgICAgcmV2aXNp b24gb3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFn ZXMgdGhhdCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIHR3by1jaGFyYWN0ZXIgY29kZQ0KICAg YW5kIGEgdGhyZWUgY2hhcmFjdGVyIGNvZGUgYXNzaWduZWQgYnkgZWl0aGVyIElTTyA2Mzkt MiBvciBJU08gNjM5LTMsDQogICBvbmx5IHRoZSBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBj b2RlIGlzIGRlZmluZWQgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5Lg0KDQogICBOb3RlOiBG b3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBubyBJU08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2Rl IGFuZCBmb3INCiAgIHdoaWNoIHRoZSBJU08gNjM5LTIvVCAoVGVybWlub2xvZ3kpIGNvZGUg YW5kIHRoZSBJU08gNjM5LTIvQg0KICAgKEJpYmxpb2dyYXBoaWMpIGNvZGVzIGRpZmZlciwg b25seSB0aGUgVGVybWlub2xvZ3kgY29kZSBpcyBkZWZpbmVkIGluDQogICB0aGUgSUFOQSBy ZWdpc3RyeS4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIGFsbA0K ICAgbGFuZ3VhZ2VzIHRoYXQgaGFkIGJvdGgga2luZHMgb2YgdGhyZWUtY2hhcmFjdGVyIGNv ZGUgd2VyZSBhbHNvDQogICBhc3NpZ25lZCBhIHR3by1jaGFyYWN0ZXIgY29kZTsgaXQgaXMg ZXhwZWN0ZWQgdGhhdCBmdXR1cmUgYXNzaWdubWVudHMNCiAgIG9mIHRoaXMgbmF0dXJlIHdp bGwgbm90IG9jY3VyLg0KDQogICBOb3RlOiBUbyBhdm9pZCBwcm9ibGVtcyB3aXRoIHZlcnNp b25pbmcgYW5kIHN1YnRhZyBjaG9pY2UgYXMNCiAgIGV4cGVyaWVuY2VkIGR1cmluZyB0aGUg dHJhbnNpdGlvbiBiZXR3ZWVuIFJGQyAxNzY2IGFuZCBSRkMgMzA2NiwgYXMNCiAgIHdlbGwg YXMgdGhlIGNhbm9uaWNhbCBuYXR1cmUgb2Ygc3VidGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9j dW1lbnQsIHRoZQ0KICAgSVNPIDYzOSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5IEpvaW50IEFk dmlzb3J5IENvbW1pdHRlZSAoSVNPIDYzOS8NCiAgIFJBLUpBQykgaGFzIGluY2x1ZGVkIHRo ZSBmb2xsb3dpbmcgc3RhdGVtZW50IGluIFtpc282MzkucHJpbl06DQoNCiAgICAgICJBIGxh bmd1YWdlIGNvZGUgYWxyZWFkeSBpbiBJU08gNjM5LTIgYXQgdGhlIHBvaW50IG9mIGZyZWV6 aW5nIElTTw0KICAgICAgNjM5LTEgc2hhbGwgbm90IGxhdGVyIGJlIGFkZGVkIHRvIElTTyA2 MzktMS4gIFRoaXMgaXMgdG8gZW5zdXJlDQogICAgICBjb25zaXN0ZW5jeSBpbiB1c2FnZSBv dmVyIHRpbWUsIHNpbmNlIHVzZXJzIGFyZSBkaXJlY3RlZCBpbg0KICAgICAgSW50ZXJuZXQg YXBwbGljYXRpb25zIHRvIGVtcGxveSB0aGUgYWxwaGEtMyBjb2RlIHdoZW4gYW4gYWxwaGEt Mg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICAgICBjb2RlIGZvciB0aGF0IGxhbmd1YWdlIGlzIG5vdCBhdmFpbGFibGUuIg0KDQog ICBJbiBvcmRlciB0byBhdm9pZCBpbnN0YWJpbGl0eSBpbiB0aGUgY2Fub25pY2FsIGZvcm0g b2YgdGFncywgaWYgYQ0KICAgdHdvLWNoYXJhY3RlciBjb2RlIGlzIGFkZGVkIHRvIElTTyA2 MzktMSBmb3IgYSBsYW5ndWFnZSBmb3Igd2hpY2ggYQ0KICAgdGhyZWUtY2hhcmFjdGVyIGNv ZGUgd2FzIGFscmVhZHkgaW5jbHVkZWQgaW4gZWl0aGVyIElTTyA2MzktMiBvciBJU08NCiAg IDYzOS0zLCB0aGUgdHdvLWNoYXJhY3RlciBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQu ICBTZWUNCiAgIFNlY3Rpb24gMy40Lg0KDQogICBGb3IgZXhhbXBsZSwgaWYgc29tZSBjb250 ZW50IHdlcmUgdGFnZ2VkIHdpdGggJ2hhdycgKEhhd2FpaWFuKSwgd2hpY2gNCiAgIGN1cnJl bnRseSBoYXMgbm8gdHdvLWNoYXJhY3RlciBjb2RlLCB0aGUgdGFnIHdvdWxkIG5vdCBiZSBp bnZhbGlkYXRlZA0KICAgaWYgSVNPIDYzOS0xIHdlcmUgdG8gYXNzaWduIGEgdHdvLWNoYXJh Y3RlciBjb2RlIHRvIHRoZSBIYXdhaWlhbg0KICAgbGFuZ3VhZ2UgYXQgYSBsYXRlciBkYXRl Lg0KDQogICBOb3RlOiBBbiBleGFtcGxlIG9mIGluZGVwZW5kZW50IHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFnIHJlZ2lzdHJhdGlvbg0KICAgbWlnaHQgaW5jbHVkZTogb25lIG9mIHRoZSBn cmFuZGZhdGhlcmVkIElBTkEgcmVnaXN0cmF0aW9ucyBpcw0KICAgImktZW5vY2hpYW4iLiAg VGhlIHN1YnRhZyAnZW5vY2hpYW4nIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEN CiAgIHJlZ2lzdHJ5IGFzIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGFzc3VtaW5nIHRo YXQgSVNPIDYzOSBkb2VzIG5vdA0KICAgcmVnaXN0ZXIgdGhpcyBsYW5ndWFnZSBmaXJzdCks IG1ha2luZyB0YWdzIHN1Y2ggYXMgImVub2NoaWFuLUFRIiBhbmQNCiAgICJlbm9jaGlhbi1M YXRuIiB2YWxpZC4NCg0KMi4yLjIuICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAg IEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgYXJlIHVzZWQgdG8gaWRlbnRpZnkgbGFuZ3Vh Z2VzIHRoYXQgYXJlDQogICBlbmNvbXBhc3NlZCBieSBhICJtYWNyb2xhbmd1YWdlIi4gIElT TyA2MzktMyBkZWZpbmVzIGNlcnRhaW4NCiAgIGxhbmd1YWdlcyB0byBiZSAibWFjcm9sYW5n dWFnZXMiOyB0aGF0IGlzLCB0aGV5IGFyZSBncm91cHMgb2YgdmVyeQ0KICAgY2xvc2VseSBy ZWxhdGVkIGxhbmd1YWdlcyB3aGljaCBhcmUgdHJlYXRlZCBhcyBhIHNpbmdsZSBsYW5ndWFn ZSBpbg0KICAgY2VydGFpbiBjb250ZXh0cy4gIEluIG9yZGVyIHRvIGltcHJvdmUgbWF0Y2hp bmcgYmVoYXZpb3IgYW5kIHRhZ2dpbmcNCiAgIGNvbnNpc3RlbmN5LCBlYWNoIGxhbmd1YWdl IGVuY29tcGFzc2VkIGJ5IGEgSVNPIDYzOS0zIG1hY3JvbGFuZ3VhZ2UNCiAgIGlzIHJlcHJl c2VudGVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IHVzaW5nIGFuIGV4dGVuZGVkIGxhbmd1YWdl DQogICBzdWJ0YWcsIHByb3ZpZGVkIHRoYXQgaXQgaXMgbm90IGFscmVhZHkgcmVwcmVzZW50 ZWQgdXNpbmcgYSBsYW5ndWFnZQ0KICAgc3VidGFnLiAgVGhlIGZvbGxvd2luZyBydWxlcyBh cHBseSB0byB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnczoNCg0KICAgMS4gIFRoZXNl IHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0 bw0KICAgICAgIGFzc2lnbm1lbnRzIGZvdW5kIGluIElTTyA2MzkgUGFydCAzLg0KDQogICAy LiAgQSBzZXF1ZW5jZSBvZiB1cCB0byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdz IE1BWSBhcHBlYXIgaW4NCiAgICAgICBhIGxhbmd1YWdlIHRhZy4gIFRoaXMgc2VxdWVuY2Ug TVVTVCBmb2xsb3cgdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcgYW5kIHBy ZWNlZGUgYW55IG90aGVyIHN1YnRhZ3MuDQoNCiAgIDMuICBFYWNoIGV4dGVuZGVkIGxhbmd1 YWdlIHN1YnRhZyBNVVNUIG9ubHkgYmUgdXNlZCB3aXRoIHRoZSBleGFjdA0KICAgICAgIHNl cXVlbmNlIG9mIHN1YnRhZ3MgdGhhdCBhcHBlYXJzIGluIHRoZSAnUHJlZml4JyBmaWVsZCBp biBpdHMNCiAgICAgICByZWdpc3RyeSByZWNvcmQuDQoNCiAgIDQuICBUaGVyZSBNQVkgYmUg dXAgdG8gdGhyZWUgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncy4NCg0KICAgNS4gIE90aGVy IHZhbHVlcyBNVVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2Ug c3VidGFnDQogICAgICAgZXhjZXB0IGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRv Y3VtZW50Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwg MjAwNw0KDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZyByZWNvcmRzIE1VU1QgaW5j bHVkZSBleGFjdGx5IG9uZSAnUHJlZml4Jw0KICAgZmllbGQgaW5kaWNhdGluZyBhbiBhcHBy b3ByaWF0ZSBzdWJ0YWcgb3Igc2VxdWVuY2Ugb2Ygc3VidGFncyBmb3INCiAgIHRoYXQgZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLg0KDQogICBGb3IgZXhhbXBsZSwgdGhlICdnYW4nIGFu ZCAnY21uJyBzdWJ0YWdzIHJlcHJlc2VudCB0aGUgbGFuZ3VhZ2VzIEdhbg0KICAgQ2hpbmVz ZSBhbmQgTWFuZGFyaW4gQ2hpbmVzZS4gIEVhY2ggaXMgZW5jb21wYXNzZWQgYnkgdGhlDQog ICBtYWNyb2xhbmd1YWdlICd6aCcgKENoaW5lc2UpLiAgVGhlcmVmb3JlLCB0aGV5IGJvdGgg aGF2ZSB0aGUgcHJlZml4DQogICAiemgiIGluIHRoZWlyIHJlZ2lzdHJ5IHJlY29yZHMuICBD b25zZXF1ZW50bHksIEdhbiBDaGluZXNlIGlzDQogICByZXByZXNlbnRlZCBhcyAiemgtZ2Fu IiBhbmQgTWFuZGFyaW4gQ2hpbmVzZSBhcyAiemgtY21uIi4gIFRoZQ0KICAgbGFuZ3VhZ2Ug c3VidGFnICd6aCcgY2FuIHN0aWxsIGJlIHVzZWQgd2l0aG91dCBhbiBleHRlbmRlZCBsYW5n dWFnZQ0KICAgc3VidGFnIHRvIGxhYmVsIGEgcmVzb3VyY2UgYXMgc29tZSB1bnNwZWNpZmll ZCB2YXJpZXR5IG9mIENoaW5lc2UNCiAgICh3aGljaCBpbiBwcmFjdGljZSB3aWxsIHVzdWFs bHkgYmUgTWFuZGFyaW4sIHRoZSBkb21pbmFudCB2YXJpZXR5IG9mDQogICBDaGluZXNlLCBi dXQgbWlnaHQgYWxzbyBiZSBzb21lIG90aGVyIHZhcmlldHkpLg0KDQogICBOb3cgc3VwcG9z ZSB0aGF0LCBpbiB0aGUgZnV0dXJlLCB0aGUgSVNPIDYzOS0zIFJlZ2lzdHJhdGlvbiBBdXRo b3JpdHkNCiAgIHdlcmUgdG8gZGVjaWRlIHRoYXQgR2FuIENoaW5lc2UgaXMgYWN0dWFsbHkg dHdvIGRpZmZlcmVudCBjbG9zZWx5DQogICByZWxhdGVkIGxhbmd1YWdlczogaXQgbWlnaHQg cmVjbGFzc2lmeSAnZ2FuJyBhcyBhIG1hY3JvbGFuZ3VhZ2UgYW5kDQogICBpbnRyb2R1Y2Ug dHdvIG5ldyBjb2RlIGVsZW1lbnRzLiAgSW4gdGhhdCBjYXNlLCB0aGVzZSBjb2RlIGVsZW1l bnRzDQogICB3b3VsZCBiZSBhZGRlZCB0byB0aGUgSUFOQSByZWdpc3RyeSBhcyBleHRlbmRl ZCBsYW5ndWFnZSBzdWJ0YWdzIHdpdGgNCiAgIHByZWZpeGVzIG9mICJ6aC1nYW4iLiAgTm8g Y2hhbmdlIHdvdWxkIGJlIG1hZGUgdG8gdGhlIHJlZ2lzdHJ5IHJlY29yZA0KICAgZm9yICdn YW4nLg0KDQoyLjIuMy4gIFNjcmlwdCBTdWJ0YWcNCg0KICAgU2NyaXB0IHN1YnRhZ3MgYXJl IHVzZWQgdG8gaW5kaWNhdGUgdGhlIHNjcmlwdCBvciB3cml0aW5nIHN5c3RlbQ0KICAgdmFy aWF0aW9ucyB0aGF0IGRpc3Rpbmd1aXNoIHRoZSB3cml0dGVuIGZvcm1zIG9mIGEgbGFuZ3Vh Z2Ugb3IgaXRzDQogICBkaWFsZWN0cy4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8g dGhlIHNjcmlwdCBzdWJ0YWdzOg0KDQogICAxLiAgQWxsIGZvdXItY2hhcmFjdGVyIHN1YnRh Z3Mgd2VyZSBkZWZpbmVkIGFjY29yZGluZyB0bw0KICAgICAgIFtJU08xNTkyNF0tLSJDb2Rl cyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBuYW1lcyBvZg0KICAgICAgIHNjcmlw dHMiOiBhbHBoYS00IHNjcmlwdCBjb2Rlcywgb3Igc3Vic2VxdWVudGx5IGFzc2lnbmVkIGJ5 IHRoZQ0KICAgICAgIElTTyAxNTkyNCBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJuaW5n IHN0YW5kYXJkaXphdGlvbiBib2RpZXMsDQogICAgICAgZGVub3RpbmcgdGhlIHNjcmlwdCBv ciB3cml0aW5nIHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGgNCiAgICAgICB0aGlz IGxhbmd1YWdlLg0KDQogICAyLiAgU2NyaXB0IHN1YnRhZ3MgTVVTVCBpbW1lZGlhdGVseSBm b2xsb3cgdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcgYW5kIGFsbCBleHRl bmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFuZCBNVVNUIG9jY3VyIGJlZm9yZQ0KICAgICAgIGFu eSBvdGhlciB0eXBlIG9mIHN1YnRhZyBkZXNjcmliZWQgYmVsb3cuDQoNCiAgIDMuICBUaGUg c2NyaXB0IHN1YnRhZ3MgJ1FhYWEnIHRocm91Z2ggJ1FhYngnIGFyZSByZXNlcnZlZCBmb3Ig cHJpdmF0ZQ0KICAgICAgIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBj b3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkDQogICAgICAgYnkgSVNPIDE1OTI0IGZvciBw cml2YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBub24tDQogICAgICAg cmVnaXN0ZXJlZCBzY3JpcHQgdmFsdWVzLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC41 IGZvciBtb3JlDQogICAgICAgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFncy4N Cg0KICAgNC4gIFNjcmlwdCBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgdXNpbmcg dGhlIHByb2Nlc3MgaW4NCiAgICAgICBTZWN0aW9uIDMuNSBvZiB0aGlzIGRvY3VtZW50LiAg VmFyaWFudCBzdWJ0YWdzIE1BWSBiZSBjb25zaWRlcmVkDQogICAgICAgZm9yIHJlZ2lzdHJh dGlvbiBmb3IgdGhhdCBwdXJwb3NlLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICA1LiAgVGhlcmUgTVVTVCBiZSBhdCBtb3N0IG9u ZSBzY3JpcHQgc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFnLCBhbmQNCiAgICAgICB0aGUgc2Ny aXB0IHN1YnRhZyBTSE9VTEQgYmUgb21pdHRlZCB3aGVuIGl0IGFkZHMgbm8NCiAgICAgICBk aXN0aW5ndWlzaGluZyB2YWx1ZSB0byB0aGUgdGFnIG9yIHdoZW4gdGhlIHByaW1hcnkgbGFu Z3VhZ2UNCiAgICAgICBzdWJ0YWcncyByZWNvcmQgaW5jbHVkZXMgYSBTdXBwcmVzcy1TY3Jp cHQgZmllbGQgbGlzdGluZyB0aGUNCiAgICAgICBhcHBsaWNhYmxlIHNjcmlwdCBzdWJ0YWcu DQoNCiAgIEV4YW1wbGU6ICJzci1MYXRuIiByZXByZXNlbnRzIFNlcmJpYW4gd3JpdHRlbiB1 c2luZyB0aGUgTGF0aW4gc2NyaXB0Lg0KDQoyLjIuNC4gIFJlZ2lvbiBTdWJ0YWcNCg0KICAg UmVnaW9uIHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgbGluZ3Vpc3RpYyB2YXJpYXRp b25zIGFzc29jaWF0ZWQNCiAgIHdpdGggb3IgYXBwcm9wcmlhdGUgdG8gYSBzcGVjaWZpYyBj b3VudHJ5LCB0ZXJyaXRvcnksIG9yIHJlZ2lvbi4NCiAgIFR5cGljYWxseSwgYSByZWdpb24g c3VidGFnIGlzIHVzZWQgdG8gaW5kaWNhdGUgcmVnaW9uYWwgZGlhbGVjdHMgb3INCiAgIHVz YWdlLCBvciByZWdpb24tc3BlY2lmaWMgc3BlbGxpbmcgY29udmVudGlvbnMuICBBIHJlZ2lv biBzdWJ0YWcgY2FuDQogICBhbHNvIGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBjb250ZW50 IGlzIGV4cHJlc3NlZCBpbiBhIHdheSB0aGF0IGlzDQogICBhcHByb3ByaWF0ZSBmb3IgdXNl IHRocm91Z2hvdXQgYSByZWdpb24sIGZvciBpbnN0YW5jZSwgU3BhbmlzaA0KICAgY29udGVu dCB0YWlsb3JlZCB0byBiZSB1c2VmdWwgdGhyb3VnaG91dCBMYXRpbiBBbWVyaWNhLg0KDQog ICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSByZWdpb24gc3VidGFnczoNCg0K ICAgMS4gIFJlZ2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFueSBsYW5ndWFnZSwgZXh0ZW5k ZWQgbGFuZ3VhZ2UsIG9yDQogICAgICAgc2NyaXB0IHN1YnRhZ3MgYW5kIE1VU1QgcHJlY2Vk ZSBhbGwgb3RoZXIgc3VidGFncy4NCg0KICAgMi4gIEFsbCB0d28tY2hhcmFjdGVyIHN1YnRh Z3MgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyB3ZXJlDQogICAgICAgZGVmaW5lZCBp biB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5k DQogICAgICAgaW4gW0lTTzMxNjYtMV0gKCJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9u IG9mIG5hbWVzIG9mDQogICAgICAgY291bnRyaWVzIGFuZCB0aGVpciBzdWJkaXZpc2lvbnMg LS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIikgdXNpbmcNCiAgICAgICB0aGUgbGlzdCBvZiBh bHBoYS0yIGNvdW50cnkgY29kZXMsIG9yIHVzaW5nIGFzc2lnbm1lbnRzDQogICAgICAgc3Vi c2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyAzMTY2IG1haW50ZW5hbmNlIGFnZW5jeSBvciBn b3Zlcm5pbmcNCiAgICAgICBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAzLiAgQWxs IHRocmVlLWNoYXJhY3RlciBzdWJ0YWdzIGNvbnNpc3Rpbmcgb2YgZGlnaXQgKG51bWVyaWMp DQogICAgICAgY2hhcmFjdGVycyBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIHdlcmUg ZGVmaW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUg YXNzaWdubWVudHMgZm91bmQgaW4gVU4gU3RhbmRhcmQNCiAgICAgICBDb3VudHJ5IG9yIEFy ZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSBbVU5fTS40OV0gb3INCiAgICAgICBhc3Np Z25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgZ292ZXJuaW5nIHN0YW5kYXJkcyBi b2R5Lg0KICAgICAgIE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzIGFy ZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkuICBUaGUgZm9sbG93aW5n IHJ1bGVzIGRlZmluZSB3aGljaCBjb2RlcyBhcmUgZW50ZXJlZA0KICAgICAgIGludG8gdGhl IHJlZ2lzdHJ5IGFzIHZhbGlkIHN1YnRhZ3M6DQoNCiAgICAgICBBLiAgVU4gbnVtZXJpYyBj b2RlcyBhc3NpZ25lZCB0byAnbWFjcm8tZ2VvZ3JhcGhpY2FsDQogICAgICAgICAgIChjb250 aW5lbnRhbCknIG9yIHN1Yi1yZWdpb25zIE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUNCiAg ICAgICAgICAgcmVnaXN0cnkuICBUaGVzZSBjb2RlcyBhcmUgbm90IGFzc29jaWF0ZWQgd2l0 aCBhbiBhc3NpZ25lZA0KICAgICAgICAgICBJU08gMzE2NiBhbHBoYS0yIGNvZGUgYW5kIHJl cHJlc2VudCBzdXByYS1uYXRpb25hbCBhcmVhcywNCiAgICAgICAgICAgdXN1YWxseSBjb3Zl cmluZyBtb3JlIHRoYW4gb25lIG5hdGlvbiwgc3RhdGUsIHByb3ZpbmNlLCBvcg0KICAgICAg ICAgICB0ZXJyaXRvcnkuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICAgQi4gIFVOIG51bWVyaWMgY29kZXMgZm9yICdl Y29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAgICAgICAgICBncm91cGluZ3MnIE1V U1QgTk9UIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYW5kDQogICAgICAg ICAgIE1VU1QgTk9UIGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzLg0KDQogICAgICAg Qy4gIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBvciBhcmVhcyB3aXRoIGFtYmln dW91cyBJU08NCiAgICAgICAgICAgMzE2NiBhbHBoYS0yIGNvZGVzLCB3aGVuIGVudGVyZWQg aW50byB0aGUgcmVnaXN0cnksIE1VU1QgYmUNCiAgICAgICAgICAgZGVmaW5lZCBhY2NvcmRp bmcgdG8gdGhlIHJ1bGVzIGluIFNlY3Rpb24gMy40IGFuZCBNVVNUIGJlDQogICAgICAgICAg IHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHRoYXQgcmVwcmVzZW50IHRoZSBjb3VudHJ5 IG9yDQogICAgICAgICAgIHJlZ2lvbiBmb3Igd2hpY2ggdGhleSBhcmUgZGVmaW5lZC4NCg0K ICAgICAgIEQuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgZm9y IHdoaWNoIHRoZXJlIGlzIGFuDQogICAgICAgICAgIGFzc29jaWF0ZWQgSVNPIDMxNjYgYWxw aGEtMiBjb2RlIGluIHRoZSByZWdpc3RyeSBNVVNUIE5PVCBiZQ0KICAgICAgICAgICBlbnRl cmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0NCiAg ICAgICAgICAgbGFuZ3VhZ2UgdGFncy4gIE5vdGUgdGhhdCB0aGUgSVNPIDMxNjYtYmFzZWQg c3VidGFnIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeSBNVVNUIGFjdHVhbGx5IGJlIGFz c29jaWF0ZWQgd2l0aCB0aGUgVU4gTS40OSBjb2RlIGluDQogICAgICAgICAgIHF1ZXN0aW9u Lg0KDQogICAgICAgRS4gIFVOIG51bWVyaWMgY29kZXMgYW5kIElTTyAzMTY2IGFscGhhLTIg Y29kZXMgZm9yIGNvdW50cmllcyBvcg0KICAgICAgICAgICBhcmVhcyBsaXN0ZWQgYXMgZWxp Z2libGUgZm9yIHJlZ2lzdHJhdGlvbiBpbiBbUkZDNDY0NV0gYnV0DQogICAgICAgICAgIG5v dCBwcmVzZW50bHkgcmVnaXN0ZXJlZCBNQVkgYmUgZW50ZXJlZCBpbnRvIHRoZSBJQU5BDQog ICAgICAgICAgIHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjUuICBPbmNlDQogICAgICAgICAgIHJlZ2lzdGVyZWQsIHRoZXNlIGNvZGVzIE1BWSBi ZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEYuICBBbGwgb3RoZXIg VU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIHRoYXQgZG8gbm90DQog ICAgICAgICAgIGhhdmUgYW4gYXNzb2NpYXRlZCBJU08gMzE2NiBhbHBoYS0yIGNvZGUgTVVT VCBOT1QgYmUgZW50ZXJlZA0KICAgICAgICAgICBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVT VCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQogICAgICAgICAgIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUgU2VjdGlvbiAzLjQuDQoN CiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNvZGVzIGluIEFwcGVuZGl4IFggb2Yg dGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1QgYmUgZW50ZXJlZCBpbnRvIHRoZSBy ZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0KICAgICAgIGZvcm0gbGFuZ3VhZ2Ug dGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLA0KICAgICAg IHRoZXNlIHZhbHVlcyBtYXRjaGVkIHRoZSBJU08gMzE2NiBhbHBoYS0yIGNvZGVzLikNCg0K ICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgcmVnaW9uIHN1YnRhZyBpbiBhIGxh bmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgcmVnaW9uIHN1YnRhZyBNQVkgYmUgb21pdHRl ZCwgYXMgd2hlbiBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgdmFsdWUgdG8g dGhlIHRhZy4NCg0KICAgNi4gIFRoZSByZWdpb24gc3VidGFncyAnQUEnLCAnUU0nLSdRWics ICdYQSctJ1haJywgYW5kICdaWicgYXJlDQogICAgICAgcmVzZXJ2ZWQgZm9yIHByaXZhdGUg dXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzDQogICAgICAgY29ycmVzcG9u ZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0ZSB1c2UuICBUaGVz ZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBwcml2YXRlIHVzZSByZWdpb24gc3Vi dGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEgcHJpdmF0ZSB1c2Ugc3VidGFnIHNl cXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAgIFNlY3Rpb24gNC41IGZvciBtb3Jl IGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgICJkZS1DSCIgcmVw cmVzZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgKCdDSCcpLg0K DQogICAic3ItTGF0bi1SUyIgcmVwcmVzZW50cyBTZXJiaWFuICgnc3InKSB3cml0dGVuIHVz aW5nIExhdGluIHNjcmlwdA0KICAgKCdMYXRuJykgYXMgdXNlZCBpbiBTZXJiaWEgKCdSUycp Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICAiZXMtNDE5IiByZXByZXNlbnRzIFNwYW5pc2ggKCdlcycpIGFwcHJvcHJpYXRlIHRv IHRoZSBVTi1kZWZpbmVkDQogICBMYXRpbiBBbWVyaWNhIGFuZCBDYXJpYmJlYW4gcmVnaW9u ICgnNDE5JykuDQoNCjIuMi41LiAgVmFyaWFudCBTdWJ0YWdzDQoNCiAgIFZhcmlhbnQgc3Vi dGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsLCB3ZWxsLXJlY29nbml6ZWQN CiAgIHZhcmlhdGlvbnMgdGhhdCBkZWZpbmUgYSBsYW5ndWFnZSBvciBpdHMgZGlhbGVjdHMg dGhhdCBhcmUgbm90DQogICBjb3ZlcmVkIGJ5IG90aGVyIGF2YWlsYWJsZSBzdWJ0YWdzLiAg VGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUNCiAgIHZhcmlhbnQgc3VidGFnczoN Cg0KICAgMS4gIFZhcmlhbnQgc3VidGFncyBhcmUgbm90IGFzc29jaWF0ZWQgd2l0aCBhbnkg ZXh0ZXJuYWwgc3RhbmRhcmQuDQogICAgICAgVmFyaWFudCBzdWJ0YWdzIGFuZCB0aGVpciBt ZWFuaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUNCiAgICAgICByZWdpc3RyYXRpb24gcHJvY2Vz cyBkZWZpbmVkIGluIFNlY3Rpb24gMy41Lg0KDQogICAyLiAgVmFyaWFudCBzdWJ0YWdzIE1V U1QgZm9sbG93IGFsbCBvZiB0aGUgb3RoZXIgZGVmaW5lZCBzdWJ0YWdzLCBidXQNCiAgICAg ICBwcmVjZWRlIGFueSBleHRlbnNpb24gb3IgcHJpdmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNl cy4NCg0KICAgMy4gIE1vcmUgdGhhbiBvbmUgdmFyaWFudCBNQVkgYmUgdXNlZCB0byBmb3Jt IHRoZSBsYW5ndWFnZSB0YWcuDQoNCiAgIDQuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBiZSBy ZWdpc3RlcmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICAgcnVsZXMgaW4g U2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcgdXNlZCB0byBmb3Jt DQogICAgICAgbGFuZ3VhZ2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1aXNoIHZhcmlh bnRzIGZyb20gb3RoZXIgdHlwZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdpc3RyYXRpb25z IE1VU1QgbWVldCB0aGUgZm9sbG93aW5nIGxlbmd0aCBhbmQNCiAgICAgICBjb250ZW50IHJl c3RyaWN0aW9uczoNCg0KICAgICAgIDEuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3 aXRoIGEgbGV0dGVyIChhLXosIEEtWikgTVVTVCBiZQ0KICAgICAgICAgICBhdCBsZWFzdCBm aXZlIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgICAgIDIuICBWYXJpYW50IHN1YnRhZ3MgdGhh dCBiZWdpbiB3aXRoIGEgZGlnaXQgKDAtOSkgTVVTVCBiZSBhdA0KICAgICAgICAgICBsZWFz dCBmb3VyIGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgVmFyaWFudCBzdWJ0YWcgcmVjb3JkcyBp biB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5IE1BWSBpbmNsdWRlDQogICBvbmUgb3Ig bW9yZSAnUHJlZml4JyBmaWVsZHMsIHdoaWNoIGluZGljYXRlIHRoZSBsYW5ndWFnZSB0YWcg b3IgdGFncw0KICAgdGhhdCB3b3VsZCBtYWtlIGEgc3VpdGFibGUgcHJlZml4ICh3aXRoIG90 aGVyIHN1YnRhZ3MsIGFzDQogICBhcHByb3ByaWF0ZSkgaW4gZm9ybWluZyBhIGxhbmd1YWdl IHRhZyB3aXRoIHRoZSB2YXJpYW50LiAgRm9yDQogICBleGFtcGxlLCB0aGUgc3VidGFnICdu ZWRpcycgaGFzIGEgUHJlZml4IG9mICJzbCIsIG1ha2luZyBpdCBzdWl0YWJsZQ0KICAgdG8g Zm9ybSBsYW5ndWFnZSB0YWdzIHN1Y2ggYXMgInNsLW5lZGlzIiBhbmQgInNsLUlULW5lZGlz IiwgYnV0IG5vdA0KICAgc3VpdGFibGUgZm9yIHVzZSBpbiBhIHRhZyBzdWNoIGFzICJ6aC1u ZWRpcyIgb3IgIml0LUlULW5lZGlzIi4NCg0KICAgInNsLW5lZGlzIiByZXByZXNlbnRzIHRo ZSBOYXRpc29uZSBvciBOYWRpemEgZGlhbGVjdCBvZiBTbG92ZW5pYW4uDQoNCiAgICJkZS1D SC0xOTk2IiByZXByZXNlbnRzIEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIGFuZCBh cyB3cml0dGVuDQogICB1c2luZyB0aGUgc3BlbGxpbmcgcmVmb3JtIGJlZ2lubmluZyBpbiB0 aGUgeWVhciAxOTk2IEMuRS4NCg0KICAgTW9zdCB2YXJpYW50cyB0aGF0IHNoYXJlIGEgcHJl Zml4IGFyZSBtdXR1YWxseSBleGNsdXNpdmUuICBGb3INCiAgIGV4YW1wbGUsIHRoZSBHZXJt YW4gb3J0aG9ncmFwaGljIHZhcmlhdGlvbnMgJzE5OTYnIGFuZCAnMTkwMScgU0hPVUxEDQog ICBOT1QgYmUgdXNlZCBpbiB0aGUgc2FtZSB0YWcsIGFzIHRoZXkgcmVwcmVzZW50IHRoZSBk YXRlcyBvZiBkaWZmZXJlbnQNCiAgIHNwZWxsaW5nIHJlZm9ybXMuICBBIHZhcmlhbnQgdGhh dCBjYW4gbWVhbmluZ2Z1bGx5IGJlIHVzZWQgaW4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDE1 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgY29tYmluYXRpb24gd2l0aCBhbm90 aGVyIHZhcmlhbnQgU0hPVUxEIGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbg0KICAgaXRz IHJlZ2lzdHJ5IHJlY29yZCB0aGF0IGxpc3RzIHRoYXQgb3RoZXIgdmFyaWFudC4gIEZvciBl eGFtcGxlLCBpZg0KICAgYW5vdGhlciBHZXJtYW4gdmFyaWFudCAnZXhhbXBsZScgd2VyZSBj cmVhdGVkIHRoYXQgbWFkZSBzZW5zZSB0byB1c2UNCiAgIHdpdGggJzE5OTYnLCB0aGVuICdl eGFtcGxlJyBzaG91bGQgaW5jbHVkZSB0d28gUHJlZml4IGZpZWxkczogImRlIg0KICAgYW5k ICJkZS0xOTk2Ii4NCg0KMi4yLjYuICBFeHRlbnNpb24gU3VidGFncw0KDQogICBFeHRlbnNp b25zIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIGV4dGVuZGluZyBsYW5ndWFnZSB0YWdzIGZv ciB1c2UgaW4NCiAgIHZhcmlvdXMgYXBwbGljYXRpb25zLiAgU2VlIFNlY3Rpb24gMy43LiAg VGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0bw0KICAgZXh0ZW5zaW9uczoNCg0KICAgMS4g ICBFeHRlbnNpb24gc3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRh Z3MgZGVmaW5lZA0KICAgICAgICBpbiB0aGlzIGRvY3VtZW50IGJ5IGEgc2luZ2xlLWNoYXJh Y3RlciBzdWJ0YWcgKCJzaW5nbGV0b24iKS4NCiAgICAgICAgVGhlIHNpbmdsZXRvbiBNVVNU IGJlIG9uZSBhbGxvY2F0ZWQgdG8gYSByZWdpc3RyYXRpb24gYXV0aG9yaXR5DQogICAgICAg IHZpYSB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNyBhbmQgTVVTVCBO T1QgYmUgdGhlDQogICAgICAgIGxldHRlciAneCcsIHdoaWNoIGlzIHJlc2VydmVkIGZvciBw cml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAgIE5vdGU6IFByaXZhdGUg dXNlIHN1YnRhZyBzZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2luZ2xldG9uDQogICAg ICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMi43IGJlbG93Lg0K DQogICAzLiAgIEFuIGV4dGVuc2lvbiBNVVNUIGZvbGxvdyBhdCBsZWFzdCBhIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnLg0KICAgICAgICBUaGF0IGlzLCBhIGxhbmd1YWdlIHRhZyBjYW5u b3QgYmVnaW4gd2l0aCBhbiBleHRlbnNpb24uDQogICAgICAgIEV4dGVuc2lvbnMgZXh0ZW5k IGxhbmd1YWdlIHRhZ3MsIHRoZXkgZG8gbm90IG92ZXJyaWRlIG9yIHJlcGxhY2UNCiAgICAg ICAgdGhlbS4gIEZvciBleGFtcGxlLCAiYS12YWx1ZSIgaXMgbm90IGEgd2VsbC1mb3JtZWQg bGFuZ3VhZ2UgdGFnLA0KICAgICAgICB3aGlsZSAiZGUtYS12YWx1ZSIgaXMuDQoNCiAgIDQu ICAgRWFjaCBzaW5nbGV0b24gc3VidGFnIE1VU1QgYXBwZWFyIGF0IG1vc3Qgb25lIHRpbWUg aW4gZWFjaCB0YWcNCiAgICAgICAgKG90aGVyIHRoYW4gYXMgYSBwcml2YXRlIHVzZSBzdWJ0 YWcpLiAgVGhhdCBpcywgc2luZ2xldG9uDQogICAgICAgIHN1YnRhZ3MgTVVTVCBOT1QgYmUg cmVwZWF0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAiZW4tYS1iYmItYS0NCiAgICAgICAg Y2NjIiBpcyBpbnZhbGlkIGJlY2F1c2UgdGhlIHN1YnRhZyAnYScgYXBwZWFycyB0d2ljZS4g IE5vdGUgdGhhdA0KICAgICAgICB0aGUgdGFnICJlbi1hLWJiYi14LWEtY2NjIiBpcyB2YWxp ZCBiZWNhdXNlIHRoZSBzZWNvbmQNCiAgICAgICAgYXBwZWFyYW5jZSBvZiB0aGUgc2luZ2xl dG9uICdhJyBpcyBpbiBhIHByaXZhdGUgdXNlIHNlcXVlbmNlLg0KDQogICA1LiAgIEV4dGVu c2lvbiBzdWJ0YWdzIE1VU1QgbWVldCBhbGwgb2YgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhl DQogICAgICAgIGNvbnRlbnQgYW5kIGZvcm1hdCBvZiBzdWJ0YWdzIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudC4NCg0KICAgNi4gICBFeHRlbnNpb24gc3VidGFncyBNVVNUIG1lZXQgd2hh dGV2ZXIgcmVxdWlyZW1lbnRzIGFyZSBzZXQgYnkgdGhlDQogICAgICAgIGRvY3VtZW50IHRo YXQgZGVmaW5lcyB0aGVpciBzaW5nbGV0b24gcHJlZml4IGFuZCB3aGF0ZXZlcg0KICAgICAg ICByZXF1aXJlbWVudHMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBtYWludGFpbmluZyBhdXRob3Jp dHkuDQoNCiAgIDcuICAgRWFjaCBleHRlbnNpb24gc3VidGFnIE1VU1QgYmUgZnJvbSB0d28g dG8gZWlnaHQgY2hhcmFjdGVycyBsb25nDQogICAgICAgIGFuZCBjb25zaXN0IHNvbGVseSBv ZiBsZXR0ZXJzIG9yIGRpZ2l0cywgd2l0aCBlYWNoIHN1YnRhZw0KICAgICAgICBzZXBhcmF0 ZWQgYnkgYSBzaW5nbGUgJy0nLg0KDQogICA4LiAgIEVhY2ggc2luZ2xldG9uIE1VU1QgYmUg Zm9sbG93ZWQgYnkgYXQgbGVhc3Qgb25lIGV4dGVuc2lvbg0KICAgICAgICBzdWJ0YWcuICBG b3IgZXhhbXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQgYmVjYXVzZQ0K ICAgICAgICB0aGUgZmlyc3Qgc2luZ2xldG9uICdhJyBpcyBmb2xsb3dlZCBpbW1lZGlhdGVs eSBieSBhbm90aGVyDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNw0KDQoNCiAgICAgICAgc2luZ2xldG9uICdiJy4NCg0KICAgOS4gICBFeHRlbnNp b24gc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxhbmd1YWdl LA0KICAgICAgICBzY3JpcHQsIHJlZ2lvbiwgYW5kIHZhcmlhbnQgc3VidGFncyBpbiBhIHRh Zy4NCg0KICAgMTAuICBBbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlIHNpbmdsZXRvbiBhbmQg YmVmb3JlIGFub3RoZXIgc2luZ2xldG9uDQogICAgICAgIGFyZSBwYXJ0IG9mIHRoZSBleHRl bnNpb24uICBFeGFtcGxlOiBJbiB0aGUgdGFnICJmci1hLUxhdG4iLCB0aGUNCiAgICAgICAg c3VidGFnICdMYXRuJyBkb2VzIG5vdCByZXByZXNlbnQgdGhlIHNjcmlwdCBzdWJ0YWcgJ0xh dG4nDQogICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5LiAgSXRzIG1lYW5pbmcgaXMNCiAgICAgICAgZGVmaW5lZCBieSB0aGUgZXh0ZW5zaW9u ICdhJy4NCg0KICAgMTEuICBJbiB0aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25lIGV4dGVu c2lvbiBhcHBlYXJzIGluIGEgc2luZ2xlDQogICAgICAgIHRhZywgdGhlIHRhZyBTSE9VTEQg YmUgY2Fub25pY2FsaXplZCBhcyBkZXNjcmliZWQgaW4NCiAgICAgICAgU2VjdGlvbiA0LjQu DQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUgcHJlZml4IHNpbmdsZXRvbiAncicgYW5kIHRo ZSBzaG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmluZWQsIHRoZW4gdGhlIGZvbGxvd2luZyB0 YWcgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlOiAiZW4tTGF0bi0NCiAgIEdCLWJvb250LXIt ZXh0ZW5kZWQtc2VxdWVuY2UteC1wcml2YXRlIg0KDQoyLjIuNy4gIFByaXZhdGUgVXNlIFN1 YnRhZ3MNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBk aXN0aW5jdGlvbnMgaW4gbGFuZ3VhZ2UNCiAgIGltcG9ydGFudCBpbiBhIGdpdmVuIGNvbnRl eHQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBUaGUgZm9sbG93aW5nDQogICBydWxlcyBhcHBs eSB0byBwcml2YXRlIHVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZSB1c2Ugc3VidGFn cyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAgICAg IGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0ZXIgc3Vi dGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVTVCBjb25mb3JtIHRv IHRoZSBmb3JtYXQgYW5kIGNvbnRlbnQNCiAgICAgICBjb25zdHJhaW50cyBkZWZpbmVkIGlu IHRoZSBBQk5GIGZvciBhbGwgc3VidGFncy4NCg0KICAgMy4gIFByaXZhdGUgdXNlIHN1YnRh Z3MgTVVTVCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAg ICBzY3JpcHQsIHJlZ2lvbiwgdmFyaWFudCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIGluIHRo ZSB0YWcuDQogICAgICAgQW5vdGhlciB3YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhhdCBhbGwg c3VidGFncyBmb2xsb3dpbmcgdGhlDQogICAgICAgc2luZ2xldG9uICd4JyBNVVNUIGJlIGNv bnNpZGVyZWQgcHJpdmF0ZSB1c2UuICBFeGFtcGxlOiBUaGUNCiAgICAgICBzdWJ0YWcgJ1VT JyBpbiB0aGUgdGFnICJlbi14LVVTIiBpcyBhIHByaXZhdGUgdXNlIHN1YnRhZy4NCg0KICAg NC4gIEEgdGFnIE1BWSBjb25zaXN0IGVudGlyZWx5IG9mIHByaXZhdGUgdXNlIHN1YnRhZ3Mu DQoNCiAgIDUuICBObyBzb3VyY2UgaXMgZGVmaW5lZCBmb3IgcHJpdmF0ZSB1c2Ugc3VidGFn cy4gIFVzZSBvZiBwcml2YXRlIHVzZQ0KICAgICAgIHN1YnRhZ3MgaXMgYnkgcHJpdmF0ZSBh Z3JlZW1lbnQgb25seS4NCg0KICAgNi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIE5PVCBS RUNPTU1FTkRFRCB3aGVyZSBhbHRlcm5hdGl2ZXMgZXhpc3QNCiAgICAgICBvciBmb3IgZ2Vu ZXJhbCBpbnRlcmNoYW5nZS4gIFNlZSBTZWN0aW9uIDQuNSBmb3IgbW9yZSBpbmZvcm1hdGlv bg0KICAgICAgIG9uIHByaXZhdGUgdXNlIHN1YnRhZyBjaG9pY2UuDQoNCiAgIEZvciBleGFt cGxlOiBVc2VycyB3aG8gd2lzaGVkIHRvIHV0aWxpemUgY29kZXMgZnJvbSB0aGUgRXRobm9s b2d1ZQ0KICAgcHVibGljYXRpb24gb2YgU0lMIEludGVybmF0aW9uYWwgZm9yIGxhbmd1YWdl IGlkZW50aWZpY2F0aW9uIG1pZ2h0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBh cyAiYXotQXJhYi14LUFaRS1kZXJiZW5kIi4gIFRoaXMgZXhhbXBsZQ0KICAgY29udGFpbnMg dHdvIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QgaXMgJ0FaRScgYW5kIHRoZSBz ZWNvbmQNCiAgIGlzICdkZXJiZW5kJy4NCg0KMi4yLjguICBHcmFuZGZhdGhlcmVkIFJlZ2lz dHJhdGlvbnMNCg0KICAgUHJpb3IgdG8gUkZDIDQ2NDYsIHdob2xlIGxhbmd1YWdlIHRhZ3Mg d2VyZSByZWdpc3RlcmVkIGFjY29yZGluZyB0bw0KICAgdGhlIHJ1bGVzIGluIFJGQyAxNzY2 IGFuZC9vciBSRkMgMzA2Ni4gIFRoZXNlIHJlZ2lzdGVyZWQgdGFncw0KICAgbWFpbnRhaW4g dGhlaXIgdmFsaWRpdHkuICBPZiB0aG9zZSB0YWdzLCB0aG9zZSB0aGF0IHdlcmUgbWFkZQ0K ICAgb2Jzb2xldGUgb3IgcmVkdW5kYW50IGJ5IHRoZSBhZHZlbnQgb2YgUkZDIDQ2NDYsIGJ5 IHRoaXMgZG9jdW1lbnQsIG9yDQogICBieSBzdWJzZXF1ZW50IHJlZ2lzdHJhdGlvbiBvZiBz dWJ0YWdzIGFyZSBtYWludGFpbmVkIGluIHRoZSByZWdpc3RyeQ0KICAgaW4gcmVjb3JkcyBh cyAicmVkdW5kYW50IiByZWNvcmRzLiAgVGhvc2UgdGFncyB0aGF0IGRvIG5vdCBtYXRjaCB0 aGUNCiAgICdsYW5ndGFnJyBwcm9kdWN0aW9uIGluIHRoZSBBQk5GIGluIHRoaXMgZG9jdW1l bnQgb3IgdGhhdCBjb250YWluDQogICBzdWJ0YWdzIHRoYXQgZG8gbm90IGluZGl2aWR1YWxs eSBhcHBlYXIgaW4gdGhlIHJlZ2lzdHJ5IGFyZQ0KICAgbWFpbnRhaW5lZCBpbiB0aGUgcmVn aXN0cnkgaW4gcmVjb3JkcyBvZiB0aGUgImdyYW5kZmF0aGVyZWQiIHR5cGUuDQoNCiAgIEdy YW5kZmF0aGVyZWQgdGFncyBjb250YWluIG9uZSBvciBtb3JlIHN1YnRhZ3MgdGhhdCBhcmUg bm90IGRlZmluZWQNCiAgIGluIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKHNlZSBT ZWN0aW9uIDMpLiAgUmVkdW5kYW50IHRhZ3MNCiAgIGNvbnNpc3QgZW50aXJlbHkgb2Ygc3Vi dGFncyBkZWZpbmVkIGFib3ZlIGFuZCB3aG9zZSBpbmRlcGVuZGVudA0KICAgcmVnaXN0cmF0 aW9uIHdhcyBzdXBlcnNlZGVkIGJ5IFtSRkM0NjQ2XS4gIEZvciBtb3JlIGluZm9ybWF0aW9u IHNlZQ0KICAgU2VjdGlvbiAzLjguDQoNCiAgIFNvbWUgZ3JhbmRmYXRoZXJlZCB0YWdzIGFy ZSAicmVndWxhciIgaW4gdGhhdCB0aGV5IG1hdGNoIHRoZQ0KICAgJ2xhbmd0YWcnIHByb2R1 Y3Rpb24gaW4gRmlndXJlIDEuICBJbiBzb21lIGNhc2VzLCB0aGVzZSB0YWdzIGNvdWxkDQog ICBiZWNvbWUgcmVkdW5kYW50IGlmIHRoZWlyIChjdXJyZW50IHVucmVnaXN0ZXJlZCkgc3Vi dGFncyB3ZXJlIHRvIGJlDQogICByZWdpc3RlcmVkIChhcyB2YXJpYW50cywgZm9yIGV4YW1w bGUpLiAgSW4gb3RoZXIgY2FzZXMsIGFsdGhvdWdoIHRoZQ0KICAgc3VidGFncyBtYXRjaCB0 aGUgbGFuZ3VhZ2UgdGFnIHBhdHRlcm4sIHRoZSBtZWFuaW5nIGFzc2lnbmVkIHRvIHRoZQ0K ICAgdmFyaW91cyBzdWJ0YWdzIGlzIHByb2hpYml0ZWQgYnkgcnVsZXMgZWxzZXdoZXJlIGlu IHRoaXMgZG9jdW1lbnQuDQogICBUaG9zZSB0YWdzIGNhbiBuZXZlciBiZWNvbWUgcmVkdW5k YW50Lg0KDQogICBUaGUgcmVtYWluaW5nIGdyYW5kZmF0aGVyZWQgdGFncyBhcmUgImlycmVn dWxhciIgYW5kIGRvIG5vdCBtYXRjaCB0aGUNCiAgICdsYW5ndGFnJyBwcm9kdWN0aW9uLiAg VGhlc2UgYXJlIGxpc3RlZCBpbiB0aGUgJ2lycmVndWxhcicgcHJvZHVjdGlvbg0KICAgaW4g RmlndXJlIDEuICBUaGVzZSBncmFuZGZhdGhlcmVkIHRhZ3MgY2FuIG5ldmVyIGJlY29tZSBy ZWR1bmRhbnQuDQogICBNYW55IG9mIHRoZXNlIHRhZ3MgaGF2ZSBiZWVuIHN1cGVyc2VkZWQg Ynkgb3RoZXIgcmVnaXN0cmF0aW9uczogdGhlaXINCiAgIHJlY29yZCBjb250YWlucyBhIFBy ZWZlcnJlZC1WYWx1ZSBmaWVsZCB0aGF0IHJlYWxseSBvdWdodCB0byBiZSB1c2VkDQogICB0 byBmb3JtIGxhbmd1YWdlIHRhZ3MgcmVwcmVzZW50aW5nIHRoYXQgdmFsdWUuDQoNCjIuMi45 LiAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZQ0KDQogICBJbXBsZW1lbnRhdGlvbnMgc29tZXRp bWVzIG5lZWQgdG8gZGVzY3JpYmUgdGhlaXIgY2FwYWJpbGl0aWVzIHdpdGgNCiAgIHJlZ2Fy ZCB0byB0aGUgcnVsZXMgYW5kIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVu dC4gIFRhZ3MNCiAgIGNhbiBiZSBjaGVja2VkIG9yIHZlcmlmaWVkIGluIGEgbnVtYmVyIG9m IHdheXMsIGJ1dCB0d28gcGFydGljdWxhcg0KICAgY2xhc3NlcyBvZiB0YWcgY29uZm9ybWFu Y2UgYXJlIGZvcm1hbGx5IGRlZmluZWQgaGVyZS4NCg0KICAgQSB0YWcgaXMgY29uc2lkZXJl ZCAid2VsbC1mb3JtZWQiIGlmIGl0IGNvbmZvcm1zIHRvIHRoZSBBQk5GDQogICAoU2VjdGlv biAyLjEpLiAgTm90ZSB0aGF0IGlycmVndWxhciBncmFuZGZhdGhlcmVkIHRhZ3MgYXJlIG5v dyBsaXN0ZWQNCiAgIGluIHRoZSAnaXJyZWd1bGFyJyBwcm9kdWN0aW9uLg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAg ICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIEEgdGFn IGlzIGNvbnNpZGVyZWQgInZhbGlkIiBpZiBpdCB3ZWxsLWZvcm1lZCBhbmQgaXQgYWxzbyBz YXRpc2ZpZXMNCiAgIHRoZXNlIGNvbmRpdGlvbnM6DQoNCiAgIG8gIFRoZSB0YWcgaXMgZWl0 aGVyIGEgZ3JhbmRmYXRoZXJlZCB0YWcsIG9yIGFsbCBvZiBpdHMgbGFuZ3VhZ2UsDQogICAg ICBleHRlbmRlZCBsYW5ndWFnZSwgc2NyaXB0LCByZWdpb24sIGFuZCB2YXJpYW50IHN1YnRh Z3MgYXBwZWFyIGluDQogICAgICB0aGUgSUFOQSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkg YXMgb2YgdGhlIHBhcnRpY3VsYXIgcmVnaXN0cnkNCiAgICAgIGRhdGUuDQoNCiAgIG8gIFRo ZXJlIGFyZSBubyBkdXBsaWNhdGUgc2luZ2xldG9uIChleHRlbnNpb24pIHN1YnRhZ3MgYW5k IG5vDQogICAgICBkdXBsaWNhdGUgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBvICBGb3IgZWFj aCBzdWJ0YWcgdGhhdCBoYXMgYSAnUHJlZml4JyBmaWVsZCBpbiB0aGUgcmVnaXN0cnksIHRo ZQ0KICAgICAgUHJlZml4IG1hdGNoZXMgdGhlIGxhbmd1YWdlIHRhZyB1c2luZyBFeHRlbmRl ZCBGaWx0ZXJpbmcNCiAgICAgIFtSRkM0NjQ3XS4gIFRoYXQgaXMsIGVhY2ggc3VidGFnIGlu IHRoZSBQcmVmaXggaXMgcHJlc2VudCBpbiB0aGUNCiAgICAgIHRhZyBhbmQgaW4gdGhlIHNh bWUgb3JkZXIuICBGb3IgZXhhbXBsZSwgdGhlIFByZWZpeCAiemgtVFciDQogICAgICBtYXRj aGVzIHRoZSB0YWcgInpoLUhhbnQtVFciLg0KDQogICBOb3RlIHRoYXQgYSB0YWcncyB2YWxp ZGl0eSBkZXBlbmRzIG9uIHRoZSBkYXRlIG9mIHRoZSByZWdpc3RyeSB1c2VkDQogICB0byB2 YWxpZGF0ZSB0aGUgdGFnLiAgQSBtb3JlLXJlY2VudCBjb3B5IG9mIHRoZSByZWdpc3RyeSBt aWdodA0KICAgY29udGFpbiBhIHN1YnRhZyB0aGF0IGFuIG9sZGVyIHZlcnNpb24gZG9lcyBu b3QuDQoNCiAgIEEgdGFnIGlzIGNvbnNpZGVyZWQgInZhbGlkIiBmb3IgYSBnaXZlbiBleHRl bnNpb24gKFNlY3Rpb24gMy43KSAoYXMNCiAgIG9mIGEgcGFydGljdWxhciB2ZXJzaW9uLCBy ZXZpc2lvbiwgYW5kIGRhdGUpIGlmIGl0IG1lZXRzIHRoZSBjcml0ZXJpYQ0KICAgZm9yICJ2 YWxpZCIgYWJvdmUgYW5kIGFsc28gc2F0aXNmaWVzIHRoaXMgY29uZGl0aW9uOg0KDQogICAg ICBFYWNoIHN1YnRhZyB1c2VkIGluIHRoZSBleHRlbnNpb24gcGFydCBvZiB0aGUgdGFnIGlz IHZhbGlkDQogICAgICBhY2NvcmRpbmcgdG8gdGhlIGV4dGVuc2lvbi4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDE5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KMy4gIFJlZ2lzdHJ5IEZvcm1hdCBhbmQg TWFpbnRlbmFuY2UNCg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZWdpc3RyeSBhbmQgdGhlIG1haW50ZW5hbmNlDQogICBhbmQgdXBkYXRlIHByb2Nl ZHVyZXMgYXNzb2NpYXRlZCB3aXRoIGl0LCBhcyB3ZWxsIGFzIGEgcmVnaXN0cnkgZm9yDQog ICBleHRlbnNpb25zIHRvIGxhbmd1YWdlIHRhZ3MgKFNlY3Rpb24gMy43KS4NCg0KICAgVGhl IExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBjb250YWlucyBhIGNvbXByZWhlbnNpdmUgbGlz dCBvZiBhbGwgb2YNCiAgIHRoZSBzdWJ0YWdzIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBU aGlzIGFsbG93cyBpbXBsZW1lbnRlcnMgYQ0KICAgc3RyYWlnaHRmb3J3YXJkIGFuZCByZWxp YWJsZSB3YXkgdG8gdmFsaWRhdGUgbGFuZ3VhZ2UgdGFncy4gIFRoZQ0KICAgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5IHdpbGwgYmUgbWFpbnRhaW5lZCBzbyB0aGF0LCBleGNlcHQgZm9y DQogICBleHRlbnNpb24gc3VidGFncywgaXQgaXMgcG9zc2libGUgdG8gdmFsaWRhdGUgYWxs IG9mIHRoZSBzdWJ0YWdzIHRoYXQNCiAgIGFwcGVhciBpbiBhIGxhbmd1YWdlIHRhZyB1bmRl ciB0aGUgcHJvdmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50IG9yIGl0cw0KICAgcmV2aXNpb25z IG9yIHN1Y2Nlc3NvcnMuICBJbiBhZGRpdGlvbiwgdGhlIG1lYW5pbmcgb2YgdGhlIHZhcmlv dXMNCiAgIHN1YnRhZ3Mgd2lsbCBiZSB1bmFtYmlndW91cyBhbmQgc3RhYmxlIG92ZXIgdGlt ZS4gIChUaGUgbWVhbmluZyBvZg0KICAgcHJpdmF0ZSB1c2Ugc3VidGFncywgb2YgY291cnNl LCBpcyBub3QgZGVmaW5lZCBieSB0aGUgSUFOQSByZWdpc3RyeS4pDQoNCjMuMS4gIEZvcm1h dCBvZiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkNCg0KICAgVGhlIElBTkEg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICgidGhlIHJlZ2lzdHJ5IikgY29uc2lzdHMgb2Yg YSB0ZXh0DQogICBmaWxlIHRoYXQgaXMgbWFjaGluZSByZWFkYWJsZSBpbiB0aGUgZm9ybWF0 IGRlc2NyaWJlZCBpbiB0aGlzDQogICBzZWN0aW9uLCBwbHVzIGNvcGllcyBvZiB0aGUgcmVn aXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGluIGFjY29yZGFuY2UNCiAgIHdpdGggdGhlIHBy b2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LiAgVGhlIGV4aXN0aW5nIHJlZ2lzdHJh dGlvbg0KICAgZm9ybXMgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzIHRh a2VuIGZyb20gUkZDIDMwNjYgd2lsbA0KICAgYmUgbWFpbnRhaW5lZCBhcyBwYXJ0IG9mIHRo ZSBvYnNvbGV0ZSBSRkMgMzA2NiByZWdpc3RyeS4gIFRoZQ0KICAgcmVtYWluaW5nIHNldCBv ZiBpbml0aWFsIHN1YnRhZ3Mgd2lsbCBub3QgaGF2ZSByZWdpc3RyYXRpb24gZm9ybXMNCiAg IGNyZWF0ZWQgZm9yIHRoZW0uDQoNCjMuMS4xLiAgRmlsZSBGb3JtYXQNCg0KICAgVGhlIHJl Z2lzdHJ5IGlzIGluIHRoZSB0ZXh0IGZvcm1hdCBkZXNjcmliZWQgYmVsb3cuICBUaGlzIGZv cm1hdCB3YXMNCiAgIGJhc2VkIG9uIHRoZSByZWNvcmQtamFyIGZvcm1hdCBkZXNjcmliZWQg aW4gW3JlY29yZC1qYXJdLg0KDQogICBFYWNoIGxpbmUgb2YgdGV4dCBpcyBsaW1pdGVkIHRv IDcyIGNoYXJhY3RlcnMsIGluY2x1ZGluZyBhbGwNCiAgIHdoaXRlc3BhY2UuICBSZWNvcmRz IGFyZSBzZXBhcmF0ZWQgYnkgbGluZXMgY29udGFpbmluZyBvbmx5IHRoZQ0KICAgc2VxdWVu Y2UgIiUlIiAoJXgyNS4yNSkuDQoNCiAgIEVhY2ggZmllbGQgY2FuIGJlIHZpZXdlZCBhcyBh IHNpbmdsZSwgbG9naWNhbCBsaW5lIG9mIEFTQ0lJDQogICBjaGFyYWN0ZXJzLCBjb21wcmlz aW5nIGEgZmllbGQtbmFtZSBhbmQgYSBmaWVsZC1ib2R5IHNlcGFyYXRlZCBieSBhDQogICBD T0xPTiBjaGFyYWN0ZXIgKCV4M0EpLiAgRm9yIGNvbnZlbmllbmNlLCB0aGUgZmllbGQtYm9k eSBwb3J0aW9uIG9mDQogICB0aGlzIGNvbmNlcHR1YWwgZW50aXR5IGNhbiBiZSBzcGxpdCBp bnRvIGEgbXVsdGlwbGUtbGluZQ0KICAgcmVwcmVzZW50YXRpb247IHRoaXMgaXMgY2FsbGVk ICJmb2xkaW5nIi4gIFRoZSBmb3JtYXQgb2YgdGhlIHJlZ2lzdHJ5DQogICBpcyBkZXNjcmli ZWQgYnkgdGhlIGZvbGxvd2luZyBBQk5GIChwZXIgW1JGQzQyMzRdKToNCg0KDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K ICAgcmVnaXN0cnkgICA9IHJlY29yZCAqKCIlJSIgQ1JMRiByZWNvcmQpDQogICByZWNvcmQg ICAgID0gMSooIGZpZWxkLW5hbWUgKlNQICI6IiAqU1AgZmllbGQtYm9keSBDUkxGICkNCiAg IGZpZWxkLW5hbWUgPSAoQUxQSEEgLyBESUdJVCkgWyooQUxQSEEgLyBESUdJVCAvICItIikg KEFMUEhBIC8gRElHSVQpXQ0KICAgZmllbGQtYm9keSA9ICooQVNDQ0hBUi9MV1NQKQ0KICAg QVNDQ0hBUiAgICA9ICV4MjEtMjUgLyAleDI3LTdFIC8gVU5JQ0hBUiA7IE5vdGU6IEFNUEVS U0FORCBpcyAleDI2DQogICBVTklDSEFSICAgID0gIiYjeCIgMio2SEVYRElHICI7Ig0KDQog ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IFJlZ2lzdHJ5IEZvcm1hdCBBQk5GDQoN CiAgIFRoZSBzZXF1ZW5jZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3Rl cyBhIHJhbmdlIG9mDQogICB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVwcmVzZW50cyBhbGwg c3VidGFncyBvZiB0aGUgc2FtZSBsZW5ndGggdGhhdA0KICAgYXJlIGluIGFscGhhYmV0aWMg b3IgbnVtZXJpYyBvcmRlciB3aXRoaW4gdGhhdCByYW5nZSwgaW5jbHVkaW5nIHRoZQ0KICAg dmFsdWVzIGV4cGxpY2l0bHkgbWVudGlvbmVkLiAgRm9yIGV4YW1wbGUgJ2EuLmMnIGRlbm90 ZXMgdGhlIHZhbHVlcw0KICAgJ2EnLCAnYicsIGFuZCAnYycgYW5kICcxMS4uMTMnIGRlbm90 ZXMgdGhlIHZhbHVlcyAnMTEnLCAnMTInLCBhbmQNCiAgICcxMycuDQoNCiAgIENoYXJhY3Rl cnMgZnJvbSBvdXRzaWRlIHRoZSBVUy1BU0NJSSBbSVNPNjQ2XSByZXBlcnRvaXJlLCBhcyB3 ZWxsIGFzDQogICB0aGUgQU1QRVJTQU5EIGNoYXJhY3RlciAoIiYiLCAleDI2KSB3aGVuIGl0 IG9jY3VycyBpbiBhIGZpZWxkLWJvZHksDQogICBhcmUgcmVwcmVzZW50ZWQgYnkgYSAiTnVt ZXJpYyBDaGFyYWN0ZXIgUmVmZXJlbmNlIiB1c2luZyBoZXhhZGVjaW1hbA0KICAgbm90YXRp b24gaW4gdGhlIHN0eWxlIHVzZWQgYnkgW1hNTDEwXSAoc2VlDQogICA8aHR0cDovL3d3dy53 My5vcmcvVFIvUkVDLXhtbC8jZHQtY2hhcnJlZj4pLiAgVGhpcyBjb25zaXN0cyBvZiB0aGUN CiAgIHNlcXVlbmNlICImI3giICgleDI2LjIzLjc4KSBmb2xsb3dlZCBieSBhIGhleGFkZWNp bWFsIHJlcHJlc2VudGF0aW9uDQogICBvZiB0aGUgY2hhcmFjdGVyJ3MgY29kZSBwb2ludCBp biBbSVNPMTA2NDZdIGZvbGxvd2VkIGJ5IGEgY2xvc2luZw0KICAgc2VtaWNvbG9uICgleDNC KS4gIEZvciBleGFtcGxlLCB0aGUgRVVSTyBTSUdOLCBVKzIwQUMsIHdvdWxkIGJlDQogICBy ZXByZXNlbnRlZCBieSB0aGUgc2VxdWVuY2UgIiYjeDIwQUM7Ii4gIE5vdGUgdGhhdCB0aGUg aGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9uIE1BWSBoYXZlIGJldHdlZW4gdHdvIGFuZCBzaXgg ZGlnaXRzLg0KDQogICBBbGwgZmllbGRzIHdob3NlIGZpZWxkLWJvZHkgY29udGFpbnMgYSBk YXRlIHZhbHVlIHVzZSB0aGUgImZ1bGwtZGF0ZSINCiAgIGZvcm1hdCBzcGVjaWZpZWQgaW4g W1JGQzMzMzldLiAgRm9yIGV4YW1wbGU6ICIyMDA0LTA2LTI4IiByZXByZXNlbnRzDQogICBK dW5lIDI4LCAyMDA0LCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQozLjEuMi4gIFJl Y29yZCBEZWZpbml0aW9ucw0KDQogICBUaGVyZSBhcmUgdGhyZWUgdHlwZXMgb2YgcmVjb3Jk cyBpbiB0aGUgcmVnaXN0cnk6ICJGaWxlLURhdGUiLA0KICAgIlN1YnRhZyIsIGFuZCAiVGFn IiByZWNvcmRzLg0KDQogICBUaGUgZmlyc3QgcmVjb3JkIGluIHRoZSByZWdpc3RyeSBpcyBh ICJGaWxlLURhdGUiIHJlY29yZC4gIFRoaXMNCiAgIHJlY29yZCBjb250YWlucyB0aGUgc2lu Z2xlIGZpZWxkIHdob3NlIGZpZWxkLW5hbWUgaXMgIkZpbGUtRGF0ZSIgKHNlZQ0KICAgRmln dXJlIDIpLiAgVGhlIGZpZWxkLWJvZHkgb2YgdGhpcyByZWNvcmQgY29udGFpbnMgdGhlIGxh c3QNCiAgIG1vZGlmaWNhdGlvbiBkYXRlIG9mIHRoaXMgY29weSBvZiB0aGUgcmVnaXN0cnks IG1ha2luZyBpdCBwb3NzaWJsZSB0bw0KICAgY29tcGFyZSBkaWZmZXJlbnQgdmVyc2lvbnMg b2YgdGhlIHJlZ2lzdHJ5LiAgVGhlIHJlZ2lzdHJ5IG9uIHRoZSBJQU5BDQogICB3ZWJzaXRl IGlzIHRoZSBtb3N0IGN1cnJlbnQuICBWZXJzaW9ucyB3aXRoIGFuIG9sZGVyIGRhdGUgdGhh biB0aGF0DQogICBvbmUgYXJlIG5vdCB1cC10by1kYXRlLg0KDQogICBGaWxlLURhdGU6IDIw MDQtMDYtMjgNCiAgICUlDQoNCiAgICAgICAgICAgICAgICAgRmlndXJlIDM6IEV4YW1wbGUg b2YgdGhlIEZpbGUtRGF0ZSBSZWNvcmQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgU3Vic2VxdWVudCByZWNvcmRzIHJlcHJlc2Vu dCBlaXRoZXIgc3VidGFncyBvciB0YWdzIGluIHRoZSByZWdpc3RyeS4NCiAgICJTdWJ0YWci IHJlY29yZHMgY29udGFpbiBhIGZpZWxkIHdpdGggYSBmaWVsZC1uYW1lIG9mICJTdWJ0YWci LA0KICAgd2hpbGUsIHVuc3VycHJpc2luZ2x5LCAiVGFnIiByZWNvcmRzIGNvbnRhaW4gYSBm aWVsZCB3aXRoIGEgZmllbGQtDQogICBuYW1lIG9mICJUYWciLiAgRWFjaCBvZiB0aGUgZmll bGRzIGluIGVhY2ggcmVjb3JkIE1VU1Qgb2NjdXIgbm8gbW9yZQ0KICAgdGhhbiBvbmNlLCB1 bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkIGJlbG93LiAgRWFjaCByZWNvcmQgTVVTVCBjb250YWlu DQogICB0aGUgZm9sbG93aW5nIGZpZWxkczoNCg0KICAgbyAgJ1R5cGUnDQoNCiAgICAgICog IFR5cGUncyBmaWVsZC1ib2R5IE1VU1QgY29uc2lzdCBvZiBvbmUgb2YgdGhlIGZvbGxvd2lu ZyBzdHJpbmdzOg0KICAgICAgICAgImxhbmd1YWdlIiwgImV4dGxhbmciLCAic2NyaXB0Iiwg InJlZ2lvbiIsICJ2YXJpYW50IiwNCiAgICAgICAgICJncmFuZGZhdGhlcmVkIiwgYW5kICJy ZWR1bmRhbnQiIGFuZCBkZW5vdGVzIHRoZSB0eXBlIG9mIHRhZyBvcg0KICAgICAgICAgc3Vi dGFnLg0KDQogICBvICBFaXRoZXIgJ1N1YnRhZycgb3IgJ1RhZycNCg0KICAgICAgKiAgU3Vi dGFnJ3MgZmllbGQtYm9keSBjb250YWlucyB0aGUgc3VidGFnIGJlaW5nIGRlZmluZWQuICBU aGlzDQogICAgICAgICBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgb2Ygd2hv c2UgJ1R5cGUnIGhhcyBvbmUgb2YNCiAgICAgICAgIHRoZXNlIHZhbHVlczogImxhbmd1YWdl IiwgImV4dGxhbmciLCAic2NyaXB0IiwgInJlZ2lvbiIsIG9yDQogICAgICAgICAidmFyaWFu dCIuDQoNCiAgICAgICogIFRhZydzIGZpZWxkLWJvZHkgY29udGFpbnMgYSBjb21wbGV0ZSBs YW5ndWFnZSB0YWcuICBUaGlzIGZpZWxkDQogICAgICAgICBNVVNUIG9ubHkgYXBwZWFyIGlu IHJlY29yZHMgd2hvc2UgJ1R5cGUnIGhhcyBvbmUgb2YgdGhlc2UNCiAgICAgICAgIHZhbHVl czogImdyYW5kZmF0aGVyZWQiIG9yICJyZWR1bmRhbnQiLiAgTm90ZSB0aGF0IHRoZSBmaWVs ZC0NCiAgICAgICAgIGJvZHkgd2lsbCBhbHdheXMgZm9sbG93IHRoZSAnZ3JhbmRmYXRoZXJl ZCcgcHJvZHVjdGlvbiBpbiB0aGUNCiAgICAgICAgIEFCTkYgaW4gU2VjdGlvbiAyLjENCg0K ICAgbyAgRGVzY3JpcHRpb24NCg0KICAgICAgKiAgRGVzY3JpcHRpb24ncyBmaWVsZC1ib2R5 IGNvbnRhaW5zIGEgbm9uLW5vcm1hdGl2ZSBkZXNjcmlwdGlvbg0KICAgICAgICAgb2YgdGhl IHN1YnRhZyBvciB0YWcuDQoNCiAgIG8gIEFkZGVkDQoNCiAgICAgICogIEFkZGVkJ3MgZmll bGQtYm9keSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRlZCB0bw0KICAg ICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBFYWNoIHJlY29yZCBNQVkgYWxzbyBjb250YWlu IHRoZSBmb2xsb3dpbmcgZmllbGRzOg0KDQogICBvICBQcmVmZXJyZWQtVmFsdWUNCg0KICAg ICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICdzY3JpcHQnLCAncmVnaW9uJywgYW5kICd2YXJp YW50JywNCiAgICAgICAgICdQcmVmZXJyZWQtVmFsdWUnIGNvbnRhaW5zIHRoZSBzdWJ0YWcg b2YgdGhlIHNhbWUgJ1R5cGUnIHRoYXQNCiAgICAgICAgIGlzIHByZWZlcnJlZCBmb3IgZm9y bWluZyB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUg J2xhbmd1YWdlJyBhbmQgJ2V4dGxhbmcnLCAnUHJlZmVycmVkLVZhbHVlJw0KICAgICAgICAg Y29udGFpbnMgdGhlIGxhbmd1YWdlIHByb2R1Y3Rpb24gKHNlZSBGaWd1cmUgMSkgdGhhdCBp cw0KICAgICAgICAgcHJlZmVycmVkIHdoZW4gZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLiAg VGhpcyBjYW4gYmUgc2ltcGx5IGENCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICBBcHJpbCAyMDA3DQoNCg0KICAgICAgICAgJ2xhbmd1YWdlJyBzdWJ0YWcsIG9yIGl0 IGNhbiBiZSBhICdsYW5ndWFnZScgc3VidGFnIGZvbGxvd2VkIGJ5DQogICAgICAgICBhbiBl eHRlbmRlZCBsYW5ndWFnZSBzZXF1ZW5jZS4NCg0KICAgICAgKiAgRm9yIGZpZWxkcyBvZiB0 eXBlICdncmFuZGZhdGhlcmVkJyBhbmQgJ3JlZHVuZGFudCcsIGEgY2Fub25pY2FsDQogICAg ICAgICBtYXBwaW5nIHRvIGEgY29tcGxldGUgbGFuZ3VhZ2UgdGFnLg0KDQogICBvICBEZXBy ZWNhdGVkDQoNCiAgICAgICogIERlcHJlY2F0ZWQncyBmaWVsZC1ib2R5IGNvbnRhaW5zIHRo ZSBkYXRlIHRoZSByZWNvcmQgd2FzDQogICAgICAgICBkZXByZWNhdGVkLg0KDQogICBvICBQ cmVmaXgNCg0KICAgICAgKiAgUHJlZml4J3MgZmllbGQtYm9keSBjb250YWlucyBhIGxhbmd1 YWdlIHRhZyB3aXRoIHdoaWNoIHRoaXMNCiAgICAgICAgIHN1YnRhZyBNQVkgYmUgdXNlZCB0 byBmb3JtIGEgbmV3IGxhbmd1YWdlIHRhZywgcGVyaGFwcyB3aXRoDQogICAgICAgICBvdGhl ciBzdWJ0YWdzIGFzIHdlbGwuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVj b3Jkcw0KICAgICAgICAgd2hvc2UgJ1R5cGUnIGZpZWxkLWJvZHkgaXMgJ3ZhcmlhbnQnIG9y ICdleHRsYW5nJy4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwgdGhlICdQcmVmaXgnIGZvciB0 aGUgdmFyaWFudCAnbmVkaXMnIGlzICdzbCcsIG1lYW5pbmcNCiAgICAgICAgIHRoYXQgdGhl IHRhZ3MgInNsLW5lZGlzIiBhbmQgInNsLUlULW5lZGlzIiBtaWdodCBiZSBhcHByb3ByaWF0 ZQ0KICAgICAgICAgd2hpbGUgdGhlIHRhZyAiaXMtbmVkaXMiIGlzIG5vdC4NCg0KICAgbyAg Q29tbWVudHMNCg0KICAgICAgKiAgQ29tbWVudHMgY29udGFpbnMgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBhYm91dCB0aGUgc3VidGFnLCBhcw0KICAgICAgICAgZGVlbWVkIGFwcHJvcHJp YXRlIGZvciB1bmRlcnN0YW5kaW5nIHRoZSByZWdpc3RyeSBhbmQNCiAgICAgICAgIGltcGxl bWVudGluZyBsYW5ndWFnZSB0YWdzIHVzaW5nIHRoZSBzdWJ0YWcgb3IgdGFnLg0KDQogICBv ICBTdXBwcmVzcy1TY3JpcHQNCg0KICAgICAgKiAgU3VwcHJlc3MtU2NyaXB0IGNvbnRhaW5z IGEgc2NyaXB0IHN1YnRhZyB0aGF0IFNIT1VMRCBOT1QgYmUNCiAgICAgICAgIHVzZWQgdG8g Zm9ybSBsYW5ndWFnZSB0YWdzIHdpdGggdGhlIGFzc29jaWF0ZWQgcHJpbWFyeSBsYW5ndWFn ZQ0KICAgICAgICAgc3VidGFnLiAgVGhpcyBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJl Y29yZHMgd2hvc2UgJ1R5cGUnDQogICAgICAgICBmaWVsZC1ib2R5IGlzICdsYW5ndWFnZScu ICBTZWUgU2VjdGlvbiA0LjEuDQoNCiAgIEZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGlzIGRvY3Vt ZW50IG1pZ2h0IGFkZCBhZGRpdGlvbmFsIGZpZWxkcyB0byB0aGUNCiAgIHJlZ2lzdHJ5LCBz byBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGlnbm9yZSBmaWVsZHMgZm91bmQgaW4gdGhlDQog ICByZWdpc3RyeSB0aGF0IGFyZSBub3QgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoz LjEuMy4gIFN1YnRhZyBhbmQgVGFnIEZpZWxkcw0KDQogICBUaGUgJ1N1YnRhZycgZmllbGQg TVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUgc3VidGFnLA0KICAgd2l0 aCB0d28gZXhjZXB0aW9ucy4gIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUnIGZpZWxkIGlzICdzY3Jp cHQnIChpbg0KICAgb3RoZXIgd29yZHMsIHN1YnRhZ3MgZGVmaW5lZCBieSBJU08gMTU5MjQp IE1VU1QgdXNlIHRpdGxlY2FzZS4NCiAgIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUnIGZpZWxkIGlz ICdyZWdpb24nIChpbiBvdGhlciB3b3Jkcywgc3VidGFncw0KICAgZGVmaW5lZCBieSBJU08g MzE2NikgTVVTVCB1c2UgdXBwZXJjYXNlLiAgVGhlc2UgZXhjZXB0aW9ucyBtaXJyb3IgdGhl DQogICB1c2Ugb2YgY2FzZSBpbiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMuDQoNCiAgIEVh Y2ggc3VidGFnIGluIHRoZSB0YWdzIGNvbnRhaW5lZCBpbiBhICdUYWcnIGZpZWxkIE1VU1Qg YmUgZm9ybWF0dGVkDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNw0KDQoNCiAgIHVzaW5nIHRoZSBydWxlcyBpbiB0aGUgcHJlY2VlZGluZyBwYXJh Z3JhcGguICBUaGF0IGlzLCBhbGwgc3VidGFncw0KICAgYXJlIGxvd2VyY2FzZSBleGNlcHQg Zm9yIHN1YnRhZ3MgdGhhdCByZXByZXNlbnQgc2NyaXB0IG9yIHJlZ2lvbg0KICAgY29kZXMu DQoNCjMuMS40LiAgRGVzY3JpcHRpb24gRmllbGQNCg0KICAgVGhlIGZpZWxkICdEZXNjcmlw dGlvbicgY29udGFpbnMgYSBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIG9yIHN1YnRhZw0KICAg aW4gdGhlIHJlY29yZC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIE1BWSBhcHBlYXIgbW9y ZSB0aGFuIG9uY2UgcGVyDQogICByZWNvcmQsIHRoYXQgaXMsIHRoZXJlIGNhbiBiZSBtdWx0 aXBsZSBkZXNjcmlwdGlvbnMgZm9yIGEgZ2l2ZW4NCiAgIHJlY29yZC4gIEF0IGxlYXN0IG9u ZSBvZiB0aGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMgTVVTVCBiZSB3cml0dGVuIG9yDQogICB0 cmFuc2NyaWJlZCBpbnRvIHRoZSBMYXRpbiBzY3JpcHQ7IGFkZGl0aW9uYWwgJ0Rlc2NyaXB0 aW9uJyBmaWVsZHMNCiAgIE1BWSBhbHNvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5v bi1MYXRpbiBzY3JpcHQuICBFYWNoDQogICAnRGVzY3JpcHRpb24nIGZpZWxkIE1VU1QgYmUg dW5pcXVlLCBib3RoIHdpdGhpbiB0aGUgcmVjb3JkIGluIHdoaWNoDQogICBpdCBhcHBlYXJz IGFuZCBmb3IgdGhlIGNvbGxlY3Rpb24gb2YgcmVjb3JkcyBvZiB0aGUgc2FtZSB0eXBlLg0K ICAgTW9yZW92ZXIsIGZvcm1hdHRpbmcgdmFyaWF0aW9ucyBvZiB0aGUgc2FtZSBkZXNjcmlw dGlvbiBNVVNUIE5PVA0KICAgb2NjdXIgaW4gdGhhdCBzcGVjaWZpYyByZWNvcmQgb3IgaW4g YW55IG90aGVyIHJlY29yZCBvZiB0aGUgc2FtZQ0KICAgdHlwZS4gIEZvciBleGFtcGxlLCB3 aGlsZSB0aGUgSVNPIDYzOS0xIGNvZGUgJ2Z5JyBjb250YWlucyBib3RoIHRoZQ0KICAgZGVz Y3JpcHRpb25zICJXZXN0ZXJuIEZyaXNpYW4iIGFuZCAiRnJpc2lhbiwgV2VzdGVybiIsIG9u bHkgb25lIG9mDQogICB0aGVzZSBkZXNjcmlwdGlvbnMgYXBwZWFycyBpbiB0aGUgcmVnaXN0 cnkuDQoNCiAgIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZp Y2F0aW9uIHB1cnBvc2VzIGFuZA0KICAgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXByZXNl bnQgdGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUNCiAgIGxhbmd1YWdlIG9yIHZhcmlh dGlvbiBvciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCg0KICAgRm9yIHJl Y29yZHMgdGFrZW4gZnJvbSBhIHNvdXJjZSBzdGFuZGFyZCAoc3VjaCBhcyBJU08gNjM5IG9y IElTTw0KICAgMzE2NiksIHRoZSAnRGVzY3JpcHRpb24nIHZhbHVlKHMpIFNIT1VMRCBhbHNv IGJlIHRha2VuIGZyb20gdGhlDQogICBzb3VyY2Ugc3RhbmRhcmQuICBNdWx0aXBsZSBkZXNj cmlwdGlvbnMgaW4gdGhlIHNvdXJjZSBzdGFuZGFyZCBNVVNUDQogICBiZSBzcGxpdCBpbnRv IHNlcGFyYXRlICdEZXNjcmlwdGlvbicgZmllbGRzLiAgVGhlIHNvdXJjZSBzdGFuZGFyZCdz DQogICBkZXNjcmlwdGlvbnMgTUFZIGJlIGVkaXRlZCwgZWl0aGVyIHByaW9yIHRvIGluc2Vy dGlvbiBvciB2aWEgdGhlDQogICByZWdpc3RyYXRpb24gcHJvY2Vzcy4gIEZvciBmaWVsZHMg b2YgdHlwZSAnbGFuZ3VhZ2UnIG9yICdleHRsYW5nJywNCiAgIHRoZSBmaXJzdCAnRGVzY3Jp cHRpb24nIGZpZWxkIGFwcGVhcmluZyBpbiB0aGUgUmVnaXN0cnkgY29ycmVzcG9uZHMNCiAg IHRvIHRoZSBSZWZlcmVuY2UgTmFtZSBhc3NpZ25lZCBieSBJU08gNjM5LTMuICBUaGlzIGhl bHBzIGZhY2lsaXRhdGUNCiAgIGNyb3NzLXJlZmVyZW5jaW5nIGJldHdlZW4gSVNPIDYzOSBh bmQgdGhlIHJlZ2lzdHJ5Lg0KDQogICBXaGVuIGNyZWF0aW5nIG9yIHVwZGF0aW5nIGEgcmVj b3JkIGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUNCiAgIHNvdXJjZSBzdGFuZGFy ZHMsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgU0hPVUxEIHJlbW92ZQ0KICAgZHVw bGljYXRlIG9yIHJlZHVuZGFudCBkZXNjcmlwdGlvbnMgYW5kIE1BWSBlZGl0IGRlc2NyaXB0 aW9ucyB0bw0KICAgY29ycmVjdCBpcnJlZ3VsYXJpdGllcyBpbiBmb3JtYXR0aW5nIChzdWNo IGFzIG1pc3NwZWxsaW5ncywNCiAgIGluYXBwcm9wcmlhdGUgYXBvc3Ryb3BoZXMgb3Igb3Ro ZXIgcHVuY3R1YXRpb24sIG9yIGV4Y2Vzc2l2ZSBvcg0KICAgbWlzc2luZyBzcGFjZXMpIHBy aW9yIHRvIHN1Ym1pdHRpbmcgdGhlIHByb3Bvc2VkIHJlY29yZCB0byB0aGUgaWV0Zi0NCiAg IGxhbmd1YWdlcyBsaXN0Lg0KDQogICBOb3RlOiBEZXNjcmlwdGlvbnMgaW4gcmVnaXN0cnkg ZW50cmllcyB0aGF0IGNvcnJlc3BvbmQgdG8gSVNPIDYzOSwNCiAgIElTTyAxNTkyNCwgSVNP IDMxNjYsIG9yIFVOIE0uNDkgY29kZXMgYXJlIGludGVuZGVkIG9ubHkgdG8gaW5kaWNhdGUN CiAgIHRoZSBtZWFuaW5nIG9mIHRoYXQgaWRlbnRpZmllciBhcyBkZWZpbmVkIGluIHRoZSBz b3VyY2Ugc3RhbmRhcmQgYXQNCiAgIHRoZSB0aW1lIGl0IHdhcyBhZGRlZCB0byB0aGUgcmVn aXN0cnkuICBUaGUgZGVzY3JpcHRpb24gZG9lcyBub3QNCiAgIHJlcGxhY2UgdGhlIGNvbnRl bnQgb2YgdGhlIHNvdXJjZSBzdGFuZGFyZCBpdHNlbGYuICBUaGUgZGVzY3JpcHRpb25zDQog ICBhcmUgbm90IGludGVuZGVkIHRvIGJlIHRoZSBFbmdsaXNoIGxvY2FsaXplZCBuYW1lcyBm b3IgdGhlIHN1YnRhZ3MuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNw0KDQoNCiAgIExvY2FsaXphdGlvbiBvciB0cmFuc2xhdGlvbiBvZiBsYW5n dWFnZSB0YWcgYW5kIHN1YnRhZyBkZXNjcmlwdGlvbnMNCiAgIGlzIG91dCBvZiBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQozLjEuNS4gIERlcHJlY2F0ZWQgRmllbGQNCg0KICAgVGhl IGZpZWxkICdEZXByZWNhdGVkJyBNQVkgYmUgYWRkZWQgdG8gYW55IHJlY29yZCB2aWEgdGhl IG1haW50ZW5hbmNlDQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMyBvciB2 aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjUuICBVc3VhbGx5LCB0aGUgYWRkaXRpb24gb2YgYSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxk IGlzIGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUgc3RhbmRhcmRzIGJvZGllcywg c3VjaCBhcw0KICAgSVNPIDMxNjYsIHdpdGhkcmF3aW5nIGEgY29kZS4gIEluIHNvbWUgaGlz dG9yaWNhbCBjYXNlcywgaXQgbWlnaHQgbm90DQogICBoYXZlIGJlZW4gcG9zc2libGUgdG8g cmVjb25zdHJ1Y3QgdGhlIG9yaWdpbmFsIGRlcHJlY2F0aW9uIGRhdGUuICBGb3INCiAgIHRo ZXNlIGNhc2VzLCBhbiBhcHByb3hpbWF0ZSBkYXRlIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5 LiAgQWx0aG91Z2gNCiAgIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIHN1YnRhZ3MgYW5kIHRh Z3Mgd2l0aCBhICdEZXByZWNhdGVkJyBmaWVsZA0KICAgYXJlIGRlcHJlY2F0ZWQgYW5kIHZh bGlkYXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UIGdlbmVyYXRlIHRoZXNlDQogICBzdWJ0 YWdzLiAgTm90ZSB0aGF0IGEgcmVjb3JkIHRoYXQgY29udGFpbnMgYSAnRGVwcmVjYXRlZCcg ZmllbGQgYW5kDQogICBubyBjb3JyZXNwb25kaW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxk IGhhcyBubyByZXBsYWNlbWVudCBtYXBwaW5nLg0KDQozLjEuNi4gIFByZWZlcnJlZC1WYWx1 ZSBGaWVsZA0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJlZC1WYWx1ZScgY29udGFpbnMgYSBt YXBwaW5nIGJldHdlZW4gdGhlIHJlY29yZCBpbg0KICAgd2hpY2ggaXQgYXBwZWFycyBhbmQg YW5vdGhlciB0YWcgb3Igc3VidGFnLiAgVGhlIHZhbHVlIGluIHRoaXMgZmllbGQNCiAgIGlz IHN0cm9uZ2x5IFJFQ09NTUVOREVEIGFzIHRoZSBiZXN0IGNob2ljZSB0byByZXByZXNlbnQg dGhlIHZhbHVlIG9mDQogICB0aGlzIHJlY29yZCB3aGVuIHNlbGVjdGluZyBhIGxhbmd1YWdl IHRhZy4gIFRoZXNlIHZhbHVlcyBmb3JtIHRocmVlDQogICBncm91cHM6DQoNCiAgIDEuICBJ U08gNjM5IGxhbmd1YWdlIGNvZGVzIHRoYXQgd2VyZSBsYXRlciB3aXRoZHJhd24gaW4gZmF2 b3Igb2YNCiAgICAgICBvdGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUgbW9zdGx5IGEg aGlzdG9yaWNhbCBjdXJpb3NpdHkuDQoNCiAgIDIuICBJU08gMzE2NiByZWdpb24gY29kZXMg dGhhdCBoYXZlIGJlZW4gd2l0aGRyYXduIGluIGZhdm9yIG9mIGEgbmV3DQogICAgICAgY29k ZS4gIFRoaXMgc29tZXRpbWVzIGhhcHBlbnMgd2hlbiBhIGNvdW50cnkgY2hhbmdlcyBpdHMg bmFtZSBvcg0KICAgICAgIGFkbWluaXN0cmF0aW9uIGluIHN1Y2ggYSB3YXkgdGhhdCB3YXJy YW50cyBhIG5ldyByZWdpb24gY29kZS4NCg0KICAgMy4gIEdyYW5kZmF0aGVyZWQgb3IgcmVk dW5kYW50IHRhZ3MgZnJvbSBSRkMgMzA2Ni4gIEluIG1hbnkgY2FzZXMsDQogICAgICAgdGhl c2UgdGFncyBoYXZlIGJlY29tZSBvYnNvbGV0ZSBiZWNhdXNlIHRoZSB2YWx1ZXMgdGhleSBy ZXByZXNlbnQNCiAgICAgICB3ZXJlIGxhdGVyIGVuY29kZWQgYnkgSVNPIDYzOS4NCg0KICAg UmVjb3JkcyB0aGF0IGNvbnRhaW4gYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBNVVNUIGFs c28gaGF2ZSBhDQogICAnRGVwcmVjYXRlZCcgZmllbGQuICBUaGlzIGZpZWxkIGNvbnRhaW5z IGEgZGF0ZSBvZiBkZXByZWNhdGlvbi4NCiAgIFRodXMsIGEgbGFuZ3VhZ2UgdGFnIHByb2Nl c3NvciBjYW4gdXNlIHRoZSByZWdpc3RyeSB0byBjb25zdHJ1Y3QgdGhlDQogICB2YWxpZCwg bm9uLWRlcHJlY2F0ZWQgc2V0IG9mIHN1YnRhZ3MgZm9yIGEgZ2l2ZW4gZGF0ZS4gIEluIGFk ZGl0aW9uLA0KICAgZm9yIGFueSBnaXZlbiB0YWcsIGEgcHJvY2Vzc29yIGNhbiBjb25zdHJ1 Y3QgdGhlIHNldCBvZiB2YWxpZA0KICAgbGFuZ3VhZ2UgdGFncyB0aGF0IGNvcnJlc3BvbmQg dG8gdGhhdCB0YWcgZm9yIGFsbCBkYXRlcyB1cCB0byB0aGUNCiAgIGRhdGUgb2YgdGhlIHJl Z2lzdHJ5LiAgVGhlIGFiaWxpdHkgdG8gZG8gdGhlc2UgbWFwcGluZ3MgTUFZIGJlDQogICBi ZW5lZmljaWFsIHRvIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBtYXRjaGluZywgc2VsZWN0aW5n LCBmb3INCiAgIGZpbHRlcmluZyBjb250ZW50IGJhc2VkIG9uIGl0cyBsYW5ndWFnZSB0YWdz Lg0KDQogICBOb3RlIHRoYXQgJ1ByZWZlcnJlZC1WYWx1ZScgbWFwcGluZ3MgaW4gcmVjb3Jk cyBvZiB0eXBlICdyZWdpb24nDQogICBzb21ldGltZXMgZG8gbm90IHJlcHJlc2VudCBleGFj dGx5IHRoZSBzYW1lIG1lYW5pbmcgYXMgdGhlIG9yaWdpbmFsDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBb UGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIHZhbHVlLiAgVGhlcmUg YXJlIG1hbnkgcmVhc29ucyBmb3IgYSBjb3VudHJ5IGNvZGUgdG8gYmUgY2hhbmdlZCwgYW5k DQogICB0aGUgZWZmZWN0IHRoaXMgaGFzIG9uIHRoZSBmb3JtYXRpb24gb2YgbGFuZ3VhZ2Ug dGFncyB3aWxsIGRlcGVuZCBvbg0KICAgdGhlIG5hdHVyZSBvZiB0aGUgY2hhbmdlIGluIHF1 ZXN0aW9uLg0KDQogICBJbiBwYXJ0aWN1bGFyLCB0aGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmll bGQgZG9lcyBub3QgaW1wbHkgcmV0YWdnaW5nDQogICBjb250ZW50IHRoYXQgdXNlcyB0aGUg YWZmZWN0ZWQgc3VidGFnLg0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJlZC1WYWx1ZScgTVVT VCBOT1QgYmUgbW9kaWZpZWQgb25jZSBjcmVhdGVkIGluIHRoZQ0KICAgcmVnaXN0cnkuICBU aGUgZmllbGQgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgYWNjb3JkaW5nIHRvIHRoZSBydWxl cw0KICAgaW4gU2VjdGlvbiAzLjMuDQoNCiAgIFRoZSAnUHJlZmVycmVkLVZhbHVlJyBmaWVs ZCBpbiByZWNvcmRzIG9mIHR5cGUgImdyYW5kZmF0aGVyZWQiIGFuZA0KICAgInJlZHVuZGFu dCIgY29udGFpbnMgd2hvbGUgbGFuZ3VhZ2UgdGFncyB0aGF0IGFyZSBzdHJvbmdseQ0KICAg UkVDT01NRU5ERUQgZm9yIHVzZSBpbiBwbGFjZSBvZiB0aGUgcmVjb3JkJ3MgdmFsdWUuICBJ biBtYW55IGNhc2VzLA0KICAgdGhlIG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBkZXByZWNh dGlvbiBvZiB0aGUgdGFncyBkdXJpbmcgdGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9j dW1lbnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4i IHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEtZGVmaW5lZCBsYW5n dWFnZSBjb2RlDQogICAnbm4nLg0KDQozLjEuNy4gIFByZWZpeCBGaWVsZA0KDQogICBUaGUg ZmllbGQgb2YgdHlwZSAnUHJlZml4JyBNVVNUIE5PVCBiZSByZW1vdmVkIGZyb20gYW55IHJl Y29yZC4gIFRoZQ0KICAgZmllbGQtYm9keSBmb3IgdGhpcyB0eXBlIG9mIGZpZWxkIE1BWSBi ZSBtb2RpZmllZCwgYnV0IG9ubHkgaWYgdGhlDQogICBtb2RpZmljYXRpb24gYnJvYWRlbnMg dGhlIG1lYW5pbmcgb2YgdGhlIHN1YnRhZy4gIFRoYXQgaXMsIHRoZSBmaWVsZC0NCiAgIGJv ZHkgY2FuIGJlIHJlcGxhY2VkIG9ubHkgYnkgYSBwcmVmaXggYSBwcmVmaXggb2YgaXRzZWxm LiAgRm9yDQogICBleGFtcGxlLCB0aGUgUHJlZml4ICJiZS1MYXRuIiAoQmVsYXJ1c2lhbiwg TGF0aW4gc2NyaXB0KSBjb3VsZCBiZQ0KICAgcmVwbGFjZWQgYnkgdGhlIFByZWZpeCAiYmUi IChCZWxhcnVzaWFuKSBidXQgbm90IGJ5IHRoZSBQcmVmaXggInJ1LQ0KICAgTGF0biIgKFJ1 c3NpYW4sIExhdGluIHNjcmlwdCkuDQoNCiAgIFRoZSBmaWVsZC1ib2R5IG9mIHRoZSAnUHJl Zml4JyBmaWVsZCBjb25zaXN0cyBvZiBhIGxhbmd1YWdlIHRhZyB3aG9zZQ0KICAgc3VidGFn cyBhcmUgYXBwcm9wcmlhdGUgdG8gdXNlIHdpdGggdGhpcyBzdWJ0YWcuICBGb3IgZXhhbXBs ZSwgdGhlDQogICB2YXJpYW50IHN1YnRhZyAnMTk5NicgaGFzIGEgJ1ByZWZpeCcgZmllbGQg b2YgImRlIi4gIFRoaXMgbWVhbnMgdGhhdA0KICAgdGFncyBzdGFydGluZyB3aXRoIHRoZSBz ZXF1ZW5jZSAiZGUtIiBhcmUgYXBwcm9wcmlhdGUgd2l0aCB0aGlzDQogICBzdWJ0YWcsIHNv ICJkZS1MYXRnLTE5OTYiIGFuZCAiZGUtQ0gtMTk5NiIgYXJlIGJvdGggYWNjZXB0YWJsZSwg d2hpbGUNCiAgIHRoZSB0YWcgImZyLTE5OTYiIGlzIGFuIGluYXBwcm9wcmlhdGUgY2hvaWNl Lg0KDQogICBSZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBv bmUgZmllbGQgb2YgdHlwZQ0KICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0 aGlzIHR5cGUgTUFZIGJlIGFkZGVkIHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRo ZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgVGhlIGZpZWxkLWJvZHkgb2YgdGhlICdQ cmVmaXgnIGZpZWxkIE1VU1QgTk9UIGNvbmZsaWN0IHdpdGggYW55DQogICAnUHJlZml4JyBh bHJlYWR5IHJlZ2lzdGVyZWQgZm9yIGEgZ2l2ZW4gcmVjb3JkLiAgU3VjaCBhIGNvbmZsaWN0 DQogICB3b3VsZCBvY2N1ciB3aGVuIHdoZW4gbm8gdmFsaWQgdGFnIGNvdWxkIGJlIGNvbnN0 cnVjdGVkIHRoYXQgd291bGQNCiAgIGNvbnRhaW4gdGhlIHByZWZpeCwgc3VjaCBhcyB3aGVu IHdoZW4gdHdvIHN1YnRhZ3MgZWFjaCBoYXZlIGENCiAgICdQcmVmaXgnIHRoYXQgY29udGFp bnMgdGhlIG90aGVyIHN1YnRhZy4gIEZvciBleGFtcGxlLCBzdXBwb3NlIHRoYXQNCiAgIHRo ZSBzdWJ0YWcgJ2F2YXJpYW50JyBoYXMgdGhlIHByZWZpeCAiZXMtYnZhcmlhbnQiLiAgVGhl biB0aGUgc3VidGFnDQogICAnYnZhcmlhbnQnIGNhbm5vdCBnaXZlbiB0aGUgcHJlZml4ICdh dmFyaWFudCcsIGZvciB0aGF0IHdvdWxkIHJlcXVpcmUNCiAgIGEgdGFnIG9mIHRoZSBmb3Jt ICJlcy1hdmFyaWFudC1idmFyaWFudC1hdmFyaWFudCIsIHdoaWNoIHdvdWxkIG5vdCBiZQ0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3 ICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQog ICB2YWxpZC4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhhdmUgX2V4 YWN0bHlfIG9uZSAnUHJlZml4JyBmaWVsZC4NCg0KMy4xLjguICBDb21tZW50cyBGaWVsZA0K DQogICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIHBl ciByZWNvcmQuICBUaGlzDQogICBmaWVsZCBNQVkgYmUgaW5zZXJ0ZWQgb3IgY2hhbmdlZCB2 aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGFuZCBubw0KICAgZ3VhcmFudGVlIG9mIHN0 YWJpbGl0eSBpcyBwcm92aWRlZC4gIFRoZSBjb250ZW50IG9mIHRoaXMgZmllbGQgaXMgbm90 DQogICByZXN0cmljdGVkLCBleGNlcHQgYnkgdGhlIG5lZWQgdG8gcmVnaXN0ZXIgdGhlIGlu Zm9ybWF0aW9uLCB0aGUNCiAgIHN1aXRhYmlsaXR5IG9mIHRoZSByZXF1ZXN0LCBhbmQgYnkg cmVhc29uYWJsZSBwcmFjdGljYWwgc2l6ZQ0KICAgbGltaXRhdGlvbnMuDQoNCjMuMS45LiAg U3VwcHJlc3MtU2NyaXB0IEZpZWxkDQoNCiAgIFRoZSBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0 JyBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgd2hvc2UgJ1R5cGUnDQogICBmaWVsZC1i b2R5IGlzICdsYW5ndWFnZScuICBUaGlzIGZpZWxkIE1VU1QgTk9UIGFwcGVhciBtb3JlIHRo YW4gb25lDQogICB0aW1lIGluIGEgcmVjb3JkLiAgVGhpcyBmaWVsZCBpbmRpY2F0ZXMgYSBz Y3JpcHQgdXNlZCB0byB3cml0ZSB0aGUNCiAgIG92ZXJ3aGVsbWluZyBtYWpvcml0eSBvZiBk b2N1bWVudHMgZm9yIHRoZSBnaXZlbiBsYW5ndWFnZSBhbmQgdGhhdA0KICAgdGhlcmVmb3Jl IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gYSBsYW5ndWFnZSB0YWcu ICBJdA0KICAgaGVscHMgZW5zdXJlIGdyZWF0ZXIgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRo ZSBsYW5ndWFnZSB0YWdzDQogICBnZW5lcmF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBp biB0aGlzIGRvY3VtZW50IGFuZCBsYW5ndWFnZSB0YWdzDQogICBhbmQgdGFnIHByb2Nlc3Nv cnMgb3IgY29uc3VtZXJzIGJhc2VkIG9uIFJGQyAzMDY2LiAgRm9yIGV4YW1wbGUsDQogICB2 aXJ0dWFsbHkgYWxsIEljZWxhbmRpYyBkb2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4gdGhlIExh dGluIHNjcmlwdCwNCiAgIG1ha2luZyB0aGUgc3VidGFnICdMYXRuJyByZWR1bmRhbnQgaW4g dGhlIHRhZyAiaXMtTGF0biIuDQoNCiAgIE1hbnkgbGFuZ3VhZ2Ugc3VidGFnIHJlY29yZHMg ZG8gbm90IGhhdmUgYSBTdXBwcmVzcy1TY3JpcHQgZmllbGQuDQogICBUaGUgbGFjayBvZiBh IFN1cHByZXNzLVNjcmlwdCBtaWdodCBpbmRpY2F0ZSB0aGF0IHRoZSBsYW5ndWFnZSBpcw0K ICAgY3VzdG9tYXJpbHkgd3JpdHRlbiBpbiBtb3JlIHRoYW4gb25lIHNjcmlwdCBvciB0aGF0 IHRoZSBsYW5ndWFnZSBpcw0KICAgbm90IGN1c3RvbWFyaWx5IHdyaXR0ZW4gYXQgYWxsLiAg SXQgbWlnaHQgYWxzbyBtZWFuIHRoYXQgc3VmZmljaWVudA0KICAgaW5mb3JtYXRpb24gd2Fz IG5vdCBhdmFpbGFibGUgd2hlbiB0aGUgcmVjb3JkIHdhcyBjcmVhdGVkIGFuZCB0aHVzDQog ICByZW1haW5zIGEgY2FuZGlkYXRlIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9uLg0KDQozLjIu ICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXINCg0KICAgVGhlIExhbmd1YWdlIFN1YnRhZyBS ZXZpZXdlciBtb2RlcmF0ZXMgdGhlIGlldGYtbGFuZ3VhZ2VzIG1haWxpbmcNCiAgIGxpc3Qs IHJlc3BvbmRzIHRvIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24sIGFuZCBwZXJmb3JtcyB0 aGUgb3RoZXINCiAgIHJlZ2lzdHJ5IG1haW50ZW5hbmNlIGR1dGllcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjMuICBPbmx5IHRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGlz IHBlcm1pdHRlZCB0byByZXF1ZXN0IElBTkEgdG8gY2hhbmdlLA0KICAgdXBkYXRlLCBvciBh ZGQgcmVjb3JkcyB0byB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5LiAgVGhlIExhbmd1 YWdlDQogICBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGRlbGVnYXRlIGxpc3QgbW9kZXJhdGlvbiBh bmQgb3RoZXIgY2xlcmljYWwNCiAgIGR1dGllcyBhcyBuZWVkZWQuDQoNCiAgIFRoZSBMYW5n dWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaXMgYXBwb2ludGVkIGJ5IHRoZSBJRVNHIGZvciBhbg0K ICAgaW5kZWZpbml0ZSB0ZXJtLCBzdWJqZWN0IHRvIHJlbW92YWwgb3IgcmVwbGFjZW1lbnQg YXQgdGhlIElFU0cncw0KICAgZGlzY3JldGlvbi4gIFRoZSBJRVNHIHdpbGwgc29saWNpdCBu b21pbmVlcyBmb3IgdGhlIHBvc2l0aW9uDQogICAoaW5pdGlhbGx5IG9yIHVwb24gYSB2YWNh bmN5KSBhbmQgc2VlayB0byBhc2NlcnRhaW4gdGhlIGNhbmRpZGF0ZXMnDQogICBxdWFsaWZp Y2F0aW9ucy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1i ZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAy MDA3DQoNCg0KICAgVGhlIHN1YnNlcXVlbnQgcGVyZm9ybWFuY2Ugb3IgZGVjaXNpb25zIG9m IHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgIFJldmlld2VyIE1BWSBiZSBhcHBlYWxlZCB0byB0 aGUgSUVTRyB1bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhlcg0KICAgSUVURiBkZWNpc2lv bnMgKHNlZSBbUkZDMjAyNl0pLiAgVGhlIElFU0cgY2FuIHJldmVyc2Ugb3Igb3ZlcnR1cm4g dGhlDQogICBkZWNpc2lvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBwcm92 aWRlIGd1aWRhbmNlLCBvciB0YWtlDQogICBvdGhlciBhcHByb3ByaWF0ZSBhY3Rpb25zLg0K DQozLjMuICBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ug b2YgdGhlIHJlZ2lzdHJ5IHJlcXVpcmVzIHRoYXQgYXMgY29kZXMgYXJlIGFzc2lnbmVkIG9y DQogICB3aXRoZHJhd24gYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVO IE0uNDksIHRoZSBMYW5ndWFnZQ0KICAgU3VidGFnIFJldmlld2VyIE1VU1QgZXZhbHVhdGUg ZWFjaCBjaGFuZ2UsIGRldGVybWluZSB3aGV0aGVyIGl0DQogICBjb25mbGljdHMgd2l0aCBl eGlzdGluZyByZWdpc3RyeSBlbnRyaWVzLCBhbmQgc3VibWl0IHRoZSBpbmZvcm1hdGlvbg0K ICAgdG8gSUFOQSBmb3IgaW5jbHVzaW9uIGluIHRoZSByZWdpc3RyeS4gIElmIGEgY2hhbmdl IHRha2VzIHBsYWNlIGFuZA0KICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkb2Vz IG5vdCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5lciwNCiAgIHRoZW4gYW55IGludGVyZXN0 ZWQgcGFydHkgTUFZIHVzZSB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24gMy41IHRvDQogICBy ZWdpc3RlciB0aGUgYXBwcm9wcmlhdGUgdXBkYXRlLg0KDQogICBOb3RlOiBUaGUgcmVkdW5k YW50IGFuZCBncmFuZGZhdGhlcmVkIGVudHJpZXMgdG9nZXRoZXIgYXJlIHRoZQ0KICAgY29t cGxldGUgbGlzdCBvZiB0YWdzIHJlZ2lzdGVyZWQgdW5kZXIgW1JGQzMwNjZdLiAgVGhlIHJl ZHVuZGFudCB0YWdzDQogICBhcmUgdGhvc2UgdGhhdCBjYW4gbm93IGJlIGZvcm1lZCB1c2lu ZyB0aGUgc3VidGFncyBkZWZpbmVkIGluIHRoZQ0KICAgcmVnaXN0cnkgdG9nZXRoZXIgd2l0 aCB0aGUgcnVsZXMgb2YgU2VjdGlvbiAyLjIuICBUaGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50 cmllcyBpbmNsdWRlIHRob3NlIHRoYXQgY2FuIG5ldmVyIGJlIGxlZ2FsIHVuZGVyIHRob3Nl IHNhbWUNCiAgIHByb3Zpc2lvbnMgcGx1cyB0aG9zZSB0YWdzIHRoYXQgY29udGFpbiBzdWJ0 YWdzIG5vdCB5ZXQgcmVnaXN0ZXJlZA0KICAgb3IsIHBlcmhhcHMsIGluYXBwcm9wcmlhdGUg Zm9yIHJlZ2lzdHJhdGlvbi4NCg0KICAgVGhlIHNldCBvZiByZWR1bmRhbnQgYW5kIGdyYW5k ZmF0aGVyZWQgdGFncyBpcyBwZXJtYW5lbnQgYW5kIHN0YWJsZToNCiAgIG5ldyBlbnRyaWVz IGluIHRoaXMgc2VjdGlvbiBNVVNUIE5PVCBiZSBhZGRlZCBhbmQgZXhpc3RpbmcgZW50cmll cw0KICAgTVVTVCBOT1QgYmUgcmVtb3ZlZC4gIFJlY29yZHMgb2YgdHlwZSAnZ3JhbmRmYXRo ZXJlZCcgTUFZIGhhdmUgdGhlaXINCiAgIHR5cGUgY29udmVydGVkIHRvICdyZWR1bmRhbnQn OyBzZWUgaXRlbSAxMiBpbiBTZWN0aW9uIDMuNiBmb3IgbW9yZQ0KICAgaW5mb3JtYXRpb24u ICBUaGUgZGVjaXNpb24tbWFraW5nIHByb2Nlc3MgYWJvdXQgd2hpY2ggdGFncyB3ZXJlDQog ICBpbml0aWFsbHkgZ3JhbmRmYXRoZXJlZCBhbmQgd2hpY2ggd2VyZSBtYWRlIHJlZHVuZGFu dCBpcyBkZXNjcmliZWQgaW4NCiAgIFtSRkM0NjQ1XS4NCg0KICAgUkZDIDMwNjYgdGFncyB0 aGF0IHdlcmUgZGVwcmVjYXRlZCBwcmlvciB0byB0aGUgYWRvcHRpb24gb2YgW1JGQzQ2NDZd DQogICBhcmUgcGFydCBvZiB0aGUgbGlzdCBvZiBncmFuZGZhdGhlcmVkIHRhZ3MsIGFuZCB0 aGVpciBjb21wb25lbnQNCiAgIHN1YnRhZ3Mgd2VyZSBub3QgaW5jbHVkZWQgYXMgcmVnaXN0 ZXJlZCB2YXJpYW50cyAoYWx0aG91Z2ggdGhleQ0KICAgcmVtYWluIGVsaWdpYmxlIGZvciBy ZWdpc3RyYXRpb24pLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImFydC1sb2piYW4iDQogICB3 YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnICdqYm8nLg0K DQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgZW5zdXJlIHRoYXQgbmV3 IHN1YnRhZ3MgbWVldCB0aGUNCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQuMSBvciBz dWJtaXQgYW4gYXBwcm9wcmlhdGUgYWx0ZXJuYXRlIHN1YnRhZw0KICAgYXMgZGVzY3JpYmVk IGluIHRoYXQgc2VjdGlvbi4gIFdoZW4gZWl0aGVyIGEgY2hhbmdlIG9yIGFkZGl0aW9uIHRv DQogICB0aGUgcmVnaXN0cnkgaXMgbmVlZGVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmll d2VyIE1VU1QgcHJlcGFyZSB0aGUNCiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFs bCBmaWVsZHMsIGFuZCBmb3J3YXJkIGl0IHRvIElBTkEgZm9yDQogICBpbnNlcnRpb24gaW50 byB0aGUgcmVnaXN0cnkuICBFYWNoIHJlY29yZCBiZWluZyBtb2RpZmllZCBvciBpbnNlcnRl ZA0KICAgTVVTVCBiZSBmb3J3YXJkZWQgaW4gYSBzZXBhcmF0ZSBtZXNzYWdlLg0KDQogICBJ ZiBhIHJlY29yZCByZXByZXNlbnRzIGEgbmV3IHN1YnRhZyB0aGF0IGRvZXMgbm90IGN1cnJl bnRseSBleGlzdCBpbg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFw cmlsIDIwMDcNCg0KDQogICB0aGUgcmVnaXN0cnksIHRoZW4gdGhlIG1lc3NhZ2UncyBzdWJq ZWN0IGxpbmUgTVVTVCBpbmNsdWRlIHRoZSB3b3JkDQogICAiSU5TRVJUIi4gIElmIHRoZSBy ZWNvcmQgcmVwcmVzZW50cyBhIGNoYW5nZSB0byBhbiBleGlzdGluZyBzdWJ0YWcsDQogICB0 aGVuIHRoZSBzdWJqZWN0IGxpbmUgb2YgdGhlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHRoZSB3 b3JkICJNT0RJRlkiLg0KICAgVGhlIG1lc3NhZ2UgTVVTVCBjb250YWluIGJvdGggdGhlIHJl Y29yZCBmb3IgdGhlIHN1YnRhZyBiZWluZw0KICAgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgYW5k IHRoZSBuZXcgRmlsZS1EYXRlIHJlY29yZC4gIEhlcmUgaXMgYW4NCiAgIGV4YW1wbGUgb2Yg d2hhdCB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZSBtaWdodCBjb250YWluOg0KDQogICBMQU5H VUFHRSBTVUJUQUcgTU9ESUZJQ0FUSU9ODQogICBGaWxlLURhdGU6IDIwMDUtMDEtMDINCiAg ICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IG5lZGlzDQogICBEZXNjcmlwdGlv bjogTmF0aXNvbmUgZGlhbGVjdA0KICAgRGVzY3JpcHRpb246IE5hZGl6YSBkaWFsZWN0DQog ICBBZGRlZDogMjAwMy0xMC0wOQ0KICAgUHJlZml4OiBzbA0KICAgQ29tbWVudHM6IFRoaXMg aXMgYSBjb21tZW50IHNob3duDQogICAgIGFzIGFuIGV4YW1wbGUuDQogICAlJQ0KDQogICAg ICAgICBGaWd1cmUgNDogRXhhbXBsZSBvZiBhIExhbmd1YWdlIFN1YnRhZyBNb2RpZmljYXRp b24gRm9ybQ0KDQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVk IGluIHRoZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBz dGFydCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9z dCByZWNlbnQgbW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhlIFtSRkMzMzM5XSAiZnVsbC1kYXRl IiBmb3JtYXQuDQoNCiAgIEJlZm9yZSBmb3J3YXJkaW5nIGEgbmV3IHJlZ2lzdHJhdGlvbiB0 byBJQU5BLCB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZXZpZXdlciBNVVNUIGVuc3VyZSB0 aGF0IHZhbHVlcyBpbiB0aGUgJ1N1YnRhZycgZmllbGQgbWF0Y2ggY2FzZQ0KICAgYWNjb3Jk aW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBpbiBTZWN0aW9uIDMuMS4NCg0KMy40LiAgU3RhYmls aXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVu dHJpZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzDQogICBjcml0aWNh bCB0byB0aGUgbG9uZy10ZXJtIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJ1 bGVzIGluDQogICB0aGlzIHNlY3Rpb24gZ3VhcmFudGVlIHRoYXQgYSBzcGVjaWZpYyBsYW5n dWFnZSB0YWcncyBtZWFuaW5nIGlzDQogICBzdGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5v dCBjaGFuZ2UuDQoNCiAgIFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBkZWFsIHdpdGggaG93 IGNoYW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVj YXRpb24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAxNTkyNCwg SVNPIDMxNjYsIGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFuZ3Vh Z2UNCiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1 YWdlIFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFi aWxpdHkgcnVsZXM6DQoNCiAgIDEuICAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ1R5cGUnLCAn U3VidGFnJywgJ1RhZycsICdBZGRlZCcsDQogICAgICAgICdEZXByZWNhdGVkJyBhbmQgJ1By ZWZlcnJlZC1WYWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlDQogICAgICAgIGd1 YXJhbnRlZWQgdG8gYmUgc3RhYmxlIG92ZXIgdGltZS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBb UGFnZSAyOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIDIuICAgVmFsdWVzIGlu IHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIE1VU1QgTk9UIGJlIGNoYW5nZWQgaW4gYSB3YXkN CiAgICAgICAgdGhhdCB3b3VsZCBpbnZhbGlkYXRlIHByZXZpb3VzbHktZXhpc3RpbmcgdGFn cy4gIFRoZXkgTUFZIGJlDQogICAgICAgIGJyb2FkZW5lZCBzb21ld2hhdCBpbiBzY29wZSwg Y2hhbmdlZCB0byBhZGQgaW5mb3JtYXRpb24sIG9yDQogICAgICAgIGFkYXB0ZWQgdG8gdGhl IG1vc3QgY29tbW9uIG1vZGVybiB1c2FnZS4gIEZvciBleGFtcGxlLCBjb3VudHJpZXMNCiAg ICAgICAgb2NjYXNpb25hbGx5IGNoYW5nZSB0aGVpciBvZmZpY2lhbCBuYW1lczsgYSBoaXN0 b3JpY2FsIGV4YW1wbGUNCiAgICAgICAgb2YgdGhpcyB3b3VsZCBiZSAiVXBwZXIgVm9sdGEi IGNoYW5naW5nIHRvICJCdXJraW5hIEZhc28iLg0KDQogICAzLiAgIFZhbHVlcyBpbiB0aGUg ZmllbGQgJ1ByZWZpeCcgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgb2YgdHlwZQ0KICAgICAg ICAndmFyaWFudCcgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4gIElmIGEgcHJlZml4 IGlzIGFkZGVkIHRvDQogICAgICAgIGEgdmFyaWFudCByZWNvcmQsICdDb21tZW50JyBmaWVs ZHMgU0hPVUxEIGJlIHVzZWQgdG8gZXhwbGFpbg0KICAgICAgICBkaWZmZXJlbnQgdXNhZ2Vz IHdpdGggdGhlIHZhcmlvdXMgcHJlZml4ZXMuDQoNCiAgIDQuICAgVmFsdWVzIGluIHRoZSBm aWVsZCAnUHJlZml4JyBpbiByZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBiZQ0KICAg ICAgICBtb2RpZmllZCwgc28gbG9uZyBhcyB0aGUgbW9kaWZpY2F0aW9ucyBicm9hZGVuIHRo ZSBzZXQgb2YNCiAgICAgICAgcHJlZml4ZXMuICBUaGF0IGlzLCBhIHByZWZpeCBNQVkgYmUg cmVwbGFjZWQgYnkgb25lIG9mIGl0cyBvd24NCiAgICAgICAgcHJlZml4ZXMuICBGb3IgZXhh bXBsZSwgdGhlIHByZWZpeCAiZW4tVVMiIGNvdWxkIGJlIHJlcGxhY2VkIGJ5DQogICAgICAg ICJlbiIsIGJ1dCBub3QgYnkgdGhlIHByZWZpeGVzICJlbi1MYXRuIiwgImZyIiwgb3IgImVu LVVTLWJvb250Ii4NCiAgICAgICAgSWYgb25lIG9mIHRob3NlIHByZWZpeGVzIHdlcmUgbmVl ZGVkLCBhIG5ldyBQcmVmaXggU0hPVUxEIGJlDQogICAgICAgIHJlZ2lzdGVyZWQuDQoNCiAg IDUuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4JyBpbiByZWNvcmRzIG9mIHR5cGUg J2V4dGxhbmcnIE1VU1QNCiAgICAgICAgTk9UIGJlIG1vZGlmaWVkLg0KDQogICA2LiAgIFZh bHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZC4NCg0KICAg Ny4gICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkgYmUgYWRkZWQsIGNoYW5nZWQsIG1vZGlm aWVkLCBvciByZW1vdmVkDQogICAgICAgIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mg b3IgYW55IG9mIHRoZSBwcm9jZXNzZXMgb3INCiAgICAgICAgY29uc2lkZXJhdGlvbnMgZGVz Y3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0KICAgOC4gICBUaGUgZmllbGQgJ1N1cHByZXNz LVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgICByZWdp c3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgOS4gICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5 LTEgdGhhdCBkbyBub3QgY29uZmxpY3Qgd2l0aCBleGlzdGluZw0KICAgICAgICB0d28tbGV0 dGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgd2hpY2ggaGF2ZSBubw0KICAgICAg ICBjb3JyZXNwb25kaW5nIHRocmVlLWxldHRlciBwcmltYXJ5IG9yIGV4dGVuZGVkIGxhbmd1 YWdlIHN1YnRhZ3MNCiAgICAgICAgZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnkgYXJlIGVudGVy ZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgICBuZXcgcmVjb3JkcyBvZiB0 eXBlICdsYW5ndWFnZScuDQoNCiAgIDEwLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOS0y IHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAgdGhyZWUtbGV0 dGVyIHByaW1hcnkgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgZW50ZXJlZA0K ICAgICAgICBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzIG9mIHR5cGUg J2xhbmd1YWdlJy4NCg0KICAgMTEuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LTMgdGhh dCBkbyBub3QgY29uZmxpY3Qgd2l0aCBleGlzdGluZw0KICAgICAgICB0aHJlZS1sZXR0ZXIg cHJpbWFyeSBvciBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFyZSBlbnRlcmVkDQogICAg ICAgIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29yZHMuDQoNCiAgICAgICAg MS4gIENvZGVzIHRoYXQgaGF2ZSBhIGRlZmluZWQgIm1hY3JvLWxhbmd1YWdlIiBtYXBwaW5n IGF0IHRoZQ0KICAgICAgICAgICAgdGltZSBvZiB0aGVpciByZWdpc3RyYXRpb24gTVVTVCBi ZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzMF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgICAgICAgICAgIGFzIHJlY29yZHMgb2Yg dHlwZSAnZXh0bGFuZycgd2l0aCBhICdQcmVmaXgnIGZpZWxkDQogICAgICAgICAgICBjb250 YWluaW5nIHRoZSBhcHByb3ByaWF0ZSBwcmVmaXggdGFnLg0KDQogICAgICAgIDIuICBDb2Rl cyB0aGF0IHJlcHJlc2VudCBzaWduIGxhbmd1YWdlcyBNVVNUIGJlIGVudGVyZWQgaW50byB0 aGUNCiAgICAgICAgICAgIHJlZ2lzdHJ5IGFzIHJlY29yZCBvZiB0eXBlICdleHRsYW5nJyB3 aXRoIGEgJ1ByZWZpeCcgZmllbGQNCiAgICAgICAgICAgIHRoYXQgbWF0Y2hlcyB0aGUgQmFz aWMgTGFuZ3VhZ2UgUmFuZ2UgInNnbiIgKHNlZSBTZWN0aW9uDQogICAgICAgICAgICAzLjMu MSAiQmFzaWMgRmlsdGVyaW5nIiBpbiBbUkZDNDY0N10pLg0KDQogICAgICAgIDMuICBBbGwg b3RoZXIgY29kZXMgTVVTVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFzIHJlY29y ZHMNCiAgICAgICAgICAgIG9mIHR5cGUgJ2xhbmd1YWdlJy4NCg0KICAgMTIuICBBIHJlY29y ZCBvZiB0eXBlICdsYW5ndWFnZScgb3IgJ2V4dGxhbmcnIE1VU1QgTk9UIGJlIHJlZ2lzdGVy ZWQNCiAgICAgICAgaWYgdGhlcmUgZXhpc3RzIGEgcmVjb3JkIG9mIGVpdGhlciB0eXBlIHdp dGggdGhlIHNhbWUgc3VidGFnDQogICAgICAgIHZhbHVlLiAgRm9yIGV4YW1wbGUsIGlmIGFu ICdleHRsYW5nJyBzdWJ0YWcgJ2ZvbycgZXhpc3RzIGluIHRoZQ0KICAgICAgICByZWdpc3Ry eSwgYWxsIGF0dGVtcHRzIHRvIHJlZ2lzdGVyIGEgJ2xhbmd1YWdlJyBzdWJ0YWcgJ2ZvbycN CiAgICAgICAgd2lsbCBiZSByZWplY3RlZC4NCg0KICAgMTMuICBDb2RlcyBhc3NpZ25lZCBi eSBJU08gMTU5MjQgYW5kIElTTyAzMTY2IHRoYXQgZG8gbm90IGNvbmZsaWN0DQogICAgICAg IHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlIGFuZCB3aG9z ZSBtZWFuaW5nDQogICAgICAgIGlzIG5vdCB0aGUgc2FtZSBhcyBhbiBleGlzdGluZyBzdWJ0 YWcgb2YgdGhlIHNhbWUgdHlwZSBhcmUNCiAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5B IHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzLg0KDQogICAxNC4gIENvZGVzIGFzc2lnbmVkIGJ5 IElTTyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBhcmUNCiAgICAgICAgd2l0 aGRyYXduIGJ5IHRoZWlyIHJlc3BlY3RpdmUgbWFpbnRlbmFuY2Ugb3IgcmVnaXN0cmF0aW9u DQogICAgICAgIGF1dGhvcml0eSByZW1haW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIEEg J0RlcHJlY2F0ZWQnIGZpZWxkDQogICAgICAgIGNvbnRhaW5pbmcgdGhlIGRhdGUgb2Ygd2l0 aGRyYXdhbCBNVVNUIGJlIGFkZGVkIHRvIHRoZSByZWNvcmQuDQogICAgICAgIElmIGEgbmV3 IHJlY29yZCBvZiB0aGUgc2FtZSB0eXBlIGlzIGFkZGVkIHRoYXQgcmVwcmVzZW50cyBhDQog ICAgICAgIHJlcGxhY2VtZW50IHZhbHVlLCB0aGVuIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmll bGQgTUFZIGFsc28gYmUNCiAgICAgICAgYWRkZWQuICBUaGUgcmVnaXN0cmF0aW9uIHByb2Nl c3MgTUFZIGJlIHVzZWQgdG8gYWRkIGNvbW1lbnRzDQogICAgICAgIGFib3V0IHRoZSB3aXRo ZHJhd2FsIG9mIHRoZSBjb2RlIGJ5IHRoZSByZXNwZWN0aXZlIHN0YW5kYXJkLg0KDQogICAg ICAgIEV4YW1wbGUgIFRoZSByZWdpb24gY29kZSAnVEwnIHdhcyBhc3NpZ25lZCB0byB0aGUg Y291bnRyeQ0KICAgICAgICAgICAnVGltb3ItTGVzdGUnLCByZXBsYWNpbmcgdGhlIGNvZGUg J1RQJyAod2hpY2ggd2FzIGFzc2lnbmVkIHRvDQogICAgICAgICAgICdFYXN0IFRpbW9yJyB3 aGVuIGl0IHdhcyB1bmRlciBhZG1pbmlzdHJhdGlvbiBieSBQb3J0dWdhbCkuDQogICAgICAg ICAgIFRoZSBzdWJ0YWcgJ1RQJyByZW1haW5zIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIGJ1 dCBpdHMNCiAgICAgICAgICAgcmVjb3JkIGNvbnRhaW5zIHRoZSBhICdQcmVmZXJyZWQtVmFs dWUnIG9mICdUTCcgYW5kIGl0cyBmaWVsZA0KICAgICAgICAgICAnRGVwcmVjYXRlZCcgY29u dGFpbnMgdGhlIGRhdGUgdGhlIG5ldyBjb2RlIHdhcyBhc3NpZ25lZA0KICAgICAgICAgICAo JzIwMDQtMDctMDYnKS4NCg0KICAgMTUuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJ U08gMTU5MjQsIG9yIElTTyAzMTY2IHRoYXQgY29uZmxpY3QNCiAgICAgICAgd2l0aCBleGlz dGluZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUsIGluY2x1ZGluZyBzdWJ0YWdz DQogICAgICAgIHRoYXQgYXJlIGRlcHJlY2F0ZWQsIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50 byB0aGUgcmVnaXN0cnkuICBUaGUNCiAgICAgICAgZm9sbG93aW5nIGFkZGl0aW9uYWwgY29u c2lkZXJhdGlvbnMgYXBwbHkgdG8gc3VidGFnIHZhbHVlcyB0aGF0DQogICAgICAgIGFyZSBy ZWFzc2lnbmVkOg0KDQogICAgICAgIEEuICBGb3IgSVNPIDYzOSBjb2RlcywgaWYgdGhlIG5l d2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBub3QgcmVwcmVz ZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZQ0KICAgICAgICAg ICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjUsIFNIQUxMDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzMV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwg MjAwNw0KDQoNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcg aW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAgICAgYXMgcHJhY3RpY2Fs IGEgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlDQogICAgICAg ICAgICB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVy ZWQgbGFuZ3VhZ2UNCiAgICAgICAgICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0 aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAgICAgICAgIFJldmlld2VyIGFuZCBN VVNUIGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIGxhbmd1YWdlDQogICAgICAg ICAgICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgQi4gIEZvciBhbGwg c3VidGFncyB3aG9zZSBtZWFuaW5nIGlzIGRlcml2ZWQgZnJvbSBhbiBleHRlcm5hbA0KICAg ICAgICAgICAgc3RhbmRhcmQgKHRoYXQgaXMsIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgSVNP IDMxNjYsIG9yIFVODQogICAgICAgICAgICBNLjQ5KSwgaWYgYSBuZXcgbWVhbmluZyBpcyBh c3NpZ25lZCB0byBhbiBleGlzdGluZyBjb2RlIGFuZA0KICAgICAgICAgICAgdGhlIG5ldyBt ZWFuaW5nIGJyb2FkZW5zIHRoZSBtZWFuaW5nIG9mIHRoYXQgY29kZSwgdGhlbiB0aGUNCiAg ICAgICAgICAgIG1lYW5pbmcgZm9yIHRoZSBhc3NvY2lhdGVkIHN1YnRhZyBNQVkgYmUgY2hh bmdlZCB0byBtYXRjaC4NCiAgICAgICAgICAgIFRoZSBtZWFuaW5nIG9mIGEgc3VidGFnIE1V U1QgTk9UIGJlIG5hcnJvd2VkLCBob3dldmVyLCBhcw0KICAgICAgICAgICAgdGhpcyBjYW4g cmVzdWx0IGluIGFuIHVua25vd24gcHJvcG9ydGlvbiBvZiB0aGUgZXhpc3RpbmcNCiAgICAg ICAgICAgIHVzZXMgb2YgYSBzdWJ0YWcgYmVjb21pbmcgaW52YWxpZC4gIE5vdGU6IElTTyA2 MzkNCiAgICAgICAgICAgIG1haW50ZW5hbmNlIGFnZW5jeS9yZWdpc3RyYXRpb24gYXV0aG9y aXR5IChNQS9SQSkgaGFzDQogICAgICAgICAgICBhZG9wdGVkIGEgc2ltaWxhciBzdGFiaWxp dHkgcG9saWN5Lg0KDQogICAgICAgIEMuICBGb3IgSVNPIDE1OTI0IGNvZGVzLCBpZiB0aGUg bmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIG5vdCByZXBy ZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlDQogICAgICAg ICAgICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDMuNSwgU0hBTEwNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJp bmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAgICAgYXMgcHJhY3Rp Y2FsIGEgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAg ICAgICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0 ZXJlZCB2YXJpYW50DQogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3Jl dGlvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICAgICAgICAgICBSZXZpZXdlciBhbmQg TVVTVCBjb25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9ucyBvbiB2YXJpYW50DQogICAgICAg ICAgICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgRC4gIEZvciBJU08g MzE2NiBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQog ICAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgVU4gTS40OSBjb2RlIGFzIGFu b3RoZXIgJ3JlZ2lvbicNCiAgICAgICAgICAgIHN1YnRhZywgdGhlbiB0aGUgZXhpc3Rpbmcg cmVnaW9uIHN1YnRhZyByZW1haW5zIGFzIHRoZQ0KICAgICAgICAgICAgcHJlZmVycmVkIHZh bHVlIGZvciB0aGF0IHJlZ2lvbiBhbmQgbm8gbmV3IGVudHJ5IGlzIGNyZWF0ZWQuDQogICAg ICAgICAgICBBIGNvbW1lbnQgTUFZIGJlIGFkZGVkIHRvIHRoZSBleGlzdGluZyByZWdpb24g c3VidGFnDQogICAgICAgICAgICBpbmRpY2F0aW5nIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhl IG5ldyBJU08gMzE2NiBjb2RlLg0KDQogICAgICAgIEUuICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAg YXNzb2NpYXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQgaXMgbm90IHJlcHJlc2VudGVk IGJ5IGFuDQogICAgICAgICAgICBleGlzdGluZyByZWdpb24gc3VidGFnLCB0aGVuIHRoZSBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsDQogICAgICAgICAgICBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjUsIFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3INCiAgICAgICAgICAg IGVudGVyaW5nIHRoZSBhcHByb3ByaWF0ZSBVTiBNLjQ5IGNvdW50cnkgY29kZSBhcyBhbiBl bnRyeSBpbg0KICAgICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgICAgICAgRi4g IEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlcmUgaXMgbm8gYXNzb2NpYXRlZCBVTiBudW1l cmljDQogICAgICAgICAgICBjb2RlLCB0aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgU0hBTEwgcGV0aXRpb24gdGhlDQogICAgICAgICAgICBVTiB0byBjcmVhdGUgb25lLiAg SWYgdGhlcmUgaXMgbm8gcmVzcG9uc2UgZnJvbSB0aGUgVU4NCiAgICAgICAgICAgIHdpdGhp biBuaW5ldHkgZGF5cyBvZiB0aGUgcmVxdWVzdCBiZWluZyBzZW50LCB0aGUgTGFuZ3VhZ2UN CiAgICAgICAgICAgIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwg Zm9yIGVudGVyaW5nIGluIHRoZQ0KICAgICAgICAgICAgSUFOQSByZWdpc3RyeSBhcyBzb29u IGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgdmFyaWFudA0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgMzJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICAgICAgICAgICBzdWJ0YWcg YXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZg0K ICAgICAgICAgICAgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgd2lsbCBiZSBhdCB0 aGUgZGlzY3JldGlvbiBvZg0KICAgICAgICAgICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZp ZXdlciBhbmQgTVVTVCBjb25mb3JtIHRvIG90aGVyDQogICAgICAgICAgICByZXN0cmljdGlv bnMgb24gdmFyaWFudCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzDQogICAgICAg ICAgICBzaXR1YXRpb24gaXMgdmVyeSB1bmxpa2VseSB0byBldmVyIG9jY3VyLg0KDQogICAx Ni4gIFVOIE0uNDkgaGFzIGNvZGVzIGZvciBib3RoIGNvdW50cmllcyBhbmQgYXJlYXMgKHN1 Y2ggYXMgJzI3NicNCiAgICAgICAgZm9yIEdlcm1hbnkpIGFuZCBnZW9ncmFwaGljYWwgcmVn aW9ucyBhbmQgc3ViLXJlZ2lvbnMgKHN1Y2ggYXMNCiAgICAgICAgJzE1MCcgZm9yIEV1cm9w ZSkuICBVTiBNLjQ5IGNvdW50cnkgb3IgYXJlYSBjb2RlcyBmb3Igd2hpY2gNCiAgICAgICAg dGhlcmUgaXMgbm8gY29ycmVzcG9uZGluZyBJU08gMzE2NiBjb2RlIFNIT1VMRCBOT1QgYmUN CiAgICAgICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08g MzE2NiBjb2RlIHRoYXQgaXMNCiAgICAgICAgYmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBi eSBhbiBleGlzdGluZyBzdWJ0YWcuICBJZiBzdWNoIGEgY29kZQ0KICAgICAgICBiZWNvbWVz IG5lY2Vzc2FyeSwgdGhlbiB0aGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDMx NjYNCiAgICAgICAgU0hPVUxEIGZpcnN0IGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29k ZSB0byB0aGUgcmVnaW9uLiAgSWYNCiAgICAgICAgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUg YXNzaWdubWVudCBieSBJU08gMzE2NiBpcyByZWZ1c2VkIG9yIG5vdA0KICAgICAgICBhY3Rl ZCBvbiBpbiBhIHRpbWVseSBtYW5uZXIsIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBkZXNj cmliZWQNCiAgICAgICAgaW4gU2VjdGlvbiAzLjUgTUFZIHRoZW4gYmUgdXNlZCB0byByZWdp c3RlciB0aGUgY29ycmVzcG9uZGluZyBVTg0KICAgICAgICBNLjQ5IGNvZGUuICBUaGlzIHdh eSwgVU4gTS40OSBjb2RlcyByZW1haW4gYXZhaWxhYmxlIGFzIHRoZQ0KICAgICAgICB2YWx1 ZSBvZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2NiByZWFzc2lnbnMgYQ0K ICAgICAgICBkZXByZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS4NCg0KICAgMTcuICBT dGFiaWxpdHkgcHJvdmlzaW9ucyBhcHBseSB0byBncmFuZGZhdGhlcmVkIHRhZ3Mgd2l0aCB0 aGlzDQogICAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGNvbXBv c2Ugb25lIG9mIHRoZQ0KICAgICAgICBncmFuZGZhdGhlcmVkIHRhZ3MgZnJvbSByZWdpc3Rl cmVkIHN1YnRhZ3MsIHRoZW4gdGhlIGZpZWxkDQogICAgICAgICdUeXBlJyBpbiB0aGF0IHJl Y29yZCBpcyBjaGFuZ2VkIGZyb20gJ2dyYW5kZmF0aGVyZWQnIHRvDQogICAgICAgICdyZWR1 bmRhbnQnLiAgTm90ZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0IGxhbmd1YWdlIHRhZ3Mg dGhhdA0KICAgICAgICBtYXRjaCB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcsIHNpbmNlIHRoZXNl IHRhZ3Mgd2lsbCBub3cgbWF0Y2gNCiAgICAgICAgdmFsaWQgZ2VuZXJhdGl2ZSBzdWJ0YWcg c2VxdWVuY2VzLiAgRm9yIGV4YW1wbGUsIHRoaXMgZG9jdW1lbnQNCiAgICAgICAgY2F1c2Vk IHRoZSBJU08gNjM5LTMgY29kZSAnZ2FuJywgdXNlZCBpbiB0aGUgcmVkdW5kYW50IHRhZyAi emgtDQogICAgICAgIGdhbiIsIHRvIGJlIHJlZ2lzdGVyZWQgYXMgYW4gZXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFnLiAgVGhlDQogICAgICAgIGZvcm1lcmx5LWdyYW5kZmF0aGVyZWQgdGFn ICJ6aC1nYW4iIGJlY2FtZSBhIHJlZHVuZGFudCB0YWcgYXMgYQ0KICAgICAgICByZXN1bHQg KGJ1dCBleGlzdGluZyBjb250ZW50IG9yIGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSAiemgt DQogICAgICAgIGdhbiIgcmVtYWluIHZhbGlkKS4NCg0KMy41LiAgUmVnaXN0cmF0aW9uIFBy b2NlZHVyZSBmb3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUgTVVT VCBiZSB1c2VkIGJ5IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3Qg Y3VycmVudGx5IGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAg T25seSBzdWJ0YWdzIG9mIHR5cGUgJ2xhbmd1YWdlJyBhbmQgJ3ZhcmlhbnQnIHdpbGwgYmUg Y29uc2lkZXJlZCBmb3INCiAgIGluZGVwZW5kZW50IHJlZ2lzdHJhdGlvbiBvZiBuZXcgc3Vi dGFncy4gIEhhbmRsaW5nIG9mIHN1YnRhZ3MgbmVlZGVkDQogICBmb3Igc3RhYmlsaXR5IGFu ZCBzdWJ0YWdzIG5lY2Vzc2FyeSB0byBrZWVwIHRoZSByZWdpc3RyeSBzeW5jaHJvbml6ZWQN CiAgIHdpdGggSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgd2l0 aGluIHRoZSBsaW1pdHMNCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhcmUgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4zLiAgU3RhYmlsaXR5DQogICBwcm92aXNpb25zIGFyZSBkZXNj cmliZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIFRoaXMgcHJvY2VkdXJlIE1BWSBhbHNvIGJl IHVzZWQgdG8gcmVnaXN0ZXIgb3IgYWx0ZXIgdGhlIGluZm9ybWF0aW9uDQogICBmb3IgdGhl ICdEZXNjcmlwdGlvbicsICdDb21tZW50cycsICdEZXByZWNhdGVkJywgJ1ByZWZpeCcsIG9y DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIw MDcgICAgICAgICAgICAgICBbUGFnZSAzM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoN CiAgICdTdXBwcmVzcy1TY3JpcHQnIGZpZWxkcyBpbiBhIHN1YnRhZydzIHJlY29yZCBhcyBk ZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy40LiAgQ2hhbmdlcyB0byBhbGwgb3RoZXIgZmll bGRzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFyZQ0KICAgTk9UIHBlcm1pdHRlZC4NCg0KICAg UmVnaXN0ZXJpbmcgYSBuZXcgc3VidGFnIG9yIHJlcXVlc3RpbmcgbW9kaWZpY2F0aW9ucyB0 byBhbiBleGlzdGluZw0KICAgdGFnIG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUgcmVxdWVz dGVyIGZpbGxpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24NCiAgIGZvcm0gcmVwcm9kdWNlZCBi ZWxvdy4gIE5vdGUgdGhhdCBlYWNoIHJlc3BvbnNlIGlzIG5vdCBsaW1pdGVkIGluDQogICBz aXplIHNvIHRoYXQgdGhlIHJlcXVlc3QgY2FuIGFkZXF1YXRlbHkgZGVzY3JpYmUgdGhlIHJl Z2lzdHJhdGlvbi4NCiAgIFRoZSBmaWVsZHMgaW4gdGhlICJSZWNvcmQgUmVxdWVzdGVkIiBz ZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhlDQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiAz LjEuDQoNCiAgIExBTkdVQUdFIFNVQlRBRyBSRUdJU1RSQVRJT04gRk9STQ0KICAgMS4gTmFt ZSBvZiByZXF1ZXN0ZXI6DQogICAyLiBFLW1haWwgYWRkcmVzcyBvZiByZXF1ZXN0ZXI6DQog ICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICAgICBUeXBlOg0KICAgICAgU3VidGFnOg0K ICAgICAgRGVzY3JpcHRpb246DQogICAgICBQcmVmaXg6DQogICAgICBQcmVmZXJyZWQtVmFs dWU6DQogICAgICBEZXByZWNhdGVkOg0KICAgICAgU3VwcHJlc3MtU2NyaXB0Og0KICAgICAg Q29tbWVudHM6DQoNCiAgIDQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhlIHN1YnRhZzoNCiAg IDUuIFJlZmVyZW5jZSB0byBwdWJsaXNoZWQgZGVzY3JpcHRpb24NCiAgICAgIG9mIHRoZSBs YW5ndWFnZSAoYm9vayBvciBhcnRpY2xlKToNCiAgIDYuIEFueSBvdGhlciByZWxldmFudCBp bmZvcm1hdGlvbjoNCg0KICAgICAgICAgICAgICBGaWd1cmUgNTogVGhlIExhbmd1YWdlIFN1 YnRhZyBSZWdpc3RyYXRpb24gRm9ybQ0KDQogICBUaGUgc3VidGFnIHJlZ2lzdHJhdGlvbiBm b3JtIE1VU1QgYmUgc2VudCB0bw0KICAgPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiBmb3Ig YSB0d28td2VlayByZXZpZXcgcGVyaW9kIGJlZm9yZSBpdCBjYW4NCiAgIGJlIHN1Ym1pdHRl ZCB0byBJQU5BLiAgSWYgbW9kaWZpY2F0aW9ucyBhcmUgbWFkZSB0byB0aGUgcmVxdWVzdA0K ICAgZHVyaW5nIHRoZSBjb3Vyc2Ugb2YgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIChzdWNo IGFzIGNvcnJlY3Rpb25zIHRvDQogICBtZWV0IHRoZSByZXF1aXJlbWVudHMgaW4gU2VjdGlv biAzLjEpIHRoZSBjb3JyZWN0ZWQgZm9ybSBNVVNUIGFsc28gYmUNCiAgIHNlbnQgdG8gPGll dGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiBwcmlvciB0byBzdWJtaXNzaW9uIHRvIElBTkEuDQoN CiAgIFRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0IGlzIGFuIG9wZW4gbGlzdCBhbmQgY2FuIGJl IGpvaW5lZCBieSBzZW5kaW5nDQogICBhIHJlcXVlc3QgdG8gPGlldGYtbGFuZ3VhZ2VzLXJl cXVlc3RAaWFuYS5vcmc+LiAgVGhlIGxpc3QgY2FuIGJlDQogICBob3N0ZWQgYnkgSUFOQSBv ciBieSBhbnkgdGhpcmQgcGFydHkgYXQgdGhlIHJlcXVlc3Qgb2YgSUVTRy4NCg0KICAgVmFy aWFudCBzdWJ0YWdzIGFyZSB1c3VhbGx5IHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRoIGEgcGFy dGljdWxhcg0KICAgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGUg c3VidGFnICdyb3phaicgaXMgaW50ZW5kZWQNCiAgIGZvciB1c2Ugd2l0aCBsYW5ndWFnZSB0 YWdzIHRoYXQgc3RhcnQgd2l0aCB0aGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnICJz bCIsIHNpbmNlIFJlc2lhbiBpcyBhIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLiAgVGh1cywgdGhl DQogICBzdWJ0YWcgJ3JvemFqJyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpbiB0YWdzIHN1Y2gg YXMgInNsLUxhdG4tcm96YWoiDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICAgQXByaWwgMjAwNw0KDQoNCiAgIG9yICJzbC1JVC1yb3phaiIuICBUaGlzIGluZm9ybWF0 aW9uIGlzIHN0b3JlZCBpbiB0aGUgJ1ByZWZpeCcgZmllbGQNCiAgIGluIHRoZSByZWdpc3Ry eS4gIFZhcmlhbnQgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIFNIT1VMRCBpbmNsdWRlIGF0DQog ICBsZWFzdCBvbmUgJ1ByZWZpeCcgZmllbGQgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtLg0K DQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIE1VU1QgaW5jbHVkZSBleGFjdGx5IG9u ZSAnUHJlZml4JyBmaWVsZC4NCg0KICAgVGhlICdQcmVmaXgnIGZpZWxkIGZvciBhIGdpdmVu IHJlZ2lzdGVyZWQgc3VidGFnIGV4aXN0cyBpbiB0aGUgSUFOQQ0KICAgcmVnaXN0cnkgYXMg YSBndWlkZSB0byB1c2FnZS4gIEFkZGl0aW9uYWwgcHJlZml4ZXMgTUFZIGJlIGFkZGVkIGJ5 DQogICBmaWxpbmcgYW4gYWRkaXRpb25hbCByZWdpc3RyYXRpb24gZm9ybS4gIEluIHRoYXQg Zm9ybSwgdGhlICJBbnkgb3RoZXINCiAgIHJlbGV2YW50IGluZm9ybWF0aW9uOiIgZmllbGQg TVVTVCBpbmRpY2F0ZSB0aGF0IGl0IGlzIHRoZSBhZGRpdGlvbiBvZg0KICAgYSBwcmVmaXgu DQoNCiAgIFJlcXVlc3RzIHRvIGFkZCBhIHByZWZpeCB0byBhIHZhcmlhbnQgc3VidGFnIHRo YXQgaW1wbHkgYSBkaWZmZXJlbnQNCiAgIHNlbWFudGljIG1lYW5pbmcgd2lsbCBwcm9iYWJs eSBiZSByZWplY3RlZC4gIEZvciBleGFtcGxlLCBhIHJlcXVlc3QNCiAgIHRvIGFkZCB0aGUg cHJlZml4ICJkZSIgdG8gdGhlIHN1YnRhZyAnbmVkaXMnIHNvIHRoYXQgdGhlIHRhZyAiZGUt DQogICBuZWRpcyIgcmVwcmVzZW50ZWQgc29tZSBHZXJtYW4gZGlhbGVjdCB3b3VsZCBiZSBy ZWplY3RlZC4gIFRoZQ0KICAgJ25lZGlzJyBzdWJ0YWcgcmVwcmVzZW50cyBhIHBhcnRpY3Vs YXIgU2xvdmVuaWFuIGRpYWxlY3QgYW5kIHRoZQ0KICAgYWRkaXRpb25hbCByZWdpc3RyYXRp b24gd291bGQgY2hhbmdlIHRoZSBzZW1hbnRpYyBtZWFuaW5nIGFzc2lnbmVkIHRvDQogICB0 aGUgc3VidGFnLiAgQSBzZXBhcmF0ZSBzdWJ0YWcgU0hPVUxEIGJlIHByb3Bvc2VkIGluc3Rl YWQuDQoNCiAgIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIE1VU1QgY29udGFpbiBhIGRlc2Ny aXB0aW9uIG9mIHRoZSB0YWcgYmVpbmcNCiAgIHJlZ2lzdGVyZWQgd3JpdHRlbiBvciB0cmFu c2NyaWJlZCBpbnRvIHRoZSBMYXRpbiBzY3JpcHQ7IGl0IE1BWSBhbHNvDQogICBpbmNsdWRl IGEgZGVzY3JpcHRpb24gaW4gYSBub24tTGF0aW4gc2NyaXB0LiAgTm9uLUFTQ0lJIGNoYXJh Y3RlcnMNCiAgIE1VU1QgYmUgZXNjYXBlZCB1c2luZyB0aGUgc3ludGF4IGRlc2NyaWJlZCBp biBTZWN0aW9uIDMuMS4gIFRoZQ0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpcyB1c2VkIGZv ciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgZG9lc24ndA0KICAgbmVjZXNzYXJpbHkg cmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1YWdlIG9yDQog ICB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCiAg IFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBpcyBub3QgZ3VhcmFudGVl ZCB0byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlvbnMgTUFZIGJlIHVuZGVy dGFrZW4gZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0byBwcm92aWRlIHRyYW5z bGF0aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3RyeQ0K ICAgaXRzZWxmIHdpbGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRoZSBjb21tdW5p dHkgb3IgcmVqZWN0ZWQNCiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMgbmF0dXJl IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBwcm92aXNpb25zDQogICBpbiBTZWN0aW9uIDMuNC4N Cg0KICAgV2hlbiB0aGUgdHdvLXdlZWsgcGVyaW9kIGhhcyBwYXNzZWQsIHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXINCiAgIE1VU1QgdGFrZSBvbmUgb2YgdGhlIGZvbGxvd2luZyBh Y3Rpb25zOg0KDQogICAgICBGb3J3YXJkIHRoZSByZWNvcmQgdG8gYmUgaW5zZXJ0ZWQgb3Ig bW9kaWZpZWQgdG8gaWFuYUBpYW5hLm9yZw0KICAgICAgYWNjb3JkaW5nIHRvIHRoZSBwcm9j ZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0KDQogICAgICBFeHBsaWNpdGx5IHJl amVjdCB0aGUgcmVxdWVzdCBiZWNhdXNlIG9mIHNpZ25pZmljYW50IG9iamVjdGlvbnMNCiAg ICAgIHJhaXNlZCBvbiB0aGUgbGlzdCBvciBkdWUgdG8gcHJvYmxlbXMgd2l0aCBjb25zdHJh aW50cyBpbiB0aGlzDQogICAgICBkb2N1bWVudCAod2hpY2ggTVVTVCBiZSBleHBsaWNpdGx5 IGNpdGVkKQ0KDQogICAgICBFeHRlbmQgdGhlIHJldmlldyBwZXJpb2QgYnkgZ3JhbnRpbmcg YW4gYWRkaXRpb25hbCB0d28td2Vlaw0KICAgICAgaW5jcmVtZW50IHRvIHBlcm1pdCBmdXJ0 aGVyIGRpc2N1c3Npb24uICBBZnRlciBlYWNoIHR3by13ZWVrDQogICAgICBpbmNyZW1lbnQs IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBpbmRpY2F0ZSBvbiB0aGUgbGlz dA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAy MDA3ICAgICAgICAgICAgICAgW1BhZ2UgMzVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0K DQogICAgICB3aGV0aGVyIHRoZSByZWdpc3RyYXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsIHJl amVjdGVkLCBvciBleHRlbmRlZC4NCg0KICAgTm90ZSB0aGF0IHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3ZXIgTUFZIHJhaXNlIG9iamVjdGlvbnMgb24gdGhlDQogICBsaXN0IGlmIGhl IG9yIHNoZSBzbyBkZXNpcmVzLiAgVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IHRoZQ0K ICAgb2JqZWN0aW9uIE1VU1QgYmUgbWFkZSBwdWJsaWNseS4NCg0KICAgU29tZXRpbWVzIHRo ZSByZXF1ZXN0ZWQgcmVjb3JkIG5lZWRzIHRvIGJlIG1vZGlmaWVkIGFzIGEgcmVzdWx0IG9m DQogICBkaXNjdXNzaW9uIGR1cmluZyB0aGUgcmV2aWV3IHBlcmlvZCBvciBkdWUgdG8gcmVx dWlyZW1lbnRzIGluIHRoaXMNCiAgIGRvY3VtZW50LiAgVGhlIGFwcGxpY2FudCwgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyLCBvciBvdGhlcnMgYXJlDQogICBmcmVlIHRvIHN1Ym1pdCBh IG1vZGlmaWVkIHZlcnNpb24gb2YgdGhlIHJlcXVlc3QsIHdoaWNoIHdpbGwgYmUNCiAgIGNv bnNpZGVyZWQgaW4gbGlldSBvZiB0aGUgb3JpZ2luYWwgcmVxdWVzdCB3aXRoIHRoZSBleHBs aWNpdCBhcHByb3ZhbA0KICAgb2YgdGhlIGFwcGxpY2FudC4gIFN1Y2ggY2hhbmdlcyBkbyBu b3QgcmVzdGFydCB0aGUgdHdvLXdlZWsNCiAgIGRpc2N1c3Npb24gcGVyaW9kLCBhbHRob3Vn aCBhbiBhcHBsaWNhdGlvbiBjb250YWluaW5nIHRoZSBmaW5hbA0KICAgcmVjb3JkIHN1Ym1p dHRlZCB0byBJQU5BIE1VU1QgYXBwZWFyIG9uIHRoZSBsaXN0IGF0IGxlYXN0IG9uZSB3ZWVr DQogICBwcmlvciB0byB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGZvcndhcmRpbmcg dGhlIHJlY29yZCB0byBJQU5BLg0KICAgVGhlIGFwcGxpY2FudCBpcyBhbHNvIGZyZWUgdG8g bW9kaWZ5IGEgcmVqZWN0ZWQgYXBwbGljYXRpb24gd2l0aA0KICAgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBhbmQgc3VibWl0IGl0IGFnYWluOyB0aGlzIHN0YXJ0cyBhIG5ldyB0d28tDQog ICB3ZWVrIGNvbW1lbnQgcGVyaW9kLg0KDQogICBEZWNpc2lvbnMgbWFkZSBieSB0aGUgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyIE1BWSBiZSBhcHBlYWxlZCB0byB0aGUNCiAgIElFU0cg W1JGQzIwMjhdIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYgZGVjaXNpb25z DQogICBbUkZDMjAyNl0uICBUaGlzIGluY2x1ZGVzIGEgZGVjaXNpb24gdG8gZXh0ZW5kIHRo ZSByZXZpZXcgcGVyaW9kIG9yDQogICB0aGUgZmFpbHVyZSB0byBhbm5vdW5jZSBhIGRlY2lz aW9uIGluIGEgY2xlYXIgYW5kIHRpbWVseSBtYW5uZXIuDQoNCiAgIEFsbCBhcHByb3ZlZCBy ZWdpc3RyYXRpb24gZm9ybXMgYXJlIGF2YWlsYWJsZSBvbmxpbmUgaW4gdGhlIGRpcmVjdG9y eQ0KICAgaHR0cDovL3d3dy5pYW5hLm9yZy9udW1iZXJzLmh0bWwgdW5kZXIgImxhbmd1YWdl cyIuDQoNCiAgIFVwZGF0ZXMgb3IgY2hhbmdlcyB0byBleGlzdGluZyByZWNvcmRzIGZvbGxv dyB0aGUgc2FtZSBwcm9jZWR1cmUgYXMNCiAgIG5ldyByZWdpc3RyYXRpb25zLiAgVGhlIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkZWNpZGVzIHdoZXRoZXINCiAgIHRoZXJlIGlzIGNv bnNlbnN1cyB0byB1cGRhdGUgdGhlIHJlZ2lzdHJhdGlvbiBmb2xsb3dpbmcgdGhlIHR3byB3 ZWVrDQogICByZXZpZXcgcGVyaW9kOyBub3JtYWxseSwgb2JqZWN0aW9ucyBieSB0aGUgb3Jp Z2luYWwgcmVnaXN0cmFudCB3aWxsDQogICBjYXJyeSBleHRyYSB3ZWlnaHQgaW4gZm9ybWlu ZyBzdWNoIGEgY29uc2Vuc3VzLg0KDQogICBSZWdpc3RyYXRpb25zIGFyZSBwZXJtYW5lbnQg YW5kIHN0YWJsZS4gIE9uY2UgcmVnaXN0ZXJlZCwgc3VidGFncw0KICAgd2lsbCBub3QgYmUg cmVtb3ZlZCBmcm9tIHRoZSByZWdpc3RyeSBhbmQgd2lsbCByZW1haW4gYSB2YWxpZCB3YXkg aW4NCiAgIHdoaWNoIHRvIHNwZWNpZnkgYSBzcGVjaWZpYyBsYW5ndWFnZSBvciB2YXJpYW50 Lg0KDQogICBOb3RlOiBUaGUgcHVycG9zZSBvZiB0aGUgIlJlZmVyZW5jZSB0byBwdWJsaXNo ZWQgZGVzY3JpcHRpb24iIHNlY3Rpb24NCiAgIGluIHRoZSByZWdpc3RyYXRpb24gZm9ybSBp cyB0byBhaWQgaW4gdmVyaWZ5aW5nIHdoZXRoZXIgYSBsYW5ndWFnZSBpcw0KICAgcmVnaXN0 ZXJlZCBvciB3aGF0IGxhbmd1YWdlIG9yIGxhbmd1YWdlIHZhcmlhdGlvbiBhIHBhcnRpY3Vs YXIgc3VidGFnDQogICByZWZlcnMgdG8uICBJbiBtb3N0IGNhc2VzLCByZWZlcmVuY2UgdG8g YW4gYXV0aG9yaXRhdGl2ZSBncmFtbWFyIG9yDQogICBkaWN0aW9uYXJ5IG9mIHRoYXQgbGFu Z3VhZ2Ugd2lsbCBiZSB1c2VmdWw7IGluIGNhc2VzIHdoZXJlIG5vIHN1Y2gNCiAgIHdvcmsg ZXhpc3RzLCBvdGhlciB3ZWxsLWtub3duIHdvcmtzIGRlc2NyaWJpbmcgdGhhdCBsYW5ndWFn ZSBvciBpbg0KICAgdGhhdCBsYW5ndWFnZSBNQVkgYmUgYXBwcm9wcmlhdGUuICBUaGUgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyDQogICBkZWNpZGVzIHdoYXQgY29uc3RpdHV0ZXMgImdv b2QgZW5vdWdoIiByZWZlcmVuY2UgbWF0ZXJpYWwuICBUaGlzDQogICByZXF1aXJlbWVudCBp cyBub3QgaW50ZW5kZWQgdG8gZXhjbHVkZSBwYXJ0aWN1bGFyIGxhbmd1YWdlcyBvcg0KICAg ZGlhbGVjdHMgZHVlIHRvIHRoZSBzaXplIG9mIHRoZSBzcGVha2VyIHBvcHVsYXRpb24gb3Ig bGFjayBvZiBhDQogICBzdGFuZGFyZGl6ZWQgb3J0aG9ncmFwaHkuICBNaW5vcml0eSBsYW5n dWFnZXMgd2lsbCBiZSBjb25zaWRlcmVkDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzNl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIGVxdWFsbHkgb24gdGhlaXIgb3duIG1lcml0 cy4NCg0KMy42LiAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uDQoNCiAgIFBvc3Np YmlsaXRpZXMgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdWJ0YWdzIG9yIGluZm9ybWF0aW9uIGFi b3V0DQogICBzdWJ0YWdzIGluY2x1ZGU6DQoNCiAgIG8gIFByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFncyBmb3IgbGFuZ3VhZ2VzIG5vdCBsaXN0ZWQgaW4gSVNPIDYzOSB0aGF0DQogICAgICBh cmUgbm90IHZhcmlhbnRzIG9mIGFueSBsaXN0ZWQgb3IgcmVnaXN0ZXJlZCBsYW5ndWFnZSBN QVkgYmUNCiAgICAgIHJlZ2lzdGVyZWQuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdh cyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vDQogICAgICBleGFtcGxlcyBvZiB0aGlzIGZvcm0g b2Ygc3VidGFnLiAgQmVmb3JlIGF0dGVtcHRpbmcgdG8gcmVnaXN0ZXIgYQ0KICAgICAgbGFu Z3VhZ2Ugc3VidGFnLCB0aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVnaXN0ZXIgdGhl IGxhbmd1YWdlDQogICAgICB3aXRoIElTTyA2MzkuICBTdWJ0YWdzIE1VU1QgTk9UIGJlIHJl Z2lzdGVyZWQgZm9yIGxhbmd1YWdlcw0KICAgICAgZGVmaW5lZCBieSBjb2RlcyB0aGF0IGV4 aXN0IGluIElTTyA2MzktMSwgSVNPIDYzOS0yLCBvciBJU08gNjM5LTMsDQogICAgICBvciB0 aGF0IGFyZSB1bmRlciBjb25zaWRlcmF0aW9uIGJ5IHRoZSBJU08gNjM5IHJlZ2lzdHJhdGlv bg0KICAgICAgYXV0aG9yaXRpZXMsIG9yIHRoYXQgaGF2ZSBuZXZlciBiZWVuIGF0dGVtcHRl ZCBmb3IgcmVnaXN0cmF0aW9uDQogICAgICB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiAgSWYg SVNPIDYzOSBoYXMgcHJldmlvdXNseSByZWplY3RlZCBhDQogICAgICBsYW5ndWFnZSBmb3Ig cmVnaXN0cmF0aW9uLCBpdCBpcyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IHRoZXJlDQog ICAgICBtdXN0IGJlIGFkZGl0aW9uYWwsIHZlcnkgY29tcGVsbGluZyBldmlkZW5jZSBvZiBu ZWVkIGJlZm9yZSBpdA0KICAgICAgd2lsbCBiZSByZWdpc3RlcmVkIGFzIGEgcHJpbWFyeSBs YW5ndWFnZSBzdWJ0YWcgaW4gdGhlIElBTkENCiAgICAgIHJlZ2lzdHJ5ICh0byB0aGUgZXh0 ZW50IHRoYXQgaXQgaXMgdmVyeSB1bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzDQogICAgICB3 aWxsIGJlIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBvciBv dGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQog ICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3Rvcmlj YWwgdXNhZ2UsDQogICAgICB0cmFuc2xpdGVyYXRpb24gb3Igb3RoZXIgdHJhbnNmb3JtYXRp b24sIG9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICB2YXJpYXRpb24gTUFZIGJlIHJlZ2lzdGVy ZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBpcyB0aGUNCiAgICAgICdyb3ph aicgc3VidGFnICh0aGUgUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVuaWFuKS4NCg0KICAgbyAg VGhlIGFkZGl0aW9uIG9yIG1haW50ZW5hbmNlIG9mIGZpZWxkcyAoZ2VuZXJhbGx5IG9mIGFu DQogICAgICBpbmZvcm1hdGlvbmFsIG5hdHVyZSkgaW4gVGFnIG9yIFN1YnRhZyByZWNvcmRz IGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlvbiAzLjEgYW5kIHN1YmplY3QgdG8gdGhl IHN0YWJpbGl0eSBwcm92aXNpb25zIGluDQogICAgICBTZWN0aW9uIDMuNC4gIFRoaXMgaW5j bHVkZXMgZGVzY3JpcHRpb25zLCBjb21tZW50cywgZGVwcmVjYXRpb24NCiAgICAgIGFuZCBw cmVmZXJyZWQgdmFsdWVzIGZvciBvYnNvbGV0ZSBvciB3aXRoZHJhd24gY29kZXMsIG9yIHRo ZQ0KICAgICAgYWRkaXRpb24gb2Ygc2NyaXB0IG9yIGV4dGxhbmcgaW5mb3JtYXRpb24gdG8g cHJpbWFyeSBsYW5ndWFnZQ0KICAgICAgc3VidGFncy4NCg0KICAgbyAgVGhlIGFkZGl0aW9u IG9mIHJlY29yZHMgYW5kIHJlbGF0ZWQgZmllbGQgdmFsdWUgY2hhbmdlcyBuZWNlc3NhcnkN CiAgICAgIHRvIHJlZmxlY3QgYXNzaWdubWVudHMgbWFkZSBieSBJU08gNjM5LCBJU08gMTU5 MjQsIElTTyAzMTY2LCBhbmQNCiAgICAgIFVOIE0uNDkgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy40Lg0KDQogICBTdWJ0YWdzIHByb3Bvc2VkIGZvciByZWdpc3RyYXRpb24gdGhhdCB3 b3VsZCBjYXVzZSBhbGwgb3IgcGFydCBvZiBhDQogICBncmFuZGZhdGhlcmVkIHRhZyB0byBi ZWNvbWUgcmVkdW5kYW50IGJ1dCB3aG9zZSBtZWFuaW5nIGNvbmZsaWN0cw0KICAgd2l0aCBv ciBhbHRlcnMgdGhlIG1lYW5pbmcgb2YgdGhlIGdyYW5kZmF0aGVyZWQgdGFnIE1VU1QgYmUg cmVqZWN0ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgbGVhdmVzIHRoZSBkZWNpc2lvbiBvbiB3 aGF0IHN1YnRhZ3Mgb3IgY2hhbmdlcyB0bw0KICAgc3VidGFncyBhcmUgYXBwcm9wcmlhdGUg KG9yIG5vdCkgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjUuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzN10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNw0KDQoNCiAgIE5vdGU6IGZvdXItY2hhcmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gYWxsb3cNCiAgIGZvciB0aGUgcG9zc2liaWxpdHkg b2YgYWxwaGE0IGNvZGVzIGluIHNvbWUgZnV0dXJlIGFkZGl0aW9uIHRvIHRoZQ0KICAgSVNP IDYzOSBmYW1pbHkgb2Ygc3RhbmRhcmRzLg0KDQogICBJU08gNjM5IGRlZmluZXMgYSBtYWlu dGVuYW5jZSBhZ2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcyBpbg0KICAgdGhl IGxpc3Qgb2YgbGFuZ3VhZ2VzIGluIElTTyA2MzkuICBUaGlzIGFnZW5jeSBpczoNCg0KICAg SW50ZXJuYXRpb25hbCBJbmZvcm1hdGlvbiBDZW50cmUgZm9yIFRlcm1pbm9sb2d5IChJbmZv dGVybSkNCiAgIEFpY2hob2x6Z2Fzc2UgNi8xMiwgQVQtMTEyMA0KICAgV2llbiwgQXVzdHJp YQ0KICAgUGhvbmU6ICs0MyAxIDI2IDc1IDM1IEV4dC4gMzEyIEZheDogKzQzIDEgMjE2IDMy IDcyDQoNCiAgIElTTyA2MzktMiBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBh ZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMNCiAgIGluIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBp biBJU08gNjM5LTIuICBUaGlzIGFnZW5jeSBpczoNCg0KICAgTGlicmFyeSBvZiBDb25ncmVz cw0KICAgTmV0d29yayBEZXZlbG9wbWVudCBhbmQgTUFSQyBTdGFuZGFyZHMgT2ZmaWNlDQog ICBXYXNoaW5ndG9uLCBELkMuIDIwNTQwIFVTQQ0KICAgUGhvbmU6ICsxIDIwMiA3MDcgNjIz NyBGYXg6ICsxIDIwMiA3MDcgMDExNQ0KICAgVVJMOiBodHRwOi8vd3d3LmxvYy5nb3Yvc3Rh bmRhcmRzL2lzbzYzOS0yDQoNCiAgIElTTyA2MzktMyBkZWZpbmVzIGEgbWFpbnRlbmFuY2Ug YWdlbmN5IGZvciBhZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMNCiAgIGluIHRoZSBsaXN0IG9m IGxhbmd1YWdlcyBpbiBJU08gNjM5LTMuICBUaGlzIGFnZW5jeSBpczoNCg0KICAgU0lMIElu dGVybmF0aW9uYWwNCiAgIElTTyA2MzktMyBSZWdpc3RyYXINCiAgIDc1MDAgVy4gQ2FtcCBX aXNkb20gUmQuDQogICBEYWxsYXMsIFRYIDc1MjM2IFVTQQ0KICAgUGhvbmU6ICsxIDk3MiA3 MDggNzQwMCwgZXh0LiAyMjkzIEZheDogKzEgOTcyIDcwOCA3NTQ2DQogICBFbWFpbDogaXNv NjM5LTNAc2lsLm9yZw0KICAgVVJMOiBodHRwOi8vd3d3LnNpbC5vcmcvaXNvNjM5LTMNCg0K ICAgVGhlIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgSVNPIDMxNjYgKGNvdW50cnkgY29kZXMp IGlzOg0KDQogICBJU08gMzE2NiBNYWludGVuYW5jZSBBZ2VuY3kNCiAgIGMvbyBJbnRlcm5h dGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uDQogICBDYXNlIHBvc3Rh bGUgNTYNCiAgIENILTEyMTEgR2VuZXZhIDIwIFN3aXR6ZXJsYW5kDQogICBQaG9uZTogKzQx IDIyIDc0OSA3MiAzMyBGYXg6ICs0MSAyMiA3NDkgNzMgNDkNCiAgIFVSTDogaHR0cDovL3d3 dy5pc28ub3JnL2lzby9lbi9wcm9kcy1zZXJ2aWNlcy9pc28zMTY2bWEvaW5kZXguaHRtbA0K DQogICBUaGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDE1OTI0IChzY3JpcHQg Y29kZXMpIGlzOg0KDQogICBVbmljb2RlIENvbnNvcnRpdW0gQm94IDM5MTQ3Ng0KICAgTW91 bnRhaW4gVmlldywgQ0EgOTQwMzktMTQ3NiwgVVNBDQogICBVUkw6IGh0dHA6Ly93d3cudW5p Y29kZS5vcmcvaXNvMTU5MjQNCg0KICAgVGhlIFN0YXRpc3RpY3MgRGl2aXNpb24gb2YgdGhl IFVuaXRlZCBOYXRpb25zIFNlY3JldGFyaWF0IG1haW50YWlucw0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAg W1BhZ2UgMzhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQogICB0aGUgU3RhbmRhcmQg Q291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UgYW5kIGNhbiBiZQ0K ICAgcmVhY2hlZCBhdDoNCg0KICAgU3RhdGlzdGljYWwgU2VydmljZXMgQnJhbmNoDQogICBT dGF0aXN0aWNzIERpdmlzaW9uDQogICBVbml0ZWQgTmF0aW9ucywgUm9vbSBEQzItMTYyMA0K ICAgTmV3IFlvcmssIE5ZIDEwMDE3LCBVU0ENCg0KICAgRmF4OiArMS0yMTItOTYzLTA2MjMN CiAgIEUtbWFpbDogc3RhdGlzdGljc0B1bi5vcmcNCiAgIFVSTDogaHR0cDovL3Vuc3RhdHMu dW4ub3JnL3Vuc2QvbWV0aG9kcy9tNDkvbTQ5YWxwaGEuaHRtDQoNCjMuNy4gIEV4dGVuc2lv bnMgYW5kIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgRXh0ZW5zaW9uIHN1YnRhZ3MgYXJl IHRob3NlIGludHJvZHVjZWQgYnkgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWdzDQogICAoInNp bmdsZXRvbnMiKSBvdGhlciB0aGFuICd4Jy4gIFRoZXkgYXJlIHJlc2VydmVkIGZvciB0aGUg Z2VuZXJhdGlvbg0KICAgb2YgaWRlbnRpZmllcnMgdGhhdCBjb250YWluIGEgbGFuZ3VhZ2Ug Y29tcG9uZW50IGFuZCBhcmUgY29tcGF0aWJsZQ0KICAgd2l0aCBhcHBsaWNhdGlvbnMgdGhh dCB1bmRlcnN0YW5kIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIFRoZSBzdHJ1Y3R1cmUgYW5kIGZv cm0gb2YgZXh0ZW5zaW9ucyBhcmUgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IHNvDQogICB0 aGF0IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY3JlYXRlZCB0aGF0IGFyZSBmb3J3YXJkIGNv bXBhdGlibGUgd2l0aA0KICAgYXBwbGljYXRpb25zIHRoYXQgbWlnaHQgYmUgY3JlYXRlZCB1 c2luZyBzaW5nbGV0b25zIGluIHRoZSBmdXR1cmUuDQogICBJbiBhZGRpdGlvbiwgZGVmaW5p bmcgYSBtZWNoYW5pc20gZm9yIG1haW50YWluaW5nIHNpbmdsZXRvbnMgd2lsbA0KICAgbGVu ZCBzdGFiaWxpdHkgdG8gdGhpcyBkb2N1bWVudCBieSByZWR1Y2luZyB0aGUgbGlrZWx5IG5l ZWQgZm9yDQogICBmdXR1cmUgcmV2aXNpb25zIG9yIHVwZGF0ZXMuDQoNCiAgIFNpbmdsZS1j aGFyYWN0ZXIgc3VidGFncyBhcmUgYXNzaWduZWQgYnkgSUFOQSB1c2luZyB0aGUgIklFVEYN CiAgIENvbnNlbnN1cyIgcG9saWN5IGRlZmluZWQgYnkgW1JGQzI0MzRdLiAgVGhpcyBwb2xp Y3kgcmVxdWlyZXMgdGhlDQogICBkZXZlbG9wbWVudCBvZiBhbiBSRkMsIHdoaWNoIFNIQUxM IGRlZmluZSB0aGUgbmFtZSwgcHVycG9zZSwNCiAgIHByb2Nlc3NlcywgYW5kIHByb2NlZHVy ZXMgZm9yIG1haW50YWluaW5nIHRoZSBzdWJ0YWdzLiAgVGhlDQogICBtYWludGFpbmluZyBv ciByZWdpc3RlcmluZyBhdXRob3JpdHksIGluY2x1ZGluZyBuYW1lLCBjb250YWN0IGVtYWls LA0KICAgZGlzY3Vzc2lvbiBsaXN0IGVtYWlsLCBhbmQgVVJMIGxvY2F0aW9uIG9mIHRoZSBy ZWdpc3RyeSwgTVVTVCBiZQ0KICAgaW5kaWNhdGVkIGNsZWFybHkgaW4gdGhlIFJGQy4gIFRo ZSBSRkMgTVVTVCBzcGVjaWZ5IG9yIGluY2x1ZGUgZWFjaA0KICAgb2YgdGhlIGZvbGxvd2lu ZzoNCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhlIHNwZWNp ZmljIHZlcnNpb24gb3IgcmV2aXNpb24NCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQgdGhhdCBn b3Zlcm5zIGl0cyBjcmVhdGlvbiBhbmQgTVVTVCByZWZlcmVuY2UgdGhpcw0KICAgICAgc2Vj dGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBhbmQg YWxsIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAgTVVTVCBm b2xsb3cgdGhlIEFCTkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9mIHRh Z3MgYW5kDQogICAgICBzdWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIElu IHBhcnRpY3VsYXIsIGl0IE1VU1QNCiAgICAgIHNwZWNpZnkgdGhhdCBjYXNlIGlzIG5vdCBz aWduaWZpY2FudCBhbmQgdGhhdCBzdWJ0YWdzIE1VU1QgTk9UDQogICAgICBleGNlZWQgZWln aHQgY2hhcmFjdGVycyBpbiBsZW5ndGguDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1V U1Qgc3BlY2lmeSBhIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbi4NCg0KDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAg ICAgICBbUGFnZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgIG8gIFRoZSBz cGVjaWZpY2F0aW9uIG9mIHZhbGlkIHN1YnRhZ3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0 aGUNCiAgICAgIEludGVybmV0IGFuZCBhdCBubyBjb3N0Lg0KDQogICBvICBUaGUgc3BlY2lm aWNhdGlvbiBNVVNUIGJlIGluIHRoZSBwdWJsaWMgZG9tYWluIG9yIGF2YWlsYWJsZSB2aWEg YQ0KICAgICAgcm95YWx0eS1mcmVlIGxpY2Vuc2UgYWNjZXB0YWJsZSB0byB0aGUgSUVURiBh bmQgc3BlY2lmaWVkIGluIHRoZQ0KICAgICAgUkZDLg0KDQogICBvICBUaGUgc3BlY2lmaWNh dGlvbiBNVVNUIGJlIHZlcnNpb25lZCwgYW5kIGVhY2ggdmVyc2lvbiBvZiB0aGUNCiAgICAg IHNwZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQsIGFuZCBzdGFibGUuDQoN CiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxlLiAgVGhhdCBpcywgZXh0 ZW5zaW9uIHN1YnRhZ3MsDQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBzcGVjaWZpY2F0aW9u LCBNVVNUIE5PVCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBtZWFuaW5nIGlu IGFueSBzdWJzdGFudGlhbCB3YXkuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1Qg aW5jbHVkZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRpb24g Zm9ybSByZXByb2R1Y2VkIGluIHRoaXMgc2VjdGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4N CiAgICAgIHJlZ2lzdGVyaW5nIHRoZSBleHRlbnNpb24gdXBvbiBwdWJsaWNhdGlvbiBhcyBh biBSRkMuDQoNCiAgIG8gIElBTkEgTVVTVCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRo ZSBjb250YWN0IGluZm9ybWF0aW9uIGFuZA0KICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNh dGlvbi4NCg0KICAgSUFOQSB3aWxsIG1haW50YWluIGEgcmVnaXN0cnkgb2YgYWxsb2NhdGVk IHNpbmdsZS1jaGFyYWN0ZXINCiAgIChzaW5nbGV0b24pIHN1YnRhZ3MuICBUaGlzIHJlZ2lz dHJ5IE1VU1QgdXNlIHRoZSByZWNvcmQtamFyIGZvcm1hdA0KICAgZGVzY3JpYmVkIGJ5IHRo ZSBBQk5GIGluIFNlY3Rpb24gMy4xLiAgVXBvbiBwdWJsaWNhdGlvbiBvZiBhbg0KICAgZXh0 ZW5zaW9uIGFzIGFuIFJGQywgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBkZWZpbmVkIGlu IHRoZSBSRkMNCiAgIE1VU1QgZm9yd2FyZCB0aGlzIHJlZ2lzdHJhdGlvbiBmb3JtIHRvIGll c2dAaWV0Zi5vcmcsIHdobyBNVVNUDQogICBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIGlhbmFA aWFuYS5vcmcuICBUaGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IG9mDQogICB0aGUgZXh0ZW5z aW9uIE1VU1QgbWFpbnRhaW4gdGhlIGFjY3VyYWN5IG9mIHRoZSByZWNvcmQgYnkgc2VuZGlu ZyBhbg0KICAgdXBkYXRlZCBmdWxsIGNvcHkgb2YgdGhlIHJlY29yZCB0byBpYW5hQGlhbmEu b3JnIHdpdGggdGhlIHN1YmplY3QNCiAgIGxpbmUgIkxBTkdVQUdFIFRBRyBFWFRFTlNJT04g VVBEQVRFIiB3aGVuZXZlciBjb250ZW50IGNoYW5nZXMuICBPbmx5DQogICB0aGUgJ0NvbW1l bnRzJywgJ0NvbnRhY3RfRW1haWwnLCAnTWFpbGluZ19MaXN0JywgYW5kICdVUkwnIGZpZWxk cyBNQVkNCiAgIGJlIG1vZGlmaWVkIGluIHRoZXNlIHVwZGF0ZXMuDQoNCiAgIEZhaWx1cmUg dG8gbWFpbnRhaW4gdGhpcyByZWNvcmQsIG1haW50YWluIHRoZSBjb3JyZXNwb25kaW5nIHJl Z2lzdHJ5LA0KICAgb3IgbWVldCBvdGhlciBjb25kaXRpb25zIGltcG9zZWQgYnkgdGhpcyBz ZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQgTUFZDQogICBiZSBhcHBlYWxlZCB0byB0aGUgSUVT RyBbUkZDMjAyOF0gdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXIgSUVURg0KICAgZGVj aXNpb25zIChzZWUgW1JGQzIwMjZdKSBhbmQgTUFZIHJlc3VsdCBpbiB0aGUgYXV0aG9yaXR5 IHRvIG1haW50YWluDQogICB0aGUgZXh0ZW5zaW9uIGJlaW5nIHdpdGhkcmF3biBvciByZWFz c2lnbmVkIGJ5IHRoZSBJRVNHLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcgICAgICAgICAgICAg ICBbUGFnZSA0MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAgICUlDQogICBJZGVu dGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQogICBDb21tZW50czoNCiAgIEFkZGVkOg0KICAg UkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29udGFjdF9FbWFpbDoNCiAgIE1haWxpbmdfTGlz dDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBGaWd1cmUgNjogRm9ybWF0IG9mIFJlY29yZHMg aW4gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgICdJZGVudGlm aWVyJyBjb250YWlucyB0aGUgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgKHNpbmdsZXRvbikN CiAgIGFzc2lnbmVkIHRvIHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJhZnQgc3Vi bWl0dGVkIHRvIGRlZmluZQ0KICAgdGhlIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGlj aCBsZXR0ZXIgb3IgZGlnaXQgdG8gdXNlLCBhbHRob3VnaA0KICAgdGhlIElFU0cgTUFZIGNo YW5nZSB0aGUgYXNzaWdubWVudCB3aGVuIGFwcHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVz Y3JpcHRpb24nIGNvbnRhaW5zIHRoZSBuYW1lIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0 ZW5zaW9uLg0KDQogICAnQ29tbWVudHMnIGlzIGFuIE9QVElPTkFMIGZpZWxkIGFuZCBNQVkg Y29udGFpbiBhIGJyb2FkZXIgZGVzY3JpcHRpb24NCiAgIG9mIHRoZSBleHRlbnNpb24uDQoN CiAgICdBZGRlZCcgY29udGFpbnMgdGhlIGRhdGUgdGhlIFJGQyB3YXMgcHVibGlzaGVkIGlu IHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBG b3IgZXhhbXBsZTogMjAwNC0wNi0yOCByZXByZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0LCBp biB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQogICAnUkZDJyBjb250YWlucyB0aGUgUkZD IG51bWJlciBhc3NpZ25lZCB0byB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQXV0aG9yaXR5JyBj b250YWlucyB0aGUgbmFtZSBvZiB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciB0aGUN CiAgIGV4dGVuc2lvbi4NCg0KICAgJ0NvbnRhY3RfRW1haWwnIGNvbnRhaW5zIHRoZSBlbWFp bCBhZGRyZXNzIHVzZWQgdG8gY29udGFjdCB0aGUNCiAgIG1haW50YWluaW5nIGF1dGhvcml0 eS4NCg0KICAgJ01haWxpbmdfTGlzdCcgY29udGFpbnMgdGhlIFVSTCBvciBzdWJzY3JpcHRp b24gZW1haWwgYWRkcmVzcyBvZiB0aGUNCiAgIG1haWxpbmcgbGlzdCB1c2VkIGJ5IHRoZSBt YWludGFpbmluZyBhdXRob3JpdHkuDQoNCiAgICdVUkwnIGNvbnRhaW5zIHRoZSBVUkwgb2Yg dGhlIHJlZ2lzdHJ5IGZvciB0aGlzIGV4dGVuc2lvbi4NCg0KICAgVGhlIGRldGVybWluYXRp b24gb2Ygd2hldGhlciBhbiBJbnRlcm5ldC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAgIGNv bmRpdGlvbnMgYW5kIHRoZSBkZWNpc2lvbiB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1 dGhvcml0eSByZXN0cw0KICAgc29sZWx5IHdpdGggdGhlIElFU0cgYW5kIGlzIHN1YmplY3Qg dG8gdGhlIG5vcm1hbCByZXZpZXcgYW5kIGFwcGVhbHMNCiAgIHByb2Nlc3MgYXNzb2NpYXRl ZCB3aXRoIHRoZSBSRkMgcHJvY2Vzcy4NCg0KICAgRXh0ZW5zaW9uIGF1dGhvcnMgYXJlIHN0 cm9uZ2x5IGNhdXRpb25lZCB0aGF0IG1hbnkgKGluY2x1ZGluZyBtb3N0DQogICB3ZWxsLWZv cm1lZCkgcHJvY2Vzc29ycyB3aWxsIGJlIHVuYXdhcmUgb2YgYW55IHNwZWNpYWwgcmVsYXRp b25zaGlwcw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIw MDcNCg0KDQogICBvciBtZWFuaW5nIGluaGVyZW50IGluIHRoZSBvcmRlciBvZiBleHRlbnNp b24gc3VidGFncy4gIEV4dGVuc2lvbg0KICAgYXV0aG9ycyBTSE9VTEQgYXZvaWQgc3VidGFn IHJlbGF0aW9uc2hpcHMgb3IgY2Fub25pY2FsaXphdGlvbg0KICAgbWVjaGFuaXNtcyB0aGF0 IGludGVyZmVyZSB3aXRoIG1hdGNoaW5nIG9yIHdpdGggbGVuZ3RoIHJlc3RyaWN0aW9ucw0K ICAgdGhhdCBzb21ldGltZXMgZXhpc3QgaW4gY29tbW9uIHByb3RvY29scyB3aGVyZSB0aGUg ZXh0ZW5zaW9uIGlzIHVzZWQuDQogICBJbiBwYXJ0aWN1bGFyLCBhcHBsaWNhdGlvbnMgTUFZ IHRydW5jYXRlIHRoZSBzdWJ0YWdzIGluIGRvaW5nDQogICBtYXRjaGluZyBvciBpbiBmaXR0 aW5nIGludG8gbGltaXRlZCBsZW5ndGhzLCBzbyBpdCBpcyBSRUNPTU1FTkRFRA0KICAgdGhh dCB0aGUgbW9zdCBzaWduaWZpY2FudCBpbmZvcm1hdGlvbiBiZSBpbiB0aGUgbW9zdCBzaWdu aWZpY2FudA0KICAgKGxlZnQtbW9zdCkgc3VidGFncyBhbmQgdGhhdCB0aGUgc3BlY2lmaWNh dGlvbiBncmFjZWZ1bGx5IGhhbmRsZQ0KICAgdHJ1bmNhdGVkIHN1YnRhZ3MuDQoNCiAgIFdo ZW4gYSBsYW5ndWFnZSB0YWcgaXMgdG8gYmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwg cHJvdG9jb2wsIGl0DQogICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdl IHRhZyBub3QgY29udGFpbiBleHRlbnNpb25zIG5vdA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQg cHJvdG9jb2wuICBJbiBhZGRpdGlvbiwgbm90ZSB0aGF0IHNvbWUgcHJvdG9jb2xzDQogICBN QVkgaW1wb3NlIHVwcGVyIGxpbWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIHVz ZWQgdG8gc3RvcmUgb3INCiAgIHRyYW5zcG9ydCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQozLjgu ICBVcGRhdGUgb2YgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5IHdpbGwNCiAgIG5lZWQgYW4gdXBkYXRlIHNvIHRoYXQgaXQgY29udGFpbnMgdGhlIGNv bXBsZXRlIHNldCBvZiBzdWJ0YWdzIHZhbGlkDQogICBpbiBhIGxhbmd1YWdlIHRhZy4gIFRo aXMgY29sbGVjdGlvbiBvZiBzdWJ0YWdzLCBhbG9uZyB3aXRoIGENCiAgIGRlc2NyaXB0aW9u IG9mIHRoZSBwcm9jZXNzIHVzZWQgdG8gY3JlYXRlIGl0LCBpcyBkZXNjcmliZWQgYnkNCiAg IFtyZWdpc3RyeS11cGRhdGVdLiAgSUFOQSB3aWxsIHB1Ymxpc2ggdGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiB0aGUNCiAgIHJlZ2lzdHJ5IGRlc2NyaWJlZCBieSB0aGlzIGRvY3VtZW50IHVz aW5nIHRoZSBpbnN0cnVjdGlvbnMgYW5kDQogICBjb250ZW50IG9mIFtyZWdpc3RyeS11cGRh dGVdLiAgT25jZSBwdWJsaXNoZWQgYnkgSUFOQSwgdGhlDQogICBtYWludGVuYW5jZSBwcm9j ZWR1cmVzLCBydWxlcywgYW5kIHJlZ2lzdHJhdGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkDQog ICBpbiB0aGlzIGRvY3VtZW50IHdpbGwgYmUgYXZhaWxhYmxlIGZvciBuZXcgcmVnaXN0cmF0 aW9ucyBvciB1cGRhdGVzLg0KDQogICBSZWdpc3RyYXRpb25zIHRoYXQgYXJlIGluIHByb2Nl c3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQgaW4NCiAgIFtSRkM0NjQ2XSB3aGVuIHRoaXMg ZG9jdW1lbnQgaXMgYWRvcHRlZCBNVVNUIGJlIGNvbXBsZXRlZCB1bmRlciB0aGUNCiAgIHJ1 bGVzIGNvbnRhaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQyXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA3DQoNCg0KNC4gIEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBMYW5ndWFnZSBU YWdzDQoNCiAgIFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgaG93IHRvIHVzZSB0aGUgaW5mb3Jt YXRpb24gaW4gdGhlIHJlZ2lzdHJ5DQogICB3aXRoIHRoZSB0YWcgc3ludGF4IHRvIGNob29z ZSwgZm9ybSwgYW5kIHByb2Nlc3MgbGFuZ3VhZ2UgdGFncy4NCg0KNC4xLiAgQ2hvaWNlIG9m IExhbmd1YWdlIFRhZw0KDQogICBUaGUgZ3VpZGluZyBwcmluY2lwbGUgaW4gZm9ybWluZyBs YW5ndWFnZSB0YWdzIGlzIHRvICJ0YWcgY29udGVudA0KICAgd2lzZWx5LiIgIFRoaXMgbWVh bnMgdGhhdCBzb21ldGltZXMgdGhlcmUgaXMgYSBjaG9pY2UgYmV0d2VlbiBzZXZlcmFsDQog ICBwb3NzaWJsZSB0YWdzIGZvciB0aGUgc2FtZSBjb250ZW50IGFuZCB0aGF0IHRoZSBjaG9p Y2Ugb2Ygd2hpY2ggdGFnDQogICB0byB1c2UgZGVwZW5kcyBvbiB0aGUgY29udGVudCBhbmQg YXBwbGljYXRpb24gaW4gcXVlc3Rpb24uDQoNCiAgIEludGVyb3BlcmFiaWxpdHkgaXMgYmVz dCBzZXJ2ZWQgd2hlbiB0aGUgc2FtZSBsYW5ndWFnZSB0YWcgaXMgdXNlZA0KICAgY29uc2lz dGVudGx5IHRvIHJlcHJlc2VudCB0aGUgc2FtZSBsYW5ndWFnZS4gIElmIGFuIGFwcGxpY2F0 aW9uIGhhcw0KICAgcmVxdWlyZW1lbnRzIHRoYXQgbWFrZSB0aGUgcnVsZXMgaGVyZSBpbmFw cGxpY2FibGUsIHRoZW4gdGhhdA0KICAgYXBwbGljYXRpb24gcmlza3MgZGFtYWdpbmcgaW50 ZXJvcGVyYWJpbGl0eS4gIEl0IGlzIHN0cm9uZ2x5DQogICBSRUNPTU1FTkRFRCB0aGF0IHVz ZXJzIG5vdCBkZWZpbmUgdGhlaXIgb3duIHJ1bGVzIGZvciBsYW5ndWFnZSB0YWcNCiAgIGNo b2ljZS4NCg0KICAgQSBzdWJ0YWcgU0hPVUxEIG9ubHkgYmUgdXNlZCB3aGVuIGl0IGFkZHMg dXNlZnVsIGRpc3Rpbmd1aXNoaW5nDQogICBpbmZvcm1hdGlvbiB0byB0aGUgdGFnLiAgRXh0 cmFuZW91cyBzdWJ0YWdzIGludGVyZmVyZSB3aXRoIHRoZQ0KICAgbWVhbmluZywgdW5kZXJz dGFuZGluZywgYW5kIHByb2Nlc3Npbmcgb2YgbGFuZ3VhZ2UgdGFncy4gIEluDQogICBwYXJ0 aWN1bGFyLCB1c2VycyBhbmQgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBmb2xsb3cgdGhlICdQ cmVmaXgnIGFuZA0KICAgJ1N1cHByZXNzLVNjcmlwdCcgZmllbGRzIGluIHRoZSByZWdpc3Ry eSAoZGVmaW5lZCBpbiBTZWN0aW9uIDMuMSk6DQogICB0aGVzZSBmaWVsZHMgcHJvdmlkZSBn dWlkYW5jZSBvbiB3aGVuIHNwZWNpZmljIGFkZGl0aW9uYWwgc3VidGFncw0KICAgU0hPVUxE IGJlIHVzZWQgb3IgYXZvaWRlZCBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAgSW4gcGFydGlj dWxhciwgc29tZSBhcHBsaWNhdGlvbnMgY2FuIGJlbmVmaXQgZnJvbSB0aGUgdXNlIG9mIHNj cmlwdA0KICAgc3VidGFncyBpbiBsYW5ndWFnZSB0YWdzLCBhcyBsb25nIGFzIHRoZSB1c2Ug aXMgY29uc2lzdGVudCBmb3IgYQ0KICAgZ2l2ZW4gY29udGV4dC4gIFNjcmlwdCBzdWJ0YWdz IGFyZSBuZXZlciBhcHByb3ByaWF0ZSBmb3IgdW53cml0dGVuDQogICBjb250ZW50IChzdWNo IGFzIGF1ZGlvIHJlY29yZGluZ3MpLg0KDQogICBTY3JpcHQgc3VidGFncyB3ZXJlIG5vdCBm b3JtYWxseSBkZWZpbmVkIGluIFtSRkMzMDY2XSBhbmQgdGhlaXIgdXNlDQogICBjYW4gYWZm ZWN0IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24gZm9yIGltcGxlbWVudGF0 aW9ucyBvZg0KICAgUkZDIDMwNjYsIGFzIHRoZXNlIHN1YnRhZ3MgYXBwZWFyIGJldHdlZW4g dGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kDQogICByZWdpb24gc3VidGFncy4gIEZvciBleGFt cGxlLCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBzZWxlY3RzIGNvbnRlbnQNCiAgIHVzaW5nIEJh c2ljIEZpbHRlcmluZyBbUkZDNDY0N10gKG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFNlY3Rp b24gMi41DQogICBvZiBbUkZDMzA2Nl0pIGFuZCB0aGUgdXNlciByZXF1ZXN0ZWQgdGhlIGxh bmd1YWdlIHJhbmdlICJlbi1VUyIsDQogICBjb250ZW50IGxhYmVsZWQgImVuLUxhdG4tVVMi IHdpbGwgbm90IG1hdGNoIHRoZSByZXF1ZXN0IGFuZCB0aHVzIG5vdA0KICAgYmUgc2VsZWN0 ZWQuICBUaGVyZWZvcmUsIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdoZW4gc2NyaXB0IHN1 YnRhZ3MNCiAgIHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0aGV5IG91Z2h0 IG5vdCBiZSB1c2VkLiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNzLVNjcmlw dCBmaWVsZCBoZWxwcyBlbnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVu IHRoZSBsYW5ndWFnZSB0YWdzIGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMgU0hPVUxEDQogICBO T1QgaW5jbHVkZSBhIHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBs YW5ndWFnZQ0KICAgc3VidGFnLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzICh0 eXBlICdleHRsYW5nJyBpbiB0aGUgcmVnaXN0cnk7IHNlZQ0KICAgU2VjdGlvbiAzLjEpIGFs c28gYXBwZWFyIGJldHdlZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHN1YnNlcXVlbnQN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAw NyAgICAgICAgICAgICAgIFtQYWdlIDQzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0K ICAgKHNjcmlwdCwgcmVnaW9uLCBvciB2YXJpYW50KSBzdWJ0YWdzLiAgQXBwbGljYXRpb25z IHNvbWV0aW1lcyBiZW5lZml0DQogICBmcm9tIHRoZWlyIGp1ZGljaW91cyB1c2UgaW4gZm9y bWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBTdGFuZGFyZHMsIHByb3RvY29scywgYW5kIGFw cGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50DQogICBub3JtYXRpdmVs eSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBvbmVzIGdpdmVuIGluIHRoaXMN CiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyBsYW5ndWFnZSB0YWcgc2VsZWN0aW9uIHZh cmllcyBmcm9tIHRoZQ0KICAgZ3VpZGVsaW5lcyBnaXZlbiBoZXJlLg0KDQogICBUaGUgY2hv aWNlIG9mIHN1YnRhZ3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnIFNIT1VMRCBiZSBn dWlkZWQgYnkNCiAgIHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBVc2UgYXMgcHJl Y2lzZSBhIHRhZyBhcyBwb3NzaWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMgdGhhbiBpcw0K ICAgICAgIGp1c3RpZmllZC4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGlt cG9ydGFudCBmb3INCiAgICAgICBkaXN0aW5ndWlzaGluZyBjb250ZW50IGluIGFuIGFwcGxp Y2F0aW9uLg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBm b3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0dGVuDQogICAgICAgICAgaW4gR2VybWFuLCB3aGls ZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkgdW5uZWNlc3NhcmlseQ0KICAgICAgICAgIHBy ZWNpc2UgZm9yIHN1Y2ggYSB0YXNrLg0KDQogICAyLiAgVGhlIHNjcmlwdCBzdWJ0YWcgU0hP VUxEIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB1bmxlc3MNCiAgICAgICB0 aGUgc2NyaXB0IGFkZHMgc29tZSBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiB0byB0aGUg dGFnLiAgVGhlDQogICAgICAgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgaW4gdGhlIHByaW1h cnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0KICAgICAgIHJlZ2lzdHJ5IGluZGljYXRlcyBz Y3JpcHQgc3VidGFncyB0aGF0IGRvIG5vdCBhZGQgZGlzdGluZ3Vpc2hpbmcNCiAgICAgICBp bmZvcm1hdGlvbiBmb3IgbW9zdCBhcHBsaWNhdGlvbnMuICBGb3IgZXhhbXBsZToNCg0KICAg ICAgICogIFRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIHRoZSBw cmltYXJ5IGxhbmd1YWdlDQogICAgICAgICAgJ2VuJyBiZWNhdXNlIG5lYXJseSBhbGwgRW5n bGlzaCBkb2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4gdGhlDQogICAgICAgICAgTGF0aW4gc2Ny aXB0IGFuZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uLg0KICAgICAg ICAgIEhvd2V2ZXIsIGlmIGEgZG9jdW1lbnQgd2VyZSB3cml0dGVuIGluIEVuZ2xpc2ggbWl4 aW5nIExhdGluDQogICAgICAgICAgc2NyaXB0IHdpdGggYW5vdGhlciBzY3JpcHQgc3VjaCBh cyBCcmFpbGxlICgnQnJhaScpLCB0aGVuIGl0DQogICAgICAgICAgbWlnaHQgYmUgYXBwcm9w cmlhdGUgdG8gY2hvb3NlIHRvIGluZGljYXRlIGJvdGggc2NyaXB0cyB0byBhaWQNCiAgICAg ICAgICBpbiBjb250ZW50IHNlbGVjdGlvbiwgc3VjaCBhcyB0aGUgYXBwbGljYXRpb24gb2Yg YSBzdHlsZQ0KICAgICAgICAgIHNoZWV0Lg0KDQogICAgICAgKiAgV2hlbiBsYWJlbGluZyBj b250ZW50IHRoYXQgaXMgdW53cml0dGVuIChzdWNoIGFzIGEgcmVjb3JkaW5nDQogICAgICAg ICAgb2YgaHVtYW4gc3BlZWNoKSwgdGhlIHNjcmlwdCBzdWJ0YWcgc2hvdWxkIG5vdCBiZSB1 c2VkLCBldmVuDQogICAgICAgICAgaWYgdGhlIGxhbmd1YWdlIGlzIGN1c3RvbWFyaWx5IHdy aXR0ZW4gaW4gc2V2ZXJhbCBzY3JpcHRzLg0KICAgICAgICAgIFRodXMgdGhlIHN1YnRpdGxl cyB0byBhIG1vdmllIG1pZ2h0IHVzZSB0aGUgdGFnICJ6aC1jbW4tSGFudCINCiAgICAgICAg ICAoQ2hpbmVzZSwgTWFuZGFyaW4sIFRyYWRpdGlvbmFsIHNjcmlwdCksIGJ1dCB0aGUgYXVk aW8gdHJhY2sNCiAgICAgICAgICBmb3IgdGhlIHNhbWUgbGFuZ3VhZ2Ugd291bGQgYmUgdGFn Z2VkICJ6aC1jbW4iLg0KDQogICAzLiAgSWYgYSB0YWcgb3Igc3VidGFnIGhhcyBhICdQcmVm ZXJyZWQtVmFsdWUnIGZpZWxkIGluIGl0cyByZWdpc3RyeQ0KICAgICAgIGVudHJ5LCB0aGVu IHRoZSB2YWx1ZSBvZiB0aGF0IGZpZWxkIFNIT1VMRCBiZSB1c2VkIHRvIGZvcm0gdGhlDQog ICAgICAgbGFuZ3VhZ2UgdGFnIGluIHByZWZlcmVuY2UgdG8gdGhlIHRhZyBvciBzdWJ0YWcg aW4gd2hpY2ggdGhlDQogICAgICAgcHJlZmVycmVkIHZhbHVlIGFwcGVhcnMuDQoNCiAgICAg ICAqICBGb3IgZXhhbXBsZSwgdXNlICdoZScgZm9yIEhlYnJldyBpbiBwcmVmZXJlbmNlIHRv ICdpdycuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1i ZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ0XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAy MDA3DQoNCg0KICAgNC4gIFtJU082MzktMl0gaGFzIGRlZmluZWQgc2V2ZXJhbCBjb2RlcyBp bmNsdWRlZCBpbiB0aGUgc3VidGFnDQogICAgICAgcmVnaXN0cnkgdGhhdCByZXF1aXJlIGFk ZGl0aW9uYWwgY2FyZSB3aGVuIGNob29zaW5nIGxhbmd1YWdlDQogICAgICAgdGFncy4gIElu IG1vc3Qgb2YgdGhlc2UgY2FzZXMsIHdoZXJlIG9taXR0aW5nIHRoZSBsYW5ndWFnZSB0YWcg aXMNCiAgICAgICBwZXJtaXR0ZWQsIHN1Y2ggb21pc3Npb24gcHJlZmVyYWJsZSB0byB1c2lu ZyB0aGVzZSBjb2Rlcy4NCiAgICAgICBMYW5ndWFnZSB0YWdzIFNIT1VMRCBOT1QgaW5jb3Jw b3JhdGUgdGhlc2Ugc3VidGFncyBhcyBhIHByZWZpeCwNCiAgICAgICB1bmxlc3MgdGhlIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24gY29udmV5cyBzb21lIHZhbHVlIHRvIHRoZQ0KICAgICAg IGFwcGxpY2F0aW9uLg0KDQogICAgICAgMS4gIFVzZSBzcGVjaWZpYyBsYW5ndWFnZSBzdWJ0 YWdzIG9yIHN1YnRhZyBzZXF1ZW5jZXMgaW4NCiAgICAgICAgICAgcHJlZmVyZW5jZSB0byBz dWJ0YWdzIGZvciBsYW5ndWFnZSBjb2xsZWN0aW9ucy4gIEEgImxhbmd1YWdlDQogICAgICAg ICAgIGNvbGxlY3Rpb24iIGlzIGEgc3VidGFnIGRlcml2ZWQgZnJvbSBvbmUgb2YgdGhlIFtJ U082MzktMl0NCiAgICAgICAgICAgY29kZXMgdGhhdCByZXByZXNlbnRzIG11bHRpcGxlIHJl bGF0ZWQgbGFuZ3VhZ2VzLiAgVGhlc2UNCiAgICAgICAgICAgY29kZXMgYXJlIGluY2x1ZGVk IGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBpbiB0aGUNCiAgICAgICAgICAgcmVnaXN0 cnkuICBGb3IgZXhhbXBsZSwgdGhlIGNvZGUgJ2NtYycgcmVwcmVzZW50cyAiQ2hhbWljDQog ICAgICAgICAgIGxhbmd1YWdlcyIuICBUaGUgcmVnaXN0cnkgY29udGFpbnMgdmFsdWVzIGZv ciBlYWNoIG9mIHRoZQ0KICAgICAgICAgICBhcHByb3hpbWF0ZWx5IHRlbiBpbmRpdmlkdWFs IGxhbmd1YWdlcyByZXByZXNlbnRlZCBieSB0aGlzDQogICAgICAgICAgIGNvbGxlY3RpdmUg Y29kZS4gIFNvbWUgb3RoZXIgZXhhbXBsZXMgaW5jbHVkZSB0aGUgc3VidGFncw0KICAgICAg ICAgICBHZXJtYW5pYyAoJ2dlcicpIG9yIEFsZ29ucXVpYW4gbGFuZ3VhZ2VzICgnYWxnJyku ICBTaW5jZQ0KICAgICAgICAgICB0aGVzZSBjb2RlcyBhcmUgaW50ZXJwcmV0ZWQgaW5jbHVz aXZlbHksIGNvbnRlbnQgdGFnZ2VkIHdpdGgNCiAgICAgICAgICAgImVuIiAoRW5nbGlzaCks ICJkZSIgKEdlcm1hbiksIG9yICJnc3ciIChTd2lzcyBHZXJtYW4sDQogICAgICAgICAgIEFs ZW1hbm5pYykgY291bGQgYWxzbyAoYnV0IFNIT1VMRCBOT1QpIGJlIHRhZ2dlZCB3aXRoICJn ZXIiDQogICAgICAgICAgIChHZXJtYW5pYyBsYW5ndWFnZXMpLiAgU3VidGFncyBkZXJpdmVk IGZyb20gY29sbGVjdGlvbiBjb2Rlcw0KICAgICAgICAgICBTSE9VTEQgTk9UIGJlIHVzZWQg YmUgdXNlZCB1bmxlc3MgbW9yZSBzcGVjaWZpYyBsYW5ndWFnZQ0KICAgICAgICAgICBpbmZv cm1hdGlvbiBpcyBub3QgYXZhaWxhYmxlLiAgTm90ZSB0aGF0IG1hdGNoaW5nDQogICAgICAg ICAgIGltcGxlbWVudGF0aW9ucyBnZW5lcmFsbHkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHJl bGF0aW9uc2hpcA0KICAgICAgICAgICBiZXR3ZWVuIHRoZSBjb2xsZWN0aW9uIGFuZCBpdHMg ZW5jb21wYXNzZWQgbGFuZ3VhZ2VzLCBhbmQgc28NCiAgICAgICAgICAgdXNlcnMgb3VnaHQg bm90IGFzc3VtZSBhIHN1YnRhZyBiYXNlZCBvbiBhIGxhbmd1YWdlDQogICAgICAgICAgIGNv bGxlY3Rpb24gaXMgYSB1c2VmdWwgbWVhbnMgZm9yIHNlbGVjdGluZyBjb250ZW50IGluIGl0 cw0KICAgICAgICAgICBlbmNvbXBhc3NlZCBsYW5ndWFnZXMuDQoNCiAgICAgICAyLiAgVGhl ICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMgaW50ZW5kZWQg dG8NCiAgICAgICAgICAgaWRlbnRpZnkgY29udGVudCBpbiBtdWx0aXBsZSBsYW5ndWFnZXMu ICBJdCBTSE9VTEQgTk9UIGJlDQogICAgICAgICAgIHVzZWQgd2hlbiBhIGxpc3Qgb2YgbGFu Z3VhZ2VzIChzdWNoIGFzIENvbnRlbnQtTGFuZ3VhZ2UpIG9yDQogICAgICAgICAgIGluZGl2 aWR1YWwgdGFncyBmb3IgZWFjaCBjb250ZW50IGVsZW1lbnQgY2FuIGJlIHVzZWQgaW5zdGVh ZC4NCg0KICAgICAgIDMuICBUaGUgJ3VuZCcgKFVuZGV0ZXJtaW5lZCkgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWcgaXMgaW50ZW5kZWQNCiAgICAgICAgICAgdG8gaWRlbnRpZnkgbGluZ3Vp c3RpYyBjb250ZW50IHdob3NlIGxhbmd1YWdlIGlzIG5vdCBrbm93bi4NCiAgICAgICAgICAg SXQgU0hPVUxEIE5PVCBiZSB1c2VkIHVubGVzcyBhIGxhbmd1YWdlIHRhZyBpcyByZXF1aXJl ZCBhbmQNCiAgICAgICAgICAgbGFuZ3VhZ2UgaW5mb3JtYXRpb24gaXMgbm90IGF2YWlsYWJs ZSBvciBjYW5ub3QgYmUNCiAgICAgICAgICAgZGV0ZXJtaW5lZC4gIE9taXR0aW5nIHRoZSBs YW5ndWFnZSB0YWcgKHdoZXJlIHBlcm1pdHRlZCkgaXMNCiAgICAgICAgICAgcHJlZmVycmVk LiAgVGhlICd1bmQnIHN1YnRhZyBNQVkgYmUgdXNlZnVsIGZvciBwcm90b2NvbHMgdGhhdA0K ICAgICAgICAgICByZXF1aXJlIGEgbGFuZ3VhZ2UgdGFnIHRvIGJlIHByb3ZpZGVkIG9yIHdo ZXJlIGEgcHJpbWFyeQ0KICAgICAgICAgICBsYW5ndWFnZSBzdWJ0YWcgaXMgcmVxdWlyZWQg KHN1Y2ggYXMgaW4gInVuZC1MYXRuIikuICBUaGUNCiAgICAgICAgICAgJ3VuZCcgc3VidGFn IE1BWSBhbHNvIGJlIHVzZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MNCiAgICAg ICAgICAgaW4gY2VydGFpbiBzaXR1YXRpb25zLg0KDQogICAgICAgNC4gIFRoZSAnenh4JyAo Tm9uLUxpbmd1aXN0aWMpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzDQogICAgICAgICAg IGludGVuZGVkIHRvIGlkZW50aWZ5IGNvbnRlbnQgdGhhdCBoYXMgbm8gbGFuZ3VhZ2UuICBT b21lDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMDcgICAgICAgICAgICAgICBbUGFnZSA0NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCiAgICAgICAgICAgZXhhbXBsZXMgbWlnaHQgaW5jbHVkZSBpbnN0cnVtZW50YWwgb3Ig ZWxlY3Ryb25pYyBtdXNpYzsNCiAgICAgICAgICAgc291bmQgcmVjb3JkaW5ncyBjb25zaXN0 aW5nIG9mIG5vbnZlcmJhbCBzb3VuZHM7IGF1ZGlvdmlzdWFsDQogICAgICAgICAgIG1hdGVy aWFscyB3aXRoIG5vIG5hcnJhdGlvbiwgcHJpbnRlZCB0aXRsZXMsIG9yIHN1YnRpdGxlczsN CiAgICAgICAgICAgbWFjaGluZS1yZWFkYWJsZSBkYXRhIGZpbGVzIGNvbnNpc3Rpbmcgb2Yg bWFjaGluZSBsYW5ndWFnZXMNCiAgICAgICAgICAgb3IgY2hhcmFjdGVyIGNvZGVzOyBvciBw cm9ncmFtbWluZyBzb3VyY2UgY29kZS4gIE5vdGU6IHdoZXJlDQogICAgICAgICAgIHRoZXJl IGFyZSBmcmFnbWVudHMgb2YgbGluZ3Vpc3RpYyBjb250ZW50LCBzdWNoIGFzDQogICAgICAg ICAgIHByb2dyYW1taW5nIHNvdXJjZSBjb2RlIGNvbnRhaW5pbmcgY29tbWVudHMgd3JpdHRl biBpbg0KICAgICAgICAgICBFbmdsaXNoLCB0aGUgc3VidGFnICd6eHgnIG1pZ2h0IHN0aWxs IGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlDQogICAgICAgICAgIHByaW1hcnkgc3RhdHVzIG9m IHRoZSBjb250ZW50LCBqdXN0IGFzICdlbicgY2FuIGJlIGFwcGxpZWQgdG8NCiAgICAgICAg ICAgYSBwcmVkb21pbmFudGx5IEVuZ2xpc2ggdGV4dCB0aGF0IGNvbnRhaW5zIGEgZmV3IEZy ZW5jaA0KICAgICAgICAgICBwaHJhc2VzLg0KDQogICAgICAgNS4gIFRoZSAnbWlzJyAoTWlz Y2VsbGFuZW91cykgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMgZGVyaXZlZA0KICAgICAg ICAgICBmcm9tIGEgY29sbGVjdGl2ZSBjb2RlIGFuZCBpcyB1c2VkIHRvIGlkZW50aWZ5IGxp bmd1aXN0aWMNCiAgICAgICAgICAgY29udGVudCB3aG9zZSBsYW5ndWFnZSBpcyBrbm93biBi dXQgY2Fubm90IG90aGVyd2lzZSBiZQ0KICAgICAgICAgICBpZGVudGlmaWVkLiAgSXQgaXMg Y29tbW9ubHkgdXNlZCB3aGVuIHRoZSByYW5nZSBvZiBsYW5ndWFnZQ0KICAgICAgICAgICB0 YWdzIGlzIGNvbnN0cmFpbmVkIG9yIGZvciBsYW5ndWFnZXMgbm90IG90aGVyd2lzZQ0KICAg ICAgICAgICBjYXRlZ29yaXplZC4gIEZvciBleGFtcGxlLCBhIGxpYnJhcnkgYXBwbGljYXRp b24gbWlnaHQgYmUNCiAgICAgICAgICAgbGltaXRlZCB0byB0aGUgc2V0IG9mIHN1YnRhZ3Mg ZGVmaW5lZCBmb3IgdXNlIGJ5IHRoZSBbTUFSQzIxXQ0KICAgICAgICAgICBzdGFuZGFyZC4g IFRoZSAnbWlzJyBzdWJ0YWcgbWlnaHQgYmUgdXNlZCBieSB0aGlzIGFwcGxpY2F0aW9uDQog ICAgICAgICAgIGZvciBsYW5ndWFnZXMgbm90IGluY2x1ZGVkIGluIHRoYXQgc2V0LiAgSXQg U0hPVUxEIE5PVCBiZQ0KICAgICAgICAgICB1c2VkIHVubGVzcyBhIGxhbmd1YWdlIHRhZyBp cyByZXF1aXJlZCBhbmQgbm8gb3RoZXIgbWVhbnMgb2YNCiAgICAgICAgICAgaWRlbnRpZnlp bmcgdGhlIGxhbmd1YWdlIGlzIGF2YWlsYWJsZS4NCg0KICAgICAgIDYuICBUaGUgZ3JhbmRm YXRoZXJlZCB0YWcgImktZGVmYXVsdCIgKERlZmF1bHQgTGFuZ3VhZ2UpIHdhcw0KICAgICAg ICAgICBvcmlnaW5hbGx5IHJlZ2lzdGVyZWQgYWNjb3JkaW5nIHRvIFtSRkMxNzY2XSB0byBt ZWV0IHRoZQ0KICAgICAgICAgICBuZWVkcyBvZiBbUkZDMjI3N10uICBJdCBpcyB1c2VkIHRv IGluZGljYXRlIG5vdCBhIHNwZWNpZmljDQogICAgICAgICAgIGxhbmd1YWdlLCBidXQgcmF0 aGVyLCBpdCBpZGVudGlmaWVzIHRoZSBjb25kaXRpb24gb3IgY29udGVudA0KICAgICAgICAg ICB1c2VkIHdoZXJlIHRoZSBsYW5ndWFnZSBwcmVmZXJlbmNlcyBvZiB0aGUgdXNlciBjYW5u b3QgYmUNCiAgICAgICAgICAgZXN0YWJsaXNoZWQuICBJdCBTSE9VTEQgTk9UIGJlIHVzZWQg ZXhjZXB0IGFzIGEgbWVhbnMgb2YNCiAgICAgICAgICAgbGFiZWxpbmcgdGhlIGRlZmF1bHQg Y29udGVudCBmb3IgYXBwbGljYXRpb25zIG9yIHByb3RvY29scw0KICAgICAgICAgICB0aGF0 IHJlcXVpcmUgZGVmYXVsdCBsYW5ndWFnZSBjb250ZW50IHRvIGJlIGxhYmVsZWQgd2l0aCB0 aGF0DQogICAgICAgICAgIHNwZWNpZmljIHRhZy4gIEl0IE1BWSBhbHNvIGJlIHVzZWQgYnkg YW4gYXBwbGljYXRpb24gb3INCiAgICAgICAgICAgcHJvdG9jb2wgdG8gaWRlbnRpZnkgd2hl biB0aGUgZGVmYXVsdCBsYW5ndWFnZSBjb250ZW50IGlzDQogICAgICAgICAgIGJlaW5nIHJl dHVybmVkLg0KDQogICA1LiAgVGhlIHNhbWUgdmFyaWFudCBzdWJ0YWcgTVVTVCBOT1QgYmUg dXNlZCBtb3JlIHRoYW4gb25jZSB3aXRoaW4gYQ0KICAgICAgIGxhbmd1YWdlIHRhZy4NCg0K ICAgICAgICogIEZvciBleGFtcGxlLCB0aGUgdGFnICJkZS1ERS0xOTAxLTE5MDEiIGlzIG5v dCB2YWxpZC4NCg0KICAgVG8gZW5zdXJlIGNvbnNpc3RlbnQgYmFja3dhcmQgY29tcGF0aWJp bGl0eSwgdGhpcyBkb2N1bWVudCBjb250YWlucw0KICAgc2V2ZXJhbCBwcm92aXNpb25zIHRv IGFjY291bnQgZm9yIHBvdGVudGlhbCBpbnN0YWJpbGl0eSBpbiB0aGUNCiAgIHN0YW5kYXJk cyB1c2VkIHRvIGRlZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2UgdXAgbGFuZ3VhZ2UgdGFn cy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMgbWVhbiB0aGF0IG5vIGxhbmd1YWdlIHRhZyBjcmVh dGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAgdGhpcyBkb2N1bWVudCB3aWxsIGJlY29tZSBp bnZhbGlkLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA3DQoNCg0KNC4yLiAgTWVhbmluZyBvZiB0aGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIFRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdGFnIGFuZCB0aGUgaW5mb3JtYXRpb24gaXQg cmVsYXRlcyB0byBpcw0KICAgZGVmaW5lZCBieSB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUg dGFnIGFwcGVhcnMuICBBY2NvcmRpbmdseSwgdGhpcw0KICAgc2VjdGlvbiBnaXZlcyBvbmx5 IHBvc3NpYmxlIGV4YW1wbGVzIG9mIGl0cyB1c2FnZS4NCg0KICAgbyAgRm9yIGEgc2luZ2xl IGluZm9ybWF0aW9uIG9iamVjdCwgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UgdGFncw0KICAg ICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdGhhdCBp cyBuZWNlc3NhcnkgZm9yDQogICAgICBhIGNvbXBsZXRlIGNvbXByZWhlbnNpb24gb2YgdGhl IGNvbXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6IFBsYWluDQogICAgICB0ZXh0IGRvY3VtZW50 cy4NCg0KICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9mIGluZm9ybWF0aW9uIG9iamVjdHMs IHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlDQogICAgICB0YWdzIGNvdWxkIGJlIHRha2VuIGFz IHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHVzZWQgaW5zaWRlIGNvbXBvbmVudHMNCiAgICAgIG9m IHRoYXQgYWdncmVnYXRpb24uICBFeGFtcGxlczogRG9jdW1lbnQgc3RvcmVzIGFuZCBsaWJy YXJpZXMuDQoNCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmplY3RzIHdob3NlIHB1cnBvc2Ug aXMgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZXMsDQogICAgICB0aGUgYXNzb2NpYXRlZCBsYW5n dWFnZSB0YWdzIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAgICAg Y29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFsIGxhbmd1YWdlcyBhbmQgdGhhdCBvbmUg aGFzIHRvDQogICAgICBpbnNwZWN0IGVhY2ggb2YgdGhlIGFsdGVybmF0aXZlcyBpbiBvcmRl ciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcg0KICAgICAgbGFuZ3VhZ2VzLiAgSW4gdGhpcyBj YXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncyBtaWdodCBub3QNCiAgICAgIG1l YW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGluZ3VhbCB0byBnZXQgY29tcGxldGUN CiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50LiAgRXhhbXBsZTogTUlNRSBt dWx0aXBhcnQvDQogICAgICBhbHRlcm5hdGl2ZS4NCg0KICAgbyAgSW4gbWFya3VwIGxhbmd1 YWdlcywgc3VjaCBhcyBIVE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9ybWF0aW9uDQogICAg ICBjYW4gYmUgYWRkZWQgdG8gZWFjaCBwYXJ0IG9mIHRoZSBkb2N1bWVudCBpZGVudGlmaWVk IGJ5IHRoZSBtYXJrdXANCiAgICAgIHN0cnVjdHVyZSAoaW5jbHVkaW5nIHRoZSB3aG9sZSBk b2N1bWVudCBpdHNlbGYpLiAgRm9yIGV4YW1wbGUsIG9uZQ0KICAgICAgY291bGQgd3JpdGUg PHNwYW4gbGFuZz0iZnIiPkMnZXN0IGxhIHZpZS48L3NwYW4+IGluc2lkZSBhDQogICAgICBO b3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3BlYWtpbmcgdXNlciBjb3VsZCB0 aGVuIGFjY2Vzcw0KICAgICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rpb25hcnkgdG8gZmlu ZCBvdXQgd2hhdCB0aGUgbWFya2VkIHNlY3Rpb24NCiAgICAgIG1lYW50LiAgSWYgdGhlIHVz ZXIgd2VyZSBsaXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVudCB0aHJvdWdoIGENCiAgICAgIHNw ZWVjaCBzeW50aGVzaXMgaW50ZXJmYWNlLCB0aGlzIGZvcm1hdGlvbiBjb3VsZCBiZSB1c2Vk IHRvIHNpZ25hbA0KICAgICAgdGhlIHN5bnRoZXNpemVyIHRvIGFwcHJvcHJpYXRlbHkgYXBw bHkgRnJlbmNoIHRleHQtdG8tc3BlZWNoDQogICAgICBwcm9udW5jaWF0aW9uIHJ1bGVzIHRv IHRoYXQgc3BhbiBvZiB0ZXh0LCBpbnN0ZWFkIG9mIGFwcGx5aW5nIHRoZQ0KICAgICAgaW5h cHByb3ByaWF0ZSBOb3J3ZWdpYW4gcnVsZXMuDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIHJl bGF0ZWQgd2hlbiB0aGV5IGNvbnRhaW4gYSBzaW1pbGFyIHNlcXVlbmNlIG9mDQogICBzdWJ0 YWdzLiAgRm9yIGV4YW1wbGUsIGlmIGEgbGFuZ3VhZ2UgdGFnIEIgY29udGFpbnMgbGFuZ3Vh Z2UgdGFnIEEgYXMNCiAgIGEgcHJlZml4LCB0aGVuIEIgaXMgdHlwaWNhbGx5ICJuYXJyb3dl ciIgb3IgIm1vcmUgc3BlY2lmaWMiIHRoYW4gQS4NCiAgIFRodXMsICJ6aC1IYW50LVRXIiBp cyBtb3JlIHNwZWNpZmljIHRoYW4gInpoLUhhbnQiLg0KDQogICBUaGlzIHJlbGF0aW9uc2hp cCBpcyBub3QgZ3VhcmFudGVlZCBpbiBhbGwgY2FzZXM6IHNwZWNpZmljYWxseSwNCiAgIGxh bmd1YWdlcyB0aGF0IGJlZ2luIHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ugb2Ygc3VidGFncyBh cmUgTk9UDQogICBndWFyYW50ZWVkIHRvIGJlIG11dHVhbGx5IGludGVsbGlnaWJsZSwgYWx0 aG91Z2ggdGhleSBtaWdodCBiZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHRhZyAiYXoiIHNo YXJlcyBhIHByZWZpeCB3aXRoIGJvdGggImF6LUxhdG4iDQogICAoQXplcmJhaWphbmkgd3Jp dHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KSBhbmQgImF6LUN5cmwiDQogICAoQXplcmJh aWphbmkgd3JpdHRlbiB1c2luZyB0aGUgQ3lyaWxsaWMgc2NyaXB0KS4gIEEgcGVyc29uIGZs dWVudCBpbg0KICAgb25lIHNjcmlwdCBtaWdodCBub3QgYmUgYWJsZSB0byByZWFkIHRoZSBv dGhlciwgZXZlbiB0aG91Z2ggdGhlIHRleHQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgbWlnaHQgYmUgaWRlbnRpY2FsLiAgQ29u dGVudCB0YWdnZWQgYXMgImF6IiBtb3N0IHByb2JhYmx5IGlzIHdyaXR0ZW4NCiAgIGluIGp1 c3Qgb25lIHNjcmlwdCBhbmQgdGh1cyBtaWdodCBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIGEg cmVhZGVyDQogICBmYW1pbGlhciB3aXRoIHRoZSBvdGhlciBzY3JpcHQuDQoNCjQuMy4gIExl bmd0aCBDb25zaWRlcmF0aW9ucw0KDQogICBUaGVyZSBpcyBubyBkZWZpbmVkIHVwcGVyIGxp bWl0IG9uIHRoZSBzaXplIG9mIGxhbmd1YWdlIHRhZ3MuICBXaGlsZQ0KICAgaGlzdG9yaWNh bGx5IG1vc3QgbGFuZ3VhZ2UgdGFncyBoYXZlIGNvbnNpc3RlZCBvZiBsYW5ndWFnZSBhbmQg cmVnaW9uDQogICBzdWJ0YWdzIHdpdGggYSBjb21iaW5lZCB0b3RhbCBsZW5ndGggb2YgdXAg dG8gc2l4IGNoYXJhY3RlcnMsIGxhcmdlcg0KICAgdGFncyBoYXZlIGFsd2F5cyBiZWVuIGJv dGggcG9zc2libGUgYW5kIGFjdHVhbGx5IGFwcGVhcmVkIGluIHVzZS4NCg0KICAgTmVpdGhl ciB0aGUgbGFuZ3VhZ2UgdGFnIHN5bnRheCBub3Igb3RoZXIgcmVxdWlyZW1lbnRzIGluIHRo aXMNCiAgIGRvY3VtZW50IGltcG9zZSBhIGZpeGVkIHVwcGVyIGxpbWl0IG9uIHRoZSBudW1i ZXIgb2Ygc3VidGFncyBpbiBhDQogICBsYW5ndWFnZSB0YWcgKGFuZCB0aHVzIGFuIHVwcGVy IGJvdW5kIG9uIHRoZSBzaXplIG9mIGEgdGFnKS4gIFRoZQ0KICAgbGFuZ3VhZ2UgdGFnIHN5 bnRheCBzdWdnZXN0cyB0aGF0LCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljDQogICBsYW5n dWFnZSwgbW9yZSBzdWJ0YWdzIChhbmQgdGh1cyBhIGxvbmdlciB0YWcpIGFyZSBzb21ldGlt ZXMNCiAgIG5lY2Vzc2FyeSB0byBjb21wbGV0ZWx5IGlkZW50aWZ5IHRoZSBsYW5ndWFnZSBm b3IgY2VydGFpbg0KICAgYXBwbGljYXRpb25zOyB0aHVzLCBpdCBpcyBwb3NzaWJsZSB0byBl bnZpc2lvbiBsb25nIG9yIGNvbXBsZXggc3VidGFnDQogICBzZXF1ZW5jZXMuDQoNCjQuMy4x LiAgV29ya2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNpemVzDQoNCiAgIFNvbWUgYXBwbGlj YXRpb25zIGFuZCBwcm90b2NvbHMgYXJlIGZvcmNlZCB0byBhbGxvY2F0ZSBmaXhlZCBidWZm ZXINCiAgIHNpemVzIG9yIG90aGVyd2lzZSBsaW1pdCB0aGUgbGVuZ3RoIG9mIGEgbGFuZ3Vh Z2UgdGFnLiAgQSBjb25mb3JtYW50DQogICBpbXBsZW1lbnRhdGlvbiBvciBzcGVjaWZpY2F0 aW9uIE1BWSByZWZ1c2UgdG8gc3VwcG9ydCB0aGUgc3RvcmFnZSBvZg0KICAgbGFuZ3VhZ2Ug dGFncyB0aGF0IGV4Y2VlZCBhIHNwZWNpZmllZCBsZW5ndGguICBBbnkgc3VjaCBsaW1pdGF0 aW9uDQogICBTSE9VTEQgYmUgY2xlYXJseSBkb2N1bWVudGVkLCBhbmQgc3VjaCBkb2N1bWVu dGF0aW9uIFNIT1VMRCBpbmNsdWRlDQogICB3aGF0IGhhcHBlbnMgdG8gbG9uZ2VyIHRhZ3Mg KGZvciBleGFtcGxlLCB3aGV0aGVyIGFuIGVycm9yIHZhbHVlIGlzDQogICBnZW5lcmF0ZWQg b3IgdGhlIGxhbmd1YWdlIHRhZyBpcyB0cnVuY2F0ZWQpLiAgQSBwcm90b2NvbCB0aGF0IGFs bG93cw0KICAgdGFncyB0byBiZSB0cnVuY2F0ZWQgYXQgYW4gYXJiaXRyYXJ5IGxpbWl0LCB3 aXRob3V0IGdpdmluZyBhbnkNCiAgIGluZGljYXRpb24gb2Ygd2hhdCB0aGF0IGxpbWl0IGlz LCBoYXMgdGhlIHBvdGVudGlhbCBmb3IgY2F1c2luZyBoYXJtDQogICBieSBjaGFuZ2luZyB0 aGUgbWVhbmluZyBvZiB0YWdzIGluIHN1YnN0YW50aWFsIHdheXMuDQoNCiAgIEluIHByYWN0 aWNlLCBtb3N0IGxhbmd1YWdlIHRhZ3MgZG8gbm90IHJlcXVpcmUgbW9yZSB0aGFuIGEgZmV3 DQogICBzdWJ0YWdzIGFuZCB3aWxsIG5vdCBhcHByb2FjaCByZWFzb25hYmx5IHNpemVkIGJ1 ZmZlciBsaW1pdGF0aW9uczsNCiAgIHNlZSBTZWN0aW9uIDQuMS4NCg0KICAgU29tZSBzcGVj aWZpY2F0aW9ucyBvciBwcm90b2NvbHMgaGF2ZSBsaW1pdHMgb24gdGFnIGxlbmd0aCBidXQg ZG8gbm90DQogICBoYXZlIGEgZml4ZWQgbGVuZ3RoIGxpbWl0YXRpb24uICBGb3IgZXhhbXBs ZSwgW1JGQzIyMzFdIGhhcyBubw0KICAgZXhwbGljaXQgbGVuZ3RoIGxpbWl0YXRpb246IHRo ZSBsZW5ndGggYXZhaWxhYmxlIGZvciB0aGUgbGFuZ3VhZ2UgdGFnDQogICBpcyBjb25zdHJh aW5lZCBieSB0aGUgbGVuZ3RoIG9mIG90aGVyIGhlYWRlciBjb21wb25lbnRzIChzdWNoIGFz IHRoZQ0KICAgY2hhcnNldCdzIG5hbWUpIGNvdXBsZWQgd2l0aCB0aGUgNzYtY2hhcmFjdGVy IGxpbWl0IGluIFtSRkMyMDQ3XS4NCiAgIFRodXMsIHRoZSAibGltaXQiIG1pZ2h0IGJlIDUw IG9yIG1vcmUgY2hhcmFjdGVycywgYnV0IGl0IGNvdWxkDQogICBwb3RlbnRpYWxseSBiZSBx dWl0ZSBzbWFsbC4NCg0KICAgVGhlIGNvbnNpZGVyYXRpb25zIGZvciBhc3NpZ25pbmcgYSBi dWZmZXIgbGltaXQgYXJlOg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDQ4XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICBBcHJpbCAyMDA3DQoNCg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1Qg 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 ICAgICAgICAgICAgIEZpZ3VyZSA3OiBEZXJpdmF0aW9uIG9mIHRoZSBMaW1pdCBvbiBUYWcg TGVuZ3RoDQoNCjQuMy4yLiAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFRy dW5jYXRpb24gb2YgYSBsYW5ndWFnZSB0YWcgYWx0ZXJzIHRoZSBtZWFuaW5nIG9mIHRoZSB0 YWcsIGFuZCB0aHVzDQogICBTSE9VTEQgYmUgYXZvaWRlZC4gIEhvd2V2ZXIsIHRydW5jYXRp b24gb2YgbGFuZ3VhZ2UgdGFncyBpcyBzb21ldGltZXMNCiAgIG5lY2Vzc2FyeSBkdWUgdG8g bGltaXRlZCBidWZmZXIgc2l6ZXMuICBTdWNoIHRydW5jYXRpb24gTVVTVCBOT1QNCiAgIHBl cm1pdCBhIHN1YnRhZyB0byBiZSBjaG9wcGVkIG9mZiBpbiB0aGUgbWlkZGxlIG9yIHRoZSBm b3JtYXRpb24gb2YNCiAgIGludmFsaWQgdGFncyAoZm9yIGV4YW1wbGUsIG9uZSBlbmRpbmcg d2l0aCB0aGUgIi0iIGNoYXJhY3RlcikuDQoNCiAgIFRoaXMgbWVhbnMgdGhhdCBhcHBsaWNh dGlvbnMgb3IgcHJvdG9jb2xzIHRoYXQgdHJ1bmNhdGUgdGFncyBNVVNUIGRvDQogICBzbyBi eSBwcm9ncmVzc2l2ZWx5IHJlbW92aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBwcmVj ZWRpbmcgIi0iDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDEsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSA0OV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwg MjAwNw0KDQoNCiAgIGZyb20gdGhlIHJpZ2h0IHNpZGUgb2YgdGhlIGxhbmd1YWdlIHRhZyB1 bnRpbCB0aGUgdGFnIGlzIHNob3J0IGVub3VnaA0KICAgZm9yIHRoZSBnaXZlbiBidWZmZXIu ICBJZiB0aGUgcmVzdWx0aW5nIHRhZyBlbmRzIHdpdGggYSBzaW5nbGUtDQogICBjaGFyYWN0 ZXIgc3VidGFnLCB0aGF0IHN1YnRhZyBhbmQgaXRzIHByZWNlZGluZyAiLSIgTVVTVCBhbHNv IGJlDQogICByZW1vdmVkLiAgRm9yIGV4YW1wbGU6DQoNCiAgIFRhZyB0byB0cnVuY2F0ZTog emgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDEteC13YWRlZ2lsZS1wcml2YXRlMQ0KICAg MS4gemgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDEteC13YWRlZ2lsZQ0KICAgMi4gemgt TGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDENCiAgIDMuIHpoLUxhdG4tQ04tdmFyaWFudDEN CiAgIDQuIHpoLUxhdG4tQ04NCiAgIDUuIHpoLUxhdG4NCiAgIDYuIHpoDQoNCiAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDg6IEV4YW1wbGUgb2YgVGFnIFRydW5jYXRpb24NCg0KNC40 LiAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFNpbmNlIGEgcGFy dGljdWxhciBsYW5ndWFnZSB0YWcgaXMgc29tZXRpbWVzIHVzZWQgYnkgbWFueSBwcm9jZXNz ZXMsDQogICBsYW5ndWFnZSB0YWdzIFNIT1VMRCBhbHdheXMgYmUgY3JlYXRlZCBvciBnZW5l cmF0ZWQgaW4gYSBjYW5vbmljYWwNCiAgIGZvcm0uDQoNCiAgIEEgbGFuZ3VhZ2UgdGFnIGlz IGluIGNhbm9uaWNhbCBmb3JtIHdoZW46DQoNCiAgIDEuICBUaGUgdGFnIGlzIHdlbGwtZm9y bWVkIGFjY29yZGluZyB0aGUgcnVsZXMgaW4gU2VjdGlvbiAyLjEgYW5kDQogICAgICAgU2Vj dGlvbiAyLjIuDQoNCiAgIDIuICBTdWJ0YWdzIG9mIHR5cGUgJ1JlZ2lvbicgdGhhdCBoYXZl IGEgUHJlZmVycmVkLVZhbHVlIG1hcHBpbmcgaW4NCiAgICAgICB0aGUgSUFOQSByZWdpc3Ry eSAoc2VlIFNlY3Rpb24gMy4xKSBTSE9VTEQgYmUgcmVwbGFjZWQgd2l0aCB0aGVpcg0KICAg ICAgIG1hcHBlZCB2YWx1ZS4gIE5vdGU6IEluIHJhcmUgY2FzZXMsIHRoZSBtYXBwZWQgdmFs dWUgd2lsbCBhbHNvDQogICAgICAgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZS4NCg0KICAgMy4g IFJlZHVuZGFudCBvciBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVk LVZhbHVlDQogICAgICAgbWFwcGluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rp b24gMy4xKSBNVVNUIGJlIHJlcGxhY2VkDQogICAgICAgd2l0aCB0aGVpciBtYXBwZWQgdmFs dWUuICBUaGVzZSBpdGVtcyBlaXRoZXIgYXJlIGRlcHJlY2F0ZWQNCiAgICAgICBtYXBwaW5n cyBjcmVhdGVkIGJlZm9yZSB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCAoc3VjaCBh cw0KICAgICAgIHRoZSBtYXBwaW5nIG9mICJuby1ueW4iIHRvICJubiIgb3IgImkta2xpbmdv biIgdG8gInRsaCIpIG9yIGFyZQ0KICAgICAgIHRoZSByZXN1bHQgb2YgbGF0ZXIgcmVnaXN0 cmF0aW9ucyBvciBhZGRpdGlvbnMgdG8gdGhpcyBkb2N1bWVudA0KICAgICAgIChmb3IgZXhh bXBsZSwgInpoLWhha2thIiB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3Vh Z2UtDQogICAgICAgZXh0bGFuZyBjb21iaW5hdGlvbiAiemgtaGFrIiB3aGVuIHRoaXMgZG9j dW1lbnQgd2FzIGFkb3B0ZWQpLg0KDQogICA0LiAgT3RoZXIgc3VidGFncyB0aGF0IGhhdmUg YSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5 IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQN CiAgICAgICB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGNvbnNpc3QgZW50aXJlbHkgb2YgY2xlcmlj YWwgY29ycmVjdGlvbnMgdG8NCiAgICAgICBJU08gNjM5LTEgaW4gd2hpY2ggdGhlIGRlcHJl Y2F0ZWQgc3VidGFncyBoYXZlIGJlZW4gbWFpbnRhaW5lZA0KICAgICAgIGZvciBjb21wYXRp YmlsaXR5IHB1cnBvc2VzLg0KDQogICA1LiAgSWYgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24g c3VidGFnIHNlcXVlbmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbg0KICAgICAgIHNlcXVlbmNl cyBhcmUgb3JkZXJlZCBpbnRvIGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIgYnkNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAg ICAgICAgICAgICAgIFtQYWdlIDUwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAg ICAgIHNpbmdsZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcg ImVuLUEtYWFhLUItY2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25pY2FsDQogICBmb3JtLCB3 aGlsZSAiZW4tQi1jY2MtYmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZvcm1lZCBidXQgbm90 IGluDQogICBjYW5vbmljYWwgZm9ybS4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRh ZyAiZW4tQlUiIChFbmdsaXNoIGFzIHVzZWQgaW4gQnVybWEpIGlzIG5vdA0KICAgY2Fub25p Y2FsIGJlY2F1c2UgdGhlICdCVScgc3VidGFnIGhhcyBhIGNhbm9uaWNhbCBtYXBwaW5nIHRv ICdNTScNCiAgIChNeWFubWFyKSwgYWx0aG91Z2ggdGhlIHRhZyAiZW4tQlUiIG1haW50YWlu cyBpdHMgdmFsaWRpdHkuDQoNCiAgIENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFn cyBkb2VzIG5vdCBpbXBseSBhbnl0aGluZyBhYm91dCB0aGUNCiAgIHVzZSBvZiB1cHBlciBv ciBsb3dlcmNhc2UgbGV0dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQogICBz dWJ0YWdzIChhbmQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gIEFsbCBjb21wYXJp c29ucyBNVVNUIGJlDQogICBwZXJmb3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlIG1hbm5l ci4NCg0KICAgV2hlbiBwZXJmb3JtaW5nIGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2Ug dGFncywgcHJvY2Vzc29ycyBNQVkNCiAgIHJlZ3VsYXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1 YnRhZ3MgKHRoYXQgaXMsIHRoaXMgcHJvY2VzcyBpcw0KICAgT1BUSU9OQUwpLCBmb2xsb3dp bmcgdGhlIGNhc2UgdXNlZCBpbiB0aGUgcmVnaXN0cnkuICBOb3RlIHRoYXQgdGhpcw0KICAg Y29ycmVzcG9uZHMgdG8gdGhlIGZvbGxvd2luZyBjYXNpbmcgcnVsZXM6IHVwcGVyY2FzZSBh bGwgbm9uLWluaXRpYWwNCiAgIHR3by1sZXR0ZXIgc3VidGFnczsgdGl0bGVjYXNlIGFsbCBu b24taW5pdGlhbCBmb3VyLWxldHRlciBzdWJ0YWdzOw0KICAgbG93ZXJjYXNlIGV2ZXJ5dGhp bmcgZWxzZS4NCg0KICAgTm90ZTogQ2FzZSBmb2xkaW5nIG9mIEFTQ0lJIGxldHRlcnMgaW4g Y2VydGFpbiBsb2NhbGVzLCB1bmxlc3MNCiAgIGNhcmVmdWxseSBoYW5kbGVkLCBzb21ldGlt ZXMgcHJvZHVjZXMgbm9uLUFTQ0lJIGNoYXJhY3RlciB2YWx1ZXMuDQogICBUaGUgVW5pY29k ZSBDaGFyYWN0ZXIgRGF0YWJhc2UgZmlsZSAiU3BlY2lhbENhc2luZy50eHQiIGRlZmluZXMg dGhlDQogICBzcGVjaWZpYyBjYXNlcyB0aGF0IGFyZSBrbm93biB0byBjYXVzZSBwcm9ibGVt cyB3aXRoIHRoaXMuICBJbg0KICAgcGFydGljdWxhciwgdGhlIGxldHRlciAnaScgKFUrMDA2 OSkgaW4gVHVya2lzaCBhbmQgQXplcmJhaWphbmkgaXMNCiAgIHVwcGVyY2FzZWQgdG8gVSsw MTMwIChMQVRJTiBDQVBJVEFMIExFVFRFUiBJIFdJVEggRE9UIEFCT1ZFKS4NCiAgIEltcGxl bWVudGVycyBTSE9VTEQgc3BlY2lmeSBhIGxvY2FsZS1uZXV0cmFsIGNhc2luZyBvcGVyYXRp b24gdG8NCiAgIGVuc3VyZSB0aGF0IGNhc2UgZm9sZGluZyBvZiBzdWJ0YWdzIGRvZXMgbm90 IHByb2R1Y2UgdGhpcyB2YWx1ZSwNCiAgIHdoaWNoIGlzIGlsbGVnYWwgaW4gbGFuZ3VhZ2Ug dGFncy4gIEZvciBleGFtcGxlLCBpZiBvbmUgd2VyZSB0bw0KICAgdXBwZXJjYXNlIHRoZSBy ZWdpb24gc3VidGFnICdpbicgdXNpbmcgVHVya2lzaCBsb2NhbGUgcnVsZXMsIHRoZQ0KICAg c2VxdWVuY2UgVSswMTMwIFUrMDA0RSB3b3VsZCByZXN1bHQgaW5zdGVhZCBvZiB0aGUgZXhw ZWN0ZWQgJ0lOJy4NCg0KICAgTm90ZTogaWYgdGhlIGZpZWxkICdEZXByZWNhdGVkJyBhcHBl YXJzIGluIGEgcmVnaXN0cnkgcmVjb3JkIHdpdGhvdXQNCiAgIGFuIGFjY29tcGFueWluZyAn UHJlZmVycmVkLVZhbHVlJyBmaWVsZCwgdGhlbiB0aGF0IHRhZyBvciBzdWJ0YWcgaXMNCiAg IGRlcHJlY2F0ZWQgd2l0aG91dCBhIHJlcGxhY2VtZW50LiAgVmFsaWRhdGluZyBwcm9jZXNz b3JzIFNIT1VMRCBOT1QNCiAgIGdlbmVyYXRlIHRhZ3MgdGhhdCBpbmNsdWRlIHRoZXNlIHZh bHVlcywgYWx0aG91Z2ggdGhlIHZhbHVlcyBhcmUNCiAgIGNhbm9uaWNhbCB3aGVuIHRoZXkg YXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBBbiBleHRlbnNpb24gTVVTVCBkZWZp bmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBleGlzdCBiZXR3ZWVuIHRoZQ0KICAgdmFyaW91 cyBzdWJ0YWdzIGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMgTUFZIGRlZmluZSBhbiBhbHRl cm5hdGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0aGUgZXh0ZW5zaW9uJ3Mg c3VidGFncy4gIEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93IHRoZSBvcmRlciBvZiB0 aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQuICBGb3INCiAgIGV4YW1w bGUsIGFuIGV4dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMgc3VidGFncyBhcmUgaW4g Y2Fub25pY2FsDQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFyZSBwbGFjZWQgaW50byBB U0NJSSBvcmRlcjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBv ZiAiZW4tYS1jY2MtYmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lvbiBtaWdodA0KICAgZGVm aW5lIHRoYXQgdGhlIG9yZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1ZW5jZXMgdGhlaXIgc2Vt YW50aWMNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDUxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3 DQoNCg0KICAgbWVhbmluZyAoc28gdGhhdCAiZW4tYi1jY2MtYmJiLWFhYSIgaGFzIGEgZGlm ZmVyZW50IHZhbHVlIGZyb20gImVuLWItDQogICBhYWEtYmJiLWNjYyIpLiAgSG93ZXZlciwg ZXh0ZW5zaW9uIHNwZWNpZmljYXRpb25zIFNIT1VMRCBiZSBkZXNpZ25lZA0KICAgc28gdGhh dCB0aGV5IGFyZSB0b2xlcmFudCBvZiB0aGUgdHlwaWNhbCBwcm9jZXNzZXMgZGVzY3JpYmVk IGluDQogICBTZWN0aW9uIDMuNy4NCg0KNC41LiAgQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZh dGUgVXNlIFN1YnRhZ3MNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncywgbGlrZSBhbGwgb3Ro ZXIgc3VidGFncywgTVVTVCBjb25mb3JtIHRvIHRoZQ0KICAgZm9ybWF0IGFuZCBjb250ZW50 IGNvbnN0cmFpbnRzIGluIHRoZSBBQk5GLiAgUHJpdmF0ZSB1c2Ugc3VidGFncyBoYXZlDQog ICBubyBtZWFuaW5nIG91dHNpZGUgdGhlIHByaXZhdGUgYWdyZWVtZW50IGJldHdlZW4gdGhl IHBhcnRpZXMgdGhhdA0KICAgaW50ZW5kIHRvIHVzZSBvciBleGNoYW5nZSBsYW5ndWFnZSB0 YWdzIHRoYXQgZW1wbG95IHRoZW0uICBUaGUgc2FtZQ0KICAgc3VidGFncyBNQVkgYmUgdXNl ZCB3aXRoIGEgZGlmZmVyZW50IG1lYW5pbmcgdW5kZXIgYSBzZXBhcmF0ZSBwcml2YXRlDQog ICBhZ3JlZW1lbnQuICBUaGV5IFNIT1VMRCBOT1QgYmUgdXNlZCB3aGVyZSBhbHRlcm5hdGl2 ZXMgZXhpc3QgYW5kDQogICBTSE9VTEQgTk9UIGJlIHVzZWQgaW4gY29udGVudCBvciBwcm90 b2NvbHMgaW50ZW5kZWQgZm9yIGdlbmVyYWwgdXNlLg0KDQogICBQcml2YXRlIHVzZSBzdWJ0 YWdzIGFyZSBzaW1wbHkgdXNlbGVzcyBmb3IgaW5mb3JtYXRpb24gZXhjaGFuZ2UNCiAgIHdp dGhvdXQgcHJpb3IgYXJyYW5nZW1lbnQuICBUaGUgdmFsdWUgYW5kIHNlbWFudGljIG1lYW5p bmcgb2YgcHJpdmF0ZQ0KICAgdXNlIHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdzIHVzZWQgd2l0 aGluIHN1Y2ggYSBsYW5ndWFnZSB0YWcgYXJlIG5vdA0KICAgZGVmaW5lZCBieSB0aGlzIGRv Y3VtZW50Lg0KDQogICBTdWJ0YWdzIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMg aGF2aW5nIGEgc3BlY2lmaWMgcHJpdmF0ZSB1c2UNCiAgIG1lYW5pbmcgY29udmV5IG1vcmUg aW5mb3JtYXRpb24gdGhhdCBhIHB1cmVseSBwcml2YXRlIHVzZSB0YWcNCiAgIHByZWZpeGVk IGJ5IHRoZSBzaW5nbGV0b24gc3VidGFnICd4Jy4gIEZvciBhcHBsaWNhdGlvbnMsIHRoaXMN CiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gTUFZIGJlIHVzZWZ1bC4NCg0KICAgRm9yIGV4 YW1wbGUsIHRoZSByZWdpb24gc3VidGFncyAnQUEnLCAnWlonLCBhbmQgaW4gdGhlIHJhbmdl cw0KICAgJ1FNJy0nUVonIGFuZCAnWEEnLSdYWicgKGRlcml2ZWQgZnJvbSBJU08gMzE2NiBw cml2YXRlIHVzZSBjb2RlcykgTUFZDQogICBiZSB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0 YWcuICBBIHRhZyBzdWNoIGFzICJ6aC1IYW5zLVhRIiBjb252ZXlzIGENCiAgIGdyZWF0IGRl YWwgb2YgcHVibGljLCBpbnRlcmNoYW5nZWFibGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxh bmd1YWdlDQogICBtYXRlcmlhbCAodGhhdCBpdCBpcyBDaGluZXNlIGluIHRoZSBzaW1wbGlm aWVkIENoaW5lc2Ugc2NyaXB0IGFuZCBpcw0KICAgc3VpdGFibGUgZm9yIHNvbWUgZ2VvZ3Jh cGhpYyByZWdpb24gJ1hRJykuICBXaGlsZSB0aGUgcHJlY2lzZQ0KICAgZ2VvZ3JhcGhpYyBy ZWdpb24gaXMgbm90IGtub3duIG91dHNpZGUgb2YgcHJpdmF0ZSBhZ3JlZW1lbnQsIHRoZSB0 YWcNCiAgIGNvbnZleXMgZmFyIG1vcmUgaW5mb3JtYXRpb24gdGhhbiBhbiBvcGFxdWUgdGFn IHN1Y2ggYXMgIngtc29tZUxhbmciLA0KICAgd2hpY2ggY29udGFpbnMgbm8gaW5mb3JtYXRp b24gYWJvdXQgdGhlIGxhbmd1YWdlIHN1YnRhZyBvciBzY3JpcHQNCiAgIHN1YnRhZyBvdXRz aWRlIG9mIHRoZSBwcml2YXRlIGFncmVlbWVudC4NCg0KICAgSG93ZXZlciwgaW4gc29tZSBj YXNlcyBjb250ZW50IHRhZ2dlZCB3aXRoIHByaXZhdGUgdXNlIHN1YnRhZ3MgTUFZDQogICBp bnRlcmFjdCB3aXRoIG90aGVyIHN5c3RlbXMgaW4gYSBkaWZmZXJlbnQgYW5kIHBvc3NpYmx5 IHVuc3VpdGFibGUNCiAgIG1hbm5lciBjb21wYXJlZCB0byB0YWdzIHRoYXQgdXNlIG9wYXF1 ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3VidGFncywNCiAgIHNvIHRoZSBjaG9pY2Ugb2YgdGhl IGJlc3QgYXBwcm9hY2ggc29tZXRpbWVzIGRlcGVuZHMgb24gdGhlDQogICBwYXJ0aWN1bGFy IGRvbWFpbiBpbiBxdWVzdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgNTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0 aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0aGUgcHJvY2Vzc2VzIGFuZCBy ZXF1aXJlbWVudHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1bmRlcnRha2UgdG8gbWFp bnRhaW4gdGhlIHN1YnRhZyBhbmQgZXh0ZW5zaW9uIHJlZ2lzdHJpZXMgYXMNCiAgIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSByZXF1aXJl bWVudHMgb2YNCiAgIFtSRkMyNDM0XS4NCg0KICAgVGhlIGltcGFjdCBvbiB0aGUgSUFOQSBt YWludGFpbmVycyBvZiB0aGUgdHdvIHJlZ2lzdHJpZXMgZGVmaW5lZCBieQ0KICAgdGhpcyBk b2N1bWVudCB3aWxsIGJlIGEgc21hbGwgaW5jcmVhc2UgaW4gdGhlIGZyZXF1ZW5jeSBvZiBu ZXcNCiAgIGVudHJpZXMgb3IgdXBkYXRlcy4NCg0KNS4xLiAgTGFuZ3VhZ2UgU3VidGFnIFJl Z2lzdHJ5DQoNCiAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCwgSUFOQSB3aWxs IHVwZGF0ZSB0aGUgcmVnaXN0cnkgdXNpbmcNCiAgIGluc3RydWN0aW9ucyBhbmQgY29udGVu dCBwcm92aWRlZCBpbiBhIGNvbXBhbmlvbiBkb2N1bWVudDoNCiAgIFtyZWdpc3RyeS11cGRh dGVdLiAgVGhlIGNyaXRlcmlhIGFuZCBwcm9jZXNzIGZvciBzZWxlY3RpbmcgdGhlDQogICB1 cGRhdGVkIHNldCBvZiByZWNvcmRzIGFyZSBkZXNjcmliZWQgaW4gdGhhdCBkb2N1bWVudC4g IFRoZSB1cGRhdGVkDQogICBzZXQgb2YgcmVjb3JkcyByZXByZXNlbnRzIG5vIGltcGFjdCBv biBJQU5BLCBzaW5jZSB0aGUgd29yayB0byBjcmVhdGUNCiAgIGl0IHdpbGwgYmUgcGVyZm9y bWVkIGV4dGVybmFsbHkuDQoNCiAgIEZ1dHVyZSB3b3JrIG9uIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmVnaXN0cnkgaGFzIGJlZW4gbGltaXRlZCB0bw0KICAgaW5zZXJ0aW5nIG9yIHJlcGxh Y2luZyB3aG9sZSByZWNvcmRzIHByZWZvcm1hdHRlZCBmb3IgSUFOQSBieSB0aGUNCiAgIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMgb2Yg dGhpcyBkb2N1bWVudA0KICAgYW5kIGFyY2hpdmluZyB0aGUgZm9yd2FyZGVkIHJlZ2lzdHJh dGlvbiBmb3JtLg0KDQogICBFYWNoIHJlY29yZCBNVVNUIGJlIHNlbnQgdG8gaWFuYUBpYW5h Lm9yZyB3aXRoIGEgc3ViamVjdCBsaW5lDQogICBpbmRpY2F0aW5nIHdoZXRoZXIgdGhlIGVu Y2xvc2VkIHJlY29yZCBpcyBhbiBpbnNlcnRpb24gb2YgYSBuZXcNCiAgIHJlY29yZCAoaW5k aWNhdGVkIGJ5IHRoZSB3b3JkICJJTlNFUlQiIGluIHRoZSBzdWJqZWN0IGxpbmUpIG9yIGEN CiAgIHJlcGxhY2VtZW50IG9mIGFuIGV4aXN0aW5nIHJlY29yZCAoaW5kaWNhdGVkIGJ5IHRo ZSB3b3JkICJNT0RJRlkiIGluDQogICB0aGUgc3ViamVjdCBsaW5lKS4gIFJlY29yZHMgTVVT VCBOT1QgYmUgZGVsZXRlZCBmcm9tIHRoZSByZWdpc3RyeS4NCiAgIElBTkEgTVVTVCBwbGFj ZSBhbnkgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgcmVjb3JkcyBpbnRvIHRoZSBhcHByb3ByaWF0 ZQ0KICAgc2VjdGlvbiBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5LCBncm91cGlu ZyB0aGUgcmVjb3JkcyBieQ0KICAgdGhlaXIgJ1R5cGUnIGZpZWxkLiAgSW5zZXJ0ZWQgcmVj b3JkcyBNQVkgYmUgcGxhY2VkIGFueXdoZXJlIGluIHRoZQ0KICAgYXBwcm9wcmlhdGUgc2Vj dGlvbjsgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIG9mIHRoZSBvcmRlciBvZiB0aGUNCiAgIHJl Y29yZHMgYmV5b25kIGdyb3VwaW5nIHRoZW0gdG9nZXRoZXIgYnkgJ1R5cGUnLiAgTW9kaWZp ZWQgcmVjb3Jkcw0KICAgTVVTVCBvdmVyd3JpdGUgdGhlIHJlY29yZCB0aGV5IHJlcGxhY2Uu DQoNCiAgIEluY2x1ZGVkIGluIGFueSByZXF1ZXN0IHRvIGluc2VydCBvciBtb2RpZnkgcmVj b3JkcyBNVVNUIGJlIGEgbmV3DQogICBGaWxlLURhdGUgcmVjb3JkLiAgVGhpcyByZWNvcmQg TVVTVCBiZSBwbGFjZWQgZmlyc3QgaW4gdGhlIHJlZ2lzdHJ5Lg0KICAgSW4gdGhlIGV2ZW50 IHRoYXQgdGhlIEZpbGUtRGF0ZSByZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkgaGFz IGENCiAgIGxhdGVyIGRhdGUgdGhhbiB0aGUgcmVjb3JkIGJlaW5nIGluc2VydGVkIG9yIG1v ZGlmaWVkLCB0aGUgZXhpc3RpbmcNCiAgIHJlY29yZCBNVVNUIGJlIHByZXNlcnZlZC4NCg0K NS4yLiAgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4dGVu c2lvbnMgUmVnaXN0cnkgY2FuIGNvbnRhaW4gYXQgbW9zdCAzNSByZWNvcmRzDQogICBhbmQg dGh1cyBjaGFuZ2VzIHRvIHRoaXMgcmVnaXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlIHZlcnkg aW5mcmVxdWVudC4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNTNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFw cmlsIDIwMDcNCg0KDQogICBGdXR1cmUgd29yayBieSBJQU5BIG9uIHRoZSBMYW5ndWFnZSBU YWcgRXh0ZW5zaW9ucyBSZWdpc3RyeSBpcw0KICAgbGltaXRlZCB0byB0d28gY2FzZXMuICBG aXJzdCwgdGhlIElFU0cgTUFZIHJlcXVlc3QgdGhhdCBuZXcgcmVjb3Jkcw0KICAgYmUgaW5z ZXJ0ZWQgaW50byB0aGlzIHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0aW1lLiAgVGhlc2UgcmVx dWVzdHMNCiAgIE1VU1QgaW5jbHVkZSB0aGUgcmVjb3JkIHRvIGluc2VydCBpbiB0aGUgZXhh Y3QgZm9ybWF0IGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjcuICBJbiBhZGRpdGlvbiwg dGhlcmUgTUFZIGJlIG9jY2FzaW9uYWwgcmVxdWVzdHMgZnJvbSB0aGUNCiAgIG1haW50YWlu aW5nIGF1dGhvcml0eSBmb3IgYSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRoZSBj b250YWN0DQogICBpbmZvcm1hdGlvbiBvciBVUkxzIGluIHRoZSByZWNvcmQuICBUaGVzZSBy ZXF1ZXN0cyBNVVNUIGluY2x1ZGUgdGhlDQogICBjb21wbGV0ZSwgdXBkYXRlZCByZWNvcmQu ICBJQU5BIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIGluZm9y bWF0aW9uIHByb3ZpZGVkLCBvbmx5IHRoYXQgaXQgaXMgcHJvcGVybHkgZm9ybWF0dGVkLiAg SXQgc2hvdWxkDQogICByZWFzb25hYmx5IGJlIHNlZW4gdG8gY29tZSBmcm9tIHRoZSBtYWlu dGFpbmluZyBhdXRob3JpdHkgbmFtZWQgaW4NCiAgIHRoZSByZWNvcmQgcHJlc2VudCBpbiB0 aGUgcmVnaXN0cnkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdl IDU0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KNi4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQoNCiAgIExhbmd1YWdlIHRhZ3MgdXNlZCBpbiBjb250ZW50IG5lZ290aWF0aW9u LCBsaWtlIGFueSBvdGhlciBpbmZvcm1hdGlvbg0KICAgZXhjaGFuZ2VkIG9uIHRoZSBJbnRl cm5ldCwgbWlnaHQgYmUgYSBzb3VyY2Ugb2YgY29uY2VybiBiZWNhdXNlIHRoZXkNCiAgIG1p Z2h0IGJlIHVzZWQgdG8gaW5mZXIgdGhlIG5hdGlvbmFsaXR5IG9mIHRoZSBzZW5kZXIsIGFu ZCB0aHVzDQogICBpZGVudGlmeSBwb3RlbnRpYWwgdGFyZ2V0cyBmb3Igc3VydmVpbGxhbmNl Lg0KDQogICBUaGlzIGlzIGEgc3BlY2lhbCBjYXNlIG9mIHRoZSBnZW5lcmFsIHByb2JsZW0g dGhhdCBhbnl0aGluZyBzZW50IGlzDQogICB2aXNpYmxlIHRvIHRoZSByZWNlaXZpbmcgcGFy dHkgYW5kIHBvc3NpYmx5IHRvIHRoaXJkIHBhcnRpZXMgYXMgd2VsbC4NCiAgIEl0IGlzIHVz ZWZ1bCB0byBiZSBhd2FyZSB0aGF0IHN1Y2ggY29uY2VybnMgY2FuIGV4aXN0IGluIHNvbWUg Y2FzZXMuDQoNCiAgIFRoZSBldmFsdWF0aW9uIG9mIHRoZSBleGFjdCBtYWduaXR1ZGUgb2Yg dGhlIHRocmVhdCwgYW5kIGFueSBwb3NzaWJsZQ0KICAgY291bnRlcm1lYXN1cmVzLCBpcyBs ZWZ0IHRvIGVhY2ggYXBwbGljYXRpb24gcHJvdG9jb2wgKHNlZSBCQ1AgNzINCiAgIFtSRkMz NTUyXSBmb3IgYmVzdCBjdXJyZW50IHByYWN0aWNlIGd1aWRhbmNlIG9uIHNlY3VyaXR5IHRo cmVhdHMgYW5kDQogICBkZWZlbnNlcykuDQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgYXNzb2Np YXRlZCB3aXRoIGEgcGFydGljdWxhciBpbmZvcm1hdGlvbiBpdGVtIGlzIG9mDQogICBubyBj b25zZXF1ZW5jZSB3aGF0c29ldmVyIGluIGRldGVybWluaW5nIHdoZXRoZXIgdGhhdCBjb250 ZW50IG1pZ2h0DQogICBjb250YWluIHBvc3NpYmxlIGhvbW9ncmFwaHMuICBUaGUgZmFjdCB0 aGF0IGEgdGV4dCBpcyB0YWdnZWQgYXMgYmVpbmcNCiAgIGluIG9uZSBsYW5ndWFnZSBvciB1 c2luZyBhIHBhcnRpY3VsYXIgc2NyaXB0IHN1YnRhZyBwcm92aWRlcyBubw0KICAgYXNzdXJh bmNlIHdoYXRzb2V2ZXIgdGhhdCBpdCBkb2VzIG5vdCBjb250YWluIGNoYXJhY3RlcnMgZnJv bSBzY3JpcHRzDQogICBvdGhlciB0aGFuIHRoZSBvbmUocykgYXNzb2NpYXRlZCB3aXRoIG9y IHNwZWNpZmllZCBieSB0aGF0IGxhbmd1YWdlDQogICB0YWcuDQoNCiAgIFNpbmNlIHRoZXJl IGlzIG5vIGxpbWl0IHRvIHRoZSBudW1iZXIgb2YgdmFyaWFudCwgcHJpdmF0ZSB1c2UsIGFu ZA0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGFuZCBjb25zZXF1ZW50bHkgbm8gbGltaXQgb24g dGhlIHBvc3NpYmxlIGxlbmd0aA0KICAgb2YgYSB0YWcsIGltcGxlbWVudGF0aW9ucyBuZWVk IHRvIGd1YXJkIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93DQogICBhdHRhY2tzLiAgU2VlIFNl Y3Rpb24gNC4zIGZvciBkZXRhaWxzIG9uIGxhbmd1YWdlIHRhZyB0cnVuY2F0aW9uLA0KICAg d2hpY2ggY2FuIG9jY3VyIGFzIGEgY29uc2VxdWVuY2Ugb2YgZGVmZW5zZXMgYWdhaW5zdCBi dWZmZXIgb3ZlcmZsb3cuDQoNCiAgIEFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHZh bGlkIHN1YnRhZ3MgZm9yIGFuIGV4dGVuc2lvbiAoc2VlDQogICBTZWN0aW9uIDMuNykgTVVT VCBiZSBhdmFpbGFibGUgb3ZlciB0aGUgSW50ZXJuZXQsIGltcGxlbWVudGF0aW9ucw0KICAg U0hPVUxEIE5PVCBtZWNoYW5pY2FsbHkgZGVwZW5kIG9uIGl0IGJlaW5nIGFsd2F5cyBhY2Nl c3NpYmxlLCB0bw0KICAgcHJldmVudCBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDU1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICBBcHJpbCAyMDA3DQoNCg0KNy4gIENoYXJhY3RlciBTZXQgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhlIHN5bnRheCBpbiB0aGlzIGRvY3VtZW50IHJlcXVpcmVzIHRoYXQgbGFu Z3VhZ2UgdGFncyB1c2Ugb25seSB0aGUNCiAgIGNoYXJhY3RlcnMgQS1aLCBhLXosIDAtOSwg YW5kIEhZUEhFTi1NSU5VUywgd2hpY2ggYXJlIHByZXNlbnQgaW4gbW9zdA0KICAgY2hhcmFj dGVyIHNldHMsIHNvIHRoZSBjb21wb3NpdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHNob3VsZCBu b3QgaGF2ZQ0KICAgYW55IGNoYXJhY3RlciBzZXQgaXNzdWVzLg0KDQogICBSZW5kZXJpbmcg b2YgY2hhcmFjdGVycyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiBhIGxhbmd1YWdlIHRhZyBp cyBub3QNCiAgIGFkZHJlc3NlZCBpbiB0aGlzIG1lbW8uICBIaXN0b3JpY2FsbHksIHNvbWUg bGFuZ3VhZ2VzIGhhdmUgcmVsaWVkIG9uDQogICB0aGUgdXNlIG9mIHNwZWNpZmljIGNoYXJh Y3RlciBzZXRzIG9yIG90aGVyIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvDQogICBpbmZlciBo b3cgYSBzcGVjaWZpYyBjaGFyYWN0ZXIgc2hvdWxkIGJlIHJlbmRlcmVkIChub3RhYmx5IHRo aXMNCiAgIGFwcGxpZXMgdG8gbGFuZ3VhZ2UtIGFuZCBjdWx0dXJlLXNwZWNpZmljIHZhcmlh dGlvbnMgb2YgSGFuDQogICBpZGVvZ3JhcGhzIGFzIHVzZWQgaW4gSmFwYW5lc2UsIENoaW5l c2UsIGFuZCBLb3JlYW4pLiAgV2hlbiBsYW5ndWFnZQ0KICAgdGFncyBhcmUgYXBwbGllZCB0 byBzcGFucyBvZiB0ZXh0LCByZW5kZXJpbmcgZW5naW5lcyBzb21ldGltZXMgdXNlDQogICB0 aGF0IGluZm9ybWF0aW9uIGluIGRlY2lkaW5nIHdoaWNoIGZvbnQgdG8gdXNlIGluIHRoZSBh YnNlbmNlIG9mDQogICBvdGhlciBpbmZvcm1hdGlvbiwgcGFydGljdWxhcmx5IHdoZXJlIGxh bmd1YWdlcyB3aXRoIGRpc3RpbmN0IHdyaXRpbmcNCiAgIHRyYWRpdGlvbnMgdXNlIHRoZSBz YW1lIGNoYXJhY3RlcnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDU2XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICBBcHJpbCAyMDA3DQoNCg0KOC4gIENoYW5nZXMgZnJvbSBSRkMgNDY0Ng0KDQog ICBUaGUgbWFpbiBnb2FsIGZvciB0aGlzIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQgd2Fz IHRvIGluY29ycG9yYXRlDQogICBJU08gNjM5LTMgYW5kIGl0cyBhdHRlbmRlbnQgc2V0IG9m IGxhbmd1YWdlIGNvZGVzIGludG8gdGhlIElBTkENCiAgIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeSwgcGVybWl0dGluZyB0aGUgaWRlbnRpZmljYXRpb24gb2YgbWFueSBtb3JlDQogICBs YW5ndWFnZXMgYW5kIGRpYWxlY3RzIHRoYW4gcHJldmlvdXNseSBzdXBwb3J0ZWQuDQoNCiAg IFRoZSBzcGVjaWZpYyBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgdG8gbWVldCB0aGVzZSBn b2FscyBhcmU6DQoNCiAgIG8gIERlZmluZXMgdGhlIGluY29ycG9yYXRpb24gb2YgSVNPIDYz OS0zIGNvZGVzIGFzIGxhbmd1YWdlIGFuZA0KICAgICAgZXh0bGFuZyBzdWJ0YWdzLiAgRXh0 bGFuZ3MgYXJlIG5vdyBwZXJtaXR0ZWQgaW4gbGFuZ3VhZ2UgdGFncy4NCiAgICAgIFRoZSBj aGFuZ2VzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIHRoaXMgd2VyZToNCg0KICAgICAgKiAgc29t ZXRoaW5nDQoNCiAgIG8gIENoYW5nZWQgdGhlIEFCTkYgcmVsYXRlZCB0byBncmFuZGZhdGhl cmVkIHRhZ3MuICBUaGUgaXJyZWd1bGFyDQogICAgICB0YWdzIGFyZSBub3cgbGlzdGVkLiAg V2VsbC1mb3JtZWQgZ3JhbmRmYXRoZXJlZCB0YWdzIGFyZSBub3cNCiAgICAgIGRlc2NyaWJl ZCBieSB0aGUgJ2xhbmd0YWcnIHByb2R1Y3Rpb24gYW5kIHRoZSAnZ3JhbmRmYXRoZXJlZCcN CiAgICAgIHByb2R1Y3Rpb24gd2FzIHJlbW92ZWQgYXMgYSByZXN1bHQuICBBbHNvOiBhZGRl ZCBkZXNjcmlwdGlvbiBvZg0KICAgICAgYm90aCB0eXBlcyBvZiBncmFuZGZhdGhlcmVkIHRh Z3MgdG8gU2VjdGlvbiAyLjIuOC4NCg0KICAgbyAgQWRkZWQgdGhlIHBhcmFncmFwaCBvbiAi Y29sbGVjdGlvbnMiIHRvIFNlY3Rpb24gNC4xLg0KDQogICBvICBDaGFuZ2VkIHRoZSBjYXBp dGFsaXphdGlvbiBydWxlcyBmb3IgJ1RhZycgZmllbGRzIGluIFNlY3Rpb24gMy4xLg0KDQog ICBvICBTcGxpdCBzZWN0aW9uIDMuMSB1cCBpbnRvIHN1YnNlY3Rpb25zLg0KDQogICBvICBN b2RpZmllZCBzZWN0aW9uIDMuNSB0byBhbGxvdyBTdXBwcmVzcy1TY3JpcHQgZmllbGRzIHRv IGJlIGFkZGVkLA0KICAgICAgbW9kaWZpZWQsIG9yIHJlbW92ZWQgdmlhIHRoZSByZWdpc3Ry YXRpb24gcHJvY2Vzcy4gIFRoaXMgd2FzIGFuDQogICAgICBlcnJhdHVtIGZyb20gUkZDIDQ2 NDYuDQoNCiAgIG8gIE1vZGlmaWVkIGV4YW1wbGVzIHRoYXQgdXNlZCByZWdpb24gY29kZSAn Q1MnIChmb3JtZXJseSBTZXJiaWEgYW5kDQogICAgICBNb250ZW5lZ3JvKSB0byB1c2UgJ1JT JyAoU2VyYmlhKSBpbnN0ZWFkLg0KDQogICBvICBNb2RpZmllZCB0aGUgcnVsZXMgZm9yIGNy ZWF0aW5nIGFuZCBtYWludGFpbmluZyByZWNvcmQNCiAgICAgICdEZXNjcmlwdGlvbicgZmll bGRzIHRvIHByZXZlbnQgZHVwbGljYXRlcywgaW5jbHVkaW5nIGludmVydGVkDQogICAgICBk dXBsaWNhdGVzLg0KDQogICBvICBSZW1vdmVkIHRoZSBsZW5ndGh5IGRlc2NyaXB0aW9uIG9m IHdoeSBSRkMgNDY0NiB3YXMgY3JlYXRlZCBmcm9tDQogICAgICB0aGlzIHNlY3Rpb24sIHdo aWNoIGFsc28gY2F1c2VkIHRoZSByZW1vdmFsIG9mIHRoZSByZWZlcmVuY2UgdG8NCiAgICAg IFhNTCBTY2hlbWEuDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSB0ZXh0IGluIHNlY3Rpb24gMi4x IHRvIHBsYWNlIG1vcmUgZW1waGFzaXMgb24gdGhlDQogICAgICBmYWN0IHRoYXQgbGFuZ3Vh Z2UgdGFncyBhcmUgbm90IGNhc2Ugc2Vuc2l0aXZlLg0KDQogICBvICBSZXBsYWNlZCB0aGUg ZXhhbXBsZSAiZnItTGF0bi1DQSIgaW4gU2VjdGlvbiAyLjEgd2l0aCAic3ItTGF0bi1SUyIN CiAgICAgIGFuZCAiYXotQXJhYi1JUiIgYmVjYXVzZSAiZnItTGF0bi1DQSIgZG9lc24ndCBy ZXNwZWN0IHRoZQ0KICAgICAgU3VwcHJlc3MtU2NyaXB0IG9uICdMYXRuJyB3aXRoICdmcicu DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIw MDcgICAgICAgICAgICAgICBbUGFnZSA1N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoN CiAgIG8gIENoYW5nZWQgdGhlIHJlcXVpcmVtZW50cyBmb3Igd2VsbC1mb3JtZWRuZXNzIHRv IG1ha2Ugc2luZ2xldG9uDQogICAgICByZXBldGl0aW9uIGNoZWNraW5nIG9wdGlvbmFsIChp dCBpcyByZXF1aXJlZCBmb3IgdmFsaWRpdHkNCiAgICAgIGNoZWNraW5nKSBpbiBTZWN0aW9u IDIuMi45Lg0KDQogICBvICBDaGFuZ2VkIHRoZSB0ZXh0IGluIFNlY3Rpb24gMi4yLjkgcmVm ZXJpbmcgdG8gZ3JhbmRmYXRoZXJlZA0KICAgICAgY2hlY2tpbmcgdG8gbm90ZSB0aGF0IHRo ZSBsaXN0IGlzIG5vdyBpbmNsdWRlZCBpbiB0aGUgQUJORi4NCg0KICAgbyAgTW9kaWZpZWQg YW5kIGFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjIuICBUaGUgam9iIGRlc2NyaXB0aW9uIHdh cw0KICAgICAgcGxhY2VkIGZpcnN0LiAgQSBub3RlIHdhcyBhZGRlZCBtYWtpbmcgY2xlYXIg dGhhdCB0aGUgTGFuZ3VhZ2UNCiAgICAgIFN1YnRhZyBSZXZpZXdlciBtYXkgZGVsZWdhdGUg dmFyaW91cyBub24tY3JpdGljYWwgZHV0aWVzLA0KICAgICAgaW5jbHVkaW5nIGxpc3QgbW9k ZXJhdGlvbi4gIEZpbmFsbHksIGFkZGl0aW9uYWwgdGV4dCB3YXMgYWRkZWQgdG8NCiAgICAg IG1ha2UgdGhlIGFwcG9pbnRtZW50IHByb2Nlc3MgY2xlYXIgYW5kIHRvIGNsYXJpZnkgdGhh dCBkZWNpc2lvbnMNCiAgICAgIGFuZCBwZXJmb3JtYW5jZSBvZiB0aGUgcmV2aWV3ZXIgYXJl IGFwcGVhbGFibGUuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjUgY2xhcmlm eWluZyB0aGF0IHRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0DQogICAgICBpcyBvcGVyYXRlZCBi eSB3aG9tZXZlciB0aGUgSUVTRyBhcHBvaW50cy4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byBT ZWN0aW9uIDMuMS40IGNsYXJpZnlpbmcgdGhhdCB0aGUgZmlyc3QgRGVzY3JpcHRpb24NCiAg ICAgIGluIGEgJ2xhbmd1YWdlJyBvciAnZXh0bGFuZycgcmVjb3JkIG1hdGNoZXMgdGhlIGNv cnJlc3BvbmRpbmcNCiAgICAgIFJlZmVyZW5jZSBOYW1lIGZvciB0aGUgbGFuZ3VhZ2UgaW4g SVNPIDYzOS0zLg0KDQogICBvICBNb2RpZmllZCBTZWN0aW9uIDIuMi45IHRvIGRlZmluZSBj bGFzc2VzIG9mIGNvbmZvcm1hbmNlIHJlbGF0ZWQgdG8NCiAgICAgIHNwZWNpZmljIHRhZ3Mg KGZvcm1lcmx5ICd3ZWxsLWZvcm1lZCcgYW5kICd2YWxpZCcgcmVmZXJyZWQgdG8NCiAgICAg IGltcGxlbWVudGF0aW9ucykuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gdGhlIGVuZCBvZiBT ZWN0aW9uIDMuMS4yIG5vdGluZyB0aGF0IGZ1dHVyZSB2ZXJzaW9ucw0KICAgICAgb2YgdGhp cyBkb2N1bWVudCBtaWdodCBhZGQgbmV3IGZpZWxkIHR5cGVzIGFuZCByZWNvbW1lbmRpbmcg dGhhdA0KICAgICAgaW1wbGVtZW50YXRpb25zIGlnbm9yZSBhbnkgdW5yZWNvZ25pemVkIGZp ZWxkcy4NCg0KICAgbyAgTW9kaWZpZWQgdGhlICdleHRsYW5nJyBleGFtcGxlcyBpbiBBcHBl bmRpeCBBIHRvIHVzZSB2YWxpZCBzdWJ0YWdzDQogICAgICBhbmQgcmVtb3ZlZCB0aGUgbm90 ZSBzYXlpbmcgdGhhdCB0aGV5IHdlcmUgb25seSBleGFtcGxlcy4NCg0KICAgbyAgQWRkZWQg dGV4dCBhYm91dCB3aGF0IHRoZSBsYWNrIG9mIGEgU3VwcHJlc3MtU2NyaXB0IGZpZWxkIG1l YW5zIGluDQogICAgICBhIHJlY29yZCB0byBTZWN0aW9uIDMuMS45Lg0KDQogICBvICBBZGRl ZCB0ZXh0IGFsbG93aW5nIHRoZSBjb3JyZWN0aW9uIG9mIG1pc3NwZWxsaW5ncyBhbmQgdHlw b2dyYXBoaWMNCiAgICAgIGVycm9ycyB0byBTZWN0aW9uIDMuMS40Lg0KDQogICBvICBBZGRl ZCB0ZXh0IHRvIFNlY3Rpb24gMy4xLjcgZGlzYWxsb3dpbmcgUHJlZml4IGZpZWxkIGNvbmZs aWN0cw0KICAgICAgKHN1Y2ggYXMgY2lyY3VsYXIgcHJlZml4IHJlZmVyZW5jZXMpLg0KDQog ICBvICBNb2RpZmllZCB0ZXh0IGluIFNlY3Rpb24gMy41IHRvIHJlcXVpcmUgdGhlIHN1YnRh ZyByZXZpZXdlciB0bw0KICAgICAgYW5ub3VuY2UgaGlzL2hlciBkZWNpc2lvbiAob3IgZXh0 ZW5zaW9uKSBmb2xsb3dpbmcgdGhlIHR3by13ZWVrDQogICAgICBwZXJpb2QuICBBbHNvIGNs YXJpZmllZCB0aGF0IGFueSBkZWNpc2lvbiBvciBmYWlsdXJlIHRvIGRlY2lkZSBjYW4NCiAg ICAgIGJlIGFwcGVhbGVkLg0KDQogICBvICBNb2RpZmllZCB0ZXh0IGluIFNlY3Rpb24gNC4x IHRvIGluY2x1ZGUgdGhlIChoZXJldG9mb3JlIGFuZWNkb3RhbCkNCiAgICAgIGd1aWRpbmcg cHJpbmNpcGxlIG9mIHRhZyBjaG9pY2UsIGFuZCBjbGFyaWZ5aW5nIHRoZSBub24tdXNlIG9m DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIw MDcgICAgICAgICAgICAgICBbUGFnZSA1OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoN CiAgICAgIHNjcmlwdCBzdWJ0YWdzIGluIG5vbi13cml0dGVuIGFwcGxpY2F0aW9ucy4gIEFs c28gdXBkYXRlZCBleGFtcGxlcw0KICAgICAgaW4gdGhpcyBzZWN0aW9uIHRvIHVzZSBDaGFt aWMgbGFuZ3VhZ2VzIGFzIGFuIGV4YW1wbGUgb2YgbGFuZ3VhZ2UNCiAgICAgIGNvbGxlY3Rp b25zLg0KDQogICBvICBQcm9oaWJpdGVkIG11bHRpcGxlIHVzZSBvZiB0aGUgc2FtZSB2YXJp YW50IGluIGEgdGFnIChpLmUuICJkZS0NCiAgICAgIDE5MDEtMTkwMSIpLiAgUHJldmlvdXNs eSB0aGlzIHdhcyBvbmx5IGEgcmVjb21tZW5kYXRpb24NCiAgICAgICgiU0hPVUxEIikuDQoN CiAgIG8gIFJlbW92ZWQgaW5hcHByb3ByaWF0ZSBbUkZDMjExOV0gbGFuZ3VhZ2UgZnJvbSB0 aGUgaWxsdXN0cmF0aW9uIGluDQogICAgICBTZWN0aW9uIDQuMy4xLg0KDQogICBvICBSZXBs YWNlZCB0aGUgZXhhbXBsZSBvZiAiemgtZ291eXUiIHdpdGggInpoLWhha2thIi0+InpoLWhh ayIgaW4NCiAgICAgIFNlY3Rpb24gNC40LCBub3RpbmcgdGhhdCBpdCB3YXMgdGhpcyBkb2N1 bWVudCB0aGF0IGNhdXNlZCB0aGUNCiAgICAgIGNoYW5nZS4NCg0KICAgbyAgUmVwbGFjZWQg dGhlIHNlY3Rpb24gaW4gU2VjdGlvbiA0LjEgZGVhbGluZyB3aXRoICJtdWwiLyJ1bmQiIHRv DQogICAgICBpbmNsdWRlIHRoZSBzdWJ0YWdzICd6eHgnIGFuZCAnbWlzJywgYXMgd2VsbCBh cyB0aGUgdGFnDQogICAgICAiaS1kZWZhdWx0Ii4gIEEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBSRkMgMjI3NyB3YXMgYWRkZWQsIGFsb25nDQogICAgICB3aXRoIGFuIGluZm9ybWF0aXZl IHJlZmVyZW5jZSB0byBNQVJDMjEuDQoNCiAgIG8gIEFkZGVkIHRleHQgdG8gU2VjdGlvbiAz LjUgY2xhcmlmeWluZyB0aGF0IGFueSBtb2RpZmljYXRpb25zIG9mIGENCiAgICAgIHJlZ2lz dHJhdGlvbiByZXF1ZXN0IG11c3QgYmUgc2VudCB0byB0aGUgaWV0Zi1sYW5ndWFnZXMgbGlz dA0KICAgICAgYmVmb3JlIHN1Ym1pc3Npb24gdG8gSUFOQS4NCg0KICAgW1tFZC5Ob3RlOiBP cGVuIGlzc3VlcyBpbiB0aGlzIHZlcnNpb246DQoNCiAgICAgIFdoZXRoZXIgZW5jb21wYXNz ZWQgbGFuZ3VhZ2UgcnVsZXMgZm9yIHRoZSBjcmVhdGlvbiBvZiBleHRsYW5nDQogICAgICBy ZWNvcmRzIGluIHRoZSByZWdpc3RyeSBzaG91bGQgYmUgcmV0YWluZWQgb3IgbW9kaWZpZWQu DQoNCiAgICAgIE1vZGlmaWNhdGlvbiBvZiB0aGUgcmVnaXN0cnkgdG8gdXNlIFVURi04IGFz IGl0cyBjaGFyYWN0ZXINCiAgICAgIGVuY29kaW5nLiAocmVtb3ZlZCBhbmQgYXBwYXJlbnRs eSByZWplY3RlZCkNCg0KICAgICAgRGV0YWlscyBvZiB0aGUgYXBwb2ludG1lbnQsIHRlcm0g ZHVyYXRpb24sIHBlcmZvcm1hbmNlIHJldmlldyBvZg0KICAgICAgdGhlIHN1YnRhZyByZXZp ZXdlciBieSB0aGUgSUVTRy4gKGFkZHJlc3NlZD8pDQoNCiAgICAgIEluY2x1c2lvbiBvZiBh ZGRpdGlvbmFsIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gU3VwcHJlc3MtU2NyaXB0IGluDQog ICAgICB0aGUgcmVnaXN0cnkgKGUuZy4gdGhhdCBpdCB3YXNuJ3QgYXNzaWduZWQgb24gcHVy cG9zZSkNCg0KICAgXV0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdl IDU5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KOS4gIFJlZmVyZW5jZXMNCg0KOS4x LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0lTTzEwNjQ2XQ0KICAgICAgICAgICAg ICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNP L0lFQw0KICAgICAgICAgICAgICAxMDY0NjoyMDAzLiBJbmZvcm1hdGlvbiB0ZWNobm9sb2d5 IC0tIFVuaXZlcnNhbCBNdWx0aXBsZS0NCiAgICAgICAgICAgICAgT2N0ZXQgQ29kZWQgQ2hh cmFjdGVyIFNldCAoVUNTKSIsIDIwMDMuDQoNCiAgIFtJU08xNTkyNF0NCiAgICAgICAgICAg ICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklT Tw0KICAgICAgICAgICAgICAxNTkyNDoyMDA0LiBJbmZvcm1hdGlvbiBhbmQgZG9jdW1lbnRh dGlvbiAtLSBDb2RlcyBmb3IgdGhlDQogICAgICAgICAgICAgIHJlcHJlc2VudGF0aW9uIG9m IG5hbWVzIG9mIHNjcmlwdHMiLCBKYW51YXJ5IDIwMDQuDQoNCiAgIFtJU08zMTY2LTFdDQog ICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6 YXRpb24sICJJU08gMzE2Ni0NCiAgICAgICAgICAgICAgMToxOTk3LiBDb2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcw0KICAgICAgICAgICAgICBh bmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyIsIDE5OTcu DQoNCiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6 YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktDQogICAgICAgICAgICAgIDE6 MjAwMi4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFn ZXMNCiAgICAgICAgICAgICAgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiLCAyMDAyLg0KDQog ICBbSVNPNjM5LTJdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9u IGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAgICAgICAyOjE5OTgu IENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2VzDQog ICAgICAgICAgICAgIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlLCBmaXJzdCBlZGl0aW9uIiwg MTk5OC4NCg0KICAgW0lTTzYzOS0zXQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9y Z2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPIDYzOS0NCiAgICAgICAgICAg ICAgMzoyMDA3LiBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxh bmd1YWdlcw0KICAgICAgICAgICAgICAtLSBQYXJ0IDM6IEFscGhhLTMgY29kZSBmb3IgY29t cHJlaGVuc2l2ZSBjb3ZlcmFnZSBvZg0KICAgICAgICAgICAgICBsYW5ndWFnZXMiLCAyMDA3 Lg0KDQogICBbSVNPNjQ2XSAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFu ZGFyZGl6YXRpb24sICJJU08vSUVDDQogICAgICAgICAgICAgIDY0NjoxOTkxLCBJbmZvcm1h dGlvbiB0ZWNobm9sb2d5IC0tIElTTyA3LWJpdCBjb2RlZA0KICAgICAgICAgICAgICBjaGFy YWN0ZXIgc2V0IGZvciBpbmZvcm1hdGlvbiBpbnRlcmNoYW5nZS4iLCAxOTkxLg0KDQogICBb UkZDMjAyNl0gIEJyYWRuZXIsIFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNz IC0tIFJldmlzaW9uDQogICAgICAgICAgICAgIDMiLCBCQ1AgOSwgUkZDIDIwMjYsIE9jdG9i ZXIgMTk5Ni4NCg0KICAgW1JGQzIwMjhdICBIb3ZleSwgUi4gYW5kIFMuIEJyYWRuZXIsICJU aGUgT3JnYW5pemF0aW9ucyBJbnZvbHZlZCBpbg0KICAgICAgICAgICAgICB0aGUgSUVURiBT dGFuZGFyZHMgUHJvY2VzcyIsIEJDUCAxMSwgUkZDIDIwMjgsDQogICAgICAgICAgICAgIE9j dG9iZXIgMTk5Ni4NCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQg TGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAg IFtQYWdlIDYwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA3DQoNCg0KICAgW1JGQzIyNzddICBB bHZlc3RyYW5kLCBILiwgIklFVEYgUG9saWN5IG9uIENoYXJhY3RlciBTZXRzIGFuZA0KICAg ICAgICAgICAgICBMYW5ndWFnZXMiLCBCQ1AgMTgsIFJGQyAyMjc3LCBKYW51YXJ5IDE5OTgu DQoNCiAgIFtSRkMyNDM0XSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRl bGluZXMgZm9yIFdyaXRpbmcgYW4NCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9u cyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyAyNDM0LA0KICAgICAgICAgICAgICBP Y3RvYmVyIDE5OTguDQoNCiAgIFtSRkMyODYwXSAgQ2FycGVudGVyLCBCLiwgQmFrZXIsIEYu LCBhbmQgTS4gUm9iZXJ0cywgIk1lbW9yYW5kdW0gb2YNCiAgICAgICAgICAgICAgVW5kZXJz dGFuZGluZyBDb25jZXJuaW5nIHRoZSBUZWNobmljYWwgV29yayBvZiB0aGUNCiAgICAgICAg ICAgICAgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkiLCBSRkMgMjg2MCwg SnVuZSAyMDAwLg0KDQogICBbUkZDMzMzOV0gIEtseW5lLCBHLiBhbmQgQy4gTmV3bWFuLCAi RGF0ZSBhbmQgVGltZSBvbiB0aGUgSW50ZXJuZXQ6DQogICAgICAgICAgICAgIFRpbWVzdGFt cHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0KDQogICBbUkZDNDIzNF0gIENyb2NrZXIsIEQu IGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4DQogICAgICAgICAg ICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgUkZDIDQyMzQsIE9jdG9iZXIgMjAwNS4NCg0K ICAgW1JGQzQ2NDVdICBFd2VsbCwgRC4sIEVkLiwgIkluaXRpYWwgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5IiwNCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYsIDxodHRwOi8vd3d3 LmlldGYub3JnL3JmYy9yZmM0NjQ1LnR4dD4uDQoNCiAgIFtSRkM0NjQ3XSAgUGhpbGxpcHMs IEEuLCBFZC4gYW5kIE0uIERhdmlzLCBFZC4sICJNYXRjaGluZyBvZiBMYW5ndWFnZQ0KICAg ICAgICAgICAgICBUYWdzIiwgU2VwdGVtYmVyIDIwMDYsDQogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LmlldGYub3JnL3JmYy9yZmM0NjQ3LnR4dD4uDQoNCiAgIFtVTl9NLjQ5XSAgU3Rh dGlzdGljcyBEaXZpc2lvbiwgVW5pdGVkIE5hdGlvbnMsICJTdGFuZGFyZCBDb3VudHJ5IG9y DQogICAgICAgICAgICAgIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSIsIFVOIFN0 YW5kYXJkIENvdW50cnkgb3INCiAgICAgICAgICAgICAgQXJlYSBDb2RlcyBmb3IgU3RhdGlz dGljYWwgVXNlLCBSZXZpc2lvbiA0IChVbml0ZWQgTmF0aW9ucw0KICAgICAgICAgICAgICBw dWJsaWNhdGlvbiwgU2FsZXMgTm8uIDk4LlhWSUkuOSwgSnVuZSAxOTk5Lg0KDQo5LjIuICBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtNQVJDMjFdICAgTGlicmFyeSBvZiBDb25n cmVzcywgTmF0aW9uYWwgRGV2ZWxvcG1lbnQgYW5kIE1BUkMNCiAgICAgICAgICAgICAgU3Rh bmRhcmRzIE9mZmljZSwgIk1BUkMgMjEgU3BlY2lmaWNhdGlvbnMgZm9yIFJlY29yZA0KICAg ICAgICAgICAgICBTdHJ1Y3R1cmUsIENoYXJhY3RlciBTZXRzLCBhbmQgRXhjaGFuZ2UgTWVk aWEiLA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMDAsIDxodHRwOi8vd3d3LmxvYy5nb3Yv bWFyYy9zcGVjaWZpY2F0aW9ucy8+Lg0KDQogICBbUkZDMTc2Nl0gIEFsdmVzdHJhbmQsIEgu LCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAgICAgICAgICAgIExhbmd1 YWdlcyIsIFJGQyAxNzY2LCBNYXJjaCAxOTk1Lg0KDQogICBbUkZDMjA0N10gIE1vb3JlLCBL LiwgIk1JTUUgKE11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVuc2lvbnMpDQogICAg ICAgICAgICAgIFBhcnQgVGhyZWU6IE1lc3NhZ2UgSGVhZGVyIEV4dGVuc2lvbnMgZm9yIE5v bi1BU0NJSSBUZXh0IiwNCiAgICAgICAgICAgICAgUkZDIDIwNDcsIE5vdmVtYmVyIDE5OTYu DQoNCiAgIFtSRkMyMjMxXSAgRnJlZWQsIE4uIGFuZCBLLiBNb29yZSwgIk1JTUUgUGFyYW1l dGVyIFZhbHVlIGFuZCBFbmNvZGVkDQogICAgICAgICAgICAgIFdvcmQgRXh0ZW5zaW9uczog Q2hhcmFjdGVyIFNldHMsIExhbmd1YWdlcywgYW5kDQogICAgICAgICAgICAgIENvbnRpbnVh dGlvbnMiLCBSRkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0KICAgW1JGQzI3ODFdICBIb2Zm bWFuLCBQLiBhbmQgRi4gWWVyZ2VhdSwgIlVURi0xNiwgYW4gZW5jb2Rpbmcgb2YgSVNPDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMDcg ICAgICAgICAgICAgICBbUGFnZSA2MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0KDQoNCiAg ICAgICAgICAgICAgMTA2NDYiLCBSRkMgMjc4MSwgRmVicnVhcnkgMjAwMC4NCg0KICAgW1JG QzMwNjZdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBv Zg0KICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBCQ1AgNDcsIFJGQyAzMDY2LCBKYW51YXJ5 IDIwMDEuDQoNCiAgIFtSRkMzNTUyXSAgUmVzY29ybGEsIEUuIGFuZCBCLiBLb3J2ZXIsICJH dWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQw0KICAgICAgICAgICAgICBUZXh0IG9uIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIiwgQkNQIDcyLCBSRkMgMzU1MiwNCiAgICAgICAgICAgICAg SnVseSAyMDAzLg0KDQogICBbUkZDNDY0Nl0gIFBoaWxsaXBzLCBBLiwgRWQuIGFuZCBNLiBE YXZpcywgRWQuLCAiVGFncyBmb3IgdGhlDQogICAgICAgICAgICAgIElkZW50aWZpY2F0aW9u IG9mIExhbmd1YWdlcyIsIFNlcHRlbWJlciAyMDA2LA0KICAgICAgICAgICAgICA8aHR0cDov L3d3dy5pZXRmLm9yZy9yZmMvcmZjNDY0Ni50eHQ+Lg0KDQogICBbVW5pY29kZV0gIFVuaWNv ZGUgQ29uc29ydGl1bSwgIlRoZSBVbmljb2RlIENvbnNvcnRpdW0uIFRoZSBVbmljb2RlDQog ICAgICAgICAgICAgIFN0YW5kYXJkLCBWZXJzaW9uIDUuMCwgKEJvc3RvbiwgTUEsIEFkZGlz b24tV2VzbGV5LCAyMDAzLg0KICAgICAgICAgICAgICBJU0JOIDAtMzIxLTQ5MDgxLTApIiwg SmFudWFyeSAyMDA3Lg0KDQogICBbWE1MMTBdICAgIEJyYXkgKGV0IGFsKSwgVC4sICJFeHRl bnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAoWE1MKSAxLjAiLA0KICAgICAgICAgICAgICAwMiAy MDA0Lg0KDQogICBbaXNvNjM5LnByaW5dDQogICAgICAgICAgICAgIElTTyA2MzkgSm9pbnQg QWR2aXNvcnkgQ29tbWl0dGVlLCAiSVNPIDYzOSBKb2ludCBBZHZpc29yeQ0KICAgICAgICAg ICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBsZXMgZm9yIElTTyA2MzkgbWFpbnRl bmFuY2UiLA0KICAgICAgICAgICAgICBNYXJjaCAyMDAwLA0KICAgICAgICAgICAgICA8aHR0 cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi8NCiAgICAgICAgICAgICAgaXNv NjM5amFjX24zci5odG1sPi4NCg0KICAgW3JlY29yZC1qYXJdDQogICAgICAgICAgICAgIFJh eW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1taW5nIiwgMjAwMywNCiAgICAg ICAgICAgICAgPHVybjppc2JuOjAtMTMtMTQyOTAxLTk+Lg0KDQogICBbcmVnaXN0cnktdXBk YXRlXQ0KICAgICAgICAgICAgICBFd2VsbCwgRC4sIEVkLiwgIlVwZGF0ZSB0byB0aGUgTGFu Z3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IiwNCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYs IDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtcmVnaXN0cnktMDAudHh0Pi4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNjJdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFw cmlsIDIwMDcNCg0KDQpBcHBlbmRpeCBBLiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBBbnkg bGlzdCBvZiBjb250cmlidXRvcnMgaXMgYm91bmQgdG8gYmUgaW5jb21wbGV0ZTsgcGxlYXNl IHJlZ2FyZCB0aGUNCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2VsZWN0aW9uIGZyb20gdGhl IGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQ0KICAgY29udHJpYnV0ZWQgdG8gbWFrZSB0aGlz IGRvY3VtZW50IHdoYXQgaXQgaXMgdG9kYXkuDQoNCiAgIFRoZSBjb250cmlidXRvcnMgdG8g UkZDIDQ2NDYsIFJGQyA0NjQ3LCBSRkMgMzA2NiwgYW5kIFJGQyAxNzY2LCB0aGUNCiAgIHBy ZWN1cnNvcnMgb2YgdGhpcyBkb2N1bWVudCwgbWFkZSBlbm9ybW91cyBjb250cmlidXRpb25z IGRpcmVjdGx5IG9yDQogICBpbmRpcmVjdGx5IHRvIHRoaXMgZG9jdW1lbnQgYW5kIGFyZSBn ZW5lcmFsbHkgcmVzcG9uc2libGUgZm9yIHRoZQ0KICAgc3VjY2VzcyBvZiBsYW5ndWFnZSB0 YWdzLg0KDQogICBUaGUgZm9sbG93aW5nIHBlb3BsZSBjb250cmlidXRlZCB0byB0aGlzIGRv Y3VtZW50Og0KDQogICBTdGVwaGFuZSBCb3J0em1leWVyLCBLYXJlbiBCcm9vbWUsIFBldGVy IENvbnN0YWJsZSwgSm9obiBDb3dhbiwNCiAgIE1hcnRpbiBEdWVyc3QsIEZyYW5rIEVsbGVy bWFuLCBEb3VnIEV3ZWxsLCBEZWJvcmFoIEdhcnNpZGUsIE1hcmlvbg0KICAgR3VubiwgS2Vu dCBLYXJsc3NvbiwgUmFuZHkgUHJlc3VobiwgU3RlcGhlbiBTaWx2ZXIsIGFuZCBtYW55LCBt YW55DQogICBvdGhlcnMuDQoNCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBI YXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwgd2hvDQogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBh bmQgMzA2NiwgYW5kIHdpdGhvdXQgd2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBub3Qg aGF2ZSBiZWVuIHBvc3NpYmxlLg0KDQogICBTcGVjaWFsIHRoYW5rcyBnbyB0byBNaWNoYWVs IEV2ZXJzb24sIHdobyBzZXJ2ZWQgYXMgdGhlIExhbmd1YWdlIFRhZw0KICAgUmV2aWV3ZXIg Zm9yIGFsbW9zdCB0aGUgZW50aXJlIFJGQyAxNzY2L1JGQyAzMDY2IHBlcmlvZCwgYXMgd2Vs bCBhcw0KICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBzaW5jZSB0aGUgYWRvcHRp b24gb2YgUkZDIDQ2NDYuDQoNCiAgIFNwZWNpYWwgdGhhbmtzIGFsc28gdG8gRG91ZyBFd2Vs bCwgZm9yIGhpcyBwcm9kdWN0aW9uIG9mIHRoZSBmaXJzdA0KICAgY29tcGxldGUgc3VidGFn IHJlZ2lzdHJ5LCBoaXMgd29yayB0byBzdXBwb3J0IGFuZCBtYWludGFpbiBuZXcNCiAgIHJl Z2lzdHJhdGlvbnMsIGFuZCBoaXMgY2FyZWZ1bCBlZGl0b3JzaGlwIG9mIGJvdGggUkZDIDQ2 NDUgYW5kDQogICBbcmVnaXN0cnktdXBkYXRlXS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDYzXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA3DQoNCg0KQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKElu Zm9ybWF0aXZlKQ0KDQogICBTaW1wbGUgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBkZSAo R2VybWFuKQ0KDQogICAgICBmciAoRnJlbmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoN CiAgICAgIGktZW5vY2hpYW4gKGV4YW1wbGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0K ICAgTGFuZ3VhZ2Ugc3VidGFnIHBsdXMgU2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFu dCAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlw dCkNCg0KICAgICAgemgtSGFucyAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlm aWVkIENoaW5lc2Ugc2NyaXB0KQ0KDQogICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4g dXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0biAoU2VyYmlhbiB3 cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1S ZWdpb246DQoNCiAgICAgIHpoLUhhbnMtQ04gKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUg U2ltcGxpZmllZCBzY3JpcHQgYXMgdXNlZCBpbg0KICAgICAgbWFpbmxhbmQgQ2hpbmEpDQoN CiAgICAgIHNyLUxhdG4tUlMgKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2Ny aXB0IGFzIHVzZWQgaW4NCiAgICAgIFNlcmJpYSkNCg0KICAgTGFuZ3VhZ2UtVmFyaWFudDoN Cg0KICAgICAgc2wtcm96YWogKFJlc2lhbiBkaWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAg ICAgc2wtbmVkaXMgKE5hZGl6YSBkaWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgTGFuZ3Vh Z2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAgICAgIGRlLUNILTE5MDEgKEdlcm1hbiBhcyB1c2Vk IGluIFN3aXR6ZXJsYW5kIHVzaW5nIHRoZSAxOTAxIHZhcmlhbnQNCiAgICAgIFtvcnRob2dy YXBoeV0pDQoNCiAgICAgIHNsLUlULW5lZGlzIChTbG92ZW5pYW4gYXMgdXNlZCBpbiBJdGFs eSwgTmFkaXphIGRpYWxlY3QpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb24tVmFyaWFu dDoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNjRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmls IDIwMDcNCg0KDQogICAgICBoeS1MYXRuLUlULWFyZXZlbGEgKEVhc3Rlcm4gQXJtZW5pYW4g d3JpdHRlbiBpbiBMYXRpbiBzY3JpcHQsIGFzDQogICAgICB1c2VkIGluIEl0YWx5KQ0KDQog ICBMYW5ndWFnZS1SZWdpb246DQoNCiAgICAgIGRlLURFIChHZXJtYW4gZm9yIEdlcm1hbnkp DQoNCiAgICAgIGVuLVVTIChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMp DQoNCiAgICAgIGVzLTQxOSAoU3BhbmlzaCBhcHByb3ByaWF0ZSBmb3IgdGhlIExhdGluIEFt ZXJpY2EgYW5kIENhcmliYmVhbg0KICAgICAgcmVnaW9uIHVzaW5nIHRoZSBVTiByZWdpb24g Y29kZSkNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFnczoNCg0KICAgICAgZGUtQ0gteC1waG9u ZWJrDQoNCiAgICAgIGF6LUFyYWIteC1BWkUtZGVyYmVuZA0KDQogICBFeHRlbmRlZCBsYW5n dWFnZSBzdWJ0YWdzOg0KDQogICAgICB6aC1jbW4NCg0KICAgICAgemgtY21uLUhhbnQtQ04N Cg0KICAgUHJpdmF0ZSB1c2UgcmVnaXN0cnkgdmFsdWVzOg0KDQogICAgICB4LXdoYXRldmVy IChwcml2YXRlIHVzZSB1c2luZyB0aGUgc2luZ2xldG9uICd4JykNCg0KICAgICAgcWFhLVFh YWEtUU0teC1zb3V0aGVybiAoYWxsIHByaXZhdGUgdGFncykNCg0KICAgICAgZGUtUWFhYSAo R2VybWFuLCB3aXRoIGEgcHJpdmF0ZSBzY3JpcHQpDQoNCiAgICAgIHNyLUxhdG4tUU0gKFNl cmJpYW4sIExhdGluLXNjcmlwdCwgcHJpdmF0ZSByZWdpb24pDQoNCiAgICAgIHNyLVFhYWEt UlMgKFNlcmJpYW4sIHByaXZhdGUgc2NyaXB0LCBmb3IgU2VyYmlhKQ0KDQogICBUYWdzIHRo YXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1wbGVzIE9OTFk6IGV4dGVuc2lvbnMgTVVTVCBiZSBk ZWZpbmVkDQogICBieSByZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCBvciBi eSBSRkMpOg0KDQogICAgICBlbi1VUy11LWlzbGFtQ2FsDQoNCiAgICAgIHpoLUNOLWEtbXlF eHQteC1wcml2YXRlDQoNCiAgICAgIGVuLWEtbXlFeHQtYi1hbm90aGVyDQoNCiAgIFNvbWUg SW52YWxpZCBUYWdzOg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGly ZXMgTm92ZW1iZXIgMSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDY1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA3DQoNCg0KICAgICAgZGUtNDE5LURFICh0d28gcmVnaW9uIHRhZ3MpDQoN CiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFnIGluIHByaW1h cnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRoYXQgdGhlcmUgYXJlIGEgZmV3IGdyYW5kZmF0 aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImktIiB0aGF0DQogICAgICBhcmUgdmFsaWQp DQoNCiAgICAgIGFyLWEtYWFhLWItYmJiLWEtY2NjICh0d28gZXh0ZW5zaW9ucyB3aXRoIHNh bWUgc2luZ2xlLWxldHRlcg0KICAgICAgcHJlZml4KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMDcgICAgICAgICAgICAgICBbUGFnZSA2Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K DQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBBZGRpc29uIFBoaWxsaXBzIChlZGl0b3Ip DQogICBZYWhvbyEgSW5jLg0KDQogICBFbWFpbDogYWRkaXNvbkBpbnRlci1sb2NhbGUuY29t DQogICBVUkk6ICAgaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tDQoNCg0KICAgTWFyayBE YXZpcyAoZWRpdG9yKQ0KICAgR29vZ2xlDQoNCiAgIEVtYWlsOiBtYXJrLmRhdmlzQG1hY2No aWF0by5jb20gb3IgbWFyay5kYXZpc0Bnb29nbGUuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDA3ICAg ICAgICAgICAgICAgW1BhZ2UgNjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDcNCg0KDQpGdWxs IENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVz dCAoMjAwNykuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRz LCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zDQogICBjb250YWluZWQgaW4gQkNQIDc4LCBh bmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycw0KICAgcmV0YWlu IGFsbCB0aGVpciByaWdodHMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBi YXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBS RVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBT T0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQNCiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklO RyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTDQogICBPUiBJ TVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU IFRIRSBVU0UgT0YNCiAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KSW50 ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJl Z2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQg dG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVj aG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0 byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWln aHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz DQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2gg cmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVj dCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3 OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8g dGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1w dCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0 aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMg b3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJv bSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0 eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50 cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmln aHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8g aW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9y bWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpBY2tu b3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBp cyBwcm92aWRlZCBieSB0aGUgSUVURg0KICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rp dml0eSAoSUFTQSkuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJl cyBOb3ZlbWJlciAxLCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgNjhdDQoMDQo= --------------080700050806030009050507 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 --------------080700050806030009050507-- From ltru-bounces@ietf.org Mon Apr 30 12:47: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 1HiZ1k-0000R5-VT; Mon, 30 Apr 2007 12:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZ1k-0000R0-1Y for ltru@ietf.org; Mon, 30 Apr 2007 12:47:04 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZ1i-0003WJ-N4 for ltru@ietf.org; Mon, 30 Apr 2007 12:47:04 -0400 Received: from [10.72.72.38] (snvvpn1-10-72-72-c38.corp.yahoo.com [10.72.72.38]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l3UGksbu015085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Apr 2007 09:46: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:subject: content-type:content-transfer-encoding; b=qqtis+icaVProcdeVItlWd/K1xGSbyRaoY7p3/TWT+4aZKkmDX+C17mhRTriCpK6 Message-ID: <46361D7D.4050609@yahoo-inc.com> Date: Mon, 30 Apr 2007 09:46:53 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] draft-05 changes, etc. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I just submitted draft-05. Note that I made some edits this morning in an attempt to fix the thread on collections. I note that we actually had a separate paragraph recommending against the use of collections separate from the bullet list about 'mis'/'mul'/'und', etc. I merged this with the other text, removed the word "special", and did additional edits to address comments on the list. Check it out. Inter-locale is up-to-date, including the wdiff link (or use http://tinyurl.com/2kctcy) Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 30 19:08: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 1HiezC-0002za-I9; Mon, 30 Apr 2007 19:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiezB-0002zP-Fk for ltru@ietf.org; Mon, 30 Apr 2007 19:08:49 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiez9-0006dg-01 for ltru@ietf.org; Mon, 30 Apr 2007 19:08:49 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2253799nzd for ; Mon, 30 Apr 2007 16:08:46 -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=HSZx2Ow15BqDij837F4IatKRLVjfrXeHxREmqTz/0dcPQ5h3YH5EUw0Ay2ZUmezLEwFTDSTxgALau8WS+VSUIJmLV6D4Oaxy3/6RhYYbmcUmgCOXHyH/iUL1+GXXs7vsEgLgZuFlM4o3fcKYFdp5zYNVC53ffxPThIEFrOCNlto= 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=WjZLnd0j5uuPJP5+kfGOJGX5fZeOtW/vnVmxJIsLSJz+/fXFUFqwe1g5f0qOgzUO1DV3Hsft1ngbECyCK1uCrtiJ1AWyP2UOsjicDuytMjTzPMrqI3QeZ1gkEZMg19nQMKdcmE887DNDo9t6YRm8Z18UTLk6fVrPPmR8qZTSf4k= Received: by 10.114.137.2 with SMTP id k2mr2161793wad.1177974525873; Mon, 30 Apr 2007 16:08:45 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Mon, 30 Apr 2007 16:08:45 -0700 (PDT) Message-ID: <30b660a20704301608n149efe16mc207206212643706@mail.gmail.com> Date: Mon, 30 Apr 2007 16:08:45 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: modification of Prefix fields In-Reply-To: <463615D3.5020908@yahoo-inc.com> MIME-Version: 1.0 References: <003c01c78a91$205ff8c0$6401a8c0@DGBP7M81> <463615D3.5020908@yahoo-inc.com> X-Google-Sender-Auth: 50bbdcab5782938b X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============0681261075==" Errors-To: ltru-bounces@ietf.org --===============0681261075== Content-Type: multipart/alternative; boundary="----=_Part_131462_24639372.1177974525792" ------=_Part_131462_24639372.1177974525792 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd suggest slightly different wording, since saying that it cannot be removed but can be modified is a bit odd. So I'd suggest: The collection of fields of type 'Prefix' MUST NOT be changed in a way that narrows the meaning of the subtag. If there is no Prefix, then one cannot be added. If there a Prefix, then others can be added. A Prefix can be removed only if it is redundant: there is another Prefix that covers all of the cases that it does. For example: Prefix: zh-Hant Prefix: zh-Hans can be replaced by Prefix: zh Prefix: ru This is because addition of zh makes zh-Hant and zh-Hans redundant, so they can be removed, and the addition of "ru" only broadens. Mark On 4/30/07, Addison Phillips wrote: > > I changed the first instance to read: > > 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). > > Addison > > Doug Ewell wrote: > > Stephen Silver wrote: > > > >> The current draft of 4646bis disagrees with itself on the question of > >> whether 'Prefix' fields can be modified. > >> > >> In section 3.1.7, it says: > >> > >> The field of type 'Prefix' MUST NOT be removed from any record. > >> The field-body for this type of field MUST NOT be modified. > >> > >> But in section 3.4, bullet 4, it says: > >> > >> 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. > > > > Good catch. This wording was carried over from RFC 4646, where we in > > LTRU started out thinking that no modifications should be allowed, and > > then came to understand the potential for multiple prefixes or > > broadening changes. We need to change the first passage to match the > > second. > > > > -- > > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > > http://users.adelphia.net/~dewell/ > > http://www1.ietf.org/html.charters/ltru-charter.html > > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_131462_24639372.1177974525792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline  I'd suggest slightly different wording, since saying that it cannot be removed but can be modified is a bit odd. So I'd suggest:

The collection of fields of type 'Prefix' MUST NOT be changed in a way that narrows the meaning of the subtag. If there is no Prefix, then one cannot be added. If there a Prefix, then others can be added. A Prefix can be removed only if it is redundant: there is another Prefix that covers all of the cases that it does. For example:
  Prefix: zh-Hant
  Prefix: zh-Hans
can be replaced by
  Prefix: zh
  Prefix: ru
This is because addition of zh makes zh-Hant and zh-Hans redundant, so they can be removed, and the addition of "ru" only broadens.

Mark

On 4/30/07, Addison Phillips < addison@yahoo-inc.com> wrote:
I changed the first instance to read:

<t>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).</t>

Addison

Doug Ewell wrote:
> Stephen Silver <ltru at argentum dot freeserve dot co dot uk> wrote:
>
>> The current draft of 4646bis disagrees with itself on the question of
>> whether 'Prefix' fields can be modified.
>>
>> In section 3.1.7, it says:
>>
>>  The field of type 'Prefix' MUST NOT be removed from any record.
>>  The field-body for this type of field MUST NOT be modified.
>>
>> But in section 3.4, bullet 4, it says:
>>
>>  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.
>
> Good catch.  This wording was carried over from RFC 4646, where we in
> LTRU started out thinking that no modifications should be allowed, and
> then came to understand the potential for multiple prefixes or
> broadening changes.  We need to change the first passage to match the
> second.
>
> --
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
> http://users.adelphia.net/~dewell/
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

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

Internationalization is an architecture.
It is not a feature.

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



--
Mark ------=_Part_131462_24639372.1177974525792-- --===============0681261075== 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 --===============0681261075==-- From ltru-bounces@ietf.org Mon Apr 30 23:59: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 1HijW5-00083Y-Lt; Mon, 30 Apr 2007 23:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HijW4-0007yt-1t for ltru@lists.ietf.org; Mon, 30 Apr 2007 23:59:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HijVz-00048E-Ev for ltru@lists.ietf.org; Mon, 30 Apr 2007 23:59:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HijVo-0003dL-DG for ltru@lists.ietf.org; Tue, 01 May 2007 05:58:48 +0200 Received: from 1cust153.tnt3.hbg2.deu.da.uu.net ([149.225.14.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 05:58:48 +0200 Received: from nobody by 1cust153.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 05:58:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 01 May 2007 05:57:56 +0200 Organization: Lines: 18 Message-ID: <4636BAC4.6DAB@xyzzy.claranet.de> References: <003c01c78a91$205ff8c0$6401a8c0@DGBP7M81> <463615D3.5020908@yahoo-inc.com> <30b660a20704301608n149efe16mc207206212643706@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust153.tnt3.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: modification of Prefix fields X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Prefix: zh-Hant > Prefix: zh-Hans > can be replaced by > Prefix: zh > Prefix: ru > This is because addition of zh makes zh-Hant and zh-Hans redundant, > so they can be removed, and the addition of "ru" only broadens. For 4646bis we might better stay away from zh-tags in examples (?) Otherwise your wording is a bit clearer, matter of taste, probably. In your version s/because addition/because the addition/ In Addison's version s/a prefix a prefix/a prefix/ (?) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru