From ltru-bounces@ietf.org Wed Nov 02 11:41:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLfd-0006qs-Hr; Wed, 02 Nov 2005 11:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLfc-0006pE-AB for ltru@megatron.ietf.org; Wed, 02 Nov 2005 11:41:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18276 for ; Wed, 2 Nov 2005 11:40:42 -0500 (EST) Received: from mail01.svc.cra.dublin.eircom.net ([159.134.118.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXLuC-0001uy-Q0 for ltru@ietf.org; Wed, 02 Nov 2005 11:56:11 -0500 Received: (qmail 5171 messnum 7067001 invoked from network[159.134.169.10/159-134-169-10.as1.prp.dublin.eircom.net]); 2 Nov 2005 16:40:49 -0000 Received: from 159-134-169-10.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.10) by mail01.svc.cra.dublin.eircom.net (qp 5171) with SMTP; 2 Nov 2005 16:40:49 -0000 Message-ID: <4368EC21.4193FEF9@egt.ie> Date: Wed, 02 Nov 2005 16:41:04 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: TC46-L Information and Documentation Technology List , ltru@ietf.org Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA18276 Cc: Subject: [Ltru] Re: =?iso-8859-1?q?=C5land?= X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Exactly. So the obvious solution is for both UK and GB to be accommodated in ISO 3166, unless you can find a good reason to oppose that. Can you? mg Scr=EDobh Jon Hanna: >=20 > ISO 3166 (part two of which is > > currently under review), which equates GB ('Great Britain') to a > > higher-level territory (UK) of which it is only a part ('The United > > Kingdom of Great Britain and Northern Ireland') and which ignores the > > fact that the e-mail territorial address identifier for the entire > > territory is actually .UK (as in www.bbc.co.uk, smo.uhi.ac,uk, > > www.qub.ac.uk, www.cadw.wales.gov.uk, etc., etc.). >=20 > Much like the way Shakespeare often got it wrong when he wrote somethin= g > I would quote. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 02 11:59:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLx7-0006ve-BA; Wed, 02 Nov 2005 11:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLx4-0006vP-QK for ltru@megatron.ietf.org; Wed, 02 Nov 2005 11:59:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20899 for ; Wed, 2 Nov 2005 11:58:45 -0500 (EST) Received: from mail.arena1.com ([63.116.216.137] helo=communicraft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMBg-0003QA-8e for ltru@ietf.org; Wed, 02 Nov 2005 12:14:13 -0500 Received: from [192.168.100.14] [63.116.216.137] by communicraft.com with ESMTP (SMTPD32-8.05) id A0382D850124; Wed, 02 Nov 2005 11:58:32 -0500 Message-ID: <4368F186.3040907@hackcraft.net> Date: Wed, 02 Nov 2005 17:04:06 +0000 From: Jon Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] Re: =?UTF-8?B?w4VsYW5k?= References: <4368EC21.4193FEF9@egt.ie> In-Reply-To: <4368EC21.4193FEF9@egt.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [63.116.216.137] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > Exactly. So the obvious solution is for both UK and GB to be > accommodated in ISO 3166, unless you can find a good reason to oppose > that. Can you? There is no need to encode Great Britain in ISO 3166. It is not a sovereign state separate from the United Kingdom, nor has there been any desire expressed on the part of the British to have Great Britain so encoded. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 02 12:09:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM6s-0003oo-4m; Wed, 02 Nov 2005 12:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM6q-0003ob-3Q for ltru@megatron.ietf.org; Wed, 02 Nov 2005 12:09:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21787 for ; Wed, 2 Nov 2005 12:08:50 -0500 (EST) Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXMLR-00040z-RZ for ltru@ietf.org; Wed, 02 Nov 2005 12:24:19 -0500 Received: (qmail 76374 messnum 5379534 invoked from network[159.134.169.10/159-134-169-10.as1.prp.dublin.eircom.net]); 2 Nov 2005 17:09:00 -0000 Received: from 159-134-169-10.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.10) by mail08.svc.cra.dublin.eircom.net (qp 76374) with SMTP; 2 Nov 2005 17:09:00 -0000 Message-ID: <4368F2BB.EC12A7D0@egt.ie> Date: Wed, 02 Nov 2005 17:09:15 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jon Hanna Subject: Re: [Ltru] Re: =?iso-8859-1?Q?=C5land?= References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA21787 Cc: ltru@ietf.org, TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org But that is already been encoded there (as GB); the code 3166 fails to encode is the e-mail domain (UK).=20 mg Scr=EDobh Jon Hanna: >=20 > Marion Gunn wrote: > > Exactly. So the obvious solution is for both UK and GB to be > > accommodated in ISO 3166, unless you can find a good reason to oppos= e > > that. Can you? >=20 > There is no need to encode Great Britain in ISO 3166. It is not a > sovereign state separate from the United Kingdom, nor has there been an= y > desire expressed on the part of the British to have Great Britain so > encoded. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 02 12:34:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMVP-0000Vp-Ix; Wed, 02 Nov 2005 12:34:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMVN-0000Qo-JT for ltru@megatron.ietf.org; Wed, 02 Nov 2005 12:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23864 for ; Wed, 2 Nov 2005 12:34:12 -0500 (EST) Received: from mail.arena1.com ([63.116.216.137] helo=communicraft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMjz-0005TP-V6 for ltru@ietf.org; Wed, 02 Nov 2005 12:49:41 -0500 Received: from [192.168.100.14] [63.116.216.137] by communicraft.com with ESMTP (SMTPD32-8.05) id A871D0900D6; Wed, 02 Nov 2005 12:33:37 -0500 Message-ID: <4368F9C3.2010204@hackcraft.net> Date: Wed, 02 Nov 2005 17:39:15 +0000 From: Jon Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Re: =?UTF-8?B?w4VsYW5k?= References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> In-Reply-To: <4368F2BB.EC12A7D0@egt.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [63.116.216.137] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > But that is already been encoded there (as GB); The United Kingdom has already been encoded there (as GB). Great Britain has not. A cursory glance at ISO 3166 confirms this. the code 3166 fails to > encode is the e-mail domain (UK). > mg ccTLD names are not in scope for ISO 3166. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 02 13:30:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNNY-0004mV-JK; Wed, 02 Nov 2005 13:30:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNNT-0004iQ-M7 for ltru@megatron.ietf.org; Wed, 02 Nov 2005 13:30:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29220 for ; Wed, 2 Nov 2005 13:30:05 -0500 (EST) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXNc6-0000U6-8g for ltru@ietf.org; Wed, 02 Nov 2005 13:45:35 -0500 Received: (qmail 21774 messnum 2900157 invoked from network[159.134.169.59/159-134-169-59.as1.prp.dublin.eircom.net]); 2 Nov 2005 18:30:13 -0000 Received: from 159-134-169-59.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.59) by mail07.svc.cra.dublin.eircom.net (qp 21774) with SMTP; 2 Nov 2005 18:30:13 -0000 Message-ID: <436905C3.93855506@egt.ie> Date: Wed, 02 Nov 2005 18:30:28 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: unicode@unicode.org, harald@alvestrand.no Subject: Re: [Ltru] Re: =?iso-8859-1?Q?=C5land?= References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA29220 Cc: TC46-L Information and Documentation Technology List , 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scr=EDobh Jon Hanna: >=20 > There is no need to encode Great Britain in ISO 3166. It is not a > sovereign state separate from the United Kingdom... Yes, I guess we all have to agree with you on the above point. > The United Kingdom has already been encoded there (as GB). Great Britai= n > has not. A cursory glance at ISO 3166 confirms this... Exactly - only a cursory glance!=20 Only look beyond that and see how reality requires 'UK' be included in ISO 3166 to accommodate the actual fact (reality) that the e-mail territorial address identifier for the entire territory (Great Britain _and_ Northern Ireland) is actually .UK (as in www.bbc.co.uk, smo.uhi.ac,uk, www.qub.ac.uk, www.cadw.wales.gov.uk, etc., etc.). Only logical. Again, the request is not to change 'GB', but only to add 'UK' as the identifier already in use for e-mail and websites. In passing, I do not pretend either to understand or agree with what Harald says (below), but suppose one must take it into account. mg Scr=EDobh Harald Tveit Alvestrand: > ... > "United Kingdom" is a stupid name for a > country, but the British seem to be attached to it - allocating the .uk > domain to the British academics in the early 80s was a mistake by Jon > Postel, but the inconsistency is not terribly harmful. >=20 > "GB" is the first letter in the third and fourth word of the formal nam= e of > the country (fourth and fifth if you count "of"). It's the ISO 3166 > agency's choice, and theirs to change if they ever want to. >=20 > I hope they don't. Too much work with no benefit. > Harald=20 --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 02 15:08:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOu9-0002l3-Fc; Wed, 02 Nov 2005 15:08:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOu6-0002jD-0H for ltru@megatron.ietf.org; Wed, 02 Nov 2005 15:08:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05779 for ; Wed, 2 Nov 2005 15:07:51 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXP8h-0004TT-Ja for ltru@ietf.org; Wed, 02 Nov 2005 15:23:22 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 059262596DB; Wed, 2 Nov 2005 21:07:17 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12976-08; Wed, 2 Nov 2005 21:07:13 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 844442596DC; Wed, 2 Nov 2005 21:07:12 +0100 (CET) Date: Wed, 02 Nov 2005 20:12:34 +0100 From: Harald Tveit Alvestrand To: unicode@unicode.org Subject: =?UTF-8?Q?Re:_[Ltru]_Re:_=C3=85land?= Message-ID: <361707C27A8B494B8297CCA5@B50854F0A9192E8EC6CDA126> In-Reply-To: <436905C3.93855506@egt.ie> References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> <436905C3.93855506@egt.ie> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============0995198026==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0995198026== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========94D88D96ADC323FECB46==========" --==========94D88D96ADC323FECB46========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Note to the lists: The text Marion quotes was sent in private email. I did not send it to any mailing lists, and had no wish to bring the topic=20 to either the Unicode, the LTRU or the TC46 list. My apologies if this message serves to prolong such debate on those lists;=20 it might be relevant to TC46, but I don't think it's relevant to Unicode or = LTRU. Harald Alvestrand --On 2. november 2005 18:30 +0000 Marion Gunn wrote: > In passing, I do not pretend either to understand or agree with what > Harald says (below), but suppose one must take it into account. --==========94D88D96ADC323FECB46========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDaQ+iOMj+2+WY0F4RAhJGAJ4qvysP8/QQgR1P25LUnB8RK6TAMQCeIs/+ WbB5eLsP14hOafjOkLYOfdo= =KYXs -----END PGP SIGNATURE----- --==========94D88D96ADC323FECB46==========-- --===============0995198026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0995198026==-- From ltru-bounces@ietf.org Wed Nov 02 20:32:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXTy7-00036B-Hi; Wed, 02 Nov 2005 20:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIbV-0007kK-EK for ltru@megatron.ietf.org; Wed, 02 Nov 2005 08:24:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05694 for ; Wed, 2 Nov 2005 08:24:14 -0500 (EST) Received: from mail09.svc.cra.dublin.eircom.net ([159.134.118.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXIq4-0000xO-SI for ltru@ietf.org; Wed, 02 Nov 2005 08:39:42 -0500 Received: (qmail 13246 messnum 2875353 invoked from network[159.134.168.191/159-134-168-191.as1.prp.dublin.eircom.net]); 2 Nov 2005 13:24:15 -0000 Received: from 159-134-168-191.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.191) by mail09.svc.cra.dublin.eircom.net (qp 13246) with SMTP; 2 Nov 2005 13:24:15 -0000 Message-ID: <4368BDFF.DD8CD48D@egt.ie> Date: Wed, 02 Nov 2005 13:24:15 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Kent Karlsson , unicode@unicode.org, ietf-languages@alvestrand.no References: <001701c5df91$facb0bf0$6400a8c0@chalmers95a69n> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA05694 X-Mailman-Approved-At: Wed, 02 Nov 2005 20:32:41 -0500 Cc: Subject: [Ltru] Re: =?iso-8859-1?q?=C5land?= X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org That is only due to a misleading bug in ISO 3166 (part two of which is currently under review), which equates GB ('Great Britain') to a higher-level territory (UK) of which it is only a part ('The United Kingdom of Great Britain and Northern Ireland') and which ignores the fact that the e-mail territorial address identifier for the entire territory is actually .UK (as in www.bbc.co.uk, smo.uhi.ac,uk, www.qub.ac.uk, www.cadw.wales.gov.uk, etc., etc.). Hope this helps, mg Scr=EDobh Kent Karlsson: >=20 >=20 > The English name for the territory code "GB" is "United Kingdom"... >=20 > /kent k --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 03 07:36:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXeKN-0000yc-K5; Thu, 03 Nov 2005 07:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXeKL-0000yX-Op for ltru@megatron.ietf.org; Thu, 03 Nov 2005 07:36:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28101 for ; Thu, 3 Nov 2005 07:35:59 -0500 (EST) Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXeZ7-0008TR-UN for ltru@ietf.org; Thu, 03 Nov 2005 07:51:39 -0500 Received: (qmail 86856 messnum 4212477 invoked from network[159.134.168.69/159-134-168-69.as1.prp.dublin.eircom.net]); 3 Nov 2005 12:36:07 -0000 Received: from 159-134-168-69.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.69) by mail13.svc.cra.dublin.eircom.net (qp 86856) with SMTP; 3 Nov 2005 12:36:07 -0000 Message-ID: <436A0443.FF78350A@egt.ie> Date: Thu, 03 Nov 2005 12:36:20 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ltru@ietf.org, TC46-L@LISTSERV.HEANET.IE Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA28101 Cc: Subject: [Ltru] ISO 3166-2 vote (was: Re: =?iso-8859-1?q?=C5land?= ) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Thank you all for your responses, especially John.=20 I'll try to make one reply fit all, offering apologies to anyone feeling the topic is out of place on his/her list, or outside their norma= l field of expertise. This is a relatively simple matter of 3 facts and 1 question.=20 F1 ISO 3166-2 is currently under review; F2 UK is Northern Ireland's e-mail/webtag; F3 UK is not currently listed in ISO 3166. Q1 Woul you like to support its inclusion? If you do, your National Body can act on that. If you dont, the question just goes away for another 5 years. Either way, asking is good and no harm can be done. mg=20 Scr=EDobh John Clews: >=20 > Just to put some sense into this discussion from a UK resident: most ot= her > correspondents about GB/UK are not UK residents. >=20 > I find myself agreeing with some elements from most contributors, but > would also like to add some additional facts and corrections. >=20 > 1. The formal name of the country concerned is >=20 > - The United Kingdom of Great Britain and Northern Ireland >=20 > 2. UK is the most common 2-letter abbreviation used in speech and in > writing to describe the country as a whole, with _extremely_ wide use. >=20 > 3. Nobody uses GB as a 2-letter abbreviation used in speech and in > writing, as the code begs the question "does GB include Northern Irelan= d > or not?" >=20 > In general, GB as a code causes more questions than does the UK as a co= de.... =20 --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 03 07:47:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXeUn-0004St-GB; Thu, 03 Nov 2005 07:47:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXeUl-0004R9-BS for ltru@megatron.ietf.org; Thu, 03 Nov 2005 07:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28641 for ; Thu, 3 Nov 2005 07:46:44 -0500 (EST) Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXejX-0000be-FL for ltru@ietf.org; Thu, 03 Nov 2005 08:02:24 -0500 Received: (qmail 55070 messnum 5381697 invoked from network[159.134.168.69/159-134-168-69.as1.prp.dublin.eircom.net]); 3 Nov 2005 12:46:55 -0000 Received: from 159-134-168-69.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.69) by mail08.svc.cra.dublin.eircom.net (qp 55070) with SMTP; 3 Nov 2005 12:46:55 -0000 Message-ID: <436A06CD.AD77D7A1@egt.ie> Date: Thu, 03 Nov 2005 12:47:09 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [Ltru] Re: =?iso-8859-1?Q?=C5land?= References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> <436905C3.93855506@egt.ie> <361707C27A8B494B8297CCA5@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA28641 Cc: ltru@ietf.org, unicode@unicode.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Sigh - apologies to Harald, then - it is hard to direct such volumes of traffic suitably (having a relevant ISO 3166 list might help). mg Scr=EDobh Harald Tveit Alvestrand: >=20 > Note to the lists... > Harald Alvestrandi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 03 08:23:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXf3v-0007ej-Tv; Thu, 03 Nov 2005 08:23:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXf3u-0007ee-HX for ltru@megatron.ietf.org; Thu, 03 Nov 2005 08:23:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00655 for ; Thu, 3 Nov 2005 08:23:04 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXfIh-00026t-AU for ltru@ietf.org; Thu, 03 Nov 2005 08:38:44 -0500 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EXf3h-0001eb-VY; Thu, 03 Nov 2005 05:23:14 -0800 Message-Id: <6.2.3.4.2.20051103141635.04f67aa0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 03 Nov 2005 14:22:52 +0100 To: Marion Gunn From: r&d afrac Subject: Re: [Ltru] Re: Åland In-Reply-To: <436A06CD.AD77D7A1@egt.ie> References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> <436905C3.93855506@egt.ie> <361707C27A8B494B8297CCA5@B50854F0A9192E8EC6CDA126> <436A06CD.AD77D7A1@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 13:47 03/11/2005, Marion Gunn wrote: >Sigh - apologies to Harald, then - it is hard to direct such volumes of >traffic suitably (having a relevant ISO 3166 list might help). >mg if that can be of interest to you, I can set-up http://3166.info and run a mailing list on it for you. I agree it would unload a lot of mailing lists. However in the case of this WG I still have difficulties undestanding what an administrative boarder can have to do with a language. But if it may help, you welcome. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 03 18:53:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXotv-0003Bq-UM; Thu, 03 Nov 2005 18:53:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXclJ-0002SI-Le for ltru@megatron.ietf.org; Thu, 03 Nov 2005 05:56:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23465 for ; Thu, 3 Nov 2005 05:55:43 -0500 (EST) Received: from mailout.uk2.net ([83.170.69.139] helo=webmailsmtp1.uk2net.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXczy-0003lt-0i for ltru@ietf.org; Thu, 03 Nov 2005 06:11:22 -0500 Received: from [10.0.1.59] (helo=mailnew-9.uk2.net) by webmailsmtp1.uk2net.com with smtp (Exim 4.43) id 1EXcl2-00040O-D5; Thu, 03 Nov 2005 10:55:48 +0000 Received: from 62.252.224.13 (proxying for 82.24.192.41) (SquirrelMail authenticated user scripts20) by maxproxy9.uk2net.com with HTTP; Thu, 3 Nov 2005 10:55:48 -0000 (GMT) Message-ID: <40690.62.252.224.13.1131015348.squirrel@maxproxy9.uk2net.com> In-Reply-To: <436905C3.93855506@egt.ie> References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> <436905C3.93855506@egt.ie> Date: Thu, 3 Nov 2005 10:55:48 -0000 (GMT) Subject: UK/GB - United Kingdom [Re: [Ltru] Re: =?iso-8859-1?Q?=C5land]?= From: "John Clews" To: "Marion Gunn" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Score: 4.5 (++++) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA23465 X-Mailman-Approved-At: Thu, 03 Nov 2005 18:53:47 -0500 Cc: TC46-L Information and Documentation Technology List , ltru@ietf.org, unicode@unicode.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Just to put some sense into this discussion from a UK resident: most othe= r correspondents about GB/UK are not UK residents. I find myself agreeing with some elements from most contributors, but would also like to add some additional facts and corrections. 1. The formal name of the country concerned is - The United Kingdom of Great Britain and Northern Ireland 2. UK is the most common 2-letter abbreviation used in speech and in writing to describe the country as a whole, with _extremely_ wide use. 3. Nobody uses GB as a 2-letter abbreviation used in speech and in writing, as the code begs the question "does GB include Northern Ireland or not?" In general, GB as a code causes more questions than does the UK as a code. 4. In ISO 3166, GB is the code for - The United Kingdom of Great Britain and Northern Ireland This follows official government policy (unreviewed in several decades) 5. In Internet domain naming, ISO 3166, UK is the code for - The United Kingdom of Great Britain and Northern Ireland This follows popular usage of UK. 6. In Eurostat NUTS codes, UK is the code for - The United Kingdom of Great Britain and Northern Ireland This follows popular usage of UK. 7. We all hapily put up with the problems: GB in ISO 3166 maps 1:1 with U= K in Eurostat NUTS and Internet domain names. 8. UK existed in domain names before Jan Postel allocated them, and I don't think it is fair to Jan to say that this was a mistake. When the JANET system managed UK academic domain names prior to that, domain names were something like ... uk.ac.leeds and it was very easy to do a major global change to ... leeds.ac.uk for all universities Best regards John Clews ---------------------------- Original Message ---------------------------= - Marion wrote, re: [Fwd: Re: [Ltru] Re: =C5land] -------------------------------------------------------------------------= - Subject: Re: [Ltru] Re: =C5land From: "Marion Gunn" Date: Wed, November 2, 2005 6:30 pm To: unicode@unicode.org harald@alvestrand.no Cc: ltru@ietf.org "TC46-L Information and Documentation Technology List" -------------------------------------------------------------------------= - Scr=EDobh Jon Hanna: > > There is no need to encode Great Britain in ISO 3166. It is not a sovereign state separate from the United Kingdom... Yes, I guess we all have to agree with you on the above point. > The United Kingdom has already been encoded there (as GB). Great Britai= n has not. A cursory glance at ISO 3166 confirms this... Exactly - only a cursory glance! Only look beyond that and see how reality requires 'UK' be included in IS= O 3166 to accommodate the actual fact (reality) that the e-mail territorial address identifier for the entire territory (Great Britain _and_ Northern Ireland) is actually .UK (as in www.bbc.co.uk, smo.uhi.ac,uk, www.qub.ac.uk, www.cadw.wales.gov.uk, etc., etc.). Only logical. Again, the request is not to change 'GB', but only to add 'UK' as the identifier already in use for e-mail and websites. In passing, I do not pretend either to understand or agree with what Harald says (below), but suppose one must take it into account. mg Scr=EDobh Harald Tveit Alvestrand: > ... > "United Kingdom" is a stupid name for a > country, but the British seem to be attached to it - allocating the .uk domain to the British academics in the early 80s was a mistake by Jon Postel, but the inconsistency is not terribly harmful. > > "GB" is the first letter in the third and fourth word of the formal nam= e of the country (fourth and fifth if you count "of"). It's the ISO 3166 agency's choice, and theirs to change if they ever want to. > > I hope they don't. Too much work with no benefit. > Harald --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * Best regards John Clews -- John Clews, Keytempo Limited (Information Management), 8 Avenue Rd, Harrogate, HG2 7PG Tel: 01423 888 432 mobile: 07766 711 395 Email: scripts20@uk2.net _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 03 21:09:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXr1Q-0000iE-56; Thu, 03 Nov 2005 21:09:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXr1N-0000i9-IZ for ltru@megatron.ietf.org; Thu, 03 Nov 2005 21:09:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13718 for ; Thu, 3 Nov 2005 21:09:14 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXrGH-0004bZ-Su for ltru@ietf.org; Thu, 03 Nov 2005 21:25:02 -0500 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EXr1C-00085N-P2; Thu, 03 Nov 2005 18:09:28 -0800 Message-Id: <6.2.3.4.2.20051104013116.03bb0820@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 04 Nov 2005 03:09:14 +0100 To: "John Clews" , "Marion Gunn" From: r&d afrac Subject: Re: UK/GB - United Kingdom [Re: [Ltru] Re: Åland] In-Reply-To: <40690.62.252.224.13.1131015348.squirrel@maxproxy9.uk2net.c om> References: <4368EC21.4193FEF9@egt.ie> <4368F186.3040907@hackcraft.net> <4368F2BB.EC12A7D0@egt.ie> <4368F9C3.2010204@hackcraft.net> <436905C3.93855506@egt.ie> <40690.62.252.224.13.1131015348.squirrel@maxproxy9.uk2net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA13718 Cc: ltru@ietf.org, TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 11:55 03/11/2005, John Clews wrote: >8. UK existed in domain names before Jan Postel allocated them, and=20 >I don't think it is fair to Jan to say that this was a mistake. When=20 >the JANET system managed UK academic domain names prior to that,=20 >domain names were something like ... uk.ac.leeds and it was very=20 >easy to do a major global change to ... leeds.ac.uk John, may be of interest I detail the history, as it explains the today=20 situation, the WG-ltru contention and many other architectural disputes. Robert Tr=E9hin (Tymnet - 1st network service bill in 2/72) started=20 with the BPO the British international packet services in 1977. I was=20 still an external consultant (I joined officially Tymnet in May 78=20 and created Intlnet in August) interested in M.E. and in private=20 value-added systems. - all the countries started with a Tymnet gateway, either local=20 (Belgium, Germany, Switzerland, etc.) or in New-York (Israel,=20 South-Africa, etc). For all these independent national systems we=20 used ISO 3166 alpha-3 root names (GER-- ,BEL-- , FRA-- , ITA--, etc.). - France, was in the lead. First to install a full gateway to the=20 Transpac network (one million of users around 1982), it closed the=20 Cyclades network in 1979. Cyclades was the network of Louis Pouzin=20 (we created Eurolinc over the multilingual issue). It permitted Louis=20 to stabilise TCP/IP and to introduce the DoD "catenet" architecture=20 ("the network of networks", cf. RFC 1958) Vint Cerf applied. Louis is=20 one of the leaders of the people supporters at the WSIS and authored=20 some parts of the 2003 declarations. - BPO (British Post Office) kept working with Internet people and=20 Larry Roberts/Barry Westler Telenet team (the packet concept was=20 invented by a British). So, they issue an independent RFP (end 1977)=20 for an International Packet Switch System (X.25 which had not yet=20 specified separately from X.75). In the meanwhile they _leased_ ports=20 to the Tymshare UK, on the Tymnet corporate's network. So their root=20 name was Tymshare UK Ltd.'s "UK" root name. Peter Jones was the=20 Director there who organised it. We confirmed this in 1984 when interconnecting the ARPANET Internet.=20 We agreed on the dotted format for the international connection of=20 the DNS. Our names were rootname/hostname (and application-name since=20 1978). We reversed name at the Gateway on the "dot-root" (final dot -=20 to avoid confusion with IP addresses). Our obsoleting "UKLEEDSAC"=20 being transformed into "ac.leeds.uk" and vice versa (after the whole=20 internet became "name.arpa", and then diversified in several TLDs in 1984= ). ISO 3166 alpha-2 is the Telex code. We used it to identified the=20 "pirate" traffic: the Telex refilers, mostly active between UK=20 (by then operating X.25) and the USA, refiling Telex traffic under=20 low cost packet services. The Internet communities were doing the=20 same (refiling TCP/IP traffic under Tymnet or X.75 protocols). So we=20 used the same root names (the DNS degraded into "TLD", what initiated=20 the debate of the "alt/open roots). Jon Postel's RFC 920 stabilised=20 our consensus. Unfortunately I made the _big_ mistake not to impose the X.121=20 numbering plan in the agreement (I was finishing to port all the=20 international network under X.121 addresses): we considered Internet=20 as a local private network (like Euronet, IBM or GTE) and the DoD had=20 committed to X.121 support (they published RFC 1236 ... 7 years=20 later on). Otherwise we would be IPv6 for a very long (32 hexa=20 addresses have been voted by the ITU-T [CCITT] in 1984/85). This is because I know first hand the impact of this kind of mistakes=20 and their very long hysteresis, I do not want us not to repeat it=20 with limited rigid langtags. The hysteresis of the "UK" issue is=20 already 28 years, and still not addressed. The hysteresis of the=20 "en-commerce" tag will probably be also more than 2 generations and=20 hence affect more than 10 or 20 billions people before they can=20 painstakingly restore their own culture. The confusion over "GB"/"UK" - for all this time, and still for a=20 while - is the same as for langtags, and many other architectural=20 issues, between: - those who want to rule "the network"as per the(ir) rule and their=20 (commercial) concept (CLDR) (see RFC 3935 definition of the Internet,=20 very similar to the US Communications Code definition) - it should be=20 "GB" because it is the ISO tables (computer is the master) - and those who want to support the _people_ (whatever fun they have)=20 through a network technology (see the usual IETF definition of the=20 Internet as the adherence to the RFCs). It is "UK" because this is=20 the way British people think of it (Brainware - people are the masters). I maintain for a long, and I am disputed the same, the master is the=20 man and the computer the slave, not the opposite. ISO may say "GB",=20 "UK" it will be because people say so. WG-ltru may say the CLDR's=20 ABNF, it will be RFC 4151 because people (and DoD, Govs, SSDOs) will=20 use it. Better to have RFC3066 bis (if it is supposed to be a BCP) to=20 acknowledge it and to organise CLDR relations, through filtering. Or=20 CLDR will meet difficulties. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 04 00:43:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuMH-0001Of-Bd; Fri, 04 Nov 2005 00:43:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtwB-0003ZI-Be for ltru@megatron.ietf.org; Fri, 04 Nov 2005 00:16:27 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22698 for ; Fri, 4 Nov 2005 00:16:04 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051104051246.XYYG19306.mta11.adelphia.net@DGBP7M81> for ; Fri, 4 Nov 2005 00:12:46 -0500 Message-ID: <001901c5e0fe$654801a0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20051103150931.YQEP14498.edge5.adelphia.net@megatron.ietf.org> Date: Thu, 3 Nov 2005 21:12:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Nov 2005 00:43:23 -0500 Subject: [Ltru] Re: ISO 3166-2 vote (was: Re: ?land ) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > F1 ISO 3166-2 is currently under review; What on earth does this have to do with ISO 3166-2? That part of the standard deals with codes for SUBDIVISIONS of countries. This whole GB vs. UK thing is out of scope for ISO 3166-2. > F2 UK is Northern Ireland's e-mail/webtag; The use of .uk instead of .gb as a country-code top-level domain (which I assume is what "e-mail/webtag" is supposed to mean) was a notable error. All other countries that have an ISO 3166-1 code element use it as their ccTLD. (.com and .org and such are "generic" top-level domains, or gTLDs.) > F3 UK is not currently listed in ISO 3166. It is listed as "exceptionally reserved" by the United Kingdom, to prevent its assignment to any other country. See http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html#UK. > Q1 Woul you like to support its inclusion? Well, let's see. I think code changes in ISO 3166-1 should be avoided whenever possible, because of stability requirements. So I don't support having UK replace GB. And I think each entity should be represented by one and only one code whenever possible, to avoid confusion. So I don't support having both UK and GB to represent the same country, or defining UK to mean the entire United Kingdom while redefining GB to mean only the larger island. So I guess my answer would be, No, I would not. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 04 10:23:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3PN-0008MU-47; Fri, 04 Nov 2005 10:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3PL-0008LF-OR for ltru@megatron.ietf.org; Fri, 04 Nov 2005 10:23:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25473 for ; Fri, 4 Nov 2005 10:22:47 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3eJ-0001Qp-TL for ltru@ietf.org; Fri, 04 Nov 2005 10:38:43 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EY3PB-0007DU-Nm; Fri, 04 Nov 2005 07:23:02 -0800 Message-Id: <6.2.3.4.2.20051104153405.03d80eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 04 Nov 2005 15:48:31 +0100 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-Reply-To: <001901c5e0fe$654801a0$050aa8c0@DGBP7M81> References: <20051103150931.YQEP14498.edge5.adelphia.net@megatron.ietf.org> <001901c5e0fe$654801a0$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 06:12 04/11/2005, Doug Ewell wrote: >The use of .uk instead of .gb as a country-code top-level domain >(which I assume is what "e-mail/webtag" is supposed to mean) was a >notable error. All other countries that have an ISO 3166-1 code >element use it as their ccTLD. (.com and .org and such are >"generic" top-level domains, or gTLDs.) I documented why/how we made that "error". And that I do not want to repeat it with RFC 3066 bis. BTW may I ask you how you catalog ".cat". I note that the consensus of the WG-ltru has been NOT to consider the DNS as concerned by the langtags. >I think code changes in ISO 3166-1 should be avoided whenever >possible, because of stability requirements. So I don't support >having UK replace GB. And I think each entity should be represented >by one and only one code whenever possible, to avoid confusion. So >I don't support having both UK and GB to represent the same country, >or defining UK to mean the entire United Kingdom while redefining GB >to mean only the larger island. > >So I guess my answer would be, No, I would not. May I ask in which capacity you are commenting decisions by the British sovereign Government? This is is the WG-ltru, so I suppose your mail is relevant and is an illustration of the world you want us to live in under RFC 3066 bis under constraints, managed by an unprecise group of experts. Question: is the "only the larger island" meant to exclude the Isles of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. and the claim they may still have on Corsica? jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 06 00:16:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYcn4-00081b-7T; Sun, 06 Nov 2005 00:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYHzE-0001c5-Vj for ltru@megatron.ietf.org; Sat, 05 Nov 2005 01:57:13 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14290 for ; Sat, 5 Nov 2005 01:56:42 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051105065632.WONO23334.mta13.adelphia.net@DGBP7M81> for ; Sat, 5 Nov 2005 01:56:32 -0500 Message-ID: <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20051104171042.OOCV31446.edge4.adelphia.net@megatron.ietf.org> Date: Fri, 4 Nov 2005 22:56:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 06 Nov 2005 00:10:01 -0500 Subject: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I am only responding to this because it was directed at me. r&d afrac wrote: > At 06:12 04/11/2005, Doug Ewell wrote: >> The use of .uk instead of .gb as a country-code top-level domain >> (which I assume is what "e-mail/webtag" is supposed to mean) was a >> notable error. All other countries that have an ISO 3166-1 code >> element use it as their ccTLD. (.com and .org and such are >> "generic" top-level domains, or gTLDs.) > > I documented why/how we made that "error". And that I do not want to > repeat it with RFC 3066 bis. Your post and mine crossed in the mail. I don't wish to belabor this. ISO 3166 does not exist to mirror ccTLDs. > BTW may I ask you how you catalog ".cat". I note that the consensus > of the WG-ltru has been NOT to consider the DNS as concerned by the > langtags. What is ".cat" and how would one be expected to catalog it? Does it have something to do with identifying languages? The consensus of the WG has been that ccTLDs are one use of ISO 3166-1 alpha-2 code elements, and language tags are another, and that is the only relationship between the two. > May I ask in which capacity you are commenting decisions by the > British sovereign Government? This is is the WG-ltru, so I suppose > your mail is relevant and is an illustration of the world you want us > to live in under RFC 3066 bis under constraints, managed by an > unprecise group of experts. Marion made a set of statements about UK and GB, and an unrelated statement about ISO 3166-2, and asked whether we supported a particular change to ISO 3166-1. I replied that I did not, and gave my reasons. That is the capacity in which I make my comments, as an individual with a right to free speech. In any case, I don't see what this has to do with the British government, since if they had wanted UK badly enough I am sure they would have made this desire abundantly known to ISO 3166/MA. Your accusation that I wish to remake the world in some nefarious way and force everyone else to live by my rules is as far out of line as ever. We are talking about a coding system for identifying the language of computerized content. Stop treating it like it's a declaration of war. > Question: is the "only the larger island" meant to exclude the Isles > of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. > and the claim they may still have on Corsica? Don't ask me. I'm not the one who keeps insisting that GB stands for something other than the entire United Kingdom. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 06 00:16:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYcn4-00081l-CZ; Sun, 06 Nov 2005 00:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYW2v-00025H-QD for ltru@megatron.ietf.org; Sat, 05 Nov 2005 16:57:57 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22506 for ; Sat, 5 Nov 2005 16:57:33 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051105215726.FHMD16334.mta10.adelphia.net@DGBP7M81> for ; Sat, 5 Nov 2005 16:57:26 -0500 Message-ID: <007801c5e253$e6b016f0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 5 Nov 2005 13:57:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA22506 X-Mailman-Approved-At: Sun, 06 Nov 2005 00:10:01 -0500 Subject: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org H=C3=A5vard Hjulstad wrote on ietf-languages: > The ISO 639 Registration Authorities' Joint Advisory Committee (JAC) > has approved the following: > > Alpha-3 identifier in ISO 639-2: gsw > > (No alpha-2 identifier has been assigned) > > English name: Swiss German; Alemanic > > French name: al=C3=A9manique > > Indigenous name: Schwyzerd=C3=BCtsch This implies that the following primary language subtag will need to be=20 added to the initial registry: Type: language Subtag: gsw Description: Swiss German Description: Alemanic Added: 2005-11-04 I am working with the co-chairs to determine the best way to add this to=20 draft-ietf-ltru-initial-06. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 06 12:01:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYntz-0005J3-Qj; Sun, 06 Nov 2005 12:01:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnty-0005Iv-5y for ltru@megatron.ietf.org; Sun, 06 Nov 2005 12:01:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08086 for ; Sun, 6 Nov 2005 12:01:29 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYo9P-0007N1-Ei for ltru@ietf.org; Sun, 06 Nov 2005 12:17:51 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EYnte-0005yY-Le; Sun, 06 Nov 2005 09:01:45 -0800 Message-Id: <6.2.3.4.2.20051106104527.03fb5b80@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 06 Nov 2005 16:39:33 +0100 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-Reply-To: <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81> References: <20051104171042.OOCV31446.edge4.adelphia.net@megatron.ietf.org> <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 07:56 05/11/2005, Doug Ewell wrote: >I am only responding to this because it was directed at me. Bravo. It seems you grasp the true spirit of a WG. >r&d afrac wrote: >>I documented why/how we made that "error". And that I do not want to >>repeat it with RFC 3066 bis. > >Your post and mine crossed in the mail. I don't wish to belabor >this. ISO 3166 does not exist to mirror ccTLDs. ISO 3166 does not exist to document languages. >>BTW may I ask you how you catalog ".cat". I note that the consensus >>of the WG-ltru has been NOT to consider the DNS as concerned by the >>langtags. > >What is ".cat" and how would one be expected to catalog it? Does it >have something to do with identifying languages? > >The consensus of the WG has been that ccTLDs are one use of ISO >3166-1 alpha-2 code elements, and language tags are another, and >that is the only relationship between the two. I do not want to harp on this answer by the author of the proposed IANA language registry. I know you are a Unicode, W3C, ISO expert. But this is the IETF. This triggers the RFC 3935 principle of competence. This is a serious cause for appeal of your proposed registry. Since the current WG-ltru debate is over filtering, it shows that important Internet (cf. RFC 3935 definition) aspects are not considered. >>Question: is the "only the larger island" meant to exclude the Isles >>of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. >>and the claim they may still have on Corsica? > >Don't ask me. I'm not the one who keeps insisting that GB stands >for something other than the entire United Kingdom. This also trigger the RFC 3935 principle of competence and of responsibility for your registry proposition. - you published a Draft registry where you releate territories and languages. - you comment one entry (GB) seeming to exclude the reference to a larger territory than many other territories in the registry - when asked about it you answer "Don't ask me". Who else should I ask? We cannot expect from you as an author to be an expert in every international issue at hand. But we can expect you have a methodology to address them. > > This is is the WG-ltru, so I suppose > > your mail is relevant and is an illustration of the world you want us > > to live in under RFC 3066 bis under constraints, managed by an > >unprecise group of experts. >Your accusation that I wish to remake the world in some nefarious >way and force everyone else to live by my rules is as far out of >line as ever. We are talking about a coding system for identifying >the language of computerized content. Stop treating it like it's a >declaration of war. Again, you totally invent a position of mine you can oppose. You are the author of RFC 3066 bis comburent document, I suppose you want to see applied and used? Authors of the RFC 3066 bis have documented enough they add constraints to RFC 3066 to ensure its better use. This use depends on experts you currently embodies as the registry authors the point above permits me to qualify as unprecise. I do not think RFC 3066 bis is nefarious (your term) but uncomplete. Imposing a proprietary naming system to language products, solutions etc. It will also lead to unprecise and contradictory filtering. The question is simple: who is most authoritative over what people do. The experts who feed their computers or the people themselves? This is like parents for their kids. At the begining the experts are. Then technology and the people's expertise develops and becomes more pertinent. There is a need for a transition. Transitions are costly and mean (power, control, market, recognition, etc.) domain losses. So, some experts want to stay in the lead instead of transfering. They progressively lose (RFC 3935) competence and responsibility capacity. This is why I think it is upto responsible engineers to organise the new technical context for experts to assist people, instead of shepherding them. These reluctant experts may be unaware or nostalgic, I do not judge them. They may confuse some merchants for a while (commercial interest is _never_ to oppose the market). But they are on the wrong track, and the work they do (which unfortunately might be precious) might be lost. We saw that all the time, in all the technologies. "the customer/user is king" is not a commercial trick, but a long time experience. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 06 15:50:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrTR-00088k-TF; Sun, 06 Nov 2005 15:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrTQ-00088a-HD for ltru@megatron.ietf.org; Sun, 06 Nov 2005 15:50:44 -0500 Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19335 for ; Sun, 6 Nov 2005 15:50:19 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051105220228.NVLT19306.mta11.adelphia.net@DGBP7M81> for ; Sat, 5 Nov 2005 17:02:28 -0500 Message-ID: <007c01c5e254$9bf5e1c0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 5 Nov 2005 14:02:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org What additional work needs to be done on the matching draft before it is ready for WG Last Call? Are there any outstanding questions on it? I haven't seen any traffic on this list related to the matching draft for about three weeks, and that was just a matter of ABNF reformatting. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 06 22:33:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxkx-0004Ru-5G; Sun, 06 Nov 2005 22:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxkv-0004Pk-3t for ltru@megatron.ietf.org; Sun, 06 Nov 2005 22:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08984 for ; Sun, 6 Nov 2005 22:32:47 -0500 (EST) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYy0O-0005Mv-JL for ltru@ietf.org; Sun, 06 Nov 2005 22:49:15 -0500 Received: from h-68-165-6-26.snvacaid.dynamic.covad.net ([68.165.6.26] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EYxki-0001U8-00 for ltru@ietf.org; Sun, 06 Nov 2005 22:33:00 -0500 Message-ID: <002a01c5e34c$882876a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20051104171042.OOCV31446.edge4.adelphia.net@megatron.ietf.org><004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81> <6.2.3.4.2.20051106104527.03fb5b80@mail.afrac.org> Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) Date: Sun, 6 Nov 2005 19:37:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - This thread is not contibuting to forward progress. If you feel the need to post to the ltru mailing list, please focus on addressing specific comments on our sole remaining deliverable: the matching draft. I suspect that Martin will soon issue the WG last call, so it's time to carefully review the draft. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 04:40:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3UL-0005Oc-M9; Mon, 07 Nov 2005 04:40:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3UJ-0005O4-Bv for ltru@megatron.ietf.org; Mon, 07 Nov 2005 04:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28869 for ; Mon, 7 Nov 2005 04:40:02 -0500 (EST) Received: from mail02.svc.cra.dublin.eircom.net ([159.134.118.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ3js-0006ZI-4X for ltru@ietf.org; Mon, 07 Nov 2005 04:56:33 -0500 Received: (qmail 78777 messnum 5246655 invoked from network[159.134.169.61/159-134-169-61.as1.prp.dublin.eircom.net]); 7 Nov 2005 09:40:11 -0000 Received: from 159-134-169-61.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.61) by mail02.svc.cra.dublin.eircom.net (qp 78777) with SMTP; 7 Nov 2005 09:40:11 -0000 Message-ID: <436F2107.B9B36481@egt.ie> Date: Mon, 07 Nov 2005 09:40:23 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: tc46-l@listserv.heanet.ie, ltru@ietf.org, unicode@unicode.org, ietf-languages@alvestrand.no Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA28869 Cc: Subject: [Ltru] ISO 3166-2 and GA-UK X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scr=EDobh r&d afrac: > ... > The confusion over "GB"/"UK" - for all this time, and still for a > while - is the same as for langtags... Exactly!=20 That is why the need that LTRU and IETF members support GA-UK. Irish language communities have every right to be angry with langtag controllers refusing us the same basic rights happily accorded to Saami communities (who are similarly spread over various dot FI, dot NO, dot RU and dot SE email/webtags).=20 This should be easy - all it requires is goodwill across ISO members generally towards NSAI's and BSI's communities of Irish speakers.=20 Right now (November 2005) langtag controllers oppose this, offering as their excuse that GA-UK would require ISO 3166-2 to be updtated, but, by the same logic, (with ISO 3166-2 currently being updated right now), they can support that right now, if they want to. =20 It is that simple. In the above, I would especially welcome Harald's supp= ort. To recap (for non-Europeans), "UK of GB & NI" means exactly that and nothing more is required than to facilitate (via ISO 3166-2) assigning GA-UK to serve Irish speakers north of the border in my country, matching GA-IE south of it. I thank you for your attention in this matter.=20 mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 06:25:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ57m-0005sm-Vh; Mon, 07 Nov 2005 06:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ57l-0005sh-46 for ltru@megatron.ietf.org; Mon, 07 Nov 2005 06:25:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03457 for ; Mon, 7 Nov 2005 06:24:51 -0500 (EST) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ5NL-0000Z7-0y for ltru@ietf.org; Mon, 07 Nov 2005 06:41:24 -0500 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id jA7BP43h025428; Mon, 7 Nov 2005 13:25:04 +0200 (EET) Message-ID: <436F3990.6020704@kotus.fi> Date: Mon, 07 Nov 2005 13:25:04 +0200 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] ISO 3166-2 and GA-UK References: <436F2107.B9B36481@egt.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by suomi.kotus.fi id jA7BP43h025428 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org, tc46-l@listserv.heanet.ie, ietf-languages@alvestrand.no, unicode@unicode.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Marion, You are only adding to the confusion with your example. You call FI, NO,=20 SE and RU "email/webtags", which role they also have, admittedly. Since,=20 however, they are the actual ISO 3166 country codes, the speakers of the=20 S=E1mi communities get no special treatment in this context. Sincerely, Erkki Marion Gunn wrote: > Scr=EDobh r&d afrac: >=20 >>... >>The confusion over "GB"/"UK" - for all this time, and still for a >>while - is the same as for langtags... >> >=20 > Exactly!=20 >=20 > That is why the need that LTRU and IETF members support GA-UK. >=20 > Irish language communities have every right to be angry with langtag > controllers refusing us the same basic rights happily accorded to Saami > communities (who are similarly spread over various dot FI, dot NO, dot > RU and dot SE email/webtags).=20 >=20 > This should be easy - all it requires is goodwill across ISO members > generally towards NSAI's and BSI's communities of Irish speakers.=20 >=20 > Right now (November 2005) langtag controllers oppose this, offering as > their excuse that GA-UK would require ISO 3166-2 to be updtated, but, b= y > the same logic, (with ISO 3166-2 currently being updated right now), > they can support that right now, if they want to. =20 >=20 > It is that simple. In the above, I would especially welcome Harald's su= pport. >=20 > To recap (for non-Europeans), "UK of GB & NI" means exactly that and > nothing more is required than to facilitate (via ISO 3166-2) assigning > GA-UK to serve Irish speakers north of the border in my country, > matching GA-IE south of it. >=20 > I thank you for your attention in this matter.=20 > mg >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 07:51:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6TA-0003Nm-0V; Mon, 07 Nov 2005 07:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6T8-0003NP-Kn for ltru@megatron.ietf.org; Mon, 07 Nov 2005 07:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07364 for ; Mon, 7 Nov 2005 07:51:00 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ6ij-0002cp-GR for ltru@ietf.org; Mon, 07 Nov 2005 08:07:34 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZ6T1-000466-TA; Mon, 07 Nov 2005 04:51:20 -0800 Message-Id: <6.2.3.4.2.20051107130415.04c68370@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 07 Nov 2005 13:31:57 +0100 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-Reply-To: <002a01c5e34c$882876a0$7f1afea9@oemcomputer> References: <20051104171042.OOCV31446.edge4.adelphia.net@megatron.ietf.org> <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81> <6.2.3.4.2.20051106104527.03fb5b80@mail.afrac.org> <002a01c5e34c$882876a0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Randy, I am afraid you miss the issue. Filtering is to permit to get a reading compromise between readers having different preferences. Therefore to clarify difficult situations. The UK/GB is a typical real life case of difficult situation. For religious reasons the ietf-languages@alvestrand.no mailing list refuses to accept UK as an alias for GB (this would be no problem in my proposed approach). For many reasons many programs, routines, etc. will use "uk". This creates a typical problem the proposed Draft does not address. In addition, we discovered that the author of the proposed registry is not able to tell if the Isles of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. and Northern-Ireland are or not documented at all (what would lead GB to be understood as the "larger island", and UK for what rules the Brisith Governement). The interest of the GB/UK case is that it precisely rises two typical examples (two codes for a same name, different coverages for a same name) which create real problem to filtering. For example, filtering wise, one can assume that GA-UK is closer to GA-IE (as only separated by a few meters over the boarder) than to GA-GB which might be some Cork family living in London. All this rises again the question: who is to decide what is good for the users: the ietf-languages@alvestrand.no CLDR experts or the users themselves. ditto for filtering. This is the core of the Draft. And this has not been discussed. jfc At 04:37 07/11/2005, Randy Presuhn wrote: >Hi - > >This thread is not contibuting to forward progress. > >If you feel the need to post to the ltru mailing list, >please focus on addressing specific comments >on our sole remaining deliverable: the matching draft. >I suspect that Martin will soon issue the WG last call, >so it's time to carefully review the draft. > >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 Mon Nov 07 08:23:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6xj-0000sM-16; Mon, 07 Nov 2005 08:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6xh-0000sH-TO for ltru@megatron.ietf.org; Mon, 07 Nov 2005 08:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09141 for ; Mon, 7 Nov 2005 08:22:35 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ7DK-0003Qr-2S for ltru@ietf.org; Mon, 07 Nov 2005 08:39:10 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZ6xe-00043R-6w; Mon, 07 Nov 2005 05:22:58 -0800 Message-Id: <6.2.3.4.2.20051107133407.04c6f190@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 07 Nov 2005 13:46:21 +0100 To: Marion Gunn , tc46-l@listserv.heanet.ie, ltru@ietf.org, unicode@unicode.org, ietf-languages@alvestrand.no From: r&d afrac Subject: Re: [Ltru] ISO 3166-2 and GA-UK In-Reply-To: <436F2107.B9B36481@egt.ie> References: <436F2107.B9B36481@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA09141 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 10:40 07/11/2005, Marion Gunn wrote: >Scr=EDobh r&d afrac: > > ... > > The confusion over "GB"/"UK" - for all this time, and still for a > > while - is the same as for langtags... > >Exactly! > >That is why the need that LTRU and IETF members support GA-UK. I testified that datacommunications since their inception used UK and=20 why. There is absolutely no reason not to include it in Doug's Draft.=20 All the more than Doug has described GB as the "larger island" what=20 roughly match the legal definition (but the Isles I quoted) and=20 exludes Northern-Ireland which is included in the UK legal=20 definition. This only calls for Doug to enter "UK" in his table, as I=20 did in mine. >Irish language communities have every right to be angry with langtag >controllers refusing us the same basic rights happily accorded to Saami >communities (who are similarly spread over various dot FI, dot NO, dot >RU and dot SE email/webtags). > >This should be easy - all it requires is goodwill across ISO members >generally towards NSAI's and BSI's communities of Irish speakers. > >Right now (November 2005) langtag controllers oppose this, offering as >their excuse that GA-UK would require ISO 3166-2 to be updtated, but, by >the same logic, (with ISO 3166-2 currently being updated right now), >they can support that right now, if they want to. This is the Internet, not ISO. The purpose of the RFC 3066 bis is=20 flexibility in front of situation the network meet and ISO did not indent= ify. >It is that simple. In the above, I would especially welcome Harald's sup= port. > >To recap (for non-Europeans), "UK of GB & NI" means exactly that and >nothing more is required than to facilitate (via ISO 3166-2) assigning >GA-UK to serve Irish speakers north of the border in my country, >matching GA-IE south of it. I would suggest you another solution. NI is deprived from a RFC 3066 bis territory. As a part of=20 Anglo/Irish agreements, why not to propose an "all Irish" TLD in=20 forming a consortium for ".gle" and asking ICANN to enter it into the=20 root. This is exactly what Catalans did and obtained for the Catalan lang= uage. Soon everyone will understand that a language is not defined in=20 reference to a computer by "experts", but to who speak it. So what=20 counts is the spaces of exchanges an architext is meant to (an=20 architext can be multilingual). A language TLD is obviously such a space. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 09:57:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8Qz-0002Y2-LA; Mon, 07 Nov 2005 09:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8Qw-0002XZ-QD for ltru@megatron.ietf.org; Mon, 07 Nov 2005 09:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14467 for ; Mon, 7 Nov 2005 09:56:51 -0500 (EST) Received: from mail.arena1.com ([63.116.216.137] helo=communicraft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8gY-00062J-Hl for ltru@ietf.org; Mon, 07 Nov 2005 10:13:27 -0500 Received: from [192.168.100.14] [63.116.216.137] by communicraft.com with ESMTP (SMTPD32-8.05) id AB311EC10154; Mon, 07 Nov 2005 09:56:49 -0500 Message-ID: <436F6C81.7030402@hackcraft.net> Date: Mon, 07 Nov 2005 15:02:25 +0000 From: Jon Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: r&d afrac Subject: Re: [Ltru] ISO 3166-2 and GA-UK References: <436F2107.B9B36481@egt.ie> <6.2.3.4.2.20051107133407.04c6f190@mail.afrac.org> In-Reply-To: <6.2.3.4.2.20051107133407.04c6f190@mail.afrac.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: jon@hackcraft.net [63.116.216.137] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org, tc46-l@listserv.heanet.ie, ietf-languages@alvestrand.no, unicode@unicode.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > NI is deprived from a RFC 3066 bis territory. As a part of Anglo/Irish > agreements, why not to propose an "all Irish" TLD in forming a > consortium for ".gle" and asking ICANN to enter it into the root. NI is Nicaragua. There already is an all-Irish TLD, which is not that amazing since ccTLDs and sovereign states are not one and the same. Border disputes tend not to be quite as exciting for one thing, .tp not withstanding. That this thread has managed to reach such new depths is amazing though. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 13:21:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBcV-00062H-Ny; Mon, 07 Nov 2005 13:21:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBcU-000628-JB for ltru@megatron.ietf.org; Mon, 07 Nov 2005 13:21:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27028 for ; Mon, 7 Nov 2005 13:21:00 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZBs7-0003am-KM for ltru@ietf.org; Mon, 07 Nov 2005 13:37:37 -0500 Received: from stewie.corp.google.com (stewie.corp.google.com [172.24.0.49]) by smtp-out.google.com with ESMTP id jA7IL8OU013368; Mon, 7 Nov 2005 10:21:08 -0800 Received: from [172.24.89.156] (evdp.corp.google.com [172.24.89.156]) by stewie.corp.google.com with ESMTP id jA7IKt0R021563; Mon, 7 Nov 2005 10:20:55 -0800 Message-ID: <436F9B07.70709@google.com> Date: Mon, 07 Nov 2005 10:20:55 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic References: <007801c5e253$e6b016f0$050aa8c0@DGBP7M81> In-Reply-To: <007801c5e253$e6b016f0$050aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-out.google.com id jA7IL8OU013368 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm wondering whether it might be better to delay the addition of "gsw"=20 until after the 2 IDs currently at the IESG stage get published as RFCs.=20 It just seems like "gsw" has a number of issues hanging off of it, and=20 that any "rushed" addition might miss something or cause an error. I may=20 be overreacting -- if so, please let me know, I'm new here. Now for the issues themselves. There are already a couple of "redundant"=20 tags for Swiss German: de-CH-1901 and de-CH-1996. However, if we add=20 "gsw" and it becomes the preferred subtag for Swiss German, then those=20 de-CH tags are no longer "redundant" in the normal sense of that word.=20 Should we then add a Preferred-Value (or a See-Also) to those=20 "redundant" entries? Rules 8 and 10 in Section 3.4 of the registry ID=20 appear to talk specifically about language subtags, but I didn't=20 immediately notice any discussion of language-COUNTRY combos like de-CH.=20 I'm probably missing something -- let me know. If it is true that Switzerland's orthography years were the same as=20 Germany's (1901 and 1996), then should the entry for the "variant" with=20 the subtag "1901" also have the prefix "gsw" (and likewise for 1996)? If German has a Suppress-Script of Latn, shouldn't "gsw" also have that? On the other hand, if this "gsw" case raises a number of issues in the=20 IDs, we may want to delay them to fix them (for new rules that would=20 cover this sort of case). Not that I want to be the person blamed for=20 the delay of these RFCs! Erik Doug Ewell wrote: > H=C3=A5vard Hjulstad wrote on ietf-languages: >=20 >> The ISO 639 Registration Authorities' Joint Advisory Committee (JAC) >> has approved the following: >> >> Alpha-3 identifier in ISO 639-2: gsw >> >> (No alpha-2 identifier has been assigned) >> >> English name: Swiss German; Alemanic >> >> French name: al=C3=A9manique >> >> Indigenous name: Schwyzerd=C3=BCtsch >=20 > This implies that the following primary language subtag will need to be= =20 > added to the initial registry: >=20 > Type: language > Subtag: gsw > Description: Swiss German > Description: Alemanic > Added: 2005-11-04 >=20 > I am working with the co-chairs to determine the best way to add this t= o=20 > draft-ietf-ltru-initial-06. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 14:14:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCSC-00050r-GD; Mon, 07 Nov 2005 14:14:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCSB-0004zP-Ac for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:14:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01428 for ; Mon, 7 Nov 2005 14:14:25 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZChp-0005Ve-GI for ltru@ietf.org; Mon, 07 Nov 2005 14:31:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 621C52596B7; Mon, 7 Nov 2005 20:13:53 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14721-01; Mon, 7 Nov 2005 20:13:49 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59E7A258093; Mon, 7 Nov 2005 20:13:44 +0100 (CET) Date: Mon, 07 Nov 2005 11:10:38 -0800 From: Harald Tveit Alvestrand To: Erik van der Poel , Doug Ewell Subject: Re: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic Message-ID: <15F9F1FCE86EF806CDFB4EAB@B50854F0A9192E8EC6CDA126> In-Reply-To: <436F9B07.70709@google.com> References: <007801c5e253$e6b016f0$050aa8c0@DGBP7M81> <436F9B07.70709@google.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0715773622==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0715773622== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========CB81A61F6072A6989366==========" --==========CB81A61F6072A6989366========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I second the sentiment: I see no harm in letting the "gsw" update wait=20 until it can be registered using the procedures of the draft, instead of=20 being in the initial registry. I don't think we will forget. (note - I think IANA's supposed to switch to the new procedures when the=20 draft is approved + whatever time IANA needs to prepare - it shouldn't have = to wait for the RFC to be published...) Harald --On 7. november 2005 10:20 -0800 Erik van der Poel =20 wrote: > I'm wondering whether it might be better to delay the addition of "gsw" > until after the 2 IDs currently at the IESG stage get published as RFCs. > It just seems like "gsw" has a number of issues hanging off of it, and > that any "rushed" addition might miss something or cause an error. --==========CB81A61F6072A6989366========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDb6auOMj+2+WY0F4RArxhAJ9ukm4Ri1pRM0q3x31+LfIYm2aiWwCglsQd 4WcMjiWVlazoUzs5RIGfYxA= =27In -----END PGP SIGNATURE----- --==========CB81A61F6072A6989366==========-- --===============0715773622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0715773622==-- From ltru-bounces@ietf.org Mon Nov 07 14:23:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCaW-0006eT-F0; Mon, 07 Nov 2005 14:23:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCaU-0006eL-B4 for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:23:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01867 for ; Mon, 7 Nov 2005 14:22:59 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCq8-0005iM-FW for ltru@ietf.org; Mon, 07 Nov 2005 14:39:37 -0500 Received: from uknsprd1 (unverified [129.1.30.40]) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Mon, 7 Nov 2005 19:26:56 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IPL00MJPN6BY0@eupig2.dtc.lon.ime.reuters.com>; Mon, 07 Nov 2005 19:22:59 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Mon, 07 Nov 2005 19:22:59 +0000 Date: Mon, 07 Nov 2005 19:23:28 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: Swiss German;Alemanic To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic Thread-Index: AcXjyCfqgp8YpmsaS2KV8k8w+LIY4gACFqcA Content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Nov 2005 19:22:59.0053 (UTC) FILETIME=[A9BF81D0:01C5E3D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Ouch. Good catch. What will happen to the matching=20 of "de" or "de-CH" against "gsw"? Misha -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Erik van der Poel Sent: 07 November 2005 18:21 To: Doug Ewell Cc: LTRU Working Group Subject: Re: [Ltru] Re: New ISO 639 language identifier approved: Swiss German;Alemanic I'm wondering whether it might be better to delay the addition of "gsw"=20 until after the 2 IDs currently at the IESG stage get published as RFCs. It just seems like "gsw" has a number of issues hanging off of it, and=20 that any "rushed" addition might miss something or cause an error. I may be overreacting -- if so, please let me know, I'm new here. Now for the issues themselves. There are already a couple of "redundant" tags for Swiss German: de-CH-1901 and de-CH-1996. However, if we add=20 "gsw" and it becomes the preferred subtag for Swiss German, then those=20 de-CH tags are no longer "redundant" in the normal sense of that word.=20 Should we then add a Preferred-Value (or a See-Also) to those=20 "redundant" entries? Rules 8 and 10 in Section 3.4 of the registry ID=20 appear to talk specifically about language subtags, but I didn't=20 immediately notice any discussion of language-COUNTRY combos like de-CH. I'm probably missing something -- let me know. If it is true that Switzerland's orthography years were the same as=20 Germany's (1901 and 1996), then should the entry for the "variant" with=20 the subtag "1901" also have the prefix "gsw" (and likewise for 1996)? If German has a Suppress-Script of Latn, shouldn't "gsw" also have that? On the other hand, if this "gsw" case raises a number of issues in the=20 IDs, we may want to delay them to fix them (for new rules that would=20 cover this sort of case). Not that I want to be the person blamed for=20 the delay of these RFCs! Erik To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 14:26:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCdn-0007DG-QJ; Mon, 07 Nov 2005 14:26:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCdl-0007D4-KE for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:26:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02069 for ; Mon, 7 Nov 2005 14:26:20 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCtO-0005o1-FA for ltru@ietf.org; Mon, 07 Nov 2005 14:42:58 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:27:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic Date: Mon, 7 Nov 2005 11:26:28 -0800 Message-ID: Thread-Topic: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic Thread-Index: AcXjyCfqgp8YpmsaS2KV8k8w+LIY4gACFqcAAAAdxIA= From: "Addison Phillips" To: "Misha Wolf" , "LTRU Working Group" X-OriginalArrivalTime: 07 Nov 2005 19:27:14.0251 (UTC) FILETIME=[41DBA1B0:01C5E3D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0012614686==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0012614686== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWNjb3JkaW5nIHRvIHRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0IGRpc2N1c3Npb24sICdnc3cnIGFu ZCAiZGUtQ0giIGFyZSBub3QgdGhlIHNhbWUgbGFuZ3VhZ2UsIGRlc3BpdGUgdGhlaXIgRW5nbGlz aCBuYW1lcy4gQXMgc3VjaCwgImdzdy0qIiBhbmQgImRlLSotQ0gtKiIgZG9uJ3QgbWF0Y2guDQoN CkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3Qs IFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29y a2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQg aXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBNaXNoYSBXb2xmDQo+IFNlbnQ6IDIwMDXlubQxMeaciDfml6UgMTE6 MjMNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBO ZXcgSVNPIDYzOSBsYW5ndWFnZSBpZGVudGlmaWVyIGFwcHJvdmVkOg0KPiBTd2lzc0dlcm1hbjtB bGVtYW5pYw0KPiANCj4gT3VjaC4gIEdvb2QgY2F0Y2guICBXaGF0IHdpbGwgaGFwcGVuIHRvIHRo ZSBtYXRjaGluZw0KPiBvZiAiZGUiIG9yICJkZS1DSCIgYWdhaW5zdCAiZ3N3Ij8NCj4gDQo+IE1p c2hhDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gRXJpayB2YW4gZGVyIFBvZWwNCj4gU2VudDogMDcgTm92ZW1iZXIgMjAwNSAxODoyMQ0K PiBUbzogRG91ZyBFd2VsbA0KPiBDYzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJl OiBbTHRydV0gUmU6IE5ldyBJU08gNjM5IGxhbmd1YWdlIGlkZW50aWZpZXIgYXBwcm92ZWQ6IFN3 aXNzDQo+IEdlcm1hbjtBbGVtYW5pYw0KPiANCj4gSSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0IG1p Z2h0IGJlIGJldHRlciB0byBkZWxheSB0aGUgYWRkaXRpb24gb2YgImdzdyINCj4gdW50aWwgYWZ0 ZXIgdGhlIDIgSURzIGN1cnJlbnRseSBhdCB0aGUgSUVTRyBzdGFnZSBnZXQgcHVibGlzaGVkIGFz IFJGQ3MuDQo+IA0KPiBJdCBqdXN0IHNlZW1zIGxpa2UgImdzdyIgaGFzIGEgbnVtYmVyIG9mIGlz c3VlcyBoYW5naW5nIG9mZiBvZiBpdCwgYW5kDQo+IHRoYXQgYW55ICJydXNoZWQiIGFkZGl0aW9u IG1pZ2h0IG1pc3Mgc29tZXRoaW5nIG9yIGNhdXNlIGFuIGVycm9yLiBJIG1heQ0KPiANCj4gYmUg b3ZlcnJlYWN0aW5nIC0tIGlmIHNvLCBwbGVhc2UgbGV0IG1lIGtub3csIEknbSBuZXcgaGVyZS4N Cj4gDQo+IE5vdyBmb3IgdGhlIGlzc3VlcyB0aGVtc2VsdmVzLiBUaGVyZSBhcmUgYWxyZWFkeSBh IGNvdXBsZSBvZiAicmVkdW5kYW50Ig0KPiANCj4gdGFncyBmb3IgU3dpc3MgR2VybWFuOiBkZS1D SC0xOTAxIGFuZCBkZS1DSC0xOTk2LiBIb3dldmVyLCBpZiB3ZSBhZGQNCj4gImdzdyIgYW5kIGl0 IGJlY29tZXMgdGhlIHByZWZlcnJlZCBzdWJ0YWcgZm9yIFN3aXNzIEdlcm1hbiwgdGhlbiB0aG9z ZQ0KPiBkZS1DSCB0YWdzIGFyZSBubyBsb25nZXIgInJlZHVuZGFudCIgaW4gdGhlIG5vcm1hbCBz ZW5zZSBvZiB0aGF0IHdvcmQuDQo+IFNob3VsZCB3ZSB0aGVuIGFkZCBhIFByZWZlcnJlZC1WYWx1 ZSAob3IgYSBTZWUtQWxzbykgdG8gdGhvc2UNCj4gInJlZHVuZGFudCIgZW50cmllcz8gUnVsZXMg OCBhbmQgMTAgaW4gU2VjdGlvbiAzLjQgb2YgdGhlIHJlZ2lzdHJ5IElEDQo+IGFwcGVhciB0byB0 YWxrIHNwZWNpZmljYWxseSBhYm91dCBsYW5ndWFnZSBzdWJ0YWdzLCBidXQgSSBkaWRuJ3QNCj4g aW1tZWRpYXRlbHkgbm90aWNlIGFueSBkaXNjdXNzaW9uIG9mIGxhbmd1YWdlLUNPVU5UUlkgY29t Ym9zIGxpa2UgZGUtQ0guDQo+IA0KPiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcgLS0g bGV0IG1lIGtub3cuDQo+IA0KPiBJZiBpdCBpcyB0cnVlIHRoYXQgU3dpdHplcmxhbmQncyBvcnRo b2dyYXBoeSB5ZWFycyB3ZXJlIHRoZSBzYW1lIGFzDQo+IEdlcm1hbnkncyAoMTkwMSBhbmQgMTk5 NiksIHRoZW4gc2hvdWxkIHRoZSBlbnRyeSBmb3IgdGhlICJ2YXJpYW50IiB3aXRoDQo+IHRoZSBz dWJ0YWcgIjE5MDEiIGFsc28gaGF2ZSB0aGUgcHJlZml4ICJnc3ciIChhbmQgbGlrZXdpc2UgZm9y IDE5OTYpPw0KPiANCj4gSWYgR2VybWFuIGhhcyBhIFN1cHByZXNzLVNjcmlwdCBvZiBMYXRuLCBz aG91bGRuJ3QgImdzdyIgYWxzbyBoYXZlIHRoYXQ/DQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFuZCwg aWYgdGhpcyAiZ3N3IiBjYXNlIHJhaXNlcyBhIG51bWJlciBvZiBpc3N1ZXMgaW4gdGhlDQo+IElE cywgd2UgbWF5IHdhbnQgdG8gZGVsYXkgdGhlbSB0byBmaXggdGhlbSAoZm9yIG5ldyBydWxlcyB0 aGF0IHdvdWxkDQo+IGNvdmVyIHRoaXMgc29ydCBvZiBjYXNlKS4gTm90IHRoYXQgSSB3YW50IHRv IGJlIHRoZSBwZXJzb24gYmxhbWVkIGZvcg0KPiB0aGUgZGVsYXkgb2YgdGhlc2UgUkZDcyENCj4g DQo+IEVyaWsNCj4gDQo+IA0KPiBUbyBmaW5kIG91dCBtb3JlIGFib3V0IFJldXRlcnMgdmlzaXQg d3d3LmFib3V0LnJldXRlcnMuY29tDQo+IA0KPiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLA0KPiBleGNlcHQgd2hl cmUgdGhlIHNlbmRlciBzcGVjaWZpY2FsbHkgc3RhdGVzIHRoZW0gdG8gYmUgdGhlIHZpZXdzIG9m DQo+IFJldXRlcnMgTHRkLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============0012614686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0012614686==-- From ltru-bounces@ietf.org Mon Nov 07 14:28:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCfc-0008Jc-NZ; Mon, 07 Nov 2005 14:28:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCfc-0008DD-3j for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:28:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02202 for ; Mon, 7 Nov 2005 14:28:14 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCvD-0005rt-0C for ltru@ietf.org; Mon, 07 Nov 2005 14:44:52 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:28:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic Date: Mon, 7 Nov 2005 11:28:28 -0800 Message-ID: Thread-Topic: [Ltru] Re: New ISO 639 language identifier approved: Swiss German; Alemanic Thread-Index: AcXjyCGRYugQrx1kSTi0IKg64hmJCgABtPfQ From: "Addison Phillips" To: "Erik van der Poel" , "Doug Ewell" X-OriginalArrivalTime: 07 Nov 2005 19:28:29.0435 (UTC) FILETIME=[6EABCCB0:01C5E3D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621447217==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1621447217== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgRXJpaywNCg0KRmlyc3QsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQganVzdCBpbnNlcnQgJ2dz dycgdXNpbmcgdGhlIG5vcm1hbCByZWdpc3RyYXRpb24gcHJvY2VzcyByYXRoZXIgdGhhbiBpbnRv IGRyYWZ0LWluaXRpYWwuIFRoZSBkcmFmdC1pbml0aWFsIGJvYXQgaGFzIHNhaWxlZC4gSW5zZXJ0 aW5nICdnc3cnIGludG8gaXQgZHVyaW5nIEFVVEg0OCBpcyBwb2ludGxlc3MsIGJlY2F1c2UgdGhl IFJGQyBFZGl0b3Igd2lsbCBtZXJlbHkgcmVtb3ZlIGl0IGFueXdheS4gV2hhdCdzIGltcG9ydGFu dCBpcyB3aGF0IGdvZXMgaW50byB0aGUgYWN0dWFsIHJlZ2lzdHJ5LiBIYXZpbmcgZXhhY3RseSBv bmUgc3VidGFnIChzbyBmYXIpIHRvIGluc2VydCBpcyBoYXJkbHkgYSBtYWpvciBidXJkZW4uDQoN CiJkZS1DSC0qIiB0YWdzIHdpbGwgYmUgcmVkdW5kYW50IGJlY2F1c2UgYWxsIG9mIHRoZWlyIHN1 YnRhZ3MgYXJlIHJlZ2lzdGVyZWQgaW4gdGhlIHJlZ2lzdHJ5IHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciAnZ3N3JyBpcyBhZGRlZCBvciBub3QuIFJlZHVuZGFuY3kgdnMuIGdyYW5kZmF0aGVyZWQgc3Rh dHVzIGlzIG5vdCBhIGZ1bmN0aW9uIG9mIHdoZXRoZXIgYW55IHBhcnRpY3VsYXIgdGFnIGlzIGEg Z29vZCBjaG9pY2Ugb3Igbm90IGZvciBhIGdpdmVuIHBpZWNlIG9mIGNvbnRlbnQuDQoNCkZ1cnRo ZXJtb3JlLCB0aGUgImRlLUNIIiB0YWcgKGFuZCBpdHMgZnJpZW5kcykgcmVhbGx5IGFyZSBub3Qg aW4gY29sbGlzaW9uIHdpdGggJ2dzdycuIFRoaXMgd2FzIGRpc2N1c3NlZCBvbiB0aGUgaWV0Zi1s YW5ndWFnZXMgbGlzdC4gVGhlIHN1YnRhZyAnZGUnIGlzIGZvciBHZXJtYW4sIHRoYXQgaXMsIGZv ciBzdGFuZGFyZCBHZXJtYW4uIEFsZW1hbmljIGlzIGFjdHVhbGx5IGEgc2VwYXJhdGUgbGFuZ3Vh Z2UsIGFjY29yZGluZyB0byB0aGUgY29ycmVzcG9uZGVudHMgb24gdGhhdCBsaXN0LCBkZXNwaXRl IGl0cyBFbmdsaXNoIG5hbWUuIFRodXMgdGhlIHZhcmlvdXMgImRlLUNIIiB0YWdzIGluIGV4aXN0 ZW5jZSBhcmUgbm90IG5lY2Vzc2FyaWx5IGluIG5lZWQgb2YgcmVwbGFjZW1lbnQuIENvbnRlbnQg YXV0aG9ycywgdWx0aW1hdGVseSwgbXVzdCBkZWNpZGUgaWYgdGhlaXIgY29udGVudCBpcyBHZXJt YW4gd2l0aCBhIFN3aXNzIGFjY2VudCBvciBTY2h3eXplcmRldXRzY2guDQoNCkFzIGZvciB0aGUg U3VwcHJlc3MtU2NyaXB0IHZhbHVlIGZvciAnZ3N3JywgZXRjLjogdGhhdCdzIHdoYXQgdGhlIHJl Z2lzdHJhdGlvbiBwcm9jZXNzIGlzIGZvci4gSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCBzdXBwcmVz cyAnTGF0bicsIGFuZCBkb3VidCB0aGF0IHdlJ2xsIGZpbmQgYW55IGRlbXVycmVycy4NCg0KRmlu YWxseSwgaWYgJ2dzdycgZm9sbG93ZWQgdGhlIHNhbWUgc3BlbGxpbmcgYW5kIG9ydGhvZ3JhcGhp YyByZWZvcm1zIHRoYXQgc3RhbmRhcmQgR2VybWFuIGRpZCwgdGhlbiBzb21lb25lIGNhbiByZWdp c3RlciBhIGNoYW5nZSB0byB0aGUgJzE5MDEnIGFuZCAnMTk5Nicgc3VidGFncyB0byBjb3ZlciB0 aG9zZSBjYXNlcy4gQWxsIG9mIHRoZXNlIHRoaW5ncyBhcmUgZ29vZCB0ZXN0cyBmb3IgdGhlIHJl Z2lzdHJhdGlvbiBwcm9jZXNzLg0KDQpOb3RpY2UgaG93IG11Y2ggY2xlYW5lciB0aGlzIGlzIHRo YW4gUkZDIDMwNjYsIHRob3VnaDogdW5kZXIgUkZDIDMwNjYsIGlmIHdoYXQgeW91J3JlIHNheWlu ZyB3ZXJlIHRvIHByb3ZlIGNvcnJlY3QsIHdlIHdvdWxkIGhhdmUgdG8gZGVwcmVjYXRlIGFueSBu dW1iZXIgb2YgdGFncyAoZWFjaCB3aXRoIGl0cyBvd24gcmVnaXN0cmF0aW9uIHBlcmlvZCkgYW5k IHRoZW4gc2VwYXJhdGVseSByZWdpc3RlciBhIGhhbGYgZG96ZW4gdGFncy4gV2l0aCAzMDY2Ymlz LCB3ZSBtZXJlbHkgaW5zZXJ0ICdnc3cnIGFuZCBhZGQgYSBQcmVmaXggdG8gdGhlIHNwZWxsaW5n IHJlZm9ybSB0YWdzLiAoV2UgbWlnaHQgdHJvdWJsZSBvdXJzZWx2ZXMgdG8gZGVwcmVjYXRlIHRo ZSBvbGQgZGUtQ0gtKiB0YWdzIHRvbywgYWx0aG91Z2ggdGhpcyBpcyB1bm5lY2Vzc2FyeSwgZ2l2 ZW4gdGhhdCB0aGV5IGFyZSBtZXJlbHkgcGxhY2Vob2xkZXJzIGZvciBvbGQgMzA2NiByZWdpc3Ry YXRpb25zKS4NCg0KQmVzdCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxp cHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJ bnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6 YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gRXJpayB2YW4gZGVy IFBvZWwNCj4gU2VudDogMjAwNeW5tDEx5pyIN+aXpSAxMDoyMQ0KPiBUbzogRG91ZyBFd2VsbA0K PiBDYzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gUmU6IE5ldyBJ U08gNjM5IGxhbmd1YWdlIGlkZW50aWZpZXIgYXBwcm92ZWQ6IFN3aXNzDQo+IEdlcm1hbjtBbGVt YW5pYw0KPiANCj4gSSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0IG1pZ2h0IGJlIGJldHRlciB0byBk ZWxheSB0aGUgYWRkaXRpb24gb2YgImdzdyINCj4gdW50aWwgYWZ0ZXIgdGhlIDIgSURzIGN1cnJl bnRseSBhdCB0aGUgSUVTRyBzdGFnZSBnZXQgcHVibGlzaGVkIGFzIFJGQ3MuDQo+IEl0IGp1c3Qg c2VlbXMgbGlrZSAiZ3N3IiBoYXMgYSBudW1iZXIgb2YgaXNzdWVzIGhhbmdpbmcgb2ZmIG9mIGl0 LCBhbmQNCj4gdGhhdCBhbnkgInJ1c2hlZCIgYWRkaXRpb24gbWlnaHQgbWlzcyBzb21ldGhpbmcg b3IgY2F1c2UgYW4gZXJyb3IuIEkgbWF5DQo+IGJlIG92ZXJyZWFjdGluZyAtLSBpZiBzbywgcGxl YXNlIGxldCBtZSBrbm93LCBJJ20gbmV3IGhlcmUuDQo+IA0KPiBOb3cgZm9yIHRoZSBpc3N1ZXMg dGhlbXNlbHZlcy4gVGhlcmUgYXJlIGFscmVhZHkgYSBjb3VwbGUgb2YgInJlZHVuZGFudCINCj4g dGFncyBmb3IgU3dpc3MgR2VybWFuOiBkZS1DSC0xOTAxIGFuZCBkZS1DSC0xOTk2LiBIb3dldmVy LCBpZiB3ZSBhZGQNCj4gImdzdyIgYW5kIGl0IGJlY29tZXMgdGhlIHByZWZlcnJlZCBzdWJ0YWcg Zm9yIFN3aXNzIEdlcm1hbiwgdGhlbiB0aG9zZQ0KPiBkZS1DSCB0YWdzIGFyZSBubyBsb25nZXIg InJlZHVuZGFudCIgaW4gdGhlIG5vcm1hbCBzZW5zZSBvZiB0aGF0IHdvcmQuDQo+IFNob3VsZCB3 ZSB0aGVuIGFkZCBhIFByZWZlcnJlZC1WYWx1ZSAob3IgYSBTZWUtQWxzbykgdG8gdGhvc2UNCj4g InJlZHVuZGFudCIgZW50cmllcz8gUnVsZXMgOCBhbmQgMTAgaW4gU2VjdGlvbiAzLjQgb2YgdGhl IHJlZ2lzdHJ5IElEDQo+IGFwcGVhciB0byB0YWxrIHNwZWNpZmljYWxseSBhYm91dCBsYW5ndWFn ZSBzdWJ0YWdzLCBidXQgSSBkaWRuJ3QNCj4gaW1tZWRpYXRlbHkgbm90aWNlIGFueSBkaXNjdXNz aW9uIG9mIGxhbmd1YWdlLUNPVU5UUlkgY29tYm9zIGxpa2UgZGUtQ0guDQo+IEknbSBwcm9iYWJs eSBtaXNzaW5nIHNvbWV0aGluZyAtLSBsZXQgbWUga25vdy4NCj4gDQo+IElmIGl0IGlzIHRydWUg dGhhdCBTd2l0emVybGFuZCdzIG9ydGhvZ3JhcGh5IHllYXJzIHdlcmUgdGhlIHNhbWUgYXMNCj4g R2VybWFueSdzICgxOTAxIGFuZCAxOTk2KSwgdGhlbiBzaG91bGQgdGhlIGVudHJ5IGZvciB0aGUg InZhcmlhbnQiIHdpdGgNCj4gdGhlIHN1YnRhZyAiMTkwMSIgYWxzbyBoYXZlIHRoZSBwcmVmaXgg ImdzdyIgKGFuZCBsaWtld2lzZSBmb3IgMTk5Nik/DQo+IA0KPiBJZiBHZXJtYW4gaGFzIGEgU3Vw cHJlc3MtU2NyaXB0IG9mIExhdG4sIHNob3VsZG4ndCAiZ3N3IiBhbHNvIGhhdmUgdGhhdD8NCj4g DQo+IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGlzICJnc3ciIGNhc2UgcmFpc2VzIGEgbnVtYmVy IG9mIGlzc3VlcyBpbiB0aGUNCj4gSURzLCB3ZSBtYXkgd2FudCB0byBkZWxheSB0aGVtIHRvIGZp eCB0aGVtIChmb3IgbmV3IHJ1bGVzIHRoYXQgd291bGQNCj4gY292ZXIgdGhpcyBzb3J0IG9mIGNh c2UpLiBOb3QgdGhhdCBJIHdhbnQgdG8gYmUgdGhlIHBlcnNvbiBibGFtZWQgZm9yDQo+IHRoZSBk ZWxheSBvZiB0aGVzZSBSRkNzIQ0KPiANCj4gRXJpaw0KPiANCj4gRG91ZyBFd2VsbCB3cm90ZToN Cj4gPiBIw6V2YXJkIEhqdWxzdGFkIDxISGogYXQgc3RhbmRhcmQgZG90IG5vPiB3cm90ZSBvbiBp ZXRmLWxhbmd1YWdlczoNCj4gPg0KPiA+PiBUaGUgSVNPIDYzOSBSZWdpc3RyYXRpb24gQXV0aG9y aXRpZXMnIEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZSAoSkFDKQ0KPiA+PiBoYXMgYXBwcm92ZWQg dGhlIGZvbGxvd2luZzoNCj4gPj4NCj4gPj4gQWxwaGEtMyBpZGVudGlmaWVyIGluIElTTyA2Mzkt MjogZ3N3DQo+ID4+DQo+ID4+IChObyBhbHBoYS0yIGlkZW50aWZpZXIgaGFzIGJlZW4gYXNzaWdu ZWQpDQo+ID4+DQo+ID4+IEVuZ2xpc2ggbmFtZTogU3dpc3MgR2VybWFuOyBBbGVtYW5pYw0KPiA+ Pg0KPiA+PiBGcmVuY2ggbmFtZTogYWzDqW1hbmlxdWUNCj4gPj4NCj4gPj4gSW5kaWdlbm91cyBu YW1lOiBTY2h3eXplcmTDvHRzY2gNCj4gPg0KPiA+IFRoaXMgaW1wbGllcyB0aGF0IHRoZSBmb2xs b3dpbmcgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgd2lsbCBuZWVkIHRvIGJlDQo+ID4gYWRkZWQg dG8gdGhlIGluaXRpYWwgcmVnaXN0cnk6DQo+ID4NCj4gPiBUeXBlOiBsYW5ndWFnZQ0KPiA+IFN1 YnRhZzogZ3N3DQo+ID4gRGVzY3JpcHRpb246IFN3aXNzIEdlcm1hbg0KPiA+IERlc2NyaXB0aW9u OiBBbGVtYW5pYw0KPiA+IEFkZGVkOiAyMDA1LTExLTA0DQo+ID4NCj4gPiBJIGFtIHdvcmtpbmcg d2l0aCB0aGUgY28tY2hhaXJzIHRvIGRldGVybWluZSB0aGUgYmVzdCB3YXkgdG8gYWRkIHRoaXMg dG8NCj4gPiBkcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC0wNi4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+ IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydQ0K --===============1621447217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1621447217==-- From ltru-bounces@ietf.org Mon Nov 07 14:32:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCjj-0001Ku-4u; Mon, 07 Nov 2005 14:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCjh-0001Kk-Qj for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:32:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02435 for ; Mon, 7 Nov 2005 14:32:31 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCzN-0005zP-27 for ltru@ietf.org; Mon, 07 Nov 2005 14:49:09 -0500 Received: from uknsprd1 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Mon, 7 Nov 2005 19:32:48 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IPL002PGNMDSY@eupig2.dtc.lon.ime.reuters.com>; Mon, 07 Nov 2005 19:32:37 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 07 Nov 2005 19:32:37 +0000 Date: Mon, 07 Nov 2005 19:33:07 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman;Alemanic To: Addison Phillips , LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic Thread-Index: AcXjyCfqgp8YpmsaS2KV8k8w+LIY4gACFqcAAAAdxIAAAD7HoA== Content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Nov 2005 19:32:37.0792 (UTC) FILETIME=[02B41200:01C5E3D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I must have been asleep at the time :-) This will require some fancy user education! Misha -----Original Message----- From: Addison Phillips [mailto:addison.phillips@quest.com]=20 Sent: 07 November 2005 19:26 To: Misha Wolf; LTRU Working Group Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman;Alemanic According to the ietf-languages list discussion, 'gsw' and "de-CH" are not the same language, despite their English names. As such, "gsw-*" and "de-*-CH-*" don't match. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 14:52:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZD2x-00069Z-MM; Mon, 07 Nov 2005 14:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZD2v-00069U-Pu for ltru@megatron.ietf.org; Mon, 07 Nov 2005 14:52:50 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03789 for ; Mon, 7 Nov 2005 14:52:22 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZD1K-0000eo-QC for ltru@lists.ietf.org; Mon, 07 Nov 2005 20:51:10 +0100 Received: from c-134-88-29.hh.dial.de.ignite.net ([62.134.88.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2005 20:51:10 +0100 Received: from nobody by c-134-88-29.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2005 20:51:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 07 Nov 2005 20:47:36 +0100 Organization: Lines: 12 Message-ID: <436FAF58.3BE4@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: c-134-88-29.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > According to the ietf-languages list discussion, 'gsw' and > "de-CH" are not the same language, despite their English > names. As such, "gsw-*" and "de-*-CH-*" don't match. Yes. And we probably don't need 1901/1996 for gsw, nds, etc., the "official spelling" is only relevant for de as written in schools or laws. For related languages without "official spelling" it's irrelevant. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 15:19:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDSR-0004bM-DZ; Mon, 07 Nov 2005 15:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDSQ-0004bE-3S for ltru@megatron.ietf.org; Mon, 07 Nov 2005 15:19:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05134 for ; Mon, 7 Nov 2005 15:18:43 -0500 (EST) From: Karen_Broome@spe.sony.com Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail101-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZDi5-0007Ir-El for ltru@ietf.org; Mon, 07 Nov 2005 15:35:22 -0500 Received: from mail101-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail101-red-R.bigfish.com (Postfix) with ESMTP id BC60D41DC96; Mon, 7 Nov 2005 20:18:51 +0000 (UTC) X-BigFish: VP Received: by mail101-red (MessageSwitch) id 1131394731690001_23219; Mon, 7 Nov 2005 20:18:51 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail101-red.bigfish.com (Postfix) with ESMTP id 9E04B41D79A; Mon, 7 Nov 2005 20:18:51 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005110712284290:36725 ; Mon, 7 Nov 2005 12:28:42 -0800 To: Misha Wolf Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.13 March 9, 2004 Message-ID: Date: Mon, 7 Nov 2005 12:18:39 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 11/07/2005 12:18:40, Serialize complete at 11/07/2005 12:18:40, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/07/2005 12:28:42 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/07/2005 12:28:43 PM, Serialize complete at 11/07/2005 12:28:43 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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="===============0836901823==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0836901823== Content-Type: multipart/alternative; boundary="=_alternative 006F9694882570B2_=" This is a multipart message in MIME format. --=_alternative 006F9694882570B2_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There was discussion on the list that forced my registration of gsw. I=20 previously thought de-CH and de-AT applied to these Swiss and Austrian=20 dialects as well, and I'm sure this is not an uncommon belief. It was=20 made clear that these tags applied to German and Austrian variants of=20 standard German, often combined with the tagging for the spelling reforms, = and did not apply to the primarily spoken dialects I was trying to=20 identify.=20 I guess this case shows both the advantages and potential pitfalls of RFC=20 3066bis and how tagging building blocks defined by RFC 3066bis could be=20 combined in an inaccurate ways by those who are unfamiliar with such=20 subtleties . Perhaps the multiple description feature in the registry will = help resolve some of these ambiguities -- it's not particularly=20 unreasonable to assume that de-CH defines "Swiss German." If this tag is=20 added to the registry, I would also include the description "Schwyzerd=FCts= ch." This is also the name used for this language in 639-3. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Misha Wolf Sent by: ltru-bounces@ietf.org 11/07/2005 11:33 AM =20 To: Addison Phillips , LTRU Working= Group=20 cc:=20 Subject: RE: [Ltru] Re: New ISO 639 language identifier appr= oved:=20 SwissGerman;Alemanic I must have been asleep at the time :-) This will require some fancy user education! Misha -----Original Message----- From: Addison Phillips [mailto:addison.phillips@quest.com]=20 Sent: 07 November 2005 19:26 To: Misha Wolf; LTRU Working Group Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman;Alemanic According to the ietf-languages list discussion, 'gsw' and "de-CH" are not the same language, despite their English names. As such, "gsw-*" and "de-*-CH-*" don't match. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 To find out more about Reuters visit www.about.reuters.com 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=20 Reuters Ltd. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006F9694882570B2_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There was discussion on the list tha= t forced my registration of gsw. I previously thought de-CH and de-AT appli= ed to these Swiss and Austrian dialects as well, and I'm sure this is not a= n uncommon belief.  It was made clear that these tags applied to Germa= n and Austrian variants of standard German, often combined with the tagging= for the spelling reforms, and did not apply to the primarily spoken dialec= ts I was trying to identify.

I guess this case shows both the adv= antages and potential pitfalls of RFC 3066bis and how tagging building bloc= ks defined by RFC 3066bis could be combined in an inaccurate ways by those = who are unfamiliar with such subtleties . Perhaps the multiple description = feature in the registry will help resolve some of these ambiguities -- it's= not particularly unreasonable to assume that de-CH defines "Swiss Ger= man."  If this tag is added to the registry, I would also include= the description "Schwyzerd= =FCtsch." This is also the n= ame used for this language in 639-3.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384



Misha Wolf <Misha.Wolf@reuters= .com>
Sent by: ltru-bounces@ietf.org

11/07/2005 11:33 AM

       
        To: &nbs= p;      Addison Phillips <addison.phillips@quest.com>,= LTRU Working Group <ltru@ietf.org>
        cc: &nbs= p;      
        Subject:=        RE: [Ltru] Re: New ISO 639 language identifier = approved:        SwissGerman;Alemanic



I must have been asleep at the time= :-)

This will require some fancy user education!

Misha


-----Original Message-----
From: Addison Phillips [mailto:addison.phillips@quest.com]
Sent: 07 November 2005 19:26
To: Misha Wolf; LTRU Working Group
Subject: RE: [Ltru] Re: New ISO 639 language identifier approved:
SwissGerman;Alemanic

According to the ietf-languages list discussion, 'gsw' and "de-CH"= ; are
not the same language, despite their English names. As such, "gsw-*&qu= ot; and
"de-*-CH-*" don't match.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture.


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d.


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

--=_alternative 006F9694882570B2_=-- --===============0836901823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0836901823==-- From ltru-bounces@ietf.org Mon Nov 07 16:56:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEyW-0002Kj-QD; Mon, 07 Nov 2005 16:56:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEyU-0002Ke-U1 for ltru@megatron.ietf.org; Mon, 07 Nov 2005 16:56:23 -0500 Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10513 for ; Mon, 7 Nov 2005 16:55:57 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051107215529.SDVE19306.mta11.adelphia.net@DGBP7M81>; Mon, 7 Nov 2005 16:55:29 -0500 Message-ID: <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> Date: Mon, 7 Nov 2005 13:55:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: >> The consensus of the WG has been that ccTLDs are one use of ISO >> 3166-1 alpha-2 code elements, and language tags are another, and >> that is the only relationship between the two. > > I do not want to harp on this answer by the author of the proposed > IANA language registry. I know you are a Unicode, W3C, ISO expert. > But this is the IETF. This triggers the RFC 3935 principle of > competence. This is a serious cause for appeal of your proposed > registry. First, I am not an author. I am an editor. The difference, as I understand it, is that the present document consists entirely of group consensus material, approved by the group before it makes its way into the document. This is not a matter of me writing the words and the group subsequently approving them. This is an important distinction, since the ownership of and responsibility for the content belongs to the group, not just me. My job as editor of this document, again as I understand it, is as follows: 1. To ensure that the initial registry (Section 3) is correct and complete, according to its own rules and based on the current contents of the core standards. 2. To ensure that the accompanying text (Section 2) accurately reflects the process by which the initial registry contents were derived. 3. To ensure that the entire document reflects rough group consensus. The job of editing this particular document is one of a record-keeper, not a lingusitic or network expert. Of course, since I have now been charged with incompetence, and an appeal has been threatened against draft-initial on that basis, what I say must be taken at face value. Certainly this charge must be taken seriously from a contributor who has never written, co-written, edited, or co-edited an RFC. >>> Question: is the "only the larger island" meant to exclude the Isles >>> of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. >>> and the claim they may still have on Corsica? >> >> Don't ask me. I'm not the one who keeps insisting that GB stands >> for something other than the entire United Kingdom. > > This also trigger the RFC 3935 principle of competence and of > responsibility for your registry proposition. > - you published a Draft registry where you releate territories and > languages. Draft-registry (the document edited by Addison and Mark) defines region subtags as a way "to indicate linguistic variations associated with or appropriate to a specific country, territory, or region," and says that the set of valid region subtags is drawn from a registry. Draft-initial (the document currently edited by me) presents the initial contents of the registry, and explains how those initial contents were determined. It says nothing about how region subtags should be used. > - you comment one entry (GB) seeming to exclude the reference to a > larger territory than many other territories in the registry For the LAST TIME, the region subtag GB in the initial registry represents "United Kingdom." It does not represent a portion or subdivision thereof. This would be equally true regardless of whether the actual letters were GB, UK, or ZQ. ----- Type: region Subtag: GB Description: United Kingdom Added: 2005-10-16 ----- Is this still unclear in some way? What can I do to make it more clear? > - when asked about it you answer "Don't ask me". Who else should I > ask? You should ask the person who is continuing to claim that GB does not represent "United Kingdom" because it consists of the letters G and B. > We cannot expect from you as an author to be an expert in every > international issue at hand. But we can expect you have a methodology > to address them. You should not expect anything from me as an author, because I am not one. As an EDITOR, I should be expected to follow the methodology agreed upon by the group, which is to use ISO 3166-1 alpha-2 code elements (dating back to the publication date of RFC 1766) as region subtags, and not to invent our own region subtags. > You are the author of RFC 3066 bis comburent document, "Comburent"? It supports combustion? What does this mean? In any case, I am an editor, not an author. At least for now. > I suppose you want to see applied and used? Well, of course if I am contributing to a document, I don't want to see to go directly into the dustbin. > Authors of the RFC 3066 bis have documented enough they add > constraints to RFC 3066 to ensure its better use. This use depends on > experts you currently embodies as the registry authors the point > above permits me to qualify as unprecise. I genuinely do not understand that last sentence, and would appreciate if someone would explain to me what it means. > I do not think RFC 3066 bis is nefarious (your term) but uncomplete. > Imposing a proprietary naming system to language products, solutions > etc. It will also lead to unprecise and contradictory filtering. "Proprietary" in English means that a party exercises exclusive private ownership over something. RFC 3066bis is based on publicly available ISO and UN standards, augmented by variant subtags established by a publicly accessible, IETF-affiliated group, and private-use tags defined by end users. Standards that are not freely available, such as ISO 3166-2, were expressly excluded. The mechanism itself is intended for publication in a freely available document, and the drafts have always been freely available. Other than the IETF and Internet Society boilerplate, there are no copyright notices, patents, trademark restrictions, or other IP restrictions. Where is the private ownership? > The question is simple: who is most authoritative over what people > do. The experts who feed their computers or the people themselves? > This is like parents for their kids. At the begining the experts are. > Then technology and the people's expertise develops and becomes more > pertinent. There is a need for a transition. > > Transitions are costly and mean (power, control, market, recognition, > etc.) domain losses. So, some experts want to stay in the lead > instead of transfering. They progressively lose (RFC 3935) competence > and responsibility capacity. This is why I think it is upto > responsible engineers to organise the new technical context for > experts to assist people, instead of shepherding them. Well, I guess everyone should just make up their own language tags as they go. That will surely eliminate the problem of "unprecise and contradictory filtering." > These reluctant experts may be unaware or nostalgic, I do not judge > them. They may confuse some merchants for a while (commercial > interest is _never_ to oppose the market). But they are on the wrong > track, and the work they do (which unfortunately might be precious) > might be lost. We saw that all the time, in all the technologies. > "the customer/user is king" is not a commercial trick, but a long > time experience. I have said repeatedly, and will say again FOR THE LAST TIME, that I have NO commercial stake in this project. My company neither supports nor opposes this project. I have been involved in it for reasons of personal choice only. I joined this project back in March 2004, during its preliminary stage on ietf-languages, because I wanted to help coordinate the registry under discussion. I thought it would help. Obviously if draft-initial is now going to be appealed on the basis of my supposed incompetence, then my contribution is not helping. We have already seen the progress of draft-registry stalled indefinitely by one appeal. There should be no doubt that this contributor will follow through on his threat to file another appeal -- anything to prevent the LTRU documents from moving forward. This has been a very difficult project for me personally, all because of one person. I did not get involved so that I could be accused of trampling on the needs and desires of users, or giving big powerful corporations hegemony over the Internet, or making "Govs" angry, or violating human rights, or causing people to "suffer and die" (an actual quote). I deeply resent having been accused of these things continually over the past year. I was under the impression that RFC 3934 and RFC 3683 existed so that WG business could be conducted on mailing lists just as it would be face-to-face, in an orderly manner, with reasonable dissent but without being beaten over the head by a lone angry protester. As it turns out, either the process does not work or there is little or no desire to make it work in this case. I have been told to sit quietly and take it, and admonished for responding; in short, I am getting no support on this. On top of this, my involvement is now poised to trigger an appeal on grounds of incompetence. This is both detrimental to the project and personally embarrassing. I don't know if there is any process or precedent for transferring the editorship of a document already in IESG Last Call, but I am now asking Randy and Martin to investigate this for draft-ietf-ltru-initial. I mentioned this possible course of action in private e-mails yesterday and have received no response at all, which perhaps is telling in its own way. I request a timely response from the co-chairs, and from the AD if appropriate. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 17:15:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFHA-00068A-3Z; Mon, 07 Nov 2005 17:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFH8-000685-4K for ltru@megatron.ietf.org; Mon, 07 Nov 2005 17:15:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11503 for ; Mon, 7 Nov 2005 17:15:12 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFWo-00023o-KJ for ltru@ietf.org; Mon, 07 Nov 2005 17:31:51 -0500 Received: from vegeta.corp.google.com (vegeta.corp.google.com [172.24.0.3]) by smtp-out.google.com with ESMTP id jA7MFVNb002990; Mon, 7 Nov 2005 14:15:31 -0800 Received: from [172.24.89.156] (evdp.corp.google.com [172.24.89.156]) by vegeta.corp.google.com with ESMTP id jA7MFTur003190; Mon, 7 Nov 2005 14:15:29 -0800 Message-ID: <436FD201.6080101@google.com> Date: Mon, 07 Nov 2005 14:15:29 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-out.google.com id jA7MFVNb002990 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Misha Wolf , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm sorry that I brought up an old issue! I just joined ietf-languages.=20 I agree with Karen that it would be a good idea to use the multiple=20 description feature to point out the subtleties. Perhaps gsw should be=20 mentioned in the entries for de, CH, de-CH-1901 and de-CH-1996. Or maybe=20 a pointer (URI) to a document that briefly explains this stuff. E.g. %% Type: language Subtag: de Description: German Description: see also=20 http://www.iana.org/assignments/lang-tag-docs/swiss-german Added: 2005-10-16 Suppress-Script: Latn %% (and the same for CH, de-CH-1901, de-CH-1996 and gsw) Erik Karen_Broome@spe.sony.com wrote: > There was discussion on the list that forced my registration of gsw. I=20 > previously thought de-CH and de-AT applied to these Swiss and Austrian=20 > dialects as well, and I'm sure this is not an uncommon belief. It was=20 > made clear that these tags applied to German and Austrian variants of=20 > standard German, often combined with the tagging for the spelling=20 > reforms, and did not apply to the primarily spoken dialects I was tryin= g=20 > to identify. >=20 > I guess this case shows both the advantages and potential pitfalls of=20 > RFC 3066bis and how tagging building blocks defined by RFC 3066bis coul= d=20 > be combined in an inaccurate ways by those who are unfamiliar with such= =20 > subtleties . Perhaps the multiple description feature in the registry=20 > will help resolve some of these ambiguities -- it's not particularly=20 > unreasonable to assume that de-CH defines "Swiss German." If this tag=20 > is added to the registry, I would also include the description=20 > "Schwyzerd=FCtsch." This is also the name used for this language in 639= -3. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 18:26:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGO3-0007kH-EJ; Mon, 07 Nov 2005 18:26:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGO2-0007kC-22 for ltru@megatron.ietf.org; Mon, 07 Nov 2005 18:26:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16896 for ; Mon, 7 Nov 2005 18:26:22 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGdg-0004VY-GP for ltru@ietf.org; Mon, 07 Nov 2005 18:43:01 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 15:26:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic Date: Mon, 7 Nov 2005 15:26:25 -0800 Message-ID: Thread-Topic: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic Thread-Index: AcXj6O+Qob5NiisfS9qPdDxz1xOZxQAB8GKA From: "Addison Phillips" To: "Erik van der Poel" , X-OriginalArrivalTime: 07 Nov 2005 23:26:33.0703 (UTC) FILETIME=[B0C21F70:01C5E3F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Misha Wolf , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1236657875==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1236657875== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2UnZCBiZSBiZXR0ZXIgb2ZmIHdpdGggYSBsb25nICJDb21tZW50cyIgZmllbGQgdGhhbiB3aXRo IGFuIHVudXN1YWwgIkRlc2NyaXB0aW9uIi4gQW5kLCBpbiBteSBvcGluaW9uLCB0aGUgIkNvbW1l bnRzIiB3b3VsZCBwcm9wZXJseSBiZWxvbmcgb24gdGhlICdnc3cnIHN1YnRhZy4gDQoNCkludGVy ZXN0aW5nbHksIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbGxvd3MgZm9yIGluZGl2aWR1YWxz IHRvIHByb3Bvc2UgYWRkaXRpb25zIG9mIHRoaXMgbmF0dXJlLCBpZiBzb21lb25lIGZlZWxzIHRo ZW0gbmVjZXNzYXJ5LiBBIGxvbmctaXNoIGNvbW1lbnQgbWlnaHQgZXZlbiBiZSBqdXN0aWZpZWQg dG8gcHJldmVudCBmdXR1cmUgY29uZnVzaW9uLiBGb3IgZXhhbXBsZToNCg0KJSUNClR5cGU6IGxh bmd1YWdlDQpTdWJ0YWc6IGdzdw0KRGVzY3JpcHRpb246IEFsZW1hbmljDQpEZXNjcmlwdGlvbjog U3dpc3MgR2VybWFuDQpEZXNjcmlwdGlvbjogU2Nod3l6ZXJkJiN4RkM7dHNjaA0KQWRkZWQ6IDIw MDUtMTAtMTYNClN1cHByZXNzLVNjcmlwdDogTGF0bg0KQ29tbWVudHM6IEFsdGhvdWdoIHRoZSBk ZXNjcmlwdGlvbiAnU3dpc3MgR2VybWFuJyBpcyBzdWdnZXN0aXZlLA0KICB0aGlzIGxhbmd1YWdl IGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyB0YWdzIG9mIHRoZSBmb3JtIA0KICAiZGUtQ0giIGFu ZCB0aGlzIHN1YnRhZyBzaG91bGQgbm90IGJlIHVzZWQgdG8gaW5kaWNhdGUNCiAgdGhhdCBwYXJ0 aWN1bGFyIHJlZ2lvbmFsIHZhcmlhdGlvbiBvZiBTdGFuZGFyZCBHZXJtYW4uDQolJQ0KDQpCZXN0 IFJlZ2FyZHMsDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0 aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBFcmlrIHZhbiBkZXIgUG9lbA0KPiBTZW50OiAy MDA15bm0MTHmnIg35pelIDE0OjE1DQo+IFRvOiBLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tDQo+ IENjOiBNaXNoYSBXb2xmOyBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1 XSBSZTogTmV3IElTTyA2MzkgbGFuZ3VhZ2UgaWRlbnRpZmllciBhcHByb3ZlZDoNCj4gU3dpc3NH ZXJtYW47IEFsZW1hbmljDQo+IA0KPiBJJ20gc29ycnkgdGhhdCBJIGJyb3VnaHQgdXAgYW4gb2xk IGlzc3VlISBJIGp1c3Qgam9pbmVkIGlldGYtbGFuZ3VhZ2VzLg0KPiBJIGFncmVlIHdpdGggS2Fy ZW4gdGhhdCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byB1c2UgdGhlIG11bHRpcGxlDQo+IGRl c2NyaXB0aW9uIGZlYXR1cmUgdG8gcG9pbnQgb3V0IHRoZSBzdWJ0bGV0aWVzLiBQZXJoYXBzIGdz dyBzaG91bGQgYmUNCj4gbWVudGlvbmVkIGluIHRoZSBlbnRyaWVzIGZvciBkZSwgQ0gsIGRlLUNI LTE5MDEgYW5kIGRlLUNILTE5OTYuIE9yIG1heWJlDQo+IGEgcG9pbnRlciAoVVJJKSB0byBhIGRv Y3VtZW50IHRoYXQgYnJpZWZseSBleHBsYWlucyB0aGlzIHN0dWZmLiBFLmcuDQo+IA0KPiAlJQ0K PiBUeXBlOiBsYW5ndWFnZQ0KPiBTdWJ0YWc6IGRlDQo+IERlc2NyaXB0aW9uOiBHZXJtYW4NCj4g RGVzY3JpcHRpb246IHNlZSBhbHNvDQo+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv bGFuZy10YWctZG9jcy9zd2lzcy1nZXJtYW4NCj4gQWRkZWQ6IDIwMDUtMTAtMTYNCj4gU3VwcHJl c3MtU2NyaXB0OiBMYXRuDQo+ICUlDQo+IA0KPiAoYW5kIHRoZSBzYW1lIGZvciBDSCwgZGUtQ0gt MTkwMSwgZGUtQ0gtMTk5NiBhbmQgZ3N3KQ0KPiANCj4gRXJpaw0KPiANCj4gS2FyZW5fQnJvb21l QHNwZS5zb255LmNvbSB3cm90ZToNCj4gPiBUaGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiB0aGUgbGlz dCB0aGF0IGZvcmNlZCBteSByZWdpc3RyYXRpb24gb2YgZ3N3LiBJDQo+ID4gcHJldmlvdXNseSB0 aG91Z2h0IGRlLUNIIGFuZCBkZS1BVCBhcHBsaWVkIHRvIHRoZXNlIFN3aXNzIGFuZCBBdXN0cmlh bg0KPiA+IGRpYWxlY3RzIGFzIHdlbGwsIGFuZCBJJ20gc3VyZSB0aGlzIGlzIG5vdCBhbiB1bmNv bW1vbiBiZWxpZWYuICBJdCB3YXMNCj4gPiBtYWRlIGNsZWFyIHRoYXQgdGhlc2UgdGFncyBhcHBs aWVkIHRvIEdlcm1hbiBhbmQgQXVzdHJpYW4gdmFyaWFudHMgb2YNCj4gPiBzdGFuZGFyZCBHZXJt YW4sIG9mdGVuIGNvbWJpbmVkIHdpdGggdGhlIHRhZ2dpbmcgZm9yIHRoZSBzcGVsbGluZw0KPiA+ IHJlZm9ybXMsIGFuZCBkaWQgbm90IGFwcGx5IHRvIHRoZSBwcmltYXJpbHkgc3Bva2VuIGRpYWxl Y3RzIEkgd2FzIHRyeWluZw0KPiA+IHRvIGlkZW50aWZ5Lg0KPiA+DQo+ID4gSSBndWVzcyB0aGlz IGNhc2Ugc2hvd3MgYm90aCB0aGUgYWR2YW50YWdlcyBhbmQgcG90ZW50aWFsIHBpdGZhbGxzIG9m DQo+ID4gUkZDIDMwNjZiaXMgYW5kIGhvdyB0YWdnaW5nIGJ1aWxkaW5nIGJsb2NrcyBkZWZpbmVk IGJ5IFJGQyAzMDY2YmlzIGNvdWxkDQo+ID4gYmUgY29tYmluZWQgaW4gYW4gaW5hY2N1cmF0ZSB3 YXlzIGJ5IHRob3NlIHdobyBhcmUgdW5mYW1pbGlhciB3aXRoIHN1Y2gNCj4gPiBzdWJ0bGV0aWVz IC4gUGVyaGFwcyB0aGUgbXVsdGlwbGUgZGVzY3JpcHRpb24gZmVhdHVyZSBpbiB0aGUgcmVnaXN0 cnkNCj4gPiB3aWxsIGhlbHAgcmVzb2x2ZSBzb21lIG9mIHRoZXNlIGFtYmlndWl0aWVzIC0tIGl0 J3Mgbm90IHBhcnRpY3VsYXJseQ0KPiA+IHVucmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCBkZS1D SCBkZWZpbmVzICJTd2lzcyBHZXJtYW4uIiAgSWYgdGhpcyB0YWcNCj4gPiBpcyBhZGRlZCB0byB0 aGUgcmVnaXN0cnksIEkgd291bGQgYWxzbyBpbmNsdWRlIHRoZSBkZXNjcmlwdGlvbg0KPiA+ICJT Y2h3eXplcmTDvHRzY2guIiBUaGlzIGlzIGFsc28gdGhlIG5hbWUgdXNlZCBmb3IgdGhpcyBsYW5n dWFnZSBpbiA2MzktMy4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============1236657875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1236657875==-- From ltru-bounces@ietf.org Mon Nov 07 18:58:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGt0-0006J7-8z; Mon, 07 Nov 2005 18:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGsy-0006Dy-6R for ltru@megatron.ietf.org; Mon, 07 Nov 2005 18:58:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19799 for ; Mon, 7 Nov 2005 18:58:21 -0500 (EST) From: Karen_Broome@spe.sony.com Received: from mail-par.bigfish.com ([217.117.146.230] helo=mail3-par-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZH8c-0005iI-HL for ltru@ietf.org; Mon, 07 Nov 2005 19:15:01 -0500 Received: from mail3-par.bigfish.com (localhost.localdomain [127.0.0.1]) by mail3-par-R.bigfish.com (Postfix) with ESMTP id A139D4ABDA3; Mon, 7 Nov 2005 23:58:31 +0000 (UTC) X-BigFish: VP Received: by mail3-par (MessageSwitch) id 1131407911564716_5054; Mon, 7 Nov 2005 23:58:31 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail3-par.bigfish.com (Postfix) with ESMTP id 391114ABD48; Mon, 7 Nov 2005 23:58:31 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005110715495593:45822 ; Mon, 7 Nov 2005 15:49:55 -0800 To: "Addison Phillips" Subject: RE: [Ltru] Re: New ISO 639 language identifier approved: SwissGerman; Alemanic MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.13 March 9, 2004 Message-ID: Date: Mon, 7 Nov 2005 15:39:52 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 11/07/2005 15:39:53, Serialize complete at 11/07/2005 15:39:53, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/07/2005 03:49:55 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/07/2005 04:08:22 PM, Serialize complete at 11/07/2005 04:08:22 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Misha Wolf , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1444769342==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1444769342== Content-Type: multipart/alternative; boundary="=_alternative 008202A9882570B2_=" This is a multipart message in MIME format. --=_alternative 008202A9882570B2_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KzENCg0KSWYgSSBoYXZlIGFkZGl0aW9uYWwgc3VnZ2VzdGlvbnMgZm9yIGNvbW1lbnRzIHN1Y2gg YXMgdGhlc2UsIEkgd2lsbCBzdWJtaXQgDQp0aGVtLiAoTm9uZSBjb21lIHRvIG1pbmQgYXQgcHJl c2VudCwgYnV0IEknbGwgZ2l2ZSBpdCBzb21lIHRob3VnaHQgYmFzZWQgDQpvbiB3aGF0IEkndmUg c2VlbiBpbiBteSBhbmFseXNpcyBvZiByZWFsLXdvcmxkIGFwcGxpY2F0aW9uIG9mIHRoZXNlIHRh Z3MuKSANCiBJIHRoaW5rIHRoZSBjb21tZW50cyBmaWVsZCBpcyBjcml0aWNhbCBmb3IgZXhhY3Rs eSBzdWNoIGNhc2VzLiAtIEthcmVuDQoNCg0KDQoNCg0KIkFkZGlzb24gUGhpbGxpcHMiIDxhZGRp c29uLnBoaWxsaXBzQHF1ZXN0LmNvbT4NCjExLzA3LzIwMDUgMDM6MjYgUE0NCg0KIA0KICAgICAg ICBUbzogICAgICJFcmlrIHZhbiBkZXIgUG9lbCIgPGVyaWt2QGdvb2dsZS5jb20+LCA8S2FyZW5f QnJvb21lQHNwZS5zb255LmNvbT4NCiAgICAgICAgY2M6ICAgICAiTWlzaGEgV29sZiIgPE1pc2hh LldvbGZAcmV1dGVycy5jb20+LCAiTFRSVSBXb3JraW5nIEdyb3VwIiANCjxsdHJ1QGlldGYub3Jn Pg0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUkU6IFtMdHJ1XSBSZTogTmV3IElTTyA2MzkgbGFu Z3VhZ2UgaWRlbnRpZmllciBhcHByb3ZlZDogU3dpc3NHZXJtYW47IA0KQWxlbWFuaWMNCg0KDQpX ZSdkIGJlIGJldHRlciBvZmYgd2l0aCBhIGxvbmcgIkNvbW1lbnRzIiBmaWVsZCB0aGFuIHdpdGgg YW4gdW51c3VhbCANCiJEZXNjcmlwdGlvbiIuIEFuZCwgaW4gbXkgb3BpbmlvbiwgdGhlICJDb21t ZW50cyIgd291bGQgcHJvcGVybHkgYmVsb25nIG9uIA0KdGhlICdnc3cnIHN1YnRhZy4gDQoNCklu dGVyZXN0aW5nbHksIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbGxvd3MgZm9yIGluZGl2aWR1 YWxzIHRvIHByb3Bvc2UgDQphZGRpdGlvbnMgb2YgdGhpcyBuYXR1cmUsIGlmIHNvbWVvbmUgZmVl bHMgdGhlbSBuZWNlc3NhcnkuIEEgbG9uZy1pc2ggDQpjb21tZW50IG1pZ2h0IGV2ZW4gYmUganVz dGlmaWVkIHRvIHByZXZlbnQgZnV0dXJlIGNvbmZ1c2lvbi4gRm9yIGV4YW1wbGU6DQoNCiUlDQpU eXBlOiBsYW5ndWFnZQ0KU3VidGFnOiBnc3cNCkRlc2NyaXB0aW9uOiBBbGVtYW5pYw0KRGVzY3Jp cHRpb246IFN3aXNzIEdlcm1hbg0KRGVzY3JpcHRpb246IFNjaHd5emVyZCYjeEZDO3RzY2gNCkFk ZGVkOiAyMDA1LTEwLTE2DQpTdXBwcmVzcy1TY3JpcHQ6IExhdG4NCkNvbW1lbnRzOiBBbHRob3Vn aCB0aGUgZGVzY3JpcHRpb24gJ1N3aXNzIEdlcm1hbicgaXMgc3VnZ2VzdGl2ZSwNCiAgdGhpcyBs YW5ndWFnZSBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgdGFncyBvZiB0aGUgZm9ybSANCiAgImRl LUNIIiBhbmQgdGhpcyBzdWJ0YWcgc2hvdWxkIG5vdCBiZSB1c2VkIHRvIGluZGljYXRlDQogIHRo YXQgcGFydGljdWxhciByZWdpb25hbCB2YXJpYXRpb24gb2YgU3RhbmRhcmQgR2VybWFuLg0KJSUN Cg0KQmVzdCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2Jh bGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMg bm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRy dS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gRXJpayB2YW4gZGVyIFBvZWwNCj4g U2VudDogMjAwNeW5tDEx5pyIN+aXpSAxNDoxNQ0KPiBUbzogS2FyZW5fQnJvb21lQHNwZS5zb255 LmNvbQ0KPiBDYzogTWlzaGEgV29sZjsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJl OiBbTHRydV0gUmU6IE5ldyBJU08gNjM5IGxhbmd1YWdlIGlkZW50aWZpZXIgYXBwcm92ZWQ6DQo+ IFN3aXNzR2VybWFuOyBBbGVtYW5pYw0KPiANCj4gSSdtIHNvcnJ5IHRoYXQgSSBicm91Z2h0IHVw IGFuIG9sZCBpc3N1ZSEgSSBqdXN0IGpvaW5lZCBpZXRmLWxhbmd1YWdlcy4NCj4gSSBhZ3JlZSB3 aXRoIEthcmVuIHRoYXQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gdXNlIHRoZSBtdWx0aXBs ZQ0KPiBkZXNjcmlwdGlvbiBmZWF0dXJlIHRvIHBvaW50IG91dCB0aGUgc3VidGxldGllcy4gUGVy aGFwcyBnc3cgc2hvdWxkIGJlDQo+IG1lbnRpb25lZCBpbiB0aGUgZW50cmllcyBmb3IgZGUsIENI LCBkZS1DSC0xOTAxIGFuZCBkZS1DSC0xOTk2LiBPciBtYXliZQ0KPiBhIHBvaW50ZXIgKFVSSSkg dG8gYSBkb2N1bWVudCB0aGF0IGJyaWVmbHkgZXhwbGFpbnMgdGhpcyBzdHVmZi4gRS5nLg0KPiAN Cj4gJSUNCj4gVHlwZTogbGFuZ3VhZ2UNCj4gU3VidGFnOiBkZQ0KPiBEZXNjcmlwdGlvbjogR2Vy bWFuDQo+IERlc2NyaXB0aW9uOiBzZWUgYWxzbw0KPiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2xhbmctdGFnLWRvY3Mvc3dpc3MtZ2VybWFuDQo+IEFkZGVkOiAyMDA1LTEwLTE2DQo+ IFN1cHByZXNzLVNjcmlwdDogTGF0bg0KPiAlJQ0KPiANCj4gKGFuZCB0aGUgc2FtZSBmb3IgQ0gs IGRlLUNILTE5MDEsIGRlLUNILTE5OTYgYW5kIGdzdykNCj4gDQo+IEVyaWsNCj4gDQo+IEthcmVu X0Jyb29tZUBzcGUuc29ueS5jb20gd3JvdGU6DQo+ID4gVGhlcmUgd2FzIGRpc2N1c3Npb24gb24g dGhlIGxpc3QgdGhhdCBmb3JjZWQgbXkgcmVnaXN0cmF0aW9uIG9mIGdzdy4gSQ0KPiA+IHByZXZp b3VzbHkgdGhvdWdodCBkZS1DSCBhbmQgZGUtQVQgYXBwbGllZCB0byB0aGVzZSBTd2lzcyBhbmQg QXVzdHJpYW4NCj4gPiBkaWFsZWN0cyBhcyB3ZWxsLCBhbmQgSSdtIHN1cmUgdGhpcyBpcyBub3Qg YW4gdW5jb21tb24gYmVsaWVmLiAgSXQgd2FzDQo+ID4gbWFkZSBjbGVhciB0aGF0IHRoZXNlIHRh Z3MgYXBwbGllZCB0byBHZXJtYW4gYW5kIEF1c3RyaWFuIHZhcmlhbnRzIG9mDQo+ID4gc3RhbmRh cmQgR2VybWFuLCBvZnRlbiBjb21iaW5lZCB3aXRoIHRoZSB0YWdnaW5nIGZvciB0aGUgc3BlbGxp bmcNCj4gPiByZWZvcm1zLCBhbmQgZGlkIG5vdCBhcHBseSB0byB0aGUgcHJpbWFyaWx5IHNwb2tl biBkaWFsZWN0cyBJIHdhcyANCnRyeWluZw0KPiA+IHRvIGlkZW50aWZ5Lg0KPiA+DQo+ID4gSSBn dWVzcyB0aGlzIGNhc2Ugc2hvd3MgYm90aCB0aGUgYWR2YW50YWdlcyBhbmQgcG90ZW50aWFsIHBp dGZhbGxzIG9mDQo+ID4gUkZDIDMwNjZiaXMgYW5kIGhvdyB0YWdnaW5nIGJ1aWxkaW5nIGJsb2Nr cyBkZWZpbmVkIGJ5IFJGQyAzMDY2YmlzIA0KY291bGQNCj4gPiBiZSBjb21iaW5lZCBpbiBhbiBp bmFjY3VyYXRlIHdheXMgYnkgdGhvc2Ugd2hvIGFyZSB1bmZhbWlsaWFyIHdpdGggDQpzdWNoDQo+ ID4gc3VidGxldGllcyAuIFBlcmhhcHMgdGhlIG11bHRpcGxlIGRlc2NyaXB0aW9uIGZlYXR1cmUg aW4gdGhlIHJlZ2lzdHJ5DQo+ID4gd2lsbCBoZWxwIHJlc29sdmUgc29tZSBvZiB0aGVzZSBhbWJp Z3VpdGllcyAtLSBpdCdzIG5vdCBwYXJ0aWN1bGFybHkNCj4gPiB1bnJlYXNvbmFibGUgdG8gYXNz dW1lIHRoYXQgZGUtQ0ggZGVmaW5lcyAiU3dpc3MgR2VybWFuLiIgIElmIHRoaXMgdGFnDQo+ID4g aXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LCBJIHdvdWxkIGFsc28gaW5jbHVkZSB0aGUgZGVzY3Jp cHRpb24NCj4gPiAiU2Nod3l6ZXJkw7x0c2NoLiIgVGhpcyBpcyBhbHNvIHRoZSBuYW1lIHVzZWQg Zm9yIHRoaXMgbGFuZ3VhZ2UgaW4gDQo2MzktMy4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K DQoNCg0K --=_alternative 008202A9882570B2_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBJIGhhdmUgYWRkaXRpb25hbCBzdWdn ZXN0aW9ucyBmb3IgY29tbWVudHMgc3VjaCBhcyB0aGVzZSwgSSB3aWxsIHN1Ym1pdCB0aGVtLiAo Tm9uZSBjb21lIHRvIG1pbmQgYXQgcHJlc2VudCwgYnV0IEknbGwgZ2l2ZSBpdCBzb21lIHRob3Vn aHQgYmFzZWQgb24gd2hhdCBJJ3ZlIHNlZW4gaW4gbXkgYW5hbHlzaXMgb2YgcmVhbC13b3JsZCBh cHBsaWNhdGlvbiBvZiB0aGVzZSB0YWdzLikgJm5ic3A7SSB0aGluayB0aGUgY29tbWVudHMgZmll bGQgaXMgY3JpdGljYWwgZm9yIGV4YWN0bHkgc3VjaCBjYXNlcy4gLSBLYXJlbjwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0FkZGlz b24gUGhpbGxpcHMmcXVvdDsgJmx0O2FkZGlzb24ucGhpbGxpcHNAcXVlc3QuY29tJmd0OzwvYj48 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTEvMDcvMjAwNSAwMzoy NiBQTTwvZm9udD4NCjxicj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUbzogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7RXJpayB2YW4gZGVyIFBvZWwmcXVvdDsgJmx0O2VyaWt2QGdvb2dsZS5j b20mZ3Q7LCAmbHQ7S2FyZW5fQnJvb21lQHNwZS5zb255LmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBj YzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7TWlzaGEgV29sZiZxdW90OyAmbHQ7 TWlzaGEuV29sZkByZXV0ZXJzLmNvbSZndDssICZxdW90O0xUUlUgV29ya2luZyBHcm91cCZxdW90 OyAmbHQ7bHRydUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtSRTogW0x0cnVdIFJlOiBOZXcgSVNPIDYzOSBsYW5ndWFnZSBpZGVu dGlmaWVyIGFwcHJvdmVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTd2lzc0dlcm1hbjsg QWxlbWFuaWM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPldlJ2QgYmUgYmV0dGVyIG9mZiB3aXRoIGEgbG9uZyAmcXVvdDtDb21t ZW50cyZxdW90OyBmaWVsZCB0aGFuIHdpdGggYW4gdW51c3VhbCAmcXVvdDtEZXNjcmlwdGlvbiZx dW90Oy4gQW5kLCBpbiBteSBvcGluaW9uLCB0aGUgJnF1b3Q7Q29tbWVudHMmcXVvdDsgd291bGQg cHJvcGVybHkgYmVsb25nIG9uIHRoZSAnZ3N3JyBzdWJ0YWcuIDxicj4NCjxicj4NCkludGVyZXN0 aW5nbHksIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbGxvd3MgZm9yIGluZGl2aWR1YWxzIHRv IHByb3Bvc2UgYWRkaXRpb25zIG9mIHRoaXMgbmF0dXJlLCBpZiBzb21lb25lIGZlZWxzIHRoZW0g bmVjZXNzYXJ5LiBBIGxvbmctaXNoIGNvbW1lbnQgbWlnaHQgZXZlbiBiZSBqdXN0aWZpZWQgdG8g cHJldmVudCBmdXR1cmUgY29uZnVzaW9uLiBGb3IgZXhhbXBsZTo8YnI+DQo8YnI+DQolJTxicj4N ClR5cGU6IGxhbmd1YWdlPGJyPg0KU3VidGFnOiBnc3c8YnI+DQpEZXNjcmlwdGlvbjogQWxlbWFu aWM8YnI+DQpEZXNjcmlwdGlvbjogU3dpc3MgR2VybWFuPGJyPg0KRGVzY3JpcHRpb246IFNjaHd5 emVyZCZhbXA7I3hGQzt0c2NoPGJyPg0KQWRkZWQ6IDIwMDUtMTAtMTY8YnI+DQpTdXBwcmVzcy1T Y3JpcHQ6IExhdG48YnI+DQpDb21tZW50czogQWx0aG91Z2ggdGhlIGRlc2NyaXB0aW9uICdTd2lz cyBHZXJtYW4nIGlzIHN1Z2dlc3RpdmUsPGJyPg0KICZuYnNwO3RoaXMgbGFuZ3VhZ2UgaXMgbm90 IHRoZSBzYW1lIHRoaW5nIGFzIHRhZ3Mgb2YgdGhlIGZvcm0gPGJyPg0KICZuYnNwOyZxdW90O2Rl LUNIJnF1b3Q7IGFuZCB0aGlzIHN1YnRhZyBzaG91bGQgbm90IGJlIHVzZWQgdG8gaW5kaWNhdGU8 YnI+DQogJm5ic3A7dGhhdCBwYXJ0aWN1bGFyIHJlZ2lvbmFsIHZhcmlhdGlvbiBvZiBTdGFuZGFy ZCBHZXJtYW4uPGJyPg0KJSU8YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMsPGJyPg0KPGJyPg0KQWRk aXNvbjxicj4NCjxicj4NCkFkZGlzb24gUC4gUGhpbGxpcHM8YnI+DQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmU8YnI+DQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0 aW9uIENvcmUgV29ya2luZyBHcm91cDxicj4NCjxicj4NCkludGVybmF0aW9uYWxpemF0aW9uIGlz IG5vdCBhIGZlYXR1cmUuPGJyPg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiA8YnI+DQo8YnI+DQom Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBsdHJ1LWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZjxi cj4NCiZndDsgRXJpayB2YW4gZGVyIFBvZWw8YnI+DQomZ3Q7IFNlbnQ6IDIwMDXlubQxMeaciDfm l6UgMTQ6MTU8YnI+DQomZ3Q7IFRvOiBLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tPGJyPg0KJmd0 OyBDYzogTWlzaGEgV29sZjsgTFRSVSBXb3JraW5nIEdyb3VwPGJyPg0KJmd0OyBTdWJqZWN0OiBS ZTogW0x0cnVdIFJlOiBOZXcgSVNPIDYzOSBsYW5ndWFnZSBpZGVudGlmaWVyIGFwcHJvdmVkOjxi cj4NCiZndDsgU3dpc3NHZXJtYW47IEFsZW1hbmljPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEknbSBz b3JyeSB0aGF0IEkgYnJvdWdodCB1cCBhbiBvbGQgaXNzdWUhIEkganVzdCBqb2luZWQgaWV0Zi1s YW5ndWFnZXMuPGJyPg0KJmd0OyBJIGFncmVlIHdpdGggS2FyZW4gdGhhdCBpdCB3b3VsZCBiZSBh IGdvb2QgaWRlYSB0byB1c2UgdGhlIG11bHRpcGxlPGJyPg0KJmd0OyBkZXNjcmlwdGlvbiBmZWF0 dXJlIHRvIHBvaW50IG91dCB0aGUgc3VidGxldGllcy4gUGVyaGFwcyBnc3cgc2hvdWxkIGJlPGJy Pg0KJmd0OyBtZW50aW9uZWQgaW4gdGhlIGVudHJpZXMgZm9yIGRlLCBDSCwgZGUtQ0gtMTkwMSBh bmQgZGUtQ0gtMTk5Ni4gT3IgbWF5YmU8YnI+DQomZ3Q7IGEgcG9pbnRlciAoVVJJKSB0byBhIGRv Y3VtZW50IHRoYXQgYnJpZWZseSBleHBsYWlucyB0aGlzIHN0dWZmLiBFLmcuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICUlPGJyPg0KJmd0OyBUeXBlOiBsYW5ndWFnZTxicj4NCiZndDsgU3VidGFnOiBk ZTxicj4NCiZndDsgRGVzY3JpcHRpb246IEdlcm1hbjxicj4NCiZndDsgRGVzY3JpcHRpb246IHNl ZSBhbHNvPGJyPg0KJmd0OyBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmctdGFn LWRvY3Mvc3dpc3MtZ2VybWFuPGJyPg0KJmd0OyBBZGRlZDogMjAwNS0xMC0xNjxicj4NCiZndDsg U3VwcHJlc3MtU2NyaXB0OiBMYXRuPGJyPg0KJmd0OyAlJTxicj4NCiZndDsgPGJyPg0KJmd0OyAo YW5kIHRoZSBzYW1lIGZvciBDSCwgZGUtQ0gtMTkwMSwgZGUtQ0gtMTk5NiBhbmQgZ3N3KTxicj4N CiZndDsgPGJyPg0KJmd0OyBFcmlrPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEthcmVuX0Jyb29tZUBz cGUuc29ueS5jb20gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIHdhcyBkaXNjdXNzaW9uIG9u IHRoZSBsaXN0IHRoYXQgZm9yY2VkIG15IHJlZ2lzdHJhdGlvbiBvZiBnc3cuIEk8YnI+DQomZ3Q7 ICZndDsgcHJldmlvdXNseSB0aG91Z2h0IGRlLUNIIGFuZCBkZS1BVCBhcHBsaWVkIHRvIHRoZXNl IFN3aXNzIGFuZCBBdXN0cmlhbjxicj4NCiZndDsgJmd0OyBkaWFsZWN0cyBhcyB3ZWxsLCBhbmQg SSdtIHN1cmUgdGhpcyBpcyBub3QgYW4gdW5jb21tb24gYmVsaWVmLiAmbmJzcDtJdCB3YXM8YnI+ DQomZ3Q7ICZndDsgbWFkZSBjbGVhciB0aGF0IHRoZXNlIHRhZ3MgYXBwbGllZCB0byBHZXJtYW4g YW5kIEF1c3RyaWFuIHZhcmlhbnRzIG9mPGJyPg0KJmd0OyAmZ3Q7IHN0YW5kYXJkIEdlcm1hbiwg b2Z0ZW4gY29tYmluZWQgd2l0aCB0aGUgdGFnZ2luZyBmb3IgdGhlIHNwZWxsaW5nPGJyPg0KJmd0 OyAmZ3Q7IHJlZm9ybXMsIGFuZCBkaWQgbm90IGFwcGx5IHRvIHRoZSBwcmltYXJpbHkgc3Bva2Vu IGRpYWxlY3RzIEkgd2FzIHRyeWluZzxicj4NCiZndDsgJmd0OyB0byBpZGVudGlmeS48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBndWVzcyB0aGlzIGNhc2Ugc2hvd3MgYm90aCB0aGUg YWR2YW50YWdlcyBhbmQgcG90ZW50aWFsIHBpdGZhbGxzIG9mPGJyPg0KJmd0OyAmZ3Q7IFJGQyAz MDY2YmlzIGFuZCBob3cgdGFnZ2luZyBidWlsZGluZyBibG9ja3MgZGVmaW5lZCBieSBSRkMgMzA2 NmJpcyBjb3VsZDxicj4NCiZndDsgJmd0OyBiZSBjb21iaW5lZCBpbiBhbiBpbmFjY3VyYXRlIHdh eXMgYnkgdGhvc2Ugd2hvIGFyZSB1bmZhbWlsaWFyIHdpdGggc3VjaDxicj4NCiZndDsgJmd0OyBz dWJ0bGV0aWVzIC4gUGVyaGFwcyB0aGUgbXVsdGlwbGUgZGVzY3JpcHRpb24gZmVhdHVyZSBpbiB0 aGUgcmVnaXN0cnk8YnI+DQomZ3Q7ICZndDsgd2lsbCBoZWxwIHJlc29sdmUgc29tZSBvZiB0aGVz ZSBhbWJpZ3VpdGllcyAtLSBpdCdzIG5vdCBwYXJ0aWN1bGFybHk8YnI+DQomZ3Q7ICZndDsgdW5y ZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IGRlLUNIIGRlZmluZXMgJnF1b3Q7U3dpc3MgR2VybWFu LiZxdW90OyAmbmJzcDtJZiB0aGlzIHRhZzxicj4NCiZndDsgJmd0OyBpcyBhZGRlZCB0byB0aGUg cmVnaXN0cnksIEkgd291bGQgYWxzbyBpbmNsdWRlIHRoZSBkZXNjcmlwdGlvbjxicj4NCiZndDsg Jmd0OyAmcXVvdDtTY2h3eXplcmTDvHRzY2guJnF1b3Q7IFRoaXMgaXMgYWxzbyB0aGUgbmFtZSB1 c2VkIGZvciB0aGlzIGxhbmd1YWdlIGluIDYzOS0zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTHRy dSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IEx0cnVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo= --=_alternative 008202A9882570B2_=-- --===============1444769342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1444769342==-- From ltru-bounces@ietf.org Mon Nov 07 20:17:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZI5o-0001NU-Pe; Mon, 07 Nov 2005 20:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZI5n-0001NN-HZ for ltru@megatron.ietf.org; Mon, 07 Nov 2005 20:16:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28681 for ; Mon, 7 Nov 2005 20:15:40 -0500 (EST) Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZILV-00011p-7z for ltru@ietf.org; Mon, 07 Nov 2005 20:32:21 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LV4HT7FJJ400BDWZ@mauve.mrochek.com> (original mail from ned.freed@mrochek.com) for ltru@ietf.org; Mon, 7 Nov 2005 17:15:43 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1131412542; h=Date: From:Subject:MIME-version:Content-type; b=svXn/0lciXxuqJAp6bsr5e5hP /q/Ht1xKV/gTX6mmblL8QBjzYEVM7k7Wb7r0MUW/yrof+2HRaSbkpWoQC9ACA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LV05D9CZ0W000092@mauve.mrochek.com>; Mon, 07 Nov 2005 17:15:40 -0800 (PST) To: Doug Ewell Message-id: <01LV4HT6RCC6000092@mauve.mrochek.com> Date: Mon, 07 Nov 2005 16:42:21 -0800 (PST) From: Ned Freed Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-reply-to: "Your message dated Mon, 07 Nov 2005 13:55:25 -0800" <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=utf-8; reply-type=original References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > I have said repeatedly, and will say again FOR THE LAST TIME, that I > have NO commercial stake in this project. My company neither supports > nor opposes this project. I have been involved in it for reasons of > personal choice only. FWIW, this parallels my own, much more limited, involvement in this group. I have tracked this effort because I felt that there were some issues surrounding the handling of language tags that needed to be addressed in the original 3066bis document. I'm pleased to say that I believe these issues have all been dealt with in the current round of drafts. My employer, Sun Microsystems, has never expressed the slightest degree of interest in telling me to present a particular position on any of this. My past objections were solely my own, as is my current support. > I joined this project back in March 2004, during its preliminary stage > on ietf-languages, because I wanted to help coordinate the registry > under discussion. I thought it would help. Obviously if draft-initial > is now going to be appealed on the basis of my supposed incompetence, > then my contribution is not helping. Doug, I doubt very much that you being the editor is a significant factor here. > We have already seen the progress > of draft-registry stalled indefinitely by one appeal. There should be > no doubt that this contributor will follow through on his threat to file > another appeal -- anything to prevent the LTRU documents from moving > forward. I'm afraid I have to agree with this assessment. I further note that there have only ever been 10 IESG appeals, and 3 of them have yet to be resolved. I don't believe there has ever been a time when there were 3 open at once, and this may result in the appeals taking longer than usual. > This has been a very difficult project for me personally, all because of > one person. I did not get involved so that I could be accused of > trampling on the needs and desires of users, or giving big powerful > corporations hegemony over the Internet, or making "Govs" angry, or > violating human rights, or causing people to "suffer and die" (an actual > quote). I deeply resent having been accused of these things continually > over the past year. Doug, while I have not been on the receiving end of any of this specifically, goodness knows I have been on the receiving end of various attacks as a result of my work in the IETF. I think I can therefore say that I understand where you're coming from. > I was under the impression that RFC 3934 and RFC > 3683 existed so that WG business could be conducted on mailing lists > just as it would be face-to-face, in an orderly manner, with reasonable > dissent but without being beaten over the head by a lone angry > protester. Guess you haven't attended an IETF in person, then ;-) Shouting matches aren't exactly unknown. I can even recall one occasion where I thought a physical attack was imminent. I wish I could say that this sort of thing was unique to the IETF, but i've been involved in other standards processes and they can get rough as well. Some of this is necessary - the crucible of informed debate may not be a comfortable place to be - but experience has shown that having it does significantly improve the resulting specifications. But there is a limit past which things devolve into personal attacks, delaying tactics, and other sorts of pernicious nonsense. IMO we reached, and passed, that point some time back. > As it turns out, either the process does not work or there > is little or no desire to make it work in this case. I have been told > to sit quietly and take it, and admonished for responding; in short, I > am getting no support on this. Well, I for one support you in this. I think Harald at a minimum does too, although I hasten to add that I don't speak for him. > On top of this, my involvement is now poised to trigger an appeal on > grounds of incompetence. This is both detrimental to the project and > personally embarrassing. Again, my reading is that this is hardly contingent on your involvement specifically. > I don't know if there is any process or precedent for transferring the > editorship of a document already in IESG Last Call, but I am now asking > Randy and Martin to investigate this for draft-ietf-ltru-initial. I > mentioned this possible course of action in private e-mails yesterday > and have received no response at all, which perhaps is telling in its > own way. > I request a timely response from the co-chairs, and from the AD if > appropriate. Doug, I am sorry it has come to this and I for one will in my small way support any choice you elect to make. I feel it is worth pointing out that this is the serious downside to all this "free speech at any cost" stuff: It tends to drive good and valuable people - and IMO you are a valuable contributor - away. This can be hugely damaging, and I urge the powers-that-be to take note. Ned _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 20:24:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIE5-0003sC-06; Mon, 07 Nov 2005 20:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIE3-0003s7-5T for ltru@megatron.ietf.org; Mon, 07 Nov 2005 20:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29007 for ; Mon, 7 Nov 2005 20:24:12 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZITi-0001DM-Sd for ltru@ietf.org; Mon, 07 Nov 2005 20:40:53 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZIDt-0007UK-Mi; Mon, 07 Nov 2005 17:24:30 -0800 Message-Id: <6.2.3.4.2.20051107234503.05758880@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 08 Nov 2005 02:24:11 +0100 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-Reply-To: <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Doug, I read carefully your mail. I will spend time to carefully and friendly respond to it (I never took seriously the PR-action you signed). I am sincerely sorry you take as a private issue what results from your genuine adherence to an uncomplete (and this way harmful) project. I wish you calm yourself and consider what is the real debate. Also, may be will you want to reread RFC 3935: the principles of competence and of responsibility are NOT aimed at participants, but at the IETF. You are not in any case concerned. But the comments you introduce and your capacity to support them are important. So is your last comment: it seems to document what I think is the problem: the inadequation of the IETF to take the world leadership in language identification. I do not want to dispute your author/editor role: for the IETF you are the author, but I understand you prefer being called editor. In any case you are our current authority about the RFC 3066 bis associated registry. Until RFC 3066 bis is enacted (decision unfortunately is not mine) you are in fact replacing for us the ietf-languages@alvestrand.no mailing list center of expertise. They registered a few scores of langtags in 10 years. You register thousands of them. We discuss here filtering and we are heading towards a WG LC. We want to document what happens when a user has a problem with a langtag which does not match the langtags he can deal with. His problem may result: 1. from his lack of knowledge of the proposed language (this is the case considered by the draft) 2. from a concept error in the RFC 3066 bis - I consider there is a major one: its rigidity and limitations can be the main cause of problems (except may be in one exclusive case). 3. from the used registry - I consider there is a major problem which is its limitations and the procedure to add subtags (I can copy you our current equivalent draft csv). 4. from a metastructural issue not covered by the RFC 3066 bis: a predetermined non US-ASCII default due to a lingual TLD. We have a request by a participant for a subtag (UK) to be introduced as a synonym for GB. This requests mares the debate for years. It also happens that the way it is proposed may also help investigate the case nr. 4. It is therefore a simple, known to all, school case to test the proposed RFC 3066 bis/Registry system precisely designed to accommodate subtag registration. This being said, I review your points when I think it helps the filtering debate or is fair to you. At 22:55 07/11/2005, Doug Ewell wrote: >r&d afrac wrote: > >>>The consensus of the WG has been that ccTLDs are one use of ISO >>>3166-1 alpha-2 code elements, and language tags are another, and >>>that is the only relationship between the two. >> >>I do not want to harp on this answer by the author of the proposed >>IANA language registry. I know you are a Unicode, W3C, ISO expert. >>But this is the IETF. This triggers the RFC 3935 principle of >>competence. This is a serious cause for appeal of your proposed >>registry. > >First, I am not an author. I am an editor. The difference, as I >understand it, is that the present document consists entirely of >group consensus material, approved by the group before it makes its >way into the document. This is not a matter of me writing the words >and the group subsequently approving them. This is an important >distinction, since the ownership of and responsibility for the >content belongs to the group, not just me. > >My job as editor of this document, again as I understand it, is as follows: > >1. To ensure that the initial registry (Section 3) is correct and >complete, according to its own rules and based on the current >contents of the core standards. > >2. To ensure that the accompanying text (Section 2) accurately >reflects the process by which the initial registry contents were derived. > >3. To ensure that the entire document reflects rough group consensus. > >The job of editing this particular document is one of a >record-keeper, not a lingusitic or network expert. > >Of course, since I have now been charged with incompetence, and an >appeal has been threatened against draft-initial on that basis, what >I say must be taken at face value. Certainly this charge must be >taken seriously from a contributor who has never written, >co-written, edited, or co-edited an RFC. As you perfectly described it, the WG Ltru has chosen you, supported you, told you what to do, in an domain which is not yours. You carried the job very well (you may recall you are the only one I congratulated for a job well done). But all this demonstrates the IETF has NOT the capacity to carry the job as a world leading expert center and to take over the responsibility of a registry where these issues are to be discussed and decided. We have no ISO 3166 MA group member (ICANN is one), who would have appropriately addressed the issue you enlighten or which were risen. Harald just documented that this was not the job of ietf-languages to discuss the addition of UK as a subtag in the langtag registry. There is therefore not even a claim to carry what the RFC 3066 bis meant to. So, you have not been charged with incompetence. But do you pretend to be a world expert of reference in the ISO 3166 area? It happens that there are some. Acknowledged by ISO. >>>>Question: is the "only the larger island" meant to exclude the Isles >>>>of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc. >>>>and the claim they may still have on Corsica? >>> >>>Don't ask me. I'm not the one who keeps insisting that GB stands >>>for something other than the entire United Kingdom. >> >>This also trigger the RFC 3935 principle of competence and of >>responsibility for your registry proposition. >>- you published a Draft registry where you releate territories and >>languages. > >Draft-registry (the document edited by Addison and Mark) defines >region subtags as a way "to indicate linguistic variations >associated with or appropriate to a specific country, territory, or >region," and says that the set of valid region subtags is drawn from >a registry. > >Draft-initial (the document currently edited by me) presents the >initial contents of the registry, and explains how those initial >contents were determined. It says nothing about how region subtags >should be used. The question at hand is only to understandhow you yourself (as the editor of the Registry) understand one of the entries. Because you prompted a new definition. >>- you comment one entry (GB) seeming to exclude the reference to a >>larger territory than many other territories in the registry > >For the LAST TIME, the region subtag GB in the initial registry >represents "United Kingdom." It does not represent a portion or >subdivision thereof. This would be equally true regardless of >whether the actual letters were GB, UK, or ZQ. I have no problem with that. I only rose the question because _you_ said otherwise. >>- when asked about it you answer "Don't ask me". Who else should I ask? > >You should ask the person who is continuing to claim that GB does >not represent "United Kingdom" because it consists of the letters G and B. Here we are in full agreement. .... This represent the largest part of the crowd supposed to use GB. >>We cannot expect from you as an author to be an expert in every >>international issue at hand. But we can expect you have a methodology >>to address them. > >You should not expect anything from me as an author, because I am not one. > >As an EDITOR, I should be expected to follow the methodology agreed >upon by the group, which is to use ISO 3166-1 alpha-2 code elements >(dating back to the publication date of RFC 1766) as region subtags, >and not to invent our own region subtags. BTW this was documented today as a "decision" of and by the author of RFC 1766 and RFC 3066. By nature I oppose unilateral decisions without adherence because they do not scale. The Charter documents there is no real adherence. The WG-ltru has been set to correct that. >>You are the author of RFC 3066 bis comburent document, > >"Comburent"? It supports combustion? What does this mean? That RFC 3066 bis cannot fly without your registry. >In any case, I am an editor, not an author. At least for now. > >>I suppose you want to see applied and used? > >Well, of course if I am contributing to a document, I don't want to >see to go directly into the dustbin. > >>Authors of the RFC 3066 bis have documented enough they add >>constraints to RFC 3066 to ensure its better use. This use depends on >>experts you currently embodies as the registry authors the point >>above permits me to qualify as unprecise. > >I genuinely do not understand that last sentence, and would >appreciate if someone would explain to me what it means. Sorry, multilingual environment makes it more complex. RFC 3066 bis introduces constraints in addition to RFC 3066. Towards a better use of langtags. This uses calls for a registry. You are the "editor" of this registry and a member of the mailing list of expert which is to keep editing it. I think I am entitled to qualify your positions on the Brisith Isles as imprecise. This is no critic of you. This is a critic on a system which imposes on you to be authoritative in areas which are not yours. >>I do not think RFC 3066 bis is nefarious (your term) but uncomplete. >>Imposing a proprietary naming system to language products, solutions >>etc. It will also lead to unprecise and contradictory filtering. > >"Proprietary" in English means that a party exercises exclusive >private ownership over something. RFC 3066bis is based on publicly >available ISO and UN standards, augmented by variant subtags >established by a publicly accessible, IETF-affiliated group, and >private-use tags defined by end users. Standards that are not >freely available, such as ISO 3166-2, were expressly excluded. The >mechanism itself is intended for publication in a freely available >document, and the drafts have always been freely available. Other >than the IETF and Internet Society boilerplate, there are no >copyright notices, patents, trademark restrictions, or other IP >restrictions. Where is the private ownership? I will answer that because you ask, but this is now at IESG. RFC 3066 bis ABNF is designed to be consistent with the Unicode CLDR scheme and to exclude the other ABNFs by SSDOs, R&D or private users. Please read the Charter. Consider who are the authors. Find in the WG Ltru archives a response from Mark Davis to my request of information concerning the CLDR IPRs. What is under consideration now, is to understand the real purpose of filtering. Is it for an Hungarian person to know if he can understand the Polish or the Serbian he does not know, or is it it to know if the variations of the Polish locale or of the Serbian locale are most adapted to replace missing Hungarian locale elements. >>The question is simple: who is most authoritative over what people >>do. The experts who feed their computers or the people themselves? >>This is like parents for their kids. At the begining the experts are. >>Then technology and the people's expertise develops and becomes more >>pertinent. There is a need for a transition. >> >>Transitions are costly and mean (power, control, market, recognition, >>etc.) domain losses. So, some experts want to stay in the lead >>instead of transfering. They progressively lose (RFC 3935) competence >>and responsibility capacity. This is why I think it is upto >>responsible engineers to organise the new technical context for >>experts to assist people, instead of shepherding them. > >Well, I guess everyone should just make up their own language tags >as they go. That will surely eliminate the problem of "unprecise >and contradictory filtering." Certainly yes. But it would require more work to developers to understand how to do it. We know it: "the problem is the user". I am here as a user. And the world in many places, including DARPA and AFRAC, carry the necessary work. >>These reluctant experts may be unaware or nostalgic, I do not judge >>them. They may confuse some merchants for a while (commercial >>interest is _never_ to oppose the market). But they are on the wrong >>track, and the work they do (which unfortunately might be precious) >>might be lost. We saw that all the time, in all the technologies. >>"the customer/user is king" is not a commercial trick, but a long >>time experience. > >I have said repeatedly, and will say again FOR THE LAST TIME, that I >have NO commercial stake in this project. My company neither >supports nor opposes this project. I have been involved in it for >reasons of personal choice only. Doug, the commercial stakes in this are much, much bigger than that. You are not concerned. They concern the sales of billions books, contents, etc. >I joined this project back in March 2004, during its preliminary >stage on ietf-languages, because I wanted to help coordinate the >registry under discussion. I thought it would help. Obviously if >draft-initial is now going to be appealed on the basis of my >supposed incompetence, then my contribution is not helping. We have >already seen the progress of draft-registry stalled indefinitely by >one appeal. There should be no doubt that this contributor will >follow through on his threat to file another appeal -- anything to >prevent the LTRU documents from moving forward. Yes. Unfortunately the Internet standard process does not permit to prevent societally harming projects to develop or to be corrected before they are published. But it offers ways to block their application. I know it is poor for those who worked on them. It is also poor for me. But this is the way it is. I have been very loyal all the way through. Documenting what I will do and why. And proposing solutions towards a consensus (and making many things change to protect users in case it would go though). Today I propose a structural solution to avoid such a waste of time in the future: to revive appropriately the ISTF and the ISSG. I am sure that your dedication would have listen to a position of the ISSG regarding the Charter. This would have lead you to consider it more carefully and to discuss its implications. Had we done that I suppose RFC 3066 bis would be published for a long. But today we are to discuss filtering. Ane we can certainly do it in a way which would contribute to network permanent stability. >This has been a very difficult project for me personally, all >because of one person. Same for me, and all because of one person and his allies. This is the reality of the life, welcome to the stanardisation world. But this should not prevent us to continue working on the filtering issue, which is partly orthogonal to all that. >I did not get involved so that I could be accused of trampling on >the needs and desires of users, or giving big powerful corporations >hegemony over the Internet, or ng "Govs" angry, or violatimaking >human rights, or causing people to "suffer and die" (an actual >quote). I deeply resent having been accused of these things >continually over the past year. Did you ever consider that I might be right. All the non-WG-ltru people I know I informed of the RFC 3066 bis consider it as a declaration of war on cultures (what is interesting is that I do not need to propose them the idea). Do you think there are so many angry lunatics. Did you even tried to understand what the Peace Nobel Price I quoted said about physical internal and external conflicts resulting from that globalization RFC 1766, 3066 and 3066 bis are the conceptual technical basis? >I was under the impression that RFC 3934 and RFC 3683 existed so >that WG business could be conducted on mailing lists just as it >would be face-to-face, in an orderly manner, with reasonable dissent >but without being beaten over the head by a lone angry protester. I am not angry. I am sad. I am not alone: I only chose to be alone in here. I wanted to avoid the WG to be a battle field leading to no where: it would not have exposed the fundamental differences of doctrine between Harald, and the Members of its affinity group, and me. This was important to appeals within and outside the IETF and to the response to their joint industrial endeavour. I am sure that even if you are not commercial, not the entire industrial world is a member of our non-profit consortium. >As it turns out, either the process does not work or there is little >or no desire to make it work in this case. I have been told to sit >quietly and take it, and admonished for responding; in short, I am >getting no support on this. > >On top of this, my involvement is now poised to trigger an appeal on >grounds of incompetence. This is both detrimental to the project >and personally embarrassing. Think about my own embarassment at being PR-actioned by a _childish_ document! If we both want to get good documents at the end of the day, on filtering - this is what we should discuss - these kinds of things are common in standardisation. We all saw far worse :-) Do you realise the amount of money at stake? >I don't know if there is any process or precedent for transferring >the editorship of a document already in IESG Last Call, but I am now >asking Randy and Martin to investigate this for >draft-ietf-ltru-initial. I mentioned this possible course of action >in private e-mails yesterday and have received no response at all, >which perhaps is telling in its own way. > >I request a timely response from the co-chairs, and from the AD if >appropriate. Doug, I understand your worry. But an appeal against draft-ietf-ltru-initial can only be on the ground that you made an outstanding job. If you had done a poor job, IESG could claim the problem originated in you, but the concept was good. Here the appeal will be on the ground that in spite of having been carried in the best way, by the most motivated person, with the best WG-ltru support, etc. the WG-ltru debate has shown the IETF has not the capacity, nor the intent (cf. Harald Alvestrand's today mail on his mailing list) to competently debate and responsibly support along with the RFC 3935 standards, the intended RFC 3066 bis documented registry without some missing modification, reducing the need of competence and responsibility to a level acceptable by the IETF. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 20:42:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIV6-0008Cp-Lt; Mon, 07 Nov 2005 20:42:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIV4-0008Ck-RD for ltru@megatron.ietf.org; Mon, 07 Nov 2005 20:42:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29795 for ; Mon, 7 Nov 2005 20:41:48 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZIkk-0001af-4L for ltru@ietf.org; Mon, 07 Nov 2005 20:58:29 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45D8D2596AF; Tue, 8 Nov 2005 02:41:14 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24175-04; Tue, 8 Nov 2005 02:41:10 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5089258093; Tue, 8 Nov 2005 02:41:08 +0100 (CET) Date: Mon, 07 Nov 2005 17:41:54 -0800 From: Harald Tveit Alvestrand To: Ned Freed , Doug Ewell Subject: Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...)) Message-ID: <8DFDC48FB2328FA1E4EE38F7@[10.21.144.74]> In-Reply-To: <01LV4HT6RCC6000092@mauve.mrochek.com> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> <01LV4HT6RCC6000092@mauve.mrochek.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============1312762863==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1312762863== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========07DB6BD5192741F9EFFD==========" --==========07DB6BD5192741F9EFFD========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At the moment, I am in the IETF meeting in Vancouver. I'm told that the IESG still hasn't made a determination on my request that = they consider an RFC 3934 action against Jefsey, among other things because = it's not readily apparent to someone reading individual messages out of=20 context just how disruptive this individual has been to the process. >From my personal knowledge of these people, there is a strong desire to=20 make the process work, but also a strong desire to treat individuals=20 fairly, and a strong tendency - too strong, in my opinion - to err on the=20 side of permitting people to express themselves. Those of you who are in Vancouver might want to give your opinions to IESG=20 people you work with on this issue. Harald --On 7. november 2005 16:42 -0800 Ned Freed wrote: >> I was under the impression that RFC 3934 and RFC >> 3683 existed so that WG business could be conducted on mailing lists >> just as it would be face-to-face, in an orderly manner, with reasonable >> dissent but without being beaten over the head by a lone angry >> protester. > > Guess you haven't attended an IETF in person, then ;-) Shouting matches > aren't > exactly unknown. I can even recall one occasion where I thought a = physical > attack was imminent. > > I wish I could say that this sort of thing was unique to the IETF, but > i've > been involved in other standards processes and they can get rough as = well. > > Some of this is necessary - the crucible of informed debate may not be a > comfortable place to be - but experience has shown that having it does > significantly improve the resulting specifications. > > But there is a limit past which things devolve into personal attacks, > delaying > tactics, and other sorts of pernicious nonsense. IMO we reached, and > passed, > that point some time back. > >> As it turns out, either the process does not work or there >> is little or no desire to make it work in this case. I have been told >> to sit quietly and take it, and admonished for responding; in short, I >> am getting no support on this. > > Well, I for one support you in this. I think Harald at a minimum does = too, > although I hasten to add that I don't speak for him. --==========07DB6BD5192741F9EFFD========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDcAJiOMj+2+WY0F4RAqTBAKD39F5RObe6qIFwIWBYafuKkr8ARgCgi8GV cpcBSpKkX6Rh19YQPlDGroo= =vjNe -----END PGP SIGNATURE----- --==========07DB6BD5192741F9EFFD==========-- --===============1312762863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1312762863==-- From ltru-bounces@ietf.org Mon Nov 07 20:47:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIaK-0000Un-0G; Mon, 07 Nov 2005 20:47:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIaJ-0000Ug-0t for ltru@megatron.ietf.org; Mon, 07 Nov 2005 20:47:39 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00068 for ; Mon, 7 Nov 2005 20:47:11 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZIYt-0001QH-Go for ltru@lists.ietf.org; Tue, 08 Nov 2005 02:46:11 +0100 Received: from c-134-88-29.hh.dial.de.ignite.net ([62.134.88.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 02:46:11 +0100 Received: from nobody by c-134-88-29.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 02:46:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 08 Nov 2005 02:40:31 +0100 Organization: Lines: 36 Message-ID: <4370020F.3B92@xyzzy.claranet.de> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@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: c-134-88-29.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Procedural issues (was: ISO 3166 alpha-2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > We have already seen the progress of draft-registry stalled > indefinitely by one appeal. It's not "stalled indefinitely", and the appeal doesn't pass any giggle test. Just another brick in the 368^Wwall. In theory Scott could have approved draft-registry, the RfC editor note is not that important, the authors could as well fix the simple typo in AUTH48. With this note there's no chance to forget this, that's all, a safeguard. Putting the approval on hold is just another safeguard, because _in theory_ it would be more work to change it after it's sent than before. In practice that's all complete nonsense, we all know that it's a simple typo. We also all know that ccTLD vs. 3166-1 was discussed here and before, incl. but not not limited to UK vs. GB. So if one person claims that this was never discussed, then this person is a liar. It's also a lie when this person claims that the typo was an intentional feature. > I mentioned this possible course of action in private e-mails > yesterday and have received no response at all Folks are in Vancouver and busy, the 64th IETF meeting started yesterday. Everything's fine with your text, so don't let one [censored] make you give it away. You can and should be proud to be the editor and author of this soon-to-be-RfC, Bye, Frank http://mid.gmane.org/435850F6.6E7E@xyzzy.claranet.de http://mid.gmane.org/4358887C.24C8@xyzzy.claranet.de _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 21:03:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIpP-0005d8-3u; Mon, 07 Nov 2005 21:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIpM-0005d3-U5 for ltru@megatron.ietf.org; Mon, 07 Nov 2005 21:03:13 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00927 for ; Mon, 7 Nov 2005 21:02:45 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051108020241.GAVD16334.mta10.adelphia.net@DGBP7M81>; Mon, 7 Nov 2005 21:02:41 -0500 Message-ID: <009501c5e408$7fe802f0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , , "Unicode Mailing List" Date: Mon, 7 Nov 2005 18:02:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] E-mail problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I've just discovered that some e-mail messages sent to me may have been blocked, due to an overzealous configuration of Norton Internet Security installed on my new PC. If you've sent me an e-mail in the past week or so, and you have reason to believe I didn't receive it, please try again. I'm trying to fix the Norton problem. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 07 23:44:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLL8-0004Tv-3J; Mon, 07 Nov 2005 23:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6gN-0006CG-QQ for ltru@megatron.ietf.org; Mon, 07 Nov 2005 08:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08455 for ; Mon, 7 Nov 2005 08:04:41 -0500 (EST) Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ6vy-00033r-U3 for ltru@ietf.org; Mon, 07 Nov 2005 08:21:15 -0500 Received: by rap.rap.dk (Postfix, from userid 500) id C98122C7C2; Mon, 7 Nov 2005 14:04:38 +0100 (CET) Date: Mon, 7 Nov 2005 14:04:37 +0100 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Marion Gunn Message-ID: <20051107130437.GA7165@rap.rap.dk> References: <436F2107.B9B36481@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <436F2107.B9B36481@egt.ie> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Nov 2005 23:44:09 -0500 Cc: ltru@ietf.org, tc46-l@listserv.heanet.ie, ietf-languages@alvestrand.no, unicode@unicode.org Subject: [Ltru] Re: ISO 3166-2 and GA-UK X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Mon, Nov 07, 2005 at 09:40:23AM +0000, Marion Gunn wrote: > Scr=EDobh r&d afrac: > > ... > > The confusion over "GB"/"UK" - for all this time, and still for a > > while - is the same as for langtags... >=20 > Exactly!=20 >=20 > That is why the need that LTRU and IETF members support GA-UK. >=20 > Irish language communities have every right to be angry with langtag > controllers refusing us the same basic rights happily accorded to Saami > communities (who are similarly spread over various dot FI, dot NO, dot > RU and dot SE email/webtags).=20 >=20 > This should be easy - all it requires is goodwill across ISO members > generally towards NSAI's and BSI's communities of Irish speakers.=20 >=20 > Right now (November 2005) langtag controllers oppose this, offering as > their excuse that GA-UK would require ISO 3166-2 to be updtated, but, b= y > the same logic, (with ISO 3166-2 currently being updated right now), > they can support that right now, if they want to. =20 >=20 > It is that simple. In the above, I would especially welcome Harald's su= pport. >=20 > To recap (for non-Europeans), "UK of GB & NI" means exactly that and > nothing more is required than to facilitate (via ISO 3166-2) assigning > GA-UK to serve Irish speakers north of the border in my country, > matching GA-IE south of it. Why dont you use ga-GB for this purpose? GB is the ISO 3166 code for the nation in question, including Northern Ireland. best regards Keld _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 04:43:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQ1E-0005DN-SL; Tue, 08 Nov 2005 04:43:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQ1C-0005D1-Pr for ltru@megatron.ietf.org; Tue, 08 Nov 2005 04:43:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24897 for ; Tue, 8 Nov 2005 04:43:27 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZQGz-0006D0-4q for ltru@ietf.org; Tue, 08 Nov 2005 05:00:13 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZQ1A-0006YE-6Z; Tue, 08 Nov 2005 01:43:52 -0800 Message-Id: <6.2.3.4.2.20051108100758.052bbca0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 08 Nov 2005 10:08:32 +0100 To: Harald Tveit Alvestrand From: r&d afrac Subject: Re: Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...)) In-Reply-To: <8DFDC48FB2328FA1E4EE38F7@[10.21.144.74]> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> <01LV4HT6RCC6000092@mauve.mrochek.com> <8DFDC48FB2328FA1E4EE38F7@[10.21.144.74]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: LTRU Working Group , iesg@iesg.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 02:41 08/11/2005, Harald Tveit Alvestrand wrote: >At the moment, I am in the IETF meeting in Vancouver. > >I'm told that the IESG still hasn't made a determination on my >request that they consider an RFC 3934 action against Jefsey, among >other things because it's not readily apparent to someone reading >individual messages out of context just how disruptive this >individual has been to the process. > > From my personal knowledge of these people, there is a strong > desire to make the process work, but also a strong desire to treat > individuals fairly, and a strong tendency - too strong, in my > opinion - to err on the side of permitting people to express themselves. > >Those of you who are in Vancouver might want to give your opinions >to IESG people you work with on this issue. > > Harald Dear Harald, I suppose that everyone serious will read this mail on the WG-ltru list at the time we discuss ... filtering: - as an ad-hominem - irrelevant to the WG-ltru debate - an attempt to influence the Judges you called upon. - as taking advantage from your employer's money (your presence in Vancouver) to disloyaly fight your competition. I am more seriously interested in the doctrine you document, you engaged the IETF into and I oppose, as it does affect the WG-ltru debate. Your doctrine is to reach network stability though constraint. This is the widely documented theme of RFC 3066 bis.This culture is exemplified here in your rant against "permitting people to express themselves". You want to decide for the users the languages they can use. Is it because they are the languages your organization (you are on the BoD) thinks it can support (Unicode CLDR project directed by the author of the RFC 3066 bis)? Is it because you look for a logical MoU with the IETF to be delegated the IANA registry confirming the ietf-languages@alvestrand.no mailing list's role (some others also look for a IANA control). I accept that this doctrine is well built and consistent. I am impressed by the quality of its leading supporters (Mark Davis [IBM, Unicode President, and Director of the CLDR Project], Peter Constable [Microsoft, author of ISO 639-3], Addison Philips [W3C Internationalisation, but not committing the W3C], etc.) But I am not impressed by your architectural and technical doctrine, because I think constraint does not scale (except in tirany). And because it therefore leads to network instability. This doctrine of yours has already lead to the IDNA failure and to the balkanisation of the DNS. The rigidity of this doctrine will lead to the split 80/20 of the Internet - it is certainly at the core of the WSIS debate and it practically roots in the core of the Internet culture (through languages) that "global" is unilateral. What leads many to consider it is a "war on cultures". IESG is to decide in a complex political context. But you carefully chosed the dates. I think the "master" in a network is not the computer, and through the computer, the "expert" who feeds global data into it, but the people. I think the people are entitled to "err to express themselves", this is even named "market judgment" and "Liberty". My understanding of "global" is multilateral (it happens that we are a few billions thinking that way). For some few years since Adam, man has shown that "erring" this way permitted him to do a few things. Constraining languages and cultures, putting pressure on the IESG, fighting people's liberty, PR-actioning your open use competition with childish accusations (let imagine the IESG confronted to an appeal of mine against the pertinence of your text :-)), considering the Internet as does a national Communications Code vs. the traditional adhesion to the Internet documents, etc. all this certainly belongs to a consistent architectural approach. I have no objection to that, I even accept it as a possible starting point, a default, a necessary begining (like parents take decisions for their kids: but now the Internet is grown-up, we are to organize transition. This is the proposition I do to save RFC 3066 bis from legal debacle and endless appeals and legal actions). This consistent architectural approach of yours has a name: centralised networking. I am sorry, but this is not the distributed network culture of an Internet for the people by the people I have for 30 years this year. At my age one does not change.... Our difference is that you want to exclude me to exclude my technical position, while I am proposing to include yours in mine and mine in yours. Now, I suggest that you stay on topic for your next WG-ltru posts. I listed yesterday the four areas the currently discussed document should address as a real IETF document (not as a support of your pet project) or comment in security or in societal considerations: it only discusses one right now. There is work ahead. I do not think your kind of disruption and your personal rants are productive: we oppose on a fondamental point. OK, either we live with it, or we try to take advantage from it to best document the IETF community. Your position represents a significant part of current solution providers dominance, mine represents the progresses of a significant part of their competition, of their service providers challengers and of the world R&D, your affinity group rejected through the opposition to a declared intent of conformance to ISO 11179. You have decided through your PR-action to identify me as your opponent. I am not against it as I am interested in IETF deliverables user QA in the multilingual/multicultural area. But please use technical arguments against my technical arguments: I am sure you have some if you search well - this area is still under R&D. Otherwise you will not be taken seriously what, IMHO, you certainly do not desserve. I oppose you, but to the countrary of you, I respect you. Have a good meeting, enjoy Vancouver. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 04:44:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQ1N-0005Iw-4Z; Tue, 08 Nov 2005 04:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQ1J-0005HC-IH for ltru@megatron.ietf.org; Tue, 08 Nov 2005 04:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24914 for ; Tue, 8 Nov 2005 04:43:34 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZQH6-0006DL-DP for ltru@ietf.org; Tue, 08 Nov 2005 05:00:20 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZQ1F-0006YE-Cb; Tue, 08 Nov 2005 01:43:57 -0800 Message-Id: <6.2.3.4.2.20051108103539.0552a630@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 08 Nov 2005 10:36:52 +0100 To: randy_presuhn@mindspring.com, duerst@w3c.org From: r&d afrac Subject: Re: Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...)) In-Reply-To: <8DFDC48FB2328FA1E4EE38F7@[10.21.144.74]> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> <01LV4HT6RCC6000092@mauve.mrochek.com> <8DFDC48FB2328FA1E4EE38F7@[10.21.144.74]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sha@428cobrajet.net, 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Chairs, I must this time ask for a formal warning according to RFC 3934 against this kind of repeated off topic kind of ad hominems. I am not hurt by that mails, but I think this is part of a pressure strategy to barter an approval of RFC 3066 bis (also documented in another list as ready to be implemented by the IANA). I do not think this kind of IETF detrimental practice should be tolerated, all the more from a respected signatoree who engages the weight of his name and reputation. This is a violation of the Internet standard process rights of the opponents. I accept that should there be an ISTF and an ISSG, my opposition would have been expressed and addressed a long ago. The present Internet standard process puts societal and architectural appeals at the end of the process, instead of at the begining through a review and an obligation to consider and respect the WG Charter. This certainly leads to more politicking than we should have. But this is not my choice. I have for months clearly described how I will use the rights of the users, through appeals inside and outside the IETF. At 02:41 08/11/2005, Harald Tveit Alvestrand wrote: >At the moment, I am in the IETF meeting in Vancouver. > >I'm told that the IESG still hasn't made a determination on my >request that they consider an RFC 3934 action against Jefsey, among >other things because it's not readily apparent to someone reading >individual messages out of context just how disruptive this >individual has been to the process. > > From my personal knowledge of these people, there is a strong > desire to make the process work, but also a strong desire to treat > individuals fairly, and a strong tendency - too strong, in my > opinion - to err on the side of permitting people to express themselves. > >Those of you who are in Vancouver might want to give your opinions >to IESG people you work with on this issue. > > Harald Sincerely yours. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 12:35:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXNP-0007GM-R8; Tue, 08 Nov 2005 12:35:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXNO-0007GH-Rj for ltru@megatron.ietf.org; Tue, 08 Nov 2005 12:35:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19427 for ; Tue, 8 Nov 2005 12:34:52 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZXdE-00020k-Kf for ltru@ietf.org; Tue, 08 Nov 2005 12:51:42 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA8HZ3KF022284 for ; Tue, 8 Nov 2005 12:35:04 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA8HZ3Pp017500 for ; Tue, 8 Nov 2005 12:35:03 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA8HZ3KT016023 for ; Tue, 8 Nov 2005 12:35:03 -0500 Received: from [127.0.0.1] (sig-9-48-117-158.mts.ibm.com [9.48.117.158]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jA8HZ2sq015811; Tue, 8 Nov 2005 12:35:03 -0500 Message-ID: <4370E1C3.6050300@icu-project.org> Date: Tue, 08 Nov 2005 09:34:59 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> In-Reply-To: <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > I don't know if there is any process or precedent for transferring the > editorship of a document already in IESG Last Call, but I am now > asking Randy and Martin to investigate this for > draft-ietf-ltru-initial. I mentioned this possible course of action > in private e-mails yesterday and have received no response at all, > which perhaps is telling in its own way. For certain people, I found early on that it was not worth reading any of their rantings; there is a difference between honest disagreement and this kind of pernicious misreadings and wild, out-of-scope assertions. They'll look for any pretext to try to derail progress, but that will be the case no matter whether you reply to them or not. So best to just filter them out; or if you want to be on record as in opposition, do so to the effect that "the message is so filled with inaccuracies that it is not worth replying to in detail", since it just isn't worth your time to bother with them. Of course, in a better world, there would be a good, responsive mechanism for excluding such people from disrupting real work, but the IETF gears turn, as we have seen, astonishingly slowly. You have been doing a fine job as editor, and wouldn't want to see you driven away by this situation. Mark > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 20:20:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZecS-0005ju-Ib; Tue, 08 Nov 2005 20:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZecQ-0005jo-T3 for ltru@megatron.ietf.org; Tue, 08 Nov 2005 20:19:19 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01055 for ; Tue, 8 Nov 2005 20:18:51 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZeab-00066s-BP for ltru@lists.ietf.org; Wed, 09 Nov 2005 02:17:25 +0100 Received: from pd9fba8e9.dip0.t-ipconnect.de ([217.251.168.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Nov 2005 02:17:25 +0100 Received: from nobody by pd9fba8e9.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Nov 2005 02:17:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 09 Nov 2005 02:10:50 +0100 Organization: Lines: 9 Message-ID: <43714C9A.A67@xyzzy.claranet.de> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> <4370E1C3.6050300@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8e9.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Procedural issues (was: ISO 3166 alpha-2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > IETF gears turn, as we have seen, astonishingly slowly. One scenario to accelerate it would constitute a conflict of interests, another scenario would involve the AD of the general area, and that's the Chair. IOU 0,02 =80 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 20:22:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZefW-0006ah-BI; Tue, 08 Nov 2005 20:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZAQk-0004Jf-MG for ltru@megatron.ietf.org; Mon, 07 Nov 2005 12:05:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22559 for ; Mon, 7 Nov 2005 12:04:49 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZAgO-0001QX-Ny for ltru@ietf.org; Mon, 07 Nov 2005 12:21:25 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZAQX-0001zo-M4; Mon, 07 Nov 2005 09:05:02 -0800 Message-Id: <6.2.3.4.2.20051107165543.047622c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 07 Nov 2005 18:04:37 +0100 To: Jon Hanna , r&d afrac From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] ISO 3166-2 and GA-UK In-Reply-To: <436F6C81.7030402@hackcraft.net> References: <436F2107.B9B36481@egt.ie> <6.2.3.4.2.20051107133407.04c6f190@mail.afrac.org> <436F6C81.7030402@hackcraft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Tue, 08 Nov 2005 20:22:29 -0500 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 16:02 07/11/2005, Jon Hanna wrote: >r&d afrac wrote: >>NI is deprived from a RFC 3066 bis territory. As a part of >>Anglo/Irish agreements, why not to propose an "all Irish" TLD in >>forming a consortium for ".gle" and asking ICANN to enter it into the root. > >NI is Nicaragua. John, I suggest you keep in line with the technical aspect of this thread. >There already is an all-Irish TLD, which is not that amazing since >ccTLDs and sovereign states are not one and the same. Border >disputes tend not to be quite as exciting for one thing, .tp not withstanding. I am afraid you confuse ccTLDs and specialised language TLDs. I know this is a confusion where RFC 3066 leads to. But I would be interested you indicate the label of that existing "all-Irish TLD", so I may clarify this for you. The TLD I suggest is "all-Irish" (language) not "all-Ireland". If I suggest it, it is in relation to the Anglo/Irish agreement Nov. 15th, 1985 Art.10 (b) "the Conference shall be a framework for the promotion of co-operation between the two parts of Ireland concerning cross border aspects of economic, social and cultural matters". This is very similar to the situation for the Catalan language ICANN accepted. I am not interested in the political aspect. But for years the UK/GB issue is used everywhere as an example to illustrate the complexity of the ISO 3166 usage in relation to the Internet. It permits to show the confusion between and by users, governments, experts. I fully understand that this may irritate the people who are directly concerned. But it is far easier to stay aside of the political aspects in a case we all know about (even imperfectly) than in a new case like the _former_ ".tp" case you quote (even if ".tp" was managed on Mark Street, in Dublin). In addition ".tl" is a legitimate ISO 3166 change which is different from the GB/UK case. Possibly you could quote the ".su" case, but there is no claim of the same territory. Marion's, your or my confusion whatever they may be, show that the situation we reached is unclear. The purpose of the document we discuss is to make such a situation clear to an automated process. I think we are far from that and we either have to work more on it, or to describe it in security/societal considerations. In illustrating the ".cat" case Doug confused, this point also shows a new filtering problem. IMHO most of the people will consider that ".cat" pages will be "cat-latn" by default. This case has not been considered. This makes a few points to consider for Randy's tracking system. >That this thread has managed to reach such new depths is amazing though. Yes. This is the natural consequence of linking partly orthogonal matters such as geography and governments, and to document local usages through global "decisions" (I quote the RFC 1766 and RFC 3066). . I understand that the target is an easier filtering and CLDR correspondency. The examples above show this is not always acceptable or possible, and that the filtering/correspondency proposed mechanism may be inadequate to such situations. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 20:58:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfEV-0002io-PK; Tue, 08 Nov 2005 20:58:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfEV-0002gq-1T for ltru@megatron.ietf.org; Tue, 08 Nov 2005 20:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03066 for ; Tue, 8 Nov 2005 20:58:11 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfUQ-0003mG-1H for ltru@ietf.org; Tue, 08 Nov 2005 21:15:06 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZfEL-0006uF-8y; Tue, 08 Nov 2005 17:58:29 -0800 Message-Id: <6.2.3.4.2.20051108230531.04c3b710@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 09 Nov 2005 02:58:01 +0100 To: Mark Davis From: r&d afrac Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) In-Reply-To: <4370E1C3.6050300@icu-project.org> References: <20051107151634.LQTG14498.edge5.adelphia.net@megatron.ietf.org> <007f01c5e3e5$f6713f40$050aa8c0@DGBP7M81> <4370E1C3.6050300@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 18:34 08/11/2005, Mark Davis wrote: >>I don't know if there is any process or precedent for transferring >>the editorship of a document already in IESG Last Call, but I am >>now asking Randy and Martin to investigate this for >>draft-ietf-ltru-initial. I mentioned this possible course of >>action in private e-mails yesterday and have received no response >>at all, which perhaps is telling in its own way. > >For certain people, I found early on that it was not worth reading >any of their rantings; Dear Mark, I feel really sorry that you resort to this kind of off topic rant/trick to avoid documenting the exclusive convergence of RFC 3066 bis and of your own CLDR project and the way it helps the filtering issue this WG deals with (your own document we should currently discuss). - CLDR is explicitly mentioned to the WG-ltru Charter, so I do not see your problem? Even if we never analysed the Charter yet. I want (as I suppose every other member) to be sure its particular filtering adequation to RFC 3066 bis was worth the exclusion of the other SSDO solutions, of ISO 11179 conformance, of RFC 4151 ABNF, etc. and of the other better schemes Addison documented he might propose. - I wish also to be sure we are not going to indirectly introduce proprietary solutions/patents into the core of "globalized" Linux via this CLDR/LDML (we should then use Asianux?). I must say that I am worried because you do not answer my request for a formal warranty that the CLDR project will permanently and totally stay open use. And no obligation whatsoever to Unicode or/and to Unicode member will be borne from using CLDR locale files in relation with RFC 3066 bis. I must say I have difficulty understanding why the relation and waiver implied by the WG-ltru Charter, is no part of the proposed draft, as the copyright wording for the UN and ISO tables was not added to the registry. I like the legal things to be carried in a legal way. There are countries where the carelessness may be acceptable, there are others where it is not. I am in particular concerned be the following Unicode wording not being adapted to the IETF legal wording. - Any person is hereby authorized, without fee, to view, use, reproduce, and distribute all documents and files solely for informational purposes in the creation of products supporting the Unicode Standard, subject to the Terms and Conditions herein. (question: what about other usages?) - Further specifications of rights and restrictions pertaining to the use of the particular set of data files known as the "Unicode Character Database" can be found in Exhibit 1. (question: this exhibit does not seem to cover RFC 3066 bis/CLDR joint usage, however mentioned in the WG-ltru Charter) Each version of the Unicode Standard has further specifications of rights and restrictions of use. For the book editions, these are found on the back of the title page. For the online edition, certain files (such as the PDF files for book chapters and code charts) carry specific restrictions. All other files are covered under these general Terms of Use. To request a permission to reproduce any part of the Unicode Standard, please contact the Unicode Consortium. (question: would it not be better once for all to provide the necessary permission to IETF and Internet users, as an appendix of RFC 3066 bis?) >there is a difference between honest disagreement and this kind of >pernicious misreadings and wild, out-of-scope assertions. This "wild, out-of-scope" assertions, are (?) - while we discuss their implication in the filtering document: - either a requested clarification over a plainly new reading of the "GB" ISO 3166 by the author of the proposed registry. - or the relation between RFC 3066 bis and CLDR ... which is part of the Charter (however the Charter does not introduce exclusive). I note that this exclusive again others, therefore against my own organization work, is our _only_ point of contention. An honest statement of yours as a President of Unicode affirming an open use of the CLDR and locale introduced data; and as an author of the Draft of a non ABNF exclusion of RFC 4151, ISO 11179, other SSDOs would immediately clarify that contention. >They'll look for any pretext to try to derail progress, but that >will be the case no matter whether you reply to them or not. So best >to just filter them out; or if you want to be on record as in >opposition, do so to the effect that "the message is so filled with >inaccuracies that it is not worth replying to in detail", since it >just isn't worth your time to bother with them. "derail progress" is an odd term to qualify Internet standard process appeal rights against a terminal option for the IETF. This pratice of yours will be helpfull to IESG, IAB or others to understand why you were unable to respond my repeated consensual harmonisation propositions. >Of course, in a better world, there would be a good, responsive >mechanism for excluding such people from disrupting real work, but >the IETF gears turn, as we have seen, astonishingly slowly. Such a statement is your responsibility. You are at liberty to propose, as I suggested some, changes in the Internet standard process to avoid such situations due to a lack of consideration of societal, cultural and human prerequisites and the priority of common good over commercial interests and personal technical/political opinions or pride. >You have been doing a fine job as editor, and wouldn't want to see >you driven away by this situation. This has been expressed by everyone. But this does not change that Doug has duties to this WG debate. It would really help, if you stayed on topic. jfc morfin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 21:18:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfXp-0000Vc-AE; Tue, 08 Nov 2005 21:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfXo-0000Ut-KA for ltru@megatron.ietf.org; Tue, 08 Nov 2005 21:18:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04082 for ; Tue, 8 Nov 2005 21:18:09 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfnj-0004EY-89 for ltru@ietf.org; Tue, 08 Nov 2005 21:35:04 -0500 Received: from dul1shollenbl1 ([::ffff:209.52.111.221]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 08 Nov 2005 21:18:19 -0500 id 01588071.43715C6D.000058EC From: "Scott Hollenbeck" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) Date: Tue, 8 Nov 2005 21:18:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.3.4.2.20051108230531.04c3b710@mail.afrac.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: High Thread-Index: AcXk0TGEj+M5tUboQzCY6OTG0767nAAANYdA Message-ID: X-Spam-Score: 1.0 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org (Speaking as LTRU Area Advisor) Folks, one of your WG chairs has said [1] that discussion of this topic is not helping the working group complete its final milestone. It is time to stop. People who have been warned either privately or publicly about off-topic posting are reminded that there may be consequences for ignoring those warnings. -Scott- [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg04000.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 22:05:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgHA-0001W8-0q; Tue, 08 Nov 2005 22:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZg08-0002p2-Vj for ltru@megatron.ietf.org; Tue, 08 Nov 2005 21:47:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06412 for ; Tue, 8 Nov 2005 21:47:25 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgG3-00059Z-Qz for ltru@ietf.org; Tue, 08 Nov 2005 22:04:21 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EZg06-0004Lm-K2 for ltru@ietf.org; Tue, 08 Nov 2005 18:47:51 -0800 Message-Id: <6.2.3.4.2.20051109033225.04df6170@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 09 Nov 2005 03:47:37 +0100 To: "LTRU Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 08 Nov 2005 22:05:27 -0500 Subject: [Ltru] Filtering coverture pending topics X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Scott, full agreement: it would be good if we could concentrate on WG-ltru topics. This is a short list of basic concerns I have expressed concerning the filtering issues. The reason why a langtag is not the expected one and may call for filtering: - user does not know the language - the machine does not support the language - the locale must adapt, - the construct of the locale is then of importance (not the same constraints/possibility as a user) - study of LDML might help? the Charter relation RFC 3066 bis/CLDR applies: - what is special about it? - why does it prevent other solutions (RFC 4151, ISO 11179, open to other SSDOs) - we do not know the IPRs of CLDR/LDML. We need to be sure it will be a stable proposition before committing to it. - there is a concept error in RFC 3066 bis: - it lead to another langtag - for example RFC 4151 conformant - the used langtag has been refused by the IANA advisers. - there is a new metastructural issue, due to a lingual TLD. These points must be addressed either specifically (my proposition) or in security or usage considerations (probable fall back of the author from my acquired experience). jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 08 22:33:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgie-0002RI-D0; Tue, 08 Nov 2005 22:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgic-0002R3-9o for ltru@megatron.ietf.org; Tue, 08 Nov 2005 22:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08390 for ; Tue, 8 Nov 2005 22:33:22 -0500 (EST) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgyX-00068t-Cm for ltru@ietf.org; Tue, 08 Nov 2005 22:50:18 -0500 Received: from h-68-166-189-65.snvacaid.dynamic.covad.net ([68.166.189.65] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EZgiV-0003Yt-00 for ltru@ietf.org; Tue, 08 Nov 2005 22:33:43 -0500 Message-ID: <01ac01c5e4de$f9a8f780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 8 Nov 2005 19:37:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Ltru] RFC 3934 Morfin suspension X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - Recent postings by Jefsey Morphin exhibit a pattern of disruptive behaviour, including the use of inflammatory language and substantial off-topic content. Examples include the following: http://www1.ietf.org/mail-archive/web/ltru/current/msg03998.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04003.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04018.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04019.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04024.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04025.html Since Jefsey has been previously warned publicly http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html as well as privately, in the interest of allowing the working group to complete its remaining work, the matching draft, I am suspending his posting privileges to the ltru working group mailing list for a period of 30 days, under the terms of RFC 3934 section 2. The suspension will expire on Thursday, December 8, 2005. If he so chooses, he may appeal this decision to our Area Director, Scott Hollenbeck. Randy Presuhn, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 09 01:18:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZjHl-0001sa-Kv; Wed, 09 Nov 2005 01:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZjHj-0001sL-Ml for ltru@megatron.ietf.org; Wed, 09 Nov 2005 01:18:16 -0500 Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15908 for ; Wed, 9 Nov 2005 01:17:48 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051109061734.PVJZ19306.mta11.adelphia.net@DGBP7M81>; Wed, 9 Nov 2005 01:17:34 -0500 Message-ID: <006601c5e4f5$45af8b60$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , , "Unicode Mailing List" Date: Tue, 8 Nov 2005 22:17:32 -0800 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] [OT] Re: E-mail problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I figured out my e-mail problem. It was my fault, not Norton's. I had configured OE to mark my messages as having come from adelphia.com, instead of adelphia.net, so anyone who hit the Reply button sent their reply to a bogus address. Please do not send mail to dewell@adelphia.com. I don't work there, I just pay them for Internet service. -- Doug Ewell Fullerton, California, USA dewell@adelphia.net http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 09 18:47:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzfK-0006gq-K1; Wed, 09 Nov 2005 18:47:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzfI-0006fm-Lh for ltru@megatron.ietf.org; Wed, 09 Nov 2005 18:47:40 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18692 for ; Wed, 9 Nov 2005 18:47:13 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051109234658.GMDI23334.mta13.adelphia.net@DGBP7M81> for ; Wed, 9 Nov 2005 18:46:58 -0500 Message-ID: <000b01c5e587$e0053330$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 9 Nov 2005 15:46:58 -0800 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching draft? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org For the record, I have no objections to the matching draft as it currently stands. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 09 19:00:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzrg-0003fD-8r; Wed, 09 Nov 2005 19:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzrf-0003bt-2a for ltru@megatron.ietf.org; Wed, 09 Nov 2005 19:00:27 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19355 for ; Wed, 9 Nov 2005 18:59:59 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051109235955.PPDL16334.mta10.adelphia.net@DGBP7M81>; Wed, 9 Nov 2005 18:59:55 -0500 Message-ID: <000f01c5e589$add5d700$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , Date: Wed, 9 Nov 2005 15:59:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA19355 Cc: Subject: [Ltru] New 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org In addition to "gsw" for Swiss German, two other new code elements have=20 just been added to ISO 639-2: "anp" for Angika "frr" for Northern Frisian It has been proposed that "gsw" and presumably these other two should be=20 registered after the publication of draft-initial, through the normal=20 ietf-languages channel, rather than added to the draft. I have no=20 objection to this. The three records that would need to be added are as follows: Type: language Subtag: anp Description: Angika Added: 2005-11-08 %% Type: language Subtag: frr Description: Northern Frisian Added: 2005-11-08 %% Type: language Subtag: gsw Description: Swiss German Description: Alemanic Added: 2005-11-04 The "Added" dates are for illustration; they reflect the date these=20 items were added to ISO 639. In reality, they would be probably=20 assigned an "Added" date equal to the date they were registered through=20 ietf-languages. Note that the description of "gsw" was taken verbatim from ISO 639, and=20 does not include the name "Schwyzerd=C3=BCtsch" for that reason. ISO/DIS= =20 639-3 does use this name. Note also that "frr" does not currently exist=20 in ISO/DIS 639-3, although it does not conflict with it. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 10 02:01:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea6RD-0005xX-CG; Thu, 10 Nov 2005 02:01:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea6RC-0005xG-I4 for ltru@megatron.ietf.org; Thu, 10 Nov 2005 02:01:34 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12283 for ; Thu, 10 Nov 2005 02:00:56 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051110065935.VPTN19306.mta11.adelphia.net@DGBP7M81>; Thu, 10 Nov 2005 01:59:35 -0500 Message-ID: <003801c5e5c4$4d026340$050aa8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <000f01c5e589$add5d700$050aa8c0@DGBP7M81> <20051110041929.GB3128@NYCMJCOWA2> Date: Wed, 9 Nov 2005 22:59:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Frisian problems (was: New 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org (adding LTRU back to the list because of RFC 3066bis registry philosophy questions) John Cowan wrote: >> Note also that "frr" does not currently exist >> in ISO/DIS 639-3, although it does not conflict with it. > > Where do you get this from? Both the Ethnologue and the ISO 639-3 > site show 'frr' as the code for Northern Frisian. You're right, I screwed up. Actually a bit of explaining is in order. As some may know, I have already gone ahead and mocked up a possible registry for the anticipated future "RFC 3066ter" era, in which each ISO 639-3 code element would be utilized as either (a) a primary language subtag or (b) an extended language ("extlang") subtag, depending on whether it (b) is or (a) is not covered under a macrolanguage code element. I hope this work will end up being of some use to whoever is involved in the RFC 3066ter effort. (I am not making it available at present, so please don't ask for it.) In checking whether the new ISO 639-2 code element "frr" existed in ISO 639-3, I actually cheated and looked in the RFC 3066ter registry mockup instead. I did not find a primary language subtag "frr", but had I looked a little deeper I would have found "frr" as an extlang subtag. That is because, as John points out, "frr" (Northern Frisian) is actually a member of the ISO 639-3 macrolanguage "fry" (Frisian). This raises an interesting question. If "frr" is, in fact, going to be an extlang subtag under RFC 3066ter, then it probably doesn't make sense to add it as a primary language subtag under RFC 3066bis. After all, there is no provision for reclassifying a subtag from primary language to extlang. I would have to recheck this, but I don't believe there is another ISO 639-2 code element that is covered under a macrolanguage in 639-3. So if "anp" and "gsw" are to be added to the RFC 3066bis registry through the registration process, maybe it would be best NOT to add "frr", but rather to wait until the role of that code element in the RFC 3066ter framework is agreed upon. > In looking this up, I spotted two serious problems with Frisian... I have nothing to add to John's very lucid explanation of these issues. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 10 03:09:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea7Um-0007nl-7t; Thu, 10 Nov 2005 03:09:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea7Ug-0007gL-DJ for ltru@megatron.ietf.org; Thu, 10 Nov 2005 03:09:17 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15418 for ; Thu, 10 Nov 2005 03:08:45 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ea7TK-0003rt-Av for ltru@lists.ietf.org; Thu, 10 Nov 2005 09:07:50 +0100 Received: from 212.82.251.105 ([212.82.251.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Nov 2005 09:07:50 +0100 Received: from nobody by 212.82.251.105 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Nov 2005 09:07:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 10 Nov 2005 09:05:30 +0100 Organization: Lines: 39 Message-ID: <4372FF4A.76B5@xyzzy.claranet.de> References: <000f01c5e589$add5d700$050aa8c0@DGBP7M81> <20051110041929.GB3128@NYCMJCOWA2> <003801c5e5c4$4d026340$050aa8c0@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.105 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Frisian problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > This raises an interesting question. If "frr" is, in fact, > going to be an extlang subtag under RFC 3066ter, then it > probably doesn't make sense to add it as a primary language > subtag under RFC 3066bis. No, that's IMO backwards. Because frr will be registered as 3066bis language, the fy-frr (or fry-frr ?) extlang combo won't make it in 3066ter. Same situation as today, if an alpha-2 code already exists, a new equivalent alpha-3 code won't be registered. And vice versa, but they promised to never create a new alpha-2 code for an existing alpha-3, so that's only a theoretical case. If for 639-3 there's no such promise / guarantee, then 3066ter can pick one of two approaches: Whatever is registered first is it, forever. Or: if a shorter alpha-3 is registered after an equivalent extlang-combo, then the latter is deprecated. > I don't believe there is another ISO 639-2 code element that > is covered under a macrolanguage in 639-3. Yes, I vaguely recall a statement from Peter (?) here, it's an odd case, it shouldn't happen. But 639-2 is not yet obliged to play by some future rules, and 639-3 has to be updated for its own incarnation of "date B", so maybe that can't happen in any "official" 639-3. > maybe it would be best NOT to add "frr", but rather to wait > until the role of that code element in the RFC 3066ter > framework is agreed upon. No, it's the idea of 3066bis (and later 3066ter) to eliminate such ISO issues. If frr is eligible it should be registered, let 639-3 get it right. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 10 03:30:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea7oo-0006Js-07; Thu, 10 Nov 2005 03:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea7ol-0006JC-CJ for ltru@megatron.ietf.org; Thu, 10 Nov 2005 03:30:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16585 for ; Thu, 10 Nov 2005 03:29:31 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea84v-0002Pe-ML for ltru@ietf.org; Thu, 10 Nov 2005 03:46:42 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id jAA8TiJh005561; Thu, 10 Nov 2005 03:29:45 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 10 Nov 2005 01:29:43 -0700 Date: Thu, 10 Nov 2005 01:29:41 -0700 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] Re: Frisian problems Message-ID: <20051110082941.GE3128@NYCMJCOWA2> References: <000f01c5e589$add5d700$050aa8c0@DGBP7M81> <20051110041929.GB3128@NYCMJCOWA2> <003801c5e5c4$4d026340$050aa8c0@DGBP7M81> <4372FF4A.76B5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4372FF4A.76B5@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > No, that's IMO backwards. Because frr will be registered as > 3066bis language, the fy-frr (or fry-frr ?) extlang combo won't > make it in 3066ter. I agree entirely. Shorter subtags beat longer ones. (It would be 'fy-frr', FWIW.) An alternative is to change DIS 639-3 so that 'fry' is no longer a macrolanguage but simply the 639-3 code for Western Frisian, which is far and away the most prominent kind of Frisian. In that case, the RFC 3066bis language subtags would be simply =7F 'fy', 'frr', and (in RFC 3066ter) 'stg'. I don't know how much turmoil that would cause with existing data. It may even be that the 639-2/RA assumed that 'fy'/'fry' already meant Western Frisian specifically. --=20 LEAR: Dost thou call me fool, boy? John Cowan FOOL: All thy other titles http://www.ccil.org/~cowan thou hast given away: jcowan@reutershealth.com That thou wast born with. http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 11 04:31:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaVFu-0007o4-Uw; Fri, 11 Nov 2005 04:31:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaVFs-0007nc-L1 for ltru@megatron.ietf.org; Fri, 11 Nov 2005 04:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25888 for ; Fri, 11 Nov 2005 04:30:58 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaVW9-00072i-A7 for ltru@ietf.org; Fri, 11 Nov 2005 04:48:24 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAB9Utu24246 for ; Fri, 11 Nov 2005 18:30:55 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 2d85_dbd39808_5295_11da_9bf5_0030482533a1; Fri, 11 Nov 2005 18:30:55 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAB9U30V030057 for ; Fri, 11 Nov 2005 18:30:28 +0900 Message-Id: <6.0.0.20.2.20051111175415.06b8be70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 11 Nov 2005 18:29:03 +0900 To: "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Filtering coverture pending topics In-Reply-To: <6.2.3.4.2.20051109033225.04df6170@pop.online.fr> References: <6.2.3.4.2.20051109033225.04df6170@pop.online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [co-chair hat on] Due to Randy's mail at http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html, we may not hear from Jefsey again for a while. However, to make progress on the matching draft, we have to deal with the following mail and reach some consensus on it. [co-chair hat off] I think that while some of the points mentioned below are related to filtering, none of them is affecting the matching draft. I'll explain, point for point, but shortly, why I think so. At 11:47 05/11/09, Jefsey Morfin wrote: >Dear Scott, >full agreement: it would be good if we could concentrate on WG-ltru topics. >This is a short list of basic concerns I have expressed concerning the filtering issues. > >The reason why a langtag is not the expected one and may call for filtering: >- user does not know the language Yes, things like language-range can be used that way. This is working in practice, no need to change/add anything. >- the machine does not support the language - the locale must adapt, This is also an usage that is easily possible with the current matching draft. > - the construct of the locale is then of importance (not the same constraints/possibility as a user) Construction of locales is not a topic of this WG. > - study of LDML might help? Again, locale description is not a topic of this WG. > the Charter relation RFC 3066 bis/CLDR applies: > - what is special about it? Nothing, in my view. CLDR isn't mentioned in the context of the WG deliverable, it is mentioned in the context of the current (soon past, I guess) RFC 3066. See http://www.ietf.org/html.charters/ltru-charter.html. > - why does it prevent other solutions (RFC 4151, ISO 11179, open to other SSDOs) Nothing in the drafts of this WG does prevent somebody else to use some other tagging system for identifying languages in the protocols and formats that they design. The main problem with them will be interoperability with the well-establised RFC 1766/3066/3066bis system, but that's up to them to decide. > - we do not know the IPRs of CLDR/LDML. We need to be sure it will be a stable proposition before committing to it. This WG is in no way commiting to CLDR/LDML. This is therefore irrelevant. >- there is a concept error in RFC 3066 bis: > - it lead to another langtag - for example RFC 4151 conformant It is a property of all standards that they in some way limit what's possible in order to make the possible probable and easy to use. This is in general not a concept error. > - the used langtag has been refused by the IANA advisers. This is unrelated to filtering/matching, it is a registration issue. >- there is a new metastructural issue, due to a lingual TLD. I'm not sure how this is related to matching. I guess that in some applications, it might be possible to try to include or exclude some documents based on the assumption that data served from some domains is in some languages. But that assumption will always be very fragile, and is out of the scope of our matching draft. >These points must be addressed either specifically (my proposition) or in security or usage considerations (probable fall back of the author from my acquired experience). If these points had indeed been addressed specifically (in particular, by proposing specific text for the matching draft), that would have been helpful. Also, if the security- related points above were so marked, that too would have been helpful (I have to admit that I didn't find any point that would be relevant to security in the context of our matching draft). Given that these points haven't happened, and based on my technical evaluation above, I propose to close the above issues without any changes to the document. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 11 11:34:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eabqu-0000OT-KR; Fri, 11 Nov 2005 11:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eabqs-0000OO-PG for ltru@megatron.ietf.org; Fri, 11 Nov 2005 11:34:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17340 for ; Fri, 11 Nov 2005 11:33:41 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eac7K-0002tv-TN for ltru@ietf.org; Fri, 11 Nov 2005 11:51:11 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jABGY0jd029579 for ; Fri, 11 Nov 2005 11:34:00 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jABGY0Pu107332 for ; Fri, 11 Nov 2005 11:34:00 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jABGY0WN013862 for ; Fri, 11 Nov 2005 11:34:00 -0500 Received: from [127.0.0.1] (sig-9-48-115-51.mts.ibm.com [9.48.115.51]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jABGXwBl013790; Fri, 11 Nov 2005 11:33:59 -0500 Message-ID: <4374C7F3.5090600@icu-project.org> Date: Fri, 11 Nov 2005 08:33:55 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Filtering coverture pending topics References: <6.2.3.4.2.20051109033225.04df6170@pop.online.fr> <6.0.0.20.2.20051111175415.06b8be70@localhost> In-Reply-To: <6.0.0.20.2.20051111175415.06b8be70@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Given that these points haven't > happened, and based on my technical evaluation above, > I propose to close the above issues without any > changes to the document. Agreed. Martin Duerst wrote: > [co-chair hat on] > > Due to Randy's mail at > http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html, > we may not hear from Jefsey again for a while. However, > to make progress on the matching draft, we have to deal > with the following mail and reach some consensus on it. > > [co-chair hat off] > > I think that while some of the points mentioned below are > related to filtering, none of them is affecting the > matching draft. I'll explain, point for point, but > shortly, why I think so. > > At 11:47 05/11/09, Jefsey Morfin wrote: > >Dear Scott, > >full agreement: it would be good if we could concentrate on WG-ltru > topics. > >This is a short list of basic concerns I have expressed concerning > the filtering issues. > > > >The reason why a langtag is not the expected one and may call for > filtering: > >- user does not know the language > > Yes, things like language-range can be used that way. > This is working in practice, no need to change/add anything. > > >- the machine does not support the language - the locale must adapt, > > This is also an usage that is easily possible with the current > matching draft. > > > - the construct of the locale is then of importance (not the same > constraints/possibility as a user) > > Construction of locales is not a topic of this WG. > > > - study of LDML might help? > > Again, locale description is not a topic of this WG. > > > the Charter relation RFC 3066 bis/CLDR applies: > > - what is special about it? > > Nothing, in my view. CLDR isn't mentioned in the context > of the WG deliverable, it is mentioned in the context of > the current (soon past, I guess) RFC 3066. See > http://www.ietf.org/html.charters/ltru-charter.html. > > > - why does it prevent other solutions (RFC 4151, ISO 11179, open > to other SSDOs) > > Nothing in the drafts of this WG does prevent somebody > else to use some other tagging system for identifying > languages in the protocols and formats that they design. > The main problem with them will be interoperability > with the well-establised RFC 1766/3066/3066bis system, > but that's up to them to decide. > > > - we do not know the IPRs of CLDR/LDML. We need to be sure it will > be a stable proposition before committing to it. > > This WG is in no way commiting to CLDR/LDML. This is > therefore irrelevant. > > >- there is a concept error in RFC 3066 bis: > > - it lead to another langtag - for example RFC 4151 conformant > > It is a property of all standards that they in some > way limit what's possible in order to make the possible > probable and easy to use. This is in general not a > concept error. > > > - the used langtag has been refused by the IANA advisers. > > This is unrelated to filtering/matching, it is a registration > issue. > > >- there is a new metastructural issue, due to a lingual TLD. > > I'm not sure how this is related to matching. I guess that > in some applications, it might be possible to try to include > or exclude some documents based on the assumption that data > served from some domains is in some languages. But that > assumption will always be very fragile, and is out of the > scope of our matching draft. > > >These points must be addressed either specifically (my proposition) > or in security or usage considerations (probable fall back of the > author from my acquired experience). > > If these points had indeed been addressed specifically (in > particular, by proposing specific text for the matching > draft), that would have been helpful. Also, if the security- > related points above were so marked, that too would have > been helpful (I have to admit that I didn't find any > point that would be relevant to security in the context > of our matching draft). Given that these points haven't > happened, and based on my technical evaluation above, > I propose to close the above issues without any > changes to the document. > > > Regards, Martin. > > _______________________________________________ > 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 Nov 11 21:59:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ealbu-0002iB-OZ; Fri, 11 Nov 2005 21:59:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ealbt-0002i6-S2 for ltru@megatron.ietf.org; Fri, 11 Nov 2005 21:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05782 for ; Fri, 11 Nov 2005 21:58:50 -0500 (EST) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EalsN-0007Vv-Cl for ltru@ietf.org; Fri, 11 Nov 2005 22:16:25 -0500 Received: from h-68-165-7-120.snvacaid.dynamic.covad.net ([68.165.7.120] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ealbk-00032F-00 for ltru@ietf.org; Fri, 11 Nov 2005 21:59:12 -0500 Message-ID: <002b01c5e735$ab1fd440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <01ac01c5e4de$f9a8f780$7f1afea9@oemcomputer> Subject: Re: [Ltru] RFC 3934 Morfin suspension Date: Fri, 11 Nov 2005 19:03:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Randy Presuhn" > To: "LTRU Working Group" > Sent: Tuesday, November 08, 2005 7:37 PM > Subject: [Ltru] RFC 3934 Morfin suspension ... > Recent postings by Jefsey Morphin exhibit a pattern of disruptive > behaviour, including the use of inflammatory language and substantial > off-topic content. Examples include the following: ... Jefsey has brought it to my attention that I spelled his last name incorrectly. The correct spelling is, of course, "Morfin", and I apologize for the error. As someone whose own name is frequently mangled, I can sympathize. However, this has no bearing on the suspension itself. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 11 22:00:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaldF-0002zV-Hw; Fri, 11 Nov 2005 22:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaldE-0002zI-PS for ltru@megatron.ietf.org; Fri, 11 Nov 2005 22:00:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05838 for ; Fri, 11 Nov 2005 22:00:15 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ealtj-0007XE-IH for ltru@ietf.org; Fri, 11 Nov 2005 22:17:50 -0500 Received: from dul1shollenbl1 ([::ffff:216.253.196.186]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Fri, 11 Nov 2005 22:00:09 -0500 id 01588060.43755ABA.00002442 From: "Scott Hollenbeck" To: "'LTRU Working Group'" Subject: RE: [Ltru] RFC 3934 Morfin suspension Date: Fri, 11 Nov 2005 22:00:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <01ac01c5e4de$f9a8f780$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcXk3pvwupUD2y8PSSi3VQiMpTttEQCVmjWQ Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Mr. Morfin has appealed Randy's decision to suspend his posting rights. I will review his appeal and provide a decision next week. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 13 07:24:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuW-0006Wd-OP; Sun, 13 Nov 2005 07:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuV-0006Tu-9g for ltru@megatron.ietf.org; Sun, 13 Nov 2005 07:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00394 for ; Sun, 13 Nov 2005 07:24:07 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbHBI-0008Uh-JN for ltru@ietf.org; Sun, 13 Nov 2005 07:42:01 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jADCOGu02389 for ; Sun, 13 Nov 2005 21:24:16 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1a65_6868d5de_5440_11da_93a0_00304811fd80; Sun, 13 Nov 2005 21:24:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jADCNLWQ031046 for ; Sun, 13 Nov 2005 21:23:50 +0900 Message-Id: <6.0.0.20.2.20051113205642.06b9b5d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 13 Nov 2005 21:09:36 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft: terminology: matching and lookup X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I think the current draft still has various terminology problems. Nothing really serious, but better we fix it before we move on. First, there is no clear separation between matching and lookup as concepts by themselves and matching and lookup in the context of basic language ranges. I propose to create a subsection or two in section 1 or in the next section defining matching and lookup independent of a specific range. In my understanding, matching pairs a more general (and thus usually shorter) range with more specific language tags. On the other hand, lookup pairs a longer range against shorter tags. If that's correct, it should be said so, quite at the start. We should also write something about the fact that an application has to chose one or the other because the two won't mix very well. What is currently 2.2.1 and 2.2.2 should then be renamed to Basic Matching and Basic Lookup, so that other specs have clear and easily findable terms. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 13 07:24:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuW-0006XD-Sr; Sun, 13 Nov 2005 07:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuV-0006Tt-9d for ltru@megatron.ietf.org; Sun, 13 Nov 2005 07:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00393 for ; Sun, 13 Nov 2005 07:24:07 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbHBI-0008Uc-JK for ltru@ietf.org; Sun, 13 Nov 2005 07:42:01 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jADCOFu02383 for ; Sun, 13 Nov 2005 21:24:15 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 4c6c_6762a110_5440_11da_89da_0030482533a1; Sun, 13 Nov 2005 21:24:14 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jADCNLWM031046 for ; Sun, 13 Nov 2005 21:23:49 +0900 Message-Id: <6.0.0.20.2.20051113195122.06b745b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 13 Nov 2005 20:56:20 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft: structure X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm currently doing a careful re-read of the matching draft as part of my chair duty. The folling are comments that I'm sending as a technical contributor. This comment is about the structure of the draft. First, all of the 'beef' is in Section 2. I think it would be much better to have that separated into several sections. I'll explain how I think it can be done. Second, I don't understand how "Distance Metric Scheme" got into the section about "Extended Language Range". I think it should be in its own section. So I would split section 2 into three or more sections, one on terminology and basics (see separate mail), one on ranges and matching and lookup algorithms, and one on additional considerations. Other splits are also possible. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 13 07:24:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuX-0006Xp-1d; Sun, 13 Nov 2005 07:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuV-0006U4-A2 for ltru@megatron.ietf.org; Sun, 13 Nov 2005 07:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00398 for ; Sun, 13 Nov 2005 07:24:08 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbHBI-0008Ud-JJ for ltru@ietf.org; Sun, 13 Nov 2005 07:42:02 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jADCOFd23821 for ; Sun, 13 Nov 2005 21:24:15 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1aad_67c9960e_5440_11da_9b49_00304811fd80; Sun, 13 Nov 2005 21:24:15 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jADCNLWO031046 for ; Sun, 13 Nov 2005 21:23:50 +0900 Message-Id: <6.0.0.20.2.20051113210722.06b9ec40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 13 Nov 2005 21:09:07 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft: terminology: application X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The term 'application' shows up many times in the document, but it's not very clear what that means. My understanding is that it means other standards such as HTTP, CSS, and so on, not individual end-user applications on a PC. If this is so, we should make this clear, preferably in an introductory section about terminology. If this is different, we should also make it clear. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 13 07:24:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuX-0006YP-6L; Sun, 13 Nov 2005 07:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGuW-0006VC-6k for ltru@megatron.ietf.org; Sun, 13 Nov 2005 07:24:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00403 for ; Sun, 13 Nov 2005 07:24:09 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbHBK-00005x-49 for ltru@ietf.org; Sun, 13 Nov 2005 07:42:03 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jADCONu02393 for ; Sun, 13 Nov 2005 21:24:23 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1a65_6ca8a28c_5440_11da_93a0_00304811fd80; Sun, 13 Nov 2005 21:24:23 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jADCNWGH031047 for ; Sun, 13 Nov 2005 21:23:58 +0900 Message-Id: <6.0.0.20.2.20051113210954.06b78c60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 13 Nov 2005 21:22:49 +0900 To: LTRU Working Group From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft: Abstract X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The Abstract of the matching draft uses the word 'describe' twice. It should make clearer that the core of the draft is matching and lookup (which may be two forms of comparison), and that language negotiation and content selection are usages thereof. Also, the word 'evaluate' should probably be removed from the Abstract. It only appears once in the rest of the document, not worth to mention it in the abstract. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 13 11:41:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbKvH-0005Eq-SH; Sun, 13 Nov 2005 11:41:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbKvF-0005Dc-34 for ltru@megatron.ietf.org; Sun, 13 Nov 2005 11:41:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17834 for ; Sun, 13 Nov 2005 11:41:08 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbLC3-00016c-5N for ltru@ietf.org; Sun, 13 Nov 2005 11:59:04 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 13 Nov 2005 08:41:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Ltru] Matching draft: Abstract MIME-Version: 1.0 Date: Sun, 13 Nov 2005 08:41:18 -0800 Message-ID: Thread-Topic: [Ltru] Matching draft: Abstract Thread-Index: AcXoTWos+D9hBI+aTdaF7QvnTQzaLwAI0tRA From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 13 Nov 2005 16:41:19.0910 (UTC) FILETIME=[13163C60:01C5E871] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313906422==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1313906422== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVsbG8gTWFydGluLA0KDQpUaGFua3MgZm9yIHRoaXMgY29tbWVudC4NCg0KSGVyZSBpcyB0aGUg Y3VycmVudCB0ZXh0Og0KDQotLQ0KPHQ+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZGlmZmVyZW50 IG1lY2hhbmlzbXMgZm9yIGNvbXBhcmluZywgbWF0Y2hpbmcsIGFuZCBldmFsdWF0aW5nIGxhbmd1 YWdlIHRhZ3MuIFBvc3NpYmxlIGFsZ29yaXRobXMgZm9yIGxhbmd1YWdlIG5lZ290aWF0aW9uIGFu ZCBjb250ZW50IHNlbGVjdGlvbiBhcmUgZGVzY3JpYmVkLjwvdD4NCi0tDQoNCkkgd291bGQgc3Vn Z2VzdCB3ZSByZXdvcmQgaXQgdGh1czoNCg0KLS0NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGRp ZmZlcmVudCBtZWNoYW5pc21zIGZvciBjb21wYXJpbmcgYW5kIG1hdGNoaW5nIGxhbmd1YWdlIHRh Z3MgZm9yIHVzZSBpbiBzZWxlY3Rpbmcgb3IgbmVnb3RpYXRpbmcgY29udGVudCBhY2NvcmRpbmcg dG8gbGFuZ3VhZ2UuDQotLQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFydGluIER1ZXJzdA0KPiBTZW50OiAyMDA1 5bm0MTHmnIgxM+aXpSA0OjIzDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDog W0x0cnVdIE1hdGNoaW5nIGRyYWZ0OiBBYnN0cmFjdA0KPiANCj4gVGhlIEFic3RyYWN0IG9mIHRo ZSBtYXRjaGluZyBkcmFmdCB1c2VzIHRoZSB3b3JkICdkZXNjcmliZScNCj4gdHdpY2UuIEl0IHNo b3VsZCBtYWtlIGNsZWFyZXIgdGhhdCB0aGUgY29yZSBvZiB0aGUgZHJhZnQgaXMNCj4gbWF0Y2hp bmcgYW5kIGxvb2t1cCAod2hpY2ggbWF5IGJlIHR3byBmb3JtcyBvZiBjb21wYXJpc29uKSwNCj4g YW5kIHRoYXQgbGFuZ3VhZ2UgbmVnb3RpYXRpb24gYW5kIGNvbnRlbnQgc2VsZWN0aW9uIGFyZQ0K PiB1c2FnZXMgdGhlcmVvZi4NCj4gDQo+IEFsc28sIHRoZSB3b3JkICdldmFsdWF0ZScgc2hvdWxk IHByb2JhYmx5IGJlIHJlbW92ZWQgZnJvbSB0aGUNCj4gQWJzdHJhY3QuIEl0IG9ubHkgYXBwZWFy cyBvbmNlIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCwNCj4gbm90IHdvcnRoIHRvIG1lbnRp b24gaXQgaW4gdGhlIGFic3RyYWN0Lg0KPiANCj4gUmVnYXJkcywgICBNYXJ0aW4uDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRy dSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============1313906422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1313906422==-- From ltru-bounces@ietf.org Sun Nov 13 11:44:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbKxy-0005VK-UV; Sun, 13 Nov 2005 11:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbKxx-0005VE-IY for ltru@megatron.ietf.org; Sun, 13 Nov 2005 11:44:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17953 for ; Sun, 13 Nov 2005 11:43:59 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbLEo-0001CA-3M for ltru@ietf.org; Sun, 13 Nov 2005 12:01:55 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 13 Nov 2005 08:44:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Ltru] Matching draft: terminology: application MIME-Version: 1.0 Date: Sun, 13 Nov 2005 08:44:17 -0800 Message-ID: Thread-Topic: [Ltru] Matching draft: terminology: application Thread-Index: AcXoTX+hclBn1RPSToelw7aCRFDLdgAI6RWw From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 13 Nov 2005 16:44:19.0474 (UTC) FILETIME=[7E1D8720:01C5E871] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0409109877==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0409109877== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBkb24ndCBxdWl0ZSBhZ3JlZS4gDQoNCkkgYmVsaWV2ZSB0aGUgd29yZCBhcHBsaWNhdGlvbiBk b2VzICppbmNsdWRlKiBvdGhlciBzdGFuZGFyZHMsIHN1Y2ggYXMgSFRUUCBvciBDU1MuIEJ1dCBp dCBhbHNvIGluY2x1ZGVzIHRoZSB0cmFkaXRpb25hbCBtZWFuaW5nIG9mIHRoZSB3b3JkICdhcHBs aWNhdGlvbicuIEZvciBleGFtcGxlLCBoZXJlIGlzIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiB0aGUg d29yZCBhcHBsaWNhdGlvbjoNCg0KLS0NClRoZSBzdWl0YWJpbGl0eSBvZiBhIHBhcnRpY3VsYXIg bWVjaGFuaXNtIHRvIGEgcGFydGljdWxhciBhcHBsaWNhdGlvbiBkZXBlbmRzIG9uIHRoZSBuZWVk cyBvZiB0aGF0IGFwcGxpY2F0aW9uLg0KLS0NCg0KSXQgc2VlbXMgY2xlYXIgdG8gbWUgdGhhdCB0 aGUgaW50ZW5kZWQgYXVkaWVuY2UgaXMgYW55b25lIG5lZWRpbmcgdG8gc2VsZWN0IGEgbWF0Y2hp bmcgc2NoZW1lIGZvciB0aGVpciBhcHBsaWNhdGlvbiAoYmUgaXQgYSBzdGFuZGFyZCBvciBhIHNw ZWNpZmljIGltcGxlbWVudGF0aW9uKS4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBz DQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25h bGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFydGluIER1 ZXJzdA0KPiBTZW50OiAyMDA15bm0MTHmnIgxM+aXpSA0OjA5DQo+IFRvOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogW0x0cnVdIE1hdGNoaW5nIGRyYWZ0OiB0ZXJtaW5vbG9neTogYXBw bGljYXRpb24NCj4gDQo+IFRoZSB0ZXJtICdhcHBsaWNhdGlvbicgc2hvd3MgdXAgbWFueSB0aW1l cyBpbiB0aGUgZG9jdW1lbnQsDQo+IGJ1dCBpdCdzIG5vdCB2ZXJ5IGNsZWFyIHdoYXQgdGhhdCBt ZWFucy4gTXkgdW5kZXJzdGFuZGluZw0KPiBpcyB0aGF0IGl0IG1lYW5zIG90aGVyIHN0YW5kYXJk cyBzdWNoIGFzIEhUVFAsIENTUywgYW5kIHNvDQo+IG9uLCBub3QgaW5kaXZpZHVhbCBlbmQtdXNl ciBhcHBsaWNhdGlvbnMgb24gYSBQQy4NCj4gDQo+IElmIHRoaXMgaXMgc28sIHdlIHNob3VsZCBt YWtlIHRoaXMgY2xlYXIsIHByZWZlcmFibHkgaW4NCj4gYW4gaW50cm9kdWN0b3J5IHNlY3Rpb24g YWJvdXQgdGVybWlub2xvZ3kuIElmIHRoaXMgaXMNCj4gZGlmZmVyZW50LCB3ZSBzaG91bGQgYWxz byBtYWtlIGl0IGNsZWFyLg0KPiANCj4gUmVnYXJkcywgICBNYXJ0aW4uDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWls aW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1DQo= --===============0409109877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0409109877==-- From ltru-bounces@ietf.org Sun Nov 13 12:58:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbM7z-00044v-47; Sun, 13 Nov 2005 12:58:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbM7w-00043Y-Ft for ltru@megatron.ietf.org; Sun, 13 Nov 2005 12:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23370 for ; Sun, 13 Nov 2005 12:58:17 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbMOi-0003pS-V3 for ltru@ietf.org; Sun, 13 Nov 2005 13:16:14 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 13 Nov 2005 09:58:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Ltru] Matching draft: structure MIME-Version: 1.0 Date: Sun, 13 Nov 2005 09:58:31 -0800 Message-ID: Thread-Topic: [Ltru] Matching draft: structure Thread-Index: AcXoTYXLN81iJkxTTeuURA1iFT7GhQALhapA From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 13 Nov 2005 17:58:32.0383 (UTC) FILETIME=[DC4184F0:01C5E87B] 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: , Content-Type: multipart/mixed; boundary="===============0615444704==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0615444704== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QXMgdXN1YWwsIHlvdSBtYWtlIHNvbWUgZXhjZWxsZW50IG9ic2VydmF0aW9ucyBpbiB0aGlzIGFu ZCB0aGUgb3RoZXIgc2ltaWxhciBlbWFpbCByZWxhdGVkIHRvIGl0LiBJJ20gcG9uZGVyaW5nIGEg d2F5IHRvIHF1aWNrbHkgcmVvcmdhbml6ZSB0aGUgY29udGVudCBhbG9uZyB0aGVzZSBsaW5lcyBh bmQgd3JpdGUgc29tZSBnbHVlIHRleHQsIHdoaWNoIEknbGwgcG9zdCBhcyBhIHByb3Bvc2FsIHNo b3J0bHkuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBB cmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1hcnRpbiBEdWVyc3QNCj4gU2VudDogMjAw NeW5tDEx5pyIMTPml6UgMzo1Ng0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6 IFtMdHJ1XSBNYXRjaGluZyBkcmFmdDogc3RydWN0dXJlDQo+IA0KPiBJJ20gY3VycmVudGx5IGRv aW5nIGEgY2FyZWZ1bCByZS1yZWFkIG9mIHRoZSBtYXRjaGluZyBkcmFmdCBhcyBwYXJ0DQo+IG9m IG15IGNoYWlyIGR1dHkuDQo+IA0KPiBUaGUgZm9sbGluZyBhcmUgY29tbWVudHMgdGhhdCBJJ20g c2VuZGluZyBhcyBhIHRlY2huaWNhbCBjb250cmlidXRvci4NCj4gDQo+IFRoaXMgY29tbWVudCBp cyBhYm91dCB0aGUgc3RydWN0dXJlIG9mIHRoZSBkcmFmdC4NCj4gDQo+IEZpcnN0LCBhbGwgb2Yg dGhlICdiZWVmJyBpcyBpbiBTZWN0aW9uIDIuIEkgdGhpbmsgaXQgd291bGQNCj4gYmUgbXVjaCBi ZXR0ZXIgdG8gaGF2ZSB0aGF0IHNlcGFyYXRlZCBpbnRvIHNldmVyYWwgc2VjdGlvbnMuDQo+IEkn bGwgZXhwbGFpbiBob3cgSSB0aGluayBpdCBjYW4gYmUgZG9uZS4NCj4gDQo+IFNlY29uZCwgSSBk b24ndCB1bmRlcnN0YW5kIGhvdyAiRGlzdGFuY2UgTWV0cmljIFNjaGVtZSIgZ290DQo+IGludG8g dGhlIHNlY3Rpb24gYWJvdXQgIkV4dGVuZGVkIExhbmd1YWdlIFJhbmdlIi4gSSB0aGluaw0KPiBp dCBzaG91bGQgYmUgaW4gaXRzIG93biBzZWN0aW9uLg0KPiANCj4gU28gSSB3b3VsZCBzcGxpdCBz ZWN0aW9uIDIgaW50byB0aHJlZSBvciBtb3JlIHNlY3Rpb25zLA0KPiBvbmUgb24gdGVybWlub2xv Z3kgYW5kIGJhc2ljcyAoc2VlIHNlcGFyYXRlIG1haWwpLCBvbmUgb24NCj4gcmFuZ2VzIGFuZCBt YXRjaGluZyBhbmQgbG9va3VwIGFsZ29yaXRobXMsIGFuZCBvbmUgb24NCj4gYWRkaXRpb25hbCBj b25zaWRlcmF0aW9ucy4gT3RoZXIgc3BsaXRzIGFyZSBhbHNvIHBvc3NpYmxlLg0KPiANCj4gUmVn YXJkcywgICBNYXJ0aW4uDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0K PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0615444704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0615444704==-- From ltru-bounces@ietf.org Mon Nov 14 05:15:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbbMp-00004v-T5; Mon, 14 Nov 2005 05:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbbMo-00004q-G5 for ltru@megatron.ietf.org; Mon, 14 Nov 2005 05:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09816 for ; Mon, 14 Nov 2005 05:14:41 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebbdn-0006RC-Gf for ltru@ietf.org; Mon, 14 Nov 2005 05:32:49 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAEAEru25086 for ; Mon, 14 Nov 2005 19:14:53 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1b37_7f7bf3ca_54f7_11da_9225_00304811fd80; Mon, 14 Nov 2005 19:14:52 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAEAE2vi012334 for ; Mon, 14 Nov 2005 19:14:28 +0900 Message-Id: <6.0.0.20.2.20051114182353.06619e50@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 14 Nov 2005 19:13:30 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching draft: 2.4 Meaning 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm somewhat surprised we have a paragraph on meaning of language tags in the matching document; shouldn't that have been in the registry document? I agree some of the material makes sense here, but I don't see the point of the bulletet list at the end, which is a (modulo minor changes, I didn't check for that) verbatim copy of Section 4.2 of draft-ietf-ltru-registry-14.txt and isn't, in my view, very matching-specific. The first paragraph says that a language tag 'defines' a language; we successfully elimitated this usage; if we still need this paragraph, please use 'indicate' or whatever. The paragraph starting "This relationship is not guaranteed..." doesn't make sense to me. "This relationship" refers to "narrower"/"more specific", but the paragraph then gives "NOT guaranteed to be mutually intellegible". Mutual intellegibility is something different from narrower or wider. In theory, there could be a prefix for Indo-European, and then some narrower stuff, and we all know Indo-European is too wide to be mutually intellegible. Another (minor) problem is that "intellegible" is used both in the general (spoken and written) sense as well as just for writing (in the az example). Regarding 'mutually intellegible', it would be good to point out that this is a subjective concept; the text somehow alludes to that in the az example paragraph, but doesn't really explicitly say so. For the end, back to the title of the section: it should be changed so that it's clear we don't define the meaning of language tags here. Also, we should say something about ranges, or leave it out of the title. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 05:45:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebbpp-0004PU-S2; Mon, 14 Nov 2005 05:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebbpo-0004PP-2a for ltru@megatron.ietf.org; Mon, 14 Nov 2005 05:45:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11256 for ; Mon, 14 Nov 2005 05:44:39 -0500 (EST) Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ebc6l-0007Lh-QM for ltru@ietf.org; Mon, 14 Nov 2005 06:02:47 -0500 Received: (qmail 86420 messnum 2899479 invoked from network[159.134.169.146/159-134-169-146.as1.prp.dublin.eircom.net]); 14 Nov 2005 10:44:44 -0000 Received: from 159-134-169-146.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.146) by mail07.svc.cra.dublin.eircom.net (qp 86420) with SMTP; 14 Nov 2005 10:44:44 -0000 Message-ID: <43786AA1.F88DEEDF@egt.ie> Date: Mon, 14 Nov 2005 10:44:49 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: LTRU Working Group Subject: Re: [Ltru] Matching draft: terminology: application References: <6.0.0.20.2.20051113210722.06b9ec40@localhost> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA11256 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org In the case of ISO standards, it is useful to have a terminology section, even if mostly containing definitions quoted from related standards. 'Application' should be defined in the LTRU context. mg Scr=EDobh Martin Duerst: >=20 > The term 'application' shows up many times in the document, > but it's not very clear what that means. My understanding > is that it means other standards such as HTTP, CSS, and so > on, not individual end-user applications on a PC. >=20 > If this is so, we should make this clear, preferably in > an introductory section about terminology. If this is > different, we should also make it clear. >=20 > Regards, Martin. >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 05:51:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbbvS-00056l-TB; Mon, 14 Nov 2005 05:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbbvR-00056g-UP for ltru@megatron.ietf.org; Mon, 14 Nov 2005 05:51:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11553 for ; Mon, 14 Nov 2005 05:50:29 -0500 (EST) Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbcCO-0007W9-Ju for ltru@ietf.org; Mon, 14 Nov 2005 06:08:37 -0500 Received: (qmail 66370 messnum 280943 invoked from network[159.134.169.146/159-134-169-146.as1.prp.dublin.eircom.net]); 14 Nov 2005 10:50:46 -0000 Received: from 159-134-169-146.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.146) by mail03.svc.cra.dublin.eircom.net (qp 66370) with SMTP; 14 Nov 2005 10:50:46 -0000 Message-ID: <43786C0B.4407D8F4@egt.ie> Date: Mon, 14 Nov 2005 10:50:51 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: LTRU Working Group Subject: Re: [Ltru] Matching draft: 2.4 Meaning of language tags... References: <6.0.0.20.2.20051114182353.06619e50@localhost> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA11553 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I understand that the purpose of a language tag is to 'identify' a language, that the word 'langtag' is only short for language identifier. Using words such as 'defines' or 'indicates' could be confusing. What is the advantage in avoiding the words 'identify' or 'ide= ntifier"? mg Scr=EDobh Martin Duerst: > ... > The first paragraph says that a language tag 'defines' > a language; we successfully elimitated this usage; if > we still need this paragraph, please use 'indicate' or > whatever... --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 11:45:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhSJ-0005K0-Jz; Mon, 14 Nov 2005 11:45:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhSG-0005Jl-P1 for ltru@megatron.ietf.org; Mon, 14 Nov 2005 11:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03628 for ; Mon, 14 Nov 2005 11:44:43 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbhjJ-0002bj-He for ltru@ietf.org; Mon, 14 Nov 2005 12:02:54 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 08:44:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching draft: 2.4 Meaning of language tags... Date: Mon, 14 Nov 2005 08:44:58 -0800 Message-ID: Thread-Topic: [Ltru] Matching draft: 2.4 Meaning of language tags... Thread-Index: AcXpCXKchfYC5luyRKmgRLjWYrBuJgAMCZiA From: "Addison Phillips" To: "Marion Gunn" X-OriginalArrivalTime: 14 Nov 2005 16:44:57.0453 (UTC) FILETIME=[BF2A69D0:01C5E93A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0091582483==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0091582483== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlIHVzZSBvZiB2YXJpb3VzIHdvcmRzIGluIHRoYXQgc2VjdGlvbiBpcyBwcm9ibGVtYXRpYyBm b3IgdGhlIHJlYXNvbnMgTWFydGluIGNpdGVzOiBsYW5ndWFnZSB0YWdzIGRvIG5vdCBkZWZpbmUg YSBsYW5ndWFnZS4gTWFyaW9uJ3Mgc3VnZ2VzdGlvbiBpcywgaW4gbXkgb3BpbmlvbiwgdGhlIHJp Z2h0IG9uZTogbGFuZ3VhZ2UgdGFncyBpZGVudGlmeSBhbmQgSSB3aWxsIG1ha2UgdGhpcyBjaGFu Z2UgYXMgcGFydCBvZiB0aGUgcHJvcG9zZWQganVnZ2xpbmcgb2YgdGV4dCBmcm9tIHRoaXMgd2Vl a2VuZCdzIGVtYWlsLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBp cyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzps dHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYXJpb24gR3Vubg0KPiBTZW50 OiAyMDA15bm0MTHmnIgxNOaXpSAyOjUxDQo+IENjOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3Vi amVjdDogUmU6IFtMdHJ1XSBNYXRjaGluZyBkcmFmdDogMi40IE1lYW5pbmcgb2YgbGFuZ3VhZ2Ug dGFncy4uLg0KPiANCj4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHB1cnBvc2Ugb2YgYSBsYW5ndWFn ZSB0YWcgaXMgdG8gJ2lkZW50aWZ5JyBhDQo+IGxhbmd1YWdlLCB0aGF0IHRoZSB3b3JkICdsYW5n dGFnJyBpcyAgb25seSBzaG9ydCBmb3IgbGFuZ3VhZ2UNCj4gaWRlbnRpZmllci4gVXNpbmcgd29y ZHMgc3VjaCBhcyAnZGVmaW5lcycgb3IgJ2luZGljYXRlcycgY291bGQgYmUNCj4gY29uZnVzaW5n LiBXaGF0IGlzIHRoZSBhZHZhbnRhZ2UgaW4gYXZvaWRpbmcgdGhlIHdvcmRzICdpZGVudGlmeScg b3INCj4gJ2lkZW50aWZpZXIiPw0KPiBtZw0KPiANCj4gU2Nyw61vYmggTWFydGluIER1ZXJzdDoN Cj4gPiAuLi4NCj4gPiBUaGUgZmlyc3QgcGFyYWdyYXBoIHNheXMgdGhhdCBhIGxhbmd1YWdlIHRh ZyAnZGVmaW5lcycNCj4gPiBhIGxhbmd1YWdlOyB3ZSBzdWNjZXNzZnVsbHkgZWxpbWl0YXRlZCB0 aGlzIHVzYWdlOyBpZg0KPiA+IHdlIHN0aWxsIG5lZWQgdGhpcyBwYXJhZ3JhcGgsIHBsZWFzZSB1 c2UgJ2luZGljYXRlJyBvcg0KPiA+IHdoYXRldmVyLi4uDQo+IA0KPiAtLQ0KPiANCj4gTWFyaW9u IEd1bm4gKiBFR1RlbyAoRXN0YWIuMTk5MSkNCj4gMjcgUMOhaXJjIGFuIEZow6lpdGhsaW5uLCBC YWlsZSBhbg0KPiBCaMOzdGhhaXIsIENvLiDDgXRoYSBDbGlhdGgsIMOJaXJlLg0KPiAqIG1ndW5u QGVndC5pZSAqIGVhbW9ubkBlZ3QuaWUgKg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0091582483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0091582483==-- From ltru-bounces@ietf.org Mon Nov 14 12:05:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhli-0001S5-An; Mon, 14 Nov 2005 12:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhlg-0001Rw-Lw for ltru@megatron.ietf.org; Mon, 14 Nov 2005 12:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04827 for ; Mon, 14 Nov 2005 12:04:47 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebi2j-0003H8-NA for ltru@ietf.org; Mon, 14 Nov 2005 12:22:59 -0500 Received: from nappa.corp.google.com (nappa.corp.google.com [172.24.0.4]) by smtp-out.google.com with ESMTP id jAEH4jfB016883; Mon, 14 Nov 2005 09:04:45 -0800 Received: from [172.24.89.156] (evdp.corp.google.com [172.24.89.156]) by nappa.corp.google.com with ESMTP id jAEH4dFn018010; Mon, 14 Nov 2005 09:04:39 -0800 Message-ID: <4378C3A6.1030301@google.com> Date: Mon, 14 Nov 2005 09:04:38 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Matching draft: terminology: application References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-out.google.com id jAEH4jfB016883 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org RFCs often use the word "application" in this confusing way. If you're=20 used to RFCs and Internet Drafts, you know what "application" means. But=20 if you're coming from a different background, such as PC software=20 development, the word "application" has a more specific meaning. The matching draft does sometimes make it quite clear. In one place it=20 raises HTTP as an example of an application. In other places it talks=20 about "application or protocol". And in one place it even has=20 "application protocol". I don't know whether we need to define=20 "application" in this spec, but maybe some more of the occurences of the=20 word "application" could be replaced with "application or protocol". Erik Addison Phillips wrote: > I don't quite agree.=20 >=20 > I believe the word application does *include* other standards, such as = HTTP or CSS. But it also includes the traditional meaning of the word 'ap= plication'. For example, here is the first instance of the word applicati= on: >=20 > -- > The suitability of a particular mechanism to a particular application d= epends on the needs of that application. > -- >=20 > It seems clear to me that the intended audience is anyone needing to se= lect a matching scheme for their application (be it a standard or a speci= fic implementation). >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 >=20 >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Martin Duerst >>Sent: 2005=E5=B9=B411=E6=9C=8813=E6=97=A5 4:09 >>To: LTRU Working Group >>Subject: [Ltru] Matching draft: terminology: application >> >>The term 'application' shows up many times in the document, >>but it's not very clear what that means. My understanding >>is that it means other standards such as HTTP, CSS, and so >>on, not individual end-user applications on a PC. >> >>If this is so, we should make this clear, preferably in >>an introductory section about terminology. If this is >>different, we should also make it clear. >> >>Regards, Martin. >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 12:22:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhx7-0003uT-FJ; Mon, 14 Nov 2005 12:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhx6-0003uF-Pj for ltru@megatron.ietf.org; Mon, 14 Nov 2005 12:17:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05905 for ; Mon, 14 Nov 2005 12:16:37 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbiEA-0003lR-4E for ltru@ietf.org; Mon, 14 Nov 2005 12:34:47 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 09:16:55 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:16:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Frisian problems Date: Mon, 14 Nov 2005 09:16:56 -0800 Message-ID: Thread-Topic: [Ltru] Re: Frisian problems thread-index: AcXl0Qq/mNM8od/zQd6i+XxK/GEXtgDbcOOA From: "Peter Constable" To: , X-OriginalArrivalTime: 14 Nov 2005 17:16:55.0165 (UTC) FILETIME=[36360AD0:01C5E93F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of John.Cowan > An alternative is to change DIS 639-3 so that 'fry' is no longer a > macrolanguage but simply the 639-3 code for Western Frisian > I don't know how much turmoil that would cause with existing data. > It may even be that the 639-2/RA assumed that 'fy'/'fry' already meant > Western Frisian specifically. The ISO 639 JAC is in the process of clarifying the documentation for = 'fy'/'fry' in precisely this way, that the corresponding change will be = made before 639-3 is published.=FD Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 13:00:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebid4-0001qm-9h; Mon, 14 Nov 2005 13:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebid2-0001qh-Iz for ltru@megatron.ietf.org; Mon, 14 Nov 2005 13:00:28 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09214 for ; Mon, 14 Nov 2005 12:59:56 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EbibH-0000Mq-Oi for ltru@lists.ietf.org; Mon, 14 Nov 2005 18:58:39 +0100 Received: from c-134-88-187.hh.dial.de.ignite.net ([62.134.88.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Nov 2005 18:58:39 +0100 Received: from nobody by c-134-88-187.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Nov 2005 18:58:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Nov 2005 18:57:04 +0100 Organization: Lines: 18 Message-ID: <4378CFF0.7170@xyzzy.claranet.de> References: <4378C3A6.1030301@google.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: c-134-88-187.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching draft: terminology: application X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Erik van der Poel wrote: > I don't know whether we need to define "application" in this > spec Let's stick to RfC 1983 / FYI 18: | application | A program that performs a function directly for a user. | FTP, mail and Telnet clients are examples of network | applications. It also explains "protocol", "application layer", and "API". Pretty old, some (now) obscure terms, but still better than reinventing the wheel. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 14:14:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebjmj-0003iN-Ql; Mon, 14 Nov 2005 14:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebjmi-0003iI-IV for ltru@megatron.ietf.org; Mon, 14 Nov 2005 14:14:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15001 for ; Mon, 14 Nov 2005 14:14:01 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebk3n-0008Ih-UB for ltru@ietf.org; Mon, 14 Nov 2005 14:32:12 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Mon, 14 Nov 2005 14:13:55 -0500 id 01588021.4378E1F3.00004613 From: "Scott Hollenbeck" To: ltru@ietf.org Date: Mon, 14 Nov 2005 14:14:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXnM7lpMsY5j8IPT1WgrpQpRE+7PwCAx7wgAAYZ1dA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Subject: [Ltru] FW: Appeal RFC 3934 Morfin suspension X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org My review of JFC Morfin's recent posting rights appeal, and my decision regarding that appeal, is included below. I am sending this message to the LTRU working group mailing list to document my findings and my decision for the public record. Scott Hollenbeck LTRU Area Advisor -----Original Message----- From: Scott Hollenbeck [mailto:sah@428cobrajet.net] Sent: Monday, November 14, 2005 2:11 PM To: 'r&d afrac' Cc: 'Randy Presuhn'; 'Martin Duerst'; sah@428cobrajet.net Subject: RE: Appeal RFC 3934 Morfin suspension On 8 November 2005 Randy Presuhn, co-chair of the LTRU working group, announced that the posting rights of Mr. JFC Morfin were being suspended "for a period of 30 days, under the terms of RFC 3934 section 2" [1]. Mr. Morfin appealed this decision in a private mail note sent on 11 November 2005 to me, Randy Presuhn, and LTRU co-chair Martin Duerst. I have reviewed both the mailing list activities that led to the suspension decision and Mr. Morfin's appeal. I have prepared a statement of my findings in this mail note, followed by my decision. Mr. Presuhn sent a note to the LTRU mailing list on 13 October 2005 [2] describing the topics that remain valid for working group discussion. Mr. Morfin received a public warning [3] for off-topic posting on 15 October. He received an additional private warning for an attempt to continue discussion of a closed issue on 26 October. I must note that Mr. Morfin has also appealed this private warning to me. His appeal request included allegations of chair inaction to track on-topic discussion of issues allegedly identified by Mr. Morfin. He did not provide any citations to document his contributions, so I put processing of this appeal aside until Mr. Morfin could provide references to mailing list discussion to confirm his allegations. He has not done so to date, so this appeal has not been processed. However, I do find that the note sent by Mr. Morfin [4] that prompted the warning does appear to be an attempt to continue discussion of a topic that has been declared "closed" by a working group chair. On 7 November, Mr. Presuhn sent a note to the LTRU mailing list [5] that includes a request to close a thread that "is not contibuting to forward progress". Mr. Morfin continued to post messages [6] continuing this thread from 7 through 9 November. Since others were also continuing the discussion, I reinforced Mr. Presuhn's message in a note sent to the working group [7] on 9 November. Mr. Morfin's suspension was announced later on 9 November. I believe that Mr. Morfin has received multiple, proper warnings for off-topic posting to the LTRU working group mailing list. He posted multiple off-topic messages after receipt of these warnings. As a result, Mr. Morfin's appeal to the responsible Area Director is denied. The working group chair decision to suspend his posting rights is upheld. I will forward this message to the LTRU mailing list to create a public record of my decision. Scott Hollenbeck LTRU Area Advisor [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html [2] http://www1.ietf.org/mail-archive/web/ltru/current/msg03904.html [3] http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html [4] http://www1.ietf.org/mail-archive/web/ltru/current/msg03977.html [5] http://www1.ietf.org/mail-archive/web/ltru/current/msg04000.html [6] http://www1.ietf.org/mail-archive/web/ltru/current/msg04004.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04019.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04028.html http://www1.ietf.org/mail-archive/web/ltru/current/msg04029.html [7] http://www1.ietf.org/mail-archive/web/ltru/current/msg04030.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 15:05:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkZk-0003kA-RP; Mon, 14 Nov 2005 15:05:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkZh-0003ix-Nb for ltru@megatron.ietf.org; Mon, 14 Nov 2005 15:05:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19356 for ; Mon, 14 Nov 2005 15:04:37 -0500 (EST) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebkqm-0001yx-GF for ltru@ietf.org; Mon, 14 Nov 2005 15:22:49 -0500 Received: from h-68-165-4-233.snvacaid.dynamic.covad.net ([68.165.4.233] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EbkZf-0005fj-00 for ltru@ietf.org; Mon, 14 Nov 2005 15:05:07 -0500 Message-ID: <002401c5e957$57d79560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 14 Nov 2005 12:09:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ltru] Approval of two ltru documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I think members of the ltru working group will be delighted to learn that draft-ietf-ltru-initial and draft-ietf-ltru-registry have been approved. The official announcement should soon appear. For more details, see ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13008&rfc_flag=0 Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 16:57:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbmKF-0006IX-AB; Mon, 14 Nov 2005 16:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbmKD-0006IN-WD for ltru@megatron.ietf.org; Mon, 14 Nov 2005 16:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04212 for ; Mon, 14 Nov 2005 16:56:43 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbmbF-0000CF-6a for ltru@ietf.org; Mon, 14 Nov 2005 17:14:56 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 13:56:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 13:56:48 -0800 Message-ID: Thread-Topic: draft-06 of matching prototype... Thread-Index: AcXpZlAPyAa5VSycQcyNe/GGYM5JIQ== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 14 Nov 2005 21:56:55.0234 (UTC) FILETIME=[53D52220:01C5E966] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] draft-06 of matching prototype... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0611164477==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0611164477== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QmFzZWQgb24gTWFydGluJ3MgY29tbWVudHMgZnJvbSBvdmVyIHRoZSB3ZWVrZW5kLCBJIGhhdmUg cHJvZHVjZWQgYSBoZWF2aWx5IHJlb3JnYW5pemVkIHZlcnNpb24gb2YgZHJhZnQtbWF0Y2hpbmcg YW5kIHVwbG9hZGVkIGl0IHRvIG15IHBlcnNvbmFsIHdlYnNpdGUuIFRoaXMgY29weSBpcyBpbnRl bmRlZCBhcyBhIHRlc3QgcnVuIHRvIHNlZSBpZiBpdCBhZGRyZXNzZWQgTWFydGluJ3Mgc3BlY2lm aWMgY29uY2VybnMgYW5kIHdoZXRoZXIgdGhpcyB3YXMgcmVhbGx5IHRoZSByaWdodCBhcHByb2Fj aCAoZG9lcyBpdCBuZWVkIGRvaW5nPykNCg0KQmFzaWNhbGx5LCB3aGF0IEkgZGlkIHdhczoNCg0K MS4gSSBzZXBhcmF0ZWQgdGhlIGRlZmluaXRpb24gb2YgTGFuZ3VhZ2UgUmFuZ2VzIGZyb20gdGhl IG1hdGNoaW5nIHNjaGVtZXMgYWx0b2dldGhlci4gQm90aCBiYXNpYyBhbmQgZXh0ZW5kZWQgbGFu Z3VhZ2UgcmFuZ2VzIGFyZSBkZWZpbmVkIHRvZ2V0aGVyLCB0aGVuLCBpbiBhIHNlcGFyYXRlIHNl Y3Rpb24sIHRoZSAiVHlwZXMgb2YgTWF0Y2hpbmciDQoNCjIuIFRvIG1ha2UgdGhpbmdzIGNsZWFy ZXIsIEkgcmV0aXRsZWQgdGhlICJtYXRjaGluZyIgbWF0Y2hpbmcgc2NoZW1lcyBhcyAiZmlsdGVy aW5nIiAoc28gd2UgaGF2ZSAibG9va3VwIiBhbmQgImZpbHRlcmluZyIsIGJvdGggb2Ygd2hpY2gg YXJlIG1hdGNoaW5nIHNjaGVtZXMpLiBJIHJldGl0bGVkIHRoZSBEaXN0YW5jZSBNZXRyaWMgU2No ZW1lIGFzIERpc3RhbmNlIE1ldHJpYyBGaWx0ZXJpbmcgYXMgd2VsbC4NCg0KMy4gVGhlIHRleHQg dGhhdCB3YXMgaW4gIkNob29zaW5nIGEgTGFuZ3VhZ2UgTWF0Y2hpbmcgU2NoZW1lIiB3YXMgaW5j b3Jwb3JhdGVkIGludG8gdGhlIGludHJvZHVjdGlvbiB0byB0aGUgc2VjdGlvbiBvbiBtYXRjaGlu ZyBzY2hlbWVzLg0KDQo0LiBUaGUgcmVtYWluaW5nICJqdW5rIiAobWVhbmluZywgY29uc2lkZXJh dGlvbnMgZm9yIHByaXZhdGUgdXNlIHN1YnRhZ3MsIGFuZCBsZW5ndGggY29uc2lkZXJhdGlvbnMp IHdlcmUgbW92ZWQgaW50byBhIG5ldywgc2VwYXJhdGUgc2VjdGlvbiBjYWxsICJPdGhlciBDb25z aWRlcmF0aW9ucyIuIA0KDQo1LiBBIHJvdWdoIG9uY2Utb3ZlciBlZGl0IHdhcyBhcHBsaWVkIHRv IG1ha2UgdGhlIHRleHQgbW9yZS1vci1sZXNzIGNsZWFuLg0KDQpNYXJ0aW4sIGV0IGFsOiBpcyB0 aGlzIGdlbmVyYWxseSB3aGF0IHlvdSBoYXZlIGluIG1pbmQ/IElzIHRoaXMgdGhlIHJpZ2h0IHdh eSB0byBwcm9jZWVkPyANCg0KSFRNTDogaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2Ry YWZ0LWlldGYtbHRydS1tYXRjaGluZy0wNi5odG1sDQpYTUw6IGh0dHA6Ly93d3cuaW50ZXItbG9j YWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtbWF0Y2hpbmctMDYueG1sDQoNCkJlc3QgUmVnYXJk cywNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkludGVybmF0aW9u YWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============0611164477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0611164477==-- From ltru-bounces@ietf.org Mon Nov 14 17:59:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnIS-0008Q0-W4; Mon, 14 Nov 2005 17:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnIQ-0008P5-RO for ltru@megatron.ietf.org; Mon, 14 Nov 2005 17:59:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08416 for ; Mon, 14 Nov 2005 17:58:58 -0500 (EST) Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbnZX-0002Rd-5Z for ltru@ietf.org; Mon, 14 Nov 2005 18:17:12 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAEMxGZC017789 for ; Mon, 14 Nov 2005 17:59:16 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAEMx5ge074540 for ; Mon, 14 Nov 2005 15:59:05 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAEMxFC4007487 for ; Mon, 14 Nov 2005 15:59:15 -0700 Received: from [127.0.0.1] (mark-davis.sanjose.ibm.com [9.43.213.128] (may be forged)) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAEMvEne001893; Mon, 14 Nov 2005 15:59:15 -0700 Message-ID: <43791649.1050503@icu-project.org> Date: Mon, 14 Nov 2005 14:57:13 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Approval of two ltru documents References: <002401c5e957$57d79560$7f1afea9@oemcomputer> In-Reply-To: <002401c5e957$57d79560$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org That's great news! A question -- when will we know what the RFC number is? Mark Randy Presuhn wrote: >Hi - > >I think members of the ltru working group will be delighted >to learn that draft-ietf-ltru-initial and draft-ietf-ltru-registry >have been approved. The official announcement should soon appear. > > >For more details, see >ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13008&rfc_flag=0 > >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 Mon Nov 14 20:50:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpxS-0006tC-B5; Mon, 14 Nov 2005 20:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpxR-0006sd-5x for ltru@megatron.ietf.org; Mon, 14 Nov 2005 20:50:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20024 for ; Mon, 14 Nov 2005 20:49:29 -0500 (EST) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbqEY-00007Y-Pr for ltru@ietf.org; Mon, 14 Nov 2005 21:07:44 -0500 Received: from h-64-105-34-111.snvacaid.dynamic.covad.net ([64.105.34.111] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EbpxO-0005FP-00 for ltru@ietf.org; Mon, 14 Nov 2005 20:49:58 -0500 Message-ID: <001601c5e987$8256a3a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002401c5e957$57d79560$7f1afea9@oemcomputer> <43791649.1050503@icu-project.org> Subject: Re: [Ltru] Approval of two ltru documents Date: Mon, 14 Nov 2005 17:54:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Monday, November 14, 2005 2:57 PM > Subject: Re: [Ltru] Approval of two ltru documents > > That's great news! > > A question -- when will we know what the RFC number is? ... We'll find out at the beginning of the AUTH48 period, when the editors verify whether the RFC editor's edits have broken anything. However, I'd consider it tacky to let the information leak out until the RFC editor has actually sent out the announcement of availability. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 21:56:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebr02-00012P-RI; Mon, 14 Nov 2005 21:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebr01-00011U-DC for ltru@megatron.ietf.org; Mon, 14 Nov 2005 21:56:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23241 for ; Mon, 14 Nov 2005 21:56:13 -0500 (EST) Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbrH6-0002KP-Pt for ltru@ietf.org; Mon, 14 Nov 2005 22:14:26 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAF2uOuu024061 for ; Mon, 14 Nov 2005 21:56:24 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAF2vc7W070546 for ; Mon, 14 Nov 2005 19:57:38 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAF2uMF9005062 for ; Mon, 14 Nov 2005 19:56:22 -0700 Received: from [127.0.0.1] (mark-davis.sanjose.ibm.com [9.43.213.128]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAF2uLPU004976; Mon, 14 Nov 2005 19:56:22 -0700 Message-ID: <43794E53.6060200@icu-project.org> Date: Mon, 14 Nov 2005 18:56:19 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Approval of two ltru documents References: <002401c5e957$57d79560$7f1afea9@oemcomputer> <43791649.1050503@icu-project.org> <001601c5e987$8256a3a0$7f1afea9@oemcomputer> In-Reply-To: <001601c5e987$8256a3a0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Ok. It would just be nice to refer to it as the forthcoming RFC 6666 instead of still saying 3066bis. This is in reference to the program for the upcoming Unicode conference in May. But one doesn't want to be tacky... When should we expect the 'announcement of availability'? Mark Randy Presuhn wrote: >Hi - > > > >>From: "Mark Davis" >>To: "Randy Presuhn" >>Cc: "LTRU Working Group" >>Sent: Monday, November 14, 2005 2:57 PM >>Subject: Re: [Ltru] Approval of two ltru documents >> >>That's great news! >> >>A question -- when will we know what the RFC number is? >> >> >... > >We'll find out at the beginning of the AUTH48 period, when the >editors verify whether the RFC editor's edits have broken anything. >However, I'd consider it tacky to let the information leak out until the >RFC editor has actually sent out the announcement of availability. > >Randy > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 22:30:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbrWz-0003Se-4w; Mon, 14 Nov 2005 22:30:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbrWy-0003Rj-8u for ltru@megatron.ietf.org; Mon, 14 Nov 2005 22:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24735 for ; Mon, 14 Nov 2005 22:30:15 -0500 (EST) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebro6-0003IH-Fk for ltru@ietf.org; Mon, 14 Nov 2005 22:48:31 -0500 Received: from h-64-105-34-111.snvacaid.dynamic.covad.net ([64.105.34.111] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EbrWn-0007hp-00 for ltru@ietf.org; Mon, 14 Nov 2005 22:30:37 -0500 Message-ID: <000601c5e995$8de7ba20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002401c5e957$57d79560$7f1afea9@oemcomputer> <43791649.1050503@icu-project.org> <001601c5e987$8256a3a0$7f1afea9@oemcomputer> <43794E53.6060200@icu-project.org> Subject: Re: [Ltru] Approval of two ltru documents Date: Mon, 14 Nov 2005 19:34:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Monday, November 14, 2005 6:56 PM > Subject: Re: [Ltru] Approval of two ltru documents ... > When should we expect the 'announcement of availability'? ... It's not predictable. You can monitor the document's progress at http://www.rfc-editor.org/queue.html once it's been handed over to the RFC editor for processing. We don't have any unsatisfied references, so we shouldn't fare as badly as those few documents that have been in the queue since 2002. For information that might help you guess when things might be done (assuming the matching work is soon completed!) see http://www3.ietf.org/proceedings/05nov/slides/plenaryw-2.pdf Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 14 23:25:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbsOI-0002uF-OY; Mon, 14 Nov 2005 23:25:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbsOH-0002u5-Kc for ltru@megatron.ietf.org; Mon, 14 Nov 2005 23:25:53 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27743 for ; Mon, 14 Nov 2005 23:25:20 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EbsMx-0004Mr-Ql for ltru@lists.ietf.org; Tue, 15 Nov 2005 05:24:31 +0100 Received: from pd9fba923.dip0.t-ipconnect.de ([217.251.169.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 05:24:31 +0100 Received: from nobody by pd9fba923.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 05:24:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 15 Nov 2005 05:23:11 +0100 Organization: Lines: 6 Message-ID: <437962AF.6D19@xyzzy.claranet.de> References: <002401c5e957$57d79560$7f1afea9@oemcomputer> <43791649.1050503@icu-project.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: pd9fba923.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Approval of two ltru documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > when will we know what the RFC number is? Spring 2006 (guessing). The BCP number is 47 :-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 03:33:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwFu-0002DR-MC; Tue, 15 Nov 2005 03:33:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwFt-0002DL-EN for ltru@megatron.ietf.org; Tue, 15 Nov 2005 03:33:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09502 for ; Tue, 15 Nov 2005 03:32:55 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwX3-0003mM-2p for ltru@ietf.org; Tue, 15 Nov 2005 03:51:14 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAF8XCu16311; Tue, 15 Nov 2005 17:33:12 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 73fc_756f4da8_55b2_11da_89e8_00304811fd80; Tue, 15 Nov 2005 17:33:11 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAF8VuA4026313; Tue, 15 Nov 2005 17:32:35 +0900 Message-Id: <6.0.0.20.2.20051115105626.06fba910@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 15 Nov 2005 12:02:52 +0900 To: "Addison Phillips" , "LTRU Working Group" From: Martin Duerst Subject: RE: [Ltru] Matching draft: terminology: application In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hello Addison, others, [co-chair hat on] I think we have to split this discussion into two issues: 1) What do we want to say, and 2) How do we say it So let's figure out 1) first, and let's look at 2) once we have figured out 1). I think we have two options: a) Apply to protocols (and other standards) only b) Apply to everything including what I'd like to call here 'end user applications' It looks to me like Erik is saying that the current draft says a), whereas Frank seems to say that the current draft says b) (at least where it doesn't mention protocols). Addison seems to say the current draft says b). [co-chair hat off] I personally think I could live both with a) and with b), given that it was clear what we ment. I favorize b) because the matching stuff can indeed be used by 'end user applications'. However, I have one concern with b): I'd like end user applications that implement a protocol (or other standard) to follow that standard first and foremost, and the advice in our draft after that. I'd also like protocol specs and other standards to clearly choose which matching algorithm they use in case they do matching. If there is a good way to make this clear, I think b) is clearly the better option. Regards, Martin. At 01:44 05/11/14, Addison Phillips wrote: >I don't quite agree. > >I believe the word application does *include* other standards, such as HTTP >or CSS. But it also includes the traditional meaning of the word >'application'. For example, here is the first instance of the word application: > >-- >The suitability of a particular mechanism to a particular application >depends on the needs of that application. >-- > >It seems clear to me that the intended audience is anyone needing to select >a matching scheme for their application (be it a standard or a specific >implementation). > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > >> -----Original Message----- >> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >> Martin Duerst >> Sent: 2005$BG/(B11$B7n(B13$BF|(B 4:09 >> To: LTRU Working Group >> Subject: [Ltru] Matching draft: terminology: application >> >> The term 'application' shows up many times in the document, >> but it's not very clear what that means. My understanding >> is that it means other standards such as HTTP, CSS, and so >> on, not individual end-user applications on a PC. >> >> If this is so, we should make this clear, preferably in >> an introductory section about terminology. If this is >> different, we should also make it clear. >> >> Regards, Martin. >> >> >> _______________________________________________ >> 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 Nov 15 04:18:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwqu-00073z-2Y; Tue, 15 Nov 2005 04:11:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwqs-00073u-9C for ltru@megatron.ietf.org; Tue, 15 Nov 2005 04:11:42 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12200 for ; Tue, 15 Nov 2005 04:11:09 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ebwp4-0007Zm-Oe for ltru@lists.ietf.org; Tue, 15 Nov 2005 10:09:50 +0100 Received: from pd9fbadb6.dip0.t-ipconnect.de ([217.251.173.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 10:09:50 +0100 Received: from nobody by pd9fbadb6.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 10:09:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 15 Nov 2005 10:07:45 +0100 Organization: Lines: 13 Message-ID: <4379A561.3B22@xyzzy.claranet.de> References: <6.0.0.20.2.20051115105626.06fba910@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadb6.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching draft: terminology: application X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Frank seems to say that the current draft says b) Okay, but actually I wanted to say something different: If we need some kind of "definition" for "application" and / or "protocol" let's reference RfC 1983 (FYI 18). Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 05:24:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxzG-00029h-QB; Tue, 15 Nov 2005 05:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxzF-00026h-8g for ltru@megatron.ietf.org; Tue, 15 Nov 2005 05:24:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15816 for ; Tue, 15 Nov 2005 05:23:52 -0500 (EST) Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbyGR-0007Y3-JJ for ltru@ietf.org; Tue, 15 Nov 2005 05:42:12 -0500 Received: (qmail 61607 messnum 6386114 invoked from network[159.134.169.249/159-134-169-249.as1.prp.dublin.eircom.net]); 15 Nov 2005 10:24:11 -0000 Received: from 159-134-169-249.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.249) by mail00.svc.cra.dublin.eircom.net (qp 61607) with SMTP; 15 Nov 2005 10:24:11 -0000 Message-ID: <4379B750.2D53D1D7@egt.ie> Date: Tue, 15 Nov 2005 10:24:17 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Matching draft: terminology: application References: <4378C3A6.1030301@google.com> <4378CFF0.7170@xyzzy.claranet.de> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA15816 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Much better. Use the terminology formula: 'application: as defined in RfC 1983 / FYI 18' and ideally follow that with the full quotation, as given by Frank below (to save people having to buy yet another standard to get one stray definition). mg Scr=EDobh Frank Ellermann: > ... >=20 > Let's stick to RfC 1983 / FYI 18: >=20 > | application > | A program that performs a function directly for a user. > | FTP, mail and Telnet clients are examples of network > | applications. >=20 > It also explains "protocol", "application layer", and "API". >=20 > Pretty old, some (now) obscure terms, but still better than > reinventing the wheel. > Bye, Frank --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 07:38:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec04u-00029i-8z; Tue, 15 Nov 2005 07:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec04s-00029d-Se for ltru@megatron.ietf.org; Tue, 15 Nov 2005 07:38:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21394 for ; Tue, 15 Nov 2005 07:37:51 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec0M6-0002Xj-It for ltru@ietf.org; Tue, 15 Nov 2005 07:56:11 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 15 Nov 2005 07:37:50 -0500 id 01588017.4379D69E.00007A06 From: "Scott Hollenbeck" To: "'Marion Gunn'" Subject: RE: [Ltru] Re: Matching draft: terminology: application Date: Tue, 15 Nov 2005 07:38:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4379B750.2D53D1D7@egt.ie> Thread-Index: AcXpztGpTmXUqfLLR0i5WRjCELPqBwAEi07g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 1.0 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie] > Sent: Tuesday, November 15, 2005 5:24 AM > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Matching draft: terminology: application > > Much better. Use the terminology formula: 'application: as defined in > RfC 1983 / FYI 18' and ideally follow that with the full quotation, as > given by Frank below (to save people having to buy yet > another standard > to get one stray definition). > mg IETF standards are free (as in beer). There is no cost to obtain copies beyond whatever it costs you to download and save a copy of a text document. It is generally better to cite a definition found in another document without quoting it. Quoting puts that definition in two places. If one of them changes in the future, which one remains the authoritative definition? -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 10:32:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2np-0007yo-Ba; Tue, 15 Nov 2005 10:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2nm-0007xZ-2k for ltru@megatron.ietf.org; Tue, 15 Nov 2005 10:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00698 for ; Tue, 15 Nov 2005 10:32:21 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec350-0007vN-4c for ltru@ietf.org; Tue, 15 Nov 2005 10:50:44 -0500 Received: from evilmonkey.corp.google.com (evilmonkey.corp.google.com [172.24.0.124]) by smtp-out.google.com with ESMTP id jAFFWkAD016272; Tue, 15 Nov 2005 07:32:47 -0800 Received: from [172.24.89.156] (evdp.corp.google.com [172.24.89.156]) by evilmonkey.corp.google.com with ESMTP id jAFFWjtG011101; Tue, 15 Nov 2005 07:32:45 -0800 Message-ID: <4379FF9D.8080103@google.com> Date: Tue, 15 Nov 2005 07:32:45 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Approval of two ltru documents References: <002401c5e957$57d79560$7f1afea9@oemcomputer> <43791649.1050503@icu-project.org> <437962AF.6D19@xyzzy.claranet.de> In-Reply-To: <437962AF.6D19@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Mark Davis wrote: > > when will we know what the RFC number is? > > Spring 2006 (guessing). The BCP number is 47 :-) Bye, Frank Yes, draft-ietf-ltru-registry-14's intended status is BCP and it says that it will obsolete RFC 3066 (which is BCP 47) if approved. However, draft-ietf-ltru-matching-05 also says that it will obsolete 3066 but it does not have an intended status: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13140 What happens to a BCP if its RFC gets obsoleted by _two_ new RFCs, one of which is proceeding at a slower pace? Erik _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 10:38:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2tP-0000S0-Om; Tue, 15 Nov 2005 10:38:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2tO-0000Rm-BY for ltru@megatron.ietf.org; Tue, 15 Nov 2005 10:38:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01002 for ; Tue, 15 Nov 2005 10:38:09 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec3Ae-00085Y-KI for ltru@ietf.org; Tue, 15 Nov 2005 10:56:32 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 15 Nov 2005 10:38:22 -0500 id 01588001.437A00EE.00002646 From: "Scott Hollenbeck" To: "'Erik van der Poel'" Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Tue, 15 Nov 2005 10:38:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4379FF9D.8080103@google.com> Thread-Index: AcXp+iffztBBT0ziSj+6G6DXXHLElAAAC1Gg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Erik van der Poel [mailto:erikv@google.com] > Sent: Tuesday, November 15, 2005 10:33 AM > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Approval of two ltru documents > > Frank Ellermann wrote: > > Mark Davis wrote: > > > when will we know what the RFC number is? > > > > Spring 2006 (guessing). The BCP number is 47 :-) Bye, Frank > > Yes, draft-ietf-ltru-registry-14's intended status is BCP and it says > that it will obsolete RFC 3066 (which is BCP 47) if approved. > However, > draft-ietf-ltru-matching-05 also says that it will obsolete > 3066 but it > does not have an intended status: > > https://datatracker.ietf.org/public/idindex.cgi?command=id_det > ail&id=13140 > > What happens to a BCP if its RFC gets obsoleted by _two_ new > RFCs, one > of which is proceeding at a slower pace? The answer to that question is included in the "Note to the RFC Editor" that can be found in the I-D tracker entry for registry-14. The matching draft doesn't have an identified status because you guys haven't yet formally asked the IESG to do anything with the document. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 10:54:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec38l-0006Mu-VL; Tue, 15 Nov 2005 10:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec38l-0006Mp-DH for ltru@megatron.ietf.org; Tue, 15 Nov 2005 10:54:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02199 for ; Tue, 15 Nov 2005 10:54:01 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec3Q0-0000Ex-OJ for ltru@ietf.org; Tue, 15 Nov 2005 11:12:25 -0500 Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id jAFFsLfX025072; Tue, 15 Nov 2005 07:54:21 -0800 Received: from [172.24.89.156] (evdp.corp.google.com [172.24.89.156]) by lois.corp.google.com with ESMTP id jAFFsFWh001204; Tue, 15 Nov 2005 07:54:15 -0800 Message-ID: <437A04A7.3010902@google.com> Date: Tue, 15 Nov 2005 07:54:15 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: [Ltru] Re: Approval of two ltru documents References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scott Hollenbeck wrote: > The answer to that question is included in the "Note to the RFC Editor" that > can be found in the I-D tracker entry for registry-14. The matching draft > doesn't have an identified status because you guys haven't yet formally > asked the IESG to do anything with the document. That note also asks the editor to publish the registry and initial RFCs at the same time as the matching RFC. So now the registry RFC is being held up by the matching RFC. Erik _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 11:01:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3FZ-0007nt-K4; Tue, 15 Nov 2005 11:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3FX-0007ni-FA for ltru@megatron.ietf.org; Tue, 15 Nov 2005 11:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02732 for ; Tue, 15 Nov 2005 11:01:02 -0500 (EST) Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ec3Wm-0000Ui-RL for ltru@ietf.org; Tue, 15 Nov 2005 11:19:26 -0500 Received: (qmail 19441 messnum 4221571 invoked from network[159.134.168.228/159-134-168-228.as1.prp.dublin.eircom.net]); 15 Nov 2005 16:01:16 -0000 Received: from 159-134-168-228.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.228) by mail13.svc.cra.dublin.eircom.net (qp 19441) with SMTP; 15 Nov 2005 16:01:16 -0000 Message-ID: <437A064F.4E275E42@egt.ie> Date: Tue, 15 Nov 2005 16:01:19 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: [Ltru] Re: Matching draft: terminology: application References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 2.3 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA02732 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scr=EDobh Scott Hollenbeck: >=20 > IETF standards are free (as in beer). There is no cost to obtain copie= s > beyond whatever it costs you to download and save a copy of a text docu= ment. >=20 Good point. ISO Standards generally are not. > It is generally better to cite a definition found in another document > without quoting it. Quoting puts that definition in two places. If on= e of > them changes in the future, which one remains the authoritative definit= ion? >=20 I'd say quoting it makes it the authoritative definition in in the doc. wherein quoted, but I'd also say it would be enough to enclose a copy/link to original in the daughter doc. Either way, if it costs nothing to get the second one, giving it in reference is probably enough, though still a bit annoying to users not having both readily to h= and. mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 11:02:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3Gt-0008Fo-Op; Tue, 15 Nov 2005 11:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3Gs-0008Fc-DA for ltru@megatron.ietf.org; Tue, 15 Nov 2005 11:02:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02883 for ; Tue, 15 Nov 2005 11:02:25 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec3Y7-0000Yu-PE for ltru@ietf.org; Tue, 15 Nov 2005 11:20:49 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 15 Nov 2005 11:02:37 -0500 id 0158802B.437A069D.00002A24 From: "Scott Hollenbeck" To: "'Erik van der Poel'" Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Tue, 15 Nov 2005 11:02:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <437A04A7.3010902@google.com> Thread-Index: AcXp/N7dqNzqCr+5RkiQX6lqPntPNgAAHHRQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Erik van der Poel [mailto:erikv@google.com] > Sent: Tuesday, November 15, 2005 10:54 AM > To: Scott Hollenbeck > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Approval of two ltru documents > > Scott Hollenbeck wrote: > > The answer to that question is included in the "Note to the > RFC Editor" that > > can be found in the I-D tracker entry for registry-14. The > matching draft > > doesn't have an identified status because you guys haven't > yet formally > > asked the IESG to do anything with the document. > > That note also asks the editor to publish the registry and > initial RFCs > at the same time as the matching RFC. So now the registry RFC > is being > held up by the matching RFC. You can't have two documents obsolete an older RFC when the two new documents get published as RFCs at different times. It's all or nothing. "held up" is relative. The normal RFC publication process takes several months, so there is almost no chance of the matching draft causing a problem if the group gets it finished soon. I will ask the RFC Editor to expedite processing of the matching draft to avoid delays once the working group is through with it. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 11:45:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3wK-0007jZ-Uz; Tue, 15 Nov 2005 11:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3wF-0007iY-GR for ltru@megatron.ietf.org; Tue, 15 Nov 2005 11:45:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06853 for ; Tue, 15 Nov 2005 11:45:07 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4DT-0002DM-56 for ltru@ietf.org; Tue, 15 Nov 2005 12:03:31 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 08:45:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching draft: terminology: application Date: Tue, 15 Nov 2005 08:45:18 -0800 Message-ID: Thread-Topic: [Ltru] Matching draft: terminology: application Thread-Index: AcXpvzjsl6GHuj7eTB2iab8wkdW+3AARD8Fw From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 15 Nov 2005 16:45:20.0978 (UTC) FILETIME=[F799CB20:01C5EA03] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918412671==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0918412671== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 KzENCg0KSSB0aGluayB3aGF0IEkgd2FzIHNheWluZyB3YXMgIihiKSwgd2hlcmUgKGEpIGlzIGEg c3Vic2V0IG9mIChiKSIsIHRoYXQgaXM6IGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiB0aGF0IHJl ZmVyZW5jZXMgbGFuZ3VhZ2UgdGFncyBvciBtYXRjaGluZyBpcyAiYW4gYXBwbGljYXRpb24iLiBJ IGFncmVlIHdpdGggRXJpaydzIHByb3Bvc2FsIHRoYXQgd2UgYWN0dWFsbHkgc2F5ICJhcHBsaWNh dGlvbnMgYW5kIHByb3RvY29scyIgd2hlcmUgdGhlc2UgY2FuIGJlIGNvbnNpZGVyZWQgdG8gYmUg c2VwYXJhdGUuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBEdWVyc3QgW21haWx0bzpkdWVyc3RAaXQuYW95 YW1hLmFjLmpwXQ0KPiBTZW50OiAyMDA15bm0MTHmnIgxNOaXpSAxOTowMw0KPiBUbzogQWRkaXNv biBQaGlsbGlwczsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gTWF0 Y2hpbmcgZHJhZnQ6IHRlcm1pbm9sb2d5OiBhcHBsaWNhdGlvbg0KPiANCj4gSGVsbG8gQWRkaXNv biwgb3RoZXJzLA0KPiANCj4gW2NvLWNoYWlyIGhhdCBvbl0NCj4gSSB0aGluayB3ZSBoYXZlIHRv IHNwbGl0IHRoaXMgZGlzY3Vzc2lvbiBpbnRvIHR3byBpc3N1ZXM6DQo+IA0KPiAxKSBXaGF0IGRv IHdlIHdhbnQgdG8gc2F5LCBhbmQNCj4gMikgSG93IGRvIHdlIHNheSBpdA0KPiANCj4gU28gbGV0 J3MgZmlndXJlIG91dCAxKSBmaXJzdCwgYW5kIGxldCdzIGxvb2sgYXQgMikNCj4gb25jZSB3ZSBo YXZlIGZpZ3VyZWQgb3V0IDEpLiBJIHRoaW5rIHdlIGhhdmUgdHdvIG9wdGlvbnM6DQo+IGEpIEFw cGx5IHRvIHByb3RvY29scyAoYW5kIG90aGVyIHN0YW5kYXJkcykgb25seQ0KPiBiKSBBcHBseSB0 byBldmVyeXRoaW5nIGluY2x1ZGluZyB3aGF0IEknZCBsaWtlIHRvIGNhbGwgaGVyZQ0KPiAgICAg J2VuZCB1c2VyIGFwcGxpY2F0aW9ucycNCj4gDQo+IEl0IGxvb2tzIHRvIG1lIGxpa2UgRXJpayBp cyBzYXlpbmcgdGhhdCB0aGUgY3VycmVudCBkcmFmdA0KPiBzYXlzIGEpLCB3aGVyZWFzIEZyYW5r IHNlZW1zIHRvIHNheSB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0DQo+IHNheXMgYikgKGF0IGxlYXN0 IHdoZXJlIGl0IGRvZXNuJ3QgbWVudGlvbiBwcm90b2NvbHMpLg0KPiBBZGRpc29uIHNlZW1zIHRv IHNheSB0aGUgY3VycmVudCBkcmFmdCBzYXlzIGIpLg0KPiBbY28tY2hhaXIgaGF0IG9mZl0NCj4g DQo+IA0KPiBJIHBlcnNvbmFsbHkgdGhpbmsgSSBjb3VsZCBsaXZlIGJvdGggd2l0aCBhKSBhbmQg d2l0aCBiKSwNCj4gZ2l2ZW4gdGhhdCBpdCB3YXMgY2xlYXIgd2hhdCB3ZSBtZW50LiBJIGZhdm9y aXplIGIpIGJlY2F1c2UNCj4gdGhlIG1hdGNoaW5nIHN0dWZmIGNhbiBpbmRlZWQgYmUgdXNlZCBi eSAnZW5kIHVzZXIgYXBwbGljYXRpb25zJy4NCj4gSG93ZXZlciwgSSBoYXZlIG9uZSBjb25jZXJu IHdpdGggYik6IEknZCBsaWtlIGVuZCB1c2VyDQo+IGFwcGxpY2F0aW9ucyB0aGF0IGltcGxlbWVu dCBhIHByb3RvY29sIChvciBvdGhlciBzdGFuZGFyZCkNCj4gdG8gZm9sbG93IHRoYXQgc3RhbmRh cmQgZmlyc3QgYW5kIGZvcmVtb3N0LCBhbmQgdGhlDQo+IGFkdmljZSBpbiBvdXIgZHJhZnQgYWZ0 ZXIgdGhhdC4gSSdkIGFsc28gbGlrZSBwcm90b2NvbA0KPiBzcGVjcyBhbmQgb3RoZXIgc3RhbmRh cmRzIHRvIGNsZWFybHkgY2hvb3NlIHdoaWNoIG1hdGNoaW5nDQo+IGFsZ29yaXRobSB0aGV5IHVz ZSBpbiBjYXNlIHRoZXkgZG8gbWF0Y2hpbmcuIElmIHRoZXJlIGlzDQo+IGEgZ29vZCB3YXkgdG8g bWFrZSB0aGlzIGNsZWFyLCBJIHRoaW5rIGIpIGlzIGNsZWFybHkNCj4gdGhlIGJldHRlciBvcHRp b24uDQo+IA0KPiBSZWdhcmRzLCAgIE1hcnRpbi4NCj4gDQo+IA0KPiBBdCAwMTo0NCAwNS8xMS8x NCwgQWRkaXNvbiBQaGlsbGlwcyB3cm90ZToNCj4gID5JIGRvbid0IHF1aXRlIGFncmVlLg0KPiAg Pg0KPiAgPkkgYmVsaWV2ZSB0aGUgd29yZCBhcHBsaWNhdGlvbiBkb2VzICppbmNsdWRlKiBvdGhl ciBzdGFuZGFyZHMsIHN1Y2ggYXMNCj4gSFRUUA0KPiAgPm9yIENTUy4gQnV0IGl0IGFsc28gaW5j bHVkZXMgdGhlIHRyYWRpdGlvbmFsIG1lYW5pbmcgb2YgdGhlIHdvcmQNCj4gID4nYXBwbGljYXRp b24nLiBGb3IgZXhhbXBsZSwgaGVyZSBpcyB0aGUgZmlyc3QgaW5zdGFuY2Ugb2YgdGhlIHdvcmQN Cj4gYXBwbGljYXRpb246DQo+ICA+DQo+ICA+LS0NCj4gID5UaGUgc3VpdGFiaWxpdHkgb2YgYSBw YXJ0aWN1bGFyIG1lY2hhbmlzbSB0byBhIHBhcnRpY3VsYXIgYXBwbGljYXRpb24NCj4gID5kZXBl bmRzIG9uIHRoZSBuZWVkcyBvZiB0aGF0IGFwcGxpY2F0aW9uLg0KPiAgPi0tDQo+ICA+DQo+ICA+ SXQgc2VlbXMgY2xlYXIgdG8gbWUgdGhhdCB0aGUgaW50ZW5kZWQgYXVkaWVuY2UgaXMgYW55b25l IG5lZWRpbmcgdG8NCj4gc2VsZWN0DQo+ICA+YSBtYXRjaGluZyBzY2hlbWUgZm9yIHRoZWlyIGFw cGxpY2F0aW9uIChiZSBpdCBhIHN0YW5kYXJkIG9yIGEgc3BlY2lmaWMNCj4gID5pbXBsZW1lbnRh dGlvbikuDQo+ICA+DQo+ICA+QWRkaXNvbg0KPiAgPg0KPiAgPkFkZGlzb24gUC4gUGhpbGxpcHMN Cj4gID5HbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCj4gID4NCj4gID5J bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiAgPkl0IGlzIGFuIGFyY2hp dGVjdHVyZS4NCj4gID4NCj4gID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICA+PiBG cm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZg0KPiAgPj4gTWFydGluIER1ZXJzdA0KPiAgPj4gU2VudDogMjAwNeW5 tDEx5pyIMTPml6UgNDowOQ0KPiAgPj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiAgPj4gU3Vi amVjdDogW0x0cnVdIE1hdGNoaW5nIGRyYWZ0OiB0ZXJtaW5vbG9neTogYXBwbGljYXRpb24NCj4g ID4+DQo+ICA+PiBUaGUgdGVybSAnYXBwbGljYXRpb24nIHNob3dzIHVwIG1hbnkgdGltZXMgaW4g dGhlIGRvY3VtZW50LA0KPiAgPj4gYnV0IGl0J3Mgbm90IHZlcnkgY2xlYXIgd2hhdCB0aGF0IG1l YW5zLiBNeSB1bmRlcnN0YW5kaW5nDQo+ICA+PiBpcyB0aGF0IGl0IG1lYW5zIG90aGVyIHN0YW5k YXJkcyBzdWNoIGFzIEhUVFAsIENTUywgYW5kIHNvDQo+ICA+PiBvbiwgbm90IGluZGl2aWR1YWwg ZW5kLXVzZXIgYXBwbGljYXRpb25zIG9uIGEgUEMuDQo+ICA+Pg0KPiAgPj4gSWYgdGhpcyBpcyBz bywgd2Ugc2hvdWxkIG1ha2UgdGhpcyBjbGVhciwgcHJlZmVyYWJseSBpbg0KPiAgPj4gYW4gaW50 cm9kdWN0b3J5IHNlY3Rpb24gYWJvdXQgdGVybWlub2xvZ3kuIElmIHRoaXMgaXMNCj4gID4+IGRp ZmZlcmVudCwgd2Ugc2hvdWxkIGFsc28gbWFrZSBpdCBjbGVhci4NCj4gID4+DQo+ICA+PiBSZWdh cmRzLCAgIE1hcnRpbi4NCj4gID4+DQo+ICA+Pg0KPiAgPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+IEx0cnUgbWFpbGluZyBsaXN0DQo+ICA+ PiBMdHJ1QGlldGYub3JnDQo+ICA+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sdHJ1DQoNCg== --===============0918412671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0918412671==-- From ltru-bounces@ietf.org Tue Nov 15 12:18:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Nn-0000Rn-Ix; Tue, 15 Nov 2005 12:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Nm-0000QF-Bh for ltru@megatron.ietf.org; Tue, 15 Nov 2005 12:14:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10161 for ; Tue, 15 Nov 2005 12:13:37 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4f1-0003it-8k for ltru@ietf.org; Tue, 15 Nov 2005 12:32:01 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 09:13:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Tue, 15 Nov 2005 09:13:45 -0800 Message-ID: Thread-Topic: [Ltru] Re: Approval of two ltru documents Thread-Index: AcXp/N7dqNzqCr+5RkiQX6lqPntPNgAAHHRQAAJ82SA= From: "Addison Phillips" To: "Scott Hollenbeck" , "Erik van der Poel" X-OriginalArrivalTime: 15 Nov 2005 17:13:58.0780 (UTC) FILETIME=[F77D93C0:01C5EA07] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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="===============1444005263==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1444005263== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlcmUgaXMgYSBoaXN0b3JpY2FsIHByZWNlZGVudCB0byB0aGUgY29udHJhcnk6IFJGQyAzMDY2 IGFuZCBSRkMgMzI4Mi4NCg0KVGhleSBib3RoIG9ic29sZXRlIFJGQyAxNzY2LCB0aGUgQkNQIDQ3 IG9mIGl0cyB0aW1lLiBPbiBkaWZmZXJlbnQgZGF5cy4NCg0KVGhlIG1hdGVyaWFsIG9ic29sZXRl ZCBieSBkcmFmdC1tYXRjaGluZyBpbiBSRkMgMzA2NiBpcyBub24tbm9ybWF0aXZlLCBzbyBJIGRv bid0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBsaW5rIHRoZSB0d28gdG9nZXRoZXIuIEJ1dCBJ IGFncmVlIHRoYXQgd2Ugc2hvdWxkIGp1c3QgZmluaXNoIHRoZSBtYXRjaGluZyB3b3JrLCBnaXZl biB0aGF0IHRoZSBJRVNHIGRpZG4ndCBidXkgbXkgYXJndW1lbnQgdG8gc2VwYXJhdGUgdGhlIHR3 bywgYXZvaWQgdGhlIHdob2xlIGlzc3VlIGFuZCBxdWl0IGdyaXBpbmcgYWJvdXQgaXQuDQoNCk1v cmUgdG8gdGhlIHBvaW50OiB3b3VsZCBkcmFmdC1tYXRjaGluZyBiZWNvbWUgYSBwYXJ0IG9mIHRo ZSBuZXcgQkNQIDQ3PyBPciB3b3VsZCBpdCBnZXQgaXRzIG93biBCQ1AgbnVtYmVyPyBJJ20gbm90 IHNvIGNvbmNlcm5lZCBhYm91dCBub3csIGJ1dCBhYm91dCBhIHBvdGVudGlhbCAzMDY2dGVyIGJl aW5nIGhlbGQgdXAgYnkgYW4gYXJ0aWZpY2lhbCBuZWVkIHRvIHJldmlzZSBkcmFmdC1tYXRjaGlu Zy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVh dHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gU2NvdHQgSG9sbGVuYmVjaw0KPiBTZW50OiAyMDA1 5bm0MTHmnIgxNeaXpSA4OjAzDQo+IFRvOiAnRXJpayB2YW4gZGVyIFBvZWwnDQo+IENjOiBsdHJ1 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gUmU6IEFwcHJvdmFsIG9mIHR3byBsdHJ1 IGRvY3VtZW50cw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IEVyaWsgdmFuIGRlciBQb2VsIFttYWlsdG86ZXJpa3ZAZ29vZ2xlLmNvbV0NCj4gPiBTZW50OiBU dWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAwNSAxMDo1NCBBTQ0KPiA+IFRvOiBTY290dCBIb2xsZW5i ZWNrDQo+ID4gQ2M6IGx0cnVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBB cHByb3ZhbCBvZiB0d28gbHRydSBkb2N1bWVudHMNCj4gPg0KPiA+IFNjb3R0IEhvbGxlbmJlY2sg d3JvdGU6DQo+ID4gPiBUaGUgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24gaXMgaW5jbHVkZWQgaW4g dGhlICJOb3RlIHRvIHRoZQ0KPiA+IFJGQyBFZGl0b3IiIHRoYXQNCj4gPiA+IGNhbiBiZSBmb3Vu ZCBpbiB0aGUgSS1EIHRyYWNrZXIgZW50cnkgZm9yIHJlZ2lzdHJ5LTE0LiAgVGhlDQo+ID4gbWF0 Y2hpbmcgZHJhZnQNCj4gPiA+IGRvZXNuJ3QgaGF2ZSBhbiBpZGVudGlmaWVkIHN0YXR1cyBiZWNh dXNlIHlvdSBndXlzIGhhdmVuJ3QNCj4gPiB5ZXQgZm9ybWFsbHkNCj4gPiA+IGFza2VkIHRoZSBJ RVNHIHRvIGRvIGFueXRoaW5nIHdpdGggdGhlIGRvY3VtZW50Lg0KPiA+DQo+ID4gVGhhdCBub3Rl IGFsc28gYXNrcyB0aGUgZWRpdG9yIHRvIHB1Ymxpc2ggdGhlIHJlZ2lzdHJ5IGFuZA0KPiA+IGlu aXRpYWwgUkZDcw0KPiA+IGF0IHRoZSBzYW1lIHRpbWUgYXMgdGhlIG1hdGNoaW5nIFJGQy4gU28g bm93IHRoZSByZWdpc3RyeSBSRkMNCj4gPiBpcyBiZWluZw0KPiA+IGhlbGQgdXAgYnkgdGhlIG1h dGNoaW5nIFJGQy4NCj4gDQo+IFlvdSBjYW4ndCBoYXZlIHR3byBkb2N1bWVudHMgb2Jzb2xldGUg YW4gb2xkZXIgUkZDIHdoZW4gdGhlIHR3byBuZXcNCj4gZG9jdW1lbnRzIGdldCBwdWJsaXNoZWQg YXMgUkZDcyBhdCBkaWZmZXJlbnQgdGltZXMuICBJdCdzIGFsbCBvciBub3RoaW5nLg0KPiANCj4g ImhlbGQgdXAiIGlzIHJlbGF0aXZlLiAgVGhlIG5vcm1hbCBSRkMgcHVibGljYXRpb24gcHJvY2Vz cyB0YWtlcyBzZXZlcmFsDQo+IG1vbnRocywgc28gdGhlcmUgaXMgYWxtb3N0IG5vIGNoYW5jZSBv ZiB0aGUgbWF0Y2hpbmcgZHJhZnQgY2F1c2luZyBhDQo+IHByb2JsZW0NCj4gaWYgdGhlIGdyb3Vw IGdldHMgaXQgZmluaXNoZWQgc29vbi4gIEkgd2lsbCBhc2sgdGhlIFJGQyBFZGl0b3IgdG8gZXhw ZWRpdGUNCj4gcHJvY2Vzc2luZyBvZiB0aGUgbWF0Y2hpbmcgZHJhZnQgdG8gYXZvaWQgZGVsYXlz IG9uY2UgdGhlIHdvcmtpbmcgZ3JvdXAgaXMNCj4gdGhyb3VnaCB3aXRoIGl0Lg0KPiANCj4gLVNj b3R0LQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============1444005263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1444005263==-- From ltru-bounces@ietf.org Tue Nov 15 12:46:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4sb-0000p6-BD; Tue, 15 Nov 2005 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4sZ-0000ow-9W for ltru@megatron.ietf.org; Tue, 15 Nov 2005 12:45:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12144 for ; Tue, 15 Nov 2005 12:45:25 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec59n-0004j2-9P for ltru@ietf.org; Tue, 15 Nov 2005 13:03:50 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 15 Nov 2005 12:45:27 -0500 id 0158802A.437A1EB7.00003C69 From: "Scott Hollenbeck" To: "'Addison Phillips'" Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Tue, 15 Nov 2005 12:45:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXp/N7dqNzqCr+5RkiQX6lqPntPNgAAHHRQAAJ82SAAAPMZEA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Tuesday, November 15, 2005 12:14 PM > To: Scott Hollenbeck; Erik van der Poel > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Approval of two ltru documents > > There is a historical precedent to the contrary: RFC 3066 and > RFC 3282. > > They both obsolete RFC 1766, the BCP 47 of its time. On > different days. That wouldn't happen today. Frankly it appears to be an error. How can 3282 obsolete something that has already been obsoleted by 3066? > The material obsoleted by draft-matching in RFC 3066 is > non-normative, so I don't think it is necessary to link the > two together. But I agree that we should just finish the > matching work, given that the IESG didn't buy my argument to > separate the two, avoid the whole issue and quit griping about it. The IESG disagreed with your assessment, hence the need to link the two documents to make progress. I do agree that we're spending far too much time on what is largely a publication formality. > More to the point: would draft-matching become a part of the > new BCP 47? Or would it get its own BCP number? I'm not so > concerned about now, but about a potential 3066ter being held > up by an artificial need to revise draft-matching. Both will become BCP 47. I've already confirmed with the RFC Editor that one or the other can be obsoleted later on independently of the other if needed. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 12:51:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4y6-0002JR-NX; Tue, 15 Nov 2005 12:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4y5-0002Ix-HI for ltru@megatron.ietf.org; Tue, 15 Nov 2005 12:51:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12560 for ; Tue, 15 Nov 2005 12:51:03 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5FF-0004vx-B1 for ltru@ietf.org; Tue, 15 Nov 2005 13:09:28 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 09:51:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Tue, 15 Nov 2005 09:51:16 -0800 Message-ID: Thread-Topic: [Ltru] Re: Approval of two ltru documents Thread-Index: AcXp/N7dqNzqCr+5RkiQX6lqPntPNgAAHHRQAAJ82SAAAPMZEAAAeqlQ From: "Addison Phillips" To: "Scott Hollenbeck" X-OriginalArrivalTime: 15 Nov 2005 17:51:18.0109 (UTC) FILETIME=[2E3C10D0:01C5EA0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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="===============1783075479==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1783075479== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiANCj4gQm90aCB3aWxsIGJlY29tZSBCQ1AgNDcuICBJJ3ZlIGFscmVhZHkgY29uZmlybWVkIHdp dGggdGhlIFJGQyBFZGl0b3IgdGhhdA0KPiBvbmUgb3IgdGhlIG90aGVyIGNhbiBiZSBvYnNvbGV0 ZWQgbGF0ZXIgb24gaW5kZXBlbmRlbnRseSBvZiB0aGUgb3RoZXIgaWYNCj4gbmVlZGVkLg0KDQpU aGF0J3Mga2luZCBvZiB3ZWlyZCwgYnV0IGFzIGxvbmcgYXMgdGhlIGxpbmthZ2UgaXMgZGlzc29s dmVkICh3aGVuIGl0IG1ha2VzIHNlbnNlIHRvIGJlIGRpc3NvbHZlZCkgSSdtIGhhcHB5Lg0KDQpB ZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0K SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============1783075479== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1783075479==-- From ltru-bounces@ietf.org Tue Nov 15 12:57:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec540-0005S2-2I; Tue, 15 Nov 2005 12:57:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec53y-0005Ro-NT for ltru@megatron.ietf.org; Tue, 15 Nov 2005 12:57:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13185 for ; Tue, 15 Nov 2005 12:57:13 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5LD-0005E5-Sm for ltru@ietf.org; Tue, 15 Nov 2005 13:15:38 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAFHvRwG013643 for ; Tue, 15 Nov 2005 12:57:27 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAFHvR4F104400 for ; Tue, 15 Nov 2005 12:57:27 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAFHvRRR008195 for ; Tue, 15 Nov 2005 12:57:27 -0500 Received: from [127.0.0.1] (sig-9-48-119-72.mts.ibm.com [9.48.119.72]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAFHvQPL007906; Tue, 15 Nov 2005 12:57:27 -0500 Message-ID: <437A2180.5070408@icu-project.org> Date: Tue, 15 Nov 2005 09:57:20 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] draft-06 of matching prototype... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I really like the restructuring. Interesting how much value it is just to introduce terminology like 'filtering'; it will make the situation much clearer to users. What I think it also makes clear is that we shouldn't be including 3.2.2. Extended Range Lookup. A lookup has to give a precise, single answer whenever there are a number of possible matches. The formulation that the draft gives does not distinguish in priority among matching items. If the following are all available, a lookup (as opposed to a filter) has to specify which would be the *first choice* when handed "*-US": en-US es_US en-Latn-US en-US-r-extends (extensions are ignored) nn-US no-US en es nn no I don't know of anyone in practice who implements 3.2.2, so I think this should be removed. Some future version of this RFC could be enhanced to include something like it, once all the kinks are worked out. Mark Addison Phillips wrote: >Based on Martin's comments from over the weekend, I have produced a heavily reorganized version of draft-matching and uploaded it to my personal website. This copy is intended as a test run to see if it addressed Martin's specific concerns and whether this was really the right approach (does it need doing?) > >Basically, what I did was: > >1. I separated the definition of Language Ranges from the matching schemes altogether. Both basic and extended language ranges are defined together, then, in a separate section, the "Types of Matching" > >2. To make things clearer, I retitled the "matching" matching schemes as "filtering" (so we have "lookup" and "filtering", both of which are matching schemes). I retitled the Distance Metric Scheme as Distance Metric Filtering as well. > >3. The text that was in "Choosing a Language Matching Scheme" was incorporated into the introduction to the section on matching schemes. > >4. The remaining "junk" (meaning, considerations for private use subtags, and length considerations) were moved into a new, separate section call "Other Considerations". > >5. A rough once-over edit was applied to make the text more-or-less clean. > >Martin, et al: is this generally what you have in mind? Is this the right way to proceed? > >HTML: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-06.html >XML: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-06.xml > >Best Regards, > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Internationalization is not a feature. >It is an architecture. > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Nov 15 13:00:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec56s-0006gt-Cy; Tue, 15 Nov 2005 13:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec56n-0006cc-Eb; Tue, 15 Nov 2005 13:00:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13352; Tue, 15 Nov 2005 13:00:07 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5O4-0005K8-Ip; Tue, 15 Nov 2005 13:18:33 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Ec56b-0004in-EB; Tue, 15 Nov 2005 13:00:29 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 15 Nov 2005 13:00:29 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Internet Architecture Board , ltru mailing list , RFC Editor Subject: [Ltru] Protocol Action: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The IESG has approved the following documents: - 'Initial Language Subtag Registry ' as an Informational RFC - 'Tags for Identifying Languages ' as a BCP These documents are products of the Language Tag Registry Update Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt Technical Summary The registry 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. The "initial" document defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. These documents were produced as part of the effort to develop a successor to RFC 3066, and are the primary deliverables the working group was chartered to produce. Working Group Summary Use of the existing IANA Language Tag registry revealed several shortcomings, leading to the development of this document. In addressing the requirements of its charter, the working group found it necessary to significantly change the registry format. Since language tags are used in a large number of protocols and formats, the working group maintained compatibility with existing language tag syntax, though it did change the syntax of registry entries and updated the procedures for the maintenance of the registry. There was strong consensus on all of these. Two issues are noteworthy for the amount of debate needed before the working group was able to reach rough consensus on them. The first was the order of subtags, in particular of the script identifier. The second was the "Suppress-Script" registry field. These two are closely related, and the tradeoffs involved a desire to avoid re-tagging existing data and a need to keep the tag format syntactically compatible with existing software, versus a desire to provide a tag structure that was in some ways more consistent. The working group opted for compatibility and avoiding re-tagging. The "initial" document is a necessary companion to the primary work item of the ltru working group, the specification of the IANA Language Subtag Registry. The IETF last call request produced many comments, some of which revisited issues that had previously been discussed by the working group and others which led to document changes. A summary of the comments and working group action to address them can be found in the archives of the working group mailing list: http://www1.ietf.org/mail-archive/web/ltru/current/msg03807.html Protocol Quality This document received extensive review and discussion within the ltru working group and the IETF as a whole. Since language tags are used in a large number of protocols and formats, the working group maintained compatibility with existing language tag syntax. At the time of this summary, likely additions to the registry had already been discussed, but the WG agreed that since such changes are part of the normal operation of the IANA Language Subtag Registry, they should be handled on the mailing list ietf-languages@iana.org after the registry has been initialized. The "initial" document is merely the delivery vehicle for the initial content for the IANA Lanaguage Subtag Registry. At the time of this summary, likely additions ("language synonyms") had already been discussed, but the WG agreed that since such changes are part of the normal operation of the IANA Language Subtag Registry, they can be handled on ietf-languages@iana.org after the registry has been initialized using the contents of this document. The initial registry contents were checked against the data from the underlying standards and for internal consistency by multiple working group members using independent methods. Scott Hollenbeck has reviewed these documents for the IESG. Note to the RFC Editor: draft-ietf-ltru-registry-14 in combination with draft-ietf-ltru-matching (not yet approved by the IESG) are intended to obsolete RFC 3066 and BCP 47. These two documents should thus be published at the same time as draft-ietf-ltru-matching once draft-ietf-ltru-matching has been approved by the IESG. Please add text to the Abstract and Introduction of draft-ietf-ltru-registry-14 to make this clear. "TBD" refers to the RFC number assigned to draft-ietf-ltru-matching. To be added to the end of the Abstract: This document, in combination with RFC TBD, replaces RFC 3066, which replaced RFC 1766. Introduction, second to last paragraph: OLD: This document replaces [RFC3066], which replaced [RFC1766]. NEW: This document, in combination with [RFCTBD], replaces [RFC3066], which replaced [RFC1766]. Please add an Informative reference in draft-ietf-ltru-registry-14 to the RFC that draft-ietf-ltru-matching becomes. Please replace zh-Hant-CN-variant1-a-extend1-x-wadegile-private1 by zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 on page 43 of draft-ietf-ltru-registry-14 in chapter 4.3.2 for consistency with the immediately following zh-Latn truncation example on the same page. This typo was found after the IESG evaluation and confirmed by the authors. OLD: zh-Hant-CN-variant1-a-extend1-x-wadegile-private1 NEW: zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 13:40:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5jP-00050x-Jn; Tue, 15 Nov 2005 13:40:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5jN-00050p-MQ for ltru@megatron.ietf.org; Tue, 15 Nov 2005 13:40:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16696 for ; Tue, 15 Nov 2005 13:39:59 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec60c-0006tQ-LW for ltru@ietf.org; Tue, 15 Nov 2005 13:58:22 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 10:40:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06 of matching prototype... Date: Tue, 15 Nov 2005 10:40:15 -0800 Message-ID: Thread-Topic: [Ltru] draft-06 of matching prototype... Thread-Index: AcXqDgxgYTjKTFz2QeuEPXmZWVBHdgAAvaTQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 15 Nov 2005 18:40:17.0231 (UTC) FILETIME=[06167DF0:01C5EA14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1998139646==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1998139646== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiANCj4gSSByZWFsbHkgbGlrZSB0aGUgcmVzdHJ1Y3R1cmluZy4gSW50ZXJlc3RpbmcgaG93IG11 Y2ggdmFsdWUgaXQgaXMganVzdA0KPiB0byBpbnRyb2R1Y2UgdGVybWlub2xvZ3kgbGlrZSAnZmls dGVyaW5nJzsgaXQgd2lsbCBtYWtlIHRoZSBzaXR1YXRpb24NCj4gbXVjaCBjbGVhcmVyIHRvIHVz ZXJzLg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpJIHRob3VnaHQgaXQgd29ya2VkIG91dCBwcmV0 dHkgd2VsbC4NCj4gDQo+IFdoYXQgSSB0aGluayBpdCBhbHNvIG1ha2VzIGNsZWFyIGlzIHRoYXQg d2Ugc2hvdWxkbid0IGJlIGluY2x1ZGluZw0KPiAzLjIuMi4gRXh0ZW5kZWQgUmFuZ2UgTG9va3Vw LiBBIGxvb2t1cCBoYXMgdG8gZ2l2ZSBhIHByZWNpc2UsIHNpbmdsZQ0KPiBhbnN3ZXIgd2hlbmV2 ZXIgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBvc3NpYmxlIG1hdGNoZXMuIFRoZSBmb3JtdWxhdGlv bg0KPiB0aGF0IHRoZSBkcmFmdCBnaXZlcyBkb2VzIG5vdCBkaXN0aW5ndWlzaCBpbiBwcmlvcml0 eSBhbW9uZyBtYXRjaGluZw0KPiBpdGVtcy4gDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkkgYWdy ZWUsIGFsdGhvdWdoIEkgd291bGQgdGFrZSBhIGRpZmZlcmVudCBhcHByb2FjaC4NCg0KRm9yIEhU VFAgaW4gcGFydGljdWxhciwgdGhlIEFjY2VwdC1MYW5ndWFnZSBoZWFkZXIgbWlnaHQgYmUgdXNl ZCBmb3IgYm90aCBmaWx0ZXJpbmcgYW5kIGxvb2t1cCBhcHBsaWNhdGlvbnMuIEl0IHdvdWxkIGJl IHVzZWZ1bCBJIHRoaW5rIHRvIHNwZWNpZnkgYSBtYXBwaW5nIGZyb20gRXh0ZW5kZWQgdG8gQmFz aWMgTGFuZ3VhZ2UgUmFuZ2VzIGluIHRoZSAoc29sZSkgTG9va3VwIHNjaGVtZS4NCg0KSSB0aGlu ayB0aGUgbWFwcGluZyB3b3JrcyB0aHVzbHk6DQoNCjEuIElmIHRoZSBFeHRlbmRlZCBMYW5ndWFn ZSBSYW5nZSBzdGFydHMgd2l0aCAiKiIsIHRoZW4gdGhlIEJhc2ljIExhbmd1YWdlIFJhbmdlIGlz ICIqIi4NCg0KMi4gT3RoZXJ3aXNlLCByZW1vdmUgYW55ICIqIiBzdWJ0YWdzIGFuZCB0aGVpciBh c3NvY2lhdGVkIHRyYWlsaW5nICItIiBpZiBpdCBleGlzdHMuDQoNClRodXMgYSByZXF1ZXN0IGZv cjoNCg0KICAiKi1VUyIgPT4gIioiDQogICJlbi0qLVVTIiA9PiAiZW4tVVMiDQogICJzci0qLUNT IiA9PiAic3ItQ1MiDQogICJzbC0qLSotbmVkaXMiID0+ICJzbC1uZWRpcyINCiAgImRlLSotMTkw MSIgPT4gImRlLTE5MDEiDQogICJkZS0qIiA9PiAiZGUiDQoNCkJlc3QgUmVnYXJkcywNCg0KQWRk aXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVl c3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg== --===============1998139646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1998139646==-- From ltru-bounces@ietf.org Tue Nov 15 14:34:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6ZE-00080K-9p; Tue, 15 Nov 2005 14:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6ZC-00080A-71 for ltru@megatron.ietf.org; Tue, 15 Nov 2005 14:34:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20198 for ; Tue, 15 Nov 2005 14:33:34 -0500 (EST) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6qU-0000KX-Cj for ltru@ietf.org; Tue, 15 Nov 2005 14:51:58 -0500 Received: from h-68-165-3-27.snvacaid.dynamic.covad.net ([68.165.3.27] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ec6ZB-0004pE-00 for ltru@ietf.org; Tue, 15 Nov 2005 14:34:05 -0500 Message-ID: <005e01c5ea1c$28aae740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 15 Nov 2005 11:38:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [Ltru] Fw: Response to appeal received from J-F C. Morfin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I'm forwarding this because the working group was omitted from the original distribution list. Randy ----- Original Message ----- > From: "The IESG" > To: "J-F C. Morfin" > Cc: ; > Sent: Tuesday, November 15, 2005 8:42 AM > Subject: Response to appeal received from J-F C. Morfin > > On 19 October 2005 the IESG received a request from J-F C. Morfin appealing > the decision of Randy Presuhn, LTRU working group chair, and Scott > Hollenbeck, LTRU Area Advisor, to include a note to the RFC Editor > describing a change to be made in draft-ietf-ltru-registry-14.txt prior to > publication as an RFC (see > http://www.ietf.org/IESG/APPEALS/appeal-iesg-poor-rfc-3066.txt for the full > text). The need for this change was discovered during IESG > evaluation of the document. > > Mr. Morfin claims that the change to the example 'concerns the core issue of > the RFC 3066 bis doctrine (the private-use space) through the correction of > a supposed "typo"'. The IESG has reviewed both the proposed text change and > the appeal provided by Mr. Morfin. After careful consideration the IESG has > determined that the proposed text change is a minor correction to an > informative example that does not alter the normative specification in any > way. > > The decision of the working group chair and Area Advisor to correct this > error using a note to the RFC Editor is upheld. The appeal is denied. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 15:07:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec755-0004Ma-5T; Tue, 15 Nov 2005 15:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec752-0004HF-NM for ltru@megatron.ietf.org; Tue, 15 Nov 2005 15:07:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23092 for ; Tue, 15 Nov 2005 15:06:28 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7MJ-0001gg-SE for ltru@ietf.org; Tue, 15 Nov 2005 15:24:53 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAFK6jTs020870 for ; Tue, 15 Nov 2005 15:06:45 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAFK6kPd085010 for ; Tue, 15 Nov 2005 15:06:46 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAFK6jPI022986 for ; Tue, 15 Nov 2005 15:06:46 -0500 Received: from [127.0.0.1] (sig-9-48-120-126.mts.ibm.com [9.48.120.126]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAFK6iTS022899; Tue, 15 Nov 2005 15:06:45 -0500 Message-ID: <437A3FD3.5010008@icu-project.org> Date: Tue, 15 Nov 2005 12:06:43 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] draft-06 of matching prototype... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org We could consider that, but... If I lookup "*" and "fr" and "en" are available, which gets returned? Can't have that kind of indeterminacy in lookup in the spec. So if we want to take that approach, then I suggest the following mapping: 1. Remove all trailing "-*" strings. 2. Remove "-*" for the script if there is Suppress Script 3. If the tag has any remaining "*", then it cannot be mapped. If the range was part of a priority list, then ignore it for lookup. If there are no values left, then the lookup fails (or returns the default value). An implementation may (MAY?) chose not to do #3 if it has a mechanism for prioritizing lookups. [Add note in Security section that such behavior that causes differences between implementations may be open to security problems.] Mark Addison Phillips wrote: >>I really like the restructuring. Interesting how much value it is just >>to introduce terminology like 'filtering'; it will make the situation >>much clearer to users. >> >> >[Addison Phillips] > >I thought it worked out pretty well. > > >>What I think it also makes clear is that we shouldn't be including >>3.2.2. Extended Range Lookup. A lookup has to give a precise, single >>answer whenever there are a number of possible matches. The formulation >>that the draft gives does not distinguish in priority among matching >>items. >> >> >[Addison Phillips] > >I agree, although I would take a different approach. > >For HTTP in particular, the Accept-Language header might be used for both filtering and lookup applications. It would be useful I think to specify a mapping from Extended to Basic Language Ranges in the (sole) Lookup scheme. > >I think the mapping works thusly: > >1. If the Extended Language Range starts with "*", then the Basic Language Range is "*". > >2. Otherwise, remove any "*" subtags and their associated trailing "-" if it exists. > >Thus a request for: > > "*-US" => "*" > "en-*-US" => "en-US" > "sr-*-CS" => "sr-CS" > "sl-*-*-nedis" => "sl-nedis" > "de-*-1901" => "de-1901" > "de-*" => "de" > >Best Regards, > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 15:33:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7Ud-0005EM-W4; Tue, 15 Nov 2005 15:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7Uc-00057P-JV for ltru@megatron.ietf.org; Tue, 15 Nov 2005 15:33:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24433 for ; Tue, 15 Nov 2005 15:32:50 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7lq-0002Oo-Qu for ltru@ietf.org; Tue, 15 Nov 2005 15:51:15 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 12:33:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06 of matching prototype... Date: Tue, 15 Nov 2005 12:33:05 -0800 Message-ID: Thread-Topic: [Ltru] draft-06 of matching prototype... Thread-Index: AcXqIB9KBQJZ9RdHS7SNlzW5sQrIqgAABGpQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 15 Nov 2005 20:33:07.0672 (UTC) FILETIME=[C995CD80:01C5EA23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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="===============0058563999==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0058563999== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlIHJhbmdlICIqIiBtZWFucyAiZGVmYXVsdCIuIFNpbmNlIGl0IG1hdGNoZXMgYW55dGhpbmcs IHRoZXJlIGlzIG5vIG90aGVyIGJhc2lzIG9uIHdoaWNoIHRvIGNob29zZS4gRGVmYXVsdCBpcyBp bXBsZW1lbnRhdGlvbiBkZWZpbmVkLiBCb3RoIG9mIHRoZXNlIHRoaW5ncyByZWFsbHkgc2hvdWxk IGJlIGFkZGVkIHRvIHRoZSBCYXNpYyBSYW5nZSBMb29rdXAgc2NoZW1lICh0aGF0ICIqIiBtZWFu cyAiZGVmYXVsdCIgYW5kIHRoYXQgdGhlIGRlZmF1bHQgaXMgaW1wbGVtZW50YXRpb24gZGVmaW5l ZCBvciB0aGUgZW1wdHkgdGFnKS4NCg0KSSBzdHJvbmdseSBkaXNsaWtlIHlvdXIgIzIgYW5kICMz LiBJIHRoaW5rIG15IGFwcHJvYWNoIHdhcyBjbGVhbmVyIGFuZCBtb3JlIGxvZ2ljYWxseSBjb25z aXN0ZW50Lg0KDQpJZiBhIHRhZyBoYXMgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBhbmQgemVy byBvciBtb3JlIG90aGVyIHN1YnRhZ3MsIHRoaXMgaXMgZW5vdWdoIHRvIGdldCBpbnRvIHRoZSBs b2dpY2FsIGZhbGxiYWNrIHBhdHRlcm4gaW4gYSBjb25zaXN0ZW50IG1hbm5lci4gTm90aWNlIHRo YXQgYSAiKiIgY2FuIGJlIG9taXR0ZWQgaW4gYW4gRXh0ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2UuICJl bi1VUyIgaXMgY29uc2lkZXJlZCBlcXVpdmFsZW50IHRvICJlbi0qLVVTIi4gDQoNCkNvbnNpZGVy IHRoaXMgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdDoNCg0KICAgZW4tKi1VUywgZnI7IHE9MC44DQoN CkNsZWFybHkgSSB3b3VsZCBleHBlY3QgdG8gc2VlICJlbi1VUyIgb3IgImVuIiBjb250ZW50IGJl Zm9yZSBzZWVpbmcgRnJlbmNoLiBNeSBhbGdvcml0aG0gcHJvZHVjZXMgYm90aCAoYnV0IG5vdCAi ZW4tQnJhaSIgb3IgImVuLUxhdG4tVVMiKS4gWW91ciBhbGdvcml0aG0gcHJvZHVjZXMgdGhlIHNh bWUgcmVzdWx0LCBzbyB0aGVuIGxldCdzIGNvbnNpZGVyOg0KDQogIGVuLSosIGZyOyBxPTAuOA0K DQpNeSB2ZXJzaW9uIHN0aWxsIHByb2R1Y2VzICJlbiIgYmVmb3JlICJmciIgKGJ1dCBub3QgImVu LVVTIikuIFlvdXIncyBwcm9kdWNlcyAiZnIiLiBNaW5lIGlzIGxvZ2ljYWwgdG8gdGhlIGVuZCB1 c2VyOiB0aGV5IHdhbnRlZCAiYW55IGZsYXZvciBvZiBFbmdsaXNoIiBhbmQgdGhleSBnb3QgdGhl IGdlbmVyaWMgRW5nbGlzaC4NCg0KTGV0J3MgZGl2ZSBkZWVwZXIgc3RpbGwuIENvbnNpZGVyOg0K DQogIGRlLSotMTkwMSwgZnI7IHE9MC44IC8vICogaW4gYm90aCBzY3JpcHQgYW5kIHJlZ2lvbiBw b3NpdGlvbg0KDQpOb3cgbXkgdmVyc2lvbiBwcm9kdWNlcyAiZGUtMTkwMSIgYW5kICJkZSIgYmVm b3JlICJmciIgKGJ1dCBub3QsIGZvciBleGFtcGxlLCAiZGUtQ0gtMTkwMSIpLCB3aGlsZSB5b3Vy J3MgcHJvZHVjZXMgImZyIiBpbW1lZGlhdGVseS4NCg0KVGh1cyB0aGUgc2FtZSByZXF1ZXN0IGNh biBiZSB1c2VkIHRvIGZ1bGZpbGwgYm90aCBsb29rdXAgYW5kIGZpbHRlcmluZyBhcHBsaWNhdGlv biBuZWVkcyB3aXRoIHJlc3VsdHMgY29uc2lzdGVudCBmb3IgKmJvdGgqLg0KDQpOb3cgbGV0J3Mg Y29uc2lkZXIgdGhpcyByZXF1ZXN0Og0KDQogICotVVMsIGZyOyBxPTAuOA0KDQpIZXJlIGlzIHdo ZXJlIHdlIHdvdWxkIG5lZWQgdG8gYWRkIG9uZSB0d2lzdCB0byBteSBwcm9wb3NhbDogaWYgdGhl IHJhbmdlIGlzICIqIiBhbmQgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGhhcyBiZWVuIHN1cHBs aWVkLCBnbyB0byB0aGUgbmV4dCBpdGVtIGJlZm9yZSByZXR1cm5pbmcgdGhlIGRlZmF1bHQgY29u dGVudC4NCg0KSWYgeW91IHRoaW5rIGFib3V0IGl0LCB0aGUgcmVxdWVzdCBhYm92ZSBpcyAiZ2l2 ZSBtZSBhbnkgZGlhbGVjdCB1c2VkIGluIHRoZSBVU0EgYW5kLCBpZiBub3QgYXZhaWxhYmxlLCBn aXZlIG1lIEZyZW5jaCIuIFRoYXQgcmVxdWVzdCBjb3VsZCBqdXN0IGFzIGVhc2lseSByZXR1cm4g InpoLUhhbnQtVVMiIG9yICJzZ24tVVMiIGFzICJlbi1VUyI6IGl0IGlzIGVzc2VudGlhbGx5IGEg aG9wZWxlc3MgcmVxdWVzdCBmb3IgYW55dGhpbmcgZXhjZXB0IGZpbHRlcmluZy4gSW4gdGhpcyBj YXNlLCB0cmVhdGluZyAiKi1VUyIgYXMgImRlZmF1bHQiIGFuZCBza2lwcGluZyB0byBGcmVuY2gg Z2l2ZXMgYSBmYWxsYmFjayBwYXR0ZXJuIG9mOg0KDQogIDEuIGZyDQogIDIuIChkZWZhdWx0IG9y IGVtcHR5IHRhZykNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQ LiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCklu dGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1 cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmsgRGF2aXMg W21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NCj4gU2VudDogMjAwNeW5tDEx5pyI MTXml6UgMTI6MDcNCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6IExUUlUgV29ya2luZyBH cm91cA0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIGRyYWZ0LTA2IG9mIG1hdGNoaW5nIHByb3RvdHlw ZS4uLg0KPiANCj4gV2UgY291bGQgY29uc2lkZXIgdGhhdCwgYnV0Li4uDQo+IA0KPiBJZiBJIGxv b2t1cCAiKiIgYW5kICJmciIgYW5kICJlbiIgYXJlIGF2YWlsYWJsZSwgd2hpY2ggZ2V0cyByZXR1 cm5lZD8NCj4gQ2FuJ3QgaGF2ZSB0aGF0IGtpbmQgb2YgaW5kZXRlcm1pbmFjeSBpbiBsb29rdXAg aW4gdGhlIHNwZWMuIFNvIGlmIHdlDQo+IHdhbnQgdG8gdGFrZSB0aGF0IGFwcHJvYWNoLCB0aGVu IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIG1hcHBpbmc6DQo+IA0KPiAxLiBSZW1vdmUgYWxsIHRy YWlsaW5nICItKiIgc3RyaW5ncy4NCj4gMi4gUmVtb3ZlICItKiIgZm9yIHRoZSBzY3JpcHQgaWYg dGhlcmUgaXMgU3VwcHJlc3MgU2NyaXB0DQo+IDMuIElmIHRoZSB0YWcgaGFzIGFueSByZW1haW5p bmcgIioiLCB0aGVuIGl0IGNhbm5vdCBiZSBtYXBwZWQuIElmIHRoZQ0KPiByYW5nZSB3YXMgcGFy dCBvZiBhIHByaW9yaXR5IGxpc3QsIHRoZW4gaWdub3JlIGl0IGZvciBsb29rdXAuIElmIHRoZXJl DQo+IGFyZSBubyB2YWx1ZXMgbGVmdCwgdGhlbiB0aGUgbG9va3VwIGZhaWxzIChvciByZXR1cm5z IHRoZSBkZWZhdWx0IHZhbHVlKS4NCj4gDQo+IEFuIGltcGxlbWVudGF0aW9uIG1heSAoTUFZPykg Y2hvc2Ugbm90IHRvIGRvICMzIGlmIGl0IGhhcyBhIG1lY2hhbmlzbQ0KPiBmb3IgcHJpb3JpdGl6 aW5nIGxvb2t1cHMuDQo+IA0KPiBbQWRkIG5vdGUgaW4gU2VjdXJpdHkgc2VjdGlvbiB0aGF0IHN1 Y2ggYmVoYXZpb3IgdGhhdCBjYXVzZXMgZGlmZmVyZW5jZXMNCj4gYmV0d2VlbiBpbXBsZW1lbnRh dGlvbnMgbWF5IGJlIG9wZW4gdG8gc2VjdXJpdHkgcHJvYmxlbXMuXQ0KPiANCj4gTWFyaw0KPiAN Cj4gQWRkaXNvbiBQaGlsbGlwcyB3cm90ZToNCj4gDQo+ID4+SSByZWFsbHkgbGlrZSB0aGUgcmVz dHJ1Y3R1cmluZy4gSW50ZXJlc3RpbmcgaG93IG11Y2ggdmFsdWUgaXQgaXMganVzdA0KPiA+PnRv IGludHJvZHVjZSB0ZXJtaW5vbG9neSBsaWtlICdmaWx0ZXJpbmcnOyBpdCB3aWxsIG1ha2UgdGhl IHNpdHVhdGlvbg0KPiA+Pm11Y2ggY2xlYXJlciB0byB1c2Vycy4NCj4gPj4NCj4gPj4NCj4gPltB ZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5JIHRob3VnaHQgaXQgd29ya2VkIG91dCBwcmV0dHkg d2VsbC4NCj4gPg0KPiA+DQo+ID4+V2hhdCBJIHRoaW5rIGl0IGFsc28gbWFrZXMgY2xlYXIgaXMg dGhhdCB3ZSBzaG91bGRuJ3QgYmUgaW5jbHVkaW5nDQo+ID4+My4yLjIuIEV4dGVuZGVkIFJhbmdl IExvb2t1cC4gQSBsb29rdXAgaGFzIHRvIGdpdmUgYSBwcmVjaXNlLCBzaW5nbGUNCj4gPj5hbnN3 ZXIgd2hlbmV2ZXIgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBvc3NpYmxlIG1hdGNoZXMuIFRoZSBm b3JtdWxhdGlvbg0KPiA+PnRoYXQgdGhlIGRyYWZ0IGdpdmVzIGRvZXMgbm90IGRpc3Rpbmd1aXNo IGluIHByaW9yaXR5IGFtb25nIG1hdGNoaW5nDQo+ID4+aXRlbXMuDQo+ID4+DQo+ID4+DQo+ID5b QWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SSBhZ3JlZSwgYWx0aG91Z2ggSSB3b3VsZCB0YWtl IGEgZGlmZmVyZW50IGFwcHJvYWNoLg0KPiA+DQo+ID5Gb3IgSFRUUCBpbiBwYXJ0aWN1bGFyLCB0 aGUgQWNjZXB0LUxhbmd1YWdlIGhlYWRlciBtaWdodCBiZSB1c2VkIGZvciBib3RoDQo+IGZpbHRl cmluZyBhbmQgbG9va3VwIGFwcGxpY2F0aW9ucy4gSXQgd291bGQgYmUgdXNlZnVsIEkgdGhpbmsg dG8gc3BlY2lmeSBhDQo+IG1hcHBpbmcgZnJvbSBFeHRlbmRlZCB0byBCYXNpYyBMYW5ndWFnZSBS YW5nZXMgaW4gdGhlIChzb2xlKSBMb29rdXAgc2NoZW1lLg0KPiA+DQo+ID5JIHRoaW5rIHRoZSBt YXBwaW5nIHdvcmtzIHRodXNseToNCj4gPg0KPiA+MS4gSWYgdGhlIEV4dGVuZGVkIExhbmd1YWdl IFJhbmdlIHN0YXJ0cyB3aXRoICIqIiwgdGhlbiB0aGUgQmFzaWMNCj4gTGFuZ3VhZ2UgUmFuZ2Ug aXMgIioiLg0KPiA+DQo+ID4yLiBPdGhlcndpc2UsIHJlbW92ZSBhbnkgIioiIHN1YnRhZ3MgYW5k IHRoZWlyIGFzc29jaWF0ZWQgdHJhaWxpbmcgIi0iIGlmDQo+IGl0IGV4aXN0cy4NCj4gPg0KPiA+ VGh1cyBhIHJlcXVlc3QgZm9yOg0KPiA+DQo+ID4gICIqLVVTIiA9PiAiKiINCj4gPiAgImVuLSot VVMiID0+ICJlbi1VUyINCj4gPiAgInNyLSotQ1MiID0+ICJzci1DUyINCj4gPiAgInNsLSotKi1u ZWRpcyIgPT4gInNsLW5lZGlzIg0KPiA+ICAiZGUtKi0xOTAxIiA9PiAiZGUtMTkwMSINCj4gPiAg ImRlLSoiID0+ICJkZSINCj4gPg0KPiA+QmVzdCBSZWdhcmRzLA0KPiA+DQo+ID5BZGRpc29uDQo+ ID4NCj4gPkFkZGlzb24gUC4gUGhpbGxpcHMNCj4gPkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KPiA+DQo+ID5JbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0 dXJlLg0KPiA+SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ID4NCg0K --===============0058563999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0058563999==-- From ltru-bounces@ietf.org Tue Nov 15 15:51:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7lr-0002ea-Vx; Tue, 15 Nov 2005 15:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7lr-0002eS-6M for ltru@megatron.ietf.org; Tue, 15 Nov 2005 15:51:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25364 for ; Tue, 15 Nov 2005 15:50:42 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec838-00031J-R8 for ltru@ietf.org; Tue, 15 Nov 2005 16:09:08 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECAD72596DF; Tue, 15 Nov 2005 21:50:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30478-02; Tue, 15 Nov 2005 21:50:35 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FD8E2596DD; Tue, 15 Nov 2005 21:50:33 +0100 (CET) Date: Tue, 15 Nov 2005 12:43:05 -0800 From: Harald Tveit Alvestrand To: Scott Hollenbeck , "'Addison Phillips'" Subject: Obsoleting links (RE: [Ltru] Re: Approval of two ltru documents) Message-ID: <3D57F18810A83A0ED63944CE@B50854F0A9192E8EC6CDA126> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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="===============0940954359==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0940954359== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========EB6FCA266A475778519C==========" --==========EB6FCA266A475778519C========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 15. november 2005 12:45 -0500 Scott Hollenbeck =20 wrote: >> There is a historical precedent to the contrary: RFC 3066 and >> RFC 3282. >> >> They both obsolete RFC 1766, the BCP 47 of its time. On >> different days. > > That wouldn't happen today. Frankly it appears to be an error. How can > 3282 obsolete something that has already been obsoleted by 3066? It was a long discussion.... 3282 and 3066 together obsoleted everything in = 1766, but none of them obsoleted all of 1766. The conclusion at the time was that the term "obsoletes" is a much too=20 blunt instrument to show the true relationship between documents, and that=20 "obsoletes" links from both documents was slightly less false than=20 "updates" links from both documents (which was the other alternative=20 fielded) - but that there was no marking using only "obsoletes", "obsoleted = by", "updates" and "updated by" in the RFC Index that was completely = "true". That experience was part of the impetus for the idea of "ISD" (see newtrk). Harald --==========EB6FCA266A475778519C========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDekhZOMj+2+WY0F4RApycAJ9IyvOntV3c0Zia3HnEXTCxKw14qwCgx+Zc T6fPqcwWm+Kqaijh10YbOX4= =EK6F -----END PGP SIGNATURE----- --==========EB6FCA266A475778519C==========-- --===============0940954359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0940954359==-- From ltru-bounces@ietf.org Tue Nov 15 18:29:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAFH-0005go-G2; Tue, 15 Nov 2005 18:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAFF-0005fP-Sx for ltru@megatron.ietf.org; Tue, 15 Nov 2005 18:29:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05967 for ; Tue, 15 Nov 2005 18:29:12 -0500 (EST) Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcAWZ-000887-V8 for ltru@ietf.org; Tue, 15 Nov 2005 18:47:40 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAFNTYcY013036 for ; Tue, 15 Nov 2005 18:29:34 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAFNUo0i070526 for ; Tue, 15 Nov 2005 16:30:50 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAFNTY80028432 for ; Tue, 15 Nov 2005 16:29:34 -0700 Received: from [127.0.0.1] (sig-9-48-123-119.mts.ibm.com [9.48.123.119]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAFNTWfx028409; Tue, 15 Nov 2005 16:29:33 -0700 Message-ID: <437A6F5B.3070103@icu-project.org> Date: Tue, 15 Nov 2005 15:29:31 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] draft-06 of matching prototype... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id jAFNTYcY013036 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org My main concern is that I don't think it is very well defined. It is=20 still approaching it from a filtering point of view, and not a lookup=20 point of view. What happens when you have *-US and you have en no fr pt What do you get? If you can come up with a reasonable answer, then I can = see keeping the section. But I don't see an obvious answer. Mark Addison Phillips wrote: >The range "*" means "default". Since it matches anything, there is no ot= her basis on which to choose. Default is implementation defined. Both of = these things really should be added to the Basic Range Lookup scheme (tha= t "*" means "default" and that the default is implementation defined or t= he empty tag). > >I strongly dislike your #2 and #3. I think my approach was cleaner and m= ore logically consistent. > >If a tag has a primary language subtag and zero or more other subtags, t= his is enough to get into the logical fallback pattern in a consistent ma= nner. Notice that a "*" can be omitted in an Extended Language Range. "en= -US" is considered equivalent to "en-*-US".=20 > >Consider this language priority list: > > en-*-US, fr; q=3D0.8 > >Clearly I would expect to see "en-US" or "en" content before seeing Fren= ch. My algorithm produces both (but not "en-Brai" or "en-Latn-US"). Your = algorithm produces the same result, so then let's consider: > > en-*, fr; q=3D0.8 > >My version still produces "en" before "fr" (but not "en-US"). Your's pro= duces "fr". Mine is logical to the end user: they wanted "any flavor of E= nglish" and they got the generic English. > >Let's dive deeper still. Consider: > > de-*-1901, fr; q=3D0.8 // * in both script and region position > >Now my version produces "de-1901" and "de" before "fr" (but not, for exa= mple, "de-CH-1901"), while your's produces "fr" immediately. > >Thus the same request can be used to fulfill both lookup and filtering a= pplication needs with results consistent for *both*. > >Now let's consider this request: > > *-US, fr; q=3D0.8 > >Here is where we would need to add one twist to my proposal: if the rang= e is "*" and a language priority list has been supplied, go to the next i= tem before returning the default content. > >If you think about it, the request above is "give me any dialect used in= the USA and, if not available, give me French". That request could just = as easily return "zh-Hant-US" or "sgn-US" as "en-US": it is essentially a= hopeless request for anything except filtering. In this case, treating "= *-US" as "default" and skipping to French gives a fallback pattern of: > > 1. fr > 2. (default or empty tag) > >What do you think? > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B411=E6=9C=8815=E6=97=A5 12:07 >>To: Addison Phillips >>Cc: LTRU Working Group >>Subject: Re: [Ltru] draft-06 of matching prototype... >> >>We could consider that, but... >> >>If I lookup "*" and "fr" and "en" are available, which gets returned? >>Can't have that kind of indeterminacy in lookup in the spec. So if we >>want to take that approach, then I suggest the following mapping: >> >>1. Remove all trailing "-*" strings. >>2. Remove "-*" for the script if there is Suppress Script >>3. If the tag has any remaining "*", then it cannot be mapped. If the >>range was part of a priority list, then ignore it for lookup. If there >>are no values left, then the lookup fails (or returns the default value= ). >> >>An implementation may (MAY?) chose not to do #3 if it has a mechanism >>for prioritizing lookups. >> >>[Add note in Security section that such behavior that causes difference= s >>between implementations may be open to security problems.] >> >>Mark >> >>Addison Phillips wrote: >> >> =20 >> >>>>I really like the restructuring. Interesting how much value it is jus= t >>>>to introduce terminology like 'filtering'; it will make the situation >>>>much clearer to users. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I thought it worked out pretty well. >>> >>> >>> =20 >>> >>>>What I think it also makes clear is that we shouldn't be including >>>>3.2.2. Extended Range Lookup. A lookup has to give a precise, single >>>>answer whenever there are a number of possible matches. The formulati= on >>>>that the draft gives does not distinguish in priority among matching >>>>items. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I agree, although I would take a different approach. >>> >>>For HTTP in particular, the Accept-Language header might be used for b= oth >>> =20 >>> >>filtering and lookup applications. It would be useful I think to specif= y a >>mapping from Extended to Basic Language Ranges in the (sole) Lookup sch= eme. >> =20 >> >>>I think the mapping works thusly: >>> >>>1. If the Extended Language Range starts with "*", then the Basic >>> =20 >>> >>Language Range is "*". >> =20 >> >>>2. Otherwise, remove any "*" subtags and their associated trailing "-"= if >>> =20 >>> >>it exists. >> =20 >> >>>Thus a request for: >>> >>> "*-US" =3D> "*" >>> "en-*-US" =3D> "en-US" >>> "sr-*-CS" =3D> "sr-CS" >>> "sl-*-*-nedis" =3D> "sl-nedis" >>> "de-*-1901" =3D> "de-1901" >>> "de-*" =3D> "de" >>> >>>Best Regards, >>> >>>Addison >>> >>>Addison P. Phillips >>>Globalization Architect, Quest Software >>> >>>Internationalization is not a feature. >>>It is an architecture. >>> >>> >>> =20 >>> > > =20 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 15 18:49:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAYm-0004Ik-FQ; Tue, 15 Nov 2005 18:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAYl-0004Hg-Kn for ltru@megatron.ietf.org; Tue, 15 Nov 2005 18:49:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07527 for ; Tue, 15 Nov 2005 18:49:19 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcAq0-0000NM-0y for ltru@ietf.org; Tue, 15 Nov 2005 19:07:44 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 15:49:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06 of matching prototype... Date: Tue, 15 Nov 2005 15:49:33 -0800 Message-ID: Thread-Topic: [Ltru] draft-06 of matching prototype... Thread-Index: AcXqPHIO6+igRrsETBOmPu0uTMPCNgAAR4uQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 15 Nov 2005 23:49:34.0272 (UTC) FILETIME=[3AF23C00:01C5EA3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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="===============1393932349==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1393932349== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 WW91J3JlIG1pc3Npbmcgd2hhdCBJIHNhaWQsIEkgdGhpbmsuIFdlIGFyZSBzYXlpbmcgdGhlIHNh bWUgdGhpbmcuIEknbSBtZXJlbHkgc3VnZ2VzdGluZyB0aGF0IGhvdyB3ZSBoYW5kbGUgdGhlIGxh bmd1YWdlIHByaW9yaXR5IGxpc3QgYmUgZGlmZmVyZW50LiBZb3VyIHN1Z2dlc3Rpb24gcmVzdWx0 cyBpbiB0d28gYmVoYXZpb3JzIHRoYXQgSSB0aGluayBhcmUgdW5kZXNpcmFibGU6DQoNCjEuIFRo ZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZydzIHJlY29yZCBoYXMgdG8gYmUgbG9va2VkIHVwIGlu IHRoZSByZWdpc3RyeSAodG8gc2VlIGlmIGl0IGhhcyBhIFN1cHByZXNzLVNjcmlwdCkuDQoyLiBN b3N0IHJhbmdlcyB0aGF0IGNvbnRhaW4gYSAiKiIgYXJlIHNraXBwZWQgaW5zdGVhZCBvZiBiZWlu ZyBpbmNsdWRlZCBpbiB0aGUgZmFsbGJhY2suDQoNCkkgc2FpZCwgaW5kZWVkLCBnZXQgcmlkIG9m ICJFeHRlbmRlZCBSYW5nZSBMb29rdXAiIGFuZCBoYXZlIG9ubHkgKHdoYXQgYW1vdW50cyB0bykg IkJhc2ljIFJhbmdlIExvb2t1cCIuDQoNClRoZSB0YWcgIiotVVMiIG1hdGNoZXMgd2hpY2hldmVy IGFtb25nIHRoZSBzZXQgImVuIi8ibm8iLyJmciIvInB0IiBpcyB0aGUgZGVmYXVsdCAoaS5lLiBp dCBtYXRjaGVzICIiKS4NCg0KSSBkb24ndCB0aGluayBJJ20gbG9va2luZyBhdCBpdCBhcyBmaWx0 ZXJpbmcuIEknbSBsb29raW5nIHN0cmljdGx5IHRvIHdyaXRlIHdoYXQgdGhlIGZhbGxiYWNrIHBh dHRlcm4gaXMuIFRoaXMgd29ya3MgYmV0dGVyIChJJ20gdHJ5aW5nIHRvIHNob3cpIGlmIHlvdSBk byBOT1Qgc2tpcCBhbGwgdmFsdWVzIHRoYXQgY29udGFpbiBhIHdpbGRjYXJkIChleGNlcHQgaW4g dGhlIGZpcnN0IHBvc2l0aW9uKS4NCg0KTGV0J3Mgc3RhdGUgaXQgYSBkaWZmZXJlbnQgd2F5LiBJ bWFnaW5lIEkgcmVxdWVzdDoNCg0KICAgemgNCg0KYW5kIHlvdSBoYXZlOg0KDQplbg0Kbm8NCmZy DQpwdA0KDQpROiBXaGF0IGdldHMgcmV0dXJuZWQgdGhlbj8NCkE6IFdoYXRldmVyIHRoZSBkZWZh dWx0IGNvbnRlbnQgaXMuDQoNClNvIGEgcmVxdWVzdCBmb3IgIiotVVMiIGluIG15IHByb3Bvc2Fs IGlzIHRoZSBzYW1lIGFzICIqIiAoZXNzZW50aWFsbHksIG5vdGhpbmcpLiBXZSBkb24ndCBkZWZp bmUgd2hhdCB0aGUgZGVmYXVsdCBjb250ZW50IGlzLCBiZWNhdXNlIGl0IGlzIHByb2JhYmx5IHVz ZXIgZGVmaW5lZC4NCg0KRG9lcyB0aGF0IG1ha2UgbW9yZSBzZW5zZT8NCg0KQWRkaXNvbg0KDQpB ZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdh cmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFy ayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KPiBTZW50OiAyMDA1 5bm0MTHmnIgxNeaXpSAxNTozMA0KPiBUbzogQWRkaXNvbiBQaGlsbGlwcw0KPiBDYzogTFRSVSBX b3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gZHJhZnQtMDYgb2YgbWF0Y2hpbmcg cHJvdG90eXBlLi4uDQo+IA0KPiBNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBJIGRvbid0IHRoaW5r IGl0IGlzIHZlcnkgd2VsbCBkZWZpbmVkLiBJdCBpcw0KPiBzdGlsbCBhcHByb2FjaGluZyBpdCBm cm9tIGEgZmlsdGVyaW5nIHBvaW50IG9mIHZpZXcsIGFuZCBub3QgYSBsb29rdXANCj4gcG9pbnQg b2Ygdmlldy4gV2hhdCBoYXBwZW5zIHdoZW4geW91IGhhdmUNCj4gDQo+ICotVVMNCj4gDQo+IGFu ZCB5b3UgaGF2ZQ0KPiANCj4gZW4NCj4gbm8NCj4gZnINCj4gcHQNCj4gDQo+IFdoYXQgZG8geW91 IGdldD8gSWYgeW91IGNhbiBjb21lIHVwIHdpdGggYSByZWFzb25hYmxlIGFuc3dlciwgdGhlbiBJ IGNhbg0KPiBzZWUga2VlcGluZyB0aGUgc2VjdGlvbi4gQnV0IEkgZG9uJ3Qgc2VlIGFuIG9idmlv dXMgYW5zd2VyLg0KPiANCj4gTWFyaw0KPiANCj4gDQo+IEFkZGlzb24gUGhpbGxpcHMgd3JvdGU6 DQo+IA0KPiA+VGhlIHJhbmdlICIqIiBtZWFucyAiZGVmYXVsdCIuIFNpbmNlIGl0IG1hdGNoZXMg YW55dGhpbmcsIHRoZXJlIGlzIG5vDQo+IG90aGVyIGJhc2lzIG9uIHdoaWNoIHRvIGNob29zZS4g RGVmYXVsdCBpcyBpbXBsZW1lbnRhdGlvbiBkZWZpbmVkLiBCb3RoIG9mDQo+IHRoZXNlIHRoaW5n cyByZWFsbHkgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBCYXNpYyBSYW5nZSBMb29rdXAgc2NoZW1l ICh0aGF0DQo+ICIqIiBtZWFucyAiZGVmYXVsdCIgYW5kIHRoYXQgdGhlIGRlZmF1bHQgaXMgaW1w bGVtZW50YXRpb24gZGVmaW5lZCBvciB0aGUNCj4gZW1wdHkgdGFnKS4NCj4gPg0KPiA+SSBzdHJv bmdseSBkaXNsaWtlIHlvdXIgIzIgYW5kICMzLiBJIHRoaW5rIG15IGFwcHJvYWNoIHdhcyBjbGVh bmVyIGFuZA0KPiBtb3JlIGxvZ2ljYWxseSBjb25zaXN0ZW50Lg0KPiA+DQo+ID5JZiBhIHRhZyBo YXMgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBhbmQgemVybyBvciBtb3JlIG90aGVyIHN1YnRh Z3MsDQo+IHRoaXMgaXMgZW5vdWdoIHRvIGdldCBpbnRvIHRoZSBsb2dpY2FsIGZhbGxiYWNrIHBh dHRlcm4gaW4gYSBjb25zaXN0ZW50DQo+IG1hbm5lci4gTm90aWNlIHRoYXQgYSAiKiIgY2FuIGJl IG9taXR0ZWQgaW4gYW4gRXh0ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2UuDQo+ICJlbi1VUyIgaXMgY29u c2lkZXJlZCBlcXVpdmFsZW50IHRvICJlbi0qLVVTIi4NCj4gPg0KPiA+Q29uc2lkZXIgdGhpcyBs YW5ndWFnZSBwcmlvcml0eSBsaXN0Og0KPiA+DQo+ID4gICBlbi0qLVVTLCBmcjsgcT0wLjgNCj4g Pg0KPiA+Q2xlYXJseSBJIHdvdWxkIGV4cGVjdCB0byBzZWUgImVuLVVTIiBvciAiZW4iIGNvbnRl bnQgYmVmb3JlIHNlZWluZw0KPiBGcmVuY2guIE15IGFsZ29yaXRobSBwcm9kdWNlcyBib3RoIChi dXQgbm90ICJlbi1CcmFpIiBvciAiZW4tTGF0bi1VUyIpLg0KPiBZb3VyIGFsZ29yaXRobSBwcm9k dWNlcyB0aGUgc2FtZSByZXN1bHQsIHNvIHRoZW4gbGV0J3MgY29uc2lkZXI6DQo+ID4NCj4gPiAg ZW4tKiwgZnI7IHE9MC44DQo+ID4NCj4gPk15IHZlcnNpb24gc3RpbGwgcHJvZHVjZXMgImVuIiBi ZWZvcmUgImZyIiAoYnV0IG5vdCAiZW4tVVMiKS4gWW91cidzDQo+IHByb2R1Y2VzICJmciIuIE1p bmUgaXMgbG9naWNhbCB0byB0aGUgZW5kIHVzZXI6IHRoZXkgd2FudGVkICJhbnkgZmxhdm9yIG9m DQo+IEVuZ2xpc2giIGFuZCB0aGV5IGdvdCB0aGUgZ2VuZXJpYyBFbmdsaXNoLg0KPiA+DQo+ID5M ZXQncyBkaXZlIGRlZXBlciBzdGlsbC4gQ29uc2lkZXI6DQo+ID4NCj4gPiAgZGUtKi0xOTAxLCBm cjsgcT0wLjggLy8gKiBpbiBib3RoIHNjcmlwdCBhbmQgcmVnaW9uIHBvc2l0aW9uDQo+ID4NCj4g Pk5vdyBteSB2ZXJzaW9uIHByb2R1Y2VzICJkZS0xOTAxIiBhbmQgImRlIiBiZWZvcmUgImZyIiAo YnV0IG5vdCwgZm9yDQo+IGV4YW1wbGUsICJkZS1DSC0xOTAxIiksIHdoaWxlIHlvdXIncyBwcm9k dWNlcyAiZnIiIGltbWVkaWF0ZWx5Lg0KPiA+DQo+ID5UaHVzIHRoZSBzYW1lIHJlcXVlc3QgY2Fu IGJlIHVzZWQgdG8gZnVsZmlsbCBib3RoIGxvb2t1cCBhbmQgZmlsdGVyaW5nDQo+IGFwcGxpY2F0 aW9uIG5lZWRzIHdpdGggcmVzdWx0cyBjb25zaXN0ZW50IGZvciAqYm90aCouDQo+ID4NCj4gPk5v dyBsZXQncyBjb25zaWRlciB0aGlzIHJlcXVlc3Q6DQo+ID4NCj4gPiAgKi1VUywgZnI7IHE9MC44 DQo+ID4NCj4gPkhlcmUgaXMgd2hlcmUgd2Ugd291bGQgbmVlZCB0byBhZGQgb25lIHR3aXN0IHRv IG15IHByb3Bvc2FsOiBpZiB0aGUgcmFuZ2UNCj4gaXMgIioiIGFuZCBhIGxhbmd1YWdlIHByaW9y aXR5IGxpc3QgaGFzIGJlZW4gc3VwcGxpZWQsIGdvIHRvIHRoZSBuZXh0IGl0ZW0NCj4gYmVmb3Jl IHJldHVybmluZyB0aGUgZGVmYXVsdCBjb250ZW50Lg0KPiA+DQo+ID5JZiB5b3UgdGhpbmsgYWJv dXQgaXQsIHRoZSByZXF1ZXN0IGFib3ZlIGlzICJnaXZlIG1lIGFueSBkaWFsZWN0IHVzZWQgaW4N Cj4gdGhlIFVTQSBhbmQsIGlmIG5vdCBhdmFpbGFibGUsIGdpdmUgbWUgRnJlbmNoIi4gVGhhdCBy ZXF1ZXN0IGNvdWxkIGp1c3QgYXMNCj4gZWFzaWx5IHJldHVybiAiemgtSGFudC1VUyIgb3IgInNn bi1VUyIgYXMgImVuLVVTIjogaXQgaXMgZXNzZW50aWFsbHkgYQ0KPiBob3BlbGVzcyByZXF1ZXN0 IGZvciBhbnl0aGluZyBleGNlcHQgZmlsdGVyaW5nLiBJbiB0aGlzIGNhc2UsIHRyZWF0aW5nICIq LQ0KPiBVUyIgYXMgImRlZmF1bHQiIGFuZCBza2lwcGluZyB0byBGcmVuY2ggZ2l2ZXMgYSBmYWxs YmFjayBwYXR0ZXJuIG9mOg0KPiA+DQo+ID4gIDEuIGZyDQo+ID4gIDIuIChkZWZhdWx0IG9yIGVt cHR5IHRhZykNCj4gPg0KPiA+V2hhdCBkbyB5b3UgdGhpbms/DQo+ID4NCj4gPkFkZGlzb24NCj4g Pg0KPiA+QWRkaXNvbiBQLiBQaGlsbGlwcw0KPiA+R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQo+ID4NCj4gPkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1 cmUuDQo+ID5JdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQo+ID4NCj4gPg0KPiA+DQo+ID4+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj5Gcm9tOiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5k YXZpc0BpY3UtcHJvamVjdC5vcmddDQo+ID4+U2VudDogMjAwNeW5tDEx5pyIMTXml6UgMTI6MDcN Cj4gPj5UbzogQWRkaXNvbiBQaGlsbGlwcw0KPiA+PkNjOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4g Pj5TdWJqZWN0OiBSZTogW0x0cnVdIGRyYWZ0LTA2IG9mIG1hdGNoaW5nIHByb3RvdHlwZS4uLg0K PiA+Pg0KPiA+PldlIGNvdWxkIGNvbnNpZGVyIHRoYXQsIGJ1dC4uLg0KPiA+Pg0KPiA+PklmIEkg bG9va3VwICIqIiBhbmQgImZyIiBhbmQgImVuIiBhcmUgYXZhaWxhYmxlLCB3aGljaCBnZXRzIHJl dHVybmVkPw0KPiA+PkNhbid0IGhhdmUgdGhhdCBraW5kIG9mIGluZGV0ZXJtaW5hY3kgaW4gbG9v a3VwIGluIHRoZSBzcGVjLiBTbyBpZiB3ZQ0KPiA+PndhbnQgdG8gdGFrZSB0aGF0IGFwcHJvYWNo LCB0aGVuIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIG1hcHBpbmc6DQo+ID4+DQo+ID4+MS4gUmVt b3ZlIGFsbCB0cmFpbGluZyAiLSoiIHN0cmluZ3MuDQo+ID4+Mi4gUmVtb3ZlICItKiIgZm9yIHRo ZSBzY3JpcHQgaWYgdGhlcmUgaXMgU3VwcHJlc3MgU2NyaXB0DQo+ID4+My4gSWYgdGhlIHRhZyBo YXMgYW55IHJlbWFpbmluZyAiKiIsIHRoZW4gaXQgY2Fubm90IGJlIG1hcHBlZC4gSWYgdGhlDQo+ ID4+cmFuZ2Ugd2FzIHBhcnQgb2YgYSBwcmlvcml0eSBsaXN0LCB0aGVuIGlnbm9yZSBpdCBmb3Ig bG9va3VwLiBJZiB0aGVyZQ0KPiA+PmFyZSBubyB2YWx1ZXMgbGVmdCwgdGhlbiB0aGUgbG9va3Vw IGZhaWxzIChvciByZXR1cm5zIHRoZSBkZWZhdWx0IHZhbHVlKS4NCj4gPj4NCj4gPj5BbiBpbXBs ZW1lbnRhdGlvbiBtYXkgKE1BWT8pIGNob3NlIG5vdCB0byBkbyAjMyBpZiBpdCBoYXMgYSBtZWNo YW5pc20NCj4gPj5mb3IgcHJpb3JpdGl6aW5nIGxvb2t1cHMuDQo+ID4+DQo+ID4+W0FkZCBub3Rl IGluIFNlY3VyaXR5IHNlY3Rpb24gdGhhdCBzdWNoIGJlaGF2aW9yIHRoYXQgY2F1c2VzIGRpZmZl cmVuY2VzDQo+ID4+YmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMgbWF5IGJlIG9wZW4gdG8gc2VjdXJp dHkgcHJvYmxlbXMuXQ0KPiA+Pg0KPiA+Pk1hcmsNCj4gPj4NCj4gPj5BZGRpc29uIFBoaWxsaXBz IHdyb3RlOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4+SSByZWFsbHkgbGlrZSB0aGUgcmVzdHJ1 Y3R1cmluZy4gSW50ZXJlc3RpbmcgaG93IG11Y2ggdmFsdWUgaXQgaXMganVzdA0KPiA+Pj4+dG8g aW50cm9kdWNlIHRlcm1pbm9sb2d5IGxpa2UgJ2ZpbHRlcmluZyc7IGl0IHdpbGwgbWFrZSB0aGUg c2l0dWF0aW9uDQo+ID4+Pj5tdWNoIGNsZWFyZXIgdG8gdXNlcnMuDQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4NCj4gPj4+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4+Pg0KPiA+Pj5JIHRo b3VnaHQgaXQgd29ya2VkIG91dCBwcmV0dHkgd2VsbC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pj5XaGF0IEkgdGhpbmsgaXQgYWxzbyBtYWtlcyBjbGVhciBpcyB0aGF0IHdlIHNo b3VsZG4ndCBiZSBpbmNsdWRpbmcNCj4gPj4+PjMuMi4yLiBFeHRlbmRlZCBSYW5nZSBMb29rdXAu IEEgbG9va3VwIGhhcyB0byBnaXZlIGEgcHJlY2lzZSwgc2luZ2xlDQo+ID4+Pj5hbnN3ZXIgd2hl bmV2ZXIgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBvc3NpYmxlIG1hdGNoZXMuIFRoZQ0KPiBmb3Jt dWxhdGlvbg0KPiA+Pj4+dGhhdCB0aGUgZHJhZnQgZ2l2ZXMgZG9lcyBub3QgZGlzdGluZ3Vpc2gg aW4gcHJpb3JpdHkgYW1vbmcgbWF0Y2hpbmcNCj4gPj4+Pml0ZW1zLg0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+PltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+Pj4NCj4gPj4+SSBh Z3JlZSwgYWx0aG91Z2ggSSB3b3VsZCB0YWtlIGEgZGlmZmVyZW50IGFwcHJvYWNoLg0KPiA+Pj4N Cj4gPj4+Rm9yIEhUVFAgaW4gcGFydGljdWxhciwgdGhlIEFjY2VwdC1MYW5ndWFnZSBoZWFkZXIg bWlnaHQgYmUgdXNlZCBmb3INCj4gYm90aA0KPiA+Pj4NCj4gPj4+DQo+ID4+ZmlsdGVyaW5nIGFu ZCBsb29rdXAgYXBwbGljYXRpb25zLiBJdCB3b3VsZCBiZSB1c2VmdWwgSSB0aGluayB0byBzcGVj aWZ5DQo+IGENCj4gPj5tYXBwaW5nIGZyb20gRXh0ZW5kZWQgdG8gQmFzaWMgTGFuZ3VhZ2UgUmFu Z2VzIGluIHRoZSAoc29sZSkgTG9va3VwDQo+IHNjaGVtZS4NCj4gPj4NCj4gPj4NCj4gPj4+SSB0 aGluayB0aGUgbWFwcGluZyB3b3JrcyB0aHVzbHk6DQo+ID4+Pg0KPiA+Pj4xLiBJZiB0aGUgRXh0 ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2Ugc3RhcnRzIHdpdGggIioiLCB0aGVuIHRoZSBCYXNpYw0KPiA+ Pj4NCj4gPj4+DQo+ID4+TGFuZ3VhZ2UgUmFuZ2UgaXMgIioiLg0KPiA+Pg0KPiA+Pg0KPiA+Pj4y LiBPdGhlcndpc2UsIHJlbW92ZSBhbnkgIioiIHN1YnRhZ3MgYW5kIHRoZWlyIGFzc29jaWF0ZWQg dHJhaWxpbmcgIi0iDQo+IGlmDQo+ID4+Pg0KPiA+Pj4NCj4gPj5pdCBleGlzdHMuDQo+ID4+DQo+ ID4+DQo+ID4+PlRodXMgYSByZXF1ZXN0IGZvcjoNCj4gPj4+DQo+ID4+PiAiKi1VUyIgPT4gIioi DQo+ID4+PiAiZW4tKi1VUyIgPT4gImVuLVVTIg0KPiA+Pj4gInNyLSotQ1MiID0+ICJzci1DUyIN Cj4gPj4+ICJzbC0qLSotbmVkaXMiID0+ICJzbC1uZWRpcyINCj4gPj4+ICJkZS0qLTE5MDEiID0+ ICJkZS0xOTAxIg0KPiA+Pj4gImRlLSoiID0+ICJkZSINCj4gPj4+DQo+ID4+PkJlc3QgUmVnYXJk cywNCj4gPj4+DQo+ID4+PkFkZGlzb24NCj4gPj4+DQo+ID4+PkFkZGlzb24gUC4gUGhpbGxpcHMN Cj4gPj4+R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQo+ID4+Pg0KPiA+ Pj5JbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiA+Pj5JdCBpcyBhbiBh cmNoaXRlY3R1cmUuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+DQo+ID4NCj4gPg0K DQo= --===============1393932349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1393932349==-- From ltru-bounces@ietf.org Tue Nov 15 20:43:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCKI-0007F7-Nd; Tue, 15 Nov 2005 20:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCKH-0007Ev-MA for ltru@megatron.ietf.org; Tue, 15 Nov 2005 20:43:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17876 for ; Tue, 15 Nov 2005 20:42:31 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcCba-0005ED-Hp for ltru@ietf.org; Tue, 15 Nov 2005 21:00:59 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 17:42:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06 of matching prototype... Date: Tue, 15 Nov 2005 17:42:42 -0800 Message-ID: Thread-Topic: [Ltru] draft-06 of matching prototype... Thread-Index: AcXqPHIO6+igRrsETBOmPu0uTMPCNgAAR4uQAARZgnA= From: "Addison Phillips" To: "Addison Phillips" , "Mark Davis" X-OriginalArrivalTime: 16 Nov 2005 01:42:44.0397 (UTC) FILETIME=[0A2D15D0:01C5EA4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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="===============0444223065==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0444223065== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VG8gaWxsdXN0cmF0ZS4uLiBJIHVwZGF0ZWQgZHJhZnQtMDYgb24gdGhlIGludGVyLWxvY2FsZSBz aXRlLiBUYWtlIGEgbG9vayBhdCB0aGF0IHRleHQgYW5kIHNlZSBob3cgeW91J2QgY2hhbmdlIGl0 Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0 ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0 dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBBZGRpc29uIFBoaWxsaXBzDQo+IFNlbnQ6IDIwMDXl ubQxMeaciDE15pelIDE1OjUwDQo+IFRvOiBNYXJrIERhdmlzDQo+IENjOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogUkU6IFtMdHJ1XSBkcmFmdC0wNiBvZiBtYXRjaGluZyBwcm90b3R5 cGUuLi4NCj4gDQo+IFlvdSdyZSBtaXNzaW5nIHdoYXQgSSBzYWlkLCBJIHRoaW5rLiBXZSBhcmUg c2F5aW5nIHRoZSBzYW1lIHRoaW5nLiBJJ20NCj4gbWVyZWx5IHN1Z2dlc3RpbmcgdGhhdCBob3cg d2UgaGFuZGxlIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGJlDQo+IGRpZmZlcmVudC4gWW91 ciBzdWdnZXN0aW9uIHJlc3VsdHMgaW4gdHdvIGJlaGF2aW9ycyB0aGF0IEkgdGhpbmsgYXJlDQo+ IHVuZGVzaXJhYmxlOg0KPiANCj4gMS4gVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnJ3MgcmVj b3JkIGhhcyB0byBiZSBsb29rZWQgdXAgaW4gdGhlDQo+IHJlZ2lzdHJ5ICh0byBzZWUgaWYgaXQg aGFzIGEgU3VwcHJlc3MtU2NyaXB0KS4NCj4gMi4gTW9zdCByYW5nZXMgdGhhdCBjb250YWluIGEg IioiIGFyZSBza2lwcGVkIGluc3RlYWQgb2YgYmVpbmcgaW5jbHVkZWQgaW4NCj4gdGhlIGZhbGxi YWNrLg0KPiANCj4gSSBzYWlkLCBpbmRlZWQsIGdldCByaWQgb2YgIkV4dGVuZGVkIFJhbmdlIExv b2t1cCIgYW5kIGhhdmUgb25seSAod2hhdA0KPiBhbW91bnRzIHRvKSAiQmFzaWMgUmFuZ2UgTG9v a3VwIi4NCj4gDQo+IFRoZSB0YWcgIiotVVMiIG1hdGNoZXMgd2hpY2hldmVyIGFtb25nIHRoZSBz ZXQgImVuIi8ibm8iLyJmciIvInB0IiBpcyB0aGUNCj4gZGVmYXVsdCAoaS5lLiBpdCBtYXRjaGVz ICIiKS4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgSSdtIGxvb2tpbmcgYXQgaXQgYXMgZmlsdGVyaW5n LiBJJ20gbG9va2luZyBzdHJpY3RseSB0bw0KPiB3cml0ZSB3aGF0IHRoZSBmYWxsYmFjayBwYXR0 ZXJuIGlzLiBUaGlzIHdvcmtzIGJldHRlciAoSSdtIHRyeWluZyB0byBzaG93KQ0KPiBpZiB5b3Ug ZG8gTk9UIHNraXAgYWxsIHZhbHVlcyB0aGF0IGNvbnRhaW4gYSB3aWxkY2FyZCAoZXhjZXB0IGlu IHRoZSBmaXJzdA0KPiBwb3NpdGlvbikuDQo+IA0KPiBMZXQncyBzdGF0ZSBpdCBhIGRpZmZlcmVu dCB3YXkuIEltYWdpbmUgSSByZXF1ZXN0Og0KPiANCj4gICAgemgNCj4gDQo+IGFuZCB5b3UgaGF2 ZToNCj4gDQo+IGVuDQo+IG5vDQo+IGZyDQo+IHB0DQo+IA0KPiBROiBXaGF0IGdldHMgcmV0dXJu ZWQgdGhlbj8NCj4gQTogV2hhdGV2ZXIgdGhlIGRlZmF1bHQgY29udGVudCBpcy4NCj4gDQo+IFNv IGEgcmVxdWVzdCBmb3IgIiotVVMiIGluIG15IHByb3Bvc2FsIGlzIHRoZSBzYW1lIGFzICIqIiAo ZXNzZW50aWFsbHksDQo+IG5vdGhpbmcpLiBXZSBkb24ndCBkZWZpbmUgd2hhdCB0aGUgZGVmYXVs dCBjb250ZW50IGlzLCBiZWNhdXNlIGl0IGlzDQo+IHByb2JhYmx5IHVzZXIgZGVmaW5lZC4NCj4g DQo+IERvZXMgdGhhdCBtYWtlIG1vcmUgc2Vuc2U/DQo+IA0KPiBBZGRpc29uDQo+IA0KPiBBZGRp c29uIFAuIFBoaWxsaXBzDQo+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2Fy ZQ0KPiANCj4gSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCj4gSXQgaXMg YW4gYXJjaGl0ZWN0dXJlLg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ IEZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NCj4g PiBTZW50OiAyMDA15bm0MTHmnIgxNeaXpSAxNTozMA0KPiA+IFRvOiBBZGRpc29uIFBoaWxsaXBz DQo+ID4gQ2M6IExUUlUgV29ya2luZyBHcm91cA0KPiA+IFN1YmplY3Q6IFJlOiBbTHRydV0gZHJh ZnQtMDYgb2YgbWF0Y2hpbmcgcHJvdG90eXBlLi4uDQo+ID4NCj4gPiBNeSBtYWluIGNvbmNlcm4g aXMgdGhhdCBJIGRvbid0IHRoaW5rIGl0IGlzIHZlcnkgd2VsbCBkZWZpbmVkLiBJdCBpcw0KPiA+ IHN0aWxsIGFwcHJvYWNoaW5nIGl0IGZyb20gYSBmaWx0ZXJpbmcgcG9pbnQgb2YgdmlldywgYW5k IG5vdCBhIGxvb2t1cA0KPiA+IHBvaW50IG9mIHZpZXcuIFdoYXQgaGFwcGVucyB3aGVuIHlvdSBo YXZlDQo+ID4NCj4gPiAqLVVTDQo+ID4NCj4gPiBhbmQgeW91IGhhdmUNCj4gPg0KPiA+IGVuDQo+ ID4gbm8NCj4gPiBmcg0KPiA+IHB0DQo+ID4NCj4gPiBXaGF0IGRvIHlvdSBnZXQ/IElmIHlvdSBj YW4gY29tZSB1cCB3aXRoIGEgcmVhc29uYWJsZSBhbnN3ZXIsIHRoZW4gSSBjYW4NCj4gPiBzZWUg a2VlcGluZyB0aGUgc2VjdGlvbi4gQnV0IEkgZG9uJ3Qgc2VlIGFuIG9idmlvdXMgYW5zd2VyLg0K PiA+DQo+ID4gTWFyaw0KPiA+DQo+ID4NCj4gPiBBZGRpc29uIFBoaWxsaXBzIHdyb3RlOg0KPiA+ DQo+ID4gPlRoZSByYW5nZSAiKiIgbWVhbnMgImRlZmF1bHQiLiBTaW5jZSBpdCBtYXRjaGVzIGFu eXRoaW5nLCB0aGVyZSBpcyBubw0KPiA+IG90aGVyIGJhc2lzIG9uIHdoaWNoIHRvIGNob29zZS4g RGVmYXVsdCBpcyBpbXBsZW1lbnRhdGlvbiBkZWZpbmVkLiBCb3RoDQo+IG9mDQo+ID4gdGhlc2Ug dGhpbmdzIHJlYWxseSBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIEJhc2ljIFJhbmdlIExvb2t1cCBz Y2hlbWUNCj4gKHRoYXQNCj4gPiAiKiIgbWVhbnMgImRlZmF1bHQiIGFuZCB0aGF0IHRoZSBkZWZh dWx0IGlzIGltcGxlbWVudGF0aW9uIGRlZmluZWQgb3INCj4gdGhlDQo+ID4gZW1wdHkgdGFnKS4N Cj4gPiA+DQo+ID4gPkkgc3Ryb25nbHkgZGlzbGlrZSB5b3VyICMyIGFuZCAjMy4gSSB0aGluayBt eSBhcHByb2FjaCB3YXMgY2xlYW5lciBhbmQNCj4gPiBtb3JlIGxvZ2ljYWxseSBjb25zaXN0ZW50 Lg0KPiA+ID4NCj4gPiA+SWYgYSB0YWcgaGFzIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgYW5k IHplcm8gb3IgbW9yZSBvdGhlciBzdWJ0YWdzLA0KPiA+IHRoaXMgaXMgZW5vdWdoIHRvIGdldCBp bnRvIHRoZSBsb2dpY2FsIGZhbGxiYWNrIHBhdHRlcm4gaW4gYSBjb25zaXN0ZW50DQo+ID4gbWFu bmVyLiBOb3RpY2UgdGhhdCBhICIqIiBjYW4gYmUgb21pdHRlZCBpbiBhbiBFeHRlbmRlZCBMYW5n dWFnZSBSYW5nZS4NCj4gPiAiZW4tVVMiIGlzIGNvbnNpZGVyZWQgZXF1aXZhbGVudCB0byAiZW4t Ki1VUyIuDQo+ID4gPg0KPiA+ID5Db25zaWRlciB0aGlzIGxhbmd1YWdlIHByaW9yaXR5IGxpc3Q6 DQo+ID4gPg0KPiA+ID4gICBlbi0qLVVTLCBmcjsgcT0wLjgNCj4gPiA+DQo+ID4gPkNsZWFybHkg SSB3b3VsZCBleHBlY3QgdG8gc2VlICJlbi1VUyIgb3IgImVuIiBjb250ZW50IGJlZm9yZSBzZWVp bmcNCj4gPiBGcmVuY2guIE15IGFsZ29yaXRobSBwcm9kdWNlcyBib3RoIChidXQgbm90ICJlbi1C cmFpIiBvciAiZW4tTGF0bi1VUyIpLg0KPiA+IFlvdXIgYWxnb3JpdGhtIHByb2R1Y2VzIHRoZSBz YW1lIHJlc3VsdCwgc28gdGhlbiBsZXQncyBjb25zaWRlcjoNCj4gPiA+DQo+ID4gPiAgZW4tKiwg ZnI7IHE9MC44DQo+ID4gPg0KPiA+ID5NeSB2ZXJzaW9uIHN0aWxsIHByb2R1Y2VzICJlbiIgYmVm b3JlICJmciIgKGJ1dCBub3QgImVuLVVTIikuIFlvdXIncw0KPiA+IHByb2R1Y2VzICJmciIuIE1p bmUgaXMgbG9naWNhbCB0byB0aGUgZW5kIHVzZXI6IHRoZXkgd2FudGVkICJhbnkgZmxhdm9yDQo+ IG9mDQo+ID4gRW5nbGlzaCIgYW5kIHRoZXkgZ290IHRoZSBnZW5lcmljIEVuZ2xpc2guDQo+ID4g Pg0KPiA+ID5MZXQncyBkaXZlIGRlZXBlciBzdGlsbC4gQ29uc2lkZXI6DQo+ID4gPg0KPiA+ID4g IGRlLSotMTkwMSwgZnI7IHE9MC44IC8vICogaW4gYm90aCBzY3JpcHQgYW5kIHJlZ2lvbiBwb3Np dGlvbg0KPiA+ID4NCj4gPiA+Tm93IG15IHZlcnNpb24gcHJvZHVjZXMgImRlLTE5MDEiIGFuZCAi ZGUiIGJlZm9yZSAiZnIiIChidXQgbm90LCBmb3INCj4gPiBleGFtcGxlLCAiZGUtQ0gtMTkwMSIp LCB3aGlsZSB5b3VyJ3MgcHJvZHVjZXMgImZyIiBpbW1lZGlhdGVseS4NCj4gPiA+DQo+ID4gPlRo dXMgdGhlIHNhbWUgcmVxdWVzdCBjYW4gYmUgdXNlZCB0byBmdWxmaWxsIGJvdGggbG9va3VwIGFu ZCBmaWx0ZXJpbmcNCj4gPiBhcHBsaWNhdGlvbiBuZWVkcyB3aXRoIHJlc3VsdHMgY29uc2lzdGVu dCBmb3IgKmJvdGgqLg0KPiA+ID4NCj4gPiA+Tm93IGxldCdzIGNvbnNpZGVyIHRoaXMgcmVxdWVz dDoNCj4gPiA+DQo+ID4gPiAgKi1VUywgZnI7IHE9MC44DQo+ID4gPg0KPiA+ID5IZXJlIGlzIHdo ZXJlIHdlIHdvdWxkIG5lZWQgdG8gYWRkIG9uZSB0d2lzdCB0byBteSBwcm9wb3NhbDogaWYgdGhl DQo+IHJhbmdlDQo+ID4gaXMgIioiIGFuZCBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgaGFzIGJl ZW4gc3VwcGxpZWQsIGdvIHRvIHRoZSBuZXh0DQo+IGl0ZW0NCj4gPiBiZWZvcmUgcmV0dXJuaW5n IHRoZSBkZWZhdWx0IGNvbnRlbnQuDQo+ID4gPg0KPiA+ID5JZiB5b3UgdGhpbmsgYWJvdXQgaXQs IHRoZSByZXF1ZXN0IGFib3ZlIGlzICJnaXZlIG1lIGFueSBkaWFsZWN0IHVzZWQNCj4gaW4NCj4g PiB0aGUgVVNBIGFuZCwgaWYgbm90IGF2YWlsYWJsZSwgZ2l2ZSBtZSBGcmVuY2giLiBUaGF0IHJl cXVlc3QgY291bGQganVzdA0KPiBhcw0KPiA+IGVhc2lseSByZXR1cm4gInpoLUhhbnQtVVMiIG9y ICJzZ24tVVMiIGFzICJlbi1VUyI6IGl0IGlzIGVzc2VudGlhbGx5IGENCj4gPiBob3BlbGVzcyBy ZXF1ZXN0IGZvciBhbnl0aGluZyBleGNlcHQgZmlsdGVyaW5nLiBJbiB0aGlzIGNhc2UsIHRyZWF0 aW5nDQo+ICIqLQ0KPiA+IFVTIiBhcyAiZGVmYXVsdCIgYW5kIHNraXBwaW5nIHRvIEZyZW5jaCBn aXZlcyBhIGZhbGxiYWNrIHBhdHRlcm4gb2Y6DQo+ID4gPg0KPiA+ID4gIDEuIGZyDQo+ID4gPiAg Mi4gKGRlZmF1bHQgb3IgZW1wdHkgdGFnKQ0KPiA+ID4NCj4gPiA+V2hhdCBkbyB5b3UgdGhpbms/ DQo+ID4gPg0KPiA+ID5BZGRpc29uDQo+ID4gPg0KPiA+ID5BZGRpc29uIFAuIFBoaWxsaXBzDQo+ ID4gPkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KPiA+ID4NCj4gPiA+ SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCj4gPiA+SXQgaXMgYW4gYXJj aGl0ZWN0dXJlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+PkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1w cm9qZWN0Lm9yZ10NCj4gPiA+PlNlbnQ6IDIwMDXlubQxMeaciDE15pelIDEyOjA3DQo+ID4gPj5U bzogQWRkaXNvbiBQaGlsbGlwcw0KPiA+ID4+Q2M6IExUUlUgV29ya2luZyBHcm91cA0KPiA+ID4+ U3ViamVjdDogUmU6IFtMdHJ1XSBkcmFmdC0wNiBvZiBtYXRjaGluZyBwcm90b3R5cGUuLi4NCj4g PiA+Pg0KPiA+ID4+V2UgY291bGQgY29uc2lkZXIgdGhhdCwgYnV0Li4uDQo+ID4gPj4NCj4gPiA+ PklmIEkgbG9va3VwICIqIiBhbmQgImZyIiBhbmQgImVuIiBhcmUgYXZhaWxhYmxlLCB3aGljaCBn ZXRzIHJldHVybmVkPw0KPiA+ID4+Q2FuJ3QgaGF2ZSB0aGF0IGtpbmQgb2YgaW5kZXRlcm1pbmFj eSBpbiBsb29rdXAgaW4gdGhlIHNwZWMuIFNvIGlmIHdlDQo+ID4gPj53YW50IHRvIHRha2UgdGhh dCBhcHByb2FjaCwgdGhlbiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBtYXBwaW5nOg0KPiA+ID4+ DQo+ID4gPj4xLiBSZW1vdmUgYWxsIHRyYWlsaW5nICItKiIgc3RyaW5ncy4NCj4gPiA+PjIuIFJl bW92ZSAiLSoiIGZvciB0aGUgc2NyaXB0IGlmIHRoZXJlIGlzIFN1cHByZXNzIFNjcmlwdA0KPiA+ ID4+My4gSWYgdGhlIHRhZyBoYXMgYW55IHJlbWFpbmluZyAiKiIsIHRoZW4gaXQgY2Fubm90IGJl IG1hcHBlZC4gSWYgdGhlDQo+ID4gPj5yYW5nZSB3YXMgcGFydCBvZiBhIHByaW9yaXR5IGxpc3Qs IHRoZW4gaWdub3JlIGl0IGZvciBsb29rdXAuIElmIHRoZXJlDQo+ID4gPj5hcmUgbm8gdmFsdWVz IGxlZnQsIHRoZW4gdGhlIGxvb2t1cCBmYWlscyAob3IgcmV0dXJucyB0aGUgZGVmYXVsdA0KPiB2 YWx1ZSkuDQo+ID4gPj4NCj4gPiA+PkFuIGltcGxlbWVudGF0aW9uIG1heSAoTUFZPykgY2hvc2Ug bm90IHRvIGRvICMzIGlmIGl0IGhhcyBhIG1lY2hhbmlzbQ0KPiA+ID4+Zm9yIHByaW9yaXRpemlu ZyBsb29rdXBzLg0KPiA+ID4+DQo+ID4gPj5bQWRkIG5vdGUgaW4gU2VjdXJpdHkgc2VjdGlvbiB0 aGF0IHN1Y2ggYmVoYXZpb3IgdGhhdCBjYXVzZXMNCj4gZGlmZmVyZW5jZXMNCj4gPiA+PmJldHdl ZW4gaW1wbGVtZW50YXRpb25zIG1heSBiZSBvcGVuIHRvIHNlY3VyaXR5IHByb2JsZW1zLl0NCj4g PiA+Pg0KPiA+ID4+TWFyaw0KPiA+ID4+DQo+ID4gPj5BZGRpc29uIFBoaWxsaXBzIHdyb3RlOg0K PiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+Pj5JIHJlYWxseSBsaWtlIHRoZSByZXN0cnVj dHVyaW5nLiBJbnRlcmVzdGluZyBob3cgbXVjaCB2YWx1ZSBpdCBpcw0KPiBqdXN0DQo+ID4gPj4+ PnRvIGludHJvZHVjZSB0ZXJtaW5vbG9neSBsaWtlICdmaWx0ZXJpbmcnOyBpdCB3aWxsIG1ha2Ug dGhlDQo+IHNpdHVhdGlvbg0KPiA+ID4+Pj5tdWNoIGNsZWFyZXIgdG8gdXNlcnMuDQo+ID4gPj4+ Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+PltBZGRpc29uIFBoaWxsaXBz XQ0KPiA+ID4+Pg0KPiA+ID4+PkkgdGhvdWdodCBpdCB3b3JrZWQgb3V0IHByZXR0eSB3ZWxsLg0K PiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pj5XaGF0IEkgdGhpbmsg aXQgYWxzbyBtYWtlcyBjbGVhciBpcyB0aGF0IHdlIHNob3VsZG4ndCBiZSBpbmNsdWRpbmcNCj4g PiA+Pj4+My4yLjIuIEV4dGVuZGVkIFJhbmdlIExvb2t1cC4gQSBsb29rdXAgaGFzIHRvIGdpdmUg YSBwcmVjaXNlLCBzaW5nbGUNCj4gPiA+Pj4+YW5zd2VyIHdoZW5ldmVyIHRoZXJlIGFyZSBhIG51 bWJlciBvZiBwb3NzaWJsZSBtYXRjaGVzLiBUaGUNCj4gPiBmb3JtdWxhdGlvbg0KPiA+ID4+Pj50 aGF0IHRoZSBkcmFmdCBnaXZlcyBkb2VzIG5vdCBkaXN0aW5ndWlzaCBpbiBwcmlvcml0eSBhbW9u ZyBtYXRjaGluZw0KPiA+ID4+Pj5pdGVtcy4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4N Cj4gPiA+Pj4+DQo+ID4gPj4+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4gPj4+DQo+ID4gPj4+SSBh Z3JlZSwgYWx0aG91Z2ggSSB3b3VsZCB0YWtlIGEgZGlmZmVyZW50IGFwcHJvYWNoLg0KPiA+ID4+ Pg0KPiA+ID4+PkZvciBIVFRQIGluIHBhcnRpY3VsYXIsIHRoZSBBY2NlcHQtTGFuZ3VhZ2UgaGVh ZGVyIG1pZ2h0IGJlIHVzZWQgZm9yDQo+ID4gYm90aA0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+ ZmlsdGVyaW5nIGFuZCBsb29rdXAgYXBwbGljYXRpb25zLiBJdCB3b3VsZCBiZSB1c2VmdWwgSSB0 aGluayB0bw0KPiBzcGVjaWZ5DQo+ID4gYQ0KPiA+ID4+bWFwcGluZyBmcm9tIEV4dGVuZGVkIHRv IEJhc2ljIExhbmd1YWdlIFJhbmdlcyBpbiB0aGUgKHNvbGUpIExvb2t1cA0KPiA+IHNjaGVtZS4N Cj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4+SSB0aGluayB0aGUgbWFwcGluZyB3b3JrcyB0aHVzbHk6 DQo+ID4gPj4+DQo+ID4gPj4+MS4gSWYgdGhlIEV4dGVuZGVkIExhbmd1YWdlIFJhbmdlIHN0YXJ0 cyB3aXRoICIqIiwgdGhlbiB0aGUgQmFzaWMNCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pkxhbmd1 YWdlIFJhbmdlIGlzICIqIi4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4+Mi4gT3RoZXJ3aXNlLCBy ZW1vdmUgYW55ICIqIiBzdWJ0YWdzIGFuZCB0aGVpciBhc3NvY2lhdGVkIHRyYWlsaW5nICItDQo+ ICINCj4gPiBpZg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+aXQgZXhpc3RzLg0KPiA+ID4+DQo+ ID4gPj4NCj4gPiA+Pj5UaHVzIGEgcmVxdWVzdCBmb3I6DQo+ID4gPj4+DQo+ID4gPj4+ICIqLVVT IiA9PiAiKiINCj4gPiA+Pj4gImVuLSotVVMiID0+ICJlbi1VUyINCj4gPiA+Pj4gInNyLSotQ1Mi ID0+ICJzci1DUyINCj4gPiA+Pj4gInNsLSotKi1uZWRpcyIgPT4gInNsLW5lZGlzIg0KPiA+ID4+ PiAiZGUtKi0xOTAxIiA9PiAiZGUtMTkwMSINCj4gPiA+Pj4gImRlLSoiID0+ICJkZSINCj4gPiA+ Pj4NCj4gPiA+Pj5CZXN0IFJlZ2FyZHMsDQo+ID4gPj4+DQo+ID4gPj4+QWRkaXNvbg0KPiA+ID4+ Pg0KPiA+ID4+PkFkZGlzb24gUC4gUGhpbGxpcHMNCj4gPiA+Pj5HbG9iYWxpemF0aW9uIEFyY2hp dGVjdCwgUXVlc3QgU29mdHdhcmUNCj4gPiA+Pj4NCj4gPiA+Pj5JbnRlcm5hdGlvbmFsaXphdGlv biBpcyBub3QgYSBmZWF0dXJlLg0KPiA+ID4+Pkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCj4gPiA+ Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCg0K --===============0444223065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0444223065==-- From ltru-bounces@ietf.org Wed Nov 16 01:29:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcGnZ-0000AD-I7; Wed, 16 Nov 2005 01:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcGnY-0000A5-CI for ltru@megatron.ietf.org; Wed, 16 Nov 2005 01:29:36 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03255 for ; Wed, 16 Nov 2005 01:29:01 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EcGcS-0006XG-Th for ltru@lists.ietf.org; Wed, 16 Nov 2005 07:18:19 +0100 Received: from pd9fbad17.dip0.t-ipconnect.de ([217.251.173.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 07:18:08 +0100 Received: from nobody by pd9fbad17.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 07:18:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 16 Nov 2005 07:06:08 +0100 Organization: Lines: 25 Message-ID: <437ACC4F.7ECD@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: pd9fbad17.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Approval of two ltru documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I agree that we should just finish the matching work, given > that the IESG didn't buy my argument to separate the two, > avoid the whole issue and quit griping about it. Wasn't only you, I also supported to split it. Apparently "they" think that Bruce got it right, and our idea was wrong. Saying so in an RfC editor note is a bit late, because now we got no review from Bruce - he has the knack to find all bugs. > More to the point: would draft-matching become a part of the > new BCP 47? Scott's answer: "Both will become BCP 47" Ugly. Brian's "discovery" that BCPs could cover more than one RfC is rather new. IMNSHO this is no "feature". > a potential 3066ter being held up by an artificial need to > revise draft-matching. You have extlang-ranges, so at least the syntax is clear. Bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 01:31:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcGpX-0000oN-9a; Wed, 16 Nov 2005 01:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcGpV-0000oB-Fx for ltru@megatron.ietf.org; Wed, 16 Nov 2005 01:31:37 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03332 for ; Wed, 16 Nov 2005 01:31:03 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EcGjd-00084E-4n for ltru@lists.ietf.org; Wed, 16 Nov 2005 07:25:35 +0100 Received: from pd9fbad17.dip0.t-ipconnect.de ([217.251.173.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 07:25:33 +0100 Received: from nobody by pd9fbad17.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 07:25:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 16 Nov 2005 07:22:31 +0100 Organization: Lines: 10 Message-ID: <437AD027.4ADC@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: pd9fbad17.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Approval of two ltru documents X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > That's kind of weird You're not forced to accept it. Late updates via "RfC editor notes" are a weak point in the process. They could also add it as an "IESG note" if you don't like it. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 04:55:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0q-0003DH-3L; Wed, 16 Nov 2005 04:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0o-0003CW-7s for ltru@megatron.ietf.org; Wed, 16 Nov 2005 04:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13697 for ; Wed, 16 Nov 2005 04:54:55 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcKIB-00020l-Li for ltru@ietf.org; Wed, 16 Nov 2005 05:13:28 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAG9tEu20927 for ; Wed, 16 Nov 2005 18:55:14 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 4d7a_159b72e6_5687_11da_8402_0030482533a1; Wed, 16 Nov 2005 18:55:13 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAG9r937009615 for ; Wed, 16 Nov 2005 18:54:49 +0900 Message-Id: <6.0.0.20.2.20051116182437.0795dec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Nov 2005 18:43:28 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching: choice of schemes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [This is a technical contribution, mostly motivated by my long experience with how other WGs use specs.] The section on choice of matching schemes has been moved closer to the front of the document. This is good. But there are some, in many ways serious, problems. I think they are serious because in many ways, this is the most important section of this draft: Other WGs creating protocols and formats, and application designers, ideally should be able to go to that section, read it, and then reference the section that they have identified as being the most appropriate for their usage case, and be done with it. Of course, we as experts hope that others will study this draft in detail, but that's generally not going to happen. What will happen most often is A) a WG or so just picks a scheme based on their first impression, because they want to move on, or B) a WG gets entangled into long discussions because it's not really clear from our draft what is best for them. While I understand that there is a limit in the advice we can give, I think we definitely can and should try our best to make sure we give as much advice as we can, and make it as clear as possible. So here are my specific comments: First, make sure we have a (sub)section entitled "Choice of language matching scheme" (or some such), so that this is easy to find. Second, make sure we discuss all alternatives. In particular, currently the choice between 'filtering' and 'lookup' is given, but the choice between basic and extended isn't discussed at all. Third, try to use as definitive and precise wording as possible. Ideally, if we have five different schemes, then we would have five paragraphs, each clearly mentioning the conditions and circumstances for chosing that scheme. Fourth, clearly separate the choice of matching scheme from advice like "and you may also think about doing this and that on top of it". This is particular applies to what is currently (in Addison's draft draft) the last paragraph just before section 3.1 (talking about nn/nb/no and zh-CN/zh-Hans). This paragraph only confuses people trying to make their choice. In may view, the best thing we could do with this paragraph is to move it to a section entitled something like "Limitations of Matching Schemes" or so, somewhere in the "Others" section. Fifth, the text currently mostly uses the words "implementer" and "implementation". Similar to "application", the first impression this gives is that it's about implementations of (end user) applications. However, our first and foremost concern should be with what is generally called "protocol designers" or "spec writers", and we should chose wording that makes this clear. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 04:55:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0q-0003E4-C7; Wed, 16 Nov 2005 04:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0o-0003Cd-8E for ltru@megatron.ietf.org; Wed, 16 Nov 2005 04:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13709 for ; Wed, 16 Nov 2005 04:54:57 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcKID-00020n-B1 for ltru@ietf.org; Wed, 16 Nov 2005 05:13:30 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAG9tGd00682; Wed, 16 Nov 2005 18:55:16 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1652_16900bda_5687_11da_94b2_00304811fd80; Wed, 16 Nov 2005 18:55:15 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAG9r93B009615; Wed, 16 Nov 2005 18:54:49 +0900 Message-Id: <6.0.0.20.2.20051116175239.0792aec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Nov 2005 18:52:17 +0900 To: "Addison Phillips" , "Mark Davis" From: Martin Duerst Subject: Matching: Filtering and Lookup: What's the fundamental difference (was: RE: [Ltru] draft-06 of matching prototype...) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [This is mostly a technical contribution, plus a tad of 'trying to sit back' to focus the discussion.] In general, I like the improved structure very much. Here, I'd like to closely look at what's the fundamental difference between what's currently called filtering and what's currently called lookup. This is in part motivated by the observation that HTTP language negotiation quite closely fits the "usage profile" (one solution, potential default/fallback) of lookup, but uses the matching pattern of filtering (general ranges match against (potentially) more specific tags). In the draft as currently written, the fundamental difference is presented as: filtering: zero to many results lookup: one result I think that this is actually not the most fundamental difference. I think the most fundamental difference is the following: filtering: most general language range, more specific ones are okay lookup: most specific language range, more general ones are okay (note that with this distinction, the terms may no longer be completely accurate, but I'll still use them for the moment). Remembering the discussion about language negotiation in HTTP (about 8 or 10 years ago), when we worked on the details, I think we came to the conclusion that there were two generally workable ways to do things: 1) Negotiation would work with Accept-Language containing specific ranges matched against potentially more general tags. I.e. requesting en-US would also return en, but requesting en wouldn't return en-US. 2) Negotiation would also work with Accept-Language containing general ranges matched against potetially more specific tags. I.e. requesting en would also return en-us, but requesting en-US wouldn't return en. In both cases, some advice is needed for users. For 1), document providers have to be told to not use overly specific tags (or in case multiple tagging is possible, not overly specific tags only). For 2), end users (or browser makers) have to be told to not request overly specific ranges (or in case multiple ranges can be used, not overly specific ranges only). The HTTP spec in the end went for 2). I don't remember exactly why, probably because some implementations did it that way, or it seemed more natural to the people involved. It may be somewhat more natural, but it's in no way overwhelmingly better. The important conclusion is that you can have it one way or the other, but not both ways. You could say that e.g. a request for en-US matches both en and (made up) en-US-boont, but this means that a lot of stuff is being matched, and the selectivity/ expressiveness of the matching scheme is reduced. In my eyes, whether in the end you chose only one result or whether you end up with a (potentially prioritized) list of results is important for the users of our draft (in their protocol or application, which one they need will be pretty clear), but it is not an intrinsic property of the matching schemes we are defining. Regards, Martin. At 10:42 05/11/16, Addison Phillips wrote: >Content-class: urn:content-classes:message >Content-Type: text/plain;charset="UTF-8" > >To illustrate... I updated draft-06 on the inter-locale site. Take a look >at that text and see how you'd change it. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > >> -----Original Message----- >> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >> Addison Phillips >> Sent: 2005$Bj;%((B11$Bk|/(B5$Bkw!&(B 15:50 >> To: Mark Davis >> Cc: LTRU Working Group >> Subject: RE: [Ltru] draft-06 of matching prototype... >> >> You're missing what I said, I think. We are saying the same thing. I'm >> merely suggesting that how we handle the language priority list be >> different. Your suggestion results in two behaviors that I think are >> undesirable: >> >> 1. The primary language subtag's record has to be looked up in the >> registry (to see if it has a Suppress-Script). >> 2. Most ranges that contain a "*" are skipped instead of being included in >> the fallback. >> >> I said, indeed, get rid of "Extended Range Lookup" and have only (what >> amounts to) "Basic Range Lookup". >> >> The tag "*-US" matches whichever among the set "en"/"no"/"fr"/"pt" is the >> default (i.e. it matches ""). >> >> I don't think I'm looking at it as filtering. I'm looking strictly to >> write what the fallback pattern is. This works better (I'm trying to show) >> if you do NOT skip all values that contain a wildcard (except in the first >> position). >> >> Let's state it a different way. Imagine I request: >> >> zh >> >> and you have: >> >> en >> no >> fr >> pt >> >> Q: What gets returned then? >> A: Whatever the default content is. >> >> So a request for "*-US" in my proposal is the same as "*" (essentially, >> nothing). We don't define what the default content is, because it is >> probably user defined. >> >> Does that make more sense? >> >> Addison >> >> Addison P. Phillips >> Globalization Architect, Quest Software >> >> Internationalization is not a feature. >> It is an architecture. >> >> > -----Original Message----- >> > From: Mark Davis [mailto:mark.davis@icu-project.org] >> > Sent: 2005$Bj;%((B11$Bk|/(B5$Bkw!&(B 15:30 >> > To: Addison Phillips >> > Cc: LTRU Working Group >> > Subject: Re: [Ltru] draft-06 of matching prototype... >> > >> > My main concern is that I don't think it is very well defined. It is >> > still approaching it from a filtering point of view, and not a lookup >> > point of view. What happens when you have >> > >> > *-US >> > >> > and you have >> > >> > en >> > no >> > fr >> > pt >> > >> > What do you get? If you can come up with a reasonable answer, then I can >> > see keeping the section. But I don't see an obvious answer. >> > >> > Mark >> > >> > >> > Addison Phillips wrote: >> > >> > >The range "*" means "default". Since it matches anything, there is no >> > other basis on which to choose. Default is implementation defined. Both >> of >> > these things really should be added to the Basic Range Lookup scheme >> (that >> > "*" means "default" and that the default is implementation defined or >> the >> > empty tag). >> > > >> > >I strongly dislike your #2 and #3. I think my approach was cleaner and >> > more logically consistent. >> > > >> > >If a tag has a primary language subtag and zero or more other subtags, >> > this is enough to get into the logical fallback pattern in a consistent >> > manner. Notice that a "*" can be omitted in an Extended Language Range. >> > "en-US" is considered equivalent to "en-*-US". >> > > >> > >Consider this language priority list: >> > > >> > > en-*-US, fr; q=0.8 >> > > >> > >Clearly I would expect to see "en-US" or "en" content before seeing >> > French. My algorithm produces both (but not "en-Brai" or "en-Latn-US"). >> > Your algorithm produces the same result, so then let's consider: >> > > >> > > en-*, fr; q=0.8 >> > > >> > >My version still produces "en" before "fr" (but not "en-US"). Your's >> > produces "fr". Mine is logical to the end user: they wanted "any flavor >> of >> > English" and they got the generic English. >> > > >> > >Let's dive deeper still. Consider: >> > > >> > > de-*-1901, fr; q=0.8 // * in both script and region position >> > > >> > >Now my version produces "de-1901" and "de" before "fr" (but not, for >> > example, "de-CH-1901"), while your's produces "fr" immediately. >> > > >> > >Thus the same request can be used to fulfill both lookup and filtering >> > application needs with results consistent for *both*. >> > > >> > >Now let's consider this request: >> > > >> > > *-US, fr; q=0.8 >> > > >> > >Here is where we would need to add one twist to my proposal: if the >> range >> > is "*" and a language priority list has been supplied, go to the next >> item >> > before returning the default content. >> > > >> > >If you think about it, the request above is "give me any dialect used >> in >> > the USA and, if not available, give me French". That request could just >> as >> > easily return "zh-Hant-US" or "sgn-US" as "en-US": it is essentially a >> > hopeless request for anything except filtering. In this case, treating >> "*- >> > US" as "default" and skipping to French gives a fallback pattern of: >> > > >> > > 1. fr >> > > 2. (default or empty tag) >> > > >> > >What do you think? >> > > >> > >Addison >> > > >> > >Addison P. Phillips >> > >Globalization Architect, Quest Software >> > > >> > >Internationalization is not a feature. >> > >It is an architecture. >> > > >> > > >> > > >> > >>-----Original Message----- >> > >>From: Mark Davis [mailto:mark.davis@icu-project.org] >> > >>Sent: 2005$Bj;%((B11$Bk|/(B5$Bkw!&(B 12:07 >> > >>To: Addison Phillips >> > >>Cc: LTRU Working Group >> > >>Subject: Re: [Ltru] draft-06 of matching prototype... >> > >> >> > >>We could consider that, but... >> > >> >> > >>If I lookup "*" and "fr" and "en" are available, which gets returned? >> > >>Can't have that kind of indeterminacy in lookup in the spec. So if we >> > >>want to take that approach, then I suggest the following mapping: >> > >> >> > >>1. Remove all trailing "-*" strings. >> > >>2. Remove "-*" for the script if there is Suppress Script >> > >>3. If the tag has any remaining "*", then it cannot be mapped. If the >> > >>range was part of a priority list, then ignore it for lookup. If there >> > >>are no values left, then the lookup fails (or returns the default >> value). >> > >> >> > >>An implementation may (MAY?) chose not to do #3 if it has a mechanism >> > >>for prioritizing lookups. >> > >> >> > >>[Add note in Security section that such behavior that causes >> differences >> > >>between implementations may be open to security problems.] >> > >> >> > >>Mark >> > >> >> > >>Addison Phillips wrote: >> > >> >> > >> >> > >> >> > >>>>I really like the restructuring. Interesting how much value it is >> just >> > >>>>to introduce terminology like 'filtering'; it will make the >> situation >> > >>>>much clearer to users. >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>[Addison Phillips] >> > >>> >> > >>>I thought it worked out pretty well. >> > >>> >> > >>> >> > >>> >> > >>> >> > >>>>What I think it also makes clear is that we shouldn't be including >> > >>>>3.2.2. Extended Range Lookup. A lookup has to give a precise, single >> > >>>>answer whenever there are a number of possible matches. The >> > formulation >> > >>>>that the draft gives does not distinguish in priority among matching >> > >>>>items. >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>[Addison Phillips] >> > >>> >> > >>>I agree, although I would take a different approach. >> > >>> >> > >>>For HTTP in particular, the Accept-Language header might be used for >> > both >> > >>> >> > >>> >> > >>filtering and lookup applications. It would be useful I think to >> specify >> > a >> > >>mapping from Extended to Basic Language Ranges in the (sole) Lookup >> > scheme. >> > >> >> > >> >> > >>>I think the mapping works thusly: >> > >>> >> > >>>1. If the Extended Language Range starts with "*", then the Basic >> > >>> >> > >>> >> > >>Language Range is "*". >> > >> >> > >> >> > >>>2. Otherwise, remove any "*" subtags and their associated trailing "- >> " >> > if >> > >>> >> > >>> >> > >>it exists. >> > >> >> > >> >> > >>>Thus a request for: >> > >>> >> > >>> "*-US" => "*" >> > >>> "en-*-US" => "en-US" >> > >>> "sr-*-CS" => "sr-CS" >> > >>> "sl-*-*-nedis" => "sl-nedis" >> > >>> "de-*-1901" => "de-1901" >> > >>> "de-*" => "de" >> > >>> >> > >>>Best Regards, >> > >>> >> > >>>Addison >> > >>> >> > >>>Addison P. Phillips >> > >>>Globalization Architect, Quest Software >> > >>> >> > >>>Internationalization is not a feature. >> > >>>It is an architecture. >> > >>> >> > >>> >> > >>> >> > >>> >> > > >> > > >> > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 04:55:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0q-0003DD-0K; Wed, 16 Nov 2005 04:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0o-0003CY-7a for ltru@megatron.ietf.org; Wed, 16 Nov 2005 04:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13699 for ; Wed, 16 Nov 2005 04:54:55 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcKIB-00020m-Sb for ltru@ietf.org; Wed, 16 Nov 2005 05:13:28 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAG9tEd00678 for ; Wed, 16 Nov 2005 18:55:14 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1622_15be3dbc_5687_11da_9c71_00304811fd80; Wed, 16 Nov 2005 18:55:13 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAG9r939009615 for ; Wed, 16 Nov 2005 18:54:49 +0900 Message-Id: <6.0.0.20.2.20051116184334.07960df0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Nov 2005 18:49:46 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching: Ranges vs. range lists X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [This mail is somewhat related to my mail entitled Matching: Filtering and Lookup: What's the fundamental difference.] I think the current draft is not careful enough to distinguish between single ranges and lists of ranges. I think that each specific matching section (e.g. basic range lookup, and so on) should first define whether a given range matches against a given tag (the result ideally being binary), and then go on and talk about the cases of having more than one tag and/or more than one range, in a well organized fashion. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 04:55:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0q-0003Ds-80; Wed, 16 Nov 2005 04:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK0o-0003CZ-7X for ltru@megatron.ietf.org; Wed, 16 Nov 2005 04:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13706 for ; Wed, 16 Nov 2005 04:54:56 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcKIB-000201-La for ltru@ietf.org; Wed, 16 Nov 2005 05:13:29 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAG9srd00498; Wed, 16 Nov 2005 18:54:53 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1684_08d5ad4c_5687_11da_9df7_00304811fd80; Wed, 16 Nov 2005 18:54:52 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAG9r933009615; Wed, 16 Nov 2005 18:54:06 +0900 Message-Id: <6.0.0.20.2.20051116172803.079d08e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Nov 2005 17:35:55 +0900 To: "Addison Phillips" , "Scott Hollenbeck" From: Martin Duerst Subject: RE: [Ltru] Re: Approval of two ltru documents In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 02:51 05/11/16, Addison Phillips wrote: >> Both will become BCP 47. I've already confirmed with the RFC Editor that >> one or the other can be obsoleted later on independently of the other if >> needed. > >That's kind of weird, but as long as the linkage is dissolved (when it >makes sense to be dissolved) I'm happy. That seems extremely easy to do. The RFC Editor just updates the list of BCP->RFC correspondences. (see http://www.rfc-editor.org/bcp-index.html). So I don't think there is any problem at all. Let's concentrate on the matching draft itself. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 07:12:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcM9U-00016A-BN; Wed, 16 Nov 2005 07:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcM9T-000165-1P for ltru@megatron.ietf.org; Wed, 16 Nov 2005 07:12:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20186 for ; Wed, 16 Nov 2005 07:12:01 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMQt-0005ZI-3z for ltru@ietf.org; Wed, 16 Nov 2005 07:30:36 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Wed, 16 Nov 2005 07:12:00 -0500 id 01588018.437B2210.00007A6A From: "Scott Hollenbeck" To: ltru@ietf.org Subject: RE: [Ltru] Re: Approval of two ltru documents Date: Wed, 16 Nov 2005 07:12:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <437ACC4F.7ECD@xyzzy.claranet.de> Thread-Index: AcXqdzWHggheqQHuSMWRoFcu8jgGigAL1NWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Wednesday, November 16, 2005 1:06 AM > To: ltru@ietf.org > Subject: [Ltru] Re: Approval of two ltru documents > > Addison Phillips wrote: > > > I agree that we should just finish the matching work, given > > that the IESG didn't buy my argument to separate the two, > > avoid the whole issue and quit griping about it. > > Wasn't only you, I also supported to split it. Apparently > "they" think that Bruce got it right, and our idea was wrong. Frankly, no, Bruce's comments weren't the influence. John Klensin's were, though they essentially suggested the same thing on this particular point. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 10:49:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPXV-0006ql-H6; Wed, 16 Nov 2005 10:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPXT-0006pk-7J for ltru@megatron.ietf.org; Wed, 16 Nov 2005 10:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04588 for ; Wed, 16 Nov 2005 10:49:01 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcPlu-0005YP-Iq for ltru@ietf.org; Wed, 16 Nov 2005 11:04:32 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 07:46:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: Ranges vs. range lists Date: Wed, 16 Nov 2005 07:46:07 -0800 Message-ID: Thread-Topic: [Ltru] Matching: Ranges vs. range lists Thread-Index: AcXqlHzLeydOo4+eRBuG7yz6CStRhgAL931Q From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 16 Nov 2005 15:46:08.0354 (UTC) FILETIME=[DC7C2420:01C5EAC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384686508==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0384686508== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGRvIHRoYXQuIFNlZSB0aGUgIkxvb2t1cCIgc2VjdGlvbiAo d2hpY2ggZG9lcyBtb3JlLW9yLWxlc3MgdGhpcykuDQoNCkdlbmVyYWwgb2JzZXJ2YXRpb246IG1h a2luZyBnZW5lcmFsIG9ic2VydmF0aW9ucyBhYm91dCB0aGUgdGV4dCBpcyB2ZXhpbmcgZm9yIHRo ZSBlZGl0b3JzLiBUcnkgdG8gbWFrZSBzcGVjaWZpYyBzdWdnZXN0aW9ucyBhYm91dCBzcGVjaWZp YyBwaWVjZXMgb2YgdGV4dC4NCg0KSSdtIGdvaW5nIHRvIGZpbmlzaCB1cCBhIGJ1bmNoIG9mIGVk aXRzIGJhc2VkIG9uIE1hcnRpbidzIGVtYWlscyB0b2RheSBhbG9uZyB3aXRoIG15IHdvcmsgdG8g Zml4IHRoZSAiYXBwbGljYXRpb24iIHZzLiAiYXBwbGljYXRpb24gb3IgcHJvdG9jb2xzIiB0ZXh0 IGhhbmRsaW5nIGFuZCBzdWJtaXQgbXkgcHJvdG8tZHJhZnQtMDYuIEkgdGhpbmsgdGhpcyBpcyB0 aGUgcHJvcGVyIGNvdXJzZSBvZiBhY3Rpb24sIGdpdmVuIHRoYXQgbm8gb25lIGhhcyBvYmplY3Rl ZCB0byB0aGUgbmV3IGZvcm1hdCBhbmQgaXQgd2lsbCBtYWtlIGVkaXRpbmcgdGhlIGRvY3VtZW50 IGVhc2llciBpZiBJIGRvbid0IGhhdmUgdG8gbWFpbnRhaW4gdHdvIHJhcGlkbHkgZGl2ZXJnaW5n IGRvY3VtZW50cy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMg bm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRy dS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFydGluIER1ZXJzdA0KPiBTZW50 OiAyMDA15bm0MTHmnIgxNuaXpSAxOjUwDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3Vi amVjdDogW0x0cnVdIE1hdGNoaW5nOiBSYW5nZXMgdnMuIHJhbmdlIGxpc3RzDQo+IA0KPiBbVGhp cyBtYWlsIGlzIHNvbWV3aGF0IHJlbGF0ZWQgdG8gbXkgbWFpbCBlbnRpdGxlZA0KPiBNYXRjaGlu ZzogRmlsdGVyaW5nIGFuZCBMb29rdXA6IFdoYXQncyB0aGUgZnVuZGFtZW50YWwgZGlmZmVyZW5j ZS5dDQo+IA0KPiBJIHRoaW5rIHRoZSBjdXJyZW50IGRyYWZ0IGlzIG5vdCBjYXJlZnVsIGVub3Vn aCB0byBkaXN0aW5ndWlzaA0KPiBiZXR3ZWVuIHNpbmdsZSByYW5nZXMgYW5kIGxpc3RzIG9mIHJh bmdlcy4NCj4gDQo+IEkgdGhpbmsgdGhhdCBlYWNoIHNwZWNpZmljIG1hdGNoaW5nIHNlY3Rpb24g KGUuZy4gYmFzaWMgcmFuZ2UNCj4gbG9va3VwLCBhbmQgc28gb24pIHNob3VsZCBmaXJzdCBkZWZp bmUgd2hldGhlciBhIGdpdmVuIHJhbmdlIG1hdGNoZXMNCj4gYWdhaW5zdCBhIGdpdmVuIHRhZyAo dGhlIHJlc3VsdCBpZGVhbGx5IGJlaW5nIGJpbmFyeSksIGFuZCB0aGVuDQo+IGdvIG9uIGFuZCB0 YWxrIGFib3V0IHRoZSBjYXNlcyBvZiBoYXZpbmcgbW9yZSB0aGFuIG9uZSB0YWcNCj4gYW5kL29y IG1vcmUgdGhhbiBvbmUgcmFuZ2UsIGluIGEgd2VsbCBvcmdhbml6ZWQgZmFzaGlvbi4NCj4gDQo+ IFJlZ2FyZHMsICAgTWFydGluLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============0384686508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0384686508==-- From ltru-bounces@ietf.org Wed Nov 16 11:56:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQaT-0003NR-TU; Wed, 16 Nov 2005 11:56:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQaS-0003JA-Dg for ltru@megatron.ietf.org; Wed, 16 Nov 2005 11:56:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09836 for ; Wed, 16 Nov 2005 11:56:10 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQrv-000051-1S for ltru@ietf.org; Wed, 16 Nov 2005 12:14:47 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAGGuRfJ010521 for ; Wed, 16 Nov 2005 11:56:27 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAGGviie063992 for ; Wed, 16 Nov 2005 09:57:44 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAGGuRQA003566 for ; Wed, 16 Nov 2005 09:56:27 -0700 Received: from [127.0.0.1] (sig-9-48-121-75.mts.ibm.com [9.48.121.75]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAGGuOgc003373; Wed, 16 Nov 2005 09:56:26 -0700 Message-ID: <437B64B6.8030402@icu-project.org> Date: Wed, 16 Nov 2005 08:56:22 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Matching: Ranges vs. range lists References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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="===============1410981213==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1410981213== Content-Type: multipart/alternative; boundary="------------020401020305090104020001" This is a multi-part message in MIME format. --------------020401020305090104020001 Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id jAGGuRfJ010521 Content-Transfer-Encoding: quoted-printable I'd like to discuss the following. I don't think it is controversial=20 (but I've been wrong about that before!). If we can agree on the=20 concept, then I'll suggest some additional text. One of the key issues is making sure that lookup allows for correct=20 handling of the default fallback. This is important because different=20 systems do it differently. Lookup on a single language tag progressively=20 truncates. It switches to the default language before going to root (the=20 last resort). So suppose that the default language is ja-JP (Japanese in=20 Japan). We would search as follows:
en_US_California
en_US
en
ja_JP
ja
ROOT
There are different ways to extend this to a /list/ of languages, such=20 as what one has in HTML. Suppose we have a situation where the=20 Accept-list of languages is **, and the actual installed=20 languages for the product are *ja* and *en*, with the default language=20 set to *ja*. There are several ways to walk the language hierarchy, some=20 of which may get an unwanted answer. 1. If the normal lookup is used /serially/, then one will check for *ru*, not find it, then go to the default language: *japanese*. /This is clearly not what is wanted/. 2. If an /exact match/ on languages is used, then one would check for *ru*, not find it, then check for *en-us*, not find it, check for *fr*, not find it, and also end up with the default language: *japanese*. /Also not desired./ 3. Instead, one should only switch to the /default language at the end of the list/. That is, one would do normal lookup, but stopping if the language switches to the default language. That way we would get *en* in the above example. This is effectively the same as modifying the accept list to add truncated languages, e.g. changing the above example to ** and only then switching to the default. * One might extend this to add only languages where they would not "block" later ones on the list, e.g. ** =3D> **. However, that is only really an issue where one has multiple countries/variants in a list, not grouped together. That is probably pretty rare, and is not worth designing for. * Notice that (c) is a compatible extension to the normal lookup used by Java, ICU, and other systems. If there is only one item in the list, the same results would be produced. Addison Phillips wrote: >I have been trying to do that. See the "Lookup" section (which does more= -or-less this). > >General observation: making general observations about the text is vexin= g for the editors. Try to make specific suggestions about specific pieces= of text. > >I'm going to finish up a bunch of edits based on Martin's emails today a= long with my work to fix the "application" vs. "application or protocols"= text handling and submit my proto-draft-06. I think this is the proper c= ourse of action, given that no one has objected to the new format and it = will make editing the document easier if I don't have to maintain two rap= idly diverging documents. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Martin Duerst >>Sent: 2005=E5=B9=B411=E6=9C=8816=E6=97=A5 1:50 >>To: LTRU Working Group >>Subject: [Ltru] Matching: Ranges vs. range lists >> >>[This mail is somewhat related to my mail entitled >>Matching: Filtering and Lookup: What's the fundamental difference.] >> >>I think the current draft is not careful enough to distinguish >>between single ranges and lists of ranges. >> >>I think that each specific matching section (e.g. basic range >>lookup, and so on) should first define whether a given range matches >>against a given tag (the result ideally being binary), and then >>go on and talk about the cases of having more than one tag >>and/or more than one range, in a well organized fashion. >> >>Regards, Martin. >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> =20 >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> =20 >> --------------020401020305090104020001 Content-Type: text/html; charset=UTF-8 X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id jAGGuRfJ010521 Content-Transfer-Encoding: quoted-printable

I'd like to discuss the following. I don't think it is controversial (but I've been wrong about that before!). If we can agree on the concept, then I'll suggest some additional text.


One of the key issues is making sure that lookup allows for correct handling of the default fallback. This is important because different systems do it differently. Lookup on a single language tag progressively truncates. It switches to the default language before going to root (the last resort). So suppose that the default language is ja-JP (Japanese in Japan). We would search as follows:

<br> en_US_California<br> en_US<br> en<br> ja_JP<br> ja<br> ROOT<br>

There are different ways to extend this to a list of languages, such as what one has in HTML. Suppose we have a situation where the Accept-list of languages is <ru, en-US, fr>, and the actual installed languages for the product are ja and e= n, with the default language set to ja. There are several ways to walk the language hierarchy, some of which may get an unwanted answer.

  1. If the normal lookup is used serially, then one will check for ru, not find it, then go to the default language: jap= anese. This is clearly not what is wanted.
  2. If an exact match on languages is used, then one would check for ru, not find it, then check for en-us, not find it, check for fr, not find it, and also end up with the default language: japanese. Also not desired.
  3. Instead, one should only switch to the default language at the end of the list. That is, one would do normal lookup, but stopping if the language switches to the default language. That way we would get en in the above example. This is effectively the same as modifying the accept list to add truncated languages, e.g. changing the above example to <ru, en-US, en, fr> and only then switching to the default.
    • One might extend this to add only languages where they would not "block" later ones on the list, e.g. <ru en-US fr en-GB-plum> =3D> <ru en-US-California en-US fr en-GB-plum en-GB en>. However, that is only really an issue where one has multiple countries/variants in a list, not grouped together. That is probably pretty rare, and is not worth designing for.
    • Notice that (c) is a compatible extension to the normal lookup used by Java, ICU, and other systems. If there is only one item in the list, the same results would be produced.


Addison Phillips wrote: 
I have been trying to do that. See the "Lookup" section =
(which does more-or-less this).

General observation: making general observations about the text is vexing=
 for the editors. Try to make specific suggestions about specific pieces =
of text.

I'm going to finish up a bunch of edits based on Martin's emails today al=
ong with my work to fix the "application" vs. "application or protocols" =
text handling and submit my proto-draft-06. I think this is the proper co=
urse of action, given that no one has objected to the new format and it w=
ill make editing the document easier if I don't have to maintain two rapi=
dly diverging documents.

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture.=20

  
-----Original Message-----
From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On =
Behalf Of
Martin Duerst
Sent: 2005=E5=B9=B411=E6=9C=8816=E6=97=A5 1:50
To: LTRU Working Group
Subject: [Ltru] Matching: Ranges vs. range lists

[This mail is somewhat related to my mail entitled
Matching: Filtering and Lookup: What's the fundamental difference.]

I think the current draft is not careful enough to distinguish
between single ranges and lists of ranges.

I think that each specific matching section (e.g. basic range
lookup, and so on) should first define whether a given range matches
against a given tag (the result ideally being binary), and then
go on and talk about the cases of having more than one tag
and/or more than one range, in a well organized fashion.

Regards,   Martin.


_______________________________________________
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
--------------020401020305090104020001-- --===============1410981213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1410981213==-- From ltru-bounces@ietf.org Wed Nov 16 13:30:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcS3a-0007Bz-AB; Wed, 16 Nov 2005 13:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcS3Z-0007BQ-0H for ltru@megatron.ietf.org; Wed, 16 Nov 2005 13:30:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15631 for ; Wed, 16 Nov 2005 13:30:18 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSL2-0003Ya-3o for ltru@ietf.org; Wed, 16 Nov 2005 13:48:57 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 10:30:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: Ranges vs. range lists Date: Wed, 16 Nov 2005 10:30:33 -0800 Message-ID: Thread-Topic: [Ltru] Matching: Ranges vs. range lists Thread-Index: AcXqzrfLqRGXJIC/SxyBEgxFKrOprgAAHGFQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 16 Nov 2005 18:30:35.0739 (UTC) FILETIME=[D5E79AB0:01C5EADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239579880==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0239579880== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KSSB0aGluayBJIGFncmVlIHdpdGggbW9zdCBvZiB5b3VyIHBvaW50cywgYWx0 aG91Z2ggSSBub3RlIHRoYXQgdGhlIHRleHQgbW9yZS1vci1sZXNzIGNvdmVyZWQgdGhpcyBhbHJl YWR5LiBJIGluY2x1ZGVkIHNvbWUgY2hhbmdlcyB0byBhZGRyZXNzIHlvdXIgZXhhbXBsZSBhbmQg Y29uY2VybnMgaW50byBkcmFmdC0wNiwgdGhvdWdoLg0KDQpJIGFsc28gdXBkYXRlZCBhbGwgdGhl IHVzZXMgb2YgdGhlIHdvcmQgImFwcGxpY2F0aW9uIi4NCg0KQW5kIEkgaGlnaGxpZ2h0ZWQgdGhl IGRpZmZlcmVuY2UgTWFydGluIGZvdW5kIG1vc3QgY29tcGVsbGluZyBiZXR3ZWVuIGxvb2t1cCBh bmQgZmlsdGVyaW5nIGluIGJvdGggdGhlIHRvcCBvZiBTZWN0aW9uIDMgKFR5cGVzIG9mIE1hdGNo aW5nKSBhbmQgaW5kaXZpZHVhbGx5IGluIGVhY2ggc2VjdGlvbiBvbiB0aGUgdHlwZXMuDQoNCkZp bmFsbHksIEkgY29ycmVjdGVkIHRoZSByZWZlcmVuY2UgdG8gUkZDIDQyMzQgKGluc3RlYWQgb2Yg MjIzNGJpcykgYW5kIHJlbW92ZWQgcmVkdW5kYW50IHJlZmVyZW5jZXMuDQoNClRoZSBuZXcgdmVy c2lvbiBpcyBwb3N0ZWQgb24gaW50ZXItbG9jYWxlLiBUaGlzIG1hcmtzIGEgdmFzdCBudW1iZXIg b2YgY2hhbmdlcyB0byB0aGUgY29udGVudC4gSSdkIGxpa2UgdG8gc3VibWl0IHRoaXMsIHBhY2Ug c29tZSByZXZpZXcgdG9kYXkgYnkgdGhlIGxpc3QsIHNvIHRoYXQgd2UgY2FuIHdvcmsgb24gKnNw ZWNpZmljKiB0ZXh0dWFsIGNoYW5nZXMgaW4gYSBkcmFmdC0wNy4NCg0KaHR0cDovL3d3dy5pbnRl ci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1tYXRjaGluZy0wNi5odG1sDQpodHRwOi8v d3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA2LnR4dA0K aHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1tYXRjaGluZy0w Ni54bWwNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9u YWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K --===============0239579880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0239579880==-- From ltru-bounces@ietf.org Wed Nov 16 13:44:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSGJ-00034y-Bs; Wed, 16 Nov 2005 13:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSGH-00034s-Ra for ltru@megatron.ietf.org; Wed, 16 Nov 2005 13:44:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16514 for ; Wed, 16 Nov 2005 13:43:27 -0500 (EST) Received: from eastrmmtao06.cox.net ([68.230.240.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSXj-00041k-1H for ltru@ietf.org; Wed, 16 Nov 2005 14:02:06 -0500 Received: from A31P ([68.100.55.187]) by eastrmmtao06.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051116184227.MYEL9108.eastrmmtao06.cox.net@A31P>; Wed, 16 Nov 2005 13:42:27 -0500 From: "Scott Hollenbeck" To: "'Addison Phillips'" Date: Wed, 16 Nov 2005 13:43:42 -0500 Message-ID: <004401c5eadd$ab16d740$2667fea9@A31P> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXqzrfLqRGXJIC/SxyBEgxFKrOprgAAHGFQAANlGEA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' Subject: [Ltru] Proto-Matching Draft Update 06 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison, Some text needs to be added to the Abstract and Intro to cover the "obsoletes 3066" status described in the "Note to the RFC Editor" that was included with the approval announcement for draft-ietf-ltru-registry-14. I'll tweak the note text here; "TBD" refers to the RFC number to be assigned to registry-14: To be added to the end of the Abstract: This document, in combination with RFC TBD (replace "TBD" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. To be added to the end of the Introduction: This document, in combination with [RFCTBD] (replace "TBD" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced [RFC1766]. An informative reference to registry-14 should also be added. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 13:54:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSQp-0006nK-5l; Wed, 16 Nov 2005 13:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSQo-0006nA-2a for ltru@megatron.ietf.org; Wed, 16 Nov 2005 13:54:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17078 for ; Wed, 16 Nov 2005 13:54:19 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSiG-0004OE-Hu for ltru@ietf.org; Wed, 16 Nov 2005 14:12:58 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 10:54:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 10:54:39 -0800 Message-ID: Thread-Topic: Proto-Matching Draft Update 06 Thread-Index: AcXqzrfLqRGXJIC/SxyBEgxFKrOprgAAHGFQAANlGEAAAJPMUA== From: "Addison Phillips" To: "Scott Hollenbeck" X-OriginalArrivalTime: 16 Nov 2005 18:54:41.0589 (UTC) FILETIME=[33B2CE50:01C5EADF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group Subject: [Ltru] RE: Proto-Matching Draft Update 06 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0666164375==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0666164375== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R290IGl0Lg0KDQpJdCBsb29rcyBvZGQgdG8gaGF2ZSBbUkZDVEJEXSBldmVyeXdoZXJlLiBDYW4g SSB1c2UgUkZDIDMwNjZiaXMgaW5zdGVhZD8gV2UgYWxyZWFkeSBoYXZlIGEgbnVtYmVyIG9mIHJl ZmVyZW5jZXMgdG8gZHJhZnQtcmVnaXN0cnkgaW4gdGhlIGRvY3VtZW50Lg0KDQpBZGRpc29uDQoN CkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0 d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4g YXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBT Y290dCBIb2xsZW5iZWNrIFttYWlsdG86c2FoQDQyOGNvYnJhamV0Lm5ldF0NCj4gU2VudDogMjAw NeW5tDEx5pyIMTbml6UgMTA6NDQNCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6ICdMVFJV IFdvcmtpbmcgR3JvdXAnDQo+IFN1YmplY3Q6IFByb3RvLU1hdGNoaW5nIERyYWZ0IFVwZGF0ZSAw Ng0KPiANCj4gQWRkaXNvbiwNCj4gDQo+IFNvbWUgdGV4dCBuZWVkcyB0byBiZSBhZGRlZCB0byB0 aGUgQWJzdHJhY3QgYW5kIEludHJvIHRvIGNvdmVyIHRoZQ0KPiAib2Jzb2xldGVzIDMwNjYiIHN0 YXR1cyBkZXNjcmliZWQgaW4gdGhlICJOb3RlIHRvIHRoZSBSRkMgRWRpdG9yIiB0aGF0IHdhcw0K PiBpbmNsdWRlZCB3aXRoIHRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgZm9yIGRyYWZ0LWlldGYt bHRydS1yZWdpc3RyeS0xNC4NCj4gSSdsbCB0d2VhayB0aGUgbm90ZSB0ZXh0IGhlcmU7ICJUQkQi IHJlZmVycyB0byB0aGUgUkZDIG51bWJlciB0byBiZQ0KPiBhc3NpZ25lZA0KPiB0byByZWdpc3Ry eS0xNDoNCj4gDQo+IFRvIGJlIGFkZGVkIHRvIHRoZSBlbmQgb2YgdGhlIEFic3RyYWN0Og0KPiAN Cj4gVGhpcyBkb2N1bWVudCwgaW4gY29tYmluYXRpb24gd2l0aCBSRkMgVEJEIChyZXBsYWNlICJU QkQiIHdpdGggdGhlIFJGQw0KPiBudW1iZXIgYXNzaWduZWQgdG8gZHJhZnQtaWV0Zi1sdHJ1LXJl Z2lzdHJ5LTE0KSwgcmVwbGFjZXMgUkZDIDMwNjYsIHdoaWNoDQo+IHJlcGxhY2VkIFJGQyAxNzY2 Lg0KPiANCj4gVG8gYmUgYWRkZWQgdG8gdGhlIGVuZCBvZiB0aGUgSW50cm9kdWN0aW9uOg0KPiAN Cj4gVGhpcyBkb2N1bWVudCwgaW4gY29tYmluYXRpb24gd2l0aCBbUkZDVEJEXSAocmVwbGFjZSAi VEJEIiB3aXRoIHRoZSBSRkMNCj4gbnVtYmVyIGFzc2lnbmVkIHRvIGRyYWZ0LWlldGYtbHRydS1y ZWdpc3RyeS0xNCksIHJlcGxhY2VzIFtSRkMzMDY2XSwgd2hpY2gNCj4gcmVwbGFjZWQgW1JGQzE3 NjZdLg0KPiANCj4gQW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHJlZ2lzdHJ5LTE0IHNob3Vs ZCBhbHNvIGJlIGFkZGVkLg0KPiANCj4gLVNjb3R0LQ0KDQo= --===============0666164375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0666164375==-- From ltru-bounces@ietf.org Wed Nov 16 13:58:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSUY-0007YM-OR; Wed, 16 Nov 2005 13:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSUV-0007YH-Q1 for ltru@megatron.ietf.org; Wed, 16 Nov 2005 13:58:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17287 for ; Wed, 16 Nov 2005 13:58:09 -0500 (EST) Received: from eastrmmtao01.cox.net ([68.230.240.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSlz-0004Vo-BV for ltru@ietf.org; Wed, 16 Nov 2005 14:16:48 -0500 Received: from A31P ([68.100.55.187]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051116185744.MNLI2178.eastrmmtao01.cox.net@A31P>; Wed, 16 Nov 2005 13:57:44 -0500 From: "Scott Hollenbeck" To: "'Addison Phillips'" Date: Wed, 16 Nov 2005 13:58:32 -0500 Message-ID: <000001c5eadf$bd9396e0$2667fea9@A31P> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXqzrfLqRGXJIC/SxyBEgxFKrOprgAAHGFQAANlGEAAAJPMUAAAJK1A X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' Subject: [Ltru] RE: Proto-Matching Draft Update 06 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Wednesday, November 16, 2005 1:55 PM > To: Scott Hollenbeck > Cc: LTRU Working Group > Subject: RE: Proto-Matching Draft Update 06 > > Got it. > > It looks odd to have [RFCTBD] everywhere. Can I use RFC > 3066bis instead? We already have a number of references to > draft-registry in the document. That's fine. As long as the references are consistent the RFC Editor will know what to do. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 14:12:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcShd-0003Eg-8b; Wed, 16 Nov 2005 14:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSha-0003Ea-UI for ltru@megatron.ietf.org; Wed, 16 Nov 2005 14:12:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17991 for ; Wed, 16 Nov 2005 14:11:40 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSz3-0004yR-Qy for ltru@ietf.org; Wed, 16 Nov 2005 14:30:19 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 11:11:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: choice of schemes Date: Wed, 16 Nov 2005 11:11:51 -0800 Message-ID: Thread-Topic: [Ltru] Matching: choice of schemes Thread-Index: AcXqlE65eO/0P4mBRhKxJugRl4fbtQATSLRQ From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 16 Nov 2005 19:11:53.0428 (UTC) FILETIME=[9AB8F140:01C5EAE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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="===============1171058082==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1171058082== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TWFydGluIHdyb3RlOg0KDQo+IEZpZnRoLCB0aGUgdGV4dCBjdXJyZW50bHkgbW9zdGx5IHVzZXMg dGhlIHdvcmRzICJpbXBsZW1lbnRlciINCj4gYW5kICJpbXBsZW1lbnRhdGlvbiIuIFNpbWlsYXIg dG8gImFwcGxpY2F0aW9uIiwgdGhlIGZpcnN0DQo+IGltcHJlc3Npb24gdGhpcyBnaXZlcyBpcyB0 aGF0IGl0J3MgYWJvdXQgaW1wbGVtZW50YXRpb25zIG9mDQo+IChlbmQgdXNlcikgYXBwbGljYXRp b25zLiBIb3dldmVyLCBvdXIgZmlyc3QgYW5kIGZvcmVtb3N0DQo+IGNvbmNlcm4gc2hvdWxkIGJl IHdpdGggd2hhdCBpcyBnZW5lcmFsbHkgY2FsbGVkDQo+ICJwcm90b2NvbCBkZXNpZ25lcnMiIG9y ICJzcGVjIHdyaXRlcnMiLCBhbmQgd2Ugc2hvdWxkIGNob3NlDQo+IHdvcmRpbmcgdGhhdCBtYWtl cyB0aGlzIGNsZWFyLg0KDQpJIGRpZCB3b3Jkc21pdGhpbmcgdG8gYWRkcmVzcyB0aGlzIHRvIHRo ZSBleHRlbnQgcG9zc2libGUuIFRoZSBzdGVtICJpbXBsZW1lbnQuLi4iIGFwcGVhcnMgZnJlcXVl bnRseSBpbiB0aGUgIkxlbmd0aCIgc2VjdGlvbiwgd2hlcmUgaXQgaXMgcm91Z2hseSBjb21wYXJh YmxlIHRvIGRyYWZ0LXJlZ2lzdHJ5J3MgdGV4dC4NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xv YmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9uYWxpemF0 aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============1171058082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1171058082==-- From ltru-bounces@ietf.org Wed Nov 16 14:43:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTC6-0003We-93; Wed, 16 Nov 2005 14:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTC4-0003WW-OQ for ltru@megatron.ietf.org; Wed, 16 Nov 2005 14:43:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19724 for ; Wed, 16 Nov 2005 14:43:09 -0500 (EST) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTTY-000649-Dn for ltru@ietf.org; Wed, 16 Nov 2005 15:01:49 -0500 Received: from h-64-105-34-178.snvacaid.dynamic.covad.net ([64.105.34.178] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EcTBz-0001np-01 for ltru@ietf.org; Wed, 16 Nov 2005 14:43:40 -0500 Message-ID: <000101c5eae6$a77ea640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] RE: Proto-Matching Draft Update 06 Date: Wed, 16 Nov 2005 11:47:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "Scott Hollenbeck" > Cc: "LTRU Working Group" > Sent: Wednesday, November 16, 2005 10:54 AM > Subject: [Ltru] RE: Proto-Matching Draft Update 06 ... > It looks odd to have [RFCTBD] everywhere. > Can I use RFC 3066bis instead? We already have a number of > references to draft-registry in the document. ... I think it would be simpler for all concerned to simply use in the xml source and let the tools do the job. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 14:50:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTI9-00057B-1t; Wed, 16 Nov 2005 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTI7-000571-SA for ltru@megatron.ietf.org; Wed, 16 Nov 2005 14:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20043 for ; Wed, 16 Nov 2005 14:49:25 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTZa-0006Fq-Kw for ltru@ietf.org; Wed, 16 Nov 2005 15:08:03 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 11:49:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: choice of schemes Date: Wed, 16 Nov 2005 11:49:38 -0800 Message-ID: Thread-Topic: [Ltru] Matching: choice of schemes Thread-Index: AcXqlE65eO/0P4mBRhKxJugRl4fbtQATVCpQ From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 16 Nov 2005 19:49:40.0673 (UTC) FILETIME=[E21B1310:01C5EAE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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="===============0401632042==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0401632042== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBTbyBoZXJlIGFyZSBteSBzcGVjaWZpYyBjb21tZW50czoNCj4gDQo+IEZpcnN0LCBtYWtlIHN1 cmUgd2UgaGF2ZSBhIChzdWIpc2VjdGlvbiBlbnRpdGxlZA0KPiAiQ2hvaWNlIG9mIGxhbmd1YWdl IG1hdGNoaW5nIHNjaGVtZSIgKG9yIHNvbWUgc3VjaCksIHNvDQo+IHRoYXQgdGhpcyBpcyBlYXN5 IHRvIGZpbmQuDQoNCkRvbmUuDQo+IA0KPiBTZWNvbmQsIG1ha2Ugc3VyZSB3ZSBkaXNjdXNzIGFs bCBhbHRlcm5hdGl2ZXMuIEluIHBhcnRpY3VsYXIsDQo+IGN1cnJlbnRseSB0aGUgY2hvaWNlIGJl dHdlZW4gJ2ZpbHRlcmluZycgYW5kICdsb29rdXAnIGlzDQo+IGdpdmVuLCBidXQgdGhlIGNob2lj ZSBiZXR3ZWVuIGJhc2ljIGFuZCBleHRlbmRlZCBpc24ndA0KPiBkaXNjdXNzZWQgYXQgYWxsLg0K DQpJdCBpcyBraW5kIG9mIGRpc2N1c3NlZCBpbnNpZGUgdGhlIHNlY3Rpb24gb24gZXh0ZW5kZWQg YW5kIGluIHRoZSBzZWN0aW9uIG9uIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlcy4gU3VnZ2VzdCBz b21lIHRleHQgdG8gcHV0IGludG8gImNob2ljZSI/DQo+IA0KPiBUaGlyZCwgdHJ5IHRvIHVzZSBh cyBkZWZpbml0aXZlIGFuZCBwcmVjaXNlIHdvcmRpbmcgYXMgcG9zc2libGUuDQo+IElkZWFsbHks IGlmIHdlIGhhdmUgZml2ZSBkaWZmZXJlbnQgc2NoZW1lcywgdGhlbiB3ZSB3b3VsZA0KPiBoYXZl IGZpdmUgcGFyYWdyYXBocywgZWFjaCBjbGVhcmx5IG1lbnRpb25pbmcgdGhlIGNvbmRpdGlvbnMN Cj4gYW5kIGNpcmN1bXN0YW5jZXMgZm9yIGNob3NpbmcgdGhhdCBzY2hlbWUuDQoNCldlIGhhdmUg Zm91ciBkaWZmZXJlbnQgc2NoZW1lczoNCg0KLSBCYXNpYyBGaWx0ZXJpbmcgKGZvciB1c2Ugd2l0 aCBiYXNpYyByYW5nZXMpDQotIEV4dGVuZGVkIEZpbHRlcmluZyAoZm9yIHVzZSB3aXRoIGV4dGVu ZGVkIHJhbmdlcykNCi0gU2NvcmVkIEZpbHRlcmluZyAoZm9yIG9yZGVyZWQgbGlzdHMpDQotIExv b2t1cA0KDQpJIGhhdmUgcHJvdmlkZWQgc3VnZ2VzdGVkIHRleHQgaW4gZHJhZnQtMDYgdGhhdCBk b2VzIHdoYXQgeW91IHdhbnQgd2l0aCByZWdhcmQgdG8gZGVzY3JpYmluZyB0aGUgY2hvaWNlcy4g SGVyZSBpdCBpczoNCg0KLS0NCjx0PkZpbHRlcmluZyBjYW4gYmUgdXNlZCB0byBwcm9kdWNlIGEg c2V0IG9mIHJlc3VsdHMgKHN1Y2ggYXMgYSBjb2xsZWN0aW9uIG9mIGRvY3VtZW50cykuIEZvciBl eGFtcGxlLCBpZiB1c2luZyBhIHNlYXJjaCBlbmdpbmUsIG9uZSBtaWdodCB1c2UgZmlsdGVyaW5n IHRvIGxpbWl0IHRoZSByZXN1bHRzIHRvIGRvY3VtZW50cyB3cml0dGVuIGluIEZyZW5jaC4gSXQg Y2FuIGFsc28gYmUgdXNlZCB3aGVuIGRlY2lkaW5nIHdoZXRoZXIgdG8gcGVyZm9ybSBzb21lIHBy b2Nlc3NpbmcgdGhhdCBpcyBsYW5ndWFnZSBzZW5zaXRpdmUgb24gc29tZSBjb250ZW50LiBGb3Ig ZXhhbXBsZSwgYSBwcm9jZXNzIG1pZ2h0IGNhdXNlIHBhcmFncmFwaHMgd2hvc2UgbGFuZ3VhZ2Ug dGFnIG1hdGNoZWQgdGhlIGxhbmd1YWdlIHJhbmdlICJubCIgdG8gYmUgZGlzcGxheWVkIGluIGl0 YWxpY3Mgd2l0aGluIGEgZG9jdW1lbnQuPC90Pg0KDQo8dD5UaGlzIGRvY3VtZW50IGRlc2NyaWJl cyB0aHJlZSB0eXBlcyBvZiBmaWx0ZXJpbmc6DQogICA8bGlzdCBzdHlsZT0ibnVtYmVycyI+DQoN CiAgIDx0Pjx4cmVmIHRhcmdldD0iYmFzaWNNYXRjaCI+QmFzaWMgRmlsdGVyaW5nPC94cmVmPiBp cyB1c2VkIHRvIG1hdGNoIGNvbnRlbnQgdXNpbmcgYmFzaWMgbGFuZ3VhZ2UgcmFuZ2VzPHhyZWYg dGFyZ2V0PSJiYXNpY1JhbmdlIj48L3hyZWY+LiBJdCBpcyBjb21wYXRpYmxlIHdpdGggaW1wbGVt ZW50YXRpb25zIHRoYXQgZG8gbm90IHByb2R1Y2UgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzLjwv dD4NCg0KICAgPHQ+PHhyZWYgdGFyZ2V0PSJleHRNYXRjaGluZyI+RXh0ZW5kZWQgUmFuZ2UgRmls dGVyaW5nPC94cmVmPiBpcyB1c2VkIHRvIG1hdGNoIGNvbnRlbnQgdXNpbmcgZXh0ZW5kZWQgbGFu Z3VhZ2UgcmFuZ2VzPHhyZWYgdGFyZ2V0PSJleHRyYW5nZSI+PC94cmVmPi4gTmV3ZXIgaW1wbGVt ZW50YXRpb25zIFNIT1VMRCB1c2UgdGhpcyBmb3JtIG9mIGZpbHRlcmluZyBpbiBwcmVmZXJlbmNl IHRvIGJhc2ljIGZpbHRlcmluZy48L3Q+DQoNCiAgIDx0Pjx4cmVmIHRhcmdldD0ic2NvcmVkTWF0 Y2hpbmciPlNjb3JlZCBGaWx0ZXJpbmc8L3hyZWY+IHByb2R1Y2VzIGFuIG9yZGVyZWQgc2V0IG9m IGNvbnRlbnQgdXNpbmcgZWl0aGVyIGJhc2ljIG9yIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlcy4g SXQgc2hvdWxkIGJlIHVzZWQgd2hlbiB0aGUgcXVhbGl0eSBvZiB0aGUgbWF0Y2ggd2l0aGluIGEg c3BlY2lmaWMgbGFuZ3VhZ2UgcmFuZ2UgaXMgaW1wb3J0YW50LCBhcyB3aGVuIHByZXNlbnRpbmcg YSBsaXN0IG9mIGRvY3VtZW50cyByZXN1bHRpbmcgZnJvbSBhIHNlYXJjaC48L3Q+DQoNCiAgIDwv bGlzdD48L3Q+DQoNCjx0Pjx4cmVmIHRhcmdldD0ibG9va3VwIj5Mb29rdXA8L3hyZWY+IGlzIHVz ZWQgd2hlbiBlYWNoIHJlcXVlc3QgTVVTVCBwcm9kdWNlIGV4YWN0bHkgb25lIHBpZWNlIG9mIGNv bnRlbnQuIEZvciBleGFtcGxlLCBhIFdlYiBzZXJ2ZXIgbWlnaHQgdXNlIHRoZSBBY2NlcHQtTGFu Z3VhZ2UgSFRUUCBoZWFkZXIgdG8gY2hvb3NlIHdoaWNoIGxhbmd1YWdlIHRvIHJldHVybiBhIGN1 c3RvbSA0MDQgcGFnZSBpbjogc2luY2UgaXQgY2FuIHJldHVybiBvbmx5IG9uZSBwYWdlLCBpdCBt dXN0IGNob29zZSBhIHNpbmdsZSBpdGVtIGFuZCBpdCBtdXN0IHJldHVybiBzb21lIGl0ZW0sIGV2 ZW4gaWYgbm8gY29udGVudCBtYXRjaGVzIHRoZSBsYW5ndWFnZSByYW5nZXMgc3VwcGxpZWQgYnkg dGhlIHVzZXIuPC90Pg0KLS0NCg0KPiANCj4gRm91cnRoLCBjbGVhcmx5IHNlcGFyYXRlIHRoZSBj aG9pY2Ugb2YgbWF0Y2hpbmcgc2NoZW1lIGZyb20NCj4gYWR2aWNlIGxpa2UgImFuZCB5b3UgbWF5 IGFsc28gdGhpbmsgYWJvdXQgZG9pbmcgdGhpcyBhbmQgdGhhdA0KPiBvbiB0b3Agb2YgaXQiLiBU aGlzIGlzIHBhcnRpY3VsYXIgYXBwbGllcyB0byB3aGF0IGlzIGN1cnJlbnRseQ0KPiAoaW4gQWRk aXNvbidzIGRyYWZ0IGRyYWZ0KSB0aGUgbGFzdCBwYXJhZ3JhcGgganVzdCBiZWZvcmUNCj4gc2Vj dGlvbiAzLjEgKHRhbGtpbmcgYWJvdXQgbm4vbmIvbm8gYW5kIHpoLUNOL3poLUhhbnMpLg0KPiBU aGlzIHBhcmFncmFwaCBvbmx5IGNvbmZ1c2VzIHBlb3BsZSB0cnlpbmcgdG8gbWFrZSB0aGVpcg0K PiBjaG9pY2UuIEluIG1heSB2aWV3LCB0aGUgYmVzdCB0aGluZyB3ZSBjb3VsZCBkbyB3aXRoIHRo aXMNCj4gcGFyYWdyYXBoIGlzIHRvIG1vdmUgaXQgdG8gYSBzZWN0aW9uIGVudGl0bGVkIHNvbWV0 aGluZw0KPiBsaWtlICJMaW1pdGF0aW9ucyBvZiBNYXRjaGluZyBTY2hlbWVzIiBvciBzbywgc29t ZXdoZXJlDQo+IGluIHRoZSAiT3RoZXJzIiBzZWN0aW9uLg0KDQpJJ3ZlIHJlYWNoZWQgdGhlIGxp bWl0IG9mIHdoYXQgY2FuIGJlIGRvbmUsIEkgdGhpbmssIHdpdGhvdXQgYSBjbGVhbiBkcmFmdC4g UHJvcG9zZSAobW92aW5nIG9yIGFkZGl0aW9uYWwpIHRleHQgZm9yIGRyYWZ0LTA3LCBva2F5Pw0K DQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJl Lg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYXJ0aW4gRHVlcnN0DQo+IFNlbnQ6IDIwMDXlubQxMeac iDE25pelIDE6NDMNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0g TWF0Y2hpbmc6IGNob2ljZSBvZiBzY2hlbWVzDQo+IA0KPiBbVGhpcyBpcyBhIHRlY2huaWNhbCBj b250cmlidXRpb24sIG1vc3RseSBtb3RpdmF0ZWQNCj4gYnkgbXkgbG9uZyBleHBlcmllbmNlIHdp dGggaG93IG90aGVyIFdHcyB1c2Ugc3BlY3MuXQ0KPiANCj4gVGhlIHNlY3Rpb24gb24gY2hvaWNl IG9mIG1hdGNoaW5nIHNjaGVtZXMgaGFzIGJlZW4gbW92ZWQNCj4gY2xvc2VyIHRvIHRoZSBmcm9u dCBvZiB0aGUgZG9jdW1lbnQuIFRoaXMgaXMgZ29vZC4NCj4gDQo+IEJ1dCB0aGVyZSBhcmUgc29t ZSwgaW4gbWFueSB3YXlzIHNlcmlvdXMsIHByb2JsZW1zLiBJIHRoaW5rDQo+IHRoZXkgYXJlIHNl cmlvdXMgYmVjYXVzZSBpbiBtYW55IHdheXMsIHRoaXMgaXMgdGhlIG1vc3QNCj4gaW1wb3J0YW50 IHNlY3Rpb24gb2YgdGhpcyBkcmFmdDogT3RoZXIgV0dzIGNyZWF0aW5nIHByb3RvY29scw0KPiBh bmQgZm9ybWF0cywgYW5kIGFwcGxpY2F0aW9uIGRlc2lnbmVycywgaWRlYWxseSBzaG91bGQgYmUN Cj4gYWJsZSB0byBnbyB0byB0aGF0IHNlY3Rpb24sIHJlYWQgaXQsIGFuZCB0aGVuIHJlZmVyZW5j ZQ0KPiB0aGUgc2VjdGlvbiB0aGF0IHRoZXkgaGF2ZSBpZGVudGlmaWVkIGFzIGJlaW5nIHRoZSBt b3N0DQo+IGFwcHJvcHJpYXRlIGZvciB0aGVpciB1c2FnZSBjYXNlLCBhbmQgYmUgZG9uZSB3aXRo IGl0Lg0KPiBPZiBjb3Vyc2UsIHdlIGFzIGV4cGVydHMgaG9wZSB0aGF0IG90aGVycyB3aWxsIHN0 dWR5IHRoaXMNCj4gZHJhZnQgaW4gZGV0YWlsLCBidXQgdGhhdCdzIGdlbmVyYWxseSBub3QgZ29p bmcgdG8gaGFwcGVuLg0KPiANCj4gV2hhdCB3aWxsIGhhcHBlbiBtb3N0IG9mdGVuIGlzIEEpIGEg V0cgb3Igc28ganVzdCBwaWNrcyBhDQo+IHNjaGVtZSBiYXNlZCBvbiB0aGVpciBmaXJzdCBpbXBy ZXNzaW9uLCBiZWNhdXNlIHRoZXkgd2FudA0KPiB0byBtb3ZlIG9uLCBvciBCKSBhIFdHIGdldHMg ZW50YW5nbGVkIGludG8gbG9uZyBkaXNjdXNzaW9ucw0KPiBiZWNhdXNlIGl0J3Mgbm90IHJlYWxs eSBjbGVhciBmcm9tIG91ciBkcmFmdCB3aGF0IGlzIGJlc3QNCj4gZm9yIHRoZW0uDQo+IA0KPiBX aGlsZSBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBhIGxpbWl0IGluIHRoZSBhZHZpY2Ugd2UN Cj4gY2FuIGdpdmUsIEkgdGhpbmsgd2UgZGVmaW5pdGVseSBjYW4gYW5kIHNob3VsZCB0cnkgb3Vy IGJlc3QNCj4gdG8gbWFrZSBzdXJlIHdlIGdpdmUgYXMgbXVjaCBhZHZpY2UgYXMgd2UgY2FuLCBh bmQgbWFrZSBpdA0KPiBhcyBjbGVhciBhcyBwb3NzaWJsZS4NCj4gDQo+IA0KPiBGaWZ0aCwgdGhl IHRleHQgY3VycmVudGx5IG1vc3RseSB1c2VzIHRoZSB3b3JkcyAiaW1wbGVtZW50ZXIiDQo+IGFu ZCAiaW1wbGVtZW50YXRpb24iLiBTaW1pbGFyIHRvICJhcHBsaWNhdGlvbiIsIHRoZSBmaXJzdA0K PiBpbXByZXNzaW9uIHRoaXMgZ2l2ZXMgaXMgdGhhdCBpdCdzIGFib3V0IGltcGxlbWVudGF0aW9u cyBvZg0KPiAoZW5kIHVzZXIpIGFwcGxpY2F0aW9ucy4gSG93ZXZlciwgb3VyIGZpcnN0IGFuZCBm b3JlbW9zdA0KPiBjb25jZXJuIHNob3VsZCBiZSB3aXRoIHdoYXQgaXMgZ2VuZXJhbGx5IGNhbGxl ZA0KPiAicHJvdG9jb2wgZGVzaWduZXJzIiBvciAic3BlYyB3cml0ZXJzIiwgYW5kIHdlIHNob3Vs ZCBjaG9zZQ0KPiB3b3JkaW5nIHRoYXQgbWFrZXMgdGhpcyBjbGVhci4NCj4gDQo+IA0KPiBSZWdh cmRzLCAgICBNYXJ0aW4uDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0K PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0401632042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0401632042==-- From ltru-bounces@ietf.org Wed Nov 16 19:44:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXtO-0005PU-TB; Wed, 16 Nov 2005 19:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXtK-0005PP-Pr for ltru@megatron.ietf.org; Wed, 16 Nov 2005 19:44:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11342 for ; Wed, 16 Nov 2005 19:44:08 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcYAr-00017T-8k for ltru@ietf.org; Wed, 16 Nov 2005 20:02:50 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60DFF2596DE; Thu, 17 Nov 2005 01:44:06 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12666-02; Thu, 17 Nov 2005 01:44:02 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 610A92596DF; Thu, 17 Nov 2005 01:43:58 +0100 (CET) Date: Wed, 16 Nov 2005 16:34:28 -0800 From: Harald Tveit Alvestrand To: Mark Davis , Addison Phillips Subject: Re: [Ltru] Matching: Ranges vs. range lists Message-ID: In-Reply-To: <437B64B6.8030402@icu-project.org> References: <437B64B6.8030402@icu-project.org> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529472930==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1529472930== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========57C706CA2565093FF1C6==========" --==========57C706CA2565093FF1C6========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 16. november 2005 08:56 -0800 Mark Davis =20 wrote: > One of the key issues is making sure that lookup allows for correct > handling of the default fallback. This is important because different > systems do it differently. Lookup on a single language tag progressively > truncates. It switches to the default language before going to root (the > last resort). So suppose that the default language is ja-JP (Japanese in > Japan). We would search as follows: > en_US_California > en_US > en > ja_JP > ja > ROOT I don't think I agree. My interpretation is that "default language" is a=20 per-application decision, not a part of the language matching rule, and=20 treating it as part of the langauge matching rule will just add confusion. But I have to read the matching draft carefully before I'm sure what I=20 disagree with, or how to express it. --==========57C706CA2565093FF1C6========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDe9AUOMj+2+WY0F4RAtkeAKDtzwE+6BNlMu2BxpcEBEBA/ZFXcgCbB41Y kWv6oYWPYJai/YhDFXfpdqY= =a7h/ -----END PGP SIGNATURE----- --==========57C706CA2565093FF1C6==========-- --===============1529472930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1529472930==-- From ltru-bounces@ietf.org Wed Nov 16 20:03:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYBz-00028A-B3; Wed, 16 Nov 2005 20:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYBy-000285-0H for ltru@megatron.ietf.org; Wed, 16 Nov 2005 20:03:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12246 for ; Wed, 16 Nov 2005 20:03:23 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcYTV-0001cj-MS for ltru@ietf.org; Wed, 16 Nov 2005 20:22:06 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE2F32596E1; Thu, 17 Nov 2005 02:03:22 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13131-02; Thu, 17 Nov 2005 02:03:19 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B8642596DE; Thu, 17 Nov 2005 02:03:16 +0100 (CET) Date: Wed, 16 Nov 2005 17:02:14 -0800 From: Harald Tveit Alvestrand To: Addison Phillips , Martin Duerst , LTRU Working Group Subject: RE: [Ltru] Matching: choice of schemes Message-ID: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============0286771164==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0286771164== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========A397D4782D71FBA831B1==========" --==========A397D4782D71FBA831B1========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 16. november 2005 11:49 -0800 Addison Phillips=20 wrote: > I have provided suggested text in draft-06 that does what you want with > regard to describing the choices. Here it is: I've got issues with almost every single paragraph in the text you propose. = But I think the -06 reorganization has exposed these issues much more=20 clearly than the previous versions - which is very good. I'll comment on=20 -06 after publication. --==========A397D4782D71FBA831B1========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDe9aWOMj+2+WY0F4RAkreAKCGSi+nTBnZ5V8xf+O9nu5/H+m4nQCfYiic VS2PKwePS9I1a1NuKWqzA4E= =tMmp -----END PGP SIGNATURE----- --==========A397D4782D71FBA831B1==========-- --===============0286771164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0286771164==-- From ltru-bounces@ietf.org Wed Nov 16 20:07:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYFl-0002cR-9Y; Wed, 16 Nov 2005 20:07:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYFi-0002cF-Hs; Wed, 16 Nov 2005 20:07:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12385; Wed, 16 Nov 2005 20:07:10 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcYX8-0001ie-N6; Wed, 16 Nov 2005 20:25:52 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 17:07:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5EB13.484957F6" Date: Wed, 16 Nov 2005 17:07:28 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-ltru-matching-06 submission Thread-Index: AcXrE0d92S/8CT9NSCGTeQ9VN3wpwQ== From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Nov 2005 01:07:30.0770 (UTC) FILETIME=[48C4F320:01C5EB13] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd9ffe26482d533f4d1fa531728a7327 Cc: LTRU Working Group Subject: [Ltru] draft-ietf-ltru-matching-06 submission X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB13.484957F6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGRyYWZ0LTA2IG9mICJkcmFmdC1p ZXRmLWx0cnUtbWF0Y2hpbmciLg0KDQpUaGFua3MhDQoNCkFkZGlzb24gKGZvciB0aGUgZWRpdG9y cykNCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0 IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBp cyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K ------_=_NextPart_001_01C5EB13.484957F6 Content-Type: text/plain; name="draft-ietf-ltru-matching-06.txt" Content-Description: draft-ietf-ltru-matching-06.txt Content-Disposition: attachment; filename="draft-ietf-ltru-matching-06.txt" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBLiBQaGlsbGlwcywgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBRdWVzdCBTb2Z0d2FyZQpPYnNvbGV0ZXM6IDMwNjYgKGlmIGFw cHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIERhdmlzLCBFZC4KRXhwaXJl czogTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSUJNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAxNiwgMjAwNQoKCiAgICAgICAgICAgTWF0Y2hpbmcgVGFncyBmb3Ig dGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdlcwogICAgICAgICAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA2CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJt aXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBh bnkKICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBv ciBzaGUgaXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55 IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRh c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJl IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu eQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz IHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBj YW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFj dHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVz IGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoK ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgMjAsIDIwMDYuCgpDb3B5 cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1 KS4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBkaWZmZXJlbnQgbWVjaGFu aXNtcyBmb3IgY29tcGFyaW5nLCBtYXRjaGluZywKICAgYW5kIGV2YWx1YXRpbmcgbGFuZ3VhZ2Ug dGFncy4gIFBvc3NpYmxlIGFsZ29yaXRobXMgZm9yIGxhbmd1YWdlCiAgIG5lZ290aWF0aW9uIGFu ZCBjb250ZW50IHNlbGVjdGlvbiBhcmUgZGVzY3JpYmVkLiAgVGhpcyBkb2N1bWVudCwgaW4KICAg Y29tYmluYXRpb24gd2l0aCBSRkMgMzA2NmJpcyAocmVwbGFjZSAiMzA2NmJpcyIgd2l0aCB0aGUg UkZDIG51bWJlcgogICBhc3NpZ25lZCB0byBkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTQpLCBy ZXBsYWNlcyBSRkMgMzA2Niwgd2hpY2gKICAgcmVwbGFjZWQgUkZDIDE3NjYuCgoKCgpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICAg W1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIElu dHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzCiAgIDIuICBUaGUgTGFuZ3VhZ2UgUmFuZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDIuMS4gIExpc3RzIG9mIExhbmd1YWdlIFJhbmdl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAyLjIuICBCYXNpYyBM YW5ndWFnZSBSYW5nZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAg ICAgMi4zLiAgRXh0ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNQogICAzLiAgVHlwZXMgb2YgTWF0Y2hpbmcgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAzLjEuICBDaG9vc2luZyBhIFR5cGUg b2YgTWF0Y2hpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMy4yLiAg RmlsdGVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICAgICAgMy4yLjEuICBGaWx0ZXJpbmcgd2l0aCBCYXNpYyBMYW5ndWFnZSBSYW5nZXMg LiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgICAgIDMuMi4yLiAgRmlsdGVyaW5nIHdpdGggRXh0ZW5k ZWQgTGFuZ3VhZ2UgUmFuZ2VzICAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICAzLjIuMy4gIERpc3Rh bmNlIE1ldHJpYyBGaWx0ZXJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAg IDMuMy4gIExvb2t1cCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTMKICAgNC4gIE90aGVyIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgNC4xLiAgTWVhbmluZyBvZiBMYW5ndWFn ZSBUYWdzIGFuZCBSYW5nZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgIDQuMi4gIENv bnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTcKICAgICA0LjMuICBMZW5ndGggQ29uc2lkZXJhdGlvbnMgaW4gTWF0Y2hpbmcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE3CiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMAogICA2LiAgQ2hhbmdlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgNy4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDIyCiAgIDguICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICA5LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQKICAgICA5LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0 CiAgICAgOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNAogICBBcHBlbmRpeCBBLiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2CiAgIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAu IC4gLiAyNwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAg RXhwaXJlcyBNYXkgMjAsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwNQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxhbmV0 IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBudW1iZXIgb2YKICAgbGFuZ3VhZ2VzLiAg VGhlcmUgYXJlIG1hbnkgcmVhc29ucyB3aHkgb25lIHdvdWxkIHdhbnQgdG8gaWRlbnRpZnkgdGhl CiAgIGxhbmd1YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRp b24uCgogICBJbmZvcm1hdGlvbiBhYm91dCBhIHVzZXIncyBsYW5ndWFnZSBwcmVmZXJlbmNlcyBj b21tb25seSBuZWVkcyB0byBiZQogICBpZGVudGlmaWVkIHNvIHRoYXQgYXBwcm9wcmlhdGUgcHJv Y2Vzc2luZyBjYW4gYmUgYXBwbGllZC4gIEZvcgogICBleGFtcGxlLCB0aGUgdXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIGluIGEgYnJvd3NlciBjYW4gYmUgdXNlZCB0bwogICBzZWxlY3Qgd2Vi IHBhZ2VzIGFwcHJvcHJpYXRlbHkuICBMYW5ndWFnZSBwcmVmZXJlbmNlcyBjYW4gYWxzbyBiZQog ICB1c2VkIHRvIHNlbGVjdCBhbW9uZyB0b29scyAoc3VjaCBhcyBkaWN0aW9uYXJpZXMpIHRvIGFz c2lzdCBpbiB0aGUKICAgcHJvY2Vzc2luZyBvciB1bmRlcnN0YW5kaW5nIG9mIGNvbnRlbnQgaW4g ZGlmZmVyZW50IGxhbmd1YWdlcy4KCiAgIEdpdmVuIGEgc2V0IG9mIGxhbmd1YWdlIGlkZW50aWZp ZXJzLCBzdWNoIGFzIHRob3NlIGRlZmluZWQgaW4KICAgW1JGQzMwNjZiaXNdLCB2YXJpb3VzIG1l Y2hhbmlzbXMgY2FuIGJlIGVudmlzaW9uZWQgZm9yIHBlcmZvcm1pbmcKICAgbGFuZ3VhZ2UgbmVn b3RpYXRpb24gYW5kIHRhZyBtYXRjaGluZy4gIEFwcGxpY2F0aW9ucywgcHJvdG9jb2xzLCBvcgog ICBzcGVjaWZpY2F0aW9ucyB3aWxsIGhhdmUgdmFyeWluZyBuZWVkcyBhbmQgcmVxdWlyZW1lbnRz IHRoYXQgd2lsbAogICBhZmZlY3QgdGhlIGNob2ljZSBvZiBhIHN1aXRhYmxlIG1lY2hhbmlzbS4g IFByb3RvY29scyBhbmQKICAgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGNsZWFybHkgaW5kaWNhdGUg dGhlIHBhcnRpY3VsYXIgbWVjaGFuaXNtIHVzZWQKICAgaW4gc2VsZWN0aW5nIG9yIG1hdGNoaW5n IGxhbmd1YWdlIHRhZ3MuCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgc2V2ZXJhbCBtZWNoYW5p c21zIGZvciBtYXRjaGluZywgc2VsZWN0aW5nLCBvcgogICBmaWx0ZXJpbmcgY29udGVudCB3aG9z ZSBuYXR1cmFsIGxhbmd1YWdlIGlzIGlkZW50aWZpZWQgdXNpbmcgTGFuZ3VhZ2UKICAgVGFncyBb UkZDMzA2NmJpc10sIGFzIHdlbGwgYXMgdGhlIHN5bnRheCAoY2FsbGVkIGEgImxhbmd1YWdlIHJh bmdlIikKICAgYXNzb2NpYXRlZCB3aXRoIGVhY2ggb2YgdGhlc2UgbWVjaGFuaXNtcyBmb3Igc3Bl Y2lmeWluZyB0aGUgdXNlcidzCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzLgoKICAgVGhpcyBkb2N1 bWVudCwgaW4gY29tYmluYXRpb24gd2l0aCBbUkZDMzA2NmJpc10gKHJlcGxhY2UgIjMwNjZiaXMi CiAgIGdsb2JhbGx5IGluIHRoaXMgZG9jdW1lbnQgd2l0aCB0aGUgUkZDIG51bWJlciBhc3NpZ25l ZCB0bwogICBkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTQpLCByZXBsYWNlcyBbUkZDMzA2Nl0s IHdoaWNoIHJlcGxhY2VkCiAgIFtSRkMxNzY2XS4KCiAgIFRoZSBrZXl3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMy MTE5XS4KCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBN YXkgMjAsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoK CjIuICBUaGUgTGFuZ3VhZ2UgUmFuZ2UKCiAgIExhbmd1YWdlIFRhZ3MgW1JGQzMwNjZiaXNdIGFy ZSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBsYW5ndWFnZSBvZiBzb21lCiAgIGluZm9ybWF0aW9uIGl0 ZW0gb3IgY29udGVudC4gIEFwcGxpY2F0aW9ucyBvciBwcm90b2NvbHMgdGhhdCB1c2UKICAgbGFu Z3VhZ2UgdGFncyBhcmUgb2Z0ZW4gZmFjZWQgd2l0aCB0aGUgcHJvYmxlbSBvZiBpZGVudGlmeWlu ZyBzZXRzIG9mCiAgIGNvbnRlbnQgdGhhdCBzaGFyZSBjZXJ0YWluIGxhbmd1YWdlIGF0dHJpYnV0 ZXMuICBGb3IgZXhhbXBsZSwgSFRUUAogICAxLjEgW1JGQzI2MTZdIGRlc2NyaWJlcyBsYW5ndWFn ZSByYW5nZXMgaW4gaXRzIGRpc2N1c3Npb24gb2YgdGhlCiAgIEFjY2VwdC1MYW5ndWFnZSBoZWFk ZXIgKFNlY3Rpb24gMTQuNCksIHdoaWNoIGlzIHVzZWQgZm9yIHNlbGVjdGluZwogICBjb250ZW50 IGZyb20gc2VydmVycyBiYXNlZCBvbiB0aGUgbGFuZ3VhZ2Ugb2YgdGhhdCBjb250ZW50LgoKICAg V2hlbiBzZWxlY3RpbmcgY29udGVudCBhY2NvcmRpbmcgdG8gaXRzIGxhbmd1YWdlLCBpdCBpcyB1 c2VmdWwgdG8KICAgaGF2ZSBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgc2V0cyBvZiBsYW5n dWFnZSB0YWdzIHRoYXQgc2hhcmUKICAgc3BlY2lmaWMgYXR0cmlidXRlcy4gIFRoaXMgYWxsb3dz IHVzZXJzIHRvIHNlbGVjdCBvciBmaWx0ZXIgY29udGVudAogICBiYXNlZCBvbiBzcGVjaWZpYyBy ZXF1aXJlbWVudHMuICBTdWNoIGFuIGlkZW50aWZpZXIgaXMgY2FsbGVkIGEKICAgIkxhbmd1YWdl IFJhbmdlIi4KCjIuMS4gIExpc3RzIG9mIExhbmd1YWdlIFJhbmdlcwoKICAgV2hlbiB1c2VycyBz cGVjaWZ5IGEgbGFuZ3VhZ2UgcHJlZmVyZW5jZSB0aGV5IG9mdGVuIG5lZWQgdG8gc3BlY2lmeSBh CiAgIHByaW9yaXRpemVkIGxpc3Qgb2YgbGFuZ3VhZ2UgcmFuZ2VzIGluIG9yZGVyIHRvIGJlc3Qg cmVmbGVjdCB0aGVpcgogICBsYW5ndWFnZSByZXF1aXJlbWVudHMgZm9yIHRoZSBtYXRjaGluZyBv cGVyYXRpb24uICBUaGlzIGlzIGVzcGVjaWFsbHkKICAgdHJ1ZSBmb3Igc3BlYWtlcnMgb2YgbWlu b3JpdHkgbGFuZ3VhZ2VzLiAgQSBzcGVha2VyIG9mIEJyZXRvbiBpbgogICBGcmFuY2UsIGZvciBl eGFtcGxlLCBtYXkgc3BlY2lmeSAiYmUiIGZvbGxvd2VkIGJ5ICJmciIsIG1lYW5pbmcgdGhhdAog ICBpZiBCcmV0b24gaXMgYXZhaWxhYmxlLCBpdCBpcyBwcmVmZXJyZWQsIGJ1dCBvdGhlcndpc2Ug RnJlbmNoIGlzIHRoZQogICBiZXN0IGFsdGVybmF0aXZlLiAgSXQgY2FuIGdldCBtb3JlIGNvbXBs ZXg6IGEgc3BlYWtlciBtYXkgd2lzaCB0bwogICBmYWxsYmFjayBmcm9tIFNrb2x0IFNhbWkgdG8g Tm9ydGhlcm4gU2FtaSB0byBGaW5uaXNoLgoKICAgQSAiTGFuZ3VhZ2UgUHJpb3JpdHkgTGlzdCIg Y29uc2lzdHMgb2YgYSBwcmlvcml0aXplZCBvciB3ZWlnaHRlZCBsaXN0CiAgIG9mIGxhbmd1YWdl IHJhbmdlcy4gIE9uZSB3ZWxsIGtub3duIGV4YW1wbGUgb2Ygc3VjaCBhIGxpc3QgaXMgdGhlCiAg ICJBY2NlcHQtTGFuZ3VhZ2UiIGhlYWRlciBkZWZpbmVkIGluIFJGQyAyNjE2IFtSRkMyNjE2XSAo c2VlIFNlY3Rpb24KICAgMTQuNCkgYW5kIFJGQyAzMjgyIFtSRkMzMjgyXS4gIFRoZSB2YXJpb3Vz IG1hdGNoaW5nIG9wZXJhdGlvbnMKICAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaW5jbHVk ZSBjb25zaWRlcmF0aW9ucyBmb3IgdXNpbmcgYQogICBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LgoK Mi4yLiAgQmFzaWMgTGFuZ3VhZ2UgUmFuZ2UKCiAgIEEgIkJhc2ljIExhbmd1YWdlIFJhbmdlIiBp ZGVudGlmaWVzIHRoZSBzZXQgb2YgY29udGVudCB3aG9zZSBsYW5ndWFnZQogICB0YWdzIGJlZ2lu IHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ugb2Ygc3VidGFncy4gIEEgYmFzaWMgbGFuZ3VhZ2UgcmFu Z2UKICAgaXMgaWRlbnRpZmllZCBieSBpdHMgJ2xhbmd1YWdlLXJhbmdlJyB0YWcsIGJ5IGFkYXB0 aW5nIHRoZQogICBBQk5GW1JGQzQyMzRdIGZyb20gSFRUUC8xLjEgW1JGQzI2MTZdIDoKCiAgIGxh bmd1YWdlLXJhbmdlID0gbGFuZ3VhZ2UtdGFnIC8gIioiCiAgIGxhbmd1YWdlLXRhZyAgID0gMSo4 W2FscGhhbnVtXSAqWyItIiAxKjhhbHBoYW51bV0KICAgYWxwaGFudW0gICAgICAgPSBBTFBIQSAv IERJR0lUCgogICBUaGF0IGlzLCBhIGxhbmd1YWdlLXJhbmdlIGhhcyB0aGUgc2FtZSBzeW50YXgg YXMgYSBsYW5ndWFnZS10YWcgb3IgaXMKICAgdGhlIHNpbmdsZSBjaGFyYWN0ZXIgIioiLiAgQmFz aWMgTGFuZ3VhZ2UgUmFuZ2VzIGltcGx5IHRoYXQgdGhlcmUgaXMKICAgYSBzZW1hbnRpYyByZWxh dGlvbnNoaXAgYmV0d2VlbiBsYW5ndWFnZSB0YWdzIHRoYXQgc2hhcmUgdGhlIHNhbWUKCgoKUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAgICAgICAgICAg ICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGlu ZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgcHJlZml4LiAgV2hpbGUgdGhpcyBp cyBvZnRlbiB0aGUgY2FzZSwgaXQgaXMgbm90IGFsd2F5cyB0cnVlIGFuZAogICB1c2VycyBzaG91 bGQgbm90ZSB0aGF0IHRoZSBzZXQgb2YgbGFuZ3VhZ2UgdGFncyB0aGF0IG1hdGNoIGEgc3BlY2lm aWMKICAgbGFuZ3VhZ2UtcmFuZ2UgbWF5IG5vdCBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUuCgog ICBCYXNpYyBsYW5ndWFnZSByYW5nZXMgd2VyZSBvcmlnaW5hbGx5IGRlc2NyaWJlZCBpbiBbUkZD MzA2Nl0gYW5kIEhUVFAKICAgMS4xIFtSRkMyNjE2XSAod2hlcmUgdGhleSBhcmUgcmVmZXJyZWQg dG8gYXMgc2ltcGx5IGEgImxhbmd1YWdlCiAgIHJhbmdlIikuCgogICBVc2VycyBTSE9VTEQgYXZv aWQgc3VidGFncyB0aGF0IGFkZCBubyBkaXN0aW5ndWlzaGluZyB2YWx1ZSB0byBhCiAgIGxhbmd1 YWdlIHJhbmdlLiAgRm9yIGV4YW1wbGUsIHNjcmlwdCBzdWJ0YWdzIFNIT1VMRCBOT1QgYmUgdXNl ZCB0bwogICBmb3JtIGEgbGFuZ3VhZ2UgcmFuZ2Ugd2l0aCBsYW5ndWFnZSBzdWJ0YWdzIHdoaWNo IGhhdmUgYSBtYXRjaGluZwogICBTdXBwcmVzcy1TY3JpcHQgZmllbGQgaW4gdGhlaXIgcmVnaXN0 cnkgcmVjb3JkLiAgVGh1cyB0aGUgbGFuZ3VhZ2UKICAgcmFuZ2UgImVuLUxhdG4iIGlzIHByb2Jh Ymx5IGluYXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcyAoYmVjYXVzZSB0aGUKICAgdmFzdCBtYWpv cml0eSBFbmdsaXNoIGRvY3VtZW50cyBhcmUgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0IGFu ZAogICB0aHVzIHRoZSAnZW4nIGxhbmd1YWdlIHN1YnRhZyBoYXMgYSBTdXBwcmVzcy1TY3JpcHQg ZmllbGQgZm9yICdMYXRuJwogICBpbiB0aGUgcmVnaXN0cnkpLgoKICAgTGFuZ3VhZ2UgdGFncyBh bmQgdGh1cyBsYW5ndWFnZSByYW5nZXMgYXJlIHRvIGJlIHRyZWF0ZWQgYXMgY2FzZQogICBpbnNl bnNpdGl2ZTogdGhlcmUgZXhpc3QgY29udmVudGlvbnMgZm9yIHRoZSBjYXBpdGFsaXphdGlvbiBv ZiBzb21lCiAgIG9mIHRoZSBzdWJ0YWdzLCBidXQgdGhlc2UgTVVTVCBOT1QgYmUgdGFrZW4gdG8g Y2FycnkgbWVhbmluZy4KICAgTWF0Y2hpbmcgb2YgbGFuZ3VhZ2UgdGFncyB0byBsYW5ndWFnZSBy YW5nZXMgTVVTVCBiZSBkb25lIGluIGEgY2FzZQogICBpbnNlbnNpdGl2ZSBtYW5uZXIuCgogICBX aGVuIHdvcmtpbmcgd2l0aCB0YWdzIGFuZCByYW5nZXMsIG5vdGUgdGhhdCBleHRlbnNpb25zIGFu ZCBtb3N0CiAgIHByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIGdlbmVyYWxseSBvcnRob2dvbmFsIHRv IGxhbmd1YWdlIHRhZyBmYWxsYmFjawogICBhbmQgdXNlcnMgU0hPVUxEIGF2b2lkIHVzaW5nIHRo ZXNlIHN1YnRhZ3MgaW4gbGFuZ3VhZ2UgcmFuZ2VzLCBzaW5jZQogICB0aGV5IHdpbGwgb2Z0ZW4g aW50ZXJmZXJlIHdpdGggdGhlIHNlbGVjdGlvbiBvZiBhdmFpbGFibGUgbGFuZ3VhZ2UKICAgY29u dGVudC4gIFNpbmNlIHRoZXNlIHN1YnRhZ3MgYXJlIGFsd2F5cyBhdCB0aGUgZW5kIG9mIHRoZSBz ZXF1ZW5jZQogICBvZiBzdWJ0YWdzLCB0aGV5IGRvbid0IG5vcm1hbGx5IGludGVyZmVyZSB3aXRo IHRoZSB1c2Ugb2YgcHJlZml4ZXMKICAgZm9yIG1hdGNoaW5nIGluIHRoZSBzY2hlbWVzIGRlc2Ny aWJlZCBiZWxvdy4KCiAgIE5vdGUgdGhhdCB3aGVuIHdvcmtpbmcgd2l0aCBiYXNpYyBsYW5ndWFn ZSByYW5nZXMsIG5vIGF0dGVtcHQgaXMgbWFkZQogICB0byBwcm9jZXNzIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIHRhZ3Mgb3IgcmFuZ2VzIGluIGFueSB3YXkuICBUaGUKICAgbGFuZ3VhZ2UgdGFnIGFu ZCBsYW5ndWFnZSByYW5nZSBhcmUgY29tcGFyZWQgaW4gYSBjYXNlIGluc2Vuc2l0aXZlCiAgIG1h bm5lciB1c2luZyBiYXNpYyBzdHJpbmcgcHJvY2Vzc2luZy4gIFRodXMgdGhlIGNob2ljZSBvZiBz dWJ0YWdzIGluCiAgIGJvdGggdGhlIGxhbmd1YWdlIHRhZyBhbmQgbGFuZ3VhZ2UgcmFuZ2UgbWF5 IGFmZmVjdCB0aGUgcmVzdWx0cwogICBwcm9kdWNlZCBhcyBhIHJlc3VsdC4KCjIuMy4gIEV4dGVu ZGVkIExhbmd1YWdlIFJhbmdlCgogICBBIEJhc2ljIExhbmd1YWdlIFJhbmdlIGRvZXMgbm90IGFs d2F5cyBwcm92aWRlIHRoZSBtb3N0IGFwcHJvcHJpYXRlCiAgIHdheSB0byBzcGVjaWZ5IGEgdXNl cidzIHByZWZlcmVuY2VzLiAgU29tZXRpbWVzIGl0IGlzIGJlbmVmaWNpYWwgdG8KICAgZGVmaW5l IGEgbW9yZSBncmFudWxhciBtYXRjaGluZyBzY2hlbWUgdGhhdCB0YWtlcyBhZHZhbnRhZ2Ugb2Yg dGhlCiAgIGludGVybmFsIHN0cnVjdHVyZSBvZiBsYW5ndWFnZSB0YWdzLCBieSBhbGxvd2luZyB0 aGUgdXNlciB0byBzcGVjaWZ5LAogICBmb3IgZXhhbXBsZSwgdGhlIHZhbHVlIG9mIGEgc3BlY2lm aWMgZmllbGQgaW4gYSBsYW5ndWFnZSB0YWcgb3IgdG8KICAgaW5kaWNhdGUgd2hpY2ggdmFsdWVz IGFyZSBvZiBpbnRlcmVzdCBpbiBmaWx0ZXJpbmcgb3Igc2VsZWN0aW5nIHRoZQogICBjb250ZW50 LgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAg ICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRy dS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgSW4gYW4gZXh0ZW5k ZWQgbGFuZ3VhZ2UgcmFuZ2UsIHRoZSBpZGVudGlmaWVyIHRha2VzIHRoZSBmb3JtIG9mIGEKICAg c2VyaWVzIG9mIHN1YnRhZ3Mgd2hpY2ggbXVzdCBjb25zaXN0IG9mIHdlbGwtZm9ybWVkIHN1YnRh Z3Mgb3IgdGhlCiAgIHNwZWNpYWwgc3VidGFnICIqIi4gIEZvciBleGFtcGxlLCB0aGUgbGFuZ3Vh Z2UgcmFuZ2UgImVuLSotVVMiCiAgIHNwZWNpZmllcyBhIHByaW1hcnkgbGFuZ3VhZ2Ugb2YgJ2Vu JywgZm9sbG93ZWQgYnkgYW55IHNjcmlwdCBzdWJ0YWcsCiAgIGZvbGxvd2VkIGJ5IHRoZSByZWdp b24gc3VidGFnICdVUycuCgogICBBbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBjYW4gYmUgcmVw cmVzZW50ZWQgYnkgdGhlIGZvbGxvd2luZyBBQk5GOgogICBleHRlbmRlZC1sYW5ndWFnZS1yYW5n ZSAgPSByYW5nZSA7IGEgcmFuZ2UKICAgICAgICAgICAgICAgICAvIHByaXZhdGV1c2UgICAgICAg ICAgICAgIDsgcHJpdmF0ZSB1c2UgdGFnCiAgICAgICAgICAgICAgICAgLyBncmFuZGZhdGhlcmVk ICAgICAgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9ucwoKICAgcmFuZ2UgICAgICAg ICA9IChsYW5ndWFnZQogICAgICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0XQogICAgICAgICAg ICAgICAgICAgIFsiLSIgcmVnaW9uXQogICAgICAgICAgICAgICAgICAgICooIi0iIHZhcmlhbnQp CiAgICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9uKQogICAgICAgICAgICAgICAgICAg IFsiLSIgcHJpdmF0ZXVzZV0pCgogICBsYW5ndWFnZSAgICAgID0gKDIqM0FMUEhBIFsgZXh0bGFu ZyBdKSA7IHNob3J0ZXN0IElTTyA2MzkgY29kZQogICAgICAgICAgICAgICAgIC8gNEFMUEhBICAg ICAgICAgICAgICAgICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlCiAgICAgICAgICAgICAgICAg LyA1KjhBTFBIQSAgICAgICAgICAgICAgIDsgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcKICAg ICAgICAgICAgICAgICAvICIqIiAgICAgICAgICAgICAgICAgICAgOyAuLi4gb3Igd2lsZGNhcmQK CiAgIGV4dGxhbmcgICAgICAgPSAqMigiLSIgM0FMUEhBKSAoIi0iICggM0FMUEhBIC8gIioiKSkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyByZXNlcnZlZCBmb3Ig ZnV0dXJlIHVzZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IHdp bGRjYXJkIGNhbiBvbmx5IGFwcGVhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA7ICAgYXQgdGhlIGVuZAoKICAgc2NyaXB0ICAgICAgICA9IDRBTFBIQSAgICAgICAg ICAgICAgICAgOyBJU08gMTU5MjQgY29kZQogICAgICAgICAgICAgICAgIC8gIioiICAgICAgICAg ICAgICAgICAgICA7IG9yIHdpbGRjYXJkCgogICByZWdpb24gICAgICAgID0gMkFMUEhBICAgICAg ICAgICAgICAgICA7IElTTyAzMTY2IGNvZGUKICAgICAgICAgICAgICAgICAvIDNESUdJVCAgICAg ICAgICAgICAgICAgOyBVTiBNLjQ5IGNvZGUKICAgICAgICAgICAgICAgICAvICIqIiAgICAgICAg ICAgICAgICAgICAgOyAuLi4gb3Igd2lsZGNhcmQKCiAgIHZhcmlhbnQgICAgICAgPSA1KjhhbHBo YW51bSAgICAgICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cwogICAgICAgICAgICAgICAgIC8g KERJR0lUIDNhbHBoYW51bSkgICAgICA7CiAgICAgICAgICAgICAgICAgLyAiKiIgICAgICAgICAg ICAgICAgICAgIDsgLi4uIG9yIHdpbGRjYXJkCgogICBleHRlbnNpb24gICAgID0gc2luZ2xldG9u ICooIi0iICgyKjhhbHBoYW51bSkpIFsgIi0qIiBdCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDsgZXh0ZW5zaW9uIHN1YnRhZ3MKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgOyB3aWxkY2FyZCBjYW4gb25seSBhcHBlYXIKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyAgIGF0IHRoZSBlbmQKCiAgIHNpbmds ZXRvbiAgICAgPSAleDQxLTU3IC8gJXg1OS01QSAvICV4NjEtNzcgLyAleDc5LTdBIC8gRElHSVQK ICAgICAgICAgICAgICAgICA7ICJhIi0idyIgLyAieSItInoiIC8gIkEiLSJXIiAvICJZIi0iWiIg LyAiMCItIjkiCiAgICAgICAgICAgICAgICAgOyBTaW5nbGUgbGV0dGVyczogeC9YIGlzIHJlc2Vy dmVkIGZvciBwcml2YXRlIHVzZQoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVz IE1heSAyMCwgMjAwNiAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1 CgoKICAgcHJpdmF0ZXVzZSAgICA9ICgieCIvIlgiKSAxKigiLSIgKDEqOGFscGhhbnVtKSkKCiAg IGdyYW5kZmF0aGVyZWQgPSAxKjNBTFBIQSAxKjIoIi0iICgyKjhhbHBoYW51bSkpCiAgICAgICAg ICAgICAgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9uCiAgICAgICAgICAgICAgICAg ICA7IE5vdGU6IGkgaXMgdGhlIG9ubHkgc2luZ2xldG9uCiAgICAgICAgICAgICAgICAgICA7IHRo YXQgc3RhcnRzIGEgZ3JhbmRmYXRoZXJlZCB0YWcKCiAgIGFscGhhbnVtICAgICAgPSAoQUxQSEEg LyBESUdJVCkgICAgICAgOyBsZXR0ZXJzIGFuZCBudW1iZXJzCgogICBBIGZpZWxkIG5vdCBwcmVz ZW50IGluIHRoZSBtaWRkbGUgb2YgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgTUFZCiAgIGJl IHRyZWF0ZWQgYXMgaWYgdGhlIGZpZWxkIGNvbnRhaW5lZCBhICIqIi4gIEZvciBleGFtcGxlLCB0 aGUgcmFuZ2UKICAgImVuLVVTIiBNQVkgYmUgY29uc2lkZXJlZCB0byBiZSBlcXVpdmFsZW50IHRv IHRoZSByYW5nZSAiZW4tKi1VUyIuCiAgIFRoaXMgYWxzbyBtZWFucyB0aGF0IG11bHRpcGxlIHdp bGRjYXJkcyBjYW4gYmUgY29sbGFwc2VkIChzbyB0aGF0CiAgICJlbi0qLSotVVMiIGlzIGVxdWl2 YWxlbnQgdG8gImVuLSotVVMiKS4KCiAgIFdoZW4gd29ya2luZyB3aXRoIHRhZ3MgYW5kIHJhbmdl cyB1c2VycyBTSE9VTEQgbm90ZSB0aGUgZm9sbG93aW5nOgoKICAgMS4gIFByaXZhdGUtdXNlIGFu ZCBFeHRlbnNpb24gc3VidGFncyBhcmUgbm9ybWFsbHkgb3J0aG9nb25hbCB0bwogICAgICAgbGFu Z3VhZ2UgdGFnIGZhbGxiYWNrLiAgSW1wbGVtZW50YXRpb25zIG9yIHNwZWNpZmljYXRpb25zIHRo YXQKICAgICAgIHVzZSBhIGxvb2t1cCAoU2VjdGlvbiAzLjMpIG1hdGNoaW5nIHNjaGVtZSBTSE9V TEQgaWdub3JlCiAgICAgICB1bnJlY29nbml6ZWQgcHJpdmF0ZS11c2UgYW5kIGV4dGVuc2lvbiBz dWJ0YWdzIHdoZW4gcGVyZm9ybWluZwogICAgICAgbGFuZ3VhZ2UgdGFnIGZhbGxiYWNrLiAgU2lu Y2UgdGhlc2Ugc3VidGFncyBhcmUgYWx3YXlzIGF0IHRoZSBlbmQKICAgICAgIG9mIHRoZSBzZXF1 ZW5jZSBvZiBzdWJ0YWdzLCB0aGV5IGRvbid0IG5vcm1hbGx5IGludGVyZmVyZSB3aXRoCiAgICAg ICB0aGUgdXNlIG9mIHByZWZpeGVzIGZvciBtYXRjaGluZyBpbiB0aGUgc2NoZW1lcyBkZXNjcmli ZWQgYmVsb3cuCgogICAyLiAgQXBwbGljYXRpb25zLCBzcGVjaWZpY2F0aW9ucywgb3IgcHJvdG9j b2xzIHRoYXQgY2hvb3NlIG5vdCB0bwogICAgICAgaW50ZXJwcmV0IG9uZSBvciBtb3JlIHByaXZh dGUtdXNlIG9yIGV4dGVuc2lvbiBzdWJ0YWdzIFNIT1VMRCBOT1QKICAgICAgIHJlbW92ZSBvciBt b2RpZnkgdGhlc2UgZXh0ZW5zaW9ucyBpbiBjb250ZW50IHRoYXQgdGhleSBhcmUKICAgICAgIHBy b2Nlc3NpbmcuICBXaGVuIGEgbGFuZ3VhZ2UgdGFnIGluc3RhbmNlIGlzIHRvIGJlIHVzZWQgaW4g YQogICAgICAgc3BlY2lmaWMsIGtub3duIHByb3RvY29sLCBhbmQgaXMgbm90IGJlaW5nIHBhc3Nl ZCB0aHJvdWdoIHRvCiAgICAgICBvdGhlciBwcm90b2NvbHMsIGxhbmd1YWdlIHRhZ3MgTUFZIGJl IGZpbHRlcmVkIHRvIHJlbW92ZSBzdWJ0YWdzCiAgICAgICBhbmQgZXh0ZW5zaW9ucyB0aGF0IGFy ZSBub3Qgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBTdWNoCiAgICAgICBmaWx0ZXJpbmcg U0hPVUxEIGJlIGF2b2lkZWQsIGlmIHBvc3NpYmxlLCBzaW5jZSBpdCByZW1vdmVzCiAgICAgICBp bmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGJlIHJlbGV2YW50IGlmIHNlcnZpY2VzIG9uIHRoZSBvdGhl ciBlbmQKICAgICAgIG9mIHRoZSBwcm90b2NvbCB3b3VsZCBtYWtlIHVzZSBvZiB0aGF0IGluZm9y bWF0aW9uLgoKICAgMy4gIFNvbWUgYXBwbGljYXRpb25zIG9mIGxhbmd1YWdlIHRhZ3MgbWlnaHQg d2FudCBvciBuZWVkIHRvIGNvbnNpZGVyCiAgICAgICBleHRlbnNpb25zIGFuZCBwcml2YXRlLXVz ZSBzdWJ0YWdzIHdoZW4gbWF0Y2hpbmcgdGFncy4gIElmCiAgICAgICBleHRlbnNpb25zIGFuZCBw cml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBpbmNsdWRlZCBpbiBhIG1hdGNoaW5nIG9yCiAgICAgICBm aWx0ZXJpbmcgcHJvY2VzcyB0aGF0IHV0aWxpemVzIHRoZSBvbmUgb2YgdGhlIHNjaGVtZXMgZGVz Y3JpYmVkCiAgICAgICBpbiB0aGlzIGRvY3VtZW50LCB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbiBT SE9VTEQgY2Fub25pY2FsaXplIHRoZQogICAgICAgbGFuZ3VhZ2UgdGFncyBhbmQvb3IgcmFuZ2Vz IGJlZm9yZSBwZXJmb3JtaW5nIHRoZSBtYXRjaGluZy4gIE5vdGUKICAgICAgIHRoYXQgbGFuZ3Vh Z2UgdGFnIHByb2Nlc3NvcnMgdGhhdCBjbGFpbSB0byBiZSAid2VsbC1mb3JtZWQiCiAgICAgICBw cm9jZXNzb3JzIGFzIGRlZmluZWQgaW4gW1JGQzMwNjZiaXNdIGdlbmVyYWxseSBmYWxsIGludG8g dGhpcwogICAgICAgY2F0ZWdvcnkuCgogICBUaGVyZSBhcmUgc2V2ZXJhbCBtYXRjaGluZyBhbGdv cml0aG1zIG9yIHNjaGVtZXMgd2hpY2ggY2FuIGJlIGFwcGxpZWQKICAgd2hlbiBtYXRjaGluZyBl eHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgdG8gbGFuZ3VhZ2UgdGFncy4KCgoKUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA1CgoKMy4gIFR5cGVzIG9mIE1hdGNoaW5nCgogICBNYXRjaGlu ZyBsYW5ndWFnZSByYW5nZXMgdG8gbGFuZ3VhZ2UgdGFncyBjYW4gYmUgZG9uZSBpbiBhIG51bWJl ciBvZgogICBkaWZmZXJlbnQgd2F5cy4gIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIGRpZmZl cmVudCB0eXBlcyBvZgogICBtYXRjaGluZyBzY2hlbWUsIGFzIHdlbGwgYXMgdGhlIGNvbnNpZGVy YXRpb25zIGZvciBjaG9vc2luZyBiZXR3ZWVuCiAgIHRoZW0uCgogICBUaGVyZSBhcmUgdHdvIGJh c2ljIHR5cGVzIG9mIG1hdGNoaW5nIHNjaGVtZTogdGhvc2UgdGhhdCBwcm9kdWNlIGFuCiAgIG9w ZW4tZW5kZWQgc2V0IG9mIGNvbnRlbnQgKGNhbGxlZCAiZmlsdGVyaW5nIikgYW5kIHRob3NlIHRo YXQgcHJvZHVjZQogICBhIHNpbmdsZSBpbmZvcm1hdGlvbiBpdGVtIGZvciBhIGdpdmVuIHJlcXVl c3QgKGNhbGxlZCAibG9va3VwIikuCgogICBBIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2Ug dHdvIHR5cGVzIG9mIG1hdGNoaW5nIHNjaGVtZSBpcyB0aGF0CiAgIHRoZSBsYW5ndWFnZSByYW5n ZSBmb3IgZmlsdGVyaW5nIG9wZXJhdGlvbnMgaXMgYWx3YXlzIHRoZSBfbGVhc3RfCiAgIHNwZWNp ZmljIHRhZyBvbmUgd2lsbCBhY2NlcHQgYXMgYSBtYXRjaCwgd2hpbGUgZm9yIGxvb2t1cCBvcGVy YXRpb25zCiAgIHRoZSBsYW5ndWFnZSByYW5nZSBpcyBhbHdheXMgdGhlIF9tb3N0XyBzcGVjaWZp YyB0YWcuCgozLjEuICBDaG9vc2luZyBhIFR5cGUgb2YgTWF0Y2hpbmcKCiAgIEFwcGxpY2F0aW9u cywgcHJvdG9jb2xzLCBhbmQgc3BlY2lmaWNhdGlvbnMgYXJlIGZhY2VkIHdpdGggdGhlCiAgIGRl Y2lzaW9uIG9mIHdoYXQgdHlwZSBvZiBtYXRjaGluZyB0byB1c2UuICBTb21ldGltZXMsIGRpZmZl cmVudAogICBzdHlsZXMgb2YgbWF0Y2hpbmcgbWlnaHQgYmUgc3VpdGVkIGZvciBkaWZmZXJlbnQg a2luZHMgb2YgcHJvY2Vzc2luZwogICB3aXRoaW4gYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uIG9y IHByb3RvY29sLgoKICAgRmlsdGVyaW5nIGNhbiBiZSB1c2VkIHRvIHByb2R1Y2UgYSBzZXQgb2Yg cmVzdWx0cyAoc3VjaCBhcyBhCiAgIGNvbGxlY3Rpb24gb2YgZG9jdW1lbnRzKS4gIEZvciBleGFt cGxlLCBpZiB1c2luZyBhIHNlYXJjaCBlbmdpbmUsIG9uZQogICBtaWdodCB1c2UgZmlsdGVyaW5n IHRvIGxpbWl0IHRoZSByZXN1bHRzIHRvIGRvY3VtZW50cyB3cml0dGVuIGluCiAgIEZyZW5jaC4g IEl0IGNhbiBhbHNvIGJlIHVzZWQgd2hlbiBkZWNpZGluZyB3aGV0aGVyIHRvIHBlcmZvcm0gc29t ZQogICBwcm9jZXNzaW5nIHRoYXQgaXMgbGFuZ3VhZ2Ugc2Vuc2l0aXZlIG9uIHNvbWUgY29udGVu dC4gIEZvciBleGFtcGxlLAogICBhIHByb2Nlc3MgbWlnaHQgY2F1c2UgcGFyYWdyYXBocyB3aG9z ZSBsYW5ndWFnZSB0YWcgbWF0Y2hlZCB0aGUKICAgbGFuZ3VhZ2UgcmFuZ2UgIm5sIiB0byBiZSBk aXNwbGF5ZWQgaW4gaXRhbGljcyB3aXRoaW4gYSBkb2N1bWVudC4KCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRocmVlIHR5cGVzIG9mIGZpbHRlcmluZzoKCiAgIDEuICBCYXNpYyBGaWx0ZXJp bmcgKFNlY3Rpb24gMy4yLjEpIGlzIHVzZWQgdG8gbWF0Y2ggY29udGVudCB1c2luZwogICAgICAg YmFzaWMgbGFuZ3VhZ2UgcmFuZ2VzU2VjdGlvbiAyLjIuICBJdCBpcyBjb21wYXRpYmxlIHdpdGgK ICAgICAgIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBwcm9kdWNlIGV4dGVuZGVkIGxhbmd1 YWdlIHJhbmdlcy4KCiAgIDIuICBFeHRlbmRlZCBSYW5nZSBGaWx0ZXJpbmcgKFNlY3Rpb24gMy4y LjIpIGlzIHVzZWQgdG8gbWF0Y2ggY29udGVudAogICAgICAgdXNpbmcgZXh0ZW5kZWQgbGFuZ3Vh Z2UgcmFuZ2VzU2VjdGlvbiAyLjMuICBOZXdlciBpbXBsZW1lbnRhdGlvbnMKICAgICAgIFNIT1VM RCB1c2UgdGhpcyBmb3JtIG9mIGZpbHRlcmluZyBpbiBwcmVmZXJlbmNlIHRvIGJhc2ljCiAgICAg ICBmaWx0ZXJpbmcuCgogICAzLiAgU2NvcmVkIEZpbHRlcmluZyAoU2VjdGlvbiAzLjIuMykgcHJv ZHVjZXMgYW4gb3JkZXJlZCBzZXQgb2YKICAgICAgIGNvbnRlbnQgdXNpbmcgZWl0aGVyIGJhc2lj IG9yIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlcy4gIEl0CiAgICAgICBzaG91bGQgYmUgdXNlZCB3 aGVuIHRoZSBxdWFsaXR5IG9mIHRoZSBtYXRjaCB3aXRoaW4gYSBzcGVjaWZpYwogICAgICAgbGFu Z3VhZ2UgcmFuZ2UgaXMgaW1wb3J0YW50LCBhcyB3aGVuIHByZXNlbnRpbmcgYSBsaXN0IG9mCiAg ICAgICBkb2N1bWVudHMgcmVzdWx0aW5nIGZyb20gYSBzZWFyY2guCgoKCgpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICAgW1BhZ2Ug OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDUKCgogICBMb29rdXAgKFNlY3Rpb24gMy4zKSBpcyB1c2VkIHdo ZW4gZWFjaCByZXF1ZXN0IE1VU1QgcHJvZHVjZSBleGFjdGx5CiAgIG9uZSBwaWVjZSBvZiBjb250 ZW50LiAgRm9yIGV4YW1wbGUsIGEgV2ViIHNlcnZlciBtaWdodCB1c2UgdGhlCiAgIEFjY2VwdC1M YW5ndWFnZSBIVFRQIGhlYWRlciB0byBjaG9vc2Ugd2hpY2ggbGFuZ3VhZ2UgdG8gcmV0dXJuIGEK ICAgY3VzdG9tIDQwNCBwYWdlIGluOiBzaW5jZSBpdCBjYW4gcmV0dXJuIG9ubHkgb25lIHBhZ2Us IGl0IG11c3QgY2hvb3NlCiAgIGEgc2luZ2xlIGl0ZW0gYW5kIGl0IG11c3QgcmV0dXJuIHNvbWUg aXRlbSwgZXZlbiBpZiBubyBjb250ZW50CiAgIG1hdGNoZXMgdGhlIGxhbmd1YWdlIHJhbmdlcyBz dXBwbGllZCBieSB0aGUgdXNlci4KCiAgIE1vc3QgdHlwZXMgb2YgbWF0Y2hpbmcgaW4gdGhpcyBk b2N1bWVudCBhcmUgZGVzaWduZWQgc28gdGhhdAogICBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IGhh dmUgdG8gZXhhbWluZSB0aGUgdmFsdWVzIG9mIHRoZSBzdWJ0YWdzCiAgIHN1cHBsaWVkIGFuZCwg ZXhjZXB0IGZvciBzY29yZWQgZmlsdGVyaW5nLCB0aGV5IGRvIG5vdCBuZWVkIGFjY2VzcyB0bwog ICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IG5vciBkbyB0aGV5IHJlcXVpcmUgdGhlIHVz ZSBvZiB2YWxpZAogICBzdWJ0YWdzIGluIGVpdGhlciBsYW5ndWFnZSB0YWdzIG9yIGxhbmd1YWdl IHJhbmdlcy4gIFRoaXMgaGFzIGdyZWF0CiAgIGJlbmVmaXQgZm9yIHNwZWVkIGFuZCBzaW1wbGlj aXR5IG9mIGltcGxlbWVudGF0aW9uLgoKICAgSW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsc28gd2lz aCB0byB1c2Ugc2VtYW50aWMgaW5mb3JtYXRpb24gZXh0ZXJuYWwKICAgdG8gdGhlIGxhbmdhdWdl IHRhZ3Mgd2hlbiBwZXJmb3JtaW5nIGZhbGxiYWNrLiAgRm9yIGV4YW1wbGUsIHRoZQogICBwcmlt YXJ5IGxhbmd1YWdlIHN1YnRhZ3MgJ25uJyAoTnlub3JzayBOb3J3ZWdpYW4pIGFuZCAnbmInIChC b2ttYWwKICAgTm9yd2VnaWFuKSBtaWdodCBib3RoIGJlIHVzZWZ1bGx5IG1hdGNoZWQgdG8gdGhl IG1vcmUgZ2VuZXJhbCBzdWJ0YWcKICAgJ25vJyAoTm9yd2VnaWFuKS4gIE9yIGFuIGltcGxlbWVu dGF0aW9uIG1pZ2h0IGluZmVyIHRoYXQgY29udGVudAogICBsYWJlbGVkICJ6aC1DTiIgaXMgbW9y ZWx5IGxpa2VseSB0byBtYXRjaCB0aGUgcmFuZ2UgInpoLUhhbnMiIHRoYW4KICAgZXF1aXZhbGVu dCBjb250ZW50IGxhYmVsZWQgInpoLVRXIi4KCjMuMi4gIEZpbHRlcmluZwoKICAgRmlsdGVyaW5n IGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzZXQgb2YgY29udGVudCB0aGF0IG1hdGNoZXMgYSBnaXZl bgogICBwcmVmaXguICBJdCBpcyBjYWxsZWQgImZpbHRlcmluZyIgYmVjYXVzZSB0aGlzIHNldCBv ZiBjb250ZW50IG1heQogICBjb250YWluIG5vIGl0ZW1zIGF0IGFsbCBvciBpdCBtYXkgcmV0dXJu IGFuIGFyYml0cmFyeSBudW1iZXIgb2YKICAgbWF0Y2hpbmcgaXRlbXMtLWFzIG1hbnkgYXMgbWF0 Y2ggdGhlIGxhbmd1YWdlIHJhbmdlIHVzZWQgdG8gc3BlY2lmeQogICB0aGUgaXRlbXMsIHRodXMg ZmlsdGVyaW5nIG91dCB0aGUgbm9uLW1hdGNoaW5nIGNvbnRlbnQuCgogICBJbiBmaWx0ZXJpbmcs IHRoZSBsYW5ndWFnZSByYW5nZSByZXByZXNlbnRzIHRoZSBfbGVhc3RfIHNwZWNpZmljIHRhZwog ICB3aGljaCBpcyBhbiBhY2NlcHRhYmxlIG1hdGNoLiAgVGhhdCBpcywgYWxsIG9mIHRoZSBsYW5n dWFnZSB0YWdzIGluCiAgIHRoZSBzZXQgb2YgZmlsdGVyZWQgY29udGVudCB3aWxsIGhhdmUgYW4g ZXF1YWwgb3IgZ3JlYXRlciBudW1iZXIgb2YKICAgc3VidGFncyB0aGFuIHRoZSBsYW5ndWFnZSBy YW5nZS4gIEZvciBleGFtcGxlLCBpZiB0aGUgbGFuZ3VhZ2UgcmFuZ2UKICAgaXMgImRlLUNIIiwg b25lIG1pZ2h0IHNlZSBtYXRjaGluZyBjb250ZW50IHdpdGggdGhlIHRhZyAiZGUtQ0gtMTk5NiIK ICAgYnV0IG9uZSB3aWxsIG5ldmVyIHNlZSBhIG1hdGNoIHdpdGggdGhlIHRhZyAiZGUiLgoKICAg SWYgdGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgKHNlZSBTZWN0aW9uIDIuMSkgY29udGFpbnMg bW9yZSB0aGFuCiAgIG9uZSByYW5nZSwgdGhlIGNvbnRlbnQgcmV0dXJuZWQgaXMgdHlwaWNhbGx5 IG9yZGVyZWQgaW4gZGVzY2VuZGluZwogICBsZXZlbCBvZiBwcmVmZXJlbmNlLgoKICAgU29tZSBl eGFtcGxlcyB3aGVyZSBmaWx0ZXJpbmcgbWlnaHQgYmUgYXBwcm9wcmlhdGUgaW5jbHVkZToKCiAg IG8gIEFwcGx5aW5nIGEgc3R5bGUgdG8gc2VjdGlvbnMgb2YgYSBkb2N1bWVudCBpbiBhIHBhcnRp Y3VsYXIKICAgICAgbGFuZ3VhZ2UgcmFuZ2UuCgogICBvICBEaXNwbGF5aW5nIHRoZSBzZXQgb2Yg ZG9jdW1lbnRzIGNvbnRhaW5pbmcgYSBwYXJ0aWN1bGFyIHNldCBvZgogICAgICBrZXl3b3JkcyB3 cml0dGVuIGluIGEgc3BlY2lmaWMgbGFuZ3VhZ2UuCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAg ICAgRXhwaXJlcyBNYXkgMjAsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNQoKCiAgIG8gIFNlbGVjdGluZyBhbGwgZW1haWwgaXRlbXMgd3JpdHRlbiBpbiBz cGVjaWZpYyByYW5nZSBvZiBsYW5ndWFnZXMuCgogICBGaWx0ZXJpbmcgY2FuIHByb2R1Y2UgZWl0 aGVyIG9yZGVyZWQgb3IgdW5vcmRlcmVkIHNldCBvZiByZXN1bHRzLgogICBGb3IgZXhhbXBsZSwg YXBwbHlpbmcgZm9ybWF0dGluZyB0byBhIGRvY3VtZW50IGJhc2VkIG9uIHRoZSBsYW5ndWFnZQog ICBvZiBzcGVjaWZpYyBwaWVjZXMgb2YgY29udGVudCBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb250 ZW50IHRvIGJlCiAgIG9yZGVyZWQuICBJdCBpcyBzdWZmaWNpZW50IHRvIGtub3cgd2hldGhlciBh IHNwZWNpZmljIHBpZWNlIG9mCiAgIGNvbnRlbnQgbWF0Y2hlcyBvciBkb2VzIG5vdCBtYXRjaC4g IEEgc2VhcmNoIGFwcGxpY2F0aW9uLCBvbiB0aGUKICAgb3RoZXIgaGFuZCwgcHJvYmFibHkgd291 bGQgcHV0IHRoZSByZXN1bHRzIGludG8gYSBwcmlvcml0eSBvcmRlci4KCiAgIElmIGFuIG9yZGVy ZWQgc2V0IGlzIGRlc2lyZWQsIGFzIGRlc2NyaWJlZCBhYm92ZSwgdGhlbiB0aGUKICAgYXBwbGlj YXRpb24gb3IgcHJvdG9jb2wgbmVlZHMgdG8gZGV0ZXJtaW5lIHRoZSByZWxhdGl2ZSAicXVhbGl0 eSIgb2YKICAgdGhlIG1hdGNoIGJldHdlZW4gZGlmZmVyZW50IGxhbmd1YWdlIHRhZ3MgYW5kIHRo ZSBsYW5ndWFnZSByYW5nZS4KCiAgIFRoaXMgbWVhc3VybWVudCBpcyBjYWxsZWQgYSAiZGlzdGFu Y2UgbWV0cmljIi4gIEEgZGlzdGFuY2UgbWV0cmljCiAgIGFzc2lnbnMgYSBudW1lcmljIHZhbHVl IHRvIHRoZSBjb21wYXJpc29uIG9mIGVhY2ggbGFuZ3VhZ2UgdGFnIHRvIGEKICAgbGFuZ3VhZ2Ug cmFuZ2UgYW5kIHJlcHJlc2VudHMgdGhlICdkaXN0YW5jZScgYmV0d2VlbiB0aGUgdHdvLiAgQQog ICBkaXN0YW5jZSBvZiB6ZXJvIG1lYW5zIHRoYXQgdGhleSBhcmUgaWRlbnRpY2FsLCBhIHNtYWxs IGRpc3RhbmNlCiAgIGluZGljYXRlcyB0aGF0IHRoZXkgYXJlIHZlcnkgc2ltaWxhciwgYW5kIGEg bGFyZ2UgZGlzdGFuY2UgaW5kaWNhdGVkCiAgIHRoYXQgdGhleSBhcmUgdmVyeSBkaWZmZXJlbnQu ICBVc2luZyBhIGRpc3RhbmNlIG1ldHJpYywKICAgaW1wbGVtZW50YXRpb25zIGNhbiwgZm9yIGV4 YW1wbGUsIGFsbG93IHVzZXJzIHRvIHNlbGVjdCBhIHRocmVzaG9sZAogICBkaXN0YW5jZSBmb3Ig YSBtYXRjaCB0byBiZSAic3VjY2Vzc2Z1bCIgd2hpbGUgZmlsdGVyaW5nIG9yIGl0IGNhbiB1c2UK ICAgdGhlIG51bWVyaWMgdmFsdWUgdG8gb3JkZXIgdGhlIHJlc3VsdHMuCgozLjIuMS4gIEZpbHRl cmluZyB3aXRoIEJhc2ljIExhbmd1YWdlIFJhbmdlcwoKICAgV2hlbiBmaWx0ZXJpbmcgdXNpbmcg YSBiYXNpYyBsYW5ndWFnZSByYW5nZSwgdGhlIGxhbmd1YWdlIHJhbmdlCiAgIG1hdGNoZXMgYSBs YW5ndWFnZSB0YWcgaWYgaXQgZXhhY3RseSBlcXVhbHMgdGhlIHRhZywgb3IgaWYgaXQgZXhhY3Rs eQogICBlcXVhbHMgYSBwcmVmaXggb2YgdGhlIHRhZyBzdWNoIHRoYXQgdGhlIGZpcnN0IGNoYXJh Y3RlciBmb2xsb3dpbmcKICAgdGhlIHByZWZpeCBpcyAiLSIuICAoVGhhdCBpcywgdGhlIGxhbmd1 YWdlLXJhbmdlICJkZS1kZSIgbWF0Y2hlcyB0aGUKICAgbGFuZ3VhZ2UgdGFnICJkZS1ERS0xOTk2 IiwgYnV0IG5vdCB0aGUgbGFuZ3VhZ2UgdGFnICJkZS1EZXZhIi4pCgogICBUaGUgc3BlY2lhbCBy YW5nZSAiKiIgbWF0Y2hlcyBhbnkgdGFnLiAgQSBwcm90b2NvbCB3aGljaCB1c2VzCiAgIGxhbmd1 YWdlIHJhbmdlcyBNQVkgc3BlY2lmeSBhZGRpdGlvbmFsIHJ1bGVzIGFib3V0IHRoZSBzZW1hbnRp Y3Mgb2YKICAgIioiOyBmb3IgaW5zdGFuY2UsIEhUVFAvMS4xIHNwZWNpZmllcyB0aGF0IHRoZSBy YW5nZSAiKiIgbWF0Y2hlcyBvbmx5CiAgIGxhbmd1YWdlcyBub3QgbWF0Y2hlZCBieSBhbnkgb3Ro ZXIgcmFuZ2Ugd2l0aGluIGFuICJBY2NlcHQtTGFuZ3VhZ2UiCiAgIGhlYWRlci4KCjMuMi4yLiAg RmlsdGVyaW5nIHdpdGggRXh0ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2VzCgogICBJbiB0aGUgRXh0ZW5k ZWQgUmFuZ2UgTWF0Y2hpbmcgc2NoZW1lLCBlYWNoIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlCiAg IGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGlzIGNvbnNpZGVyZWQgaW4gdHVybiwgYWNj b3JkaW5nIHRvCiAgIHByaW9yaXR5LiAgVGhlIHN1YnRhZ3MgaW4gZWFjaCBleHRlbmRlZCBsYW5n dWFnZSByYW5nZSBhcmUgY29tcGFyZWQKICAgdG8gdGhlIGNvcnJlc3BvbmRpbmcgc3VidGFncyBp biB0aGUgbGFuZ3VhZ2UgdGFnIGJlaW5nIGV4YW1pbmVkLiAgVGhlCiAgIHN1YnRhZyBmcm9tIHRo ZSByYW5nZSBpcyBjb25zaWRlcmVkIHRvIG1hdGNoIGlmIGl0IGV4YWN0bHkgbWF0Y2hlcwogICB0 aGUgY29ycmVzcG9uZGluZyBzdWJ0YWcgaW4gdGhlIHRhZyBvciB0aGUgcmFuZ2UncyBzdWJ0YWcg aGFzIHRoZQogICB2YWx1ZSAiKiIgKHdoaWNoIG1hdGNoZXMgYWxsIHN1YnRhZ3MsIGluY2x1ZGlu ZyB0aGUgZW1wdHkgc3VidGFnKS4KICAgRXh0ZW5kZWQgUmFuZ2UgTWF0Y2hpbmcgaXMgYW4gZXh0 ZW5zaW9uIG9mIGJhc2ljIG1hdGNoaW5nCiAgIChTZWN0aW9uIDMuMi4xKTogdGhlIGxhbmd1YWdl IHJhbmdlIHJlcHJlc2VudHMgdGhlIGxlYXN0IHNwZWNpZmljIHRhZwoKCgpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAx MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDUKCgogICB3aGljaCBpcyBhbiBhY2NlcHRhYmxlIG1hdGNoLgoK ICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBNQVkgYmUgc3BlY2lmaWVkIGluIHRoZSBsYW5ndWFnZSBy YW5nZSBhbmQgTVVTVAogICBOT1QgYmUgaWdub3JlZCB3aGVuIG1hdGNoaW5nLgoKICAgU3VidGFn cyBub3Qgc3BlY2lmaWVkLCBpbmNsdWRpbmcgdGhvc2UgYXQgdGhlIGVuZCBvZiB0aGUgbGFuZ3Vh Z2UKICAgcmFuZ2UsIGFyZSBhc3NpZ25lZCB0aGUgdmFsdWUgIioiLiAgVGhpcyBtYWtlcyBlYWNo IHJhbmdlIGludG8gYQogICBwcmVmaXggbXVjaCBsaWtlIHRoYXQgdXNlZCBpbiBiYXNpYyBsYW5n dWFnZSByYW5nZSBtYXRjaGluZy4gIEZvcgogICBleGFtcGxlLCB0aGUgZXh0ZW5kZWQgbGFuZ3Vh Z2UgcmFuZ2UgInpoLSotQ04iIG1hdGNoZXMgYWxsIG9mIHRoZQogICBmb2xsb3dpbmcgdGFncyBi ZWNhdXNlIHRoZSB1bnNwZWNpZmllZCB2YXJpYW50IGZpZWxkIGlzIGV4cGFuZGVkIHRvCiAgICIq IjoKCiAgICAgIHpoLUhhbnQtQ04KCiAgICAgIHpoLUNOCgogICAgICB6aC1IYW5zLUNOCgogICAg ICB6aC1DTi14LXdhZGVnaWxlCgogICAgICB6aC1MYXRuLUNOLWJvb250CgogICAgICB6aC1jbW4t SGFucy1DTi14LXByaXZhdGUKCjMuMi4zLiAgRGlzdGFuY2UgTWV0cmljIEZpbHRlcmluZwoKICAg Qm90aCBiYXNpYyBhbmQgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgZmlsdGVyaW5nIHByb2R1Y2Ug c2ltcGxlCiAgIGJvb2xlYW4gbWF0Y2hlcy4gIFNvbWV0aW1lcyBpdCBtYXkgYmUgYmVuZWZpY2lh bCB0byBwcm92aWRlIGFuIGFycmF5CiAgIG9mIHJlc3VsdHMgd2l0aCBkaWZmZXJlbnQgbGV2ZWxz IG9mIG1hdGNoaW5nLCBmb3IgZXhhbXBsZSwgc29ydGluZwogICByZXN1bHRzIGJhc2VkIG9uIHRo ZSBvdmVyYWxsICJxdWFsaXR5IiBvZiB0aGUgbWF0Y2guICBEaXN0YW5jZSBtZXRyaWMKICAgZmls dGVyaW5nIHByb3ZpZGVzIGEgd2F5IHRvIGdlbmVyYXRlIHRoZXNlIHF1YWxpdHkgdmFsdWVzLgoK ICAgRmlyc3QgYm90aCB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgYW5kIHRoZSBsYW5ndWFn ZSB0YWdzIHRvIGJlCiAgIG1hdGNoZWQgdG8gaXQgbXVzdCBiZSBjYW5vbmljYWxpemVkIGJ5IG1h cHBpbmcgZ3JhbmRmYXRoZXJlZCBhbmQKICAgb2Jzb2xldGUgdGFncyBpbnRvIG1vZGVybiBlcXVp dmFsZW50cy4KCiAgIFRoZSBsYW5ndWFnZSByYW5nZSBhbmQgdGhlIGxhbmd1YWdlIHRhZ3MgYXJl IHRoZW4gdHJhbnNmb3JtZWQgaW50bwogICBxdWludHVwbGVzIG9mIGVsZW1lbnRzIG9mIHRoZSBm b3JtIChsYW5ndWFnZSwgc2NyaXB0LCBjb3VudHJ5LAogICB2YXJpYW50LCBleHRlbnNpb24pLiAg QW55IGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgYXJlIGNvbnNpZGVyZWQKICAgcGFydCBvZiB0 aGUgbGFuZ3VhZ2UgZWxlbWVudDsgcHJpdmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlcyBhcmUKICAg Y29uc2lkZXJlZCBwYXJ0IG9mIHRoZSBsYW5ndWFnZSBlbGVtZW50IGlmIGluIHRoZSBpbml0aWFs IHBvc2l0aW9uIGluCiAgIHRoZSB0YWcgYW5kIHBhcnQgb2YgdGhlIHZhcmlhbnQgZWxlbWVudCBp ZiBub3QuICBMYW5ndWFnZSBzdWJ0YWdzCiAgICd1bmQnLCAnbXVsJywgYW5kIHRoZSBzY3JpcHQg c3VidGFnICdaeXl5JyBhcmUgY29udmVydGVkIHRvICIqIi4KCiAgIE1pc3NpbmcgY29tcG9uZW50 cyBpbiB0aGUgbGFuZ3VhZ2UtdGFnIGFyZSBzZXQgdG8gIioiOyB0aHVzIGEgIioiCiAgIHBhdHRl cm4gYmVjb21lcyB0aGUgcXVpbnR1cGxlICgiKiIsICIqIiwgIioiLCAiKiIsICIqIikuICBNaXNz aW5nCiAgIGNvbXBvbmVudHMgaW4gdGhlIGV4dGVuZGVkIGxhbmd1YWdlLXJhbmdlIGFyZSBoYW5k bGVkIHNpbWlsYXJseSB0bwogICBleHRlbmRlZCByYW5nZSBsb29rdXA6IG1pc3NpbmcgaW50ZXJu YWwgc3VidGFncyBhcmUgZXhwYW5kZWQgdG8gIioiLgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAg ICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5v dmVtYmVyIDIwMDUKCgogICBNaXNzaW5nIGVuZCBzdWJ0YWdzIGFyZSBleHBhbmRlZCBhcyB0aGUg ZW1wdHkgc3RyaW5nLiAgVGh1cyBhIHBhdHRlcm4KICAgImVuLVVTIiBiZWNvbWVzIHRoZSBxdWlu dHVwbGUgKCJlbiIsIioiLCJVUyIsIiIsIiIpLgoKICAgSGVyZSBhcmUgc29tZSBleGFtcGxlcyBv ZiBsYW5ndWFnZS10YWdzIGFuZCB0aGVpciBxdWludHVwbGVzOgoKICAgICAgZW4tVVMgKCJlbiIs IioiLCJVUyIsIioiLCIqIikKCiAgICAgIHNyLUxhdG4gKCJzciwiTGF0biIsIioiLCIqIiwiKiIp CgogICAgICB6aC1jbW4tSGFudCAoInpoLWNtbiIsIkhhbnQiLCIqIiwiKiIsIioiKQoKICAgICAg eC1mb28gKCJ4LWZvbyIsIioiLCIqIiwiKiIsIioiKQoKICAgICAgZW4teC1mb28gKCJlbiIsIioi LCIqIiwieC1mb28iLCIqIikKCiAgICAgIGktZGVmYXVsdCAoImktZGVmYXVsdCIsIioiLCIqIiwi KiIsIioiKQoKICAgICAgc2wtTGF0bi1JVC1yb2F6aiAoInNsIiwiTGF0biIsIklUIiwicm96YWoi LCIqIikKCiAgICAgIHpoLXItd2FkZWdpbGUgKCJ6aCIsIioiLCIqIiwiKiIsInItd2FkZWdpbGUi KSAvLyBoeXBvdGhldGljYWwKCiAgIEVhY2ggbGFuZ3VhZ2UtcmFuZ2UvbGFuZ3VhZ2UtdGFnIHBh aXIgYmVpbmcgY29tcGFyZWQgaXMgYXNzaWduZWQgYQogICBkaXN0YW5jZSB2YWx1ZSwgd2hlcmVi eSBzbWFsbCB2YWx1ZXMgaW5kaWNhdGUgYmV0dGVyIG1hdGNoZXMgYW5kCiAgIGxhcmdlIHZhbHVl cyBpbmRpY2F0ZSB3b3JzZSBvbmVzLiAgVGhlIGRpc3RhbmNlIGJldHdlZW4gdGhlIHBhaXIgaXMK ICAgdGhlIHN1bSBvZiB0aGUgZGlzdGFuY2VzIGZvciBlYWNoIG9mIHRoZSBjb3JyZXNwb25kaW5n IGVsZW1lbnRzIG9mCiAgIHRoZSBxdWludHVwbGUuICBJZiB0aGUgZWxlbWVudHMgYXJlIGlkZW50 aWNhbCBvciBvbmUgaXMgJyonLCB0aGVuIHRoZQogICBkaXN0YW5jZSB2YWx1ZSBiZXR3ZWVuIHRo ZW0gaXMgemVyby4gIE90aGVyd2lzZSwgaXQgaXMgZ2l2ZW4gYnkgdGhlCiAgIGZvbGxvd2luZyB0 YWJsZToKICAgICAyNTYgICAgbGFuZ3VhZ2UgbWlzbWF0Y2gKICAgICAxMjggICAgc2NyaXB0IG1p c21hdGNoCiAgICAgIDMyICAgIHJlZ2lvbiBtaXNtYXRjaAogICAgICAgNCAgICB2YXJpYW50IG1p c21hdGNoCiAgICAgICAxICAgIGV4dGVuc2lvbiBtaXNtYXRjaAoKICAgQSB2YWx1ZSBvZiAwIGlz IGEgcGVyZmVjdCBtYXRjaDsgNDIxIGlzIG5vIG1hdGNoIGF0IGFsbC4gIERpZmZlcmVudAogICB0 aHJlc2hvbGQgdmFsdWVzIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGZvciBkaWZmZXJlbnQgYXBwbGlj YXRpb25zIG9yCiAgIHByb3RvY29scy4gIEltcGxlbWVudGF0aW9ucyB3aWxsIHVzdWFsbHkgYWxs b3cgdXNlcnMgdG8gY2hvb3NlIHRoZQogICBtb3N0IGFwcHJvcHJpYXRlIHNlbGVjdGlvbiB2YWx1 ZSwgcmFua2luZyB0aGUgbWF0Y2hlZCBpdGVtcyBiYXNlZCBvbgogICBzY29yZS4KCiAgIEV4YW1w bGVzIG9mIHZhcmlvdXMgdGFnJ3MgZGlzdGFuY2VzIGZyb20gdGhlIHJhbmdlICJlbi1VUyI6Cgog ICAiZnIiICAgICAgICAgICAgIDI1NiAobGFuZ3VhZ2UgbWlzbWF0Y2gsIHJlZ2lvbiBtYXRjaCkK ICAgImVuLUdCIiAgICAgICAgICAzODQgKGxhbmd1YWdlLCByZWdpb24gbWlzbWF0Y2gpCiAgICJl bi1MYXRuLVVTIiAgICAgICAwIChhbGwgZmllbGRzIG1hdGNoKQogICAiZW4tQnJhaSIgICAgICAg ICAzMiAocmVnaW9uIG1pc21hdGNoKQogICAiZW4tVVMteC1mb28iICAgICAgNCAodmFyaWFudCBt aXNtYXRjaDogcmFuZ2UgaXMgdGhlIGVtcHR5IHN0cmluZykKICAgImVuLVVTLXItd2FkZWdpbGUi IDEgKGV4dGVuc2lvbiBtaXNtYXRjaDogcmFuZ2UgaXMgdGhlIGVtcHR5IHN0cmluZykKCgoKUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAgICAgICAgICAg ICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGlu ZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgSW1wbGVtZW50YXRpb25zIG9yIHBy b3RvY29scyBzb21ldGltZXMgbWlnaHQgd2lzaCB0byB1c2UgbW9yZQogICBzb3BoaXN0aWNhdGVk IHdlaWdodHMgdGhhdCBkZXBlbmQgb24gdGhlIHZhbHVlcyBvZiB0aGUgY29ycmVzcG9uZGluZwog ICBlbGVtZW50cy4gIEZvciBleGFtcGxlLCBkZXBlbmRpbmcgb24gdGhlIGRvbWFpbiwgYW4gaW1w bGVtZW5hdGlvbgogICBtaWdodCBnaXZlIGEgc21hbGwgZGlzdGFuY2UgdG8gdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UKICAgc3VidGFnICdubycgYW5kIHRoZSBjbG9zZWx5IHJl bGF0ZWQgbGFuZ3VhZ2Ugc3VidGFncyAnbmInIG9yICdubic7IG9yCiAgIGJldHdlZW4gdGhlIHNj cmlwdCBzdWJ0YWdzICdLYXRhJyBhbmQgJ0hpcmEnOyBvciBiZXR3ZWVuIHRoZSByZWdpb24KICAg c3VidGFncyAnVVMnIGFuZCAnVU0nLgoKMy4zLiAgTG9va3VwCgogICBMb29rdXAgaXMgdXNlZCB0 byBzZWxlY3QgdGhlIHNpbmdsZSBpbmZvcm1hdGlvbiBpdGVtIHRoYXQgYmVzdAogICBtYXRjaGVz IHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGZvciBhIGdpdmVuIHJlcXVlc3QuICBJbiBsb29r dXAsCiAgIGVhY2ggbGFuZ3VhZ2UgcmFuZ2UgaW4gdGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3Qg cmVwcmVzZW50cyB0aGUKICAgX21vc3RfIHNwZWNpZmljIHRhZyB3aGljaCBpcyBhbiBhY2NlcHRh YmxlIG1hdGNoOyBvbmx5IHRoZSBjbG9zZXN0CiAgIG1hdGNoaW5nIGl0ZW0gYWNjb3JkaW5nIHRo ZSB1c2VyJ3MgcHJpb3JpdHkgaXMgcmV0dXJuZWQuICBGb3IKICAgZXhhbXBsZSwgaWYgdGhlIGxh bmd1YWdlIHJhbmdlIGlzICJkZS1DSCIsIG9uZSBtaWdodCBleHBlY3QgdG8KICAgcmVjZWl2ZSBh biBpbmZvcm1hdGlvbiBpdGVtIHdpdGggdGhlIHRhZyAiZGUiIGJ1dCBuZXZlciBvbmUgd2l0aCB0 aGUKICAgdGFnICJkZS1DSC0xOTk2Ii4gIFVzdWFsbHkgaWYgbm8gY29udGVudCBtYXRjaGVzIHRo ZSByZXF1ZXN0LCBhCiAgICJkZWZhdWx0IiBpdGVtIGlzIHJldHVybmVkLgoKICAgRm9yIGV4YW1w bGUsIGlmIGFuIGFwcGxpY2F0aW9uIGluc2VydHMgc29tZSBkeW5hbWljIGNvbnRlbnQgaW50byBh CiAgIGRvY3VtZW50LCByZXR1cm5pbmcgYW4gZW1wdHkgc3RyaW5nIGlmIHRoZXJlIGlzIG5vIGV4 YWN0IG1hdGNoIGlzIG5vdAogICBhbiBvcHRpb24uICBJbnN0ZWFkLCB0aGUgYXBwbGljYXRpb24g ImZhbGxzIGJhY2siIHVudGlsIGl0IGZpbmRzIGEKICAgc3VpdGFibGUgcGllY2Ugb2YgY29udGVu dCB0byBpbnNlcnQuICBPdGhlciBleGFtcGxlcyBvZiBsb29rdXAgbWlnaHQKICAgaW5jbHVkZToK CiAgIG8gIFNlbGVjdGlvbiBvZiBhIHRlbXBsYXRlIGNvbnRhaW5pbmcgdGhlIHRleHQgZm9yIGFu IGF1dG9tYXRlZCBlbWFpbAogICAgICByZXNwb25zZS4KCiAgIG8gIFNlbGVjdGlvbiBvZiBhIGdy YXBoaWMgY29udGFpbmluZyB0ZXh0IGZvciBpbmNsdXNpb24gaW4gYQogICAgICBwYXJ0aWN1bGFy IFdlYiBwYWdlLgoKICAgbyAgU2VsZWN0aW9uIG9mIGEgc3RyaW5nIG9mIHRleHQgZm9yIGluY2x1 c2lvbiBpbiBhbiBlcnJvciBsb2cuCgogICBJbiB0aGUgTG9va3VwIHNjaGVtZSwgdGhlIGxhbmd1 YWdlIHJhbmdlIGlzIHByb2dyZXNzaXZlbHkgdHJ1bmNhdGVkCiAgIGZyb20gdGhlIGVuZCB1bnRp bCBhIG1hdGNoaW5nIHBpZWNlIG9mIGNvbnRlbnQgaXMgbG9jYXRlZC4gIEZvcgogICBleGFtcGxl LCBzdGFydGluZyB3aXRoIHRoZSByYW5nZSAiemgtSGFudC1DTi14LXByaXZhdGUiLCB0aGUgbG9v a3VwCiAgIHdvdWxkIHByb2dyZXNzaXZlbHkgc2VhcmNoIGZvciBjb250ZW50IGFzIHNob3duIGJl bG93OgoKICAgUmFuZ2UgdG8gbWF0Y2g6IHpoLUhhbnQtQ04teC1wcml2YXRlCiAgIDEuIHpoLUhh bnQtQ04teC1wcml2YXRlCiAgIDIuIHpoLUhhbnQtQ04KICAgMy4gemgtSGFudAogICA0LiB6aAog ICA1LiAoZGVmYXVsdCBjb250ZW50IG9yIHRoZSBlbXB0eSB0YWcpCgogICBGaWd1cmUgNTogRXhh bXBsZSBvZiBhIExvb2t1cCBGYWxsYmFjayBQYXR0ZXJuCgoKCgpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDUKCgogICBUaGlzIHNjaGVtZSBhbGxvd3Mgc29tZSBmbGV4aWJpbGl0eSBp biBmaW5kaW5nIGNvbnRlbnQuICBJdCBhbHNvCiAgIHR5cGljYWxseSBwcm92aWRlcyBiZXR0ZXIg cmVzdWx0cyB3aGVuIGRhdGEgaXMgbm90IGF2YWlsYWJsZSBhdCBhCiAgIHNwZWNpZmljIGxldmVs IG9mIHRhZyBncmFudWxhcml0eSBvciBpcyBzcGFyc2VseSBwb3B1bGF0ZWQgKHRoYW4gaWYKICAg dGhlIGRlZmF1bHQgbGFuZ3VhZ2UgZm9yIHRoZSBzeXN0ZW0gb3IgY29udGVudCB3ZXJlIHVzZWQp LgoKICAgVGhlIGxhbmd1YWdlIHJhbmdlICIqIiBtYXRjaGVzIGFueSBsYW5ndWFnZSB0YWcuICBJ biB0aGUgbG9va3VwCiAgIHNjaGVtZSwgdGhpcyBsYW5ndWFnZSByYW5nZSBkb2VzIG5vdCBjb252 ZXkgZW5vdWdoIGluZm9ybWF0aW9uIHRvCiAgIGRldGVybWluZSB3aGljaCBjb250ZW50IGlzIG1v c3QgYXBwcm9wcmlhdGUuICBJZiB0aGlzIGxhbmd1YWdlIHJhbmdlCiAgIGlzIHRoZSBvbmx5IG9u ZSBpbiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCwgaXQgbWF0Y2hlcyB0aGUgZGVmYXVsdAog ICBjb250ZW50LiAgSWYgdGhpcyBsYW5ndWFnZSByYW5nZSBpcyBmb2xsb3dlZCBieSBvdGhlciBs YW5ndWFnZQogICByYW5nZXMsIGl0IHNob3VsZCBiZSBza2lwcGVkLgoKICAgV2hlbiBwZXJmb3Jt aW5nIGxvb2t1cCB1c2luZyBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QsIHRoZQogICBwcm9ncmVz c2l2ZSBzZWFyY2ggTVVTVCBwcm9jZWVkIHRvIGNvbnNpZGVyIGVhY2ggbGFuZ3VhZ2UgcmFuZ2UK ICAgYmVmb3JlIGZpbmRpbmcgdGhlIGRlZmF1bHQgY29udGVudCBvciBlbXB0eSB0YWcuICBUaGUg ZGVmYXVsdCBjb250ZW50CiAgIG1pZ2h0IGJlIGNvbnRlbnQgd2l0aCBubyBsYW5ndWFnZSB0YWcg KG9yIHdpdGggYW4gZW1wdHkgdmFsdWUsIGFzCiAgIHdpdGggeG1sOmxhbmcgaW4gdGhlIFhNTCBz cGVjaWZpY2F0aW9uKSwgb3IgaXQgbWlnaHQgYmUgYSBwYXJ0aWN1bGFyCiAgIGxhbmd1YWdlIGRl c2lnbmF0ZWQgZm9yIHRoYXQgYml0IG9mIGNvbnRlbnQuCgogICBPbmUgY29tbW9uIHdheSB0byBw cm92aWRlIGZvciBkZWZhdWx0IGNvbnRlbnQgaXMgdG8gYWxsb3cgYSBzcGVjaWZpYwogICBsYW5n dWFnZSByYW5nZSB0byBiZSBzZXQgYXMgdGhlIGRlZmF1bHQgZm9yIGEgc3BlY2lmaWMgdHlwZSBv ZgogICByZXF1ZXN0LiAgVGhpcyBsYW5ndWFnZSByYW5nZSBpcyB0aGVuIHRyZWF0ZWQgYXMgaWYg aXQgd2VyZSBhcHBlbmRlZAogICB0byB0aGUgZW5kIG9mIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBs aXN0LCByYXRoZXIgdGhhbiBhZnRlciBlYWNoIGl0ZW0KICAgaW4gdGhlIGxhbmd1YWdlIHByaW9y aXR5IGxpc3QuCgogICBGb3IgZXhhbXBsZSwgaWYgYSBwYXJ0aWN1bGFyIHVzZXIncyBsYW5ndWFn ZSBwcmlvcml0eSBsaXN0IHdlcmUKICAgImZyLUZSOyB6aC1IYW50IiBhbmQgdGhlIHByb2dyYW0g ZG9pbmcgdGhlIG1hdGNoaW5nIGhhZCBhIGRlZmF1bHQKICAgbGFuZ3VhZ2UgcmFuZ2Ugb2YgImph LUpQIiwgdGhlIHByb2dyYW0gd291bGQgc2VhcmNoIGZvciBjb250ZW50IGFzCiAgIGZvbGxvd3M6 CiAgIDEuIGZyLUZSCiAgIDIuIGZyCiAgIDMuIHpoLUhhbnQgLy8gbmV4dCBsYW5ndWFnZQogICA0 LiB6aAogICA1LiAocmV0dXJuIGRlZmF1bHQgY29udGVudCkKICAgICAgYS4gamEtSlAKICAgICAg Yi4gamEKICAgICAgYy4gKGVtcHR5IHRhZyBvciBvdGhlciBkZWZhdWx0IGNvbnRlbnQpCgogICBG aWd1cmUgNjogTG9va3VwIFVzaW5nIGEgTGFuZ3VhZ2UgUHJpb3JpdHkgTGlzdAoKICAgSW4gc29t ZSBjYXNlcywgdGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgbWlnaHQgY29udGFpbiBvbmUgb3Ig bW9yZQogICBleHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgKGFzLCBmb3IgZXhhbXBsZSwgd2hlbiB0 aGUgc2FtZSBsYW5ndWFnZQogICBwcmlvcml0eSBsaXN0IGlzIHVzZWQgYXMgaW5wdXQgZm9yIGJv dGggbG9va3VwIGFuZCBmaWx0ZXJpbmcKICAgb3BlcmF0aW9ucykuICBXaWxkY2FyZCB2YWx1ZXMg aW4gYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgYXJlCiAgIHN1cHBvc2VkIHRvIG1hdGNoIGFu eSB2YWx1ZSB0aGF0IG9jY3VycyBpbiB0aGF0IHBvc2l0aW9uIGluIGEKICAgbGFuZ3VhZ2UgdGFn LiAgU2luY2Ugb25seSBvbmUgaXRlbSBjYW4gYmUgcmV0dXJuZWQgZm9yIGFueSBnaXZlbgogICBs b29rdXAgcmVxdWVzdCwgdGhlIHdpbGRjYXJkcyBtdXN0IGJlIHByb2Nlc3NlZCBpbiBhIHByZWRp Y3RhYmxlCiAgIG1hbm5lciAob3IgdGhlIHNhbWUgcmVxdWVzdCBtaWdodCBwcm9kdWNlIHdpZGVs eSB2YXJ5aW5nIHJlc3VsdHMpLgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMg TWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUK CgogICBUaHVzLCBmb3IgZWFjaCByYW5nZSBpbiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCwg dGhlIGZvbGxvd2luZwogICBydWxlcyBtdXN0IGJlIGFwcGxpZWQgdG8gcHJvZHVjZSBhIGJhc2lj IGxhbmd1YWdlIHJhbmdlIGZvciB1c2UgaW4KICAgdGhlIGZhbGxiYWNrIG1lY2hhbmlzbToKCiAg IDEuICBJZiB0aGUgZmlyc3Qgc3VidGFnIGluIHRoZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBp cyBhICIqIiB0aGVuCiAgICAgICBlbnRpcmUgcmFuZ2UgaXMgY29udmVydGVkIHRvICIqIi4KCiAg IDIuICBGb3IgZWFjaCBzdWJzZXF1ZW50IHN1YnRhZywgaWYgdGhlIHZhbHVlIGlzIGEgIioiIHRo ZW4gdGhhdAogICAgICAgc3VidGFnIGFuZCBpdHMgcHJlY2VlZGluZyBoeXBoZW4gYXJlIHJlbW92 ZWQuCgogICBGb3IgZXhhbXBsZToKCiAgICotVVMgICAgICBiZWNvbWVzICAqCiAgIGVuLSotVVMg ICBiZWNvbWVzICBlbi1VUwogICBlbi1MYXRuLSogYmVjb21lcyAgZW4tTGF0bgoKICAgRmlndXJl IDc6IFRyYW5zZm9ybWF0aW9uIG9mIEV4dGVuZGVkIExhbmd1YWdlIFJhbmdlcwoKICAgRm9yIHRo ZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0ICIqLVVTOyBmci0qLUZSOyB6aC1IYW50IiwgdGhlIGZh bGxiYWNrCiAgIHBhdHRlcm4gd291bGQgYmU6CiAgIDEuICogKHNraXBwZWQpCiAgIDIuIGZyLUZS CiAgIDMuIGZyCiAgIDQuIHpoLUhhbnQKICAgNS4gemgKICAgNi4gKGRlZmF1bHQgY29udGVudCkK CiAgIEZpZ3VyZSA4OiBFeHRlbmRlZCBMYW5ndWFnZSBSYW5nZSBGYWxsYmFjayBFeGFtcGxlCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1h eSAyMCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoK NC4gIE90aGVyIENvbnNpZGVyYXRpb25zCgogICBXaGVuIHdvcmtpbmcgd2l0aCBsYW5ndWFnZSBy YW5nZXMgYW5kIG1hdGNoaW5nIHNjaGVtZXMsIHRoZXJlIGFyZQogICBzb21lIGFkZGl0aW9uYWwg cG9pbnRzIHRoYXQgbWF5IGluZmx1ZW5jZSB0aGUgY2hvaWNlIG9mIGVpdGhlci4KCjQuMS4gIE1l YW5pbmcgb2YgTGFuZ3VhZ2UgVGFncyBhbmQgUmFuZ2VzCgogICBTZWxlY3RpbmcgY29udGVudCB1 c2luZyBsYW5ndWFnZSByYW5nZXMgcmVxdWlyZXMgc29tZSB1bmRlcnN0YW5kaW5nCiAgIGJ5IHVz ZXJzIG9mIHdoYXQgdGhleSBhcmUgc2VsZWN0aW5nLiAgQSBsYW5ndWFnZSB0YWcgb3IgcmFuZ2UK ICAgaWRlbnRpZmllcyBhIGxhbmd1YWdlIGFzIHNwb2tlbiAob3Igd3JpdHRlbiwgc2lnbmVkIG9y IG90aGVyd2lzZQogICBzaWduYWxlZCkgYnkgaHVtYW4gYmVpbmdzIGZvciBjb21tdW5pY2F0aW9u IG9mIGluZm9ybWF0aW9uIHRvIG90aGVyCiAgIGh1bWFuIGJlaW5ncy4KCiAgIElmIGEgbGFuZ3Vh Z2UgdGFnIEIgY29udGFpbnMgbGFuZ3VhZ2UgdGFnIEEgYXMgYSBwcmVmaXgsIHRoZW4gQiBpcwog ICB0eXBpY2FsbHkgIm5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZpYyIgdGhhbiBBLiBGb3IgZXhh bXBsZSwgInpoLQogICBIYW50LVRXIiBpcyBtb3JlIHNwZWNpZmljIHRoYW4gInpoLUhhbnQiLgoK ICAgVGhpcyByZWxhdGlvbnNoaXAgaXMgbm90IGd1YXJhbnRlZWQgaW4gYWxsIGNhc2VzOiBzcGVj aWZpY2FsbHksCiAgIGxhbmd1YWdlcyB0aGF0IGJlZ2luIHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ug b2Ygc3VidGFncyBhcmUgTk9UCiAgIGd1YXJhbnRlZWQgdG8gYmUgbXV0dWFsbHkgaW50ZWxsaWdp YmxlLCBhbHRob3VnaCB0aGV5IG1pZ2h0IGJlLgoKICAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImF6 IiBzaGFyZXMgYSBwcmVmaXggd2l0aCBib3RoICJhei1MYXRuIgogICAoQXplcmJhaWphbmkgd3Jp dHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KSBhbmQgImF6LUFyYWIiCiAgIChBemVyYmFpamFu aSB3cml0dGVuIHVzaW5nIHRoZSBBcmFiaWMgc2NyaXB0KS4gIEEgcGVyc29uIGZsdWVudCBpbgog ICBvbmUgc2NyaXB0IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHJlYWQgdGhlIG90aGVyLCBldmVuIHRo b3VnaCB0aGUgdGV4dAogICBtaWdodCBiZSBvdGhlcndpc2UgaWRlbnRpY2FsLiAgQ29udGVudCB0 YWdnZWQgYXMgImF6IiBtb3N0IHByb2JhYmx5CiAgIGlzIHdyaXR0ZW4gaW4ganVzdCBvbmUgc2Ny aXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBiZSBpbnRlbGxpZ2libGUgdG8gYQogICByZWFkZXIgZmFt aWxpYXIgd2l0aCB0aGUgb3RoZXIgc2NyaXB0LgoKICAgVmFyaWFudCBzdWJ0YWdzIGluIHBhcnRp Y3VsYXIgc2VlbSB0byByZXByZXNlbnQgc3BlY2lmaWMgZGl2aXNpb25zIGluCiAgIG11dHVhbCB1 bmRlcnN0YW5kaW5nLCBzaW5jZSB0aGV5IG9mdGVuIGVuY29kZSBkaWFsZWN0cyBvciBvdGhlcgog ICBpZGlvc3luY3JhdGljIHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2UuCgogICBUaGUgcmVs YXRpb25zaGlwIGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZyBhbmQgdGhlIGluZm9ybWF0aW9uIGl0 CiAgIHJlbGF0ZXMgdG8gaXMgZGVmaW5lZCBieSB0aGUgc3RhbmRhcmQgZGVzY3JpYmluZyB0aGUg Y29udGV4dCBpbiB3aGljaAogICBpdCBhcHBlYXJzLiAgQWNjb3JkaW5nbHksIHRoaXMgc2VjdGlv biBjYW4gb25seSBnaXZlIHBvc3NpYmxlCiAgIGV4YW1wbGVzIG9mIGl0cyB1c2FnZToKCiAgIG8g IEZvciBhIHNpbmdsZSBpbmZvcm1hdGlvbiBvYmplY3QsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdl IHRhZ3MKICAgICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMg dGhhdCBhcmUgbmVjZXNzYXJ5CiAgICAgIGZvciBhIGNvbXBsZXRlIGNvbXByZWhlbnNpb24gb2Yg dGhlIGNvbXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6CiAgICAgIFBsYWluIHRleHQgZG9jdW1lbnRz LgoKICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9mIGluZm9ybWF0aW9uIG9iamVjdHMsIHRoZSBh c3NvY2lhdGVkIGxhbmd1YWdlCiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNldCBv ZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cwogICAgICBvZiB0aGF0IGFnZ3JlZ2F0 aW9uLiAgRXhhbXBsZXM6IERvY3VtZW50IHN0b3JlcyBhbmQgbGlicmFyaWVzLgoKCgoKClBoaWxs aXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjAsIDIwMDYgICAgICAgICAgICAgICAg IFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcg ICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmpl Y3RzIHdob3NlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZXMsCiAgICAgIHRoZSBh c3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MgY291bGQgYmUgcmVnYXJkZWQgYXMgYSBoaW50IHRoYXQg dGhlCiAgICAgIGNvbnRlbnQgaXMgcHJvdmlkZWQgaW4gc2V2ZXJhbCBsYW5ndWFnZXMsIGFuZCB0 aGF0IG9uZSBoYXMgdG8KICAgICAgaW5zcGVjdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZXMgaW4g b3JkZXIgdG8gZmluZCBpdHMgbGFuZ3VhZ2Ugb3IKICAgICAgbGFuZ3VhZ2VzLiAgSW4gdGhpcyBj YXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncyBtaWdodCBub3QKICAgICAgbWVhbiB0 aGF0IG9uZSBuZWVkcyB0byBiZSBtdWx0aS1saW5ndWFsIHRvIGdldCBjb21wbGV0ZQogICAgICB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4gIEV4YW1wbGU6IE1JTUUgbXVsdGlwYXJ0Lwog ICAgICBhbHRlcm5hdGl2ZS4KCiAgIG8gIEluIG1hcmt1cCBsYW5ndWFnZXMsIHN1Y2ggYXMgSFRN TCBhbmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlvbgogICAgICBjYW4gYmUgYWRkZWQgdG8gZWFj aCBwYXJ0IG9mIHRoZSBkb2N1bWVudCBpZGVudGlmaWVkIGJ5IHRoZSBtYXJrdXAKICAgICAgc3Ry dWN0dXJlIChpbmNsdWRpbmcgdGhlIHdob2xlIGRvY3VtZW50IGl0c2VsZikuICBGb3IgZXhhbXBs ZSwgb25lCiAgICAgIGNvdWxkIHdyaXRlIDxzcGFuIGxhbmc9IkZSIj5DJ2VzdCBsYSB2aWUuPC9z cGFuPiBpbnNpZGUgYQogICAgICBOb3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3Bl YWtpbmcgdXNlciBjb3VsZCB0aGVuIGFjY2VzcwogICAgICBhIEZyZW5jaC1Ob3J3ZWdpYW4gZGlj dGlvbmFyeSB0byBmaW5kIG91dCB3aGF0IHRoZSBtYXJrZWQgc2VjdGlvbgogICAgICBtZWFudC4g IElmIHRoZSB1c2VyIHdlcmUgbGlzdGVuaW5nIHRvIHRoYXQgZG9jdW1lbnQgdGhyb3VnaCBhCiAg ICAgIHNwZWVjaCBzeW50aGVzaXMgaW50ZXJmYWNlLCB0aGlzIGZvcm1hdGlvbiBjb3VsZCBiZSB1 c2VkIHRvIHNpZ25hbAogICAgICB0aGUgc3ludGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBs eSBGcmVuY2ggdGV4dC10by1zcGVlY2gKICAgICAgcHJvbnVuY2lhdGlvbiBydWxlcyB0byB0aGF0 IHNwYW4gb2YgdGV4dCwgaW5zdGVhZCBvZiBtaXNhcHBseWluZwogICAgICB0aGUgTm9yd2VnaWFu IHJ1bGVzLgoKNC4yLiAgQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MKCiAg IFByaXZhdGUtdXNlIHN1YnRhZ3MgcmVxdWlyZSBwcml2YXRlIGFncmVlbWVudCBiZXR3ZWVuIHRo ZSBwYXJ0aWVzCiAgIHRoYXQgaW50ZW5kIHRvIHVzZSBvciBleGNoYW5nZSBsYW5ndWFnZSB0YWdz IHRoYXQgdXNlIHRoZW0gYW5kIGdyZWF0CiAgIGNhdXRpb24gU0hPVUxEIGJlIHVzZWQgaW4gZW1w bG95aW5nIHRoZW0gaW4gY29udGVudCBvciBwcm90b2NvbHMKICAgaW50ZW5kZWQgZm9yIGdlbmVy YWwgdXNlLiAgUHJpdmF0ZS11c2Ugc3VidGFncyBhcmUgc2ltcGx5IHVzZWxlc3MgZm9yCiAgIGlu Zm9ybWF0aW9uIGV4Y2hhbmdlIHdpdGhvdXQgcHJpb3IgYXJyYW5nZW1lbnQuCgogICBUaGUgdmFs dWUgYW5kIHNlbWFudGljIG1lYW5pbmcgb2YgcHJpdmF0ZS11c2UgdGFncyBhbmQgb2YgdGhlIHN1 YnRhZ3MKICAgdXNlZCB3aXRoaW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90IGRlZmluZWQu ICBNYXRjaGluZyBwcml2YXRlCiAgIHVzZSB0YWdzIHVzaW5nIGxhbmd1YWdlIHJhbmdlcyBvciBl eHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgY2FuIHJlc3VsdAogICBpbiB1bnByZWRpY3RhYmxlIGNv bnRlbnQgYmVpbmcgcmV0dXJuZWQuCgo0LjMuICBMZW5ndGggQ29uc2lkZXJhdGlvbnMgaW4gTWF0 Y2hpbmcKCiAgIFJGQyAzMDY2IFtSRkMzMDY2XSBkaWQgbm90IHByb3ZpZGUgYW4gdXBwZXIgbGlt aXQgb24gdGhlIHNpemUgb2YKICAgbGFuZ3VhZ2UgdGFncyBvciByYW5nZXMuICBSRkMgMzA2NiBk aWQgZGVmaW5lIHRoZSBzZW1hbnRpY3Mgb2YKICAgcGFydGljdWxhciBzdWJ0YWdzIGluIHN1Y2gg YSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRhZ3Mgb3IgcmFuZ2VzCiAgIGNvbnNpc3RlZCBvZiBs YW5ndWFnZSBhbmQgcmVnaW9uIHN1YnRhZ3Mgd2l0aCBhIGNvbWJpbmVkIHRvdGFsIGxlbmd0aAog ICBvZiB1cCB0byBzaXggY2hhcmFjdGVycy4gIExhcmdlciB0YWdzIGFuZCByYW5nZXMgKGluIHRl cm1zIG9mIGJvdGgKICAgc3VidGFncyBhbmQgY2hhcmFjdGVycykgZGlkIGV4aXN0LCBob3dldmVy LgoKICAgW1JGQzMwNjZiaXNdIGFsc28gZG9lcyBub3QgaW1wb3NlIGEgZml4ZWQgdXBwZXIgbGlt aXQgb24gdGhlIG51bWJlcgogICBvZiBzdWJ0YWdzIGluIGEgbGFuZ3VhZ2UgdGFnIG9yIHJhbmdl IChhbmQgdGh1cyBhbiB1cHBlciBib3VuZCBvbiB0aGUKICAgc2l6ZSBvZiBlaXRoZXIpLiAgVGhl IHN5bnRheCBpbiB0aGF0IGRvY3VtZW50IHN1Z2dlc3RzIHRoYXQsCiAgIGRlcGVuZGluZyBvbiB0 aGUgc3BlY2lmaWMgbGFuZ3VhZ2Ugb3IgcmFuZ2Ugb2YgbGFuZ3VhZ2VzLCBtb3JlCiAgIHN1YnRh Z3MgKGFuZCB0aHVzIGNoYXJhY3RlcnMpIGFyZSBzb21ldGltZXMgbmVjZXNzYXJ5IGFzIGEgcmVz dWx0LgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAg ICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBs dHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgogICBMZW5ndGggY29u c2lkZXJhdGlvbnMgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgc2VsZWN0aW9uIGFuZAogICBwcm9j ZXNzaW5nIG9mIHRhZ3MgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMS4xIG9mIHRoYXQgZG9j dW1lbnQuCgogICBBbiBhcHBsaWNhdGlvbiBvciBwcm90b2NvbCBNQVkgY2hvb3NlIHRvIGxpbWl0 IHRoZSBsZW5ndGggb2YgdGhlCiAgIGxhbmd1YWdlIHRhZ3Mgb3IgcmFuZ2VzIHVzZWQgaW4gbWF0 Y2hpbmcuICBBbnkgc3VjaCBsaW1pdGF0aW9uIFNIT1VMRAogICBiZSBjbGVhcmx5IGRvY3VtZW50 ZWQsIGFuZCBzdWNoIGRvY3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUgdGhlCiAgIGRpc3Bvc2l0 aW9uIG9mIGFueSBsb25nZXIgdGFncyBvciByYW5nZXMgKGZvciBleGFtcGxlLCB3aGV0aGVyIGFu CiAgIGVycm9yIHZhbHVlIGlzIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIG9yIHJhbmdl IGlzIHRydW5jYXRlZCkuCiAgIElmIHRydW5jYXRpb24gaXMgcGVybWl0dGVkIGl0IE1VU1QgTk9U IHBlcm1pdCBhIHN1YnRhZyB0byBiZSBkaXZpZGVkLAogICBzaW5jZSB0aGlzIGNoYW5nZXMgdGhl IHNlbWFudGljcyBvZiB0aGUgc3VidGFnIGJlaW5nIG1hdGNoZWQgYW5kIGNhbgogICByZXN1bHQg aW4gZmFsc2UgcG9zaXRpdmVzIG9yIG5lZ2F0aXZlcy4KCiAgIEFwcGxpY2F0aW9ucyBvciBwcm90 b2NvbHMgdGhhdCByZXN0cmljdCBzdG9yYWdlIFNIT1VMRCBjb25zaWRlciB0aGUKICAgaW1wYWN0 IG9mIHRhZyBvciByYW5nZSB0cnVuY2F0aW9uIG9uIHRoZSByZXN1bHRpbmcgbWF0Y2hlcy4gIEZv cgogICBleGFtcGxlLCByZW1vdmluZyB0aGUgIioiIGZyb20gdGhlIGVuZCBvZiBhbiBleHRlbmRl ZCBsYW5ndWFnZSByYW5nZQogICAoc2VlIFNlY3Rpb24gMi4zKSBjYW4gZ3JlYXRseSBtb2RpZnkg dGhlIHNldCBvZiByZXR1cm5lZCBtYXRjaGVzLiAgQQogICBwcm90b2NvbCB0aGF0IGFsbG93cyB0 YWdzIG9yIHJhbmdlcyB0byBiZSB0cnVuY2F0ZWQgYXQgYW4gYXJiaXRyYXJ5CiAgIGxpbWl0LCB3 aXRob3V0IGdpdmluZyBhbnkgaW5kaWNhdGlvbiBvZiB3aGF0IHRoYXQgbGltaXQgaXMsIGhhcyB0 aGUKICAgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm0gYnkgY2hhbmdpbmcgdGhlIG1lYW5pbmcg b2YgdmFsdWVzIGluCiAgIHN1YnN0YW50aWFsIHdheXMuCgogICBJbiBwcmFjdGljZSwgbW9zdCB0 YWdzIGRvIG5vdCByZXF1aXJlIGFkZGl0aW9uYWwgc3VidGFncyBvcgogICBzdWJzdGFudGlhbGx5 IG1vcmUgY2hhcmFjdGVycy4gIEFkZGl0aW9uYWwgc3VidGFncyBzb21ldGltZXMgYWRkCiAgIHVz ZWZ1bCBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiwgYnV0IGV4dHJhbmVvdXMgc3VidGFncyBp bnRlcmZlcmUKICAgd2l0aCB0aGUgbWVhbmluZywgdW5kZXJzdGFuZGluZywgYW5kIGVzcGVjaWFs bHkgbWF0Y2hpbmcgb2YgbGFuZ3VhZ2UKICAgdGFncy4gIFNpbmNlIGxhbmd1YWdlIHRhZ3Mgb3Ig cmFuZ2VzIE1BWSBiZSB0cnVuY2F0ZWQgYnkgYW4KICAgYXBwbGljYXRpb24gb3IgcHJvdG9jb2wg dGhhdCBsaW1pdHMgc3RvcmFnZSwgd2hlbiBjaG9vc2luZyBsYW5ndWFnZQogICB0YWdzIG9yIHJh bmdlcyB1c2VycyBhbmQgYXBwbGljYXRpb25zIFNIT1VMRCBhdm9pZCBhZGRpbmcgc3VidGFncwog ICB0aGF0IGFkZCBubyBkaXN0aW5ndWlzaGluZyB2YWx1ZS4gIEluIHBhcnRpY3VsYXIsIHVzZXJz IGFuZAogICBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0aGUgJ1ByZWZpeCcgYW5kICdT dXBwcmVzcy1TY3JpcHQnCiAgIGZpZWxkcyBpbiB0aGUgcmVnaXN0cnkgKGRlZmluZWQgaW4gU2Vj dGlvbiAzLjYgb2YgW1JGQzMwNjZiaXNdKToKICAgdGhlc2UgZmllbGRzIHByb3ZpZGUgZ3VpZGFu Y2Ugb24gd2hlbiBzcGVjaWZpYyBhZGRpdGlvbmFsIHN1YnRhZ3MKICAgU0hPVUxEIChhbmQgU0hP VUxEIE5PVCkgYmUgdXNlZC4KCiAgIEltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgYSBsaW1p dCBvZiBhdCBsZWFzdCAzMyBjaGFyYWN0ZXJzLiAgVGhpcwogICBsaW1pdCBpbmNsdWRlcyBhdCBs ZWFzdCBvbmUgc3VidGFnIG9mIGVhY2ggbm9uLWV4dGVuc2lvbiwgbm9uLXByaXZhdGUKICAgdXNl IHR5cGUuICBXaGVuIGNob29zaW5nIGEgYnVmZmVyIGxpbWl0LCBhIGxlbmd0aCBvZiBhdCBsZWFz dCA0MgogICBjaGFyYWN0ZXJzIGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVELgoKICAgVGhlIHByYWN0 aWNhbCBsaW1pdCBvbiB0YWdzIG9yIHJhbmdlcyBkZXJpdmVkIHNvbGVseSBmcm9tIHJlZ2lzdGVy ZWQKICAgdmFsdWVzIGlzIDQyIGNoYXJhY3RlcnMuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSBh YmxlIHRvIGhhbmRsZSB0YWdzCiAgIGFuZCByYW5nZXMgb2YgdGhpcyBsZW5ndGguICBTdXBwb3J0 IGZvciB0YWdzIGFuZCByYW5nZXMgb2YgYXQgbGVhc3QKICAgNjIgY2hhcmFjdGVycyBpbiBsZW5n dGggaXMgUkVDT01NRU5ERUQuICBJbXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQKICAgbG9uZ2Vy IHZhbHVlcywgaW5jbHVkaW5nIG1hdGNoaW5nIGV4dGVuc2l2ZSBzZXRzIG9mIHByaXZhdGUgdXNl IG9yCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLgoKICAgQXBwbGljYXRpb25zIG9yIHByb3RvY29scyB3 aGljaCBoYXZlIHRvIHRydW5jYXRlIGEgdGFnIE1VU1QgZG8gc28gYnkKICAgcHJvZ3Jlc3NpdmVs eSByZW1vdmluZyBzdWJ0YWdzIGFsb25nIHdpdGggdGhlaXIgcHJlY2VkaW5nICItIiBmcm9tCgoK ClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjAsIDIwMDYgICAgICAgICAg ICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0 Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCiAgIHRoZSByaWdodCBzaWRlIG9m IHRoZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBpcyBzaG9ydCBlbm91Z2ggZm9yCiAgIHRo ZSBnaXZlbiBidWZmZXIuICBJZiB0aGUgcmVzdWx0aW5nIHRhZyBlbmRzIHdpdGggYSBzaW5nbGUt Y2hhcmFjdGVyCiAgIHN1YnRhZywgdGhhdCBzdWJ0YWcgYW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1V U1QgYWxzbyBiZSByZW1vdmVkLiAgRm9yCiAgIGV4YW1wbGU6CgogICBUYWcgdG8gdHJ1bmNhdGU6 IHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxLXgtd2FkZWdpbGUtcHJpdmF0ZTEKICAgMS4g emgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDEteC13YWRlZ2lsZQogICAyLiB6aC1MYXRuLUNO LXZhcmlhbnQxLWEtZXh0ZW5kMQogICAzLiB6aC1MYXRuLUNOLXZhcmlhbnQxCiAgIDQuIHpoLUxh dG4tQ04KICAgNS4gemgtTGF0bgogICA2LiB6aAoKICAgRmlndXJlIDk6IEV4YW1wbGUgb2YgVGFn IFRydW5jYXRpb24KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjAsIDIwMDYgICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBU aGlzIGRvY3VtZW50IHByZXNlbnRzIG5vIG5ldyBvciBleGlzdGluZyBjb25zaWRlcmF0aW9ucyBm b3IgSUFOQS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAgICAgICAg ICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRj aGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKNi4gIENoYW5nZXMKCiAgIFRoaXMg aXMgdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudC4KCiAgIFRoZSBmb2xsb3dpbmcg Y2hhbmdlcyB3ZXJlIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQgc2luY2UgZHJhZnQtMDU6CgogICAg ICBNb2RpZmllZCB0aGUgQUJORiB0byBtYXRjaCBjaGFuZ2VzIGluIFtSRkMzMDY2YmlzXSAoSy5L YXJsc3NvbikKCiAgICAgIE1hdGNoZWQgdGhlIHJlZmVyZW5jZXMgYW5kIHJlZmVyZW5jZSBmb3Jt YXRzIHRvIFtSRkMzMDY2YmlzXQogICAgICAoSy5LYXJsc3NvbikKCiAgICAgIFZhcmlvdXMgZWRp dHMsIGFkZGl0aW9ucywgYW5kIGVtZW5kYXRpb25zIHRvIGRlYWwgd2l0aCBjaGFuZ2VzIGluCiAg ICAgIHRoZSBMYXN0IENhbGwgb2YgZHJhZnQtcmVnaXN0cnkgYXMgd2VsbCBhcyBjbGVhbmluZyB1 cCB0aGUgdGV4dC4KCiAgICAgIENoYW5nZWQgZnJvbSAnZGVmaW5lZCcgdG8gJ2lkZW50aWZpZXMn IGluIFNlY3Rpb24gNC4xLiAgKE0uR3VubikKCiAgICAgIFJlb3JnYW5pemVkIHRoZSB0ZXh0IGFu ZCBicm9rZSBpdCBpbnRvIHNlY3Rpb25zIChNLkR1ZXJzdCkKCiAgICAgIE1vZGlmaWVkIG9jY3Vy ZW5jZXMgb2YgdGhlIHdvcmQgImFwcGxpY2F0aW9uIiB0byByZWZlciB0bwogICAgICAiYXBwbGlj YXRpb25zIG9yIHByb3RvY29scyIgb3Igb3RoZXJ3aXNlIGJlIHNwZWNpZmljIChFLiB2YW4gZGVy CiAgICAgIFBvZWwpCgogICAgICBSZW1vdmVkICJFeHRlbmRlZCBMYW5ndWFnZSBSYW5nZSBMb29r dXAiLCBtZXJnaW5nIGl0IHdpdGggb3RoZXIKICAgICAgdGV4dCBvbiBsb29rdXAgdG8gZm9ybSBh IHNpbmdsZSBzY2hlbWUuICAoTS5EYXZpcykKCiAgICAgIEZpeGVkIG9yIHJlbW92ZWQgb2Jzb2xl dGUgb3IgZGFuZ2xpbmcgcmVmZXJlbmNlcyAoRWQuKQoKICAgICAgQWRkZWQgYW4gaW50cm9kdWN0 aW9uIHRvIHNlY3Rpb24gNCBhbmQgYWRkZWQgb25lIHNlbnRlbmNlIHRvIG1ha2UKICAgICAgaXQg ZmxvdyBiZXR0ZXIgdG8gdGhlIHN0YXJ0IG9mIHNlY3Rpb24gNC4xLiAgKEVkLikKCgoKCgoKCgoK CgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjAsIDIw MDYgICAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCjcuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucwoKICAgTGFuZ3VhZ2UgcmFuZ2VzIHVzZWQgaW4gY29udGVudCBu ZWdvdGlhdGlvbiBtaWdodCBiZSB1c2VkIHRvIGluZmVyCiAgIHRoZSBuYXRpb25hbGl0eSBvZiB0 aGUgc2VuZGVyLCBhbmQgdGh1cyBpZGVudGlmeSBwb3RlbnRpYWwgdGFyZ2V0cwogICBmb3Igc3Vy dmVpbGxhbmNlLiAgSW4gYWRkaXRpb24sIHVuaXF1ZSBvciBoaWdobHkgdW51c3VhbCBsYW5ndWFn ZQogICByYW5nZXMgb3IgY29tYmluYXRpb25zIG9mIGxhbmd1YWdlIHJhbmdlcyBtaWdodCBiZSB1 c2VkIHRvIHRyYWNrCiAgIHNwZWNpZmljIGluZGl2aWR1YWwncyBhY3Rpdml0aWVzLgoKICAgVGhp cyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcg eW91IHNlbmQKICAgaXMgdmlzaWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5LiAgSXQgaXMgdXNl ZnVsIHRvIGJlIGF3YXJlIHRoYXQKICAgc3VjaCBjb25jZXJucyBjYW4gZXhpc3QgaW4gc29tZSBj YXNlcy4KCiAgIFRoZSBldmFsdWF0aW9uIG9mIHRoZSBleGFjdCBtYWduaXR1ZGUgb2YgdGhlIHRo cmVhdCwgYW5kIGFueSBwb3NzaWJsZQogICBjb3VudGVybWVhc3VyZXMsIGlzIGxlZnQgdG8gZWFj aCBhcHBsaWNhdGlvbiBvciBwcm90b2NvbC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjAsIDIwMDYgICAg ICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0 cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCjguICBDaGFyYWN0ZXIg U2V0IENvbnNpZGVyYXRpb25zCgogICBUaGUgc3ludGF4IG9mIGxhbmd1YWdlIHRhZ3MgYW5kIGxh bmd1YWdlIHJhbmdlcyBwZXJtaXQgb25seSB0aGUKICAgY2hhcmFjdGVycyBBLVosIGEteiwgMC05 LCBhbmQgSFlQSEVOLU1JTlVTICgleDJEKS4gIFRoZXNlIGNoYXJhY3RlcnMKICAgYXJlIHByZXNl bnQgaW4gbW9zdCBjaGFyYWN0ZXIgc2V0cywgc28gcHJlc2VudGF0aW9uIG9mIGxhbmd1YWdlIHRh Z3MKICAgc2hvdWxkIG5vdCBwcmVzZW50IGFueSBjaGFyYWN0ZXIgc2V0IGlzc3Vlcy4KCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA1CgoKOS4gIFJlZmVyZW5jZXMKCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwg UkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlz LCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwKICAgICAgICAgICAgICBNYXNpbnRlciwgTC4s IExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0CiAgICAgICAgICAgICAg VHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEiLCBSRkMgMjYxNiwgSnVuZSAxOTk5LgoKICAg W1JGQzMwNjZiaXNdCiAgICAgICAgICAgICAgUGhpbGxpcHMsIEEuLCBFZC4gYW5kIE0uIERhdmlz LCBFZC4sICJUYWdzIGZvciB0aGUKICAgICAgICAgICAgICBJZGVudGlmaWNhdGlvbiBvZiBMYW5n dWFnZXMiLCBPY3RvYmVyIDIwMDUsIDxodHRwOi8vCiAgICAgICAgICAgICAgd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkt MTQudHh0Pi4KCiAgIFtSRkM0MjM0XSAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdt ZW50ZWQgQk5GIGZvciBTeW50YXgKICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIs IFJGQyA0MjM0LCBPY3RvYmVyIDIwMDUuCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgog ICBbUkZDMTc2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9u IG9mCiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgUkZDIDE3NjYsIE1hcmNoIDE5OTUuCgogICBb UkZDMzA2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9m CiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgQkNQIDQ3LCBSRkMgMzA2NiwgSmFudWFyeSAyMDAx LgoKICAgW1JGQzMyODJdICBBbHZlc3RyYW5kLCBILiwgIkNvbnRlbnQgTGFuZ3VhZ2UgSGVhZGVy cyIsIFJGQyAzMjgyLAogICAgICAgICAgICAgIE1heSAyMDAyLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAg ICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1h dGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgpBcHBlbmRpeCBBLiAgQWNrbm93 bGVkZ2VtZW50cwoKICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlzIGJvdW5kIHRvIGJlIGlu Y29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2VsZWN0 aW9uIGZyb20gdGhlIGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQogICBjb250cmlidXRlZCB0byBt YWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2RheS4KCiAgIFRoZSBjb250cmlidXRvcnMg dG8gW1JGQzMwNjZiaXNdLCBbUkZDMzA2Nl0gYW5kIFtSRkMxNzY2XSwgZWFjaCBvZgogICB3aGlj aCBpcyBhIHByZWN1cnNvciB0byB0aGlzIGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRyaWJ1 dGlvbnMKICAgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlzIGRvY3VtZW50IGFuZCBhcmUg Z2VuZXJhbGx5IHJlc3BvbnNpYmxlCiAgIGZvciB0aGUgc3VjY2VzcyBvZiBsYW5ndWFnZSB0YWdz LgoKICAgVGhlIGZvbGxvd2luZyBwZW9wbGUgKGluIGFscGhhYmV0aWNhbCBvcmRlciBieSBmYW1p bHkgbmFtZSkKICAgY29udHJpYnV0ZWQgdG8gdGhpcyBkb2N1bWVudDoKCiAgIEplcmVteSBDYXJy b2xsLCBKb2huIENvd2FuLCBNYXJ0aW4gRHVlcnN0LCBGcmFuayBFbGxlcm1hbm4sIERvdWcKICAg RXdlbGwsIE1hcmlvbiBHdW5uLCBLZW50IEthcmxzc29uLCBJcmEgTWNEb25hbGQsIE0uIFBhdHRv biwgUmFuZHkKICAgUHJlc3VobiwgRXJpYyB2YW4gZGVyIFBvZWwsIGFuZCBtYW55LCBtYW55IG90 aGVycy4KCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQgQWx2 ZXN0cmFuZCwgd2hvCiAgIG9yaWdpbmF0ZWQgUkZDcyAxNzY2IGFuZCAzMDY2LCBhbmQgd2l0aG91 dCB3aG9tIHRoaXMgZG9jdW1lbnQgd291bGQKICAgbm90IGhhdmUgYmVlbiBwb3NzaWJsZS4KCiAg IEZvciB0aGlzIHBhcnRpY3VsYXIgZG9jdW1lbnQsIEpvaG4gQ293YW4gb3JpZ2luYXRlZCB0aGUg c2NoZW1lCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMi4zLiAgTWFyayBEYXZpcyBvcmlnaW5h dGVkIHRoZSBzY2hlbWUKICAgZGVzY3JpYmVkIGluIHRoZSBTZWN0aW9uIDMuMy4KCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIw LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgpBdXRo b3JzJyBBZGRyZXNzZXMKCiAgIEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikKICAgUXVlc3QgU29m dHdhcmUKCiAgIEVtYWlsOiBhZGRpc29uIGRvdCBwaGlsbGlwcyBhdCBxdWVzdCBkb3QgY29tCgoK ICAgTWFyayBEYXZpcyAoZWRpdG9yKQogICBJQk0KCiAgIEVtYWlsOiBtYXJrIGRvdCBkYXZpcyBh dCBpYm0gZG90IGNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQaGls bGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAgICAgICAgICAg ICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5n ICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3Rh dGVtZW50CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlk aXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90 aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1w bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVw cmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVu dGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3 aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGlu IEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRv IHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0 byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUg dG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YK ICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRo aXMKICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5l IElQUiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElF VEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9u IGFueQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90 aGVyIHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQg bWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFk ZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3Jn LgoKCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkKCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJh c2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VO VFMKICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBB TkQgVEhFIElOVEVSTkVUCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdB UlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwKICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQogICBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJSQU5U SUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4KCgpDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT b2NpZXR5ICgyMDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdAogICB0byB0aGUgcmlnaHRz LCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZAogICBl eGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIg cmlnaHRzLgoKCkFja25vd2xlZGdtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBm dW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCiAgIEludGVybmV0IFNvY2lldHku CgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDA2ICAgICAg ICAgICAgICAgICBbUGFnZSAyN10KDAo= ------_=_NextPart_001_01C5EB13.484957F6 Content-Type: text/plain; charset="us-ascii" 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_001_01C5EB13.484957F6-- From ltru-bounces@ietf.org Wed Nov 16 20:17:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYO2-0005It-U5; Wed, 16 Nov 2005 20:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYO1-0005Ii-Be for ltru@megatron.ietf.org; Wed, 16 Nov 2005 20:16:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12813 for ; Wed, 16 Nov 2005 20:15:46 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcYfV-0001ze-2U for ltru@ietf.org; Wed, 16 Nov 2005 20:34:29 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 17:16:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: Ranges vs. range lists Date: Wed, 16 Nov 2005 17:16:11 -0800 Message-ID: Thread-Topic: [Ltru] Matching: Ranges vs. range lists Thread-Index: AcXrEBTFTISC7ddXRo+Xe6sKv//LaAABC/iA From: "Addison Phillips" To: "Harald Tveit Alvestrand" , "Mark Davis" X-OriginalArrivalTime: 17 Nov 2005 01:16:12.0048 (UTC) FILETIME=[7F79A900:01C5EB14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123993136==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1123993136== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aGluayBJIGFncmVlIHdpdGggSGFyYWxkLCBhbHRob3VnaCBJIGFsc28gYWdyZWUgdGhhdCB3 ZSBzaG91bGQgbWVudGlvbiAoYXMgdGhlIHRleHQgaW4gZHJhZnQtMDYgY3VycmVudGx5IGRvZXMp IHdoYXQgb25lIG1pZ2h0IGRvIHdpdGggdGhlIGRlZmF1bHQgY29udGVudC4gUGxlYXNlIHByb3Bv c2UgY2hhbmdlcyB0byB0aGF0IHRleHQhDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9u YWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhhcmFsZCBUdmVpdCBBbHZlc3Ry YW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+IFNlbnQ6IDIwMDXlubQxMeaciDE2 5pelIDE2OjM0DQo+IFRvOiBNYXJrIERhdmlzOyBBZGRpc29uIFBoaWxsaXBzDQo+IENjOiBMVFJV IFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBNYXRjaGluZzogUmFuZ2VzIHZz LiByYW5nZSBsaXN0cw0KPiANCj4gDQo+IA0KPiAtLU9uIDE2LiBub3ZlbWJlciAyMDA1IDA4OjU2 IC0wODAwIE1hcmsgRGF2aXMgPG1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPg0KPiB3cm90ZToN Cj4gDQo+ID4gT25lIG9mIHRoZSBrZXkgaXNzdWVzIGlzIG1ha2luZyBzdXJlIHRoYXQgbG9va3Vw IGFsbG93cyBmb3IgY29ycmVjdA0KPiA+IGhhbmRsaW5nIG9mIHRoZSBkZWZhdWx0IGZhbGxiYWNr LiBUaGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIGRpZmZlcmVudA0KPiA+IHN5c3RlbXMgZG8gaXQg ZGlmZmVyZW50bHkuIExvb2t1cCBvbiBhIHNpbmdsZSBsYW5ndWFnZSB0YWcgcHJvZ3Jlc3NpdmVs eQ0KPiA+IHRydW5jYXRlcy4gSXQgc3dpdGNoZXMgdG8gdGhlIGRlZmF1bHQgbGFuZ3VhZ2UgYmVm b3JlIGdvaW5nIHRvIHJvb3QgKHRoZQ0KPiA+IGxhc3QgcmVzb3J0KS4gU28gc3VwcG9zZSB0aGF0 IHRoZSBkZWZhdWx0IGxhbmd1YWdlIGlzIGphLUpQIChKYXBhbmVzZSBpbg0KPiA+IEphcGFuKS4g V2Ugd291bGQgc2VhcmNoIGFzIGZvbGxvd3M6DQo+ID4gZW5fVVNfQ2FsaWZvcm5pYQ0KPiA+IGVu X1VTDQo+ID4gZW4NCj4gPiBqYV9KUA0KPiA+IGphDQo+ID4gUk9PVA0KPiANCj4gSSBkb24ndCB0 aGluayBJIGFncmVlLiBNeSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0ICJkZWZhdWx0IGxhbmd1YWdl IiBpcyBhDQo+IHBlci1hcHBsaWNhdGlvbiBkZWNpc2lvbiwgbm90IGEgcGFydCBvZiB0aGUgbGFu Z3VhZ2UgbWF0Y2hpbmcgcnVsZSwgYW5kDQo+IHRyZWF0aW5nIGl0IGFzIHBhcnQgb2YgdGhlIGxh bmdhdWdlIG1hdGNoaW5nIHJ1bGUgd2lsbCBqdXN0IGFkZCBjb25mdXNpb24uDQo+IA0KPiBCdXQg SSBoYXZlIHRvIHJlYWQgdGhlIG1hdGNoaW5nIGRyYWZ0IGNhcmVmdWxseSBiZWZvcmUgSSdtIHN1 cmUgd2hhdCBJDQo+IGRpc2FncmVlIHdpdGgsIG9yIGhvdyB0byBleHByZXNzIGl0Lg0KDQo= --===============1123993136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1123993136==-- From ltru-bounces@ietf.org Wed Nov 16 20:23:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYV8-0006u9-Be; Wed, 16 Nov 2005 20:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYV7-0006u4-BB for ltru@megatron.ietf.org; Wed, 16 Nov 2005 20:23:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13164 for ; Wed, 16 Nov 2005 20:23:10 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcYme-0002EQ-9J for ltru@ietf.org; Wed, 16 Nov 2005 20:41:53 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 17:23:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: choice of schemes Date: Wed, 16 Nov 2005 17:23:29 -0800 Message-ID: Thread-Topic: [Ltru] Matching: choice of schemes Thread-Index: AcXrEsW81epHGHWFRAORu++WCUIKqgAAcC+A From: "Addison Phillips" To: "Harald Tveit Alvestrand" , "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 17 Nov 2005 01:23:30.0800 (UTC) FILETIME=[84FDE700:01C5EB15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2075473957==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2075473957== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Q29vbC4gSSBsaWtlIHNwZWNpZmljIGNvbW1lbnRzIGFuZCBkb24ndCBtaW5kIGl0IGlmIHlvdSBk b24ndCBsaWtlIG15IHByb3Bvc2FscyAobWFkZSBpbiB0aGUgZGFyayBvZiBuaWdodCwgYXMgaXQg d2VyZTogSSdtIG5vdCB0b28gZm9uZCBvZiB0aGUgcXVvdGVkIHRleHQgbXlzZWxmKS4gV2UnbGwg bWFrZSBiZXR0ZXIgcHJvZ3Jlc3MgYnkgd29ya2luZyBmcm9tIHNvbWUgdGV4dCwgdGhvJy4NCg0K VGhlIHRleHQgaGFzIGdvbmUgdXAgdG8gdGhlIElEIGVkaXRvciBvciB5b3UgY2FuIHJlYWQgaXQg b24gaW50ZXItbG9jYWxlIChJIG1hZGUgb25lIGxhc3Qgcm91bmQgb2YgZXJyb3IgY29ycmVjdGlv bnMvYWRkaXRpb25zL2VtZW5kYXRpb25zKS4NCg0KTm90ZSB0aGF0IEknbSBub3QgcHJvZHVjaW5n IGEgZGlmZiBmb3IgdGhpcyB2ZXJzaW9uOiB0aGUgZGlmZmVyZW5jZXMgYXJlIHRvbyB2YXN0LCBn aXZlbiB3aG9sZXNhbGUgbW92aW5nIG9mIHRleHQuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQ aGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu IA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhhcmFsZCBUdmVpdCBB bHZlc3RyYW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+IFNlbnQ6IDIwMDXlubQx MeaciDE25pelIDE3OjAyDQo+IFRvOiBBZGRpc29uIFBoaWxsaXBzOyBNYXJ0aW4gRHVlcnN0OyBM VFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUkU6IFtMdHJ1XSBNYXRjaGluZzogY2hvaWNl IG9mIHNjaGVtZXMNCj4gDQo+IA0KPiANCj4gLS1PbiAxNi4gbm92ZW1iZXIgMjAwNSAxMTo0OSAt MDgwMCBBZGRpc29uIFBoaWxsaXBzDQo+IDxhZGRpc29uLnBoaWxsaXBzQHF1ZXN0LmNvbT4gd3Jv dGU6DQo+IA0KPiA+IEkgaGF2ZSBwcm92aWRlZCBzdWdnZXN0ZWQgdGV4dCBpbiBkcmFmdC0wNiB0 aGF0IGRvZXMgd2hhdCB5b3Ugd2FudCB3aXRoDQo+ID4gcmVnYXJkIHRvIGRlc2NyaWJpbmcgdGhl IGNob2ljZXMuIEhlcmUgaXQgaXM6DQo+IA0KPiBJJ3ZlIGdvdCBpc3N1ZXMgd2l0aCBhbG1vc3Qg ZXZlcnkgc2luZ2xlIHBhcmFncmFwaCBpbiB0aGUgdGV4dCB5b3UgcHJvcG9zZS4NCj4gQnV0IEkg dGhpbmsgdGhlIC0wNiByZW9yZ2FuaXphdGlvbiBoYXMgZXhwb3NlZCB0aGVzZSBpc3N1ZXMgbXVj aCBtb3JlDQo+IGNsZWFybHkgdGhhbiB0aGUgcHJldmlvdXMgdmVyc2lvbnMgLSB3aGljaCBpcyB2 ZXJ5IGdvb2QuIEknbGwgY29tbWVudCBvbg0KPiAtMDYgYWZ0ZXIgcHVibGljYXRpb24uDQo+IA0K PiANCg0K --===============2075473957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2075473957==-- From ltru-bounces@ietf.org Wed Nov 16 22:06:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eca6m-00063J-To; Wed, 16 Nov 2005 22:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eca6l-00063E-Ls for ltru@megatron.ietf.org; Wed, 16 Nov 2005 22:06:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21369 for ; Wed, 16 Nov 2005 22:06:10 -0500 (EST) Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcaOJ-0006Y4-ES for ltru@ietf.org; Wed, 16 Nov 2005 22:24:52 -0500 Received: from A31P ([68.100.55.187]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051117030454.XJAF4997.eastrmmtao04.cox.net@A31P> for ; Wed, 16 Nov 2005 22:04:54 -0500 From: "Scott Hollenbeck" To: Date: Wed, 16 Nov 2005 22:06:28 -0500 Message-ID: <003c01c5eb23$e758b3e0$2667fea9@A31P> 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.2670 Thread-Index: AcXago+do/rE1iBTQ5yvZI2jM4i08wQoLIbw X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [Ltru] FW: Off-list RFC 3934 warning to Jefsey Morfin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Jefsey Morfin has appealed the off-list warning described below. I am forwarding the warning to the LTRU mailing list with his permission to create a public record. The appeal itself will be forwarded in a second note. Scott Hollenbeck LTRU Area Advisor > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 26, 2005 7:14 PM > To: JFC (Jefsey) Morfin; r&d afrac > Cc: Scott Hollenbeck; Martin Duerst > Subject: Off-list RFC 3934 warning to Jefsey Morfin > > Hi - > > > From: "r&d afrac" > > To: "Frank Ellermann" ; > > Sent: Wednesday, October 26, 2005 2:30 PM > > Subject: Re: [Ltru] Re: RFC 4151 on The 'tag' URI Scheme > > > > At 22:07 26/10/2005, Frank Ellermann wrote: > > >JFC (Jefsey) Morfin wrote: > > > > > > > The "0-" userspace URI-tag RFC 4151 is now published. > > > My first tag. > > > > This will be usefull in appeal to illustrate the attitude > of this WG. > > jfc > > Since RFC 4151 does not satisfy the requirements for > extensions set forth in > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt > section 3.7, I had interpreted Jefsey's posting as a joke, > and had intended to simply ignore it. > > Since he now appears to be serious, I guess we'll have to > treat it as yet another example of his refusal to give up on > issue #1092 (issue tracker at https://rt.psg.com/ user and > password "ietf"). > > I regard as disruptive continued attempts to re-open closed > issues without providing new rationale. Continuation of this > or other disruptive activities may resulting in the > suspension of Jefsey's posting privileges to the ltru WG > mailing list for a period of up to 30 days. > > Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 16 23:41:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcbaX-00088S-AI; Wed, 16 Nov 2005 23:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcbaV-00088L-RE for ltru@megatron.ietf.org; Wed, 16 Nov 2005 23:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26565 for ; Wed, 16 Nov 2005 23:40:57 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecbs1-0001DO-QY for ltru@ietf.org; Wed, 16 Nov 2005 23:59:41 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAH4f8u27921; Thu, 17 Nov 2005 13:41:08 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 35ea_5f0d754e_5724_11da_93b4_00304811fd80; Thu, 17 Nov 2005 13:41:07 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAH4dmB7022697; Thu, 17 Nov 2005 13:40:31 +0900 Message-Id: <6.0.0.20.2.20051117105104.079caad0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Nov 2005 10:52:35 +0900 To: "Addison Phillips" From: Martin Duerst Subject: Re: [Ltru] draft-ietf-ltru-matching-06 submission In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hello Addison, Thanks for submitting another official draft. I was thinking about suggesting that, and it's great to see things just happen! Regards, Martin. At 10:07 05/11/17, Addison Phillips wrote: >Dear Editor, > >Please find attached draft-06 of "draft-ietf-ltru-matching". > >Thanks! > >Addison (for the editors) > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Internationalization is not a feature. >It is an architecture. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 05:43:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchFG-00030L-QQ; Thu, 17 Nov 2005 05:43:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchFF-000303-3J for ltru@megatron.ietf.org; Thu, 17 Nov 2005 05:43:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13086 for ; Thu, 17 Nov 2005 05:43:23 -0500 (EST) Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EchWr-0004KF-8E for ltru@ietf.org; Thu, 17 Nov 2005 06:02:10 -0500 Received: (qmail 61850 messnum 275741 invoked from network[159.134.168.169/159-134-168-169.as1.prp.dublin.eircom.net]); 17 Nov 2005 10:43:37 -0000 Received: from 159-134-168-169.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.169) by mail03.svc.cra.dublin.eircom.net (qp 61850) with SMTP; 17 Nov 2005 10:43:37 -0000 Message-ID: <437C5EDC.41E01D37@egt.ie> Date: Thu, 17 Nov 2005 10:43:39 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ltru@ietf.org, ietf-languages@alvestrand.no, unicode@unicode.org Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA13086 Cc: Subject: [Ltru] John Clews of BSI, RIP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John Clews, my old friend, from beginning to end, a Cornishman, and true. All your friends in BSI with others, such as I, are sorely missing you. Cres dh'y enef. mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 07:16:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecigg-00017M-V1; Thu, 17 Nov 2005 07:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecigf-00015p-Bl for ltru@megatron.ietf.org; Thu, 17 Nov 2005 07:16:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18292 for ; Thu, 17 Nov 2005 07:15:46 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EciyG-0007PW-Ml for ltru@ietf.org; Thu, 17 Nov 2005 07:34:35 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 17 Nov 2005 07:15:44 -0500 id 0158800A.437C7470.00006D26 From: "Scott Hollenbeck" To: ltru@ietf.org Date: Thu, 17 Nov 2005 07:16:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcXaoACfWEaPWsYMQGe3PAoJL8pJBgQg+4Vw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OlkEid: EB24783F2723BDF600BC434AB558B10D3DE30CC3 X-MS-TNEF-Correlator: 00000000ABC852028EB3CB489F89FFD501BB1CEB24783F00 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Content-Transfer-Encoding: 7bit Subject: [Ltru] FW: Appeal - Off-list RFC 3934 warning to Jefsey Morfin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is the appeal received from Jefsey Morfin in response to the off-list warning for off-topic posting that is described here: http://www1.ietf.org/mail-archive/web/ltru/current/msg04110.html After I received his appeal we exchanged a few other messages as I attempted to understand the facts of his appeal. Ultimately that exchange produced this understanding: > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: Thursday, October 27, 2005 7:11 PM > To: Scott Hollenbeck > Subject: RE: Appeal - Off-list RFC 3934 warning to Jefsey Morfin > > On 14:34 27/10/2005, Scott Hollenbeck said: > > > Jefsey, > > " For all the reasons above I appeal of the today > warning of co-Chair Randy Presun and of his evaluation of > consensus concerning the RFC 3066 bis." > > I need to understand what you're appealing. The > warning, as I understand it, was given to you because Randy > believes your message concerned a topic that has been closed > for discussion and you have been told repeatedly that such > messages are not appropriate. Are you claiming that the > warning was inappropriate because your message was not > related to a topic that was closed when the working group > reached consensus on a position, or that Randy did not > correctly determine consensus? > > > Both. > I thought I documented it well enough, sorry if it not clear enough. I then asked Mr. Morfin to point me to specific instances of his contributions to the working group mailing list that he believes were not properly handled. Mr. Morfin sent me that list yesterday. I will forward it shortly. I am forwarding his appeal to the LTRU mailing list with his permission to create a public record. I am reviewing this appeal in two parts to address both of Mr. Morfin's claims and will return my decision to Mr. Morfin and this list as quickly as possible. Scott Hollenbeck LTRU Area Advisor > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: Wednesday, October 26, 2005 9:22 PM > To: Scott Hollenbeck > Cc: Martin Duerst; Randy Presuhn > Subject: Appeal - Off-list RFC 3934 warning to Jefsey Morfin > > Dear Scott, > I am sorry but I can only appeal with very serious reasons. > They show the very nature of this warning and that the text > you shepher in front of the IESG does not result from a > concensus, on my key point; and that this is not by mistake. > > APPEAL > ------------- > Of the October 26th warning and of the declaration of a > consensus over the RFC 3066 bis document. > > > 1. The exotic "#1092" is not concerned. The issue "#1092" says: > > > Sujet: WGLC treat 0- as escape from syntax > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03099.html > tml> requests that the proposal to use 0- as an escape, > introduced in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03061.html > tml> be given a distinct issue number. > Note that the resolution of other issues, e.g., #1072 > subsumes this issue and precludes the suggested solution. > consequently, this issue is marked as "rejected" > > > A look at the quoted mails shows that Point "#1092" covers > the discussion between format: > > > > > >> > > x-you-could-simply-string-together-any-addition-al-attribut-es-you- > > > >> > > like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii- > > > >> characte-rs > > > > and format > "0-language-tags.x-tags.com:singapourien.jefsey-languages.com: 20051203160809A-2001:879:98F6::789C:1236" > > It supports the concept that "0-" would _terminate_ the ABNF, > permitting afteward a free format. > > > > 2. this mail concerns the inclusion of information of the type: > > "0-tag:xyzzy.claranet.de,2005:troll-alert" > from for example, > > as documented by an opponent who has well understood the proposition. > > It supports the concept that "0-" would include information > respecting the RFC 4151 ABNF, avoiding the RFC 3066 bis to > conflict with RFC 4151 > > I note that this proposition has been made sevreal times at > the WG and was allways opposed the misrepresentation above. > That this proposition has the significant advantage to > support ISO 11179 compliance, and the proposed wording for > ISO 639-4 which underlay the ISO 639 series (the WG-ltru > charter calls for the homogenous support). That due to the > misrepresentation above the "consensus" has been to oppose an > ISO 11179 conformance what is highly detrimental to the > architectural deployment of the Internet. > > That this proposition has therefore been made during the IESG > LC and is therefore a pending representation. > > That RFC 4151 (as demonstrated by the quoted response) > permits to identify and document the language of a document. > That as an existing informational RFC it describes a practice > of the Global Internet Community the WG-ltru Chair has > refused to consider. > > That most of all in this particular appeal, this information > concerns both the passed registry debate and the _current_ > filtering debate. > > > 3. the pratice documented by RFC 4151 creates a problem to > the currently discussed issue of the WG-ltru, i.e. filtering. > When a language information is delivered through an RFC 4151 > conformant format, > > - it can be resolved in (among others) the RFC 3066 bis format > - it can be filtered exactly in the same way. > > But this (may) rise(s) some issues which have not yet been > considered. > > This "warning" is therefore a way to _influence_ the current > debate on filtering. It illustrates the way the co-Chair has > objected the propositions I made to find the most adequate > solution to the users and SSDOs needs and to the RFC 4151 > documented practices. This makes RFC 3066 bis to still ignore > them. This is also something the Members of the WG ignore. > May be even the authors and their small number of supporters, > while they want to exclude and constrain these needs and > practices. As if they wanted their pet software products not > to be changed or challenged. > > I note that I have patiently accepted to be exposed to that > practice. Because the experience of centuries of missionaries > has shown that it was a pretty efficient manner to introduce > the proper solutions. Because, as today, error and bias > expose themselves. > > > 4. all this shows that: > > - my post does not concerns #1092 > - that my position on this issue as constantly been > misrepresented by the co-Chair, as it is today > - that in so doing he had coached the WG-ltru n such a > way that my _only_ objection to the current text (the > inclusion of the RFC 4151 described practices) had been > suposedly consensually rejected and my other concurrent > propositions have been disregarded on similar gronds. > - that he has constantly used private warnings with no > more substance that this one, since: > - this comments introduces new information which > concerns (but not affect) the indirect access to the langtags > and the user security > - it concerns a proposition I made which has never been > discussed > - which is pending in front of the IESG, IAB and the > community (I never hiden that I will appeal for it) > - which is pertinent to the current debate of the WG-ltru > - it concerns the current debate over filtering. > > > 5. I note that in so doing the co-Chair, as in all the other > occasions, uses warnings or suspension to support a > delictuous action of a Member and has so encouraged them > deliberately creating the deleterious climate of this WG.. > Ban (now too old for appeal) was over an oppostion to a > racist position of a Member, a recent warning against a > reaction to stop a similar creep. He should have taken care > of instead of encouraging it. Today it is used to support a > blattant ad-hominem and to threat my right to appeal. > > > 6. I could consider that this is only a continuation of the > personal feelings the co-Chair expressed in a public > ad-hominem full of .. disputable affirmations, but ... > > - this case concerns a point of high commercial, political > and Internet architectural impact. This is over a document > the co-Chair tries to influence as the manager of a tracking > system he created and the way he demonstrates by this case. > > - this demonstrates that there is not a single way to > accomplish the purpose of the langtags as affirmed by the BCP > qualification of RFC 3066 bis. This is something a simple > initial review of the Charter would have shown. A review I > asked for many times, the co-Chair opposed - in spite of its > "thorny" (his qualification) points - but promised to carry > at the end of the process. This validation has not been carried yet. > > - this increases the legal risks related to the proposed text > since there is now an existing RFC documented alternative > which does not run into that risk. This should be mentionned > into the security considerations: they only mention the risk > and not the RFC 4151 solution. > > - all these points have been hidden or reduced in the view of > the community and of the IETF, in misprepresenting it - as it > is still done today - with the authority of a WG-Chair. This > makes the WG-ltru, the IETF and the IESG feel my key > proposition has been discussed, opposed and consensually > refused, what it has _never_ been discussed. Knowing that > this point was complex and that this affimation would be > controverted, I purposely never quoted a key aspect which > would have resulted from any serious discussion. > > It is easy to show if I am right or if I am wrong. I just > introduced it in this mail for the first time. > > > > For all the reasons above I appeal of the today warning of > co-Chair Randy Presun and of his evaluation of consensus > concerning the RFC 3066 bis. > > > I note that I have no feeling concerning Randy Presuhn, > except for his behaviour over the "Route 666" issue. This is > purely technical and I am only motivated by the good of the > IETF and of the users. I fully understand the pressure and > the load you all meets. I am sorry to add burdens, but this > time there is a full exposure of the oily mechanism I am > myself submitted to, for so many months. > > There is a clear exposure of the bias which lead to the > presented document (I think I positively contributed to, in > spite or becaus of the opposition). This document is wrong, > but can be made right in includint the only proposition I > consider important: compatibility with its RFC competitor. I > certainly understand it breaks the notion of immediate > exclusive. Is that a reason to hide them to the WG-ltru members? > > I think the exclusive comes from quality rather than > misrepresentation, or typos. > jfc morfin > > > > > At 01:14 27/10/2005, Randy Presuhn wrote: > > > Hi - > > From: "r&d afrac" > > To: "Frank Ellermann" ; > > > Sent: Wednesday, October 26, 2005 2:30 PM > > Subject: Re: [Ltru] Re: RFC 4151 on The 'tag' URI Scheme > > > > At 22:07 26/10/2005, Frank Ellermann wrote: > > >JFC (Jefsey) Morfin wrote: > > > > > > > The "0-" userspace URI-tag RFC 4151 is now published. > > > My first tag. > > > > This will be usefull in appeal to illustrate the > attitude of this WG. > > jfc > > Since RFC 4151 does not satisfy the requirements for extensions > set forth in > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-1 > 4.txt > 14.txt> > section 3.7, I had interpreted Jefsey's posting as a > joke, and had > intended to simply ignore it. > > Since he now appears to be serious, I guess we'll have > to treat it > as yet another example of his refusal to give up on issue #1092 > (issue tracker at https://rt.psg.com/ user and password "ietf"). > > I regard as disruptive continued attempts to re-open closed > issues without providing new rationale. Continuation of this > or other disruptive activities may resulting in the > suspension of > Jefsey's posting privileges to the ltru WG mailing list > for a period > of up to 30 days. > > Randy, ltru co-chair > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 07:19:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecijq-0001lP-HL; Thu, 17 Nov 2005 07:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecijo-0001lH-Uv for ltru@megatron.ietf.org; Thu, 17 Nov 2005 07:19:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18562 for ; Thu, 17 Nov 2005 07:19:02 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecj1S-0007Xu-9D for ltru@ietf.org; Thu, 17 Nov 2005 07:37:50 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 17 Nov 2005 07:19:15 -0500 id 0158800A.437C7543.00006D84 From: "Scott Hollenbeck" To: ltru@ietf.org Date: Thu, 17 Nov 2005 07:19:31 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXqwb7DYU+mhBmKRkef6MMDudipRwArvIjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Subject: [Ltru] FW: the URLs you asked for X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1033731028==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1033731028== Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01C5EB47.415B3930" This is a multi-part message in MIME format. ------=_NextPart_000_013E_01C5EB47.415B3930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the final element of the appeal submitted by Jefsey Morfin. I am forwarding this part of his appeal to the LTRU mailing list with his permission to create a public record. Scott Hollenbeck LTRU Area Advisor _____ From: Jefsey Morfin [mailto:jefsey@online.fr] Sent: Wednesday, November 16, 2005 10:24 AM To: sah@428cobrajet.net Subject: the URLs you asked for Dear Scott, I rush this for you. It documents clearly that two proposition have received tracker numbers and discussed, not the last one wich is therefore still open and undocumented in http://www1.ietf.org/mail-archive/web/ltru/current/msg03807.html. I add some of the points (IRI, encryption) on this proposition which have obviously never been discussed by WG-ltru. 1. "x-" private use zone is modified - tracker # 1072 http://www1.ietf.org/mail-archive/web/ltru/current/msg03053.html I ask Randy: 1. you warranty these scheme will prevent conflicts 2. will support a simple format such as x-schemes:name.subname:address:date-etc. 3. will address the right of billions of users to document the way they want 20.000 languages in thousands of regions, the languages and scripting variations they may chose (private use is for that). If you can seriously document this I will drop my demand. 2. "0-" is an absolute escape sequence quitting the gracefully the domain of RFC 3066 - tracker # 1092 http://www1.ietf.org/mail-archive/web/ltru/current/msg03101.html For completeness, I've added this to the tracker. ------------------------------------------------------------------------- > http://www1.ietf.org/mail-archive/web/ltru/current/msg03099.html > requests that the proposal to use 0- as an escape, introduced > in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03061.html > be given a distinct issue number. > Note that the resolution of other issues, e.g., #1072 > subsumes this issue and precludes the suggested solution. > consequently, this issue is marked as "rejected" This reject of this obviously different proposition is disputed further on. 3. "0-" is not an absolute escape. It is an introduction to user space ABNF by an exsting RFC - no tracker on this accepted agreement. http://www1.ietf.org/mail-archive/web/ltru/current/msg03242.html Addison Philips: -I oppose the last call suggestion to put in text reserving the digit 0 to introduce malformed tags. JFC: Agreed. The "0-" is to escape the Draft ABNF and to permit to introduce "better schemes", like the one you introduced in the past. May be will you be kind enough to give the reference. I see we agree now: malformed tags are to be before "0-" and tags after "0-", MUST be correctly informed tags, following the K/H RFC. I note that during the IESG Last Call: - we have had an exchange on this new non tracked and never addressed problem of the conflict between RFC 3066 bis and RGC 4151. http://www1.ietf.org/mail-archive/web/ietf/current/msg37090.html I note that _you_ have not concluded given a reponse and that RFC 3066 bis text today does not comment the complemetarity or the conflict with RFC 4151. Both are authored by members of the W3C acting privately. As AFRAC my intent is to write the W3C and the IETF (now in charge through) to ask a clarification on the solution they truly W3C supports, copy to all the interested parties. - http://www1.ietf.org/mail-archive/web/ietf/current/msg37285.html review my positions evolution and the lack of information of Peter Constable. In this I say: "I then came to the conclusion that using the present Draft as a default non exclusive solution, and some reserved numeric "singleton" as the hooks for URI-tags was preserving the work made by the WG, while addressing the needs of the rest of the world, avoiding an unnecessary conflict." "The real solution is IRI-tags we will document as soon as the URI-tags RFC is published. But that will create a deployment conflict with your application, due to your sponsors. No one needs that." None of these positions have been discussed by the WG. They obviously greatly influence the filtering since an URI/IRI-tag can present the information discussed by the WG in different, possibly conflicting ways, or simply relate to and (extended) langtag. This debate is certainly not closed and will reopen with the IRI-tag Draft. Addressing it now would be advisable: - http://www1.ietf.org/mail-archive/web/ietf/current/msg37262.html rises a new point of importantce: encrypted format. This means that the legitimate URI tag: "tags:x-tags.org:constable.english.x-tag.org" must be accommodated into the format "x-xxxxxxxx-xxxxxxxx-xxxxxxxx-etc." instead of "0-x-tags.org:constable.english.x-tag.org" This can only lead to a confusing deprecation of the RFC 3066bis which will be replaced by a generalised IRI-tags solution. The solution I propose consists only in accepting that what the Draft would call "specialised subtags" have a size limited to the tag length - 2, and an URI-tag charset. NB. Since "x-" was used in RFC 3066 and it has been pointed to me that a specific privateuse (in a VPN for example) could be needed, we selected "0-" for an open format. Actually we suggest "1-" for an encrypted format. No work has been yet carried on this. All the best. jfc ------=_NextPart_000_013E_01C5EB47.415B3930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is the final element of the appeal = submitted by=20 Jefsey Morfin.  I am = forwarding this part of his appeal to the LTRU = mailing list=20 with his permission to create a public record.

Scott Hollenbeck
LTRU = Area=20 Advisor


From: Jefsey Morfin = [mailto:jefsey@online.fr]=20
Sent: Wednesday, November 16, 2005 10:24 AM
To:=20 sah@428cobrajet.net
Subject: the URLs you asked=20 for

Dear Scott,
I rush this for you. It documents clearly that = two=20 proposition have received tracker numbers and discussed, not the last = one wich=20 is therefore still open and undocumented in http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03807.html.=20
I add some of the points (IRI, encryption) on this proposition which = have=20 obviously never been discussed by WG-ltru.

1. "x-" private use = zone is=20 modified - tracker # 1072
http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03053.html
I=20 ask Randy:
1. you warranty these scheme will prevent conflicts
2. = will=20 support a simple format such as = x-schemes:name.subname:address:date-etc.
3.=20 will address the right of billions of users to document the way they = want 20.000=20 languages in thousands of regions, the languages and scripting = variations they=20 may chose (private use is for that).
If you can seriously document = this I=20 will drop my demand.


2. "0-" is an absolute escape sequence = quitting=20 the gracefully the domain of RFC 3066 - tracker # 1092
http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03101.html
For=20 completeness, I've added this to the=20 tracker.
-------------------------------------------------------------= ------------
>=20 http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03099.html
>=20 requests that the proposal to use 0- as an escape, introduced
> in = message
> http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03061.html
>=20 be given a distinct issue number.
> Note that the resolution of = other=20 issues, e.g., #1072
> subsumes this issue and precludes the = suggested=20 solution.
> consequently, this issue is marked as = "rejected"

This=20 reject of this obviously different proposition is disputed further = on.

3.=20 "0-" is not an absolute escape. It is an introduction to user space ABNF = by an=20 exsting RFC - no tracker on this accepted agreement.
http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03242.html
Addison=20 Philips:
-I oppose the last call suggestion to put in text reserving = the=20 digit 0 to introduce malformed tags.
JFC:
Agreed. The "0-" is to = escape=20 the Draft ABNF and to permit to introduce "better schemes", like the one = you=20 introduced in the past. May be will you be kind enough to give the = reference. I=20 see we agree now: malformed tags are to be before "0-" and tags after = "0-", MUST=20 be correctly informed tags, following the K/H RFC. =


I note=20 that during the IESG Last Call:
- we have had an exchange on this new = non=20 tracked and never addressed problem of the conflict between RFC 3066 bis = and RGC=20 4151. http://www1.ietf.org/mail-archive/web/ietf/current/msg= 37090.html
I=20 note that _you_ have not concluded given a reponse and that RFC 3066 bis = text=20 today does not comment the complemetarity or the conflict with RFC 4151. = Both=20 are authored by members of the W3C acting privately. As AFRAC my intent = is to=20 write the W3C and the IETF (now in charge through) to ask a = clarification on the=20 solution they truly W3C supports, copy to all the interested = parties.

-=20 http://www1.ietf.org/mail-archive/web/ietf/current/msg= 37285.html
review=20 my positions evolution and the lack of information of Peter Constable. = In this I=20 say:
"I then came to the conclusion that using the present Draft as a = default=20 non exclusive solution, and some reserved numeric "singleton" as the = hooks for=20 URI-tags was preserving the work made by the WG, while addressing the = needs of=20 the rest of the world, avoiding an unnecessary conflict."
"The real = solution=20 is IRI-tags we will document as soon as the URI-tags RFC is published. = But that=20 will create a deployment conflict with your application, due to your = sponsors.=20 No one needs that."

None of these positions have been discussed = by the=20 WG. They obviously greatly influence the filtering since an URI/IRI-tag = can=20 present the information discussed by the WG in different, possibly = conflicting=20 ways, or simply relate to and (extended) langtag.

This debate is=20 certainly not closed and will reopen with the IRI-tag Draft. Addressing = it now=20 would be advisable:

- http://www1.ietf.org/mail-archive/web/ietf/current/msg= 37262.html
rises=20 a new point of importantce: encrypted format.
<quote>
This = means=20 that the legitimate URI = tag:
"tags:x-tags.org:constable.english.x-tag.org"=20 must be accommodated into the format "x-xxxxxxxx-xxxxxxxx-xxxxxxxx-etc." = instead=20 of "0-x-tags.org:constable.english.x-tag.org"

This can only lead = to a=20 confusing deprecation of the RFC 3066bis which will be replaced by a = generalised=20 IRI-tags solution. The solution I propose consists only in accepting = that what=20 the Draft would call "specialised subtags" have a size limited to the = tag length=20 - 2, and an URI-tag charset.

NB. Since "x-" was used in RFC 3066 = and it=20 has been pointed to me that a specific privateuse (in a VPN for example) = could=20 be needed, we selected "0-" for an open format. Actually we suggest "1-" = for an=20 encrypted format. No work has been yet carried on this.=20
</quote>

All the best.
jfc

------=_NextPart_000_013E_01C5EB47.415B3930-- --===============1033731028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1033731028==-- From ltru-bounces@ietf.org Thu Nov 17 08:19:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjXs-0001oc-1u; Thu, 17 Nov 2005 08:11:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjXp-0001nK-CP for ltru@megatron.ietf.org; Thu, 17 Nov 2005 08:11:18 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22183 for ; Thu, 17 Nov 2005 08:10:41 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EcjVF-0004vD-Ki for ltru@lists.ietf.org; Thu, 17 Nov 2005 14:08:37 +0100 Received: from pd9fba9ac.dip0.t-ipconnect.de ([217.251.169.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 14:08:37 +0100 Received: from nobody by pd9fba9ac.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 14:08:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 14:03:08 +0100 Organization: Lines: 15 Message-ID: <437C7F8C.380@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: pd9fba9ac.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: FW: the URLs you asked for X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scott Hollenbeck wrote: > I am forwarding this part of his appeal to the LTRU mailing > list with his permission to create a public record. Do you expect "us" (or me) to do anything with it, e.g. find the threads where the "0-" idea was discussed, and how any character that's neither letter nor digit could be used to introduce some kind of non-3066 / non-3066bis "tags" ? Similar threads where using pieces of eight B64 characters to encode anything as x-base64ba-se64base-etc were discussed. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 08:27:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjnB-0007Lj-FH; Thu, 17 Nov 2005 08:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjnA-0007Le-BW for ltru@megatron.ietf.org; Thu, 17 Nov 2005 08:27:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23283 for ; Thu, 17 Nov 2005 08:26:33 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eck4n-0001j2-MJ for ltru@ietf.org; Thu, 17 Nov 2005 08:45:22 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 17 Nov 2005 08:26:38 -0500 id 0158801D.437C850E.0000778D From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: FW: the URLs you asked for Date: Thu, 17 Nov 2005 08:26:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <437C7F8C.380@xyzzy.claranet.de> Thread-Index: AcXreeSsrSu1BBA+TBieCXB7HYF5jgAACxCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Thursday, November 17, 2005 8:03 AM > To: ltru@ietf.org > Subject: [Ltru] Re: FW: the URLs you asked for > > Scott Hollenbeck wrote: > > > I am forwarding this part of his appeal to the LTRU mailing > > list with his permission to create a public record. > > Do you expect "us" (or me) to do anything with it, e.g. find > the threads where the "0-" idea was discussed, and how any > character that's neither letter nor digit could be used to > introduce some kind of non-3066 / non-3066bis "tags" ? > > Similar threads where using pieces of eight B64 characters > to encode anything as x-base64ba-se64base-etc were discussed. No, I'm not asking anyone to do anything. What I'm doing is documenting a process action that may or may not have an impact on the work of the group. My decision can be appealed, and if that happens I want to be sure that the information I am reviewing is available to those who might have to review my decision in the future. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 08:33:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjtn-0000Ru-JY; Thu, 17 Nov 2005 08:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjtm-0000RE-FX for ltru@megatron.ietf.org; Thu, 17 Nov 2005 08:33:58 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23701 for ; Thu, 17 Nov 2005 08:33:23 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ecjpg-0005f7-S4 for ltru@lists.ietf.org; Thu, 17 Nov 2005 14:29:44 +0100 Received: from pd9fba9ac.dip0.t-ipconnect.de ([217.251.169.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 14:29:44 +0100 Received: from nobody by pd9fba9ac.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 14:29:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 14:24:59 +0100 Organization: Lines: 19 Message-ID: <437C84AB.4B41@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: pd9fba9ac.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Need more interesting distance metric (?) (was: Matching: choice of schemes) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Harald Tveit Alvestrand wrote: > I'll comment on -06 after publication. Something with the "distance metric" is odd. It was 8-4-2-1. That was the minimal metric having precisely the same effect as LTR (letf-to-right). Now it's 256-128-32-4-1. Beats me where that could be different from 16-8-4-2-1, which would be again the same as LTR, only over 5 positions. For some interesting effect - plus a still missing example to explain it - we need w1-w2-w3-w4-w5 with a pair w(i)-w(i+1) where w(i) < 2*w(i+1). With 2*w(i+1) <= w(i) everywhere it's always the same as LTR matching, or do I miss something ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 09:22:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eckew-0000BX-1r; Thu, 17 Nov 2005 09:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eckeu-0000Ar-Ng for ltru@megatron.ietf.org; Thu, 17 Nov 2005 09:22:41 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26637 for ; Thu, 17 Nov 2005 09:22:04 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Eckbm-0004RC-P4 for ltru@lists.ietf.org; Thu, 17 Nov 2005 15:19:26 +0100 Received: from c-180-160-157.hh.dial.de.ignite.net ([62.180.160.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 15:19:26 +0100 Received: from nobody by c-180-160-157.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 15:19:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 15:15:08 +0100 Organization: Lines: 9 Message-ID: <437C906C.240A@xyzzy.claranet.de> References: <437C7F8C.380@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: c-180-160-157.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: FW: the URLs you asked for X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Scott Hollenbeck wrote: > documenting a process action JFTR, got it. Works rather smooth from my POV. Only the BCP vs. standards track issue was a bit rough, it never occured to me that it also affects the matching draft resulting in one BCP with two RfCs. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 09:34:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckqG-0002wF-Su; Thu, 17 Nov 2005 09:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckqF-0002wA-GX for ltru@megatron.ietf.org; Thu, 17 Nov 2005 09:34:23 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27292 for ; Thu, 17 Nov 2005 09:33:47 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Eckmb-0000r2-Sg for ltru@lists.ietf.org; Thu, 17 Nov 2005 15:30:37 +0100 Received: from c-180-160-157.hh.dial.de.ignite.net ([62.180.160.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 15:30:37 +0100 Received: from nobody by c-180-160-157.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 15:30:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 15:27:54 +0100 Organization: Lines: 16 Message-ID: <437C936A.49C9@xyzzy.claranet.de> References: <000101c5eae6$a77ea640$7f1afea9@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: c-180-160-157.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proto-Matching Draft Update 06 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > it would be simpler for all concerned to simply use > > in the xml source and let the tools do the job. Won't work in the abstract if you also have "strict". And without "strict" a type="abnf" artwork won't trigger the ABNF check. Last time the problem was upper case type="ABNF" that ultimately got us a [Discuss]. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 10:16:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclVD-0000aj-OP; Thu, 17 Nov 2005 10:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclVB-0000aW-VP for ltru@megatron.ietf.org; Thu, 17 Nov 2005 10:16:42 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29609 for ; Thu, 17 Nov 2005 10:16:08 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EclQB-0004Md-Pc for ltru@lists.ietf.org; Thu, 17 Nov 2005 16:11:32 +0100 Received: from c-180-160-157.hh.dial.de.ignite.net ([62.180.160.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 16:11:31 +0100 Received: from nobody by c-180-160-157.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2005 16:11:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 16:08:37 +0100 Organization: Lines: 17 Message-ID: <437C9CF5.13FD@xyzzy.claranet.de> References: <437C84AB.4B41@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: c-180-160-157.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Need more interesting distance metric (?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > Now it's 256-128-32-4-1. Beats me where that could be > different from 16-8-4-2-1, which would be again the same > as LTR, only over 5 positions. Delete that: It's different if three matching extensions trump one unmatched variant. OTOH there are no extensions at the moment, so that's rather academic, isn't it ? How about 32-16-8-TBD-1 ? Then TBD=3 would be "4 extensions can trump a variant" or "3 variants can trump the region", or a mixture like "3*1 + 2*3 > 8" to trump the region (= 8). Still odd as long as there no extensions at all, and so far there are also no "double-variants", let alone more than two variants. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 11:45:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecmsw-0001R2-6V; Thu, 17 Nov 2005 11:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecmst-0001Qc-M6 for ltru@megatron.ietf.org; Thu, 17 Nov 2005 11:45:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05593 for ; Thu, 17 Nov 2005 11:44:40 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcnAX-0000VZ-PR for ltru@ietf.org; Thu, 17 Nov 2005 12:03:31 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 08:44:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Need more interesting distance metric (?) (was: Matching:choice of schemes) Date: Thu, 17 Nov 2005 08:44:58 -0800 Message-ID: Thread-Topic: [Ltru] Need more interesting distance metric (?) (was: Matching:choice of schemes) Thread-Index: AcXre7A+ptrLQS66TrK7AHH/aUtUfQAGe3jg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Nov 2005 16:44:59.0466 (UTC) FILETIME=[3F9AD2A0:01C5EB96] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084043492==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1084043492== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlcmUgd2VyZSAoaGUgc2F5cywgcmFja2luZyBoaXMgYnJhaW5zIHRvIHJlbWVtYmVyKSBhIGNv dXBsZSBvZiByZWFzb25zIGZvciBpbmNyZWFzaW5nIHRoZSBkaXN0YW5jZXMgaW4gdGhlIG1ldHJp YzoNCg0KMS4gSXQgYWxsb3dzIGZvciBiZXR0ZXIgY3VzdG9tIHRhaWxvcmluZyAoYnkgY3JlYXRp bmcgdGhlIHBvc3NpYmlsaXR5IGZvciBoYWxmLXNjb3JlcyBhbmQgdGhlIGxpa2UpLiBUaGUgdGhl b3JpemVkIHVzZSBvZiAicSIgd2VpZ2h0cyBpbiBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgdG8g bXVsdGlwbHkgdGhlIHZhbHVlcyB3b3JrcyBiZXR0ZXIgd2l0aCBsYXJnZXIgZ2FwcyBiZXR3ZWVu IHRoZSB2YWx1ZXMsIGF0IGxlYXN0IG9uIHBhcGVyLg0KDQoyLiBJdCBoZWxwcyBkZWFsIHdpdGgg dGhlIGZhY3QgdGhhdCB2YXJpYW50cyBjYW4gaGF2ZSBtb3JlIHRoYW4gb25lIHN1YnRhZy4gWW91 IG5lZWQgZm91ciBtYXRjaGluZyB2YXJpYW50IHN1YnRhZ3MgdG8gZXF1YWwgb25lIHJlZ2lvbiBz dWJ0YWcuDQoNCkJ1dCBvdGhlcndpc2UgSSBkb24ndCByZWFsbHkgcmVjYWxsIHdoeSB0aGUgbnVt YmVycyB3ZXJlIGluY3JlYXNlZC4gTXkgaW1wbGVtZW50YXRpb24gaXNuJ3QgZG9uZSwgc28gSSBo YXZlbid0IGhhZCBhIGNoYW5jZSB0byBwbGF5IHdpdGggaXQgbXVjaCBpbiBkZXB0aC4NCg0KQWRk aXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVl c3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gRnJhbmsgRWxsZXJtYW5uDQo+IFNlbnQ6IDIwMDXlubQxMeaciDE3 5pelIDU6MjUNCj4gVG86IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0x0cnVdIE5lZWQgbW9y ZSBpbnRlcmVzdGluZyBkaXN0YW5jZSBtZXRyaWMgKD8pICh3YXM6DQo+IE1hdGNoaW5nOmNob2lj ZSBvZiBzY2hlbWVzKQ0KPiANCj4gSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQgd3JvdGU6DQo+IA0K PiA+IEknbGwgY29tbWVudCBvbiAtMDYgYWZ0ZXIgcHVibGljYXRpb24uDQo+IA0KPiBTb21ldGhp bmcgd2l0aCB0aGUgImRpc3RhbmNlIG1ldHJpYyIgaXMgb2RkLiAgSXQgd2FzIDgtNC0yLTEuDQo+ IFRoYXQgd2FzIHRoZSBtaW5pbWFsIG1ldHJpYyBoYXZpbmcgcHJlY2lzZWx5IHRoZSBzYW1lIGVm ZmVjdA0KPiBhcyBMVFIgKGxldGYtdG8tcmlnaHQpLg0KPiANCj4gTm93IGl0J3MgMjU2LTEyOC0z Mi00LTEuICBCZWF0cyBtZSB3aGVyZSB0aGF0IGNvdWxkIGJlDQo+IGRpZmZlcmVudCBmcm9tIDE2 LTgtNC0yLTEsIHdoaWNoIHdvdWxkIGJlIGFnYWluIHRoZSBzYW1lIGFzDQo+IExUUiwgb25seSBv dmVyIDUgcG9zaXRpb25zLg0KPiANCj4gRm9yIHNvbWUgaW50ZXJlc3RpbmcgZWZmZWN0IC0gcGx1 cyBhIHN0aWxsIG1pc3NpbmcgZXhhbXBsZSB0bw0KPiBleHBsYWluIGl0IC0gd2UgbmVlZCB3MS13 Mi13My13NC13NSB3aXRoIGEgcGFpciB3KGkpLXcoaSsxKQ0KPiB3aGVyZSB3KGkpIDwgMip3KGkr MSkuICBXaXRoIDIqdyhpKzEpIDw9IHcoaSkgZXZlcnl3aGVyZSBpdCdzDQo+IGFsd2F5cyB0aGUg c2FtZSBhcyBMVFIgbWF0Y2hpbmcsIG9yIGRvIEkgbWlzcyBzb21ldGhpbmcgPw0KPiANCj4gICAg ICAgICAgICAgICAgICAgICAgICBCeWUsIEZyYW5rDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0 DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydQ0K --===============1084043492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1084043492==-- From ltru-bounces@ietf.org Thu Nov 17 11:54:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn1X-0004xi-WA; Thu, 17 Nov 2005 11:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn1W-0004xd-Fr for ltru@megatron.ietf.org; Thu, 17 Nov 2005 11:54:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06175 for ; Thu, 17 Nov 2005 11:53:36 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcnJB-0000pS-IM for ltru@ietf.org; Thu, 17 Nov 2005 12:12:26 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 08:53:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proto-Matching Draft Update 06 Date: Thu, 17 Nov 2005 08:53:54 -0800 Message-ID: Thread-Topic: [Ltru] Re: Proto-Matching Draft Update 06 Thread-Index: AcXrhEgXiO7sB5waRJaa9lJwpwAAOwAEyS0w From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Nov 2005 16:53:55.0854 (UTC) FILETIME=[7F5122E0:01C5EB97] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1073958715==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1073958715== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB1c2VkIFJGQzMwNjZiaXMsIHBlciBTY290dC4gTG9va3Mgb2theSwgd29ya3MgZmluZS4NCg0K QWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwg UXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4N Ckl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gRnJhbmsgRWxsZXJtYW5uDQo+IFNlbnQ6IDIwMDXlubQxMeac iDE35pelIDY6MjgNCj4gVG86IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0x0cnVdIFJlOiBQ cm90by1NYXRjaGluZyBEcmFmdCBVcGRhdGUgMDYNCj4gDQo+IFJhbmR5IFByZXN1aG4gd3JvdGU6 DQo+IA0KPiA+IGl0IHdvdWxkIGJlIHNpbXBsZXIgZm9yIGFsbCBjb25jZXJuZWQgdG8gc2ltcGx5 IHVzZQ0KPiA+IDx4cmVmIHRhcmdldD0nSS1ELmlldGYtbHRydS1yZWdpc3RyeScvPg0KPiA+IGlu IHRoZSB4bWwgc291cmNlIGFuZCBsZXQgdGhlIHRvb2xzIGRvIHRoZSBqb2IuDQo+IA0KPiBXb24n dCB3b3JrIGluIHRoZSBhYnN0cmFjdCBpZiB5b3UgYWxzbyBoYXZlICJzdHJpY3QiLg0KPiANCj4g QW5kIHdpdGhvdXQgInN0cmljdCIgYSB0eXBlPSJhYm5mIiBhcnR3b3JrIHdvbid0DQo+IHRyaWdn ZXIgdGhlIEFCTkYgY2hlY2suDQo+IA0KPiBMYXN0IHRpbWUgdGhlIHByb2JsZW0gd2FzIHVwcGVy IGNhc2UgdHlwZT0iQUJORiINCj4gdGhhdCB1bHRpbWF0ZWx5IGdvdCB1cyBhIFtEaXNjdXNzXS4N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgQnllLCBGcmFuaw0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1h aWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1073958715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1073958715==-- From ltru-bounces@ietf.org Thu Nov 17 15:22:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqGq-0002Sz-L5; Thu, 17 Nov 2005 15:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqGp-0002Sg-LK for ltru@megatron.ietf.org; Thu, 17 Nov 2005 15:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17648 for ; Thu, 17 Nov 2005 15:21:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqYS-0007Sf-4F for ltru@ietf.org; Thu, 17 Nov 2005 15:40:28 -0500 Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ecq0k-0006xz-JB for ltru@ietf.org; Thu, 17 Nov 2005 15:05:34 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 12:03:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 12:03:31 -0800 Message-ID: Thread-Topic: draft-06: change the title? Thread-Index: AcXrsft2E2l2EE0GTb2DRDW1Nl0WUA== From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Nov 2005 20:03:31.0984 (UTC) FILETIME=[FC04D100:01C5EBB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ltru] draft-06: change the title? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0495373814==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0495373814== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIGEgZ2VuZXJhbCBkaXNsaWtlIG9mIHRoZSB0aXRsZToNCg0KIk1hdGNoaW5nIG9mIFRh Z3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZiBMYW5ndWFnZXMiDQoNCkknZCBsaWtlIHRvIHN1 Z2dlc3Qgd2UgY2hhbmdlIGl0IHRvOg0KDQoiTWF0Y2hpbmcgTGFuZ3VhZ2UgVGFncyINCg0KQmVz dCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRp b24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCg== --===============0495373814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0495373814==-- From ltru-bounces@ietf.org Thu Nov 17 15:23:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIJ-0002r0-Tz; Thu, 17 Nov 2005 15:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIG-0002nM-9s for ltru@megatron.ietf.org; Thu, 17 Nov 2005 15:23:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17841 for ; Thu, 17 Nov 2005 15:23:04 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqY4-0007Ni-9j for ltru@ietf.org; Thu, 17 Nov 2005 15:40:01 -0500 Received: from irvbhxw03.quest.com ([12.106.87.70]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ecq4U-0007zz-AA for ltru@ietf.org; Thu, 17 Nov 2005 15:09:26 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 12:07:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 12:07:30 -0800 Message-ID: Thread-Topic: draft-06: move normative language where it belongs... Thread-Index: AcXrsooZ/Uz++isGQA2K9NEfCHBSoA== From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Nov 2005 20:07:31.0252 (UTC) FILETIME=[8AA23740:01C5EBB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ltru] draft-06: move normative language where it belongs... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0093250175==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0093250175== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RmluYWxseSwgSSBub3RpY2VkIHRoYXQsIGFzIGEgcmVzdWx0IG9mIG9uZSBvZiBNYXJ0aW4ncyBv ciBNYXJrJ3MgY29tbWVudHMsIHdlIGluc2VydGVkIHRoaXMgdGV4dCBpbnRvIHRoZSBJbnRyb2R1 Y3Rpb246DQoNCi0tDQpQcm90b2NvbHMgYW5kIHNwZWNpZmljYXRpb25zIFNIT1VMRCBjbGVhcmx5 IGluZGljYXRlIHRoZSBwYXJ0aWN1bGFyIG1lY2hhbmlzbSB1c2VkIGluIHNlbGVjdGluZyBvciBt YXRjaGluZyBsYW5ndWFnZSB0YWdzLg0KLS0NCg0KVGhpcyBpcyBub3JtYXRpdmUgbGFuZ3VhZ2Ug KGFuZCBpdCBvY2N1cnMgYmVmb3JlIHRoZSBpbnZvY2F0aW9uIG9mIFJGQyAyMTE5KS4gSXQgZG9l c24ndCBiZWxvbmcgaW4gdGhlIGludHJvZHVjdGlvbi4gSSBzdWdnZXN0IHdlIG1vdmUgaXQgdG8g dGhlIHN0YXJ0IG9mIFNlY3Rpb24gMyAoIlR5cGVzIG9mIE1hdGNoaW5nIikgb3IgU2VjdGlvbiAz LjEgKCJDaG9vc2luZyBUeXBlcyBvZiBNYXRjaGluZyIpLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkFk ZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlv biBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============0093250175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0093250175==-- From ltru-bounces@ietf.org Thu Nov 17 15:23:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIQ-0002sh-7O; Thu, 17 Nov 2005 15:23:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIP-0002sS-9e for ltru@megatron.ietf.org; Thu, 17 Nov 2005 15:23:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17886 for ; Thu, 17 Nov 2005 15:23:13 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqYf-0007R2-0x for ltru@ietf.org; Thu, 17 Nov 2005 15:40:39 -0500 Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ecpzm-0006xz-07 for ltru@ietf.org; Thu, 17 Nov 2005 15:04:34 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 12:02:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 12:02:37 -0800 Message-ID: Thread-Topic: draft-06 comments: choice of range Thread-Index: AcXrsdu9huuov/cGQ32M14WCsIcAmg== From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Nov 2005 20:02:38.0734 (UTC) FILETIME=[DC4782E0:01C5EBB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] draft-06 comments: choice of range X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1705031937==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1705031937== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGF2aW5nIGhhZCBhIGNoYW5jZSB0byBhY3R1YWxseSByZWFkIG15IGhhbmRpd29yayBpbiBkcmFm dC0wNiwgSSBub3RpY2UgYW4gb2J2aW91cyBhZGRpdGlvbmFsIHN0cnVjdHVyYWwgY2hhbmdlIHRv IGJlIG1hZGUuDQoNCkFjdHVhbGx5LCBJIGJlbGlldmUgTWFydGluIGFscmVhZHkgc3VnZ2VzdGVk IHRoaXMuDQoNCkkgbm90aWNlIHRoYXQgdGhlIHNlY3Rpb25zIG9uIGVhY2ggdHlwZSBvZiBsYW5n dWFnZSByYW5nZSBub3cgY29udGFpbnMgYSBsb3Qgb2YgImhhbmQgd3JpbmdpbmciIGFib3V0IHdo YXQgdXNlcnMgc2hvdWxkIGNob29zZSBvciBub3QgY2hvb3NlLiBUaGlzIHRleHQgaXMgYWN0dWFs bHkgYXBwbGljYWJsZSB0byBhbGwgdHlwZXMgb2YgcmFuZ2VzLiBUaHVzLCBpdCBzZWVtcyB0byBt ZSB0aGF0IGEgc2VjdGlvbiBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMiBvbiAiQ2hvaWNlIG9mIExh bmd1YWdlIFJhbmdlIiBpcyBhcHByb3ByaWF0ZS4NCg0KSW4gbXkgZWRpdG9yJ3MgY29weSBvZiBk cmFmdC0wNywgSSBhY3R1YWxseSBwZXJmb3JtZWQgdGhpcyBjaGFuZ2Ugc28gZm9sa3MgY291bGQg cmV2aWV3IGl0LiAoSSBhbHNvIG1hZGUgc29tZSBvdGhlciBjb3JyZWN0aW9ucyBwb2ludGVkIG91 dCBvZmYgbGlzdDogdGhlc2UgYXJlIGxpc3RlZCBpbiB0aGUgY2hhbmdlcyBzZWN0aW9uKQ0KDQpo dHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA3 LnR4dA0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1tYXRj aGluZy0wNy5odG1sDQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1s dHJ1LW1hdGNoaW5nLTA3LnhtbA0KDQpDb21tZW50cz8NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6 Ly93d3cucXVlc3QuY29tDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUu DQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============1705031937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1705031937==-- From ltru-bounces@ietf.org Thu Nov 17 15:50:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqi6-0007PU-MO; Thu, 17 Nov 2005 15:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqhn-0007Gg-Qf; Thu, 17 Nov 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19839; Thu, 17 Nov 2005 15:49:27 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqzU-0000Fw-J8; Thu, 17 Nov 2005 16:08:21 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ecqhl-0006pN-Om; Thu, 17 Nov 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 17 Nov 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-06.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: , Sender: ltru-bounces@ietf.org 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 : Matching Tags for the Identification of Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-06.txt Pages : 27 Date : 2005-11-17 This document describes different mechanisms for comparing, matching, and evaluating language tags. Possible algorithms for language negotiation and content selection are described. This document, in combination with RFC 3066bis (replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-06.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-matching-06.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-matching-06.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: <2005-11-17121136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-17121136.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Thu Nov 17 15:58:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqq9-0001C7-Ph; Thu, 17 Nov 2005 15:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqq8-0001Bx-5X for ltru@megatron.ietf.org; Thu, 17 Nov 2005 15:58:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21533 for ; Thu, 17 Nov 2005 15:58:04 -0500 (EST) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecr7p-0000wV-9D for ltru@ietf.org; Thu, 17 Nov 2005 16:16:58 -0500 Received: from spam.cs.tut.fi (unknown [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 093BAE42 for ; Thu, 17 Nov 2005 22:58:12 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 28555-09 for ; Thu, 17 Nov 2005 22:58:11 +0200 (EET) Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id B4D8DE12 for ; Thu, 17 Nov 2005 22:58:11 +0200 (EET) Date: Thu, 17 Nov 2005 22:58:11 +0200 (EET) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] draft-06: change the title? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Thu, 17 Nov 2005, Addison Phillips wrote: > I have a general dislike of the title: > > "Matching of Tags for the Identification of Languages" Because it's long, or for some other reasons? Admittedly, the word "Identification" could be misunderstood. Would "Indication" be better? > I'd like to suggest we change it to: > > "Matching Language Tags" Taken as such, it could be parsed as "(Matching Language) Tags" or as "Matching (Language Tags)". Writing "Matching of Language Tags", though perhaps not stylistically good English, would more easily be understood the right way. -- 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 Nov 17 16:20:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr8C-0003fA-6R; Thu, 17 Nov 2005 16:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr8B-0003d7-IX for ltru@megatron.ietf.org; Thu, 17 Nov 2005 16:17:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25935 for ; Thu, 17 Nov 2005 16:16:43 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcrPq-0002iD-Iy for ltru@ietf.org; Thu, 17 Nov 2005 16:35:35 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 13:16:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06: change the title? Date: Thu, 17 Nov 2005 13:16:54 -0800 Message-ID: Thread-Topic: [Ltru] draft-06: change the title? Thread-Index: AcXru6hbRBeIjPErRGyed+HMm3F5rAAAB3ag From: "Addison Phillips" To: "Jukka K. Korpela" , X-OriginalArrivalTime: 17 Nov 2005 21:16:53.0159 (UTC) FILETIME=[3B52D370:01C5EBBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2018296078==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2018296078== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBkb24ndCBsaWtlIGl0IG5vdCBqdXN0IGZvciBsZW5ndGggcmVhc29ucywgYnV0IGJlY2F1c2Ug aXQgaXMgaW5lbGVnYW50LiBObyBvbmUgYWN0dWFsbHkgY2FsbHMgdGhlc2UgbGFuZ3VhZ2UgdGFn cyAidGFncyBmb3IgdGhlIGlkZW50aWZpY2F0aW9uIG9mIGxhbmd1YWdlcyIgaW4gcmVhbCBsaWZl Lg0KDQpJIGFncmVlIHRoYXQgaXQgc2hvdWxkIGJlICJNYXRjaGluZyBvZiBMYW5ndWFnZSBUYWdz IiBvciwgcGVyaGFwcywgIkxhbmd1YWdlIFRhZyBNYXRjaGluZyIuDQoNCkFkZGlzb24NCg0KQWRk aXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJl DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNo aXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IEp1a2thIEsuIEtvcnBlbGENCj4gU2VudDogMjAwNeW5tDEx5pyIMTfml6UgMTI6NTgN Cj4gVG86IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBkcmFmdC0wNjogY2hh bmdlIHRoZSB0aXRsZT8NCj4gDQo+IE9uIFRodSwgMTcgTm92IDIwMDUsIEFkZGlzb24gUGhpbGxp cHMgd3JvdGU6DQo+IA0KPiA+IEkgaGF2ZSBhIGdlbmVyYWwgZGlzbGlrZSBvZiB0aGUgdGl0bGU6 DQo+ID4NCj4gPiAiTWF0Y2hpbmcgb2YgVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mIExh bmd1YWdlcyINCj4gDQo+IEJlY2F1c2UgaXQncyBsb25nLCBvciBmb3Igc29tZSBvdGhlciByZWFz b25zPyBBZG1pdHRlZGx5LA0KPiB0aGUgd29yZCAiSWRlbnRpZmljYXRpb24iIGNvdWxkIGJlIG1p c3VuZGVyc3Rvb2QuDQo+IFdvdWxkICJJbmRpY2F0aW9uIiBiZSBiZXR0ZXI/DQo+IA0KPiA+IEkn ZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgY2hhbmdlIGl0IHRvOg0KPiA+DQo+ID4gIk1hdGNoaW5nIExh bmd1YWdlIFRhZ3MiDQo+IA0KPiBUYWtlbiBhcyBzdWNoLCBpdCBjb3VsZCBiZSBwYXJzZWQgYXMg IihNYXRjaGluZyBMYW5ndWFnZSkgVGFncyINCj4gb3IgYXMgIk1hdGNoaW5nIChMYW5ndWFnZSBU YWdzKSIuIFdyaXRpbmcgIk1hdGNoaW5nIG9mIExhbmd1YWdlIFRhZ3MiLA0KPiB0aG91Z2ggcGVy aGFwcyBub3Qgc3R5bGlzdGljYWxseSBnb29kIEVuZ2xpc2gsIHdvdWxkIG1vcmUgZWFzaWx5DQo+ IGJlIHVuZGVyc3Rvb2QgdGhlIHJpZ2h0IHdheS4NCj4gDQo+IC0tDQo+IEp1a2thICJZdWNjYSIg S29ycGVsYSwgaHR0cDovL3d3dy5jcy50dXQuZmkvfmprb3JwZWxhLw0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGlu ZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydQ0K --===============2018296078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2018296078==-- From ltru-bounces@ietf.org Thu Nov 17 17:01:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecroa-0004rs-0H; Thu, 17 Nov 2005 17:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcroX-0004rf-J2 for ltru@megatron.ietf.org; Thu, 17 Nov 2005 17:01:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28848 for ; Thu, 17 Nov 2005 17:00:30 -0500 (EST) From: Karen_Broome@spe.sony.com Received: from mail-haw.bigfish.com ([12.129.199.61] helo=mail70-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecs6D-0004LP-79 for ltru@ietf.org; Thu, 17 Nov 2005 17:19:23 -0500 Received: from mail70-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail70-haw-R.bigfish.com (Postfix) with ESMTP id 67E7F23B8D6; Thu, 17 Nov 2005 22:00:45 +0000 (UTC) X-BigFish: VP Received: by mail70-haw (MessageSwitch) id 1132264845338430_2995; Thu, 17 Nov 2005 22:00:45 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail70-haw.bigfish.com (Postfix) with ESMTP id 3E79C23A45B; Thu, 17 Nov 2005 22:00:45 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005111714104757:182423 ; Thu, 17 Nov 2005 14:10:47 -0800 To: "Addison Phillips" Subject: RE: [Ltru] draft-06: change the title? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.13 March 9, 2004 Message-ID: Date: Thu, 17 Nov 2005 14:00:30 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 11/17/2005 14:00:31, Serialize complete at 11/17/2005 14:00:31, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/17/2005 02:10:47 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 11/17/2005 02:10:47 PM, Serialize complete at 11/17/2005 02:10:47 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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="===============1974021232==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1974021232== Content-Type: multipart/alternative; boundary="=_alternative 0078EA9F882570BC_=" This is a multipart message in MIME format. --=_alternative 0078EA9F882570BC_= Content-Type: text/plain; charset="iso-2022-jp" Language Tag Matching and Filtering Algorithms? Matching and Filtering Language Tags? Matching and Filtering Language Tag Structures? FWIW... Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Addison Phillips" Sent by: ltru-bounces@ietf.org 11/17/2005 01:16 PM To: "Jukka K. Korpela" , cc: Subject: RE: [Ltru] draft-06: change the title? I don't like it not just for length reasons, but because it is inelegant. No one actually calls these language tags "tags for the identification of languages" in real life. I agree that it should be "Matching of Language Tags" or, perhaps, "Language Tag Matching". Addison Addison P. Phillips Globalization Architect, Quest Software Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Jukka K. Korpela > Sent: 2005$BG/(B11$B7n(B17$BF|(B 12:58 > To: ltru@ietf.org > Subject: Re: [Ltru] draft-06: change the title? > > On Thu, 17 Nov 2005, Addison Phillips wrote: > > > I have a general dislike of the title: > > > > "Matching of Tags for the Identification of Languages" > > Because it's long, or for some other reasons? Admittedly, > the word "Identification" could be misunderstood. > Would "Indication" be better? > > > I'd like to suggest we change it to: > > > > "Matching Language Tags" > > Taken as such, it could be parsed as "(Matching Language) Tags" > or as "Matching (Language Tags)". Writing "Matching of Language Tags", > though perhaps not stylistically good English, would more easily > be understood the right way. > > -- > 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 --=_alternative 0078EA9F882570BC_= Content-Type: text/html; charset="iso-2022-jp"
Language Tag Matching and Filtering Algorithms?
Matching and Filtering Language Tags?
Matching and Filtering Language Tag Structures?

FWIW...

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384




"Addison Phillips" <addison.phillips@quest.com>
Sent by: ltru-bounces@ietf.org

11/17/2005 01:16 PM

       
        To:        "Jukka K. Korpela" <jkorpela@cs.tut.fi>, <ltru@ietf.org>
        cc:        
        Subject:        RE: [Ltru] draft-06: change the title?



I don't like it not just for length reasons, but because it is inelegant. No one actually calls these language tags "tags for the identification of languages" in real life.

I agree that it should be "Matching of Language Tags" or, perhaps, "Language Tag Matching".

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of
> Jukka K. Korpela
> Sent: 2005$BG/(B11$B7n(B17$BF|(B 12:58
> To: ltru@ietf.org
> Subject: Re: [Ltru] draft-06: change the title?
>
> On Thu, 17 Nov 2005, Addison Phillips wrote:
>
> > I have a general dislike of the title:
> >
> > "Matching of Tags for the Identification of Languages"
>
> Because it's long, or for some other reasons? Admittedly,
> the word "Identification" could be misunderstood.
> Would "Indication" be better?
>
> > I'd like to suggest we change it to:
> >
> > "Matching Language Tags"
>
> Taken as such, it could be parsed as "(Matching Language) Tags"
> or as "Matching (Language Tags)". Writing "Matching of Language Tags",
> though perhaps not stylistically good English, would more easily
> be understood the right way.
>
> --
> 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

--=_alternative 0078EA9F882570BC_=-- --===============1974021232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1974021232==-- From ltru-bounces@ietf.org Thu Nov 17 17:05:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcrtB-0005iv-G9; Thu, 17 Nov 2005 17:05:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecrt9-0005ik-An; Thu, 17 Nov 2005 17:05:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29146; Thu, 17 Nov 2005 17:05:17 -0500 (EST) Received: from gate5-sandiego.nmci.navy.mil ([138.163.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcsAq-0004Xw-L6; Thu, 17 Nov 2005 17:24:10 -0500 Received: from nawesdnims04.nmci.navy.mil by Gate5-sandiego.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 17 Nov 2005 22:05:48 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by nawesdnieb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Thu, 17 Nov 2005 14:04:48 -0800 Received: from nawesdnieg04.nadsuswe.nads.navy.mil ([10.0.10.59]) by nawesdnieb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Nov 2005 12:58:27 -0800 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by nawesdnieg04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Nov 2005 12:56:42 -0800 Received: from Nawesdnims02.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.59]) with ESMTP; Thu, 17 Nov 2005 20:55:51 +0000 Received: from nawesdnifw04c.nmci.navy.mil (nawesdnifw04c.nmci.navy.mil [10.0.0.164]) by nawesdnims02.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAHKauK07719 for ; Thu, 17 Nov 2005 20:36:56 GMT Received: from [138.163.0.138] by nawesdnifw04c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Thu, 17 Nov 2005 20:55:50 +0000 Received: from mx2.spawar.navy.mil (128.49.251.7) by navysdniio02.nmci.navy.mil with ESMTP; 17 Nov 2005 12:33:47 -0800 X-DMDS: TRUE X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx2.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id jAHKsf53029146 for ; Thu, 17 Nov 2005 12:54:43 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqi1-0007L3-A5; Thu, 17 Nov 2005 15:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqhn-0007Gg-Qf; Thu, 17 Nov 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19839; Thu, 17 Nov 2005 15:49:27 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqzU-0000Fw-J8; Thu, 17 Nov 2005 16:08:21 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ecqhl-0006pN-Om; Thu, 17 Nov 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 17 Nov 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.592, required 3.3, BAYES_00 -2.60, MIME_BOUND_NEXTPART 0.00, NO_REAL_NAME 0.01) X-OriginalArrivalTime: 17 Nov 2005 20:56:43.0213 (UTC) FILETIME=[6A23B7D0:01C5EBB9] X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-06.txt X-BeenThere: ltru@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org 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 : Matching Tags for the Identification of Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-06.txt Pages : 27 Date : 2005-11-17 This document describes different mechanisms for comparing, matching, and evaluating language tags. Possible algorithms for language negotiation and content selection are described. This document, in combination with RFC 3066bis (replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-06.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-matching-06.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-matching-06.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: <2005-11-17121136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-17121136.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Thu Nov 17 18:07:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsqf-0000HI-FV; Thu, 17 Nov 2005 18:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsqe-0000HA-C8 for ltru@megatron.ietf.org; Thu, 17 Nov 2005 18:07:20 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03115 for ; Thu, 17 Nov 2005 18:06:45 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ecsoh-0004XM-4V for ltru@lists.ietf.org; Fri, 18 Nov 2005 00:05:19 +0100 Received: from c-180-160-80.hh.dial.de.ignite.net ([62.180.160.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2005 00:05:18 +0100 Received: from nobody by c-180-160-80.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2005 00:05:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Nov 2005 23:54:28 +0100 Organization: Lines: 8 Message-ID: <437D0A24.36BF@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: c-180-160-80.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: draft-06: change the title? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > it should be "Matching of Language Tags" or, perhaps, > "Language Tag Matching". Both fine. I'd stay away from "and Filtering". Bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 17 18:12:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsve-0000fO-CP; Thu, 17 Nov 2005 18:12:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsvc-0000eE-TU for ltru@megatron.ietf.org; Thu, 17 Nov 2005 18:12:29 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03361 for ; Thu, 17 Nov 2005 18:11:53 -0500 (EST) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EcsuH-0006vr-8f for ltru@lists.ietf.org; Fri, 18 Nov 2005 00:11:05 +0100 Received: from c-180-160-80.hh.dial.de.ignite.net ([62.180.160.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2005 00:11:05 +0100 Received: from nobody by c-180-160-80.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2005 00:11:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 18 Nov 2005 00:01:55 +0100 Organization: Lines: 11 Message-ID: <437D0BE3.2A@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: c-180-160-80.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] -07 (was: draft-06 comments: choice of range) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > In my editor's copy of draft-07 Argh... you're not supposed to change the text before the previous version is officially announced... ;-) Okay, -07 it is, -06 lived on my hard disk for less than 12 hours. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 01:03:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczLP-0007cH-DM; Fri, 18 Nov 2005 01:03:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczLO-0007c2-7x for ltru@megatron.ietf.org; Fri, 18 Nov 2005 01:03:30 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23920 for ; Fri, 18 Nov 2005 01:02:55 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051118060258.QGUP15290.mta11.adelphia.net@DGBP7M81> for ; Fri, 18 Nov 2005 01:02:58 -0500 Message-ID: <008601c5ec06$022bc8f0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20051117230710.BOXQ2552.edge2.adelphia.net@megatron.ietf.org> Date: Thu, 17 Nov 2005 22:04:59 -0800 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: draft-06: change the title? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org What about something like "Matching Considerations for Language Tags"? Probably not the best possible title, but maybe a step in the right direction. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 05:33:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3YW-00030u-NO; Fri, 18 Nov 2005 05:33:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3YV-00030d-AU for ltru@megatron.ietf.org; Fri, 18 Nov 2005 05:33:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07666 for ; Fri, 18 Nov 2005 05:32:43 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3qI-0002MB-MZ for ltru@ietf.org; Fri, 18 Nov 2005 05:51:43 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAIAWmd21779 for ; Fri, 18 Nov 2005 19:32:48 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 57f8_aa1552be_581e_11da_8580_00304811fd80; Fri, 18 Nov 2005 19:32:48 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAIAVKJl008769 for ; Fri, 18 Nov 2005 19:32:23 +0900 Message-Id: <6.0.0.20.2.20051118165823.079bb060@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Nov 2005 17:11:04 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching: make sure subtags are explained X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [chair hat off] (Re)Reading the matching draft, I find myself unsure about what each tag or subtag in an example means. A typical example is the following, from 3.2.3: >>>> ... For example, depending on the domain, an implemenation might give a small distance to the difference between the language subtag 'no' and the closely related language subtags 'nb' or 'nn'; or between the script subtags 'Kata' and 'Hira'; or between the region subtags 'US' and 'UM'. <<<< By chance, I know all the above subtags except 'UM'. Reading the draft, I have no intention to look these up. My guess is that maybe except for 'US', many readers easily won't know any of these tags. It seems that the text would be a lot more readable (because the examples are a lot more self-explaining) if we change this to something like >>>> ... For example, depending on the domain, an implemenation might give a small distance to the difference between the language subtag 'no' (Norvegian) and the closely related language subtags 'nb' (Norvegian, Bookmal) or 'nn' (Norvegian, Newnorsk); or between the script subtags 'Kata' (Katakana) and 'Hira' (Hiragana); or between the region subtags 'US' (USA) and 'UM' (???). <<<< Do we have a general policy for how to handle such cases? For example, there may be examples that are really just only about the mechanics of the tags, and others (like above) where the meaning of the tag is quite relevant to understand the example. Regards, Martin. [I'm not sure we have done this persistently in the registry draft, but for that it is too late now, anyway.] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 05:33:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3YW-00031I-SJ; Fri, 18 Nov 2005 05:33:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3YV-00030e-AS for ltru@megatron.ietf.org; Fri, 18 Nov 2005 05:33:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07667 for ; Fri, 18 Nov 2005 05:32:43 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3qI-0002MF-NA for ltru@ietf.org; Fri, 18 Nov 2005 05:51:43 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAIAWYd21768; Fri, 18 Nov 2005 19:32:34 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 5722_a18b8cb2_581e_11da_9255_00304811fd80; Fri, 18 Nov 2005 19:32:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAIAVKJh008769; Fri, 18 Nov 2005 19:31:59 +0900 Message-Id: <6.0.0.20.2.20051118164642.06f38960@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Nov 2005 16:47:56 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: draft-06: change the title? In-Reply-To: <437D0A24.36BF@xyzzy.claranet.de> References: <437D0A24.36BF@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [as a technical (or stylistical, in this case :-) contributor] At 07:54 05/11/18, Frank Ellermann wrote: >Addison Phillips wrote: > >> it should be "Matching of Language Tags" or, perhaps, >> "Language Tag Matching". > >Both fine. +1 >I'd stay away from "and Filtering". Bye I agree, because the current terminology uses 'matching' as a general term that subsumes 'filtering' and 'lookup'. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 05:33:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3Yb-000324-2q; Fri, 18 Nov 2005 05:33:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3Ya-00031w-1D for ltru@megatron.ietf.org; Fri, 18 Nov 2005 05:33:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07674 for ; Fri, 18 Nov 2005 05:32:49 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3qO-0002MW-VW for ltru@ietf.org; Fri, 18 Nov 2005 05:51:49 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAIAX9d21795; Fri, 18 Nov 2005 19:33:09 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 5763_b060c928_581e_11da_93a8_00304811fd80; Fri, 18 Nov 2005 19:33:09 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAIAVKJn008769; Fri, 18 Nov 2005 19:32:34 +0900 Message-Id: <6.0.0.20.2.20051118171142.06f35250@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Nov 2005 17:14:03 +0900 To: "Addison Phillips" , "Frank Ellermann" , From: Martin Duerst Subject: RE: [Ltru] Need more interesting distance metric (?) (was:Matching:choice of schemes) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [chair hat off] If we have a good idea of what 'distance metric' is useful for, we should clearly indicate that. If we can explain what the specific values are good for, we should also explain that, because it will help implementers choose other values if they need something different. But if this thing gets too complicated, or too imprecise, we should also seriously consider dropping it. Regards, Martin. At 01:44 05/11/18, Addison Phillips wrote: >Content-class: urn:content-classes:message >Content-Type: text/plain;charset="UTF-8" > >There were (he says, racking his brains to remember) a couple of reasons >for increasing the distances in the metric: > >1. It allows for better custom tailoring (by creating the possibility for >half-scores and the like). The theorized use of "q" weights in a language >priority list to multiply the values works better with larger gaps between >the values, at least on paper. > >2. It helps deal with the fact that variants can have more than one subtag. >You need four matching variant subtags to equal one region subtag. > >But otherwise I don't really recall why the numbers were increased. My >implementation isn't done, so I haven't had a chance to play with it much >in depth. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > >> -----Original Message----- >> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >> Frank Ellermann >> Sent: 2005$Bj;%((B11$Bk|/(B7$Bkw!&(B 5:25 >> To: ltru@ietf.org >> Subject: [Ltru] Need more interesting distance metric (?) (was: >> Matching:choice of schemes) >> >> Harald Tveit Alvestrand wrote: >> >> > I'll comment on -06 after publication. >> >> Something with the "distance metric" is odd. It was 8-4-2-1. >> That was the minimal metric having precisely the same effect >> as LTR (letf-to-right). >> >> Now it's 256-128-32-4-1. Beats me where that could be >> different from 16-8-4-2-1, which would be again the same as >> LTR, only over 5 positions. >> >> For some interesting effect - plus a still missing example to >> explain it - we need w1-w2-w3-w4-w5 with a pair w(i)-w(i+1) >> where w(i) < 2*w(i+1). With 2*w(i+1) <= w(i) everywhere it's >> always the same as LTR matching, or do I miss something ? >> >> Bye, Frank >> >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 05:33:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3Yu-00033p-BO; Fri, 18 Nov 2005 05:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3Ys-00033e-T4 for ltru@megatron.ietf.org; Fri, 18 Nov 2005 05:33:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07686 for ; Fri, 18 Nov 2005 05:33:08 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3qg-0002Mx-Po for ltru@ietf.org; Fri, 18 Nov 2005 05:52:08 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAIAXTu25592; Fri, 18 Nov 2005 19:33:29 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 57f8_c27f165a_581e_11da_8580_00304811fd80; Fri, 18 Nov 2005 19:33:28 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAIAVKJr008769; Fri, 18 Nov 2005 19:33:04 +0900 Message-Id: <6.0.0.20.2.20051118171946.06f429b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Nov 2005 17:20:09 +0900 To: "Addison Phillips" , From: Martin Duerst Subject: Re: [Ltru] draft-06: move normative language where it belongs... In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [chair hat off] At 05:07 05/11/18, Addison Phillips wrote: >Finally, I noticed that, as a result of one of Martin's or Mark's comments, >we inserted this text into the Introduction: > >-- >Protocols and specifications SHOULD clearly indicate the particular >mechanism used in selecting or matching language tags. >-- > >This is normative language (and it occurs before the invocation of RFC >2119). It doesn't belong in the introduction. I suggest we move it to the >start of Section 3 ("Types of Matching") or Section 3.1 ("Choosing Types of >Matching"). Fine with me. >Best Regards, > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Internationalization is not a feature. >It is an architecture. > >_______________________________________________ >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 Nov 18 11:40:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9HM-0007xp-NC; Fri, 18 Nov 2005 11:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9HK-0007lZ-LM for ltru@megatron.ietf.org; Fri, 18 Nov 2005 11:39:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27748 for ; Fri, 18 Nov 2005 11:39:23 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9ZC-0005ls-Lf for ltru@ietf.org; Fri, 18 Nov 2005 11:58:26 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 08:39:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Matching: make sure subtags are explained Date: Fri, 18 Nov 2005 08:39:37 -0800 Message-ID: Thread-Topic: [Ltru] Matching: make sure subtags are explained Thread-Index: AcXsK7yM6IZqw8UXRDmPsyAzPnq7xgAMqqlw From: "Addison Phillips" To: "Martin Duerst" , "LTRU Working Group" X-OriginalArrivalTime: 18 Nov 2005 16:39:39.0389 (UTC) FILETIME=[AB3CB2D0:01C5EC5E] 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: , Content-Type: multipart/mixed; boundary="===============0163149946==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0163149946== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSBhbmQgd2lsbCBtYWtlIHRoZSBtb2RpZmljYXRpb25zIHRvIHRoZSBtYXRjaGluZyBk cmFmdC4gVU0sIGJ5IHRoZSB3YXksIGlzICJVbml0ZWQgU3RhdGVzIE1pbm9yIE91dGx5aW5nIElz bGFuZHMiIHJlZ2lvbi4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTWFydGluIER1ZXJzdA0KPiBT ZW50OiAyMDA15bm0MTHmnIgxOOaXpSAwOjExDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4g U3ViamVjdDogW0x0cnVdIE1hdGNoaW5nOiBtYWtlIHN1cmUgc3VidGFncyBhcmUgZXhwbGFpbmVk DQo+IA0KPiBbY2hhaXIgaGF0IG9mZl0NCj4gDQo+IChSZSlSZWFkaW5nIHRoZSBtYXRjaGluZyBk cmFmdCwgSSBmaW5kIG15c2VsZiB1bnN1cmUNCj4gYWJvdXQgd2hhdCBlYWNoIHRhZyBvciBzdWJ0 YWcgaW4gYW4gZXhhbXBsZSBtZWFucy4NCj4gDQo+IEEgdHlwaWNhbCBleGFtcGxlIGlzIHRoZSBm b2xsb3dpbmcsIGZyb20gMy4yLjM6DQo+IA0KPiAgPj4+Pg0KPiAgICAgLi4uIEZvciBleGFtcGxl LCBkZXBlbmRpbmcgb24gdGhlIGRvbWFpbiwgYW4gaW1wbGVtZW5hdGlvbg0KPiAgICAgbWlnaHQg Z2l2ZSBhIHNtYWxsIGRpc3RhbmNlIHRvIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGxhbmd1 YWdlDQo+ICAgICBzdWJ0YWcgJ25vJyBhbmQgdGhlIGNsb3NlbHkgcmVsYXRlZCBsYW5ndWFnZSBz dWJ0YWdzICduYicgb3IgJ25uJzsgb3INCj4gICAgIGJldHdlZW4gdGhlIHNjcmlwdCBzdWJ0YWdz ICdLYXRhJyBhbmQgJ0hpcmEnOyBvciBiZXR3ZWVuIHRoZSByZWdpb24NCj4gICAgIHN1YnRhZ3Mg J1VTJyBhbmQgJ1VNJy4NCj4gPDw8PA0KPiANCj4gQnkgY2hhbmNlLCBJIGtub3cgYWxsIHRoZSBh Ym92ZSBzdWJ0YWdzIGV4Y2VwdCAnVU0nLg0KPiBSZWFkaW5nIHRoZSBkcmFmdCwgSSBoYXZlIG5v IGludGVudGlvbiB0byBsb29rIHRoZXNlDQo+IHVwLiBNeSBndWVzcyBpcyB0aGF0IG1heWJlIGV4 Y2VwdCBmb3IgJ1VTJywgbWFueSByZWFkZXJzDQo+IGVhc2lseSB3b24ndCBrbm93IGFueSBvZiB0 aGVzZSB0YWdzLiBJdCBzZWVtcyB0aGF0IHRoZQ0KPiB0ZXh0IHdvdWxkIGJlIGEgbG90IG1vcmUg cmVhZGFibGUgKGJlY2F1c2UgdGhlIGV4YW1wbGVzDQo+IGFyZSBhIGxvdCBtb3JlIHNlbGYtZXhw bGFpbmluZykgaWYgd2UgY2hhbmdlIHRoaXMNCj4gdG8gc29tZXRoaW5nIGxpa2UNCj4gDQo+ICA+ Pj4+DQo+ICAgICAuLi4gRm9yIGV4YW1wbGUsIGRlcGVuZGluZyBvbiB0aGUgZG9tYWluLCBhbiBp bXBsZW1lbmF0aW9uDQo+ICAgICBtaWdodCBnaXZlIGEgc21hbGwgZGlzdGFuY2UgdG8gdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UNCj4gICAgIHN1YnRhZyAnbm8nIChOb3J2ZWdp YW4pIGFuZCB0aGUgY2xvc2VseSByZWxhdGVkIGxhbmd1YWdlIHN1YnRhZ3MNCj4gICAgICduYicg KE5vcnZlZ2lhbiwgQm9va21hbCkgb3IgJ25uJyAoTm9ydmVnaWFuLCBOZXdub3Jzayk7IG9yDQo+ ICAgICBiZXR3ZWVuIHRoZSBzY3JpcHQgc3VidGFncyAnS2F0YScgKEthdGFrYW5hKSBhbmQgJ0hp cmEnIChIaXJhZ2FuYSk7DQo+ICAgICBvciBiZXR3ZWVuIHRoZSByZWdpb24gc3VidGFncyAnVVMn IChVU0EpIGFuZCAnVU0nICg/Pz8pLg0KPiA8PDw8DQo+IA0KPiBEbyB3ZSBoYXZlIGEgZ2VuZXJh bCBwb2xpY3kgZm9yIGhvdyB0byBoYW5kbGUgc3VjaCBjYXNlcz8NCj4gRm9yIGV4YW1wbGUsIHRo ZXJlIG1heSBiZSBleGFtcGxlcyB0aGF0IGFyZSByZWFsbHkganVzdA0KPiBvbmx5IGFib3V0IHRo ZSBtZWNoYW5pY3Mgb2YgdGhlIHRhZ3MsIGFuZCBvdGhlcnMgKGxpa2UNCj4gYWJvdmUpIHdoZXJl IHRoZSBtZWFuaW5nIG9mIHRoZSB0YWcgaXMgcXVpdGUgcmVsZXZhbnQgdG8NCj4gdW5kZXJzdGFu ZCB0aGUgZXhhbXBsZS4NCj4gDQo+IFJlZ2FyZHMsICAgIE1hcnRpbi4NCj4gDQo+IFtJJ20gbm90 IHN1cmUgd2UgaGF2ZSBkb25lIHRoaXMgcGVyc2lzdGVudGx5IGluIHRoZQ0KPiByZWdpc3RyeSBk cmFmdCwgYnV0IGZvciB0aGF0IGl0IGlzIHRvbyBsYXRlIG5vdywgYW55d2F5Ll0NCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1 IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============0163149946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0163149946==-- From ltru-bounces@ietf.org Fri Nov 18 12:21:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9kY-0004mD-7X; Fri, 18 Nov 2005 12:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9kU-0004I5-4H for ltru@megatron.ietf.org; Fri, 18 Nov 2005 12:10:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29540 for ; Fri, 18 Nov 2005 12:09:27 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdA2I-0006dh-Ks for ltru@ietf.org; Fri, 18 Nov 2005 12:28:30 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 09:09:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Need more interesting distance metric (?) (was:Matching:choice of schemes) Date: Fri, 18 Nov 2005 09:09:41 -0800 Message-ID: Thread-Topic: [Ltru] Need more interesting distance metric (?) (was:Matching:choice of schemes) Thread-Index: AcXsK36q/tP5Ga4BQXKqVi2ph0epMwANS0Aw From: "Addison Phillips" To: "Martin Duerst" , "Frank Ellermann" , X-OriginalArrivalTime: 18 Nov 2005 17:09:48.0479 (UTC) FILETIME=[E189ECF0:01C5EC62] 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: , Content-Type: multipart/mixed; boundary="===============1303126341==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1303126341== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBJZiB3ZSBoYXZlIGEgZ29vZCBpZGVhIG9mIHdoYXQgJ2Rpc3RhbmNlIG1ldHJpYycgaXMgdXNl ZnVsIGZvciwNCj4gd2Ugc2hvdWxkIGNsZWFybHkgaW5kaWNhdGUgdGhhdC4NCg0KSSBxdW90ZSBk cmFmdC0wNiwgU2VjdGlvbiAzLjE6DQoNCi0tDQojIFNjb3JlZCBGaWx0ZXJpbmcgKERpc3RhbmNl IE1ldHJpYyBGaWx0ZXJpbmcpIHByb2R1Y2VzIGFuIG9yZGVyZWQgc2V0IG9mIGNvbnRlbnQgdXNp bmcgZWl0aGVyIGJhc2ljIG9yIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlcy4gSXQgc2hvdWxkIGJl IHVzZWQgd2hlbiB0aGUgcXVhbGl0eSBvZiB0aGUgbWF0Y2ggd2l0aGluIGEgc3BlY2lmaWMgbGFu Z3VhZ2UgcmFuZ2UgaXMgaW1wb3J0YW50LCBhcyB3aGVuIHByZXNlbnRpbmcgYSBsaXN0IG9mIGRv Y3VtZW50cyByZXN1bHRpbmcgZnJvbSBhIHNlYXJjaC4NCi0tDQoNCkFuZCB0aGVuIFNlY3Rpb24g My4yLjM6DQoNCi0tDQpCb3RoIGJhc2ljIGFuZCBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBmaWx0 ZXJpbmcgcHJvZHVjZSBzaW1wbGUgYm9vbGVhbiBtYXRjaGVzLiBTb21ldGltZXMgaXQgbWF5IGJl IGJlbmVmaWNpYWwgdG8gcHJvdmlkZSBhbiBhcnJheSBvZiByZXN1bHRzIHdpdGggZGlmZmVyZW50 IGxldmVscyBvZiBtYXRjaGluZywgZm9yIGV4YW1wbGUsIHNvcnRpbmcgcmVzdWx0cyBiYXNlZCBv biB0aGUgb3ZlcmFsbCAicXVhbGl0eSIgb2YgdGhlIG1hdGNoLiBEaXN0YW5jZSBtZXRyaWMgZmls dGVyaW5nIHByb3ZpZGVzIGEgd2F5IHRvIGdlbmVyYXRlIHRoZXNlIHF1YWxpdHkgdmFsdWVzLg0K LS0NCg0KSSB0aGluayB0aGF0IHByZXR0eSBjbGVhcmx5IGluZGljYXRlcyB3aGF0IGEgZGlzdGFu Y2UgbWV0cmljIGlzIHVzZWZ1bCBmb3IuDQoNCj4gSWYgd2UgY2FuIGV4cGxhaW4gd2hhdCB0aGUN Cj4gc3BlY2lmaWMgdmFsdWVzIGFyZSBnb29kIGZvciwgd2Ugc2hvdWxkIGFsc28gZXhwbGFpbiB0 aGF0LA0KPiBiZWNhdXNlIGl0IHdpbGwgaGVscCBpbXBsZW1lbnRlcnMgY2hvb3NlIG90aGVyIHZh bHVlcyBpZg0KPiB0aGV5IG5lZWQgc29tZXRoaW5nIGRpZmZlcmVudC4NCg0KSSBhZ3JlZS4gSSBu b3RlIHRoYXQgbXVsdGlwbHlpbmcgdGhlIHNjb3JlcyBieSAicSIgKHF1YWxpdHkpIHdlaWdodHMg Y2FuIHByb2R1Y2UgaW50ZXJsZWF2ZWQgbGlzdHMgd2hlbiB3b3JraW5nIHdpdGggYSBsYW5ndWFn ZSBwcmlvcml0eSBsaXN0IChsaWtlIEFjY2VwdC1MYW5ndWFnZSkuDQoNCj4gQnV0IGlmIHRoaXMg dGhpbmcgZ2V0cyB0b28gY29tcGxpY2F0ZWQsIG9yIHRvbyBpbXByZWNpc2UsDQo+IHdlIHNob3Vs ZCBhbHNvIHNlcmlvdXNseSBjb25zaWRlciBkcm9wcGluZyBpdC4NCg0KUGVyaGFwcywgYWx0aG91 Z2ggd2UgY291bGQgZ28gdGhlIHJvdXRlIG9mIGJlaW5nIGxlc3Mgc3BlY2lmaWMgYWJvdXQgdGhl IHdlaWdodHMgYW5kIGp1c3QgZGVzY3JpYmluZyB0aGUgc2NoZW1lIGdlbmVyYWxseS4gSSB0ZW5k IHRvIGZhdm9yIHdoYXQgd2UndmUgZG9uZSwgdGhvdWdoLiBJJ2xsIHNlZSBpZiBJIGhhdmUgdGlt ZSB0byBmaW5pc2ggb2ZmIG15IGxpdHRsZSBpbXBsZW1lbnRhdGlvbiB0b2RheSBhbmQgcHV0IGEg ZGVtbyBvbiBteSB3ZWJzaXRlLiBUaGF0IHNob3VsZCBoZWxwIHVzIG1ha2UgYmV0dGVyIGRlY2lz aW9ucy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogTWFydGluIER1ZXJzdCBbbWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEu YWMuanBdDQo+IFNlbnQ6IDIwMDXlubQxMeaciDE45pelIDA6MTQNCj4gVG86IEFkZGlzb24gUGhp bGxpcHM7IEZyYW5rIEVsbGVybWFubjsgbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0x0 cnVdIE5lZWQgbW9yZSBpbnRlcmVzdGluZyBkaXN0YW5jZSBtZXRyaWMgKD8pDQo+ICh3YXM6TWF0 Y2hpbmc6Y2hvaWNlIG9mIHNjaGVtZXMpDQo+IA0KPiBbY2hhaXIgaGF0IG9mZl0NCj4gDQo+IElm IHdlIGhhdmUgYSBnb29kIGlkZWEgb2Ygd2hhdCAnZGlzdGFuY2UgbWV0cmljJyBpcyB1c2VmdWwg Zm9yLA0KPiB3ZSBzaG91bGQgY2xlYXJseSBpbmRpY2F0ZSB0aGF0LiBJZiB3ZSBjYW4gZXhwbGFp biB3aGF0IHRoZQ0KPiBzcGVjaWZpYyB2YWx1ZXMgYXJlIGdvb2QgZm9yLCB3ZSBzaG91bGQgYWxz byBleHBsYWluIHRoYXQsDQo+IGJlY2F1c2UgaXQgd2lsbCBoZWxwIGltcGxlbWVudGVycyBjaG9v c2Ugb3RoZXIgdmFsdWVzIGlmDQo+IHRoZXkgbmVlZCBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPiAN Cj4gQnV0IGlmIHRoaXMgdGhpbmcgZ2V0cyB0b28gY29tcGxpY2F0ZWQsIG9yIHRvbyBpbXByZWNp c2UsDQo+IHdlIHNob3VsZCBhbHNvIHNlcmlvdXNseSBjb25zaWRlciBkcm9wcGluZyBpdC4NCj4g DQo+IFJlZ2FyZHMsICAgIE1hcnRpbi4NCj4gDQo= --===============1303126341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1303126341==-- From ltru-bounces@ietf.org Fri Nov 18 13:15:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAlo-0001PA-Lb; Fri, 18 Nov 2005 13:15:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAln-0001Gg-0U for ltru@megatron.ietf.org; Fri, 18 Nov 2005 13:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02659 for ; Fri, 18 Nov 2005 13:14:55 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdB3f-0008B8-M5 for ltru@ietf.org; Fri, 18 Nov 2005 13:34:00 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIIFIJC011117 for ; Fri, 18 Nov 2005 13:15:18 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIIFIXn094718 for ; Fri, 18 Nov 2005 13:15:18 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAIIFIbG029005 for ; Fri, 18 Nov 2005 13:15:18 -0500 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAIIFHGx028875; Fri, 18 Nov 2005 13:15:18 -0500 Message-ID: <437E1A33.7010904@icu-project.org> Date: Fri, 18 Nov 2005 10:15:15 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] draft-06 comments: choice of range References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org A field not present in the middle of an extended language range MAY be treated as if the field contained a "*". For example, the range "en-US" MAY be considered to be equivalent to the range "en-*-US". This also means that multiple wildcards can be collapsed (so that "en-*-*-US" is equivalent to "en-*-US"). => A field not present in the middle of an extended language range MAY be treated as if the field contained a "*". For example, the range "en-US" MAY be considered to be equivalent to the range "en-*-US". When this is done, multiple wildcards can be collapsed (so that "en-*-*-US" is equivalent to "en-*-US"). [The "this also means" only applies when the implemenation does the MAY.] ---- measurment [spell-check] ---- [General Observation. We need to give a mechanism that will always give a precise, determinant answer. We then let protocols specify alternatives (if they need to) by additional specification. In particular, in each section we have to make clear what exactly happens with a language range, and what happens with a language priority list. For filtering, this can be done by moving the discussion of the language priority list up into 3.2. ] 3.2. If the language priority list (see Section 2.1 (Lists of Language Ranges) ) contains more than one range, the content returned is typically ordered in descending level of preference. => If the language priority list (see Section 2.1 (Lists of Language Ranges) ) contains more than one range, the contents that match that range are added to the set of results. [At the end of the section, after we've introduced the discussion of an ordered list and distance metric, add] When the set of matches is returned, the items are in descending order where the weight for each item is the priority in the language priority list divided by the distance metric. (If the filtering method does not supply a distance metric, then the distance metric is 1.) If the item matches multiple ranges, then its weight is the square root of the sum of squares of the individual weights for each range. If two items have the same weight, then their ordering is based on a case-insensitive ordering of the language tags. A protocol which uses language priority lists MAY specify an alternative mechanism for computing the ordering. ---- A protocol which uses language ranges MAY specify additional rules about the semantics of "*"; => A protocol which uses language ranges MAY specify additional rules about the semantics of "*" or other tags; [no reason to restrict it] ---- Implementations or protocols sometimes might wish to use more sophisticated weights that => Implementations or protocols sometimes MAY specify the use of alternative weights that ---- [Make subsections in Lookup. First language range lookup, then language priority list lookup, then extended language range lookup.] ---- Other examples of lookup might include: => Other examples of lookup include: [the examples *do* include. no need to be tentative ;-)] ---- If this language range is the only one in the language priority list, it matches the default content. If this language range is followed by other language ranges, it should be skipped. [doesn't address *;*] => All "*" language tags are removed from language priority list. If there is nothing left, then it matches the default content. ---- 5. (default content or the empty tag) => 5. (default) [explain below what this is. it is also otherwise odd that 1-4 are tags, but then this is 'content'] ---- When performing lookup using a language priority list, the progressive search MUST proceed to consider each language range before finding the default content or empty tag. The default content might be content with no language tag (or with an empty value, as with xml:lang in the XML specification), or it might be a particular language designated for that bit of content. One common way to provide for default content is to allow a specific language range to be set as the default for a specific type of request. This language range is then treated as if it were appended to the end of the language priority list, rather than after each item in the language priority list. => [reword for clarity. Funny thing: when I first read 'might be content with no language tag' I read it as the verb "be content with", like "be happy with". The empty tag is not a valid language tag, so we should say "und", then say that a system can use alternatives. Here is the text.] When performing lookup using a language priority list, the progressive search MUST consider each language range before finding the default. The default might be specified as "und" (or be indicated with an empty value, as with xml:lang in the XML specification, or with "root" as in some systems), or it might be specified as a particular language range. This language range is thus treated as if it were appended to the end of the language priority list, rather than after each item in the language priority list. ---- 5. (return default content) a. ja-JP b. ja c. (empty tag or other default content) 5. (default) a. ja-JP b. ja c. und ---- Wildcard values in an extended language range are supposed to match any value => Wildcard values in an extended language range match any value ---- Add 3.3.x. Distance Metric Lookup Distance metric lookup is performed by producing an ordered list of filtered results as specified in 3.2.2, then returning the first item. ---- Mark P.S. I still think that the extended range lookup doesn't quite work, but I'll send that in a separate message. Addison Phillips wrote: >Having had a chance to actually read my handiwork in draft-06, I notice an obvious additional structural change to be made. > >Actually, I believe Martin already suggested this. > >I notice that the sections on each type of language range now contains a lot of "hand wringing" about what users should choose or not choose. This text is actually applicable to all types of ranges. Thus, it seems to me that a section at the end of Section 2 on "Choice of Language Range" is appropriate. > >In my editor's copy of draft-07, I actually performed this change so folks could review it. (I also made some other corrections pointed out off list: these are listed in the changes section) > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.txt >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.xml > >Comments? > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Internationalization is not a feature. >It is an architecture. > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Nov 18 13:33:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdB3U-0005dg-Sq; Fri, 18 Nov 2005 13:33:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdB3T-0005YP-VL for ltru@megatron.ietf.org; Fri, 18 Nov 2005 13:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03390 for ; Fri, 18 Nov 2005 13:33:12 -0500 (EST) Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBLM-00006N-B9 for ltru@ietf.org; Fri, 18 Nov 2005 13:52:17 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIIXVuo029365 for ; Fri, 18 Nov 2005 13:33:31 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIIYnLY068444 for ; Fri, 18 Nov 2005 11:34:49 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAIIXVgs016142 for ; Fri, 18 Nov 2005 11:33:31 -0700 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAIIXTMg016082; Fri, 18 Nov 2005 11:33:30 -0700 Message-ID: <437E1E78.50807@icu-project.org> Date: Fri, 18 Nov 2005 10:33:28 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: draft-06: change the title? References: <437D0A24.36BF@xyzzy.claranet.de> <6.0.0.20.2.20051118164642.06f38960@localhost> In-Reply-To: <6.0.0.20.2.20051118164642.06f38960@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > > I agree, because the current terminology uses 'matching' > as a general term that subsumes 'filtering' and 'lookup'. +1 Martin Duerst wrote: > [as a technical (or stylistical, in this case :-) contributor] > > At 07:54 05/11/18, Frank Ellermann wrote: > >Addison Phillips wrote: > > > >> it should be "Matching of Language Tags" or, perhaps, > >> "Language Tag Matching". > > > >Both fine. > > +1 > > >I'd stay away from "and Filtering". Bye > > I agree, because the current terminology uses 'matching' > as a general term that subsumes 'filtering' and 'lookup'. > > Regards, Martin. > > _______________________________________________ > 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 Nov 18 13:54:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBNQ-0005XW-Az; Fri, 18 Nov 2005 13:54:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBNO-0005XQ-Qm for ltru@megatron.ietf.org; Fri, 18 Nov 2005 13:54:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04267 for ; Fri, 18 Nov 2005 13:53:47 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBfF-0000ZH-8J for ltru@ietf.org; Fri, 18 Nov 2005 14:12:52 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id jAIIrut3028573; Fri, 18 Nov 2005 10:53:56 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Nov 2005 10:56:02 -0800 Message-ID: From: "McDonald, Ira" To: "'Mark Davis'" , Martin Duerst Subject: RE: [Ltru] Re: draft-06: change the title? Date: Fri, 18 Nov 2005 10:56:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Frank Ellermann , 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi, I weakly prefer 'Matching of Language Tags', because it cannot be misunderstood. It's unfortunate (in retrospect) that the title of RFC3066bis wasn't changed to 'Registration of Language Tags', because it does NOT cover all the previous content of RFC 3066 (matching is separated and treated in much better detail). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf Of > Mark Davis > Sent: Friday, November 18, 2005 1:33 PM > To: Martin Duerst > Cc: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] Re: draft-06: change the title? > > > > > > I agree, because the current terminology uses 'matching' > > as a general term that subsumes 'filtering' and 'lookup'. > > +1 > > Martin Duerst wrote: > > > [as a technical (or stylistical, in this case :-) contributor] > > > > At 07:54 05/11/18, Frank Ellermann wrote: > > >Addison Phillips wrote: > > > > > >> it should be "Matching of Language Tags" or, perhaps, > > >> "Language Tag Matching". > > > > > >Both fine. > > > > +1 > > > > >I'd stay away from "and Filtering". Bye > > > > I agree, because the current terminology uses 'matching' > > as a general term that subsumes 'filtering' and 'lookup'. > > > > Regards, Martin. > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 14:01:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBTz-0008IH-8p; Fri, 18 Nov 2005 14:01:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBTx-0008IC-RE for ltru@megatron.ietf.org; Fri, 18 Nov 2005 14:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04606 for ; Fri, 18 Nov 2005 14:00:34 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBlr-0000j1-29 for ltru@ietf.org; Fri, 18 Nov 2005 14:19:39 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:00:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] draft-06 comments: choice of range Date: Fri, 18 Nov 2005 11:00:49 -0800 Message-ID: Thread-Topic: [Ltru] draft-06 comments: choice of range Thread-Index: AcXsbAredz6Jri0BRTClQ4mF2tmgTwAAOSzg From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 19:00:53.0694 (UTC) FILETIME=[665105E0:01C5EC72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1218106853==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1218106853== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Q29tbWVudHMgaW50ZXJsaW5lYXJseSBiZWxvdy4gSSBoYXZlIHNvbWUgc3Ryb25nIHJlc2VydmF0 aW9ucyBhYm91dCBzb21lIG9mIHRoZXNlIGNvbW1lbnRzLg0KDQpBZGRpc29uDQoNCkFkZGlzb24g UC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIERhdmlz IFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddDQo+IFNlbnQ6IDIwMDXlubQxMeac iDE45pelIDEwOjE1DQo+IFRvOiBBZGRpc29uIFBoaWxsaXBzDQo+IENjOiBsdHJ1QGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gZHJhZnQtMDYgY29tbWVudHM6IGNob2ljZSBvZiByYW5n ZQ0KPiANCi8vIHRleHQgcmVtb3ZlZA0KPiANCj4gW1RoZSAidGhpcyBhbHNvIG1lYW5zIiBvbmx5 IGFwcGxpZXMgd2hlbiB0aGUgaW1wbGVtZW5hdGlvbiBkb2VzIHRoZSBNQVkuXQ0KW0FkZGlzb24g UGhpbGxpcHNdIA0KDQpBZ3JlZWQsIGFsdGhvdWdoIEkgdGVuZCB0byB0aGluayB3ZSBzaG91bGQg Z28gdGhlIG90aGVyIGRpcmVjdGlvbiBhbmQgc2F5IE1VU1QuDQo+IA0KPiAtLS0tDQo+IA0KPiBt ZWFzdXJtZW50DQo+IFtzcGVsbC1jaGVja10NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KVGhhbmtz Lg0KPiANCj4gLS0tLQ0KPiANCj4gW0dlbmVyYWwgT2JzZXJ2YXRpb24uDQo+IA0KPiBXZSBuZWVk IHRvIGdpdmUgYSBtZWNoYW5pc20gdGhhdCB3aWxsIGFsd2F5cyBnaXZlIGEgcHJlY2lzZSwgZGV0 ZXJtaW5hbnQNCj4gYW5zd2VyLiBXZSB0aGVuIGxldCBwcm90b2NvbHMgc3BlY2lmeSBhbHRlcm5h dGl2ZXMgKGlmIHRoZXkgbmVlZCB0bykgYnkNCj4gYWRkaXRpb25hbCBzcGVjaWZpY2F0aW9uLiBJ biBwYXJ0aWN1bGFyLCBpbiBlYWNoIHNlY3Rpb24gd2UgaGF2ZSB0byBtYWtlDQo+IGNsZWFyIHdo YXQgZXhhY3RseSBoYXBwZW5zIHdpdGggYSBsYW5ndWFnZSByYW5nZSwgYW5kIHdoYXQgaGFwcGVu cyB3aXRoDQo+IGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC4NCj4gDQo+IEZvciBmaWx0ZXJpbmcs IHRoaXMgY2FuIGJlIGRvbmUgYnkgbW92aW5nIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBsYW5ndWFn ZQ0KPiBwcmlvcml0eSBsaXN0IHVwIGludG8gMy4yLiBdDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoN CkFjdHVhbGx5LCBJJ2QgZ28gZnVydGhlciBhbmQgc3VnZ2VzdCB0aGF0IGFsbCBvZiB0aGUgbWF0 Y2hpbmcgc2NoZW1lcyBiZSBkZWZpbmVkIGluIHRlcm1zIG9mIGxhbmd1YWdlIHByaW9yaXR5IGxp c3RzIChhIGxhbmd1YWdlIHJhbmdlIGJ5IGl0c2VsZiBiZWluZyB0aGUgY29sbGFwc2VkIGNhc2Ug b2YgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IHdpdGggb25seSBvbmUgaXRlbS0taW5zaWRlIHRo ZSBzcGVjaWZpYyBzY2hlbWUgd2UgZGVzY3JpYmUgaG93IHRvIG1hdGNoIGEgc2luZ2xlIHJhbmdl IHRvIGEgc2luZ2xlIHRhZywgYnV0IHRoZSBzY2hlbWUgb3ZlcmFsbCBtYXRjaGVzIHRoZSB1c2Vy J3MgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMtLWEgbGlzdC0tYWdhaW5zdCBjb250ZW50KS4gTG9va3Vw IG5vdyByZWFkcyB0aGlzIHdheS4gVGhpcyBzZWN0aW9uIDMuMiB0ZXh0Og0KDQotLQ0KRmlsdGVy aW5nIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzZXQgb2YgY29udGVudCB0aGF0IG1hdGNoZXMgYSBn aXZlbiBwcmVmaXguDQotLQ0KDQpTaG91bGQgYmUgbW9kaWZpZWQgdG8gc2F5Og0KDQotLQ0KRmls dGVyaW5nIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzZXQgb2YgY29udGVudCB0aGF0IG1hdGNoZXMg dGhlIHVzZXIncyBsYW5ndWFnZSBwcmVmZXJlbmNlcyAoc2VlIFNlY3Rpb24gMi4xLCBMYW5ndWFn ZSBQcmlvcml0eSBMaXN0cykuDQotLQ0KDQpCZWZvcmUgb2JqZWN0aW5nIHRvIHRoaXMgY2hhbmdl IGJlY2F1c2UgaXQgcmVtb3ZlcyB0aGUgY3JpdGljYWwgcG9pbnQgYWJvdXQgdGhlIHJhbmdlIGJl aW5nIGEgcHJlZml4LCBjb25zaWRlciB0aGF0IHRoZSBlbnRpcmUgc2Vjb25kIHBhcmFncmFwaCBv ZiB0aGlzIHNlY3Rpb24gY292ZXJzIHRoYXQuDQoNCj4gDQo+IDMuMi4NCj4gSWYgdGhlIGxhbmd1 YWdlIHByaW9yaXR5IGxpc3QgKHNlZSBTZWN0aW9uIDIuMSAoTGlzdHMgb2YgTGFuZ3VhZ2UNCj4g UmFuZ2VzKQ0KPiA8aHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRy dS1tYXRjaGluZy0wNy5odG1sI2xpc3RzPikNCj4gY29udGFpbnMgbW9yZSB0aGFuIG9uZSByYW5n ZSwgdGhlIGNvbnRlbnQgcmV0dXJuZWQgaXMgdHlwaWNhbGx5IG9yZGVyZWQNCj4gaW4gZGVzY2Vu ZGluZyBsZXZlbCBvZiBwcmVmZXJlbmNlLg0KPiA9Pg0KPiBJZiB0aGUgbGFuZ3VhZ2UgcHJpb3Jp dHkgbGlzdCAoc2VlIFNlY3Rpb24gMi4xIChMaXN0cyBvZiBMYW5ndWFnZQ0KPiBSYW5nZXMpDQo+ IDxodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5n LTA3Lmh0bWwjbGlzdHM+KQ0KPiBjb250YWlucyBtb3JlIHRoYW4gb25lIHJhbmdlLCB0aGUgY29u dGVudHMgdGhhdCBtYXRjaCB0aGF0IHJhbmdlIGFyZQ0KPiBhZGRlZCB0byB0aGUgc2V0IG9mIHJl c3VsdHMuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNClRoZSB3b3JkIGNvbnRlbnQgaW4gdGhpcyBz ZW50ZW5jZSBpcyBhbHJlYWR5IHBsdXJhbC4gIkNvbnRlbnRzIiBpcyB3cm9uZy4gSWYgd2Ugd2Fu dCB0byBiZSBleHBsaWNpdCBhYm91dCBpdCwgd2Ugc2hvdWxkIHVzZSB0aGUgcHJldmlvdXNseSBx dW90ZWQgZm9ybXVsYXRpb24gInNldCBvZiBjb250ZW50Ii4NCg0KPiANCj4gW0F0IHRoZSBlbmQg b2YgdGhlIHNlY3Rpb24sIGFmdGVyIHdlJ3ZlIGludHJvZHVjZWQgdGhlIGRpc2N1c3Npb24gb2Yg YW4NCj4gb3JkZXJlZCBsaXN0IGFuZCBkaXN0YW5jZSBtZXRyaWMsIGFkZF0NCj4gDQo+IFdoZW4g dGhlIHNldCBvZiBtYXRjaGVzIGlzIHJldHVybmVkLCB0aGUgaXRlbXMgYXJlIGluIGRlc2NlbmRp bmcgb3JkZXINCj4gd2hlcmUgdGhlIHdlaWdodCBmb3IgZWFjaCBpdGVtIGlzIHRoZSBwcmlvcml0 eSBpbiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkNCj4gbGlzdCBkaXZpZGVkIGJ5IHRoZSBkaXN0YW5j ZSBtZXRyaWMuIChJZiB0aGUgZmlsdGVyaW5nIG1ldGhvZCBkb2VzIG5vdA0KPiBzdXBwbHkgYSBk aXN0YW5jZSBtZXRyaWMsIHRoZW4gdGhlIGRpc3RhbmNlIG1ldHJpYyBpcyAxLikgSWYgdGhlIGl0 ZW0NCj4gbWF0Y2hlcyBtdWx0aXBsZSByYW5nZXMsIHRoZW4gaXRzIHdlaWdodCBpcyB0aGUgc3F1 YXJlIHJvb3Qgb2YgdGhlIHN1bQ0KPiBvZiBzcXVhcmVzIG9mIHRoZSBpbmRpdmlkdWFsIHdlaWdo dHMgZm9yIGVhY2ggcmFuZ2UuIElmIHR3byBpdGVtcyBoYXZlDQo+IHRoZSBzYW1lIHdlaWdodCwg dGhlbiB0aGVpciBvcmRlcmluZyBpcyBiYXNlZCBvbiBhIGNhc2UtaW5zZW5zaXRpdmUNCj4gb3Jk ZXJpbmcgb2YgdGhlIGxhbmd1YWdlIHRhZ3MuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNClVnaC4g SWNreS4gTWFueSBpdGVtcyB3aWxsIGhhdmUgdGhlIHNhbWUgd2VpZ2h0IGV2ZW4gaW4gc3BpdGUg b2YgdGhpcyBjb21wbGV4IHNjaGVtZS4NCg0KSSBub3RlIHRoYXQgcSB3ZWlnaHRzIGluIEFjY2Vw dC1MYW5ndWFnZSBhcmUgYWx3YXlzIGxlc3MgdGhhbiBvciBlcXVhbCB0byBvbmUgYW5kIGdyZWF0 ZXIgdGhhbiBvciBlcXVhbCB0byB6ZXJvLiBZb3VyIGFsZ29yaXRobSB3b24ndCB3b3JrIGNvcnJl Y3RseSB3aXRoIHRob3NlIHZhbHVlcyAoaW5zdGVhZCBtdWx0aXBsaWNhdGlvbiBvZiB0aGUgc2Nv cmUgd29ya3MgYmV0dGVyKS4NCj4gDQo+IEEgcHJvdG9jb2wgd2hpY2ggdXNlcyBsYW5ndWFnZSBw cmlvcml0eSBsaXN0cyBNQVkgc3BlY2lmeSBhbiBhbHRlcm5hdGl2ZQ0KPiBtZWNoYW5pc20gZm9y IGNvbXB1dGluZyB0aGUgb3JkZXJpbmcuDQo+IA0KPiAtLS0tDQo+IA0KPiBBIHByb3RvY29sIHdo aWNoIHVzZXMgbGFuZ3VhZ2UgcmFuZ2VzIE1BWSBzcGVjaWZ5IGFkZGl0aW9uYWwgcnVsZXMgYWJv dXQNCj4gdGhlIHNlbWFudGljcyBvZiAiKiI7DQo+ID0+DQo+IEEgcHJvdG9jb2wgd2hpY2ggdXNl cyBsYW5ndWFnZSByYW5nZXMgTUFZIHNwZWNpZnkgYWRkaXRpb25hbCBydWxlcyBhYm91dA0KPiB0 aGUgc2VtYW50aWNzIG9mICIqIiBvciBvdGhlciB0YWdzOw0KPiBbbm8gcmVhc29uIHRvIHJlc3Ry aWN0IGl0XQ0KPiANCj4gLS0tLQ0KPiANCj4gSW1wbGVtZW50YXRpb25zIG9yIHByb3RvY29scyBz b21ldGltZXMgbWlnaHQgd2lzaCB0byB1c2UgbW9yZQ0KPiBzb3BoaXN0aWNhdGVkIHdlaWdodHMg dGhhdA0KPiA9Pg0KPiBJbXBsZW1lbnRhdGlvbnMgb3IgcHJvdG9jb2xzIHNvbWV0aW1lcyBNQVkg c3BlY2lmeSB0aGUgdXNlIG9mDQo+IGFsdGVybmF0aXZlIHdlaWdodHMgdGhhdA0KW0FkZGlzb24g UGhpbGxpcHNdIA0KDQpFaXRoZXIgIi4uLnByb3RvY29scyBNQVkuLi4iIG9yICIuLi4gcHJvdG9j b2xzIHNvbWV0aW1lcyBtaWdodC4uLiINCg0KSSBjaG9zZSBub24tbm9ybWF0aXZlIGxhbmd1YWdl IGluaXRpYWxseSB0byBhbGxvdyB0aGluZ3Mgd2l0aG91dCB0dXJuaW5nIHRoZSB3aG9sZSBzZWN0 aW9uIGludG8gUkZDIDIxMTkgc291cC4NCj4gDQo+IC0tLS0NCj4gW01ha2Ugc3Vic2VjdGlvbnMg aW4gTG9va3VwLiBGaXJzdCBsYW5ndWFnZSByYW5nZSBsb29rdXAsIHRoZW4gbGFuZ3VhZ2UNCj4g cHJpb3JpdHkgbGlzdCBsb29rdXAsIHRoZW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgbG9va3Vw Ll0NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KSSB0aGluayB0aGF0J3MgYW4gYXdmdWwgaWRlYS4N Cg0KQW5kIG1ha2UgdXAgeW91ciBtaW5kOiB3ZSBSRU1PVkVEIGV4dGVuZGVkIGxhbmd1YWdlIHJh bmdlIGxvb2t1cCBiZWNhdXNlIGl0IGRvZXNu4oCZdCBtYWtlIHNlbnNlLiBMb29rdXAgaXMgbm93 IGNhc3QgYXMgSSBzdWdnZXN0ZWQgYWJvdmU6IGl0IGlzIHN0cmljdGx5IGEgbGFuZ3VhZ2UgcHJp b3JpdHkgbGlzdCBiZWFzdCwgYnV0IGl0IHN0YXJ0cyBieSBkZWZpbmVkIHRoZSBtYXRjaCBiZXR3 ZWVuIGEgdGFnIGFuZCBhIHJhbmdlLg0KPiANCj4gLS0tLQ0KPiBPdGhlciBleGFtcGxlcyBvZiBs b29rdXAgbWlnaHQgaW5jbHVkZToNCj4gPT4NCj4gT3RoZXIgZXhhbXBsZXMgb2YgbG9va3VwIGlu Y2x1ZGU6DQo+IFt0aGUgZXhhbXBsZXMgKmRvKiBpbmNsdWRlLiBubyBuZWVkIHRvIGJlIHRlbnRh dGl2ZSA7LSldDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCk9rYXkuDQo+IC0tLS0NCj4gDQo+IElm IHRoaXMgbGFuZ3VhZ2UgcmFuZ2UgaXMgdGhlIG9ubHkgb25lIGluIHRoZSBsYW5ndWFnZSBwcmlv cml0eSBsaXN0LCBpdA0KPiBtYXRjaGVzIHRoZSBkZWZhdWx0IGNvbnRlbnQuIElmIHRoaXMgbGFu Z3VhZ2UgcmFuZ2UgaXMgZm9sbG93ZWQgYnkgb3RoZXINCj4gbGFuZ3VhZ2UgcmFuZ2VzLCBpdCBz aG91bGQgYmUgc2tpcHBlZC4NCj4gW2RvZXNuJ3QgYWRkcmVzcyAgKjsqXQ0KW0FkZGlzb24gUGhp bGxpcHNdIA0KDQpZZXMsIGl0IGRvZXMuLi4gaXRlcmF0aXZlbHkuDQoNCj4gPT4NCj4gQWxsICIq IiBsYW5ndWFnZSB0YWdzIGFyZSByZW1vdmVkIGZyb20gbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC4g SWYgdGhlcmUNCj4gaXMgbm90aGluZyBsZWZ0LCB0aGVuIGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQg Y29udGVudC4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KVGhhdCdzICJyYW5nZXMiIGluIHlvdXIg Zmlyc3Qgc2VudGVuY2UuDQo+IA0KPiAtLS0tDQo+IA0KPiA1LiAoZGVmYXVsdCBjb250ZW50IG9y IHRoZSBlbXB0eSB0YWcpDQo+ID0+DQo+IDUuIChkZWZhdWx0KQ0KPiBbZXhwbGFpbiBiZWxvdyB3 aGF0IHRoaXMgaXMuIGl0IGlzIGFsc28gb3RoZXJ3aXNlIG9kZCB0aGF0IDEtNCBhcmUgdGFncywN Cj4gYnV0IHRoZW4gdGhpcyBpcyAnY29udGVudCddDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCk9r YXkuDQo+IA0KPiAtLS0tDQo+IA0KPiBXaGVuIHBlcmZvcm1pbmcgbG9va3VwIHVzaW5nIGEgbGFu Z3VhZ2UgcHJpb3JpdHkgbGlzdCwgdGhlIHByb2dyZXNzaXZlDQo+IHNlYXJjaCBNVVNUIHByb2Nl ZWQgdG8gY29uc2lkZXIgZWFjaCBsYW5ndWFnZSByYW5nZSBiZWZvcmUgZmluZGluZyB0aGUNCj4g ZGVmYXVsdCBjb250ZW50IG9yIGVtcHR5IHRhZy4gVGhlIGRlZmF1bHQgY29udGVudCBtaWdodCBi ZSBjb250ZW50IHdpdGgNCj4gbm8gbGFuZ3VhZ2UgdGFnIChvciB3aXRoIGFuIGVtcHR5IHZhbHVl LCBhcyB3aXRoIHhtbDpsYW5nIGluIHRoZSBYTUwNCj4gc3BlY2lmaWNhdGlvbiksIG9yIGl0IG1p Z2h0IGJlIGEgcGFydGljdWxhciBsYW5ndWFnZSBkZXNpZ25hdGVkIGZvciB0aGF0DQo+IGJpdCBv ZiBjb250ZW50Lg0KPiANCj4gT25lIGNvbW1vbiB3YXkgdG8gcHJvdmlkZSBmb3IgZGVmYXVsdCBj b250ZW50IGlzIHRvIGFsbG93IGEgc3BlY2lmaWMNCj4gbGFuZ3VhZ2UgcmFuZ2UgdG8gYmUgc2V0 IGFzIHRoZSBkZWZhdWx0IGZvciBhIHNwZWNpZmljIHR5cGUgb2YgcmVxdWVzdC4NCj4gVGhpcyBs YW5ndWFnZSByYW5nZSBpcyB0aGVuIHRyZWF0ZWQgYXMgaWYgaXQgd2VyZSBhcHBlbmRlZCB0byB0 aGUgZW5kIG9mDQo+IHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCByYXRoZXIgdGhhbiBhZnRl ciBlYWNoIGl0ZW0gaW4gdGhlIGxhbmd1YWdlDQo+IHByaW9yaXR5IGxpc3QuDQo+IA0KPiA9Pg0K PiBbcmV3b3JkIGZvciBjbGFyaXR5LiBGdW5ueSB0aGluZzogd2hlbiBJIGZpcnN0IHJlYWQgJ21p Z2h0IGJlIGNvbnRlbnQNCj4gd2l0aCBubyBsYW5ndWFnZSB0YWcnIEkgcmVhZCBpdCBhcyB0aGUg dmVyYiAiYmUgY29udGVudCB3aXRoIiwgbGlrZSAiYmUNCj4gaGFwcHkgd2l0aCIuIFRoZSBlbXB0 eSB0YWcgaXMgbm90IGEgdmFsaWQgbGFuZ3VhZ2UgdGFnLCBzbyB3ZSBzaG91bGQgc2F5DQo+ICJ1 bmQiLCB0aGVuIHNheSB0aGF0IGEgc3lzdGVtIGNhbiB1c2UgYWx0ZXJuYXRpdmVzLiBIZXJlIGlz IHRoZSB0ZXh0Ll0NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KTm8sIG5vdCAndW5kJyAoYW5kIEkg KmhhdGUqICd1bmQnKS4gJ1VuZCcgd291bGQgYmUgYW4gZXhhbXBsZSBvZiBhbiBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYyBkZWNpc2lvbi4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBuZXZlciB0 byBzZWUgJ3VuZCcgY29udGVudCBiZWluZyB1c2VkIGFzIGEgZGVmYXVsdC4NCj4gDQo+IFdoZW4g cGVyZm9ybWluZyBsb29rdXAgdXNpbmcgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCB0aGUgcHJv Z3Jlc3NpdmUNCj4gc2VhcmNoIE1VU1QgY29uc2lkZXIgZWFjaCBsYW5ndWFnZSByYW5nZSBiZWZv cmUgZmluZGluZyB0aGUgZGVmYXVsdC4gVGhlDQo+IGRlZmF1bHQgbWlnaHQgYmUgc3BlY2lmaWVk IGFzICJ1bmQiIChvciBiZSBpbmRpY2F0ZWQgd2l0aCBhbiBlbXB0eQ0KPiB2YWx1ZSwgYXMgd2l0 aCB4bWw6bGFuZyBpbiB0aGUgWE1MIHNwZWNpZmljYXRpb24sIG9yIHdpdGggInJvb3QiIGFzIGlu DQo+IHNvbWUgc3lzdGVtcyksIG9yIGl0IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIHBhcnRpY3Vs YXIgbGFuZ3VhZ2UgcmFuZ2UuDQo+IFRoaXMgbGFuZ3VhZ2UgcmFuZ2UgaXMgdGh1cyB0cmVhdGVk IGFzIGlmIGl0IHdlcmUgYXBwZW5kZWQgdG8gdGhlIGVuZCBvZg0KPiB0aGUgbGFuZ3VhZ2UgcHJp b3JpdHkgbGlzdCwgcmF0aGVyIHRoYW4gYWZ0ZXIgZWFjaCBpdGVtIGluIHRoZSBsYW5ndWFnZQ0K PiBwcmlvcml0eSBsaXN0Lg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpJIHByZWZlciBub3QgdG8g bWFrZSB0aGlzIGNoYW5nZS4gSSB0aGluayBpdCBkZWx2ZXMgdG9vIGNsb3NlbHkgaW50byB0aGUg aW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQo+IA0KPiAtLS0tDQo+IA0KPiA1LiAocmV0dXJuIGRl ZmF1bHQgY29udGVudCkNCj4gYS4gamEtSlANCj4gYi4gamENCj4gYy4gKGVtcHR5IHRhZyBvciBv dGhlciBkZWZhdWx0IGNvbnRlbnQpDQo+IA0KPiA1LiAoZGVmYXVsdCkNCj4gYS4gamEtSlANCj4g Yi4gamENCj4gYy4gdW5kDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkhvdyBhYm91dDoNCg0KNS4g KGRlZmF1bHQgY29udGVudCBsb29rdXApDQogICBhLiBqYS1KUA0KICAgYi4gamENCiAgIGMuIChp bXBsZW1lbnRhdGlvbiBkZWZpbmVkKQ0KPiANCj4gLS0tLQ0KPiANCj4gV2lsZGNhcmQgdmFsdWVz IGluIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGFyZSBzdXBwb3NlZCB0byBtYXRjaCBhbnkN Cj4gdmFsdWUNCj4gPT4NCj4gV2lsZGNhcmQgdmFsdWVzIGluIGFuIGV4dGVuZGVkIGxhbmd1YWdl IHJhbmdlIG1hdGNoIGFueSB2YWx1ZQ0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpObywgdGhleSBh cmUgKnN1cHBvc2VkKiB0byBtYXRjaCwgYnV0IGluIHRoaXMgY2FzZSB0aGV5IGRvbid0LiBUaGV5 IG1hdGNoIHRoZSBlbXB0eSB2YWx1ZS4NCj4gDQo+IC0tLS0NCj4gDQo+IEFkZA0KPiANCj4gDQo+ ICAgICAgIDMuMy54LiBEaXN0YW5jZSBNZXRyaWMgTG9va3VwDQo+IA0KPiBEaXN0YW5jZSBtZXRy aWMgbG9va3VwIGlzIHBlcmZvcm1lZCBieSBwcm9kdWNpbmcgYW4gb3JkZXJlZCBsaXN0IG9mDQo+ IGZpbHRlcmVkIHJlc3VsdHMgYXMgc3BlY2lmaWVkIGluIDMuMi4yLCB0aGVuIHJldHVybmluZyB0 aGUgZmlyc3QgaXRlbS4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KSSB0aGluayB3ZSdkIGJlc3Qg bm90IGdvIGRvd24gdGhhdCBwYXRoLiBBbW9uZyBvdGhlciB0aGluZ3M6IGl0IHdvbid0IHdvcmsu IERpc3RhbmNlIG1ldHJpYyBmaWx0ZXJpbmcgY2FuIHByb2R1Y2UgaXRlbXMgd2l0aCBpZGVudGlj YWwgc2NvcmVzLi4uIA0KDQo+IA0KPiAtLS0tDQo+IA0KPiBNYXJrDQo+IA0KPiBQLlMuIEkgc3Rp bGwgdGhpbmsgdGhhdCB0aGUgZXh0ZW5kZWQgcmFuZ2UgbG9va3VwIGRvZXNuJ3QgcXVpdGUgd29y aywNCj4gYnV0IEknbGwgc2VuZCB0aGF0IGluIGEgc2VwYXJhdGUgbWVzc2FnZS4NCltBZGRpc29u IFBoaWxsaXBzXSANCg0KTm8sIGl0IGRvZXNuJ3Qgd29yayBhbmQgd2UgZWxpbWluYXRlZCBpdC4g V2UndmUgbWFwcGVkIGV4dGVuZGVkIHJhbmdlcyBvbnRvIGJhc2ljIHJhbmdlcywgd2hpY2ggZG8g d29yaywgcHJvZHVjaW5nIGRpZmZlcmVudCByZXN1bHRzIHRoYW4gdGhlIGxhbmd1YWdlIHByaW9y aXR5IGxpc3QgbWlnaHQgbGVhZCBvbmUgdG8gZXhwZWN0Lg0KPiANCg0K --===============1218106853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1218106853==-- From ltru-bounces@ietf.org Fri Nov 18 14:18:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBkJ-0006WY-Ja; Fri, 18 Nov 2005 14:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBkH-0006NN-DF for ltru@megatron.ietf.org; Fri, 18 Nov 2005 14:18:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05353 for ; Fri, 18 Nov 2005 14:17:21 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdC26-00015t-1R for ltru@ietf.org; Fri, 18 Nov 2005 14:36:27 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:17:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: draft-06: change the title? Date: Fri, 18 Nov 2005 11:17:45 -0800 Message-ID: Thread-Topic: [Ltru] Re: draft-06: change the title? Thread-Index: AcXscYZ+Rl3FvrZ3RVWkRj5/AZnE6AAAygHw From: "Addison Phillips" To: "McDonald, Ira" , "Mark Davis" , "Martin Duerst" X-OriginalArrivalTime: 18 Nov 2005 19:17:46.0301 (UTC) FILETIME=[C1E096D0:01C5EC74] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Frank Ellermann , 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="===============1967945307==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1967945307== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Ik1hdGNoaW5nIG9mIExhbmd1YWdlIFRhZ3MiOiBzb3VuZHMgbGlrZSBhIHdpbm5lci4NCg0KQWRk aXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVl c3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gTWNEb25hbGQsIElyYQ0KPiBTZW50OiAyMDA15bm0MTHmnIgxOOaX pSAxMDo1Ng0KPiBUbzogJ01hcmsgRGF2aXMnOyBNYXJ0aW4gRHVlcnN0DQo+IENjOiBGcmFuayBF bGxlcm1hbm47IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtMdHJ1XSBSZTogZHJhZnQt MDY6IGNoYW5nZSB0aGUgdGl0bGU/DQo+IA0KPiBIaSwNCj4gDQo+IEkgd2Vha2x5IHByZWZlciAn TWF0Y2hpbmcgb2YgTGFuZ3VhZ2UgVGFncycsIGJlY2F1c2UgaXQgY2Fubm90DQo+IGJlIG1pc3Vu ZGVyc3Rvb2QuDQo+IA0KPiBJdCdzIHVuZm9ydHVuYXRlIChpbiByZXRyb3NwZWN0KSB0aGF0IHRo ZSB0aXRsZSBvZiBSRkMzMDY2YmlzDQo+IHdhc24ndCBjaGFuZ2VkIHRvICdSZWdpc3RyYXRpb24g b2YgTGFuZ3VhZ2UgVGFncycsIGJlY2F1c2UgaXQNCj4gZG9lcyBOT1QgY292ZXIgYWxsIHRoZSBw cmV2aW91cyBjb250ZW50IG9mIFJGQyAzMDY2IChtYXRjaGluZw0KPiBpcyBzZXBhcmF0ZWQgYW5k IHRyZWF0ZWQgaW4gbXVjaCBiZXR0ZXIgZGV0YWlsKS4NCj4gDQo+IENoZWVycywNCj4gLSBJcmEN Cj4gDQo+IElyYSBNY0RvbmFsZCAoTXVzaWNpYW4gLyBTb2Z0d2FyZSBBcmNoaXRlY3QpDQo+IEJs dWUgUm9vZiBNdXNpYyAvIEhpZ2ggTm9ydGggSW5jDQo+IFBPIEJveCAyMjEgIEdyYW5kIE1hcmFp cywgTUkgIDQ5ODM5DQo+IHBob25lOiArMS05MDYtNDk0LTI0MzQNCj4gZW1haWw6IGltY2RvbmFs ZEBzaGFycGxhYnMuY29tDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3Jn XU9uIEJlaGFsZiBPZg0KPiA+IE1hcmsgRGF2aXMNCj4gPiBTZW50OiBGcmlkYXksIE5vdmVtYmVy IDE4LCAyMDA1IDE6MzMgUE0NCj4gPiBUbzogTWFydGluIER1ZXJzdA0KPiA+IENjOiBGcmFuayBF bGxlcm1hbm47IGx0cnVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBkcmFm dC0wNjogY2hhbmdlIHRoZSB0aXRsZT8NCj4gPg0KPiA+DQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSwg YmVjYXVzZSB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSB1c2VzICdtYXRjaGluZycNCj4gPiA+IGFz IGEgZ2VuZXJhbCB0ZXJtIHRoYXQgc3Vic3VtZXMgJ2ZpbHRlcmluZycgYW5kICdsb29rdXAnLg0K PiA+DQo+ID4gKzENCj4gPg0KPiA+IE1hcnRpbiBEdWVyc3Qgd3JvdGU6DQo+ID4NCj4gPiA+IFth cyBhIHRlY2huaWNhbCAob3Igc3R5bGlzdGljYWwsIGluIHRoaXMgY2FzZSA6LSkgY29udHJpYnV0 b3JdDQo+ID4gPg0KPiA+ID4gQXQgMDc6NTQgMDUvMTEvMTgsIEZyYW5rIEVsbGVybWFubiB3cm90 ZToNCj4gPiA+ID5BZGRpc29uIFBoaWxsaXBzIHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPj4gaXQg c2hvdWxkIGJlICJNYXRjaGluZyBvZiBMYW5ndWFnZSBUYWdzIiBvciwgcGVyaGFwcywNCj4gPiA+ ID4+ICJMYW5ndWFnZSBUYWcgTWF0Y2hpbmciLg0KPiA+ID4gPg0KPiA+ID4gPkJvdGggZmluZS4N Cj4gPiA+DQo+ID4gPiArMQ0KPiA+ID4NCj4gPiA+ID5JJ2Qgc3RheSBhd2F5IGZyb20gImFuZCBG aWx0ZXJpbmciLiAgQnllDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSwgYmVjYXVzZSB0aGUgY3VycmVu dCB0ZXJtaW5vbG9neSB1c2VzICdtYXRjaGluZycNCj4gPiA+IGFzIGEgZ2VuZXJhbCB0ZXJtIHRo YXQgc3Vic3VtZXMgJ2ZpbHRlcmluZycgYW5kICdsb29rdXAnLg0KPiA+ID4NCj4gPiA+IFJlZ2Fy ZHMsICAgIE1hcnRpbi4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gTHRydSBtYWlsaW5nIGxpc3QNCj4gPiA+IEx0cnVA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+ IEx0cnVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sdHJ1DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============1967945307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1967945307==-- From ltru-bounces@ietf.org Fri Nov 18 15:58:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDJM-000821-NE; Fri, 18 Nov 2005 15:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDJK-00081t-S3 for ltru@megatron.ietf.org; Fri, 18 Nov 2005 15:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10235 for ; Fri, 18 Nov 2005 15:57:42 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDbE-0003fh-JC for ltru@ietf.org; Fri, 18 Nov 2005 16:16:49 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BE882596E3; Fri, 18 Nov 2005 21:57:41 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20691-09; Fri, 18 Nov 2005 21:57:36 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B99572596E2; Fri, 18 Nov 2005 21:57:35 +0100 (CET) Date: Fri, 18 Nov 2005 21:33:54 +0100 From: Harald Tveit Alvestrand To: Martin Duerst , LTRU Working Group Subject: Re: [Ltru] Matching: make sure subtags are explained Message-ID: <09A7312F2B4457A9CCDCB27C@B50854F0A9192E8EC6CDA126> In-Reply-To: <6.0.0.20.2.20051118165823.079bb060@localhost> References: <6.0.0.20.2.20051118165823.079bb060@localhost> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no 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: , Content-Type: multipart/mixed; boundary="===============0408283363==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0408283363== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2380E56DB1A4F4679EEF==========" --==========2380E56DB1A4F4679EEF========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 18. november 2005 17:11 +0900 Martin Duerst =20 wrote: > >>>> > ... For example, depending on the domain, an implemenation > might give a small distance to the difference between the language > subtag 'no' (Norvegian) and the closely related language subtags > 'nb' (Norvegian, Bookmal) or 'nn' (Norvegian, Newnorsk); or > between the script subtags 'Kata' (Katakana) and 'Hira' (Hiragana); > or between the region subtags 'US' (USA) and 'UM' (???). > <<<< UM =3D US Minor Outlying Islands, if I remember right. BTW, Norwegian's spelled with a W in English, and the variants should be=20 "Bokmal" and "Nynorsk" (transliterated from "Bokm=C3=A5l"), or "Book = language"=20 and "New Norwegian" if you want to translate. --==========2380E56DB1A4F4679EEF========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDfjqyOMj+2+WY0F4RAiy0AKClBP1I4glcLoahSHLAgjwI54IfJgCghqui An1W9eWq/125Jl1lkromGR4= =YtXy -----END PGP SIGNATURE----- --==========2380E56DB1A4F4679EEF==========-- --===============0408283363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0408283363==-- From ltru-bounces@ietf.org Fri Nov 18 16:42:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdE0C-0001z0-Ht; Fri, 18 Nov 2005 16:42:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdE0B-0001yv-I1 for ltru@megatron.ietf.org; Fri, 18 Nov 2005 16:42:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12519 for ; Fri, 18 Nov 2005 16:41:59 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdEI6-0004nc-Bt for ltru@ietf.org; Fri, 18 Nov 2005 17:01:06 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAILgJWN003054 for ; Fri, 18 Nov 2005 16:42:19 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAILgKXn096140 for ; Fri, 18 Nov 2005 16:42:20 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAILgJes004801 for ; Fri, 18 Nov 2005 16:42:19 -0500 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAILgIPr004701; Fri, 18 Nov 2005 16:42:19 -0500 Message-ID: <437E4AB8.3070404@icu-project.org> Date: Fri, 18 Nov 2005 13:42:16 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] draft-06 comments: choice of range References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e2.ny.us.ibm.com id jAILgJWN003054 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >Comments interlinearly below. I have some strong reservations about some= of these comments. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B411=E6=9C=8818=E6=97=A5 10:15 >>To: Addison Phillips >>Cc: ltru@ietf.org >>Subject: Re: [Ltru] draft-06 comments: choice of range >> >> =20 >> >// text removed > =20 > // just keep the text, makes it harder to tell what you are commenting=20 on ;-) >>[The "this also means" only applies when the implemenation does the MAY= .] >> =20 >> >[Addison Phillips]=20 > >Agreed, although I tend to think we should go the other direction and sa= y MUST. > =20 > If we say must, then we are really saying that any input range x-y-z-w=20 acts like x-*-y-*-z-*-w, whenever something could go between. Since we=20 say the algorithms work in the absence of parsing the language tag, that=20 means putting them in all the time. Seems like a bit much, but I'll mull=20 it over. >>---- >> >>measurment >>[spell-check] >> =20 >> >[Addison Phillips]=20 > >Thanks. > =20 > >>---- >> >>[General Observation. >> >>We need to give a mechanism that will always give a precise, determinan= t >>answer. We then let protocols specify alternatives (if they need to) by >>additional specification. In particular, in each section we have to mak= e >>clear what exactly happens with a language range, and what happens with >>a language priority list. >> >>For filtering, this can be done by moving the discussion of the languag= e >>priority list up into 3.2. ] >> =20 >> >[Addison Phillips]=20 > >Actually, I'd go further and suggest that all of the matching schemes be= defined in terms of language priority lists (a language range by itself = being the collapsed case of a language priority list with only one item--= inside the specific scheme we describe how to match a single range to a s= ingle tag, but the scheme overall matches the user''s language preference= s--a list--against content). Lookup now reads this way.=20 > That works too. Then we just say at the very top that all the mechanisms=20 treat a single language range as a single element language priority list. >This section 3.2 text: > >-- >Filtering is used to select the set of content that matches a given pref= ix. >-- > >Should be modified to say: > >-- >Filtering is used to select the set of content that matches the user's l= anguage preferences (see Section 2.1, Language Priority Lists). >-- > >Before objecting to this change because it removes the critical point ab= out the range being a prefix, consider that the entire second paragraph o= f this section covers that. > > =20 > >>3.2. >>If the language priority list (see Section 2.1 (Lists of Language >>Ranges) >>= ) >>contains more than one range, the content returned is typically ordered >>in descending level of preference. >>=3D> >>If the language priority list (see Section 2.1 (Lists of Language >>Ranges) >>= ) >>contains more than one range, the contents that match that range are >>added to the set of results. >> =20 >> >[Addison Phillips]=20 > >The word content in this sentence is already plural. "Contents" is wrong= . If we want to be explicit about it, we should use the previously quoted= formulation "set of content". > =20 > set of content works. > =20 > >>[At the end of the section, after we've introduced the discussion of an >>ordered list and distance metric, add] >> >>When the set of matches is returned, the items are in descending order >>where the weight for each item is the priority in the language priority >>list divided by the distance metric. (If the filtering method does not >>supply a distance metric, then the distance metric is 1.) If the item >>matches multiple ranges, then its weight is the square root of the sum >>of squares of the individual weights for each range. If two items have >>the same weight, then their ordering is based on a case-insensitive >>ordering of the language tags. >> =20 >> >[Addison Phillips]=20 > >Ugh. Icky. Many items will have the same weight even in spite of this co= mplex scheme. > =20 > Can't get around that. If priorities are equal and there is no distance=20 metric, then you essentially have an unordered list. >I note that q weights in Accept-Language are always less than or equal t= o one and greater than or equal to zero. Your algorithm won't work correc= tly with those values (instead multiplication of the score works better). > =20 > You're right that there is a numeric problem, but you can't multiply,=20 because smaller distances are better, but lower priorities are *worse*.=20 So you have to divide one way or another. Look at an example. X, q=3D0.5; Y, q=3D0.3; Z matches X with a distance of, say, 2. W matches Y with a distance of=20 10. If you multiply, you get Z -> (0.5 * 2) =3D 1 W -> (0.3) * 10) =3D 3 That would rank Y better than Z! What you want is a division. Now, as I think about it, the simplest way is to still think of the=20 results as distances, with the smallest distance being the best. Then=20 the algorithm is a) toss out any q weights that are zero. After all, that means that you=20 give them *no* priority. b) divide the distance by the priority. c) order in ascending order Z -> (2 / 0.5) =3D 1 W -> (10 / 0.3) =3D 33.33 which ranks them correctly. The square rooty stuff was just because distance metrics with multiple=20 fields weight better when you treat them as dimensional vectors.=20 However, in retrospect it is probably just simpler to take the minimum=20 of the possible weights. So if Q matches X with a distance of, say, 2. Q=20 matches Y with a distance of 10. Then the result would be the minimum, or= 1. >>A protocol which uses language priority lists MAY specify an alternativ= e >>mechanism for computing the ordering. >> >>---- >> >>A protocol which uses language ranges MAY specify additional rules abou= t >>the semantics of "*"; >>=3D> >>A protocol which uses language ranges MAY specify additional rules abou= t >>the semantics of "*" or other tags; >>[no reason to restrict it] >> >>---- >> >>Implementations or protocols sometimes might wish to use more >>sophisticated weights that >>=3D> >>Implementations or protocols sometimes MAY specify the use of >>alternative weights that >> =20 >> >[Addison Phillips]=20 > >Either "...protocols MAY..." or "... protocols sometimes might..." > =20 > sometimes MAY =3D> MAY >I chose non-normative language initially to allow things without turning= the whole section into RFC 2119 soup. > =20 > >>---- >>[Make subsections in Lookup. First language range lookup, then language >>priority list lookup, then extended language range lookup.] >> =20 >> >[Addison Phillips]=20 > >I think that's an awful idea. > >And make up your mind: we REMOVED extended language range lookup because= it doesn=E2=80=99t make sense. Lookup is now cast as I suggested above: = it is strictly a language priority list beast, but it starts by defined t= he match between a tag and a range. > =20 > Lemme relook at it, but it seems to me that you are doing it, but *via*=20 transforming it. (but more in a separate message anyway). >>---- >>Other examples of lookup might include: >>=3D> >>Other examples of lookup include: >>[the examples *do* include. no need to be tentative ;-)] >> =20 >> >[Addison Phillips]=20 > >Okay. > =20 > >>---- >> >>If this language range is the only one in the language priority list, i= t >>matches the default content. If this language range is followed by othe= r >>language ranges, it should be skipped. >>[doesn't address *;*] >> =20 >> >[Addison Phillips]=20 > >Yes, it does... iteratively. > =20 > You're right. > =20 > >>=3D> >>All "*" language tags are removed from language priority list. If there >>is nothing left, then it matches the default content. >> =20 >> >[Addison Phillips]=20 > >That's "ranges" in your first sentence. > =20 > >>---- >> >>5. (default content or the empty tag) >>=3D> >>5. (default) >>[explain below what this is. it is also otherwise odd that 1-4 are tags= , >>but then this is 'content'] >> =20 >> >[Addison Phillips]=20 > >Okay. > =20 > >>---- >> >>When performing lookup using a language priority list, the progressive >>search MUST proceed to consider each language range before finding the >>default content or empty tag. The default content might be content with >>no language tag (or with an empty value, as with xml:lang in the XML >>specification), or it might be a particular language designated for tha= t >>bit of content. >> >>One common way to provide for default content is to allow a specific >>language range to be set as the default for a specific type of request. >>This language range is then treated as if it were appended to the end o= f >>the language priority list, rather than after each item in the language >>priority list. >> >>=3D> >>[reword for clarity. Funny thing: when I first read 'might be content >>with no language tag' I read it as the verb "be content with", like "be >>happy with". The empty tag is not a valid language tag, so we should sa= y >>"und", then say that a system can use alternatives. Here is the text.] >> =20 >> >[Addison Phillips]=20 > >No, not 'und' (and I *hate* 'und'). 'Und' would be an example of an impl= ementation specific decision. Personally I would prefer never to see 'und= ' content being used as a default. > =20 > Well, "" is illegal as a language-tag, so I was just using it as a=20 stand-in because we don't have a language tag for "root". >>When performing lookup using a language priority list, the progressive >>search MUST consider each language range before finding the default. Th= e >>default might be specified as "und" (or be indicated with an empty >>value, as with xml:lang in the XML specification, or with "root" as in >>some systems), or it might be specified as a particular language range. >>This language range is thus treated as if it were appended to the end o= f >>the language priority list, rather than after each item in the language >>priority list. >> =20 >> >[Addison Phillips]=20 > >I prefer not to make this change. I think it delves too closely into the= implementation specific. > =20 > It can't be left as it is. Other alternatives? >>---- >> >>5. (return default content) >>a. ja-JP >>b. ja >>c. (empty tag or other default content) >> >>5. (default) >>a. ja-JP >>b. ja >>c. und >> =20 >> >[Addison Phillips]=20 > >How about: > >5. (default content lookup) > a. ja-JP > b. ja > c. (implementation defined) > =20 > That works. >>---- >> >>Wildcard values in an extended language range are supposed to match any >>value >>=3D> >>Wildcard values in an extended language range match any value >> =20 >> >[Addison Phillips]=20 > >No, they are *supposed* to match, but in this case they don't. They matc= h the empty value. > =20 > I read that differently. When you say "supposed to match", it sounds=20 like there is a choice, that there are some values that they don't=20 match. Like the US is "supposed to" disallow torture. >>---- >> >>Add >> >> >> 3.3.x. Distance Metric Lookup >> >>Distance metric lookup is performed by producing an ordered list of >>filtered results as specified in 3.2.2, then returning the first item. >> =20 >> >[Addison Phillips]=20 > >I think we'd best not go down that path. Among other things: it won't wo= rk. Distance metric filtering can produce items with identical scores...=20 > =20 > Ok, drop it. > =20 > >>---- >> >>Mark >> >>P.S. I still think that the extended range lookup doesn't quite work, >>but I'll send that in a separate message. >> =20 >> >[Addison Phillips]=20 > >No, it doesn't work and we eliminated it. We've mapped extended ranges o= nto basic ranges, which do work, producing different results than the lan= guage priority list might lead one to expect. > =20 > Let me look this over again. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 17:06:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdENA-0007SK-56; Fri, 18 Nov 2005 17:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEN8-0007RM-C4 for ltru@megatron.ietf.org; Fri, 18 Nov 2005 17:06:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13523 for ; Fri, 18 Nov 2005 17:05:39 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdEf0-0005IC-Cv for ltru@ietf.org; Fri, 18 Nov 2005 17:24:47 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:05:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: wildcards in extended ranges (was RE: [Ltru] draft-06 comments: choice of range) Date: Fri, 18 Nov 2005 14:05:56 -0800 Message-ID: Thread-Topic: wildcards in extended ranges (was RE: [Ltru] draft-06 comments: choice of range) Thread-Index: AcXsiPeWXqsrBFbiRuCt6vRc6rzwbwAAWPpA From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 22:05:58.0004 (UTC) FILETIME=[41004340:01C5EC8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1888599107==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1888599107== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 KEknbSBnb2luZyB0byByZXBseSB0byB0aGluZ3MgaW5kaXZpZHVhbGx5IHRvIGtlZXAgdGhlIG1h aWwgdGhyZWFkcyBtYW5hZ2VhYmxlLikNCg0KPiA+QWdyZWVkLCBhbHRob3VnaCBJIHRlbmQgdG8g dGhpbmsgd2Ugc2hvdWxkIGdvIHRoZSBvdGhlciBkaXJlY3Rpb24gYW5kIHNheQ0KPiBNVVNULg0K PiA+DQo+ID4NCj4gSWYgd2Ugc2F5IG11c3QsIHRoZW4gd2UgYXJlIHJlYWxseSBzYXlpbmcgdGhh dCBhbnkgaW5wdXQgcmFuZ2UgeC15LXotdw0KPiBhY3RzIGxpa2UgeC0qLXktKi16LSotdywgd2hl bmV2ZXIgc29tZXRoaW5nIGNvdWxkIGdvIGJldHdlZW4uIFNpbmNlIHdlDQo+IHNheSB0aGUgYWxn b3JpdGhtcyB3b3JrIGluIHRoZSBhYnNlbmNlIG9mIHBhcnNpbmcgdGhlIGxhbmd1YWdlIHRhZywg dGhhdA0KPiBtZWFucyBwdXR0aW5nIHRoZW0gaW4gYWxsIHRoZSB0aW1lLiBTZWVtcyBsaWtlIGEg Yml0IG11Y2gsIGJ1dCBJJ2xsIG11bGwNCj4gaXQgb3Zlci4NCg0KSXQgZG9lc24ndCBzYXkgdGhh dCB0aGUgYWxnb3JpdGhtcyB3b3JrIGluIHRoZSBhYnNlbmNlIG9mIHBhcnNpbmcgdGhlIGxhbmd1 YWdlIHRhZ3MuIEl0IHNheXMgdGhleSB3b3JrIGluIGFic2VuY2Ugb2YgdGhlIHJlZ2lzdHJ5LiBF eHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgcmVxdWlyZSBsZW5ndGgvY29udGVudCBiYXNlZCBwYXJz aW5nIG9mIGJvdGggdGhlIHJhbmdlIGFuZCB0aGUgdGFnIGluIG9yZGVyIHRvIHdvcmsuIE90aGVy d2lzZSB5b3UgY2FuJ3QgdGVsbCB3aGF0IGEgIioiIGlzIHN1cHBvc2VkIHRvIG1hdGNoICh1bmxl c3MgeW91IHJlcXVpcmUgYWxsIG9mIHRoZSBmaWVsZHMgdG8gYmUgZmlsbGVkIGluKS4NCg0KSWRl YWxseSwgZXh0ZW5kZWQgcmFuZ2UgZmlsdGVyaW5nIGFuZCBzY29yZWQgZmlsdGVyaW5nIHdpdGgg YSB0aHJlc2hvbGQgb2YgIjAiIHNob3VsZCBwcm9kdWNlIHRoZSBzYW1lIHNldHMsIG9yIGF0IGxl YXN0IEkgdGhpbmsgdGhleSBzaG91bGQuIEhhdmluZyB3cml0dGVuIGFuIGV4dGVuZGVkIHJhbmdl IGZpbHRlciBhbmQganVzdCBmaW5pc2hlZCBhIHNjb3JlZCBmaWx0ZXIsIEkgaGF2ZW4ndCB0ZXN0 ZWQgaXQgZXh0ZW5zaXZlbHkgeWV0Lg0KDQpIb3dldmVyLCBJIGRvIG5vdGUgdGhhdCBJIGhhZCB0 byBwYXJzZSBib3RoIHJhbmdlIGFuZCB0YWcgdG8gbWFrZSBleHRlbmRlZCB3b3JrIGFuZCB3b3Vs ZCBuZWVkIHRvIGV2ZW4gaWYgbWlzc2luZyBpdGVtcyBhcmUgbm90ICIqIi4uLiBJIGhhdmUgdG8g a25vdyB3aGljaCBzdWJ0YWdzIEkgaGF2ZSBpbiBvcmRlciB0byBtYXRjaCBhbnkgIioiIHZhbHVl cyB0aGF0ICpkbyogb2NjdXIuIFRoZSBvbmx5IHRpbWUgbXkgaW1wbGVtZW50YXRpb24gZ29lcyB0 byB0aGUgcmVnaXN0cnksIHRob3VnaCwgaXMgZm9yIHRoZSBsaXN0IG9mIGdyYW5kZmF0aGVyZWQg aXRlbXMuDQoNClNvLCB5ZXMsIHdlIGFyZSBzYXlpbmcgeC0qLXktKi16LSotdy4NCg0KTGV0J3Mg dGFrZSBzb21lIGV4YW1wbGVzLiBJZiBJIGhhdmUgYSByYW5nZSAiZW4tVVMiLCBzaG91bGQgaXQg bWF0Y2ggImVuLUxhdG4tVVMiIG9yIG5vdD8gQmFzaWMgcmFuZ2VzIGRvIE5PVCBtYXRjaCB0aG9z ZSB0YWdzLiBFeHRlbmRlZCByYW5nZXMsIGFzIGN1cnJlbnRseSB3cml0dGVuLCBETyBtYXRjaCB0 aG9zZSB0YWdzLg0KDQpJZiBJIGhhdmUgZGUtKi0xOTAxLCBkb2VzIGl0IG1hdGNoICJkZS1MYXRu LTE5MDEiPyAiZGUtREUtMTkwMSI/IFdoYXQgZG9lcyBhIHNpbmdsZSAqIG1lYW4/DQoNClRoZSBj dXJyZW50IHRleHQgc2F5cyAiTUFZIiBmb3IgbWlzc2luZyBlbGVtZW50cywgYWxsb3dpbmcgdGhl IGZpcnN0IGV4YW1wbGUgdG8gbWF0Y2ggb3Igbm90IGF0IGFuIGltcGxlbWVudGF0aW9uIGxldmVs LiBCdXQgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgd2UgY2hvc2Ugb25lIG9yIHRoZSBv dGhlci4NCg0KTXkgMiBjZW50cy4NCg0KQWRkaXNvbg0KDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMN Ckdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============1888599107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1888599107==-- From ltru-bounces@ietf.org Fri Nov 18 17:09:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEPm-0007u3-MK; Fri, 18 Nov 2005 17:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEPj-0007on-Vw for ltru@megatron.ietf.org; Fri, 18 Nov 2005 17:09:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13683 for ; Fri, 18 Nov 2005 17:08:23 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdEhe-0005NQ-Ti for ltru@ietf.org; Fri, 18 Nov 2005 17:27:31 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:08:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 14:08:46 -0800 Message-ID: Thread-Topic: schemes based on list or on range? Thread-Index: AcXsiPeWXqsrBFbiRuCt6vRc6rzwbwAA004w From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 22:08:48.0141 (UTC) FILETIME=[A6691BD0:01C5EC8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: ltru@ietf.org Subject: [Ltru] schemes based on list or on range? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127700056==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2127700056== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+PltHZW5lcmFsIE9ic2VydmF0aW9uLg0KPiA+Pg0KPiA+PldlIG5lZWQgdG8gZ2l2ZSBhIG1l Y2hhbmlzbSB0aGF0IHdpbGwgYWx3YXlzIGdpdmUgYSBwcmVjaXNlLCBkZXRlcm1pbmFudA0KPiA+ PmFuc3dlci4gV2UgdGhlbiBsZXQgcHJvdG9jb2xzIHNwZWNpZnkgYWx0ZXJuYXRpdmVzIChpZiB0 aGV5IG5lZWQgdG8pIGJ5DQo+ID4+YWRkaXRpb25hbCBzcGVjaWZpY2F0aW9uLiBJbiBwYXJ0aWN1 bGFyLCBpbiBlYWNoIHNlY3Rpb24gd2UgaGF2ZSB0byBtYWtlDQo+ID4+Y2xlYXIgd2hhdCBleGFj dGx5IGhhcHBlbnMgd2l0aCBhIGxhbmd1YWdlIHJhbmdlLCBhbmQgd2hhdCBoYXBwZW5zIHdpdGgN Cj4gPj5hIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QuDQo+ID4+DQo+ID4+Rm9yIGZpbHRlcmluZywg dGhpcyBjYW4gYmUgZG9uZSBieSBtb3ZpbmcgdGhlIGRpc2N1c3Npb24gb2YgdGhlIGxhbmd1YWdl DQo+ID4+cHJpb3JpdHkgbGlzdCB1cCBpbnRvIDMuMi4gXQ0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlz b24gUGhpbGxpcHNdDQo+ID4NCj4gPkFjdHVhbGx5LCBJJ2QgZ28gZnVydGhlciBhbmQgc3VnZ2Vz dCB0aGF0IGFsbCBvZiB0aGUgbWF0Y2hpbmcgc2NoZW1lcyBiZQ0KPiBkZWZpbmVkIGluIHRlcm1z IG9mIGxhbmd1YWdlIHByaW9yaXR5IGxpc3RzIChhIGxhbmd1YWdlIHJhbmdlIGJ5IGl0c2VsZg0K PiBiZWluZyB0aGUgY29sbGFwc2VkIGNhc2Ugb2YgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IHdp dGggb25seSBvbmUgaXRlbS0tDQo+IGluc2lkZSB0aGUgc3BlY2lmaWMgc2NoZW1lIHdlIGRlc2Ny aWJlIGhvdyB0byBtYXRjaCBhIHNpbmdsZSByYW5nZSB0byBhDQo+IHNpbmdsZSB0YWcsIGJ1dCB0 aGUgc2NoZW1lIG92ZXJhbGwgbWF0Y2hlcyB0aGUgdXNlcidzIGxhbmd1YWdlDQo+IHByZWZlcmVu Y2VzLS1hIGxpc3QtLWFnYWluc3QgY29udGVudCkuIExvb2t1cCBub3cgcmVhZHMgdGhpcyB3YXku DQo+ID4NCj4gVGhhdCB3b3JrcyB0b28uIFRoZW4gd2UganVzdCBzYXkgYXQgdGhlIHZlcnkgdG9w IHRoYXQgYWxsIHRoZSBtZWNoYW5pc21zDQo+IHRyZWF0IGEgc2luZ2xlIGxhbmd1YWdlIHJhbmdl IGFzIGEgc2luZ2xlIGVsZW1lbnQgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC4NCg0KWWVwLiBJIHRo aW5rIHdlIHNob3VsZCBmaW5pc2ggaGFybW9uaXppbmcgdGhlIHRleHQgdG8gdGhpcyBhcHByb2Fj aC4gSW1wbGVtZW50ZXJzIGNhbiBtYWtlIGNlcnRhaW4gYXNzdW1wdGlvbnMgd2hlbiB0aGV5IG9u bHkgYWxsb3cgb3Igb25seSBoYXZlIGEgc2luZ2xlIHJhbmdlLCBidXQgaXQgaXMgbW9yZSBpbXBv cnRhbnQgdG8gZGVzY3JpYmUgdGhlIGZ1bGwgYWxnb3JpdGhtIGluIGEgc2luZ2xlIGNvbnNpc3Rl bnQgbWFubmVyLiANCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMg bm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1 LXByb2plY3Qub3JnXQ0KPiBTZW50OiAyMDA15bm0MTHmnIgxOOaXpSAxMzo0Mg0KPiBUbzogQWRk aXNvbiBQaGlsbGlwcw0KPiBDYzogbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0x0cnVd IGRyYWZ0LTA2IGNvbW1lbnRzOiBjaG9pY2Ugb2YgcmFuZ2UNCj4gDQo+IA0KPiANCj4gQWRkaXNv biBQaGlsbGlwcyB3cm90ZToNCj4gDQo+ID5Db21tZW50cyBpbnRlcmxpbmVhcmx5IGJlbG93LiBJ IGhhdmUgc29tZSBzdHJvbmcgcmVzZXJ2YXRpb25zIGFib3V0IHNvbWUNCj4gb2YgdGhlc2UgY29t bWVudHMuDQo+ID4NCj4gPkFkZGlzb24NCj4gPg0KPiA+QWRkaXNvbiBQLiBQaGlsbGlwcw0KPiA+ R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQo+ID4NCj4gPkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQo+ID5JdCBpcyBhbiBhcmNoaXRlY3R1cmUu DQo+ID4NCj4gPg0KPiA+DQo+ID4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj5Gcm9t OiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddDQo+ID4+U2Vu dDogMjAwNeW5tDEx5pyIMTjml6UgMTA6MTUNCj4gPj5UbzogQWRkaXNvbiBQaGlsbGlwcw0KPiA+ PkNjOiBsdHJ1QGlldGYub3JnDQo+ID4+U3ViamVjdDogUmU6IFtMdHJ1XSBkcmFmdC0wNiBjb21t ZW50czogY2hvaWNlIG9mIHJhbmdlDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4NCj4gPj4tLS0tDQo+ ID4+DQo+IA0KPiA+VGhpcyBzZWN0aW9uIDMuMiB0ZXh0Og0KPiA+DQo+ID4tLQ0KPiA+RmlsdGVy aW5nIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzZXQgb2YgY29udGVudCB0aGF0IG1hdGNoZXMgYSBn aXZlbg0KPiBwcmVmaXguDQo+ID4tLQ0KPiA+DQo+ID5TaG91bGQgYmUgbW9kaWZpZWQgdG8gc2F5 Og0KPiA+DQo+ID4tLQ0KPiA+RmlsdGVyaW5nIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzZXQgb2Yg Y29udGVudCB0aGF0IG1hdGNoZXMgdGhlIHVzZXIncw0KPiBsYW5ndWFnZSBwcmVmZXJlbmNlcyAo c2VlIFNlY3Rpb24gMi4xLCBMYW5ndWFnZSBQcmlvcml0eSBMaXN0cykuDQo+ID4tLQ0KPiA+DQo+ ID5CZWZvcmUgb2JqZWN0aW5nIHRvIHRoaXMgY2hhbmdlIGJlY2F1c2UgaXQgcmVtb3ZlcyB0aGUg Y3JpdGljYWwgcG9pbnQNCj4gYWJvdXQgdGhlIHJhbmdlIGJlaW5nIGEgcHJlZml4LCBjb25zaWRl ciB0aGF0IHRoZSBlbnRpcmUgc2Vjb25kIHBhcmFncmFwaA0KPiBvZiB0aGlzIHNlY3Rpb24gY292 ZXJzIHRoYXQuDQo+ID4NCj4gPg0KPiA+DQo+ID4+My4yLg0KPiA+PklmIHRoZSBsYW5ndWFnZSBw cmlvcml0eSBsaXN0IChzZWUgU2VjdGlvbiAyLjEgKExpc3RzIG9mIExhbmd1YWdlDQo+ID4+UmFu Z2VzKQ0KPiA+PjxodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1 LW1hdGNoaW5nLTA3Lmh0bWwjbGlzdHM+KQ0KPiA+PmNvbnRhaW5zIG1vcmUgdGhhbiBvbmUgcmFu Z2UsIHRoZSBjb250ZW50IHJldHVybmVkIGlzIHR5cGljYWxseSBvcmRlcmVkDQo+ID4+aW4gZGVz Y2VuZGluZyBsZXZlbCBvZiBwcmVmZXJlbmNlLg0KPiA+Pj0+DQo+ID4+SWYgdGhlIGxhbmd1YWdl IHByaW9yaXR5IGxpc3QgKHNlZSBTZWN0aW9uIDIuMSAoTGlzdHMgb2YgTGFuZ3VhZ2UNCj4gPj5S YW5nZXMpDQo+ID4+PGh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0 cnUtbWF0Y2hpbmctMDcuaHRtbCNsaXN0cz4pDQo+ID4+Y29udGFpbnMgbW9yZSB0aGFuIG9uZSBy YW5nZSwgdGhlIGNvbnRlbnRzIHRoYXQgbWF0Y2ggdGhhdCByYW5nZSBhcmUNCj4gPj5hZGRlZCB0 byB0aGUgc2V0IG9mIHJlc3VsdHMuDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10N Cj4gPg0KPiA+VGhlIHdvcmQgY29udGVudCBpbiB0aGlzIHNlbnRlbmNlIGlzIGFscmVhZHkgcGx1 cmFsLiAiQ29udGVudHMiIGlzIHdyb25nLg0KPiBJZiB3ZSB3YW50IHRvIGJlIGV4cGxpY2l0IGFi b3V0IGl0LCB3ZSBzaG91bGQgdXNlIHRoZSBwcmV2aW91c2x5IHF1b3RlZA0KPiBmb3JtdWxhdGlv biAic2V0IG9mIGNvbnRlbnQiLg0KPiA+DQo+ID4NCj4gc2V0IG9mIGNvbnRlbnQgd29ya3MuDQo+ IA0KPiA+DQo+ID4NCj4gPj5bQXQgdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiwgYWZ0ZXIgd2UndmUg aW50cm9kdWNlZCB0aGUgZGlzY3Vzc2lvbiBvZiBhbg0KPiA+Pm9yZGVyZWQgbGlzdCBhbmQgZGlz dGFuY2UgbWV0cmljLCBhZGRdDQo+ID4+DQo+ID4+V2hlbiB0aGUgc2V0IG9mIG1hdGNoZXMgaXMg cmV0dXJuZWQsIHRoZSBpdGVtcyBhcmUgaW4gZGVzY2VuZGluZyBvcmRlcg0KPiA+PndoZXJlIHRo ZSB3ZWlnaHQgZm9yIGVhY2ggaXRlbSBpcyB0aGUgcHJpb3JpdHkgaW4gdGhlIGxhbmd1YWdlIHBy aW9yaXR5DQo+ID4+bGlzdCBkaXZpZGVkIGJ5IHRoZSBkaXN0YW5jZSBtZXRyaWMuIChJZiB0aGUg ZmlsdGVyaW5nIG1ldGhvZCBkb2VzIG5vdA0KPiA+PnN1cHBseSBhIGRpc3RhbmNlIG1ldHJpYywg dGhlbiB0aGUgZGlzdGFuY2UgbWV0cmljIGlzIDEuKSBJZiB0aGUgaXRlbQ0KPiA+Pm1hdGNoZXMg bXVsdGlwbGUgcmFuZ2VzLCB0aGVuIGl0cyB3ZWlnaHQgaXMgdGhlIHNxdWFyZSByb290IG9mIHRo ZSBzdW0NCj4gPj5vZiBzcXVhcmVzIG9mIHRoZSBpbmRpdmlkdWFsIHdlaWdodHMgZm9yIGVhY2gg cmFuZ2UuIElmIHR3byBpdGVtcyBoYXZlDQo+ID4+dGhlIHNhbWUgd2VpZ2h0LCB0aGVuIHRoZWly IG9yZGVyaW5nIGlzIGJhc2VkIG9uIGEgY2FzZS1pbnNlbnNpdGl2ZQ0KPiA+Pm9yZGVyaW5nIG9m IHRoZSBsYW5ndWFnZSB0YWdzLg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ ID4NCj4gPlVnaC4gSWNreS4gTWFueSBpdGVtcyB3aWxsIGhhdmUgdGhlIHNhbWUgd2VpZ2h0IGV2 ZW4gaW4gc3BpdGUgb2YgdGhpcw0KPiBjb21wbGV4IHNjaGVtZS4NCj4gPg0KPiA+DQo+IENhbid0 IGdldCBhcm91bmQgdGhhdC4gSWYgcHJpb3JpdGllcyBhcmUgZXF1YWwgYW5kIHRoZXJlIGlzIG5v IGRpc3RhbmNlDQo+IG1ldHJpYywgdGhlbiB5b3UgZXNzZW50aWFsbHkgaGF2ZSBhbiB1bm9yZGVy ZWQgbGlzdC4NCj4gDQo+ID5JIG5vdGUgdGhhdCBxIHdlaWdodHMgaW4gQWNjZXB0LUxhbmd1YWdl IGFyZSBhbHdheXMgbGVzcyB0aGFuIG9yIGVxdWFsIHRvDQo+IG9uZSBhbmQgZ3JlYXRlciB0aGFu IG9yIGVxdWFsIHRvIHplcm8uIFlvdXIgYWxnb3JpdGhtIHdvbid0IHdvcmsgY29ycmVjdGx5DQo+ IHdpdGggdGhvc2UgdmFsdWVzIChpbnN0ZWFkIG11bHRpcGxpY2F0aW9uIG9mIHRoZSBzY29yZSB3 b3JrcyBiZXR0ZXIpLg0KPiA+DQo+ID4NCj4gDQo+IFlvdSdyZSByaWdodCB0aGF0IHRoZXJlIGlz IGEgbnVtZXJpYyBwcm9ibGVtLCBidXQgeW91IGNhbid0IG11bHRpcGx5LA0KPiBiZWNhdXNlIHNt YWxsZXIgZGlzdGFuY2VzIGFyZSBiZXR0ZXIsIGJ1dCBsb3dlciBwcmlvcml0aWVzIGFyZSAqd29y c2UqLg0KPiBTbyB5b3UgaGF2ZSB0byBkaXZpZGUgb25lIHdheSBvciBhbm90aGVyLiBMb29rIGF0 IGFuIGV4YW1wbGUuDQo+IA0KPiBYLCBxPTAuNTsgWSwgcT0wLjM7DQo+IA0KPiBaIG1hdGNoZXMg WCB3aXRoIGEgZGlzdGFuY2Ugb2YsIHNheSwgMi4gVyBtYXRjaGVzIFkgd2l0aCBhIGRpc3RhbmNl IG9mDQo+IDEwLiBJZiB5b3UgbXVsdGlwbHksIHlvdSBnZXQNCj4gDQo+IFogLT4gKDAuNSAqIDIp ID0gMQ0KPiBXIC0+ICgwLjMpICogMTApID0gIDMNCj4gDQo+IFRoYXQgd291bGQgcmFuayBZIGJl dHRlciB0aGFuIFohIFdoYXQgeW91IHdhbnQgaXMgYSBkaXZpc2lvbi4NCj4gDQo+IE5vdywgYXMg SSB0aGluayBhYm91dCBpdCwgdGhlIHNpbXBsZXN0IHdheSBpcyB0byBzdGlsbCB0aGluayBvZiB0 aGUNCj4gcmVzdWx0cyBhcyBkaXN0YW5jZXMsIHdpdGggdGhlIHNtYWxsZXN0IGRpc3RhbmNlIGJl aW5nIHRoZSBiZXN0LiBUaGVuDQo+IHRoZSBhbGdvcml0aG0gaXMNCj4gDQo+IGEpIHRvc3Mgb3V0 IGFueSBxIHdlaWdodHMgdGhhdCBhcmUgemVyby4gQWZ0ZXIgYWxsLCB0aGF0IG1lYW5zIHRoYXQg eW91DQo+IGdpdmUgdGhlbSAqbm8qIHByaW9yaXR5Lg0KPiBiKSBkaXZpZGUgdGhlIGRpc3RhbmNl IGJ5IHRoZSBwcmlvcml0eS4NCj4gYykgb3JkZXIgaW4gYXNjZW5kaW5nIG9yZGVyDQo+IA0KPiBa IC0+ICgyIC8gMC41KSA9IDENCj4gVyAtPiAoMTAgLyAwLjMpID0gMzMuMzMNCj4gDQo+IHdoaWNo IHJhbmtzIHRoZW0gY29ycmVjdGx5Lg0KPiANCj4gVGhlIHNxdWFyZSByb290eSBzdHVmZiB3YXMg anVzdCBiZWNhdXNlIGRpc3RhbmNlIG1ldHJpY3Mgd2l0aCBtdWx0aXBsZQ0KPiBmaWVsZHMgd2Vp Z2h0IGJldHRlciB3aGVuIHlvdSB0cmVhdCB0aGVtIGFzIGRpbWVuc2lvbmFsIHZlY3RvcnMuDQo+ IEhvd2V2ZXIsIGluIHJldHJvc3BlY3QgaXQgaXMgcHJvYmFibHkganVzdCBzaW1wbGVyIHRvIHRh a2UgdGhlIG1pbmltdW0NCj4gb2YgdGhlIHBvc3NpYmxlIHdlaWdodHMuIFNvIGlmIFEgbWF0Y2hl cyBYIHdpdGggYSBkaXN0YW5jZSBvZiwgc2F5LCAyLiBRDQo+IG1hdGNoZXMgWSB3aXRoIGEgZGlz dGFuY2Ugb2YgMTAuIFRoZW4gdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGUgbWluaW11bSwgb3INCj4g MS4NCj4gDQo+ID4+QSBwcm90b2NvbCB3aGljaCB1c2VzIGxhbmd1YWdlIHByaW9yaXR5IGxpc3Rz IE1BWSBzcGVjaWZ5IGFuIGFsdGVybmF0aXZlDQo+ID4+bWVjaGFuaXNtIGZvciBjb21wdXRpbmcg dGhlIG9yZGVyaW5nLg0KPiA+Pg0KPiA+Pi0tLS0NCj4gPj4NCj4gPj5BIHByb3RvY29sIHdoaWNo IHVzZXMgbGFuZ3VhZ2UgcmFuZ2VzIE1BWSBzcGVjaWZ5IGFkZGl0aW9uYWwgcnVsZXMgYWJvdXQN Cj4gPj50aGUgc2VtYW50aWNzIG9mICIqIjsNCj4gPj49Pg0KPiA+PkEgcHJvdG9jb2wgd2hpY2gg dXNlcyBsYW5ndWFnZSByYW5nZXMgTUFZIHNwZWNpZnkgYWRkaXRpb25hbCBydWxlcyBhYm91dA0K PiA+PnRoZSBzZW1hbnRpY3Mgb2YgIioiIG9yIG90aGVyIHRhZ3M7DQo+ID4+W25vIHJlYXNvbiB0 byByZXN0cmljdCBpdF0NCj4gPj4NCj4gPj4tLS0tDQo+ID4+DQo+ID4+SW1wbGVtZW50YXRpb25z IG9yIHByb3RvY29scyBzb21ldGltZXMgbWlnaHQgd2lzaCB0byB1c2UgbW9yZQ0KPiA+PnNvcGhp c3RpY2F0ZWQgd2VpZ2h0cyB0aGF0DQo+ID4+PT4NCj4gPj5JbXBsZW1lbnRhdGlvbnMgb3IgcHJv dG9jb2xzIHNvbWV0aW1lcyBNQVkgc3BlY2lmeSB0aGUgdXNlIG9mDQo+ID4+YWx0ZXJuYXRpdmUg d2VpZ2h0cyB0aGF0DQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ RWl0aGVyICIuLi5wcm90b2NvbHMgTUFZLi4uIiBvciAiLi4uIHByb3RvY29scyBzb21ldGltZXMg bWlnaHQuLi4iDQo+ID4NCj4gPg0KPiBzb21ldGltZXMgTUFZID0+IE1BWQ0KPiANCj4gPkkgY2hv c2Ugbm9uLW5vcm1hdGl2ZSBsYW5ndWFnZSBpbml0aWFsbHkgdG8gYWxsb3cgdGhpbmdzIHdpdGhv dXQgdHVybmluZw0KPiB0aGUgd2hvbGUgc2VjdGlvbiBpbnRvIFJGQyAyMTE5IHNvdXAuDQo+ID4N Cj4gPg0KPiA+Pi0tLS0NCj4gPj5bTWFrZSBzdWJzZWN0aW9ucyBpbiBMb29rdXAuIEZpcnN0IGxh bmd1YWdlIHJhbmdlIGxvb2t1cCwgdGhlbiBsYW5ndWFnZQ0KPiA+PnByaW9yaXR5IGxpc3QgbG9v a3VwLCB0aGVuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGxvb2t1cC5dDQo+ID4+DQo+ID4+DQo+ ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SSB0aGluayB0aGF0J3MgYW4gYXdmdWwgaWRl YS4NCj4gPg0KPiA+QW5kIG1ha2UgdXAgeW91ciBtaW5kOiB3ZSBSRU1PVkVEIGV4dGVuZGVkIGxh bmd1YWdlIHJhbmdlIGxvb2t1cCBiZWNhdXNlDQo+IGl0IGRvZXNu4oCZdCBtYWtlIHNlbnNlLiBM b29rdXAgaXMgbm93IGNhc3QgYXMgSSBzdWdnZXN0ZWQgYWJvdmU6IGl0IGlzDQo+IHN0cmljdGx5 IGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCBiZWFzdCwgYnV0IGl0IHN0YXJ0cyBieSBkZWZpbmVk IHRoZQ0KPiBtYXRjaCBiZXR3ZWVuIGEgdGFnIGFuZCBhIHJhbmdlLg0KPiA+DQo+ID4NCj4gTGVt bWUgcmVsb29rIGF0IGl0LCBidXQgaXQgc2VlbXMgdG8gbWUgdGhhdCB5b3UgYXJlIGRvaW5nIGl0 LCBidXQgKnZpYSoNCj4gdHJhbnNmb3JtaW5nIGl0LiAoYnV0IG1vcmUgaW4gYSBzZXBhcmF0ZSBt ZXNzYWdlIGFueXdheSkuDQo+IA0KPiA+Pi0tLS0NCj4gPj5PdGhlciBleGFtcGxlcyBvZiBsb29r dXAgbWlnaHQgaW5jbHVkZToNCj4gPj49Pg0KPiA+Pk90aGVyIGV4YW1wbGVzIG9mIGxvb2t1cCBp bmNsdWRlOg0KPiA+Plt0aGUgZXhhbXBsZXMgKmRvKiBpbmNsdWRlLiBubyBuZWVkIHRvIGJlIHRl bnRhdGl2ZSA7LSldDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ T2theS4NCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PklmIHRoaXMgbGFuZ3VhZ2UgcmFu Z2UgaXMgdGhlIG9ubHkgb25lIGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCBpdA0KPiA+ Pm1hdGNoZXMgdGhlIGRlZmF1bHQgY29udGVudC4gSWYgdGhpcyBsYW5ndWFnZSByYW5nZSBpcyBm b2xsb3dlZCBieSBvdGhlcg0KPiA+Pmxhbmd1YWdlIHJhbmdlcywgaXQgc2hvdWxkIGJlIHNraXBw ZWQuDQo+ID4+W2RvZXNuJ3QgYWRkcmVzcyAgKjsqXQ0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24g UGhpbGxpcHNdDQo+ID4NCj4gPlllcywgaXQgZG9lcy4uLiBpdGVyYXRpdmVseS4NCj4gPg0KPiA+ DQo+IFlvdSdyZSByaWdodC4NCj4gDQo+ID4NCj4gPg0KPiA+Pj0+DQo+ID4+QWxsICIqIiBsYW5n dWFnZSB0YWdzIGFyZSByZW1vdmVkIGZyb20gbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC4gSWYgdGhl cmUNCj4gPj5pcyBub3RoaW5nIGxlZnQsIHRoZW4gaXQgbWF0Y2hlcyB0aGUgZGVmYXVsdCBjb250 ZW50Lg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPlRoYXQncyAi cmFuZ2VzIiBpbiB5b3VyIGZpcnN0IHNlbnRlbmNlLg0KPiA+DQo+ID4NCj4gPj4tLS0tDQo+ID4+ DQo+ID4+NS4gKGRlZmF1bHQgY29udGVudCBvciB0aGUgZW1wdHkgdGFnKQ0KPiA+Pj0+DQo+ID4+ NS4gKGRlZmF1bHQpDQo+ID4+W2V4cGxhaW4gYmVsb3cgd2hhdCB0aGlzIGlzLiBpdCBpcyBhbHNv IG90aGVyd2lzZSBvZGQgdGhhdCAxLTQgYXJlIHRhZ3MsDQo+ID4+YnV0IHRoZW4gdGhpcyBpcyAn Y29udGVudCddDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+T2th eS4NCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PldoZW4gcGVyZm9ybWluZyBsb29rdXAg dXNpbmcgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCB0aGUgcHJvZ3Jlc3NpdmUNCj4gPj5zZWFy Y2ggTVVTVCBwcm9jZWVkIHRvIGNvbnNpZGVyIGVhY2ggbGFuZ3VhZ2UgcmFuZ2UgYmVmb3JlIGZp bmRpbmcgdGhlDQo+ID4+ZGVmYXVsdCBjb250ZW50IG9yIGVtcHR5IHRhZy4gVGhlIGRlZmF1bHQg Y29udGVudCBtaWdodCBiZSBjb250ZW50IHdpdGgNCj4gPj5ubyBsYW5ndWFnZSB0YWcgKG9yIHdp dGggYW4gZW1wdHkgdmFsdWUsIGFzIHdpdGggeG1sOmxhbmcgaW4gdGhlIFhNTA0KPiA+PnNwZWNp ZmljYXRpb24pLCBvciBpdCBtaWdodCBiZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgZGVzaWduYXRl ZCBmb3IgdGhhdA0KPiA+PmJpdCBvZiBjb250ZW50Lg0KPiA+Pg0KPiA+Pk9uZSBjb21tb24gd2F5 IHRvIHByb3ZpZGUgZm9yIGRlZmF1bHQgY29udGVudCBpcyB0byBhbGxvdyBhIHNwZWNpZmljDQo+ ID4+bGFuZ3VhZ2UgcmFuZ2UgdG8gYmUgc2V0IGFzIHRoZSBkZWZhdWx0IGZvciBhIHNwZWNpZmlj IHR5cGUgb2YgcmVxdWVzdC4NCj4gPj5UaGlzIGxhbmd1YWdlIHJhbmdlIGlzIHRoZW4gdHJlYXRl ZCBhcyBpZiBpdCB3ZXJlIGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YNCj4gPj50aGUgbGFuZ3VhZ2Ug cHJpb3JpdHkgbGlzdCwgcmF0aGVyIHRoYW4gYWZ0ZXIgZWFjaCBpdGVtIGluIHRoZSBsYW5ndWFn ZQ0KPiA+PnByaW9yaXR5IGxpc3QuDQo+ID4+DQo+ID4+PT4NCj4gPj5bcmV3b3JkIGZvciBjbGFy aXR5LiBGdW5ueSB0aGluZzogd2hlbiBJIGZpcnN0IHJlYWQgJ21pZ2h0IGJlIGNvbnRlbnQNCj4g Pj53aXRoIG5vIGxhbmd1YWdlIHRhZycgSSByZWFkIGl0IGFzIHRoZSB2ZXJiICJiZSBjb250ZW50 IHdpdGgiLCBsaWtlICJiZQ0KPiA+PmhhcHB5IHdpdGgiLiBUaGUgZW1wdHkgdGFnIGlzIG5vdCBh IHZhbGlkIGxhbmd1YWdlIHRhZywgc28gd2Ugc2hvdWxkIHNheQ0KPiA+PiJ1bmQiLCB0aGVuIHNh eSB0aGF0IGEgc3lzdGVtIGNhbiB1c2UgYWx0ZXJuYXRpdmVzLiBIZXJlIGlzIHRoZSB0ZXh0Ll0N Cj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5Obywgbm90ICd1bmQn IChhbmQgSSAqaGF0ZSogJ3VuZCcpLiAnVW5kJyB3b3VsZCBiZSBhbiBleGFtcGxlIG9mIGFuDQo+ IGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGRlY2lzaW9uLiBQZXJzb25hbGx5IEkgd291bGQgcHJl ZmVyIG5ldmVyIHRvIHNlZQ0KPiAndW5kJyBjb250ZW50IGJlaW5nIHVzZWQgYXMgYSBkZWZhdWx0 Lg0KPiA+DQo+ID4NCj4gV2VsbCwgIiIgaXMgaWxsZWdhbCBhcyBhIGxhbmd1YWdlLXRhZywgc28g SSB3YXMganVzdCB1c2luZyBpdCBhcyBhDQo+IHN0YW5kLWluIGJlY2F1c2Ugd2UgZG9uJ3QgaGF2 ZSBhIGxhbmd1YWdlIHRhZyBmb3IgInJvb3QiLg0KPiANCj4gPj5XaGVuIHBlcmZvcm1pbmcgbG9v a3VwIHVzaW5nIGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCwgdGhlIHByb2dyZXNzaXZlDQo+ID4+ c2VhcmNoIE1VU1QgY29uc2lkZXIgZWFjaCBsYW5ndWFnZSByYW5nZSBiZWZvcmUgZmluZGluZyB0 aGUgZGVmYXVsdC4gVGhlDQo+ID4+ZGVmYXVsdCBtaWdodCBiZSBzcGVjaWZpZWQgYXMgInVuZCIg KG9yIGJlIGluZGljYXRlZCB3aXRoIGFuIGVtcHR5DQo+ID4+dmFsdWUsIGFzIHdpdGggeG1sOmxh bmcgaW4gdGhlIFhNTCBzcGVjaWZpY2F0aW9uLCBvciB3aXRoICJyb290IiBhcyBpbg0KPiA+PnNv bWUgc3lzdGVtcyksIG9yIGl0IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIHBhcnRpY3VsYXIgbGFu Z3VhZ2UgcmFuZ2UuDQo+ID4+VGhpcyBsYW5ndWFnZSByYW5nZSBpcyB0aHVzIHRyZWF0ZWQgYXMg aWYgaXQgd2VyZSBhcHBlbmRlZCB0byB0aGUgZW5kIG9mDQo+ID4+dGhlIGxhbmd1YWdlIHByaW9y aXR5IGxpc3QsIHJhdGhlciB0aGFuIGFmdGVyIGVhY2ggaXRlbSBpbiB0aGUgbGFuZ3VhZ2UNCj4g Pj5wcmlvcml0eSBsaXN0Lg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4N Cj4gPkkgcHJlZmVyIG5vdCB0byBtYWtlIHRoaXMgY2hhbmdlLiBJIHRoaW5rIGl0IGRlbHZlcyB0 b28gY2xvc2VseSBpbnRvIHRoZQ0KPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCj4gPg0KPiA+ DQo+IEl0IGNhbid0IGJlIGxlZnQgYXMgaXQgaXMuIE90aGVyIGFsdGVybmF0aXZlcz8NCj4gDQo+ ID4+LS0tLQ0KPiA+Pg0KPiA+PjUuIChyZXR1cm4gZGVmYXVsdCBjb250ZW50KQ0KPiA+PmEuIGph LUpQDQo+ID4+Yi4gamENCj4gPj5jLiAoZW1wdHkgdGFnIG9yIG90aGVyIGRlZmF1bHQgY29udGVu dCkNCj4gPj4NCj4gPj41LiAoZGVmYXVsdCkNCj4gPj5hLiBqYS1KUA0KPiA+PmIuIGphDQo+ID4+ Yy4gdW5kDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SG93IGFi b3V0Og0KPiA+DQo+ID41LiAoZGVmYXVsdCBjb250ZW50IGxvb2t1cCkNCj4gPiAgIGEuIGphLUpQ DQo+ID4gICBiLiBqYQ0KPiA+ICAgYy4gKGltcGxlbWVudGF0aW9uIGRlZmluZWQpDQo+ID4NCj4g Pg0KPiBUaGF0IHdvcmtzLg0KPiANCj4gPj4tLS0tDQo+ID4+DQo+ID4+V2lsZGNhcmQgdmFsdWVz IGluIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGFyZSBzdXBwb3NlZCB0byBtYXRjaCBhbnkN Cj4gPj52YWx1ZQ0KPiA+Pj0+DQo+ID4+V2lsZGNhcmQgdmFsdWVzIGluIGFuIGV4dGVuZGVkIGxh bmd1YWdlIHJhbmdlIG1hdGNoIGFueSB2YWx1ZQ0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhp bGxpcHNdDQo+ID4NCj4gPk5vLCB0aGV5IGFyZSAqc3VwcG9zZWQqIHRvIG1hdGNoLCBidXQgaW4g dGhpcyBjYXNlIHRoZXkgZG9uJ3QuIFRoZXkgbWF0Y2gNCj4gdGhlIGVtcHR5IHZhbHVlLg0KPiA+ DQo+ID4NCj4gSSByZWFkIHRoYXQgZGlmZmVyZW50bHkuIFdoZW4geW91IHNheSAic3VwcG9zZWQg dG8gbWF0Y2giLCBpdCBzb3VuZHMNCj4gbGlrZSB0aGVyZSBpcyBhIGNob2ljZSwgdGhhdCB0aGVy ZSBhcmUgc29tZSB2YWx1ZXMgdGhhdCB0aGV5IGRvbid0DQo+IG1hdGNoLiBMaWtlIHRoZSBVUyBp cyAic3VwcG9zZWQgdG8iIGRpc2FsbG93IHRvcnR1cmUuDQo+IA0KPiA+Pi0tLS0NCj4gPj4NCj4g Pj5BZGQNCj4gPj4NCj4gPj4NCj4gPj4gICAgICAzLjMueC4gRGlzdGFuY2UgTWV0cmljIExvb2t1 cA0KPiA+Pg0KPiA+PkRpc3RhbmNlIG1ldHJpYyBsb29rdXAgaXMgcGVyZm9ybWVkIGJ5IHByb2R1 Y2luZyBhbiBvcmRlcmVkIGxpc3Qgb2YNCj4gPj5maWx0ZXJlZCByZXN1bHRzIGFzIHNwZWNpZmll ZCBpbiAzLjIuMiwgdGhlbiByZXR1cm5pbmcgdGhlIGZpcnN0IGl0ZW0uDQo+ID4+DQo+ID4+DQo+ ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SSB0aGluayB3ZSdkIGJlc3Qgbm90IGdvIGRv d24gdGhhdCBwYXRoLiBBbW9uZyBvdGhlciB0aGluZ3M6IGl0IHdvbid0DQo+IHdvcmsuIERpc3Rh bmNlIG1ldHJpYyBmaWx0ZXJpbmcgY2FuIHByb2R1Y2UgaXRlbXMgd2l0aCBpZGVudGljYWwgc2Nv cmVzLi4uDQo+ID4NCj4gPg0KPiBPaywgZHJvcCBpdC4NCj4gDQo+ID4NCj4gPg0KPiA+Pi0tLS0N Cj4gPj4NCj4gPj5NYXJrDQo+ID4+DQo+ID4+UC5TLiBJIHN0aWxsIHRoaW5rIHRoYXQgdGhlIGV4 dGVuZGVkIHJhbmdlIGxvb2t1cCBkb2Vzbid0IHF1aXRlIHdvcmssDQo+ID4+YnV0IEknbGwgc2Vu ZCB0aGF0IGluIGEgc2VwYXJhdGUgbWVzc2FnZS4NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBo aWxsaXBzXQ0KPiA+DQo+ID5ObywgaXQgZG9lc24ndCB3b3JrIGFuZCB3ZSBlbGltaW5hdGVkIGl0 LiBXZSd2ZSBtYXBwZWQgZXh0ZW5kZWQgcmFuZ2VzDQo+IG9udG8gYmFzaWMgcmFuZ2VzLCB3aGlj aCBkbyB3b3JrLCBwcm9kdWNpbmcgZGlmZmVyZW50IHJlc3VsdHMgdGhhbiB0aGUNCj4gbGFuZ3Vh Z2UgcHJpb3JpdHkgbGlzdCBtaWdodCBsZWFkIG9uZSB0byBleHBlY3QuDQo+ID4NCj4gPg0KPiBM ZXQgbWUgbG9vayB0aGlzIG92ZXIgYWdhaW4uDQoNCg== --===============2127700056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2127700056==-- From ltru-bounces@ietf.org Fri Nov 18 17:29:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEjy-0004RJ-0d; Fri, 18 Nov 2005 17:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEju-0004PO-IM for ltru@megatron.ietf.org; Fri, 18 Nov 2005 17:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14603 for ; Fri, 18 Nov 2005 17:29:15 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdF1p-0005sC-EO for ltru@ietf.org; Fri, 18 Nov 2005 17:48:22 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:29:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 14:29:39 -0800 Message-ID: Thread-Topic: weights in scored filtering Thread-Index: AcXsiPeWXqsrBFbiRuCt6vRc6rzwbwAA7AlA From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 22:29:40.0711 (UTC) FILETIME=[91001F70:01C5EC8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: ltru@ietf.org Subject: [Ltru] weights in scored filtering X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977658191==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0977658191== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+DQo+ID4+W0F0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24sIGFmdGVyIHdlJ3ZlIGludHJvZHVj ZWQgdGhlIGRpc2N1c3Npb24gb2YgYW4NCj4gPj5vcmRlcmVkIGxpc3QgYW5kIGRpc3RhbmNlIG1l dHJpYywgYWRkXQ0KPiA+Pg0KPiA+PldoZW4gdGhlIHNldCBvZiBtYXRjaGVzIGlzIHJldHVybmVk LCB0aGUgaXRlbXMgYXJlIGluIGRlc2NlbmRpbmcgb3JkZXINCj4gPj53aGVyZSB0aGUgd2VpZ2h0 IGZvciBlYWNoIGl0ZW0gaXMgdGhlIHByaW9yaXR5IGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eQ0K PiA+Pmxpc3QgZGl2aWRlZCBieSB0aGUgZGlzdGFuY2UgbWV0cmljLiAoSWYgdGhlIGZpbHRlcmlu ZyBtZXRob2QgZG9lcyBub3QNCj4gPj5zdXBwbHkgYSBkaXN0YW5jZSBtZXRyaWMsIHRoZW4gdGhl IGRpc3RhbmNlIG1ldHJpYyBpcyAxLikgSWYgdGhlIGl0ZW0NCj4gPj5tYXRjaGVzIG11bHRpcGxl IHJhbmdlcywgdGhlbiBpdHMgd2VpZ2h0IGlzIHRoZSBzcXVhcmUgcm9vdCBvZiB0aGUgc3VtDQo+ ID4+b2Ygc3F1YXJlcyBvZiB0aGUgaW5kaXZpZHVhbCB3ZWlnaHRzIGZvciBlYWNoIHJhbmdlLiBJ ZiB0d28gaXRlbXMgaGF2ZQ0KPiA+PnRoZSBzYW1lIHdlaWdodCwgdGhlbiB0aGVpciBvcmRlcmlu ZyBpcyBiYXNlZCBvbiBhIGNhc2UtaW5zZW5zaXRpdmUNCj4gPj5vcmRlcmluZyBvZiB0aGUgbGFu Z3VhZ2UgdGFncy4NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5V Z2guIElja3kuIE1hbnkgaXRlbXMgd2lsbCBoYXZlIHRoZSBzYW1lIHdlaWdodCBldmVuIGluIHNw aXRlIG9mIHRoaXMNCj4gY29tcGxleCBzY2hlbWUuDQo+ID4NCj4gPg0KPiBDYW4ndCBnZXQgYXJv dW5kIHRoYXQuIElmIHByaW9yaXRpZXMgYXJlIGVxdWFsIGFuZCB0aGVyZSBpcyBubyBkaXN0YW5j ZQ0KPiBtZXRyaWMsIHRoZW4geW91IGVzc2VudGlhbGx5IGhhdmUgYW4gdW5vcmRlcmVkIGxpc3Qu DQoNCklmIEkgaGF2ZSB0d28gYml0cyBvZiBjb250ZW50IHdpdGggdGhlIHNhbWUgdGFnLCB0aGVp ciB2YWx1ZXMgd2lsbCBiZSBlcXVhbC4gVGhlIGNob2ljZSBvZiB3aGF0IG9yZGVyIHRoZXkgYXJl IHJldHVybmVkIGluIHRoZW4gaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIHBlcmhhcHMgYmFz ZWQgb24gc29tZSBvdGhlciBpbmZvcm1hdGlvbiAobGlrZSBGSUZPIG9yIHdvcmQgZnJlcXVlbmN5 IG9yLi4uKQ0KPiANCj4gPkkgbm90ZSB0aGF0IHEgd2VpZ2h0cyBpbiBBY2NlcHQtTGFuZ3VhZ2Ug YXJlIGFsd2F5cyBsZXNzIHRoYW4gb3IgZXF1YWwgdG8NCj4gb25lIGFuZCBncmVhdGVyIHRoYW4g b3IgZXF1YWwgdG8gemVyby4gWW91ciBhbGdvcml0aG0gd29uJ3Qgd29yayBjb3JyZWN0bHkNCj4g d2l0aCB0aG9zZSB2YWx1ZXMgKGluc3RlYWQgbXVsdGlwbGljYXRpb24gb2YgdGhlIHNjb3JlIHdv cmtzIGJldHRlcikuDQo+ID4NCj4gDQo+IFlvdSdyZSByaWdodCB0aGF0IHRoZXJlIGlzIGEgbnVt ZXJpYyBwcm9ibGVtLCBidXQgeW91IGNhbid0IG11bHRpcGx5LA0KPiBiZWNhdXNlIHNtYWxsZXIg ZGlzdGFuY2VzIGFyZSBiZXR0ZXIsIGJ1dCBsb3dlciBwcmlvcml0aWVzIGFyZSAqd29yc2UqLg0K PiBTbyB5b3UgaGF2ZSB0byBkaXZpZGUgb25lIHdheSBvciBhbm90aGVyLiBMb29rIGF0IGFuIGV4 YW1wbGUuDQoNCk15IGJhZC4gQXQgdGhhdCBtb21lbnQgSSB3YXMgdGhpbmtpbmcgaW4gdGVybXMg b2YgdGhlIG9sZCB2ZXJzaW9uIHdoZXJlIHplcm8gd2FzIGJhZC4gRHVubm8gd2h5LiBZb3UncmUg Y29ycmVjdC4NCg0KPiANCj4gTm93LCBhcyBJIHRoaW5rIGFib3V0IGl0LCB0aGUgc2ltcGxlc3Qg d2F5IGlzIHRvIHN0aWxsIHRoaW5rIG9mIHRoZQ0KPiByZXN1bHRzIGFzIGRpc3RhbmNlcywgd2l0 aCB0aGUgc21hbGxlc3QgZGlzdGFuY2UgYmVpbmcgdGhlIGJlc3QuIFRoZW4NCj4gdGhlIGFsZ29y aXRobSBpcw0KPiANCj4gYSkgdG9zcyBvdXQgYW55IHEgd2VpZ2h0cyB0aGF0IGFyZSB6ZXJvLiBB ZnRlciBhbGwsIHRoYXQgbWVhbnMgdGhhdCB5b3UNCj4gZ2l2ZSB0aGVtICpubyogcHJpb3JpdHku DQoNClVoLi4uIHlvdSBtYWRlIHRoZSBwb2ludCB0aGF0IGEgd2VpZ2h0IG9mIHplcm8gaGFzIGEg bWVhbmluZywgb25lIHRoYXQgd29ya3Mgd2VsbCB3aXRoIGRpdmlzaW9uOiBpdCBpcyAibmV2ZXIg cmV0dXJuIGNvbnRlbnQgaW4gdGhpcyBsYW5ndWFnZSIuIERJVi8wIGVycm9yIGlzIGEgZ29vZCB3 YXkgdG8gZmxhZyB0aGVzZSBpdGVtcy4gQXMgd2l0aDoNCg0KICBzciwgcT0xLjA7IHNyLUxhdG4s IHE9MC4wOyBlbiwgcT0wLjgNCg0KTWVhbnM6IEknZCBsaWtlIFNlcmJpYW4sIGJ1dCBuZXZlciBp biBMYXRpbiBzY3JpcHQsIGZvbGxvd2VkIGJ5IEVuZ2xpc2guDQoNCg0KPiANCj4gVGhlIHNxdWFy ZSByb290eSBzdHVmZiB3YXMganVzdCBiZWNhdXNlIGRpc3RhbmNlIG1ldHJpY3Mgd2l0aCBtdWx0 aXBsZQ0KPiBmaWVsZHMgd2VpZ2h0IGJldHRlciB3aGVuIHlvdSB0cmVhdCB0aGVtIGFzIGRpbWVu c2lvbmFsIHZlY3RvcnMuDQo+IEhvd2V2ZXIsIGluIHJldHJvc3BlY3QgaXQgaXMgcHJvYmFibHkg anVzdCBzaW1wbGVyIHRvIHRha2UgdGhlIG1pbmltdW0NCj4gb2YgdGhlIHBvc3NpYmxlIHdlaWdo dHMuIFNvIGlmIFEgbWF0Y2hlcyBYIHdpdGggYSBkaXN0YW5jZSBvZiwgc2F5LCAyLiBRDQo+IG1h dGNoZXMgWSB3aXRoIGEgZGlzdGFuY2Ugb2YgMTAuIFRoZW4gdGhlIHJlc3VsdCB3b3VsZCBiZSB0 aGUgbWluaW11bSwgb3INCj4gMS4NCg0KRm9yIGEgZ2l2ZW4gdGFnL3JhbmdlIG1hdGNoLCB5b3Ug Z2V0IGEgc2NvcmUuIFRoZSBsb3dlc3Qgc2NvcmUgd2lucy4gQSBzbWFydCBpbXBsZW1lbnRhdGlv biBoYXMgYSB0aHJlc2hvbGQgdmFsdWUuIFRoZSBmaXJzdCB2YWx1ZSBhYm92ZSB0aGUgdGhyZXNo b2xkIGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGlzIHRoZSBzY29yZSBmb3IgdGhlIGNv bnRlbnQgKHBlcmhhcHMgZXZlbiBpZiBhIGxhdGVyIHJhbmdlIG1pZ2h0IHNjb3JlIGhpZ2hlciku IEEgdGhyZXNob2xkIG9mIHplcm8gbWF0Y2hlcyBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBmaWx0 ZXJpbmcuDQoNCk9uZSBtb3JlIGZseSBpbiB0aGUgb2ludG1lbnQ6IGEgc2NvcmUgb2YgemVybyBp c24ndCBvcGVuIHRvIGNvZXJjaW9uIGJ5IHdlaWdodC4gQ29uc2lkZXIgdGhpcyBsYW5ndWFnZSBw cmlvcml0eSBsaXN0OiAiZW47IGZyOyBkZSIgYW5kIHRoaXMgdGFnOiAiZnItRlIiLiBUaGUgc2Nv cmUgZm9yIHRoZSB0YWcgd2l0aCAiZnIiIGlzIHplcm8gYW5kIHRoZSBmYWN0IHRoYXQgJ2ZyJyBp cyB3ZWlnaHRlZCBsb3dlciB0aGFuICJlbiIgaGFzIG5vIGVmZmVjdCBvbiB0aGlzLg0KDQpJIHRo aW5rIGl0IHdvdWxkIGJlIGJldHRlciBpZiB3ZSBjb3VsZCBmaW5kIGFuIGludGVnZXItb25seSBz Y29yaW5nIHNjaGVtZSB0aGF0IGRlYWxzIHdpdGggd2VpZ2h0cyBpbiBzb21lIGNvbnNpc3RlbnQg bWFubmVyLiBQZXJoYXBzOiBjcmVhdGUgc2NvcmVzIGZvciBlYWNoIHRhZyB2cy4gZWFjaCByYW5n ZSBpbiB0aGUgbGlzdC4gVGhlbiBhZGQgdGhlIHBvc2l0aW9uIGluIHRoZSBsaXN0IChzdGFydGlu ZyBhdCBiYXNlIHplcm8pIHRvIHRoZSBzY29yZS4gRm9yIHRoZSBleGFtcGxlIGFib3ZlLCB0aGUg c2NvcmUgZm9yICJmci1GUiIgaXMgIjEiIGFuZCB0aGUgc2NvcmUgZm9yICJkZSIgaXMgIjIiLg0K DQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJl Lg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmdd DQo+IFNlbnQ6IDIwMDXlubQxMeaciDE45pelIDEzOjQyDQo+IFRvOiBBZGRpc29uIFBoaWxsaXBz DQo+IENjOiBsdHJ1QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gZHJhZnQtMDYgY29t bWVudHM6IGNob2ljZSBvZiByYW5nZQ0KPiANCj4gDQo+IA0KPiBBZGRpc29uIFBoaWxsaXBzIHdy b3RlOg0KPiANCj4gDQo+ID4+QSBwcm90b2NvbCB3aGljaCB1c2VzIGxhbmd1YWdlIHByaW9yaXR5 IGxpc3RzIE1BWSBzcGVjaWZ5IGFuIGFsdGVybmF0aXZlDQo+ID4+bWVjaGFuaXNtIGZvciBjb21w dXRpbmcgdGhlIG9yZGVyaW5nLg0KPiA+Pg0KPiA+Pi0tLS0NCj4gPj4NCj4gPj5BIHByb3RvY29s IHdoaWNoIHVzZXMgbGFuZ3VhZ2UgcmFuZ2VzIE1BWSBzcGVjaWZ5IGFkZGl0aW9uYWwgcnVsZXMg YWJvdXQNCj4gPj50aGUgc2VtYW50aWNzIG9mICIqIjsNCj4gPj49Pg0KPiA+PkEgcHJvdG9jb2wg d2hpY2ggdXNlcyBsYW5ndWFnZSByYW5nZXMgTUFZIHNwZWNpZnkgYWRkaXRpb25hbCBydWxlcyBh Ym91dA0KPiA+PnRoZSBzZW1hbnRpY3Mgb2YgIioiIG9yIG90aGVyIHRhZ3M7DQo+ID4+W25vIHJl YXNvbiB0byByZXN0cmljdCBpdF0NCj4gPj4NCj4gPj4tLS0tDQo+ID4+DQo+ID4+SW1wbGVtZW50 YXRpb25zIG9yIHByb3RvY29scyBzb21ldGltZXMgbWlnaHQgd2lzaCB0byB1c2UgbW9yZQ0KPiA+ PnNvcGhpc3RpY2F0ZWQgd2VpZ2h0cyB0aGF0DQo+ID4+PT4NCj4gPj5JbXBsZW1lbnRhdGlvbnMg b3IgcHJvdG9jb2xzIHNvbWV0aW1lcyBNQVkgc3BlY2lmeSB0aGUgdXNlIG9mDQo+ID4+YWx0ZXJu YXRpdmUgd2VpZ2h0cyB0aGF0DQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4g Pg0KPiA+RWl0aGVyICIuLi5wcm90b2NvbHMgTUFZLi4uIiBvciAiLi4uIHByb3RvY29scyBzb21l dGltZXMgbWlnaHQuLi4iDQo+ID4NCj4gPg0KPiBzb21ldGltZXMgTUFZID0+IE1BWQ0KPiANCj4g PkkgY2hvc2Ugbm9uLW5vcm1hdGl2ZSBsYW5ndWFnZSBpbml0aWFsbHkgdG8gYWxsb3cgdGhpbmdz IHdpdGhvdXQgdHVybmluZw0KPiB0aGUgd2hvbGUgc2VjdGlvbiBpbnRvIFJGQyAyMTE5IHNvdXAu DQo+ID4NCj4gPg0KPiA+Pi0tLS0NCj4gPj5bTWFrZSBzdWJzZWN0aW9ucyBpbiBMb29rdXAuIEZp cnN0IGxhbmd1YWdlIHJhbmdlIGxvb2t1cCwgdGhlbiBsYW5ndWFnZQ0KPiA+PnByaW9yaXR5IGxp c3QgbG9va3VwLCB0aGVuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGxvb2t1cC5dDQo+ID4+DQo+ ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SSB0aGluayB0aGF0J3MgYW4gYXdm dWwgaWRlYS4NCj4gPg0KPiA+QW5kIG1ha2UgdXAgeW91ciBtaW5kOiB3ZSBSRU1PVkVEIGV4dGVu ZGVkIGxhbmd1YWdlIHJhbmdlIGxvb2t1cCBiZWNhdXNlDQo+IGl0IGRvZXNu4oCZdCBtYWtlIHNl bnNlLiBMb29rdXAgaXMgbm93IGNhc3QgYXMgSSBzdWdnZXN0ZWQgYWJvdmU6IGl0IGlzDQo+IHN0 cmljdGx5IGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCBiZWFzdCwgYnV0IGl0IHN0YXJ0cyBieSBk ZWZpbmVkIHRoZQ0KPiBtYXRjaCBiZXR3ZWVuIGEgdGFnIGFuZCBhIHJhbmdlLg0KPiA+DQo+ID4N Cj4gTGVtbWUgcmVsb29rIGF0IGl0LCBidXQgaXQgc2VlbXMgdG8gbWUgdGhhdCB5b3UgYXJlIGRv aW5nIGl0LCBidXQgKnZpYSoNCj4gdHJhbnNmb3JtaW5nIGl0LiAoYnV0IG1vcmUgaW4gYSBzZXBh cmF0ZSBtZXNzYWdlIGFueXdheSkuDQo+IA0KPiA+Pi0tLS0NCj4gPj5PdGhlciBleGFtcGxlcyBv ZiBsb29rdXAgbWlnaHQgaW5jbHVkZToNCj4gPj49Pg0KPiA+Pk90aGVyIGV4YW1wbGVzIG9mIGxv b2t1cCBpbmNsdWRlOg0KPiA+Plt0aGUgZXhhbXBsZXMgKmRvKiBpbmNsdWRlLiBubyBuZWVkIHRv IGJlIHRlbnRhdGl2ZSA7LSldDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4g Pg0KPiA+T2theS4NCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PklmIHRoaXMgbGFuZ3Vh Z2UgcmFuZ2UgaXMgdGhlIG9ubHkgb25lIGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCBp dA0KPiA+Pm1hdGNoZXMgdGhlIGRlZmF1bHQgY29udGVudC4gSWYgdGhpcyBsYW5ndWFnZSByYW5n ZSBpcyBmb2xsb3dlZCBieSBvdGhlcg0KPiA+Pmxhbmd1YWdlIHJhbmdlcywgaXQgc2hvdWxkIGJl IHNraXBwZWQuDQo+ID4+W2RvZXNuJ3QgYWRkcmVzcyAgKjsqXQ0KPiA+Pg0KPiA+Pg0KPiA+W0Fk ZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPlllcywgaXQgZG9lcy4uLiBpdGVyYXRpdmVseS4NCj4g Pg0KPiA+DQo+IFlvdSdyZSByaWdodC4NCj4gDQo+ID4NCj4gPg0KPiA+Pj0+DQo+ID4+QWxsICIq IiBsYW5ndWFnZSB0YWdzIGFyZSByZW1vdmVkIGZyb20gbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC4g SWYgdGhlcmUNCj4gPj5pcyBub3RoaW5nIGxlZnQsIHRoZW4gaXQgbWF0Y2hlcyB0aGUgZGVmYXVs dCBjb250ZW50Lg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPlRo YXQncyAicmFuZ2VzIiBpbiB5b3VyIGZpcnN0IHNlbnRlbmNlLg0KPiA+DQo+ID4NCj4gPj4tLS0t DQo+ID4+DQo+ID4+NS4gKGRlZmF1bHQgY29udGVudCBvciB0aGUgZW1wdHkgdGFnKQ0KPiA+Pj0+ DQo+ID4+NS4gKGRlZmF1bHQpDQo+ID4+W2V4cGxhaW4gYmVsb3cgd2hhdCB0aGlzIGlzLiBpdCBp cyBhbHNvIG90aGVyd2lzZSBvZGQgdGhhdCAxLTQgYXJlIHRhZ3MsDQo+ID4+YnV0IHRoZW4gdGhp cyBpcyAnY29udGVudCddDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0K PiA+T2theS4NCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PldoZW4gcGVyZm9ybWluZyBs b29rdXAgdXNpbmcgYSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCB0aGUgcHJvZ3Jlc3NpdmUNCj4g Pj5zZWFyY2ggTVVTVCBwcm9jZWVkIHRvIGNvbnNpZGVyIGVhY2ggbGFuZ3VhZ2UgcmFuZ2UgYmVm b3JlIGZpbmRpbmcgdGhlDQo+ID4+ZGVmYXVsdCBjb250ZW50IG9yIGVtcHR5IHRhZy4gVGhlIGRl ZmF1bHQgY29udGVudCBtaWdodCBiZSBjb250ZW50IHdpdGgNCj4gPj5ubyBsYW5ndWFnZSB0YWcg KG9yIHdpdGggYW4gZW1wdHkgdmFsdWUsIGFzIHdpdGggeG1sOmxhbmcgaW4gdGhlIFhNTA0KPiA+ PnNwZWNpZmljYXRpb24pLCBvciBpdCBtaWdodCBiZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgZGVz aWduYXRlZCBmb3IgdGhhdA0KPiA+PmJpdCBvZiBjb250ZW50Lg0KPiA+Pg0KPiA+Pk9uZSBjb21t b24gd2F5IHRvIHByb3ZpZGUgZm9yIGRlZmF1bHQgY29udGVudCBpcyB0byBhbGxvdyBhIHNwZWNp ZmljDQo+ID4+bGFuZ3VhZ2UgcmFuZ2UgdG8gYmUgc2V0IGFzIHRoZSBkZWZhdWx0IGZvciBhIHNw ZWNpZmljIHR5cGUgb2YgcmVxdWVzdC4NCj4gPj5UaGlzIGxhbmd1YWdlIHJhbmdlIGlzIHRoZW4g dHJlYXRlZCBhcyBpZiBpdCB3ZXJlIGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YNCj4gPj50aGUgbGFu Z3VhZ2UgcHJpb3JpdHkgbGlzdCwgcmF0aGVyIHRoYW4gYWZ0ZXIgZWFjaCBpdGVtIGluIHRoZSBs YW5ndWFnZQ0KPiA+PnByaW9yaXR5IGxpc3QuDQo+ID4+DQo+ID4+PT4NCj4gPj5bcmV3b3JkIGZv ciBjbGFyaXR5LiBGdW5ueSB0aGluZzogd2hlbiBJIGZpcnN0IHJlYWQgJ21pZ2h0IGJlIGNvbnRl bnQNCj4gPj53aXRoIG5vIGxhbmd1YWdlIHRhZycgSSByZWFkIGl0IGFzIHRoZSB2ZXJiICJiZSBj b250ZW50IHdpdGgiLCBsaWtlICJiZQ0KPiA+PmhhcHB5IHdpdGgiLiBUaGUgZW1wdHkgdGFnIGlz IG5vdCBhIHZhbGlkIGxhbmd1YWdlIHRhZywgc28gd2Ugc2hvdWxkIHNheQ0KPiA+PiJ1bmQiLCB0 aGVuIHNheSB0aGF0IGEgc3lzdGVtIGNhbiB1c2UgYWx0ZXJuYXRpdmVzLiBIZXJlIGlzIHRoZSB0 ZXh0Ll0NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5Obywgbm90 ICd1bmQnIChhbmQgSSAqaGF0ZSogJ3VuZCcpLiAnVW5kJyB3b3VsZCBiZSBhbiBleGFtcGxlIG9m IGFuDQo+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGRlY2lzaW9uLiBQZXJzb25hbGx5IEkgd291 bGQgcHJlZmVyIG5ldmVyIHRvIHNlZQ0KPiAndW5kJyBjb250ZW50IGJlaW5nIHVzZWQgYXMgYSBk ZWZhdWx0Lg0KPiA+DQo+ID4NCj4gV2VsbCwgIiIgaXMgaWxsZWdhbCBhcyBhIGxhbmd1YWdlLXRh Zywgc28gSSB3YXMganVzdCB1c2luZyBpdCBhcyBhDQo+IHN0YW5kLWluIGJlY2F1c2Ugd2UgZG9u J3QgaGF2ZSBhIGxhbmd1YWdlIHRhZyBmb3IgInJvb3QiLg0KPiANCj4gPj5XaGVuIHBlcmZvcm1p bmcgbG9va3VwIHVzaW5nIGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCwgdGhlIHByb2dyZXNzaXZl DQo+ID4+c2VhcmNoIE1VU1QgY29uc2lkZXIgZWFjaCBsYW5ndWFnZSByYW5nZSBiZWZvcmUgZmlu ZGluZyB0aGUgZGVmYXVsdC4gVGhlDQo+ID4+ZGVmYXVsdCBtaWdodCBiZSBzcGVjaWZpZWQgYXMg InVuZCIgKG9yIGJlIGluZGljYXRlZCB3aXRoIGFuIGVtcHR5DQo+ID4+dmFsdWUsIGFzIHdpdGgg eG1sOmxhbmcgaW4gdGhlIFhNTCBzcGVjaWZpY2F0aW9uLCBvciB3aXRoICJyb290IiBhcyBpbg0K PiA+PnNvbWUgc3lzdGVtcyksIG9yIGl0IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIHBhcnRpY3Vs YXIgbGFuZ3VhZ2UgcmFuZ2UuDQo+ID4+VGhpcyBsYW5ndWFnZSByYW5nZSBpcyB0aHVzIHRyZWF0 ZWQgYXMgaWYgaXQgd2VyZSBhcHBlbmRlZCB0byB0aGUgZW5kIG9mDQo+ID4+dGhlIGxhbmd1YWdl IHByaW9yaXR5IGxpc3QsIHJhdGhlciB0aGFuIGFmdGVyIGVhY2ggaXRlbSBpbiB0aGUgbGFuZ3Vh Z2UNCj4gPj5wcmlvcml0eSBsaXN0Lg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNd DQo+ID4NCj4gPkkgcHJlZmVyIG5vdCB0byBtYWtlIHRoaXMgY2hhbmdlLiBJIHRoaW5rIGl0IGRl bHZlcyB0b28gY2xvc2VseSBpbnRvIHRoZQ0KPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCj4g Pg0KPiA+DQo+IEl0IGNhbid0IGJlIGxlZnQgYXMgaXQgaXMuIE90aGVyIGFsdGVybmF0aXZlcz8N Cj4gDQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PjUuIChyZXR1cm4gZGVmYXVsdCBjb250ZW50KQ0KPiA+ PmEuIGphLUpQDQo+ID4+Yi4gamENCj4gPj5jLiAoZW1wdHkgdGFnIG9yIG90aGVyIGRlZmF1bHQg Y29udGVudCkNCj4gPj4NCj4gPj41LiAoZGVmYXVsdCkNCj4gPj5hLiBqYS1KUA0KPiA+PmIuIGph DQo+ID4+Yy4gdW5kDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ SG93IGFib3V0Og0KPiA+DQo+ID41LiAoZGVmYXVsdCBjb250ZW50IGxvb2t1cCkNCj4gPiAgIGEu IGphLUpQDQo+ID4gICBiLiBqYQ0KPiA+ICAgYy4gKGltcGxlbWVudGF0aW9uIGRlZmluZWQpDQo+ ID4NCj4gPg0KPiBUaGF0IHdvcmtzLg0KPiANCj4gPj4tLS0tDQo+ID4+DQo+ID4+V2lsZGNhcmQg dmFsdWVzIGluIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGFyZSBzdXBwb3NlZCB0byBtYXRj aCBhbnkNCj4gPj52YWx1ZQ0KPiA+Pj0+DQo+ID4+V2lsZGNhcmQgdmFsdWVzIGluIGFuIGV4dGVu ZGVkIGxhbmd1YWdlIHJhbmdlIG1hdGNoIGFueSB2YWx1ZQ0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlz b24gUGhpbGxpcHNdDQo+ID4NCj4gPk5vLCB0aGV5IGFyZSAqc3VwcG9zZWQqIHRvIG1hdGNoLCBi dXQgaW4gdGhpcyBjYXNlIHRoZXkgZG9uJ3QuIFRoZXkgbWF0Y2gNCj4gdGhlIGVtcHR5IHZhbHVl Lg0KPiA+DQo+ID4NCj4gSSByZWFkIHRoYXQgZGlmZmVyZW50bHkuIFdoZW4geW91IHNheSAic3Vw cG9zZWQgdG8gbWF0Y2giLCBpdCBzb3VuZHMNCj4gbGlrZSB0aGVyZSBpcyBhIGNob2ljZSwgdGhh dCB0aGVyZSBhcmUgc29tZSB2YWx1ZXMgdGhhdCB0aGV5IGRvbid0DQo+IG1hdGNoLiBMaWtlIHRo ZSBVUyBpcyAic3VwcG9zZWQgdG8iIGRpc2FsbG93IHRvcnR1cmUuDQo+IA0KPiA+Pi0tLS0NCj4g Pj4NCj4gPj5BZGQNCj4gPj4NCj4gPj4NCj4gPj4gICAgICAzLjMueC4gRGlzdGFuY2UgTWV0cmlj IExvb2t1cA0KPiA+Pg0KPiA+PkRpc3RhbmNlIG1ldHJpYyBsb29rdXAgaXMgcGVyZm9ybWVkIGJ5 IHByb2R1Y2luZyBhbiBvcmRlcmVkIGxpc3Qgb2YNCj4gPj5maWx0ZXJlZCByZXN1bHRzIGFzIHNw ZWNpZmllZCBpbiAzLjIuMiwgdGhlbiByZXR1cm5pbmcgdGhlIGZpcnN0IGl0ZW0uDQo+ID4+DQo+ ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+SSB0aGluayB3ZSdkIGJlc3Qgbm90 IGdvIGRvd24gdGhhdCBwYXRoLiBBbW9uZyBvdGhlciB0aGluZ3M6IGl0IHdvbid0DQo+IHdvcmsu IERpc3RhbmNlIG1ldHJpYyBmaWx0ZXJpbmcgY2FuIHByb2R1Y2UgaXRlbXMgd2l0aCBpZGVudGlj YWwgc2NvcmVzLi4uDQo+ID4NCj4gPg0KPiBPaywgZHJvcCBpdC4NCj4gDQo+ID4NCj4gPg0KPiA+ Pi0tLS0NCj4gPj4NCj4gPj5NYXJrDQo+ID4+DQo+ID4+UC5TLiBJIHN0aWxsIHRoaW5rIHRoYXQg dGhlIGV4dGVuZGVkIHJhbmdlIGxvb2t1cCBkb2Vzbid0IHF1aXRlIHdvcmssDQo+ID4+YnV0IEkn bGwgc2VuZCB0aGF0IGluIGEgc2VwYXJhdGUgbWVzc2FnZS4NCj4gPj4NCj4gPj4NCj4gPltBZGRp c29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5ObywgaXQgZG9lc24ndCB3b3JrIGFuZCB3ZSBlbGltaW5h dGVkIGl0LiBXZSd2ZSBtYXBwZWQgZXh0ZW5kZWQgcmFuZ2VzDQo+IG9udG8gYmFzaWMgcmFuZ2Vz LCB3aGljaCBkbyB3b3JrLCBwcm9kdWNpbmcgZGlmZmVyZW50IHJlc3VsdHMgdGhhbiB0aGUNCj4g bGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCBtaWdodCBsZWFkIG9uZSB0byBleHBlY3QuDQo+ID4NCj4g Pg0KPiBMZXQgbWUgbG9vayB0aGlzIG92ZXIgYWdhaW4uDQoNCg== --===============0977658191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0977658191==-- From ltru-bounces@ietf.org Fri Nov 18 17:41:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEvf-0007ji-Ot; Fri, 18 Nov 2005 17:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEvd-0007jS-RJ for ltru@megatron.ietf.org; Fri, 18 Nov 2005 17:41:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15233 for ; Fri, 18 Nov 2005 17:41:21 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdFDX-0006AE-5H for ltru@ietf.org; Fri, 18 Nov 2005 18:00:27 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:41:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 14:41:38 -0800 Message-ID: Thread-Topic: using 'und' for default content Thread-Index: AcXsiPeWXqsrBFbiRuCt6vRc6rzwbwABsEtA From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 22:41:39.0567 (UTC) FILETIME=[3D78D7F0:01C5EC91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ltru@ietf.org Subject: [Ltru] using 'und' for default content X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0923509045==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0923509045== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+Pg0KPiA+Pj0+DQo+ID4+W3Jld29yZCBmb3IgY2xhcml0eS4gRnVubnkgdGhpbmc6IHdoZW4g SSBmaXJzdCByZWFkICdtaWdodCBiZSBjb250ZW50DQo+ID4+d2l0aCBubyBsYW5ndWFnZSB0YWcn IEkgcmVhZCBpdCBhcyB0aGUgdmVyYiAiYmUgY29udGVudCB3aXRoIiwgbGlrZSAiYmUNCj4gPj5o YXBweSB3aXRoIi4gVGhlIGVtcHR5IHRhZyBpcyBub3QgYSB2YWxpZCBsYW5ndWFnZSB0YWcsIHNv IHdlIHNob3VsZCBzYXkNCj4gPj4idW5kIiwgdGhlbiBzYXkgdGhhdCBhIHN5c3RlbSBjYW4gdXNl IGFsdGVybmF0aXZlcy4gSGVyZSBpcyB0aGUgdGV4dC5dDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNv biBQaGlsbGlwc10NCj4gPg0KPiA+Tm8sIG5vdCAndW5kJyAoYW5kIEkgKmhhdGUqICd1bmQnKS4g J1VuZCcgd291bGQgYmUgYW4gZXhhbXBsZSBvZiBhbg0KPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp YyBkZWNpc2lvbi4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBuZXZlciB0byBzZWUNCj4gJ3Vu ZCcgY29udGVudCBiZWluZyB1c2VkIGFzIGEgZGVmYXVsdC4NCj4gPg0KPiA+DQo+IFdlbGwsICIi IGlzIGlsbGVnYWwgYXMgYSBsYW5ndWFnZS10YWcsIHNvIEkgd2FzIGp1c3QgdXNpbmcgaXQgYXMg YQ0KPiBzdGFuZC1pbiBiZWNhdXNlIHdlIGRvbid0IGhhdmUgYSBsYW5ndWFnZSB0YWcgZm9yICJy b290Ii4NCg0KV2UgaGF2ZSBwZXJmZWN0bHkgZ29vZCB0ZXh0IGRlc2NyaWJpbmcgdGhlIGRlZmF1 bHQgY29udGVudCwgSSB0aGluay4gSXQgaXMgaW1wbGVtZW50YXRpb24gZGVmaW5lZC4gSXQgbWln aHQgYmUgaW4gc29tZSBwcmVkZXRlcm1pbmVkIGxhbmd1YWdlLCBvciBpdCBtaWdodCBiZSB1bmxh YmVsZWQgb3IgaXQgbXVzdCBiZSB3aGF0ZXZlci4gQnV0IGl0IGRlZmluaXRlbHkgc2hvdWxkIG5v dCBiZSAndW5kJy4gV2Ugc2hvdWxkIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgdGhlIHVzZSBvZiAndW5k JyBhbmQgJ211bCcsIElNSE8uDQoNCldlIGRvbid0IG5lZWQgdG8gY29tcGxpY2F0ZSB0aGlzIHBh cnRpY3VsYXIgcG9pbnQgdG9vIG11Y2gsIEkgdGhpbmssIGJ5IGludHJvZHVjaW5nIGFsbCB0aGUg b3B0aW9ucy4NCg0KPiANCj4gPj5XaGVuIHBlcmZvcm1pbmcgbG9va3VwIHVzaW5nIGEgbGFuZ3Vh Z2UgcHJpb3JpdHkgbGlzdCwgdGhlIHByb2dyZXNzaXZlDQo+ID4+c2VhcmNoIE1VU1QgY29uc2lk ZXIgZWFjaCBsYW5ndWFnZSByYW5nZSBiZWZvcmUgZmluZGluZyB0aGUgZGVmYXVsdC4gVGhlDQo+ ID4+ZGVmYXVsdCBtaWdodCBiZSBzcGVjaWZpZWQgYXMgInVuZCIgKG9yIGJlIGluZGljYXRlZCB3 aXRoIGFuIGVtcHR5DQo+ID4+dmFsdWUsIGFzIHdpdGggeG1sOmxhbmcgaW4gdGhlIFhNTCBzcGVj aWZpY2F0aW9uLCBvciB3aXRoICJyb290IiBhcyBpbg0KPiA+PnNvbWUgc3lzdGVtcyksIG9yIGl0 IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgcmFuZ2UuDQo+ID4+ VGhpcyBsYW5ndWFnZSByYW5nZSBpcyB0aHVzIHRyZWF0ZWQgYXMgaWYgaXQgd2VyZSBhcHBlbmRl ZCB0byB0aGUgZW5kIG9mDQo+ID4+dGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QsIHJhdGhlciB0 aGFuIGFmdGVyIGVhY2ggaXRlbSBpbiB0aGUgbGFuZ3VhZ2UNCj4gPj5wcmlvcml0eSBsaXN0Lg0K PiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPkkgcHJlZmVyIG5vdCB0 byBtYWtlIHRoaXMgY2hhbmdlLiBJIHRoaW5rIGl0IGRlbHZlcyB0b28gY2xvc2VseSBpbnRvIHRo ZQ0KPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCj4gPg0KPiA+DQo+IEl0IGNhbid0IGJlIGxl ZnQgYXMgaXQgaXMuIE90aGVyIGFsdGVybmF0aXZlcz8NCg0KV2h5IG5vdD8gSGVyZSwgZm9yIHJl ZmVyZW5jZSwgaXMgd2hhdCBpdCBzYXlzOg0KDQotLQ0KV2hlbiBwZXJmb3JtaW5nIGxvb2t1cCB1 c2luZyBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QsIHRoZSBwcm9ncmVzc2l2ZSBzZWFyY2ggTVVT VCBwcm9jZWVkIHRvIGNvbnNpZGVyIGVhY2ggbGFuZ3VhZ2UgcmFuZ2UgYmVmb3JlIGZpbmRpbmcg dGhlIGRlZmF1bHQgY29udGVudCBvciBlbXB0eSB0YWcuIFRoZSBkZWZhdWx0IGNvbnRlbnQgbWln aHQgYmUgY29udGVudCB3aXRoIG5vIGxhbmd1YWdlIHRhZyAob3Igd2l0aCBhbiBlbXB0eSB2YWx1 ZSwgYXMgd2l0aCB4bWw6bGFuZyBpbiB0aGUgWE1MIHNwZWNpZmljYXRpb24pLCBvciBpdCBtaWdo dCBiZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgZGVzaWduYXRlZCBmb3IgdGhhdCBiaXQgb2YgY29u dGVudC4NCg0KT25lIGNvbW1vbiB3YXkgdG8gcHJvdmlkZSBmb3IgZGVmYXVsdCBjb250ZW50IGlz IHRvIGFsbG93IGEgc3BlY2lmaWMgbGFuZ3VhZ2UgcmFuZ2UgdG8gYmUgc2V0IGFzIHRoZSBkZWZh dWx0IGZvciBhIHNwZWNpZmljIHR5cGUgb2YgcmVxdWVzdC4gVGhpcyBsYW5ndWFnZSByYW5nZSBp cyB0aGVuIHRyZWF0ZWQgYXMgaWYgaXQgd2VyZSBhcHBlbmRlZCB0byB0aGUgZW5kIG9mIHRoZSBs YW5ndWFnZSBwcmlvcml0eSBsaXN0LCByYXRoZXIgdGhhbiBhZnRlciBlYWNoIGl0ZW0gaW4gdGhl IGxhbmd1YWdlIHByaW9yaXR5IGxpc3QuDQotLQ0KDQpJIGRvbid0IHNlZSB3aHkgeW91ciB2ZXJz aW9uIGlzIGFueSBkaWZmZXJlbnQsIGV4Y2VwdCB0aGF0IGl0IGludHJvZHVjZXMgJ3VuZCcuIE5v dGUgdGhhdCAiY29udGVudCB3aXRoIG5vIGxhbmd1YWdlIHRhZyIgaXMgbm90IHRoZSBzYW1lIGFz ICJjb250ZW50IHdpdGggdGhlIChpbGxlZ2FsKSBsYW5ndWFnZSB0YWcgKGVtcHR5IHN0cmluZyki Lg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3Qg U29mdHdhcmUNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlz IGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KPiBTZW50 OiAyMDA15bm0MTHmnIgxOOaXpSAxMzo0Mg0KPiBUbzogQWRkaXNvbiBQaGlsbGlwcw0KPiBDYzog bHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIGRyYWZ0LTA2IGNvbW1lbnRzOiBj aG9pY2Ugb2YgcmFuZ2UNCj4gDQo+IA0KPiANCj4gPj4tLS0tDQo+ID4+DQo+ID4+NS4gKHJldHVy biBkZWZhdWx0IGNvbnRlbnQpDQo+ID4+YS4gamEtSlANCj4gPj5iLiBqYQ0KPiA+PmMuIChlbXB0 eSB0YWcgb3Igb3RoZXIgZGVmYXVsdCBjb250ZW50KQ0KPiA+Pg0KPiA+PjUuIChkZWZhdWx0KQ0K PiA+PmEuIGphLUpQDQo+ID4+Yi4gamENCj4gPj5jLiB1bmQNCj4gPj4NCj4gPj4NCj4gPltBZGRp c29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5Ib3cgYWJvdXQ6DQo+ID4NCj4gPjUuIChkZWZhdWx0IGNv bnRlbnQgbG9va3VwKQ0KPiA+ICAgYS4gamEtSlANCj4gPiAgIGIuIGphDQo+ID4gICBjLiAoaW1w bGVtZW50YXRpb24gZGVmaW5lZCkNCj4gPg0KPiA+DQo+IFRoYXQgd29ya3MuDQo+IA0KPiA+Pi0t LS0NCj4gPj4NCj4gPj5XaWxkY2FyZCB2YWx1ZXMgaW4gYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFu Z2UgYXJlIHN1cHBvc2VkIHRvIG1hdGNoIGFueQ0KPiA+PnZhbHVlDQo+ID4+PT4NCj4gPj5XaWxk Y2FyZCB2YWx1ZXMgaW4gYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgbWF0Y2ggYW55IHZhbHVl DQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+Tm8sIHRoZXkgYXJl ICpzdXBwb3NlZCogdG8gbWF0Y2gsIGJ1dCBpbiB0aGlzIGNhc2UgdGhleSBkb24ndC4gVGhleSBt YXRjaA0KPiB0aGUgZW1wdHkgdmFsdWUuDQo+ID4NCj4gPg0KPiBJIHJlYWQgdGhhdCBkaWZmZXJl bnRseS4gV2hlbiB5b3Ugc2F5ICJzdXBwb3NlZCB0byBtYXRjaCIsIGl0IHNvdW5kcw0KPiBsaWtl IHRoZXJlIGlzIGEgY2hvaWNlLCB0aGF0IHRoZXJlIGFyZSBzb21lIHZhbHVlcyB0aGF0IHRoZXkg ZG9uJ3QNCj4gbWF0Y2guIExpa2UgdGhlIFVTIGlzICJzdXBwb3NlZCB0byIgZGlzYWxsb3cgdG9y dHVyZS4NCj4gDQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PkFkZA0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAg IDMuMy54LiBEaXN0YW5jZSBNZXRyaWMgTG9va3VwDQo+ID4+DQo+ID4+RGlzdGFuY2UgbWV0cmlj IGxvb2t1cCBpcyBwZXJmb3JtZWQgYnkgcHJvZHVjaW5nIGFuIG9yZGVyZWQgbGlzdCBvZg0KPiA+ PmZpbHRlcmVkIHJlc3VsdHMgYXMgc3BlY2lmaWVkIGluIDMuMi4yLCB0aGVuIHJldHVybmluZyB0 aGUgZmlyc3QgaXRlbS4NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ ID5JIHRoaW5rIHdlJ2QgYmVzdCBub3QgZ28gZG93biB0aGF0IHBhdGguIEFtb25nIG90aGVyIHRo aW5nczogaXQgd29uJ3QNCj4gd29yay4gRGlzdGFuY2UgbWV0cmljIGZpbHRlcmluZyBjYW4gcHJv ZHVjZSBpdGVtcyB3aXRoIGlkZW50aWNhbCBzY29yZXMuLi4NCj4gPg0KPiA+DQo+IE9rLCBkcm9w IGl0Lg0KPiANCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+Pk1hcmsNCj4gPj4NCj4gPj5Q LlMuIEkgc3RpbGwgdGhpbmsgdGhhdCB0aGUgZXh0ZW5kZWQgcmFuZ2UgbG9va3VwIGRvZXNuJ3Qg cXVpdGUgd29yaywNCj4gPj5idXQgSSdsbCBzZW5kIHRoYXQgaW4gYSBzZXBhcmF0ZSBtZXNzYWdl Lg0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPk5vLCBpdCBkb2Vz bid0IHdvcmsgYW5kIHdlIGVsaW1pbmF0ZWQgaXQuIFdlJ3ZlIG1hcHBlZCBleHRlbmRlZCByYW5n ZXMNCj4gb250byBiYXNpYyByYW5nZXMsIHdoaWNoIGRvIHdvcmssIHByb2R1Y2luZyBkaWZmZXJl bnQgcmVzdWx0cyB0aGFuIHRoZQ0KPiBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IG1pZ2h0IGxlYWQg b25lIHRvIGV4cGVjdC4NCj4gPg0KPiA+DQo+IExldCBtZSBsb29rIHRoaXMgb3ZlciBhZ2Fpbi4N Cg0K --===============0923509045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0923509045==-- From ltru-bounces@ietf.org Fri Nov 18 17:56:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdF9D-0002Ni-VS; Fri, 18 Nov 2005 17:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdF9C-0002Ml-LM for ltru@megatron.ietf.org; Fri, 18 Nov 2005 17:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15748 for ; Fri, 18 Nov 2005 17:55:24 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdFR7-0006RH-TS for ltru@ietf.org; Fri, 18 Nov 2005 18:14:30 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:55:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 14:55:47 -0800 Message-ID: Thread-Topic: mapping ext-lang-range to basic in lookup Thread-Index: AcXsiPeWXqsrBFbiRuCt6vRc6rzwbwACFSLQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 18 Nov 2005 22:55:48.0942 (UTC) FILETIME=[37BD2EE0:01C5EC93] X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: ltru@ietf.org Subject: [Ltru] mapping ext-lang-range to basic in lookup X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1330819126==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1330819126== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+Pi0tLS0NCj4gPj4NCj4gPj5XaWxkY2FyZCB2YWx1ZXMgaW4gYW4gZXh0ZW5kZWQgbGFuZ3Vh Z2UgcmFuZ2UgYXJlIHN1cHBvc2VkIHRvIG1hdGNoIGFueQ0KPiA+PnZhbHVlDQo+ID4+PT4NCj4g Pj5XaWxkY2FyZCB2YWx1ZXMgaW4gYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgbWF0Y2ggYW55 IHZhbHVlDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+Tm8sIHRo ZXkgYXJlICpzdXBwb3NlZCogdG8gbWF0Y2gsIGJ1dCBpbiB0aGlzIGNhc2UgdGhleSBkb24ndC4g VGhleSBtYXRjaA0KPiB0aGUgZW1wdHkgdmFsdWUuDQo+ID4NCj4gPg0KPiBJIHJlYWQgdGhhdCBk aWZmZXJlbnRseS4gV2hlbiB5b3Ugc2F5ICJzdXBwb3NlZCB0byBtYXRjaCIsIGl0IHNvdW5kcw0K PiBsaWtlIHRoZXJlIGlzIGEgY2hvaWNlLCB0aGF0IHRoZXJlIGFyZSBzb21lIHZhbHVlcyB0aGF0 IHRoZXkgZG9uJ3QNCj4gbWF0Y2guIExpa2UgdGhlIFVTIGlzICJzdXBwb3NlZCB0byIgZGlzYWxs b3cgdG9ydHVyZS4NCg0KV2hlbiBjb25zaWRlcmVkIGluIGlzb2xhdGlvbiwgSSBzdXBwb3NlIG9u ZSBjb3VsZCBoYXZlIHRoYXQgcmVhZGluZywgYnV0IEkgdGhpbmsgdGhlIHRleHQgaXMgYWN0dWFs bHkgcHJldHR5IGNsZWFyIGhlcmUuIFBlcmhhcHMgaXQgY291bGQgYmUgY2xlYXJlci4gVGhlIG1p c3NpbmcgcG9pbnQgdGhhdCBJIHdhcyB0cnlpbmcgdG8gY29udmV5IGlzIHRoYXQgZXh0ZW5kZWQg bGFuZ3VhZ2UgcmFuZ2VzIGRvIG5vdCBwcm9kdWNlIHRoZSBleHBlY3RlZCByZXN1bHRzIGJhc2Vk IG9uIHRoZWlyIG1lYW5pbmcuIFRoZSByYW5nZSAiZW4tKi1VUyIgd2lsbCBuZXZlciBwYXNzIHRo cm91Z2ggY29udGVudCBsYWJlbGVkICJlbi1CcmFpIiAob3IgYW55IG90aGVyIGNvbnRlbnQgd2l0 aCBhIHNjcmlwdCBzdWJ0YWcpLCBldmVuIHRob3VnaCB0aGlzIG1hdGNoZXMgdGhlIG1lYW5pbmcg b2YgdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlLiBGcm9tICJlbi1VUyIgeW91IHNraXAgaW1t ZWRpYXRlbHkgdG8gImVuIi4gSXQgaXMgc3VwcG9zZWQgdG8gbWF0Y2guLi4gYW5kIGl0IGRvZXNu J3QuDQoNCkkgdGhpbmsgd2UgbWlnaHQgbWFrZSBhIHZlcnNpb24gb2YgdGhlIGNoYW5nZSB5b3Ug c3VnZ2VzdCBhbmQgdGhlbiBzcGVsbCBvdXQgbXkgZXhhbXBsZS4NCg0KVGhlIHRleHQgY3VycmVu dGx5Og0KDQotLQ0KSW4gc29tZSBjYXNlcywgdGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgbWln aHQgY29udGFpbiBvbmUgb3IgbW9yZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgKGFzLCBmb3Ig ZXhhbXBsZSwgd2hlbiB0aGUgc2FtZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IGlzIHVzZWQgYXMg aW5wdXQgZm9yIGJvdGggbG9va3VwIGFuZCBmaWx0ZXJpbmcgb3BlcmF0aW9ucykuIFdpbGRjYXJk IHZhbHVlcyBpbiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBhcmUgc3VwcG9zZWQgdG8gbWF0 Y2ggYW55IHZhbHVlIHRoYXQgb2NjdXJzIGluIHRoYXQgcG9zaXRpb24gaW4gYSBsYW5ndWFnZSB0 YWcuIFNpbmNlIG9ubHkgb25lIGl0ZW0gY2FuIGJlIHJldHVybmVkIGZvciBhbnkgZ2l2ZW4gbG9v a3VwIHJlcXVlc3QsIHRoZSB3aWxkY2FyZHMgbXVzdCBiZSBwcm9jZXNzZWQgaW4gYSBwcmVkaWN0 YWJsZSBtYW5uZXIgKG9yIHRoZSBzYW1lIHJlcXVlc3QgbWlnaHQgcHJvZHVjZSB3aWRlbHkgdmFy eWluZyByZXN1bHRzKS4gVGh1cywgZm9yIGVhY2ggcmFuZ2UgaW4gdGhlIGxhbmd1YWdlIHByaW9y aXR5IGxpc3QsIHRoZSBmb2xsb3dpbmcgcnVsZXMgbXVzdCBiZSBhcHBsaWVkIHRvIHByb2R1Y2Ug YSBiYXNpYyBsYW5ndWFnZSByYW5nZSBmb3IgdXNlIGluIHRoZSBmYWxsYmFjayBtZWNoYW5pc206 DQotLQ0KDQpQcm9wb3NlZCBjaGFuZ2U6DQoNCi0tDQouLi5XaWxkY2FyZCB2YWx1ZXMgaW4gYW4g ZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2Ugbm9ybWFsbHkgbWF0Y2ggYW55IHZhbHVlIHRoYXQgb2Nj dXJzIGluIHRoYXQgcG9zaXRpb24gaW4gYSBsYW5ndWFnZSB0YWcuLi4gDQotLQ0KDQpBbmQgdGhl biBhZGQgKGFmdGVyIHRoZSBleGFtcGxlKToNCg0KLS0NClRoZSByZXN1bHRpbmcgYmFzaWMgbGFu Z3VhZ2UgcmFuZ2VzIHdpbGwgcHJvZHVjZSBkaWZmZXJlbnQgcmVzdWx0cyB0aGF0IHRoZSB1c2Vy IG1pZ2h0IGV4cGVjdC4gRm9yIGV4YW1wbGUsIGEgcmVxdWVzdCBmb3IgImVuLSotVVMiIHdpbGwg bmV2ZXIgZmluZCBjb250ZW50IGxhYmVsZWQgImVuLUJyYWkiLCBldmVuIHRob3VnaCB0aGlzIHRh ZyBtYXRjaGVzIHRoZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZS4NCi0tDQoNCg0KQWRkaXNvbiBQ LiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCklu dGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1 cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmsgRGF2aXMg W21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NCj4gU2VudDogMjAwNeW5tDEx5pyI MTjml6UgMTM6NDINCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6IGx0cnVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtMdHJ1XSBkcmFmdC0wNiBjb21tZW50czogY2hvaWNlIG9mIHJhbmdl DQo+IA0KPiANCj4gDQo+IEFkZGlzb24gUGhpbGxpcHMgd3JvdGU6DQo+IA0KPiA+Q29tbWVudHMg aW50ZXJsaW5lYXJseSBiZWxvdy4gSSBoYXZlIHNvbWUgc3Ryb25nIHJlc2VydmF0aW9ucyBhYm91 dCBzb21lDQo+IG9mIHRoZXNlIGNvbW1lbnRzLg0KPiA+DQo+ID5BZGRpc29uDQo+ID4NCj4gPkFk ZGlzb24gUC4gUGhpbGxpcHMNCj4gPkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0 d2FyZQ0KPiA+DQo+ID5JbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiA+ SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ID4NCj4gPg0KPiA+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+RnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1 LXByb2plY3Qub3JnXQ0KPiA+PlNlbnQ6IDIwMDXlubQxMeaciDE45pelIDEwOjE1DQo+ID4+VG86 IEFkZGlzb24gUGhpbGxpcHMNCj4gPj5DYzogbHRydUBpZXRmLm9yZw0KPiA+PlN1YmplY3Q6IFJl OiBbTHRydV0gZHJhZnQtMDYgY29tbWVudHM6IGNob2ljZSBvZiByYW5nZQ0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+Ly8gdGV4dCByZW1vdmVkDQo+ID4NCj4gPg0KPiAvLyBqdXN0IGtlZXAgdGhlIHRl eHQsIG1ha2VzIGl0IGhhcmRlciB0byB0ZWxsIHdoYXQgeW91IGFyZSBjb21tZW50aW5nDQo+IG9u IDstKQ0KPiANCj4gPj5bVGhlICJ0aGlzIGFsc28gbWVhbnMiIG9ubHkgYXBwbGllcyB3aGVuIHRo ZSBpbXBsZW1lbmF0aW9uIGRvZXMgdGhlIE1BWS5dDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQ aGlsbGlwc10NCj4gPg0KPiA+QWdyZWVkLCBhbHRob3VnaCBJIHRlbmQgdG8gdGhpbmsgd2Ugc2hv dWxkIGdvIHRoZSBvdGhlciBkaXJlY3Rpb24gYW5kIHNheQ0KPiBNVVNULg0KPiA+DQo+ID4NCj4g SWYgd2Ugc2F5IG11c3QsIHRoZW4gd2UgYXJlIHJlYWxseSBzYXlpbmcgdGhhdCBhbnkgaW5wdXQg cmFuZ2UgeC15LXotdw0KPiBhY3RzIGxpa2UgeC0qLXktKi16LSotdywgd2hlbmV2ZXIgc29tZXRo aW5nIGNvdWxkIGdvIGJldHdlZW4uIFNpbmNlIHdlDQo+IHNheSB0aGUgYWxnb3JpdGhtcyB3b3Jr IGluIHRoZSBhYnNlbmNlIG9mIHBhcnNpbmcgdGhlIGxhbmd1YWdlIHRhZywgdGhhdA0KPiBtZWFu cyBwdXR0aW5nIHRoZW0gaW4gYWxsIHRoZSB0aW1lLiBTZWVtcyBsaWtlIGEgYml0IG11Y2gsIGJ1 dCBJJ2xsIG11bGwNCj4gaXQgb3Zlci4NCj4gDQo+ID4+LS0tLQ0KPiA+Pg0KPiA+Pm1lYXN1cm1l bnQNCj4gPj5bc3BlbGwtY2hlY2tdDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10N Cj4gPg0KPiA+VGhhbmtzLg0KPiA+DQo+ID4NCj4gPj4tLS0tDQo+ID4+DQo+ID4+W0dlbmVyYWwg T2JzZXJ2YXRpb24uDQo+ID4+DQo+ID4+V2UgbmVlZCB0byBnaXZlIGEgbWVjaGFuaXNtIHRoYXQg d2lsbCBhbHdheXMgZ2l2ZSBhIHByZWNpc2UsIGRldGVybWluYW50DQo+ID4+YW5zd2VyLiBXZSB0 aGVuIGxldCBwcm90b2NvbHMgc3BlY2lmeSBhbHRlcm5hdGl2ZXMgKGlmIHRoZXkgbmVlZCB0bykg YnkNCj4gPj5hZGRpdGlvbmFsIHNwZWNpZmljYXRpb24uIEluIHBhcnRpY3VsYXIsIGluIGVhY2gg c2VjdGlvbiB3ZSBoYXZlIHRvIG1ha2UNCj4gPj5jbGVhciB3aGF0IGV4YWN0bHkgaGFwcGVucyB3 aXRoIGEgbGFuZ3VhZ2UgcmFuZ2UsIGFuZCB3aGF0IGhhcHBlbnMgd2l0aA0KPiA+PmEgbGFuZ3Vh Z2UgcHJpb3JpdHkgbGlzdC4NCj4gPj4NCj4gPj5Gb3IgZmlsdGVyaW5nLCB0aGlzIGNhbiBiZSBk b25lIGJ5IG1vdmluZyB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgbGFuZ3VhZ2UNCj4gPj5wcmlvcml0 eSBsaXN0IHVwIGludG8gMy4yLiBdDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGlsbGlwc10N Cj4gPg0KPiA+QWN0dWFsbHksIEknZCBnbyBmdXJ0aGVyIGFuZCBzdWdnZXN0IHRoYXQgYWxsIG9m IHRoZSBtYXRjaGluZyBzY2hlbWVzIGJlDQo+IGRlZmluZWQgaW4gdGVybXMgb2YgbGFuZ3VhZ2Ug cHJpb3JpdHkgbGlzdHMgKGEgbGFuZ3VhZ2UgcmFuZ2UgYnkgaXRzZWxmDQo+IGJlaW5nIHRoZSBj b2xsYXBzZWQgY2FzZSBvZiBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3Qgd2l0aCBvbmx5IG9uZSBp dGVtLS0NCj4gaW5zaWRlIHRoZSBzcGVjaWZpYyBzY2hlbWUgd2UgZGVzY3JpYmUgaG93IHRvIG1h dGNoIGEgc2luZ2xlIHJhbmdlIHRvIGENCj4gc2luZ2xlIHRhZywgYnV0IHRoZSBzY2hlbWUgb3Zl cmFsbCBtYXRjaGVzIHRoZSB1c2VyJ3MgbGFuZ3VhZ2UNCj4gcHJlZmVyZW5jZXMtLWEgbGlzdC0t YWdhaW5zdCBjb250ZW50KS4gTG9va3VwIG5vdyByZWFkcyB0aGlzIHdheS4NCj4gPg0KPiBUaGF0 IHdvcmtzIHRvby4gVGhlbiB3ZSBqdXN0IHNheSBhdCB0aGUgdmVyeSB0b3AgdGhhdCBhbGwgdGhl IG1lY2hhbmlzbXMNCj4gdHJlYXQgYSBzaW5nbGUgbGFuZ3VhZ2UgcmFuZ2UgYXMgYSBzaW5nbGUg ZWxlbWVudCBsYW5ndWFnZSBwcmlvcml0eSBsaXN0Lg0KPiANCj4gPlRoaXMgc2VjdGlvbiAzLjIg dGV4dDoNCj4gPg0KPiA+LS0NCj4gPkZpbHRlcmluZyBpcyB1c2VkIHRvIHNlbGVjdCB0aGUgc2V0 IG9mIGNvbnRlbnQgdGhhdCBtYXRjaGVzIGEgZ2l2ZW4NCj4gcHJlZml4Lg0KPiA+LS0NCj4gPg0K PiA+U2hvdWxkIGJlIG1vZGlmaWVkIHRvIHNheToNCj4gPg0KPiA+LS0NCj4gPkZpbHRlcmluZyBp cyB1c2VkIHRvIHNlbGVjdCB0aGUgc2V0IG9mIGNvbnRlbnQgdGhhdCBtYXRjaGVzIHRoZSB1c2Vy J3MNCj4gbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgKHNlZSBTZWN0aW9uIDIuMSwgTGFuZ3VhZ2UgUHJp b3JpdHkgTGlzdHMpLg0KPiA+LS0NCj4gPg0KPiA+QmVmb3JlIG9iamVjdGluZyB0byB0aGlzIGNo YW5nZSBiZWNhdXNlIGl0IHJlbW92ZXMgdGhlIGNyaXRpY2FsIHBvaW50DQo+IGFib3V0IHRoZSBy YW5nZSBiZWluZyBhIHByZWZpeCwgY29uc2lkZXIgdGhhdCB0aGUgZW50aXJlIHNlY29uZCBwYXJh Z3JhcGgNCj4gb2YgdGhpcyBzZWN0aW9uIGNvdmVycyB0aGF0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ PjMuMi4NCj4gPj5JZiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCAoc2VlIFNlY3Rpb24gMi4x IChMaXN0cyBvZiBMYW5ndWFnZQ0KPiA+PlJhbmdlcykNCj4gPj48aHR0cDovL3d3dy5pbnRlci1s b2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1tYXRjaGluZy0wNy5odG1sI2xpc3RzPikNCj4g Pj5jb250YWlucyBtb3JlIHRoYW4gb25lIHJhbmdlLCB0aGUgY29udGVudCByZXR1cm5lZCBpcyB0 eXBpY2FsbHkgb3JkZXJlZA0KPiA+PmluIGRlc2NlbmRpbmcgbGV2ZWwgb2YgcHJlZmVyZW5jZS4N Cj4gPj49Pg0KPiA+PklmIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IChzZWUgU2VjdGlvbiAy LjEgKExpc3RzIG9mIExhbmd1YWdlDQo+ID4+UmFuZ2VzKQ0KPiA+PjxodHRwOi8vd3d3LmludGVy LWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA3Lmh0bWwjbGlzdHM+KQ0K PiA+PmNvbnRhaW5zIG1vcmUgdGhhbiBvbmUgcmFuZ2UsIHRoZSBjb250ZW50cyB0aGF0IG1hdGNo IHRoYXQgcmFuZ2UgYXJlDQo+ID4+YWRkZWQgdG8gdGhlIHNldCBvZiByZXN1bHRzLg0KPiA+Pg0K PiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPlRoZSB3b3JkIGNvbnRlbnQgaW4g dGhpcyBzZW50ZW5jZSBpcyBhbHJlYWR5IHBsdXJhbC4gIkNvbnRlbnRzIiBpcyB3cm9uZy4NCj4g SWYgd2Ugd2FudCB0byBiZSBleHBsaWNpdCBhYm91dCBpdCwgd2Ugc2hvdWxkIHVzZSB0aGUgcHJl dmlvdXNseSBxdW90ZWQNCj4gZm9ybXVsYXRpb24gInNldCBvZiBjb250ZW50Ii4NCj4gPg0KPiA+ DQo+IHNldCBvZiBjb250ZW50IHdvcmtzLg0KPiANCj4gPg0KPiA+DQo+ID4+W0F0IHRoZSBlbmQg b2YgdGhlIHNlY3Rpb24sIGFmdGVyIHdlJ3ZlIGludHJvZHVjZWQgdGhlIGRpc2N1c3Npb24gb2Yg YW4NCj4gPj5vcmRlcmVkIGxpc3QgYW5kIGRpc3RhbmNlIG1ldHJpYywgYWRkXQ0KPiA+Pg0KPiA+ PldoZW4gdGhlIHNldCBvZiBtYXRjaGVzIGlzIHJldHVybmVkLCB0aGUgaXRlbXMgYXJlIGluIGRl c2NlbmRpbmcgb3JkZXINCj4gPj53aGVyZSB0aGUgd2VpZ2h0IGZvciBlYWNoIGl0ZW0gaXMgdGhl IHByaW9yaXR5IGluIHRoZSBsYW5ndWFnZSBwcmlvcml0eQ0KPiA+Pmxpc3QgZGl2aWRlZCBieSB0 aGUgZGlzdGFuY2UgbWV0cmljLiAoSWYgdGhlIGZpbHRlcmluZyBtZXRob2QgZG9lcyBub3QNCj4g Pj5zdXBwbHkgYSBkaXN0YW5jZSBtZXRyaWMsIHRoZW4gdGhlIGRpc3RhbmNlIG1ldHJpYyBpcyAx LikgSWYgdGhlIGl0ZW0NCj4gPj5tYXRjaGVzIG11bHRpcGxlIHJhbmdlcywgdGhlbiBpdHMgd2Vp Z2h0IGlzIHRoZSBzcXVhcmUgcm9vdCBvZiB0aGUgc3VtDQo+ID4+b2Ygc3F1YXJlcyBvZiB0aGUg aW5kaXZpZHVhbCB3ZWlnaHRzIGZvciBlYWNoIHJhbmdlLiBJZiB0d28gaXRlbXMgaGF2ZQ0KPiA+ PnRoZSBzYW1lIHdlaWdodCwgdGhlbiB0aGVpciBvcmRlcmluZyBpcyBiYXNlZCBvbiBhIGNhc2Ut aW5zZW5zaXRpdmUNCj4gPj5vcmRlcmluZyBvZiB0aGUgbGFuZ3VhZ2UgdGFncy4NCj4gPj4NCj4g Pj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5VZ2guIElja3kuIE1hbnkgaXRlbXMg d2lsbCBoYXZlIHRoZSBzYW1lIHdlaWdodCBldmVuIGluIHNwaXRlIG9mIHRoaXMNCj4gY29tcGxl eCBzY2hlbWUuDQo+ID4NCj4gPg0KPiBDYW4ndCBnZXQgYXJvdW5kIHRoYXQuIElmIHByaW9yaXRp ZXMgYXJlIGVxdWFsIGFuZCB0aGVyZSBpcyBubyBkaXN0YW5jZQ0KPiBtZXRyaWMsIHRoZW4geW91 IGVzc2VudGlhbGx5IGhhdmUgYW4gdW5vcmRlcmVkIGxpc3QuDQo+IA0KPiA+SSBub3RlIHRoYXQg cSB3ZWlnaHRzIGluIEFjY2VwdC1MYW5ndWFnZSBhcmUgYWx3YXlzIGxlc3MgdGhhbiBvciBlcXVh bCB0bw0KPiBvbmUgYW5kIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byB6ZXJvLiBZb3VyIGFsZ29y aXRobSB3b24ndCB3b3JrIGNvcnJlY3RseQ0KPiB3aXRoIHRob3NlIHZhbHVlcyAoaW5zdGVhZCBt dWx0aXBsaWNhdGlvbiBvZiB0aGUgc2NvcmUgd29ya3MgYmV0dGVyKS4NCj4gPg0KPiA+DQo+IA0K PiBZb3UncmUgcmlnaHQgdGhhdCB0aGVyZSBpcyBhIG51bWVyaWMgcHJvYmxlbSwgYnV0IHlvdSBj YW4ndCBtdWx0aXBseSwNCj4gYmVjYXVzZSBzbWFsbGVyIGRpc3RhbmNlcyBhcmUgYmV0dGVyLCBi dXQgbG93ZXIgcHJpb3JpdGllcyBhcmUgKndvcnNlKi4NCj4gU28geW91IGhhdmUgdG8gZGl2aWRl IG9uZSB3YXkgb3IgYW5vdGhlci4gTG9vayBhdCBhbiBleGFtcGxlLg0KPiANCj4gWCwgcT0wLjU7 IFksIHE9MC4zOw0KPiANCj4gWiBtYXRjaGVzIFggd2l0aCBhIGRpc3RhbmNlIG9mLCBzYXksIDIu IFcgbWF0Y2hlcyBZIHdpdGggYSBkaXN0YW5jZSBvZg0KPiAxMC4gSWYgeW91IG11bHRpcGx5LCB5 b3UgZ2V0DQo+IA0KPiBaIC0+ICgwLjUgKiAyKSA9IDENCj4gVyAtPiAoMC4zKSAqIDEwKSA9ICAz DQo+IA0KPiBUaGF0IHdvdWxkIHJhbmsgWSBiZXR0ZXIgdGhhbiBaISBXaGF0IHlvdSB3YW50IGlz IGEgZGl2aXNpb24uDQo+IA0KPiBOb3csIGFzIEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBzaW1wbGVz dCB3YXkgaXMgdG8gc3RpbGwgdGhpbmsgb2YgdGhlDQo+IHJlc3VsdHMgYXMgZGlzdGFuY2VzLCB3 aXRoIHRoZSBzbWFsbGVzdCBkaXN0YW5jZSBiZWluZyB0aGUgYmVzdC4gVGhlbg0KPiB0aGUgYWxn b3JpdGhtIGlzDQo+IA0KPiBhKSB0b3NzIG91dCBhbnkgcSB3ZWlnaHRzIHRoYXQgYXJlIHplcm8u IEFmdGVyIGFsbCwgdGhhdCBtZWFucyB0aGF0IHlvdQ0KPiBnaXZlIHRoZW0gKm5vKiBwcmlvcml0 eS4NCj4gYikgZGl2aWRlIHRoZSBkaXN0YW5jZSBieSB0aGUgcHJpb3JpdHkuDQo+IGMpIG9yZGVy IGluIGFzY2VuZGluZyBvcmRlcg0KPiANCj4gWiAtPiAoMiAvIDAuNSkgPSAxDQo+IFcgLT4gKDEw IC8gMC4zKSA9IDMzLjMzDQo+IA0KPiB3aGljaCByYW5rcyB0aGVtIGNvcnJlY3RseS4NCj4gDQo+ IFRoZSBzcXVhcmUgcm9vdHkgc3R1ZmYgd2FzIGp1c3QgYmVjYXVzZSBkaXN0YW5jZSBtZXRyaWNz IHdpdGggbXVsdGlwbGUNCj4gZmllbGRzIHdlaWdodCBiZXR0ZXIgd2hlbiB5b3UgdHJlYXQgdGhl bSBhcyBkaW1lbnNpb25hbCB2ZWN0b3JzLg0KPiBIb3dldmVyLCBpbiByZXRyb3NwZWN0IGl0IGlz IHByb2JhYmx5IGp1c3Qgc2ltcGxlciB0byB0YWtlIHRoZSBtaW5pbXVtDQo+IG9mIHRoZSBwb3Nz aWJsZSB3ZWlnaHRzLiBTbyBpZiBRIG1hdGNoZXMgWCB3aXRoIGEgZGlzdGFuY2Ugb2YsIHNheSwg Mi4gUQ0KPiBtYXRjaGVzIFkgd2l0aCBhIGRpc3RhbmNlIG9mIDEwLiBUaGVuIHRoZSByZXN1bHQg d291bGQgYmUgdGhlIG1pbmltdW0sIG9yDQo+IDEuDQo+IA0KPiA+PkEgcHJvdG9jb2wgd2hpY2gg dXNlcyBsYW5ndWFnZSBwcmlvcml0eSBsaXN0cyBNQVkgc3BlY2lmeSBhbiBhbHRlcm5hdGl2ZQ0K PiA+Pm1lY2hhbmlzbSBmb3IgY29tcHV0aW5nIHRoZSBvcmRlcmluZy4NCj4gPj4NCj4gPj4tLS0t DQo+ID4+DQo+ID4+QSBwcm90b2NvbCB3aGljaCB1c2VzIGxhbmd1YWdlIHJhbmdlcyBNQVkgc3Bl Y2lmeSBhZGRpdGlvbmFsIHJ1bGVzIGFib3V0DQo+ID4+dGhlIHNlbWFudGljcyBvZiAiKiI7DQo+ ID4+PT4NCj4gPj5BIHByb3RvY29sIHdoaWNoIHVzZXMgbGFuZ3VhZ2UgcmFuZ2VzIE1BWSBzcGVj aWZ5IGFkZGl0aW9uYWwgcnVsZXMgYWJvdXQNCj4gPj50aGUgc2VtYW50aWNzIG9mICIqIiBvciBv dGhlciB0YWdzOw0KPiA+PltubyByZWFzb24gdG8gcmVzdHJpY3QgaXRdDQo+ID4+DQo+ID4+LS0t LQ0KPiA+Pg0KPiA+PkltcGxlbWVudGF0aW9ucyBvciBwcm90b2NvbHMgc29tZXRpbWVzIG1pZ2h0 IHdpc2ggdG8gdXNlIG1vcmUNCj4gPj5zb3BoaXN0aWNhdGVkIHdlaWdodHMgdGhhdA0KPiA+Pj0+ DQo+ID4+SW1wbGVtZW50YXRpb25zIG9yIHByb3RvY29scyBzb21ldGltZXMgTUFZIHNwZWNpZnkg dGhlIHVzZSBvZg0KPiA+PmFsdGVybmF0aXZlIHdlaWdodHMgdGhhdA0KPiA+Pg0KPiA+Pg0KPiA+ W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPkVpdGhlciAiLi4ucHJvdG9jb2xzIE1BWS4uLiIg b3IgIi4uLiBwcm90b2NvbHMgc29tZXRpbWVzIG1pZ2h0Li4uIg0KPiA+DQo+ID4NCj4gc29tZXRp bWVzIE1BWSA9PiBNQVkNCj4gDQo+ID5JIGNob3NlIG5vbi1ub3JtYXRpdmUgbGFuZ3VhZ2UgaW5p dGlhbGx5IHRvIGFsbG93IHRoaW5ncyB3aXRob3V0IHR1cm5pbmcNCj4gdGhlIHdob2xlIHNlY3Rp b24gaW50byBSRkMgMjExOSBzb3VwLg0KPiA+DQo+ID4NCj4gPj4tLS0tDQo+ID4+W01ha2Ugc3Vi c2VjdGlvbnMgaW4gTG9va3VwLiBGaXJzdCBsYW5ndWFnZSByYW5nZSBsb29rdXAsIHRoZW4gbGFu Z3VhZ2UNCj4gPj5wcmlvcml0eSBsaXN0IGxvb2t1cCwgdGhlbiBleHRlbmRlZCBsYW5ndWFnZSBy YW5nZSBsb29rdXAuXQ0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4g PkkgdGhpbmsgdGhhdCdzIGFuIGF3ZnVsIGlkZWEuDQo+ID4NCj4gPkFuZCBtYWtlIHVwIHlvdXIg bWluZDogd2UgUkVNT1ZFRCBleHRlbmRlZCBsYW5ndWFnZSByYW5nZSBsb29rdXAgYmVjYXVzZQ0K PiBpdCBkb2VzbuKAmXQgbWFrZSBzZW5zZS4gTG9va3VwIGlzIG5vdyBjYXN0IGFzIEkgc3VnZ2Vz dGVkIGFib3ZlOiBpdCBpcw0KPiBzdHJpY3RseSBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgYmVh c3QsIGJ1dCBpdCBzdGFydHMgYnkgZGVmaW5lZCB0aGUNCj4gbWF0Y2ggYmV0d2VlbiBhIHRhZyBh bmQgYSByYW5nZS4NCj4gPg0KPiA+DQo+IExlbW1lIHJlbG9vayBhdCBpdCwgYnV0IGl0IHNlZW1z IHRvIG1lIHRoYXQgeW91IGFyZSBkb2luZyBpdCwgYnV0ICp2aWEqDQo+IHRyYW5zZm9ybWluZyBp dC4gKGJ1dCBtb3JlIGluIGEgc2VwYXJhdGUgbWVzc2FnZSBhbnl3YXkpLg0KPiANCj4gPj4tLS0t DQo+ID4+T3RoZXIgZXhhbXBsZXMgb2YgbG9va3VwIG1pZ2h0IGluY2x1ZGU6DQo+ID4+PT4NCj4g Pj5PdGhlciBleGFtcGxlcyBvZiBsb29rdXAgaW5jbHVkZToNCj4gPj5bdGhlIGV4YW1wbGVzICpk byogaW5jbHVkZS4gbm8gbmVlZCB0byBiZSB0ZW50YXRpdmUgOy0pXQ0KPiA+Pg0KPiA+Pg0KPiA+ W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPk9rYXkuDQo+ID4NCj4gPg0KPiA+Pi0tLS0NCj4g Pj4NCj4gPj5JZiB0aGlzIGxhbmd1YWdlIHJhbmdlIGlzIHRoZSBvbmx5IG9uZSBpbiB0aGUgbGFu Z3VhZ2UgcHJpb3JpdHkgbGlzdCwgaXQNCj4gPj5tYXRjaGVzIHRoZSBkZWZhdWx0IGNvbnRlbnQu IElmIHRoaXMgbGFuZ3VhZ2UgcmFuZ2UgaXMgZm9sbG93ZWQgYnkgb3RoZXINCj4gPj5sYW5ndWFn ZSByYW5nZXMsIGl0IHNob3VsZCBiZSBza2lwcGVkLg0KPiA+Pltkb2Vzbid0IGFkZHJlc3MgICo7 Kl0NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5ZZXMsIGl0IGRv ZXMuLi4gaXRlcmF0aXZlbHkuDQo+ID4NCj4gPg0KPiBZb3UncmUgcmlnaHQuDQo+IA0KPiA+DQo+ ID4NCj4gPj49Pg0KPiA+PkFsbCAiKiIgbGFuZ3VhZ2UgdGFncyBhcmUgcmVtb3ZlZCBmcm9tIGxh bmd1YWdlIHByaW9yaXR5IGxpc3QuIElmIHRoZXJlDQo+ID4+aXMgbm90aGluZyBsZWZ0LCB0aGVu IGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQgY29udGVudC4NCj4gPj4NCj4gPj4NCj4gPltBZGRpc29u IFBoaWxsaXBzXQ0KPiA+DQo+ID5UaGF0J3MgInJhbmdlcyIgaW4geW91ciBmaXJzdCBzZW50ZW5j ZS4NCj4gPg0KPiA+DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+PjUuIChkZWZhdWx0IGNvbnRlbnQgb3Ig dGhlIGVtcHR5IHRhZykNCj4gPj49Pg0KPiA+PjUuIChkZWZhdWx0KQ0KPiA+PltleHBsYWluIGJl bG93IHdoYXQgdGhpcyBpcy4gaXQgaXMgYWxzbyBvdGhlcndpc2Ugb2RkIHRoYXQgMS00IGFyZSB0 YWdzLA0KPiA+PmJ1dCB0aGVuIHRoaXMgaXMgJ2NvbnRlbnQnXQ0KPiA+Pg0KPiA+Pg0KPiA+W0Fk ZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPk9rYXkuDQo+ID4NCj4gPg0KPiA+Pi0tLS0NCj4gPj4N Cj4gPj5XaGVuIHBlcmZvcm1pbmcgbG9va3VwIHVzaW5nIGEgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlz dCwgdGhlIHByb2dyZXNzaXZlDQo+ID4+c2VhcmNoIE1VU1QgcHJvY2VlZCB0byBjb25zaWRlciBl YWNoIGxhbmd1YWdlIHJhbmdlIGJlZm9yZSBmaW5kaW5nIHRoZQ0KPiA+PmRlZmF1bHQgY29udGVu dCBvciBlbXB0eSB0YWcuIFRoZSBkZWZhdWx0IGNvbnRlbnQgbWlnaHQgYmUgY29udGVudCB3aXRo DQo+ID4+bm8gbGFuZ3VhZ2UgdGFnIChvciB3aXRoIGFuIGVtcHR5IHZhbHVlLCBhcyB3aXRoIHht bDpsYW5nIGluIHRoZSBYTUwNCj4gPj5zcGVjaWZpY2F0aW9uKSwgb3IgaXQgbWlnaHQgYmUgYSBw YXJ0aWN1bGFyIGxhbmd1YWdlIGRlc2lnbmF0ZWQgZm9yIHRoYXQNCj4gPj5iaXQgb2YgY29udGVu dC4NCj4gPj4NCj4gPj5PbmUgY29tbW9uIHdheSB0byBwcm92aWRlIGZvciBkZWZhdWx0IGNvbnRl bnQgaXMgdG8gYWxsb3cgYSBzcGVjaWZpYw0KPiA+Pmxhbmd1YWdlIHJhbmdlIHRvIGJlIHNldCBh cyB0aGUgZGVmYXVsdCBmb3IgYSBzcGVjaWZpYyB0eXBlIG9mIHJlcXVlc3QuDQo+ID4+VGhpcyBs YW5ndWFnZSByYW5nZSBpcyB0aGVuIHRyZWF0ZWQgYXMgaWYgaXQgd2VyZSBhcHBlbmRlZCB0byB0 aGUgZW5kIG9mDQo+ID4+dGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QsIHJhdGhlciB0aGFuIGFm dGVyIGVhY2ggaXRlbSBpbiB0aGUgbGFuZ3VhZ2UNCj4gPj5wcmlvcml0eSBsaXN0Lg0KPiA+Pg0K PiA+Pj0+DQo+ID4+W3Jld29yZCBmb3IgY2xhcml0eS4gRnVubnkgdGhpbmc6IHdoZW4gSSBmaXJz dCByZWFkICdtaWdodCBiZSBjb250ZW50DQo+ID4+d2l0aCBubyBsYW5ndWFnZSB0YWcnIEkgcmVh ZCBpdCBhcyB0aGUgdmVyYiAiYmUgY29udGVudCB3aXRoIiwgbGlrZSAiYmUNCj4gPj5oYXBweSB3 aXRoIi4gVGhlIGVtcHR5IHRhZyBpcyBub3QgYSB2YWxpZCBsYW5ndWFnZSB0YWcsIHNvIHdlIHNo b3VsZCBzYXkNCj4gPj4idW5kIiwgdGhlbiBzYXkgdGhhdCBhIHN5c3RlbSBjYW4gdXNlIGFsdGVy bmF0aXZlcy4gSGVyZSBpcyB0aGUgdGV4dC5dDQo+ID4+DQo+ID4+DQo+ID5bQWRkaXNvbiBQaGls bGlwc10NCj4gPg0KPiA+Tm8sIG5vdCAndW5kJyAoYW5kIEkgKmhhdGUqICd1bmQnKS4gJ1VuZCcg d291bGQgYmUgYW4gZXhhbXBsZSBvZiBhbg0KPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBkZWNp c2lvbi4gUGVyc29uYWxseSBJIHdvdWxkIHByZWZlciBuZXZlciB0byBzZWUNCj4gJ3VuZCcgY29u dGVudCBiZWluZyB1c2VkIGFzIGEgZGVmYXVsdC4NCj4gPg0KPiA+DQo+IFdlbGwsICIiIGlzIGls bGVnYWwgYXMgYSBsYW5ndWFnZS10YWcsIHNvIEkgd2FzIGp1c3QgdXNpbmcgaXQgYXMgYQ0KPiBz dGFuZC1pbiBiZWNhdXNlIHdlIGRvbid0IGhhdmUgYSBsYW5ndWFnZSB0YWcgZm9yICJyb290Ii4N Cj4gDQo+ID4+V2hlbiBwZXJmb3JtaW5nIGxvb2t1cCB1c2luZyBhIGxhbmd1YWdlIHByaW9yaXR5 IGxpc3QsIHRoZSBwcm9ncmVzc2l2ZQ0KPiA+PnNlYXJjaCBNVVNUIGNvbnNpZGVyIGVhY2ggbGFu Z3VhZ2UgcmFuZ2UgYmVmb3JlIGZpbmRpbmcgdGhlIGRlZmF1bHQuIFRoZQ0KPiA+PmRlZmF1bHQg bWlnaHQgYmUgc3BlY2lmaWVkIGFzICJ1bmQiIChvciBiZSBpbmRpY2F0ZWQgd2l0aCBhbiBlbXB0 eQ0KPiA+PnZhbHVlLCBhcyB3aXRoIHhtbDpsYW5nIGluIHRoZSBYTUwgc3BlY2lmaWNhdGlvbiwg b3Igd2l0aCAicm9vdCIgYXMgaW4NCj4gPj5zb21lIHN5c3RlbXMpLCBvciBpdCBtaWdodCBiZSBz cGVjaWZpZWQgYXMgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHJhbmdlLg0KPiA+PlRoaXMgbGFuZ3Vh Z2UgcmFuZ2UgaXMgdGh1cyB0cmVhdGVkIGFzIGlmIGl0IHdlcmUgYXBwZW5kZWQgdG8gdGhlIGVu ZCBvZg0KPiA+PnRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0LCByYXRoZXIgdGhhbiBhZnRlciBl YWNoIGl0ZW0gaW4gdGhlIGxhbmd1YWdlDQo+ID4+cHJpb3JpdHkgbGlzdC4NCj4gPj4NCj4gPj4N Cj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5JIHByZWZlciBub3QgdG8gbWFrZSB0aGlz IGNoYW5nZS4gSSB0aGluayBpdCBkZWx2ZXMgdG9vIGNsb3NlbHkgaW50byB0aGUNCj4gaW1wbGVt ZW50YXRpb24gc3BlY2lmaWMuDQo+ID4NCj4gPg0KPiBJdCBjYW4ndCBiZSBsZWZ0IGFzIGl0IGlz LiBPdGhlciBhbHRlcm5hdGl2ZXM/DQo+IA0KPiA+Pi0tLS0NCj4gPj4NCj4gPj41LiAocmV0dXJu IGRlZmF1bHQgY29udGVudCkNCj4gPj5hLiBqYS1KUA0KPiA+PmIuIGphDQo+ID4+Yy4gKGVtcHR5 IHRhZyBvciBvdGhlciBkZWZhdWx0IGNvbnRlbnQpDQo+ID4+DQo+ID4+NS4gKGRlZmF1bHQpDQo+ ID4+YS4gamEtSlANCj4gPj5iLiBqYQ0KPiA+PmMuIHVuZA0KPiA+Pg0KPiA+Pg0KPiA+W0FkZGlz b24gUGhpbGxpcHNdDQo+ID4NCj4gPkhvdyBhYm91dDoNCj4gPg0KPiA+NS4gKGRlZmF1bHQgY29u dGVudCBsb29rdXApDQo+ID4gICBhLiBqYS1KUA0KPiA+ICAgYi4gamENCj4gPiAgIGMuIChpbXBs ZW1lbnRhdGlvbiBkZWZpbmVkKQ0KPiA+DQo+ID4NCj4gVGhhdCB3b3Jrcy4NCj4gDQo+ID4+LS0t LQ0KPiA+Pg0KPiA+PkFkZA0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgIDMuMy54LiBEaXN0YW5jZSBN ZXRyaWMgTG9va3VwDQo+ID4+DQo+ID4+RGlzdGFuY2UgbWV0cmljIGxvb2t1cCBpcyBwZXJmb3Jt ZWQgYnkgcHJvZHVjaW5nIGFuIG9yZGVyZWQgbGlzdCBvZg0KPiA+PmZpbHRlcmVkIHJlc3VsdHMg YXMgc3BlY2lmaWVkIGluIDMuMi4yLCB0aGVuIHJldHVybmluZyB0aGUgZmlyc3QgaXRlbS4NCj4g Pj4NCj4gPj4NCj4gPltBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID5JIHRoaW5rIHdlJ2QgYmVz dCBub3QgZ28gZG93biB0aGF0IHBhdGguIEFtb25nIG90aGVyIHRoaW5nczogaXQgd29uJ3QNCj4g d29yay4gRGlzdGFuY2UgbWV0cmljIGZpbHRlcmluZyBjYW4gcHJvZHVjZSBpdGVtcyB3aXRoIGlk ZW50aWNhbCBzY29yZXMuLi4NCj4gPg0KPiA+DQo+IE9rLCBkcm9wIGl0Lg0KPiANCj4gPg0KPiA+ DQo+ID4+LS0tLQ0KPiA+Pg0KPiA+Pk1hcmsNCj4gPj4NCj4gPj5QLlMuIEkgc3RpbGwgdGhpbmsg dGhhdCB0aGUgZXh0ZW5kZWQgcmFuZ2UgbG9va3VwIGRvZXNuJ3QgcXVpdGUgd29yaywNCj4gPj5i dXQgSSdsbCBzZW5kIHRoYXQgaW4gYSBzZXBhcmF0ZSBtZXNzYWdlLg0KPiA+Pg0KPiA+Pg0KPiA+ W0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPk5vLCBpdCBkb2Vzbid0IHdvcmsgYW5kIHdlIGVs aW1pbmF0ZWQgaXQuIFdlJ3ZlIG1hcHBlZCBleHRlbmRlZCByYW5nZXMNCj4gb250byBiYXNpYyBy YW5nZXMsIHdoaWNoIGRvIHdvcmssIHByb2R1Y2luZyBkaWZmZXJlbnQgcmVzdWx0cyB0aGFuIHRo ZQ0KPiBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IG1pZ2h0IGxlYWQgb25lIHRvIGV4cGVjdC4NCj4g Pg0KPiA+DQo+IExldCBtZSBsb29rIHRoaXMgb3ZlciBhZ2Fpbi4NCg0K --===============1330819126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1330819126==-- From ltru-bounces@ietf.org Fri Nov 18 19:22:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdGV0-0005kp-FO; Fri, 18 Nov 2005 19:22:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdGUz-0005kh-Ct for ltru@megatron.ietf.org; Fri, 18 Nov 2005 19:22:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24222 for ; Fri, 18 Nov 2005 19:21:56 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdGms-0001XX-Q2 for ltru@ietf.org; Fri, 18 Nov 2005 19:41:04 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 16:22:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 16:22:13 -0800 Message-ID: Thread-Topic: scored filtering demo... Thread-Index: AcXsn0oDVSWfLmYMT3GO5sid/ucG7Q== From: "Addison Phillips" To: X-OriginalArrivalTime: 19 Nov 2005 00:22:14.0246 (UTC) FILETIME=[4A6BC860:01C5EC9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] scored filtering demo... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2097253278==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2097253278== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlcmUgaXMgYSBkZW1vIHBhZ2UgZm9yIHNjb3JlZCBmaWx0ZXJpbmcgb24gbXkgd2Vic2l0ZSBi YXNlZCBvbiBteSBsaXR0bGUgSmF2YSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgU2NvcmVkIEZpbHRl cmluZyBpbiBkcmFmdC0wNi4NCg0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL2xhbmd0YWdz L2luZGV4LmpzcA0KDQpUaGUgZGVtbyBoYXMgb25lIHF1aXJrOiBncmFuZGZhdGhlcmVkIHRhZ3Mg YXJlIG5vdCBwYXJzZWQgcHJvcGVybHksIHNvICJlbi1ib29udCIgcHJvZHVjZXMgZnVubnkgc2Nv cmVzIChpdCBkb2Vzbid0IG1hdGNoIHRoZSByYW5nZSAnZW4nLCBmb3IgZXhhbXBsZSkuDQoNClRo ZXJlIGlzIGEgY2FubmVkIGxpc3Qgb2YgbGFuZ3VhZ2UgdGFncyB0aGF0IHRoZSByYW5nZSB5b3Ug ZW50ZXIgaXMgY29tcGFyZWQgdG8uIFRoZXJlIG1heSBiZSBidWdzIGFzIHlldC4NCg0KQmFzZWQg b24gc29tZSBsaWdodCBleHBlcmltZW50YXRpb24sIHdlIG1heSB3aXNoIHRvIGNoYW5nZSBhc3Bl Y3RzIG9mIHRoZSBhbGdvcml0aG0gKGVzcGVjaWFsbHkgZXhwYW5zaW9uIG9mIGZpZWxkcyBpbiBl aXRoZXIgcmFuZ2VzIG9yIHRhZ3MgdG8gdGhlIHdpbGRjYXJkKS4gDQoNCkJlc3QgUmVnYXJkcywN Cg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkludGVybmF0aW9uYWxp emF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============2097253278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2097253278==-- From ltru-bounces@ietf.org Fri Nov 18 20:28:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHX3-0004rF-Ii; Fri, 18 Nov 2005 20:28:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHX1-0004r7-O1 for ltru@megatron.ietf.org; Fri, 18 Nov 2005 20:28:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27228 for ; Fri, 18 Nov 2005 20:28:08 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdHoy-00031Y-Mo for ltru@ietf.org; Fri, 18 Nov 2005 20:47:17 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1SYwS002495 for ; Fri, 18 Nov 2005 20:28:34 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAJ1TqLY066740 for ; Fri, 18 Nov 2005 18:29:52 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAJ1SXQL027683 for ; Fri, 18 Nov 2005 18:28:33 -0700 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1SWca027669; Fri, 18 Nov 2005 18:28:33 -0700 Message-ID: <437E7FBE.2070300@icu-project.org> Date: Fri, 18 Nov 2005 17:28:30 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: wildcards in extended ranges (was RE: [Ltru] draft-06 comments: choice of range) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >(I'm going to reply to things individually to keep the mail threads manageable.) > > > >>>Agreed, although I tend to think we should go the other direction and say >>> >>> >>MUST. >> >> >>> >>> >>If we say must, then we are really saying that any input range x-y-z-w >>acts like x-*-y-*-z-*-w, whenever something could go between. Since we >>say the algorithms work in the absence of parsing the language tag, that >>means putting them in all the time. Seems like a bit much, but I'll mull >>it over. >> >> > >It doesn't say that the algorithms work in the absence of parsing the language tags. It says they work in absence of the registry. Extended language ranges require length/content based parsing of both the range and the tag in order to work. Otherwise you can't tell what a "*" is supposed to match (unless you require all of the fields to be filled in). > > You're right. My lapse. >Ideally, extended range filtering and scored filtering with a threshold of "0" should produce the same sets, or at least I think they should. Having written an extended range filter and just finished a scored filter, I haven't tested it extensively yet. > >However, I do note that I had to parse both range and tag to make extended work and would need to even if missing items are not "*"... I have to know which subtags I have in order to match any "*" values that *do* occur. The only time my implementation goes to the registry, though, is for the list of grandfathered items. > >So, yes, we are saying x-*-y-*-z-*-w. > > I'm ok with that, let's just make it slightly clearer in the text. >Let's take some examples. If I have a range "en-US", should it match "en-Latn-US" or not? Basic ranges do NOT match those tags. Extended ranges, as currently written, DO match those tags. > >If I have de-*-1901, does it match "de-Latn-1901"? "de-DE-1901"? What does a single * mean? > >The current text says "MAY" for missing elements, allowing the first example to match or not at an implementation level. But I think it would be better if we chose one or the other. > > My opinion is that we are describing a process. Within *that* description, they should be MUSTs. At the end we say of each process we say the allowed ways that a protocol can add specifications. That makes it very clear to users what they can expect out of a protocol *if it doesn't add any additional specifications*. So, I'm ok with MUST as long as we have the escape clause at the end. >My 2 cents. > >Addison > > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 20:37:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHfM-0006tY-De; Fri, 18 Nov 2005 20:37:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHfL-0006tT-Ji for ltru@megatron.ietf.org; Fri, 18 Nov 2005 20:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27545 for ; Fri, 18 Nov 2005 20:36:43 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdHxH-0003Dh-Qj for ltru@ietf.org; Fri, 18 Nov 2005 20:55:52 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1b9nb029826 for ; Fri, 18 Nov 2005 20:37:09 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAJ1b9Xn115218 for ; Fri, 18 Nov 2005 20:37:09 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAJ1b8Rm007954 for ; Fri, 18 Nov 2005 20:37:08 -0500 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1b7RV007872; Fri, 18 Nov 2005 20:37:08 -0500 Message-ID: <437E81C1.10002@icu-project.org> Date: Fri, 18 Nov 2005 17:37:05 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e2.ny.us.ibm.com id jAJ1b9nb029826 X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org Subject: [Ltru] Re: weights in scored filtering X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org We can do an integer only approach. Convert the q's into round(100/q). For filtering, we can't assume anything about the order of items in the=20 list that have the same q values. I have en, de, fr, it, nl. But my=20 English is significantly better than my German, which is somewhat better=20 than my French, which is significantly better than my Italian, etc. For lookup, we and everybody I know just uses the q values to reorder=20 the list. Then throws them away. So for lookup, ordering is very importan= t. Mark Addison Phillips wrote: >>>>[At the end of the section, after we've introduced the discussion of = an >>>>ordered list and distance metric, add] >>>> >>>>When the set of matches is returned, the items are in descending orde= r >>>>where the weight for each item is the priority in the language priori= ty >>>>list divided by the distance metric. (If the filtering method does no= t >>>>supply a distance metric, then the distance metric is 1.) If the item >>>>matches multiple ranges, then its weight is the square root of the su= m >>>>of squares of the individual weights for each range. If two items hav= e >>>>the same weight, then their ordering is based on a case-insensitive >>>>ordering of the language tags. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Ugh. Icky. Many items will have the same weight even in spite of this >>> =20 >>> >>complex scheme. >> =20 >> >>> =20 >>> >>Can't get around that. If priorities are equal and there is no distance >>metric, then you essentially have an unordered list. >> =20 >> > >If I have two bits of content with the same tag, their values will be eq= ual. The choice of what order they are returned in then is implementation= specific, perhaps based on some other information (like FIFO or word fre= quency or...) > =20 > >>>I note that q weights in Accept-Language are always less than or equal= to >>> =20 >>> >>one and greater than or equal to zero. Your algorithm won't work correc= tly >>with those values (instead multiplication of the score works better). >> =20 >> >>You're right that there is a numeric problem, but you can't multiply, >>because smaller distances are better, but lower priorities are *worse*. >>So you have to divide one way or another. Look at an example. >> =20 >> > >My bad. At that moment I was thinking in terms of the old version where = zero was bad. Dunno why. You're correct. > > =20 > >>Now, as I think about it, the simplest way is to still think of the >>results as distances, with the smallest distance being the best. Then >>the algorithm is >> >>a) toss out any q weights that are zero. After all, that means that you >>give them *no* priority. >> =20 >> > >Uh... you made the point that a weight of zero has a meaning, one that w= orks well with division: it is "never return content in this language". D= IV/0 error is a good way to flag these items. As with: > > sr, q=3D1.0; sr-Latn, q=3D0.0; en, q=3D0.8 > >Means: I'd like Serbian, but never in Latin script, followed by English. > =20 > good point. > > =20 > >>The square rooty stuff was just because distance metrics with multiple >>fields weight better when you treat them as dimensional vectors. >>However, in retrospect it is probably just simpler to take the minimum >>of the possible weights. So if Q matches X with a distance of, say, 2. = Q >>matches Y with a distance of 10. Then the result would be the minimum, = or >>1. >> =20 >> > >For a given tag/range match, you get a score. The lowest score wins. A s= mart implementation has a threshold value. The first value above the thre= shold in the language priority list is the score for the content (perhaps= even if a later range might score higher). A threshold of zero matches e= xtended language range filtering. > >One more fly in the ointment: a score of zero isn't open to coercion by = weight. Consider this language priority list: "en; fr; de" and this tag: = "fr-FR". The score for the tag with "fr" is zero and the fact that 'fr' i= s weighted lower than "en" has no effect on this. > >I think it would be better if we could find an integer-only scoring sche= me that deals with weights in some consistent manner. Perhaps: create sco= res for each tag vs. each range in the list. Then add the position in the= list (starting at base zero) to the score. For the example above, the sc= ore for "fr-FR" is "1" and the score for "de" is "2". > =20 > Don't think that works. >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B411=E6=9C=8818=E6=97=A5 13:42 >>To: Addison Phillips >>Cc: ltru@ietf.org >>Subject: Re: [Ltru] draft-06 comments: choice of range >> >> >> >>Addison Phillips wrote: >> >> >> =20 >> >>>>A protocol which uses language priority lists MAY specify an alternat= ive >>>>mechanism for computing the ordering. >>>> >>>>---- >>>> >>>>A protocol which uses language ranges MAY specify additional rules ab= out >>>>the semantics of "*"; >>>>=3D> >>>>A protocol which uses language ranges MAY specify additional rules ab= out >>>>the semantics of "*" or other tags; >>>>[no reason to restrict it] >>>> >>>>---- >>>> >>>>Implementations or protocols sometimes might wish to use more >>>>sophisticated weights that >>>>=3D> >>>>Implementations or protocols sometimes MAY specify the use of >>>>alternative weights that >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Either "...protocols MAY..." or "... protocols sometimes might..." >>> >>> >>> =20 >>> >>sometimes MAY =3D> MAY >> >> =20 >> >>>I chose non-normative language initially to allow things without turni= ng >>> =20 >>> >>the whole section into RFC 2119 soup. >> =20 >> >>> =20 >>> >>>>---- >>>>[Make subsections in Lookup. First language range lookup, then langua= ge >>>>priority list lookup, then extended language range lookup.] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I think that's an awful idea. >>> >>>And make up your mind: we REMOVED extended language range lookup becau= se >>> =20 >>> >>it doesn=E2=80=99t make sense. Lookup is now cast as I suggested above:= it is >>strictly a language priority list beast, but it starts by defined the >>match between a tag and a range. >> =20 >> >>> =20 >>> >>Lemme relook at it, but it seems to me that you are doing it, but *via* >>transforming it. (but more in a separate message anyway). >> >> =20 >> >>>>---- >>>>Other examples of lookup might include: >>>>=3D> >>>>Other examples of lookup include: >>>>[the examples *do* include. no need to be tentative ;-)] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Okay. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>If this language range is the only one in the language priority list,= it >>>>matches the default content. If this language range is followed by ot= her >>>>language ranges, it should be skipped. >>>>[doesn't address *;*] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Yes, it does... iteratively. >>> >>> >>> =20 >>> >>You're right. >> >> =20 >> >>> =20 >>> >>>>=3D> >>>>All "*" language tags are removed from language priority list. If the= re >>>>is nothing left, then it matches the default content. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>That's "ranges" in your first sentence. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>5. (default content or the empty tag) >>>>=3D> >>>>5. (default) >>>>[explain below what this is. it is also otherwise odd that 1-4 are ta= gs, >>>>but then this is 'content'] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Okay. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>When performing lookup using a language priority list, the progressiv= e >>>>search MUST proceed to consider each language range before finding th= e >>>>default content or empty tag. The default content might be content wi= th >>>>no language tag (or with an empty value, as with xml:lang in the XML >>>>specification), or it might be a particular language designated for t= hat >>>>bit of content. >>>> >>>>One common way to provide for default content is to allow a specific >>>>language range to be set as the default for a specific type of reques= t. >>>>This language range is then treated as if it were appended to the end= of >>>>the language priority list, rather than after each item in the langua= ge >>>>priority list. >>>> >>>>=3D> >>>>[reword for clarity. Funny thing: when I first read 'might be content >>>>with no language tag' I read it as the verb "be content with", like "= be >>>>happy with". The empty tag is not a valid language tag, so we should = say >>>>"und", then say that a system can use alternatives. Here is the text.= ] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, not 'und' (and I *hate* 'und'). 'Und' would be an example of an >>> =20 >>> >>implementation specific decision. Personally I would prefer never to se= e >>'und' content being used as a default. >> =20 >> >>> =20 >>> >>Well, "" is illegal as a language-tag, so I was just using it as a >>stand-in because we don't have a language tag for "root". >> >> =20 >> >>>>When performing lookup using a language priority list, the progressiv= e >>>>search MUST consider each language range before finding the default. = The >>>>default might be specified as "und" (or be indicated with an empty >>>>value, as with xml:lang in the XML specification, or with "root" as i= n >>>>some systems), or it might be specified as a particular language rang= e. >>>>This language range is thus treated as if it were appended to the end= of >>>>the language priority list, rather than after each item in the langua= ge >>>>priority list. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I prefer not to make this change. I think it delves too closely into t= he >>> =20 >>> >>implementation specific. >> =20 >> >>> =20 >>> >>It can't be left as it is. Other alternatives? >> >> =20 >> >>>>---- >>>> >>>>5. (return default content) >>>>a. ja-JP >>>>b. ja >>>>c. (empty tag or other default content) >>>> >>>>5. (default) >>>>a. ja-JP >>>>b. ja >>>>c. und >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>How about: >>> >>>5. (default content lookup) >>> a. ja-JP >>> b. ja >>> c. (implementation defined) >>> >>> >>> =20 >>> >>That works. >> >> =20 >> >>>>---- >>>> >>>>Wildcard values in an extended language range are supposed to match a= ny >>>>value >>>>=3D> >>>>Wildcard values in an extended language range match any value >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, they are *supposed* to match, but in this case they don't. They ma= tch >>> =20 >>> >>the empty value. >> =20 >> >>> =20 >>> >>I read that differently. When you say "supposed to match", it sounds >>like there is a choice, that there are some values that they don't >>match. Like the US is "supposed to" disallow torture. >> >> =20 >> >>>>---- >>>> >>>>Add >>>> >>>> >>>> 3.3.x. Distance Metric Lookup >>>> >>>>Distance metric lookup is performed by producing an ordered list of >>>>filtered results as specified in 3.2.2, then returning the first item. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I think we'd best not go down that path. Among other things: it won't >>> =20 >>> >>work. Distance metric filtering can produce items with identical scores= ... >> =20 >> >>> =20 >>> >>Ok, drop it. >> >> =20 >> >>> =20 >>> >>>>---- >>>> >>>>Mark >>>> >>>>P.S. I still think that the extended range lookup doesn't quite work, >>>>but I'll send that in a separate message. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, it doesn't work and we eliminated it. We've mapped extended ranges >>> =20 >>> >>onto basic ranges, which do work, producing different results than the >>language priority list might lead one to expect. >> =20 >> >>> =20 >>> >>Let me look this over again. >> =20 >> > > =20 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 18 20:38:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHgm-00071M-5p; Fri, 18 Nov 2005 20:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHgk-00071H-5Y for ltru@megatron.ietf.org; Fri, 18 Nov 2005 20:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27606 for ; Fri, 18 Nov 2005 20:38:10 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdHyf-0003Fm-TW for ltru@ietf.org; Fri, 18 Nov 2005 20:57:19 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1cV8B002307 for ; Fri, 18 Nov 2005 20:38:31 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAJ1cVma110460 for ; Fri, 18 Nov 2005 20:38:31 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAJ1cVJ2009693 for ; Fri, 18 Nov 2005 20:38:31 -0500 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAJ1cTUZ009636; Fri, 18 Nov 2005 20:38:30 -0500 Message-ID: <437E8214.2@icu-project.org> Date: Fri, 18 Nov 2005 17:38:28 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id jAJ1cV8B002307 X-Spam-Score: 0.0 (/) X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org Subject: [Ltru] Re: mapping ext-lang-range to basic in lookup X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >>>>---- >>>> >>>>Wildcard values in an extended language range are supposed to match a= ny >>>>value >>>>=3D> >>>>Wildcard values in an extended language range match any value >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, they are *supposed* to match, but in this case they don't. They ma= tch >>> =20 >>> >>the empty value. >> =20 >> >>> =20 >>> >>I read that differently. When you say "supposed to match", it sounds >>like there is a choice, that there are some values that they don't >>match. Like the US is "supposed to" disallow torture. >> =20 >> > >When considered in isolation, I suppose one could have that reading, but= I think the text is actually pretty clear here. Perhaps it could be clea= rer. The missing point that I was trying to convey is that extended langu= age ranges do not produce the expected results based on their meaning. Th= e range "en-*-US" will never pass through content labeled "en-Brai" (or a= ny other content with a script subtag), even though this matches the mean= ing of the extended language range. From "en-US" you skip immediately to = "en". It is supposed to match... and it doesn't. > >I think we might make a version of the change you suggest and then spell= out my example. > =20 > ok >The text currently: > >-- >In some cases, the language priority list might contain one or more exte= nded language ranges (as, for example, when the same language priority li= st is used as input for both lookup and filtering operations). Wildcard v= alues in an extended language range are supposed to match any value that = occurs in that position in a language tag. Since only one item can be ret= urned for any given lookup request, the wildcards must be processed in a = predictable manner (or the same request might produce widely varying resu= lts). Thus, for each range in the language priority list, the following r= ules must be applied to produce a basic language range for use in the fal= lback mechanism: >-- > >Proposed change: > >-- >...Wildcard values in an extended language range normally match any valu= e that occurs in that position in a language tag...=20 >-- > >And then add (after the example): > >-- >The resulting basic language ranges will produce different results that = the user might expect. For example, a request for "en-*-US" will never fi= nd content labeled "en-Brai", even though this tag matches the extended l= anguage range. >-- > > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B411=E6=9C=8818=E6=97=A5 13:42 >>To: Addison Phillips >>Cc: ltru@ietf.org >>Subject: Re: [Ltru] draft-06 comments: choice of range >> >> >> >>Addison Phillips wrote: >> >> =20 >> >>>Comments interlinearly below. I have some strong reservations about so= me >>> =20 >>> >>of these comments. >> =20 >> >>>Addison >>> >>>Addison P. Phillips >>>Globalization Architect, Quest Software >>> >>>Internationalization is not a feature. >>>It is an architecture. >>> >>> >>> >>> =20 >>> >>>>-----Original Message----- >>>>From: Mark Davis [mailto:mark.davis@icu-project.org] >>>>Sent: 2005=E5=B9=B411=E6=9C=8818=E6=97=A5 10:15 >>>>To: Addison Phillips >>>>Cc: ltru@ietf.org >>>>Subject: Re: [Ltru] draft-06 comments: choice of range >>>> >>>> >>>> >>>> =20 >>>> >>>// text removed >>> >>> >>> =20 >>> >>// just keep the text, makes it harder to tell what you are commenting >>on ;-) >> >> =20 >> >>>>[The "this also means" only applies when the implemenation does the M= AY.] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Agreed, although I tend to think we should go the other direction and = say >>> =20 >>> >>MUST. >> =20 >> >>> =20 >>> >>If we say must, then we are really saying that any input range x-y-z-w >>acts like x-*-y-*-z-*-w, whenever something could go between. Since we >>say the algorithms work in the absence of parsing the language tag, tha= t >>means putting them in all the time. Seems like a bit much, but I'll mul= l >>it over. >> >> =20 >> >>>>---- >>>> >>>>measurment >>>>[spell-check] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Thanks. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>[General Observation. >>>> >>>>We need to give a mechanism that will always give a precise, determin= ant >>>>answer. We then let protocols specify alternatives (if they need to) = by >>>>additional specification. In particular, in each section we have to m= ake >>>>clear what exactly happens with a language range, and what happens wi= th >>>>a language priority list. >>>> >>>>For filtering, this can be done by moving the discussion of the langu= age >>>>priority list up into 3.2. ] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Actually, I'd go further and suggest that all of the matching schemes = be >>> =20 >>> >>defined in terms of language priority lists (a language range by itself >>being the collapsed case of a language priority list with only one item= -- >>inside the specific scheme we describe how to match a single range to a >>single tag, but the scheme overall matches the user's language >>preferences--a list--against content). Lookup now reads this way. >> =20 >> >>That works too. Then we just say at the very top that all the mechanism= s >>treat a single language range as a single element language priority lis= t. >> >> =20 >> >>>This section 3.2 text: >>> >>>-- >>>Filtering is used to select the set of content that matches a given >>> =20 >>> >>prefix. >> =20 >> >>>-- >>> >>>Should be modified to say: >>> >>>-- >>>Filtering is used to select the set of content that matches the user's >>> =20 >>> >>language preferences (see Section 2.1, Language Priority Lists). >> =20 >> >>>-- >>> >>>Before objecting to this change because it removes the critical point >>> =20 >>> >>about the range being a prefix, consider that the entire second paragra= ph >>of this section covers that. >> =20 >> >>> >>> =20 >>> >>>>3.2. >>>>If the language priority list (see Section 2.1 (Lists of Language >>>>Ranges) >>>>) >>>>contains more than one range, the content returned is typically order= ed >>>>in descending level of preference. >>>>=3D> >>>>If the language priority list (see Section 2.1 (Lists of Language >>>>Ranges) >>>>) >>>>contains more than one range, the contents that match that range are >>>>added to the set of results. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>The word content in this sentence is already plural. "Contents" is wro= ng. >>> =20 >>> >>If we want to be explicit about it, we should use the previously quoted >>formulation "set of content". >> =20 >> >>> =20 >>> >>set of content works. >> >> =20 >> >>> =20 >>> >>>>[At the end of the section, after we've introduced the discussion of = an >>>>ordered list and distance metric, add] >>>> >>>>When the set of matches is returned, the items are in descending orde= r >>>>where the weight for each item is the priority in the language priori= ty >>>>list divided by the distance metric. (If the filtering method does no= t >>>>supply a distance metric, then the distance metric is 1.) If the item >>>>matches multiple ranges, then its weight is the square root of the su= m >>>>of squares of the individual weights for each range. If two items hav= e >>>>the same weight, then their ordering is based on a case-insensitive >>>>ordering of the language tags. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Ugh. Icky. Many items will have the same weight even in spite of this >>> =20 >>> >>complex scheme. >> =20 >> >>> =20 >>> >>Can't get around that. If priorities are equal and there is no distance >>metric, then you essentially have an unordered list. >> >> =20 >> >>>I note that q weights in Accept-Language are always less than or equal= to >>> =20 >>> >>one and greater than or equal to zero. Your algorithm won't work correc= tly >>with those values (instead multiplication of the score works better). >> =20 >> >>> =20 >>> >>You're right that there is a numeric problem, but you can't multiply, >>because smaller distances are better, but lower priorities are *worse*. >>So you have to divide one way or another. Look at an example. >> >>X, q=3D0.5; Y, q=3D0.3; >> >>Z matches X with a distance of, say, 2. W matches Y with a distance of >>10. If you multiply, you get >> >>Z -> (0.5 * 2) =3D 1 >>W -> (0.3) * 10) =3D 3 >> >>That would rank Y better than Z! What you want is a division. >> >>Now, as I think about it, the simplest way is to still think of the >>results as distances, with the smallest distance being the best. Then >>the algorithm is >> >>a) toss out any q weights that are zero. After all, that means that you >>give them *no* priority. >>b) divide the distance by the priority. >>c) order in ascending order >> >>Z -> (2 / 0.5) =3D 1 >>W -> (10 / 0.3) =3D 33.33 >> >>which ranks them correctly. >> >>The square rooty stuff was just because distance metrics with multiple >>fields weight better when you treat them as dimensional vectors. >>However, in retrospect it is probably just simpler to take the minimum >>of the possible weights. So if Q matches X with a distance of, say, 2. = Q >>matches Y with a distance of 10. Then the result would be the minimum, = or >>1. >> >> =20 >> >>>>A protocol which uses language priority lists MAY specify an alternat= ive >>>>mechanism for computing the ordering. >>>> >>>>---- >>>> >>>>A protocol which uses language ranges MAY specify additional rules ab= out >>>>the semantics of "*"; >>>>=3D> >>>>A protocol which uses language ranges MAY specify additional rules ab= out >>>>the semantics of "*" or other tags; >>>>[no reason to restrict it] >>>> >>>>---- >>>> >>>>Implementations or protocols sometimes might wish to use more >>>>sophisticated weights that >>>>=3D> >>>>Implementations or protocols sometimes MAY specify the use of >>>>alternative weights that >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Either "...protocols MAY..." or "... protocols sometimes might..." >>> >>> >>> =20 >>> >>sometimes MAY =3D> MAY >> >> =20 >> >>>I chose non-normative language initially to allow things without turni= ng >>> =20 >>> >>the whole section into RFC 2119 soup. >> =20 >> >>> =20 >>> >>>>---- >>>>[Make subsections in Lookup. First language range lookup, then langua= ge >>>>priority list lookup, then extended language range lookup.] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I think that's an awful idea. >>> >>>And make up your mind: we REMOVED extended language range lookup becau= se >>> =20 >>> >>it doesn=E2=80=99t make sense. Lookup is now cast as I suggested above:= it is >>strictly a language priority list beast, but it starts by defined the >>match between a tag and a range. >> =20 >> >>> =20 >>> >>Lemme relook at it, but it seems to me that you are doing it, but *via* >>transforming it. (but more in a separate message anyway). >> >> =20 >> >>>>---- >>>>Other examples of lookup might include: >>>>=3D> >>>>Other examples of lookup include: >>>>[the examples *do* include. no need to be tentative ;-)] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Okay. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>If this language range is the only one in the language priority list,= it >>>>matches the default content. If this language range is followed by ot= her >>>>language ranges, it should be skipped. >>>>[doesn't address *;*] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Yes, it does... iteratively. >>> >>> >>> =20 >>> >>You're right. >> >> =20 >> >>> =20 >>> >>>>=3D> >>>>All "*" language tags are removed from language priority list. If the= re >>>>is nothing left, then it matches the default content. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>That's "ranges" in your first sentence. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>5. (default content or the empty tag) >>>>=3D> >>>>5. (default) >>>>[explain below what this is. it is also otherwise odd that 1-4 are ta= gs, >>>>but then this is 'content'] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>Okay. >>> >>> >>> =20 >>> >>>>---- >>>> >>>>When performing lookup using a language priority list, the progressiv= e >>>>search MUST proceed to consider each language range before finding th= e >>>>default content or empty tag. The default content might be content wi= th >>>>no language tag (or with an empty value, as with xml:lang in the XML >>>>specification), or it might be a particular language designated for t= hat >>>>bit of content. >>>> >>>>One common way to provide for default content is to allow a specific >>>>language range to be set as the default for a specific type of reques= t. >>>>This language range is then treated as if it were appended to the end= of >>>>the language priority list, rather than after each item in the langua= ge >>>>priority list. >>>> >>>>=3D> >>>>[reword for clarity. Funny thing: when I first read 'might be content >>>>with no language tag' I read it as the verb "be content with", like "= be >>>>happy with". The empty tag is not a valid language tag, so we should = say >>>>"und", then say that a system can use alternatives. Here is the text.= ] >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, not 'und' (and I *hate* 'und'). 'Und' would be an example of an >>> =20 >>> >>implementation specific decision. Personally I would prefer never to se= e >>'und' content being used as a default. >> =20 >> >>> =20 >>> >>Well, "" is illegal as a language-tag, so I was just using it as a >>stand-in because we don't have a language tag for "root". >> >> =20 >> >>>>When performing lookup using a language priority list, the progressiv= e >>>>search MUST consider each language range before finding the default. = The >>>>default might be specified as "und" (or be indicated with an empty >>>>value, as with xml:lang in the XML specification, or with "root" as i= n >>>>some systems), or it might be specified as a particular language rang= e. >>>>This language range is thus treated as if it were appended to the end= of >>>>the language priority list, rather than after each item in the langua= ge >>>>priority list. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I prefer not to make this change. I think it delves too closely into t= he >>> =20 >>> >>implementation specific. >> =20 >> >>> =20 >>> >>It can't be left as it is. Other alternatives? >> >> =20 >> >>>>---- >>>> >>>>5. (return default content) >>>>a. ja-JP >>>>b. ja >>>>c. (empty tag or other default content) >>>> >>>>5. (default) >>>>a. ja-JP >>>>b. ja >>>>c. und >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>How about: >>> >>>5. (default content lookup) >>> a. ja-JP >>> b. ja >>> c. (implementation defined) >>> >>> >>> =20 >>> >>That works. >> >> =20 >> >>>>---- >>>> >>>>Add >>>> >>>> >>>> 3.3.x. Distance Metric Lookup >>>> >>>>Distance metric lookup is performed by producing an ordered list of >>>>filtered results as specified in 3.2.2, then returning the first item. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>I think we'd best not go down that path. Among other things: it won't >>> =20 >>> >>work. Distance metric filtering can produce items with identical scores= ... >> =20 >> >>> =20 >>> >>Ok, drop it. >> >> =20 >> >>> =20 >>> >>>>---- >>>> >>>>Mark >>>> >>>>P.S. I still think that the extended range lookup doesn't quite work, >>>>but I'll send that in a separate message. >>>> >>>> >>>> =20 >>>> >>>[Addison Phillips] >>> >>>No, it doesn't work and we eliminated it. We've mapped extended ranges >>> =20 >>> >>onto basic ranges, which do work, producing different results than the >>language priority list might lead one to expect. >> =20 >> >>> =20 >>> >>Let me look this over again. >> =20 >> > > =20 > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 19 14:36:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdYVb-0002um-5g; Sat, 19 Nov 2005 14:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdYVZ-0002to-H7 for ltru@megatron.ietf.org; Sat, 19 Nov 2005 14:36:21 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13433 for ; Sat, 19 Nov 2005 14:35:44 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EdYUA-0006U6-8D for ltru@lists.ietf.org; Sat, 19 Nov 2005 20:34:54 +0100 Received: from c-134-89-146.hh.dial.de.ignite.net ([62.134.89.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Nov 2005 20:34:54 +0100 Received: from nobody by c-134-89-146.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Nov 2005 20:34:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 19 Nov 2005 20:33:00 +0100 Organization: Lines: 40 Message-ID: <437F7DEC.1F30@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: c-134-89-146.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Need more interesting distance metric (?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I note that multiplying the scores by "q" (quality) weights > can produce interleaved lists when working with a language > priority list (like Accept-Language). That's okay, but please stick to the original "scoring" idea. Maybe we should use the term "scoring" instead of "distance metric", the latter is somewhat unclear, there's no clear limit for the number of variants. For extensions we have at least a theoretical limit 25. Multiple variants and extensions are messy. I don't see the point of splitting it into _five_ dimensions. The original four dimensions language + script + region + "whatever" were already difficult. >From my POV the region is just a special case of "whatever", like variants and extensions. Either it's important, I want en-US and no other en-* (or en-GB-oed and no other en-*), or it's irrelevant. It's the job of the scoring to help me with this, the only case I really care about is "I don't want it if it's no Latin". >> But if this thing gets too complicated, or too imprecise, >> we should also seriously consider dropping it. > Perhaps, although we could go the route of being less > specific about the weights and just describing the scheme > generally. I tend to favor what we've done, though. I'm not convinced. If I get de-DE-1996 as Braille I'm lost. The *-Brai q=0.0 approach could allow me to say so, with any scoring, so why not simply use 10-5-1-1-1 if you insist on five dimensions ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 19 15:05:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdYxq-0008So-SA; Sat, 19 Nov 2005 15:05:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdYxp-0008Sc-F6 for ltru@megatron.ietf.org; Sat, 19 Nov 2005 15:05:33 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14322 for ; Sat, 19 Nov 2005 15:04:56 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EdYwc-0006Hs-ME for ltru@lists.ietf.org; Sat, 19 Nov 2005 21:04:18 +0100 Received: from c-134-89-146.hh.dial.de.ignite.net ([62.134.89.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Nov 2005 21:04:18 +0100 Received: from nobody by c-134-89-146.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Nov 2005 21:04:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 19 Nov 2005 21:01:46 +0100 Organization: Lines: 20 Message-ID: <437F84AA.6D91@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: c-134-89-146.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching: make sure subtags are explained X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > UM, by the way, is "United States Minor Outlying Islands" > region. Most of them uninhabited, unusable for laguage tags. Even if en-UM as spoken on Midway is different from en-US, then what about en-UM as spoken on Wake Island ? Baker 0 http://www.cia.gov/cia/publications/factbook/print/fq.html Howland 0 http://www.cia.gov/cia/publications/factbook/print/hq.html Johnston 361 http://www.cia.gov/cia/publications/factbook/print/jq.html Kingman 0 http://www.cia.gov/cia/publications/factbook/print/kq.html Midway 40 http://www.cia.gov/cia/publications/factbook/print/mq.html Navassa 0 http://www.cia.gov/cia/publications/factbook/print/bq.html Palmyra 12 http://www.cia.gov/cia/publications/factbook/print/lq.html Wake 200 http://www.cia.gov/cia/publications/factbook/print/wq.html 613 Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 19 16:25:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdaDH-0007ma-1E; Sat, 19 Nov 2005 16:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdaDG-0007mS-C9 for ltru@megatron.ietf.org; Sat, 19 Nov 2005 16:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17202 for ; Sat, 19 Nov 2005 16:24:57 -0500 (EST) Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdaVM-0003nh-R2 for ltru@ietf.org; Sat, 19 Nov 2005 16:44:18 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAJLPHvr010130 for ; Sat, 19 Nov 2005 16:25:17 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAJLOxvE075332 for ; Sat, 19 Nov 2005 14:24:59 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAJLPHsD027059 for ; Sat, 19 Nov 2005 14:25:17 -0700 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAJLPGba027048; Sat, 19 Nov 2005 14:25:16 -0700 Message-ID: <437F9839.7010605@icu-project.org> Date: Sat, 19 Nov 2005 13:25:13 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Wildcards in filtering X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Here is the problem I have with the current formulation of "*" in filtering. There is a conflict between the user expectations and the need for a determinant answer. A. If a user has "sr-*-BA", and the actual content is one of: sr sr-Cyrl sr-Cyrl-BA sr-Latn Then I believe the user's perfectly reasonable expectations would be that "sr-Cyrl-BA" would match. That is an exact, single match against the pattern. B. However, if the content is sr sr-Cyrl sr-Cyrl-BA sr-Latn sr-Latn-BA then we can't get a determinant answer from that pattern: both sr-Cyrl-BA and sr-Latn-BA are perfectly reasonable matches. Your proposal has the advantage of getting a determinant answer, but not matching the user expectations. You transform the sr-*-BA into sr-BA, then do the lookup. In both cases A and B above, you'd return "sr", which is not what the user would expect. My view is that there are two possible alternatives. ===== 1. Continue the fallback unless there is a *single* match, adding text to the effect that: As usual, a wildcard matches against a subtag in that position. When filtering, however, the fallback process returns contents if and only if there is exactly one match against the language priority list. If there are two possible matches against the wildcard (or zero) then the fallback continues. Thus suppose we are filtering with the language priority list "sr-Cyrl-BA", and content for the following tags: sr sr-Cyrl sr-Cyrl-BA sr-Latn The result is the content for "sr-Cyrl-BA". When filtering with the language priority list "sr-*", and the same possible content, the result is the content for "sr". ===== 2. Leave out wildcards entirely, replacing the discussion of wildcards (in two places) with text to the effect that: Wildcards are not permitted in filtered lookup, because they allow for the possiblity of indeterminant answers. If, for example, the language priority list is "sr-*" and the content is the following, then the results would be indeterminant. sr sr-Cyrl sr-Cyrl-BA sr-Latn ==== In both cases, add: However, a protocol MAY add additional specifications to filtered lookup to provide for for resolution of cases where there are multiple matches. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 19 19:19:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edcvk-0004c2-Kp; Sat, 19 Nov 2005 19:19:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edcvj-0004bx-SX for ltru@megatron.ietf.org; Sat, 19 Nov 2005 19:19:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22346 for ; Sat, 19 Nov 2005 19:19:04 -0500 (EST) Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EddDr-0006n8-Tl for ltru@ietf.org; Sat, 19 Nov 2005 19:38:25 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAK0JPts009005 for ; Sat, 19 Nov 2005 19:19:25 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAK0J7vE080220 for ; Sat, 19 Nov 2005 17:19:07 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAK0JOKc013360 for ; Sat, 19 Nov 2005 17:19:25 -0700 Received: from [127.0.0.1] (sig-9-48-114-132.mts.ibm.com [9.48.114.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAK0JMRh013324; Sat, 19 Nov 2005 17:19:24 -0700 Message-ID: <437FC108.1010500@icu-project.org> Date: Sat, 19 Nov 2005 16:19:20 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Wildcards in filtering References: <437F9839.7010605@icu-project.org> In-Reply-To: <437F9839.7010605@icu-project.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm sorry, I really jumbled my message. What I meant was *lookup*; replace the word "filter" by that (mutatis mutandis) and see if it makes more sense. -- Mark Mark Davis wrote: > Here is the problem I have with the current formulation of "*" in > filtering. There is a conflict between the user expectations and the > need for a determinant answer. > > A. If a user has "sr-*-BA", and the actual content is one of: > > sr > sr-Cyrl > sr-Cyrl-BA > sr-Latn > > Then I believe the user's perfectly reasonable expectations would be > that "sr-Cyrl-BA" would match. That is an exact, single match against > the pattern. > > B. However, if the content is > > sr > sr-Cyrl > sr-Cyrl-BA > sr-Latn > sr-Latn-BA > > then we can't get a determinant answer from that pattern: both > sr-Cyrl-BA and sr-Latn-BA are perfectly reasonable matches. > > > Your proposal has the advantage of getting a determinant answer, but > not matching the user expectations. You transform the sr-*-BA into > sr-BA, then do the lookup. In both cases A and B above, you'd return > "sr", which is not what the user would expect. > > > My view is that there are two possible alternatives. > > ===== > > 1. Continue the fallback unless there is a *single* match, adding text > to the effect that: > > As usual, a wildcard matches against a subtag in that position. When > filtering, however, the fallback process returns contents if and > only if there is exactly one match against the language priority > list. If there are two possible matches against the wildcard (or > zero) then the fallback continues. Thus suppose we are filtering > with the language priority list "sr-Cyrl-BA", and content for the > following tags: > > sr > sr-Cyrl > sr-Cyrl-BA > sr-Latn > > The result is the content for "sr-Cyrl-BA". When filtering with the > language priority list "sr-*", and the same possible content, the > result is the content for "sr". > > > ===== > > 2. Leave out wildcards entirely, replacing the discussion of wildcards > (in two places) with text to the effect that: > > Wildcards are not permitted in filtered lookup, because they allow > for the possiblity of indeterminant answers. If, for example, the > language priority list is "sr-*" and the content is the following, > then the results would be indeterminant. > > sr > sr-Cyrl > sr-Cyrl-BA > sr-Latn > > > ==== > In both cases, add: > > However, a protocol MAY add additional specifications to filtered > lookup to provide for for resolution of cases where there are > multiple matches. > > > > > _______________________________________________ > 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 Nov 19 22:53:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdgGZ-0006A0-JK; Sat, 19 Nov 2005 22:53:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdgGY-00069v-75 for ltru@megatron.ietf.org; Sat, 19 Nov 2005 22:53:22 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28785 for ; Sat, 19 Nov 2005 22:52:45 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051120035250.UGQN15290.mta11.adelphia.net@DGBP7M81> for ; Sat, 19 Nov 2005 22:52:50 -0500 Message-ID: <002801c5ed86$28eae350$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Nov 2005 19:54:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] en-UM and the like (was: Re: Matching: make sure subtags are explained) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> UM, by the way, is "United States Minor Outlying Islands" >> region. > > Most of them uninhabited, unusable for laguage tags. Even if > en-UM as spoken on Midway is different from en-US, then what > about en-UM as spoken on Wake Island ? Please, I beg, let's not go down this dusty road again. Yes, of course you are right from a practical standpoint. It is absurd to talk about "language X as spoken in" an uninhabited region, and for regions populated by military or scientific personnel, the language variant(s) is/are completely determined by wherever the itinerant population comes from. "English as spoken in Australia" is en-US on an American research base, en-AU on an Australian base, and so forth. en-BV is preposterous. But we have made a commitment to stay compatible with all language tags that were valid under RFC 1766 and 3066, and that means allowing any ISO 3166-1 code element valid since 1995 as a region subtag, no matter how preposterous the language-region combination. To do otherwise would be to claim authority and responsibility for determining "what is a country," which we have decided not to do for both practical and scriptural reasons. Region subtagging can be too precise, not precise enough, or maybe even both at the same time. Let's accept that and turn the page. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 00:56:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdiC0-0008Qm-11; Sun, 20 Nov 2005 00:56:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdiBy-0008Qh-87 for ltru@megatron.ietf.org; Sun, 20 Nov 2005 00:56:46 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02543 for ; Sun, 20 Nov 2005 00:56:08 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051120055614.IPHV17844.mta9.adelphia.net@DGBP7M81> for ; Sun, 20 Nov 2005 00:56:14 -0500 Message-ID: <002e01c5ed97$6460d780$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Nov 2005 21:58:12 -0800 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.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: en-UM and the like (was: Re: Matching: make sure subtags are explained) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I wrote: > "English as spoken in Australia" is en-US on an American research > base, en-AU on an Australian base, and so forth. Sorry, obviously that should have been "English as spoken in Antarctica." -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 06:37:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdnW6-0005dw-9U; Sun, 20 Nov 2005 06:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdnW4-0005dk-FR for ltru@megatron.ietf.org; Sun, 20 Nov 2005 06:37:52 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13662 for ; Sun, 20 Nov 2005 06:37:14 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EdnUg-0000bU-Qk for ltru@lists.ietf.org; Sun, 20 Nov 2005 12:36:26 +0100 Received: from pd9fba93f.dip0.t-ipconnect.de ([217.251.169.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2005 12:36:26 +0100 Received: from nobody by pd9fba93f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2005 12:36:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 20 Nov 2005 12:32:05 +0100 Organization: Lines: 45 Message-ID: <43805EB5.8D0@xyzzy.claranet.de> References: <002801c5ed86$28eae350$050aa8c0@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: pd9fba93f.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: en-UM and the like X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Please, I beg, let's not go down this dusty road again. As a dusty road it isn't suited for an example in a part of BCP 47. We also replaced en-boont by better examples. The whole concept of region codes derived from 3166-1 is dubious, we only kept it for backward compatibility. The region codes in language tags are in no way more important than variants or future extensions, it's a waste of time to invent complex scoring schemes where the region code is always more relevant than variant(s) or extension(s): Left-to-right automatically does this. Something simple like 32-16-8-3-1 is good enough to reflect left-to-right numerically for almost all practical cases. An "interesting" scoring example would allow to overrule the left-to-right effect, e.g. 8-4-1-1-1. It could even rearrange the left-to-right order, just use 4-8-1-1-1 for some "script first" effect. or 8-4-0-1-1 for "ignore region". > It is absurd to talk about "language X as spoken in" an > uninhabited region, and for regions populated by military > or scientific personnel, the language variant(s) is/are > completely determined by wherever the itinerant population > comes from. Yes, and by absuing en-UM as example that point is obscured, and next you see is a strange debate about ga-GB vs. "ga-UK", where my main question would be whether ga is different from ga-IE, and if yes whether ga-GB is actually ga-IE. The region codes in language tags aren't for the geographical position of the speaker or author, en-UM is "valid" but bogus. > en-BV is preposterous. ACK. There are more than enough relevant examples like en-JA. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 09:17:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edq0Y-00029X-LI; Sun, 20 Nov 2005 09:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edq0W-00029O-EO for ltru@megatron.ietf.org; Sun, 20 Nov 2005 09:17:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21815 for ; Sun, 20 Nov 2005 09:16:48 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdqIj-0002SR-Jt for ltru@ietf.org; Sun, 20 Nov 2005 09:36:17 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AACE42596C0; Sun, 20 Nov 2005 15:16:47 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28936-02; Sun, 20 Nov 2005 15:16:43 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43C032596BF; Sun, 20 Nov 2005 15:16:43 +0100 (CET) Date: Sun, 20 Nov 2005 15:18:49 +0100 From: Harald Tveit Alvestrand To: Addison Phillips , ltru@ietf.org Subject: Re: [Ltru] scored filtering demo... Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On fredag, november 18, 2005 16:22:13 -0800 Addison Phillips wrote: > There is a demo page for scored filtering on my website based on my > little Java implementation of the Scored Filtering in draft-06. > > http://www.inter-locale.com/langtags/index.jsp > > The demo has one quirk: grandfathered tags are not parsed properly, so > "en-boont" produces funny scores (it doesn't match the range 'en', for > example). > > There is a canned list of language tags that the range you enter is > compared to. There may be bugs as yet. > > Based on some light experimentation, we may wish to change aspects of the > algorithm (especially expansion of fields in either ranges or tags to the > wildcard). hmm... very interesting! de-CH gives zero distance to de, de-CH and de-Latn in the first variant, zero distance to de-CH and de-Latn-CH-1901 in the second variant, and de-CH only in the third variant. It wasn't clear to me what the difference between the 3 variants was... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 13:36:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edu2l-0003j4-Q0; Sun, 20 Nov 2005 13:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edu2k-0003hs-I3 for ltru@megatron.ietf.org; Sun, 20 Nov 2005 13:36:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05812 for ; Sun, 20 Nov 2005 13:35:20 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EduKx-0000is-Uj for ltru@ietf.org; Sun, 20 Nov 2005 13:54:53 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Nov 2005 10:35:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] scored filtering demo... Date: Sun, 20 Nov 2005 10:35:32 -0800 Message-ID: Thread-Topic: [Ltru] scored filtering demo... Thread-Index: AcXt3R2Qb6T2gLiaTweO7fa5VeeP7gAI6HTw From: "Addison Phillips" To: "Harald Tveit Alvestrand" , X-OriginalArrivalTime: 20 Nov 2005 18:35:34.0192 (UTC) FILETIME=[3172EB00:01C5EE01] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2134107581==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2134107581== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSGFyYWxkLA0KDQpUaGUgZGlmZmVyZW5jZXMgYXJlIGludGVyZXN0aW5nLCBhcmVuJ3QgdGhl eT8NCg0KVGhlIGZpcnN0IG9uZSBmb2xsb3dzIHRoZSBjdXJyZW50IHRleHQgaW4gdGhlIGRyYWZ0 LCBpbiB3aGljaCBtaXNzaW5nIGZpZWxkcyBpbiByYW5nZXMgYW5kIHRhZ3MgZXhwYW5kIHRvIHdp bGRjYXJkcyBsaWtlIHRoaXM6DQoNCmVuLVVTDQogICBUYWc6ICAgKGVuLCAqLCBVUywgKiwgKikN CiAgIFJhbmdlOiAoZW4sICosIFVTLCAiIiwgIiIpDQoNClRoZSBzZWNvbmQgdmFyaWFudCByZXZl cnNlcyB0aGUgZXhwYW5zaW9uOg0KDQplbi1VUw0KICAgUmFuZ2U6IChlbiwgKiwgVVMsICosICop DQogICBUYWc6ICAgKGVuLCAqLCBVUywgIiIsICIiKQ0KDQpUaGUgdGhpcmQgdmFyaWF0aW9uIGRv ZXMgKm5vKiB3aWxkY2FyZCBleHBhbnNpb246DQoNCmVuLVVTDQogICBUYWc6ICAgKGVuLCAiIiwg VVMsICIiLCAiIikNCiAgIFJhbmdlOiAoZW4sICIiLCBVUywgIiIsICIiKQ0KDQpBZGRpc29uDQoN CkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0 d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4g YXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBI YXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXQ0KPiBT ZW50OiAyMDA15bm0MTHmnIgyMOaXpSA2OjE5DQo+IFRvOiBBZGRpc29uIFBoaWxsaXBzOyBsdHJ1 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gc2NvcmVkIGZpbHRlcmluZyBkZW1vLi4u DQo+IA0KPiANCj4gDQo+IC0tT24gZnJlZGFnLCBub3ZlbWJlciAxOCwgMjAwNSAxNjoyMjoxMyAt MDgwMCBBZGRpc29uIFBoaWxsaXBzDQo+IDxhZGRpc29uLnBoaWxsaXBzQHF1ZXN0LmNvbT4gd3Jv dGU6DQo+IA0KPiA+IFRoZXJlIGlzIGEgZGVtbyBwYWdlIGZvciBzY29yZWQgZmlsdGVyaW5nIG9u IG15IHdlYnNpdGUgYmFzZWQgb24gbXkNCj4gPiBsaXR0bGUgSmF2YSBpbXBsZW1lbnRhdGlvbiBv ZiB0aGUgU2NvcmVkIEZpbHRlcmluZyBpbiBkcmFmdC0wNi4NCj4gPg0KPiA+IGh0dHA6Ly93d3cu aW50ZXItbG9jYWxlLmNvbS9sYW5ndGFncy9pbmRleC5qc3ANCj4gPg0KPiA+IFRoZSBkZW1vIGhh cyBvbmUgcXVpcms6IGdyYW5kZmF0aGVyZWQgdGFncyBhcmUgbm90IHBhcnNlZCBwcm9wZXJseSwg c28NCj4gPiAiZW4tYm9vbnQiIHByb2R1Y2VzIGZ1bm55IHNjb3JlcyAoaXQgZG9lc24ndCBtYXRj aCB0aGUgcmFuZ2UgJ2VuJywgZm9yDQo+ID4gZXhhbXBsZSkuDQo+ID4NCj4gPiBUaGVyZSBpcyBh IGNhbm5lZCBsaXN0IG9mIGxhbmd1YWdlIHRhZ3MgdGhhdCB0aGUgcmFuZ2UgeW91IGVudGVyIGlz DQo+ID4gY29tcGFyZWQgdG8uIFRoZXJlIG1heSBiZSBidWdzIGFzIHlldC4NCj4gPg0KPiA+IEJh c2VkIG9uIHNvbWUgbGlnaHQgZXhwZXJpbWVudGF0aW9uLCB3ZSBtYXkgd2lzaCB0byBjaGFuZ2Ug YXNwZWN0cyBvZg0KPiB0aGUNCj4gPiBhbGdvcml0aG0gKGVzcGVjaWFsbHkgZXhwYW5zaW9uIG9m IGZpZWxkcyBpbiBlaXRoZXIgcmFuZ2VzIG9yIHRhZ3MgdG8NCj4gdGhlDQo+ID4gd2lsZGNhcmQp Lg0KPiANCj4gaG1tLi4uIHZlcnkgaW50ZXJlc3RpbmchDQo+IA0KPiBkZS1DSCBnaXZlcyB6ZXJv IGRpc3RhbmNlIHRvIGRlLCBkZS1DSCBhbmQgZGUtTGF0biBpbiB0aGUgZmlyc3QgdmFyaWFudCwN Cj4gemVybyBkaXN0YW5jZSB0byBkZS1DSCBhbmQgZGUtTGF0bi1DSC0xOTAxIGluIHRoZSBzZWNv bmQgdmFyaWFudCwgYW5kIGRlLQ0KPiBDSA0KPiBvbmx5IGluIHRoZSB0aGlyZCB2YXJpYW50Lg0K PiANCj4gSXQgd2Fzbid0IGNsZWFyIHRvIG1lIHdoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGUgMyB2YXJpYW50cyB3YXMuLi4NCg0K --===============2134107581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2134107581==-- From ltru-bounces@ietf.org Sun Nov 20 15:39:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edvy6-0003LK-NL; Sun, 20 Nov 2005 15:39:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edvy4-0003LF-Vi for ltru@megatron.ietf.org; Sun, 20 Nov 2005 15:39:20 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11945 for ; Sun, 20 Nov 2005 15:38:43 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051120203849.YTTE15290.mta11.adelphia.net@DGBP7M81> for ; Sun, 20 Nov 2005 15:38:49 -0500 Message-ID: <00bc01c5ee12$b00e0ce0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 20 Nov 2005 12:40:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: David Crystal's red alert X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC (Jefsey) Morfin wrote: > Your own remark on "Guam" shows that you are not happy with the > obligation to only respect RFC 3066. I said no such thing. You lie again. I said that some language-region combinations are preposterous from the standpoint of identifying language variants. I never said I was "not happy" with that situation. Any other mechanism would have its own disadvantages. > My position only goes a step > further in term of security: I have no objection to _also_ support > RFC 3066, I have no objection to even set-it up as a _default_. I > have a very deep ethic concern at making it _exclusive_. This leads > this group to twist reality and spoil a great and good job to _only_ > match it. I have a practical deep problem in having no way to > non-conflictingly match other needs in term of modes, tones, styles, > mediums, dates, sociolinguistic or trade entities, etc. etc. Of course there is a way to do this. Write up your own specification and follow it. We've been saying this for a year now. > In this I share the "red alert". What happened in Tunis, for example, > just after the UNESCO GA where the mood was different, gives me the > bitter feeling of a Monroe split - in addition to the perfectly > understandable and acceptable technical, political, economical and > societal positions of the various sides. > > The "red alert" is for this group to make sure that its work (which > will greatly extend with RFC 3066 bis if applied) has ethical effects. > This is the same kind of moral concerns as the people of the Manhattan > Project had. And I think the impact on the people of the world - > through their language and cultures - is of the same magnitude. Maybe someone should write to Professor Crystal and ask what he thinks of RFC 3066 and language tagging, instead of putting words in his mouth. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 15:47:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edw5u-0004Vk-6Y; Sun, 20 Nov 2005 15:47:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edw5s-0004Vc-Jt for ltru@megatron.ietf.org; Sun, 20 Nov 2005 15:47:24 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12316 for ; Sun, 20 Nov 2005 15:46:47 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051120204653.LORD17844.mta9.adelphia.net@DGBP7M81> for ; Sun, 20 Nov 2005 15:46:53 -0500 Message-ID: <00c001c5ee13$d2c93c40$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 20 Nov 2005 12:48:53 -0800 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: David Crystal's red alert X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I sincerely apologize for sending this to the wrong mailing list. My humblest apologies. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 19:59:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01e-0004bh-EX; Sun, 20 Nov 2005 19:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01e-0004bS-0T for ltru@megatron.ietf.org; Sun, 20 Nov 2005 19:59:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23193 for ; Sun, 20 Nov 2005 19:58:38 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee0Jx-0001OC-Dx for ltru@ietf.org; Sun, 20 Nov 2005 20:18:15 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL0whd18809; Mon, 21 Nov 2005 09:58:43 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7757_f639fc46_5a29_11da_90f6_00304811fd80; Mon, 21 Nov 2005 09:58:43 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL0vPYn017227; Mon, 21 Nov 2005 09:58:18 +0900 Message-Id: <6.0.0.20.2.20051120162120.01a101f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 20 Nov 2005 16:31:10 +0900 To: Mark Davis , Mark Davis From: Martin Duerst Subject: Re: [Ltru] Wildcards in filtering In-Reply-To: <437FC108.1010500@icu-project.org> References: <437F9839.7010605@icu-project.org> <437FC108.1010500@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 09:19 05/11/20, Mark Davis wrote: >I'm sorry, I really jumbled my message. What I meant was *lookup*; replace the word "filter" by that (mutatis mutandis) and see if it makes more sense. -- Mark I don't really see the point of throwing out two (or more) choices and go for something that easily could be seen as matching less just to avoid having to throw a dice. Or did I misunderstand something? >Mark Davis wrote: > >> Here is the problem I have with the current formulation of "*" in filtering. There is a conflict between the user expectations and the need for a determinant answer. >> >> A. If a user has "sr-*-BA", and the actual content is one of: >> >> sr >> sr-Cyrl >> sr-Cyrl-BA >> sr-Latn >> >> Then I believe the user's perfectly reasonable expectations would be that "sr-Cyrl-BA" would match. That is an exact, single match against the pattern. Yes, agreed. >> B. However, if the content is >> >> sr >> sr-Cyrl >> sr-Cyrl-BA >> sr-Latn >> sr-Latn-BA >> >> then we can't get a determinant answer from that pattern: both sr-Cyrl-BA and sr-Latn-BA are perfectly reasonable matches. So can't we just choose one of them, at random? >> Your proposal has the advantage of getting a determinant answer, but not matching the user expectations. You transform the sr-*-BA into sr-BA, then do the lookup. In both cases A and B above, you'd return "sr", which is not what the user would expect. I'm not sure that there would be that many variants, anyway. If there is sr-Cyrl and sr-Latn, then sr is most probably just a second mention of the content labeled by either sr-Cyrl or sr-Latn. Of course, in the general case, that may be different. >> My view is that there are two possible alternatives. >> >> ===== >> >> 1. Continue the fallback unless there is a *single* match, adding text to the effect that: >> >> As usual, a wildcard matches against a subtag in that position. When >> filtering, however, the fallback process returns contents if and >> only if there is exactly one match against the language priority >> list. If there are two possible matches against the wildcard (or >> zero) then the fallback continues. Thus suppose we are filtering >> with the language priority list "sr-Cyrl-BA", and content for the >> following tags: >> >> sr >> sr-Cyrl >> sr-Cyrl-BA >> sr-Latn >> >> The result is the content for "sr-Cyrl-BA". When filtering with the >> language priority list "sr-*", and the same possible content, the >> result is the content for "sr". As I said above, I wouldn't think that makes sense. If there are two matches that are 'better' than anything else, but can't be distinguished, let's just return one of them at random or in an implementation dependent fashion. >> ===== >> >> 2. Leave out wildcards entirely, replacing the discussion of wildcards (in two places) with text to the effect that: >> >> Wildcards are not permitted in filtered lookup, because they allow >> for the possiblity of indeterminant answers. If, for example, the >> language priority list is "sr-*" and the content is the following, >> then the results would be indeterminant. >> >> sr >> sr-Cyrl >> sr-Cyrl-BA >> sr-Latn >> >> >> ==== >> In both cases, add: >> >> However, a protocol MAY add additional specifications to filtered >> lookup to provide for for resolution of cases where there are >> multiple matches. detail: "for for" -> "for" Two concerns: 1) Adding wildcards back in will need a lot of careful work which we shouldn't expect the users of our draft to need. Forbidding it for cases that don't want them may be a lot easier for users, although a bit more work for us. 2) It is easily possible that in a system (say database,...), there are multiple variants of content that are tagged exactly the same. So the whole effort of avoiding ties because of slightly differently tagged content may be fruitless anyway. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 19:59:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01f-0004c5-JF; Sun, 20 Nov 2005 19:59:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01e-0004bP-0Q for ltru@megatron.ietf.org; Sun, 20 Nov 2005 19:59:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23187 for ; Sun, 20 Nov 2005 19:58:38 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee0Jx-0001OP-ER for ltru@ietf.org; Sun, 20 Nov 2005 20:18:14 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL0whu03121; Mon, 21 Nov 2005 09:58:43 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 320f_f623b4cc_5a29_11da_8968_0030482533a1; Mon, 21 Nov 2005 09:58:43 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL0vPYl017227; Mon, 21 Nov 2005 09:58:17 +0900 Message-Id: <6.0.0.20.2.20051120161626.01a12440@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 20 Nov 2005 16:16:40 +0900 To: Mark Davis , Addison Phillips From: Martin Duerst In-Reply-To: <437E8214.2@icu-project.org> References: <437E8214.2@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] On quoting X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [co-chair hat on] Please use quoting carefully. Not enough quoting is confusing, but quoting too much should also be avoided. [I'm on purpose quoting a full mail below.] Thanks, Martin. At 10:38 05/11/19, Mark Davis wrote: > > >Addison Phillips wrote: > >>>>>---- >>>>> >>>>>Wildcard values in an extended language range are supposed to match any >>>>>value >>>>>=> >>>>>Wildcard values in an extended language range match any value >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>No, they are *supposed* to match, but in this case they don't. They match >>>> >>>> >>>the empty value. >>> >>> >>>> >>>> >>>I read that differently. When you say "supposed to match", it sounds >>>like there is a choice, that there are some values that they don't >>>match. Like the US is "supposed to" disallow torture. >>> >>> >> >>When considered in isolation, I suppose one could have that reading, but I think the text is actually pretty clear here. Perhaps it could be clearer. The missing point that I was trying to convey is that extended language ranges do not produce the expected results based on their meaning. The range "en-*-US" will never pass through content labeled "en-Brai" (or any other content with a script subtag), even though this matches the meaning of the extended language range. From "en-US" you skip immediately to "en". It is supposed to match... and it doesn't. >> >>I think we might make a version of the change you suggest and then spell out my example. >> >> >ok > >>The text currently: >> >>-- >>In some cases, the language priority list might contain one or more extended language ranges (as, for example, when the same language priority list is used as input for both lookup and filtering operations). Wildcard values in an extended language range are supposed to match any value that occurs in that position in a language tag. Since only one item can be returned for any given lookup request, the wildcards must be processed in a predictable manner (or the same request might produce widely varying results). Thus, for each range in the language priority list, the following rules must be applied to produce a basic language range for use in the fallback mechanism: >>-- >> >>Proposed change: >> >>-- >>...Wildcard values in an extended language range normally match any value that occurs in that position in a language tag... -- >> >>And then add (after the example): >> >>-- >>The resulting basic language ranges will produce different results that the user might expect. For example, a request for "en-*-US" will never find content labeled "en-Brai", even though this tag matches the extended language range. >>-- >> >> >>Addison P. Phillips >>Globalization Architect, Quest Software >> >>Internationalization is not a feature. >>It is an architecture. >> >> >>>-----Original Message----- >>>From: Mark Davis [mailto:mark.davis@icu-project.org] >>>Sent: 2005$Bj;%((B11$Bk|/(B8$Bkw!&(B 13:42 >>>To: Addison Phillips >>>Cc: ltru@ietf.org >>>Subject: Re: [Ltru] draft-06 comments: choice of range >>> >>> >>> >>>Addison Phillips wrote: >>> >>> >>> >>>>Comments interlinearly below. I have some strong reservations about some >>>> >>>> >>>of these comments. >>> >>> >>>>Addison >>>> >>>>Addison P. Phillips >>>>Globalization Architect, Quest Software >>>> >>>>Internationalization is not a feature. >>>>It is an architecture. >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Mark Davis [mailto:mark.davis@icu-project.org] >>>>>Sent: 2005$Bj;%((B11$Bk|/(B8$Bkw!&(B 10:15 >>>>>To: Addison Phillips >>>>>Cc: ltru@ietf.org >>>>>Subject: Re: [Ltru] draft-06 comments: choice of range >>>>> >>>>> >>>>> >>>>> >>>>> >>>>// text removed >>>> >>>> >>>> >>>> >>>// just keep the text, makes it harder to tell what you are commenting >>>on ;-) >>> >>> >>> >>>>>[The "this also means" only applies when the implemenation does the MAY.] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Agreed, although I tend to think we should go the other direction and say >>>> >>>> >>>MUST. >>> >>> >>>> >>>> >>>If we say must, then we are really saying that any input range x-y-z-w >>>acts like x-*-y-*-z-*-w, whenever something could go between. Since we >>>say the algorithms work in the absence of parsing the language tag, that >>>means putting them in all the time. Seems like a bit much, but I'll mull >>>it over. >>> >>> >>> >>>>>---- >>>>> >>>>>measurment >>>>>[spell-check] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Thanks. >>>> >>>> >>>> >>>> >>>>>---- >>>>> >>>>>[General Observation. >>>>> >>>>>We need to give a mechanism that will always give a precise, determinant >>>>>answer. We then let protocols specify alternatives (if they need to) by >>>>>additional specification. In particular, in each section we have to make >>>>>clear what exactly happens with a language range, and what happens with >>>>>a language priority list. >>>>> >>>>>For filtering, this can be done by moving the discussion of the language >>>>>priority list up into 3.2. ] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Actually, I'd go further and suggest that all of the matching schemes be >>>> >>>> >>>defined in terms of language priority lists (a language range by itself >>>being the collapsed case of a language priority list with only one item-- >>>inside the specific scheme we describe how to match a single range to a >>>single tag, but the scheme overall matches the user's language >>>preferences--a list--against content). Lookup now reads this way. >>> >>> >>>That works too. Then we just say at the very top that all the mechanisms >>>treat a single language range as a single element language priority list. >>> >>> >>> >>>>This section 3.2 text: >>>> >>>>-- >>>>Filtering is used to select the set of content that matches a given >>>> >>>> >>>prefix. >>> >>> >>>>-- >>>> >>>>Should be modified to say: >>>> >>>>-- >>>>Filtering is used to select the set of content that matches the user's >>>> >>>> >>>language preferences (see Section 2.1, Language Priority Lists). >>> >>> >>>>-- >>>> >>>>Before objecting to this change because it removes the critical point >>>> >>>> >>>about the range being a prefix, consider that the entire second paragraph >>>of this section covers that. >>> >>> >>>> >>>> >>>> >>>>>3.2. >>>>>If the language priority list (see Section 2.1 (Lists of Language >>>>>Ranges) >>>>>) >>>>>contains more than one range, the content returned is typically ordered >>>>>in descending level of preference. >>>>>=> >>>>>If the language priority list (see Section 2.1 (Lists of Language >>>>>Ranges) >>>>>) >>>>>contains more than one range, the contents that match that range are >>>>>added to the set of results. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>The word content in this sentence is already plural. "Contents" is wrong. >>>> >>>> >>>If we want to be explicit about it, we should use the previously quoted >>>formulation "set of content". >>> >>> >>>> >>>> >>>set of content works. >>> >>> >>> >>>> >>>> >>>>>[At the end of the section, after we've introduced the discussion of an >>>>>ordered list and distance metric, add] >>>>> >>>>>When the set of matches is returned, the items are in descending order >>>>>where the weight for each item is the priority in the language priority >>>>>list divided by the distance metric. (If the filtering method does not >>>>>supply a distance metric, then the distance metric is 1.) If the item >>>>>matches multiple ranges, then its weight is the square root of the sum >>>>>of squares of the individual weights for each range. If two items have >>>>>the same weight, then their ordering is based on a case-insensitive >>>>>ordering of the language tags. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Ugh. Icky. Many items will have the same weight even in spite of this >>>> >>>> >>>complex scheme. >>> >>> >>>> >>>> >>>Can't get around that. If priorities are equal and there is no distance >>>metric, then you essentially have an unordered list. >>> >>> >>> >>>>I note that q weights in Accept-Language are always less than or equal to >>>> >>>> >>>one and greater than or equal to zero. Your algorithm won't work correctly >>>with those values (instead multiplication of the score works better). >>> >>> >>>> >>>> >>>You're right that there is a numeric problem, but you can't multiply, >>>because smaller distances are better, but lower priorities are *worse*. >>>So you have to divide one way or another. Look at an example. >>> >>>X, q=0.5; Y, q=0.3; >>> >>>Z matches X with a distance of, say, 2. W matches Y with a distance of >>>10. If you multiply, you get >>> >>>Z -> (0.5 * 2) = 1 >>>W -> (0.3) * 10) = 3 >>> >>>That would rank Y better than Z! What you want is a division. >>> >>>Now, as I think about it, the simplest way is to still think of the >>>results as distances, with the smallest distance being the best. Then >>>the algorithm is >>> >>>a) toss out any q weights that are zero. After all, that means that you >>>give them *no* priority. >>>b) divide the distance by the priority. >>>c) order in ascending order >>> >>>Z -> (2 / 0.5) = 1 >>>W -> (10 / 0.3) = 33.33 >>> >>>which ranks them correctly. >>> >>>The square rooty stuff was just because distance metrics with multiple >>>fields weight better when you treat them as dimensional vectors. >>>However, in retrospect it is probably just simpler to take the minimum >>>of the possible weights. So if Q matches X with a distance of, say, 2. Q >>>matches Y with a distance of 10. Then the result would be the minimum, or >>>1. >>> >>> >>> >>>>>A protocol which uses language priority lists MAY specify an alternative >>>>>mechanism for computing the ordering. >>>>> >>>>>---- >>>>> >>>>>A protocol which uses language ranges MAY specify additional rules about >>>>>the semantics of "*"; >>>>>=> >>>>>A protocol which uses language ranges MAY specify additional rules about >>>>>the semantics of "*" or other tags; >>>>>[no reason to restrict it] >>>>> >>>>>---- >>>>> >>>>>Implementations or protocols sometimes might wish to use more >>>>>sophisticated weights that >>>>>=> >>>>>Implementations or protocols sometimes MAY specify the use of >>>>>alternative weights that >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Either "...protocols MAY..." or "... protocols sometimes might..." >>>> >>>> >>>> >>>> >>>sometimes MAY => MAY >>> >>> >>> >>>>I chose non-normative language initially to allow things without turning >>>> >>>> >>>the whole section into RFC 2119 soup. >>> >>> >>>> >>>> >>>>>---- >>>>>[Make subsections in Lookup. First language range lookup, then language >>>>>priority list lookup, then extended language range lookup.] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>I think that's an awful idea. >>>> >>>>And make up your mind: we REMOVED extended language range lookup because >>>> >>>> >>>it doesn$Bc`QU(B make sense. Lookup is now cast as I suggested above: it is >>>strictly a language priority list beast, but it starts by defined the >>>match between a tag and a range. >>> >>> >>>> >>>> >>>Lemme relook at it, but it seems to me that you are doing it, but *via* >>>transforming it. (but more in a separate message anyway). >>> >>> >>> >>>>>---- >>>>>Other examples of lookup might include: >>>>>=> >>>>>Other examples of lookup include: >>>>>[the examples *do* include. no need to be tentative ;-)] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Okay. >>>> >>>> >>>> >>>> >>>>>---- >>>>> >>>>>If this language range is the only one in the language priority list, it >>>>>matches the default content. If this language range is followed by other >>>>>language ranges, it should be skipped. >>>>>[doesn't address *;*] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Yes, it does... iteratively. >>>> >>>> >>>> >>>> >>>You're right. >>> >>> >>> >>>> >>>> >>>>>=> >>>>>All "*" language tags are removed from language priority list. If there >>>>>is nothing left, then it matches the default content. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>That's "ranges" in your first sentence. >>>> >>>> >>>> >>>> >>>>>---- >>>>> >>>>>5. (default content or the empty tag) >>>>>=> >>>>>5. (default) >>>>>[explain below what this is. it is also otherwise odd that 1-4 are tags, >>>>>but then this is 'content'] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>Okay. >>>> >>>> >>>> >>>> >>>>>---- >>>>> >>>>>When performing lookup using a language priority list, the progressive >>>>>search MUST proceed to consider each language range before finding the >>>>>default content or empty tag. The default content might be content with >>>>>no language tag (or with an empty value, as with xml:lang in the XML >>>>>specification), or it might be a particular language designated for that >>>>>bit of content. >>>>> >>>>>One common way to provide for default content is to allow a specific >>>>>language range to be set as the default for a specific type of request. >>>>>This language range is then treated as if it were appended to the end of >>>>>the language priority list, rather than after each item in the language >>>>>priority list. >>>>> >>>>>=> >>>>>[reword for clarity. Funny thing: when I first read 'might be content >>>>>with no language tag' I read it as the verb "be content with", like "be >>>>>happy with". The empty tag is not a valid language tag, so we should say >>>>>"und", then say that a system can use alternatives. Here is the text.] >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>No, not 'und' (and I *hate* 'und'). 'Und' would be an example of an >>>> >>>> >>>implementation specific decision. Personally I would prefer never to see >>>'und' content being used as a default. >>> >>> >>>> >>>> >>>Well, "" is illegal as a language-tag, so I was just using it as a >>>stand-in because we don't have a language tag for "root". >>> >>> >>> >>>>>When performing lookup using a language priority list, the progressive >>>>>search MUST consider each language range before finding the default. The >>>>>default might be specified as "und" (or be indicated with an empty >>>>>value, as with xml:lang in the XML specification, or with "root" as in >>>>>some systems), or it might be specified as a particular language range. >>>>>This language range is thus treated as if it were appended to the end of >>>>>the language priority list, rather than after each item in the language >>>>>priority list. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>I prefer not to make this change. I think it delves too closely into the >>>> >>>> >>>implementation specific. >>> >>> >>>> >>>> >>>It can't be left as it is. Other alternatives? >>> >>> >>> >>>>>---- >>>>> >>>>>5. (return default content) >>>>>a. ja-JP >>>>>b. ja >>>>>c. (empty tag or other default content) >>>>> >>>>>5. (default) >>>>>a. ja-JP >>>>>b. ja >>>>>c. und >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>How about: >>>> >>>>5. (default content lookup) >>>> a. ja-JP >>>> b. ja >>>> c. (implementation defined) >>>> >>>> >>>> >>>> >>>That works. >>> >>> >>> >>>>>---- >>>>> >>>>>Add >>>>> >>>>> >>>>> 3.3.x. Distance Metric Lookup >>>>> >>>>>Distance metric lookup is performed by producing an ordered list of >>>>>filtered results as specified in 3.2.2, then returning the first item. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>I think we'd best not go down that path. Among other things: it won't >>>> >>>> >>>work. Distance metric filtering can produce items with identical scores... >>> >>> >>>> >>>> >>>Ok, drop it. >>> >>> >>> >>>> >>>> >>>>>---- >>>>> >>>>>Mark >>>>> >>>>>P.S. I still think that the extended range lookup doesn't quite work, >>>>>but I'll send that in a separate message. >>>>> >>>>> >>>>> >>>>> >>>>[Addison Phillips] >>>> >>>>No, it doesn't work and we eliminated it. We've mapped extended ranges >>>> >>>> >>>onto basic ranges, which do work, producing different results than the >>>language priority list might lead one to expect. >>> >>> >>>> >>>> >>>Let me look this over again. >>> >>> >> >> >> > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 19:59:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01f-0004cT-O8; Sun, 20 Nov 2005 19:59:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee01e-0004bQ-0R for ltru@megatron.ietf.org; Sun, 20 Nov 2005 19:59:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23192 for ; Sun, 20 Nov 2005 19:58:38 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee0Jx-0001O0-Ei for ltru@ietf.org; Sun, 20 Nov 2005 20:18:15 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL0wdu03117; Mon, 21 Nov 2005 09:58:39 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 319d_f3cbae00_5a29_11da_8bac_0030482533a1; Mon, 21 Nov 2005 09:58:38 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL0vPYj017227; Mon, 21 Nov 2005 09:57:50 +0900 Message-Id: <6.0.0.20.2.20051120161306.01a12750@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 20 Nov 2005 16:15:12 +0900 To: Mark Davis , Addison Phillips From: Martin Duerst Subject: Re: wildcards in extended ranges (was RE: [Ltru] draft-06 comments:choice of range) In-Reply-To: <437E7FBE.2070300@icu-project.org> References: <437E7FBE.2070300@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 10:28 05/11/19, Mark Davis wrote: > > >Addison Phillips wrote: > >>(I'm going to reply to things individually to keep the mail threads manageable.) >>The current text says "MAY" for missing elements, allowing the first example to match or not at an implementation level. But I think it would be better if we chose one or the other. >> >> >My opinion is that we are describing a process. Within *that* description, they should be MUSTs. At the end we say of each process we say the allowed ways that a protocol can add specifications. That makes it very clear to users what they can expect out of a protocol *if it doesn't add any additional specifications*. > >So, I'm ok with MUST as long as we have the escape clause at the end. Not only in this specific context, but in general, I very much agree. Earlier versions of our draft just left too many MAYs and SHOULDs that confused protocol designers and implementers (who don't necessarily understand all the details). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 20 22:44:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee2bS-0008MS-08; Sun, 20 Nov 2005 22:44:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee2bR-0008MM-LS for ltru@megatron.ietf.org; Sun, 20 Nov 2005 22:44:25 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29979 for ; Sun, 20 Nov 2005 22:43:48 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051121034349.QLUG28023.mta13.adelphia.net@DGBP7M81> for ; Sun, 20 Nov 2005 22:43:49 -0500 Message-ID: <00e801c5ee4e$1193b600$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 20 Nov 2005 19:45:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Comments on draft-matching-07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Here are my comments on draft-matching-07. Most of these are editorial. Section 2.1: "It can get more complex: a speaker may wish to fallback from Skolt Sami to Northern Sami to Finnish." -> This should be "fall back," two words when used as a verb like this, but one word as a noun ("a fallback mechanism"). Please use search-and-replace for this. Section 2.2: "by adapting the ABNF[RFC4234] from HTTP/1.1 [RFC2616] :" and later "Basic language ranges were originally described in [RFC3066] and HTTP 1.1 [RFC2616]" -> Please call it either "HTTP 1.1" without the slash or "HTTP/1.1" with the slash, consistently. Section 2.4: "because the vast majority English documents are written in the Latin script" -> Add "of "after "majority." Section 2.4: "note that extensions and most private use subtags are orthogonal" -> "Private-use" should be hyphenated when used before the noun it modifies, like this. It would not be hyphenated as part of a phrase, like "these subtags are for private use." This occurs in various places, so please use search-and-replace here too. Section 3.1: "content labeled "zh-CN" is morely likely to match" -> "more" likely Section 3.2: "Filtering can produce either ordered or unordered set of results." -> Add "an" before "ordered," and optionally after "unordered" as well. Section 3.2: "measurment" -> Spelling error (typo) still not corrected. Section 3.2.2: "zh-Latn-CN-boont" -> "boont" is not a variant subtag. I would much prefer not to use it in an example. Try a real variant like "1901" or "nedis." Section 3.2.3: "Missing end subtags are expanded as the empty string..." -> Originally (based on draft-matching-06) I was going to complain that this section contradicted itself. In some places it appeared to say that all "missing" subtags were expanded as asterisk. Addison has rewritten this passage to clarify the different treatment of tags and ranges, and I'll have to read the new text carefully to see whether it de-confused me. Section 3.2.3: "Examples of various tag's distances from the range "en-US":... "fr-FR" 384 (language & region mismatch)" -> If language counts as 256 and region as 32, then this score should be 256 + 32 = 288, not 384. Again I need to read the revised text to see if the examples make more sense now. "en-Latn-US" 0 (all fields match) -> In reading this, it appears that "en-Brai-US" would also give a perfect 0 score, and for that matter so would "en-Egyp-US". Is that correct? We aren't looking at Suppress-Script here, so that doesn't factor into anything (unless we are one of the "implementations or protocols" that customize things). Section 7: "might be used to track specific individual's activities." -> This is not grammatical. It should be "track a specific individual's activities" if we are talking about one individual, or "track specific individuals' activities" (notice the apostrophe) if we are talking about multiple individuals. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 02:22:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee60f-0006tf-0b; Mon, 21 Nov 2005 02:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee60d-0006tZ-RM for ltru@megatron.ietf.org; Mon, 21 Nov 2005 02:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09942 for ; Mon, 21 Nov 2005 02:22:01 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee6J3-0001bl-4c for ltru@ietf.org; Mon, 21 Nov 2005 02:41:41 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAL7MO6p028865 for ; Mon, 21 Nov 2005 02:22:24 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAL7MPPt109092 for ; Mon, 21 Nov 2005 02:22:25 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAL7MPm6020030 for ; Mon, 21 Nov 2005 02:22:25 -0500 Received: from [127.0.0.1] (sig-9-48-115-216.mts.ibm.com [9.48.115.216]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAL7MN2Z019922; Mon, 21 Nov 2005 02:22:24 -0500 Message-ID: <438175AB.3010404@icu-project.org> Date: Sun, 20 Nov 2005 23:22:19 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Wildcards in filtering References: <437F9839.7010605@icu-project.org> <437FC108.1010500@icu-project.org> <6.0.0.20.2.20051120162120.01a101f0@localhost> In-Reply-To: <6.0.0.20.2.20051120162120.01a101f0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > At 09:19 05/11/20, Mark Davis wrote: > >I'm sorry, I really jumbled my message. What I meant was *lookup*; > replace the word "filter" by that (mutatis mutandis) and see if it > makes more sense. -- Mark > > I don't really see the point of throwing out two (or more) choices > and go for something that easily could be seen as matching less just > to avoid having to throw a dice. Or did I misunderstand something? > > > >Mark Davis wrote: > > > >> Here is the problem I have with the current formulation of "*" in > filtering. There is a conflict between the user expectations and the > need for a determinant answer. > >> > >> A. If a user has "sr-*-BA", and the actual content is one of: > >> > >> sr > >> sr-Cyrl > >> sr-Cyrl-BA > >> sr-Latn > >> > >> Then I believe the user's perfectly reasonable expectations would > be that "sr-Cyrl-BA" would match. That is an exact, single match > against the pattern. > > Yes, agreed. > > >> B. However, if the content is > >> > >> sr > >> sr-Cyrl > >> sr-Cyrl-BA > >> sr-Latn > >> sr-Latn-BA > >> > >> then we can't get a determinant answer from that pattern: both > sr-Cyrl-BA and sr-Latn-BA are perfectly reasonable matches. > > So can't we just choose one of them, at random? At random really won't do. If we want to do anything, we should have a determinant rule, such as "return the content for the language tag that is alphabetically less (case-insensitive)." It already has (in my formulation) an escape clause at the end, so someone can override this behavior. > > >> Your proposal has the advantage of getting a determinant answer, > but not matching the user expectations. You transform the sr-*-BA into > sr-BA, then do the lookup. In both cases A and B above, you'd return > "sr", which is not what the user would expect. > > I'm not sure that there would be that many variants, anyway. > If there is sr-Cyrl and sr-Latn, then sr is most probably just > a second mention of the content labeled by either sr-Cyrl or sr-Latn. > Of course, in the general case, that may be different. In the general case, especially with en-*, es-*, *-CA, etc, there will be many possible matches. > > >> My view is that there are two possible alternatives. > >> > >> ===== > >> > >> 1. Continue the fallback unless there is a *single* match, adding > text to the effect that: > >> > >> As usual, a wildcard matches against a subtag in that position. > When > >> filtering, however, the fallback process returns contents if and > >> only if there is exactly one match against the language priority > >> list. If there are two possible matches against the wildcard (or > >> zero) then the fallback continues. Thus suppose we are filtering > >> with the language priority list "sr-Cyrl-BA", and content for the > >> following tags: > >> > >> sr > >> sr-Cyrl > >> sr-Cyrl-BA > >> sr-Latn > >> > >> The result is the content for "sr-Cyrl-BA". When filtering with the > >> language priority list "sr-*", and the same possible content, the > >> result is the content for "sr". > > As I said above, I wouldn't think that makes sense. If there are two > matches that are 'better' than anything else, but can't be distinguished, > let's just return one of them at random or in an implementation dependent > fashion. as above. > > >> ===== > >> > >> 2. Leave out wildcards entirely, replacing the discussion of > wildcards (in two places) with text to the effect that: > >> > >> Wildcards are not permitted in filtered lookup, because they allow > >> for the possiblity of indeterminant answers. If, for example, the > >> language priority list is "sr-*" and the content is the following, > >> then the results would be indeterminant. > >> > >> sr > >> sr-Cyrl > >> sr-Cyrl-BA > >> sr-Latn > >> > >> > >> ==== > >> In both cases, add: > >> > >> However, a protocol MAY add additional specifications to filtered > >> lookup to provide for for resolution of cases where there are > >> multiple matches. > > detail: "for for" -> "for" > > Two concerns: 1) Adding wildcards back in will need a lot of careful work > which we shouldn't expect the users of our draft to need. Forbidding it > for cases that don't want them may be a lot easier for users, although > a bit more work for us. I'm not really adding the ability to have wildcards in lookup back in. On *input* the current draft handles them; it just handles them in a way that I don't think works (by removing then doing a lookup, and getting suboptimal results). > 2) It is easily possible that in a system (say database,...), there > are multiple variants of content that are tagged exactly the same. > So the whole effort of avoiding ties because of slightly differently > tagged content may be fruitless anyway. Remember, we are talking lookup, not filtering. In that case it is pointless to have two pieces of content (such as a ResourceBundle) with the same tag. You don't want the choice of return to be random! > > > Regards, Martin. > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 04:16:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7kq-0004TF-QL; Mon, 21 Nov 2005 04:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7ko-0004T3-R5 for ltru@megatron.ietf.org; Mon, 21 Nov 2005 04:14:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15220 for ; Mon, 21 Nov 2005 04:13:47 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee83B-0004R0-Se for ltru@ietf.org; Mon, 21 Nov 2005 04:33:27 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL9E5d24148; Mon, 21 Nov 2005 18:14:05 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7702_2a4093de_5a6f_11da_9287_00304811fd80; Mon, 21 Nov 2005 18:14:05 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL9D3l6022255; Mon, 21 Nov 2005 18:13:28 +0900 Message-Id: <6.0.0.20.2.20051121175656.01a1db20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 21 Nov 2005 18:04:48 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Suppressed and non-suppressed scripts (was: Re: [Ltru] Comments on draft-matching-07) In-Reply-To: <00e801c5ee4e$1193b600$050aa8c0@DGBP7M81> References: <00e801c5ee4e$1193b600$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 12:45 05/11/21, Doug Ewell wrote: >Here are my comments on draft-matching-07. Most of these are editorial. Thanks, great. I'm picking out one (maybe the only one, apart from the fact that in some places, you planned to look at the new version of the document anyway) issue that doesn't look editorial. >"en-Latn-US" 0 (all fields match) > >-> In reading this, it appears that "en-Brai-US" would also give a perfect 0 score, and for that matter so would "en-Egyp-US". Is that correct? We aren't looking at Suppress-Script here, so that doesn't factor into anything (unless we are one of the "implementations or protocols" that customize things). I got the same impression. It doesn't look like that would make sense. I was thinking that maybe how this should be handled is as follows: - In a range, a '*' in script position stays a '*'; an absent script field gets converted into the 'suppress-script' value for that lanugage if such a value is available. Otherwise, this expands into a '*'. - The corresponding content tags are also expanded by suppress-script information where available. - The matching is done on the resulting expanded tags, with a '*' matching anything. This would give the following: Range: en-US -> en-Latn-US Tag: en-Brai-US -> en-Brai-US -> match on language and region, but not on script Range: en-*-US -> en-*-US Tag: en-Brai-US -> en-Brai-US -> match on all fields Range: en-US -> en-Latn-US Tag: en-US -> en-Latn-US -> match on all fields I'm rather sure somebody will find a hair in this soup, if not some bigger obstacle, but at least for the cases above, it would work reasonably as expected. Regards, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 04:16:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7ku-0004Te-04; Mon, 21 Nov 2005 04:14:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7kr-0004TS-Nr for ltru@megatron.ietf.org; Mon, 21 Nov 2005 04:14:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15223 for ; Mon, 21 Nov 2005 04:13:52 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee83G-0004R3-Lu for ltru@ietf.org; Mon, 21 Nov 2005 04:33:32 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL9EHd24171; Mon, 21 Nov 2005 18:14:17 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7790_30f97a88_5a6f_11da_8c72_00304811fd80; Mon, 21 Nov 2005 18:14:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL9D3l8022255; Mon, 21 Nov 2005 18:13:50 +0900 Message-Id: <6.0.0.20.2.20051121180535.01a22a90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 21 Nov 2005 18:09:15 +0900 To: Mark Davis From: Martin Duerst Subject: Re: [Ltru] Wildcards in filtering In-Reply-To: <438175AB.3010404@icu-project.org> References: <437F9839.7010605@icu-project.org> <437FC108.1010500@icu-project.org> <6.0.0.20.2.20051120162120.01a101f0@localhost> <438175AB.3010404@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 16:22 05/11/21, Mark Davis wrote: [co-chair hat on] Mark, please try to cite a bit less. Thanks. [co-chair hat off] See below. >> 2) It is easily possible that in a system (say database,...), there >> are multiple variants of content that are tagged exactly the same. >> So the whole effort of avoiding ties because of slightly differently >> tagged content may be fruitless anyway. > >Remember, we are talking lookup, not filtering. In that case it is pointless to have two pieces of content (such as a ResourceBundle) with the same tag. You don't want the choice of return to be random! Ok, I see that true 'random' doesn't make sense in such a case. But we could easily say that the returned piece is 'implementation defined'. That would avoid us having to make an arbitrary choice (and getting into complaints like that we preferred English over French or Japanese because we proposed alphabetic order) while still allowing implementations to be predictive. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 04:16:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7lT-0004Ye-By; Mon, 21 Nov 2005 04:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7lR-0004YQ-Te for ltru@megatron.ietf.org; Mon, 21 Nov 2005 04:15:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15251 for ; Mon, 21 Nov 2005 04:14:28 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee83m-0004SH-EN for ltru@ietf.org; Mon, 21 Nov 2005 04:34:08 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAL9EUu06104; Mon, 21 Nov 2005 18:14:35 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7790_392776d8_5a6f_11da_8c72_00304811fd80; Mon, 21 Nov 2005 18:14:29 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAL9D3lA022255; Mon, 21 Nov 2005 18:14:08 +0900 Message-Id: <6.0.0.20.2.20051121181020.019221a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 21 Nov 2005 18:11:43 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: en-UM and the like In-Reply-To: <43805EB5.8D0@xyzzy.claranet.de> References: <002801c5ed86$28eae350$050aa8c0@DGBP7M81> <43805EB5.8D0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 20:32 05/11/20, Frank Ellermann wrote: >Doug Ewell wrote: >> It is absurd to talk about "language X as spoken in" an >> uninhabited region, and for regions populated by military >> or scientific personnel, the language variant(s) is/are >> completely determined by wherever the itinerant population >> comes from. > >Yes, and by absuing en-UM as example that point is obscured, My understanding was that in that specific instance, en-UM was taken as an example of a case where there wouldn't be any difference to en-US. For that, the example seemed to make sense. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 07:37:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAvc-0001kX-Mh; Mon, 21 Nov 2005 07:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAva-0001kS-Gb for ltru@megatron.ietf.org; Mon, 21 Nov 2005 07:37:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25893 for ; Mon, 21 Nov 2005 07:37:08 -0500 (EST) Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeBE1-00019r-Hw for ltru@ietf.org; Mon, 21 Nov 2005 07:56:50 -0500 Received: (qmail 37183 messnum 11070637 invoked from network[159.134.169.18/159-134-169-18.as1.prp.dublin.eircom.net]); 21 Nov 2005 12:37:17 -0000 Received: from 159-134-169-18.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.18) by mail11.svc.cra.dublin.eircom.net (qp 37183) with SMTP; 21 Nov 2005 12:37:17 -0000 Message-ID: <4381BF7E.FA97CD5A@egt.ie> Date: Mon, 21 Nov 2005 12:37:17 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Jukka K. Korpela" Subject: Re: [Ltru] draft-06: change the title? References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA25893 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org And "Matching [of] language tags" is also readily translatable (which the former is not).=20 Now, another question: do we follow ISO standard presentation of having only the first letter of title begin with a capital letter? mg Scr=EDobh "Jukka K. Korpela": > ... > Taken as such, it could be parsed as "(Matching Language) Tags" > or as "Matching (Language Tags)". Writing "Matching of Language Tags", > though perhaps not stylistically good English, would more easily > be understood the right way. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 07:52:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeB9R-000421-N7; Mon, 21 Nov 2005 07:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeB9Q-00041p-2z for ltru@megatron.ietf.org; Mon, 21 Nov 2005 07:52:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26794 for ; Mon, 21 Nov 2005 07:51:25 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeBRr-0001hp-GN for ltru@ietf.org; Mon, 21 Nov 2005 08:11:08 -0500 Received: from dul1shollenbl1 ([::ffff:68.100.55.187]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Mon, 21 Nov 2005 07:51:29 -0500 id 01588020.4381C2D1.000048C1 From: "Scott Hollenbeck" To: "'Marion Gunn'" Subject: RE: [Ltru] draft-06: change the title? Date: Mon, 21 Nov 2005 07:51:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcXumG4g99D7nInHQiKIE05dpLmC2QAAD4Lg In-Reply-To: <4381BF7E.FA97CD5A@egt.ie> Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie] > Sent: Monday, November 21, 2005 7:37 AM > To: Jukka K. Korpela > Cc: ltru@ietf.org > Subject: Re: [Ltru] draft-06: change the title? > > And "Matching [of] language tags" is also readily translatable (which > the former is not). > > Now, another question: do we follow ISO standard presentation > of having > only the first letter of title begin with a capital letter? IETF convention [1] would be more appropriate for an IETF document. -Scott- [1] The RFC Editor appears to prefer what is typically known as "title case". The first letters of "significant" words are upper-cased. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 08:05:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBMc-0006YT-EO; Mon, 21 Nov 2005 08:05:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBMb-0006Xs-EK for ltru@megatron.ietf.org; Mon, 21 Nov 2005 08:05:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28445 for ; Mon, 21 Nov 2005 08:05:02 -0500 (EST) Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeBf2-0002FQ-4t for ltru@ietf.org; Mon, 21 Nov 2005 08:24:45 -0500 Received: (qmail 35954 messnum 4217966 invoked from network[159.134.169.196/159-134-169-196.as1.prp.dublin.eircom.net]); 21 Nov 2005 13:05:28 -0000 Received: from 159-134-169-196.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.196) by mail13.svc.cra.dublin.eircom.net (qp 35954) with SMTP; 21 Nov 2005 13:05:28 -0000 Message-ID: <4381C619.63734DB3@egt.ie> Date: Mon, 21 Nov 2005 13:05:28 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: [Ltru] draft-06: change the title? References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA28445 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I accept that, but personally prefer the ISO convention. mg Scr=EDobh Scott Hollenbeck: >=20 > > -----Original Message----- > > From: Marion Gunn [mailto:mgunn@egt.ie] > > Sent: Monday, November 21, 2005 7:37 AM > > To: Jukka K. Korpela > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] draft-06: change the title? > > > > And "Matching [of] language tags" is also readily translatable (which > > the former is not). > > > > Now, another question: do we follow ISO standard presentation > > of having > > only the first letter of title begin with a capital letter? >=20 > IETF convention [1] would be more appropriate for an IETF document. >=20 > -Scott- >=20 > [1] > The RFC Editor appears to prefer what is typically known as "title case= ". > The first letters of "significant" words are upper-cased. --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 09:46:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCwX-0006xU-W5; Mon, 21 Nov 2005 09:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCwW-0006wn-6N for ltru@megatron.ietf.org; Mon, 21 Nov 2005 09:46:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05215 for ; Mon, 21 Nov 2005 09:46:14 -0500 (EST) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeDEy-00057y-2p for ltru@ietf.org; Mon, 21 Nov 2005 10:05:57 -0500 Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051121144634.VKCU10822.mta10.adelphia.net@DGBP7M81>; Mon, 21 Nov 2005 09:46:34 -0500 Message-ID: <013d01c5eeaa$a67602d0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00e801c5ee4e$1193b600$050aa8c0@DGBP7M81> <6.0.0.20.2.20051121175656.01a1db20@localhost> Subject: Re: Suppressed and non-suppressed scripts (was: Re: [Ltru] Comments on draft-matching-07) Date: Mon, 21 Nov 2005 06:48:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > - In a range, a '*' in script position stays a '*'; an absent > script field gets converted into the 'suppress-script' value > for that lanugage if such a value is available. Otherwise, this > expands into a '*'. > > - The corresponding content tags are also expanded by suppress-script > information where available. This would seem to work. Distance metric filtering (still referred to as "scored filtering" in Section 3.1) is already listed as the only type of filtering that requires access to the registry. As long as we have to go there to resolve grandfathered and obsolete (sub)tags, we may as well resolve Suppress-Script at the same time. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 11:54:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEvf-0001fa-0u; Mon, 21 Nov 2005 11:54:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEvd-0001ev-Uh for ltru@megatron.ietf.org; Mon, 21 Nov 2005 11:54:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14220 for ; Mon, 21 Nov 2005 11:53:28 -0500 (EST) Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFE7-0000ZY-8T for ltru@ietf.org; Mon, 21 Nov 2005 12:13:12 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jALGrqR2020640 for ; Mon, 21 Nov 2005 11:53:52 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jALGtDpC062066 for ; Mon, 21 Nov 2005 09:55:13 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jALGrqsH003452 for ; Mon, 21 Nov 2005 09:53:52 -0700 Received: from [127.0.0.1] (sig-9-48-113-0.mts.ibm.com [9.48.113.0] (may be forged)) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jALGrouF003311; Mon, 21 Nov 2005 09:53:52 -0700 Message-ID: <4381FB9D.8030106@icu-project.org> Date: Mon, 21 Nov 2005 08:53:49 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Wildcards in filtering References: <437F9839.7010605@icu-project.org> <437FC108.1010500@icu-project.org> <6.0.0.20.2.20051120162120.01a101f0@localhost> <438175AB.3010404@icu-project.org> <6.0.0.20.2.20051121180535.01a22a90@localhost> In-Reply-To: <6.0.0.20.2.20051121180535.01a22a90@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org When something has that big a hole in it, then we are then probably best off saying that *anything* with wildcards in lookup is implementation-defined, and not trying to specify it any further than that. (That has no impact on the use of wildcards in filtering, of course.) Mark Martin Duerst wrote: > At 16:22 05/11/21, Mark Davis wrote: > > [co-chair hat on] Mark, please try to cite a bit less. Thanks. > > [co-chair hat off] See below. > > >> 2) It is easily possible that in a system (say database,...), there > >> are multiple variants of content that are tagged exactly the same. > >> So the whole effort of avoiding ties because of slightly differently > >> tagged content may be fruitless anyway. > > > >Remember, we are talking lookup, not filtering. In that case it is > pointless to have two pieces of content (such as a ResourceBundle) > with the same tag. You don't want the choice of return to be random! > > Ok, I see that true 'random' doesn't make sense in such a case. > But we could easily say that the returned piece is > 'implementation defined'. That would avoid us having to make > an arbitrary choice (and getting into complaints like that we > preferred English over French or Japanese because we proposed > alphabetic order) while still allowing implementations to be > predictive. > > Regards, Martin. > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 12:04:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeF61-0003fV-TK; Mon, 21 Nov 2005 12:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeF60-0003fN-4H for ltru@megatron.ietf.org; Mon, 21 Nov 2005 12:04:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14923 for ; Mon, 21 Nov 2005 12:04:08 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFOP-0000qj-EJ for ltru@ietf.org; Mon, 21 Nov 2005 12:23:52 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:04:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Wildcards in filtering Date: Mon, 21 Nov 2005 09:04:26 -0800 Message-ID: Thread-Topic: [Ltru] Wildcards in filtering Thread-Index: AcXuvFH30A2/35PaSqexHx/T67ZB1AAAByQg From: "Addison Phillips" To: "Mark Davis" , "Martin Duerst" X-OriginalArrivalTime: 21 Nov 2005 17:04:27.0327 (UTC) FILETIME=[A15B44F0:01C5EEBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551007169==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0551007169== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBXaGVuIHNvbWV0aGluZyBoYXMgdGhhdCBiaWcgYSBob2xlIGluIGl0LCB0aGVuIHdlIGFyZSB0 aGVuIHByb2JhYmx5IGJlc3QNCj4gb2ZmIHNheWluZyB0aGF0ICphbnl0aGluZyogd2l0aCB3aWxk Y2FyZHMgaW4gbG9va3VwIGlzDQo+IGltcGxlbWVudGF0aW9uLWRlZmluZWQsIGFuZCBub3QgdHJ5 aW5nIHRvIHNwZWNpZnkgaXQgYW55IGZ1cnRoZXIgdGhhbg0KPiB0aGF0LiAoVGhhdCBoYXMgbm8g aW1wYWN0IG9uIHRoZSB1c2Ugb2Ygd2lsZGNhcmRzIGluIGZpbHRlcmluZywgb2YgY291cnNlLikN Cg0KV2h5IG5vdCBnbyB3aXRoIHdoYXQgd2UgaGF2ZSBhbmQgcHJvdmlkZSBhIE1BWSBlc2NhcGUg Y2xhdXNlIGF0IHRoZSBlbmQ/IFRoZSBjdXJyZW50IHZlcnNpb24gb2YgbG9va3VwIGlzIGRldGVy bWluYXRlIGFuZCBzaW1wbGUuIFRoZW4sIGF0IHRoZSBlbmQgb2YgU2VjdGlvbiAzLjMgd2UgY291 bGQgYWRkIHRoaXMgdGV4dDoNCg0KLS0NCkFwcGxpY2F0aW9ucyBvciBwcm90b2NvbHMgTUFZIHBy b3ZpZGUgZm9yIGV4cGFuc2lvbiBhbmQgbWF0Y2hpbmcgb2Ygd2lsZGNhcmRzIGR1cmluZyBsb29r dXAuIEV4cGFuZGluZyB3aWxkY2FyZHMgaW4gdGhlIGxvb2t1cCBwcm9jZXNzIGNhbiByZXN1bHQg aW4gbXVsdGlwbGUgcGllY2VzIG9mIGNvbnRlbnQgYmVpbmcgYW4gZXF1YWxseSBnb29kIG1hdGNo IG9uIGFueSBwYXJ0aWN1bGFyICJsZXZlbCIgb2YgdGhlIGZhbGxiYWNrIHByb2Nlc3MuIEFuIGlt cGxlbWVudGF0aW9uIFNIT1VMRCBzcGVjaWZ5IGhvdyB0aGUgY29udGVudCBpcyBjaG9zZW4gKGV2 ZW4gaWYgaXQgaXMgcmFuZG9tLCBmaXJzdCBjb250ZW50IGZvdW5kLCBvciBzb21lIG90aGVyIG5v bi1kZXRlcm1pbmFudCBtZWNoYW5pc20pLg0KLS0NCg0KV2UgZG9uJ3QgaGF2ZSB0byBzcGVjaWZ5 IGV2ZXJ5dGhpbmcgaW4gaGVyZS4gSSdkIGdvIGZ1cnRoZXIgYW5kIHNheSB3ZSBuZWVkIHNvbWUg cnVubmluZyBjb2RlIHRvIGV2YWx1YXRlIHRoZSByZXN1bHRzIGJlZm9yZSB3ZSBkYWJibGUgaW4g ImV4dGVuZGVkIHJhbmdlIGxvb2t1cCIgdG9vIGZhci4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCg== --===============0551007169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0551007169==-- From ltru-bounces@ietf.org Mon Nov 21 12:20:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFL8-0000eZ-BM; Mon, 21 Nov 2005 12:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFL7-0000d4-2t for ltru@megatron.ietf.org; Mon, 21 Nov 2005 12:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16442 for ; Mon, 21 Nov 2005 12:19:47 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFdb-0001Sv-PM for ltru@ietf.org; Mon, 21 Nov 2005 12:39:32 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:20:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: wildcards in extended ranges (was RE: [Ltru] draft-06 comments:choice of range) Date: Mon, 21 Nov 2005 09:20:12 -0800 Message-ID: Thread-Topic: wildcards in extended ranges (was RE: [Ltru] draft-06 comments:choice of range) Thread-Index: AcXuNrf7bz/fzFfCTjGT6v8TeBICIgAiH0oA From: "Addison Phillips" To: "Martin Duerst" , "Mark Davis" X-OriginalArrivalTime: 21 Nov 2005 17:20:13.0639 (UTC) FILETIME=[D5670570:01C5EEBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641771153==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1641771153== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBOb3Qgb25seSBpbiB0aGlzIHNwZWNpZmljIGNvbnRleHQsIGJ1dCBpbiBnZW5lcmFsLCBJIHZl cnkgbXVjaCBhZ3JlZS4NCj4gRWFybGllciB2ZXJzaW9ucyBvZiBvdXIgZHJhZnQganVzdCBsZWZ0 IHRvbyBtYW55IE1BWXMgYW5kIFNIT1VMRHMNCj4gdGhhdCBjb25mdXNlZCBwcm90b2NvbCBkZXNp Z25lcnMgYW5kIGltcGxlbWVudGVycyAod2hvIGRvbid0IG5lY2Vzc2FyaWx5DQo+IHVuZGVyc3Rh bmQgYWxsIHRoZSBkZXRhaWxzKS4NCg0KQmUgc3BlY2lmaWMuIEkgd29uJ3QgY2hhbmdlIGFueXRo aW5nIGluIHRoZSBkcmFmdCB0aGF0IGlzbid0IHNwZWNpZmljLg0KDQpUaGlzIGxhdGVzdCBzZXQg b2YgdGhyZWFkcyBoYXMgbWUgc2l0dGluZyBvbiBteSBoYW5kcy4gSSBjYW4ndCBmaWd1cmUgb3V0 IHdoYXQgdG8gcHV0IGluIG9yIHRha2Ugb3V0IGFuZCBpdCBpc24ndCBqdXN0IHRoZSBxdW90aW5n IG9mIHByZXZpb3VzIHBvc3RzLiBJdCdzIHRoZSByZWxhdGl2ZSBsYWNrIG9mIHNwZWNpZmljaXR5 IGFib3V0IHRoZSB0ZXh0LiAoSXQgaXMgYWxzbyB0aGUgZmFjdCB0aGF0IG9ubHkgdHdvIG9yIHRo cmVlIHBvc3RlcnMgYXBwZWFyIHRvIGJlIHBhcnRpY2lwYXRpbmcsIHRodXMgbWFraW5nIG1lIGZl ZWwgd2UgZG9u4oCZdCBoYXZlIGEgY29uc2Vuc3VzIHlldC4uLikNCg0KSWYgeW91IHRoaW5rIGEg Ik1BWSIgb3IgIlNIT1VMRCIgb3VnaHQgdG8gYmUgYSBNVVNUIChvciByZW1vdmVkKSwgeW91IG5l ZWQgdG8gc2F5IHdoaWNoIG9uZSBhbmQgaG93IHlvdSB3b3VsZCBjaGFuZ2UgaXQuDQoNCkluZGl2 aWR1YWwgcG9zdHMgcGVyIGl0ZW0gKG9yIGF0IGxlYXN0IHNlY3Rpb24pIGFyZSBwcmVmZXJyZWQg YnkgdGhlIGVkaXRvcnMuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFs aXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0aW9uYWxpemF0aW9u IGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============1641771153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1641771153==-- From ltru-bounces@ietf.org Mon Nov 21 12:27:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFSF-0002Nd-2O; Mon, 21 Nov 2005 12:27:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFSD-0002NS-IA for ltru@megatron.ietf.org; Mon, 21 Nov 2005 12:27:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16969 for ; Mon, 21 Nov 2005 12:27:07 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFkh-0001gA-Uv for ltru@ietf.org; Mon, 21 Nov 2005 12:46:52 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:27:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Wildcards in filtering Date: Mon, 21 Nov 2005 09:27:33 -0800 Message-ID: Thread-Topic: [Ltru] Wildcards in filtering Thread-Index: AcXuNvF8VrhIw8gsT1O5dMLoVJ4qkwAiPQpw From: "Addison Phillips" To: "Martin Duerst" , "Mark Davis" X-OriginalArrivalTime: 21 Nov 2005 17:27:36.0171 (UTC) FILETIME=[DD2C0BB0:01C5EEC0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008904140==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2008904140== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlIElFVEYgbWFudHJhIGlzICJyb3VnaCBjb25zZW5zdXMgYW5kIHJ1bm5pbmcgY29kZSIuIEkg ZG9uJ3Qgc2Vuc2UgdGhhdCB3ZSBoYXZlIGVpdGhlciBoZXJlLg0KDQpJIHRoaW5rIHRoYXQsIGlm IHdlIGFyZSB0byBoYXZlIHJvdWdoIGNvbnNlbnN1cyBvbiBhbGxvd2luZyB3aWxkY2FyZHMgaW50 byBsb29rdXAsIHRoZW4gd2UgbmVlZCB0byBoYXZlIHNvbWUgcnVubmluZyBjb2RlIHRvIGV2YWx1 YXRlLCBldmVuIGlmIGl0IGlzIGp1c3QgYSBzaW11bGF0aW9uLg0KDQpJIHdvdWxkIHdyaXRlIG9u ZSAoSSBoYXZlIGEgYmFzaWMgbG9va3VwIGltcGxlbWVudGF0aW9uIGFuZCBhbSB3b3JraW5nIG9u IGEgcGFpciBmb3IgZmlsdGVyaW5nKSwgYnV0IHRoaXMgaXMgbXkgbGFzdCBkYXkgaW4gdGhlIG9m ZmljZSBmb3IgdGhpcyB3ZWVrIChmYW1pbHkgdmFjYXRpb24pLiBXaGVuIEknbSBiYWNrIG5leHQg d2VlayBJIG1heSBnZXQgYXJvdW5kIHRvIGl0LiBTdGlsbC4uLiBNYXJrLCB5b3UgbWF5IGhhdmUg c29tZSBhZGFwdGFibGUgY29kZSBseWluZyBhcm91bmQgaW4gSUNVLiBJJ2xsIGhhcHBpbHkgaG9z dCBhIEpTUCBwYWdlIG9yIHNpbWlsYXIgb24gbXkgd2ViIHNlcnZlciBhcyBhIGRlbW8gd2UgY2Fu IGFsbCBsb29rIGF0Lg0KDQpKdXN0IGEgdGhvdWdodC4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+IEF0IDA5OjE5IDA1LzEx LzIwLCBNYXJrIERhdmlzIHdyb3RlOg0KPiAgPkknbSBzb3JyeSwgIEkgcmVhbGx5IGp1bWJsZWQg bXkgbWVzc2FnZS4gV2hhdCBJIG1lYW50IHdhcyAqbG9va3VwKjsNCj4gcmVwbGFjZSB0aGUgd29y ZCAiZmlsdGVyIiBieSB0aGF0IChtdXRhdGlzIG11dGFuZGlzKSBhbmQgc2VlIGlmIGl0IG1ha2Vz DQo+IG1vcmUgc2Vuc2UuIC0tIE1hcmsNCj4gDQo+IEkgZG9uJ3QgcmVhbGx5IHNlZSB0aGUgcG9p bnQgb2YgdGhyb3dpbmcgb3V0IHR3byAob3IgbW9yZSkgY2hvaWNlcw0KPiBhbmQgZ28gZm9yIHNv bWV0aGluZyB0aGF0IGVhc2lseSBjb3VsZCBiZSBzZWVuIGFzIG1hdGNoaW5nIGxlc3MganVzdA0K PiB0byBhdm9pZCBoYXZpbmcgdG8gdGhyb3cgYSBkaWNlLiBPciBkaWQgSSBtaXN1bmRlcnN0YW5k IHNvbWV0aGluZz8NCj4gDQo= --===============2008904140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2008904140==-- From ltru-bounces@ietf.org Mon Nov 21 12:40:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFeF-0004hb-8w; Mon, 21 Nov 2005 12:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFe7-0004gk-RM for ltru@megatron.ietf.org; Mon, 21 Nov 2005 12:40:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804 for ; Mon, 21 Nov 2005 12:39:25 -0500 (EST) Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFwc-0001yp-BA for ltru@ietf.org; Mon, 21 Nov 2005 12:59:10 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jALHdoc1028972 for ; Mon, 21 Nov 2005 12:39:50 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jALHdU8C046306 for ; Mon, 21 Nov 2005 10:39:30 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jALHdnIf030121 for ; Mon, 21 Nov 2005 10:39:49 -0700 Received: from [127.0.0.1] (sig-9-48-113-0.mts.ibm.com [9.48.113.0] (may be forged)) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jALHdmdf030011; Mon, 21 Nov 2005 10:39:49 -0700 Message-ID: <43820664.1010008@icu-project.org> Date: Mon, 21 Nov 2005 09:39:48 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Wildcards in filtering References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'm ok with that IF we take out the mechanisms for resolving wildcards in lookup. That is because of the problem with the current formulation that I pointed out. The problematic language is the following, and needs to be replaced, one way or another: > > The language range "*" matches any language tag. In the lookup scheme, > this language range does not convey enough information to determine > which content is most appropriate. If this language range is the only > one in the language priority list, it matches the default content. If > this language range is followed by other language ranges, it should be > skipped. and > In some cases, the language priority list might contain one or more > extended language ranges (as, for example, when the same language > priority list is used as input for both lookup and filtering > operations). Wildcard values in an extended language range are > supposed to match any value that occurs in that position in a language > tag. Since only one item can be returned for any given lookup request, > the wildcards must be processed in a predictable manner (or the same > request might produce widely varying results). Thus, for each range in > the language priority list, the following rules must be applied to > produce a basic language range for use in the fallback mechanism: > > 1. If the first subtag in the extended language range is a "*" then > entire range is converted to "*". > 2. For each subsequent subtag, if the value is a "*" then that > subtag and its preceeding hyphen are removed. > > For example: > > *-US becomes * > en-*-US becomes en-US > en-Latn-* becomes en-Latn > > Figure 8: Transformation of Extended Language Ranges > > For the language priority list "*-US; fr-*-FR; zh-Hant", the fallback > pattern would be: > > 1. * (skipped) > 2. fr-FR > 3. fr > 4. zh-Hant > 5. zh > 6. (default content) > > Figure 9: Extended Language Range Fallback Example =========================== Repeating my previous message, but with the language cleaned up: Here is the problem I have with the current formulation of "*" in lookup. There is a conflict between the user expectations and the need for a determinant answer. A. If a user has "sr-*-BA", and the actual content is one of: sr sr-Cyrl sr-Cyrl-BA sr-Latn Then I believe the user's perfectly reasonable expectations would be that "sr-Cyrl-BA" would match. That is an exact, single match against the pattern. B. However, if the content is sr sr-Cyrl sr-Cyrl-BA sr-Latn sr-Latn-BA then we can't get a determinant answer from that pattern: both sr-Cyrl-BA and sr-Latn-BA are perfectly reasonable matches. The current draft has the advantage of getting a determinant answer, but *not* matching the user expectations. It transforms the sr-*-BA into sr-BA, then does the lookup. In both cases A and B above, it'd return "sr", which is *not* what the user would expect. My view is that there are two possible alternatives. ===== 1. Continue the fallback unless there is a *single* match, replacing the problematic text with text to the effect that that: As usual, a wildcard matches against a subtag in that position. When filtering, however, the fallback process returns contents if and only if there is exactly one match against the language priority list. If there are two possible matches against the wildcard (or zero) then the fallback continues. Thus suppose we are filtering with the language priority list "sr-Cyrl-BA", and content for the following tags: sr sr-Cyrl sr-Cyrl-BA sr-Latn The result is the content for "sr-Cyrl-BA". When filtering with the language priority list "sr-*", and the same possible content, the result is the content for "sr". ===== 2. Leave out wildcards entirely, replacing the replacing the problematic text with text to the effect that: The use of wildcards are not defined in filtered lookup, because they allow for the possiblity of indeterminant answers. If, for example, the language priority list is "sr-*" and the content is the following, then the results would be indeterminant. sr sr-Cyrl sr-Cyrl-BA sr-Latn 3. Resolve the indeterminancy somewhat arbitrarily (but *not* randomly): As usual, a wildcard matches against a subtag in that position. If there are two possible matches against the wildcard (or zero) then contents for the language tag that is alphabetically first (with a caseless compare) is returned. Thus suppose we are filtering with the language priority list "sr-Cyrl-BA", and content for the following tags: sr sr-Cyrl sr-Cyrl-BA sr-Latn The result is the content for "sr-Cyrl-BA". When filtering with the language priority list "sr-*", and the same possible content, the result is the content for "sr-Cyrl", because that is alphabetically before the other possibility: "sr-Latn". ==== In *both* cases, add: However, a protocol MAY add additional specifications to filtered lookup to provide for wildcard matching, or for alternative choices. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru Addison Phillips wrote: >>When something has that big a hole in it, then we are then probably best >>off saying that *anything* with wildcards in lookup is >>implementation-defined, and not trying to specify it any further than >>that. (That has no impact on the use of wildcards in filtering, of course.) >> >> > >Why not go with what we have and provide a MAY escape clause at the end? The current version of lookup is determinate and simple. Then, at the end of Section 3.3 we could add this text: > >-- >Applications or protocols MAY provide for expansion and matching of wildcards during lookup. Expanding wildcards in the lookup process can result in multiple pieces of content being an equally good match on any particular "level" of the fallback process. An implementation SHOULD specify how the content is chosen (even if it is random, first content found, or some other non-determinant mechanism). >-- > >We don't have to specify everything in here. I'd go further and say we need some running code to evaluate the results before we dabble in "extended range lookup" too far. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software > >Internationalization is not a feature. >It is an architecture. > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 12:43:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFhF-0004zg-FP; Mon, 21 Nov 2005 12:43:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFhD-0004y4-HW for ltru@megatron.ietf.org; Mon, 21 Nov 2005 12:43:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18112 for ; Mon, 21 Nov 2005 12:42:37 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFzh-00024B-7T for ltru@ietf.org; Mon, 21 Nov 2005 13:02:22 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:42:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Comments on draft-matching-07 Date: Mon, 21 Nov 2005 09:42:57 -0800 Message-ID: Thread-Topic: [Ltru] Comments on draft-matching-07 Thread-Index: AcXuTgOKjUTThzFuQ5alQg1e/+tniAAcuEQw From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 21 Nov 2005 17:42:59.0063 (UTC) FILETIME=[03423070:01C5EEC3] X-Spam-Score: 0.0 (/) 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: , Content-Type: multipart/mixed; boundary="===============1070226048==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1070226048== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SW50ZXJsaW5lYXIgY29tbWVudHMgYmVsb3cuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IERvdWcg RXdlbGwNCj4gU2VudDogMjAwNeW5tDEx5pyIMjDml6UgMTk6NDYNCj4gVG86IExUUlUgV29ya2lu ZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gQ29tbWVudHMgb24gZHJhZnQtbWF0Y2hpbmctMDcN Cj4gDQo+IEhlcmUgYXJlIG15IGNvbW1lbnRzIG9uIGRyYWZ0LW1hdGNoaW5nLTA3LiAgTW9zdCBv ZiB0aGVzZSBhcmUgZWRpdG9yaWFsLg0KPiANCj4gU2VjdGlvbiAyLjE6ICJJdCBjYW4gZ2V0IG1v cmUgY29tcGxleDogYSBzcGVha2VyIG1heSB3aXNoIHRvIGZhbGxiYWNrDQo+IGZyb20gU2tvbHQg U2FtaSB0byBOb3J0aGVybiBTYW1pIHRvIEZpbm5pc2guIg0KPiANCj4gLT4gVGhpcyBzaG91bGQg YmUgImZhbGwgYmFjaywiIHR3byB3b3JkcyB3aGVuIHVzZWQgYXMgYSB2ZXJiIGxpa2UgdGhpcywN Cj4gYnV0IG9uZSB3b3JkIGFzIGEgbm91biAoImEgZmFsbGJhY2sgbWVjaGFuaXNtIikuICBQbGVh c2UgdXNlDQo+IHNlYXJjaC1hbmQtcmVwbGFjZSBmb3IgdGhpcy4NCltBZGRpc29uIFBoaWxsaXBz XSANCg0KQWdyZWVkLiBUaGVyZSB3YXMgb25lIGluc3RhbmNlIGluIGRyYWZ0LTA3ICh0aGUgcmVt YWluZGVyIHdlcmUgbm91biBmb3JtcykuDQo+IA0KPiBTZWN0aW9uIDIuMjogICJieSBhZGFwdGlu ZyB0aGUgQUJORltSRkM0MjM0XSBmcm9tIEhUVFAvMS4xIFtSRkMyNjE2XSA6Ig0KPiBhbmQgbGF0 ZXIgIkJhc2ljIGxhbmd1YWdlIHJhbmdlcyB3ZXJlIG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFtS RkMzMDY2XQ0KPiBhbmQgSFRUUCAxLjEgW1JGQzI2MTZdIg0KPiANCj4gLT4gUGxlYXNlIGNhbGwg aXQgZWl0aGVyICJIVFRQIDEuMSIgd2l0aG91dCB0aGUgc2xhc2ggb3IgIkhUVFAvMS4xIiB3aXRo DQo+IHRoZSBzbGFzaCwgY29uc2lzdGVudGx5Lg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpEb25l ICh1c2VkIEhUVFAvMS4xKS4gMiBpbnN0YW5jZXMuDQo+IA0KPiBTZWN0aW9uIDIuNDogICJiZWNh dXNlIHRoZSB2YXN0IG1ham9yaXR5IEVuZ2xpc2ggZG9jdW1lbnRzIGFyZSB3cml0dGVuDQo+IGlu IHRoZSBMYXRpbiBzY3JpcHQiDQo+IA0KPiAtPiBBZGQgIm9mICJhZnRlciAibWFqb3JpdHkuIg0K W0FkZGlzb24gUGhpbGxpcHNdIA0KDQpEb25lLg0KPiANCj4gU2VjdGlvbiAyLjQ6ICAibm90ZSB0 aGF0IGV4dGVuc2lvbnMgYW5kIG1vc3QgcHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUNCj4gb3J0aG9n b25hbCINCj4gDQo+IC0+ICJQcml2YXRlLXVzZSIgc2hvdWxkIGJlIGh5cGhlbmF0ZWQgd2hlbiB1 c2VkIGJlZm9yZSB0aGUgbm91biBpdA0KPiBtb2RpZmllcywgbGlrZSB0aGlzLiAgSXQgd291bGQg bm90IGJlIGh5cGhlbmF0ZWQgYXMgcGFydCBvZiBhIHBocmFzZSwNCj4gbGlrZSAidGhlc2Ugc3Vi dGFncyBhcmUgZm9yIHByaXZhdGUgdXNlLiIgIFRoaXMgb2NjdXJzIGluIHZhcmlvdXMNCj4gcGxh Y2VzLCBzbyBwbGVhc2UgdXNlIHNlYXJjaC1hbmQtcmVwbGFjZSBoZXJlIHRvby4NCltBZGRpc29u IFBoaWxsaXBzXSANCg0KRG9uZS4NCj4gDQo+IFNlY3Rpb24gMy4xOiAgImNvbnRlbnQgbGFiZWxl ZCAiemgtQ04iIGlzIG1vcmVseSBsaWtlbHkgdG8gbWF0Y2giDQo+IA0KPiAtPiAibW9yZSIgbGlr ZWx5DQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkFscmVhZHkgY2F1Z2h0IGFuZCBmaXhlZCBpdCBp biBteSBjb3B5Lg0KPiANCj4gU2VjdGlvbiAzLjI6ICAiRmlsdGVyaW5nIGNhbiBwcm9kdWNlIGVp dGhlciBvcmRlcmVkIG9yIHVub3JkZXJlZCBzZXQgb2YNCj4gcmVzdWx0cy4iDQo+IA0KPiAtPiBB ZGQgImFuIiBiZWZvcmUgIm9yZGVyZWQsIiBhbmQgb3B0aW9uYWxseSBhZnRlciAidW5vcmRlcmVk IiBhcyB3ZWxsLg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpEb25lLg0KPiANCj4gU2VjdGlvbiAz LjI6ICAibWVhc3VybWVudCINCj4gDQo+IC0+IFNwZWxsaW5nIGVycm9yICh0eXBvKSBzdGlsbCBu b3QgY29ycmVjdGVkLg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpObywgaXQncyBjb3JyZWN0ZWQs IGJ1dCBpdCBzdGlsbCBpc24ndCBwb3N0ZWQuDQo+IA0KPiBTZWN0aW9uIDMuMi4yOiAgInpoLUxh dG4tQ04tYm9vbnQiDQo+IA0KPiAtPiAiYm9vbnQiIGlzIG5vdCBhIHZhcmlhbnQgc3VidGFnLiAg SSB3b3VsZCBtdWNoIHByZWZlciBub3QgdG8gdXNlIGl0DQo+IGluIGFuIGV4YW1wbGUuICBUcnkg YSByZWFsIHZhcmlhbnQgbGlrZSAiMTkwMSIgb3IgIm5lZGlzLiINCltBZGRpc29uIFBoaWxsaXBz XSANCg0KSSB0cmllZCB0byBmaW5kIGEgcmFuZ2UgdGhhdCB3b3VsZCBnaXZlIG1lIHRoZSB3aWRl c3QgdmFyaWV0eSBvZiB0YWdzIHRoYXQgd291bGQgd29yayBhcyBtYXRjaGVzIGFuZCBiZSByZWFs aXN0aWMgdGFncy4gVGh1cyBJIGNoYW5nZWQgdGhlIGV4YW1wbGUgdG8gdXNlIHRoZSByYW5nZSAi ZGUtKi1ERSIgYW5kIHRoaXMgc2V0IG9mIHJlc3VsdHM6DQoNCjx0PmRlLURFPC90Pg0KPHQ+ZGUt TGF0bi1ERTwvdD4NCjx0PmRlLUxhdGYtREU8L3Q+DQo8dD5kZS1ERS14LWdvZXRoZTwvdD4NCjx0 PmRlLUxhdG4tREUtMTk5NjwvdD4NCg0KDQo+IA0KPiBTZWN0aW9uIDMuMi4zOiAgIk1pc3Npbmcg ZW5kIHN1YnRhZ3MgYXJlIGV4cGFuZGVkIGFzIHRoZSBlbXB0eQ0KPiBzdHJpbmcuLi4iDQo+IA0K PiAtPiBPcmlnaW5hbGx5IChiYXNlZCBvbiBkcmFmdC1tYXRjaGluZy0wNikgSSB3YXMgZ29pbmcg dG8gY29tcGxhaW4gdGhhdA0KPiB0aGlzIHNlY3Rpb24gY29udHJhZGljdGVkIGl0c2VsZi4gIElu IHNvbWUgcGxhY2VzIGl0IGFwcGVhcmVkIHRvIHNheQ0KPiB0aGF0IGFsbCAibWlzc2luZyIgc3Vi dGFncyB3ZXJlIGV4cGFuZGVkIGFzIGFzdGVyaXNrLiAgQWRkaXNvbiBoYXMNCj4gcmV3cml0dGVu IHRoaXMgcGFzc2FnZSB0byBjbGFyaWZ5IHRoZSBkaWZmZXJlbnQgdHJlYXRtZW50IG9mIHRhZ3Mg YW5kDQo+IHJhbmdlcywgYW5kIEknbGwgaGF2ZSB0byByZWFkIHRoZSBuZXcgdGV4dCBjYXJlZnVs bHkgdG8gc2VlIHdoZXRoZXIgaXQNCj4gZGUtY29uZnVzZWQgbWUuDQpbQWRkaXNvbiBQaGlsbGlw c10gDQoNCk9rYXkuIFBsZWFzZSBkby4gSSB0aGluaywgYmFzZWQgb24gbXkgZXhwZXJpZW5jZSB3 aXRoIG15IGxpdHRsZSBpbXBsZW1lbnRhdGlvbiwgdGhhdCB3ZSBvdWdodCB0byBjaGFuZ2UgdGhl IGV4cGFuc2lvbiBydWxlcyAoSSBhY3R1YWxseSBmYXZvciByZW1vdmluZyB0aGVtIGFsdG9nZXRo ZXIgaW4gc2NvcmVkIGZpbHRlcmluZywgc2luY2UgdGhhdCBhcHBlYXJzIHRvIGdpdmUgdGhlIGJl c3QgZGlzdGFuY2UgbWV0cmljKS4NCj4gDQo+IFNlY3Rpb24gMy4yLjM6ICAiRXhhbXBsZXMgb2Yg dmFyaW91cyB0YWcncyBkaXN0YW5jZXMgZnJvbSB0aGUgcmFuZ2UNCj4gImVuLVVTIjouLi4gImZy LUZSIiAgICAgICAgICAzODQgKGxhbmd1YWdlICYgcmVnaW9uIG1pc21hdGNoKSINCj4gDQo+IC0+ IElmIGxhbmd1YWdlIGNvdW50cyBhcyAyNTYgYW5kIHJlZ2lvbiBhcyAzMiwgdGhlbiB0aGlzIHNj b3JlIHNob3VsZCBiZQ0KPiAyNTYgKyAzMiA9IDI4OCwgbm90IDM4NC4gIEFnYWluIEkgbmVlZCB0 byByZWFkIHRoZSByZXZpc2VkIHRleHQgdG8gc2VlDQo+IGlmIHRoZSBleGFtcGxlcyBtYWtlIG1v cmUgc2Vuc2Ugbm93Lg0KPiANCj4gImVuLUxhdG4tVVMiICAgICAgIDAgKGFsbCBmaWVsZHMgbWF0 Y2gpDQo+IA0KPiAtPiBJbiByZWFkaW5nIHRoaXMsIGl0IGFwcGVhcnMgdGhhdCAiZW4tQnJhaS1V UyIgd291bGQgYWxzbyBnaXZlIGENCj4gcGVyZmVjdCAwIHNjb3JlLCBhbmQgZm9yIHRoYXQgbWF0 dGVyIHNvIHdvdWxkICJlbi1FZ3lwLVVTIi4gIElzIHRoYXQNCj4gY29ycmVjdD8gIFdlIGFyZW4n dCBsb29raW5nIGF0IFN1cHByZXNzLVNjcmlwdCBoZXJlLCBzbyB0aGF0IGRvZXNuJ3QNCj4gZmFj dG9yIGludG8gYW55dGhpbmcgKHVubGVzcyB3ZSBhcmUgb25lIG9mIHRoZSAiaW1wbGVtZW50YXRp b25zIG9yDQo+IHByb3RvY29scyIgdGhhdCBjdXN0b21pemUgdGhpbmdzKQ0KW0FkZGlzb24gUGhp bGxpcHNdIA0KDQpZZXMuIFRoYXQncyB3aGF0IHdpbGRjYXJkIG1hdGNoaW5nIG1lYW5zLiBBZ2Fp biwgc2VlIG15IHJlY29tbWVuZGF0aW9uIGFib3ZlOiByZW1vdmluZyB3aWxkY2FyZCBleHBhbnNp b24gbWFrZXMgYmV0dGVyIG1ldHJpY3MuDQouDQo+IA0KPiBTZWN0aW9uIDc6ICAibWlnaHQgYmUg dXNlZCB0byB0cmFjayBzcGVjaWZpYyBpbmRpdmlkdWFsJ3MgYWN0aXZpdGllcy4iDQo+IA0KPiAt PiBUaGlzIGlzIG5vdCBncmFtbWF0aWNhbC4gIEl0IHNob3VsZCBiZSAidHJhY2sgYSBzcGVjaWZp YyBpbmRpdmlkdWFsJ3MNCj4gYWN0aXZpdGllcyIgaWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQgb25l IGluZGl2aWR1YWwsIG9yICJ0cmFjayBzcGVjaWZpYw0KPiBpbmRpdmlkdWFscycgYWN0aXZpdGll cyIgKG5vdGljZSB0aGUgYXBvc3Ryb3BoZSkgaWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQNCj4gbXVs dGlwbGUgaW5kaXZpZHVhbHMuDQo+IA0KSXQgc2hvdWxkIGJlICJhIHNwZWNpZmljIi4gSXQgaXMg Yml6YXJyZSB0byBzYXkgInNwZWNpZmljIiBhbmQgdGhlbiB1c2UgcGx1cmFsICJpbmRpdmlkdWFs cyIuDQo= --===============1070226048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1070226048==-- From ltru-bounces@ietf.org Mon Nov 21 13:05:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeG2g-0001Q8-Jt; Mon, 21 Nov 2005 13:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeG2c-0001Pu-Vf for ltru@megatron.ietf.org; Mon, 21 Nov 2005 13:05:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19367 for ; Mon, 21 Nov 2005 13:04:44 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeGL5-0002fN-JO for ltru@ietf.org; Mon, 21 Nov 2005 13:24:30 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 10:05:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Suppressed and non-suppressed scripts (was: Re: [Ltru]Comments on draft-matching-07) Date: Mon, 21 Nov 2005 10:05:09 -0800 Message-ID: Thread-Topic: Suppressed and non-suppressed scripts (was: Re: [Ltru]Comments on draft-matching-07) Thread-Index: AcXufGQgDZ3DJ/hpQl6nE1hXaFL9cgARyTww From: "Addison Phillips" To: "Martin Duerst" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 21 Nov 2005 18:05:11.0014 (UTC) FILETIME=[1D29C860:01C5EEC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166416762==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1166416762== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVyZSBJJ2xsIGV4cGFuZCBvbiB0aGUgcmVtYXJrcyBidXJpZWQgaW4gbXkgcmVzcG9uc2UgdG8g RG91Zy4NCg0KSWYgeW91IGxvb2sgYXQgbXkgbGl0dGxlIGltcGxlbWVudGF0aW9uLCB3aGljaCBz ZWVtcyB0byBiZSByZWxhdGl2ZWx5IGJ1Zy1mcmVlLCB5b3UnbGwgc2VlIHRoYXQgZXhwYW5kaW5n IHdpbGRjYXJkcyBwcm9kdWNlcyBzb21lIG9kZC1zZWVtaW5nIHJlc3VsdHMuIFRoZXkgYXJlIGNv bnNpc3RlbnQgd2l0aCB0aGUgdGV4dCBvZiB0aGUgZHJhZnQuIEJ1dCBJIHdvdWxkIHZpZXcgdGhl bSBhcyBvZGQgYXMgYSB1c2VyLg0KDQpJZGVhbGx5LCBJIHRoaW5rLCBhIGRpc3RhbmNlIG1ldHJp YyBzaG91bGQgcHJvZHVjZSBhcyBtYW55IGRpZmZlcmVudCBsZXZlbHMgb2Ygc2NvcmUgYXMgcG9z c2libGUuIFRoYXQgaXMgImVuLUJyYWktVVMiIHNob3VsZCBoYXZlIGEgbG93ZXIgc2NvcmUgdGhh biAiZW4tVVMiIGZvciB0aGUgcmFuZ2UgImVuLVVTIi4uLiBidXQgYSBoaWdoZXIgc2NvcmUgdGhh biwgc2F5LCAiZnIiIG9yICJlbi1HQiIuIEl0IHNlZW1zIG1vcmUgc2Vuc2libGUuDQoNClRodXMg SSBwcm9wb3NlIHRoYXQgd2UgcmVtb3ZlIHdpbGRjYXJkIGV4cGFuc2lvbiBmcm9tIHNjb3JlZCBm aWx0ZXJpbmcgdW5sZXNzIHRoZSB3aWxkY2FyZCBpcyBleHBsaWNpdGx5IGluIHRoZSByYW5nZS4g VGh1cyAiZW4tKi1VUyIgbWF0Y2hlcyAiZW4tQnJhaS1VUyIgd2l0aCBhIHNjb3JlIG9mIHplcm8s IHdoaWxlICJlbi1VUyIgbWF0Y2hlcyBpdCB3aXRoIGEgc2NvcmUgb2YgMTI4Lg0KDQpDb25zaWRl ciB0aGlzIHJlc3VsdCBzZXQgZm9yIGVuLVVTOg0KDQotIGVuLVVTICgwKQ0KLSBlbi1VUy14LWZv byAoMSkNCi0gZW4tVVMtYm9vbnQgKDQpIC8vIGZpY3Rpb25hbA0KLSBlbiAoMzIpDQotIGVuLUdC ICgzMikNCi0gZW4tTGF0bi1HQiAoMzYpDQotIGVuLUJyYWktVVMgKDEyOCkNCi0gZW4tQnJhaSAo MTYwKQ0KLSBmci1VUyAoMjU2KQ0KLSBmci1GUiAoMjg4KQ0KLSBmci1CcmFpICg0MTYpDQoNCkNv bXBhcmUgdGhpcyB0byB0aGUgd2lsZGNhcmQgZXhwYW5kZWQgbGlzdDoNCg0KLSBlbi1VUyAoMCkN Ci0gZW4tVVMteC1mb28gKDApDQotIGVuLVVTLWJvb250ICgwKQ0KLSBlbi1CcmFpLVVTICgwKQ0K LSBlbiAoMzIpDQotIGVuLUdCICgzMikNCi0gZW4tTGF0bi1HQiAoMzIpDQotIGVuLUJyYWkgKDMy KQ0KLSBmci1VUyAoMjU2KQ0KLSBmci1CcmFpICgyNTYpDQotIGZyLUZSICgyODgpDQoNCkhtbS4u LiB0aGF0IGxpc3QgaXNuJ3QgYXMgdXNlZnVsLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgdmFsdWVz IGFyZSBjb25zaXN0ZW50IHdpdGggdGhlIGFsZ29yaXRobSwgYnV0IGlmIHRoZSBwb2ludCBpcyB0 aGF0IHRoZSBsaXN0IGlzIG9yZGVyZWQsIGl0IG1ha2VzIHNlbnNlIHRoYXQgdGhlICJtaXNzaW5n IiB2YWx1ZXMgaW4gdGhlIHJhbmdlIGFyZSBzY29yZWQuIE5vdyBjb25zaWRlciB0aGlzIHJlc3Vs dCB3aXRoIGVuLSotVVM6DQoNCi0gZW4tVVMgKDApDQotIGVuLUJyYWktVVMgKDApDQotIGVuLVVT LXgtZm9vICgxKQ0KLSBlbi1VUy1ib29udCAoNCkNCi0gZW4gKDMyKQ0KLSBlbi1HQiAoMzIpDQot IGVuLUxhdG4tR0IgKDMyKQ0KLSBlbi1CcmFpICgzMikNCi0gZnItVVMgKDI1NikNCi0gZnItRlIg KDI4OCkNCi0gZnItQnJhaSAoMjg4KQ0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMN Ckdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsdHJ1LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYXJ0aW4gRHVl cnN0DQo+IFNlbnQ6IDIwMDXlubQxMeaciDIx5pelIDE6MDUNCj4gVG86IERvdWcgRXdlbGw7IExU UlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBTdXBwcmVzc2VkIGFuZCBub24tc3VwcHJlc3Nl ZCBzY3JpcHRzICh3YXM6IFJlOiBbTHRydV1Db21tZW50cyBvbg0KPiBkcmFmdC1tYXRjaGluZy0w NykNCj4gDQo+IEF0IDEyOjQ1IDA1LzExLzIxLCBEb3VnIEV3ZWxsIHdyb3RlOg0KPiAgPkhlcmUg YXJlIG15IGNvbW1lbnRzIG9uIGRyYWZ0LW1hdGNoaW5nLTA3LiAgTW9zdCBvZiB0aGVzZSBhcmUg ZWRpdG9yaWFsLg0KPiANCj4gVGhhbmtzLCBncmVhdC4gSSdtIHBpY2tpbmcgb3V0IG9uZSAobWF5 YmUgdGhlIG9ubHkgb25lLA0KPiBhcGFydCBmcm9tIHRoZSBmYWN0IHRoYXQgaW4gc29tZSBwbGFj ZXMsIHlvdSBwbGFubmVkDQo+IHRvIGxvb2sgYXQgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1 bWVudCBhbnl3YXkpDQo+IGlzc3VlIHRoYXQgZG9lc24ndCBsb29rIGVkaXRvcmlhbC4NCj4gDQo+ ICA+ImVuLUxhdG4tVVMiICAgICAgIDAgKGFsbCBmaWVsZHMgbWF0Y2gpDQo+ICA+DQo+ICA+LT4g SW4gcmVhZGluZyB0aGlzLCBpdCBhcHBlYXJzIHRoYXQgImVuLUJyYWktVVMiIHdvdWxkIGFsc28g Z2l2ZSBhDQo+IHBlcmZlY3QgMCBzY29yZSwgYW5kIGZvciB0aGF0IG1hdHRlciBzbyB3b3VsZCAi ZW4tRWd5cC1VUyIuICBJcyB0aGF0DQo+IGNvcnJlY3Q/ICBXZSBhcmVuJ3QgbG9va2luZyBhdCBT dXBwcmVzcy1TY3JpcHQgaGVyZSwgc28gdGhhdCBkb2Vzbid0DQo+IGZhY3Rvcg0KPiBpbnRvIGFu eXRoaW5nICh1bmxlc3Mgd2UgYXJlIG9uZSBvZiB0aGUgImltcGxlbWVudGF0aW9ucyBvciBwcm90 b2NvbHMiDQo+IHRoYXQNCj4gY3VzdG9taXplIHRoaW5ncykuDQo+IA0KPiBJIGdvdCB0aGUgc2Ft ZSBpbXByZXNzaW9uLiBJdCBkb2Vzbid0IGxvb2sgbGlrZSB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2Uu DQo+IEkgd2FzIHRoaW5raW5nIHRoYXQgbWF5YmUgaG93IHRoaXMgc2hvdWxkIGJlIGhhbmRsZWQg aXMgYXMgZm9sbG93czoNCj4gDQo+IC0gSW4gYSByYW5nZSwgYSAnKicgaW4gc2NyaXB0IHBvc2l0 aW9uIHN0YXlzIGEgJyonOyBhbiBhYnNlbnQNCj4gICAgc2NyaXB0IGZpZWxkIGdldHMgY29udmVy dGVkIGludG8gdGhlICdzdXBwcmVzcy1zY3JpcHQnIHZhbHVlDQo+ICAgIGZvciB0aGF0IGxhbnVn YWdlIGlmIHN1Y2ggYSB2YWx1ZSBpcyBhdmFpbGFibGUuIE90aGVyd2lzZSwgdGhpcw0KPiAgICBl eHBhbmRzIGludG8gYSAnKicuDQo+IA0KPiAtIFRoZSBjb3JyZXNwb25kaW5nIGNvbnRlbnQgdGFn cyBhcmUgYWxzbyBleHBhbmRlZCBieSBzdXBwcmVzcy1zY3JpcHQNCj4gICAgaW5mb3JtYXRpb24g d2hlcmUgYXZhaWxhYmxlLg0KPiANCj4gLSBUaGUgbWF0Y2hpbmcgaXMgZG9uZSBvbiB0aGUgcmVz dWx0aW5nIGV4cGFuZGVkIHRhZ3MsIHdpdGggYSAnKicNCj4gICAgbWF0Y2hpbmcgYW55dGhpbmcu DQo+IA0KPiBUaGlzIHdvdWxkIGdpdmUgdGhlIGZvbGxvd2luZzoNCj4gDQo+IFJhbmdlOiBlbi1V UyAtPiBlbi1MYXRuLVVTDQo+IFRhZzogZW4tQnJhaS1VUyAtPiBlbi1CcmFpLVVTDQo+IC0+IG1h dGNoIG9uIGxhbmd1YWdlIGFuZCByZWdpb24sIGJ1dCBub3Qgb24gc2NyaXB0DQo+IA0KPiBSYW5n ZTogZW4tKi1VUyAtPiBlbi0qLVVTDQo+IFRhZzogZW4tQnJhaS1VUyAtPiBlbi1CcmFpLVVTDQo+ IC0+IG1hdGNoIG9uIGFsbCBmaWVsZHMNCj4gDQo+IFJhbmdlOiBlbi1VUyAtPiBlbi1MYXRuLVVT DQo+IFRhZzogZW4tVVMgLT4gZW4tTGF0bi1VUw0KPiAtPiBtYXRjaCBvbiBhbGwgZmllbGRzDQo+ IA0KPiBJJ20gcmF0aGVyIHN1cmUgc29tZWJvZHkgd2lsbCBmaW5kIGEgaGFpciBpbiB0aGlzIHNv dXAsDQo+IGlmIG5vdCBzb21lIGJpZ2dlciBvYnN0YWNsZSwgYnV0IGF0IGxlYXN0IGZvciB0aGUg Y2FzZXMNCj4gYWJvdmUsIGl0IHdvdWxkIHdvcmsgcmVhc29uYWJseSBhcyBleHBlY3RlZC4NCj4g DQo+IA0KPiBSZWdhcmRzLCAgICBNYXJ0aW4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1 QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUN Cg== --===============1166416762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1166416762==-- From ltru-bounces@ietf.org Mon Nov 21 18:31:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeL8T-0003n7-Dq; Mon, 21 Nov 2005 18:31:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeL8S-0003me-63 for ltru@megatron.ietf.org; Mon, 21 Nov 2005 18:31:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27014 for ; Mon, 21 Nov 2005 18:31:03 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeLQw-0007jC-5W for ltru@ietf.org; Mon, 21 Nov 2005 18:50:51 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:31:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Nov 2005 15:31:22 -0800 Message-ID: Thread-Topic: another demo... Thread-Index: AcXu867WmKLE5RElSNm/GnnhpFTUWA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 21 Nov 2005 23:31:23.0480 (UTC) FILETIME=[AF431580:01C5EEF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ltru] another demo... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771683465==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1771683465== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBwdXQgbXkgYmFzaWMgYW5kIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGRlbW8gcGFnZSBvbiBt eSB3ZWJzaXRlIHRvZGF5IHRvby4gTm90aGluZyBzcGVjaWFsIGFuZCBub3QgZXh0ZW5zaXZlbHkg dGVzdGVkLCBidXQgbWlnaHQgYmUgdXNlZnVsLiBUaGUgZXh0ZW5kZWQgcmFuZ2UgZmlsdGVyaW5n IHByb3ZpZGVzIGV4YW1wbGVzIG9mIGJvdGggdmVyc2lvbnMgb2YgdGhlIE1BWSBpbiBkcmFmdC0w Ny4NCg0KUGxlYXNlIG5vdGU6IEknbSBvbiB2YWNhdGlvbiB0aHJvdWdoIEZyaWRheS4gSSdtIGdv aW5nIHRvIHN1Ym1pdCB0aGUgZHJhZnQtMDcgb24gbXkgd2Vic2l0ZSBzbyB0aGF0IHdoYXRldmVy IHRoZSBjdXJyZW50IGRlYmF0ZSBhYm91dCBsb29rdXAgc2V0dGxlcyB1cG9uIGNhbiBiZSB3b3Jr ZWQgaW50byBhIGNsZWFuIGRvY3VtZW50Lg0KDQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20v bGFuZ3RhZ3MvZmlsdGVyZWQuanNwDQoNCkJlc3QgUmVnYXJkcywNCg0KQWRkaXNvbg0KDQpBZGRp c29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUN Cmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZl YXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= --===============1771683465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1771683465==-- From ltru-bounces@ietf.org Mon Nov 21 18:33:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLAD-0004MK-HI; Mon, 21 Nov 2005 18:33:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLAB-0004Kh-Ft; Mon, 21 Nov 2005 18:33:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27314; Mon, 21 Nov 2005 18:32:41 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeLSV-0007oB-TT; Mon, 21 Nov 2005 18:52:30 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:33:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5EEF3.E9795A24" Date: Mon, 21 Nov 2005 15:33:00 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-ltru-matching: submission Thread-Index: AcXu8+jmngcrVe3vTJqD4R5oZyc5dA== From: "Addison Phillips" To: X-OriginalArrivalTime: 21 Nov 2005 23:33:02.0184 (UTC) FILETIME=[EA181E80:01C5EEF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 717d651095a319b49fc3b6c7b72cb4dd Cc: LTRU Working Group Subject: [Ltru] draft-ietf-ltru-matching: submission X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EEF3.E9795A24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGRyYWZ0LTA3IG9mIGRyYWZ0LWll dGYtbHRydS1tYXRjaGluZy4NCg0KVGhhbmtzIQ0KDQpBZGRpc29uIChmb3IgdGhlIGVkaXRvcnMp DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBT b2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMg bm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg== ------_=_NextPart_001_01C5EEF3.E9795A24 Content-Type: text/plain; name="draft-ietf-ltru-matching-07.txt" Content-Description: draft-ietf-ltru-matching-07.txt Content-Disposition: attachment; filename="draft-ietf-ltru-matching-07.txt" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBLiBQaGlsbGlwcywgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBRdWVzdCBTb2Z0d2FyZQpPYnNvbGV0ZXM6IDMwNjYgKGlmIGFw cHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIERhdmlzLCBFZC4KRXhwaXJl czogTWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSUJNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAxOCwgMjAwNQoKCiAgICAgICAgICAgICAgICAgICAgICAgTWF0Y2hp bmcgb2YgTGFuZ3VhZ2UgVGFncwogICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1sdHJ1 LW1hdGNoaW5nLTA3CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMg SW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGlj YWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdh cmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhl IG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNl IHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElF VEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3Ro ZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAg VGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nl c3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgMjIsIDIwMDYuCgpDb3B5cmlnaHQgTm90aWNl CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4KCkFic3RyYWN0 CgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBkaWZmZXJlbnQgbWVjaGFuaXNtcyBmb3IgY29t cGFyaW5nLCBtYXRjaGluZywKICAgYW5kIGV2YWx1YXRpbmcgbGFuZ3VhZ2UgdGFncy4gIFBvc3Np YmxlIGFsZ29yaXRobXMgZm9yIGxhbmd1YWdlCiAgIG5lZ290aWF0aW9uIGFuZCBjb250ZW50IHNl bGVjdGlvbiBhcmUgZGVzY3JpYmVkLiAgVGhpcyBkb2N1bWVudCwgaW4KICAgY29tYmluYXRpb24g d2l0aCBSRkMgMzA2NmJpcyAocmVwbGFjZSAiMzA2NmJpcyIgd2l0aCB0aGUgUkZDIG51bWJlcgog ICBhc3NpZ25lZCB0byBkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTQpLCByZXBsYWNlcyBSRkMg MzA2Niwgd2hpY2gKICAgcmVwbGFjZWQgUkZDIDE3NjYuCgoKCgpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDUKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDIu ICBUaGUgTGFuZ3VhZ2UgUmFuZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNAogICAgIDIuMS4gIExpc3RzIG9mIExhbmd1YWdlIFJhbmdlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAyLjIuICBCYXNpYyBMYW5ndWFnZSBSYW5n ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMi4zLiAgRXh0 ZW5kZWQgTGFuZ3VhZ2UgUmFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NQogICAgIDIuNC4gIENob29zaW5nIGEgTGFuZ3VhZ2UgUmFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDYKICAgMy4gIFR5cGVzIG9mIE1hdGNoaW5nICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMy4xLiAgQ2hvb3NpbmcgYSBU eXBlIG9mIE1hdGNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgIDMu Mi4gIEZpbHRlcmluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTAKICAgICAgIDMuMi4xLiAgRmlsdGVyaW5nIHdpdGggQmFzaWMgTGFuZ3VhZ2UgUmFu Z2VzIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMi4gIEZpbHRlcmluZyB3aXRoIEV4 dGVuZGVkIExhbmd1YWdlIFJhbmdlcyAgLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4yLjMuICBT Y29yZWQgRmlsdGVyaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIK ICAgICAzLjMuICBMb29rdXAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE0CiAgIDQuICBPdGhlciBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgIDQuMS4gIE1lYW5pbmcgb2YgTGFu Z3VhZ2UgVGFncyBhbmQgUmFuZ2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICA0LjIu ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4g LiAuIDE5CiAgICAgNC4zLiAgTGVuZ3RoIENvbnNpZGVyYXRpb25zIGluIE1hdGNoaW5nICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjIKICAgNi4gIENoYW5nZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAg IDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyNAogICA4LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2CiAgICAgOS4xLiAg Tm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNgogICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjYKICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3CiAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOAogICBJ bnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjkKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAg ICAgRXhwaXJlcyBNYXkgMjIsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxh bmV0IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBudW1iZXIgb2YKICAgbGFuZ3VhZ2Vz LiAgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyB3aHkgb25lIHdvdWxkIHdhbnQgdG8gaWRlbnRpZnkg dGhlCiAgIGxhbmd1YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3Jt YXRpb24uCgogICBJbmZvcm1hdGlvbiBhYm91dCBhIHVzZXIncyBsYW5ndWFnZSBwcmVmZXJlbmNl cyBjb21tb25seSBuZWVkIHRvIGJlCiAgIGlkZW50aWZpZWQgc28gdGhhdCBhcHByb3ByaWF0ZSBw cm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yCiAgIGV4YW1wbGUsIHRoZSB1c2VyJ3MgbGFu Z3VhZ2UgcHJlZmVyZW5jZXMgaW4gYSBicm93c2VyIGNhbiBiZSB1c2VkIHRvCiAgIHNlbGVjdCB3 ZWIgcGFnZXMgYXBwcm9wcmlhdGVseS4gIExhbmd1YWdlIHByZWZlcmVuY2VzIGNhbiBhbHNvIGJl CiAgIHVzZWQgdG8gc2VsZWN0IGFtb25nIHRvb2xzIChzdWNoIGFzIGRpY3Rpb25hcmllcykgdG8g YXNzaXN0IGluIHRoZQogICBwcm9jZXNzaW5nIG9yIHVuZGVyc3RhbmRpbmcgb2YgY29udGVudCBp biBkaWZmZXJlbnQgbGFuZ3VhZ2VzLgoKICAgR2l2ZW4gYSBzZXQgb2YgbGFuZ3VhZ2UgaWRlbnRp ZmllcnMsIHN1Y2ggYXMgdGhvc2UgZGVmaW5lZCBpbgogICBbUkZDMzA2NmJpc10sIHZhcmlvdXMg bWVjaGFuaXNtcyBjYW4gYmUgZW52aXNpb25lZCBmb3IgcGVyZm9ybWluZwogICBsYW5ndWFnZSBu ZWdvdGlhdGlvbiBhbmQgdGFnIG1hdGNoaW5nLiAgQXBwbGljYXRpb25zLCBwcm90b2NvbHMsIG9y CiAgIHNwZWNpZmljYXRpb25zIHdpbGwgaGF2ZSB2YXJ5aW5nIG5lZWRzIGFuZCByZXF1aXJlbWVu dHMgdGhhdCBhZmZlY3QKICAgdGhlIGNob2ljZSBvZiBhIHN1aXRhYmxlIG1lY2hhbmlzbS4KCiAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG1lY2hhbmlzbXMgZm9yIG1hdGNoaW5nLCBz ZWxlY3RpbmcsIG9yCiAgIGZpbHRlcmluZyBjb250ZW50IHdob3NlIG5hdHVyYWwgbGFuZ3VhZ2Ug aXMgaWRlbnRpZmllZCB1c2luZyBMYW5ndWFnZQogICBUYWdzIFtSRkMzMDY2YmlzXSwgYXMgd2Vs bCBhcyB0aGUgc3ludGF4IChjYWxsZWQgYSAibGFuZ3VhZ2UgcmFuZ2UiKQogICBhc3NvY2lhdGVk IHdpdGggZWFjaCBvZiB0aGVzZSBtZWNoYW5pc21zIGZvciBzcGVjaWZ5aW5nIHRoZSB1c2VyJ3MK ICAgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMuCgogICBUaGlzIGRvY3VtZW50LCBpbiBjb21iaW5hdGlv biB3aXRoIFtSRkMzMDY2YmlzXSAocmVwbGFjZSAiMzA2NmJpcyIKICAgZ2xvYmFsbHkgaW4gdGhp cyBkb2N1bWVudCB3aXRoIHRoZSBSRkMgbnVtYmVyIGFzc2lnbmVkIHRvCiAgIGRyYWZ0LWlldGYt bHRydS1yZWdpc3RyeS0xNCksIHJlcGxhY2VzIFtSRkMzMDY2XSwgd2hpY2ggcmVwbGFjZWQKICAg W1JGQzE3NjZdLgoKICAgVGhlIGtleXdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKCgoKCgoKCgoKCgoK CgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAg ICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1 LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgoyLiAgVGhlIExhbmd1YWdl IFJhbmdlCgogICBMYW5ndWFnZSBUYWdzIFtSRkMzMDY2YmlzXSBhcmUgdXNlZCB0byBpZGVudGlm eSB0aGUgbGFuZ3VhZ2Ugb2Ygc29tZQogICBpbmZvcm1hdGlvbiBpdGVtIG9yIGNvbnRlbnQuICBB cHBsaWNhdGlvbnMgb3IgcHJvdG9jb2xzIHRoYXQgdXNlCiAgIGxhbmd1YWdlIHRhZ3MgYXJlIG9m dGVuIGZhY2VkIHdpdGggdGhlIHByb2JsZW0gb2YgaWRlbnRpZnlpbmcgc2V0cyBvZgogICBjb250 ZW50IHRoYXQgc2hhcmUgY2VydGFpbiBsYW5ndWFnZSBhdHRyaWJ1dGVzLiAgRm9yIGV4YW1wbGUs CiAgIEhUVFAvMS4xIFtSRkMyNjE2XSBkZXNjcmliZXMgbGFuZ3VhZ2UgcmFuZ2VzIGluIGl0cyBk aXNjdXNzaW9uIG9mIHRoZQogICBBY2NlcHQtTGFuZ3VhZ2UgaGVhZGVyIChTZWN0aW9uIDE0LjQp LiAgVGhlc2UgYXJlIHRvIGJlIHVzZWQgd2hlbgogICBzZWxlY3RpbmcgY29udGVudCBmcm9tIHNl cnZlcnMgYmFzZWQgb24gdGhlIGxhbmd1YWdlIG9mIHRoYXQgY29udGVudC4KCiAgIFdoZW4gc2Vs ZWN0aW5nIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGl0cyBsYW5ndWFnZSwgaXQgaXMgdXNlZnVsIHRv CiAgIGhhdmUgYSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIHNldHMgb2YgbGFuZ3VhZ2UgdGFn cyB0aGF0IHNoYXJlCiAgIHNwZWNpZmljIGF0dHJpYnV0ZXMuICBUaGlzIGFsbG93cyB1c2VycyB0 byBzZWxlY3Qgb3IgZmlsdGVyIGNvbnRlbnQKICAgYmFzZWQgb24gc3BlY2lmaWMgcmVxdWlyZW1l bnRzLiAgU3VjaCBhbiBpZGVudGlmaWVyIGlzIGNhbGxlZCBhCiAgICJMYW5ndWFnZSBSYW5nZSIu CgogICBMYW5ndWFnZSB0YWdzIGFuZCB0aHVzIGxhbmd1YWdlIHJhbmdlcyBhcmUgdG8gYmUgdHJl YXRlZCBhcyBjYXNlCiAgIGluc2Vuc2l0aXZlOiB0aGVyZSBleGlzdCBjb252ZW50aW9ucyBmb3Ig dGhlIGNhcGl0YWxpemF0aW9uIG9mIHNvbWUKICAgb2YgdGhlIHN1YnRhZ3MsIGJ1dCB0aGVzZSBN VVNUIE5PVCBiZSB0YWtlbiB0byBjYXJyeSBtZWFuaW5nLgogICBNYXRjaGluZyBvZiBsYW5ndWFn ZSB0YWdzIHRvIGxhbmd1YWdlIHJhbmdlcyBNVVNUIGJlIGRvbmUgaW4gYSBjYXNlCiAgIGluc2Vu c2l0aXZlIG1hbm5lciBhcyB3ZWxsLgoKMi4xLiAgTGlzdHMgb2YgTGFuZ3VhZ2UgUmFuZ2VzCgog ICBXaGVuIHVzZXJzIHNwZWNpZnkgYSBsYW5ndWFnZSBwcmVmZXJlbmNlIHRoZXkgb2Z0ZW4gbmVl ZCB0byBzcGVjaWZ5IGEKICAgcHJpb3JpdGl6ZWQgbGlzdCBvZiBsYW5ndWFnZSByYW5nZXMgaW4g b3JkZXIgdG8gYmVzdCByZWZsZWN0IHRoZWlyCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzLiAgVGhp cyBpcyBlc3BlY2lhbGx5IHRydWUgZm9yIHNwZWFrZXJzIG9mCiAgIG1pbm9yaXR5IGxhbmd1YWdl cy4gIEEgc3BlYWtlciBvZiBCcmV0b24gaW4gRnJhbmNlLCBmb3IgZXhhbXBsZSwgbWF5CiAgIHNw ZWNpZnkgImJlIiBmb2xsb3dlZCBieSAiZnIiLCBtZWFuaW5nIHRoYXQgaWYgQnJldG9uIGlzIGF2 YWlsYWJsZSwKICAgaXQgaXMgcHJlZmVycmVkLCBidXQgb3RoZXJ3aXNlIEZyZW5jaCBpcyB0aGUg YmVzdCBhbHRlcm5hdGl2ZS4gIEl0CiAgIGNhbiBnZXQgbW9yZSBjb21wbGV4OiBhIHNwZWFrZXIg bWF5IHdpc2ggdG8gZmFsbCBiYWNrIGZyb20gU2tvbHQgU2FtaQogICB0byBOb3J0aGVybiBTYW1p IHRvIEZpbm5pc2guCgogICBBICJMYW5ndWFnZSBQcmlvcml0eSBMaXN0IiBjb25zaXN0cyBvZiBh IHByaW9yaXRpemVkIG9yIHdlaWdodGVkIGxpc3QKICAgb2YgbGFuZ3VhZ2UgcmFuZ2VzLiAgT25l IHdlbGwga25vd24gZXhhbXBsZSBvZiBzdWNoIGEgbGlzdCBpcyB0aGUKICAgIkFjY2VwdC1MYW5n dWFnZSIgaGVhZGVyIGRlZmluZWQgaW4gUkZDIDI2MTYgW1JGQzI2MTZdIChzZWUgU2VjdGlvbgog ICAxNC40KSBhbmQgUkZDIDMyODIgW1JGQzMyODJdLgoKICAgVGhlIHZhcmlvdXMgbWF0Y2hpbmcg b3BlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBpbmNsdWRlCiAgIGNvbnNpZGVy YXRpb25zIGZvciB1c2luZyBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QuICBXaGVuIGdpdmVuIGFz CiAgIGV4YW1wbGVzIGluIHRoaXMgZG9jdW1lbnQsIGxhbmd1YWdlIHByaW9yaXR5IGxpc3RzIHdp bGwgYmUgc2hvd24gYXMgYQogICBxdW90ZWQgc2VxdWVuY2Ugb2YgcmFuZ2VzIHNlcGFyYXRlZCBi eSBzZW1pLWNvbG9ucywgbGlrZSB0aGlzOiAiZW47CiAgIGZyOyB6aC1IYW50IiAod2hpY2ggd291 bGQgYmUgcmVhZCBhcyAiRW5nbGlzaCBiZWZvcmUgRnJlbmNoIGJlZm9yZQogICBDaGluZXNlIGFz IHdyaXR0ZW4gaW4gdGhlIFRyYWRpdGlvbmFsIHNjcmlwdCIpLgoKMi4yLiAgQmFzaWMgTGFuZ3Vh Z2UgUmFuZ2UKCiAgIEEgIkJhc2ljIExhbmd1YWdlIFJhbmdlIiBpZGVudGlmaWVzIHRoZSBzZXQg b2YgY29udGVudCB3aG9zZSBsYW5ndWFnZQoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4 cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVy IDIwMDUKCgogICB0YWdzIGJlZ2luIHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ugb2Ygc3VidGFncy4g IEEgYmFzaWMgbGFuZ3VhZ2UgcmFuZ2UKICAgaXMgaWRlbnRpZmllZCBieSBpdHMgJ2xhbmd1YWdl IHJhbmdlJyB0YWcsIGJ5IGFkYXB0aW5nIHRoZQogICBBQk5GW1JGQzQyMzRdIGZyb20gSFRUUC8x LjEgW1JGQzI2MTZdIDoKCiAgIGxhbmd1YWdlLXJhbmdlID0gbGFuZ3VhZ2UtdGFnIC8gIioiCiAg IGxhbmd1YWdlLXRhZyAgID0gMSo4W2FscGhhbnVtXSAqWyItIiAxKjhhbHBoYW51bV0KICAgYWxw aGFudW0gICAgICAgPSBBTFBIQSAvIERJR0lUCgogICBUaGF0IGlzLCBhIGxhbmd1YWdlLXJhbmdl IGhhcyB0aGUgc2FtZSBzeW50YXggYXMgYSBsYW5ndWFnZS10YWcgb3IgaXMKICAgdGhlIHNpbmds ZSBjaGFyYWN0ZXIgIioiLiAgQmFzaWMgTGFuZ3VhZ2UgUmFuZ2VzIGltcGx5IHRoYXQgdGhlcmUg aXMKICAgYSBzZW1hbnRpYyByZWxhdGlvbnNoaXAgYmV0d2VlbiBsYW5ndWFnZSB0YWdzIHRoYXQg c2hhcmUgdGhlIHNhbWUKICAgcHJlZml4LiAgV2hpbGUgdGhpcyBpcyBvZnRlbiB0aGUgY2FzZSwg aXQgaXMgbm90IGFsd2F5cyB0cnVlIGFuZAogICB1c2VycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBz ZXQgb2YgbGFuZ3VhZ2UgdGFncyB0aGF0IG1hdGNoIGEgc3BlY2lmaWMKICAgbGFuZ3VhZ2UtcmFu Z2UgbWF5IG5vdCBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUuCgogICBCYXNpYyBsYW5ndWFnZSBy YW5nZXMgd2VyZSBvcmlnaW5hbGx5IGRlc2NyaWJlZCBpbiBbUkZDMzA2Nl0gYW5kCiAgIEhUVFAv MS4xIFtSRkMyNjE2XSAod2hlcmUgdGhleSBhcmUgcmVmZXJyZWQgdG8gYXMgc2ltcGx5IGEgImxh bmd1YWdlCiAgIHJhbmdlIikuCgoyLjMuICBFeHRlbmRlZCBMYW5ndWFnZSBSYW5nZQoKICAgQSBC YXNpYyBMYW5ndWFnZSBSYW5nZSBkb2VzIG5vdCBhbHdheXMgcHJvdmlkZSB0aGUgbW9zdCBhcHBy b3ByaWF0ZQogICB3YXkgdG8gc3BlY2lmeSBhIHVzZXIncyBwcmVmZXJlbmNlcy4gIFNvbWV0aW1l cyBpdCBpcyBiZW5lZmljaWFsIHRvCiAgIHVzZSBhIG1vcmUgZ3JhbnVsYXIgbWF0Y2hpbmcgc2No ZW1lIHRoYXQgdGFrZXMgYWR2YW50YWdlIG9mIHRoZQogICBpbnRlcm5hbCBzdHJ1Y3R1cmUgb2Yg bGFuZ3VhZ2UgdGFncywgYnkgYWxsb3dpbmcgdGhlIHVzZXIgdG8gc3BlY2lmeSwKICAgZm9yIGV4 YW1wbGUsIHRoZSB2YWx1ZSBvZiBhIHNwZWNpZmljIGZpZWxkIGluIGEgbGFuZ3VhZ2UgdGFnIG9y IHRvCiAgIGluZGljYXRlIHdoaWNoIHZhbHVlcyBhcmUgb2YgaW50ZXJlc3QgaW4gZmlsdGVyaW5n IG9yIHNlbGVjdGluZyB0aGUKICAgY29udGVudC4KCiAgIEluIGFuIGV4dGVuZGVkIGxhbmd1YWdl IHJhbmdlLCB0aGUgaWRlbnRpZmllciB0YWtlcyB0aGUgZm9ybSBvZiBhCiAgIHNlcmllcyBvZiBz dWJ0YWdzIHdoaWNoIE1VU1QgY29uc2lzdCBvZiB3ZWxsLWZvcm1lZCBzdWJ0YWdzIG9yIHRoZQog ICBzcGVjaWFsIHN1YnRhZyAiKiIuICBGb3IgZXhhbXBsZSwgdGhlIGxhbmd1YWdlIHJhbmdlICJl bi0qLVVTIgogICBzcGVjaWZpZXMgYSBwcmltYXJ5IGxhbmd1YWdlIG9mICdlbicsIGZvbGxvd2Vk IGJ5IGFueSBzY3JpcHQgc3VidGFnLAogICBmb2xsb3dlZCBieSB0aGUgcmVnaW9uIHN1YnRhZyAn VVMnLgoKICAgQW4gZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgY2FuIGJlIHJlcHJlc2VudGVkIGJ5 IHRoZSBmb2xsb3dpbmcgQUJORjoKICAgZXh0ZW5kZWQtbGFuZ3VhZ2UtcmFuZ2UgID0gcmFuZ2Ug OyBhIHJhbmdlCiAgICAgICAgICAgICAgICAgLyBwcml2YXRldXNlICAgICAgICAgICAgICA7IHBy aXZhdGUtdXNlIHRhZwogICAgICAgICAgICAgICAgIC8gZ3JhbmRmYXRoZXJlZCAgICAgICAgICAg OyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlvbnMKCiAgIHJhbmdlICAgICAgICAgPSAobGFuZ3Vh Z2UKICAgICAgICAgICAgICAgICAgICBbIi0iIHNjcmlwdF0KICAgICAgICAgICAgICAgICAgICBb Ii0iIHJlZ2lvbl0KICAgICAgICAgICAgICAgICAgICAqKCItIiB2YXJpYW50KQogICAgICAgICAg ICAgICAgICAgICooIi0iIGV4dGVuc2lvbikKICAgICAgICAgICAgICAgICAgICBbIi0iIHByaXZh dGV1c2VdKQoKICAgbGFuZ3VhZ2UgICAgICA9ICgyKjNBTFBIQSBbIGV4dGxhbmcgXSkgOyBzaG9y dGVzdCBJU08gNjM5IGNvZGUKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1h eSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoK ICAgICAgICAgICAgICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAgOyByZXNlcnZlZCBmb3Ig ZnV0dXJlIHVzZQogICAgICAgICAgICAgICAgIC8gNSo4QUxQSEEgICAgICAgICAgICAgICA7IHJl Z2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnCiAgICAgICAgICAgICAgICAgLyAiKiIgICAgICAgICAg ICAgICAgICAgIDsgLi4uIG9yIHdpbGRjYXJkCgogICBleHRsYW5nICAgICAgID0gKjIoIi0iIDNB TFBIQSkgKCItIiAoIDNBTFBIQSAvICIqIikpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgOyB3aWxkY2FyZCBjYW4gb25seSBhcHBlYXIKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyAgIGF0IHRoZSBlbmQKCiAgIHNj cmlwdCAgICAgICAgPSA0QUxQSEEgICAgICAgICAgICAgICAgIDsgSVNPIDE1OTI0IGNvZGUKICAg ICAgICAgICAgICAgICAvICIqIiAgICAgICAgICAgICAgICAgICAgOyBvciB3aWxkY2FyZAoKICAg cmVnaW9uICAgICAgICA9IDJBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2RlCiAg ICAgICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgICAgIDsgVU4gTS40OSBjb2RlCiAg ICAgICAgICAgICAgICAgLyAiKiIgICAgICAgICAgICAgICAgICAgIDsgLi4uIG9yIHdpbGRjYXJk CgogICB2YXJpYW50ICAgICAgID0gNSo4YWxwaGFudW0gICAgICAgICAgICA7IHJlZ2lzdGVyZWQg dmFyaWFudHMKICAgICAgICAgICAgICAgICAvIChESUdJVCAzYWxwaGFudW0pICAgICAgOwogICAg ICAgICAgICAgICAgIC8gIioiICAgICAgICAgICAgICAgICAgICA7IC4uLiBvciB3aWxkY2FyZAoK ICAgZXh0ZW5zaW9uICAgICA9IHNpbmdsZXRvbiAqKCItIiAoMio4YWxwaGFudW0pKSBbICItKiIg XQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IGV4dGVuc2lvbiBz dWJ0YWdzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgd2lsZGNh cmQgY2FuIG9ubHkgYXBwZWFyCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDsgICBhdCB0aGUgZW5kCgogICBzaW5nbGV0b24gICAgID0gJXg0MS01NyAvICV4NTktNUEg LyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lUCiAgICAgICAgICAgICAgICAgOyAiYSItInciIC8g InkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloiIC8gIjAiLSI5IgogICAgICAgICAgICAgICAgIDsg U2luZ2xlIGxldHRlcnM6IHgvWCBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UKCiAgIHByaXZh dGV1c2UgICAgPSAoIngiLyJYIikgMSooIi0iICgxKjhhbHBoYW51bSkpCgogICBncmFuZGZhdGhl cmVkID0gMSozQUxQSEEgMSoyKCItIiAoMio4YWxwaGFudW0pKQogICAgICAgICAgICAgICAgICAg OyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlvbgogICAgICAgICAgICAgICAgICAgOyBOb3RlOiBJ IGlzIHRoZSBvbmx5IHNpbmdsZXRvbgogICAgICAgICAgICAgICAgICAgOyB0aGF0IHN0YXJ0cyBh IGdyYW5kZmF0aGVyZWQgdGFnCgogICBhbHBoYW51bSAgICAgID0gKEFMUEhBIC8gRElHSVQpICAg ICAgIDsgbGV0dGVycyBhbmQgbnVtYmVycwoKICAgQSBmaWVsZCBub3QgcHJlc2VudCBpbiB0aGUg bWlkZGxlIG9mIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIE1BWQogICBiZSB0cmVhdGVkIGFz IGlmIHRoZSBmaWVsZCBjb250YWluZWQgYSAiKiIuICBGb3IgZXhhbXBsZSwgdGhlIHJhbmdlCiAg ICJlbi1VUyIgTUFZIGJlIGNvbnNpZGVyZWQgdG8gYmUgZXF1aXZhbGVudCB0byB0aGUgcmFuZ2Ug ImVuLSotVVMiLgogICBUaGlzIGFsc28gbWVhbnMgdGhhdCBtdWx0aXBsZSB3aWxkY2FyZHMgY2Fu IGJlIGNvbGxhcHNlZCAoc28gdGhhdAogICAiZW4tKi0qLVVTIiBpcyBlcXVpdmFsZW50IHRvICJl bi0qLVVTIikuCgoyLjQuICBDaG9vc2luZyBhIExhbmd1YWdlIFJhbmdlCgogICBVc2VycyBpbmRp Y2F0ZSB0aGVpciBsYW5ndWFnZSBwcmVmZXJlbmNlcyB2aWEgdGhlIGNob2ljZSBvZiBhCiAgIGxh bmd1YWdlIHJhbmdlIG9yIHRoZSBzZXQgb2YgbGFuZ3VhZ2UgcmFuZ2VzIGluIHRoZSBsYW5ndWFn ZSBwcmlvcml0eQoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAy MDA2ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgogICBsaXN0 LiAgVGhlIHR5cGUgb2YgbWF0Y2hpbmcgd2lsbCBhZmZlY3Qgd2hhdCB0aGUgYmVzdCBjaG9pY2Ug aXMgZm9yCiAgIGdpdmVuIHVzZXIuICBJbiBhZGRpdGlvbiwgdXNlcidzIHNob3VsZCBiZSBhd2Fy ZSB0aGF0LCB3aGVuIHdvcmtpbmcKICAgd2l0aCBsYW5ndWFnZSByYW5nZXMsIG1vc3QgbWF0Y2hp bmcgc2NoZW1lcyBtYWtlIG5vIGF0dGVtcHQgdG8KICAgcHJvY2VzcyB0aGUgc2VtYW50aWMgbWVh bmluZyBvZiB0aGUgc3VidGFncy4gIFRoZSBsYW5ndWFnZSB0YWcgYW5kCiAgIGxhbmd1YWdlIHJh bmdlIChvciB0aGVpciBzdWJ0YWdzKSBhcmUgdXN1YWxseSBjb21wYXJlZCBpbiBhIGNhc2UKICAg aW5zZW5zaXRpdmUgbWFubmVyIHVzaW5nIGJhc2ljIHN0cmluZyBwcm9jZXNzaW5nLiAgVGh1cyB0 aGUgY2hvaWNlIG9mCiAgIHN1YnRhZ3MgaW4gYm90aCB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCBsYW5n dWFnZSByYW5nZSBtYXkgYWZmZWN0IHRoZQogICByZXN1bHRzIHByb2R1Y2VkLgoKICAgVXNlcnMg U0hPVUxEIGF2b2lkIHN1YnRhZ3MgdGhhdCBhZGQgbm8gZGlzdGluZ3Vpc2hpbmcgdmFsdWUgdG8g YQogICBsYW5ndWFnZSByYW5nZS4gIEZvciBleGFtcGxlLCBzY3JpcHQgc3VidGFncyBTSE9VTEQg Tk9UIGJlIHVzZWQgdG8KICAgZm9ybSBhIGxhbmd1YWdlIHJhbmdlIHdpdGggbGFuZ3VhZ2Ugc3Vi dGFncyB3aGljaCBoYXZlIGEgbWF0Y2hpbmcKICAgU3VwcHJlc3MtU2NyaXB0IGZpZWxkIGluIHRo ZWlyIHJlZ2lzdHJ5IHJlY29yZC4gIFRodXMgdGhlIGxhbmd1YWdlCiAgIHJhbmdlICJlbi1MYXRu IiBpcyBwcm9iYWJseSBpbmFwcHJvcHJpYXRlIGluIG1vc3QgY2FzZXMgKGJlY2F1c2UgdGhlCiAg IHZhc3QgbWFqb3JpdHkgb2YgRW5nbGlzaCBkb2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4gdGhlIExh dGluIHNjcmlwdAogICBhbmQgdGh1cyB0aGUgJ2VuJyBsYW5ndWFnZSBzdWJ0YWcgaGFzIGEgU3Vw cHJlc3MtU2NyaXB0IGZpZWxkIGZvcgogICAnTGF0bicgaW4gdGhlIHJlZ2lzdHJ5KS4KCiAgIFdo ZW4gd29ya2luZyB3aXRoIHRhZ3MgYW5kIHJhbmdlcywgbm90ZSB0aGF0IGV4dGVuc2lvbnMgYW5k IG1vc3QKICAgcHJpdmF0ZS11c2Ugc3VidGFncyBhcmUgb3J0aG9nb25hbCB0byBsYW5ndWFnZSB0 YWcgZmFsbGJhY2sgYW5kIHVzZXJzCiAgIFNIT1VMRCBhdm9pZCB1c2luZyB0aGVzZSBzdWJ0YWdz IGluIGxhbmd1YWdlIHJhbmdlcywgc2luY2UgdGhleSB3aWxsCiAgIG9mdGVuIGludGVyZmVyZSB3 aXRoIHRoZSBzZWxlY3Rpb24gb2YgYXZhaWxhYmxlIGxhbmd1YWdlIGNvbnRlbnQuCiAgIFNpbmNl IHRoZXNlIHN1YnRhZ3MgYXJlIGFsd2F5cyBhdCB0aGUgZW5kIG9mIHRoZSBzZXF1ZW5jZSBvZiBz dWJ0YWdzLAogICB0aGV5IGRvbid0IG5vcm1hbGx5IGludGVyZmVyZSB3aXRoIHRoZSB1c2Ugb2Yg cHJlZml4ZXMgZm9yIHRoZQogICBmaWx0ZXJpbmcgc2NoZW1lcyBkZXNjcmliZWQgYmVsb3cgaW4g U2VjdGlvbiAzLgoKICAgV2hlbiB3b3JraW5nIHdpdGggdGFncyBhbmQgcmFuZ2VzIHVzZXJzIFNI T1VMRCBub3RlIHRoZSBmb2xsb3dpbmc6CgogICAxLiAgUHJpdmF0ZS11c2UgYW5kIEV4dGVuc2lv biBzdWJ0YWdzIGFyZSBub3JtYWxseSBvcnRob2dvbmFsIHRvCiAgICAgICBsYW5ndWFnZSB0YWcg ZmFsbGJhY2suICBJbXBsZW1lbnRhdGlvbnMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdAogICAgICAg dXNlIGEgbG9va3VwIChTZWN0aW9uIDMuMykgbWF0Y2hpbmcgc2NoZW1lIFNIT1VMRCBpZ25vcmUK ICAgICAgIHVucmVjb2duaXplZCBwcml2YXRlLXVzZSBhbmQgZXh0ZW5zaW9uIHN1YnRhZ3Mgd2hl biBwZXJmb3JtaW5nCiAgICAgICBsYW5ndWFnZSB0YWcgZmFsbGJhY2suICBTaW5jZSB0aGVzZSBz dWJ0YWdzIGFyZSBhbHdheXMgYXQgdGhlIGVuZAogICAgICAgb2YgdGhlIHNlcXVlbmNlIG9mIHN1 YnRhZ3MsIHRoZXkgZG9uJ3Qgbm9ybWFsbHkgaW50ZXJmZXJlIHdpdGgKICAgICAgIHRoZSB1c2Ug b2YgcHJlZml4ZXMgZm9yIG1hdGNoaW5nIGluIHRoZSBzY2hlbWVzIGRlc2NyaWJlZCBiZWxvdy4K CiAgIDIuICBBcHBsaWNhdGlvbnMsIHNwZWNpZmljYXRpb25zLCBvciBwcm90b2NvbHMgdGhhdCBj aG9vc2Ugbm90IHRvCiAgICAgICBpbnRlcnByZXQgb25lIG9yIG1vcmUgcHJpdmF0ZS11c2Ugb3Ig ZXh0ZW5zaW9uIHN1YnRhZ3MgU0hPVUxEIE5PVAogICAgICAgcmVtb3ZlIG9yIG1vZGlmeSB0aGVz ZSBleHRlbnNpb25zIGluIGNvbnRlbnQgdGhhdCB0aGV5IGFyZQogICAgICAgcHJvY2Vzc2luZy4g IFdoZW4gYSBsYW5ndWFnZSB0YWcgaW5zdGFuY2UgaXMgdG8gYmUgdXNlZCBpbiBhCiAgICAgICBz cGVjaWZpYywga25vd24gcHJvdG9jb2wsIGFuZCBpcyBub3QgYmVpbmcgcGFzc2VkIHRocm91Z2gg dG8KICAgICAgIG90aGVyIHByb3RvY29scywgbGFuZ3VhZ2UgdGFncyBNQVkgYmUgZmlsdGVyZWQg dG8gcmVtb3ZlIHN1YnRhZ3MKICAgICAgIGFuZCBleHRlbnNpb25zIHRoYXQgYXJlIG5vdCBzdXBw b3J0ZWQgYnkgdGhhdCBwcm90b2NvbC4gIFN1Y2gKICAgICAgIGZpbHRlcmluZyBTSE9VTEQgYmUg YXZvaWRlZCwgaWYgcG9zc2libGUsIHNpbmNlIGl0IHJlbW92ZXMKICAgICAgIGluZm9ybWF0aW9u IHRoYXQgbWlnaHQgYmUgcmVsZXZhbnQgaWYgc2VydmljZXMgb24gdGhlIG90aGVyIGVuZAogICAg ICAgb2YgdGhlIHByb3RvY29sIHdvdWxkIG1ha2UgdXNlIG9mIHRoYXQgaW5mb3JtYXRpb24uCgoK CgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAg ICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1t YXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgMy4gIFNvbWUgYXBwbGlj YXRpb25zIG9mIGxhbmd1YWdlIHRhZ3MgbWlnaHQgd2FudCBvciBuZWVkIHRvIGNvbnNpZGVyCiAg ICAgICBleHRlbnNpb25zIGFuZCBwcml2YXRlLXVzZSBzdWJ0YWdzIHdoZW4gbWF0Y2hpbmcgdGFn cy4gIElmCiAgICAgICBleHRlbnNpb25zIGFuZCBwcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBpbmNs dWRlZCBpbiBhIG1hdGNoaW5nIG9yCiAgICAgICBmaWx0ZXJpbmcgcHJvY2VzcyB0aGF0IHV0aWxp emVzIHRoZSBvbmUgb2YgdGhlIHNjaGVtZXMgZGVzY3JpYmVkCiAgICAgICBpbiB0aGlzIGRvY3Vt ZW50LCB0aGVuIHRoZSBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgY2Fub25pY2FsaXplIHRoZQogICAg ICAgbGFuZ3VhZ2UgdGFncyBhbmQvb3IgcmFuZ2VzIGJlZm9yZSBwZXJmb3JtaW5nIHRoZSBtYXRj aGluZy4gIE5vdGUKICAgICAgIHRoYXQgbGFuZ3VhZ2UgdGFnIHByb2Nlc3NvcnMgdGhhdCBjbGFp bSB0byBiZSAid2VsbC1mb3JtZWQiCiAgICAgICBwcm9jZXNzb3JzIGFzIGRlZmluZWQgaW4gW1JG QzMwNjZiaXNdIGdlbmVyYWxseSBmYWxsIGludG8gdGhpcwogICAgICAgY2F0ZWdvcnkuCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAwNQoKCjMuICBUeXBlcyBvZiBNYXRjaGluZwoKICAgTWF0Y2hpbmcgbGFuZ3Vh Z2UgcmFuZ2VzIHRvIGxhbmd1YWdlIHRhZ3MgY2FuIGJlIGRvbmUgaW4gYSBudW1iZXIgb2YKICAg ZGlmZmVyZW50IHdheXMuICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBkaWZmZXJlbnQgdHlw ZXMgb2YKICAgbWF0Y2hpbmcgc2NoZW1lLCBhcyB3ZWxsIGFzIHRoZSBjb25zaWRlcmF0aW9ucyBm b3IgY2hvb3NpbmcgYmV0d2VlbgogICB0aGVtLiAgUHJvdG9jb2xzIGFuZCBzcGVjaWZpY2F0aW9u cyBTSE9VTEQgY2xlYXJseSBpbmRpY2F0ZSB0aGUKICAgcGFydGljdWxhciBtZWNoYW5pc20gdXNl ZCBpbiBzZWxlY3Rpbmcgb3IgbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncy4KCiAgIFRoZXJlIGFyZSB0 d28gYmFzaWMgdHlwZXMgb2YgbWF0Y2hpbmcgc2NoZW1lOiB0aG9zZSB0aGF0IHByb2R1Y2UgYW4K ICAgb3Blbi1lbmRlZCBzZXQgb2YgY29udGVudCAoY2FsbGVkICJmaWx0ZXJpbmciKSBhbmQgdGhv c2UgdGhhdCBwcm9kdWNlCiAgIGEgc2luZ2xlIGluZm9ybWF0aW9uIGl0ZW0gZm9yIGEgZ2l2ZW4g cmVxdWVzdCAoY2FsbGVkICJsb29rdXAiKS4KCiAgIEEga2V5IGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGVzZSB0d28gdHlwZXMgb2YgbWF0Y2hpbmcgc2NoZW1lIGlzIHRoYXQKICAgdGhlIGxhbmd1YWdl IHJhbmdlIGZvciBmaWx0ZXJpbmcgb3BlcmF0aW9ucyBpcyBhbHdheXMgdGhlIF9sZWFzdF8KICAg c3BlY2lmaWMgdGFnIG9uZSB3aWxsIGFjY2VwdCBhcyBhIG1hdGNoLCB3aGlsZSBmb3IgbG9va3Vw IG9wZXJhdGlvbnMKICAgdGhlIGxhbmd1YWdlIHJhbmdlIGlzIGFsd2F5cyB0aGUgX21vc3RfIHNw ZWNpZmljIHRhZy4KCjMuMS4gIENob29zaW5nIGEgVHlwZSBvZiBNYXRjaGluZwoKICAgQXBwbGlj YXRpb25zLCBwcm90b2NvbHMsIGFuZCBzcGVjaWZpY2F0aW9ucyBhcmUgZmFjZWQgd2l0aCB0aGUK ICAgZGVjaXNpb24gb2Ygd2hhdCB0eXBlIG9mIG1hdGNoaW5nIHRvIHVzZS4gIFNvbWV0aW1lcywg ZGlmZmVyZW50CiAgIHN0eWxlcyBvZiBtYXRjaGluZyBtaWdodCBiZSBzdWl0ZWQgZm9yIGRpZmZl cmVudCBraW5kcyBvZiBwcm9jZXNzaW5nCiAgIHdpdGhpbiBhIHBhcnRpY3VsYXIgYXBwbGljYXRp b24gb3IgcHJvdG9jb2wuCgogICBGaWx0ZXJpbmcgY2FuIGJlIHVzZWQgdG8gcHJvZHVjZSBhIHNl dCBvZiByZXN1bHRzIChzdWNoIGFzIGEKICAgY29sbGVjdGlvbiBvZiBkb2N1bWVudHMpLiAgRm9y IGV4YW1wbGUsIGlmIHVzaW5nIGEgc2VhcmNoIGVuZ2luZSwgb25lCiAgIG1pZ2h0IHVzZSBmaWx0 ZXJpbmcgdG8gbGltaXQgdGhlIHJlc3VsdHMgdG8gZG9jdW1lbnRzIHdyaXR0ZW4gaW4KICAgRnJl bmNoLiAgSXQgY2FuIGFsc28gYmUgdXNlZCB3aGVuIGRlY2lkaW5nIHdoZXRoZXIgdG8gcGVyZm9y bSBzb21lCiAgIHByb2Nlc3NpbmcgdGhhdCBpcyBsYW5ndWFnZSBzZW5zaXRpdmUgb24gc29tZSBj b250ZW50LiAgRm9yIGV4YW1wbGUsCiAgIGEgcHJvY2VzcyBtaWdodCBjYXVzZSBwYXJhZ3JhcGhz IHdob3NlIGxhbmd1YWdlIHRhZyBtYXRjaGVkIHRoZQogICBsYW5ndWFnZSByYW5nZSAibmwiIHRv IGJlIGRpc3BsYXllZCBpbiBpdGFsaWNzIHdpdGhpbiBhIGRvY3VtZW50LgoKICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgdGhyZWUgdHlwZXMgb2YgZmlsdGVyaW5nOgoKICAgMS4gIEJhc2ljIEZp bHRlcmluZyAoU2VjdGlvbiAzLjIuMSkgaXMgdXNlZCB0byBtYXRjaCBjb250ZW50IHVzaW5nCiAg ICAgICBiYXNpYyBsYW5ndWFnZSByYW5nZXMgKFNlY3Rpb24gMi4yKS4gIEl0IGlzIGNvbXBhdGli bGUgd2l0aAogICAgICAgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHByb2R1Y2UgZXh0ZW5k ZWQgbGFuZ3VhZ2UgcmFuZ2VzLgoKICAgMi4gIEV4dGVuZGVkIFJhbmdlIEZpbHRlcmluZyAoU2Vj dGlvbiAzLjIuMikgaXMgdXNlZCB0byBtYXRjaCBjb250ZW50CiAgICAgICB1c2luZyBleHRlbmRl ZCBsYW5ndWFnZSByYW5nZXMgKFNlY3Rpb24gMi4zKS4gIE5ld2VyCiAgICAgICBpbXBsZW1lbnRh dGlvbnMgU0hPVUxEIHVzZSB0aGlzIGZvcm0gb2YgZmlsdGVyaW5nIGluIHByZWZlcmVuY2UKICAg ICAgIHRvIGJhc2ljIGZpbHRlcmluZy4KCiAgIDMuICBTY29yZWQgRmlsdGVyaW5nIChTZWN0aW9u IDMuMi4zKSBwcm9kdWNlcyBhbiBvcmRlcmVkIHNldCBvZgogICAgICAgY29udGVudCB1c2luZyBl aXRoZXIgYmFzaWMgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzLiAgSXQKICAgICAgIFNIT1VM RCBiZSB1c2VkIHdoZW4gdGhlIHF1YWxpdHkgb2YgdGhlIG1hdGNoIHdpdGhpbiBhIHNwZWNpZmlj CiAgICAgICBsYW5ndWFnZSByYW5nZSBpcyBpbXBvcnRhbnQsIGFzIHdoZW4gcHJlc2VudGluZyBh IGxpc3Qgb2YKICAgICAgIGRvY3VtZW50cyByZXN1bHRpbmcgZnJvbSBhIHNlYXJjaC4KCgoKUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAgICAgICAg ICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGlu ZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgTG9va3VwIChTZWN0aW9uIDMuMykg aXMgdXNlZCB3aGVuIGVhY2ggcmVxdWVzdCBNVVNUIHByb2R1Y2UgZXhhY3RseQogICBvbmUgcGll Y2Ugb2YgY29udGVudC4gIEZvciBleGFtcGxlLCBhIFdlYiBzZXJ2ZXIgbWlnaHQgdXNlIHRoZQog ICBBY2NlcHQtTGFuZ3VhZ2UgSFRUUCBoZWFkZXIgdG8gY2hvb3NlIHdoaWNoIGxhbmd1YWdlIHRv IHJldHVybiBhCiAgIGN1c3RvbSA0MDQgcGFnZSBpbjogc2luY2UgaXQgY2FuIHJldHVybiBvbmx5 IG9uZSBwYWdlLCBpdCBtdXN0IGNob29zZQogICBhIHNpbmdsZSBpdGVtIGFuZCBpdCBtdXN0IHJl dHVybiBzb21lIGl0ZW0sIGV2ZW4gaWYgbm8gY29udGVudAogICBtYXRjaGVzIHRoZSBsYW5ndWFn ZSByYW5nZXMgc3VwcGxpZWQgYnkgdGhlIHVzZXIuCgogICBNb3N0IHR5cGVzIG9mIG1hdGNoaW5n IGluIHRoaXMgZG9jdW1lbnQgYXJlIGRlc2lnbmVkIHNvIHRoYXQKICAgaW1wbGVtZW50YXRpb25z IGRvIG5vdCBoYXZlIHRvIGV4YW1pbmUgdGhlIHZhbHVlcyBvZiB0aGUgc3VidGFncwogICBzdXBw bGllZCBhbmQsIGV4Y2VwdCBmb3Igc2NvcmVkIGZpbHRlcmluZywgdGhleSBkbyBub3QgbmVlZCBh Y2Nlc3MgdG8KICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBub3IgZG8gdGhleSByZXF1 aXJlIHRoZSB1c2Ugb2YgdmFsaWQKICAgc3VidGFncyBpbiBlaXRoZXIgbGFuZ3VhZ2UgdGFncyBv ciBsYW5ndWFnZSByYW5nZXMuICBUaGlzIGhhcyBncmVhdAogICBiZW5lZml0IGZvciBzcGVlZCBh bmQgc2ltcGxpY2l0eSBvZiBpbXBsZW1lbnRhdGlvbi4KCiAgIEltcGxlbWVudGF0aW9ucyBtaWdo dCBhbHNvIHdpc2ggdG8gdXNlIHNlbWFudGljIGluZm9ybWF0aW9uIGV4dGVybmFsCiAgIHRvIHRo ZSBsYW5ndWFnZSB0YWdzIHdoZW4gcGVyZm9ybWluZyBmYWxsYmFjay4gIEZvciBleGFtcGxlLCB0 aGUKICAgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzICdubicgKE55bm9yc2sgTm9yd2VnaWFuKSBh bmQgJ25iJyAoQm9rbWFsCiAgIE5vcndlZ2lhbikgbWlnaHQgYm90aCBiZSB1c2VmdWxseSBtYXRj aGVkIHRvIHRoZSBtb3JlIGdlbmVyYWwgc3VidGFnCiAgICdubycgKE5vcndlZ2lhbikuICBPciBh biBpbXBsZW1lbnRhdGlvbiBtaWdodCBpbmZlciB0aGF0IGNvbnRlbnQKICAgbGFiZWxlZCAiemgt Q04iIGlzIG1vcmUgbGlrZWx5IHRvIG1hdGNoIHRoZSByYW5nZSAiemgtSGFucyIgdGhhbgogICBl cXVpdmFsZW50IGNvbnRlbnQgbGFiZWxlZCAiemgtVFciLgoKMy4yLiAgRmlsdGVyaW5nCgogICBG aWx0ZXJpbmcgaXMgdXNlZCB0byBzZWxlY3QgdGhlIHNldCBvZiBjb250ZW50IHRoYXQgbWF0Y2hl cyBhIGdpdmVuCiAgIHByZWZpeC4gIEl0IGlzIGNhbGxlZCAiZmlsdGVyaW5nIiBiZWNhdXNlIHRo aXMgc2V0IG9mIGNvbnRlbnQgbWF5CiAgIGNvbnRhaW4gbm8gaXRlbXMgYXQgYWxsIG9yIGl0IG1h eSByZXR1cm4gYW4gYXJiaXRyYXJ5IG51bWJlciBvZgogICBtYXRjaGluZyBpdGVtcy0tYXMgbWFu eSBhcyBtYXRjaCB0aGUgbGFuZ3VhZ2UgcmFuZ2UgdXNlZCB0byBzcGVjaWZ5CiAgIHRoZSBpdGVt cywgdGh1cyBmaWx0ZXJpbmcgb3V0IHRoZSBub24tbWF0Y2hpbmcgY29udGVudC4KCiAgIEluIGZp bHRlcmluZywgdGhlIGxhbmd1YWdlIHJhbmdlIHJlcHJlc2VudHMgdGhlIF9sZWFzdF8gc3BlY2lm aWMgdGFnCiAgIHdoaWNoIGlzIGFuIGFjY2VwdGFibGUgbWF0Y2guICBUaGF0IGlzLCBhbGwgb2Yg dGhlIGxhbmd1YWdlIHRhZ3MgaW4KICAgdGhlIHNldCBvZiBmaWx0ZXJlZCBjb250ZW50IHdpbGwg aGF2ZSBhbiBlcXVhbCBvciBncmVhdGVyIG51bWJlciBvZgogICBzdWJ0YWdzIHRoYW4gdGhlIGxh bmd1YWdlIHJhbmdlLiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBsYW5ndWFnZSByYW5nZQogICBpcyAi ZGUtQ0giLCBvbmUgbWlnaHQgc2VlIG1hdGNoaW5nIGNvbnRlbnQgd2l0aCB0aGUgdGFnICJkZS1D SC0xOTk2IgogICBidXQgb25lIHdpbGwgbmV2ZXIgc2VlIGEgbWF0Y2ggd2l0aCB0aGUgdGFnICJk ZSIuCgogICBJZiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCAoc2VlIFNlY3Rpb24gMi4xKSBj b250YWlucyBtb3JlIHRoYW4KICAgb25lIHJhbmdlLCB0aGUgY29udGVudCByZXR1cm5lZCBpcyB0 eXBpY2FsbHkgb3JkZXJlZCBpbiBkZXNjZW5kaW5nCiAgIGxldmVsIG9mIHByZWZlcmVuY2UuCgog ICBTb21lIGV4YW1wbGVzIHdoZXJlIGZpbHRlcmluZyBtaWdodCBiZSBhcHByb3ByaWF0ZSBpbmNs dWRlOgoKICAgbyAgQXBwbHlpbmcgYSBzdHlsZSB0byBzZWN0aW9ucyBvZiBhIGRvY3VtZW50IGlu IGEgcGFydGljdWxhcgogICAgICBsYW5ndWFnZSByYW5nZS4KCiAgIG8gIERpc3BsYXlpbmcgdGhl IHNldCBvZiBkb2N1bWVudHMgY29udGFpbmluZyBhIHBhcnRpY3VsYXIgc2V0IG9mCiAgICAgIGtl eXdvcmRzIHdyaXR0ZW4gaW4gYSBzcGVjaWZpYyBsYW5ndWFnZS4KCgoKUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMTBd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDA1CgoKICAgbyAgU2VsZWN0aW5nIGFsbCBlbWFpbCBpdGVtcyB3cml0 dGVuIGluIHNwZWNpZmljIHJhbmdlIG9mIGxhbmd1YWdlcy4KCiAgIEZpbHRlcmluZyBjYW4gcHJv ZHVjZSBlaXRoZXIgYW4gb3JkZXJlZCBvciBhbiB1bm9yZGVyZWQgc2V0IG9mCiAgIHJlc3VsdHMu ICBGb3IgZXhhbXBsZSwgYXBwbHlpbmcgZm9ybWF0dGluZyB0byBhIGRvY3VtZW50IGJhc2VkIG9u IHRoZQogICBsYW5ndWFnZSBvZiBzcGVjaWZpYyBwaWVjZXMgb2YgY29udGVudCBkb2VzIG5vdCBy ZXF1aXJlIHRoZSBjb250ZW50CiAgIHRvIGJlIG9yZGVyZWQuICBJdCBpcyBzdWZmaWNpZW50IHRv IGtub3cgd2hldGhlciBhIHNwZWNpZmljIHBpZWNlIG9mCiAgIGNvbnRlbnQgbWF0Y2hlcyBvciBk b2VzIG5vdCBtYXRjaC4gIEEgc2VhcmNoIGFwcGxpY2F0aW9uLCBvbiB0aGUKICAgb3RoZXIgaGFu ZCwgcHJvYmFibHkgd291bGQgcHV0IHRoZSByZXN1bHRzIGludG8gYSBwcmlvcml0eSBvcmRlci4K CiAgIElmIGFuIG9yZGVyZWQgc2V0IGlzIGRlc2lyZWQsIGFzIGRlc2NyaWJlZCBhYm92ZSwgdGhl biB0aGUKICAgYXBwbGljYXRpb24gb3IgcHJvdG9jb2wgbmVlZHMgdG8gZGV0ZXJtaW5lIHRoZSBy ZWxhdGl2ZSAicXVhbGl0eSIgb2YKICAgdGhlIG1hdGNoIGJldHdlZW4gZGlmZmVyZW50IGxhbmd1 YWdlIHRhZ3MgYW5kIHRoZSBsYW5ndWFnZSByYW5nZS4KCiAgIFRoaXMgbWVhc3VyZW1lbnQgaXMg Y2FsbGVkIGEgImRpc3RhbmNlIG1ldHJpYyIuICBBIGRpc3RhbmNlIG1ldHJpYwogICBhc3NpZ25z IGEgbnVtZXJpYyB2YWx1ZSB0byB0aGUgY29tcGFyaXNvbiBvZiBlYWNoIGxhbmd1YWdlIHRhZyB0 byBhCiAgIGxhbmd1YWdlIHJhbmdlIGFuZCByZXByZXNlbnRzIHRoZSAnZGlzdGFuY2UnIGJldHdl ZW4gdGhlIHR3by4gIEEKICAgZGlzdGFuY2Ugb2YgemVybyBtZWFucyB0aGF0IHRoZXkgYXJlIGlk ZW50aWNhbCwgYSBzbWFsbCBkaXN0YW5jZQogICBpbmRpY2F0ZXMgdGhhdCB0aGV5IGFyZSB2ZXJ5 IHNpbWlsYXIsIGFuZCBhIGxhcmdlIGRpc3RhbmNlIGluZGljYXRlZAogICB0aGF0IHRoZXkgYXJl IHZlcnkgZGlmZmVyZW50LiAgVXNpbmcgYSBkaXN0YW5jZSBtZXRyaWMsCiAgIGltcGxlbWVudGF0 aW9ucyBjYW4sIGZvciBleGFtcGxlLCBhbGxvdyB1c2VycyB0byBzZWxlY3QgYSB0aHJlc2hvbGQK ICAgZGlzdGFuY2UgZm9yIGEgbWF0Y2ggdG8gYmUgInN1Y2Nlc3NmdWwiIHdoaWxlIGZpbHRlcmlu ZyBvciBpdCBjYW4gdXNlCiAgIHRoZSBudW1lcmljIHZhbHVlIHRvIG9yZGVyIHRoZSByZXN1bHRz LgoKMy4yLjEuICBGaWx0ZXJpbmcgd2l0aCBCYXNpYyBMYW5ndWFnZSBSYW5nZXMKCiAgIFdoZW4g ZmlsdGVyaW5nIHVzaW5nIGEgYmFzaWMgbGFuZ3VhZ2UgcmFuZ2UsIHRoZSBsYW5ndWFnZSByYW5n ZQogICBtYXRjaGVzIGEgbGFuZ3VhZ2UgdGFnIGlmIGl0IGV4YWN0bHkgZXF1YWxzIHRoZSB0YWcs IG9yIGlmIGl0IGV4YWN0bHkKICAgZXF1YWxzIGEgcHJlZml4IG9mIHRoZSB0YWcgc3VjaCB0aGF0 IHRoZSBmaXJzdCBjaGFyYWN0ZXIgZm9sbG93aW5nCiAgIHRoZSBwcmVmaXggaXMgIi0iLiAgKFRo YXQgaXMsIHRoZSBsYW5ndWFnZS1yYW5nZSAiZGUtZGUiIG1hdGNoZXMgdGhlCiAgIGxhbmd1YWdl IHRhZyAiZGUtREUtMTk5NiIsIGJ1dCBub3QgdGhlIGxhbmd1YWdlIHRhZyAiZGUtRGV2YSIuKQoK ICAgVGhlIHNwZWNpYWwgcmFuZ2UgIioiIG1hdGNoZXMgYW55IHRhZy4gIEEgcHJvdG9jb2wgd2hp Y2ggdXNlcwogICBsYW5ndWFnZSByYW5nZXMgTUFZIHNwZWNpZnkgYWRkaXRpb25hbCBydWxlcyBh Ym91dCB0aGUgc2VtYW50aWNzIG9mCiAgICIqIjsgZm9yIGluc3RhbmNlLCBIVFRQLzEuMSBzcGVj aWZpZXMgdGhhdCB0aGUgcmFuZ2UgIioiIG1hdGNoZXMgb25seQogICBsYW5ndWFnZXMgbm90IG1h dGNoZWQgYnkgYW55IG90aGVyIHJhbmdlIHdpdGhpbiBhbiAiQWNjZXB0LUxhbmd1YWdlIgogICBo ZWFkZXIuCgozLjIuMi4gIEZpbHRlcmluZyB3aXRoIEV4dGVuZGVkIExhbmd1YWdlIFJhbmdlcwoK ICAgSW4gdGhlIEV4dGVuZGVkIFJhbmdlIE1hdGNoaW5nIHNjaGVtZSwgZWFjaCBleHRlbmRlZCBs YW5ndWFnZSByYW5nZQogICBpbiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCBpcyBjb25zaWRl cmVkIGluIHR1cm4sIGFjY29yZGluZyB0bwogICBwcmlvcml0eS4gIFRoZSBzdWJ0YWdzIGluIGVh Y2ggZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2UgYXJlIGNvbXBhcmVkCiAgIHRvIHRoZSBjb3JyZXNw b25kaW5nIHN1YnRhZ3MgaW4gdGhlIGxhbmd1YWdlIHRhZyBiZWluZyBleGFtaW5lZC4gIFRoZQog ICBzdWJ0YWcgZnJvbSB0aGUgcmFuZ2UgaXMgY29uc2lkZXJlZCB0byBtYXRjaCBpZiBpdCBleGFj dGx5IG1hdGNoZXMKICAgdGhlIGNvcnJlc3BvbmRpbmcgc3VidGFnIGluIHRoZSB0YWcgb3IgdGhl IHJhbmdlJ3Mgc3VidGFnIGhhcyB0aGUKICAgdmFsdWUgIioiICh3aGljaCBtYXRjaGVzIGFsbCBz dWJ0YWdzLCBpbmNsdWRpbmcgdGhlIGVtcHR5IHN1YnRhZykuCiAgIEV4dGVuZGVkIFJhbmdlIE1h dGNoaW5nIGlzIGFuIGV4dGVuc2lvbiBvZiBiYXNpYyBtYXRjaGluZwogICAoU2VjdGlvbiAzLjIu MSk6IHRoZSBsYW5ndWFnZSByYW5nZSByZXByZXNlbnRzIHRoZSBsZWFzdCBzcGVjaWZpYyB0YWcK CgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAg ICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1t YXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgd2hpY2ggaXMgYW4gYWNj ZXB0YWJsZSBtYXRjaC4KCiAgIHByaXZhdGUtdXNlIHN1YnRhZ3MgTUFZIGJlIHNwZWNpZmllZCBp biB0aGUgbGFuZ3VhZ2UgcmFuZ2UgYW5kIE1VU1QKICAgTk9UIGJlIGlnbm9yZWQgd2hlbiBtYXRj aGluZy4KCiAgIFN1YnRhZ3Mgbm90IHNwZWNpZmllZCwgaW5jbHVkaW5nIHRob3NlIGF0IHRoZSBl bmQgb2YgdGhlIGxhbmd1YWdlCiAgIHJhbmdlLCBhcmUgYXNzaWduZWQgdGhlIHZhbHVlICIqIi4g IFRoaXMgbWFrZXMgZWFjaCByYW5nZSBpbnRvIGEKICAgcHJlZml4IG11Y2ggbGlrZSB0aGF0IHVz ZWQgaW4gYmFzaWMgbGFuZ3VhZ2UgcmFuZ2UgbWF0Y2hpbmcuICBGb3IKICAgZXhhbXBsZSwgdGhl IGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlICJkZS0qLURFIiBtYXRjaGVzIGFsbCBvZiB0aGUKICAg Zm9sbG93aW5nIHRhZ3MgYmVjYXVzZSB0aGUgdW5zcGVjaWZpZWQgdmFyaWFudCBmaWVsZCBpcyBl eHBhbmRlZCB0bwogICAiKiI6CgogICAgICBkZS1ERQoKICAgICAgZGUtTGF0bi1ERQoKICAgICAg ZGUtTGF0Zi1ERQoKICAgICAgZGUtREUteC1nb2V0aGUKCiAgICAgIGRlLUxhdG4tREUtMTk5NgoK My4yLjMuICBTY29yZWQgRmlsdGVyaW5nCgogICBCb3RoIGJhc2ljIGFuZCBleHRlbmRlZCBsYW5n dWFnZSByYW5nZSBmaWx0ZXJpbmcgcHJvZHVjZSBzaW1wbGUKICAgYm9vbGVhbiBtYXRjaGVzLiAg U29tZXRpbWVzIGl0IG1heSBiZSBiZW5lZmljaWFsIHRvIHByb3ZpZGUgYW4gYXJyYXkKICAgb2Yg cmVzdWx0cyB3aXRoIGRpZmZlcmVudCBsZXZlbHMgb2YgbWF0Y2hpbmcsIGZvciBleGFtcGxlLCBz b3J0aW5nCiAgIHJlc3VsdHMgYmFzZWQgb24gdGhlIG92ZXJhbGwgInF1YWxpdHkiIG9mIHRoZSBt YXRjaC4gIFNjb3JlZCAob3IKICAgImRpc3RhbmNlIG1ldHJpYyIpIGZpbHRlcmluZyBwcm92aWRl cyBhIHdheSB0byBnZW5lcmF0ZSB0aGVzZSBxdWFsaXR5CiAgIHZhbHVlcy4KCiAgIEZpcnN0IGJv dGggdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGFuZCB0aGUgbGFuZ3VhZ2UgdGFncyB0byBi ZQogICBtYXRjaGVkIHRvIGl0IG11c3QgYmUgY2Fub25pY2FsaXplZCBieSBtYXBwaW5nIGdyYW5k ZmF0aGVyZWQgYW5kCiAgIG9ic29sZXRlIHRhZ3MgaW50byBtb2Rlcm4gZXF1aXZhbGVudHMuCgog ICBUaGUgbGFuZ3VhZ2UgcmFuZ2UgYW5kIHRoZSBsYW5ndWFnZSB0YWdzIGFyZSB0aGVuIHRyYW5z Zm9ybWVkIGludG8KICAgcXVpbnR1cGxlcyBvZiBlbGVtZW50cyBvZiB0aGUgZm9ybSAobGFuZ3Vh Z2UsIHNjcmlwdCwgY291bnRyeSwKICAgdmFyaWFudCwgZXh0ZW5zaW9uKS4gIEFueSBleHRlbmRl ZCBsYW5ndWFnZSBzdWJ0YWdzIGFyZSBjb25zaWRlcmVkCiAgIHBhcnQgb2YgdGhlIGxhbmd1YWdl IGVsZW1lbnQ7IHByaXZhdGUtdXNlIHN1YnRhZyBzZXF1ZW5jZXMgYXJlCiAgIGNvbnNpZGVyZWQg cGFydCBvZiB0aGUgbGFuZ3VhZ2UgZWxlbWVudCBpZiBpbiB0aGUgaW5pdGlhbCBwb3NpdGlvbiBp bgogICB0aGUgdGFnIGFuZCBwYXJ0IG9mIHRoZSB2YXJpYW50IGVsZW1lbnQgaWYgbm90LiAgTGFu Z3VhZ2Ugc3VidGFncwogICAndW5kJywgJ211bCcsIGFuZCB0aGUgc2NyaXB0IHN1YnRhZyAnWnl5 eScgYXJlIGNvbnZlcnRlZCB0byAiKiIuCgogICBNaXNzaW5nIGNvbXBvbmVudHMgaW4gdGhlIGxh bmd1YWdlLXRhZyBhcmUgc2V0IHRvICIqIjsgdGh1cyBhICIqIgogICBwYXR0ZXJuIGJlY29tZXMg dGhlIHF1aW50dXBsZSAoIioiLCAiKiIsICIqIiwgIioiLCAiKiIpLiAgTWlzc2luZwogICBjb21w b25lbnRzIGluIHRoZSBleHRlbmRlZCBsYW5ndWFnZS1yYW5nZSBhcmUgaGFuZGxlZCBzaW1pbGFy bHkgdG8KICAgZXh0ZW5kZWQgcmFuZ2UgbG9va3VwOiBtaXNzaW5nIGludGVybmFsIHN1YnRhZ3Mg YXJlIGV4cGFuZGVkIHRvICIqIi4KICAgTWlzc2luZyBlbmQgc3VidGFncyBhcmUgZXhwYW5kZWQg YXMgdGhlIGVtcHR5IHN0cmluZy4gIFRodXMgYSBwYXR0ZXJuCgoKClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwNQoKCiAgICJlbi1VUyIgYmVjb21lcyB0aGUgcXVpbnR1cGxlICgiZW4i LCIqIiwiVVMiLCIiLCIiKS4KCiAgIEhlcmUgYXJlIHNvbWUgZXhhbXBsZXMgb2YgbGFuZ3VhZ2Ug dGFncywgc2hvd2luZyB0aGVpciBxdWludHVwbGVzIGFzCiAgIGJvdGggbGFuZ3VhZ2UgdGFncyBh bmQgbGFuZ3VhZ2UgcmFuZ2VzOgoKICAgZW4tVVMKICAgICAgVGFnOiAgIChlbiwgKiwgVVMsICos ICopCiAgICAgIFJhbmdlOiAoZW4sICosIFVTLCAiIiwgIiIpCgogICBzci1MYXRuCiAgICAgIFRh ZzogICAoc3IsIExhdG4sICosICosICopCiAgICAgIFJhbmdlOiAoc3IsIExhdG4sICIiLCAiIiwg IiIpCgogICB6aC1jbW4tSGFudAogICAgICBUYWc6ICAgKHpoLWNtbiwgSGFudCwgKiwgKiwgKikK ICAgICAgUmFuZ2U6ICh6aC1jbW4sIEhhbnQsICIiLCAiIiwgIiIpCgogICB4LWZvbwogICAgICBU YWc6ICAgKHgtZm9vLCAqLCAqLCAqLCAqKQogICAgICBSYW5nZTogKHgtZm9vLCAiIiwgIiIsICIi LCAiIikKCiAgIGVuLXgtZm9vCiAgICAgIFRhZzogICAoZW4sICosICosIHgtZm9vLCAqKQogICAg ICBSYW5nZTogKGVuLCAqLCAqLCB4LWZvbywgIiIpCgogICBpLWRlZmF1bHQKICAgICAgVGFnOiAg IChpLWRlZmF1bHQsICosICosICosICopCiAgICAgIFJhbmdlOiAoaS1kZWZhdWx0LCAiIiwgIiIs ICIiLCAiIikKCiAgIHNsLUxhdG4tSVQtcm96YWoKICAgICAgVGFnOiAgIChzbCwgTGF0biwgSVQs IHJvemFqLCAqKQogICAgICBSYW5nZTogKHNsLCBMYXRuLCBJVCwgcm96YWosICIiKQoKICAgemgt ci13YWRlZ2lsZSAoaHlwb3RoZXRpY2FsKQogICAgICBUYWc6ICAgKHouLCAqLCAqLCAqLCByLXdh ZGVnaWxlKQogICAgICBSYW5nZTogKHouLCAqLCAqLCAqLCByLXdhZGVnaWxlKQoKICAgRmlndXJl IDM6IEV4YW1wbGVzIG9mIERpc3RhbmNlIE1ldHJpYyBRdWludHVwbGVzCgogICBFYWNoIGxhbmd1 YWdlLXJhbmdlL2xhbmd1YWdlLXRhZyBwYWlyIGJlaW5nIGNvbXBhcmVkIGlzIGFzc2lnbmVkIGEK ICAgZGlzdGFuY2UgdmFsdWUsIHdoZXJlYnkgc21hbGwgdmFsdWVzIGluZGljYXRlIGJldHRlciBt YXRjaGVzIGFuZAogICBsYXJnZSB2YWx1ZXMgaW5kaWNhdGUgd29yc2Ugb25lcy4gIFRoZSBkaXN0 YW5jZSBiZXR3ZWVuIHRoZSBwYWlyIGlzCiAgIHRoZSBzdW0gb2YgdGhlIGRpc3RhbmNlcyBmb3Ig ZWFjaCBvZiB0aGUgY29ycmVzcG9uZGluZyBlbGVtZW50cyBvZgogICB0aGUgcXVpbnR1cGxlLiAg SWYgdGhlIGVsZW1lbnRzIGFyZSBpZGVudGljYWwgb3Igb25lIGlzICcqJywgdGhlbiB0aGUKICAg ZGlzdGFuY2UgdmFsdWUgYmV0d2VlbiB0aGVtIGlzIHplcm8uICBPdGhlcndpc2UsIGl0IGlzIGdp dmVuIGJ5IHRoZQogICBmb2xsb3dpbmcgdGFibGU6CgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBO b3ZlbWJlciAyMDA1CgoKICAgICAyNTYgICAgbGFuZ3VhZ2UgbWlzbWF0Y2gKICAgICAxMjggICAg c2NyaXB0IG1pc21hdGNoCiAgICAgIDMyICAgIHJlZ2lvbiBtaXNtYXRjaAogICAgICAgNCAgICB2 YXJpYW50IG1pc21hdGNoCiAgICAgICAxICAgIGV4dGVuc2lvbiBtaXNtYXRjaAoKICAgQSB2YWx1 ZSBvZiAwIGlzIGEgcGVyZmVjdCBtYXRjaDsgNDIxIGlzIG5vIG1hdGNoIGF0IGFsbC4gIERpZmZl cmVudAogICB0aHJlc2hvbGQgdmFsdWVzIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGZvciBkaWZmZXJl bnQgYXBwbGljYXRpb25zIG9yCiAgIHByb3RvY29scy4gIEltcGxlbWVudGF0aW9ucyB3aWxsIHVz dWFsbHkgYWxsb3cgdXNlcnMgdG8gY2hvb3NlIHRoZQogICBtb3N0IGFwcHJvcHJpYXRlIHNlbGVj dGlvbiB2YWx1ZSwgcmFua2luZyB0aGUgbWF0Y2hlZCBpdGVtcyBiYXNlZCBvbgogICBzY29yZS4K CiAgIEV4YW1wbGVzIG9mIHZhcmlvdXMgdGFnJ3MgZGlzdGFuY2VzIGZyb20gdGhlIHJhbmdlICJl bi1VUyI6CgogICAiZnItRlIiICAgICAgICAgIDM4NCAobGFuZ3VhZ2UgJiByZWdpb24gbWlzbWF0 Y2gpCiAgICJmciIgICAgICAgICAgICAgMjU2IChsYW5ndWFnZSBtaXNtYXRjaCwgcmVnaW9uIG1h dGNoKQogICAiZW4tR0IiICAgICAgICAgICAzMiAocmVnaW9uIG1pc21hdGNoKQogICAiZW4tTGF0 bi1VUyIgICAgICAgMCAoYWxsIGZpZWxkcyBtYXRjaCkKICAgImVuLUJyYWkiICAgICAgICAgMzIg KHJlZ2lvbiBtaXNtYXRjaCkKICAgImVuLVVTLXgtZm9vIiAgICAgIDQgKHZhcmlhbnQgbWlzbWF0 Y2g6IHJhbmdlIGlzIHRoZSBlbXB0eSBzdHJpbmcpCiAgICJlbi1VUy1yLXdhZGVnaWxlIiAxIChl eHRlbnNpb24gbWlzbWF0Y2g6IHJhbmdlIGlzIHRoZSBlbXB0eSBzdHJpbmcpCgogICBJbXBsZW1l bnRhdGlvbnMgb3IgcHJvdG9jb2xzIHNvbWV0aW1lcyBtaWdodCB3aXNoIHRvIHVzZSBtb3JlCiAg IHNvcGhpc3RpY2F0ZWQgd2VpZ2h0cyB0aGF0IGRlcGVuZCBvbiB0aGUgdmFsdWVzIG9mIHRoZSBj b3JyZXNwb25kaW5nCiAgIGVsZW1lbnRzLiAgRm9yIGV4YW1wbGUsIGRlcGVuZGluZyBvbiB0aGUg ZG9tYWluLCBhbiBpbXBsZW1lbnRhdGlvbgogICBtaWdodCBnaXZlIGEgc21hbGwgZGlzdGFuY2Ug dG8gdGhlIGRpZmZlcmVuY2UgY2xvc2VseSByZWxhdGVkCiAgIHN1YnRhZ3MuICBTb21lIGV4YW1w bGVzIG9mIGNsb3NlbHkgcmVsYXRlZCBzdWJ0YWdzIG1pZ2h0IGJlOgoKICAgTGFuZ3VhZ2U6CiAg ICAgbm8gKE5vcndlZ2lhbikKICAgICBuYiAoQm9rbWFsIE5vcndlZ2lhbikKICAgICBubiAoTnlu b3JzayBOb3J3ZWdpYW4pCgogICBTY3JpcHQ6CiAgICAgS2F0YSAoa2F0YWthbmEpCiAgICAgSGly YSAoaGlyYWdhbmEpCgogICBSZWdpb246CiAgICAgVVMgKFVuaXRlZCBTdGF0ZXMgb2YgQW1lcmlj YSkKICAgICBVTSAoVW5pdGVkIFN0YXRlcyBNaW5vciBPdXRseWluZyBJc2xhbmRzCgogICBGaWd1 cmUgNjogRXhhbXBsZXMgb2YgQ2xvc2VseSBSZWxhdGVkIFN1YnRhZ3MKCjMuMy4gIExvb2t1cAoK ICAgTG9va3VwIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzaW5nbGUgaW5mb3JtYXRpb24gaXRlbSB0 aGF0IGJlc3QKICAgbWF0Y2hlcyB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCBmb3IgYSBnaXZl biByZXF1ZXN0LiAgSW4gbG9va3VwLAogICBlYWNoIGxhbmd1YWdlLXJhbmdlIGluIHRoZSBsYW5n dWFnZSBwcmlvcml0eSBsaXN0IHJlcHJlc2VudHMgdGhlCgoKClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAwNQoKCiAgIF9tb3N0XyBzcGVjaWZpYyB0YWcgd2hpY2ggaXMgYW4gYWNjZXB0 YWJsZSBtYXRjaDsgb25seSB0aGUgY2xvc2VzdAogICBtYXRjaGluZyBpdGVtIGFjY29yZGluZyB0 aGUgdXNlcidzIHByaW9yaXR5IGlzIHJldHVybmVkLiAgRm9yCiAgIGV4YW1wbGUsIGlmIHRoZSBs YW5ndWFnZSByYW5nZSBpcyAiZGUtQ0giLCBvbmUgbWlnaHQgZXhwZWN0IHRvCiAgIHJlY2VpdmUg YW4gaW5mb3JtYXRpb24gaXRlbSB3aXRoIHRoZSB0YWcgImRlIiBidXQgbmV2ZXIgb25lIHdpdGgg dGhlCiAgIHRhZyAiZGUtQ0gtMTk5NiIuICBVc3VhbGx5IGlmIG5vIGNvbnRlbnQgbWF0Y2hlcyB0 aGUgcmVxdWVzdCwgYQogICAiZGVmYXVsdCIgaXRlbSBpcyByZXR1cm5lZC4KCiAgIEZvciBleGFt cGxlLCBpZiBhbiBhcHBsaWNhdGlvbiBpbnNlcnRzIHNvbWUgZHluYW1pYyBjb250ZW50IGludG8g YQogICBkb2N1bWVudCwgcmV0dXJuaW5nIGFuIGVtcHR5IHN0cmluZyBpZiB0aGVyZSBpcyBubyBl eGFjdCBtYXRjaCBpcyBub3QKICAgYW4gb3B0aW9uLiAgSW5zdGVhZCwgdGhlIGFwcGxpY2F0aW9u ICJmYWxscyBiYWNrIiB1bnRpbCBpdCBmaW5kcyBhCiAgIHN1aXRhYmxlIHBpZWNlIG9mIGNvbnRl bnQgdG8gaW5zZXJ0LiAgT3RoZXIgZXhhbXBsZXMgb2YgbG9va3VwIG1pZ2h0CiAgIGluY2x1ZGU6 CgogICBvICBTZWxlY3Rpb24gb2YgYSB0ZW1wbGF0ZSBjb250YWluaW5nIHRoZSB0ZXh0IGZvciBh biBhdXRvbWF0ZWQgZW1haWwKICAgICAgcmVzcG9uc2UuCgogICBvICBTZWxlY3Rpb24gb2YgYSBn cmFwaGljIGNvbnRhaW5pbmcgdGV4dCBmb3IgaW5jbHVzaW9uIGluIGEKICAgICAgcGFydGljdWxh ciBXZWIgcGFnZS4KCiAgIG8gIFNlbGVjdGlvbiBvZiBhIHN0cmluZyBvZiB0ZXh0IGZvciBpbmNs dXNpb24gaW4gYW4gZXJyb3IgbG9nLgoKICAgSW4gdGhlIExvb2t1cCBzY2hlbWUsIHRoZSBsYW5n dWFnZS1yYW5nZSBpcyBwcm9ncmVzc2l2ZWx5IHRydW5jYXRlZAogICBmcm9tIHRoZSBlbmQgdW50 aWwgYSBtYXRjaGluZyBwaWVjZSBvZiBjb250ZW50IGlzIGxvY2F0ZWQuICBGb3IKICAgZXhhbXBs ZSwgc3RhcnRpbmcgd2l0aCB0aGUgcmFuZ2UgInpoLUhhbnQtQ04teC1wcml2YXRlIiwgdGhlIGxv b2t1cAogICB3b3VsZCBwcm9ncmVzc2l2ZWx5IHNlYXJjaCBmb3IgY29udGVudCBhcyBzaG93biBi ZWxvdzoKCiAgIFJhbmdlIHRvIG1hdGNoOiB6aC1IYW50LUNOLXgtcHJpdmF0ZQogICAxLiB6aC1I YW50LUNOLXgtcHJpdmF0ZQogICAyLiB6aC1IYW50LUNOCiAgIDMuIHpoLUhhbnQKICAgNC4gei4K ICAgNS4gKGRlZmF1bHQgY29udGVudCBvciB0aGUgZW1wdHkgdGFnKQoKICAgRmlndXJlIDc6IEV4 YW1wbGUgb2YgYSBMb29rdXAgRmFsbGJhY2sgUGF0dGVybgoKICAgVGhpcyBzY2hlbWUgYWxsb3dz IHNvbWUgZmxleGliaWxpdHkgaW4gZmluZGluZyBjb250ZW50LiAgSXQgYWxzbwogICB0eXBpY2Fs bHkgcHJvdmlkZXMgYmV0dGVyIHJlc3VsdHMgd2hlbiBkYXRhIGlzIG5vdCBhdmFpbGFibGUgYXQg YQogICBzcGVjaWZpYyBsZXZlbCBvZiB0YWcgZ3JhbnVsYXJpdHkgb3IgaXMgc3BhcnNlbHkgcG9w dWxhdGVkICh0aGFuIGlmCiAgIHRoZSBkZWZhdWx0IGxhbmd1YWdlIGZvciB0aGUgc3lzdGVtIG9y IGNvbnRlbnQgd2VyZSB1c2VkKS4KCiAgIFRoZSBsYW5ndWFnZSByYW5nZSAiKiIgbWF0Y2hlcyBh bnkgbGFuZ3VhZ2UgdGFnLiAgSW4gdGhlIGxvb2t1cAogICBzY2hlbWUsIHRoaXMgbGFuZ3VhZ2Ug cmFuZ2UgZG9lcyBub3QgY29udmV5IGVub3VnaCBpbmZvcm1hdGlvbiB0bwogICBkZXRlcm1pbmUg d2hpY2ggY29udGVudCBpcyBtb3N0IGFwcHJvcHJpYXRlLiAgSWYgdGhpcyBsYW5ndWFnZSByYW5n ZQogICBpcyB0aGUgb25seSBvbmUgaW4gdGhlIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QsIGl0IG1h dGNoZXMgdGhlIGRlZmF1bHQKICAgY29udGVudC4gIElmIHRoaXMgbGFuZ3VhZ2UgcmFuZ2UgaXMg Zm9sbG93ZWQgYnkgb3RoZXIgbGFuZ3VhZ2UKICAgcmFuZ2VzLCBpdCBzaG91bGQgYmUgc2tpcHBl ZC4KCiAgIFdoZW4gcGVyZm9ybWluZyBsb29rdXAgdXNpbmcgYSBsYW5ndWFnZSBwcmlvcml0eSBs aXN0LCB0aGUKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAw NiAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgcHJvZ3Jl c3NpdmUgc2VhcmNoIE1VU1QgcHJvY2VlZCB0byBjb25zaWRlciBlYWNoIGxhbmd1YWdlIHJhbmdl CiAgIGJlZm9yZSBmaW5kaW5nIHRoZSBkZWZhdWx0IGNvbnRlbnQgb3IgZW1wdHkgdGFnLiAgVGhl IGRlZmF1bHQgY29udGVudAogICBtaWdodCBiZSBjb250ZW50IHdpdGggbm8gbGFuZ3VhZ2UgdGFn IChvciB3aXRoIGFuIGVtcHR5IHZhbHVlLCBhcwogICB3aXRoIHhtbDpsYW5nIGluIHRoZSBYTUwg c3BlY2lmaWNhdGlvbiksIG9yIGl0IG1pZ2h0IGJlIGEgcGFydGljdWxhcgogICBsYW5ndWFnZSBk ZXNpZ25hdGVkIGZvciB0aGF0IGJpdCBvZiBjb250ZW50LgoKICAgT25lIGNvbW1vbiB3YXkgdG8g cHJvdmlkZSBmb3IgZGVmYXVsdCBjb250ZW50IGlzIHRvIGFsbG93IGEgc3BlY2lmaWMKICAgbGFu Z3VhZ2UgcmFuZ2UgdG8gYmUgc2V0IGFzIHRoZSBkZWZhdWx0IGZvciBhIHNwZWNpZmljIHR5cGUg b2YKICAgcmVxdWVzdC4gIFRoaXMgbGFuZ3VhZ2UgcmFuZ2UgaXMgdGhlbiB0cmVhdGVkIGFzIGlm IGl0IHdlcmUgYXBwZW5kZWQKICAgdG8gdGhlIGVuZCBvZiB0aGUgbGFuZ3VhZ2UgcHJpb3JpdHkg bGlzdCwgcmF0aGVyIHRoYW4gYWZ0ZXIgZWFjaCBpdGVtCiAgIGluIHRoZSBsYW5ndWFnZSBwcmlv cml0eSBsaXN0LgoKICAgRm9yIGV4YW1wbGUsIGlmIGEgcGFydGljdWxhciB1c2VyJ3MgbGFuZ3Vh Z2UgcHJpb3JpdHkgbGlzdCB3ZXJlCiAgICJmci1GUjsgemgtSGFudCIgYW5kIHRoZSBwcm9ncmFt IGRvaW5nIHRoZSBtYXRjaGluZyBoYWQgYSBkZWZhdWx0CiAgIGxhbmd1YWdlIHJhbmdlIG9mICJq YS1KUCIsIHRoZSBwcm9ncmFtIHdvdWxkIHNlYXJjaCBmb3IgY29udGVudCBhcwogICBmb2xsb3dz OgogICAxLiBmci1GUgogICAyLiBmcgogICAzLiB6aC1IYW50IC8vIG5leHQgbGFuZ3VhZ2UKICAg NC4gei4KICAgNS4gKHJldHVybiBkZWZhdWx0IGNvbnRlbnQpCiAgICAgIGEuIGphLUpQCiAgICAg IGIuIGphCiAgICAgIGMuIChlbXB0eSB0YWcgb3Igb3RoZXIgZGVmYXVsdCBjb250ZW50KQoKICAg RmlndXJlIDg6IExvb2t1cCBVc2luZyBhIExhbmd1YWdlIFByaW9yaXR5IExpc3QKCiAgIEluIHNv bWUgY2FzZXMsIHRoZSBsYW5ndWFnZSBwcmlvcml0eSBsaXN0IG1pZ2h0IGNvbnRhaW4gb25lIG9y IG1vcmUKICAgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzIChhcywgZm9yIGV4YW1wbGUsIHdoZW4g dGhlIHNhbWUgbGFuZ3VhZ2UKICAgcHJpb3JpdHkgbGlzdCBpcyB1c2VkIGFzIGlucHV0IGZvciBi b3RoIGxvb2t1cCBhbmQgZmlsdGVyaW5nCiAgIG9wZXJhdGlvbnMpLiAgV2lsZGNhcmQgdmFsdWVz IGluIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIGFyZQogICBzdXBwb3NlZCB0byBtYXRjaCBh bnkgdmFsdWUgdGhhdCBvY2N1cnMgaW4gdGhhdCBwb3NpdGlvbiBpbiBhCiAgIGxhbmd1YWdlIHRh Zy4gIFNpbmNlIG9ubHkgb25lIGl0ZW0gY2FuIGJlIHJldHVybmVkIGZvciBhbnkgZ2l2ZW4KICAg bG9va3VwIHJlcXVlc3QsIHRoZSB3aWxkY2FyZHMgbXVzdCBiZSBwcm9jZXNzZWQgaW4gYSBwcmVk aWN0YWJsZQogICBtYW5uZXIgKG9yIHRoZSBzYW1lIHJlcXVlc3QgbWlnaHQgcHJvZHVjZSB3aWRl bHkgdmFyeWluZyByZXN1bHRzKS4KICAgVGh1cywgZm9yIGVhY2ggcmFuZ2UgaW4gdGhlIGxhbmd1 YWdlIHByaW9yaXR5IGxpc3QsIHRoZSBmb2xsb3dpbmcKICAgcnVsZXMgbXVzdCBiZSBhcHBsaWVk IHRvIHByb2R1Y2UgYSBiYXNpYyBsYW5ndWFnZSByYW5nZSBmb3IgdXNlIGluCiAgIHRoZSBmYWxs YmFjayBtZWNoYW5pc206CgogICAxLiAgSWYgdGhlIGZpcnN0IHN1YnRhZyBpbiB0aGUgZXh0ZW5k ZWQgbGFuZ3VhZ2UgcmFuZ2UgaXMgYSAiKiIgdGhlbgogICAgICAgZW50aXJlIHJhbmdlIGlzIGNv bnZlcnRlZCB0byAiKiIuCgogICAyLiAgRm9yIGVhY2ggc3Vic2VxdWVudCBzdWJ0YWcsIGlmIHRo ZSB2YWx1ZSBpcyBhICIqIiB0aGVuIHRoYXQKICAgICAgIHN1YnRhZyBhbmQgaXRzIHByZWNlZGlu ZyBoeXBoZW4gYXJlIHJlbW92ZWQuCgogICBGb3IgZXhhbXBsZToKCgoKCgpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAx Nl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDUKCgogICAqLVVTICAgICAgYmVjb21lcyAgKgogICBlbi0qLVVT ICAgYmVjb21lcyAgZW4tVVMKICAgZW4tTGF0bi0qIGJlY29tZXMgIGVuLUxhdG4KCiAgIEZpZ3Vy ZSA5OiBUcmFuc2Zvcm1hdGlvbiBvZiBFeHRlbmRlZCBMYW5ndWFnZSBSYW5nZXMKCiAgIEZvciB0 aGUgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdCAiKi1VUzsgZnItKi1GUjsgemgtSGFudCIsIHRoZSBm YWxsYmFjawogICBwYXR0ZXJuIHdvdWxkIGJlOgogICAxLiAqIChza2lwcGVkKQogICAyLiBmci1G UgogICAzLiBmcgogICA0LiB6aC1IYW50CiAgIDUuIHouCiAgIDYuIChkZWZhdWx0IGNvbnRlbnQp CgogICBGaWd1cmUgMTA6IEV4dGVuZGVkIExhbmd1YWdlIFJhbmdlIEZhbGxiYWNrIEV4YW1wbGUK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAg ICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5v dmVtYmVyIDIwMDUKCgo0LiAgT3RoZXIgQ29uc2lkZXJhdGlvbnMKCiAgIFdoZW4gd29ya2luZyB3 aXRoIGxhbmd1YWdlIHJhbmdlcyBhbmQgbWF0Y2hpbmcgc2NoZW1lcywgdGhlcmUgYXJlCiAgIHNv bWUgYWRkaXRpb25hbCBwb2ludHMgdGhhdCBtYXkgaW5mbHVlbmNlIHRoZSBjaG9pY2Ugb2YgZWl0 aGVyLgoKNC4xLiAgTWVhbmluZyBvZiBMYW5ndWFnZSBUYWdzIGFuZCBSYW5nZXMKCiAgIFNlbGVj dGluZyBjb250ZW50IHVzaW5nIGxhbmd1YWdlIHJhbmdlcyByZXF1aXJlcyBzb21lIHVuZGVyc3Rh bmRpbmcKICAgYnkgdXNlcnMgb2Ygd2hhdCB0aGV5IGFyZSBzZWxlY3RpbmcuICBBIGxhbmd1YWdl IHRhZyBvciByYW5nZQogICBpZGVudGlmaWVzIGEgbGFuZ3VhZ2UgYXMgc3Bva2VuIChvciB3cml0 dGVuLCBzaWduZWQgb3Igb3RoZXJ3aXNlCiAgIHNpZ25hbGVkKSBieSBodW1hbiBiZWluZ3MgZm9y IGNvbW11bmljYXRpb24gb2YgaW5mb3JtYXRpb24gdG8gb3RoZXIKICAgaHVtYW4gYmVpbmdzLgoK ICAgSWYgYSBsYW5ndWFnZSB0YWcgQiBjb250YWlucyBsYW5ndWFnZSB0YWcgQSBhcyBhIHByZWZp eCwgdGhlbiBCIGlzCiAgIHR5cGljYWxseSAibmFycm93ZXIiIG9yICJtb3JlIHNwZWNpZmljIiB0 aGFuIEEuIEZvciBleGFtcGxlLCAiemgtCiAgIEhhbnQtVFciIGlzIG1vcmUgc3BlY2lmaWMgdGhh biAiemgtSGFudCIuCgogICBUaGlzIHJlbGF0aW9uc2hpcCBpcyBub3QgZ3VhcmFudGVlZCBpbiBh bGwgY2FzZXM6IHNwZWNpZmljYWxseSwKICAgbGFuZ3VhZ2VzIHRoYXQgYmVnaW4gd2l0aCB0aGUg c2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QKICAgZ3VhcmFudGVlZCB0byBiZSBtdXR1 YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdoIHRoZXkgbWlnaHQgYmUuCgogICBGb3IgZXhhbXBs ZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3aXRoIGJvdGggImF6LUxhdG4iCiAgIChB emVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpIGFuZCAiYXotQXJhYiIK ICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIEFyYWJpYyBzY3JpcHQpLiAgQSBwZXJz b24gZmx1ZW50IGluCiAgIG9uZSBzY3JpcHQgbWlnaHQgbm90IGJlIGFibGUgdG8gcmVhZCB0aGUg b3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0CiAgIG1pZ2h0IGJlIG90aGVyd2lzZSBpZGVudGlj YWwuICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFibHkKICAgaXMgd3JpdHRlbiBp biBqdXN0IG9uZSBzY3JpcHQgYW5kIHRodXMgbWlnaHQgbm90IGJlIGludGVsbGlnaWJsZSB0byBh CiAgIHJlYWRlciBmYW1pbGlhciB3aXRoIHRoZSBvdGhlciBzY3JpcHQuCgogICBWYXJpYW50IHN1 YnRhZ3MgaW4gcGFydGljdWxhciBzZWVtIHRvIHJlcHJlc2VudCBzcGVjaWZpYyBkaXZpc2lvbnMg aW4KICAgbXV0dWFsIHVuZGVyc3RhbmRpbmcsIHNpbmNlIHRoZXkgb2Z0ZW4gZW5jb2RlIGRpYWxl Y3RzIG9yIG90aGVyCiAgIGlkaW9zeW5jcmF0aWMgdmFyaWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFn ZS4KCiAgIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUg aW5mb3JtYXRpb24gaXQKICAgcmVsYXRlcyB0byBpcyBkZWZpbmVkIGJ5IHRoZSBzdGFuZGFyZCBk ZXNjcmliaW5nIHRoZSBjb250ZXh0IGluIHdoaWNoCiAgIGl0IGFwcGVhcnMuICBBY2NvcmRpbmds eSwgdGhpcyBzZWN0aW9uIGNhbiBvbmx5IGdpdmUgcG9zc2libGUKICAgZXhhbXBsZXMgb2YgaXRz IHVzYWdlOgoKICAgbyAgRm9yIGEgc2luZ2xlIGluZm9ybWF0aW9uIG9iamVjdCwgdGhlIGFzc29j aWF0ZWQgbGFuZ3VhZ2UgdGFncwogICAgICBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0 IG9mIGxhbmd1YWdlcyB0aGF0IGFyZSBuZWNlc3NhcnkKICAgICAgZm9yIGEgY29tcGxldGUgY29t cHJlaGVuc2lvbiBvZiB0aGUgY29tcGxldGUgb2JqZWN0LiAgRXhhbXBsZToKICAgICAgUGxhaW4g dGV4dCBkb2N1bWVudHMuCgogICBvICBGb3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24g b2JqZWN0cywgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UKICAgICAgdGFncyBjb3VsZCBiZSB0YWtl biBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB1c2VkIGluc2lkZSBjb21wb25lbnRzCiAgICAgIG9m IHRoYXQgYWdncmVnYXRpb24uICBFeGFtcGxlczogRG9jdW1lbnQgc3RvcmVzIGFuZCBsaWJyYXJp ZXMuCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAg ICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg bHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKICAgbyAgRm9yIGlu Zm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFsdGVybmF0aXZl cywKICAgICAgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UgdGFncyBjb3VsZCBiZSByZWdhcmRlZCBh cyBhIGhpbnQgdGhhdCB0aGUKICAgICAgY29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFsIGxh bmd1YWdlcywgYW5kIHRoYXQgb25lIGhhcyB0bwogICAgICBpbnNwZWN0IGVhY2ggb2YgdGhlIGFs dGVybmF0aXZlcyBpbiBvcmRlciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcgogICAgICBsYW5ndWFn ZXMuICBJbiB0aGlzIGNhc2UsIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSB0YWdzIG1pZ2h0IG5v dAogICAgICBtZWFuIHRoYXQgb25lIG5lZWRzIHRvIGJlIG11bHRpLWxpbmd1YWwgdG8gZ2V0IGNv bXBsZXRlCiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50LiAgRXhhbXBsZTogTUlN RSBtdWx0aXBhcnQvCiAgICAgIGFsdGVybmF0aXZlLgoKICAgbyAgSW4gbWFya3VwIGxhbmd1YWdl cywgc3VjaCBhcyBIVE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9ybWF0aW9uCiAgICAgIGNhbiBi ZSBhZGRlZCB0byBlYWNoIHBhcnQgb2YgdGhlIGRvY3VtZW50IGlkZW50aWZpZWQgYnkgdGhlIG1h cmt1cAogICAgICBzdHJ1Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hvbGUgZG9jdW1lbnQgaXRzZWxm KS4gIEZvciBleGFtcGxlLCBvbmUKICAgICAgY291bGQgd3JpdGUgPHNwYW4gbGFuZz0iRlIiPkMn ZXN0IGxhIHZpZS48L3NwYW4+IGluc2lkZSBhCiAgICAgIE5vcndlZ2lhbiBkb2N1bWVudDsgdGhl IE5vcndlZ2lhbi1zcGVha2luZyB1c2VyIGNvdWxkIHRoZW4gYWNjZXNzCiAgICAgIGEgRnJlbmNo LU5vcndlZ2lhbiBkaWN0aW9uYXJ5IHRvIGZpbmQgb3V0IHdoYXQgdGhlIG1hcmtlZCBzZWN0aW9u CiAgICAgIG1lYW50LiAgSWYgdGhlIHVzZXIgd2VyZSBsaXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVu dCB0aHJvdWdoIGEKICAgICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRlcmZhY2UsIHRoaXMgZm9ybWF0 aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsCiAgICAgIHRoZSBzeW50aGVzaXplciB0byBhcHBy b3ByaWF0ZWx5IGFwcGx5IEZyZW5jaCB0ZXh0LXRvLXNwZWVjaAogICAgICBwcm9udW5jaWF0aW9u IHJ1bGVzIHRvIHRoYXQgc3BhbiBvZiB0ZXh0LCBpbnN0ZWFkIG9mIG1pc2FwcGx5aW5nCiAgICAg IHRoZSBOb3J3ZWdpYW4gcnVsZXMuCgo0LjIuICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBV c2UgU3VidGFncwoKICAgUHJpdmF0ZS11c2Ugc3VidGFncyByZXF1aXJlIHByaXZhdGUgYWdyZWVt ZW50IGJldHdlZW4gdGhlIHBhcnRpZXMKICAgdGhhdCBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdl IGxhbmd1YWdlIHRhZ3MgdGhhdCB1c2UgdGhlbSBhbmQgZ3JlYXQKICAgY2F1dGlvbiBTSE9VTEQg YmUgdXNlZCBpbiBlbXBsb3lpbmcgdGhlbSBpbiBjb250ZW50IG9yIHByb3RvY29scwogICBpbnRl bmRlZCBmb3IgZ2VuZXJhbCB1c2UuICBQcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBzaW1wbHkgdXNl bGVzcyBmb3IKICAgaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aG91dCBwcmlvciBhcnJhbmdlbWVu dC4KCiAgIFRoZSB2YWx1ZSBhbmQgc2VtYW50aWMgbWVhbmluZyBvZiBwcml2YXRlLXVzZSB0YWdz IGFuZCBvZiB0aGUgc3VidGFncwogICB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFy ZSBub3QgZGVmaW5lZC4gIE1hdGNoaW5nIHByaXZhdGUtCiAgIHVzZSB0YWdzIHVzaW5nIGxhbmd1 YWdlIHJhbmdlcyBvciBleHRlbmRlZCBsYW5ndWFnZSByYW5nZXMgY2FuIHJlc3VsdAogICBpbiB1 bnByZWRpY3RhYmxlIGNvbnRlbnQgYmVpbmcgcmV0dXJuZWQuCgo0LjMuICBMZW5ndGggQ29uc2lk ZXJhdGlvbnMgaW4gTWF0Y2hpbmcKCiAgIFJGQyAzMDY2IFtSRkMzMDY2XSBkaWQgbm90IHByb3Zp ZGUgYW4gdXBwZXIgbGltaXQgb24gdGhlIHNpemUgb2YKICAgbGFuZ3VhZ2UgdGFncyBvciByYW5n ZXMuICBSRkMgMzA2NiBkaWQgZGVmaW5lIHRoZSBzZW1hbnRpY3Mgb2YKICAgcGFydGljdWxhciBz dWJ0YWdzIGluIHN1Y2ggYSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRhZ3Mgb3IgcmFuZ2VzCiAg IGNvbnNpc3RlZCBvZiBsYW5ndWFnZSBhbmQgcmVnaW9uIHN1YnRhZ3Mgd2l0aCBhIGNvbWJpbmVk IHRvdGFsIGxlbmd0aAogICBvZiB1cCB0byBzaXggY2hhcmFjdGVycy4gIExhcmdlciB0YWdzIGFu ZCByYW5nZXMgKGluIHRlcm1zIG9mIGJvdGgKICAgc3VidGFncyBhbmQgY2hhcmFjdGVycykgZGlk IGV4aXN0LCBob3dldmVyLgoKICAgW1JGQzMwNjZiaXNdIGFsc28gZG9lcyBub3QgaW1wb3NlIGEg Zml4ZWQgdXBwZXIgbGltaXQgb24gdGhlIG51bWJlcgogICBvZiBzdWJ0YWdzIGluIGEgbGFuZ3Vh Z2UgdGFnIG9yIHJhbmdlIChhbmQgdGh1cyBhbiB1cHBlciBib3VuZCBvbiB0aGUKICAgc2l6ZSBv ZiBlaXRoZXIpLiAgVGhlIHN5bnRheCBpbiB0aGF0IGRvY3VtZW50IHN1Z2dlc3RzIHRoYXQsCiAg IGRlcGVuZGluZyBvbiB0aGUgc3BlY2lmaWMgbGFuZ3VhZ2Ugb3IgcmFuZ2Ugb2YgbGFuZ3VhZ2Vz LCBtb3JlCiAgIHN1YnRhZ3MgKGFuZCB0aHVzIGNoYXJhY3RlcnMpIGFyZSBzb21ldGltZXMgbmVj ZXNzYXJ5IGFzIGEgcmVzdWx0LgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMg TWF5IDIyLCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUK CgogICBMZW5ndGggY29uc2lkZXJhdGlvbnMgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgc2VsZWN0 aW9uIGFuZAogICBwcm9jZXNzaW5nIG9mIHRhZ3MgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIu MS4xIG9mIHRoYXQgZG9jdW1lbnQuCgogICBBbiBhcHBsaWNhdGlvbiBvciBwcm90b2NvbCBNQVkg Y2hvb3NlIHRvIGxpbWl0IHRoZSBsZW5ndGggb2YgdGhlCiAgIGxhbmd1YWdlIHRhZ3Mgb3IgcmFu Z2VzIHVzZWQgaW4gbWF0Y2hpbmcuICBBbnkgc3VjaCBsaW1pdGF0aW9uIFNIT1VMRAogICBiZSBj bGVhcmx5IGRvY3VtZW50ZWQsIGFuZCBzdWNoIGRvY3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUg dGhlCiAgIGRpc3Bvc2l0aW9uIG9mIGFueSBsb25nZXIgdGFncyBvciByYW5nZXMgKGZvciBleGFt cGxlLCB3aGV0aGVyIGFuCiAgIGVycm9yIHZhbHVlIGlzIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3Vh Z2UgdGFnIG9yIHJhbmdlIGlzIHRydW5jYXRlZCkuCiAgIElmIHRydW5jYXRpb24gaXMgcGVybWl0 dGVkIGl0IE1VU1QgTk9UIHBlcm1pdCBhIHN1YnRhZyB0byBiZSBkaXZpZGVkLAogICBzaW5jZSB0 aGlzIGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgc3VidGFnIGJlaW5nIG1hdGNoZWQgYW5k IGNhbgogICByZXN1bHQgaW4gZmFsc2UgcG9zaXRpdmVzIG9yIG5lZ2F0aXZlcy4KCiAgIEFwcGxp Y2F0aW9ucyBvciBwcm90b2NvbHMgdGhhdCByZXN0cmljdCBzdG9yYWdlIFNIT1VMRCBjb25zaWRl ciB0aGUKICAgaW1wYWN0IG9mIHRhZyBvciByYW5nZSB0cnVuY2F0aW9uIG9uIHRoZSByZXN1bHRp bmcgbWF0Y2hlcy4gIEZvcgogICBleGFtcGxlLCByZW1vdmluZyB0aGUgIioiIGZyb20gdGhlIGVu ZCBvZiBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5nZQogICAoc2VlIFNlY3Rpb24gMi4zKSBjYW4g Z3JlYXRseSBtb2RpZnkgdGhlIHNldCBvZiByZXR1cm5lZCBtYXRjaGVzLiAgQQogICBwcm90b2Nv bCB0aGF0IGFsbG93cyB0YWdzIG9yIHJhbmdlcyB0byBiZSB0cnVuY2F0ZWQgYXQgYW4gYXJiaXRy YXJ5CiAgIGxpbWl0LCB3aXRob3V0IGdpdmluZyBhbnkgaW5kaWNhdGlvbiBvZiB3aGF0IHRoYXQg bGltaXQgaXMsIGhhcyB0aGUKICAgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm0gYnkgY2hhbmdp bmcgdGhlIG1lYW5pbmcgb2YgdmFsdWVzIGluCiAgIHN1YnN0YW50aWFsIHdheXMuCgogICBJbiBw cmFjdGljZSwgbW9zdCB0YWdzIGRvIG5vdCByZXF1aXJlIGFkZGl0aW9uYWwgc3VidGFncyBvcgog ICBzdWJzdGFudGlhbGx5IG1vcmUgY2hhcmFjdGVycy4gIEFkZGl0aW9uYWwgc3VidGFncyBzb21l dGltZXMgYWRkCiAgIHVzZWZ1bCBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiwgYnV0IGV4dHJh bmVvdXMgc3VidGFncyBpbnRlcmZlcmUKICAgd2l0aCB0aGUgbWVhbmluZywgdW5kZXJzdGFuZGlu ZywgYW5kIGVzcGVjaWFsbHkgbWF0Y2hpbmcgb2YgbGFuZ3VhZ2UKICAgdGFncy4gIFNpbmNlIGxh bmd1YWdlIHRhZ3Mgb3IgcmFuZ2VzIE1BWSBiZSB0cnVuY2F0ZWQgYnkgYW4KICAgYXBwbGljYXRp b24gb3IgcHJvdG9jb2wgdGhhdCBsaW1pdHMgc3RvcmFnZSwgd2hlbiBjaG9vc2luZyBsYW5ndWFn ZQogICB0YWdzIG9yIHJhbmdlcyB1c2VycyBhbmQgYXBwbGljYXRpb25zIFNIT1VMRCBhdm9pZCBh ZGRpbmcgc3VidGFncwogICB0aGF0IGFkZCBubyBkaXN0aW5ndWlzaGluZyB2YWx1ZS4gIEluIHBh cnRpY3VsYXIsIHVzZXJzIGFuZAogICBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0aGUg J1ByZWZpeCcgYW5kICdTdXBwcmVzcy1TY3JpcHQnCiAgIGZpZWxkcyBpbiB0aGUgcmVnaXN0cnkg KGRlZmluZWQgaW4gU2VjdGlvbiAzLjYgb2YgW1JGQzMwNjZiaXNdKToKICAgdGhlc2UgZmllbGRz IHByb3ZpZGUgZ3VpZGFuY2Ugb24gd2hlbiBzcGVjaWZpYyBhZGRpdGlvbmFsIHN1YnRhZ3MKICAg U0hPVUxEIChhbmQgU0hPVUxEIE5PVCkgYmUgdXNlZC4KCiAgIEltcGxlbWVudGF0aW9ucyBNVVNU IHN1cHBvcnQgYSBsaW1pdCBvZiBhdCBsZWFzdCAzMyBjaGFyYWN0ZXJzLiAgVGhpcwogICBsaW1p dCBpbmNsdWRlcyBhdCBsZWFzdCBvbmUgc3VidGFnIG9mIGVhY2ggbm9uLWV4dGVuc2lvbiwgbm9u LXByaXZhdGUKICAgdXNlIHR5cGUuICBXaGVuIGNob29zaW5nIGEgYnVmZmVyIGxpbWl0LCBhIGxl bmd0aCBvZiBhdCBsZWFzdCA0MgogICBjaGFyYWN0ZXJzIGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVE LgoKICAgVGhlIHByYWN0aWNhbCBsaW1pdCBvbiB0YWdzIG9yIHJhbmdlcyBkZXJpdmVkIHNvbGVs eSBmcm9tIHJlZ2lzdGVyZWQKICAgdmFsdWVzIGlzIDQyIGNoYXJhY3RlcnMuICBJbXBsZW1lbnRh dGlvbnMgTVVTVCBiZSBhYmxlIHRvIGhhbmRsZSB0YWdzCiAgIGFuZCByYW5nZXMgb2YgdGhpcyBs ZW5ndGguICBTdXBwb3J0IGZvciB0YWdzIGFuZCByYW5nZXMgb2YgYXQgbGVhc3QKICAgNjIgY2hh cmFjdGVycyBpbiBsZW5ndGggaXMgUkVDT01NRU5ERUQuICBJbXBsZW1lbnRhdGlvbnMgTUFZIHN1 cHBvcnQKICAgbG9uZ2VyIHZhbHVlcywgaW5jbHVkaW5nIG1hdGNoaW5nIGV4dGVuc2l2ZSBzZXRz IG9mIHByaXZhdGUtdXNlIG9yCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLgoKICAgQXBwbGljYXRpb25z IG9yIHByb3RvY29scyB3aGljaCBoYXZlIHRvIHRydW5jYXRlIGEgdGFnIE1VU1QgZG8gc28gYnkK ICAgcHJvZ3Jlc3NpdmVseSByZW1vdmluZyBzdWJ0YWdzIGFsb25nIHdpdGggdGhlaXIgcHJlY2Vk aW5nICItIiBmcm9tCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjIs IDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCiAgIHRo ZSByaWdodCBzaWRlIG9mIHRoZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBpcyBzaG9ydCBl bm91Z2ggZm9yCiAgIHRoZSBnaXZlbiBidWZmZXIuICBJZiB0aGUgcmVzdWx0aW5nIHRhZyBlbmRz IHdpdGggYSBzaW5nbGUtY2hhcmFjdGVyCiAgIHN1YnRhZywgdGhhdCBzdWJ0YWcgYW5kIGl0cyBw cmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZSByZW1vdmVkLiAgRm9yCiAgIGV4YW1wbGU6CgogICBU YWcgdG8gdHJ1bmNhdGU6IHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxLXgtd2FkZWdpbGUt cHJpdmF0ZTEKICAgMS4gemgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDEteC13YWRlZ2lsZQog ICAyLiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMQogICAzLiB6aC1MYXRuLUNOLXZhcmlh bnQxCiAgIDQuIHpoLUxhdG4tQ04KICAgNS4gemgtTGF0bgogICA2LiB6LgoKICAgRmlndXJlIDEx OiBFeGFtcGxlIG9mIFRhZyBUcnVuY2F0aW9uCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAg ICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBs dHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgo1LiAgSUFOQSBDb25z aWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBubyBuZXcgb3IgZXhpc3Rpbmcg Y29uc2lkZXJhdGlvbnMgZm9yIElBTkEuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjIs IDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgIGx0cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCjYuICBD aGFuZ2VzCgogICBUaGlzIGlzIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQuCgog ICBUaGUgZm9sbG93aW5nIGNoYW5nZXMgd2VyZSBwdXQgaW50byB0aGlzIGRvY3VtZW50IHNpbmNl IGRyYWZ0LTA2OgoKICAgICAgQ2hhbmdlZCB0aGUgZG9jdW1lbnQgdGl0bGUgZnJvbSB0aGUgdW53 aWVsZHkgIk1hdGNoaW5nIFRhZ3MgZm9yCiAgICAgIHRoZSBJZGVudGlmaWNhdGlvbiBvZiBMYW5n dWFnZXMiIHRvICJNYXRjaGluZyBMYW5ndWFnZSBUYWdzIiAoRWQuKQoKICAgICAgRml4ZWQgcHJv YmxlbXMgd2l0aCB0aGUgZGlzdGFuY2UgbWV0cmljIGZpbHRlcmluZyBzY2hlbWUKICAgICAgKFNl Y3Rpb24gMy4yLjMpIGV4YW1wbGVzIChpbiB3aGljaCB0YWdzIHdlcmUgZXhwYW5kZWQKICAgICAg aW5jb3JyZWN0bHkpLiAgKEQuRXdlbGwpCgogICAgICBNb3ZlZCB0aGUgc2VudGVuY2UgIlByb3Rv Y29scyBhbmQgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGNsZWFybHkKICAgICAgaW5kaWNhdGUgdGhl IHBhcnRpY3VsYXIgbWVjaGFuaXNtIHVzZWQgaW4gc2VsZWN0aW5nIG9yIG1hdGNoaW5nCiAgICAg IGxhbmd1YWdlIHRhZ3MuIiBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24gKHdoZXJlIHRoZXJlIHNob3Vs ZCBub3QgYmUKICAgICAgYW55IG5vcm1hdGl2ZSBsYW5ndWFnZSkgdG8gdGhlIHN0YXJ0IG9mIFNl Y3Rpb24gMy4gIChBLlBoaWxsaXBzKQoKICAgICAgQ3JlYXRlZCBzZWN0aW9uIFNlY3Rpb24gMi40 IGFuZCBtb3ZlZCB0ZXh0IHRoZXJlIChBLlBoaWxsaXBzKQoKICAgICAgTW9kaWZpZWQgdGhlIGV4 YW1wbGVzIG9mIGNsb3NlbHkgcmVsYXRlZCBzdWJ0YWdzIGluIFNlY3Rpb24gMy4yLjMKICAgICAg dG8gc2hvdyB3aGF0IHRoZSBleGFtcGxlcyBtZWFuIChNLkR1ZXJzdCkKCiAgICAgIFZhcmlvdXMg c3BlbGxpbmcgYW5kIGdyYW1tYXRpY2FsIGZpeGVzIChELkV3ZWxsKQoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2 ICAgICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICBsdHJ1LW1hdGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgo3LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMKCiAgIExhbmd1YWdlIHJhbmdlcyB1c2VkIGluIGNvbnRlbnQgbmVn b3RpYXRpb24gbWlnaHQgYmUgdXNlZCB0byBpbmZlcgogICB0aGUgbmF0aW9uYWxpdHkgb2YgdGhl IHNlbmRlciwgYW5kIHRodXMgaWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMKICAgZm9yIHN1cnZl aWxsYW5jZS4gIEluIGFkZGl0aW9uLCB1bmlxdWUgb3IgaGlnaGx5IHVudXN1YWwgbGFuZ3VhZ2UK ICAgcmFuZ2VzIG9yIGNvbWJpbmF0aW9ucyBvZiBsYW5ndWFnZSByYW5nZXMgbWlnaHQgYmUgdXNl ZCB0byB0cmFjayBhCiAgIHNwZWNpZmljIGluZGl2aWR1YWwncyBhY3Rpdml0aWVzLgoKICAgVGhp cyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcg eW91IHNlbmQKICAgaXMgdmlzaWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5LiAgSXQgaXMgdXNl ZnVsIHRvIGJlIGF3YXJlIHRoYXQKICAgc3VjaCBjb25jZXJucyBjYW4gZXhpc3QgaW4gc29tZSBj YXNlcy4KCiAgIFRoZSBldmFsdWF0aW9uIG9mIHRoZSBleGFjdCBtYWduaXR1ZGUgb2YgdGhlIHRo cmVhdCwgYW5kIGFueSBwb3NzaWJsZQogICBjb3VudGVybWVhc3VyZXMsIGlzIGxlZnQgdG8gZWFj aCBhcHBsaWNhdGlvbiBvciBwcm90b2NvbC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMDYgICAg ICAgICAgICAgICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGx0 cnUtbWF0Y2hpbmcgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNQoKCjguICBDaGFyYWN0ZXIg U2V0IENvbnNpZGVyYXRpb25zCgogICBUaGUgc3ludGF4IG9mIGxhbmd1YWdlIHRhZ3MgYW5kIGxh bmd1YWdlIHJhbmdlcyBwZXJtaXQgb25seSB0aGUKICAgY2hhcmFjdGVycyBBLVosIGEteiwgMC05 LCBhbmQgSFlQSEVOLU1JTlVTICgleDJEKS4gIFRoZXNlIGNoYXJhY3RlcnMKICAgYXJlIHByZXNl bnQgaW4gbW9zdCBjaGFyYWN0ZXIgc2V0cywgc28gcHJlc2VudGF0aW9uIG9mIGxhbmd1YWdlIHRh Z3MKICAgc2hvdWxkIG5vdCBwcmVzZW50IGFueSBjaGFyYWN0ZXIgc2V0IGlzc3Vlcy4KCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMjVdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA1CgoKOS4gIFJlZmVyZW5jZXMKCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwg UkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlz LCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwKICAgICAgICAgICAgICBNYXNpbnRlciwgTC4s IExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0CiAgICAgICAgICAgICAg VHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEiLCBSRkMgMjYxNiwgSnVuZSAxOTk5LgoKICAg W1JGQzMwNjZiaXNdCiAgICAgICAgICAgICAgUGhpbGxpcHMsIEEuLCBFZC4gYW5kIE0uIERhdmlz LCBFZC4sICJUYWdzIGZvciB0aGUKICAgICAgICAgICAgICBJZGVudGlmaWNhdGlvbiBvZiBMYW5n dWFnZXMiLCBPY3RvYmVyIDIwMDUsIDxodHRwOi8vCiAgICAgICAgICAgICAgd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkt MTQudHh0Pi4KCiAgIFtSRkM0MjM0XSAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdt ZW50ZWQgQk5GIGZvciBTeW50YXgKICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIs IFJGQyA0MjM0LCBPY3RvYmVyIDIwMDUuCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgog ICBbUkZDMTc2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9u IG9mCiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgUkZDIDE3NjYsIE1hcmNoIDE5OTUuCgogICBb UkZDMzA2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9m CiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgQkNQIDQ3LCBSRkMgMzA2NiwgSmFudWFyeSAyMDAx LgoKICAgW1JGQzMyODJdICBBbHZlc3RyYW5kLCBILiwgIkNvbnRlbnQgTGFuZ3VhZ2UgSGVhZGVy cyIsIFJGQyAzMjgyLAogICAgICAgICAgICAgIE1heSAyMDAyLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA2ICAgICAgICAg ICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsdHJ1LW1h dGNoaW5nICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDUKCgpBcHBlbmRpeCBBLiAgQWNrbm93 bGVkZ2VtZW50cwoKICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlzIGJvdW5kIHRvIGJlIGlu Y29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2VsZWN0 aW9uIGZyb20gdGhlIGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQogICBjb250cmlidXRlZCB0byBt YWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2RheS4KCiAgIFRoZSBjb250cmlidXRvcnMg dG8gW1JGQzMwNjZiaXNdLCBbUkZDMzA2Nl0gYW5kIFtSRkMxNzY2XSwgZWFjaCBvZgogICB3aGlj aCBpcyBhIHByZWN1cnNvciB0byB0aGlzIGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRyaWJ1 dGlvbnMKICAgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlzIGRvY3VtZW50IGFuZCBhcmUg Z2VuZXJhbGx5IHJlc3BvbnNpYmxlCiAgIGZvciB0aGUgc3VjY2VzcyBvZiBsYW5ndWFnZSB0YWdz LgoKICAgVGhlIGZvbGxvd2luZyBwZW9wbGUgKGluIGFscGhhYmV0aWNhbCBvcmRlciBieSBmYW1p bHkgbmFtZSkKICAgY29udHJpYnV0ZWQgdG8gdGhpcyBkb2N1bWVudDoKCiAgIEhhcmFsZCBBbHZl c3RyYW5kLCBKZXJlbXkgQ2Fycm9sbCwgSm9obiBDb3dhbiwgTWFydGluIER1ZXJzdCwgRnJhbmsK ICAgRWxsZXJtYW5uLCBEb3VnIEV3ZWxsLCBNYXJpb24gR3VubiwgS2VudCBLYXJsc3NvbiwgSXJh IE1jRG9uYWxkLCBNLgogICBQYXR0b24sIFJhbmR5IFByZXN1aG4sIEVyaWMgdmFuIGRlciBQb2Vs LCBhbmQgbWFueSwgbWFueSBvdGhlcnMuCgogICBWZXJ5IHNwZWNpYWwgdGhhbmtzIG11c3QgZ28g dG8gSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQsIHdobwogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBh bmQgMzA2NiwgYW5kIHdpdGhvdXQgd2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkCiAgIG5vdCBoYXZl IGJlZW4gcG9zc2libGUuCgogICBGb3IgdGhpcyBwYXJ0aWN1bGFyIGRvY3VtZW50LCBKb2huIENv d2FuIG9yaWdpbmF0ZWQgdGhlIHNjaGVtZQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuMy4g IE1hcmsgRGF2aXMgb3JpZ2luYXRlZCB0aGUgc2NoZW1lCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2Vj dGlvbiAzLjMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgICBFeHBpcmVzIE1heSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBO b3ZlbWJlciAyMDA1CgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBBZGRpc29uIFBoaWxsaXBzIChl ZGl0b3IpCiAgIFF1ZXN0IFNvZnR3YXJlCgogICBFbWFpbDogYWRkaXNvbiBkb3QgcGhpbGxpcHMg YXQgcXVlc3QgZG90IGNvbQoKCiAgIE1hcmsgRGF2aXMgKGVkaXRvcikKICAgSUJNCgogICBFbWFp bDogbWFyayBkb3QgZGF2aXMgYXQgaWJtIGRvdCBjb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAyMiwg MjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgbHRydS1tYXRjaGluZyAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA1CgoKSW50ZWxs ZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudAoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24g cmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAg IHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBk ZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBs aWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFi bGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVu ZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAg b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRz IGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIg ZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3Vy YW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2Yg YW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNz aW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVu dGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZy b20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYu b3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg YXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292 ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBz dGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAog ICBpZXRmLWlwckBpZXRmLm9yZy4KCgpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5CgogICBUaGlzIGRv Y3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQg b24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVAogICBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsCiAgIElOQ0xV RElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUK ICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QKICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQg aW4gQkNQIDc4LCBhbmQKICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9y cyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBm b3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQog ICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoKUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVz IE1heSAyMiwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMjldCgwK ------_=_NextPart_001_01C5EEF3.E9795A24 Content-Type: text/plain; charset="us-ascii" 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_001_01C5EEF3.E9795A24-- From ltru-bounces@ietf.org Mon Nov 21 21:03:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNVC-0002gn-U2; Mon, 21 Nov 2005 21:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNVA-0002bw-IR for ltru@megatron.ietf.org; Mon, 21 Nov 2005 21:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17986 for ; Mon, 21 Nov 2005 21:02:41 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeNni-0006ne-2x for ltru@ietf.org; Mon, 21 Nov 2005 21:22:31 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAM22hd04140; Tue, 22 Nov 2005 11:02:43 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 5272_11793dd2_5afc_11da_8cdd_00304811fd80; Tue, 22 Nov 2005 11:02:42 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAM2149f000353; Tue, 22 Nov 2005 11:01:54 +0900 Message-Id: <6.0.0.20.2.20051122103801.01880b90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Nov 2005 10:41:55 +0900 To: "Addison Phillips" , "Mark Davis" From: Martin Duerst Subject: RE: wildcards in extended ranges (was RE: [Ltru] draft-06 comments:choice of range) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [chairs hat on] Hello Addison, others, At 02:20 05/11/22, Addison Phillips wrote: >> Not only in this specific context, but in general, I very much agree. >> Earlier versions of our draft just left too many MAYs and SHOULDs >> that confused protocol designers and implementers (who don't necessarily >> understand all the details). > >Be specific. I won't change anything in the draft that isn't specific. > >This latest set of threads has me sitting on my hands. I can't figure out >what to put in or take out and it isn't just the quoting of previous posts. >It's the relative lack of specificity about the text. (It is also the fact >that only two or three posters appear to be participating, thus making me >feel we don$B!G(Bt have a consensus yet...) Agreed. My current judgement is that we have consensus on most of the editorial (in the widest sense) stuff. I'll go through the individual issues and check them and list them up for documentation when I have time. I also agree that for some of the non-editorial issues, it's difficult to see consensus as of yet. Thanks for putting out -07, than gives everybody a new base. >If you think a "MAY" or "SHOULD" ought to be a MUST (or removed), you need >to say which one and how you would change it. [as an individual contributor] I will. >Individual posts per item (or at least section) are preferred by the editors. Yes, very important. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 21 23:04:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EePOf-0007SO-Nq; Mon, 21 Nov 2005 23:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EePOd-0007Ry-Va for ltru@megatron.ietf.org; Mon, 21 Nov 2005 23:04:44 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00172 for ; Mon, 21 Nov 2005 23:04:05 -0500 (EST) Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20051122040412.YMNT10822.mta10.adelphia.net@DGBP7M81> for ; Mon, 21 Nov 2005 23:04:12 -0500 Message-ID: <019d01c5ef1a$146579f0$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20051121170913.RXZT20197.edge4.adelphia.net@megatron.ietf.org> Date: Mon, 21 Nov 2005 20:06:13 -0800 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: draft-06: change the title? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: >>> Now, another question: do we follow ISO standard presentation >>> of having >>> only the first letter of title begin with a capital letter? >> >> IETF convention [1] would be more appropriate for an IETF document. > > I accept that, but personally prefer the ISO convention. So do I, but that is neither here nor there. The IETF has standardized on Title Caps, not Sentence caps, and it makes much more sense for them for pick one convention and stick to it consistently. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 22 09:53:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZW6-0002sL-5D; Tue, 22 Nov 2005 09:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZW4-0002rI-9J for ltru@megatron.ietf.org; Tue, 22 Nov 2005 09:53:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26383 for ; Tue, 22 Nov 2005 09:52:24 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZoi-0007Kz-UP for ltru@ietf.org; Tue, 22 Nov 2005 10:12:22 -0500 Received: from dul1shollenbl1 ([::ffff:68.100.55.187]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Tue, 22 Nov 2005 09:52:36 -0500 id 0158801C.438330B4.00000FAF From: "Scott Hollenbeck" To: "'r&d afrac'" Date: Tue, 22 Nov 2005 09:53:11 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXaoACfWEaPWsYMQGe3PAoJL8pJBgUzbSjw In-Reply-To: <6.2.3.4.2.20051027014020.05159dd0@mail.afrac.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 489500194134bea022a3070ad86cad76 Cc: ltru@ietf.org Subject: [Ltru] AD Appeal Response: Off-list RFC 3934 warning to Jefsey Morfin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644543907==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0644543907== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C5EF4A.8CE5B590" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C5EF4A.8CE5B590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have completed my review of the appeal described below. The following references describe additional information that I requested and received as part of this review: The warning: http://www1.ietf.org/mail-archive/web/ltru/current/msg04110.html The appeal, clarified: http://www1.ietf.org/mail-archive/web/ltru/current/msg04113.html Citations provided by Mr. Morfin in response to AD request: http://www1.ietf.org/mail-archive/web/ltru/current/msg04114.html As described in the clarified appeal, the appeal contains two claims: that the warning was inappropriate because the message that prompted the warning was not related to a topic that was closed when the working group reached consensus on a position, and that working group co-chair Randy Presuhn did not correctly determine consensus to close this issue. Mr. Morfin also alleges that several of his contributions have not been tracked as "issues to be resolved" as a result of this consensus-measuring failure. Point #1: Was the warning appropriate? I believe it was. The working group considered the "0-" escape issue, tracked it as issue #1092, rejected it, and the co-chair declared the topic closed. Mr. Morfin's message includes this text: "The "0-" userspace URI-tag RFC 4151 is now published" If new information was intended it was not presented clearly. This part of the appeal is thus denied. Point #2: Did co-chair Randy Presuhn fail to track issues and measure working group consensus? I must first note that every "issue" sent to a working group mailing list for discussion does not necessarily require tracking. The working group must accept the issue and agree to work on it. The citations provided by Mr. Morfin include two issues that were accepted, tracked, and resolved by the working group, and a third that was not tracked. I find that the reason it was not tracked is because there was no agreement within the working group to work on this alleged issue. Mr. Presuhn correctly measured working group consensus and correctly tracked and resolved those issues that the working group agreed to explore. This last part of the appeal, and thus the entire appeal, is denied. Scott Hollenbeck LTRU Area Advisor _____ From: r&d afrac [mailto:rd@afrac.org] Sent: Wednesday, October 26, 2005 9:22 PM To: Scott Hollenbeck Cc: Martin Duerst; Randy Presuhn Subject: Appeal - Off-list RFC 3934 warning to Jefsey Morfin Dear Scott, I am sorry but I can only appeal with very serious reasons. They show the very nature of this warning and that the text you shepher in front of the IESG does not result from a concensus, on my key point; and that this is not by mistake. APPEAL ------------- Of the October 26th warning and of the declaration of a consensus over the RFC 3066 bis document. 1. The exotic "#1092" is not concerned. The issue "#1092" says: Sujet: WGLC treat 0- as escape from syntax http://www1.ietf.org/mail-archive/web/ltru/current/msg03099.html requests that the proposal to use 0- as an escape, introduced in message http://www1.ietf.org/mail-archive/web/ltru/current/msg03061.html be given a distinct issue number. Note that the resolution of other issues, e.g., #1072 subsumes this issue and precludes the suggested solution. consequently, this issue is marked as "rejected" A look at the quoted mails shows that Point "#1092" covers the discussion between format: >> x-you-could-simply-string-together-any-addition-al-attribut-es-you- >> like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii- >> characte-rs and format "0-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160809 A-2001:879:98F6::789C:1236" It supports the concept that "0-" would _terminate_ the ABNF, permitting afteward a free format. 2. this mail concerns the inclusion of information of the type: "0-tag:xyzzy.claranet.de,2005:troll-alert" from for example, as documented by an opponent who has well understood the proposition. It supports the concept that "0-" would include information respecting the RFC 4151 ABNF, avoiding the RFC 3066 bis to conflict with RFC 4151 I note that this proposition has been made sevreal times at the WG and was allways opposed the misrepresentation above. That this proposition has the significant advantage to support ISO 11179 compliance, and the proposed wording for ISO 639-4 which underlay the ISO 639 series (the WG-ltru charter calls for the homogenous support). That due to the misrepresentation above the "consensus" has been to oppose an ISO 11179 conformance what is highly detrimental to the architectural deployment of the Internet. That this proposition has therefore been made during the IESG LC and is therefore a pending representation. That RFC 4151 (as demonstrated by the quoted response) permits to identify and document the language of a document. That as an existing informational RFC it describes a practice of the Global Internet Community the WG-ltru Chair has refused to consider. That most of all in this particular appeal, this information concerns both the passed registry debate and the _current_ filtering debate. 3. the pratice documented by RFC 4151 creates a problem to the currently discussed issue of the WG-ltru, i.e. filtering. When a language information is delivered through an RFC 4151 conformant format, - it can be resolved in (among others) the RFC 3066 bis format - it can be filtered exactly in the same way. But this (may) rise(s) some issues which have not yet been considered. This "warning" is therefore a way to _influence_ the current debate on filtering. It illustrates the way the co-Chair has objected the propositions I made to find the most adequate solution to the users and SSDOs needs and to the RFC 4151 documented practices. This makes RFC 3066 bis to still ignore them. This is also something the Members of the WG ignore. May be even the authors and their small number of supporters, while they want to exclude and constrain these needs and practices. As if they wanted their pet software products not to be changed or challenged. I note that I have patiently accepted to be exposed to that practice. Because the experience of centuries of missionaries has shown that it was a pretty efficient manner to introduce the proper solutions. Because, as today, error and bias expose themselves. 4. all this shows that: - my post does not concerns #1092 - that my position on this issue as constantly been misrepresented by the co-Chair, as it is today - that in so doing he had coached the WG-ltru n such a way that my _only_ objection to the current text (the inclusion of the RFC 4151 described practices) had been suposedly consensually rejected and my other concurrent propositions have been disregarded on similar gronds. - that he has constantly used private warnings with no more substance that this one, since: - this comments introduces new information which concerns (but not affect) the indirect access to the langtags and the user security - it concerns a proposition I made which has never been discussed - which is pending in front of the IESG, IAB and the community (I never hiden that I will appeal for it) - which is pertinent to the current debate of the WG-ltru - it concerns the current debate over filtering. 5. I note that in so doing the co-Chair, as in all the other occasions, uses warnings or suspension to support a delictuous action of a Member and has so encouraged them deliberately creating the deleterious climate of this WG.. Ban (now too old for appeal) was over an oppostion to a racist position of a Member, a recent warning against a reaction to stop a similar creep. He should have taken care of instead of encouraging it. Today it is used to support a blattant ad-hominem and to threat my right to appeal. 6. I could consider that this is only a continuation of the personal feelings the co-Chair expressed in a public ad-hominem full of .. disputable affirmations, but ... - this case concerns a point of high commercial, political and Internet architectural impact. This is over a document the co-Chair tries to influence as the manager of a tracking system he created and the way he demonstrates by this case. - this demonstrates that there is not a single way to accomplish the purpose of the langtags as affirmed by the BCP qualification of RFC 3066 bis. This is something a simple initial review of the Charter would have shown. A review I asked for many times, the co-Chair opposed - in spite of its "thorny" (his qualification) points - but promised to carry at the end of the process. This validation has not been carried yet. - this increases the legal risks related to the proposed text since there is now an existing RFC documented alternative which does not run into that risk. This should be mentionned into the security considerations: they only mention the risk and not the RFC 4151 solution. - all these points have been hidden or reduced in the view of the community and of the IETF, in misprepresenting it - as it is still done today - with the authority of a WG-Chair. This makes the WG-ltru, the IETF and the IESG feel my key proposition has been discussed, opposed and consensually refused, what it has _never_ been discussed. Knowing that this point was complex and that this affimation would be controverted, I purposely never quoted a key aspect which would have resulted from any serious discussion. It is easy to show if I am right or if I am wrong. I just introduced it in this mail for the first time. For all the reasons above I appeal of the today warning of co-Chair Randy Presun and of his evaluation of consensus concerning the RFC 3066 bis. I note that I have no feeling concerning Randy Presuhn, except for his behaviour over the "Route 666" issue. This is purely technical and I am only motivated by the good of the IETF and of the users. I fully understand the pressure and the load you all meets. I am sorry to add burdens, but this time there is a full exposure of the oily mechanism I am myself submitted to, for so many months. There is a clear exposure of the bias which lead to the presented document (I think I positively contributed to, in spite or becaus of the opposition). This document is wrong, but can be made right in includint the only proposition I consider important: compatibility with its RFC competitor. I certainly understand it breaks the notion of immediate exclusive. Is that a reason to hide them to the WG-ltru members? I think the exclusive comes from quality rather than misrepresentation, or typos. jfc morfin At 01:14 27/10/2005, Randy Presuhn wrote: Hi - > From: "r&d afrac" > To: "Frank Ellermann" ; > Sent: Wednesday, October 26, 2005 2:30 PM > Subject: Re: [Ltru] Re: RFC 4151 on The 'tag' URI Scheme > > At 22:07 26/10/2005, Frank Ellermann wrote: > >JFC (Jefsey) Morfin wrote: > > > > > The "0-" userspace URI-tag RFC 4151 is now published. > > My first tag. > > This will be usefull in appeal to illustrate the attitude of this WG. > jfc Since RFC 4151 does not satisfy the requirements for extensions set forth in http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt section 3.7, I had interpreted Jefsey's posting as a joke, and had intended to simply ignore it. Since he now appears to be serious, I guess we'll have to treat it as yet another example of his refusal to give up on issue #1092 (issue tracker at https://rt.psg.com/ user and password "ietf"). I regard as disruptive continued attempts to re-open closed issues without providing new rationale. Continuation of this or other disruptive activities may resulting in the suspension of Jefsey's posting privileges to the ltru WG mailing list for a period of up to 30 days. Randy, ltru co-chair ------=_NextPart_000_000C_01C5EF4A.8CE5B590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have=20 completed my review of the appeal described below.  The following=20 references describe additional information that I requested and received = as part=20 of this review:
 
The=20 warning:
http://www1.ietf.org/mail-archive/web/ltru/current/msg04110.html
 
The=20 appeal, clarified:
http://www1.ietf.org/mail-archive/web/ltru/current/msg04113.html
 
Citations provided by Mr. Morfin in response = to AD=20 request:
http://www1.ietf.org/mail-archive/web/ltru/current/msg04114.html
 
As=20 described in the clarified appeal, the appeal contains two claims: that = the=20 warning was inappropriate because the message that prompted the = warning was=20 not related to a topic that was closed when the working group reached = consensus=20 on a position, and that working group co-chair Randy = Presuhn did=20 not correctly determine consensus to close this issue.  Mr. Morfin = also=20 alleges that several of his contributions have not been tracked as = "issues to be=20 resolved" as a result of this consensus-measuring = failure.
 
Point=20 #1: Was the warning appropriate?  I believe it was.  The = working group=20 considered the "0-" escape issue, tracked it as issue #1092, rejected = it, and=20 the co-chair declared the topic closed.  Mr. Morfin's message = includes this=20 text:
 
"The=20 "0-" userspace URI-tag RFC 4151 is now published"
 
If new=20 information was intended it was not presented clearly.  This part = of the=20 appeal is thus denied.
 
Point=20 #2: Did co-chair Randy Presuhn fail to track issues and measure working = group=20 consensus?
 
I must first note that every "issue" sent to a working = group mailing=20 list for discussion does not necessarily require tracking.  The = working=20 group must accept the issue and agree to work on it.  The citations = provided by Mr. Morfin include two issues that were accepted, tracked, = and=20 resolved by the working group, and a third that was not = tracked.  I=20 find that the reason it was not tracked is because there was no = agreement within=20 the working group to work on this alleged issue.  Mr. Presuhn = correctly=20 measured working group consensus and correctly tracked and = resolved those=20 issues that the working group agreed to explore.
 
This last part of the appeal, = and thus the=20 entire appeal, is denied.
Scott=20 Hollenbeck
LTRU=20 Area Advisor

From: r&d afrac = [mailto:rd@afrac.org]=20
Sent: Wednesday, October 26, 2005 9:22 PM
To: = Scott=20 Hollenbeck
Cc: Martin Duerst; Randy = Presuhn
Subject:=20 Appeal - Off-list RFC 3934 warning to Jefsey = Morfin

Dear Scott,
I am sorry but I can only appeal with very = serious=20 reasons. They show the very nature of this warning and that the text = you=20 shepher in front of the IESG does not result from a concensus, on my = key=20 point; and that this is not by = mistake.

APPEAL
-------------
Of=20 the October 26th warning and of the declaration of a consensus over = the RFC=20 3066 bis document.


1. The exotic "#1092" is not concerned. = The=20 issue "#1092" says:

<quote>
Sujet: WGLC treat 0- as = escape=20 from syntax

http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03099.html
requests=20 that the proposal to use 0- as an escape, introduced
in = message
http://www1.ietf.org/mail-archive/web/ltru/current/msg= 03061.html
be=20 given a distinct issue number.
Note that the resolution of other = issues,=20 e.g., #1072
subsumes this issue and precludes the suggested=20 solution.
consequently, this issue is marked as "rejected"=20
</unquote>

A look at the quoted mails shows that = Point=20 "#1092" covers the discussion between format:

>>
x-you-could-simply-string-together-any-addition-al-attribut-es-you-



>>
like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii-



>> characte-rs
and format=20 =
"0-language-tags.x-tags.com:singapourien.jefsey-languages.com:2005120= 3160809A-2001:879:98F6::789C:1236"

It=20 supports the concept that "0-" would _terminate_ the ABNF, permitting = afteward=20 a free format.



2. this mail concerns the inclusion of=20 information of the type:

   =20 "0-tag:xyzzy.claranet.de,2005:troll-alert"
    from=20 <tag:xyzzy.claranet.de,2005:troll-alert> for example,

as=20 documented by an opponent who has well understood the = proposition.

It=20 supports the concept that "0-" would include information respecting = the RFC=20 4151 ABNF, avoiding the RFC 3066 bis to conflict with RFC = 4151

I note=20 that this proposition has been made sevreal times at the WG and was = allways=20 opposed the misrepresentation above. That this proposition has the = significant=20 advantage to support ISO 11179 compliance, and the proposed wording = for ISO=20 639-4 which underlay the ISO 639 series (the WG-ltru charter calls for = the=20 homogenous support). That due to the misrepresentation above the = "consensus"=20 has been to oppose an ISO 11179 conformance what is highly detrimental = to the=20 architectural deployment of the Internet.

That this proposition = has=20 therefore been made during the IESG LC and is therefore a pending=20 representation.

That RFC 4151 (as demonstrated by the quoted = response)=20 permits to identify and document the language of a document. That as = an=20 existing informational RFC it describes a practice of the Global = Internet=20 Community the WG-ltru Chair has refused to consider.

That most = of all=20 in this particular appeal, this information concerns both the passed = registry=20 debate and the _current_ filtering debate.


3. the pratice=20 documented by RFC 4151 creates a problem to the currently discussed = issue of=20 the WG-ltru, i.e. filtering. When a language information is delivered = through=20 an RFC 4151 conformant format,

- it can be resolved in (among = others)=20 the RFC 3066 bis format
- it can be filtered exactly in the same = way.=20

But this (may) rise(s) some issues which have not yet been=20 considered. 

This "warning" is therefore a way to = _influence_ the=20 current debate on filtering. It illustrates the way the co-Chair has = objected=20 the propositions I made to find the most adequate solution to the = users and=20 SSDOs needs and to the RFC 4151 documented practices. This makes RFC = 3066 bis=20 to still ignore them. This is also something the Members of the WG = ignore. May=20 be even the authors and their small number of supporters, while they = want to=20 exclude and constrain these needs and practices. As if they wanted = their pet=20 software products not to be changed or challenged.

I note that = I have=20 patiently accepted to be exposed to that practice. Because the = experience of=20 centuries of missionaries has shown that it was a pretty efficient = manner to=20 introduce the proper solutions. Because, as today, error and bias = expose=20 themselves.


4. all this shows = that:

    - my=20 post does not concerns #1092
    - that my position = on this=20 issue as constantly been misrepresented by the co-Chair, as it is=20 today
    - that in so doing he had coached the = WG-ltru n=20 such a way that my _only_ objection to the current text (the inclusion = of the=20 RFC 4151 described practices) had been suposedly consensually rejected = and my=20 other concurrent propositions have been disregarded on similar=20 gronds.
    - that he has constantly used private = warnings=20 with no more substance that this one, = since:
     =20 - this comments introduces new information which concerns (but not = affect) the=20 indirect access to the langtags and the user=20 security
      - it concerns a proposition = I made=20 which has never been discussed
      - = which is=20 pending in front of the IESG, IAB and the community (I never hiden = that I will=20 appeal for it)
      - which is pertinent = to the=20 current debate of the WG-ltru
      - it = concerns=20 the current debate over filtering.


5. I note that in so = doing the=20 co-Chair, as in all the other occasions, uses warnings or suspension = to=20 support a delictuous action of a Member and has so encouraged them=20 deliberately creating the deleterious climate of this WG.. Ban (now = too old=20 for appeal) was over an oppostion to a racist position of a Member, a = recent=20 warning against a reaction to stop a similar creep. He should have = taken care=20 of instead of encouraging it. Today it is used to support a blattant=20 ad-hominem and to threat my right to appeal.


6. I could = consider=20 that this is only a continuation of the personal feelings the co-Chair = expressed in a public ad-hominem full of .. disputable affirmations, = but=20 ...

- this case concerns a point of high commercial, political = and=20 Internet architectural impact. This is over a document the co-Chair = tries to=20 influence as the manager of a tracking system he created and the way = he=20 demonstrates by this case.

- this demonstrates that there is = not a=20 single way to accomplish the purpose of the langtags as affirmed by = the BCP=20 qualification of RFC 3066 bis. This is something a simple initial = review of=20 the Charter would have shown. A review I asked for many times, the = co-Chair=20 opposed - in spite of its "thorny" (his qualification) points - but = promised=20 to carry at the end of the process. This validation has not been = carried=20 yet.

- this increases the legal risks related to the proposed = text=20 since there is now an existing RFC documented alternative which does = not run=20 into that risk. This should be mentionned into the security = considerations:=20 they only mention the risk and not the RFC 4151 solution.

- all = these=20 points have been hidden or reduced in the view of the community and of = the=20 IETF, in misprepresenting it - as it is still done today - with the = authority=20 of a WG-Chair. This makes the WG-ltru, the IETF and the IESG feel my = key=20 proposition has been discussed, opposed and consensually refused, what = it has=20 _never_ been discussed. Knowing that this point was complex and that = this=20 affimation would be controverted, I purposely never quoted a key = aspect which=20 would have resulted from any serious discussion.

It is easy to = show if=20 I am right or if I am wrong. I just introduced it in this mail for the = first=20 time.



For all the reasons above I appeal of the today = warning=20 of co-Chair Randy Presun and of his evaluation of consensus concerning = the RFC=20 3066 bis.


I note that I have no feeling concerning Randy = Presuhn,=20 except for his behaviour over the "Route 666" issue. This is purely = technical=20 and I am only motivated by the good of the IETF and of the users. I = fully=20 understand the pressure and the load you all meets. I am sorry to add = burdens,=20 but this time there is a full exposure of the oily mechanism I am = myself=20 submitted to, for so many months.

There is a clear exposure of = the=20 bias which lead to the presented document (I think I positively = contributed=20 to, in spite or becaus of the opposition). This document is wrong, but = can be=20 made right in includint the only proposition I consider important:=20 compatibility with its RFC competitor. I certainly understand it = breaks the=20 notion of immediate exclusive. Is that a reason to hide them to the = WG-ltru=20 members?

I think the exclusive comes from quality rather than=20 misrepresentation, or typos.
jfc morfin




At 01:14 = 27/10/2005, Randy Presuhn wrote:
Hi -
> From: = "r&d=20 afrac" <rd@afrac.org>
> To: "Frank Ellermann"=20 <nobody@xyzzy.claranet.de>; <ltru@ietf.org>
> = Sent:=20 Wednesday, October 26, 2005 2:30 PM
> Subject: Re: [Ltru] Re: = RFC 4151=20 on The 'tag' URI Scheme
>
> At 22:07 26/10/2005, Frank = Ellermann=20 wrote:
> >JFC (Jefsey) Morfin wrote:
> >
> = > >=20 The "0-" userspace URI-tag RFC 4151 is now published.
>=20 ><tag:xyzzy.claranet.de,2005:troll-alert>  My first=20 tag.
>
> This will be usefull in appeal to illustrate = the=20 attitude of this WG.
> jfc

Since RFC 4151 does not = satisfy the=20 requirements for extensions
set forth in http://www.ietf.org/internet-drafts/draft-ietf-ltru-re= gistry-14.txt=20
section 3.7, I had interpreted Jefsey's posting as a joke, and=20 had
intended to simply ignore it.

Since he now appears to = be=20 serious, I guess we'll have to treat it
as yet another example of = his=20 refusal to give up on issue #1092
(issue tracker at = https://rt.psg.com/=20 user and password "ietf").

I regard as disruptive continued = attempts=20 to re-open closed
issues without providing new rationale. =20 Continuation of this
or other disruptive activities may resulting = in the=20 suspension of
Jefsey's posting privileges to the ltru WG mailing = list for=20 a period
of up to 30 days.

Randy, ltru=20 co-chair
------=_NextPart_000_000C_01C5EF4A.8CE5B590-- --===============0644543907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0644543907==-- From ltru-bounces@ietf.org Tue Nov 22 10:24:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eea06-0000D2-F7; Tue, 22 Nov 2005 10:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eea04-0000Ca-Qh for ltru@megatron.ietf.org; Tue, 22 Nov 2005 10:24:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29840 for ; Tue, 22 Nov 2005 10:23:27 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeaIj-0000ZM-VF for ltru@ietf.org; Tue, 22 Nov 2005 10:43:23 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id jAMFNvHu020561 for ; Tue, 22 Nov 2005 10:23:57 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 22 Nov 2005 10:23:54 -0500 Date: Tue, 22 Nov 2005 10:23:54 -0500 From: "John.Cowan" To: ltru@ietf.org Message-ID: <20051122152354.GA2060@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Ltru] The special status of i-default in lookup X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org "i-default" is a strange beast, like "und" and "mul", and it seems to me that it should be treated specially in the matching draft. In particular, it should be the last chance in an otherwise failing lookup just before implementation-defined behavior kicks in. Here's the relevant section of RFC 2277/BCP 18, which is the official reference for "i-default": # 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. I propose that the following paragraph in 3.3 be changed from: < When performing lookup using a language priority list, the progressive < search MUST proceed to consider each language range before finding < the default content or empty tag. The default content might be content < with no language tag (or with an empty value, as with xml:lang in the < XML specification), or it might be a particular language designated < for that bit of content. to this: > When performing lookup using a language priority list, the progressive > search MUST proceed to consider each language range before considering > the default content. If content tagged "i-default" is available, > it is the default content. Otherwise, the default content is > implementation-dependent; it might be content with no language tag > (or with an empty value, as with xml:lang in the XML specification), > or it might be a particular language designated as the default for > that bit of content. -- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 23 23:58:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef9Bb-0008Cz-QW; Wed, 23 Nov 2005 23:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef9Ba-0008Ch-Me for ltru@megatron.ietf.org; Wed, 23 Nov 2005 23:58:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14008 for ; Wed, 23 Nov 2005 23:57:36 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef9UW-0002s4-O6 for ltru@ietf.org; Thu, 24 Nov 2005 00:17:55 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jAO4vbu22596; Thu, 24 Nov 2005 13:57:37 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 156d_d583a6ee_5ca6_11da_8994_00304811fd80; Thu, 24 Nov 2005 13:57:37 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAO4tfj3003286; Thu, 24 Nov 2005 13:57:00 +0900 Message-Id: <6.0.0.20.2.20051124121238.018e2e80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Nov 2005 12:20:26 +0900 To: "John.Cowan" , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] The special status of i-default in lookup In-Reply-To: <20051122152354.GA2060@NYCMJCOWA2> References: <20051122152354.GA2060@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hello John, [co-chairs hat on] Many thanks for bring this up as an issue. [co-chairs hat off] I'm not sure I like your proposal. Although upon careful reading, it does NOT imply that i-default (and thus (simplified) English) has to be provided, it may well be read that way. Such a reading would be inappropriate in many contexts, in particular Web pages and the like. (In my view, it's more appropriate for lower level messages.) So I'd be okay to mention i-default, but in a different way, just as one possible way to establish an (implementation-defined) default. See below for my text. At 00:23 05/11/23, John.Cowan wrote: >I propose that the following paragraph in 3.3 be changed from: > >< When performing lookup using a language priority list, the progressive >< search MUST proceed to consider each language range before finding >< the default content or empty tag. The default content might be content >< with no language tag (or with an empty value, as with xml:lang in the >< XML specification), or it might be a particular language designated >< for that bit of content. > >to this: > >> When performing lookup using a language priority list, the progressive >> search MUST proceed to consider each language range before considering >> the default content. If content tagged "i-default" is available, >> it is the default content. Otherwise, the default content is >> implementation-dependent; it might be content with no language tag >> (or with an empty value, as with xml:lang in the XML specification), >> or it might be a particular language designated as the default for >> that bit of content. I propose to change it to this: > When performing lookup using a language priority list, the progressive > search MUST proceed to consider each language range before finding > the default content or empty tag. The default content might be content > with no language tag (or with an empty value, as with xml:lang in the > XML specification), or it might be a particular language designated > for that bit of content, or it might be labeled as i-default [RFC 2277]. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 24 03:27:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCRz-0000i5-08; Thu, 24 Nov 2005 03:27:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCRw-0000hs-Dz for ltru@megatron.ietf.org; Thu, 24 Nov 2005 03:27:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00644 for ; Thu, 24 Nov 2005 03:26:44 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfCkv-0002Bk-Up for ltru@ietf.org; Thu, 24 Nov 2005 03:47:04 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B1D02596CB; Thu, 24 Nov 2005 09:26:41 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19447-09; Thu, 24 Nov 2005 09:26:38 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id F37B92580CF; Thu, 24 Nov 2005 09:26:37 +0100 (CET) Date: Thu, 24 Nov 2005 09:29:00 +0100 From: Harald Tveit Alvestrand To: Martin Duerst , "John.Cowan" , ltru@ietf.org Subject: Re: [Ltru] The special status of i-default in lookup Message-ID: In-Reply-To: <6.0.0.20.2.20051124121238.018e2e80@localhost> References: <20051122152354.GA2060@NYCMJCOWA2> <6.0.0.20.2.20051124121238.018e2e80@localhost> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org A bit of background on i-default: the canonical context that caused i-default to be created was IMAP error messages at login time (before the user is known). The IMAP people (and I strongly agree with them) felt that it was good to have a special language context for the case "negotiation can't be done", and felt that it was NOT good to label this with something special like the empty string. So the i-default tag was created - in order to have an explicit label for "what we do when we don't know". --On torsdag, november 24, 2005 12:20:26 +0900 Martin Duerst wrote: > I propose to change it to this: > > When performing lookup using a language priority list, the progressive > > search MUST proceed to consider each language range before finding > > the default content or empty tag. The default content might be content > > with no language tag (or with an empty value, as with xml:lang in the > > XML specification), or it might be a particular language designated > > for that bit of content, or it might be labeled as i-default [RFC > 2277]. > Actually I'd suggest doing something slightly different. It's relatively clear to me that there are a number of issues (ultimate fallback, one or many values, scores or not) that are tied more closely to the application of the algorithm than to the algorithm itself. So I'd suggest to put somewhere (not sure where yet) a paragraph like the following: Language tag matching is a tool, and does not by itself specify a complete procedure for the use of language tags. Such procedures are intimately tied to the application protocol in which they occur. When specifying a protocol operation using matching, the protocol must specify: - Which type(s) of language tag matching it uses - Whether the operation has to return a single result (lookup) or a possibly empty set of results (matching) - For lookup, what the result is when no matching tag is found (for instance failure of operation, empty value, or return i-default [RFC 2277]). Then we can remove the concept of "default" or "empty tag" completely from the language tag matching algorithm itself. I think that would be a net win.... Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 25 03:02:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYXK-0005Sw-HQ; Fri, 25 Nov 2005 03:02:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYXI-0005Sl-Nz for ltru@megatron.ietf.org; Fri, 25 Nov 2005 03:02:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23559 for ; Fri, 25 Nov 2005 03:01:42 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfYqR-0003Qi-P8 for ltru@ietf.org; Fri, 25 Nov 2005 03:22:15 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jAP81Yd28699; Fri, 25 Nov 2005 17:01:34 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 7134_b25c7a5e_5d89_11da_99f7_0030482533a1; Fri, 25 Nov 2005 17:01:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jAP80ChI020283; Fri, 25 Nov 2005 17:00:44 +0900 Message-Id: <6.0.0.20.2.20051124190754.0189ad80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 25 Nov 2005 16:59:43 +0900 To: Harald Tveit Alvestrand , "John.Cowan" , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] The special status of i-default in lookup In-Reply-To: References: <20051122152354.GA2060@NYCMJCOWA2> <6.0.0.20.2.20051124121238.018e2e80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [co-chair hat off] At 17:29 05/11/24, Harald Tveit Alvestrand wrote: >A bit of background on i-default: > >the canonical context that caused i-default to be created was IMAP error messages at login time (before the user is known). >The IMAP people (and I strongly agree with them) felt that it was good to have a special language context for the case "negotiation can't be done", and felt that it was NOT good to label this with something special like the empty string. > >So the i-default tag was created - in order to have an explicit label for "what we do when we don't know". Okay, but in our draft, we are talking about something else, not the state before negotiation, but after negotiation. >Actually I'd suggest doing something slightly different. It's relatively clear to me that there are a number of issues (ultimate fallback, one or many values, scores or not) that are tied more closely to the application of the algorithm than to the algorithm itself. So I'd suggest to put somewhere (not sure where yet) a paragraph like the following: Having a paragraph like below is a very good idea in general. > Language tag matching is a tool, and does not by itself specify a > complete procedure for the use of language tags. Such procedures are > intimately tied to the application protocol in which they occur. > When specifying a protocol operation using matching, the protocol > must specify: > > - Which type(s) of language tag matching it uses > - Whether the operation has to return a single result (lookup) or a > possibly empty set of results (matching) > - For lookup, what the result is when no matching tag is found > (for instance failure of operation, empty value, or return i-default > [RFC 2277]). > >Then we can remove the concept of "default" or "empty tag" completely from the language tag matching algorithm itself. I disagree with removing any mention of "default" (except for i-default). As I said before, there is a thin line between "default" and i-default. The later by definition includes some form of English, the former doesn't necessarily do so. There are situations where i-default is appropriate, and others where it is not. For IMAP protocol startup, it is, but for HTTP lanugage negotiation, it is not, at least not in my view. So I suggest to change the last bullet point to something like: - For lookup, what the result is when no matching tag is found (for instance failure of operation, empty value, returning some protocol defined or implementation defined default, or return i-default [RFC 2277]). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 25 03:07:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYcT-0006Kf-7x; Fri, 25 Nov 2005 03:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYcR-0006KT-Cl for ltru@megatron.ietf.org; Fri, 25 Nov 2005 03:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23922 for ; Fri, 25 Nov 2005 03:07:02 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfYve-0003bg-FO for ltru@ietf.org; Fri, 25 Nov 2005 03:27:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DC7425970A; Fri, 25 Nov 2005 09:07:01 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27255-01; Fri, 25 Nov 2005 09:06:57 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55FE4259707; Fri, 25 Nov 2005 09:06:57 +0100 (CET) Date: Fri, 25 Nov 2005 09:09:16 +0100 From: Harald Tveit Alvestrand To: Martin Duerst , "John.Cowan" , ltru@ietf.org Subject: Re: [Ltru] The special status of i-default in lookup Message-ID: <63708A53E56FA137B7F311CC@svartdal.hjemme.alvestrand.no> In-Reply-To: <6.0.0.20.2.20051124190754.0189ad80@localhost> References: <20051122152354.GA2060@NYCMJCOWA2> <6.0.0.20.2.20051124121238.018e2e80@localhost> <6.0.0.20.2.20051124190754.0189ad80@localhost> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On fredag, november 25, 2005 16:59:43 +0900 Martin Duerst wrote: > > - For lookup, what the result is when no matching tag is found > > (for instance failure of operation, empty value, or return > i-default > > [RFC 2277]). > > > >Then we can remove the concept of "default" or "empty tag" completely > from the language tag matching algorithm itself. > > I disagree with removing any mention of "default" (except for i-default). > As I said before, there is a thin line between "default" and i-default. > The later by definition includes some form of English, the former doesn't > necessarily do so. There are situations where i-default is appropriate, > and others where it is not. For IMAP protocol startup, it is, but for > HTTP lanugage negotiation, it is not, at least not in my view. Full agreement here. > So I > suggest > to change the last bullet point to something like: > > - For lookup, what the result is when no matching tag is found > (for instance failure of operation, empty value, returning some > protocol defined or implementation defined default, or return > i-default [RFC 2277]). I think your language is better - thanks for expanding on my suggestion! Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 28 15:51:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egpxz-0000E0-42; Mon, 28 Nov 2005 15:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egpwv-00085e-1N; Mon, 28 Nov 2005 15:50:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03675; Mon, 28 Nov 2005 15:49:24 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgqGl-0006Se-EQ; Mon, 28 Nov 2005 16:10:41 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Egpwo-0007nr-4m; Mon, 28 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 28 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-07.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org 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 : Matching of Language Tags Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-07.txt Pages : 29 Date : 2005-11-28 This document describes different mechanisms for comparing, matching, and evaluating language tags. Possible algorithms for language negotiation and content selection are described. This document, in combination with RFC 3066bis (replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-28115929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-28115929.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Tue Nov 29 09:59:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6xb-00089y-Gi; Tue, 29 Nov 2005 09:59:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6xZ-00089t-Ua for ltru@megatron.ietf.org; Tue, 29 Nov 2005 09:59:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16073 for ; Tue, 29 Nov 2005 09:59:13 -0500 (EST) Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eh7Hc-0006Wu-Pv for ltru@ietf.org; Tue, 29 Nov 2005 10:20:44 -0500 Received: (qmail 6829 messnum 6388666 invoked from network[194.125.174.41/ts09-041.dublin.indigo.ie]); 29 Nov 2005 14:59:40 -0000 Received: from ts09-041.dublin.indigo.ie (HELO egt.ie) (194.125.174.41) by mail00.svc.cra.dublin.eircom.net (qp 6829) with SMTP; 29 Nov 2005 14:59:40 -0000 Message-ID: <438C6CD5.243673A@egt.ie> Date: Tue, 29 Nov 2005 14:59:34 +0000 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ltru@ietf.org, tc46-l@listserv.heanet.ie, unicode@unicode.org, harald@alvestrand.no References: <4A7C6FA2AB31194E80E13FE585F6A212010803DC@EVS-EC1-NODE1.surrey.ac.uk> <4381C0C3.E2A46D4A@egt.ie> <6.2.3.4.2.20051121141231.04331b10@mail.jefsey.com> <4381D960.6F505122@egt.ie> <6.2.3.4.2.20051121153402.0548d860@mail.jefsey.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA16073 Cc: Subject: [Ltru] [OT] John Clews X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Circulating this msg on foot of responses I have received from different countries to my little tribute to our friend and colleague John Clews, recently deceased.=20 An award to commemorate John has been proposed, citing the Jon Postel Award as precedent. Would anyone interested in joining a small ad hoc group for that specific purpose and none other please e-mail me privately= ? Personally, I'd like decisions on this to be BSI-led and=20 am asking readers to please circulate this msg on any relevant lists they can think of (John Clews of BSI being perhaps best known for his dedication to work in Unicode and ISO 10646, ISO/TC 46 and ISO/TC 37 circ= les). Especially, would some friend please help by posting this to address unicode@unicode.org? (Something I cannot currently do because unicode.org services are currently configured by Rick to bounce mail with headers with my details.) With best wishes, mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 29 11:39:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8Vp-000127-M6; Tue, 29 Nov 2005 11:39:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8Vn-0000sc-4K for ltru@megatron.ietf.org; Tue, 29 Nov 2005 11:39:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00388 for ; Tue, 29 Nov 2005 11:38:36 -0500 (EST) Received: from mta3.iomartmail.com ([62.128.193.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh8pr-00029A-Su for ltru@ietf.org; Tue, 29 Nov 2005 12:00:09 -0500 Received: from mta3.iomartmail.com (localhost [127.0.0.1]) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id jATGcr5m032297; Tue, 29 Nov 2005 16:38:53 GMT Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id jATGcpJD032249; Tue, 29 Nov 2005 16:38:52 GMT From: "Debbie Garside" To: "'Marion Gunn'" , , , , Subject: RE: [Ltru] [OT] John Clews Date: Tue, 29 Nov 2005 16:38:37 -0000 Message-ID: <0a9001c5f503$59d53860$1800a8c0@ict.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX09ibMekdnjFSdQuWNjJArx6ek3gADFjUA In-Reply-To: <438C6CD5.243673A@egt.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Marion I will forward your email to the secretary of TS1 at BSI who worked = quite closely with John over the years. Whilst I did meet John once and we exchanged a few emails I do not feel that I knew him personally. I = think that John's TS1 colleagues from the British Library may be interested in assisting this worthy proposal. =20 Kind regards Debbie Garside Chair BSI TS1-1 -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Marion Gunn Sent: 29 November 2005 15:00 To: ltru@ietf.org; tc46-l@listserv.heanet.ie; unicode@unicode.org; harald@alvestrand.no Subject: [Ltru] [OT] John Clews Circulating this msg on foot of responses I have received from different countries to my little tribute to our friend and colleague John Clews, recently deceased.=20 An award to commemorate John has been proposed, citing the Jon Postel = Award as precedent. Would anyone interested in joining a small ad hoc group = for that specific purpose and none other please e-mail me privately? Personally, I'd like decisions on this to be BSI-led and am asking = readers to please circulate this msg on any relevant lists they can think of = (John Clews of BSI being perhaps best known for his dedication to work in = Unicode and ISO 10646, ISO/TC 46 and ISO/TC 37 circles). Especially, would some friend please help by posting this to address unicode@unicode.org? (Something I cannot currently do because = unicode.org services are currently configured by Rick to bounce mail with headers = with my details.) With best wishes, mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ 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 Nov 29 14:12:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAth-0000Vw-GR; Tue, 29 Nov 2005 14:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAtf-0000Vr-K8 for ltru@megatron.ietf.org; Tue, 29 Nov 2005 14:12:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21907 for ; Tue, 29 Nov 2005 14:11:23 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBDi-0008MA-Kb for ltru@ietf.org; Tue, 29 Nov 2005 14:32:55 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 11:11:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Nov 2005 11:11:50 -0800 Message-ID: Thread-Topic: Matching draft, section 8 Thread-Index: AcX0djmvkMPG4MijQZCrIU8xucegcgAonMMQ From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 29 Nov 2005 19:11:48.0408 (UTC) FILETIME=[BF19B380:01C5F518] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dewell@adelphia.net Subject: [Ltru] RE: Matching draft, section 8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966415673==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0966415673== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R29vZCBjYXRjaC4gSSBjaGFuZ2VkIHRoaXMgc2VjdGlvbiB0byBzYXk6DQoNCjx0Pkxhbmd1YWdl IHRhZ3MgcGVybWl0IG9ubHkNCnRoZSBjaGFyYWN0ZXJzIEEtWiwgYS16LCAwLTksIGFuZCBIWVBI RU4tTUlOVVMgKCV4MkQpLiBMYW5ndWFnZSByYW5nZXMgYWxzbyB1c2UgdGhlIGNoYXJhY3RlciBB U1RFUklTSyAoJXgyQSkuICBUaGVzZSBjaGFyYWN0ZXJzIGFyZSBwcmVzZW50IGluIA0KbW9zdCBj aGFyYWN0ZXIgc2V0cywgc28gcHJlc2VudGF0aW9uIG9yIGV4Y2hhbmdlIG9mIGxhbmd1YWdlIHRh Z3Mgb3IgcmFuZ2VzIHNob3VsZCBub3QgcHJlc2VudCBhbnkgDQpjaGFyYWN0ZXIgc2V0IGlzc3Vl cy48L3Q+DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0K SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86RG91Z19Fd2VsbEBiaW8tcmFkLmNvbV0NCj4gU2Vu dDogMjAwNeW5tDEx5pyIMjjml6UgMTU6NDkNCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6 IGRld2VsbEBhZGVscGhpYS5uZXQNCj4gU3ViamVjdDogTWF0Y2hpbmcgZHJhZnQsIHNlY3Rpb24g OA0KPiANCj4gDQo+IDxxdW90ZT4NCj4gOC4gQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucw0K PiANCj4gVGhlIHN5bnRheCBvZiBsYW5ndWFnZSB0YWdzIGFuZCBsYW5ndWFnZSByYW5nZXMgcGVy bWl0IG9ubHkgdGhlIGNoYXJhY3RlcnMNCj4gQS1aLCBhLXosIDAtOSwgYW5kIEhZUEhFTi1NSU5V UyAoJXgyRCkuIFRoZXNlIGNoYXJhY3RlcnMgYXJlIHByZXNlbnQgaW4NCj4gbW9zdCBjaGFyYWN0 ZXIgc2V0cywgc28gcHJlc2VudGF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hvdWxkIG5vdCBwcmVz ZW50DQo+IGFueSBjaGFyYWN0ZXIgc2V0IGlzc3Vlcy4NCj4gPC9xdW90ZT4NCj4gDQo+IENvcnJl Y3Rpb246IFRoZSBhc3RlcmlzayAoJyonKSBpcyBhbHNvIGFsbG93ZWQgaW4gbGFuZ3VhZ2UgcmFu Z2VzLiAgVGhpcw0KPiBpcyBhbHNvIHByZXNlbnQgaW4gbW9zdCBjaGFyYWN0ZXIgc2V0cywgc28g dGhlcmUgc3RpbGwgc2hvdWxkIGJlIG5vDQo+IHByb2JsZW0sIGJ1dCB5b3UgbmVlZCB0byBtZW50 aW9uIHRoaXMgZm9yIGNvbXBsZXRlbmVzcy4NCj4gDQo+IC0tDQo+IERvdWcgRXdlbGwNCj4gT3Bp bmlvbnMgYW5kIHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIHRleHQgYXJlIG5vdCB0aG9zZSBvZiBt eSBlbXBsb3llci4NCj4gTm8gYWZmaWxpYXRpb24gd2l0aCBCaW8tUmFkIExhYm9yYXRvcmllcywg SW5jLiBpcyBleHByZXNzZWQgb3IgaW1wbGllZC4NCg0K --===============0966415673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0966415673==-- From ltru-bounces@ietf.org Tue Nov 29 14:21:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB2j-0007jT-2j; Tue, 29 Nov 2005 14:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB2h-0007g9-SB for ltru@megatron.ietf.org; Tue, 29 Nov 2005 14:21:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22929 for ; Tue, 29 Nov 2005 14:20:47 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBMp-0000Co-36 for ltru@ietf.org; Tue, 29 Nov 2005 14:42:20 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id jATJL8ba016910; Tue, 29 Nov 2005 11:21:08 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Nov 2005 11:23:33 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , LTRU Working Group Subject: RE: [Ltru] RE: Matching draft, section 8 Date: Tue, 29 Nov 2005 11:23:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dewell@adelphia.net X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Addison, Presentation should not present? How about changing to: "These characters are present in most character sets, so presentation or exchange of language tags or ranges should not be constrained by character set issues." Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 29 14:40:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBKt-0004L2-Ij; Tue, 29 Nov 2005 14:40:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBKs-0004Js-CA for ltru@megatron.ietf.org; Tue, 29 Nov 2005 14:40:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24877 for ; Tue, 29 Nov 2005 14:39:33 -0500 (EST) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBez-0000n0-T5 for ltru@ietf.org; Tue, 29 Nov 2005 15:01:07 -0500 Received: from alvmbxw01.prod.quest.corp ([10.1.50.13]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 11:40:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] RE: Matching draft, section 8 Date: Tue, 29 Nov 2005 11:40:06 -0800 Message-ID: Thread-Topic: [Ltru] RE: Matching draft, section 8 Thread-Index: AcX1GhuhO7Yk7eW4TxqXqU4TnMO6WAAAmArA From: "Addison Phillips" To: "McDonald, Ira" , "LTRU Working Group" X-OriginalArrivalTime: 29 Nov 2005 19:40:07.0934 (UTC) FILETIME=[B418C9E0:01C5F51C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dewell@adelphia.net X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918190614==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0918190614== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U2FkbHksIHRoYXQgaXMgb25lIGJpdCBvZiB0aGUgdGV4dCBJIGRpZG4ndCBjaGFuZ2UgZnJvbSBk cmFmdC1yZWdpc3RyeS4gWW91ciB2ZXJzaW9uIHJlYWRzIGJldHRlciBhbmQgSSdtIG1ha2luZyB0 aGUgY2hhbmdlICh1bmxlc3Mgc29tZW9uZSBvYmplY3RzKS4NCg0KQWRkaXNvbg0KDQpBZGRpc29u IFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCg0K SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVj dHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWNEb25hbGQs IElyYSBbbWFpbHRvOmltY2RvbmFsZEBzaGFycGxhYnMuY29tXQ0KPiBTZW50OiAyMDA15bm0MTHm nIgyOeaXpSAxMToyMw0KPiBUbzogQWRkaXNvbiBQaGlsbGlwczsgTFRSVSBXb3JraW5nIEdyb3Vw DQo+IENjOiBkZXdlbGxAYWRlbHBoaWEubmV0DQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gUkU6IE1h dGNoaW5nIGRyYWZ0LCBzZWN0aW9uIDgNCj4gDQo+IEhpIEFkZGlzb24sDQo+IA0KPiBQcmVzZW50 YXRpb24gc2hvdWxkIG5vdCBwcmVzZW50PyAgSG93IGFib3V0IGNoYW5naW5nIHRvOg0KPiANCj4g IlRoZXNlIGNoYXJhY3RlcnMgYXJlIHByZXNlbnQgaW4gbW9zdCBjaGFyYWN0ZXIgc2V0cywgc28N Cj4gcHJlc2VudGF0aW9uIG9yIGV4Y2hhbmdlIG9mIGxhbmd1YWdlIHRhZ3Mgb3IgcmFuZ2VzIHNo b3VsZA0KPiBub3QgYmUgY29uc3RyYWluZWQgYnkgY2hhcmFjdGVyIHNldCBpc3N1ZXMuIg0KPiAN Cj4gQ2hlZXJzLA0KPiAtIElyYQ0KPiANCj4gSXJhIE1jRG9uYWxkIChNdXNpY2lhbiAvIFNvZnR3 YXJlIEFyY2hpdGVjdCkNCj4gQmx1ZSBSb29mIE11c2ljIC8gSGlnaCBOb3J0aCBJbmMNCj4gUE8g Qm94IDIyMSAgR3JhbmQgTWFyYWlzLCBNSSAgNDk4MzkNCj4gcGhvbmU6ICsxLTkwNi00OTQtMjQz NA0KPiBlbWFpbDogaW1jZG9uYWxkQHNoYXJwbGFicy5jb20NCg== --===============0918190614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0918190614==--