From ltru-bounces@ietf.org Fri Jun 01 00:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtyVp-0001FD-99; Fri, 01 Jun 2007 00:13:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HtyVo-0001CU-R5 for ltru-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 00:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtyVo-0001C5-Dq for ltru@ietf.org; Fri, 01 Jun 2007 00:13:16 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtyVn-00069c-1L for ltru@ietf.org; Fri, 01 Jun 2007 00:13:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Ed9NAMYwuvz1v6v7o3X+tKjKWUwXET34afAExgNvp8ohwRdgxvzT/mAGdTwIsXG2; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.226] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HtyVm-0001gN-E2 for ltru@ietf.org; Fri, 01 Jun 2007 00:13:14 -0400 Message-ID: <000e01c7a403$ae11ae80$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 31 May 2007 21:16:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356b41af03b2e34ba8ac82c6033dd11c263350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.226 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded for your information. Randy > From: > To: > Sent: Thursday, May 31, 2007 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA > > > There are two (2) Internet-Draft cutoff dates for the 69th > IETF Meeting in Chicago, IL, USA: > > July 2nd: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 2nd at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 25th at 9:00 AM ET. > > July 9th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, July 9th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 23rd at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 69th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_69.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 11 03:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxeNs-0003cr-4i; Mon, 11 Jun 2007 03:32:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HxeNq-0003Wu-UI for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 03:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxeNq-0003SG-Bm for ltru@ietf.org; Mon, 11 Jun 2007 03:32:14 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxeNn-0000TS-Vg for ltru@ietf.org; Mon, 11 Jun 2007 03:32:14 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6E8841C0126 for ; Mon, 11 Jun 2007 09:32:11 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6A3201C0121 for ; Mon, 11 Jun 2007 09:32:11 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 67C8358ECE0 for ; Mon, 11 Jun 2007 09:32:11 +0200 (CEST) Date: Mon, 11 Jun 2007 09:32:11 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20070611073211.GA2807@nic.fr> MIME-Version: 1.0 X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ltru] Plans for www.langtag.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="===============1777123323==" Errors-To: ltru-bounces@ietf.org --===============1777123323== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable You may remember the discussion on the LTRU and IETF-languages mailing lists about marketing the standard, having a Web site and so on. At this time, I had set up a small site http://ltru.generic-nic.net/ to show what could be done.=20 Now, I'm decided to go a step further and I purchased langtag.net for that purpose (and I am of course ready to transfer it for free to any other holder, should the WG think it is better.) I would like http://www.langtag.net/ to be "blessed" as a reference Web site for the language tag activity at IETF and noticed for that at http://www.ietf.org/html.charters/ltru-charter.html. The difference between the old site and the new one are: * a better domain name :-) * a bit more content (such as the syndication feed for the registry), * the ability to give write-access to people other than me. --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbPp7QTZHl5fW0kYRAoMiAJ44RPyOGKlIYMrqjdX+f7vI0bqUXQCeP/t5 ZpL5hkGfNzJmRoxBkToyLeM= =0dtE -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- --===============1777123323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1777123323==-- From ltru-bounces@ietf.org Mon Jun 11 04:37:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxfPH-0006Mm-NH; Mon, 11 Jun 2007 04:37:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HxfPG-0006Ih-MK for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 04:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxfPG-0006I9-AB for ltru@ietf.org; Mon, 11 Jun 2007 04:37:46 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxfPE-000150-Fr for ltru@ietf.org; Mon, 11 Jun 2007 04:37:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5B8be2o009301 for ; Mon, 11 Jun 2007 17:37:41 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1a76_041e06d6_17f7_11dc_894e_0014221f2a2d; Mon, 11 Jun 2007 17:37:40 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53880) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 11 Jun 2007 17:35:51 +0900 Message-Id: <6.0.0.20.2.20070611173425.0a202710@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Jun 2007 17:37:05 +0900 To: Stephane Bortzmeyer , LTRU Working Group From: Martin Duerst Subject: Re: [Ltru] Plans for www.langtag.net In-Reply-To: <20070611073211.GA2807@nic.fr> References: <20070611073211.GA2807@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat on] Dear WG members, Please provide input (agreement or disagreement) on Stephane's proposal that the WG chairs ask the Area Director to add a link from the LTRU WG charter to http://www.langtag.net/. At 16:32 07/06/11, Stephane Bortzmeyer wrote: >I would like http://www.langtag.net/ to be "blessed" as a reference >Web site for the language tag activity at IETF and noticed for that at >http://www.ietf.org/html.charters/ltru-charter.html. [co-chair hat off] I think that this site provides very useful additional information for helping users of language tags, and I therefore personally support this request. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 11 14:31:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxoft-0006NV-0a; Mon, 11 Jun 2007 14:31:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hxofr-0006NQ-U3 for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxofr-0006NI-Ka for ltru@ietf.org; Mon, 11 Jun 2007 14:31:31 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxofn-0000xs-6z for ltru@ietf.org; Mon, 11 Jun 2007 14:31:31 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5BIVJCZ076214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 11:31:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=RM4le6WEIKdsnHnQLK++zCARBb/3YQXugdaqaOTOQNGTzgo7k/k7i9RKbP9KwLGk Message-ID: <466D94F8.9090000@yahoo-inc.com> Date: Mon, 11 Jun 2007 11:31:20 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Plans for www.langtag.net References: <20070611073211.GA2807@nic.fr> In-Reply-To: <20070611073211.GA2807@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Looks good. Sounds like a good idea to me. Addison Stephane Bortzmeyer wrote: > You may remember the discussion on the LTRU and IETF-languages mailing > lists about marketing the standard, having a Web site and so on. At > this time, I had set up a small site http://ltru.generic-nic.net/ to > show what could be done. > > Now, I'm decided to go a step further and I purchased langtag.net for > that purpose (and I am of course ready to transfer it for free to any > other holder, should the WG think it is better.) > > I would like http://www.langtag.net/ to be "blessed" as a reference > Web site for the language tag activity at IETF and noticed for that at > http://www.ietf.org/html.charters/ltru-charter.html. > > The difference between the old site and the new one are: > > * a better domain name :-) > > * a bit more content (such as the syndication feed for the registry), > > * the ability to give write-access to people other than me. > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 11 14:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxp36-0002Rs-TZ; Mon, 11 Jun 2007 14:55:32 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hxp35-0002Rn-KY for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxp35-0002Rf-B6 for ltru@ietf.org; Mon, 11 Jun 2007 14:55:31 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxp33-0005TW-UL for ltru@ietf.org; Mon, 11 Jun 2007 14:55:31 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1284464nzd for ; Mon, 11 Jun 2007 11:55:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Z9tTPy5NrVQ8qMCaUHZuuW1ukGJS42vXHtV60XXnEfGVZk7hhJjJ72CaZ4xE9De+LBNlILLIykHgCLaIyCq47CK9PmIebrU2XPSbDL4EXUbCHiomXGZu42jY0lPlE9C84q8iD3mxLyZfXHcSDiSEdoXT7Ylk4QfTu19uZEZ7vTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZYlrVRTa1dchpBguBrrupzrcmN2N+xZb0CxE/B4wc10WrUbDLq15cwam2wkAH1EUIMDq3G5LbdAA4TVdUVJRyImrRVtByDyQ50j8U8MvCTQlM3OyAEFnTDdkrkJHh6AeyO3fKRwA5CMzxNXthofMUiTqMqqKU0Ob5o9pdVQ1T9k= Received: by 10.115.111.1 with SMTP id o1mr5796002wam.1181588128639; Mon, 11 Jun 2007 11:55:28 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Mon, 11 Jun 2007 11:55:28 -0700 (PDT) Message-ID: <30b660a20706111155g369848cbl51d1b6b1b0fdb55a@mail.gmail.com> Date: Mon, 11 Jun 2007 11:55:28 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Plans for www.langtag.net In-Reply-To: <20070611073211.GA2807@nic.fr> MIME-Version: 1.0 References: <20070611073211.GA2807@nic.fr> X-Google-Sender-Auth: a83a9d724e5d8ef0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============0293336191==" Errors-To: ltru-bounces@ietf.org --===============0293336191== Content-Type: multipart/alternative; boundary="----=_Part_114121_22975614.1181588128597" ------=_Part_114121_22975614.1181588128597 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline How would site modifications work? Who would be able to modify? Mark On 6/11/07, Stephane Bortzmeyer wrote: > > You may remember the discussion on the LTRU and IETF-languages mailing > lists about marketing the standard, having a Web site and so on. At > this time, I had set up a small site http://ltru.generic-nic.net/ to > show what could be done. > > Now, I'm decided to go a step further and I purchased langtag.net for > that purpose (and I am of course ready to transfer it for free to any > other holder, should the WG think it is better.) > > I would like http://www.langtag.net/ to be "blessed" as a reference > Web site for the language tag activity at IETF and noticed for that at > http://www.ietf.org/html.charters/ltru-charter.html. > > The difference between the old site and the new one are: > > * a better domain name :-) > > * a bit more content (such as the syndication feed for the registry), > > * the ability to give write-access to people other than me. > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGbPp7QTZHl5fW0kYRAoMiAJ44RPyOGKlIYMrqjdX+f7vI0bqUXQCeP/t5 > ZpL5hkGfNzJmRoxBkToyLeM= > =0dtE > -----END PGP SIGNATURE----- > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_114121_22975614.1181588128597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline How would site modifications work? Who would be able to modify?

Mark

On 6/11/07, Stephane Bortzmeyer <bortzmeyer@nic.fr > wrote:
You may remember the discussion on the LTRU and IETF-languages mailing
lists about marketing the standard, having a Web site and so on. At
this time, I had set up a small site http://ltru.generic-nic.net/ to
show what could be done.

Now, I'm decided to go a step further and I purchased langtag.net for
that purpose (and I am of course ready to transfer it for free to any
other holder, should the WG think it is better.)

I would like http://www.langtag.net/ to be "blessed" as a reference
Web site for the language tag activity at IETF and noticed for that at
http://www.ietf.org/html.charters/ltru-charter.html.

The difference between the old site and the new one are:

* a better domain name :-)

* a bit more content (such as the syndication feed for the registry),

* the ability to give write-access to people other than me.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGbPp7QTZHl5fW0kYRAoMiAJ44RPyOGKlIYMrqjdX+f7vI0bqUXQCeP/t5
ZpL5hkGfNzJmRoxBkToyLeM=
=0dtE
-----END PGP SIGNATURE-----

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




--
Mark ------=_Part_114121_22975614.1181588128597-- --===============0293336191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0293336191==-- From ltru-bounces@ietf.org Mon Jun 11 16:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqUo-0006n0-PW; Mon, 11 Jun 2007 16:28:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HxqUn-0006eY-5f for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqU9-0002lT-Vv for ltru@ietf.org; Mon, 11 Jun 2007 16:27:34 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqOz-0001Eu-H1 for ltru@ietf.org; Mon, 11 Jun 2007 16:22:14 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7D661240826; Mon, 11 Jun 2007 22:22:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id A114C1127F; Mon, 11 Jun 2007 22:21:52 +0200 (CEST) Date: Mon, 11 Jun 2007 22:21:52 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20070611202152.GA12466@sources.org> References: <20070611073211.GA2807@nic.fr> <30b660a20706111155g369848cbl51d1b6b1b0fdb55a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20706111155g369848cbl51d1b6b1b0fdb55a@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group Subject: [Ltru] Re: Plans for www.langtag.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: , Errors-To: ltru-bounces@ietf.org On Mon, Jun 11, 2007 at 11:55:28AM -0700, Mark Davis wrote a message of 70 lines which said: > How would site modifications work? Who would be able to modify? Both the "how" and the "who" should be discussed among us, although the choices for "how" are limited as long as I manage the technical stuff :-) If an other hosting seems better, we can move the site elsewhere. How? Currently, the pages are written in XML, transformed to XHTML by a XSLT script. The automatic pages (like the registries in various formats) are automatically and nightly produced. More converters are welcome. The files are in a Subversion repository and I'm willing to open access to the module, as soon as I'll have learned how to grant access to a Subversion module but not to the others (which should not be too complicated). Anonymous read-only access seems a good idea, too. Who? We should discuss it. My personal opinion is that it should be limited to people who want to commit on the task (volunteers welcome). One-line patches and typo fixes can be sent by email to the webmaster. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 11 23:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxwka-00022F-UW; Mon, 11 Jun 2007 23:08:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HxwkZ-0001w7-Qk for ltru-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 23:08:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxwkZ-0001uA-Fw for ltru@ietf.org; Mon, 11 Jun 2007 23:08:55 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxwkX-0006Uv-6q for ltru@ietf.org; Mon, 11 Jun 2007 23:08:55 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070612030852.TYSD3934.mta11.adelphia.net@DGBP7M81> for ; Mon, 11 Jun 2007 23:08:52 -0400 Message-ID: <001001c7ac9f$0103c3f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Jun 2007 20:08:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Re: Plans for www.langtag.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: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Please provide input (agreement or disagreement) on Stephane's proposal > that the WG chairs ask the Area Director to add a link from the LTRU WG > charter to http://www.langtag.net/. If the co-chairs don't have any problem with it, then I support it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 12 00:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyJd-0005v9-7w; Tue, 12 Jun 2007 00:49:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HxyJc-0005v1-71 for ltru-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 00:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyJb-0005un-Re for ltru@ietf.org; Tue, 12 Jun 2007 00:49:11 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxyJX-0001l0-Vc for ltru@ietf.org; Tue, 12 Jun 2007 00:49:11 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5C4n44N023654 for ; Tue, 12 Jun 2007 13:49:04 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1ef6_3ed9fc18_18a0_11dc_8b76_0014221fa3c9; Tue, 12 Jun 2007 13:49:03 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52729) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Jun 2007 13:47:13 +0900 Message-Id: <6.0.0.20.2.20070612112452.0ae1d4a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 12 Jun 2007 11:28:05 +0900 To: Stephane Bortzmeyer , Mark Davis From: Martin Duerst Subject: Re: [Ltru] Re: Plans for www.langtag.net In-Reply-To: <20070611202152.GA12466@sources.org> References: <20070611073211.GA2807@nic.fr> <30b660a20706111155g369848cbl51d1b6b1b0fdb55a@mail.gmail.com> <20070611202152.GA12466@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] Two points: - We can probably not totally avoid discussion of details of this Web site here on this list, but I'd like to limit to an absolute minimum. - For people who might be affraid about the details, please note that if at any point the WG thinks that this Web site doesn't help LTRU anymore, we are free to remove the link from our charter page at any time. Regards, Martin. At 05:21 07/06/12, Stephane Bortzmeyer wrote: >On Mon, Jun 11, 2007 at 11:55:28AM -0700, > Mark Davis wrote > a message of 70 lines which said: > >> How would site modifications work? Who would be able to modify? > >Both the "how" and the "who" should be discussed among us, although >the choices for "how" are limited as long as I manage the technical >stuff :-) If an other hosting seems better, we can move the site >elsewhere. > >How? Currently, the pages are written in XML, transformed to XHTML by >a XSLT script. The automatic pages (like the registries in various >formats) are automatically and nightly produced. More converters are >welcome. > >The files are in a Subversion repository and I'm willing to open >access to the module, as soon as I'll have learned how to grant access >to a Subversion module but not to the others (which should not be too >complicated). Anonymous read-only access seems a good idea, too. > >Who? We should discuss it. My personal opinion is that it should be >limited to people who want to commit on the task (volunteers >welcome). One-line patches and typo fixes can be sent by email to the >webmaster. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 12 02:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy065-0003L5-LX; Tue, 12 Jun 2007 02:43:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hy064-0003L0-Cx for ltru-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 02:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy064-0003Ks-0H for ltru@ietf.org; Tue, 12 Jun 2007 02:43:20 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy062-0006UP-MF for ltru@ietf.org; Tue, 12 Jun 2007 02:43:19 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jV6vr4wqprnsS/dHlV1w2bhq0cTbVomtvJuLsQfRk4M+Hv5r3vnC37MS/AGJzCEf; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.81.23] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hy062-0000ON-6v for ltru@ietf.org; Tue, 12 Jun 2007 02:43:18 -0400 Message-ID: <004e01c7acbd$870e3480$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001001c7ac9f$0103c3f0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Plans for www.langtag.net Date: Mon, 11 Jun 2007 23:47:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356c64341299b7b86dfdd8506bb3f9b36ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, June 11, 2007 8:08 PM > Subject: [Ltru] Re: Plans for www.langtag.net > > Martin Duerst wrote: > > > Please provide input (agreement or disagreement) on Stephane's proposal > > that the WG chairs ask the Area Director to add a link from the LTRU WG > > charter to http://www.langtag.net/. > > If the co-chairs don't have any problem with it, then I support it. ... Although there are obviously some operational details still being worked out in this thread, as co-chair I have no problem with the idea of requesting the addition of a link to additional information to our WG web page. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 12 02:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0LQ-0008LT-4f; Tue, 12 Jun 2007 02:59:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hy0LP-0008LO-0R for ltru-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 02:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0LL-0008Ki-AG for ltru@ietf.org; Tue, 12 Jun 2007 02:59:07 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy0LK-00042l-1O for ltru@ietf.org; Tue, 12 Jun 2007 02:59:07 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 95EDD1C00FA; Tue, 12 Jun 2007 08:59:05 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 9127D1C00D9; Tue, 12 Jun 2007 08:59:04 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8322D58EB96; Tue, 12 Jun 2007 08:59:04 +0200 (CEST) Date: Tue, 12 Jun 2007 08:59:04 +0200 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20070612065904.GA11641@nic.fr> References: <20070611073211.GA2807@nic.fr> <30b660a20706111155g369848cbl51d1b6b1b0fdb55a@mail.gmail.com> <20070611202152.GA12466@sources.org> <6.0.0.20.2.20070612112452.0ae1d4a0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070612112452.0ae1d4a0@localhost> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group Subject: [Ltru] Re: Plans for www.langtag.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: , Errors-To: ltru-bounces@ietf.org On Tue, Jun 12, 2007 at 11:28:05AM +0900, Martin Duerst wrote a message of 52 lines which said: > - We can probably not totally avoid discussion of details of this > Web site here on this list, but I'd like to limit to an absolute > minimum. For instance, people who are specially interested in this Web site and eager to participate can contact me off-list and we can discuss the details together without bothering the WG with Subversion vs. Mercurial or HTTP's Accept-language vs. cookies :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 12 07:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4v1-00025O-A5; Tue, 12 Jun 2007 07:52:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hy4v0-00025H-LZ for ltru-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 07:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4v0-00024O-BI for ltru@ietf.org; Tue, 12 Jun 2007 07:52:14 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy4uy-0001OR-07 for ltru@ietf.org; Tue, 12 Jun 2007 07:52:14 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 12 Jun 2007 04:51:02 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 12 Jun 2007 04:52:11 -0700 From: Peter Constable To: Doug Ewell , LTRU Working Group Date: Tue, 12 Jun 2007 04:52:08 -0700 Subject: RE: [Ltru] Re: Plans for www.langtag.net Thread-Topic: [Ltru] Re: Plans for www.langtag.net Thread-Index: AcesnwbVWbi/sn70Rs+l9OnSUtuPWAASQ/aA Message-ID: References: <001001c7ac9f$0103c3f0$6401a8c0@DGBP7M81> In-Reply-To: <001001c7ac9f$0103c3f0$6401a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Peter Constable Program Manager * Font Technologies -----Original Message----- From: Doug Ewell [mailto:dewell@roadrunner.com] Sent: Monday, June 11, 2007 8:09 PM To: LTRU Working Group Subject: [Ltru] Re: Plans for www.langtag.net Martin Duerst wrote: > Please provide input (agreement or disagreement) on Stephane's proposal > that the WG chairs ask the Area Director to add a link from the LTRU WG > charter to http://www.langtag.net/. If the co-chairs don't have any problem with it, then I support it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 12 10:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7qW-0007eh-OB; Tue, 12 Jun 2007 10:59:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hy7qW-0007eE-7x for ltru-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 10:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7qV-0007e4-US for ltru@ietf.org; Tue, 12 Jun 2007 10:59:47 -0400 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy7oG-0006Rn-Ax for ltru@ietf.org; Tue, 12 Jun 2007 10:57:29 -0400 Received: (qmail 28697 messnum 3673769 invoked from network[194.125.174.28/ts09-028.dublin.indigo.ie]); 12 Jun 2007 14:15:50 -0000 Received: from ts09-028.dublin.indigo.ie (HELO ?194.125.174.28?) (194.125.174.28) by mail16.svc.cra.dublin.eircom.net (qp 28697) with SMTP; 12 Jun 2007 14:15:50 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <466D94F8.9090000@yahoo-inc.com> References: <20070611073211.GA2807@nic.fr> <466D94F8.9090000@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Plans for www.langtag.net Date: Tue, 12 Jun 2007 15:16:40 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 mg On 11 Jun 2007, at 18:31, scr=EDobh Addison Phillips: > Looks good. Sounds like a good idea to me. > > Addison > > Stephane Bortzmeyer wrote: > >> You may remember the discussion on the LTRU and IETF-languages =20 >> mailing >> lists about marketing the standard, having a Web site and so on. At >> this time, I had set up a small site http://ltru.generic-nic.net/ to >> show what could be done. Now, I'm decided to go a step further and =20= >> I purchased langtag.net for >> that purpose (and I am of course ready to transfer it for free to any >> other holder, should the WG think it is better.) >> I would like http://www.langtag.net/ to be "blessed" as a reference >> Web site for the language tag activity at IETF and noticed for =20 >> that at >> http://www.ietf.org/html.charters/ltru-charter.html. >> The difference between the old site and the new one are: >> * a better domain name :-) >> * a bit more content (such as the syndication feed for the registry), >> * the ability to give write-access to people other than me. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 13 11:05:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUPb-0002aw-H9; Wed, 13 Jun 2007 11:05:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HyUPZ-0002AP-F3 for ltru-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 11:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUPZ-00028u-4t for ltru@ietf.org; Wed, 13 Jun 2007 11:05:29 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUPX-0006xO-Rc for ltru@ietf.org; Wed, 13 Jun 2007 11:05:29 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070613150527.ZITJ28813.mta9.adelphia.net@DGBP7M81>; Wed, 13 Jun 2007 11:05:27 -0400 Message-ID: <002901c7adcc$463b1800$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 13 Jun 2007 08:05:25 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Dave Crocker Subject: [Ltru] Fw: Type I vs. Type II errors X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I thought I would pass along the following post by Dave Crocker from the IETF main list, as I think it applies to our work as well. More than a few of our ideas and proposals have gotten bogged down in objections of the form "someone might misunderstand this" or "someone might abuse this." These are often valid arguments, but they need to be put into perspective and weighed against the benefits. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ----- Original Message ----- From: "Dave Crocker" To: "Thomas Narten" Cc: ; Sent: Tuesday, June 12, 2007 9:52 Subject: Type I vs. Type II errors > > > Thomas Narten wrote: >> ... I do believe >> that withholding code points does prevent (in some, but not all cases) >> use of extensions that are potentially problematical. > > > > This goes to the heart of the current paradigm problem with IETF > decision-making: There is nearly exclusive concern about preventing all > cases of problems, no matter how occasional or minor, with little apparent > concern for the affirmative need to *faciliate* progress. > > For any interesting IETF effort, it is guaranteed that there are potential > problems with the outcome. > > So the mere citation of that potential cannot reasonably justify any > decision, such as denial or such as imposing a requirement for approval in > a process that is, by its nature, intended for providing coordination > rather than for demonstration community support. > > > The need is for balance, rather than the constant focus *only* on corner > cases. Corner cases are expensive... and rare. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 13 18:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HybMQ-00056V-0Q; Wed, 13 Jun 2007 18:30:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HybMO-00056P-CG for ltru-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 18:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HybMO-00056H-2n for ltru@ietf.org; Wed, 13 Jun 2007 18:30:40 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HybMM-0001ww-Hu for ltru@ietf.org; Wed, 13 Jun 2007 18:30:40 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=liEONDlO0u4MT4kkb+zSFe8sWGVBwLJe2nTzMtVr5SEIf8TpVwYE5EAcPYswERh9; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.170] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HybMM-0006c3-0L for ltru@ietf.org; Wed, 13 Jun 2007 18:30:38 -0400 Message-ID: <001d01c7ae0b$08829f80$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 13 Jun 2007 15:34:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356d9ade1db8bfa559a1d1096699304b0c4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.170 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ltru] Fw: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded from the ietf-languages@iana.org list Randy > From: "Mark Davis" > To: "John Cowan" > Cc: ; ; "Håvard Hjulstad" ; ; > Sent: Wednesday, June 13, 2007 2:55 PM > Subject: Re: ISO 639-2 decision: "mis" > > This is a mixed bag. On the one hand, it is great to finally get some > clarity on the intended meaning for the future. On the other hand, it means > that this code's meaning is intrinsically intended to narrow over time; as > each new code is added, its meaning narrows to cover fewer situations. This > is inherently *unstable*, and unsuitable for any situation that demands > stability, like BCP 47. > > Note that this still does not allow a narrowing of "mis" in BCP 47. However, > for this case I think it makes the case strong enough for completely > deprecating "mis" in BCP 47bis. > > Mark > > On 6/13/07, John Cowan wrote: > > > > Håvard Hjulstad scripsit: > > > > > The identifier mis, which has been part of ISO 639-2 since its > > > publication in 1998, has its scope changed from collective to special > > > purpose. > > > > > > The previously assigned "names" in English and French were > > > "miscellaneous languages" and "diverses, langues". These "names" > > > have been changed to uncoded languages and langues non codées. ... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 13 19:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyc9l-0004Qi-Lr; Wed, 13 Jun 2007 19:21:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hyc9k-0004Qc-4P for ltru-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 19:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyc9j-0004QT-R2 for ltru@ietf.org; Wed, 13 Jun 2007 19:21:39 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound4-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyc9i-0002qW-Fc for ltru@ietf.org; Wed, 13 Jun 2007 19:21:39 -0400 Received: from outbound4-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-sin-R.bigfish.com (Postfix) with ESMTP id B201E441C3C; Wed, 13 Jun 2007 23:21:36 +0000 (UTC) Received: from mail34-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound4-sin.bigfish.com (Postfix) with ESMTP id A5D7613D8088; Wed, 13 Jun 2007 23:21:36 +0000 (UTC) Received: from mail34-sin (localhost.localdomain [127.0.0.1]) by mail34-sin-R.bigfish.com (Postfix) with ESMTP id 7EB3A4980F1; Wed, 13 Jun 2007 23:21:36 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.195; Service: EHS Received: by mail34-sin (MessageSwitch) id 1181776896452603_3065; Wed, 13 Jun 2007 23:21:36 +0000 (UCT) Received: from usccimta01.spe.sony.com (unknown [64.14.251.195]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail34-sin.bigfish.com (Postfix) with ESMTP id DA468FF0054; Wed, 13 Jun 2007 23:21:35 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usccimta01.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007061316213393-783183 ; Wed, 13 Jun 2007 16:21:33 -0700 In-Reply-To: <001d01c7ae0b$08829f80$6601a8c0@oemcomputer> To: "Randy Presuhn" Subject: Re: [Ltru] Fw: ISO 639-2 decision: "mis" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 13 Jun 2007 16:19:28 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 06/13/2007 16:19:33, Serialize complete at 06/13/2007 16:19:33, Itemize by SMTP Server on USCCiMTA01/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/13/2007 04:21:33 PM, Serialize by Router on USCCiMTA01/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/13/2007 04:21:35 PM, Serialize complete at 06/13/2007 04:21:35 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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="===============0647136445==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0647136445== Content-Type: multipart/alternative; boundary="=_alternative 00804F2B882572F9_=" This is a multipart message in MIME format. --=_alternative 00804F2B882572F9_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hmm .... So now we have codes for uncoded languages, non-linguistic=20 languages, and unwritten scripts. I'm sure we'll be able to use these to=20 categorize unpublished books and offline web sites for non-geographical=20 regions. Karen "Randy Presuhn" =20 06/13/2007 03:34 PM To "LTRU Working Group" cc Subject [Ltru] Fw: ISO 639-2 decision: "mis" Hi - Forwarded from the ietf-languages@iana.org list Randy > From: "Mark Davis" > To: "John Cowan" > Cc: ; ; "H=E5vard Hjulstad"=20 ; ; > Sent: Wednesday, June 13, 2007 2:55 PM > Subject: Re: ISO 639-2 decision: "mis" > > This is a mixed bag. On the one hand, it is great to finally get some > clarity on the intended meaning for the future. On the other hand, it=20 means > that this code's meaning is intrinsically intended to narrow over time;=20 as > each new code is added, its meaning narrows to cover fewer situations.=20 This > is inherently *unstable*, and unsuitable for any situation that demands > stability, like BCP 47. > > Note that this still does not allow a narrowing of "mis" in BCP 47.=20 However, > for this case I think it makes the case strong enough for completely > deprecating "mis" in BCP 47bis. > > Mark > > On 6/13/07, John Cowan wrote: > > > > H=E5vard Hjulstad scripsit: > > > > > The identifier mis, which has been part of ISO 639-2 since its > > > publication in 1998, has its scope changed from collective to=20 special > > > purpose. > > > > > > The previously assigned "names" in English and French were > > > "miscellaneous languages" and "diverses, langues". These "names" > > > have been changed to uncoded languages and langues non cod=E9es. ... =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 00804F2B882572F9_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hmm .... So now we have codes for un= coded languages, non-linguistic languages, and unwritten scripts.  I'm sure we'll be able to use these to categorize unpublished books and offline web sites for non-geographical regions.

Karen



"Randy Presuhn&q= uot; <randy=5Fpresuhn@mindspring.com>

06/13/2007 03:34 PM

To
"LTRU Working Group" <l= tru@ietf.org>
cc
Subject
[Ltru] Fw: ISO 639-2 decision: "= ;mis"





Hi -

Forwarded from the ietf-languages@iana.org list

Randy

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "John Cowan" <cowan@ccil.org>
> Cc: <ietf-languages@iana.org>; <iso639-2@loc.gov>; "H= =E5vard Hjulstad" <HHj@standard.no>; <isojac@loc.gov>; <iso639@= dkuug.dk>
> Sent: Wednesday, June 13, 2007 2:55 PM
> Subject: Re: ISO 639-2 decision: "mis"
>
> This is a mixed bag. On the one hand, it is great to finally get some<= br> > clarity on the intended meaning for the future. On the other hand, it means
> that this code's meaning is intrinsically intended to narrow over time; as
> each new code is added, its meaning narrows to cover fewer situations. This
> is inherently *unstable*, and unsuitable for any situation that demand= s
> stability, like BCP 47.
>
> Note that this still does not allow a narrowing of "mis" in BCP 47. However,
> for this case I think it makes the case strong enough for completely > deprecating "mis" in BCP 47bis.
>
> Mark
>
> On 6/13/07, John Cowan <cowan@ccil.org> wrote:
> >
> > H=E5vard  Hjulstad scripsit:
> >
> > > The identifier mis, which has been part of ISO 639-2 since its
> > > publication in 1998, has its scope changed from collective to special
> > > purpose.
> > >
> > > The previously assigned "names" in English and French were
> > > "miscellaneous languages" and "diverses, langues". These "names"
> > > have been changed to uncoded languages and langues non cod= =E9es.
...




=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 00804F2B882572F9_=-- --===============0647136445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0647136445==-- From ltru-bounces@ietf.org Wed Jun 13 19:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycKv-0001JQ-P6; Wed, 13 Jun 2007 19:33:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HycKu-0001JL-3r for ltru-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 19:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycKt-0001JD-Qd for ltru@ietf.org; Wed, 13 Jun 2007 19:33:11 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HycKs-0005TK-DS for ltru@ietf.org; Wed, 13 Jun 2007 19:33:11 -0400 Received: from [10.72.66.72] (snvvpn-10-72-66-c72.corp.yahoo.com [10.72.66.72]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5DNWcec010388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 16:32:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=U7fZhgVbdlevfq4WvUrChHo1t9WHI8bNTQpP/XbrAHF1xNfZ1y448qbJrnoA5m72 Message-ID: <46707E95.50300@yahoo-inc.com> Date: Wed, 13 Jun 2007 16:32:37 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Mark Davis References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> In-Reply-To: <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp1.corp.yahoo.com id l5DNWcec010388 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ietf-languages@iana.org, =?UTF-8?B?dmFyZCBIanVsc3RhZA==?= , 'LTRU Working Group' , =?UTF-8?B?SMOl?= Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I note that this is what most people probably thought it meant in the first place. It is the only meaning that makes any sense and I cheer this clarification. Yes, the "meaning" of the 'mis' code is "narrowed" by additions of codes (assuming that codes added alway cover additional languages and not just finer gradations of existing ones, a case that isn't that uncommon)---if one takes a collective view of all content in the universe and assigns it a language tag today. But the definition of the 'mis' code is exactly what 4646bis is=20 currently set to say: stuff whose language is known (not 'und') but=20 which you can't otherwise tag, either because no code is available or=20 (more likely) the code isn't available to your application. The reasons for using the 'mis' code are limited and I suspect that we hardly ever see it in the wild nor will we in the future. As a tag it=20 only has meaning in the context of a fixed set of content and it has=20 essentially no meaning in language ranges except when working with sets=20 that are known to use it. As for deprecation, I think this is such a perverse interpretation of=20 the meaning of "narrows" that I can't see following through on it with=20 deprecation. Let's fix our draft text and move along. Currently the=20 draft for the next version of BCP 47 informs users why the subtag has=20 limited value and say that it SHOULD NOT be used. That's strong enough. Addison Mark Davis wrote: > This is a mixed bag. On the one hand, it is great to finally get some=20 > clarity on the intended meaning for the future. On the other hand, it=20 > means that this code's meaning is intrinsically intended to narrow over= =20 > time; as each new code is added, its meaning narrows to cover fewer=20 > situations. This is inherently *unstable*, and unsuitable for any=20 > situation that demands stability, like BCP 47. >=20 > Note that this still does not allow a narrowing of "mis" in BCP 47.=20 > However, for this case I think it makes the case strong enough for=20 > completely deprecating "mis" in BCP 47bis. >=20 > Mark >=20 > On 6/13/07, *John Cowan* > wrote= : >=20 > H=C3=A5vard Hjulstad scripsit: >=20 > > The identifier mis, which has been part of ISO 639-2 since its > > publication in 1998, has its scope changed from collective to sp= ecial > > purpose. > > > > The previously assigned "names" in English and French were > > "miscellaneous languages" and "diverses, langues". These "names" > > have been changed to uncoded languages and langues non cod=C3=A9= es. >=20 > Hurrah! >=20 > -- > In my last lifetime, John Cowan > I believed in > reincarnation; http://www.ccil.org/~cowan > in this lifetime, cowan@ccil.org > > I don't. --Thiagi > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages >=20 >=20 >=20 >=20 > --=20 > Mark >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 13 23:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyg8a-0002NE-IT; Wed, 13 Jun 2007 23:36:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hyg8Y-0002N6-UF for ltru-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 23:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyg8Y-0002My-JZ for ltru@ietf.org; Wed, 13 Jun 2007 23:36:42 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyg8X-00082W-BD for ltru@ietf.org; Wed, 13 Jun 2007 23:36:42 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070614033640.LGKD28813.mta9.adelphia.net@DGBP7M81>; Wed, 13 Jun 2007 23:36:40 -0400 Message-ID: <004d01c7ae35$383ba080$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , Date: Wed, 13 Jun 2007 20:36:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Addison completely. Unless Mark or someone else can find real-world examples of "mis" being used for a language that has its own ISO 639 code element and/or language tag -- not hypothetical examples or extrapolations or theory -- there is no "narrowing" argument. We have gone to great lengths to assert that "mis" isn't like the other collection codes, and now the JAC has made a decision which reflects that assertion. Let's make the appropriate change to the Registry and be done with it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 14 00:13:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hygi5-0008RA-LR; Thu, 14 Jun 2007 00:13:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hygi4-0008Qx-3I for ltru-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 00:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hygi3-0008Qp-Pm for ltru@ietf.org; Thu, 14 Jun 2007 00:13:23 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hygi2-0004Sv-El for ltru@ietf.org; Thu, 14 Jun 2007 00:13:23 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jJS/v2uBgeOy0VhsfRl563QAISeuJN+k4hkTJhkE1Lc1FGQpCc7E6qpZZE9ZU+va; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.44] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hygi1-0006ep-PK for ltru@ietf.org; Thu, 14 Jun 2007 00:13:22 -0400 Message-ID: <001901c7ae3a$e9468e80$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org><30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <46707E95.50300@yahoo-inc.com> Subject: Re: [Ltru] Re: ISO 639-2 decision: "mis" Date: Wed, 13 Jun 2007 21:17:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356c7fe4582a60d082aed81d0aa7738329a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "Mark Davis" > Cc: ; "vard Hjulstad" ; "'LTRU Working Group'" ; > Sent: Wednesday, June 13, 2007 4:32 PM > Subject: [Ltru] Re: ISO 639-2 decision: "mis" ... > But the definition of the 'mis' code is exactly what 4646bis is > currently set to say: stuff whose language is known (not 'und') but > which you can't otherwise tag, either because no code is available or > (more likely) the code isn't available to your application. "Because no code is available" is supported by the definition. Because "the code isn't available to your application" is not, in my opinion. > As for deprecation, I think this is such a perverse interpretation of > the meaning of "narrows" that I can't see following through on it with > deprecation. Let's fix our draft text and move along. Currently the > draft for the next version of BCP 47 informs users why the subtag has > limited value and say that it SHOULD NOT be used. That's strong enough. I could live with this. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 14 21:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0vl-00024F-J1; Thu, 14 Jun 2007 21:48:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hz0vk-00023c-7N for ltru-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 21:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0vj-00023Q-1R for ltru@ietf.org; Thu, 14 Jun 2007 21:48:51 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz0vh-0007q7-K3 for ltru@ietf.org; Thu, 14 Jun 2007 21:48:50 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 14 Jun 2007 18:47:35 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Thu, 14 Jun 2007 18:48:48 -0700 From: Peter Constable To: LTRU Working Group Date: Thu, 14 Jun 2007 18:48:47 -0700 Thread-Topic: RE: ISO 639-2 decision: "mis" Thread-Index: Aceu1/qbO1toI6AVSze5pN0TnGYoOAADrAxAAAIewJA= Message-ID: References: <003c01c7aec8$ca4c9fe0$6401a8c0@DGBP7M81> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ltru] RE: RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [re-sending to appropriate list] +1 to what Doug said. The name has changed; the intended semantic has not. I think we'd all agree it's not a good idea for anybody to use 'mis' in the= context of 4646bis. But I don't see why we need to do more than recommend = against its use except as a last resort: if an informed user feels that it'= s really what they need to do because they believe they know the language o= f their content and believe there is no subtag for it in the LSTR and feel = they need to declare that condition, that should be their prerogative. I would make some minor changes to the current text: from "The 'mis' (Miscellaneous) primary language subtag is derived from a collec= tive code and is used to identify linguistic content whose language is know= n but cannot otherwise be identified. It is commonly used when the range of= language tags is constrained or for languages not otherwise categorized...= " To "The 'mis' (Uncoded languages) primary language subtag is used to declare t= hat linguistic content is in a known language but that this language cannot= be indicated. It is typically used when the range of language tags support= ed in a given application context is constrained or for languages not other= wise categorized... " (I particular think we should avoid "commonly used": we don't want to sugge= st to the reader that it is commonly used. Peter -----Original Message----- From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@a= lvestrand.no] On Behalf Of Doug Ewell Sent: Thursday, June 14, 2007 2:13 PM To: ietf-languages@iana.org Subject: Re: ISO 639-2 decision: "mis" Kent Karlsson wrote: > I agree with Mark here. > > With this change, the use recommendation effectively hasn't changed, but > the coverage has, and it has changed in a way to make it inherently > unstable. I agree with Peter here. The intent of this code element has not changed, but the new name reflects the intent much better than the old name did. Th= e code element was always inherently unstable. > I see two ways of dealing with this: > > 1) Ignore the change, and let the coverage still be "all languages" (one = a > a time). Strongly, strongly opposed. > 2) Deprecate 'mis', and use 'und' ("all languages (or not a language)") i= n > its place (despite the different intention). 3) Deprecate "mis", and use "und" to mean "the language of this content is undetermined" as it has always meant. 4) Don't deprecate "mis", and use "und" to mean "the language of this content is undetermined" as it has always meant. Please stop trying to postulate a relationship between "mis" and "und" that isn't there. They have always meant two totally different things. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 02:14:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz54r-0006k5-KF; Fri, 15 Jun 2007 02:14:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hz54r-0006k0-3F for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 02:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz54q-0006hS-Nm for ltru@ietf.org; Fri, 15 Jun 2007 02:14:32 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz54o-00085l-VO for ltru@ietf.org; Fri, 15 Jun 2007 02:14:32 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Hl2qtRaRAkBqDttf6aXS77T06+9EPfkMAC88FWQXEJRiqFkUQlyRpL1nEnAIXG+d; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hz54o-0003TD-BM for ltru@ietf.org; Fri, 15 Jun 2007 02:14:30 -0400 Message-ID: <000801c7af15$02e84920$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 14 Jun 2007 23:18:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356aa2ce07981627c99d2f70a2e1fb0b0a2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded for your information. Randy > From: > To: > Sent: Thursday, June 14, 2007 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA > > There are two (2) Internet-Draft cutoff dates for the 69th > IETF Meeting in Chicago, IL, USA: > > July 2nd: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 2nd at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 25th at 9:00 AM ET. > > July 9th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, July 9th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 23rd at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 69th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_69.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 11:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDym-0004J3-BU; Fri, 15 Jun 2007 11:44:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzDyl-0004Iy-4B for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 11:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDyk-0004In-Qi for ltru@ietf.org; Fri, 15 Jun 2007 11:44:50 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDyj-0006ba-8N for ltru@ietf.org; Fri, 15 Jun 2007 11:44:50 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 15 Jun 2007 16:44:46 +0100 From: "Debbie Garside" To: , Date: Fri, 15 Jun 2007 16:44:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Aceu1/qbO1toI6AVSze5pN0TnGYoOAADrAxAAB7EplA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Message-Id: Cc: 'LTRU Working Group' Subject: [Ltru] RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Peter and Doug. However, I would change Peter's proposed text to read as follows: "The 'mis' (Uncoded languages) primary language subtag MAY be used when there is an identified need to declare that linguistic content is in a known language that is not currently supported within the Registry by any other language subtag or when the range of language tags supported in a given application are constrained. " Debbie Garside > "The 'mis' (Uncoded languages) primary language subtag is > used to declare that linguistic content is in a known > language but that this language cannot be indicated. It is > typically used when the range of language tags supported in a > given application context is constrained or for languages not > otherwise categorized... " > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of > Peter Constable > Sent: 15 June 2007 02:11 > To: ietf-languages@iana.org > Subject: RE: ISO 639-2 decision: "mis" > > +1 to what Doug said. The name has changed; the intended > semantic has not. > > I think we'd all agree it's not a good idea for anybody to > use 'mis' in the context of 4646bis. But I don't see why we > need to do more than recommend against its use except as a > last resort: if an informed user feels that it's really what > they need to do because they believe they know the language > of their content and believe there is no subtag for it in the > LSTR and feel they need to declare that condition, that > should be their prerogative. > > I would make some minor changes to the current text: from > > "The 'mis' (Miscellaneous) primary language subtag is derived > from a collective code and is used to identify linguistic > content whose language is known but cannot otherwise be > identified. It is commonly used when the range of language > tags is constrained or for languages not otherwise categorized... " > > To > > "The 'mis' (Uncoded languages) primary language subtag is > used to declare that linguistic content is in a known > language but that this language cannot be indicated. It is > typically used when the range of language tags supported in a > given application context is constrained or for languages not > otherwise categorized... " > > (I particular think we should avoid "commonly used": we don't > want to suggest to the reader that it is commonly used. > > Peter > > > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Doug Ewell > Sent: Thursday, June 14, 2007 2:13 PM > To: ietf-languages@iana.org > Subject: Re: ISO 639-2 decision: "mis" > > Kent Karlsson wrote: > > > I agree with Mark here. > > > > With this change, the use recommendation effectively hasn't > changed, > > but the coverage has, and it has changed in a way to make it > > inherently unstable. > > I agree with Peter here. The intent of this code element has > not changed, but the new name reflects the intent much better > than the old name did. The code element was always > inherently unstable. > > > I see two ways of dealing with this: > > > > 1) Ignore the change, and let the coverage still be "all languages" > > (one a a time). > > Strongly, strongly opposed. > > > 2) Deprecate 'mis', and use 'und' ("all languages (or not a > > language)") in its place (despite the different intention). > > 3) Deprecate "mis", and use "und" to mean "the language of > this content is undetermined" as it has always meant. > > 4) Don't deprecate "mis", and use "und" to mean "the language > of this content is undetermined" as it has always meant. > > Please stop trying to postulate a relationship between "mis" > and "und" that isn't there. They have always meant two > totally different things. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 12:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEru-0005BA-LI; Fri, 15 Jun 2007 12:41:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzErs-0005B5-SQ for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 12:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzErs-0005Ax-Iu for ltru@ietf.org; Fri, 15 Jun 2007 12:41:48 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzErr-0000sO-79 for ltru@ietf.org; Fri, 15 Jun 2007 12:41:48 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Jj/zUyNDEqFnAjlP5/xDULCb0scmh9sFpUaAFAA1WRM10IWF9qRfTwBMQo0s7wha; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzErq-0001uQ-Ec for ltru@ietf.org; Fri, 15 Jun 2007 12:41:46 -0400 Message-ID: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 09:45:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356effeceb79f6ea4554caabf478b80d625350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Debbie Garside" > To: ; > Cc: "'LTRU Working Group'" > Sent: Friday, June 15, 2007 8:44 AM > Subject: [Ltru] RE: ISO 639-2 decision: "mis" > > I agree with Peter and Doug. However, I would change Peter's proposed text > to read as follows: > > "The 'mis' (Uncoded languages) primary language subtag MAY be used when > there is an identified need to declare that linguistic content is in a known > language that is not currently supported within the Registry by any other > language subtag or when the range of language tags supported in a given > application are constrained. " ... I disagree with the phrase "or when the range of language tags supported in a given application are constrained." If the application knows what language it is, it should use the correct tag, if one exists. If the application doesn't know what language is in use, "und" would be correct. I also suggest that we consider what RFC 2119 says regarding "MAY" versus "SHOULD NOT" qualifiers for features: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 12:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF7J-000832-Bi; Fri, 15 Jun 2007 12:57:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzF7H-0007zv-IQ for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 12:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF7G-0007w2-PQ for ltru@ietf.org; Fri, 15 Jun 2007 12:57:42 -0400 Received: from mu-out-0910.google.com ([209.85.134.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzEw8-0001ES-Er for ltru@ietf.org; Fri, 15 Jun 2007 12:46:13 -0400 Received: by mu-out-0910.google.com with SMTP id w8so988905mue for ; Fri, 15 Jun 2007 09:46:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ezzZD+f7h5bEyTXxgRQ5tzLhWvMOtbAx64Wg+7ygSdmXiMUxAeiwjrZjIsRqG8r2p53qn5X+3g5tn7LEifJFafMiHYjyxezC/d6pCQXBsFzj5hGafwWm01J89iNVW4joQ6EpRr0/W5/v7eObIODxD8xj1s8UXpq2f/4iJ1ZvdB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nV5HwzoeOOC2idtZhkoMYnmKnDyPIGlaNda4nX/6asxQF4pltrHn2DwpI5EklXwM3iDmfFMdBritBkFgfoSpVQ1mKT6Wsy0Hrf83Rve3PESjJMo4UgoPs6Wvim++zAABYsBM3QXdUg+/Snj1mDKxQ0L87A2sS1P7XSnlAlJcKBo= Received: by 10.82.170.2 with SMTP id s2mr6049536bue.1181925971429; Fri, 15 Jun 2007 09:46:11 -0700 (PDT) Received: by 10.82.185.13 with HTTP; Fri, 15 Jun 2007 09:46:11 -0700 (PDT) Message-ID: <41a006820706150946h56365255nbbd1ddb203e32f64@mail.gmail.com> Date: Fri, 15 Jun 2007 18:46:11 +0200 From: GerardM To: "Randy Presuhn" Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" In-Reply-To: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0071688429==" Errors-To: ltru-bounces@ietf.org --===============0071688429== Content-Type: multipart/alternative; boundary="----=_Part_53410_20681728.1181925971356" ------=_Part_53410_20681728.1181925971356 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, Standards have a tendency to lag behind what is accepted to be true. When a standard does not acknowledge a specific language of linguistic entity yet because it is not in that version of the standard, a tag could be not available because a specific version of standard has not been ratified yet. Thanks, Gerard On 6/15/07, Randy Presuhn wrote: > > Hi - > > As a technical contributor... > > > From: "Debbie Garside" > > To: ; > > Cc: "'LTRU Working Group'" > > Sent: Friday, June 15, 2007 8:44 AM > > Subject: [Ltru] RE: ISO 639-2 decision: "mis" > > > > I agree with Peter and Doug. However, I would change Peter's proposed > text > > to read as follows: > > > > "The 'mis' (Uncoded languages) primary language subtag MAY be used when > > there is an identified need to declare that linguistic content is in a > known > > language that is not currently supported within the Registry by any > other > > language subtag or when the range of language tags supported in a given > > application are constrained. " > ... > > I disagree with the phrase "or when the range of language tags supported > in > a given application are constrained." If the application knows what > language > it is, it should use the correct tag, if one exists. If the application > doesn't > know what language is in use, "und" would be correct. > > I also suggest that we consider what RFC 2119 says regarding "MAY" versus > "SHOULD NOT" qualifiers for features: > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_53410_20681728.1181925971356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
Standards have a tendency to lag behind what is accepted to be true. When a standard does not acknowledge a specific language of linguistic entity yet because it is not in that version of the standard, a tag could be not available because a specific version of standard has not been ratified yet.
Thanks,
     Gerard

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

As a technical contributor...

> From: "Debbie Garside" < debbie@ictmarketing.co.uk>
> To: <petercon@microsoft.com>; <ietf-languages@iana.org>
> Cc: "'LTRU Working Group'" < ltru@ietf.org>
> Sent: Friday, June 15, 2007 8:44 AM
> Subject: [Ltru] RE: ISO 639-2 decision: "mis"
>
> I agree with Peter and Doug.  However, I would change Peter's proposed text
> to read as follows:
>
>  "The 'mis' (Uncoded languages) primary language subtag MAY be used when
> there is an identified need to declare that linguistic content is in a known
> language that is not currently supported within the Registry by any other
> language subtag or when the range of language tags supported in a given
> application are constrained. "
...

I disagree with the phrase "or when the range of language tags supported in
a given application are constrained."  If the application knows what language
it is, it should use the correct tag, if one exists.  If the application doesn't
know what language is in use, "und" would be correct.

I also suggest that we consider what RFC 2119 says regarding "MAY" versus
"SHOULD NOT" qualifiers for features:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Randy



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

------=_Part_53410_20681728.1181925971356-- --===============0071688429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0071688429==-- From ltru-bounces@ietf.org Fri Jun 15 13:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFDI-0007EJ-9f; Fri, 15 Jun 2007 13:03:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzFDG-0007ED-NA for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 13:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFDG-0007E5-Dk for ltru@ietf.org; Fri, 15 Jun 2007 13:03:54 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFDF-000696-6T for ltru@ietf.org; Fri, 15 Jun 2007 13:03:54 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qZDkk+RvZWwJgLyssIgMVo9dp6/l2e7z3jlmYX+AobXnmjMli+2LJ5sxlWKo6T5p; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzFDE-0000rC-Ph for ltru@ietf.org; Fri, 15 Jun 2007 13:03:53 -0400 Message-ID: <004e01c7af6f$bb05d220$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> <41a006820706150946h56365255nbbd1ddb203e32f64@mail.gmail.com> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 10:08:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356a48e60ae343d425059ccde40fdcf9123350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As technical contributor... > From: "GerardM" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Friday, June 15, 2007 9:46 AM > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" > > Hoi, > Standards have a tendency to lag behind what is accepted to be true. When a > standard does not acknowledge a specific language of linguistic entity yet > because it is not in that version of the standard, a tag could be not > available because a specific version of standard has not been ratified yet. This is the *sole* case where "mis" would be appropriate, However, I would also argue that if I were a field linguist collecting data on previously unknown languages (the most likely scenario in which one could legitimately encounter a need for "mis") that I'd be better off using private-use subtags as an *interim* measure for my data. With private-use subtags I'd know which was which. With "mis" I'd have thrown everything into one basket. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 14:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG6A-000641-Ik; Fri, 15 Jun 2007 14:00:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzG69-00063v-KQ for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG69-00063n-An for ltru@ietf.org; Fri, 15 Jun 2007 14:00:37 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzG67-0000VI-W6 for ltru@ietf.org; Fri, 15 Jun 2007 14:00:37 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5FI096m074907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 11:00:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=jE6h//l8qy/lueTec+suM44N5LGH/UV4jcvh1bSB0Wky4vIyyWzVw2SR0WvezxeB Message-ID: <4672D3A9.5040804@yahoo-inc.com> Date: Fri, 15 Jun 2007 11:00:09 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: John Cowan References: <20070615100003.4A9AB259727@eikenes.alvestrand.no> <004c01c7af59$df123110$6401a8c0@DGBP7M81> <20070615152643.GA8769@mercury.ccil.org> In-Reply-To: <20070615152643.GA8769@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ietf-languages@iana.org, Doug Ewell , 'LTRU Working Group' Subject: [Ltru] Re: Variant tags for sl-rozaj: History and preliminaries Draft of message X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> My gut feeling is that this is governed by the word "prefix": all of the >> subtags that make up the Prefix field for Subtag X must appear in the >> tag BEFORE Subtag X is added. I can see how a language lawyer might >> argue this point, though. > > Yes. Let's fix this bug in 4646bis. > The meaning of prefix really should be clear in the text. When John says "let's fix this bug", I presume he means that we should explicitly say that all prefix subtags must appear to the left of the variant in question. To that, I can say: +1 Copying ltru, where this discussion should continue. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 14:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG7o-0006Hz-O3; Fri, 15 Jun 2007 14:02:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzG7o-0006Ht-3p for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG7n-0006Hl-QT for ltru@ietf.org; Fri, 15 Jun 2007 14:02:19 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzG7m-0000jg-E9 for ltru@ietf.org; Fri, 15 Jun 2007 14:02:19 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 11:01:02 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Fri, 15 Jun 2007 11:02:16 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 15 Jun 2007 11:02:14 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: AcevbBh85MQPZsQwQ3OcYRFf3AeDEQACkZhw Message-ID: References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> In-Reply-To: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy: MARC is an application context -- an application of language tags, not an a= pplication in the sense of a piece software. In that application context, o= nly IDs from 639-2 can be used: that is a constraint on the range of langua= ge tags supported in that application context. Whether a user or a software= process is assigning tags, the options are not necessarily binary, as you = suggest: in that application context it is entirely possible for the langua= ge of given content to be known but not to be within the restricted set per= mitted by MARC. Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, June 15, 2007 9:46 AM To: LTRU Working Group Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Hi - As a technical contributor... > From: "Debbie Garside" > To: ; > Cc: "'LTRU Working Group'" > Sent: Friday, June 15, 2007 8:44 AM > Subject: [Ltru] RE: ISO 639-2 decision: "mis" > > I agree with Peter and Doug. However, I would change Peter's proposed te= xt > to read as follows: > > "The 'mis' (Uncoded languages) primary language subtag MAY be used when > there is an identified need to declare that linguistic content is in a kn= own > language that is not currently supported within the Registry by any other > language subtag or when the range of language tags supported in a given > application are constrained. " ... I disagree with the phrase "or when the range of language tags supported in a given application are constrained." If the application knows what langua= ge it is, it should use the correct tag, if one exists. If the application do= esn't know what language is in use, "und" would be correct. I also suggest that we consider what RFC 2119 says regarding "MAY" versus "SHOULD NOT" qualifiers for features: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 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 Fri Jun 15 14:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGCF-0000Yl-Gv; Fri, 15 Jun 2007 14:06:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzGCE-0000Xl-5m for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGCD-0000XA-Lp for ltru@ietf.org; Fri, 15 Jun 2007 14:06:53 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGC5-0001m4-W2 for ltru@ietf.org; Fri, 15 Jun 2007 14:06:53 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 11:05:31 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Fri, 15 Jun 2007 11:06:44 -0700 From: Peter Constable To: Randy Presuhn , LTRU Working Group Date: Fri, 15 Jun 2007 11:06:40 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: Acevbyn3tiOXDRD5S0yrOu7W7JdBEgACD8Pg Message-ID: References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> <41a006820706150946h56365255nbbd1ddb203e32f64@mail.gmail.com> <004e01c7af6f$bb05d220$6601a8c0@oemcomputer> In-Reply-To: <004e01c7af6f$bb05d220$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org What you say wrt private-use subtags being better than 'mis' is true if the= application context is a linguist collecting field data. It may not be tru= e in all application contexts, however. In particular, it is NOT the practi= ce in MARC, nor would it be in the interest of that standard to start defin= ing private-use IDs for use in MARC records. (It may make sense for a local= implementation of MARC, however.) Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, June 15, 2007 10:08 AM To: LTRU Working Group Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Hi - As technical contributor... > From: "GerardM" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Friday, June 15, 2007 9:46 AM > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" > > Hoi, > Standards have a tendency to lag behind what is accepted to be true. When= a > standard does not acknowledge a specific language of linguistic entity ye= t > because it is not in that version of the standard, a tag could be not > available because a specific version of standard has not been ratified ye= t. This is the *sole* case where "mis" would be appropriate, However, I would also argue that if I were a field linguist collecting data= on previously unknown languages (the most likely scenario in which one could l= egitimately encounter a need for "mis") that I'd be better off using private-use subtag= s as an *interim* measure for my data. With private-use subtags I'd know which = was which. With "mis" I'd have thrown everything into one basket. 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 Fri Jun 15 14:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGGv-0002yo-Pp; Fri, 15 Jun 2007 14:11:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzGGu-0002xr-DA for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGGu-0002xe-3M for ltru@ietf.org; Fri, 15 Jun 2007 14:11:44 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGGs-0002Y2-Ow for ltru@ietf.org; Fri, 15 Jun 2007 14:11:44 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aIqZoKfqQoOnyfAEnsxXeFtfm+JMXi3PMap0xkdGMxm/Sk/q26lDxe+zvEEGH8dE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzGGp-0004cH-S5 for ltru@ietf.org; Fri, 15 Jun 2007 14:11:40 -0400 Message-ID: <00f301c7af79$32c19700$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 11:15:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93564ce31004e67b0e26ac760df5d5e2578c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 11:02 AM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > MARC is an application context -- an application of language tags, not an > application in the sense of a piece software. In that application context, only > IDs from 639-2 can be used: that is a constraint on the range of language tags > supported in that application context. As such, I'd argue that these constraints mean it isn't an application of BCP 47. > Whether a user or a software process is assigning tags, the options are not > necessarily binary, as you suggest: in that application context it is entirely possible > for the language of given content to be known but not to be within the restricted set > permitted by MARC. These things might be called tags, and they might even be a subset of the set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* an application of BCP 47, and, consequently, is not our problem. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 14:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGOD-0003hn-FP; Fri, 15 Jun 2007 14:19:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzGOB-0003ZO-SB for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGOB-0003XL-Hy for ltru@ietf.org; Fri, 15 Jun 2007 14:19:15 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGOA-0003Zj-6S for ltru@ietf.org; Fri, 15 Jun 2007 14:19:15 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5FIJ8hx077055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 11:19:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=nSivVKyQ/R/RIWo/x4sJCLbe7aFtnIK/B+6gl3EMj5Z4NmjFjPYiaIDuEKPDRlAB Message-ID: <4672D81B.4090700@yahoo-inc.com> Date: Fri, 15 Jun 2007 11:19:07 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> In-Reply-To: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > > I disagree with the phrase "or when the range of language tags supported in > a given application are constrained." If the application knows what language > it is, it should use the correct tag, if one exists. If the application doesn't > know what language is in use, "und" would be correct. That's nice in theory. But some applications use a subset of tags (I used the MARC21 example in the text) and then transmit them through another system (where the larger range of RFC 4646 is available). Those systems only know that the content is 'mis' (because it is tagged that way) and not what the miscellaneous language happens to be. We don't define what subtags applications are capable of supporting or required to support elsewhere. We should focus on providing appropriate guidance (which is not to use the subtag). I note that Peter's use of MAY doesn't reflect the current draft. I propose that we modify the draft to say the following. Please note: the paragraph format is consistent with the other items in that section. I think that folks should glance at that text when proposing edits. -- The 'mis' (Uncoded) primary language subtag is used to identify linguistic content whose language is known but cannot otherwise be identified. It is intended for use when the range of language tags is constrained or for languages not otherwise categorized. It SHOULD NOT be used except when other means of identifying the language are not available. For example, a library application might be limited to the set of subtags defined for use by the [MARC21] standard. The 'mis' subtag might be used by this application for languages not included in that set. -- Comments? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 14:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGog-0005gk-8A; Fri, 15 Jun 2007 14:46:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzGoe-0005gR-Qn for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGoe-0005gD-H0 for ltru@ietf.org; Fri, 15 Jun 2007 14:46:36 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGod-0007Ty-6z for ltru@ietf.org; Fri, 15 Jun 2007 14:46:36 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KCYB2YLzyu3bXNipyr9gbRhuB5lh7898IAvvVN2vWkc0YMOppi9Q9uUwX+/fs2P4; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzGoc-0000JI-I3 for ltru@ietf.org; Fri, 15 Jun 2007 14:46:34 -0400 Message-ID: <010c01c7af7e$13f1c3e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> <4672D81B.4090700@yahoo-inc.com> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 11:50:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93567591c007630e9094007fded893320713350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Friday, June 15, 2007 11:19 AM > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" > > Randy Presuhn wrote: > > > > I disagree with the phrase "or when the range of language tags supported in > > a given application are constrained." If the application knows what language > > it is, it should use the correct tag, if one exists. If the application doesn't > > know what language is in use, "und" would be correct. > > That's nice in theory. But some applications use a subset of tags (I > used the MARC21 example in the text) and then transmit them through > another system (where the larger range of RFC 4646 is available). Those > systems only know that the content is 'mis' (because it is tagged that > way) and not what the miscellaneous language happens to be. This is an interworking problem, where data from a non-BCP 47 environment needs to travel through a BCP 47 one. In this particular case, things work out. But as for the proposed text... ... > The 'mis' (Uncoded) primary language subtag is used to identify > linguistic content whose language is known but cannot otherwise be > identified. The phrase "known but cannot otherwise be identified" is a bit obscure. I suggest replacing it with "known but for which no subtag has been defined." > It is intended for use when the range of language tags is > constrained or for languages not otherwise categorized. This only makes sense if we somehow want to shoehorn MARC into being BCP 47 compliant. I propose deleting this sentence. > It SHOULD NOT be > used except when other means of identifying the language are not > available. Minor edit: I think the would be much easier to read if worded: It SHOULD NOT be used when other means of identifying the language are available. > For example, a library application might be limited to the > set of subtags defined for use by the [MARC21] standard. The 'mis' > subtag might be used by this application for languages not included in > that set. I think this is not a good example of a BCP 47 use of "mis". Although I think it's quite reasonable and fortunate that MARC data could traverse a BCP 47 environment unharmed (and this falls under the "SHOULD NOT" rules of RFC 2119), I do *not* think we should stretch things to where we'd claim that MARC is "compliant". It's just a happy circumstance that data encoded under the MARC regime is still meaningful when interpreted under BCP 47 rules, unless tagged with "mis". Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 15:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH65-00063u-M9; Fri, 15 Jun 2007 15:04:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzH63-00063o-Tv for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH63-00063d-KN for ltru@ietf.org; Fri, 15 Jun 2007 15:04:35 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzH63-0002E5-A5 for ltru@ietf.org; Fri, 15 Jun 2007 15:04:35 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 12:03:19 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Fri, 15 Jun 2007 12:04:34 -0700 From: Peter Constable To: Randy Presuhn , LTRU Working Group Date: Fri, 15 Jun 2007 12:04:33 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: AceveKT0krkRw89JQWSFlmR0QeqSxgABnURA Message-ID: References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> <00f301c7af79$32c19700$6601a8c0@oemcomputer> In-Reply-To: <00f301c7af79$32c19700$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You appear to be assuming that for something to qualify as "an application = of BCP 47" it must support all tags defined by BCP 47. I would certainly agree that a BCP 47-conformant parser must fully support = the syntax that's defined, and for a BCP-47 validator to validate all and o= nly tags that are defined in relation to a given snapshot of the registry. But I see no reason why a higher-level protocol cannot restrict the set of = tags it accepts and still be considered "an application of BCP 47". I would= n't be surprised if was actually common for people to create higher-level p= rotocols that normatively reference BCP 47 but that define some subset of t= ags that are permitted. What is the problem in saying those are "applicatio= ns of BCP 47"? It would certainly be getting applied in those cases. Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, June 15, 2007 11:16 AM To: LTRU Working Group Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Hi - As a technical contributor... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 11:02 AM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > MARC is an application context -- an application of language tags, not an > application in the sense of a piece software. In that application context= , only > IDs from 639-2 can be used: that is a constraint on the range of language= tags > supported in that application context. As such, I'd argue that these constraints mean it isn't an application of B= CP 47. > Whether a user or a software process is assigning tags, the options are n= ot > necessarily binary, as you suggest: in that application context it is ent= irely possible > for the language of given content to be known but not to be within the re= stricted set > permitted by MARC. These things might be called tags, and they might even be a subset of the set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* a= n application of BCP 47, and, consequently, is not our problem. 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 Fri Jun 15 15:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH7r-0006rW-OQ; Fri, 15 Jun 2007 15:06:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzH7q-0006n1-2N for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH7p-0006mt-PB for ltru@ietf.org; Fri, 15 Jun 2007 15:06:25 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzH7n-0002eS-BO for ltru@ietf.org; Fri, 15 Jun 2007 15:06:25 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5FJ680r082263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 12:06:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kB+YnheuMCVnMPYyNAgN9o9Mhpk8pDAababgrYc7X5pI4G/Y7NxitA1zwFLJvhWC Message-ID: <4672E31F.2040806@yahoo-inc.com> Date: Fri, 15 Jun 2007 12:06:07 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "'LTRU Working Group'" Subject: Re: [Ltru] Re: Variant tags for sl-rozaj: History and preliminaries Draft of message References: <20070615100003.4A9AB259727@eikenes.alvestrand.no> <004c01c7af59$df123110$6401a8c0@DGBP7M81> <20070615152643.GA8769@mercury.ccil.org> <4672D3A9.5040804@yahoo-inc.com> In-Reply-To: <4672D3A9.5040804@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On this issue... I do note that the section on variants currently says: -- Variant subtag records in the language subtag registry MAY include one or more 'Prefix' fields, which indicate the language tag or tags that would make a suitable prefix (with other subtags, as appropriate) in forming a language tag with the variant. -- The word "suitable prefix" at least conveys some intention for the subtags to fall to the left of the variant in question. I modified this to say: -- Variant subtag records in the language subtag registry MAY include one or more 'Prefix' fields. The 'Prefix' indicates the language tag or tags that would make a suitable prefix (with other subtags, as appropriate) in forming a language tag with the variant. That is, each of the subtags in the prefix MUST appear before the variant in a valid tag. -- Note here the use of the word 'valid' in conjunction with MUST. We required the prefix to be present (using extended language range rules), but didn't make the position of the subtags clear in the section on classes of conformance. I added the [[[marked sentence]]] in this snippet from that section: -- For each subtag that has a 'Prefix' field in the registry, the Prefix matches the language tag using Extended Filtering. That is, each subtag in the Prefix is present in the tag and in the same order. [[[Furthermore, all of the Prefix's subtags MUST appear before the subtag.]]] -- I also modified the text in extended language subtag to say: -- Each extended language subtag MUST only be used in tag immediately following the exact sequence of subtags that appears in the 'Prefix' field in its registry record. -- In the section on registry format, we had: -- Prefix's field-body contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well. This field MUST only appear in records whose 'Type' field-body is 'variant' or 'extlang'. -- I changed this to read: -- Prefix's field-body contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well. The Prefix's subtags MUST appear before the subtag for the tag to be considered valid. This field MUST only appear in records whose 'Type' field-body is 'variant' or 'extlang'. -- In the subsection on Prefix I made an edit to say: -- The field-body of the 'Prefix' field consists of an extended language range whose subtags are appropriate to use with this subtag: each of the subtags in one of the subtag's Prefix fields MUST appear before the variant in a valid tag. -- Note again the use of the term 'valid' corresponds to MUST appropriately. Comments? Addison Addison Phillips wrote: > John Cowan wrote: >> >>> My gut feeling is that this is governed by the word "prefix": all of >>> the subtags that make up the Prefix field for Subtag X must appear in >>> the tag BEFORE Subtag X is added. I can see how a language lawyer >>> might argue this point, though. >> >> Yes. Let's fix this bug in 4646bis. >> > > > The meaning of prefix really should be clear in the text. When John says > "let's fix this bug", I presume he means that we should explicitly say > that all prefix subtags must appear to the left of the variant in question. > > To that, I can say: +1 > > Copying ltru, where this discussion should continue. > > Addison > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 15:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHBD-0007UJ-Sm; Fri, 15 Jun 2007 15:09:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzHBC-0007UD-Ak for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHBC-0007U5-18 for ltru@ietf.org; Fri, 15 Jun 2007 15:09:54 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound5-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHBB-0003Nt-CY for ltru@ietf.org; Fri, 15 Jun 2007 15:09:54 -0400 Received: from outbound5-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-blu-R.bigfish.com (Postfix) with ESMTP id D0DFA1108039; Fri, 15 Jun 2007 19:09:52 +0000 (UTC) Received: from mail43-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound5-blu.bigfish.com (Postfix) with ESMTP id AFD2EB30057; Fri, 15 Jun 2007 19:09:52 +0000 (UTC) Received: from mail43-blu (localhost.localdomain [127.0.0.1]) by mail43-blu-R.bigfish.com (Postfix) with ESMTP id E11CEAC0235; Fri, 15 Jun 2007 19:09:51 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail43-blu (MessageSwitch) id 1181934589660157_18265; Fri, 15 Jun 2007 19:09:49 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail43-blu.bigfish.com (Postfix) with ESMTP id B9444BF8050; Fri, 15 Jun 2007 19:09:48 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007061512094173-86819 ; Fri, 15 Jun 2007 12:09:41 -0700 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Fri, 15 Jun 2007 12:07:39 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 06/15/2007 12:07:40, Serialize complete at 06/15/2007 12:07:40, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 12:09:41 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 12:09:48 PM, Serialize complete at 06/15/2007 12:09:48 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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="===============1840097807==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1840097807== Content-Type: multipart/alternative; boundary="=_alternative 006941AC882572FB_=" This is a multipart message in MIME format. --=_alternative 006941AC882572FB_= Content-Type: text/plain; charset="US-ASCII" But MARC uses the three-character 639-2 tags for the most common languages, right? If so, that is not a restriction, it's a violation. Karen Broome Peter Constable 06/15/2007 12:04 PM To Randy Presuhn , LTRU Working Group cc Subject RE: [Ltru] RE: ISO 639-2 decision: "mis" You appear to be assuming that for something to qualify as "an application of BCP 47" it must support all tags defined by BCP 47. I would certainly agree that a BCP 47-conformant parser must fully support the syntax that's defined, and for a BCP-47 validator to validate all and only tags that are defined in relation to a given snapshot of the registry. But I see no reason why a higher-level protocol cannot restrict the set of tags it accepts and still be considered "an application of BCP 47". I wouldn't be surprised if was actually common for people to create higher-level protocols that normatively reference BCP 47 but that define some subset of tags that are permitted. What is the problem in saying those are "applications of BCP 47"? It would certainly be getting applied in those cases. Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, June 15, 2007 11:16 AM To: LTRU Working Group Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Hi - As a technical contributor... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 11:02 AM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > MARC is an application context -- an application of language tags, not an > application in the sense of a piece software. In that application context, only > IDs from 639-2 can be used: that is a constraint on the range of language tags > supported in that application context. As such, I'd argue that these constraints mean it isn't an application of BCP 47. > Whether a user or a software process is assigning tags, the options are not > necessarily binary, as you suggest: in that application context it is entirely possible > for the language of given content to be known but not to be within the restricted set > permitted by MARC. These things might be called tags, and they might even be a subset of the set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* an application of BCP 47, and, consequently, is not our problem. 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 --=_alternative 006941AC882572FB_= Content-Type: text/html; charset="US-ASCII"
But MARC uses the three-character 639-2 tags for the most common languages, right? If so, that is not a restriction, it's a violation.

Karen Broome



Peter Constable <petercon@microsoft.com>

06/15/2007 12:04 PM

To
Randy Presuhn <randy_presuhn@mindspring.com>, LTRU Working Group <ltru@ietf.org>
cc
Subject
RE: [Ltru] RE: ISO 639-2 decision: "mis"





You appear to be assuming that for something to qualify as "an application of BCP 47" it must support all tags defined by BCP 47.

I would certainly agree that a BCP 47-conformant parser must fully support the syntax that's defined, and for a BCP-47 validator to validate all and only tags that are defined in relation to a given snapshot of the registry.

But I see no reason why a higher-level protocol cannot restrict the set of tags it accepts and still be considered "an application of BCP 47". I wouldn't be surprised if was actually common for people to create higher-level protocols that normatively reference BCP 47 but that define some subset of tags that are permitted. What is the problem in saying those are "applications of BCP 47"? It would certainly be getting applied in those cases.


Peter


-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: Friday, June 15, 2007 11:16 AM
To: LTRU Working Group
Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis"

Hi -

As a technical contributor...

> From: "Peter Constable" <petercon@microsoft.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Friday, June 15, 2007 11:02 AM
> Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis"
...
> MARC is an application context -- an application of language tags, not an
> application in the sense of a piece software. In that application context, only
> IDs from 639-2 can be used: that is a constraint on the range of language tags
> supported in that application context.

As such, I'd argue that these constraints mean it isn't an application of BCP 47.

> Whether a user or a software process is assigning tags, the options are not
> necessarily binary, as you suggest: in that application context it is entirely possible
> for the language of given content to be known but not to be within the restricted set
> permitted by MARC.

These things might be called tags, and they might even be a subset of the
set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* an
application of BCP 47, and, consequently, is not our problem.

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
--=_alternative 006941AC882572FB_=-- --===============1840097807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1840097807==-- From ltru-bounces@ietf.org Fri Jun 15 16:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIJC-00052Q-15; Fri, 15 Jun 2007 16:22:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzIJ9-00051F-HR for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 16:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIJ7-00050T-Ss for ltru@ietf.org; Fri, 15 Jun 2007 16:22:09 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzIJ4-0004ic-9b for ltru@ietf.org; Fri, 15 Jun 2007 16:22:09 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 13:20:51 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Fri, 15 Jun 2007 13:22:05 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 15 Jun 2007 13:22:04 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: AcevgMdJeTEw6PJRQMadpwpbVjXSWwACKVbA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0734907845==" Errors-To: ltru-bounces@ietf.org --===============0734907845== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CEC68ANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CEC68ANAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's not get too hung up on MARC as an example. It serves as an example of= something that limits the set of tags, not specifically as an application = of BCP 47, which it does not claim to be (and, as Karen points out, is not)= . Suppose a corpus that has content in a number of languages with primary foc= us on particular languages, but in which the criteria for inclusion of reco= rds is based not solely on language, with the result that some records are = not in one of the languages of primary focus. Suppose that content is recor= ded in an XML language, with language declared using xml:lang. Because XML = is used, that would be an application of BCP 47 according to my understandi= ng of conventional uses of "application of". The policy for that corpus, ho= wever, might well be to use 'mis' for any records not in some specified lis= t of languages. IMO, that particular fact should not nullify describing tha= t system as "an application of BCP 47". Peter From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: Friday, June 15, 2007 12:08 PM To: Peter Constable Cc: LTRU Working Group; Randy Presuhn Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" But MARC uses the three-character 639-2 tags for the most common languages,= right? If so, that is not a restriction, it's a violation. Karen Broome Peter Constable 06/15/2007 12:04 PM To Randy Presuhn , LTRU Working Group cc Subject RE: [Ltru] RE: ISO 639-2 decision: "mis" You appear to be assuming that for something to qualify as "an application = of BCP 47" it must support all tags defined by BCP 47. I would certainly agree that a BCP 47-conformant parser must fully support = the syntax that's defined, and for a BCP-47 validator to validate all and o= nly tags that are defined in relation to a given snapshot of the registry. But I see no reason why a higher-level protocol cannot restrict the set of = tags it accepts and still be considered "an application of BCP 47". I would= n't be surprised if was actually common for people to create higher-level p= rotocols that normatively reference BCP 47 but that define some subset of t= ags that are permitted. What is the problem in saying those are "applicatio= ns of BCP 47"? It would certainly be getting applied in those cases. Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, June 15, 2007 11:16 AM To: LTRU Working Group Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Hi - As a technical contributor... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 11:02 AM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > MARC is an application context -- an application of language tags, not an > application in the sense of a piece software. In that application context= , only > IDs from 639-2 can be used: that is a constraint on the range of language= tags > supported in that application context. As such, I'd argue that these constraints mean it isn't an application of B= CP 47. > Whether a user or a software process is assigning tags, the options are n= ot > necessarily binary, as you suggest: in that application context it is ent= irely possible > for the language of given content to be known but not to be within the re= stricted set > permitted by MARC. These things might be called tags, and they might even be a subset of the set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* a= n application of BCP 47, and, consequently, is not our problem. 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 --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CEC68ANAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let’s not get too hung up on MARC as an example. It se= rves as an example of something that limits the set of tags, not specifically as= an application of BCP 47, which it does not claim to be (and, as Karen points = out, is not).

 

Suppose a corpus that has content in a number of languages w= ith primary focus on particular languages, but in which the criteria for inclus= ion of records is based not solely on language, with the result that some recor= ds are not in one of the languages of primary focus. Suppose that content is recorded in an XML language, with language declared using xml:lang. Because= XML is used, that would be an application of BCP 47 according to my understandi= ng of conventional uses of “application of”. The policy for that corpus, however, might well be to use ‘mis’ for any records not= in some specified list of languages. IMO, that particular fact should not null= ify describing that system as “an application of BCP 47”.

 

Peter

 

 

From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: Friday, June 15, 2007 12:08 PM
To: Peter Constable
Cc: LTRU Working Group; Randy Presuhn
Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis"

 


But MARC = uses the three-character 639-2 tags for the most common languages, right? If so, that is not a restriction, it's a violation.

Karen Bro= ome


Peter Constable <petercon@microsoft.com>

06/15= /2007 12:04 PM

To

Randy Presuhn <randy_presuhn@mindspring.com>, LTRU Working Group <ltru@ietf.org>

cc

Subject

RE: [Ltru] RE: ISO 639-2 decision: "mis"

 




You appear to be assuming that for som= ething to qualify as "an application of BCP 47" it must support all tags defined by BCP 47.

I would certainly agree that a BCP 47-conformant parser must fully supp= ort the syntax that's defined, and for a BCP-47 validator to validate all and o= nly tags that are defined in relation to a given snapshot of the registry.=

But I see no reason why a higher-level protocol cannot restrict the set= of tags it accepts and still be considered "an application of BCP 47"= ;. I wouldn't be surprised if was actually common for people to create higher-le= vel protocols that normatively reference BCP 47 but that define some subset of = tags that are permitted. What is the problem in saying those are "applicati= ons of BCP 47"? It would certainly be getting applied in those cases.=


Peter


-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: Friday, June 15, 2007 11:16 AM
To: LTRU Working Group
Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis"

Hi -

As a technical contributor...

> From: "Peter Constable" <petercon@microsoft.com>
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Friday, June 15, 2007 11:02 AM
> Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ...
> MARC is an application context -- an application of language tags,= not an
> application in the sense of a piece software. In that application context, only
> IDs from 639-2 can be used: that is a constraint on the range of language tags
> supported in that application context.

As such, I'd argue that these constraints mean it isn't an application = of BCP 47.

> Whether a user or a software process is assigning tags, the option= s are not
> necessarily binary, as you suggest: in that application context it= is entirely possible
> for the language of given content to be known but not to be within= the restricted set
> permitted by MARC.

These things might be called tags, and they might even be a subset of t= he
set of strings that are well-formed, valid BCP 47 tags, but this is *NO= T* an
application of BCP 47, and, consequently, is not our problem.

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

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CEC68ANAEXMSGC117re_-- --===============0734907845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0734907845==-- From ltru-bounces@ietf.org Fri Jun 15 17:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ5q-0002oB-Rs; Fri, 15 Jun 2007 17:12:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzJ5p-0002o1-O6 for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:12:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ5p-0002nt-EF for ltru@ietf.org; Fri, 15 Jun 2007 17:12:29 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound5-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJ5n-0005fe-J0 for ltru@ietf.org; Fri, 15 Jun 2007 17:12:29 -0400 Received: from outbound5-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-sin-R.bigfish.com (Postfix) with ESMTP id 55658156B023; Fri, 15 Jun 2007 21:12:26 +0000 (UTC) Received: from mail107-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound5-sin.bigfish.com (Postfix) with ESMTP id 4B09019E0052; Fri, 15 Jun 2007 21:12:26 +0000 (UTC) Received: from mail107-sin (localhost.localdomain [127.0.0.1]) by mail107-sin-R.bigfish.com (Postfix) with ESMTP id 414ED1BB8151; Fri, 15 Jun 2007 21:12:26 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail107-sin (MessageSwitch) id 1181941946192299_28943; Fri, 15 Jun 2007 21:12:26 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail107-sin.bigfish.com (Postfix) with ESMTP id 80252138005A; Fri, 15 Jun 2007 21:12:25 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007061514122191-91514 ; Fri, 15 Jun 2007 14:12:21 -0700 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Fri, 15 Jun 2007 14:10:20 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 06/15/2007 14:10:21, Serialize complete at 06/15/2007 14:10:21, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 02:12:21 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 02:12:25 PM, Serialize complete at 06/15/2007 02:12:25 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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="===============0533633062==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0533633062== Content-Type: multipart/alternative; boundary="=_alternative 00747CDC882572FB_=" This is a multipart message in MIME format. --=_alternative 00747CDC882572FB_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" SSd2ZSByZXN0cmljdGVkIG91ciBpbnRlcm5hbCBpbXBsZW1lbnRhdGlvbnMgbm90IHRvIHVzZSBz Y3JpcHQgdGFncyB3aXRoIA0KYXVkaW8gbGFuZ3VhZ2VzLCB0aG91Z2ggdGhhdCBpcyBub3QgY3Vy cmVudGx5IHBhcnQgb2YgdGhlIHB1Ymxpc2hlZCB3b3JrIA0KYW5kIHdoZW4gaXQgaXMsIGl0IHdp bGwgYmUgYSBTaG91bGQgbm90IGEgU2hhbGwuIA0KDQpBbHNvLCBpbiBhIHN0YW5kYXJkIG91dHNp ZGUgb2YgU29ueSBQaWN0dXJlcywgdGhlIGxlbmd0aCBvZiB0aGUgdGFnIGlzIA0KcmVzdHJpY3Rl ZCBieSB0aGUgaW1wbGVtZW50YXRpb24uIE5vbmUgb2YgdGhlc2UgcHJvdmlzaW9ucyBtYWtlIGZv ciANCmludmFsaWQgdGFncyBhY2NvcmRpbmcgdG8gQkNQIDQ3LCBzbyBJIGNvbnNpZGVyIHRoZXNl IHRvIGJlIA0KYXBwbGljYXRpb24tc3BlY2lmaWMgcmVzdHJpY3Rpb25zIHdpdGhpbiBhIEJDUCA0 Ny1jb21wbGlhbnQgZnJhbWV3b3JrLiBTbyANCnllcywgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyB0 byBwbGFjZSBjZXJ0YWluIHJlc3RyaWN0aW9ucyBvbiBCQ1AgNDcgaW4gDQpjb250ZXh0IC0tIEkg ZGlkbid0IHRoaW5rIHRoZXJlIHdhcyBhbnkgY29udHJvdmVyc3kgYXJvdW5kIHRoaXMuDQoNClJl Z2FyZHMsDQoNCkthcmVuIEJyb29tZQ0KTWV0YWRhdGEgU3lzdGVtcyBEZXNpZ25lcg0KU29ueSBQ aWN0dXJlcyBFbnRlcnRhaW5tZW50DQozMTAuMjQ0LjQzODQNCg0KDQoNClBldGVyIENvbnN0YWJs ZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbT4gDQowNi8xNS8yMDA3IDAxOjIyIFBNDQoNClRvDQpM VFJVIFdvcmtpbmcgR3JvdXAgPGx0cnVAaWV0Zi5vcmc+DQpjYw0KDQpTdWJqZWN0DQpSRTogW0x0 cnVdIFJFOiBJU08gNjM5LTIgZGVjaXNpb246ICJtaXMiDQoNCg0KDQoNCg0KDQpMZXTigJlzIG5v dCBnZXQgdG9vIGh1bmcgdXAgb24gTUFSQyBhcyBhbiBleGFtcGxlLiBJdCBzZXJ2ZXMgYXMgYW4g ZXhhbXBsZSANCm9mIHNvbWV0aGluZyB0aGF0IGxpbWl0cyB0aGUgc2V0IG9mIHRhZ3MsIG5vdCBz cGVjaWZpY2FsbHkgYXMgYW4gDQphcHBsaWNhdGlvbiBvZiBCQ1AgNDcsIHdoaWNoIGl0IGRvZXMg bm90IGNsYWltIHRvIGJlIChhbmQsIGFzIEthcmVuIHBvaW50cyANCm91dCwgaXMgbm90KS4NCiAN ClN1cHBvc2UgYSBjb3JwdXMgdGhhdCBoYXMgY29udGVudCBpbiBhIG51bWJlciBvZiBsYW5ndWFn ZXMgd2l0aCBwcmltYXJ5IA0KZm9jdXMgb24gcGFydGljdWxhciBsYW5ndWFnZXMsIGJ1dCBpbiB3 aGljaCB0aGUgY3JpdGVyaWEgZm9yIGluY2x1c2lvbiBvZiANCnJlY29yZHMgaXMgYmFzZWQgbm90 IHNvbGVseSBvbiBsYW5ndWFnZSwgd2l0aCB0aGUgcmVzdWx0IHRoYXQgc29tZSByZWNvcmRzIA0K YXJlIG5vdCBpbiBvbmUgb2YgdGhlIGxhbmd1YWdlcyBvZiBwcmltYXJ5IGZvY3VzLiBTdXBwb3Nl IHRoYXQgY29udGVudCBpcyANCnJlY29yZGVkIGluIGFuIFhNTCBsYW5ndWFnZSwgd2l0aCBsYW5n dWFnZSBkZWNsYXJlZCB1c2luZyB4bWw6bGFuZy4gDQpCZWNhdXNlIFhNTCBpcyB1c2VkLCB0aGF0 IHdvdWxkIGJlIGFuIGFwcGxpY2F0aW9uIG9mIEJDUCA0NyBhY2NvcmRpbmcgdG8gDQpteSB1bmRl cnN0YW5kaW5nIG9mIGNvbnZlbnRpb25hbCB1c2VzIG9mIOKAnGFwcGxpY2F0aW9uIG9m4oCdLiBU aGUgcG9saWN5IGZvciANCnRoYXQgY29ycHVzLCBob3dldmVyLCBtaWdodCB3ZWxsIGJlIHRvIHVz ZSDigJhtaXPigJkgZm9yIGFueSByZWNvcmRzIG5vdCBpbiANCnNvbWUgc3BlY2lmaWVkIGxpc3Qg b2YgbGFuZ3VhZ2VzLiBJTU8sIHRoYXQgcGFydGljdWxhciBmYWN0IHNob3VsZCBub3QgDQpudWxs aWZ5IGRlc2NyaWJpbmcgdGhhdCBzeXN0ZW0gYXMg4oCcYW4gYXBwbGljYXRpb24gb2YgQkNQIDQ3 4oCdLg0KIA0KUGV0ZXINCiANCiANCkZyb206IEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20gW21h aWx0bzpLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tXSANClNlbnQ6IEZyaWRheSwgSnVuZSAxNSwg MjAwNyAxMjowOCBQTQ0KVG86IFBldGVyIENvbnN0YWJsZQ0KQ2M6IExUUlUgV29ya2luZyBHcm91 cDsgUmFuZHkgUHJlc3Vobg0KU3ViamVjdDogUkU6IFtMdHJ1XSBSRTogSVNPIDYzOS0yIGRlY2lz aW9uOiAibWlzIg0KIA0KDQpCdXQgTUFSQyB1c2VzIHRoZSB0aHJlZS1jaGFyYWN0ZXIgNjM5LTIg dGFncyBmb3IgdGhlIG1vc3QgY29tbW9uIA0KbGFuZ3VhZ2VzLCByaWdodD8gSWYgc28sIHRoYXQg aXMgbm90IGEgcmVzdHJpY3Rpb24sIGl0J3MgYSB2aW9sYXRpb24uIA0KDQpLYXJlbiBCcm9vbWUg DQoNCg0KDQpQZXRlciBDb25zdGFibGUgPHBldGVyY29uQG1pY3Jvc29mdC5jb20+IA0KMDYvMTUv MjAwNyAxMjowNCBQTSANCg0KDQpUbw0KUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBtaW5k c3ByaW5nLmNvbT4sIExUUlUgV29ya2luZyBHcm91cCANCjxsdHJ1QGlldGYub3JnPiANCmNjDQoN ClN1YmplY3QNClJFOiBbTHRydV0gUkU6IElTTyA2MzktMiBkZWNpc2lvbjogIm1pcyINCiANCg0K DQoNCg0KDQoNCg0KDQpZb3UgYXBwZWFyIHRvIGJlIGFzc3VtaW5nIHRoYXQgZm9yIHNvbWV0aGlu ZyB0byBxdWFsaWZ5IGFzICJhbiBhcHBsaWNhdGlvbiANCm9mIEJDUCA0NyIgaXQgbXVzdCBzdXBw b3J0IGFsbCB0YWdzIGRlZmluZWQgYnkgQkNQIDQ3Lg0KDQpJIHdvdWxkIGNlcnRhaW5seSBhZ3Jl ZSB0aGF0IGEgQkNQIDQ3LWNvbmZvcm1hbnQgcGFyc2VyIG11c3QgZnVsbHkgc3VwcG9ydCANCnRo ZSBzeW50YXggdGhhdCdzIGRlZmluZWQsIGFuZCBmb3IgYSBCQ1AtNDcgdmFsaWRhdG9yIHRvIHZh bGlkYXRlIGFsbCBhbmQgDQpvbmx5IHRhZ3MgdGhhdCBhcmUgZGVmaW5lZCBpbiByZWxhdGlvbiB0 byBhIGdpdmVuIHNuYXBzaG90IG9mIHRoZSANCnJlZ2lzdHJ5Lg0KDQpCdXQgSSBzZWUgbm8gcmVh c29uIHdoeSBhIGhpZ2hlci1sZXZlbCBwcm90b2NvbCBjYW5ub3QgcmVzdHJpY3QgdGhlIHNldCBv ZiANCnRhZ3MgaXQgYWNjZXB0cyBhbmQgc3RpbGwgYmUgY29uc2lkZXJlZCAiYW4gYXBwbGljYXRp b24gb2YgQkNQIDQ3Ii4gSSANCndvdWxkbid0IGJlIHN1cnByaXNlZCBpZiB3YXMgYWN0dWFsbHkg Y29tbW9uIGZvciBwZW9wbGUgdG8gY3JlYXRlIA0KaGlnaGVyLWxldmVsIHByb3RvY29scyB0aGF0 IG5vcm1hdGl2ZWx5IHJlZmVyZW5jZSBCQ1AgNDcgYnV0IHRoYXQgZGVmaW5lIA0Kc29tZSBzdWJz ZXQgb2YgdGFncyB0aGF0IGFyZSBwZXJtaXR0ZWQuIFdoYXQgaXMgdGhlIHByb2JsZW0gaW4gc2F5 aW5nIA0KdGhvc2UgYXJlICJhcHBsaWNhdGlvbnMgb2YgQkNQIDQ3Ij8gSXQgd291bGQgY2VydGFp bmx5IGJlIGdldHRpbmcgYXBwbGllZCANCmluIHRob3NlIGNhc2VzLg0KDQoNClBldGVyDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhbmR5IFByZXN1aG4gW21haWx0bzpy YW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tXQ0KU2VudDogRnJpZGF5LCBKdW5lIDE1LCAyMDA3 IDExOjE2IEFNDQpUbzogTFRSVSBXb3JraW5nIEdyb3VwDQpTdWJqZWN0OiBSZTogW0x0cnVdIFJF OiBJU08gNjM5LTIgZGVjaXNpb246ICJtaXMiDQoNCkhpIC0NCg0KQXMgYSB0ZWNobmljYWwgY29u dHJpYnV0b3IuLi4NCg0KPiBGcm9tOiAiUGV0ZXIgQ29uc3RhYmxlIiA8cGV0ZXJjb25AbWljcm9z b2Z0LmNvbT4NCj4gVG86ICJMVFJVIFdvcmtpbmcgR3JvdXAiIDxsdHJ1QGlldGYub3JnPg0KPiBT ZW50OiBGcmlkYXksIEp1bmUgMTUsIDIwMDcgMTE6MDIgQU0NCj4gU3ViamVjdDogUkU6IFtMdHJ1 XSBSRTogSVNPIDYzOS0yIGRlY2lzaW9uOiAibWlzIg0KLi4uDQo+IE1BUkMgaXMgYW4gYXBwbGlj YXRpb24gY29udGV4dCAtLSBhbiBhcHBsaWNhdGlvbiBvZiBsYW5ndWFnZSB0YWdzLCBub3QgDQph bg0KPiBhcHBsaWNhdGlvbiBpbiB0aGUgc2Vuc2Ugb2YgYSBwaWVjZSBzb2Z0d2FyZS4gSW4gdGhh dCBhcHBsaWNhdGlvbiANCmNvbnRleHQsIG9ubHkNCj4gSURzIGZyb20gNjM5LTIgY2FuIGJlIHVz ZWQ6IHRoYXQgaXMgYSBjb25zdHJhaW50IG9uIHRoZSByYW5nZSBvZiANCmxhbmd1YWdlIHRhZ3MN Cj4gc3VwcG9ydGVkIGluIHRoYXQgYXBwbGljYXRpb24gY29udGV4dC4NCg0KQXMgc3VjaCwgSSdk IGFyZ3VlIHRoYXQgdGhlc2UgY29uc3RyYWludHMgbWVhbiBpdCBpc24ndCBhbiBhcHBsaWNhdGlv biBvZiANCkJDUCA0Ny4NCg0KPiBXaGV0aGVyIGEgdXNlciBvciBhIHNvZnR3YXJlIHByb2Nlc3Mg aXMgYXNzaWduaW5nIHRhZ3MsIHRoZSBvcHRpb25zIGFyZSANCm5vdA0KPiBuZWNlc3NhcmlseSBi aW5hcnksIGFzIHlvdSBzdWdnZXN0OiBpbiB0aGF0IGFwcGxpY2F0aW9uIGNvbnRleHQgaXQgaXMg DQplbnRpcmVseSBwb3NzaWJsZQ0KPiBmb3IgdGhlIGxhbmd1YWdlIG9mIGdpdmVuIGNvbnRlbnQg dG8gYmUga25vd24gYnV0IG5vdCB0byBiZSB3aXRoaW4gdGhlIA0KcmVzdHJpY3RlZCBzZXQNCj4g cGVybWl0dGVkIGJ5IE1BUkMuDQoNClRoZXNlIHRoaW5ncyBtaWdodCBiZSBjYWxsZWQgdGFncywg YW5kIHRoZXkgbWlnaHQgZXZlbiBiZSBhIHN1YnNldCBvZiB0aGUNCnNldCBvZiBzdHJpbmdzIHRo YXQgYXJlIHdlbGwtZm9ybWVkLCB2YWxpZCBCQ1AgNDcgdGFncywgYnV0IHRoaXMgaXMgKk5PVCog DQphbg0KYXBwbGljYXRpb24gb2YgQkNQIDQ3LCBhbmQsIGNvbnNlcXVlbnRseSwgaXMgbm90IG91 ciBwcm9ibGVtLg0KDQpSYW5keQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnDQpodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpM dHJ1QGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBt YWlsaW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg0KDQo= --=_alternative 00747CDC882572FB_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="UTF-8" DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkndmUgcmVzdHJpY3RlZCBvdXIg aW50ZXJuYWwgaW1wbGVtZW50YXRpb25zDQpub3QgdG8gdXNlIHNjcmlwdCB0YWdzIHdpdGggYXVk aW8gbGFuZ3VhZ2VzLCB0aG91Z2ggdGhhdCBpcyBub3QgY3VycmVudGx5DQpwYXJ0IG9mIHRoZSBw dWJsaXNoZWQgd29yayBhbmQgd2hlbiBpdCBpcywgaXQgd2lsbCBiZSBhIFNob3VsZCBub3QgYSBT aGFsbC4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ QWxzbywgaW4gYSBzdGFuZGFyZCBvdXRzaWRlIG9mIFNvbnkNClBpY3R1cmVzLCB0aGUgbGVuZ3Ro IG9mIHRoZSB0YWcgaXMgcmVzdHJpY3RlZCBieSB0aGUgaW1wbGVtZW50YXRpb24uIE5vbmUNCm9m IHRoZXNlIHByb3Zpc2lvbnMgbWFrZSBmb3IgaW52YWxpZCB0YWdzIGFjY29yZGluZyB0byBCQ1Ag NDcsIHNvIEkgY29uc2lkZXINCnRoZXNlIHRvIGJlIGFwcGxpY2F0aW9uLXNwZWNpZmljIHJlc3Ry aWN0aW9ucyB3aXRoaW4gYSBCQ1AgNDctY29tcGxpYW50DQpmcmFtZXdvcmsuIFNvIHllcywgdGhl cmUgYXJlIGdvb2QgcmVhc29ucyB0byBwbGFjZSBjZXJ0YWluIHJlc3RyaWN0aW9ucw0Kb24gQkNQ IDQ3IGluIGNvbnRleHQgLS0gSSBkaWRuJ3QgdGhpbmsgdGhlcmUgd2FzIGFueSBjb250cm92ZXJz eSBhcm91bmQNCnRoaXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+S2FyZW4gQnJvb21lPGJyPg0KTWV0YWRhdGEgU3lzdGVtcyBEZXNpZ25lcjxicj4N ClNvbnkgUGljdHVyZXMgRW50ZXJ0YWlubWVudDxicj4NCjMxMC4yNDQuNDM4NDwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QZXRlciBDb25zdGFi bGUgJmx0O3BldGVyY29uQG1pY3Jvc29mdC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA2LzE1LzIwMDcgMDE6MjIgUE08L2ZvbnQ+DQo8dGQg d2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5MVFJVIFdvcmtpbmcgR3Jv dXAgJmx0O2x0cnVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48 L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtMdHJ1XSBSRTogSVNPIDYzOS0yIGRlY2lz aW9uOiAmcXVvdDttaXMmcXVvdDs8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj5MZXTigJlz IG5vdCBnZXQgdG9vIGh1bmcNCnVwIG9uIE1BUkMgYXMgYW4gZXhhbXBsZS4gSXQgc2VydmVzIGFz IGFuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgbGltaXRzDQp0aGUgc2V0IG9mIHRhZ3MsIG5v dCBzcGVjaWZpY2FsbHkgYXMgYW4gYXBwbGljYXRpb24gb2YgQkNQIDQ3LCB3aGljaCBpdA0KZG9l cyBub3QgY2xhaW0gdG8gYmUgKGFuZCwgYXMgS2FyZW4gcG9pbnRzIG91dCwgaXMgbm90KS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2Vy aWYiPlN1cHBvc2UgYSBjb3JwdXMgdGhhdA0KaGFzIGNvbnRlbnQgaW4gYSBudW1iZXIgb2YgbGFu Z3VhZ2VzIHdpdGggcHJpbWFyeSBmb2N1cyBvbiBwYXJ0aWN1bGFyIGxhbmd1YWdlcywNCmJ1dCBp biB3aGljaCB0aGUgY3JpdGVyaWEgZm9yIGluY2x1c2lvbiBvZiByZWNvcmRzIGlzIGJhc2VkIG5v dCBzb2xlbHkNCm9uIGxhbmd1YWdlLCB3aXRoIHRoZSByZXN1bHQgdGhhdCBzb21lIHJlY29yZHMg YXJlIG5vdCBpbiBvbmUgb2YgdGhlIGxhbmd1YWdlcw0Kb2YgcHJpbWFyeSBmb2N1cy4gU3VwcG9z ZSB0aGF0IGNvbnRlbnQgaXMgcmVjb3JkZWQgaW4gYW4gWE1MIGxhbmd1YWdlLA0Kd2l0aCBsYW5n dWFnZSBkZWNsYXJlZCB1c2luZyB4bWw6bGFuZy4gQmVjYXVzZSBYTUwgaXMgdXNlZCwgdGhhdCB3 b3VsZA0KYmUgYW4gYXBwbGljYXRpb24gb2YgQkNQIDQ3IGFjY29yZGluZyB0byBteSB1bmRlcnN0 YW5kaW5nIG9mIGNvbnZlbnRpb25hbA0KdXNlcyBvZiDigJxhcHBsaWNhdGlvbiBvZuKAnS4gVGhl IHBvbGljeSBmb3IgdGhhdCBjb3JwdXMsIGhvd2V2ZXIsIG1pZ2h0DQp3ZWxsIGJlIHRvIHVzZSDi gJhtaXPigJkgZm9yIGFueSByZWNvcmRzIG5vdCBpbiBzb21lIHNwZWNpZmllZCBsaXN0IG9mIGxh bmd1YWdlcy4NCklNTywgdGhhdCBwYXJ0aWN1bGFyIGZhY3Qgc2hvdWxkIG5vdCBudWxsaWZ5IGRl c2NyaWJpbmcgdGhhdCBzeXN0ZW0gYXMNCuKAnGFuIGFwcGxpY2F0aW9uIG9mIEJDUCA0N+KAnS48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMt c2VyaWYiPlBldGVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+PGI+RnJvbTo8L2I+IEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20gW21haWx0bzpL YXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tXQ0KPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwgSnVu ZSAxNSwgMjAwNyAxMjowOCBQTTxiPjxicj4NClRvOjwvYj4gUGV0ZXIgQ29uc3RhYmxlPGI+PGJy Pg0KQ2M6PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA7IFJhbmR5IFByZXN1aG48Yj48YnI+DQpTdWJq ZWN0OjwvYj4gUkU6IFtMdHJ1XSBSRTogSVNPIDYzOS0yIGRlY2lzaW9uOiAmcXVvdDttaXMmcXVv dDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQnV0IE1BUkMgdXNl cyB0aGUgdGhyZWUtY2hhcmFjdGVyIDYzOS0yIHRhZ3MgZm9yIHRoZSBtb3N0IGNvbW1vbiBsYW5n dWFnZXMsDQpyaWdodD8gSWYgc28sIHRoYXQgaXMgbm90IGEgcmVzdHJpY3Rpb24sIGl0J3MgYSB2 aW9sYXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KS2FyZW4gQnJvb21lPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8YnI+DQo8L2Zv bnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MzQlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+UGV0ZXIgQ29uc3RhYmxlICZsdDtwZXRl cmNvbkBtaWNyb3NvZnQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+MDYvMTUvMjAwNyAxMjowNCBQTTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02NSU+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTclPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlRvPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTky JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJhbmR5IFByZXN1aG4gJmx0O3JhbmR5X3ByZXN1 aG5AbWluZHNwcmluZy5jb20mZ3Q7LA0KTFRSVSBXb3JraW5nIEdyb3VwICZsdDtsdHJ1QGlldGYu b3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPmNjPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+U3ViamVjdDwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJFOiBbTHRydV0gUkU6IElT TyA2MzktMiBkZWNpc2lvbjogJnF1b3Q7bWlzJnF1b3Q7PC9mb250PjwvdGFibGU+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0 ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NCllvdSBhcHBlYXIgdG8gYmUgYXNzdW1pbmcgdGhhdCBmb3Igc29t ZXRoaW5nIHRvIHF1YWxpZnkgYXMgJnF1b3Q7YW4gYXBwbGljYXRpb24NCm9mIEJDUCA0NyZxdW90 OyBpdCBtdXN0IHN1cHBvcnQgYWxsIHRhZ3MgZGVmaW5lZCBieSBCQ1AgNDcuPGJyPg0KPGJyPg0K SSB3b3VsZCBjZXJ0YWlubHkgYWdyZWUgdGhhdCBhIEJDUCA0Ny1jb25mb3JtYW50IHBhcnNlciBt dXN0IGZ1bGx5IHN1cHBvcnQNCnRoZSBzeW50YXggdGhhdCdzIGRlZmluZWQsIGFuZCBmb3IgYSBC Q1AtNDcgdmFsaWRhdG9yIHRvIHZhbGlkYXRlIGFsbCBhbmQNCm9ubHkgdGFncyB0aGF0IGFyZSBk ZWZpbmVkIGluIHJlbGF0aW9uIHRvIGEgZ2l2ZW4gc25hcHNob3Qgb2YgdGhlIHJlZ2lzdHJ5Ljxi cj4NCjxicj4NCkJ1dCBJIHNlZSBubyByZWFzb24gd2h5IGEgaGlnaGVyLWxldmVsIHByb3RvY29s IGNhbm5vdCByZXN0cmljdCB0aGUgc2V0DQpvZiB0YWdzIGl0IGFjY2VwdHMgYW5kIHN0aWxsIGJl IGNvbnNpZGVyZWQgJnF1b3Q7YW4gYXBwbGljYXRpb24gb2YgQkNQDQo0NyZxdW90Oy4gSSB3b3Vs ZG4ndCBiZSBzdXJwcmlzZWQgaWYgd2FzIGFjdHVhbGx5IGNvbW1vbiBmb3IgcGVvcGxlIHRvDQpj cmVhdGUgaGlnaGVyLWxldmVsIHByb3RvY29scyB0aGF0IG5vcm1hdGl2ZWx5IHJlZmVyZW5jZSBC Q1AgNDcgYnV0IHRoYXQNCmRlZmluZSBzb21lIHN1YnNldCBvZiB0YWdzIHRoYXQgYXJlIHBlcm1p dHRlZC4gV2hhdCBpcyB0aGUgcHJvYmxlbSBpbiBzYXlpbmcNCnRob3NlIGFyZSAmcXVvdDthcHBs aWNhdGlvbnMgb2YgQkNQIDQ3JnF1b3Q7PyBJdCB3b3VsZCBjZXJ0YWlubHkgYmUgZ2V0dGluZw0K YXBwbGllZCBpbiB0aG9zZSBjYXNlcy48YnI+DQo8YnI+DQo8YnI+DQpQZXRlcjxicj4NCjxicj4N Cjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogUmFuZHkgUHJlc3Vo biBbbWFpbHRvOnJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb21dPGJyPg0KU2VudDogRnJpZGF5 LCBKdW5lIDE1LCAyMDA3IDExOjE2IEFNPGJyPg0KVG86IExUUlUgV29ya2luZyBHcm91cDxicj4N ClN1YmplY3Q6IFJlOiBbTHRydV0gUkU6IElTTyA2MzktMiBkZWNpc2lvbjogJnF1b3Q7bWlzJnF1 b3Q7PGJyPg0KPGJyPg0KSGkgLTxicj4NCjxicj4NCkFzIGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9y Li4uPGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtQZXRlciBDb25zdGFibGUmcXVvdDsgJmx0 O3BldGVyY29uQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KJmd0OyBUbzogJnF1b3Q7TFRSVSBXb3Jr aW5nIEdyb3VwJnF1b3Q7ICZsdDtsdHJ1QGlldGYub3JnJmd0Ozxicj4NCiZndDsgU2VudDogRnJp ZGF5LCBKdW5lIDE1LCAyMDA3IDExOjAyIEFNPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW0x0cnVd IFJFOiBJU08gNjM5LTIgZGVjaXNpb246ICZxdW90O21pcyZxdW90Ozxicj4NCi4uLjxicj4NCiZn dDsgTUFSQyBpcyBhbiBhcHBsaWNhdGlvbiBjb250ZXh0IC0tIGFuIGFwcGxpY2F0aW9uIG9mIGxh bmd1YWdlIHRhZ3MsDQpub3QgYW48YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIGluIHRoZSBzZW5zZSBv ZiBhIHBpZWNlIHNvZnR3YXJlLiBJbiB0aGF0IGFwcGxpY2F0aW9uDQpjb250ZXh0LCBvbmx5PGJy Pg0KJmd0OyBJRHMgZnJvbSA2MzktMiBjYW4gYmUgdXNlZDogdGhhdCBpcyBhIGNvbnN0cmFpbnQg b24gdGhlIHJhbmdlIG9mIGxhbmd1YWdlDQp0YWdzPGJyPg0KJmd0OyBzdXBwb3J0ZWQgaW4gdGhh dCBhcHBsaWNhdGlvbiBjb250ZXh0Ljxicj4NCjxicj4NCkFzIHN1Y2gsIEknZCBhcmd1ZSB0aGF0 IHRoZXNlIGNvbnN0cmFpbnRzIG1lYW4gaXQgaXNuJ3QgYW4gYXBwbGljYXRpb24NCm9mIEJDUCA0 Ny48YnI+DQo8YnI+DQomZ3Q7IFdoZXRoZXIgYSB1c2VyIG9yIGEgc29mdHdhcmUgcHJvY2VzcyBp cyBhc3NpZ25pbmcgdGFncywgdGhlIG9wdGlvbnMNCmFyZSBub3Q8YnI+DQomZ3Q7IG5lY2Vzc2Fy aWx5IGJpbmFyeSwgYXMgeW91IHN1Z2dlc3Q6IGluIHRoYXQgYXBwbGljYXRpb24gY29udGV4dCBp dA0KaXMgZW50aXJlbHkgcG9zc2libGU8YnI+DQomZ3Q7IGZvciB0aGUgbGFuZ3VhZ2Ugb2YgZ2l2 ZW4gY29udGVudCB0byBiZSBrbm93biBidXQgbm90IHRvIGJlIHdpdGhpbg0KdGhlIHJlc3RyaWN0 ZWQgc2V0PGJyPg0KJmd0OyBwZXJtaXR0ZWQgYnkgTUFSQy48YnI+DQo8YnI+DQpUaGVzZSB0aGlu Z3MgbWlnaHQgYmUgY2FsbGVkIHRhZ3MsIGFuZCB0aGV5IG1pZ2h0IGV2ZW4gYmUgYSBzdWJzZXQg b2YgdGhlPGJyPg0Kc2V0IG9mIHN0cmluZ3MgdGhhdCBhcmUgd2VsbC1mb3JtZWQsIHZhbGlkIEJD UCA0NyB0YWdzLCBidXQgdGhpcyBpcyAqTk9UKg0KYW48YnI+DQphcHBsaWNhdGlvbiBvZiBCQ1Ag NDcsIGFuZCwgY29uc2VxdWVudGx5LCBpcyBub3Qgb3VyIHByb2JsZW0uPGJyPg0KPGJyPg0KUmFu ZHk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkx0cnUgbWFpbGluZyBsaXN0PGJyPg0KTHRydUBpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCkx0cnUgbWFpbGluZyBsaXN0PGJyPg0KTHRydUBpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250 IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkx0cnUgbWFpbGluZyBsaXN0PGJyPg0KTHRydUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4N Cg== --=_alternative 00747CDC882572FB_=-- --===============0533633062== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0533633062==-- From ltru-bounces@ietf.org Fri Jun 15 17:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ6S-0002s6-6P; Fri, 15 Jun 2007 17:13:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzJ6Q-0002r4-Ft for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ6Q-0002qw-68 for ltru@ietf.org; Fri, 15 Jun 2007 17:13:06 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJ6O-0005np-SO for ltru@ietf.org; Fri, 15 Jun 2007 17:13:06 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Fq4l7vVM/8Pzc6ruzHKkOC92in1Kh8/krepTBia8JxnPY1gfv32IdT5emBskShk+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzJ6O-0004Z7-8C for ltru@ietf.org; Fri, 15 Jun 2007 17:13:04 -0400 Message-ID: <001401c7af92$89fb9200$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 14:17:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93562a2b58daa996f41eb4cb9d8c509ef1ef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor.... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 1:22 PM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > Suppose a corpus that has content in a number of languages with primary > focus on particular languages, but in which the criteria for inclusion of records > is based not solely on language, with the result that some records are not in > one of the languages of primary focus. Suppose that content is recorded in an XML > language, with language declared using xml:lang. Because XML is used, that > would be an application of BCP 47 according to my understanding of conventional > uses of "application of". So far so good. > The policy for that corpus, however, might well be to use 'mis' for any records > not in some specified list of languages. IMO, that particular fact should not > nullify describing that system as "an application of BCP 47". This is where we differ. While the syntax is still ok, the semantic is changed past any hope of interoperability. (Rather like that classic paper on Recoverability Under Deletion. :-) It would rather be like using "sw" to mean "Swiss German" rather than Swahili. I'd consider that an abuse, rather than an application, of the BCP. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 17:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJVh-0001RB-Sm; Fri, 15 Jun 2007 17:39:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzJVg-0001R6-JT for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJVg-0001Qy-A3 for ltru@ietf.org; Fri, 15 Jun 2007 17:39:12 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJVe-0002S8-VO for ltru@ietf.org; Fri, 15 Jun 2007 17:39:12 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 14:37:55 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Fri, 15 Jun 2007 14:39:10 -0700 From: Peter Constable To: Randy Presuhn , LTRU Working Group Date: Fri, 15 Jun 2007 14:39:08 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: Acevkfoaee6MZ/5RTO+sCH6vfekdPwAApRWA Message-ID: References: <001401c7af92$89fb9200$6601a8c0@oemcomputer> In-Reply-To: <001401c7af92$89fb9200$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > So far so good. > >> The policy for that corpus, however, might well be to use 'mis' for any = records >> not in some specified list of languages. IMO, that particular fact shou= ld not >> nullify describing that system as "an application of BCP 47". > > This is where we differ. While the syntax is still ok, the semantic is c= hanged > past any hope of interoperability. I don't get that at all. Every user of that system, which may well be publi= c, would understand by the policy for that system, what to expect. The sema= ntics of 'mis' would be clearly documented both in ISO 639 and in the LSTR,= and the usage would be consistent with the documented semantics. If any da= ta is exported outside that system, then there would be some semantic loss = because the context is lost, but that is part of the documented contract ar= ound 'mis' -- and why users need to understand its shortcomings, so also wh= y users would probably be warned against exporting data. The only issue here is the inherent instability and shortcomings of 'mis'. = I don't see any abuse of BCP 47. There is nothing whatsoever like using "sw= " to mean 'Swiss German'. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 17:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJfi-000320-Q7; Fri, 15 Jun 2007 17:49:34 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzJfh-0002lH-DQ for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJfg-0002fu-TD for ltru@ietf.org; Fri, 15 Jun 2007 17:49:32 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJff-0003iA-K0 for ltru@ietf.org; Fri, 15 Jun 2007 17:49:32 -0400 Received: from c83-248-98-114.bredband.comhem.se ([83.248.98.114]:3216 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1HzJfe-0002hR-44; Fri, 15 Jun 2007 23:49:30 +0200 From: "Kent Karlsson" To: "'Randy Presuhn'" , "'LTRU Working Group'" References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer><41a006820706150946h56365255nbbd1ddb203e32f64@mail.gmail.com> <004e01c7af6f$bb05d220$6601a8c0@oemcomputer> Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 23:49:28 +0200 Message-ID: <00dd01c7af97$0fad0bf0$bc6ef853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcevbywhyncgsV3/Q2Sk0JbhDFa+MAAJt3GQ In-Reply-To: <004e01c7af6f$bb05d220$6601a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Originating-IP: 83.248.98.114 X-Scan-Result: No virus found in message 1HzJfe-0002hR-44. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HzJfe-0002hR-44 140cdc68eeef5e93fe8d01749f04f147 X-Spam-Score: 0.5 (/) 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: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > > As technical contributor... > > > From: "GerardM" ... > > Standards have a tendency to lag behind what is accepted to be true. When a > > standard does not acknowledge a specific language of linguistic entity yet > > because it is not in that version of the standard, a tag could be not > > available because a specific version of standard has not been ratified yet. > > This is the *sole* case where "mis" would be appropriate, With the given recent change for ISO 639 w.r.t. 'mis', 'mis' is not applicable, when using BCP 47 tags, in such cases either, due to inherent instability of 'mis' that result from the recent change. 'und' is still applicable (but has admittedly a different intension). > However, I would also argue that if I were a field linguist > collecting data on > previously unknown languages (the most likely scenario in > which one could legitimately > encounter a need for "mis") that I'd be better off using > private-use subtags as > an *interim* measure for my data. With private-use subtags > I'd know which was which. Agreed. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 17:52:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJiO-0005V1-4M; Fri, 15 Jun 2007 17:52:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzJiN-0005Uw-9z for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJiN-0005Uo-0Q for ltru@ietf.org; Fri, 15 Jun 2007 17:52:19 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJiM-00049d-O5 for ltru@ietf.org; Fri, 15 Jun 2007 17:52:18 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e5rz+/IoCpk7sg5iDWrRG/5yAcuAULFl0Iy/SzR6CFB7G+Z6clE08vH8XVa0Shj+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzJiG-0001b5-U7 for ltru@ietf.org; Fri, 15 Jun 2007 17:52:13 -0400 Message-ID: <002e01c7af98$03683800$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001401c7af92$89fb9200$6601a8c0@oemcomputer> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 14:56:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356ef1bd794f5480cf73159de39be69e52c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Peter Constable" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Friday, June 15, 2007 2:39 PM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > >> The policy for that corpus, however, might well be to use 'mis' for any records > >> not in some specified list of languages. IMO, that particular fact should not > >> nullify describing that system as "an application of BCP 47". > > > > This is where we differ. While the syntax is still ok, the semantic is changed > > past any hope of interoperability. > > I don't get that at all. Every user of that system, which may well be public, > would understand by the policy for that system, what to expect. The semantics > of 'mis' would be clearly documented both in ISO 639 and in the LSTR, and > the usage would be consistent with the documented semantics. If any data > is exported outside that system, then there would be some semantic loss > because the context is lost, You've just explained why such a usage is not interoperable. > but that is part of the documented contract around 'mis' Which "documented contract"? > -- and why users need to understand its shortcomings, so also why users > would probably be warned against exporting data. This is making the case for using "MUST NOT" rather than "SHOULD NOT". > The only issue here is the inherent instability and shortcomings of 'mis'. > I don't see any abuse of BCP 47. There is nothing whatsoever like using > "sw" to mean 'Swiss German'. Yes, it is in that permitting the tag to be used for languages for which tags already exist is in direct contradiction to its description. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 18:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzK9j-0003SI-TU; Fri, 15 Jun 2007 18:20:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzK9i-0003SB-Tf for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 18:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzK9i-0003Rz-Jd for ltru@ietf.org; Fri, 15 Jun 2007 18:20:34 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzK9h-0001FW-28 for ltru@ietf.org; Fri, 15 Jun 2007 18:20:34 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 15 Jun 2007 23:20:30 +0100 From: "Debbie Garside" To: , "'Randy Presuhn'" Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 23:20:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Aceveff/EbHGDmcCRm6797pzZcEIvQAIRDHQ In-Reply-To: <4672D81B.4090700@yahoo-inc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Message-Id: Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just a slight comment: Addison wrote: >It SHOULD NOT be used except when > other means of identifying the language are not available. Double nots are not good :-) I propose: "It should only be used when other means of identifying the language are unavailable." Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 15 June 2007 19:19 > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" > > Randy Presuhn wrote: > > > > I disagree with the phrase "or when the range of language tags > > supported in a given application are constrained." If the > application > > knows what language it is, it should use the correct tag, if one > > exists. If the application doesn't know what language is > in use, "und" would be correct. > > That's nice in theory. But some applications use a subset of > tags (I used the MARC21 example in the text) and then > transmit them through another system (where the larger range > of RFC 4646 is available). Those systems only know that the > content is 'mis' (because it is tagged that > way) and not what the miscellaneous language happens to be. > > We don't define what subtags applications are capable of > supporting or required to support elsewhere. We should focus > on providing appropriate guidance (which is not to use the > subtag). I note that Peter's use of MAY doesn't reflect the > current draft. > > I propose that we modify the draft to say the following. Please note: > the paragraph format is consistent with the other items in > that section. > I think that folks should glance at that text when proposing edits. > > -- > The 'mis' (Uncoded) primary language subtag is used to > identify linguistic content whose language is known but > cannot otherwise be identified. It is intended for use when > the range of language tags is constrained or for languages > not otherwise categorized. It SHOULD NOT be used except when > other means of identifying the language are not available. > For example, a library application might be limited to the > set of subtags defined for use by the [MARC21] standard. The 'mis' > subtag might be used by this application for languages not > included in that set. > -- > > Comments? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 18:33:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKMU-0001mR-V9; Fri, 15 Jun 2007 18:33:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzKMT-0001mM-UY for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 18:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKMT-0001mE-Kz for ltru@ietf.org; Fri, 15 Jun 2007 18:33:45 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKMT-0004M4-Bw for ltru@ietf.org; Fri, 15 Jun 2007 18:33:45 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 15:32:30 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Fri, 15 Jun 2007 15:33:44 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 15 Jun 2007 15:33:43 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: Acevl3QWNd6tBjvOQYy4cjmcVEK6UAAAn43w Message-ID: References: <001401c7af92$89fb9200$6601a8c0@oemcomputer> <002e01c7af98$03683800$6601a8c0@oemcomputer> In-Reply-To: <002e01c7af98$03683800$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> but that is part of the documented contract around 'mis' > > Which "documented contract"? I expect the ISO 639 RAs will be providing a usage note wrt 'mis' explainin= g that its extensional semantic must be defined in relation to an applicati= on context. This was one of the action items listed if the proposal to chan= ge the name were approved. I will follow up with the RAs on getting that do= ne. >> -- and why users need to understand its shortcomings, so also why users >> would probably be warned against exporting data. > > This is making the case for using "MUST NOT" rather than "SHOULD NOT". IMO, this is in the same line as people using a tag like "en-Latn": we say = "the script subtag SHOULD be omitted" in such cases, but not that they MUST= NOT include it in such cases. We expect users to make informed choices; we= 're not going to police them on certain things they *could* do but that wou= ldn't be wise to do in general. >> The only issue here is the inherent instability and shortcomings of 'mis= '. >> I don't see any abuse of BCP 47. There is nothing whatsoever like using >> "sw" to mean 'Swiss German'. > > Yes, it is in that permitting the tag to be used for languages for which = tags > already exist is in direct contradiction to its description. The issue here is evaluating "languages for which tags already exist". You'= re assuming that every application of BCP 47 must determine that based on t= he complete inventory of the LSTR. I'm assuming that a higher-level protoco= l can restrict the contents of the LSTR it permits and that it can also det= ermine the extension of 'mis' on the basis of its restricted set. I see the= se as two options we can permit; I don't see one of these excluded a priori= . It's a choice we should discuss and probably clarify in documenting 'mis'= (unless we decide to deprecate it). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 19:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzL4p-0001Oc-S7; Fri, 15 Jun 2007 19:19:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzL4o-0001OX-Iv for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 19:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzL4o-0001OP-9K for ltru@ietf.org; Fri, 15 Jun 2007 19:19:34 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzL4n-00062y-Um for ltru@ietf.org; Fri, 15 Jun 2007 19:19:34 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qL75hQ52XxW2ATgKYKsRPdMJlU8Pgqx4mjI4XGee5QBVBlq3i8wtDEf2vM8+tMLV; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzL4j-0002eT-5c for ltru@ietf.org; Fri, 15 Jun 2007 19:19:29 -0400 Message-ID: <000401c7afa4$342b51a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001401c7af92$89fb9200$6601a8c0@oemcomputer><002e01c7af98$03683800$6601a8c0@oemcomputer> Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 16:23:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356da03c45018f09bb239423547da1a782b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Friday, June 15, 2007 3:33 PM > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" ... > The issue here is evaluating "languages for which tags already exist". > You're assuming that every application of BCP 47 must determine that > based on the complete inventory of the LSTR. Yes. If an application lacks the knowledge to make that determination, "und" would be the correct choice. > I'm assuming that a higher-level protocol can restrict the contents of the > LSTR it permits As such, it would no longer support BCP 47. At a minimum, I would argue that a protocol that claims to support BCP 47 must be able to carry all valid tags, and should probably be able to carry all well-formed tags. Anything less is merely "based on" BCP 47. > and that it can also determine the extension of 'mis' on the basis of its > restricted set. This is simply not interoperable, as you've already explained. > I see these as two options we can permit; I don't see one of these > excluded a priori. It's a choice we should discuss and probably clarify > in documenting 'mis' (unless we decide to deprecate it). If someone decides a subset of BCP 47 is appropriate to their needs, that is fine, just as long as they don't claim to sully support BCP 47. Taken to absurdity, if my protocol offers a choice limited to "en" and "mis", should I be able to claim to support BCP 47? In any case, I'd really hate to have this WG go down the path of defining standardized "profiles" of BCP 47 unless there were a *huge* benefit to doing so. Just like the "adapted subset" of ASN.1 used in SMI MIB modules, at some point one has to admit that the subsetting and adaptation can result in a quite different beast from what one might have started with. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 20:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzM2v-00007Q-Qa; Fri, 15 Jun 2007 20:21:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzM2t-0008Sy-Oc for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 20:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzM2t-0008Sq-Ez for ltru@ietf.org; Fri, 15 Jun 2007 20:21:39 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzM2s-0002sp-6W for ltru@ietf.org; Fri, 15 Jun 2007 20:21:39 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 15 Jun 2007 17:20:22 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Fri, 15 Jun 2007 17:21:37 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 15 Jun 2007 17:21:35 -0700 Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: ISO 639-2 decision: "mis" Thread-Index: Acevo6UpNPhaS24QTxGjqswv4iMiOgAB86Gw Message-ID: References: <001401c7af92$89fb9200$6601a8c0@oemcomputer><002e01c7af98$03683800$6601a8c0@oemcomputer> <000401c7afa4$342b51a0$6601a8c0@oemcomputer> In-Reply-To: <000401c7afa4$342b51a0$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> and that it can also determine the extension of 'mis' on the basis of it= s >> restricted set. > > This is simply not interoperable, as you've already explained. Even treated as you proposed, 'mis' is inherently unstable wrt extension (a= nd always has been). That is part of the contract taken on by anybody who c= hooses to use it with any profile of language tags that is open to change. = You say that's not interoperable; I say it's interoperable given appropriat= ely low expectations of the usefulness of 'mis' in interchange. > In any case, I'd really hate > to have this WG go down the path of defining standardized > "profiles" of BCP 47 unless there were a *huge* benefit to doing so. Absolute agreement. I have never suggested we should define standardized "p= rofiles". If a consuming protocol wishes to do so, that's entirely up to th= em -- we certainly should not do it for them. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 15 20:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzMIH-0005jZ-4A; Fri, 15 Jun 2007 20:37:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzMIG-0005jU-G6 for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 20:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzMIG-0005jM-6V for ltru@ietf.org; Fri, 15 Jun 2007 20:37:32 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound1-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzMIE-0006zv-Ff for ltru@ietf.org; Fri, 15 Jun 2007 20:37:32 -0400 Received: from outbound1-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-dub-R.bigfish.com (Postfix) with ESMTP id CFAC48FFCEE; Sat, 16 Jun 2007 00:37:11 +0000 (UTC) Received: from mail77-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound1-dub.bigfish.com (Postfix) with ESMTP id B5DDBD18069; Sat, 16 Jun 2007 00:37:11 +0000 (UTC) Received: from mail77-dub (localhost.localdomain [127.0.0.1]) by mail77-dub-R.bigfish.com (Postfix) with ESMTP id 82B859F021D; Sat, 16 Jun 2007 00:37:11 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail77-dub (MessageSwitch) id 1181954231109526_26302; Sat, 16 Jun 2007 00:37:11 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail77-dub.bigfish.com (Postfix) with ESMTP id B2DC378005E; Sat, 16 Jun 2007 00:37:10 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007061517370559-99323 ; Fri, 15 Jun 2007 17:37:05 -0700 In-Reply-To: <000401c7afa4$342b51a0$6601a8c0@oemcomputer> To: "Randy Presuhn" Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Fri, 15 Jun 2007 17:20:13 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 06/15/2007 17:35:04, Serialize complete at 06/15/2007 17:35:04, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 05:37:05 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/15/2007 05:37:10 PM, Serialize complete at 06/15/2007 05:37:10 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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="===============0869136538==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0869136538== Content-Type: multipart/alternative; boundary="=_alternative 00020936882572FC_=" This is a multipart message in MIME format. --=_alternative 00020936882572FC_= Content-Type: text/plain; charset="US-ASCII" Randy writes: > As such, it would no longer support BCP 47. > At a minimum, I would argue that a protocol that claims to support BCP 47 > must be able to carry all valid tags, and should probably be able to carry > all well-formed tags. Anything less is merely "based on" BCP 47. > If someone decides a subset of BCP 47 is appropriate to their needs, > that is fine, just as long as they don't claim to sully support BCP 47. There's a difference between "fully supporting" BCP 47 and being compliant with BCP 47. I don't think there's any organization that has a real-life use for fully supporting BCP 47. These codes are frequently used in databases; if a developer limits the size of that field such that the most granular private use tag imaginable does not fit the space allocated, you consider that to an implementation "based on" BCP 47 even if all tags in the system are valid? I don't think what you suggest is a useful or realistic way of looking at this. If I only need en, fr, de, and it, I think that's fully compliant with BCP 47. Must I support gsw-Hant-BV-x-chicago-mwbstr14-spoken to claim to be aligned with BCP 47? Regards, Karen Broome --=_alternative 00020936882572FC_= Content-Type: text/html; charset="US-ASCII"
Randy writes:

> As such, it would no longer support BCP 47.
> At a minimum, I would argue that a protocol that claims to support BCP 47
> must be able to carry all valid tags, and should probably be able to carry
> all well-formed tags.  Anything less is merely "based on" BCP 47.

> If someone decides a subset of BCP 47 is appropriate to their needs,
> that is fine, just as long as they don't claim to sully support BCP 47.

There's a difference between "fully supporting" BCP 47 and being compliant with BCP 47. I don't think there's any organization that has a real-life use for fully supporting BCP 47. These codes are frequently used in databases; if a developer limits the size of that field such that the most granular private use tag imaginable does not fit the space allocated, you consider that to an implementation "based on" BCP 47 even if all tags in the system are valid?

I don't think what you suggest is a useful or realistic way of looking at this. If I only need en, fr, de, and it, I think that's fully compliant with BCP 47. Must I support gsw-Hant-BV-x-chicago-mwbstr14-spoken to claim to be aligned with BCP 47?

Regards,

Karen Broome --=_alternative 00020936882572FC_=-- --===============0869136538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0869136538==-- From ltru-bounces@ietf.org Fri Jun 15 23:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOir-0003FV-F6; Fri, 15 Jun 2007 23:13:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzOiq-0003FQ-Ii for ltru-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 23:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOiq-0003FF-95 for ltru@ietf.org; Fri, 15 Jun 2007 23:13:08 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzOio-0005DL-Ts for ltru@ietf.org; Fri, 15 Jun 2007 23:13:08 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CcVC6zvKMovxGpq/gEUATQbnnPz8Ek37TrJf3TvK9MAKolzBHVEY0usDZg5BTUKB; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.204.252] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzOio-0006aR-9B for ltru@ietf.org; Fri, 15 Jun 2007 23:13:06 -0400 Message-ID: <000b01c7afc4$d82fa380$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" Date: Fri, 15 Jun 2007 20:17:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93563578a2765b39a1c58a95b003e3bab509350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor.... > From: > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Friday, June 15, 2007 5:20 PM > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" ... > There's a difference between "fully supporting" BCP 47 and being compliant > with BCP 47. I don't think there's any organization that has a real-life > use for fully supporting BCP 47. These codes are frequently used in > databases; if a developer limits the size of that field such that the most > granular private use tag imaginable does not fit the space allocated, you > consider that to an implementation "based on" BCP 47 even if all tags in > the system are valid? RFC 4646 says support for a maximum of at least 33 characters is a MUST, 42 characters is a SHOULD. Anything less is not BCP 47. > I don't think what you suggest is a useful or realistic way of looking at > this. If I only need en, fr, de, and it, I think that's fully compliant > with BCP 47. Must I support gsw-Hant-BV-x-chicago-mwbstr14-spoken to claim > to be aligned with BCP 47? If someone designs a protocol, and it can only handle the language tags en, fr, de, and it, that protocol, in my judgement, would not be compliant with BCP 47. This doesn't say anything about the tags that a particular application using that protocol might *generate*. I'm just saying that it must be able to cope with receiving valid tags of up to 33 characters in length. I'm urging folks to think about where this specification sits in the "food chain". It specifies an element that is used by other protocols. If other protocols can claim to use this specification, without actually being able to carry the full range of values, there will be little value to having this specification or to claiming to support it. It'd be like claiming to support ASCII, but not permitting use of the letter "Z". I fully recognize that for good historical reasons there will be protocols that are restricted to a subset. However, I'd strongly urge against claiming that such protocols "supported" or were "aligned with", much less "conformant with" BCP 47. I think part of the disconnect is that some have been thinking about databases, rather than protocols. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 02:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzSA0-00049Q-Ee; Sat, 16 Jun 2007 02:53:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzS9z-00049G-9l for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 02:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzS9y-000493-Vk for ltru@ietf.org; Sat, 16 Jun 2007 02:53:22 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzS9y-0005Pe-IQ for ltru@ietf.org; Sat, 16 Jun 2007 02:53:22 -0400 Received: from c83-248-99-161.bredband.comhem.se ([83.248.99.161]:1482 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1HzS9x-00087m-7b; Sat, 16 Jun 2007 08:53:21 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" , "'Milicent K Wewerka'" Date: Sat, 16 Jun 2007 08:52:34 +0200 Message-ID: <000501c7afe3$09680f00$a163f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceuelsK98EmCjkLSLazTa3Xyg/kFwAK+kTQAE8VHyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Originating-IP: 83.248.99.161 X-Scan-Result: No virus found in message 1HzS9x-00087m-7b. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HzS9x-00087m-7b 7e2c57117d80528cbda839f133a1aa51 X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ietf-languages@iana.org Subject: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Milicent K Wewerka wrote: > The usage of "mis" won't necessarily be narrower over time. That assumes that some codes are actively removed (not just deprecated), for some language (or "language collection") that actually exits. I doubt that will happen in ISO 639, though that make happen in some application (like MARC) that pick up just a subset of the ISO 639 tags. > At least in > the MARC code list it is possible that languages could still > be added to the scope of "mis." MARC is just one application of 639, not THE application of 639. Note also that you erroneously conflate two issues here: 1) Which languages are covered by 'mis' in the MARC application of 639, and 2) which of those languages that are explicitly mentioned in some list for MARC. For the first one, that is most likely quite a lot of languages (every language not having a code in MARC). For the second one, it is just a matter of making explicit a few of the languages covered by 'mis' in the MARC application. You can make explicit quite a few more languages without changing which languages are covered by 'mis' in the MARC application (i.e. a change of no actual consequence). > The scope of "und" as I understand it would be when you > cannot identify which language you have. No, it is for use when the language *has* not been identified. Not at all the same as *cannot* be identified. > That is a quite different concept than to say > I know what language it is but there is no coded identifier for the > language. Yes, but from a coverage point of view, 'und' covers all languages as well as 'zxx' and 'mul'. Not a far cry from what 'mis' used to cover (namely all (natural, and natural-like) languages). And you have not given any other option than 'und' (and private use codes) as a replacement for what 'mis' used to cover (as a collection). With this change you have turned a fairly logical system into one that has an illogical and quite unnecessary exception. I fail to see why that would be a good thing. And with this change, an application of ISO 639 that requires stability over time, like IEFT language tags, unstable tags (w.r.t. coverage of languages) are highly detrimental. With the "old mis" one could correctly apply 'mis' as a language code for any language (though one should apply a more specific code if one is "available"), and stably so. With the "new mis" that is not possible. IIUC, for all other collections there are plans do make a clarification (not a change) in the opposite direction, removing the confusing (but in ISO 639 context, meaningless) word "other" in some of the collection names. /Kent Karlsson > Milicent Wewerka > Library of Congress _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 11:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaDV-0005R4-UZ; Sat, 16 Jun 2007 11:29:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzaDU-0005Pm-Mj for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 11:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaDU-0005Nj-9e for ltru@ietf.org; Sat, 16 Jun 2007 11:29:32 -0400 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaDT-0003Uk-RM for ltru@ietf.org; Sat, 16 Jun 2007 11:29:32 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1082805nzd for ; Sat, 16 Jun 2007 08:29:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=S+WCW49yO4u9uPnq9ZXyD5v3QyJHyEtCybyy6ujzfZsNpLwR4kDiJ1HuZLaCeeYLkOwb2BNL9Sv49qNpFBj93tnJ66WVv5D4aVN7XDvYRpHg99fCewpBPHcWCa/485+vaBqsrbo8BT4qQ6ouphJ9piI6AHXJBiFrMv58R7H74sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=N6cPr1IOy9+oHXgzWixTnqj7V9jYIrmIbr5ffdxIDeroCAiVaEsomKyKMgL3sp7hjOwZFzFyly5T+dLuz9wuHjcIu3Cfu5W1OgBIlI9VUIfvJCQpQruBEn3O22p7hZwTDXdzKly8Lp3LspFBxykLv31vq52xlNOgt/UM8KmKfoM= Received: by 10.114.202.15 with SMTP id z15mr4230362waf.1182007771207; Sat, 16 Jun 2007 08:29:31 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Sat, 16 Jun 2007 08:29:31 -0700 (PDT) Message-ID: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> Date: Sat, 16 Jun 2007 08:29:31 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") MIME-Version: 1.0 X-Google-Sender-Auth: eb48b17a593c58ee X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0201108485==" Errors-To: ltru-bounces@ietf.org --===============0201108485== Content-Type: multipart/alternative; boundary="----=_Part_73706_27881515.1182007771179" ------=_Part_73706_27881515.1182007771179 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline That's going in the right direction, but doesn't not given enough guidance as to why to avoid it. My suggested language: The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags. Mark On 6/15/07, Addison Phillips wrote: > > Randy Presuhn wrote: > > > > I disagree with the phrase "or when the range of language tags supported > in > > a given application are constrained." If the application knows what > language > > it is, it should use the correct tag, if one exists. If the application > doesn't > > know what language is in use, "und" would be correct. > > That's nice in theory. But some applications use a subset of tags (I > used the MARC21 example in the text) and then transmit them through > another system (where the larger range of RFC 4646 is available). Those > systems only know that the content is 'mis' (because it is tagged that > way) and not what the miscellaneous language happens to be. > > We don't define what subtags applications are capable of supporting or > required to support elsewhere. We should focus on providing appropriate > guidance (which is not to use the subtag). I note that Peter's use of > MAY doesn't reflect the current draft. > > I propose that we modify the draft to say the following. Please note: > the paragraph format is consistent with the other items in that section. > I think that folks should glance at that text when proposing edits. > > -- > The 'mis' (Uncoded) primary language subtag is used to identify > linguistic content whose language is known but cannot otherwise be > identified. It is intended for use when the range of language tags is > constrained or for languages not otherwise categorized. It SHOULD NOT be > used except when other means of identifying the language are not > available. For example, a library application might be limited to the > set of subtags defined for use by the [MARC21] standard. The 'mis' > subtag might be used by this application for languages not included in > that set. > -- > > Comments? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_73706_27881515.1182007771179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That's going in the right direction, but doesn't not given enough guidance as to why to avoid it. My suggested language:

The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags.

Mark

On 6/15/07, Addison Phillips <addison@yahoo-inc.com> wrote:
Randy Presuhn wrote:
>
> I disagree with the phrase "or when the range of language tags supported in
> a given application are constrained."  If the application knows what language
> it is, it should use the correct tag, if one exists.  If the application doesn't
> know what language is in use, "und" would be correct.

That's nice in theory. But some applications use a subset of tags (I
used the MARC21 example in the text) and then transmit them through
another system (where the larger range of RFC 4646 is available). Those
systems only know that the content is 'mis' (because it is tagged that
way) and not what the miscellaneous language happens to be.

We don't define what subtags applications are capable of supporting or
required to support elsewhere. We should focus on providing appropriate
guidance (which is not to use the subtag). I note that Peter's use of
MAY doesn't reflect the current draft.

I propose that we modify the draft to say the following. Please note:
the paragraph format is consistent with the other items in that section.
I think that folks should glance at that text when proposing edits.

--
The 'mis' (Uncoded) primary language subtag is used to identify
linguistic content whose language is known but cannot otherwise be
identified. It is intended for use when the range of language tags is
constrained or for languages not otherwise categorized. It SHOULD NOT be
used except when other means of identifying the language are not
available. For example, a library application might be limited to the
set of subtags defined for use by the [MARC21] standard. The 'mis'
subtag might be used by this application for languages not included in
that set.
--

Comments?

Addison

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

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_73706_27881515.1182007771179-- --===============0201108485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0201108485==-- From ltru-bounces@ietf.org Sat Jun 16 11:33:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaHj-0001cg-IP; Sat, 16 Jun 2007 11:33:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzaHi-0001cb-7o for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 11:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaHh-0001cT-Ue for ltru@ietf.org; Sat, 16 Jun 2007 11:33:53 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaHg-0004hZ-Lj for ltru@ietf.org; Sat, 16 Jun 2007 11:33:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070616153346.OEHX28813.mta9.adelphia.net@DGBP7M81>; Sat, 16 Jun 2007 11:33:46 -0400 Message-ID: <002501c7b02b$ba8b4480$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20070615100003.4A9AB259727@eikenes.alvestrand.no> <004c01c7af59$df123110$6401a8c0@DGBP7M81> <20070615152643.GA8769@mercury.ccil.org> <4672D3A9.5040804@yahoo-inc.com> <4672E31F.2040806@yahoo-inc.com> Subject: Re: [Ltru] Re: Variant tags for sl-rozaj: History and preliminaries Draft of message Date: Sat, 16 Jun 2007 08:33:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > On this issue... I was surprised how many places this needed to be fixed. Any time we try to say the same thing, or close, in multiple places, there's a chance they won't all agree with one another. But I'm glad Addison went through and found all these. > The word "suitable prefix" at least conveys some intention for the subtags > to fall to the left of the variant in question. Correct. For my part I understood the existing text just fine, with its heavy dependence on the word "prefix." I suppose we've learned lately that ordinary words like "miscellaneous" and "prefix" mean different things to different people, and some extra clarification is often needed. > That is, each of the subtags in the prefix MUST appear before the variant > in a valid tag. > -- > > Note here the use of the word 'valid' in conjunction with MUST. That's right. "sl-biske-rozaj" would be well-formed but not valid. I think these changes should be sufficient. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 11:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaLC-0003wl-0K; Sat, 16 Jun 2007 11:37:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzaLA-0003wd-Is for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 11:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaLA-0003wV-9K for ltru@ietf.org; Sat, 16 Jun 2007 11:37:28 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaL7-00055E-KZ for ltru@ietf.org; Sat, 16 Jun 2007 11:37:28 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1770254wah for ; Sat, 16 Jun 2007 08:37:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qWlhg5H2nmaIrkFEUGYb8ObkVermSebC5EbNRkOFIChNWASh4U3iJH/LiQTZaItT+0O6GLlKLX978WBMd/rgxUt+HvFzWPMhUSQVu+wn1dT9Nqa4r+o638vqneizs8OOpcm83WhbOzDHSUJwV62J3YtSrCAPEIUmh9WVE3IpgAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NZPqitiMNlz2MO8ZO+UAALtlQUruL9ceUEu+T/J1vKHsQKsjI96myfL45njF8o7fLcQaDtmc0vYRv/eq4Kun6HCM1WnKqQsS9v0lkgvs8mZEbFTVWmgVO4nWUHs19pf3l/Ue1sXtTU7zsO/DA8MIG1LwyLjtk7Mdgcj3QcU9GbE= Received: by 10.114.108.15 with SMTP id g15mr4272039wac.1182008244467; Sat, 16 Jun 2007 08:37:24 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Sat, 16 Jun 2007 08:37:24 -0700 (PDT) Message-ID: <30b660a20706160837v5db90217wadbc262381c4b67e@mail.gmail.com> Date: Sat, 16 Jun 2007 08:37:24 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" In-Reply-To: MIME-Version: 1.0 References: <002f01c7af6c$a4659d00$6601a8c0@oemcomputer> <00f301c7af79$32c19700$6601a8c0@oemcomputer> X-Google-Sender-Auth: 5cdc1f8529e206cc X-Spam-Score: 0.5 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0206887883==" Errors-To: ltru-bounces@ietf.org --===============0206887883== Content-Type: multipart/alternative; boundary="----=_Part_73794_20794888.1182008244390" ------=_Part_73794_20794888.1182008244390 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree strongly with Peter. Let's suppose I have a SOAP service using the BCP 47 protocol for communicating UI language preferences. My application doesn't support (surprise) all possible BCP 47 language subtags, and communicates an error back to the requester indicating when I don't accept a particular language. Such action doesn't make me uncompliant. The key for compliance is that if I say I'm interpreting a field according to BCP 47, - I do not accept anything that isn't BCP 47 compliant, - Anything that I accept has to be interpreted according to BCP 47 semantics. There are other kinds of reasonable claims that I can make. I can say, for example, that I interpret a field according to BCP 47, but with the addition of 4 exceptions for backwards compatibility with previous versions of my software. Mark On 6/15/07, Peter Constable wrote: > > You appear to be assuming that for something to qualify as "an application > of BCP 47" it must support all tags defined by BCP 47. > > I would certainly agree that a BCP 47-conformant parser must fully support > the syntax that's defined, and for a BCP-47 validator to validate all and > only tags that are defined in relation to a given snapshot of the registry. > > But I see no reason why a higher-level protocol cannot restrict the set of > tags it accepts and still be considered "an application of BCP 47". I > wouldn't be surprised if was actually common for people to create > higher-level protocols that normatively reference BCP 47 but that define > some subset of tags that are permitted. What is the problem in saying those > are "applications of BCP 47"? It would certainly be getting applied in those > cases. > > > Peter > > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, June 15, 2007 11:16 AM > To: LTRU Working Group > Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis" > > Hi - > > As a technical contributor... > > > From: "Peter Constable" > > To: "LTRU Working Group" > > Sent: Friday, June 15, 2007 11:02 AM > > Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" > ... > > MARC is an application context -- an application of language tags, not > an > > application in the sense of a piece software. In that application > context, only > > IDs from 639-2 can be used: that is a constraint on the range of > language tags > > supported in that application context. > > As such, I'd argue that these constraints mean it isn't an application of > BCP 47. > > > Whether a user or a software process is assigning tags, the options are > not > > necessarily binary, as you suggest: in that application context it is > entirely possible > > for the language of given content to be known but not to be within the > restricted set > > permitted by MARC. > > These things might be called tags, and they might even be a subset of the > set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* > an > application of BCP 47, and, consequently, is not our problem. > > 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 > -- Mark ------=_Part_73794_20794888.1182008244390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree strongly with Peter. Let's suppose I have a SOAP service using the BCP 47 protocol for communicating UI language preferences. My application doesn't support (surprise) all possible BCP 47 language subtags, and communicates an error back to the requester indicating when I don't accept a particular language. Such action doesn't make me uncompliant.

The key for compliance is that if I say I'm interpreting a field according to BCP 47,
  • I do not accept anything that isn't BCP 47 compliant,
  • Anything that I accept has to be interpreted according to BCP 47 semantics.
There are other kinds of reasonable claims that I can make. I can say, for example, that I interpret a field according to BCP 47, but with the addition of 4 exceptions for backwards compatibility with previous versions of my software.

Mark

On 6/15/07, Peter Constable <petercon@microsoft.com> wrote:
You appear to be assuming that for something to qualify as "an application of BCP 47" it must support all tags defined by BCP 47.

I would certainly agree that a BCP 47-conformant parser must fully support the syntax that's defined, and for a BCP-47 validator to validate all and only tags that are defined in relation to a given snapshot of the registry.

But I see no reason why a higher-level protocol cannot restrict the set of tags it accepts and still be considered "an application of BCP 47". I wouldn't be surprised if was actually common for people to create higher-level protocols that normatively reference BCP 47 but that define some subset of tags that are permitted. What is the problem in saying those are "applications of BCP 47"? It would certainly be getting applied in those cases.


Peter


-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: Friday, June 15, 2007 11:16 AM
To: LTRU Working Group
Subject: Re: [Ltru] RE: ISO 639-2 decision: "mis"

Hi -

As a technical contributor...

> From: "Peter Constable" <petercon@microsoft.com >
> To: "LTRU Working Group" <ltru@ietf.org>
> Sent: Friday, June 15, 2007 11:02 AM
> Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis"
...
> MARC is an application context -- an application of language tags, not an
> application in the sense of a piece software. In that application context, only
> IDs from 639-2 can be used: that is a constraint on the range of language tags
> supported in that application context.

As such, I'd argue that these constraints mean it isn't an application of BCP 47.

> Whether a user or a software process is assigning tags, the options are not
> necessarily binary, as you suggest: in that application context it is entirely possible
> for the language of given content to be known but not to be within the restricted set
> permitted by MARC.

These things might be called tags, and they might even be a subset of the
set of strings that are well-formed, valid BCP 47 tags, but this is *NOT* an
application of BCP 47, and, consequently, is not our problem.

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



--
Mark ------=_Part_73794_20794888.1182008244390-- --===============0206887883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0206887883==-- From ltru-bounces@ietf.org Sat Jun 16 11:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaYL-0007r3-SM; Sat, 16 Jun 2007 11:51:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzaYJ-0007qw-UH for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 11:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaYJ-0007qn-JH for ltru@ietf.org; Sat, 16 Jun 2007 11:51:03 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaYH-0006zH-Ms for ltru@ietf.org; Sat, 16 Jun 2007 11:51:03 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070616155101.TZJE3928.mta15.adelphia.net@DGBP7M81> for ; Sat, 16 Jun 2007 11:51:01 -0400 Message-ID: <002901c7b02e$22fc9030$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Jun 2007 08:50:59 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> MARC is an application context -- an application of language tags, not an >> application in the sense of a piece software. In that application >> context, only IDs from 639-2 can be used: that is a constraint on the >> range of language tags supported in that application context. > > As such, I'd argue that these constraints mean it isn't an application of > BCP 47. I agree with Randy on this. Section 2.2 of RFC 4646 says, "The Language Subtag Registry maintained by IANA is the source for valid subtags." That is clear and unequivocal. There will, of course, be systems and applications that are not fully conformant to BCP 47, with which conformant applications will have to interoperate, and that is fine and expected. Those systems will impose their own restrictions. Perhaps the worst cases are the simple-minded applications that assume a language tag must consist of a 2-letter language optionally followed by a hyphen and a 2-letter country, which isn't even conformant to RFC 1766. But we are talking about making a change *to BCP 47 itself* that specifies the use of "mis" when the full Registry is not available, and that is not right. Applications that have such a restriction, such as MARC apparently, do not attempt to conform to BCP 47, and so there is no point in putting text in BCP 47 that makes their limitations conformant. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 11:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzagA-0008IC-LO; Sat, 16 Jun 2007 11:59:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzag9-0008I4-P3 for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 11:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzag9-0008Hw-Fc for ltru@ietf.org; Sat, 16 Jun 2007 11:59:09 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzag8-0008LT-3L for ltru@ietf.org; Sat, 16 Jun 2007 11:59:09 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070616155907.DLLR15873.mta10.adelphia.net@DGBP7M81> for ; Sat, 16 Jun 2007 15:59:07 +0000 Message-ID: <003501c7b02f$44fdbe60$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Jun 2007 08:59:06 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I expect the ISO 639 RAs will be providing a usage note wrt 'mis' > explaining that its extensional semantic must be defined in relation to an > application context. This was one of the action items listed if the > proposal to change the name were approved. I will follow up with the RAs > on getting that done. I hope there is no expectation that this "usage note," whenever the RAs approve and publish it, needs to be copied to the Language Subtag Registry. I am already waiting for the online ISO 639-2 code lists to be updated (and only for that) before submitting a change request for the Registry for "mis". Any further elaboration on this very, very edge-case subtag needs to reside in RFC 4646bis and not within the Registry. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzavt-00044z-U5; Sat, 16 Jun 2007 12:15:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzavs-00044t-9q for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzavs-00044l-0L for ltru@ietf.org; Sat, 16 Jun 2007 12:15:24 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzavq-00066P-Np for ltru@ietf.org; Sat, 16 Jun 2007 12:15:23 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070616161514.RFAR28813.mta9.adelphia.net@DGBP7M81> for ; Sat, 16 Jun 2007 12:15:14 -0400 Message-ID: <003901c7b031$85b1b310$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Jun 2007 09:15:14 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I also agree with Randy that a private-use tag would be a much better choice than "mis" for tagging content in a language with no available subtag, either because the Registry doesn't have one or in the case of a non-BCP 47 application that uses a subset of the full Registry. If I want to tag text in Unilingua (http://en.wikibooks.org/wiki/Unilingua) you can bet I'll use "x-mirad" or something similar long before I use the completely uninformative "mis". -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:31:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbBq-0003Pd-7f; Sat, 16 Jun 2007 12:31:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzWj9-0005RB-JS for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 07:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzWj9-0005Pi-9G for ltru@ietf.org; Sat, 16 Jun 2007 07:45:59 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzWj6-0004PV-PM for ltru@ietf.org; Sat, 16 Jun 2007 07:45:59 -0400 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 9E6EF18CA6; Sat, 16 Jun 2007 13:45:44 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 Jun 2007 13:24:53 +0200 To: han.steenwijk@unipd.it,"LTRU Working Group" From: Délégué Général In-Reply-To: <1039.87.4.187.51.1181889920.squirrel@webmail.unipd.it> References: <1039.87.4.187.51.1181889920.squirrel@webmail.unipd.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070616114544.9E6EF18CA6@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Sat, 16 Jun 2007 12:31:53 -0400 Cc: ietf-languages@alvestrand.no, ietf-languages@jefsey.com Subject: [Ltru] Re: Variant tags for sl-rozaj: History and preliminaries Draft of message X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Han, I am certainly delighted by your request and the answers you get. I had to made a lot of fuss to obtain the temporarily interoperable, hence acceptable, RFC 4646 text we currently have, through clarifications mostly against me. However, I must be loyal and clear to every of yours: every decision you take on a given example and class of needs may restrict the whole RFC to that unique case in that class. If I am correct, the basic idea of the langtag designers was to preserve compatibility with RFC 3066. Preserving internal compatibility seems to be important the same. The responses you receive are enforcing the strictly hierarchical vision of languages that some favor, who had reasonably be made possible but not enforced. The way I see it, the more you ("Unicode lobby") go the way you currently go, the more you associate RFC 4646 with linguists needs and content layers only. And therefore, the more you dissociate langtags from the container, network, and readership layers. No problem with me: I think this is correct, that cctags will fully support them, and in full elegant respect of RFC 4646 (private). I thought only fair to underline it, in case some of you have "in between" applications I did not think of and cctags could not support in case of conflict between their equivalent langtag. The more I go, the more I see there is an interintelligibility aspect due to the way RFC 4646 uses ISO 639 (which documents language names code elements) as a source for langtags which document language code elements. This means that strict interoperability cannot apply between fuzzy notions, but one can organise mutual intelligibility enough for things to usually work: "I do not know exactly what you talk about, but I understand enough about it for _my_ kind of use". But it also leads to confusions. For example, there is a tendency to confuse ISO 3166-1:2006's administrative languages with ISO 639 language names. This in turn risk to unstabilize the whole digital system's virtuality. Everything is tied together within the global metastructure. Good luck. jfc At 08:45 15/06/2007, han.steenwijk@unipd.it wrote: >Earlier on, I enthusiastically said that "even the order of the variant >tags within the language tag is determined by the Prefix fields." > >However, the following statement from RFC 4646 makes me somewhat uncertain >on this point: > >An implementation that claims to be validating MUST: >... >For variant and extended language subtags, if the registry contains one or >more 'Prefix' fields for that subtag, check that the tag matches at least >one prefix. The tag matches if all the subtags in the 'Prefix' also appear >in the tag. For example, the prefix "es-CO" matches the tag >"es-Latn-CO-x-private" because both the 'es' language subtag and 'CO' >region subtag appear in the tag. >(From: 2.2.9. Classes of Conformance) > >This makes me think that, with a prefix 'sl-rozaj' for the variant subtag >'biske', both "sl-rozaj-biske" and "sl-biske-rozaj" would be valid tags, >as in either case the 'sl' language subtag and 'rozaj' variant subtag >appear in the language tag. Has it somewhere been determined that the >subtags that make up a prefix should all occur to the left of the variant >subtag to which the prefix applies? Actually, that is what the notion >'prefix' entails. > >If no such provision has been made, could the Preferred-Value field be >used to order variant subtags? > >Han > > >-- >Prof. Han Steenwijk >Cattedra di Lingua e Letteratura Slovena >Universita' di Padova >Dipartimento di Lingue e Letterature Anglo-Germaniche e Slave >Sezione di Slavistica >Via Beldomandi, 1 >I-35139 Padova > >tel. 049 8278669 >fax. 049 8278679 > >_______________________________________________ >Ietf-languages mailing list >Ietf-languages@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbGk-0003iU-Gp; Sat, 16 Jun 2007 12:36:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzbGk-0003iP-3v for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbGj-0003iH-Qi for ltru@ietf.org; Sat, 16 Jun 2007 12:36:57 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbGi-0001uO-Fl for ltru@ietf.org; Sat, 16 Jun 2007 12:36:57 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070616163656.WZAJ3928.mta15.adelphia.net@DGBP7M81> for ; Sat, 16 Jun 2007 12:36:56 -0400 Message-ID: <005701c7b034$8d09dbd0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 16 Jun 2007 09:36:54 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org GerardM wrote: > Standards have a tendency to lag behind what is accepted to be true. When > a standard does not acknowledge a specific language of linguistic entity > yet because it is not in that version of the standard, a tag could be not > available because a specific version of standard has not been ratified > yet. Responding to what I think Gerard's point is: A language subtag MUST exist in the Language Subtag Registry, or be a private-use subtag or tag, in order to be used conformantly with RFC 4646. There is no provision in RFC 4646 for using two- and three-letter language subtags that are not in a past or present version of ISO 639-1 or -2 (future: or -3) but are "accepted to be true" under some criterion. This goes for other types of subtags as well. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:39:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbJN-00041l-21; Sat, 16 Jun 2007 12:39:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzbJM-00041g-4O for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbJL-00041S-Qv for ltru@ietf.org; Sat, 16 Jun 2007 12:39:39 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbJI-0002Hv-Gd for ltru@ietf.org; Sat, 16 Jun 2007 12:39:39 -0400 Received: from spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) by mail.cs.tut.fi (Postfix) with ESMTP id AE09010A6 for ; Sat, 16 Jun 2007 19:39:35 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam2.cs.tut.fi (spam2.cs.tut.fi [130.230.4.7]) (amavisd-maia, port 10024) with ESMTP id 20011-22-3 for ; Sat, 16 Jun 2007 19:39:35 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 1E18D1043 for ; Sat, 16 Jun 2007 19:39:35 +0300 (EEST) Date: Sat, 16 Jun 2007 19:39:34 +0300 (EEST) From: "Jukka K. Korpela" To: 'LTRU Working Group' Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 15 Jun 2007, Debbie Garside wrote: > "It should only be used when other means of identifying the language are > unavailable." The meaning of "mis" does not quite fall into the scope of the meaning of "to identify", the way I see it. The language is not identified, but some indirect information about language is given. Perhaps "indicating" could be used instead of "identifying", but the following formulation might be better: "It should only be used when more specific means of giving information about the language are unavailable." -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:40:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbKF-0004Tq-Cy; Sat, 16 Jun 2007 12:40:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzbKD-0004Tf-QX for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbKD-0004TQ-Gx for ltru@ietf.org; Sat, 16 Jun 2007 12:40:33 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbKC-0002N1-7s for ltru@ietf.org; Sat, 16 Jun 2007 12:40:33 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Hgy3F5KamckRyYhN/8zGyDRzebxVpEUVjAwCUmWUChh+NKN28dQR2yNnJPYMDqqV; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.45] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzbKB-0002By-KV for ltru@ietf.org; Sat, 16 Jun 2007 12:40:31 -0400 Message-ID: <001e01c7b035$1034cec0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Sat, 16 Jun 2007 09:40:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356f984cebcd77ae938d4d07ab90abfb4ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ltru] Apology for erroniously approved posting X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - I apologize for permitting a posting to get through to the ltru list that should have been discarded. My only excuse is lack of caffeine. :-( Randy as list admin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbQj-0005Zr-2M; Sat, 16 Jun 2007 12:47:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzbQh-0005Kc-DW for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbQg-0005Fx-St for ltru@ietf.org; Sat, 16 Jun 2007 12:47:14 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbQf-0003QG-LV for ltru@ietf.org; Sat, 16 Jun 2007 12:47:14 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qduozkr7JP6qudxAt2o7bLdFFtObsBMgDPqGk0hB829Ddy1m8qnUeoTho4gN+vhd; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.45] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HzbQa-0006pK-Qt for ltru@ietf.org; Sat, 16 Jun 2007 12:47:09 -0400 Message-ID: <003301c7b035$fd9f9dc0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") Date: Sat, 16 Jun 2007 09:47:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93563a9af384c799adc333999e7196a9cee8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Addison Phillips" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, June 16, 2007 8:29 AM > Subject: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") > > That's going in the right direction, but doesn't not given enough guidance > as to why to avoid it. My suggested language: > > The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to > ISO 639, it is used to identify linguistic content whose language is known > but which does not *currently* have a corresponding subtag. It is thus > intrinsically unstable -- the addition of other codes in the future can > render its application invalid at any point without any warning -- and hence > incompatible with the stability goals of BCP 47. It is thus always > preferable to use other subtags: either "und" or -- with prior agreement -- > private use subtags. ... As a technical contributor, I rather like this proposal. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 12:48:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbS8-00083B-OA; Sat, 16 Jun 2007 12:48:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzbS7-000836-TN for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 12:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbS7-00082y-Jx for ltru@ietf.org; Sat, 16 Jun 2007 12:48:43 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbS7-0003xV-As for ltru@ietf.org; Sat, 16 Jun 2007 12:48:43 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070616164842.LCFB3934.mta11.adelphia.net@DGBP7M81> for ; Sat, 16 Jun 2007 12:48:42 -0400 Message-ID: <005901c7b036$3248e8b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") Date: Sat, 16 Jun 2007 09:48:41 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis proposed: > The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According > to ISO 639, it is used to identify linguistic content whose language is > known but which does not *currently* have a corresponding subtag. It is > thus intrinsically unstable -- the addition of other codes in the future > can render its application invalid at any point without any warning -- and > hence incompatible with the stability goals of BCP 47. It is thus always > preferable to use other subtags: either "und" or -- with prior > agreement -- private use subtags. I am OK with this except for the recommendation to use "und". If the "language is known," then it is not "undetermined." I suggest: "It is thus always preferable to use private-use subtags with prior agreement." I might quibble with the wording "without any warning," since every time a new language subtag is added to the Registry, that language is potentially removed from the scope of "mis" (or it might be removed from the scope of some other language subtag, which is thus "narrowed," which is its own discussion). I hate the way this minor and largely theoretical edge case is dragging down the project. Are we almost ready to go with 4646bis except for "mis"? Do any other issues needs to be resolved? If so, can we spend some time on those issues as well? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 13:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzbvn-0003gA-Cr; Sat, 16 Jun 2007 13:19:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzbvl-0003g5-Ba for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 13:19:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzbvl-0003fx-0C for ltru@ietf.org; Sat, 16 Jun 2007 13:19:21 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hzbvh-0002HA-3M for ltru@ietf.org; Sat, 16 Jun 2007 13:19:20 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1795078wah for ; Sat, 16 Jun 2007 10:19:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Lod273NXtFiRnF7/Z8gOgi08dP9aQeDJQQsub5gTxnpZFCkf40LBcv3U166m19dPfTSqtMmfrugezNtLw04NBAXotwlpJc5ldb43njmK4rD0Wh1SeIO+nWEWrnOd9Lm9mSh4SMIh1S+ryMFHZjNOe+rjF06qYiWFBPB1EAZd4Z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=h4PiTkhE5ynTI3kY454eEOen4Fyd3rHa0cs9GWbrtYK7csNjw3Nn/jraY40vCnqHRrD4fMkKY6j74OGuvQkblMwBakOlG8RpvPB6m5lu7gd86xLbs93zSyuN8ElOmZieYzDxNTtFqmePWp9lnvTfcSJh7OQaDXt4lC6NvnCerGQ= Received: by 10.114.190.6 with SMTP id n6mr4371029waf.1182014355627; Sat, 16 Jun 2007 10:19:15 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Sat, 16 Jun 2007 10:19:15 -0700 (PDT) Message-ID: <30b660a20706161019o15175cefl855701ffd51c110b@mail.gmail.com> Date: Sat, 16 Jun 2007 10:19:15 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") In-Reply-To: <005901c7b036$3248e8b0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <005901c7b036$3248e8b0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 0f385ec8055b673e X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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="===============0727122458==" Errors-To: ltru-bounces@ietf.org --===============0727122458== Content-Type: multipart/alternative; boundary="----=_Part_74526_33515517.1182014355607" ------=_Part_74526_33515517.1182014355607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/16/07, Doug Ewell wrote: > > Mark Davis proposed: > > > The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. > According > > to ISO 639, it is used to identify linguistic content whose language is > > known but which does not *currently* have a corresponding subtag. It is > > thus intrinsically unstable -- the addition of other codes in the future > > can render its application invalid at any point without any warning -- > and > > hence incompatible with the stability goals of BCP 47. It is thus always > > preferable to use other subtags: either "und" or -- with prior > > agreement -- private use subtags. > > I am OK with this except for the recommendation to use "und". If the > "language is known," then it is not "undetermined." I suggest: "und" is always a possible alternate tag for any content. That is, even if I know that content in my web page is English, I don't *have to* tag it with English -- I can leave it untagged, which is the equivalent of "und". And private use codes can present their own issues -- if you don't have any prior agreement then "und" is arguably better. I agree that it is usually better to tag content with as much information as possible, but nothing in BCP 47 can require that. We could reorder the sentence to express the priority, however. It is thus always preferable to use other subtags: either a private use subtag with prior agreement or failing that, "und". "It is thus always preferable to use private-use subtags with prior > agreement." I like the rewording of "prior" I might quibble with the wording "without any warning," since every time a > new language subtag is added to the Registry, that language is potentially > removed from the scope of "mis" (or it might be removed from the scope of > some other language subtag, which is thus "narrowed," which is its own > discussion). The key difference is that for other cases, it doesn't make any difference when a future code is added, but for this one it breaks stability. However, I'm ok with dropping it. I hate the way this minor and largely theoretical edge case is dragging down > the project. Are we almost ready to go with 4646bis except for "mis"? Do > any other issues needs to be resolved? If so, can we spend some time on > those issues as well? Referring to http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html There are quite a number of fixes that still need to be made. Example - cleaning up extlang to still be reserved. extlang = *3("-" 3ALPHA) *; specific ISO 639-3 codes => *extlang = *3("-" 3ALPHA) *; reserved for future use* Records of type 'extlang' MUST have *exactly* one 'Prefix' field. => [delete] Values in the field 'Prefix' in records of type 'extlang' MUST NOT be modified. => [delete] as new records. 1. Codes that have a defined "macro-language" mapping at the time of their registration MUST be entered into the registry as records of type 'extlang' with a 'Prefix' field containing the appropriate prefix tag. 2. Codes that represent sign languages MUST be entered into the registry as record of type 'extlang' with a 'Prefix' field that matches the Basic Language Range "sgn" (see Section 3.3.1 "Basic Filtering" in [RFC4647] (Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags," September 2006.)). 3. All other codes MUST be entered into the registry as records of type 'language'. => as new records of type 'language'. record of type 'language' or 'extlang' => record of type 'language' [multiple instances] script or extlang => script Extended language subtags (type 'extlang' in the registry; see Section 3.1 (Format of the IANA Language Subtag Registry)) also appear between the primary language and subsequent (script, region, or variant) subtags. Applications sometimes benefit from their judicious use in forming language tags. => [delete] (unlikely: needs prefix="language-extlang1") => (unlikely) language-extlang combination "zh-hak" when this document was adopted => language combination "zh" when this document was adopted some examples and some items in the Changes section. -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_74526_33515517.1182014355607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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

> The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According
> to ISO 639, it is used to identify linguistic content whose language is
> known but which does not *currently* have a corresponding subtag. It is
> thus intrinsically unstable -- the addition of other codes in the future
> can render its application invalid at any point without any warning -- and
> hence incompatible with the stability goals of BCP 47. It is thus always
> preferable to use other subtags: either "und" or -- with prior
> agreement -- private use subtags.

I am OK with this except for the recommendation to use "und".  If the
"language is known," then it is not "undetermined."  I suggest:

"und" is always a possible alternate tag for any content. That is, even if I know that content in my web page is English, I don't *have to* tag it with English -- I can leave it untagged, which is the equivalent of "und". And private use codes can present their own issues -- if you don't have any prior agreement then "und" is arguably better.

I agree that it is usually better to tag content with as much information as possible, but nothing in BCP 47 can require that. We could reorder the sentence to express the priority, however.

It is thus always preferable to use other subtags: either a private use subtag with prior agreement or failing that, "und".

"It is thus always preferable to use private-use subtags with prior
agreement."

I like the rewording of "prior"

I might quibble with the wording "without any warning," since every time a
new language subtag is added to the Registry, that language is potentially
removed from the scope of "mis" (or it might be removed from the scope of
some other language subtag, which is thus "narrowed," which is its own
discussion).

The key difference is that for other cases, it doesn't make any difference when a future code is added, but for this one it breaks stability. However, I'm ok with dropping it.

I hate the way this minor and largely theoretical edge case is dragging down
the project.  Are we almost ready to go with 4646bis except for "mis"?  Do
any other issues needs to be resolved?  If so, can we spend some time on
those issues as well?

Referring to http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html

There are quite a number of fixes that still need to be made.

Example - cleaning up extlang to still be reserved.

extlang
       = *3("-" 3ALPHA)         ; specific ISO 639-3 codes
=>
extlang       = 
*3("-" 3ALPHA)         ; reserved for future use


Records of type 'extlang' MUST have exactly one 'Prefix' field.
=>
[delete]

Values in the field 'Prefix' in records of type 'extlang' MUST NOT be modified.
=>
[delete]


as new records.
  1. Codes that have a defined "macro-language" mapping at the time of their registration MUST be entered into the registry as records of type 'extlang' with a 'Prefix' field containing the appropriate prefix tag.
  2. Codes that represent sign languages MUST be entered into the registry as record of type 'extlang' with a 'Prefix' field that matches the Basic Language Range "sgn" (see Section 3.3.1 "Basic Filtering" in [RFC4647] ( Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags," September 2006.)).
  3. All other codes MUST be entered into the registry as records of type 'language'.
=>
as new records of type 'language'.

record of type 'language' or 'extlang'
=>
record of type 'language'
[multiple instances]

script or extlang
=>
script

Extended language subtags (type 'extlang' in the registry; see Section 3.1 (Format of the IANA Language Subtag Registry)) also appear between the primary language and subsequent (script, region, or variant) subtags. Applications sometimes benefit from their judicious use in forming language tags.
=>
[delete]

(unlikely: needs prefix="language-extlang1")
=>
(unlikely)

language-extlang combination "zh-hak" when this document was adopted
=>
language combination "zh" when this document was adopted

some examples and some items in the Changes section.

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



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



--
Mark ------=_Part_74526_33515517.1182014355607-- --===============0727122458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0727122458==-- From ltru-bounces@ietf.org Sat Jun 16 17:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzfaL-0000SQ-2y; Sat, 16 Jun 2007 17:13:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzfaJ-0000SI-UC for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 17:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzfaJ-0000SA-Kn for ltru@ietf.org; Sat, 16 Jun 2007 17:13:27 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzfaI-0000vE-Aw for ltru@ietf.org; Sat, 16 Jun 2007 17:13:27 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070616211325.CTHT3934.mta11.adelphia.net@DGBP7M81>; Sat, 16 Jun 2007 17:13:25 -0400 Message-ID: <000601c7b05b$2d72f6d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005901c7b036$3248e8b0$6401a8c0@DGBP7M81> <30b660a20706161019o15175cefl855701ffd51c110b@mail.gmail.com> Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") Date: Sat, 16 Jun 2007 14:13:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > "und" is always a possible alternate tag for any content. That is, even if > I know that content in my web page is English, I don't *have to* tag it > with English -- I can leave it untagged, which is the equivalent of "und". > And private use codes can present their own issues -- if you don't have > any prior agreement then "und" is arguably better. I don't agree that "und" is equivalent to "no tag," but I don't want to spend a lot of time arguing about it, since I believe "und" (like "mis") is an exceptional subtag that is likely to see very little use in the real world. > Referring to > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html > > There are quite a number of fixes that still need to be made. > > Example - cleaning up extlang to still be reserved. Whoa, time out. When did we agree NOT to use the extlang mechanism for new 639-3 languages that have a macrolanguage? I know you wanted that, but where was the consensus that makes these wishes into "fixes that need to be made"? This is why I wish we were using the issue tracker as we did for 3066bis. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 21:36:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjgv-0003Bf-Dn; Sat, 16 Jun 2007 21:36:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzjgu-0003Ba-0p for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 21:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjgt-0003BS-Nd for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:36:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzjgs-0007qB-BX for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:36:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hzjgj-0001zR-UR for ltru@lists.ietf.org; Sun, 17 Jun 2007 03:36:21 +0200 Received: from dialin-145-254-036-097.pools.arcor-ip.net ([145.254.36.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:36:21 +0200 Received: from nobody by dialin-145-254-036-097.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:36:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Jun 2007 03:34:07 +0200 Organization: Lines: 19 Message-ID: <46748F8F.2B0B@xyzzy.claranet.de> References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> <003301c7b035$fd9f9dc0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-036-097.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Suggested language for "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >> The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to >> ISO 639, it is used to identify linguistic content whose language is known >> but which does not *currently* have a corresponding subtag. It is thus >> intrinsically unstable -- the addition of other codes in the future can >> render its application invalid at any point without any warning -- and hence >> incompatible with the stability goals of BCP 47. It is thus always >> preferable to use other subtags: either "und" or -- with prior agreement -- >> private use subtags. > ... > As a technical contributor, I rather like this proposal. +1, no need to discuss MARC and other good excuses to violate the SHOULD NOT. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 21:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjw0-0001pf-BY; Sat, 16 Jun 2007 21:52:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzjvz-0001mV-MQ for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 21:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjvz-0001m3-0K for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:52:07 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzjvx-000184-NV for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:52:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hzjvt-0003gP-Vv for ltru@lists.ietf.org; Sun, 17 Jun 2007 03:52:01 +0200 Received: from dialin-145-254-036-097.pools.arcor-ip.net ([145.254.36.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:52:01 +0200 Received: from nobody by dialin-145-254-036-097.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:52:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Jun 2007 03:51:14 +0200 Organization: Lines: 12 Message-ID: <46749392.3B08@xyzzy.claranet.de> References: <001d01c7ae0b$08829f80$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-036-097.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Fw: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com wrote: > Hmm .... So now we have codes for uncoded languages, non-linguistic > languages, and unwritten scripts. I'm sure we'll be able to use > these to categorize unpublished books and offline web sites for > non-geographical regions. LOL. With all those virtual realities you never know. Seriously, "uncoded" is clearer than "miscellaneous", I like the new description. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 16 21:59:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzk3B-0000bl-N2; Sat, 16 Jun 2007 21:59:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzk3B-0000YG-32 for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 21:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzk3A-0000Xi-Od for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:59:32 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzk36-0002b2-Eo for ltru@lists.ietf.org; Sat, 16 Jun 2007 21:59:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hzk2m-0004Zh-Hr for ltru@lists.ietf.org; Sun, 17 Jun 2007 03:59:09 +0200 Received: from dialin-145-254-036-097.pools.arcor-ip.net ([145.254.36.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:59:08 +0200 Received: from nobody by dialin-145-254-036-097.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 03:59:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 17 Jun 2007 03:58:40 +0200 Organization: Lines: 5 Message-ID: <46749550.2A3F@xyzzy.claranet.de> References: <20070611073211.GA2807@nic.fr> <6.0.0.20.2.20070611173425.0a202710@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: dialin-145-254-036-097.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Ltru] Re: Plans for www.langtag.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: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Please provide input (agreement or disagreement) on Stephane's proposal ........................^^^^^^^^^ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq4C-0005FT-Pi; Sun, 17 Jun 2007 04:25:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzq4A-00056G-MD for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 04:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq4A-00054q-AM for ltru@ietf.org; Sun, 17 Jun 2007 04:24:58 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzq46-00030y-F5 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:58 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5H8OpSD009738 for ; Sun, 17 Jun 2007 17:24:51 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1467_37d11bee_1cac_11dc_835a_0014221f2a2d; Sun, 17 Jun 2007 17:24:50 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40469) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Jun 2007 17:22:56 +0900 Message-Id: <6.0.0.20.2.20070617162143.05880c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jun 2007 16:28:28 +0900 To: Chris Newman From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Adding http://www.langtag.net to LTRU WG charter page X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Chris, There has been a proposal to add a link to http://www.langtag.net to the LTRU WG charter page. I have asked the WG about input on this, and have only seen positive feedback. I therefore assess that there is WG consensus on adding a link to this page to our charter page at http://www.ietf.org/html.charters/ltru-charter.html. My understanding is that you are the right person to pass this request to; if not, please tell me what to do. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq49-00053i-Hz; Sun, 17 Jun 2007 04:24:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzq48-0004v8-7X for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq47-0004uc-Ta for ltru@ietf.org; Sun, 17 Jun 2007 04:24:55 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzq47-000319-91 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:55 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5H8OsNl017095 for ; Sun, 17 Jun 2007 17:24:54 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 14e0_39b4672c_1cac_11dc_910d_0014221f2a2d; Sun, 17 Jun 2007 17:24:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40469) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Jun 2007 17:22:59 +0900 Message-Id: <6.0.0.20.2.20070617164931.073a0ab0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jun 2007 16:56:30 +0900 To: "Mark Davis" , "Addison Phillips" From: Martin Duerst Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:"mis") In-Reply-To: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.co m> References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:29 07/06/17, Mark Davis wrote: >That's going in the right direction, but doesn't not given enough guidance as to why to avoid it. My suggested language: > >The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags. I'm a bit confused here. We want to try to give absoulte stability guarantees. But then we recommend 'und' (wrong to start with, because we know what language it is, so calling it undetermined is lying) or a private tag (inherently unstable and non-interoperable). Why don't we just accept that 'mis' is unstable (no disagreement here, of course), but instead of saying "invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47", warn the receiver that 'mis' may refer to a language that in the meantime has been coded, and change our language, e.g. 'invalid' -> 'suboptimal'. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq49-00054J-LG; Sun, 17 Jun 2007 04:24:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzq48-0004xv-LS for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq48-0004w3-B3 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzq46-000311-H1 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5H8Oqpf017086 for ; Sun, 17 Jun 2007 17:24:52 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1467_38e162c8_1cac_11dc_835a_0014221f2a2d; Sun, 17 Jun 2007 17:24:52 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40469) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Jun 2007 17:22:58 +0900 Message-Id: <6.0.0.20.2.20070617163500.058ced80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jun 2007 16:40:18 +0900 To: Peter Constable , LTRU Working Group From: Martin Duerst Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" In-Reply-To: References: <001401c7af92$89fb9200$6601a8c0@oemcomputer> <002e01c7af98$03683800$6601a8c0@oemcomputer> <000401c7afa4$342b51a0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 09:21 07/06/16, Peter Constable wrote: >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >>> and that it can also determine the extension of 'mis' on the basis of its >>> restricted set. >> >> This is simply not interoperable, as you've already explained. > >Even treated as you proposed, 'mis' is inherently unstable wrt extension >(and always has been). That is part of the contract taken on by anybody who >chooses to use it with any profile of language tags that is open to change. >You say that's not interoperable; I say it's interoperable given >appropriately low expectations of the usefulness of 'mis' in interchange. I think I have to side with Peter here. We inherently know that no tag at all and things such as 'und' and 'mis' have a rather low value. On top of that, we have the problem of wrong tagging in the first place. I'd vastly prefer a repository that tagged documents from 200 languages *correctly* and used 'mis' or so in the rare case it got something in a language that the system wasn't envisioned to handle, rather than a system that tried to tag everything with a specific code but got half of that wrong. The interoperability is much more on the level of correctly using the available tags, rather than on the details of the use of 'mis'. Also, while it's easy to write 'don't use "mis" unless there is no subtag for the language in question', it's very difficult to test. >> In any case, I'd really hate >> to have this WG go down the path of defining standardized >> "profiles" of BCP 47 unless there were a *huge* benefit to doing so. > >Absolute agreement. I have never suggested we should define standardized >"profiles". If a consuming protocol wishes to do so, that's entirely up to >them -- we certainly should not do it for them. I agree. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq49-00053i-Hz; Sun, 17 Jun 2007 04:24:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzq48-0004v8-7X for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq47-0004uc-Ta for ltru@ietf.org; Sun, 17 Jun 2007 04:24:55 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzq47-000319-91 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:55 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5H8OsNl017095 for ; Sun, 17 Jun 2007 17:24:54 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 14e0_39b4672c_1cac_11dc_910d_0014221f2a2d; Sun, 17 Jun 2007 17:24:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40469) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Jun 2007 17:22:59 +0900 Message-Id: <6.0.0.20.2.20070617164931.073a0ab0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jun 2007 16:56:30 +0900 To: "Mark Davis" , "Addison Phillips" From: Martin Duerst Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:"mis") In-Reply-To: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.co m> References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:29 07/06/17, Mark Davis wrote: >That's going in the right direction, but doesn't not given enough guidance as to why to avoid it. My suggested language: > >The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags. I'm a bit confused here. We want to try to give absoulte stability guarantees. But then we recommend 'und' (wrong to start with, because we know what language it is, so calling it undetermined is lying) or a private tag (inherently unstable and non-interoperable). Why don't we just accept that 'mis' is unstable (no disagreement here, of course), but instead of saying "invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47", warn the receiver that 'mis' may refer to a language that in the meantime has been coded, and change our language, e.g. 'invalid' -> 'suboptimal'. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq49-00054J-LG; Sun, 17 Jun 2007 04:24:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzq48-0004xv-LS for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzq48-0004w3-B3 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzq46-000311-H1 for ltru@ietf.org; Sun, 17 Jun 2007 04:24:56 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5H8Oqpf017086 for ; Sun, 17 Jun 2007 17:24:52 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1467_38e162c8_1cac_11dc_835a_0014221f2a2d; Sun, 17 Jun 2007 17:24:52 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40469) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 17 Jun 2007 17:22:58 +0900 Message-Id: <6.0.0.20.2.20070617163500.058ced80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jun 2007 16:40:18 +0900 To: Peter Constable , LTRU Working Group From: Martin Duerst Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" In-Reply-To: References: <001401c7af92$89fb9200$6601a8c0@oemcomputer> <002e01c7af98$03683800$6601a8c0@oemcomputer> <000401c7afa4$342b51a0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 09:21 07/06/16, Peter Constable wrote: >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >>> and that it can also determine the extension of 'mis' on the basis of its >>> restricted set. >> >> This is simply not interoperable, as you've already explained. > >Even treated as you proposed, 'mis' is inherently unstable wrt extension >(and always has been). That is part of the contract taken on by anybody who >chooses to use it with any profile of language tags that is open to change. >You say that's not interoperable; I say it's interoperable given >appropriately low expectations of the usefulness of 'mis' in interchange. I think I have to side with Peter here. We inherently know that no tag at all and things such as 'und' and 'mis' have a rather low value. On top of that, we have the problem of wrong tagging in the first place. I'd vastly prefer a repository that tagged documents from 200 languages *correctly* and used 'mis' or so in the rare case it got something in a language that the system wasn't envisioned to handle, rather than a system that tried to tag everything with a specific code but got half of that wrong. The interoperability is much more on the level of correctly using the available tags, rather than on the details of the use of 'mis'. Also, while it's easy to write 'don't use "mis" unless there is no subtag for the language in question', it's very difficult to test. >> In any case, I'd really hate >> to have this WG go down the path of defining standardized >> "profiles" of BCP 47 unless there were a *huge* benefit to doing so. > >Absolute agreement. I have never suggested we should define standardized >"profiles". If a consuming protocol wishes to do so, that's entirely up to >them -- we certainly should not do it for them. I agree. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 07:34:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzt1s-00077p-2Y; Sun, 17 Jun 2007 07:34:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzt1q-00077c-Ib for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 07:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzt1q-00077U-9D for ltru@ietf.org; Sun, 17 Jun 2007 07:34:46 -0400 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hzt1p-00067Q-0L for ltru@ietf.org; Sun, 17 Jun 2007 07:34:46 -0400 Received: (qmail 45634 messnum 2928029 invoked from network[194.125.174.24/ts09-024.dublin.indigo.ie]); 17 Jun 2007 11:16:55 -0000 Received: from ts09-024.dublin.indigo.ie (HELO ?194.125.174.24?) (194.125.174.24) by mail06.svc.cra.dublin.eircom.net (qp 45634) with SMTP; 17 Jun 2007 11:16:55 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <6.0.0.20.2.20070617164931.073a0ab0@localhost> References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> <6.0.0.20.2.20070617164931.073a0ab0@localhost> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <718342B4-B004-4FCC-A683-FFA5DE2FB02F@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:"mis") Date: Sun, 17 Jun 2007 12:17:45 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 17 Jun 2007, at 07:56, scr=EDobh Martin Duerst: > I'm a bit confused here. We want to try to give absoulte stability > guarantees. But then we recommend 'und' (wrong to start with, because > we know what language it is, so calling it undetermined is lying) > or a private tag (inherently unstable and non-interoperable). Such confusion is among the many adverse effects of rashly converting =20= the domestic practice of one country (MARC, SIL, etc.) into =20 international standards, instead of building them brick by aware =20 brick, as is normally done. If Martin's current proposal (below) can =20 go some way towards countering the adverse efffect currently under =20 discussion here, then he has my support in that. mg > Why don't we just accept that 'mis' is unstable (no disagreement > here, of course), but instead of saying "invalid at any point without > any warning -- and hence incompatible with the stability goals of =20 > BCP 47", > warn the receiver that 'mis' may refer to a language that in the =20 > meantime > has been coded, and change our language, e.g. 'invalid' -> =20 > 'suboptimal'. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 14:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzdf-0006hR-6C; Sun, 17 Jun 2007 14:38:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzzde-0006hM-05 for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 14:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzdd-0006hE-Mv for ltru@ietf.org; Sun, 17 Jun 2007 14:38:13 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzzdc-0003O9-D9 for ltru@ietf.org; Sun, 17 Jun 2007 14:38:13 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070617183810.KCGT28396.mta16.adelphia.net@DGBP7M81> for ; Sun, 17 Jun 2007 14:38:10 -0400 Message-ID: <003e01c7b10e$a793faa0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:"mis") Date: Sun, 17 Jun 2007 11:38:09 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: >> I'm a bit confused here. We want to try to give absoulte stability >> guarantees. But then we recommend 'und' (wrong to start with, because we >> know what language it is, so calling it undetermined is lying) or a >> private tag (inherently unstable and non-interoperable). > > Such confusion is among the many adverse effects of rashly converting the > domestic practice of one country (MARC, SIL, etc.) into international > standards, instead of building them brick by aware brick, as is normally > done. If Martin's current proposal (below) can go some way towards > countering the adverse efffect currently under discussion here, then he > has my support in that. I think it is highly questionable to say that MARC was "rashly converted" into ISO 639-2 or that Ethnologue was "rashly converted" into ISO 639-3. Both MARC and Ethnologue existed for decades before being used as the basis for ISO standards. The real problem is that MARC specified what "mis" was supposed to mean, but ISO 639-2 merely gave it the name "miscellaneous languages" and left it for implementations to figure out. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 14:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzfy-0001gs-UD; Sun, 17 Jun 2007 14:40:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzzfy-0001gn-1M for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 14:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzfx-0001gf-O7 for ltru@ietf.org; Sun, 17 Jun 2007 14:40:37 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzzfw-0003nI-F3 for ltru@ietf.org; Sun, 17 Jun 2007 14:40:37 -0400 Received: from c83-248-114-182.bredband.comhem.se ([83.248.114.182]:3475 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1Hzzfv-0007hR-3p; Sun, 17 Jun 2007 20:40:35 +0200 From: "Kent Karlsson" To: "'Martin Duerst'" , "'Peter Constable'" , "'LTRU Working Group'" References: <001401c7af92$89fb9200$6601a8c0@oemcomputer><002e01c7af98$03683800$6601a8c0@oemcomputer><000401c7afa4$342b51a0$6601a8c0@oemcomputer> <6.0.0.20.2.20070617163500.058ced80@localhost> Subject: RE: [Ltru] RE: ISO 639-2 decision: "mis" Date: Sun, 17 Jun 2007 20:40:20 +0200 Message-ID: <008a01c7b10e$ff7d2ac0$a163f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcewuQVvBtTWVXQVTjiAU+c54g6EQQAUs9fg In-Reply-To: <6.0.0.20.2.20070617163500.058ced80@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Originating-IP: 83.248.114.182 X-Scan-Result: No virus found in message 1Hzzfv-0007hR-3p. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Hzzfv-0007hR-3p 815185a91de8a37a9fd859056f4024a7 X-Spam-Score: 0.5 (/) 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: , Errors-To: ltru-bounces@ietf.org =20 Martin D=C3=BCrst wrote: > I'm a bit confused here. We want to try to give absoulte stability > guarantees. But then we recommend 'und' (wrong to start with, because > we know what language it is, so calling it undetermined is lying) > or a private tag (inherently unstable and non-interoperable). > Why don't we just accept that 'mis' is unstable (no disagreement > here, of course), but instead of saying "invalid at any point without > any warning -- and hence incompatible with the stability goals of BCP = 47", > warn the receiver that 'mis' may refer to a language that in the = meantime > has been coded, and change our language, e.g. 'invalid' -> = 'suboptimal'. That was the *very thing* that was changed by the recent change to = 'mis'. (And there was a real change!) What used to be 'suboptimal' is now 'invalid' w.r.t. the use of 'mis'. 'mis' used to be interpretable in a stable way, but that is no longer possible given the change. (Which is why I've been arguing against this change all along.) /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 14:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzuw-0002O9-6Z; Sun, 17 Jun 2007 14:56:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Hzzuu-0002O3-LQ for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 14:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzuu-0002Nv-Bs for ltru@ietf.org; Sun, 17 Jun 2007 14:56:04 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzzur-0000Uc-MG for ltru@ietf.org; Sun, 17 Jun 2007 14:56:04 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2196813wah for ; Sun, 17 Jun 2007 11:56:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VAXwvzTwBQG+5bWtFePAGJidUqUnY4vq8RJfD4tV7YD8kdNtdWHw+V9ag+Uh/tgxqN57w0eavgupZ7ntMZa78UE+/W+CJjAKG2F+CRCe1AyW6kT7cpq0lc8G3iWmSmrFyfPUHsS+Qt3Wz+HIyTmP+/TOW8JFEcHmgKxHnU3inYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mAz2OSPZ6LJXugoQxznLrEGMcEMIXYkSFoF/Zw2VYsagS5PNhj044bCb/DHYZTMToqtqFKTXydLOv1z11+ro41rFffDya8jFiYS8wyflnBeTo7wqzA+g8lt01tPJAVAEVQzyhrbC3esxBx5eX/gV3N1iSJIN3iD+4hFjJU/hMbo= Received: by 10.114.93.17 with SMTP id q17mr5393174wab.1182106560921; Sun, 17 Jun 2007 11:56:00 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Sun, 17 Jun 2007 11:56:00 -0700 (PDT) Message-ID: <30b660a20706171156j5055f93cocd457ecc505b3791@mail.gmail.com> Date: Sun, 17 Jun 2007 11:56:00 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:"mis") In-Reply-To: <6.0.0.20.2.20070617164931.073a0ab0@localhost> MIME-Version: 1.0 References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> <6.0.0.20.2.20070617164931.073a0ab0@localhost> X-Google-Sender-Auth: 42542ed3eb2b35f4 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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="===============1493379513==" Errors-To: ltru-bounces@ietf.org --===============1493379513== Content-Type: multipart/alternative; boundary="----=_Part_4003_3809722.1182106560862" ------=_Part_4003_3809722.1182106560862 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We have used 'und' as a general "unknown" tag, which is really required for effective operation of language tags. We are equating "und" with _no_tag_; the latter are preferred in environments where that can be done, but "und" is required where it is not allowed. And in a situation of inheritance (like xml:lang), there needs to be something that says "don't inherit from the parent level, because I'm not sure that I and my children are the same". The key question for any tag -- assuming a tag is valid -- is what a recipient can correctly infer from the presence of that tag. With "und" I can make no assumptions about what the content is. It may be in no language, some language, more than one language, a language that has no code. I can simply make no inferences. As to why the original tagger tagged it that way, I can't know -- maybe he knew didn't know what it was, maybe he didn't try to find out, maybe he tried and didn't have 100% confidence, maybe he knew it was low elvish and there wasn't a code for it, whatever. Mark On 6/17/07, Martin Duerst wrote: > > At 00:29 07/06/17, Mark Davis wrote: > >That's going in the right direction, but doesn't not given enough > guidance as to why to avoid it. My suggested language: > > > >The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According > to ISO 639, it is used to identify linguistic content whose language is > known but which does not *currently* have a corresponding subtag. It is thus > intrinsically unstable -- the addition of other codes in the future can > render its application invalid at any point without any warning -- and hence > incompatible with the stability goals of BCP 47. It is thus always > preferable to use other subtags: either "und" or -- with prior agreement -- > private use subtags. > > I'm a bit confused here. We want to try to give absoulte stability > guarantees. But then we recommend 'und' (wrong to start with, because > we know what language it is, so calling it undetermined is lying) > or a private tag (inherently unstable and non-interoperable). > Why don't we just accept that 'mis' is unstable (no disagreement > here, of course), but instead of saying "invalid at any point without > any warning -- and hence incompatible with the stability goals of BCP 47", > warn the receiver that 'mis' may refer to a language that in the meantime > has been coded, and change our language, e.g. 'invalid' -> 'suboptimal'. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > -- Mark ------=_Part_4003_3809722.1182106560862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have used 'und' as a general "unknown" tag, which is really required for effective operation of language tags. We are equating "und" with _no_tag_; the latter are preferred in environments where that can be done, but "und" is required where it is not allowed. And in a situation of inheritance (like xml:lang), there needs to be something that says "don't inherit from the parent level, because I'm not sure that I and my children are the same".

The key question for any tag -- assuming a tag is valid -- is what a recipient can correctly infer from the presence of that tag. With "und" I can make no assumptions about what the content is. It may be in no language, some language, more than one language, a language that has no code. I can simply make no inferences. As to why the original tagger tagged it that way, I can't know -- maybe he knew didn't know what it was, maybe he didn't try to find out, maybe he tried and didn't have 100% confidence, maybe he knew it was low elvish and there wasn't a code for it, whatever.

Mark

On 6/17/07, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
At 00:29 07/06/17, Mark Davis wrote:
>That's going in the right direction, but doesn't not given enough guidance as to why to avoid it. My suggested language:
>
>The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags.

I'm a bit confused here. We want to try to give absoulte stability
guarantees. But then we recommend 'und' (wrong to start with, because
we know what language it is, so calling it undetermined is lying)
or a private tag (inherently unstable and non-interoperable).
Why don't we just accept that 'mis' is unstable (no disagreement
here, of course), but instead of saying "invalid at any point without
any warning -- and hence incompatible with the stability goals of BCP 47",
warn the receiver that 'mis' may refer to a language that in the meantime
has been coded, and change our language, e.g. 'invalid' -> 'suboptimal'.

Regards,    Martin.



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




--
Mark ------=_Part_4003_3809722.1182106560862-- --===============1493379513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1493379513==-- From ltru-bounces@ietf.org Sun Jun 17 15:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00P5-0000On-MO; Sun, 17 Jun 2007 15:27:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I00P3-0000Og-Md for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 15:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00P3-0000OX-D4 for ltru@lists.ietf.org; Sun, 17 Jun 2007 15:27:13 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I00P2-0003Yb-56 for ltru@lists.ietf.org; Sun, 17 Jun 2007 15:27:13 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8CE9A240823; Sun, 17 Jun 2007 21:27:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 0F28B125E6; Sun, 17 Jun 2007 21:26:52 +0200 (CEST) Date: Sun, 17 Jun 2007 21:26:52 +0200 From: Stephane Bortzmeyer To: rfc-editor@rfc-editor.org Message-ID: <20070617192652.GA18085@sources.org> Mime-Version: 1.0 X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org Subject: [Ltru] Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347056780==" Errors-To: ltru-bounces@ietf.org --===============0347056780== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline RFC 4930 has several normative references to RFC 3066. RFC 4930 has been approved by the IESG in January 2007 and published in May 2007. RFC 3066 have been obsoleted by RFC 4646 in September 2006, several months before. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGdYr8QTZHl5fW0kYRAlWCAKDKh0VxZgJyWRq30AmpdXrXoN2AdQCeLbE/ lpWW177kwTK0Cig1ac9o8n0= =5mNt -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- --===============0347056780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0347056780==-- From ltru-bounces@ietf.org Sun Jun 17 15:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00nN-0007JG-9F; Sun, 17 Jun 2007 15:52:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I00nL-0007Dn-GU for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 15:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00nL-0007Cp-6L for ltru@ietf.org; Sun, 17 Jun 2007 15:52:19 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I00nJ-0002Di-MS for ltru@ietf.org; Sun, 17 Jun 2007 15:52:19 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2210872wah for ; Sun, 17 Jun 2007 12:52:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=Jlewn2l4w54g99e0GKE/dC8JyOiCA3U28mGoetZjHTfH7Wgum1w6DCHwna55VmXXis+82duUbIYA4AQ417YrEPlFbmiJl64RymrrLoMRs3kr4QEvHg+EL5DH63I2lu5ORrIoE9mtNwtHJ/qQMkkA2edJ/kL7ixVQoA2uEgrofNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=l0Ums/SyVJzWxauTkKaI5jRQvVxHucdEGXcEj6jIVe1Wj837D7P7RrSq2BLL/hKXM0KETVLmoVXtUvffboQOKlwUhRtRKQVTgWgAF04CLegObJ+44tECO891M+Mp6CGjqdyhu/K2aPcm1+96k+QervkFGaw2gTxt1h8oZ+KJSuU= Received: by 10.114.171.1 with SMTP id t1mr5387829wae.1182109936426; Sun, 17 Jun 2007 12:52:16 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Sun, 17 Jun 2007 12:52:16 -0700 (PDT) Message-ID: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> Date: Sun, 17 Jun 2007 12:52:16 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) MIME-Version: 1.0 X-Google-Sender-Auth: 8aa33ade3f2c7a6e X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778389521==" Errors-To: ltru-bounces@ietf.org --===============0778389521== Content-Type: multipart/alternative; boundary="----=_Part_4427_44483.1182109936408" ------=_Part_4427_44483.1182109936408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'll move this to a different thread, so we can focus on the "mis" language under that title. You had said: "Are we almost ready to go with 4646bis except for "mis"? Do any other issues needs to be resolved? If so, can we spend some time on those issues as well?" There are at least three open issues listed in http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html. Extlang is one of them. I'll step back a bit, since it appears that we don't have consensus about making a change in extlang from RFC 4646. So we need to revive the discussion from back in March. Mark On 6/16/07, Doug Ewell wrote: [snip] You had > > > > Example - cleaning up extlang to still be reserved. > > Whoa, time out. When did we agree NOT to use the extlang mechanism for > new > 639-3 languages that have a macrolanguage? I know you wanted that, but > where was the consensus that makes these wishes into "fixes that need to > be > made"? This is why I wish we were using the issue tracker as we did for > 3066bis. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > -- Mark ------=_Part_4427_44483.1182109936408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'll move this to a different thread, so we can focus on the "mis" language under that title.

You had said: "Are we almost ready to go with 4646bis except for "mis"?  Do
any other issues needs to be resolved?  If so, can we spend some time on
those issues as well?"

There are at least three open issues listed in http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html.

Extlang is one of them. I'll step back a bit, since it appears that we don't have consensus about making a change in extlang from RFC 4646.

So we need to revive the discussion from back in March.

Mark

On 6/16/07, Doug Ewell <dewell@roadrunner.com > wrote:
[snip]

You had
>
> Example - cleaning up extlang to still be reserved.

Whoa, time out.  When did we agree NOT to use the extlang mechanism for new
639-3 languages that have a macrolanguage?  I know you wanted that, but
where was the consensus that makes these wishes into "fixes that need to be
made"?  This is why I wish we were using the issue tracker as we did for
3066bis.

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




--
Mark ------=_Part_4427_44483.1182109936408-- --===============0778389521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0778389521==-- From ltru-bounces@ietf.org Sun Jun 17 16:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00x0-0004PQ-S6; Sun, 17 Jun 2007 16:02:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I00wz-0004On-N5 for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 16:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I00wz-0004OI-DG for ltru@lists.ietf.org; Sun, 17 Jun 2007 16:02:17 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I00wy-0004GO-58 for ltru@lists.ietf.org; Sun, 17 Jun 2007 16:02:17 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A8743240817; Sun, 17 Jun 2007 22:02:10 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 1506F1123E; Sun, 17 Jun 2007 21:59:32 +0200 (CEST) Date: Sun, 17 Jun 2007 21:59:32 +0200 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20070617195931.GA22979@sources.org> References: <20070617192652.GA18085@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070617192652.GA18085@sources.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Jun 17, 2007 at 09:26:52PM +0200, Stephane Bortzmeyer wrote a message of 27 lines which said: > RFC 4930 has several normative references to RFC 3066. ... > RFC 3066 have been obsoleted by RFC 4646 in September 2006, several > months before. It is difficult even for the IETF to keep track of its own standards :-( _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 16:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I01Uv-0003jF-5v; Sun, 17 Jun 2007 16:37:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I01Ut-0003gF-Ja for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 16:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I01Ut-0003f4-9g for ltru@ietf.org; Sun, 17 Jun 2007 16:37:19 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I01Us-0003yp-11 for ltru@ietf.org; Sun, 17 Jun 2007 16:37:19 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id CA8F6240817; Sun, 17 Jun 2007 22:37:11 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 28A3B1289C; Sun, 17 Jun 2007 22:33:26 +0200 (CEST) Date: Sun, 17 Jun 2007 22:33:26 +0200 From: Stephane Bortzmeyer To: Mark Davis Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070617203326.GA27855@sources.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.7 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Jun 17, 2007 at 12:52:16PM -0700, Mark Davis wrote a message of 86 lines which said: > You had said: "Are we almost ready to go with 4646bis except for > "mis"? I believe so and I regret that "mis" takes so much energy. IMHO, it is just a detail (I agree with Doug Ewell's "Type I vs. Type II errors" message). > There are at least three open issues listed in > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html. Most are either actually closed (I do not think that there are still serious proposals to use UTF-8 in the registry: even if I regret it, it seems settled) or only details (additional information related to Suppress-Script). > Extlang is one of them. And probably the only serious one. But, on the other hand, I want to emphasize that ISO 639-3 was issued in february, that some users want the new language codes now and that any delay in the release of the RFC undermines the whole language tag effort. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 17:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I01yZ-0000O9-OP; Sun, 17 Jun 2007 17:07:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I01yY-0000O4-TQ for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 17:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I01yY-0000Nw-Jo for ltru@ietf.org; Sun, 17 Jun 2007 17:07:58 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I01yX-0000l9-8F for ltru@ietf.org; Sun, 17 Jun 2007 17:07:58 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070617210756.PYWV27139.mta13.adelphia.net@DGBP7M81> for ; Sun, 17 Jun 2007 17:07:56 -0400 Message-ID: <007801c7b123$938a13e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 17 Jun 2007 14:07:55 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > (I do not think that there are still serious proposals to use UTF-8 in the > registry: even if I regret it, it seems settled) +1 > But, on the other hand, I want to emphasize that ISO 639-3 was issued in > february, that some users want the new language codes now and that any > delay in the release of the RFC undermines the whole language tag effort. It's unfortunate that the ISO 639-3 code list still isn't truly ready for initial launch, and won't be until July, even though the standard has already been issued. But that's the way it is, and our "stability" goals would not be served by incorporating the 639-3 code list as it is today and then being forced to keep any code elements they choose to remove between now and July (cf. the Occitan languages). My wish is for us to have everything else ready *before* 639-3 announces its "final" code list, so that we can issue WGLC for 4646bis and 4645bis at that point without further delay. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 20:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04nT-00083s-Ft; Sun, 17 Jun 2007 20:08:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1HzeO0-0003Yg-Vy for ltru-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 15:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzeO0-0003YY-MB for ltru@ietf.org; Sat, 16 Jun 2007 15:56:40 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzeNz-000122-E1 for ltru@ietf.org; Sat, 16 Jun 2007 15:56:40 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Sat, 16 Jun 2007 12:55:22 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Sat, 16 Jun 2007 12:56:38 -0700 From: Peter Constable To: Kent Karlsson , 'Milicent K Wewerka' , 'Mark Davis' Date: Sat, 16 Jun 2007 12:56:30 -0700 Thread-Topic: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Index: AceuelsK98EmCjkLSLazTa3Xyg/kFwAK+kTQAGphenA= Message-ID: References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local><20070613205820.GL4585@mercury.ccil.org><30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> In-Reply-To: <000101c7afe2$0c082ac0$a163f853@streamserve.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Sun, 17 Jun 2007 20:08:41 -0400 Cc: 'LTRU Working Group' , "iso639-2@loc.gov" , "HHj@standard.no" , "isojac@loc.gov" , "ietf-languages@iana.org" , "iso639@dkuug.dk" Subject: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > With the "old mis" one could correctly apply 'mis' as a language > code for any language That has *never* been the intent of ISO 639. It is an external interpretati= on, admittedly possible because ISO 639 was not fully explicit up to now. B= ut from the perspective of the JAC, the "new mis" is exactly the same "mis"= as the "old mis". Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 17 20:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04oS-0000bH-Ol; Sun, 17 Jun 2007 20:09:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I02mf-0008E1-B5 for ltru-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 17:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02mf-0008Dq-1V for ltru@lists.ietf.org; Sun, 17 Jun 2007 17:59:45 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I02ln-0001Lg-V1 for ltru@lists.ietf.org; Sun, 17 Jun 2007 17:58:53 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id l5HLuRv3030042; Sun, 17 Jun 2007 17:56:28 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 17:58:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Jun 2007 17:58:46 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Small bibliography error in RFC 4930 Thread-Index: AcexGEXVc2G0+WqvRa2J3AMILHztSQAEmhjw From: "Hollenbeck, Scott" To: "Stephane Bortzmeyer" , X-OriginalArrivalTime: 17 Jun 2007 21:58:47.0796 (UTC) FILETIME=[AE83BB40:01C7B12A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Sun, 17 Jun 2007 20:09:43 -0400 Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org Subject: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293252601==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1293252601== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B12A.ADEA6F99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B12A.ADEA6F99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's not an error. The references are correct as published for = promotion to draft standard status. -Scott- -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Sunday, June 17, 2007 03:47 PM Eastern Standard Time To: rfc-editor@rfc-editor.org Cc: bortzmeyer@nic.fr; ietf-provreg@cafax.se; ltru@lists.ietf.org Subject: [ietf-provreg] Small bibliography error in RFC 4930 RFC 4930 has several normative references to RFC 3066. RFC 4930 has been approved by the IESG in January 2007 and published in May 2007. RFC 3066 have been obsoleted by RFC 4646 in September 2006, several months before. ------_=_NextPart_001_01C7B12A.ADEA6F99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [ietf-provreg] Small bibliography error in RFC 4930

That's not an error.  The references are correct = as published for promotion to draft standard status.

-Scott-

 -----Original Message-----
From:   Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]
Sent:   Sunday, June 17, 2007 03:47 PM Eastern Standard = Time
To:     rfc-editor@rfc-editor.org
Cc:     bortzmeyer@nic.fr; ietf-provreg@cafax.se; = ltru@lists.ietf.org
Subject:        [ietf-provreg] Small = bibliography error in RFC 4930

RFC 4930 has several normative references to RFC 3066.

RFC 4930 has been approved by the IESG in January 2007 and published
in May 2007.

RFC 3066 have been obsoleted by RFC 4646 in September 2006, several
months before.

------_=_NextPart_001_01C7B12A.ADEA6F99-- --===============1293252601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1293252601==-- From ltru-bounces@ietf.org Mon Jun 18 01:07:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09Sb-00015i-16; Mon, 18 Jun 2007 01:07:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I09Sa-00014M-9N for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 01:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09SZ-000132-Vl for ltru@ietf.org; Mon, 18 Jun 2007 01:07:27 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09SX-00076N-Kt for ltru@ietf.org; Mon, 18 Jun 2007 01:07:27 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070618050724.TPSP28396.mta16.adelphia.net@DGBP7M81>; Mon, 18 Jun 2007 01:07:24 -0400 Message-ID: <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Date: Sun, 17 Jun 2007 22:07:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > There are at least three open issues listed in > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html. > > Extlang is one of them. I'll step back a bit, since it appears that we > don't have consensus about making a change in extlang from RFC 4646. > > So we need to revive the discussion from back in March. I agree. For those who wish to follow the extlang discussion, the question is: for languages listed in ISO 639-3 that are not already present in the Registry, should we: 1. add all of them as primary language subtags, or 2. take the 5% that are encompassed by an ISO 639-3 macrolanguage, add them as extended language (extlang) subtags, and add the other 95% as primary language subtags? The discussion in March started with this message from Mark: http://www1.ietf.org/mail-archive/web/ltru/current/msg07288.html Chase the "Follow-Ups" links to follow the thread. My view is that we should keep the primary/extlang relationship that we have been planning since 2004 to reflect the ISO 639-3 macrolanguage relationship. It allows identification of the individual languages while staying compatible with the way people have tagged them in the past, and in some cases with the way people will always perceive them (i.e. "Arabic" rather than 30 different flavors). Expecting matching engines to have "a bit more smarts" so they can match "yue" with "zh" doesn't work for me when we can't even expect them to be smart enough to match "en-US" with "en-Latn-US". But that's just my view, and the important thing is for the list to discuss the matter and reach a consensus so we can move forward. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 05:07:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DD4-0001C0-QU; Mon, 18 Jun 2007 05:07:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0DD3-0001As-47 for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DCy-00019A-Ru for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:07:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DCt-0001WN-3c for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:07:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0D3p-0004mV-Fw for ltru@lists.ietf.org; Mon, 18 Jun 2007 10:58:10 +0200 Received: from dialin-145-254-042-021.pools.arcor-ip.net ([145.254.42.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 10:58:09 +0200 Received: from nobody by dialin-145-254-042-021.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 10:58:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 10:42:48 +0200 Organization: Lines: 21 Message-ID: <46764588.6AC6@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.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: dialin-145-254-042-021.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf-provreg@cafax.se Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hollenbeck, Scott wrote: > That's not an error. The references are correct as published for > promotion to draft standard status. At the moment you can reconstruct a 3066 registry by looking at the redundant / grandfathered tags in the 4646 registry, and in the source standards (i.e. the language and region subtags in the 4646 registry). IOW just stay away from scripts, variants, and UN region numbers. With the 4646bis registry it will be more convoluted, you'd also have to stay away from 639-3 languages (+ extlangs, if any pop up). Should 4646bis do something for protocols wishing to emulate the old 3066 registry ? We could flag the source of language tags in the description field (just an idea). Or add a how-to as appendix. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 05:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DJ7-0004XX-9J; Mon, 18 Jun 2007 05:13:57 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0DJ5-0004XO-KN for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DJ5-0004XF-Am for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:13:55 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DJ2-0003vY-E9 for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:13:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0DEA-0007j8-40 for ltru@lists.ietf.org; Mon, 18 Jun 2007 11:08:50 +0200 Received: from dialin-145-254-042-021.pools.arcor-ip.net ([145.254.42.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 11:08:50 +0200 Received: from nobody by dialin-145-254-042-021.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 11:08:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 11:03:34 +0200 Organization: Lines: 17 Message-ID: <46764A66.6BE4@xyzzy.claranet.de> References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local><20070613205820.GL4585@mercury.ccil.org><30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-042-021.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > But from the perspective of the JAC, the "new mis" is exactly the > same "mis" as the "old mis". From the perspective of a registry user seeing only the description "uncoded" appears to be slightly broader than John's definition "uncoded and not covered by any other collection". E.g. "missingsch" is a mixture of nl, nds, and some other languages, and I think it's "uncoded". But it should be tagged as "gem", not "mis". Maybe the verbose explanation in 4646bis should copy the verbose JAC-definition, and / or add an example. Or add a comment to the bulk registry update (individual registration doesn't work). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 05:46:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DoK-0001ar-Qz; Mon, 18 Jun 2007 05:46:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0DoJ-0001Ya-Bs for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DoI-0001YB-Tu for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:46:10 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dk8-0003bq-Ai for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:41:53 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Mon, 18 Jun 2007 10:41:49 +0100 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 Date: Mon, 18 Jun 2007 10:41:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070617195931.GA22979@sources.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcexGtEsynreozDlTNaNk/2nFKi7nQAcSrLg X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Message-Id: Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane wrote: > It is difficult even for the IETF to keep track of its own > standards :-( I agree. I have had many difficulties with this. I think it would be a good idea if every time an RFC is made obsolete by the publishing of a new RFC that the new RFC reference is added to the old RFC - preferably on the first page under "Obsoletes:". Add a new line "Obsoleted by/date:" ? How could this best be achieved across the IETF? Debbie > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: 17 June 2007 21:00 > To: ltru@lists.ietf.org > Subject: [Ltru] Re: Small bibliography error in RFC 4930 > > On Sun, Jun 17, 2007 at 09:26:52PM +0200, Stephane > Bortzmeyer wrote a message of 27 lines > which said: > > > RFC 4930 has several normative references to RFC 3066. > ... > > RFC 3066 have been obsoleted by RFC 4646 in September 2006, several > > months before. > > It is difficult even for the IETF to keep track of its own > standards :-( > > > > > _______________________________________________ > 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 Jun 18 06:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ERy-0007Rz-DE; Mon, 18 Jun 2007 06:27:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0ERy-0007Rs-4G for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 06:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ERx-0007Rg-Qg for ltru@lists.ietf.org; Mon, 18 Jun 2007 06:27:09 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ERu-00079a-8v for ltru@lists.ietf.org; Mon, 18 Jun 2007 06:27:09 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5IAR0AB023483 for ; Mon, 18 Jun 2007 19:27:04 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1417_72e2c5f4_1d86_11dc_89ce_0014221f2a2d; Mon, 18 Jun 2007 19:27:00 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37582) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 18 Jun 2007 19:25:04 +0900 Message-Id: <6.0.0.20.2.20070618185934.03b95010@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Jun 2007 19:26:21 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 In-Reply-To: <46764588.6AC6@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 17:42 07/06/18, Frank Ellermann wrote: >Hollenbeck, Scott wrote: > >> That's not an error. The references are correct as published for >> promotion to draft standard status. Like others, I have problems understanding that. Randy made the procedural argument (both RFC 3066 and RFC 4646 are BCPs). There is also an implementation argument: There are no legal language tags in RFC 4646 that aren't legal according to RFC 3066. I have absolutely no clue what could break in an implementation when using a tag that became legal in RFC 4646. The only thing that I can see break is things such as "language not available", but then that kind of error was always possible. >At the moment you can reconstruct a 3066 registry by looking at >the redundant / grandfathered tags in the 4646 registry, and in >the source standards (i.e. the language and region subtags in the >4646 registry). > >IOW just stay away from scripts, variants, and UN region numbers. This is one interpretation, but there is also a different, in my view more plausible, interpretation: RFC 4646 did a bulk registration of language/region/script/whatever combinations. Because it became obvious that there would be scaling problems when registring all combinations, we took the path of changing the registry structure. The old (RFC 3066) registry has been obsoleted, there is only the RFC 4646 registry, which is a direct continuation of the RFC 3066 registry. All the tags you can generate from the new registry using the rules in RFC 4646 are legal tags according to RFC 3066, and have to be considered under RFC 3066 as if they were in fact registered one-by-one. Frank's interpretation would mean that only the variants registered at the time RFC 3066 was replaced by RFC 4646 would be usable. That would lead to weird requests. I remember that in the transition period from RFC 3066 to RFC 4646, we had somebody requesting registration of el-Latn. We rejected this because with RFC 4646, there would be no such need anymore. With the interpretation above, that would no longer be true. >With the 4646bis registry it will be more convoluted, you'd also >have to stay away from 639-3 languages (+ extlangs, if any pop up). > >Should 4646bis do something for protocols wishing to emulate the >old 3066 registry ? We could flag the source of language tags in >the description field (just an idea). Or add a how-to as appendix. No. There is no old registry. There is only one registry. The current registry IS the RFC 3066 registry, just slightly overhauled. With this, of course the reasons for citing RFC 3066 when RFC 4646 was out become even less understandable. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 06:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ESL-0007iH-JI; Mon, 18 Jun 2007 06:27:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0ESK-0007g6-Pv for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 06:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ESK-0007ev-Fi for ltru@lists.ietf.org; Mon, 18 Jun 2007 06:27:32 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DmL-0004jW-9N for ltru@lists.ietf.org; Mon, 18 Jun 2007 05:44:10 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Mon, 18 Jun 2007 10:44:07 +0100 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 Date: Mon, 18 Jun 2007 10:43:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46764588.6AC6@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcexiDEN0fw3DdEDTo+S32BkPoHOzwABNhhg X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Message-Id: Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank wrote: > Should 4646bis do something for protocols wishing to emulate > the old 3066 registry ? We could flag the source of language > tags in the description field (just an idea). Or add a > how-to as appendix. Surely that is quite easy to do as each subtag has a date? Debbie > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: 18 June 2007 09:43 > To: ltru@lists.ietf.org > Cc: ietf-provreg@cafax.se > Subject: [Ltru] Re: Small bibliography error in RFC 4930 > > Hollenbeck, Scott wrote: > > > That's not an error. The references are correct as published for > > promotion to draft standard status. > > At the moment you can reconstruct a 3066 registry by looking > at the redundant / grandfathered tags in the 4646 registry, > and in the source standards (i.e. the language and region > subtags in the > 4646 registry). > > IOW just stay away from scripts, variants, and UN region numbers. > > With the 4646bis registry it will be more convoluted, you'd > also have to stay away from 639-3 languages (+ extlangs, if > any pop up). > > Should 4646bis do something for protocols wishing to emulate > the old 3066 registry ? We could flag the source of language > tags in the description field (just an idea). Or add a > how-to as appendix. > > Frank > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 06:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Edt-00071A-Vd; Mon, 18 Jun 2007 06:39:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Eds-000715-KE for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 06:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Eds-00070x-Ao for ltru@lists.ietf.org; Mon, 18 Jun 2007 06:39:28 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Edq-0003ps-Ur for ltru@lists.ietf.org; Mon, 18 Jun 2007 06:39:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0Edg-0000Ni-As for ltru@lists.ietf.org; Mon, 18 Jun 2007 12:39:16 +0200 Received: from dialin-145-254-042-210.pools.arcor-ip.net ([145.254.42.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 12:39:16 +0200 Received: from nobody by dialin-145-254-042-210.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 12:39:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 12:25:21 +0200 Organization: Lines: 20 Message-ID: <46765D91.E95@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@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: dialin-145-254-042-210.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-provreg@cafax.se Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: >> Should 4646bis do something for protocols wishing to emulate the >> old 3066 registry ? We could flag the source of language tags in >> the description field (just an idea). Or add a how-to as appendix. > Surely that is quite easy to do as each subtag has a date? Yes, it would be easy to reconstruct a "frozen" (2006) 3066 registry. But I guess Scott's protocol tries to pretend that 3066 still exists, i.e. new country codes like IM GG JE are okay, new 639-2 languages like frr frs are okay, old redundant and grandfathered tags are okay, while scripts, variants, 639-3 languages, and extlangs are NOT okay. Personally I'd prefer "4646 registry minus scripts" (or similar) for this purpose, but Scott said it's intentionally 3066. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 07:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Fhx-0004KU-I8; Mon, 18 Jun 2007 07:47:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Fhv-0004Cf-Tc for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 07:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Fhv-0004Ag-J0 for ltru@lists.ietf.org; Mon, 18 Jun 2007 07:47:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Fho-0003n3-HP for ltru@lists.ietf.org; Mon, 18 Jun 2007 07:47:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0Fgp-0005vK-Nc for ltru@lists.ietf.org; Mon, 18 Jun 2007 13:46:35 +0200 Received: from dialin-145-254-043-226.pools.arcor-ip.net ([145.254.43.226]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 13:46:35 +0200 Received: from nobody by dialin-145-254-043-226.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 13:46:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 13:39:55 +0200 Organization: Lines: 55 Message-ID: <46766F0B.19B6@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@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: dialin-145-254-043-226.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: [I've stripped "ietf-provreg" from the Cc: list] > Randy made the procedural argument (both RFC 3066 and RFC 4646 > are BCPs). Just to clarify, I think you or Randy mean "RFC 3066 used to be a BCP before RFC 4646 obsoleted it". > I have absolutely no clue what could break in an implementation > when using a tag that became legal in RFC 4646. Matching is tricky in the presence of script subtags (and other less likely scenarios), it was one line in RFC 3066, now it's a separate document. For 4646bis no implementation will be able to match nl-BE with what-was-it, vlm (?), by only looking at the registry, unless we deprecate it manually in favour of nl-BE. It makes perfect sense to exclude some constructs. When I try the language option of a "popular" search engine I won't find de-1996 pages while looking for de, or en-GB-oed pages while looking for en (I'm too lazy to check what it was, maybe both). And I won't find frr pages while looking for fy-DE (or v.v.). But that's no 639-3 or 4646 issue, it would be the same with 3066. For 3066 stability was an implicit assumption, and 4646 made it explicit, trying to guarantee it for region tags. RFC 3066, 4646, and 4646bis fail miserably when language tags are narrowed, or when language-region combinations get their own language tag. Maybe we should keep RFC 4646 as is, and later replace it wholesale by ISO 639-6. The fy-DE and nl-BE examples (plus the "extlang" discussion) are a warning. This nl-BE confusion is in essence the same issue as the old CS chaos, we're trying to mix standards designed to be used for something else. For ISO 639-3 it's logical to replace nl-BE by something "better" as soon as somebody seriously wants it, they don't know any "nl-BE", they only know "nl". But we know that nl-BE exists, and we've no way to deprecate it in favour of whatever comes, we could at best manually deprecate the new subtag in favour of nl-BE. For fy-NL, fy-DE, frr, and fy, let alone frs, I thought that it's okay to ignore the implications, after all I tried to find a single page tagged as fy-DE and found nothing. But for nl-BE (and zh-*) we might be in serious trouble. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 07:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Fmf-0001mU-Uj; Mon, 18 Jun 2007 07:52:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Fme-0001mI-Bx for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 07:52:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Fme-0001m9-1I for ltru@lists.ietf.org; Mon, 18 Jun 2007 07:52:36 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0FmY-0008Jb-SG for ltru@lists.ietf.org; Mon, 18 Jun 2007 07:52:35 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Mon, 18 Jun 2007 12:52:27 +0100 From: "Debbie Garside" To: , "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 Date: Mon, 18 Jun 2007 12:52:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.0.0.20.2.20070618185934.03b95010@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acexk0Y86psSHPHLTVK/GiW+vgNiWQAC3qoA X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Message-Id: Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin wrote: > No. There is no old registry. There is only one registry. I would have to disagree here. I can see applications for using an "old" registry in order to update to a "new" registry. Best Debbie > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 18 June 2007 11:26 > To: Frank Ellermann; ltru@lists.ietf.org > Cc: ietf-provreg@cafax.se > Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 > > At 17:42 07/06/18, Frank Ellermann wrote: > >Hollenbeck, Scott wrote: > > > >> That's not an error. The references are correct as published for > >> promotion to draft standard status. > > Like others, I have problems understanding that. Randy made > the procedural argument (both RFC 3066 and RFC 4646 are BCPs). > > There is also an implementation argument: > There are no legal language tags in RFC 4646 that aren't > legal according to RFC 3066. I have absolutely no clue what > could break in an implementation when using a tag that became > legal in RFC 4646. The only thing that I can see break is > things such as "language not available", but then that kind > of error was always possible. > > >At the moment you can reconstruct a 3066 registry by looking at the > >redundant / grandfathered tags in the 4646 registry, and in > the source > >standards (i.e. the language and region subtags in the > >4646 registry). > > > >IOW just stay away from scripts, variants, and UN region numbers. > > This is one interpretation, but there is also a different, in > my view more plausible, interpretation: RFC 4646 did a bulk > registration of language/region/script/whatever combinations. > Because it became obvious that there would be scaling > problems when registring all combinations, we took the path > of changing the registry structure. The old (RFC 3066) > registry has been obsoleted, there is only the RFC 4646 > registry, which is a direct continuation of the RFC 3066 > registry. All the tags you can generate from the new registry > using the rules in RFC 4646 are legal tags according to RFC > 3066, and have to be considered under RFC 3066 as if they > were in fact registered one-by-one. > > Frank's interpretation would mean that only the variants > registered at the time RFC 3066 was replaced by RFC 4646 > would be usable. That would lead to weird requests. I > remember that in the transition period from RFC 3066 to RFC > 4646, we had somebody requesting registration of el-Latn. > We rejected this because with RFC 4646, there would be no > such need anymore. With the interpretation above, that would > no longer be true. > > > >With the 4646bis registry it will be more convoluted, you'd > also have > >to stay away from 639-3 languages (+ extlangs, if any pop up). > > > >Should 4646bis do something for protocols wishing to emulate the old > >3066 registry ? We could flag the source of language tags in the > >description field (just an idea). Or add a how-to as appendix. > > No. There is no old registry. There is only one registry. > The current registry IS the RFC 3066 registry, just slightly > overhauled. > > With this, of course the reasons for citing RFC 3066 when RFC > 4646 was out become even less understandable. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 10:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IJD-0005jS-7G; Mon, 18 Jun 2007 10:34:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0IJC-0005jN-GS for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 10:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IJC-0005jF-6w for ltru@lists.ietf.org; Mon, 18 Jun 2007 10:34:22 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IJB-0007vW-0B for ltru@lists.ietf.org; Mon, 18 Jun 2007 10:34:22 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0IJ9-000325-Ui; Mon, 18 Jun 2007 10:34:20 -0400 Date: Mon, 18 Jun 2007 10:34:19 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 Message-ID: <20070618143419.GA25433@mercury.ccil.org> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@localhost> <46766F0B.19B6@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46766F0B.19B6@xyzzy.claranet.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > For 4646bis no implementation will be able to match nl-BE with > what-was-it, vlm [recte "vls"], by only looking at the registry, unless > we deprecate it manually in favour of nl-BE. We can't do that; they are two different languages, though closely related and intertwined in use It would be like deprecating nds in favor of de-northern. And fy-DE could never have been more than a hack like zh-TW for zh-Hant: is it North Frisian, or is it Saterfrisian aka East Frisian (not to be confused with the variety of nds also called "East Frisian", still less with the variety of Standard German (de) spoken in Ostfriesen)? -- The Unicode Standard does not encode John Cowan idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan use characters, nor does it encode logos or graphics. cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 11:25:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J6R-0004g7-Vs; Mon, 18 Jun 2007 11:25:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0J6Q-0004g2-Da for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J6Q-0004fu-46 for ltru@lists.ietf.org; Mon, 18 Jun 2007 11:25:14 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0J6O-00044H-Oh for ltru@lists.ietf.org; Mon, 18 Jun 2007 11:25:14 -0400 Received: from [10.72.73.7] (snvvpn1-10-72-73-c7.corp.yahoo.com [10.72.73.7]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5IFPAhq080128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 08:25:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kOryWe/rnKTi+sFEioGF2+HR1ZDeRAlc5iFYoJg6KMucjUW7M4sKafwOAfL/Ifkv Message-ID: <4676A3D4.3060300@yahoo-inc.com> Date: Mon, 18 Jun 2007 08:25:08 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Suggested language for "mis" References: <30b660a20706160829s4e6de527o457464b4a21fdf8e@mail.gmail.com> <003301c7b035$fd9f9dc0$6601a8c0@oemcomputer> <46748F8F.2B0B@xyzzy.claranet.de> In-Reply-To: <46748F8F.2B0B@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +2. I'll put that in the draft when I sit down with it again (later today??). Incidentally, I'm preparing to submit draft-07. Addison Frank Ellermann wrote: > Randy Presuhn wrote: > >>> The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to >>> ISO 639, it is used to identify linguistic content whose language is known >>> but which does not *currently* have a corresponding subtag. It is thus >>> intrinsically unstable -- the addition of other codes in the future can >>> render its application invalid at any point without any warning -- and hence >>> incompatible with the stability goals of BCP 47. It is thus always >>> preferable to use other subtags: either "und" or -- with prior agreement -- >>> private use subtags. >> ... > >> As a technical contributor, I rather like this proposal. > > +1, > no need to discuss MARC and other good excuses to violate the SHOULD NOT. > > Frank > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 11:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JGT-0006Fm-0B; Mon, 18 Jun 2007 11:35:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0JGR-0006Em-J0 for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:35:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JGR-0006Eb-9P for ltru@ietf.org; Mon, 18 Jun 2007 11:35:35 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0JGP-0005Oo-Us for ltru@ietf.org; Mon, 18 Jun 2007 11:35:35 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070618153521.OXWF15873.mta10.adelphia.net@DGBP7M81> for ; Mon, 18 Jun 2007 15:35:21 +0000 Message-ID: <00c301c7b1be$478e9e20$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 18 Jun 2007 08:35:19 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst quoted Frank Ellermann: >> At the moment you can reconstruct a 3066 registry by looking at the >> redundant / grandfathered tags in the 4646 registry, and in the source >> standards (i.e. the language and region subtags in the 4646 registry). >> >> IOW just stay away from scripts, variants, and UN region numbers. No need to do that. Just go to http://www.iana.org/assignments/language-tags . IANA must be keeping the old registry around for some reason; this must be it. Martin wrote: > I remember that in the transition period from RFC 3066 to RFC 4646, we had > somebody requesting registration of el-Latn. We rejected this because with > RFC 4646, there would be no such need anymore. With the interpretation > above, that would no longer be true. Actually, we accepted it but it initially failed to make it into the 3066 registry, since by that time 4646 was very close at hand indeed. Months after 4646 weas released, the requestor argued forcefully to have "el-Latn" added to both registries. IIRC there were veiled legal threats. > No. There is no old registry. There is only one registry. The current > registry IS the RFC 3066 registry, just slightly overhauled. > > With this, of course the reasons for citing RFC 3066 when RFC 4646 was out > become even less understandable. I admit to a lot of confusion regarding Scott's explanation. When I was working on 4645, I heard frequently that RFC references must always refer to the latest revision, not to RFCs that have been superseded. I'm sure nobody wants RFC authors to be able to pick and choose among obsolete RFCs to find the one with the most favorable, now-removed wording. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 13:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kgp-0003Qy-G8; Mon, 18 Jun 2007 13:06:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Kgo-0003QX-JL for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kgo-0003QJ-8I for ltru@ietf.org; Mon, 18 Jun 2007 13:06:54 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Kgm-0001GC-Bh for ltru@ietf.org; Mon, 18 Jun 2007 13:06:54 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2624998wah for ; Mon, 18 Jun 2007 10:06:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VPritMgobUbIPFjIjDnB90NUdf/o02V73B49sTw145jwt62/gkREIueybtIppV5GR0lmI17Xvbv12Y99vxhmJabexSdX9flmeQTrVoDIuoTTFabjUPbiUxLmfuVOC/IewCzeMLL6gBh+h4xONV7aXyqzRMklRFSvCDg35zgM0dI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iiI+SiHTOveIixygFDr9AlasNCq16FVgak0mpVdWOAILEExmsqaoUDqoAO2sMQIry4q89yALGp9WMHh9za2bfRH/z7Ymc3dIu4fstPPq8cr6hnf8LfrX7F6jl+tgnHpKnnNdKHKF9aIrM6LzU/NeX6Xmbqu+MERckUSHQOdMezM= Received: by 10.114.13.1 with SMTP id 1mr6280792wam.1182186410787; Mon, 18 Jun 2007 10:06:50 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 10:06:50 -0700 (PDT) Message-ID: <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> Date: Mon, 18 Jun 2007 10:06:50 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) In-Reply-To: <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 7a95f2151ec6d33c X-Spam-Score: 0.3 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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="===============1297085007==" Errors-To: ltru-bounces@ietf.org --===============1297085007== Content-Type: multipart/alternative; boundary="----=_Part_68413_12597298.1182186410744" ------=_Part_68413_12597298.1182186410744 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgYWRkZWQgZXh0bGFuZyB0byBhbGxvdyBvdXJzZWx2ZXMgdGhlIGZyZWVkb20gdG8gbWFrZSBj aG9pY2VzIHdoZW4gNjM5LTMKY2FtZSBhbG9uZy4gV2UgKnZlcnkgY2xlYXJseSBkaWQgbm90IGRl ZmluZSBpdHMgbWVhbmluZyosIGJlY2F1c2Ugd2UgZGlkbid0Cmtub3cgd2hhdCA2MzktMyB3YXMg ZmluYWxseSBnb2luZyB0byBsb29rIGxpa2UsIG5vciBkaWQgd2UgaGF2ZSBhZ3JlZW1lbnQgb24K d2hhdCB3ZSBzaG91bGQgYWN0dWFsbHkgZG8uIFdlIGhhZCBubyBjb21taXRtZW50IHRvIHVzaW5n IGV4dGxhbmcuCgpXZSAqYWxyZWFkeSogaGFkIG1hY3JvbGFuZ3VhZ2VzIHdpdGggSVNPIDYzOS0y IGluIFJGQyA0NjQ2IGFuZCB3ZSAqZGlkIG5vdCoKdXNlIGV4dGxhbmcgZm9yIHRoZW06IGV4YW1w bGVzIGFyZSAic3IiLCAiaHIiLCAibmIiLCBldGMuIFdlIGFyZSBub3QgZ29pbmcKdG8gKGFuZCBj YW5ub3QpIGJlIGZvcmNpbmcgdXNlcnMgdG8gZW5jb2RlIG5iIGFzIG5vLW5iLCBub3Igc3IgYXMg c2gtc3IuClRoZXNlIGluY2x1ZGUKCmFrIDQ2NDYgQWthbiBmYXQgNDY0NiBGYW50aSAgYWsgNDY0 NiBBa2FuIHR3IDQ2NDYgVHdpICBubyA0NjQ2IE5vcndlZ2lhbiBuYgo0NjQ2IE5vcndlZ2lhbiBC b2ttw4NsICBubyA0NjQ2IE5vcndlZ2lhbiBubiA0NjQ2IE5vcndlZ2lhbiBOeW5vcnNrICBzaCA0 NjQ2ClNlcmJvLUNyb2F0aWFuIGJzIDQ2NDYgQm9zbmlhbiAgc2ggNDY0NiBTZXJiby1Dcm9hdGlh biBociA0NjQ2IENyb2F0aWFuICBzaAo0NjQ2IFNlcmJvLUNyb2F0aWFuIHNyIDQ2NDYgU2VyYmlh bgpXaGVuIHdlICgiR29vZ2xlIikgdHJpZWQgaW1wbGVtZW50aW5nIG1hdGNoaW5nIHdpdGggInpo LXl1ZSIgYW5kIG90aGVycywgd2UKZm91bmQgaXQgbWFkZSB0aGluZ3MgKm1vcmUqIGRpZmZpY3Vs dCwgbm90IGxlc3MuIE1hdGNoaW5nICJ6aCIgYW5kICJ5dWUiIGlzCm5vdCBzb21ldGhpbmcgeW91 IHdhbnQgdG8gZG8gYXV0b21hdGljYWxseS4gTW9yZW92ZXIsIGJlY2F1c2Ugb2YgIzIgd2UgaGFk CnRvIGhhdmUgYSBtZWNoYW5pc20gZm9yIGRlYWxpbmcgd2l0aCBtYWNyb2xhbmd1YWdlcyBpbiBS RkMgNDY0NiAqYW55d2F5Ki4KClRodXMgdG8gbWFrZSBhIHByb3Bvc2VkIGNoYW5nZSBmcm9tIDQ2 NDYgdG8gdXNlIHRoZSBleHRsYW5nIG1lY2hhbmlzbSBmb3IKbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBt YWNyb2xhbmd1YWdlcywgd2UgbmVlZCBhIHZlcnkgY29tcGVsbGluZyBjYXNlIHRoYXQgdGhlCmFk ZGl0aW9uYWwgY29tcGxpY2F0aW9uIHNvbHZlcyBtb3JlIHByb2JsZW1zIHRoYW4gaXQgY3JlYXRl cy4gV2UgaGF2ZW4ndApzZWVuIHRoYXQgeWV0LCBhbmQgY2VydGFpbmx5IGhhdmUgbm8gY29uc2Vu c3VzIHRoYXQgaXQgaXMgdGhlIGNhc2UuCgpTbyBteSBwcm9wb3NhbCBpcyBlc3NlbnRpYWxseToK CkEuIEtlZXAgdGhlIHNhbWUgc3RydWN0dXJlIGFuZCBzYW1lIHBoaWxvc29waHkgYXMgaW4gUkZD IDQ2NDYuIElTTyA2MzktMwpjb2RlcyBiZWNvbWUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzLCB3 aGV0aGVyIHRoZXkgaGF2ZSBhIG1hY3JvIGxhbmd1YWdlIG9yCm5vdC4gVGhlc2UgYXJlIHRoZSBl ZGl0cyBJIHBhc3NlZCBvdXQgcHJldmlvdXNseSwgcGx1cyB0aGUgcmVtb3ZhbCBvZgoyLjIuMmZy b20gdGhlIGRyYWZ0LCBhbmQgYSBmZXcgb3RoZXIgY2hhbmdlcyAoYmFzaWNhbGx5IHJldmVydGlu ZyB0bwpSRkMgNDY0NiBmb3IKZXh0bGFuZykuCgpCLiAob3B0aW9uYWwpIEFkZCBhIGZpZWxkIE1h Y3JvbGFuZ3VhZ2U6IHRvIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkuClRoZSBzdWdnZXN0 ZWQgdGV4dCBjaGFuZ2VzIGFyZToKCiogaW4gMy4xLjIuICBSZWNvcmQgRGVmaW5pdGlvbnMsIGFk ZCBpbiB0aGUgb3B0aW9uYWwgZmllbGRzCgoiTWFjcm9sYW5ndWFnZQoKICAgLSBGb3IgZmllbGRz IG9mIHR5cGUgJ2xhbmd1YWdlJywgaWYgdGhlcmUgaXMgYSBtYWNybyBsYW5ndWFnZSBpbiBJU08K ICAgNjM5LTMsIHRoZW4gdGhpcyBmaWVsZCBpbmRpY2F0ZXMgdGhhdC4iCgoqIEFmdGVyIDMuMS45 IGFkZCBhIG5ldyBzZWN0aW9uLgoKTWFjcm9sYW5ndWFnZQoKVGhlIG1hY3JvIGxhbmd1YWdlIGZp ZWxkIGlzIGFkZGVkIHdoZW5ldmVyIGEgbGFuZ3VhZ2UgaGFzIGEgY29ycmVzcG9uZGluZwptYWNy byBsYW5ndWFnZSBpbiBJU08gNjM5LTMuIEZvciBleGFtcGxlLCAnc3InIChTZXJiaWFuKSB3aWxs IGhhdmUgdGhlCk1hY3JvbGFuZ3VhZ2UgdmFsdWUgJ3NoJyAoU2VyYm8tQ3JvYXRpb24pLiBUaGlz IGZpZWxkIGlzIHByb3ZpZGVkIGZvciB1c2UgaW4KbWF0Y2hpbmcgYWxnb3JpdGhtcy4gRm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG1lYW5pbmcgYW5kIHVzZSBvZgptYWNyb2xhbmd1YWdl cywgc2VlIFtJU08gNjM5LTNdLgoKKiBUaGVuIHNlYXJjaCBmb3IgaW5zdGFuY2VzIG9mICJTdXBw cmVzcy1TY3JpcHQiIChqdXN0IGFzIGEgcGxhY2UgdG8gZmluZAp3aGVyZSBmaWVsZCBkZXNjcmlw dGlvbnMgYXJlKSBhbmQgbWFrZSBhbiBhZGRpdGlvbiBvZiAiTWFjcm9sYW5ndWFnZSIgaWYKYXBw cm9wcmlhdGUsIGVnIGluIHRoZSAiTEFOR1VBR0UgU1VCVEFHIFJFR0lTVFJBVElPTiBGT1JNIgoK TWFyawoKCk9uIDYvMTcvMDcsIERvdWcgRXdlbGwgPGRld2VsbEByb2FkcnVubmVyLmNvbT4gd3Jv dGU6Cj4KPiBNYXJrIERhdmlzIHdyb3RlOgo+Cj4gPiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUg b3BlbiBpc3N1ZXMgbGlzdGVkIGluCj4gPiBodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQv ZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMDYuaHRtbC4KPiA+Cj4gPiBFeHRsYW5nIGlzIG9uZSBv ZiB0aGVtLiBJJ2xsIHN0ZXAgYmFjayBhIGJpdCwgc2luY2UgaXQgYXBwZWFycyB0aGF0IHdlCj4g PiBkb24ndCBoYXZlIGNvbnNlbnN1cyBhYm91dCBtYWtpbmcgYSBjaGFuZ2UgaW4gZXh0bGFuZyBm cm9tIFJGQyA0NjQ2Lgo+ID4KPiA+IFNvIHdlIG5lZWQgdG8gcmV2aXZlIHRoZSBkaXNjdXNzaW9u IGZyb20gYmFjayBpbiBNYXJjaC4KPgo+IEkgYWdyZWUuICBGb3IgdGhvc2Ugd2hvIHdpc2ggdG8g Zm9sbG93IHRoZSBleHRsYW5nIGRpc2N1c3Npb24sIHRoZQo+IHF1ZXN0aW9uCj4gaXM6IGZvciBs YW5ndWFnZXMgbGlzdGVkIGluIElTTyA2MzktMyB0aGF0IGFyZSBub3QgYWxyZWFkeSBwcmVzZW50 IGluIHRoZQo+IFJlZ2lzdHJ5LCBzaG91bGQgd2U6Cj4KPiAxLiAgYWRkIGFsbCBvZiB0aGVtIGFz IHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncywgb3IKPiAyLiAgdGFrZSB0aGUgNSUgdGhhdCBhcmUg ZW5jb21wYXNzZWQgYnkgYW4gSVNPIDYzOS0zIG1hY3JvbGFuZ3VhZ2UsIGFkZAo+IHRoZW0KPiBh cyBleHRlbmRlZCBsYW5ndWFnZSAoZXh0bGFuZykgc3VidGFncywgYW5kIGFkZCB0aGUgb3RoZXIg OTUlIGFzIHByaW1hcnkKPiBsYW5ndWFnZSBzdWJ0YWdzPwo+Cj4gVGhlIGRpc2N1c3Npb24gaW4g TWFyY2ggc3RhcnRlZCB3aXRoIHRoaXMgbWVzc2FnZSBmcm9tIE1hcms6Cj4gaHR0cDovL3d3dzEu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMDcyODguaHRtbAo+Cj4g Q2hhc2UgdGhlICJGb2xsb3ctVXBzIiBsaW5rcyB0byBmb2xsb3cgdGhlIHRocmVhZC4KPgo+IE15 IHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQga2VlcCB0aGUgcHJpbWFyeS9leHRsYW5nIHJlbGF0aW9u c2hpcCB0aGF0IHdlCj4gaGF2ZQo+IGJlZW4gcGxhbm5pbmcgc2luY2UgMjAwNCB0byByZWZsZWN0 IHRoZSBJU08gNjM5LTMgbWFjcm9sYW5ndWFnZQo+IHJlbGF0aW9uc2hpcC4gIEl0IGFsbG93cyBp ZGVudGlmaWNhdGlvbiBvZiB0aGUgaW5kaXZpZHVhbCBsYW5ndWFnZXMgd2hpbGUKPiBzdGF5aW5n IGNvbXBhdGlibGUgd2l0aCB0aGUgd2F5IHBlb3BsZSBoYXZlIHRhZ2dlZCB0aGVtIGluIHRoZSBw YXN0LCBhbmQKPiBpbgo+IHNvbWUgY2FzZXMgd2l0aCB0aGUgd2F5IHBlb3BsZSB3aWxsIGFsd2F5 cyBwZXJjZWl2ZSB0aGVtIChpLmUuICJBcmFiaWMiCj4gcmF0aGVyIHRoYW4gMzAgZGlmZmVyZW50 IGZsYXZvcnMpLiAgRXhwZWN0aW5nIG1hdGNoaW5nIGVuZ2luZXMgdG8gaGF2ZSAiYQo+IGJpdCBt b3JlIHNtYXJ0cyIgc28gdGhleSBjYW4gbWF0Y2ggInl1ZSIgd2l0aCAiemgiIGRvZXNuJ3Qgd29y ayBmb3IgbWUKPiB3aGVuCj4gd2UgY2FuJ3QgZXZlbiBleHBlY3QgdGhlbSB0byBiZSBzbWFydCBl bm91Z2ggdG8gbWF0Y2ggImVuLVVTIiB3aXRoCj4gImVuLUxhdG4tVVMiLgo+Cj4gQnV0IHRoYXQn cyBqdXN0IG15IHZpZXcsIGFuZCB0aGUgaW1wb3J0YW50IHRoaW5nIGlzIGZvciB0aGUgbGlzdCB0 bwo+IGRpc2N1c3MKPiB0aGUgbWF0dGVyIGFuZCByZWFjaCBhIGNvbnNlbnN1cyBzbyB3ZSBjYW4g bW92ZSBmb3J3YXJkLgo+Cj4gLS0KPiBEb3VnIEV3ZWxsICAqICBGdWxsZXJ0b24sIENhbGlmb3Ju aWEsIFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQKPiBodHRwOi8vdXNlcnMuYWRlbHBoaWEu bmV0L35kZXdlbGwvCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNo YXJ0ZXIuaHRtbAo+IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2ll dGYtbGFuZ3VhZ2VzCj4KPgoKCi0tIApNYXJrCg== ------=_Part_68413_12597298.1182186410744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgYWRkZWQgZXh0bGFuZyB0byBhbGxvdyBvdXJzZWx2ZXMgdGhlIGZyZWVkb20gdG8gbWFrZSBj aG9pY2VzIHdoZW4gNjM5LTMgY2FtZSBhbG9uZy4gV2UgKnZlcnkgY2xlYXJseSBkaWQgbm90IGRl ZmluZSBpdHMgbWVhbmluZyosIGJlY2F1c2Ugd2UgZGlkbiYjMzk7dCBrbm93IHdoYXQgNjM5LTMg d2FzIGZpbmFsbHkgZ29pbmcgdG8gbG9vayBsaWtlLCBub3IgZGlkIHdlIGhhdmUgYWdyZWVtZW50 IG9uIHdoYXQgd2Ugc2hvdWxkIGFjdHVhbGx5IGRvLiBXZSBoYWQgbm8gY29tbWl0bWVudCB0byB1 c2luZyBleHRsYW5nLgo8YnI+PGJyPldlICphbHJlYWR5KiBoYWQgbWFjcm9sYW5ndWFnZXMgd2l0 aCBJU08gNjM5LTIgaW4gUkZDIDQ2NDYgYW5kIHdlICpkaWQgbm90KiB1c2UgZXh0bGFuZyBmb3Ig dGhlbTogZXhhbXBsZXMgYXJlICZxdW90O3NyJnF1b3Q7LCAmcXVvdDtociZxdW90OywgJnF1b3Q7 bmImcXVvdDssIGV0Yy4gV2UgYXJlIG5vdCBnb2luZyB0byAoYW5kIGNhbm5vdCkgYmUgZm9yY2lu ZyB1c2VycyB0byBlbmNvZGUgbmIgYXMgbm8tbmIsIG5vciBzciBhcyBzaC1zci4mbmJzcDsgVGhl c2UgaW5jbHVkZQo8YnI+PGJyPjx0YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBz ZTsgd2lkdGg6IDQ1M3B0OyIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiIHdpZHRoPSI2MDUiPjx0Ym9keT48dHIgaGVpZ2h0PSIxNyI+PHRkIHN0eWxlPSJ3aWR0aDog MjRwdDsiIGhlaWdodD0iMTciIHdpZHRoPSIzMiI+PGZvbnQgc2l6ZT0iMiI+YWs8L2ZvbnQ+PC90 ZD4KICA8dGQgc3R5bGU9IndpZHRoOiAyNnB0OyB0ZXh0LWFsaWduOiBjZW50ZXI7IiB3aWR0aD0i MzUiPjxmb250IHNpemU9IjIiPjQ2NDY8L2ZvbnQ+PC90ZD4KICA8dGQgc3R5bGU9IndpZHRoOiAx NTBwdDsiIHdpZHRoPSIyMDAiPjxmb250IHNpemU9IjIiPkFrYW48L2ZvbnQ+PC90ZD4KICA8dGQg c3R5bGU9IndpZHRoOiAyN3B0OyIgd2lkdGg9IjM2Ij48Zm9udCBzaXplPSIyIj5mYXQ8L2ZvbnQ+ PC90ZD4KICA8dGQgc3R5bGU9IndpZHRoOiAyNnB0OyB0ZXh0LWFsaWduOiBjZW50ZXI7IiB3aWR0 aD0iMzUiPjxmb250IHNpemU9IjIiPjQ2NDY8L2ZvbnQ+PC90ZD4KICA8dGQgc3R5bGU9IndpZHRo OiAyMDBwdDsiIHdpZHRoPSIyNjciPjxmb250IHNpemU9IjIiPkZhbnRpPC9mb250PjwvdGQ+CiA8 L3RyPgogPHRyIGhlaWdodD0iMTciPgogIDx0ZCBoZWlnaHQ9IjE3Ij48Zm9udCBzaXplPSIyIj5h azwvZm9udD48L3RkPgogIDx0ZCBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyOyI+PGZvbnQgc2l6 ZT0iMiI+NDY0NjwvZm9udD48L3RkPgogIDx0ZD48Zm9udCBzaXplPSIyIj5Ba2FuPC9mb250Pjwv dGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPnR3PC9mb250PjwvdGQ+CiAgPHRkIHN0eWxlPSJ0ZXh0 LWFsaWduOiBjZW50ZXI7Ij48Zm9udCBzaXplPSIyIj40NjQ2PC9mb250PjwvdGQ+CiAgPHRkPjxm b250IHNpemU9IjIiPlR3aTwvZm9udD48L3RkPgogPC90cj4KIDx0ciBoZWlnaHQ9IjE3Ij4KICA8 dGQgaGVpZ2h0PSIxNyI+PGZvbnQgc2l6ZT0iMiI+bm88L2ZvbnQ+PC90ZD4KICA8dGQgc3R5bGU9 InRleHQtYWxpZ246IGNlbnRlcjsiPjxmb250IHNpemU9IjIiPjQ2NDY8L2ZvbnQ+PC90ZD4KICA8 dGQ+PGZvbnQgc2l6ZT0iMiI+Tm9yd2VnaWFuPC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9 IjIiPm5iPC9mb250PjwvdGQ+CiAgPHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij48Zm9u dCBzaXplPSIyIj40NjQ2PC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPk5vcndlZ2lh biBCb2ttw4NsPC9mb250PjwvdGQ+CiA8L3RyPgogPHRyIGhlaWdodD0iMTciPgogIDx0ZCBoZWln aHQ9IjE3Ij48Zm9udCBzaXplPSIyIj5ubzwvZm9udD48L3RkPgogIDx0ZCBzdHlsZT0idGV4dC1h bGlnbjogY2VudGVyOyI+PGZvbnQgc2l6ZT0iMiI+NDY0NjwvZm9udD48L3RkPgogIDx0ZD48Zm9u dCBzaXplPSIyIj5Ob3J3ZWdpYW48L2ZvbnQ+PC90ZD4KICA8dGQ+PGZvbnQgc2l6ZT0iMiI+bm48 L2ZvbnQ+PC90ZD4KICA8dGQgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlcjsiPjxmb250IHNpemU9 IjIiPjQ2NDY8L2ZvbnQ+PC90ZD4KICA8dGQ+PGZvbnQgc2l6ZT0iMiI+Tm9yd2VnaWFuIE55bm9y c2s8L2ZvbnQ+PC90ZD4KIDwvdHI+CiA8dHIgaGVpZ2h0PSIxNyI+CiAgPHRkIGhlaWdodD0iMTci Pjxmb250IHNpemU9IjIiPnNoPC9mb250PjwvdGQ+CiAgPHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBj ZW50ZXI7Ij48Zm9udCBzaXplPSIyIj40NjQ2PC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9 IjIiPlNlcmJvLUNyb2F0aWFuPC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPmJzPC9m b250PjwvdGQ+CiAgPHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij48Zm9udCBzaXplPSIy Ij40NjQ2PC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPkJvc25pYW48L2ZvbnQ+PC90 ZD4KIDwvdHI+CiA8dHIgaGVpZ2h0PSIxNyI+CiAgPHRkIGhlaWdodD0iMTciPjxmb250IHNpemU9 IjIiPnNoPC9mb250PjwvdGQ+CiAgPHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij48Zm9u dCBzaXplPSIyIj40NjQ2PC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPlNlcmJvLUNy b2F0aWFuPC9mb250PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPmhyPC9mb250PjwvdGQ+CiAg PHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij48Zm9udCBzaXplPSIyIj40NjQ2PC9mb250 PjwvdGQ+CiAgPHRkPjxmb250IHNpemU9IjIiPkNyb2F0aWFuPC9mb250PjwvdGQ+CiA8L3RyPgog PHRyIGhlaWdodD0iMTciPgogIDx0ZCBoZWlnaHQ9IjE3Ij48Zm9udCBzaXplPSIyIj5zaDwvZm9u dD48L3RkPgogIDx0ZCBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyOyI+PGZvbnQgc2l6ZT0iMiI+ NDY0NjwvZm9udD48L3RkPgogIDx0ZD48Zm9udCBzaXplPSIyIj5TZXJiby1Dcm9hdGlhbjwvZm9u dD48L3RkPgogIDx0ZD48Zm9udCBzaXplPSIyIj5zcjwvZm9udD48L3RkPgogIDx0ZCBzdHlsZT0i dGV4dC1hbGlnbjogY2VudGVyOyI+PGZvbnQgc2l6ZT0iMiI+NDY0NjwvZm9udD48L3RkPgogIDx0 ZD48Zm9udCBzaXplPSIyIj5TZXJiaWFuPC9mb250PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+ PGJyPldoZW4gd2UgKCZxdW90O0dvb2dsZSZxdW90OykgdHJpZWQgaW1wbGVtZW50aW5nIG1hdGNo aW5nIHdpdGggJnF1b3Q7emgteXVlJnF1b3Q7IGFuZCBvdGhlcnMsIHdlIGZvdW5kIGl0IG1hZGUg dGhpbmdzICptb3JlKiBkaWZmaWN1bHQsIG5vdCBsZXNzLiBNYXRjaGluZyAmcXVvdDt6aCZxdW90 OyBhbmQgJnF1b3Q7eXVlJnF1b3Q7IGlzIG5vdCBzb21ldGhpbmcgeW91IHdhbnQgdG8gZG8gYXV0 b21hdGljYWxseS4gTW9yZW92ZXIsIGJlY2F1c2Ugb2YgIzIgd2UgaGFkIHRvIGhhdmUgYSBtZWNo YW5pc20gZm9yIGRlYWxpbmcgd2l0aCBtYWNyb2xhbmd1YWdlcyBpbiBSRkMgNDY0NiAqYW55d2F5 Ki4KPGJyPjxicj5UaHVzIHRvIG1ha2UgYSBwcm9wb3NlZCBjaGFuZ2UgZnJvbSA0NjQ2IHRvIHVz ZSB0aGUgZXh0bGFuZyBtZWNoYW5pc20gZm9yIGxhbmd1YWdlcyB0aGF0IGhhdmUgbWFjcm9sYW5n dWFnZXMsIHdlIG5lZWQgYSB2ZXJ5IGNvbXBlbGxpbmcgY2FzZSB0aGF0IHRoZSBhZGRpdGlvbmFs IGNvbXBsaWNhdGlvbiBzb2x2ZXMgbW9yZSBwcm9ibGVtcyB0aGFuIGl0IGNyZWF0ZXMuIFdlIGhh dmVuJiMzOTt0IHNlZW4gdGhhdCB5ZXQsIGFuZCBjZXJ0YWlubHkgaGF2ZSBubyBjb25zZW5zdXMg dGhhdCBpdCBpcyB0aGUgY2FzZS4KPGJyPjxicj5TbyBteSBwcm9wb3NhbCBpcyBlc3NlbnRpYWxs eTo8YnI+PGJyPkEuIEtlZXAgdGhlIHNhbWUgc3RydWN0dXJlIGFuZCBzYW1lIHBoaWxvc29waHkg YXMgaW4gUkZDIDQ2NDYuIElTTyA2MzktMyBjb2RlcyBiZWNvbWUgcHJpbWFyeSBsYW5ndWFnZSBz dWJ0YWdzLCB3aGV0aGVyIHRoZXkgaGF2ZSBhIG1hY3JvIGxhbmd1YWdlIG9yIG5vdC4gVGhlc2Ug YXJlIHRoZSBlZGl0cyBJIHBhc3NlZCBvdXQgcHJldmlvdXNseSwgcGx1cyB0aGUgcmVtb3ZhbCBv ZiAKMi4yLjIgZnJvbSB0aGUgZHJhZnQsIGFuZCBhIGZldyBvdGhlciBjaGFuZ2VzIChiYXNpY2Fs bHkgcmV2ZXJ0aW5nIHRvIFJGQyA0NjQ2IGZvciBleHRsYW5nKS48YnI+PGJyPkIuIChvcHRpb25h bCkgQWRkIGEgZmllbGQgTWFjcm9sYW5ndWFnZTogdG8gdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdp c3RyeS4gVGhlIHN1Z2dlc3RlZCB0ZXh0IGNoYW5nZXMgYXJlOjxicj48YnI+KiBpbiAzLjEuMgou Jm5ic3A7ClJlY29yZCBEZWZpbml0aW9ucywgYWRkIGluIHRoZSBvcHRpb25hbCBmaWVsZHM8YnI+ PGJyPiZxdW90O01hY3JvbGFuZ3VhZ2U8dWwgY2xhc3M9InRleHQiPjxsaT5Gb3IgZmllbGRzIG9m IHR5cGUgJiMzOTtsYW5ndWFnZSYjMzk7LCBpZiB0aGVyZSBpcyBhIG1hY3JvIGxhbmd1YWdlIGlu IElTTyA2MzktMywgdGhlbiB0aGlzIGZpZWxkIGluZGljYXRlcyB0aGF0LiZxdW90OzwvbGk+PC91 bD4KKiBBZnRlciAzLjEuOSBhZGQgYSBuZXcgc2VjdGlvbi48YnI+PGJyPk1hY3JvbGFuZ3VhZ2U8 YnI+PGJyPlRoZSBtYWNybyBsYW5ndWFnZSBmaWVsZCBpcyBhZGRlZCB3aGVuZXZlciBhIGxhbmd1 YWdlIGhhcyBhIGNvcnJlc3BvbmRpbmcgbWFjcm8gbGFuZ3VhZ2UgaW4gSVNPIDYzOS0zLiBGb3Ig ZXhhbXBsZSwgJiMzOTtzciYjMzk7IChTZXJiaWFuKSB3aWxsIGhhdmUgdGhlIE1hY3JvbGFuZ3Vh Z2UgdmFsdWUgJiMzOTtzaCYjMzk7IChTZXJiby1Dcm9hdGlvbikuIFRoaXMgZmllbGQgaXMgcHJv dmlkZWQgZm9yIHVzZSBpbiBtYXRjaGluZyBhbGdvcml0aG1zLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgbWVhbmluZyBhbmQgdXNlIG9mIG1hY3JvbGFuZ3VhZ2VzLCBzZWUgW0lTTyA2 MzktM10uCjxicj48YnI+KiBUaGVuIHNlYXJjaCBmb3IgaW5zdGFuY2VzIG9mICZxdW90O1N1cHBy ZXNzLVNjcmlwdCZxdW90OyAoanVzdCBhcyBhIHBsYWNlIHRvIGZpbmQgd2hlcmUgZmllbGQgZGVz Y3JpcHRpb25zIGFyZSkgYW5kIG1ha2UgYW4gYWRkaXRpb24gb2YgJnF1b3Q7TWFjcm9sYW5ndWFn ZSZxdW90OyBpZiBhcHByb3ByaWF0ZSwgZWcgaW4gdGhlICZxdW90O0xBTkdVQUdFIFNVQlRBRyBS RUdJU1RSQVRJT04gRk9STSZxdW90Owo8YnI+PGJyPk1hcms8YnI+PGJyPjxicj48ZGl2PjxzcGFu IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNi8xNy8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5h bWUiPkRvdWcgRXdlbGw8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86ZGV3ZWxsQHJvYWRydW5uZXIu Y29tIj5kZXdlbGxAcm9hZHJ1bm5lci5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2Io MjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDog MWV4OyI+Ck1hcmsgRGF2aXMgd3JvdGU6PGJyPjxicj4mZ3Q7IFRoZXJlIGFyZSBhdCBsZWFzdCB0 aHJlZSBvcGVuIGlzc3VlcyBsaXN0ZWQgaW48YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3Lmlu dGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMDYuaHRtbCI+aHR0cDov L3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS00NjQ2YmlzLTA2Lmh0bWw8 L2E+Ci48YnI+Jmd0Ozxicj4mZ3Q7IEV4dGxhbmcgaXMgb25lIG9mIHRoZW0uIEkmIzM5O2xsIHN0 ZXAgYmFjayBhIGJpdCwgc2luY2UgaXQgYXBwZWFycyB0aGF0IHdlPGJyPiZndDsgZG9uJiMzOTt0 IGhhdmUgY29uc2Vuc3VzIGFib3V0IG1ha2luZyBhIGNoYW5nZSBpbiBleHRsYW5nIGZyb20gUkZD IDQ2NDYuPGJyPiZndDs8YnI+Jmd0OyBTbyB3ZSBuZWVkIHRvIHJldml2ZSB0aGUgZGlzY3Vzc2lv biBmcm9tIGJhY2sgaW4gTWFyY2guCjxicj48YnI+SSBhZ3JlZS4mbmJzcDsmbmJzcDtGb3IgdGhv c2Ugd2hvIHdpc2ggdG8gZm9sbG93IHRoZSBleHRsYW5nIGRpc2N1c3Npb24sIHRoZSBxdWVzdGlv bjxicj5pczogZm9yIGxhbmd1YWdlcyBsaXN0ZWQgaW4gSVNPIDYzOS0zIHRoYXQgYXJlIG5vdCBh bHJlYWR5IHByZXNlbnQgaW4gdGhlPGJyPlJlZ2lzdHJ5LCBzaG91bGQgd2U6PGJyPjxicj4xLiZu YnNwOyZuYnNwO2FkZCBhbGwgb2YgdGhlbSBhcyBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MsIG9y Cjxicj4yLiZuYnNwOyZuYnNwO3Rha2UgdGhlIDUlIHRoYXQgYXJlIGVuY29tcGFzc2VkIGJ5IGFu IElTTyA2MzktMyBtYWNyb2xhbmd1YWdlLCBhZGQgdGhlbTxicj5hcyBleHRlbmRlZCBsYW5ndWFn ZSAoZXh0bGFuZykgc3VidGFncywgYW5kIGFkZCB0aGUgb3RoZXIgOTUlIGFzIHByaW1hcnk8YnI+ bGFuZ3VhZ2Ugc3VidGFncz88YnI+PGJyPlRoZSBkaXNjdXNzaW9uIGluIE1hcmNoIHN0YXJ0ZWQg d2l0aCB0aGlzIG1lc3NhZ2UgZnJvbSBNYXJrOgo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dzEuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMDcyODguaHRtbCI+aHR0cDov L3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMDcyODguaHRt bDwvYT48YnI+PGJyPkNoYXNlIHRoZSAmcXVvdDtGb2xsb3ctVXBzJnF1b3Q7IGxpbmtzIHRvIGZv bGxvdyB0aGUgdGhyZWFkLjxicj48YnI+Ck15IHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQga2VlcCB0 aGUgcHJpbWFyeS9leHRsYW5nIHJlbGF0aW9uc2hpcCB0aGF0IHdlIGhhdmU8YnI+YmVlbiBwbGFu bmluZyBzaW5jZSAyMDA0IHRvIHJlZmxlY3QgdGhlIElTTyA2MzktMyBtYWNyb2xhbmd1YWdlPGJy PnJlbGF0aW9uc2hpcC4mbmJzcDsmbmJzcDtJdCBhbGxvd3MgaWRlbnRpZmljYXRpb24gb2YgdGhl IGluZGl2aWR1YWwgbGFuZ3VhZ2VzIHdoaWxlPGJyPgpzdGF5aW5nIGNvbXBhdGlibGUgd2l0aCB0 aGUgd2F5IHBlb3BsZSBoYXZlIHRhZ2dlZCB0aGVtIGluIHRoZSBwYXN0LCBhbmQgaW48YnI+c29t ZSBjYXNlcyB3aXRoIHRoZSB3YXkgcGVvcGxlIHdpbGwgYWx3YXlzIHBlcmNlaXZlIHRoZW0gKGku ZS4gJnF1b3Q7QXJhYmljJnF1b3Q7PGJyPnJhdGhlciB0aGFuIDMwIGRpZmZlcmVudCBmbGF2b3Jz KS4mbmJzcDsmbmJzcDtFeHBlY3RpbmcgbWF0Y2hpbmcgZW5naW5lcyB0byBoYXZlICZxdW90O2EK PGJyPmJpdCBtb3JlIHNtYXJ0cyZxdW90OyBzbyB0aGV5IGNhbiBtYXRjaCAmcXVvdDt5dWUmcXVv dDsgd2l0aCAmcXVvdDt6aCZxdW90OyBkb2VzbiYjMzk7dCB3b3JrIGZvciBtZSB3aGVuPGJyPndl IGNhbiYjMzk7dCBldmVuIGV4cGVjdCB0aGVtIHRvIGJlIHNtYXJ0IGVub3VnaCB0byBtYXRjaCAm cXVvdDtlbi1VUyZxdW90OyB3aXRoPGJyPiZxdW90O2VuLUxhdG4tVVMmcXVvdDsuPGJyPgo8YnI+ QnV0IHRoYXQmIzM5O3MganVzdCBteSB2aWV3LCBhbmQgdGhlIGltcG9ydGFudCB0aGluZyBpcyBm b3IgdGhlIGxpc3QgdG8gZGlzY3Vzczxicj50aGUgbWF0dGVyIGFuZCByZWFjaCBhIGNvbnNlbnN1 cyBzbyB3ZSBjYW4gbW92ZSBmb3J3YXJkLjxicj48YnI+LS08YnI+RG91ZyBFd2VsbCZuYnNwOyZu YnNwOyombmJzcDsmbmJzcDtGdWxsZXJ0b24sIENhbGlmb3JuaWEsIFVTQSZuYnNwOyZuYnNwOyom bmJzcDsmbmJzcDtSRkMgNDY0NSZuYnNwOyZuYnNwOyombmJzcDsmbmJzcDtVVE4gIzE0Cjxicj48 YSBocmVmPSJodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvIj5odHRwOi8vdXNlcnMu YWRlbHBoaWEubmV0L35kZXdlbGwvPC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3MS5pZXRmLm9y Zy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sIj5odHRwOi8vd3d3MS5pZXRmLm9yZy9o dG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sPC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3 LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcyI+Cmh0dHA6Ly93 d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2VzPC9hPjxicj48 YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5NYXJr Cg== ------=_Part_68413_12597298.1182186410744-- --===============1297085007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1297085007==-- From ltru-bounces@ietf.org Mon Jun 18 13:09:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kjd-0004Es-32; Mon, 18 Jun 2007 13:09:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Kjb-0004Ee-NV for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kjb-0004EU-Dm for ltru@ietf.org; Mon, 18 Jun 2007 13:09:47 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KjG-0002M6-T8 for ltru@ietf.org; Mon, 18 Jun 2007 13:09:47 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1374729nzd for ; Mon, 18 Jun 2007 10:09:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YmVSFh1QQvpwkIJumLMXUt2Gs4xQkNGlWCyBN/WQvVyDAHgKNSH3fFbjz1mBv0RZGheqwbznVRTp3r7A33OKRvTwZ3zB//63RL0068wtOKhzVKOI1ypdR/ZYAkeZ1etHPfP5nuUfmIM5MQcmko3IQXMnu64yHl7Ydc8SwuZTOIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NjSJVwJwfepQUpWq6+b966qwBphDZ6Ssf9nKD+I6xaQmQklMMn7mDty/33IBSklgMtF+vWGkkeI4+HElw4DOxxr7EBV28XMrT1RKL61fylLCpcDMHoeK/swWomnPaJ7vih4auy7Qu9U6/CEPWzsHz7pQovnxsHEkMJEqpwi3o/Y= Received: by 10.114.95.1 with SMTP id s1mr6366470wab.1182186565979; Mon, 18 Jun 2007 10:09:25 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 10:09:25 -0700 (PDT) Message-ID: <30b660a20706181009l4b0b4894sffbb8fe7dd1d7fda@mail.gmail.com> Date: Mon, 18 Jun 2007 10:09:25 -0700 From: "Mark Davis" To: "LTRU Working Group" In-Reply-To: <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> MIME-Version: 1.0 References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> X-Google-Sender-Auth: ee814f9a14141863 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , "HHj@standard.no" , "isojac@loc.gov" , "iso639@dkuug.dk" Subject: [Ltru] Fwd: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480124340==" Errors-To: ltru-bounces@ietf.org --===============0480124340== Content-Type: multipart/alternative; boundary="----=_Part_68505_16271073.1182186565930" ------=_Part_68505_16271073.1182186565930 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This got bounced for too many recipients: trying again. MD ---------- Forwarded message ---------- From: Mark Davis Date: Jun 18, 2007 9:23 AM Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis" To: Peter Constable Cc: Kent Karlsson , Milicent K Wewerka < mwew@loc.gov>, John Cowan , "iso639@dkuug.dk" < iso639@dkuug.dk>, "ietf-languages@iana.org" , " iso639-2@loc.gov" , "isojac@loc.gov" , " HHj@standard.no" , LTRU Working Group Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices: 1. Keep the broader semantic, which encompasses the new ISO narrow one, or 2. Deprecate the code (in one way or another). Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice. What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed. Mark On 6/16/07, Peter Constable wrote: > > From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > > > With the "old mis" one could correctly apply 'mis' as a language > > code for any language > > That has *never* been the intent of ISO 639. It is an external > interpretation, admittedly possible because ISO 639 was not fully explicit > up to now. But from the perspective of the JAC, the "new mis" is exactly the > same "mis" as the "old mis". > > > Peter > > -- Mark -- Mark ------=_Part_68505_16271073.1182186565930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This got bounced for too many recipients: trying again. MD

---------- Forwarded message ----------
From: Mark Davis < mark.davis@icu-project.org>
Date: Jun 18, 2007 9:23 AM
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
To: Peter Constable <petercon@microsoft.com >
Cc: Kent Karlsson <kent.karlsson14@comhem.se>, Milicent K Wewerka <mwew@loc.gov>, John Cowan < cowan@ccil.org>, "iso639@dkuug.dk" <iso639@dkuug.dk>, "ietf-languages@iana.org " <ietf-languages@iana.org>, "iso639-2@loc.gov" <iso639-2@loc.gov>, " isojac@loc.gov" <isojac@loc.gov>, "HHj@standard.no" <HHj@standard.no >, LTRU Working Group <ltru@ietf.org>

Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices:

1. Keep the broader semantic, which encompasses the new ISO narrow one, or
2. Deprecate the code (in one way or another).

Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice.

What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed.

Mark


On 6/16/07, Peter Constable <petercon@microsoft.com > wrote:
From: Kent Karlsson [mailto: kent.karlsson14@comhem.se]

> With the "old mis" one could correctly apply 'mis' as a language
> code for any language

That has *never* been the intent of ISO 639. It is an external interpretation, admittedly possible because ISO 639 was not fully explicit up to now. But from the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis".


Peter




--
Mark

--
Mark ------=_Part_68505_16271073.1182186565930-- --===============0480124340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0480124340==-- From ltru-bounces@ietf.org Mon Jun 18 13:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kqk-0005Ey-LO; Mon, 18 Jun 2007 13:17:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Kqi-0005Ef-Uk for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kqi-0005EW-Ks for ltru@ietf.org; Mon, 18 Jun 2007 13:17:08 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Kqh-0004l7-IA for ltru@ietf.org; Mon, 18 Jun 2007 13:17:08 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 18 Jun 2007 10:15:47 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Mon, 18 Jun 2007 10:17:06 -0700 From: Peter Constable To: LTRU Working Group Date: Mon, 18 Jun 2007 10:17:04 -0700 Thread-Topic: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Index: AcexxPslZyJqWBveROWa6SXMDO/00wAAe53A Message-ID: References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> In-Reply-To: <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , "isojac@loc.gov" , "iso639@dkuug.dk" Subject: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1138809770==" Errors-To: ltru-bounces@ietf.org --===============1138809770== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CECA94NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CECA94NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As far as the JAC is concerned, the intentional semantic of "mis" is what i= t has always been. As for the extension, when 639-2 was the only alpha-3 co= de, there was only one context to evaluate the extension that would be deri= ved by that intention; 639-2 did not document the extension, though at leas= t one application of 639-2 - MARC - did. With the introduction of 639-3 and= the pending introduction of 639-5 as additions to the alpha-3 space, it be= comes clear that the extension must be determined within a context: the cas= es where you'd want to use "mis" differ if you're using 639-3 rather than 6= 39-2. But for an application of a given part of 639, the change of referenc= e name has had no effect on the extension for that context: the languages e= ncompassed by "mis" in a 639-2 application, for instance, are the same as t= hey were before. When it comes to BCP 47, the change of reference name for "mis" is basicall= y irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 wi= ll change from being an application of 639-1 and -2 to being an application= of 639-1, -2 and -3. That change of context is what creates the issue wrt = interoperability of "mis" in applications of BCP 47: Under RFC 4646, Burush= aski content would be tagged "mis"; under RFC 4646bis, one would expect new= Burushaski content to be tagged "bsk". There's no basis for matching: that= 's an interop problem. And note that it has nothing to do with stability of= "mis" supposedly introduced with the name change: with or without that cha= nge, Burushaski content would be tagged differently before and after. And note that this issue exists whether one considers "old mis" to have the= semantic that Keld is stuck on, 'all languages', or the semantic that the = JAC has always intended: either way, it is the addition of 639-3 to BCP 47 = that creates an issue for uses of "mis" under BCP 47, not the name change. And even without the addition of 639-3, "mis" would have interop issues: as= suming the semantic the JAC has always assumed, the extension in the contex= t of 639-2 could narrow - inherently by the nature of the semantic - any ti= me a new entry was added; but assuming the 'all languages' semantic, one co= uld end up with comparable content tagged in non-comparable ways, "mis" and= something else. Therefore, I suggest that beating up ISO as not being in tune with the need= s of the IT community is both fruitless and baseless, and is ignoring the f= act that IETF has problems all of its own making. If IETF really wanted to = avoid any stability or interop problems related to "mis", it should never h= ave permitted its use in language tags, starting back in RFC 1766, because = "mis" has always had stability / interop issues. But that horse is long out= of the barn: "mis" *can* be used in language tags under RFCs from 1766 to = 4646. The LTRU WG within IETF needs to decide what to do about that in RFC = 4646bis. That's a job for IETF; we don't need to continue bothering JAC mem= bers with IETF issues. Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, June 18, 2007 9:23 AM To: Peter Constable Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639@dkuug.dk; ietf-la= nguages@iana.org; iso639-2@loc.gov; isojac@loc.gov; HHj@standard.no; LTRU W= orking Group Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis" Unfortunately, ISO codes have somewhat of an impedance mismatch with the ne= eds of the IT community; in particular, stability. Thus BCP 47 has to stabi= lize those codes; one of the main reasons for the existence of RFC 4646. Wh= at that means is that if ISO tries to narrow the meaning of *any* code, whe= ther it is a "clarification" or not, we have really only two choices: 1. Keep the broader semantic, which encompasses the new ISO narrow one, or 2. Deprecate the code (in one way or another). Unlike many other codes, "mis" is one that we can do without, so #2 was a r= easonable choice. What I was trying to come up with language that we could agree on even thou= gh we have very different views on the utility and meaning of 'mis'. It sou= nds like we are ok on the suggested language on the other thread, so I'm ho= ping that we can put "mis" to bed. Mark On 6/16/07, Peter Constable > wrote: From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > With the "old mis" one could correctly apply 'mis' as a language > code for any language That has *never* been the intent of ISO 639. It is an external interpretati= on, admittedly possible because ISO 639 was not fully explicit up to now. B= ut from the perspective of the JAC, the "new mis" is exactly the same "mis"= as the "old mis". Peter -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CECA94NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As far as the JAC is concerned, the intentional semantic of = “mis” is what it has always been. As for the extension, when 639-2 was the only alpha-3 code, there was only one context to evaluate the extension that wou= ld be derived by that intention; 639-2 did not document the extension, though = at least one application of 639-2 – MARC – did. With the introduct= ion of 639-3 and the pending introduction of 639-5 as additions to the alpha-3 spa= ce, it becomes clear that the extension must be determined within a context: the c= ases where you’d want to use “mis” differ if you’re usin= g 639-3 rather than 639-2. But for an application of a given part of 639, the change of reference name has had no effect on the extension for that contex= t: the languages encompassed by “mis” in a 639-2 application, for instance, are the same as they were before.

 

When it comes to BCP 47, the change of reference name for &#= 8220;mis” is basically irrelevant because there is a much bigger issue: in RFC4646bis= , BCP 47 will change from being an application of 639-1 and -2 to being an application of 639-1, -2 and -3. That change of context is what creates the issue wrt interoperability of “mis” in applications of BCP 47: Under RFC 4646, Burushaski content would be tagged “mis”; under= RFC 4646bis, one would expect new Burushaski content to be tagged “bsk= 221;. There’s no basis for matching: that’s an interop problem. And n= ote that it has nothing to do with stability of “mis” supposedly introduced with the name change: with or without that change, Burushaski co= ntent would be tagged differently before and after.

 

And note that this issue exists whether one considers “= ;old mis” to have the semantic that Keld is stuck on, ‘all languages= ’, or the semantic that the JAC has always intended: either way, it is the addition of 639-3 to BCP 47 that creates an issue for uses of “mis= 221; under BCP 47, not the name change.

 

And even without the addition of 639-3, “mis” wo= uld have interop issues: assuming the semantic the JAC has always assumed, the extension in the context of 639-2 could narrow – inherently by the na= ture of the semantic – any time a new entry was added; but assuming the &#= 8216;all languages’ semantic, one could end up with comparable content tagged = in non-comparable ways, “mis” and something else.

 

Therefore, I suggest that beating up ISO as not being in tun= e with the needs of the IT community is both fruitless and baseless, and is ignoring the fact that IETF has problems all of its own making. If IETF rea= lly wanted to avoid any stability or interop problems related to “mis”, it should never have permitted its use in language tags, starting back in RFC = 1766, because “mis” has always had stability / interop issues. But th= at horse is long out of the barn: “mis” *can* be used in language tags under RFCs from 1766 to 4646. The LTRU WG within IETF needs t= o decide what to do about that in RFC 4646bis. That’s a job for IETF; we don&#= 8217;t need to continue bothering JAC members with IETF issues.<= /p>

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639@dkuug.dk; ietf-languages@iana.org; iso639-2@loc.gov; isojac@loc.gov; HHj@standard.no; LTRU Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"

 

Unfortunately, ISO code= s have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices:

1. Keep the broader semantic, which encompasses the new ISO narrow one, or<= br> 2. Deprecate the code (in one way or another).

Unlike many other codes, "mis" is one that we can do without, so = #2 was a reasonable choice.

What I was trying to come up with language that we could agree on even thou= gh we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed.

Mark

On 6/16/07, Peter Constabl= e <petercon@mi= crosoft.com > wrote:

From: Kent Karlsson [ma= ilto: kent.karlsson14@comhem.se]

> With the "old mis" one could correctly apply 'mis' as a lang= uage
> code for any language

That has *never* been the intent of ISO 639. It is an external interpretati= on, admittedly possible because ISO 639 was not fully explicit up to now. But f= rom the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis".


Peter




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4CECA94NAEXMSGC117re_-- --===============1138809770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1138809770==-- From ltru-bounces@ietf.org Mon Jun 18 13:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kx1-00072q-Vb; Mon, 18 Jun 2007 13:23:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Jz8-00058l-QR for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Jz8-00058d-40 for ltru@lists.ietf.org; Mon, 18 Jun 2007 12:21:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Jz6-0007FO-PX for ltru@lists.ietf.org; Mon, 18 Jun 2007 12:21:46 -0400 Received: from [128.9.168.202] (rfc2.isi.edu [128.9.168.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5IGLZOa017651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2007 09:21:35 -0700 (PDT) In-Reply-To: <20070617192652.GA18085@sources.org> References: <20070617192652.GA18085@sources.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E96AC16-3EC4-4259-97BD-E0D0A5A134D3@isi.edu> Content-Transfer-Encoding: 7bit From: Alice Hagens Date: Mon, 18 Jun 2007 09:21:34 -0700 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 18 Jun 2007 13:23:38 -0400 Cc: ltru@lists.ietf.org, Scott Hollenbeck , ietf-provreg@cafax.se, RFC Editor Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane, This was not an error. On 4/3/07, Scott Hollenbeck wrote the following in response to a question from the RFC Editor: >> (3) 3730bis >> Is RFC 3066 referenced purposely? Suggest replacing with (or >> at least >> adding) a reference to 4646 or 4647. >> > > The reference to 3066 is deliberate. It should stay that way. RFC Editor/ah On Jun 17, 2007, at 12:26 PM, Stephane Bortzmeyer wrote: > RFC 4930 has several normative references to RFC 3066. > > RFC 4930 has been approved by the IESG in January 2007 and published > in May 2007. > > RFC 3066 have been obsoleted by RFC 4646 in September 2006, several > months before. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 13:24:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KxU-0007cr-SQ; Mon, 18 Jun 2007 13:24:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0K3o-0005ew-EV for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:26:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K3o-0005em-4m for ltru@lists.ietf.org; Mon, 18 Jun 2007 12:26:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0K3n-0008Em-PX for ltru@lists.ietf.org; Mon, 18 Jun 2007 12:26:36 -0400 Received: from [128.9.168.202] (rfc2.isi.edu [128.9.168.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5IGQRxi019040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2007 09:26:27 -0700 (PDT) In-Reply-To: <046F43A8D79C794FA4733814869CDF0701DE53EA@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0701DE53EA@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06AEABD8-F63A-4E66-9B99-C64D631D49B2@isi.edu> Content-Transfer-Encoding: 7bit From: Alice Hagens Date: Mon, 18 Jun 2007 09:26:26 -0700 To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.752.3) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Mon, 18 Jun 2007 13:24:07 -0400 Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org, rfc-editor@rfc-editor.org Subject: [Ltru] Re: [ietf-provreg] Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Sorry; replied before getting through my mail. RFC Editor/ah On Jun 18, 2007, at 5:39 AM, Hollenbeck, Scott wrote: > After a private exchange with Randy Presuhn of the LTRU working > group I > realized it might be helpful if I provide more info to explain why > 4930 > references 3066 instead of 4646. First, let me confirm that this > wasn't > an oversight. It was a conscious decision made with the > concurrence of > the IESG as we looked at the normative references and the standards > track status of those references. Rationale: > > 1. 4930 is the draft standard version of 3730, updated to document > implementation experience with 3730. 3730 references 3066. The first > drafts of what would become 4930 referenced 3066 before 4646 was > approved and published. Implementers of 3730 and 4930 wrote code per > 3066. > > 2. 3730 and 4930 include a language tag reference because language > tags > are used within XML Schema elements. The October 2004 edition of the > normative XML Schema datatypes reference cites 3066: > > http://www.w3.org/TR/xmlschema-2/#language > > Consistency was thus thought to be a good thing. If this were new > work > I'd agree that 4646 would be the more appropriate reference, but that > would also depend on the XML specifications picking up 4646 as well. > > -Scott- > >> -----Original Message----- >> From: owner-ietf-provreg@cafax.se >> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Stephane Bortzmeyer >> Sent: Sunday, June 17, 2007 3:27 PM >> To: rfc-editor@rfc-editor.org >> Cc: bortzmeyer@nic.fr; ietf-provreg@cafax.se; ltru@lists.ietf.org >> Subject: [ietf-provreg] Small bibliography error in RFC 4930 >> >> RFC 4930 has several normative references to RFC 3066. >> >> RFC 4930 has been approved by the IESG in January 2007 and published >> in May 2007. >> >> RFC 3066 have been obsoleted by RFC 4646 in September 2006, several >> months before. >> _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 13:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Kxo-0008Mj-3E; Mon, 18 Jun 2007 13:24:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0K0Y-0005J7-QF for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K0Y-0005Iz-Gf for ltru@ietf.org; Mon, 18 Jun 2007 12:23:14 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0K0V-0007bM-PL for ltru@ietf.org; Mon, 18 Jun 2007 12:23:14 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2605246wah for ; Mon, 18 Jun 2007 09:23:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gCk9fJmataFfYdhiCSLfX+4u7ABVrpHeccf7v8KfUoMukSkzaYhLH7FUhhw7A0MtwWKHKl71eo9eR9HKU+0gJElHfPV9Jog2P1XD/JENI8a5f4M3DPb/4PguMN35X2pXhEunWaIxf2+ZVRnIZmD1r4/bnlvihD9OmPlvWhqjiDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZKD7xHqN48dADU/YtcLTHibJSHAMDFPEF8el09YNTVvcADGYRRXLNReBLLunaSzAaHY3VhG55v1p6runSP4RWBPld+tvAClTXJz+crYirfvpiMJCnIdQOXUUC1rZoVfcOQVX7DVutOIHbyP+EcTjpueOBd+Hxj4OrPAnqDFz+Uc= Received: by 10.114.161.11 with SMTP id j11mr6377334wae.1182183791166; Mon, 18 Jun 2007 09:23:11 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 09:23:11 -0700 (PDT) Message-ID: <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> Date: Mon, 18 Jun 2007 09:23:11 -0700 From: "Mark Davis" To: "Peter Constable" In-Reply-To: MIME-Version: 1.0 References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> X-Google-Sender-Auth: 5ad7c53fcf2e3c08 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Mon, 18 Jun 2007 13:24:27 -0400 Cc: Milicent K Wewerka , "iso639-2@loc.gov" , "HHj@standard.no" , "isojac@loc.gov" , "ietf-languages@iana.org" , LTRU Working Group , Kent Karlsson , "iso639@dkuug.dk" Subject: [Ltru] Re: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2007450155==" Errors-To: ltru-bounces@ietf.org --===============2007450155== Content-Type: multipart/alternative; boundary="----=_Part_67316_23941165.1182183791074" ------=_Part_67316_23941165.1182183791074 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices: 1. Keep the broader semantic, which encompasses the new ISO narrow one, or 2. Deprecate the code (in one way or another). Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice. What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed. Mark On 6/16/07, Peter Constable wrote: > > From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > > > With the "old mis" one could correctly apply 'mis' as a language > > code for any language > > That has *never* been the intent of ISO 639. It is an external > interpretation, admittedly possible because ISO 639 was not fully explicit > up to now. But from the perspective of the JAC, the "new mis" is exactly the > same "mis" as the "old mis". > > > Peter > > -- Mark ------=_Part_67316_23941165.1182183791074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices:

1. Keep the broader semantic, which encompasses the new ISO narrow one, or
2. Deprecate the code (in one way or another).

Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice.

What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed.

Mark

On 6/16/07, Peter Constable <petercon@microsoft.com > wrote:
From: Kent Karlsson [mailto: kent.karlsson14@comhem.se]

> With the "old mis" one could correctly apply 'mis' as a language
> code for any language

That has *never* been the intent of ISO 639. It is an external interpretation, admittedly possible because ISO 639 was not fully explicit up to now. But from the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis".


Peter




--
Mark ------=_Part_67316_23941165.1182183791074-- --===============2007450155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2007450155==-- From ltru-bounces@ietf.org Mon Jun 18 13:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ky5-0001E9-JA; Mon, 18 Jun 2007 13:24:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0GW8-0006iq-Ix for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 08:39:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GW8-0006ii-9U for ltru@lists.ietf.org; Mon, 18 Jun 2007 08:39:36 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0GW7-0007iX-2O for ltru@lists.ietf.org; Mon, 18 Jun 2007 08:39:36 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id l5ICbCVO014015; Mon, 18 Jun 2007 08:37:12 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 08:39:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 08:39:44 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0701DE53EA@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <20070617192652.GA18085@sources.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Small bibliography error in RFC 4930 Thread-Index: AcexGEXVc2G0+WqvRa2J3AMILHztSQAi9aig From: "Hollenbeck, Scott" To: "Stephane Bortzmeyer" , X-OriginalArrivalTime: 18 Jun 2007 12:39:33.0243 (UTC) FILETIME=[B8DB04B0:01C7B1A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Mon, 18 Jun 2007 13:24:44 -0400 Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org Subject: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org After a private exchange with Randy Presuhn of the LTRU working group I realized it might be helpful if I provide more info to explain why 4930 references 3066 instead of 4646. First, let me confirm that this wasn't an oversight. It was a conscious decision made with the concurrence of the IESG as we looked at the normative references and the standards track status of those references. Rationale: 1. 4930 is the draft standard version of 3730, updated to document implementation experience with 3730. 3730 references 3066. The first drafts of what would become 4930 referenced 3066 before 4646 was approved and published. Implementers of 3730 and 4930 wrote code per 3066. 2. 3730 and 4930 include a language tag reference because language tags are used within XML Schema elements. The October 2004 edition of the normative XML Schema datatypes reference cites 3066: http://www.w3.org/TR/xmlschema-2/#language Consistency was thus thought to be a good thing. If this were new work I'd agree that 4646 would be the more appropriate reference, but that would also depend on the XML specifications picking up 4646 as well. -Scott-=20 > -----Original Message----- > From: owner-ietf-provreg@cafax.se=20 > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Stephane Bortzmeyer > Sent: Sunday, June 17, 2007 3:27 PM > To: rfc-editor@rfc-editor.org > Cc: bortzmeyer@nic.fr; ietf-provreg@cafax.se; ltru@lists.ietf.org > Subject: [ietf-provreg] Small bibliography error in RFC 4930 >=20 > RFC 4930 has several normative references to RFC 3066. >=20 > RFC 4930 has been approved by the IESG in January 2007 and published > in May 2007. >=20 > RFC 3066 have been obsoleted by RFC 4646 in September 2006, several > months before. >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 13:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L12-0006D8-2t; Mon, 18 Jun 2007 13:27:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0L11-0006C0-24 for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L10-0006Br-Og for ltru@lists.ietf.org; Mon, 18 Jun 2007 13:27:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0L0z-0007ZH-Bf for ltru@lists.ietf.org; Mon, 18 Jun 2007 13:27:46 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0Kc6-0007SM-OP for ltru@lists.ietf.org; Mon, 18 Jun 2007 19:02:03 +0200 Received: from dialin-145-254-032-202.pools.arcor-ip.net ([145.254.32.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 19:02:02 +0200 Received: from nobody by dialin-145-254-032-202.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 19:02:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 18:45:11 +0200 Organization: Lines: 36 Message-ID: <4676B697.3CCA@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@localhost> <46766F0B.19B6@xyzzy.claranet.de> <20070618143419.GA25433@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-032-202.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> what-was-it, vlm [recte "vls"] Thanks. > they are two different languages, though closely related and > intertwined in use It would be like deprecating nds in favor > of de-northern. Sometimes I think they're making up languages for non-technical reasons. > fy-DE could never have been more than a hack like zh-TW for > zh-Hant: is it North Frisian, or is it Saterfrisian All you can know is that it's not West Frisian (fy since 2006). For the frr suppress-Latn registration request I tried to find some background info, apparently frr is subdivided into three or more variants. > not to be confused with the variety of nds also called "East > Frisian" Yeah, I made sure that Wikipedia had this right when I was at it about a year ago. > still less with the variety of Standard German (de) spoken > in Ostfriesen I'd guess that that's no language, when nds-folks speak "de" they end up with a rather pure "de". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 16:49:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OAG-0003OR-Dn; Mon, 18 Jun 2007 16:49:32 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0OAF-0003O9-GG for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:49:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OAD-0003Ne-UK for ltru@ietf.org; Mon, 18 Jun 2007 16:49:31 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0OAD-0002KT-58 for ltru@ietf.org; Mon, 18 Jun 2007 16:49:29 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1436856nzd for ; Mon, 18 Jun 2007 13:49:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Xu+f8uA738oLmv2xlxf2QBommRDwtVFjSPOe8uFXVsEVLzflL0JCUXSzsHOMFbeDnvII7emp32AS7KHj5XzKBYFjNWj0ITYM7GQ4Pcs5ZevpKrpqK1pOe2tTdxD/TV5zQhu5Uklk7pDjCM5zc9G6a6oXb0scGwXdl/EPJ4oZLrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZylFFqhNH1bwM+9v+mbV3HyJR8gJY+eRG4vfhH8rawTz2tKi6LicChn9ugtd18CehtQ41kSkM4jUTsGRuiSgAPlPv9nyK/eVqOmk/C0xMjloL92BE1hXTST09X6kV8gqrzcNyOQTQ/N8siUXOWdHvOF0lrux/LEWxTHfD2vNjgU= Received: by 10.115.60.1 with SMTP id n1mr6573666wak.1182199765440; Mon, 18 Jun 2007 13:49:25 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 13:49:24 -0700 (PDT) Message-ID: <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> Date: Mon, 18 Jun 2007 13:49:24 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: MIME-Version: 1.0 References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> X-Google-Sender-Auth: fc916c126f3cacea X-Spam-Score: 0.1 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , LTRU Working Group , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0767631577==" Errors-To: ltru-bounces@ietf.org --===============0767631577== Content-Type: multipart/alternative; boundary="----=_Part_73493_9127944.1182199764734" ------=_Part_73493_9127944.1182199764734 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSByZWFsbHkgZGlkbid0IHdhbnQgdG8gc3RhcnQgYSBmbGFtZSBhYm91dCB0aGlzOyBJJ20gc29y cnkgaWYgd2hhdCBJIHNhaWQKd2FzIGJlIGNvbnNpZGVyZWQgaW5jZW5kaWFyeS4KClRoaXMgd2hv bGUgaXNzdWUgaXMgbm90IHJlYWxseSBjb25uZWN0ZWQgd2l0aCB0aGUgY2hhbmdlIGZyb20gcGFy dCAyIHRvIHBhcnQKMywgYXQgYWxsLiBUYWtlIHlvdXIgZXhhbXBsZTogaXQgaXMgYSBwcm9ibGVt IHdpdGggeW91ciBkZWZpbml0aW9uIG9mICJtaXMiCmluIEJDUCA0NyB3aGV0aGVyICJicmsiIHdl cmUgYWRkZWQgYmVjYXVzZSBvZiA2MzktMyBPUiBqdXN0IGJlY2F1c2UgaXQgd2VyZQphZGRlZCB0 byBJU08gNjM5LTIhIEl0IGlzIGFuIGlzc3VlIHdoZW5ldmVyIG5ldyBjb2RlcyBjb3VsZCBiZSBh ZGRlZCB0aGF0CndvdWxkIGludmFsaWRhdGUgcHJldmlvdXMgdXNhZ2Ugb2YgIm1pcyIuCgpBbmQg dGhlIHNhZCB0aGluZyBpcyB0aGF0IHRoaXMgaW5zdGFiaWxpdHkgaW4gSVNPIGNvZGVzIGlzIGNv bXBsZXRlbHkKYXZvaWRhYmxlLiBUaGVyZSBpcyBhIHBlcmZlY3RseSBnb29kIHdheSB0byBoYXZl IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkKKndpdGhvdXQqIGJlaW5nIHVuc3RhYmxlLgoKICAgLSBI YXZlIGEgY29kZSBJJ2xsIGNhbGwgaGVyZSAicm9vdCIgKHRvIGF2b2lkIGFueSBtaXN1bmRlcnN0 YW5kaW5nCiAgIGFib3V0IHRoZSBtZWFuaW5nIG9mICJtaXMiLikKICAgLSBIYXZlIGl0IGJlIHZh bGlkIHRvIHRhZyBhbnkgbGFuZ3VhZ2UgY29udGVudCB3aXRoICJyb290Ii4KICAgLSBTdGF0ZSB0 aGF0IG9uZSBTSE9VTEQgdGFnIGFzIG5hcnJvd2x5IGFzIHBvc3NpYmxlLCB0aHVzIGF2b2lkICJy b290IgogICBpZiB0aGVyZSBpcyBhIG1vcmUgc3BlY2lmaWMgbGFuZ3VhZ2UgY29kZS4KClRoaXMg Y29tcGxldGVseSB0YWtlcyB0aGUgcGxhY2Ugb2YgdGhlIG5lZWQgeW91IHNlZSBmb3IgIm1pcyIs ICp3aXRob3V0CmJlaW5nIHVuc3RhYmxlKi4gSWYgSSBoYXZlIHNvbWUgQnVydXNoYXNraSBjb250 ZW50LCB3aGVyZSBhIGNvZGUgZG9lc24ndApleGlzdCwgSSB0YWcgaXQgd2l0aCAicm9vdCIuIFRo YXQgaXMgdmFsaWQgbm93LCBhbmQgcmVtYWlucyB2YWxpZCBmb3JldmVyLApldmVuIG9uY2UgImJy ayIgaXMgYWRkZWQgLS0gd2hldGhlciAiYnJrIiB3ZXJlIGFkZGVkIGJlY2F1c2Ugb2YgNjM5LTMg b3IKanVzdCBiZWNhdXNlIGl0IHdlcmUgYWRkZWQgdG8gSVNPIDYzOS0yLgoKTWFyawoKT24gNi8x OC8wNywgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToKPgo+ ICBBcyBmYXIgYXMgdGhlIEpBQyBpcyBjb25jZXJuZWQsIHRoZSBpbnRlbnRpb25hbCBzZW1hbnRp YyBvZiAibWlzIiBpcyB3aGF0Cj4gaXQgaGFzIGFsd2F5cyBiZWVuLiBBcyBmb3IgdGhlIGV4dGVu c2lvbiwgd2hlbiA2MzktMiB3YXMgdGhlIG9ubHkgYWxwaGEtMwo+IGNvZGUsIHRoZXJlIHdhcyBv bmx5IG9uZSBjb250ZXh0IHRvIGV2YWx1YXRlIHRoZSBleHRlbnNpb24gdGhhdCB3b3VsZCBiZQo+ IGRlcml2ZWQgYnkgdGhhdCBpbnRlbnRpb247IDYzOS0yIGRpZCBub3QgZG9jdW1lbnQgdGhlIGV4 dGVuc2lvbiwgdGhvdWdoIGF0Cj4gbGVhc3Qgb25lIGFwcGxpY2F0aW9uIG9mIDYzOS0yIOKAkyBN QVJDIOKAkyBkaWQuIFdpdGggdGhlIGludHJvZHVjdGlvbiBvZiA2MzktMwo+IGFuZCB0aGUgcGVu ZGluZyBpbnRyb2R1Y3Rpb24gb2YgNjM5LTUgYXMgYWRkaXRpb25zIHRvIHRoZSBhbHBoYS0zIHNw YWNlLCBpdAo+IGJlY29tZXMgY2xlYXIgdGhhdCB0aGUgZXh0ZW5zaW9uIG11c3QgYmUgZGV0ZXJt aW5lZCB3aXRoaW4gYSBjb250ZXh0OiB0aGUKPiBjYXNlcyB3aGVyZSB5b3UnZCB3YW50IHRvIHVz ZSAibWlzIiBkaWZmZXIgaWYgeW91J3JlIHVzaW5nIDYzOS0zIHJhdGhlciB0aGFuCj4gNjM5LTIu IEJ1dCBmb3IgYW4gYXBwbGljYXRpb24gb2YgYSBnaXZlbiBwYXJ0IG9mIDYzOSwgdGhlIGNoYW5n ZSBvZgo+IHJlZmVyZW5jZSBuYW1lIGhhcyBoYWQgbm8gZWZmZWN0IG9uIHRoZSBleHRlbnNpb24g Zm9yIHRoYXQgY29udGV4dDogdGhlCj4gbGFuZ3VhZ2VzIGVuY29tcGFzc2VkIGJ5ICJtaXMiIGlu IGEgNjM5LTIgYXBwbGljYXRpb24sIGZvciBpbnN0YW5jZSwgYXJlIHRoZQo+IHNhbWUgYXMgdGhl eSB3ZXJlIGJlZm9yZS4KPgo+Cj4KPiBXaGVuIGl0IGNvbWVzIHRvIEJDUCA0NywgdGhlIGNoYW5n ZSBvZiByZWZlcmVuY2UgbmFtZSBmb3IgIm1pcyIgaXMKPiBiYXNpY2FsbHkgaXJyZWxldmFudCBi ZWNhdXNlIHRoZXJlIGlzIGEgbXVjaCBiaWdnZXIgaXNzdWU6IGluIFJGQzQ2NDZiaXMsCj4gQkNQ IDQ3IHdpbGwgY2hhbmdlIGZyb20gYmVpbmcgYW4gYXBwbGljYXRpb24gb2YgNjM5LTEgYW5kIC0y IHRvIGJlaW5nIGFuCj4gYXBwbGljYXRpb24gb2YgNjM5LTEsIC0yIGFuZCAtMy4gVGhhdCBjaGFu Z2Ugb2YgY29udGV4dCBpcyB3aGF0IGNyZWF0ZXMgdGhlCj4gaXNzdWUgd3J0IGludGVyb3BlcmFi aWxpdHkgb2YgIm1pcyIgaW4gYXBwbGljYXRpb25zIG9mIEJDUCA0NzogVW5kZXIgUkZDCj4gNDY0 NiwgQnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRhZ2dlZCAibWlzIjsgdW5kZXIgUkZDIDQ2 NDZiaXMsIG9uZSB3b3VsZAo+IGV4cGVjdCBuZXcgQnVydXNoYXNraSBjb250ZW50IHRvIGJlIHRh Z2dlZCAiYnNrIi4gVGhlcmUncyBubyBiYXNpcyBmb3IKPiBtYXRjaGluZzogdGhhdCdzIGFuIGlu dGVyb3AgcHJvYmxlbS4gQW5kIG5vdGUgdGhhdCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoCj4g c3RhYmlsaXR5IG9mICJtaXMiIHN1cHBvc2VkbHkgaW50cm9kdWNlZCB3aXRoIHRoZSBuYW1lIGNo YW5nZTogd2l0aCBvcgo+IHdpdGhvdXQgdGhhdCBjaGFuZ2UsIEJ1cnVzaGFza2kgY29udGVudCB3 b3VsZCBiZSB0YWdnZWQgZGlmZmVyZW50bHkgYmVmb3JlCj4gYW5kIGFmdGVyLgo+Cj4KPgo+IEFu ZCBub3RlIHRoYXQgdGhpcyBpc3N1ZSBleGlzdHMgd2hldGhlciBvbmUgY29uc2lkZXJzICJvbGQg bWlzIiB0byBoYXZlCj4gdGhlIHNlbWFudGljIHRoYXQgS2VsZCBpcyBzdHVjayBvbiwgJ2FsbCBs YW5ndWFnZXMnLCBvciB0aGUgc2VtYW50aWMgdGhhdAo+IHRoZSBKQUMgaGFzIGFsd2F5cyBpbnRl bmRlZDogZWl0aGVyIHdheSwgaXQgaXMgdGhlIGFkZGl0aW9uIG9mIDYzOS0zIHRvIEJDUAo+IDQ3 IHRoYXQgY3JlYXRlcyBhbiBpc3N1ZSBmb3IgdXNlcyBvZiAibWlzIiB1bmRlciBCQ1AgNDcsIG5v dCB0aGUgbmFtZQo+IGNoYW5nZS4KPgo+Cj4KPiBBbmQgZXZlbiB3aXRob3V0IHRoZSBhZGRpdGlv biBvZiA2MzktMywgIm1pcyIgd291bGQgaGF2ZSBpbnRlcm9wIGlzc3VlczoKPiBhc3N1bWluZyB0 aGUgc2VtYW50aWMgdGhlIEpBQyBoYXMgYWx3YXlzIGFzc3VtZWQsIHRoZSBleHRlbnNpb24gaW4g dGhlCj4gY29udGV4dCBvZiA2MzktMiBjb3VsZCBuYXJyb3cg4oCTIGluaGVyZW50bHkgYnkgdGhl IG5hdHVyZSBvZiB0aGUgc2VtYW50aWMg4oCTCj4gYW55IHRpbWUgYSBuZXcgZW50cnkgd2FzIGFk ZGVkOyBidXQgYXNzdW1pbmcgdGhlICdhbGwgbGFuZ3VhZ2VzJyBzZW1hbnRpYywKPiBvbmUgY291 bGQgZW5kIHVwIHdpdGggY29tcGFyYWJsZSBjb250ZW50IHRhZ2dlZCBpbiBub24tY29tcGFyYWJs ZSB3YXlzLAo+ICJtaXMiIGFuZCBzb21ldGhpbmcgZWxzZS4KPgo+Cj4KPiBUaGVyZWZvcmUsIEkg c3VnZ2VzdCB0aGF0IGJlYXRpbmcgdXAgSVNPIGFzIG5vdCBiZWluZyBpbiB0dW5lIHdpdGggdGhl Cj4gbmVlZHMgb2YgdGhlIElUIGNvbW11bml0eSBpcyBib3RoIGZydWl0bGVzcyBhbmQgYmFzZWxl c3MsIGFuZCBpcyBpZ25vcmluZwo+IHRoZSBmYWN0IHRoYXQgSUVURiBoYXMgcHJvYmxlbXMgYWxs IG9mIGl0cyBvd24gbWFraW5nLiBJZiBJRVRGIHJlYWxseSB3YW50ZWQKPiB0byBhdm9pZCBhbnkg c3RhYmlsaXR5IG9yIGludGVyb3AgcHJvYmxlbXMgcmVsYXRlZCB0byAibWlzIiwgaXQgc2hvdWxk IG5ldmVyCj4gaGF2ZSBwZXJtaXR0ZWQgaXRzIHVzZSBpbiBsYW5ndWFnZSB0YWdzLCBzdGFydGlu ZyBiYWNrIGluIFJGQyAxNzY2LCBiZWNhdXNlCj4gIm1pcyIgaGFzIGFsd2F5cyBoYWQgc3RhYmls aXR5IC8gaW50ZXJvcCBpc3N1ZXMuIEJ1dCB0aGF0IGhvcnNlIGlzIGxvbmcgb3V0Cj4gb2YgdGhl IGJhcm46ICJtaXMiICoqY2FuKiogYmUgdXNlZCBpbiBsYW5ndWFnZSB0YWdzIHVuZGVyIFJGQ3Mg ZnJvbSAxNzY2Cj4gdG8gNDY0Ni4gVGhlIExUUlUgV0cgd2l0aGluIElFVEYgbmVlZHMgdG8gZGVj aWRlIHdoYXQgdG8gZG8gYWJvdXQgdGhhdCBpbgo+IFJGQyA0NjQ2YmlzLiBUaGF0J3MgYSBqb2Ig Zm9yIElFVEY7IHdlIGRvbid0IG5lZWQgdG8gY29udGludWUgYm90aGVyaW5nIEpBQwo+IG1lbWJl cnMgd2l0aCBJRVRGIGlzc3Vlcy4KPgo+Cj4KPgo+Cj4gUGV0ZXIKPgo+Cj4KPiAqRnJvbToqIG1h cmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSBbbWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWls LmNvbV0gKk9uCj4gQmVoYWxmIE9mICpNYXJrIERhdmlzCj4gKlNlbnQ6KiBNb25kYXksIEp1bmUg MTgsIDIwMDcgOToyMyBBTQo+ICpUbzoqIFBldGVyIENvbnN0YWJsZQo+ICpDYzoqIEtlbnQgS2Fy bHNzb247IE1pbGljZW50IEsgV2V3ZXJrYTsgSm9obiBDb3dhbjsgaXNvNjM5QGRrdXVnLmRrOwo+ IGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnOyBpc282MzktMkBsb2MuZ292OyBpc29qYWNAbG9jLmdv djsgSEhqQHN0YW5kYXJkLm5vOwo+IExUUlUgV29ya2luZyBHcm91cAo+ICpTdWJqZWN0OiogUmU6 IChpc282MzkuMjcwOCkgUkU6IElTTyA2MzktMiBkZWNpc2lvbjogIm1pcyIKPgo+Cj4KPiBVbmZv cnR1bmF0ZWx5LCBJU08gY29kZXMgaGF2ZSBzb21ld2hhdCBvZiBhbiBpbXBlZGFuY2UgbWlzbWF0 Y2ggd2l0aCB0aGUKPiBuZWVkcyBvZiB0aGUgSVQgY29tbXVuaXR5OyBpbiBwYXJ0aWN1bGFyLCBz dGFiaWxpdHkuIFRodXMgQkNQIDQ3IGhhcyB0bwo+IHN0YWJpbGl6ZSB0aG9zZSBjb2Rlczsgb25l IG9mIHRoZSBtYWluIHJlYXNvbnMgZm9yIHRoZSBleGlzdGVuY2Ugb2YgUkZDCj4gNDY0Ni4gV2hh dCB0aGF0IG1lYW5zIGlzIHRoYXQgaWYgSVNPIHRyaWVzIHRvIG5hcnJvdyB0aGUgbWVhbmluZyBv ZiAqYW55Kgo+IGNvZGUsIHdoZXRoZXIgaXQgaXMgYSAiY2xhcmlmaWNhdGlvbiIgb3Igbm90LCB3 ZSBoYXZlIHJlYWxseSBvbmx5IHR3bwo+IGNob2ljZXM6Cj4KPiAxLiBLZWVwIHRoZSBicm9hZGVy IHNlbWFudGljLCB3aGljaCBlbmNvbXBhc3NlcyB0aGUgbmV3IElTTyBuYXJyb3cgb25lLCBvcgo+ IDIuIERlcHJlY2F0ZSB0aGUgY29kZSAoaW4gb25lIHdheSBvciBhbm90aGVyKS4KPgo+IFVubGlr ZSBtYW55IG90aGVyIGNvZGVzLCAibWlzIiBpcyBvbmUgdGhhdCB3ZSBjYW4gZG8gd2l0aG91dCwg c28gIzIgd2FzIGEKPiByZWFzb25hYmxlIGNob2ljZS4KPgo+IFdoYXQgSSB3YXMgdHJ5aW5nIHRv IGNvbWUgdXAgd2l0aCBsYW5ndWFnZSB0aGF0IHdlIGNvdWxkIGFncmVlIG9uIGV2ZW4KPiB0aG91 Z2ggd2UgaGF2ZSB2ZXJ5IGRpZmZlcmVudCB2aWV3cyBvbiB0aGUgdXRpbGl0eSBhbmQgbWVhbmlu ZyBvZiAnbWlzJy4gSXQKPiBzb3VuZHMgbGlrZSB3ZSBhcmUgb2sgb24gdGhlIHN1Z2dlc3RlZCBs YW5ndWFnZSBvbiB0aGUgb3RoZXIgdGhyZWFkLCBzbyBJJ20KPiBob3BpbmcgdGhhdCB3ZSBjYW4g cHV0ICJtaXMiIHRvIGJlZC4KPgo+IE1hcmsKPgo+IE9uIDYvMTYvMDcsICpQZXRlciBDb25zdGFi bGUqIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tID4gd3JvdGU6Cj4KPiBGcm9tOiBLZW50IEthcmxz c29uIFttYWlsdG86IGtlbnQua2FybHNzb24xNEBjb21oZW0uc2VdCj4KPiA+IFdpdGggdGhlICJv bGQgbWlzIiBvbmUgY291bGQgY29ycmVjdGx5IGFwcGx5ICdtaXMnIGFzIGEgbGFuZ3VhZ2UKPiA+ IGNvZGUgZm9yIGFueSBsYW5ndWFnZQo+Cj4gVGhhdCBoYXMgKm5ldmVyKiBiZWVuIHRoZSBpbnRl bnQgb2YgSVNPIDYzOS4gSXQgaXMgYW4gZXh0ZXJuYWwKPiBpbnRlcnByZXRhdGlvbiwgYWRtaXR0 ZWRseSBwb3NzaWJsZSBiZWNhdXNlIElTTyA2Mzkgd2FzIG5vdCBmdWxseSBleHBsaWNpdAo+IHVw IHRvIG5vdy4gQnV0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBKQUMsIHRoZSAibmV3IG1p cyIgaXMgZXhhY3RseSB0aGUKPiBzYW1lICJtaXMiIGFzIHRoZSAib2xkIG1pcyIuCj4KPgo+IFBl dGVyCj4KPgo+Cj4KPiAtLQo+IE1hcmsKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cj4KCgotLSAKTWFy awo= ------=_Part_73493_9127944.1182199764734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGZvbnQgc2l6ZT0iMiI+SSByZWFsbHkgZGlkbiYjMzk7dCB3YW50IHRvIHN0YXJ0IGEgZmxhbWUg YWJvdXQgdGhpczsgSSYjMzk7bSBzb3JyeSBpZiB3aGF0IEkgc2FpZCB3YXMgYmUgY29uc2lkZXJl ZCBpbmNlbmRpYXJ5Ljxicj48YnI+VGhpcyB3aG9sZSBpc3N1ZSBpcyBub3QgcmVhbGx5IGNvbm5l Y3RlZCB3aXRoIHRoZSBjaGFuZ2UgZnJvbSBwYXJ0IDIgdG8gcGFydCAzLCBhdCBhbGwuIFRha2Ug eW91ciBleGFtcGxlOiBpdCBpcyBhIHByb2JsZW0gd2l0aCB5b3VyIGRlZmluaXRpb24gb2YgJnF1 b3Q7bWlzJnF1b3Q7IGluIEJDUCA0NyB3aGV0aGVyIAo8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+JnF1 b3Q7YnJrJnF1b3Q7IHdlcmUgYWRkZWQgYmVjYXVzZSBvZiA2MzktMyBPUiBqdXN0IGJlY2F1c2Ug aXQgd2VyZSBhZGRlZCB0byBJU08gNjM5LTIhPC9mb250Pjxmb250IHNpemU9IjIiPiBJdCBpcyBh biBpc3N1ZSB3aGVuZXZlciBuZXcgY29kZXMgY291bGQgYmUgYWRkZWQgdGhhdCB3b3VsZCBpbnZh bGlkYXRlIHByZXZpb3VzIHVzYWdlIG9mICZxdW90O21pcyZxdW90Oy4KPGJyPjxicj5BbmQgdGhl IHNhZCB0aGluZyBpcyB0aGF0IHRoaXMgaW5zdGFiaWxpdHkgaW4gSVNPIGNvZGVzIGlzIGNvbXBs ZXRlbHkgYXZvaWRhYmxlLiBUaGVyZSBpcyBhIHBlcmZlY3RseSBnb29kIHdheSB0byBoYXZlIHRo ZSBzYW1lIGZ1bmN0aW9uYWxpdHkgKndpdGhvdXQqIGJlaW5nIHVuc3RhYmxlLiA8YnI+PC9mb250 Pjx1bD48bGk+PGZvbnQgc2l6ZT0iMiI+SGF2ZSBhIGNvZGUgSSYjMzk7bGwgY2FsbCBoZXJlICZx dW90O3Jvb3QmcXVvdDsgKHRvIGF2b2lkIGFueSBtaXN1bmRlcnN0YW5kaW5nIGFib3V0IHRoZSBt ZWFuaW5nIG9mICZxdW90O21pcyZxdW90Oy4pCjwvZm9udD48L2xpPjxsaT48Zm9udCBzaXplPSIy Ij5IYXZlIGl0IGJlIHZhbGlkIHRvIHRhZyBhbnkgbGFuZ3VhZ2UgY29udGVudCB3aXRoICZxdW90 O3Jvb3QmcXVvdDsuPC9mb250PjwvbGk+PGxpPjxmb250IHNpemU9IjIiPlN0YXRlIHRoYXQgb25l IFNIT1VMRCB0YWcgYXMgbmFycm93bHkgYXMgcG9zc2libGUsIHRodXMgYXZvaWQgJnF1b3Q7cm9v dCZxdW90OyBpZiB0aGVyZSBpcyBhIG1vcmUgc3BlY2lmaWMgbGFuZ3VhZ2UgY29kZS4KPGJyPjwv Zm9udD48L2xpPjwvdWw+PGZvbnQgc2l6ZT0iMiI+VGhpcyBjb21wbGV0ZWx5IHRha2VzIHRoZSBw bGFjZSBvZiB0aGUgbmVlZCB5b3Ugc2VlIGZvciAmcXVvdDttaXMmcXVvdDssICp3aXRob3V0IGJl aW5nIHVuc3RhYmxlKi4gSWYgSSBoYXZlIHNvbWUgPC9mb250PjxzcGFuPkJ1cnVzaGFza2kgPC9z cGFuPjxmb250IHNpemU9IjIiPmNvbnRlbnQsIHdoZXJlIGEgY29kZSBkb2VzbiYjMzk7dCBleGlz dCwgSSB0YWcgaXQgd2l0aCAmcXVvdDtyb290JnF1b3Q7LiBUaGF0IGlzIHZhbGlkIG5vdywgYW5k IHJlbWFpbnMgdmFsaWQgZm9yZXZlciwgZXZlbiBvbmNlICZxdW90O2JyayZxdW90OyBpcyBhZGRl ZCAtLSB3aGV0aGVyICZxdW90O2JyayZxdW90OyB3ZXJlIGFkZGVkIGJlY2F1c2Ugb2YgNjM5LTMg b3IganVzdCBiZWNhdXNlIGl0IHdlcmUgYWRkZWQgdG8gSVNPIDYzOS0yLgo8YnI+PGJyPk1hcms8 YnI+PGJyPjwvZm9udD48ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gNi8xOC8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBldGVyIENvbnN0YWJs ZTwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIj5wZXRlcmNv bkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8L2ZvbnQ+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0 LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyI+CgoKCgoKCgoKPGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+ Cgo8ZGl2PgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BcyBmYXIgYXMgdGhlIEpBQyBpcyBjb25jZXJuZWQs IHRoZSBpbnRlbnRpb25hbCBzZW1hbnRpYyBvZiAibWlzIgppcyB3aGF0IGl0IGhhcyBhbHdheXMg YmVlbi4gQXMgZm9yIHRoZSBleHRlbnNpb24sIHdoZW4gNjM5LTIgd2FzIHRoZSBvbmx5CmFscGhh LTMgY29kZSwgdGhlcmUgd2FzIG9ubHkgb25lIGNvbnRleHQgdG8gZXZhbHVhdGUgdGhlIGV4dGVu c2lvbiB0aGF0IHdvdWxkCmJlIGRlcml2ZWQgYnkgdGhhdCBpbnRlbnRpb247IDYzOS0yIGRpZCBu b3QgZG9jdW1lbnQgdGhlIGV4dGVuc2lvbiwgdGhvdWdoIGF0CmxlYXN0IG9uZSBhcHBsaWNhdGlv biBvZiA2MzktMiDigJMgTUFSQyDigJMgZGlkLiBXaXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YKNjM5 LTMgYW5kIHRoZSBwZW5kaW5nIGludHJvZHVjdGlvbiBvZiA2MzktNSBhcyBhZGRpdGlvbnMgdG8g dGhlIGFscGhhLTMgc3BhY2UsIGl0CmJlY29tZXMgY2xlYXIgdGhhdCB0aGUgZXh0ZW5zaW9uIG11 c3QgYmUgZGV0ZXJtaW5lZCB3aXRoaW4gYSBjb250ZXh0OiB0aGUgY2FzZXMKd2hlcmUgeW91J2Qg d2FudCB0byB1c2UgIm1pcyIgZGlmZmVyIGlmIHlvdSdyZSB1c2luZwo2MzktMyByYXRoZXIgdGhh biA2MzktMi4gQnV0IGZvciBhbiBhcHBsaWNhdGlvbiBvZiBhIGdpdmVuIHBhcnQgb2YgNjM5LCB0 aGUKY2hhbmdlIG9mIHJlZmVyZW5jZSBuYW1lIGhhcyBoYWQgbm8gZWZmZWN0IG9uIHRoZSBleHRl bnNpb24gZm9yIHRoYXQgY29udGV4dDoKdGhlIGxhbmd1YWdlcyBlbmNvbXBhc3NlZCBieSAibWlz IiBpbiBhIDYzOS0yIGFwcGxpY2F0aW9uLCBmb3IKaW5zdGFuY2UsIGFyZSB0aGUgc2FtZSBhcyB0 aGV5IHdlcmUgYmVmb3JlLjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+V2hlbiBpdCBjb21lcyB0byBC Q1AgNDcsIHRoZSBjaGFuZ2Ugb2YgcmVmZXJlbmNlIG5hbWUgZm9yICJtaXMiCmlzIGJhc2ljYWxs eSBpcnJlbGV2YW50IGJlY2F1c2UgdGhlcmUgaXMgYSBtdWNoIGJpZ2dlciBpc3N1ZTogaW4gUkZD NDY0NmJpcywKQkNQIDQ3IHdpbGwgY2hhbmdlIGZyb20gYmVpbmcgYW4gYXBwbGljYXRpb24gb2Yg NjM5LTEgYW5kIC0yIHRvIGJlaW5nIGFuCmFwcGxpY2F0aW9uIG9mIDYzOS0xLCAtMiBhbmQgLTMu IFRoYXQgY2hhbmdlIG9mIGNvbnRleHQgaXMgd2hhdCBjcmVhdGVzIHRoZQppc3N1ZSB3cnQgaW50 ZXJvcGVyYWJpbGl0eSBvZiAibWlzIiBpbiBhcHBsaWNhdGlvbnMgb2YgQkNQIDQ3OgpVbmRlciBS RkMgNDY0NiwgQnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRhZ2dlZCAibWlzIjsgdW5kZXIg UkZDCjQ2NDZiaXMsIG9uZSB3b3VsZCBleHBlY3QgbmV3IEJ1cnVzaGFza2kgY29udGVudCB0byBi ZSB0YWdnZWQgImJzayIuClRoZXJlJ3Mgbm8gYmFzaXMgZm9yIG1hdGNoaW5nOiB0aGF0J3MgYW4g aW50ZXJvcCBwcm9ibGVtLiBBbmQgbm90ZQp0aGF0IGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGgg c3RhYmlsaXR5IG9mICJtaXMiIHN1cHBvc2VkbHkKaW50cm9kdWNlZCB3aXRoIHRoZSBuYW1lIGNo YW5nZTogd2l0aCBvciB3aXRob3V0IHRoYXQgY2hhbmdlLCBCdXJ1c2hhc2tpIGNvbnRlbnQKd291 bGQgYmUgdGFnZ2VkIGRpZmZlcmVudGx5IGJlZm9yZSBhbmQgYWZ0ZXIuIDwvc3Bhbj48L2ZvbnQ+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+QW5kIG5vdGUgdGhhdCB0aGlzIGlzc3VlIGV4aXN0cyB3aGV0aGVyIG9uZSBjb25z aWRlcnMgIm9sZAptaXMiIHRvIGhhdmUgdGhlIHNlbWFudGljIHRoYXQgS2VsZCBpcyBzdHVjayBv biwgJ2FsbCBsYW5ndWFnZXMnLApvciB0aGUgc2VtYW50aWMgdGhhdCB0aGUgSkFDIGhhcyBhbHdh eXMgaW50ZW5kZWQ6IGVpdGhlciB3YXksIGl0IGlzIHRoZQphZGRpdGlvbiBvZiA2MzktMyB0byBC Q1AgNDcgdGhhdCBjcmVhdGVzIGFuIGlzc3VlIGZvciB1c2VzIG9mICJtaXMiCnVuZGVyIEJDUCA0 Nywgbm90IHRoZSBuYW1lIGNoYW5nZS4gPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BbmQgZXZlbiB3 aXRob3V0IHRoZSBhZGRpdGlvbiBvZiA2MzktMywgIm1pcyIgd291bGQKaGF2ZSBpbnRlcm9wIGlz c3VlczogYXNzdW1pbmcgdGhlIHNlbWFudGljIHRoZSBKQUMgaGFzIGFsd2F5cyBhc3N1bWVkLCB0 aGUKZXh0ZW5zaW9uIGluIHRoZSBjb250ZXh0IG9mIDYzOS0yIGNvdWxkIG5hcnJvdyDigJMgaW5o ZXJlbnRseSBieSB0aGUgbmF0dXJlCm9mIHRoZSBzZW1hbnRpYyDigJMgYW55IHRpbWUgYSBuZXcg ZW50cnkgd2FzIGFkZGVkOyBidXQgYXNzdW1pbmcgdGhlICdhbGwKbGFuZ3VhZ2VzJyBzZW1hbnRp Yywgb25lIGNvdWxkIGVuZCB1cCB3aXRoIGNvbXBhcmFibGUgY29udGVudCB0YWdnZWQgaW4Kbm9u LWNvbXBhcmFibGUgd2F5cywgIm1pcyIgYW5kIHNvbWV0aGluZyBlbHNlLjwvc3Bhbj48L2ZvbnQ+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+VGhlcmVmb3JlLCBJIHN1Z2dlc3QgdGhhdCBiZWF0aW5nIHVwIElTTyBhcyBub3Qg YmVpbmcgaW4gdHVuZQp3aXRoIHRoZSBuZWVkcyBvZiB0aGUgSVQgY29tbXVuaXR5IGlzIGJvdGgg ZnJ1aXRsZXNzIGFuZCBiYXNlbGVzcywgYW5kIGlzCmlnbm9yaW5nIHRoZSBmYWN0IHRoYXQgSUVU RiBoYXMgcHJvYmxlbXMgYWxsIG9mIGl0cyBvd24gbWFraW5nLiBJZiBJRVRGIHJlYWxseSB3YW50 ZWQKdG8gYXZvaWQgYW55IHN0YWJpbGl0eSBvciBpbnRlcm9wIHByb2JsZW1zIHJlbGF0ZWQgdG8g Im1pcyIsIGl0CnNob3VsZCBuZXZlciBoYXZlIHBlcm1pdHRlZCBpdHMgdXNlIGluIGxhbmd1YWdl IHRhZ3MsIHN0YXJ0aW5nIGJhY2sgaW4gUkZDIDE3NjYsCmJlY2F1c2UgIm1pcyIgaGFzIGFsd2F5 cyBoYWQgc3RhYmlsaXR5IC8gaW50ZXJvcCBpc3N1ZXMuIEJ1dCB0aGF0CmhvcnNlIGlzIGxvbmcg b3V0IG9mIHRoZSBiYXJuOiAibWlzIiAqPGI+Y2FuPC9iPiogYmUgdXNlZCBpbgpsYW5ndWFnZSB0 YWdzIHVuZGVyIFJGQ3MgZnJvbSAxNzY2IHRvIDQ2NDYuIFRoZSBMVFJVIFdHIHdpdGhpbiBJRVRG IG5lZWRzIHRvIGRlY2lkZQp3aGF0IHRvIGRvIGFib3V0IHRoYXQgaW4gUkZDIDQ2NDZiaXMuIFRo YXQncyBhIGpvYiBmb3IgSUVURjsgd2UgZG9uJ3QKbmVlZCB0byBjb250aW51ZSBib3RoZXJpbmcg SkFDIG1lbWJlcnMgd2l0aCBJRVRGIGlzc3Vlcy48L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5QZXRlcjwvc3Bhbj48L2ZvbnQ+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxkaXYgc3R5 bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItY29sb3I6IHJnYigxODEs IDE5NiwgMjIzKSAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3I7IGJvcmRl ci13aWR0aDogMXB0IG1lZGl1bSBtZWRpdW07IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+Cgo8cD48 Zm9udCBzaXplPSIyIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij4KPGEgaHJlZj0ibWFpbHRvOm1h cmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5tYXJrLmVkd2FyZC5kYXZp c0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlz QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tPC9h Pl0gPGI+T24gQmVoYWxmCk9mIDwvYj5NYXJrIERhdmlzPGJyPgo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBKdW5lIDE4LCAyMDA3IDk6MjMgQU08YnI+CjxiPlRvOjwvYj4gUGV0ZXIgQ29uc3RhYmxlPGJy Pgo8Yj5DYzo8L2I+IEtlbnQgS2FybHNzb247IE1pbGljZW50IEsgV2V3ZXJrYTsgSm9obiBDb3dh bjsgPGEgaHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1Zy5kayIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5pc282MzlA ZGt1dWcuZGs8L2E+Owo8YSBocmVmPSJtYWlsdG86aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 aXNvNjM5LTJAbG9jLmdvdiIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KaXNvNjM5LTJAbG9jLmdvdjwvYT47IDxh IGhyZWY9Im1haWx0bzppc29qYWNAbG9jLmdvdiIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5pc29qYWNAbG9jLmdv djwvYT47IDxhIGhyZWY9Im1haWx0bzpISGpAc3RhbmRhcmQubm8iIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CkhI akBzdGFuZGFyZC5ubzwvYT47CkxUUlUgV29ya2luZyBHcm91cDxicj4KPGI+U3ViamVjdDo8L2I+ IFJlOiAoaXNvNjM5LjI3MDgpIFJFOiBJU08gNjM5LTIgZGVjaXNpb246ICZxdW90O21pcyZxdW90 Ozwvc3Bhbj48L2ZvbnQ+PC9wPgoKPC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBjbGFz cz0iZSIgaWQ9InFfMTEzM2ZkNmExMjNkYWI1M18xIj4KCjxwPiZuYnNwOzwvcD4KCjxwIHN0eWxl PSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+VW5mb3J0dW5hdGVseSwgSVNPIGNvZGVzIGhhdmUKc29t ZXdoYXQgb2YgYW4gaW1wZWRhbmNlIG1pc21hdGNoIHdpdGggdGhlIG5lZWRzIG9mIHRoZSBJVCBj b21tdW5pdHk7IGluCnBhcnRpY3VsYXIsIHN0YWJpbGl0eS4gVGh1cyBCQ1AgNDcgaGFzIHRvIHN0 YWJpbGl6ZSB0aG9zZSBjb2Rlczsgb25lIG9mIHRoZQptYWluIHJlYXNvbnMgZm9yIHRoZSBleGlz dGVuY2Ugb2YgUkZDIDQ2NDYuIFdoYXQgdGhhdCBtZWFucyBpcyB0aGF0IGlmIElTTwp0cmllcyB0 byBuYXJyb3cgdGhlIG1lYW5pbmcgb2YgKmFueSogY29kZSwgd2hldGhlciBpdCBpcyBhCiZxdW90 O2NsYXJpZmljYXRpb24mcXVvdDsgb3Igbm90LCB3ZSBoYXZlIHJlYWxseSBvbmx5IHR3byBjaG9p Y2VzOiA8YnI+Cjxicj4KMS4gS2VlcCB0aGUgYnJvYWRlciBzZW1hbnRpYywgd2hpY2ggZW5jb21w YXNzZXMgdGhlIG5ldyBJU08gbmFycm93IG9uZSwgb3I8YnI+CjIuIERlcHJlY2F0ZSB0aGUgY29k ZSAoaW4gb25lIHdheSBvciBhbm90aGVyKS48YnI+Cjxicj4KVW5saWtlIG1hbnkgb3RoZXIgY29k ZXMsICZxdW90O21pcyZxdW90OyBpcyBvbmUgdGhhdCB3ZSBjYW4gZG8gd2l0aG91dCwgc28gIzIK d2FzIGEgcmVhc29uYWJsZSBjaG9pY2UuIDxicj4KPGJyPgpXaGF0IEkgd2FzIHRyeWluZyB0byBj b21lIHVwIHdpdGggbGFuZ3VhZ2UgdGhhdCB3ZSBjb3VsZCBhZ3JlZSBvbiBldmVuIHRob3VnaAp3 ZSBoYXZlIHZlcnkgZGlmZmVyZW50IHZpZXdzIG9uIHRoZSB1dGlsaXR5IGFuZCBtZWFuaW5nIG9m ICYjMzk7bWlzJiMzOTsuIEl0IHNvdW5kcwpsaWtlIHdlIGFyZSBvayBvbiB0aGUgc3VnZ2VzdGVk IGxhbmd1YWdlIG9uIHRoZSBvdGhlciB0aHJlYWQsIHNvIEkmIzM5O20gaG9waW5nCnRoYXQgd2Ug Y2FuIHB1dCAmcXVvdDttaXMmcXVvdDsgdG8gYmVkLjxicj4KPGJyPgpNYXJrPC9wPgoKPGRpdj4K CjxwPjxzcGFuPk9uIDYvMTYvMDcsIDxiPlBldGVyIENvbnN0YWJsZTwvYj4KJmx0OzxhIGhyZWY9 Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnBldGVyY29uQG1p Y3Jvc29mdC5jb20KPC9hPiZndDsgd3JvdGU6PC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4t Ym90dG9tOiAxMnB0OyI+RnJvbTogS2VudCBLYXJsc3NvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzprZW50Lmthcmxzc29uMTRAY29taGVtLnNlIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0 dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgprZW50Lmthcmxzc29u MTRAY29taGVtLnNlPC9hPl08YnI+Cjxicj4KJmd0OyBXaXRoIHRoZSAmcXVvdDtvbGQgbWlzJnF1 b3Q7IG9uZSBjb3VsZCBjb3JyZWN0bHkgYXBwbHkgJiMzOTttaXMmIzM5OyBhcyBhIGxhbmd1YWdl PGJyPgomZ3Q7IGNvZGUgZm9yIGFueSBsYW5ndWFnZTxicj4KPGJyPgpUaGF0IGhhcyAqbmV2ZXIq IGJlZW4gdGhlIGludGVudCBvZiBJU08gNjM5LiBJdCBpcyBhbiBleHRlcm5hbCBpbnRlcnByZXRh dGlvbiwKYWRtaXR0ZWRseSBwb3NzaWJsZSBiZWNhdXNlIElTTyA2Mzkgd2FzIG5vdCBmdWxseSBl eHBsaWNpdCB1cCB0byBub3cuIEJ1dCBmcm9tCnRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgSkFDLCB0 aGUgJnF1b3Q7bmV3IG1pcyZxdW90OyBpcyBleGFjdGx5IHRoZSBzYW1lCiZxdW90O21pcyZxdW90 OyBhcyB0aGUgJnF1b3Q7b2xkIG1pcyZxdW90Oy4gPGJyPgo8YnI+Cjxicj4KUGV0ZXI8L3A+Cgo8 L2Rpdj4KCjxwPjxicj4KPGJyIGNsZWFyPSJhbGwiPgo8YnI+Ci0tIDxicj4KTWFyayA8L3A+Cgo8 L3NwYW4+PC9mb250PjwvZGl2PjwvZGl2PgoKPC9kaXY+CgoKPGZvbnQgc2l6ZT0iMiI+PGJyPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkx0cnUgbWFp bGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwv YT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUi IHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydTwvYT48YnI+PGJyPjwvZm9udD48L2Jsb2NrcXVvdGU+PC9kaXY+PGZvbnQgc2l6ZT0iMiI+ PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsKPC9mb250Pgo= ------=_Part_73493_9127944.1182199764734-- --===============0767631577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0767631577==-- From ltru-bounces@ietf.org Mon Jun 18 17:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OXQ-0001WX-NY; Mon, 18 Jun 2007 17:13:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0OXP-0001Si-4u for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 17:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OXO-0001Q1-PZ for ltru@lists.ietf.org; Mon, 18 Jun 2007 17:13:26 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0OXN-0005gg-FP for ltru@lists.ietf.org; Mon, 18 Jun 2007 17:13:26 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0OXM-0004o6-FX; Mon, 18 Jun 2007 17:13:24 -0400 Date: Mon, 18 Jun 2007 17:13:24 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 Message-ID: <20070618211324.GB12688@mercury.ccil.org> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@localhost> <46766F0B.19B6@xyzzy.claranet.de> <20070618143419.GA25433@mercury.ccil.org> <4676B697.3CCA@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4676B697.3CCA@xyzzy.claranet.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Sometimes I think they're making up languages for non-technical > reasons. Sometimes I think so too, but I don't think this is one of them. Low Saxon (or whatever you want to call it) is pretty clearly established, though whether the non-Dutch dialects in the Netherlands are really all that separate from it is a question. > > fy-DE could never have been more than a hack like zh-TW for > > zh-Hant: is it North Frisian, or is it Saterfrisian > > All you can know is that it's not West Frisian (fy since 2006). > > For the frr suppress-Latn registration request I tried to find > some background info, apparently frr is subdivided into three > or more variants. Pretty much mainlander, islander (except Sylt which is no longer Frisian-speaking in practice), and Heligolander. Of course, finer distinctions can be and are made. > I'd guess that that's no language, when nds-folks speak "de" > they end up with a rather pure "de". Well, that's what de is: High German syntax in Low German phonology (cf. "lingua toscana in bocca romana"). > Frank > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly http://ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 17:19:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OdS-0001XR-GA; Mon, 18 Jun 2007 17:19:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0OdR-0001XM-Na for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 17:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OdR-0001XE-EC for ltru@ietf.org; Mon, 18 Jun 2007 17:19:41 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0OdQ-00086J-7i for ltru@ietf.org; Mon, 18 Jun 2007 17:19:41 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0OdM-00058Q-Nt; Mon, 18 Jun 2007 17:19:36 -0400 Date: Mon, 18 Jun 2007 17:19:36 -0400 To: Mark Davis Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" Message-ID: <20070618211936.GA19443@mercury.ccil.org> References: <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group , "isojac@loc.gov" , "iso639-2@loc.gov" , "ietf-languages@iana.org" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > - Have a code I'll call here "root" (to avoid any misunderstanding > about the meaning of "mis".) > - Have it be valid to tag any language content with "root". > - State that one SHOULD tag as narrowly as possible, thus avoid "root" > if there is a more specific language code. If you feel strongly about this, you could ask for it to be registered as an (exceptional) RFC 4646 language subtag. "Root" is too short, but "somelang" would work. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck cowan@ccil.org soup the rest of your life. --Groucho _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 17:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OvL-0000zz-Tf; Mon, 18 Jun 2007 17:38:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0OvK-0000zr-9E for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 17:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OvJ-0000zg-Vz for ltru@lists.ietf.org; Mon, 18 Jun 2007 17:38:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0OvI-000520-J7 for ltru@lists.ietf.org; Mon, 18 Jun 2007 17:38:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0OvB-0006GQ-Mg for ltru@lists.ietf.org; Mon, 18 Jun 2007 23:38:03 +0200 Received: from dialin-145-254-045-028.pools.arcor-ip.net ([145.254.45.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 23:38:01 +0200 Received: from nobody by dialin-145-254-045-028.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 23:38:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 18 Jun 2007 23:34:42 +0200 Organization: Lines: 12 Message-ID: <4676FA72.31F4@xyzzy.claranet.de> References: <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> <20070618211936.GA19443@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-045-028.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > "Root" is too short, but "somelang" would work. It's an idea, maybe "dummy" is a good name. It should be combined with scripts, otherwise it's probably pointless. But it's still very near to "und", why would anybody wish to make the very subtle point und-Latn vs. dummy-Latn ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 18:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PH8-0005WT-83; Mon, 18 Jun 2007 18:00:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0PH6-0005Rh-4q for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 18:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PH5-0005RZ-RC for ltru@ietf.org; Mon, 18 Jun 2007 18:00:39 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PH4-0007yp-DS for ltru@ietf.org; Mon, 18 Jun 2007 18:00:39 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2736884wah for ; Mon, 18 Jun 2007 15:00:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=FoVEslk5vKIGtKw5TxqDOHof/aE6T8gK480axGJ2ZHWRlvW6Ln2J5D70ReziFcU45tSJ6Nin8dO2FXibMuKqJUPdtINsDdNVZjr7aBZgu3Yx7BMDklAV4UT6HhJDHyoctEKZgx+BdoGZuI7+chr7cLnVvRd1bErPFr6DjlZvV2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fk1VStusIsHocDHIGtuyTfnmaH9z180lab8vzaCxvG2y2JIcRUGQlNSMXDd3QU9yDSxIGoI2IUmjgQYcR5La/gAzFtFua7Q9METaNO1KoIpWLNB8qBiWsLyBgG6CchPxPIONTxREaiuuYAeqGEJnjWxACwYwChrKG9BDf1vGQk4= Received: by 10.114.146.1 with SMTP id t1mr6679216wad.1182204037045; Mon, 18 Jun 2007 15:00:37 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 15:00:36 -0700 (PDT) Message-ID: <30b660a20706181500x8c981c9p65961655fc0f032c@mail.gmail.com> Date: Mon, 18 Jun 2007 15:00:37 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: <20070618211936.GA19443@mercury.ccil.org> MIME-Version: 1.0 References: <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> <20070618211936.GA19443@mercury.ccil.org> X-Google-Sender-Auth: b0f6b847492d2b61 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: LTRU Working Group , "isojac@loc.gov" , "iso639-2@loc.gov" , "ietf-languages@iana.org" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0698536248==" Errors-To: ltru-bounces@ietf.org --===============0698536248== Content-Type: multipart/alternative; boundary="----=_Part_75091_31813505.1182204037001" ------=_Part_75091_31813505.1182204037001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The main concern I had is deprecating the unstable "mis". I used "root" to contrast with how it could have been done in a stable fashion. The code "und" is a superset of "root" -- the basic difference being that "und" can also include non-linguistic content. So I don't think it is a priority right now to have a separate code, compared to finishing the other items in 4646bis. Mark On 6/18/07, John Cowan wrote: > > Mark Davis scripsit: > > > - Have a code I'll call here "root" (to avoid any misunderstanding > > about the meaning of "mis".) > > - Have it be valid to tag any language content with "root". > > - State that one SHOULD tag as narrowly as possible, thus avoid "root" > > if there is a more specific language code. > > If you feel strongly about this, you could ask for it to be registered > as an (exceptional) RFC 4646 language subtag. "Root" is too short, > but "somelang" would work. > > -- > Take two turkeys, one goose, four John Cowan > cabbages, but no duck, and mix them http://www.ccil.org/~cowan > together. After one taste, you'll duck cowan@ccil.org > soup the rest of your life. > --Groucho > -- Mark ------=_Part_75091_31813505.1182204037001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The main concern I had is deprecating the unstable "mis". I used "root" to contrast with how it could have been done in a stable fashion. The code "und" is a superset of "root" -- the basic difference being that "und" can also include non-linguistic content. So I don't think it is a priority right now to have a separate code, compared to finishing the other items in 4646bis.

Mark

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

>   - Have a code I'll call here "root" (to avoid any misunderstanding
>   about the meaning of "mis".)
>   - Have it be valid to tag any language content with "root".
>   - State that one SHOULD tag as narrowly as possible, thus avoid "root"
>   if there is a more specific language code.

If you feel strongly about this, you could ask for it to be registered
as an (exceptional) RFC 4646 language subtag.  "Root" is too short,
but "somelang" would work.

--
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          cowan@ccil.org
soup the rest of your life.
        --Groucho



--
Mark ------=_Part_75091_31813505.1182204037001-- --===============0698536248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0698536248==-- From ltru-bounces@ietf.org Mon Jun 18 18:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PJI-0002QT-U0; Mon, 18 Jun 2007 18:02:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0PJI-0002QM-8A for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 18:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PJH-0002QD-Un for ltru@ietf.org; Mon, 18 Jun 2007 18:02:55 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PJH-00083a-5S for ltru@ietf.org; Mon, 18 Jun 2007 18:02:55 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1456214nzd for ; Mon, 18 Jun 2007 15:02:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MxaKrTifhfi9xWrmYb8joXb/LB66ZzncxZn4PGDJrUh066gG4zHP696mCr8EcGUns1sU8TcTCrgLNjKcm2DM8sd5eVFpkLc5nDcVNV/dfSx1AGUT1XP+RLO5u4IKN/AincSYv+mlIpEe+cTdJr49AeGn9kfiG0dl7KY6pK/CU9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TxushFkqd8asG4N9l2YaneIpJGbItk8pb8QWTGghCWhwbnUKi5gjHgZNYDoPKtAFcGdgqNp0HjZytrmxu+7cezbx+OhQIT0OwVXyT5WwYZFcELc5MqHspJI8A0WJEi/7NjhRdzYV17JwphzlV9lphWmQPYJFk3+yQFz6aR4ualc= Received: by 10.115.59.4 with SMTP id m4mr6604350wak.1182204174044; Mon, 18 Jun 2007 15:02:54 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 18 Jun 2007 15:02:53 -0700 (PDT) Message-ID: <30b660a20706181502u76e3e31dia7138ef721dd3734@mail.gmail.com> Date: Mon, 18 Jun 2007 15:02:53 -0700 From: "Mark Davis" To: "LTRU Working Group" Subject: Fwd: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> MIME-Version: 1.0 References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> X-Google-Sender-Auth: 8723711fb10f3422 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1804691999==" Errors-To: ltru-bounces@ietf.org --===============1804691999== Content-Type: multipart/alternative; boundary="----=_Part_75135_6720353.1182204173775" ------=_Part_75135_6720353.1182204173775 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Qm91bmNlZCBhZ2Fpbi4gSXQncyBhIHBhaW4gdGhhdCB0aGUgcmVjaXBpZW50IGxpbWl0IGlzIHNv IGxvdyBvbiBMVFJVLgoKLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZy b206IE1hcmsgRGF2aXMgPG1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPgpEYXRlOiBKdW4gMTgs IDIwMDcgMTo0OSBQTQpTdWJqZWN0OiBSZTogW0x0cnVdIFJFOiAoaXNvNjM5LjI3MDgpIFJFOiBJ U08gNjM5LTIgZGVjaXNpb246ICJtaXMiClRvOiBQZXRlciBDb25zdGFibGUgPHBldGVyY29uQG1p Y3Jvc29mdC5jb20+CkNjOiBMVFJVIFdvcmtpbmcgR3JvdXAgPGx0cnVAaWV0Zi5vcmc+LCAiaWV0 Zi1sYW5ndWFnZXNAaWFuYS5vcmciIDwKaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc+LCAiaXNvNjM5 LTJAbG9jLmdvdiIgPGlzbzYzOS0yQGxvYy5nb3Y+LCAiCmlzb2phY0Bsb2MuZ292IiA8aXNvamFj QGxvYy5nb3Y+LCAiaXNvNjM5QGRrdXVnLmRrIiA8aXNvNjM5QGRrdXVnLmRrPgoKSSByZWFsbHkg ZGlkbid0IHdhbnQgdG8gc3RhcnQgYSBmbGFtZSBhYm91dCB0aGlzOyBJJ20gc29ycnkgaWYgd2hh dCBJIHNhaWQKd2FzIGJlIGNvbnNpZGVyZWQgaW5jZW5kaWFyeS4KClRoaXMgd2hvbGUgaXNzdWUg aXMgbm90IHJlYWxseSBjb25uZWN0ZWQgd2l0aCB0aGUgY2hhbmdlIGZyb20gcGFydCAyIHRvIHBh cnQKMywgYXQgYWxsLiBUYWtlIHlvdXIgZXhhbXBsZTogaXQgaXMgYSBwcm9ibGVtIHdpdGggeW91 ciBkZWZpbml0aW9uIG9mICJtaXMiCmluIEJDUCA0NyB3aGV0aGVyICJicmsiIHdlcmUgYWRkZWQg YmVjYXVzZSBvZiA2MzktMyBPUiBqdXN0IGJlY2F1c2UgaXQgd2VyZQphZGRlZCB0byBJU08gNjM5 LTIhIEl0IGlzIGFuIGlzc3VlIHdoZW5ldmVyIG5ldyBjb2RlcyBjb3VsZCBiZSBhZGRlZCB0aGF0 CndvdWxkIGludmFsaWRhdGUgcHJldmlvdXMgdXNhZ2Ugb2YgIm1pcyIuCgpBbmQgdGhlIHNhZCB0 aGluZyBpcyB0aGF0IHRoaXMgaW5zdGFiaWxpdHkgaW4gSVNPIGNvZGVzIGlzIGNvbXBsZXRlbHkK YXZvaWRhYmxlLiBUaGVyZSBpcyBhIHBlcmZlY3RseSBnb29kIHdheSB0byBoYXZlIHRoZSBzYW1l IGZ1bmN0aW9uYWxpdHkKKndpdGhvdXQqIGJlaW5nIHVuc3RhYmxlLgoKICAgLSBIYXZlIGEgY29k ZSBJJ2xsIGNhbGwgaGVyZSAicm9vdCIgKHRvIGF2b2lkIGFueSBtaXN1bmRlcnN0YW5kaW5nCiAg IGFib3V0IHRoZSBtZWFuaW5nIG9mICJtaXMiLikKICAgLSBIYXZlIGl0IGJlIHZhbGlkIHRvIHRh ZyBhbnkgbGFuZ3VhZ2UgY29udGVudCB3aXRoICJyb290Ii4KICAgLSBTdGF0ZSB0aGF0IG9uZSBT SE9VTEQgdGFnIGFzIG5hcnJvd2x5IGFzIHBvc3NpYmxlLCB0aHVzIGF2b2lkICJyb290IgogICBp ZiB0aGVyZSBpcyBhIG1vcmUgc3BlY2lmaWMgbGFuZ3VhZ2UgY29kZS4KClRoaXMgY29tcGxldGVs eSB0YWtlcyB0aGUgcGxhY2Ugb2YgdGhlIG5lZWQgeW91IHNlZSBmb3IgIm1pcyIsICp3aXRob3V0 CmJlaW5nIHVuc3RhYmxlKi4gSWYgSSBoYXZlIHNvbWUgQnVydXNoYXNraSBjb250ZW50LCB3aGVy ZSBhIGNvZGUgZG9lc24ndApleGlzdCwgSSB0YWcgaXQgd2l0aCAicm9vdCIuIFRoYXQgaXMgdmFs aWQgbm93LCBhbmQgcmVtYWlucyB2YWxpZCBmb3JldmVyLApldmVuIG9uY2UgImJyayIgaXMgYWRk ZWQgLS0gd2hldGhlciAiYnJrIiB3ZXJlIGFkZGVkIGJlY2F1c2Ugb2YgNjM5LTMgb3IKanVzdCBi ZWNhdXNlIGl0IHdlcmUgYWRkZWQgdG8gSVNPIDYzOS0yLgoKTWFyawoKT24gNi8xOC8wNywgUGV0 ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToKCj4gIEFzIGZhciBh cyB0aGUgSkFDIGlzIGNvbmNlcm5lZCwgdGhlIGludGVudGlvbmFsIHNlbWFudGljIG9mICJtaXMi IGlzIHdoYXQKPiBpdCBoYXMgYWx3YXlzIGJlZW4uIEFzIGZvciB0aGUgZXh0ZW5zaW9uLCB3aGVu IDYzOS0yIHdhcyB0aGUgb25seSBhbHBoYS0zCj4gY29kZSwgdGhlcmUgd2FzIG9ubHkgb25lIGNv bnRleHQgdG8gZXZhbHVhdGUgdGhlIGV4dGVuc2lvbiB0aGF0IHdvdWxkIGJlCj4gZGVyaXZlZCBi eSB0aGF0IGludGVudGlvbjsgNjM5LTIgZGlkIG5vdCBkb2N1bWVudCB0aGUgZXh0ZW5zaW9uLCB0 aG91Z2ggYXQKPiBsZWFzdCBvbmUgYXBwbGljYXRpb24gb2YgNjM5LTIg4oCTIE1BUkMg4oCTIGRp ZC4gV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIDYzOS0zCj4gYW5kIHRoZSBwZW5kaW5nIGludHJv ZHVjdGlvbiBvZiA2MzktNSBhcyBhZGRpdGlvbnMgdG8gdGhlIGFscGhhLTMgc3BhY2UsIGl0Cj4g YmVjb21lcyBjbGVhciB0aGF0IHRoZSBleHRlbnNpb24gbXVzdCBiZSBkZXRlcm1pbmVkIHdpdGhp biBhIGNvbnRleHQ6IHRoZQo+IGNhc2VzIHdoZXJlIHlvdSdkIHdhbnQgdG8gdXNlICJtaXMiIGRp ZmZlciBpZiB5b3UncmUgdXNpbmcgNjM5LTMgcmF0aGVyIHRoYW4KPiA2MzktMi4gQnV0IGZvciBh biBhcHBsaWNhdGlvbiBvZiBhIGdpdmVuIHBhcnQgb2YgNjM5LCB0aGUgY2hhbmdlIG9mCj4gcmVm ZXJlbmNlIG5hbWUgaGFzIGhhZCBubyBlZmZlY3Qgb24gdGhlIGV4dGVuc2lvbiBmb3IgdGhhdCBj b250ZXh0OiB0aGUKPiBsYW5ndWFnZXMgZW5jb21wYXNzZWQgYnkgIm1pcyIgaW4gYSA2MzktMiBh cHBsaWNhdGlvbiwgZm9yIGluc3RhbmNlLCBhcmUgdGhlCj4gc2FtZSBhcyB0aGV5IHdlcmUgYmVm b3JlLgo+Cj4KPgo+IFdoZW4gaXQgY29tZXMgdG8gQkNQIDQ3LCB0aGUgY2hhbmdlIG9mIHJlZmVy ZW5jZSBuYW1lIGZvciAibWlzIiBpcwo+IGJhc2ljYWxseSBpcnJlbGV2YW50IGJlY2F1c2UgdGhl cmUgaXMgYSBtdWNoIGJpZ2dlciBpc3N1ZTogaW4gUkZDNDY0NmJpcywKPiBCQ1AgNDcgd2lsbCBj aGFuZ2UgZnJvbSBiZWluZyBhbiBhcHBsaWNhdGlvbiBvZiA2MzktMSBhbmQgLTIgdG8gYmVpbmcg YW4KPiBhcHBsaWNhdGlvbiBvZiA2MzktMSwgLTIgYW5kIC0zLiBUaGF0IGNoYW5nZSBvZiBjb250 ZXh0IGlzIHdoYXQgY3JlYXRlcyB0aGUKPiBpc3N1ZSB3cnQgaW50ZXJvcGVyYWJpbGl0eSBvZiAi bWlzIiBpbiBhcHBsaWNhdGlvbnMgb2YgQkNQIDQ3OiBVbmRlciBSRkMKPiA0NjQ2LCBCdXJ1c2hh c2tpIGNvbnRlbnQgd291bGQgYmUgdGFnZ2VkICJtaXMiOyB1bmRlciBSRkMgNDY0NmJpcywgb25l IHdvdWxkCj4gZXhwZWN0IG5ldyBCdXJ1c2hhc2tpIGNvbnRlbnQgdG8gYmUgdGFnZ2VkICJic2si LiBUaGVyZSdzIG5vIGJhc2lzIGZvcgo+IG1hdGNoaW5nOiB0aGF0J3MgYW4gaW50ZXJvcCBwcm9i bGVtLiBBbmQgbm90ZSB0aGF0IGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGgKPiBzdGFiaWxpdHkg b2YgIm1pcyIgc3VwcG9zZWRseSBpbnRyb2R1Y2VkIHdpdGggdGhlIG5hbWUgY2hhbmdlOiB3aXRo IG9yCj4gd2l0aG91dCB0aGF0IGNoYW5nZSwgQnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRh Z2dlZCBkaWZmZXJlbnRseSBiZWZvcmUKPiBhbmQgYWZ0ZXIuCj4KPgo+Cj4gQW5kIG5vdGUgdGhh dCB0aGlzIGlzc3VlIGV4aXN0cyB3aGV0aGVyIG9uZSBjb25zaWRlcnMgIm9sZCBtaXMiIHRvIGhh dmUKPiB0aGUgc2VtYW50aWMgdGhhdCBLZWxkIGlzIHN0dWNrIG9uLCAnYWxsIGxhbmd1YWdlcycs IG9yIHRoZSBzZW1hbnRpYyB0aGF0Cj4gdGhlIEpBQyBoYXMgYWx3YXlzIGludGVuZGVkOiBlaXRo ZXIgd2F5LCBpdCBpcyB0aGUgYWRkaXRpb24gb2YgNjM5LTMgdG8gQkNQCj4gNDcgdGhhdCBjcmVh dGVzIGFuIGlzc3VlIGZvciB1c2VzIG9mICJtaXMiIHVuZGVyIEJDUCA0Nywgbm90IHRoZSBuYW1l Cj4gY2hhbmdlLgo+Cj4KPgo+IEFuZCBldmVuIHdpdGhvdXQgdGhlIGFkZGl0aW9uIG9mIDYzOS0z LCAibWlzIiB3b3VsZCBoYXZlIGludGVyb3AgaXNzdWVzOgo+IGFzc3VtaW5nIHRoZSBzZW1hbnRp YyB0aGUgSkFDIGhhcyBhbHdheXMgYXNzdW1lZCwgdGhlIGV4dGVuc2lvbiBpbiB0aGUKPiBjb250 ZXh0IG9mIDYzOS0yIGNvdWxkIG5hcnJvdyDigJMgaW5oZXJlbnRseSBieSB0aGUgbmF0dXJlIG9m IHRoZSBzZW1hbnRpYyDigJMKPiBhbnkgdGltZSBhIG5ldyBlbnRyeSB3YXMgYWRkZWQ7IGJ1dCBh c3N1bWluZyB0aGUgJ2FsbCBsYW5ndWFnZXMnIHNlbWFudGljLAo+IG9uZSBjb3VsZCBlbmQgdXAg d2l0aCBjb21wYXJhYmxlIGNvbnRlbnQgdGFnZ2VkIGluIG5vbi1jb21wYXJhYmxlIHdheXMsCj4g Im1pcyIgYW5kIHNvbWV0aGluZyBlbHNlLgo+Cj4KPgo+IFRoZXJlZm9yZSwgSSBzdWdnZXN0IHRo YXQgYmVhdGluZyB1cCBJU08gYXMgbm90IGJlaW5nIGluIHR1bmUgd2l0aCB0aGUKPiBuZWVkcyBv ZiB0aGUgSVQgY29tbXVuaXR5IGlzIGJvdGggZnJ1aXRsZXNzIGFuZCBiYXNlbGVzcywgYW5kIGlz IGlnbm9yaW5nCj4gdGhlIGZhY3QgdGhhdCBJRVRGIGhhcyBwcm9ibGVtcyBhbGwgb2YgaXRzIG93 biBtYWtpbmcuIElmIElFVEYgcmVhbGx5IHdhbnRlZAo+IHRvIGF2b2lkIGFueSBzdGFiaWxpdHkg b3IgaW50ZXJvcCBwcm9ibGVtcyByZWxhdGVkIHRvICJtaXMiLCBpdCBzaG91bGQgbmV2ZXIKPiBo YXZlIHBlcm1pdHRlZCBpdHMgdXNlIGluIGxhbmd1YWdlIHRhZ3MsIHN0YXJ0aW5nIGJhY2sgaW4g UkZDIDE3NjYsIGJlY2F1c2UKPiAibWlzIiBoYXMgYWx3YXlzIGhhZCBzdGFiaWxpdHkgLyBpbnRl cm9wIGlzc3Vlcy4gQnV0IHRoYXQgaG9yc2UgaXMgbG9uZyBvdXQKPiBvZiB0aGUgYmFybjogIm1p cyIgKipjYW4qKiBiZSB1c2VkIGluIGxhbmd1YWdlIHRhZ3MgdW5kZXIgUkZDcyBmcm9tIDE3NjYK PiB0byA0NjQ2LiBUaGUgTFRSVSBXRyB3aXRoaW4gSUVURiBuZWVkcyB0byBkZWNpZGUgd2hhdCB0 byBkbyBhYm91dCB0aGF0IGluCj4gUkZDIDQ2NDZiaXMuIFRoYXQncyBhIGpvYiBmb3IgSUVURjsg d2UgZG9uJ3QgbmVlZCB0byBjb250aW51ZSBib3RoZXJpbmcgSkFDCj4gbWVtYmVycyB3aXRoIElF VEYgaXNzdWVzLgo+Cj4KPgo+Cj4KPiBQZXRlcgo+Cj4KPgo+ICpGcm9tOiogbWFyay5lZHdhcmQu ZGF2aXNAZ21haWwuY29tIFttYWlsdG86IG1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbV0KPiAq T24gQmVoYWxmIE9mICpNYXJrIERhdmlzCj4gKlNlbnQ6KiBNb25kYXksIEp1bmUgMTgsIDIwMDcg OToyMyBBTQo+ICpUbzoqIFBldGVyIENvbnN0YWJsZQo+ICpDYzoqIEtlbnQgS2FybHNzb247IE1p bGljZW50IEsgV2V3ZXJrYTsgSm9obiBDb3dhbjsgaXNvNjM5QGRrdXVnLmRrOwo+IGlldGYtbGFu Z3VhZ2VzQGlhbmEub3JnOyBpc282MzktMkBsb2MuZ292OyBpc29qYWNAbG9jLmdvdjsgSEhqQHN0 YW5kYXJkLm5vOwo+IExUUlUgV29ya2luZyBHcm91cAo+ICpTdWJqZWN0OiogUmU6IChpc282Mzku MjcwOCkgUkU6IElTTyA2MzktMiBkZWNpc2lvbjogIm1pcyIKPgo+Cj4KPiBVbmZvcnR1bmF0ZWx5 LCBJU08gY29kZXMgaGF2ZSBzb21ld2hhdCBvZiBhbiBpbXBlZGFuY2UgbWlzbWF0Y2ggd2l0aCB0 aGUKPiBuZWVkcyBvZiB0aGUgSVQgY29tbXVuaXR5OyBpbiBwYXJ0aWN1bGFyLCBzdGFiaWxpdHku IFRodXMgQkNQIDQ3IGhhcyB0bwo+IHN0YWJpbGl6ZSB0aG9zZSBjb2Rlczsgb25lIG9mIHRoZSBt YWluIHJlYXNvbnMgZm9yIHRoZSBleGlzdGVuY2Ugb2YgUkZDCj4gNDY0Ni4gV2hhdCB0aGF0IG1l YW5zIGlzIHRoYXQgaWYgSVNPIHRyaWVzIHRvIG5hcnJvdyB0aGUgbWVhbmluZyBvZiAqYW55Kgo+ IGNvZGUsIHdoZXRoZXIgaXQgaXMgYSAiY2xhcmlmaWNhdGlvbiIgb3Igbm90LCB3ZSBoYXZlIHJl YWxseSBvbmx5IHR3bwo+IGNob2ljZXM6Cj4KPiAxLiBLZWVwIHRoZSBicm9hZGVyIHNlbWFudGlj LCB3aGljaCBlbmNvbXBhc3NlcyB0aGUgbmV3IElTTyBuYXJyb3cgb25lLCBvcgo+IDIuIERlcHJl Y2F0ZSB0aGUgY29kZSAoaW4gb25lIHdheSBvciBhbm90aGVyKS4KPgo+IFVubGlrZSBtYW55IG90 aGVyIGNvZGVzLCAibWlzIiBpcyBvbmUgdGhhdCB3ZSBjYW4gZG8gd2l0aG91dCwgc28gIzIgd2Fz IGEKPiByZWFzb25hYmxlIGNob2ljZS4KPgo+IFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGNvbWUgdXAg d2l0aCBsYW5ndWFnZSB0aGF0IHdlIGNvdWxkIGFncmVlIG9uIGV2ZW4KPiB0aG91Z2ggd2UgaGF2 ZSB2ZXJ5IGRpZmZlcmVudCB2aWV3cyBvbiB0aGUgdXRpbGl0eSBhbmQgbWVhbmluZyBvZiAnbWlz Jy4gSXQKPiBzb3VuZHMgbGlrZSB3ZSBhcmUgb2sgb24gdGhlIHN1Z2dlc3RlZCBsYW5ndWFnZSBv biB0aGUgb3RoZXIgdGhyZWFkLCBzbyBJJ20KPiBob3BpbmcgdGhhdCB3ZSBjYW4gcHV0ICJtaXMi IHRvIGJlZC4KPgo+IE1hcmsKPgo+IE9uIDYvMTYvMDcsICpQZXRlciBDb25zdGFibGUqIDxwZXRl cmNvbkBtaWNyb3NvZnQuY29tID4gd3JvdGU6Cj4KPiBGcm9tOiBLZW50IEthcmxzc29uIFttYWls dG86IGtlbnQua2FybHNzb24xNEBjb21oZW0uc2VdCj4KPiA+IFdpdGggdGhlICJvbGQgbWlzIiBv bmUgY291bGQgY29ycmVjdGx5IGFwcGx5ICdtaXMnIGFzIGEgbGFuZ3VhZ2UKPiA+IGNvZGUgZm9y IGFueSBsYW5ndWFnZQo+Cj4gVGhhdCBoYXMgKm5ldmVyKiBiZWVuIHRoZSBpbnRlbnQgb2YgSVNP IDYzOS4gSXQgaXMgYW4gZXh0ZXJuYWwKPiBpbnRlcnByZXRhdGlvbiwgYWRtaXR0ZWRseSBwb3Nz aWJsZSBiZWNhdXNlIElTTyA2Mzkgd2FzIG5vdCBmdWxseSBleHBsaWNpdAo+IHVwIHRvIG5vdy4g QnV0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBKQUMsIHRoZSAibmV3IG1pcyIgaXMgZXhh Y3RseSB0aGUKPiBzYW1lICJtaXMiIGFzIHRoZSAib2xkIG1pcyIuCj4KPgo+IFBldGVyCj4KPgo+ Cj4KPiAtLQo+IE1hcmsKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cj4KCgotLSAKTWFyawoKLS0gCk1h cmsK ------=_Part_75135_6720353.1182204173775 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Qm91bmNlZCBhZ2Fpbi4gSXQmIzM5O3MgYSBwYWluIHRoYXQgdGhlIHJlY2lwaWVudCBsaW1pdCBp cyBzbyBsb3cgb24gTFRSVS48YnI+PGJyPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0t LS0tLS0tLTxicj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPkZyb206IDxiIGNsYXNzPSJnbWFp bF9zZW5kZXJuYW1lIj5NYXJrIERhdmlzPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2 aXNAaWN1LXByb2plY3Qub3JnIj4KbWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+Jmd0Ozxi cj5EYXRlOiBKdW4gMTgsIDIwMDcgMTo0OSBQTTxicj5TdWJqZWN0OiBSZTogW0x0cnVdIFJFOiAo aXNvNjM5LjI3MDgpIFJFOiBJU08gNjM5LTIgZGVjaXNpb246ICZxdW90O21pcyZxdW90Ozxicj5U bzogUGV0ZXIgQ29uc3RhYmxlICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0 LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbQo8L2E+Jmd0Ozxicj5DYzogTFRSVSBXb3JraW5n IEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bHRydUBpZXRmLm9yZyI+bHRydUBpZXRmLm9yZzwv YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciPmll dGYtbGFuZ3VhZ2VzQGlhbmEub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYt bGFuZ3VhZ2VzQGlhbmEub3JnIj5pZXRmLWxhbmd1YWdlc0BpYW5hLm9yZwo8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOmlzbzYzOS0yQGxvYy5nb3YiPmlzbzYzOS0yQGxvYy5nb3Y8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aXNvNjM5LTJAbG9jLmdvdiI+aXNvNjM5LTJAbG9j LmdvdjwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aXNvamFjQGxvYy5nb3YiPmlzb2ph Y0Bsb2MuZ292PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlzb2phY0Bsb2MuZ292Ij4K aXNvamFjQGxvYy5nb3Y8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1 Zy5kayI+aXNvNjM5QGRrdXVnLmRrPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlzbzYz OUBka3V1Zy5kayI+aXNvNjM5QGRrdXVnLmRrPC9hPiZndDs8YnI+PGJyPjwvc3Bhbj48Zm9udCBz aXplPSIyIj5JIHJlYWxseSBkaWRuJiMzOTt0IHdhbnQgdG8gc3RhcnQgYSBmbGFtZSBhYm91dCB0 aGlzOyBJJiMzOTttIHNvcnJ5IGlmIHdoYXQgSSBzYWlkIHdhcyBiZSBjb25zaWRlcmVkIGluY2Vu ZGlhcnkuCjxicj48YnI+VGhpcyB3aG9sZSBpc3N1ZSBpcyBub3QgcmVhbGx5IGNvbm5lY3RlZCB3 aXRoIHRoZSBjaGFuZ2UgZnJvbSBwYXJ0IDIgdG8gcGFydCAzLCBhdCBhbGwuIFRha2UgeW91ciBl eGFtcGxlOiBpdCBpcyBhIHByb2JsZW0gd2l0aCB5b3VyIGRlZmluaXRpb24gb2YgJnF1b3Q7bWlz JnF1b3Q7IGluIEJDUCA0NyB3aGV0aGVyIAo8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+JnF1b3Q7YnJr JnF1b3Q7IHdlcmUgYWRkZWQgYmVjYXVzZSBvZiA2MzktMyBPUiBqdXN0IGJlY2F1c2UgaXQgd2Vy ZSBhZGRlZCB0byBJU08gNjM5LTIhPC9mb250Pjxmb250IHNpemU9IjIiPiBJdCBpcyBhbiBpc3N1 ZSB3aGVuZXZlciBuZXcgY29kZXMgY291bGQgYmUgYWRkZWQgdGhhdCB3b3VsZCBpbnZhbGlkYXRl IHByZXZpb3VzIHVzYWdlIG9mICZxdW90O21pcyZxdW90Oy4KPGJyPjxicj5BbmQgdGhlIHNhZCB0 aGluZyBpcyB0aGF0IHRoaXMgaW5zdGFiaWxpdHkgaW4gSVNPIGNvZGVzIGlzIGNvbXBsZXRlbHkg YXZvaWRhYmxlLiBUaGVyZSBpcyBhIHBlcmZlY3RseSBnb29kIHdheSB0byBoYXZlIHRoZSBzYW1l IGZ1bmN0aW9uYWxpdHkgKndpdGhvdXQqIGJlaW5nIHVuc3RhYmxlLiA8YnI+PC9mb250Pjx1bD48 bGk+PGZvbnQgc2l6ZT0iMiI+SGF2ZSBhIGNvZGUgSSYjMzk7bGwgY2FsbCBoZXJlICZxdW90O3Jv b3QmcXVvdDsgKHRvIGF2b2lkIGFueSBtaXN1bmRlcnN0YW5kaW5nIGFib3V0IHRoZSBtZWFuaW5n IG9mICZxdW90O21pcyZxdW90Oy4pCjwvZm9udD48L2xpPjxsaT48Zm9udCBzaXplPSIyIj5IYXZl IGl0IGJlIHZhbGlkIHRvIHRhZyBhbnkgbGFuZ3VhZ2UgY29udGVudCB3aXRoICZxdW90O3Jvb3Qm cXVvdDsuPC9mb250PjwvbGk+PGxpPjxmb250IHNpemU9IjIiPlN0YXRlIHRoYXQgb25lIFNIT1VM RCB0YWcgYXMgbmFycm93bHkgYXMgcG9zc2libGUsIHRodXMgYXZvaWQgJnF1b3Q7cm9vdCZxdW90 OyBpZiB0aGVyZSBpcyBhIG1vcmUgc3BlY2lmaWMgbGFuZ3VhZ2UgY29kZS4KPGJyPjwvZm9udD48 L2xpPjwvdWw+PGZvbnQgc2l6ZT0iMiI+VGhpcyBjb21wbGV0ZWx5IHRha2VzIHRoZSBwbGFjZSBv ZiB0aGUgbmVlZCB5b3Ugc2VlIGZvciAmcXVvdDttaXMmcXVvdDssICp3aXRob3V0IGJlaW5nIHVu c3RhYmxlKi4gSWYgSSBoYXZlIHNvbWUgPC9mb250PjxzcGFuPkJ1cnVzaGFza2kgPC9zcGFuPjxm b250IHNpemU9IjIiPmNvbnRlbnQsIHdoZXJlIGEgY29kZSBkb2VzbiYjMzk7dCBleGlzdCwgSSB0 YWcgaXQgd2l0aCAmcXVvdDtyb290JnF1b3Q7LiBUaGF0IGlzIHZhbGlkIG5vdywgYW5kIHJlbWFp bnMgdmFsaWQgZm9yZXZlciwgZXZlbiBvbmNlICZxdW90O2JyayZxdW90OyBpcyBhZGRlZCAtLSB3 aGV0aGVyICZxdW90O2JyayZxdW90OyB3ZXJlIGFkZGVkIGJlY2F1c2Ugb2YgNjM5LTMgb3IganVz dCBiZWNhdXNlIGl0IHdlcmUgYWRkZWQgdG8gSVNPIDYzOS0yLgo8YnI+PGJyPk1hcms8YnI+PGJy PjwvZm9udD48ZGl2PjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExMzQwOThkN2E0ZWU3YmVf MSI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA2LzE4LzA3LCA8 YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+UGV0ZXIgQ29uc3RhYmxlPC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CnBldGVyY29u QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+CjwvZm9udD48L3NwYW4+PC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBz b2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRp bmctbGVmdDogMWV4OyI+CgoKCgoKCgoKPGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBs YW5nPSJFTi1VUyI+Cgo8ZGl2PjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExMzQwOThkN2E0 ZWU3YmVfMyI+Cgo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkFzIGZhciBhcyB0aGUgSkFDIGlzIGNvbmNlcm5l ZCwgdGhlIGludGVudGlvbmFsIHNlbWFudGljIG9mICZxdW90O21pcyZxdW90OwppcyB3aGF0IGl0 IGhhcyBhbHdheXMgYmVlbi4gQXMgZm9yIHRoZSBleHRlbnNpb24sIHdoZW4gNjM5LTIgd2FzIHRo ZSBvbmx5CmFscGhhLTMgY29kZSwgdGhlcmUgd2FzIG9ubHkgb25lIGNvbnRleHQgdG8gZXZhbHVh dGUgdGhlIGV4dGVuc2lvbiB0aGF0IHdvdWxkCmJlIGRlcml2ZWQgYnkgdGhhdCBpbnRlbnRpb247 IDYzOS0yIGRpZCBub3QgZG9jdW1lbnQgdGhlIGV4dGVuc2lvbiwgdGhvdWdoIGF0CmxlYXN0IG9u ZSBhcHBsaWNhdGlvbiBvZiA2MzktMiDigJMgTUFSQyDigJMgZGlkLiBXaXRoIHRoZSBpbnRyb2R1 Y3Rpb24gb2YKNjM5LTMgYW5kIHRoZSBwZW5kaW5nIGludHJvZHVjdGlvbiBvZiA2MzktNSBhcyBh ZGRpdGlvbnMgdG8gdGhlIGFscGhhLTMgc3BhY2UsIGl0CmJlY29tZXMgY2xlYXIgdGhhdCB0aGUg ZXh0ZW5zaW9uIG11c3QgYmUgZGV0ZXJtaW5lZCB3aXRoaW4gYSBjb250ZXh0OiB0aGUgY2FzZXMK d2hlcmUgeW91JiMzOTtkIHdhbnQgdG8gdXNlICZxdW90O21pcyZxdW90OyBkaWZmZXIgaWYgeW91 JiMzOTtyZSB1c2luZwo2MzktMyByYXRoZXIgdGhhbiA2MzktMi4gQnV0IGZvciBhbiBhcHBsaWNh dGlvbiBvZiBhIGdpdmVuIHBhcnQgb2YgNjM5LCB0aGUKY2hhbmdlIG9mIHJlZmVyZW5jZSBuYW1l IGhhcyBoYWQgbm8gZWZmZWN0IG9uIHRoZSBleHRlbnNpb24gZm9yIHRoYXQgY29udGV4dDoKdGhl IGxhbmd1YWdlcyBlbmNvbXBhc3NlZCBieSAmcXVvdDttaXMmcXVvdDsgaW4gYSA2MzktMiBhcHBs aWNhdGlvbiwgZm9yCmluc3RhbmNlLCBhcmUgdGhlIHNhbWUgYXMgdGhleSB3ZXJlIGJlZm9yZS48 L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48 L3A+Cgo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPldoZW4gaXQgY29tZXMgdG8gQkNQIDQ3LCB0aGUgY2hhbmdl IG9mIHJlZmVyZW5jZSBuYW1lIGZvciAmcXVvdDttaXMmcXVvdDsKaXMgYmFzaWNhbGx5IGlycmVs ZXZhbnQgYmVjYXVzZSB0aGVyZSBpcyBhIG11Y2ggYmlnZ2VyIGlzc3VlOiBpbiBSRkM0NjQ2Ymlz LApCQ1AgNDcgd2lsbCBjaGFuZ2UgZnJvbSBiZWluZyBhbiBhcHBsaWNhdGlvbiBvZiA2MzktMSBh bmQgLTIgdG8gYmVpbmcgYW4KYXBwbGljYXRpb24gb2YgNjM5LTEsIC0yIGFuZCAtMy4gVGhhdCBj aGFuZ2Ugb2YgY29udGV4dCBpcyB3aGF0IGNyZWF0ZXMgdGhlCmlzc3VlIHdydCBpbnRlcm9wZXJh YmlsaXR5IG9mICZxdW90O21pcyZxdW90OyBpbiBhcHBsaWNhdGlvbnMgb2YgQkNQIDQ3OgpVbmRl ciBSRkMgNDY0NiwgQnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRhZ2dlZCAmcXVvdDttaXMm cXVvdDs7IHVuZGVyIFJGQwo0NjQ2YmlzLCBvbmUgd291bGQgZXhwZWN0IG5ldyBCdXJ1c2hhc2tp IGNvbnRlbnQgdG8gYmUgdGFnZ2VkICZxdW90O2JzayZxdW90Oy4KVGhlcmUmIzM5O3Mgbm8gYmFz aXMgZm9yIG1hdGNoaW5nOiB0aGF0JiMzOTtzIGFuIGludGVyb3AgcHJvYmxlbS4gQW5kIG5vdGUK dGhhdCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHN0YWJpbGl0eSBvZiAmcXVvdDttaXMmcXVv dDsgc3VwcG9zZWRseQppbnRyb2R1Y2VkIHdpdGggdGhlIG5hbWUgY2hhbmdlOiB3aXRoIG9yIHdp dGhvdXQgdGhhdCBjaGFuZ2UsIEJ1cnVzaGFza2kgY29udGVudAp3b3VsZCBiZSB0YWdnZWQgZGlm ZmVyZW50bHkgYmVmb3JlIGFuZCBhZnRlci4gPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BbmQgbm90 ZSB0aGF0IHRoaXMgaXNzdWUgZXhpc3RzIHdoZXRoZXIgb25lIGNvbnNpZGVycyAmcXVvdDtvbGQK bWlzJnF1b3Q7IHRvIGhhdmUgdGhlIHNlbWFudGljIHRoYXQgS2VsZCBpcyBzdHVjayBvbiwgJiMz OTthbGwgbGFuZ3VhZ2VzJiMzOTssCm9yIHRoZSBzZW1hbnRpYyB0aGF0IHRoZSBKQUMgaGFzIGFs d2F5cyBpbnRlbmRlZDogZWl0aGVyIHdheSwgaXQgaXMgdGhlCmFkZGl0aW9uIG9mIDYzOS0zIHRv IEJDUCA0NyB0aGF0IGNyZWF0ZXMgYW4gaXNzdWUgZm9yIHVzZXMgb2YgJnF1b3Q7bWlzJnF1b3Q7 CnVuZGVyIEJDUCA0Nywgbm90IHRoZSBuYW1lIGNoYW5nZS4gPC9zcGFuPjwvZm9udD48L3A+Cgo8 cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5BbmQgZXZlbiB3aXRob3V0IHRoZSBhZGRpdGlvbiBvZiA2MzktMywgJnF1b3Q7bWlzJnF1b3Q7 IHdvdWxkCmhhdmUgaW50ZXJvcCBpc3N1ZXM6IGFzc3VtaW5nIHRoZSBzZW1hbnRpYyB0aGUgSkFD IGhhcyBhbHdheXMgYXNzdW1lZCwgdGhlCmV4dGVuc2lvbiBpbiB0aGUgY29udGV4dCBvZiA2Mzkt MiBjb3VsZCBuYXJyb3cg4oCTIGluaGVyZW50bHkgYnkgdGhlIG5hdHVyZQpvZiB0aGUgc2VtYW50 aWMg4oCTIGFueSB0aW1lIGEgbmV3IGVudHJ5IHdhcyBhZGRlZDsgYnV0IGFzc3VtaW5nIHRoZSAm IzM5O2FsbApsYW5ndWFnZXMmIzM5OyBzZW1hbnRpYywgb25lIGNvdWxkIGVuZCB1cCB3aXRoIGNv bXBhcmFibGUgY29udGVudCB0YWdnZWQgaW4Kbm9uLWNvbXBhcmFibGUgd2F5cywgJnF1b3Q7bWlz JnF1b3Q7IGFuZCBzb21ldGhpbmcgZWxzZS48L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlRoZXJlZm9y ZSwgSSBzdWdnZXN0IHRoYXQgYmVhdGluZyB1cCBJU08gYXMgbm90IGJlaW5nIGluIHR1bmUKd2l0 aCB0aGUgbmVlZHMgb2YgdGhlIElUIGNvbW11bml0eSBpcyBib3RoIGZydWl0bGVzcyBhbmQgYmFz ZWxlc3MsIGFuZCBpcwppZ25vcmluZyB0aGUgZmFjdCB0aGF0IElFVEYgaGFzIHByb2JsZW1zIGFs bCBvZiBpdHMgb3duIG1ha2luZy4gSWYgSUVURiByZWFsbHkgd2FudGVkCnRvIGF2b2lkIGFueSBz dGFiaWxpdHkgb3IgaW50ZXJvcCBwcm9ibGVtcyByZWxhdGVkIHRvICZxdW90O21pcyZxdW90Oywg aXQKc2hvdWxkIG5ldmVyIGhhdmUgcGVybWl0dGVkIGl0cyB1c2UgaW4gbGFuZ3VhZ2UgdGFncywg c3RhcnRpbmcgYmFjayBpbiBSRkMgMTc2NiwKYmVjYXVzZSAmcXVvdDttaXMmcXVvdDsgaGFzIGFs d2F5cyBoYWQgc3RhYmlsaXR5IC8gaW50ZXJvcCBpc3N1ZXMuIEJ1dCB0aGF0CmhvcnNlIGlzIGxv bmcgb3V0IG9mIHRoZSBiYXJuOiAmcXVvdDttaXMmcXVvdDsgKjxiPmNhbjwvYj4qIGJlIHVzZWQg aW4KbGFuZ3VhZ2UgdGFncyB1bmRlciBSRkNzIGZyb20gMTc2NiB0byA0NjQ2LiBUaGUgTFRSVSBX RyB3aXRoaW4gSUVURiBuZWVkcyB0byBkZWNpZGUKd2hhdCB0byBkbyBhYm91dCB0aGF0IGluIFJG QyA0NjQ2YmlzLiBUaGF0JiMzOTtzIGEgam9iIGZvciBJRVRGOyB3ZSBkb24mIzM5O3QKbmVlZCB0 byBjb250aW51ZSBib3RoZXJpbmcgSkFDIG1lbWJlcnMgd2l0aCBJRVRGIGlzc3Vlcy48L3NwYW4+ PC9mb250PjwvcD4KCjxwPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8 cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5QZXRlcjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+ PC9mb250PjwvcD4KCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBi b3JkZXItY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKSAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3ot dXNlLXRleHQtY29sb3I7IGJvcmRlci13aWR0aDogMXB0IG1lZGl1bSBtZWRpdW07IHBhZGRpbmc6 IDNwdCAwaW4gMGluOyI+Cgo8cD48Zm9udCBzaXplPSIyIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 Ij4KPGEgaHJlZj0ibWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRo aXMpIj5tYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9 InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KCm1hcmsuZWR3 YXJkLmRhdmlzQGdtYWlsLmNvbTwvYT5dIDxiPk9uIEJlaGFsZgpPZiA8L2I+TWFyayBEYXZpczxi cj4KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxOCwgMjAwNyA5OjIzIEFNPGJyPgo8Yj5Ubzo8 L2I+IFBldGVyIENvbnN0YWJsZTxicj4KPGI+Q2M6PC9iPiBLZW50IEthcmxzc29uOyBNaWxpY2Vu dCBLIFdld2Vya2E7IEpvaG4gQ293YW47IDxhIGhyZWY9Im1haWx0bzppc282MzlAZGt1dWcuZGsi IHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSI+aXNvNjM5QGRrdXVnLmRrPC9hPjsKPGEgaHJlZj0ibWFpbHRvOmlldGYt bGFuZ3VhZ2VzQGlhbmEub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5q cy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlldGYtbGFuZ3VhZ2VzQGlhbmEub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlzbzYzOS0yQGxvYy5nb3YiIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cgpp c282MzktMkBsb2MuZ292PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlzb2phY0Bsb2MuZ292IiB0YXJn ZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZl bnQsdGhpcykiPmlzb2phY0Bsb2MuZ292PC9hPjsgPGEgaHJlZj0ibWFpbHRvOkhIakBzdGFuZGFy ZC5ubyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIj4KCkhIakBzdGFuZGFyZC5ubzwvYT47CkxUUlUgV29ya2luZyBH cm91cDxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiAoaXNvNjM5LjI3MDgpIFJFOiBJU08gNjM5LTIg ZGVjaXNpb246ICZxdW90O21pcyZxdW90Ozwvc3Bhbj48L2ZvbnQ+PC9wPgoKPC9kaXY+PC9zcGFu PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9 InFfMTEzNDA5OGQ3YTRlZTdiZV81Ij4KCjxwPiZuYnNwOzwvcD4KCjxwIHN0eWxlPSJtYXJnaW4t Ym90dG9tOiAxMnB0OyI+VW5mb3J0dW5hdGVseSwgSVNPIGNvZGVzIGhhdmUKc29tZXdoYXQgb2Yg YW4gaW1wZWRhbmNlIG1pc21hdGNoIHdpdGggdGhlIG5lZWRzIG9mIHRoZSBJVCBjb21tdW5pdHk7 IGluCnBhcnRpY3VsYXIsIHN0YWJpbGl0eS4gVGh1cyBCQ1AgNDcgaGFzIHRvIHN0YWJpbGl6ZSB0 aG9zZSBjb2Rlczsgb25lIG9mIHRoZQptYWluIHJlYXNvbnMgZm9yIHRoZSBleGlzdGVuY2Ugb2Yg UkZDIDQ2NDYuIFdoYXQgdGhhdCBtZWFucyBpcyB0aGF0IGlmIElTTwp0cmllcyB0byBuYXJyb3cg dGhlIG1lYW5pbmcgb2YgKmFueSogY29kZSwgd2hldGhlciBpdCBpcyBhCiZxdW90O2NsYXJpZmlj YXRpb24mcXVvdDsgb3Igbm90LCB3ZSBoYXZlIHJlYWxseSBvbmx5IHR3byBjaG9pY2VzOiA8YnI+ Cjxicj4KMS4gS2VlcCB0aGUgYnJvYWRlciBzZW1hbnRpYywgd2hpY2ggZW5jb21wYXNzZXMgdGhl IG5ldyBJU08gbmFycm93IG9uZSwgb3I8YnI+CjIuIERlcHJlY2F0ZSB0aGUgY29kZSAoaW4gb25l IHdheSBvciBhbm90aGVyKS48YnI+Cjxicj4KVW5saWtlIG1hbnkgb3RoZXIgY29kZXMsICZxdW90 O21pcyZxdW90OyBpcyBvbmUgdGhhdCB3ZSBjYW4gZG8gd2l0aG91dCwgc28gIzIKd2FzIGEgcmVh c29uYWJsZSBjaG9pY2UuIDxicj4KPGJyPgpXaGF0IEkgd2FzIHRyeWluZyB0byBjb21lIHVwIHdp dGggbGFuZ3VhZ2UgdGhhdCB3ZSBjb3VsZCBhZ3JlZSBvbiBldmVuIHRob3VnaAp3ZSBoYXZlIHZl cnkgZGlmZmVyZW50IHZpZXdzIG9uIHRoZSB1dGlsaXR5IGFuZCBtZWFuaW5nIG9mICYjMzk7bWlz JiMzOTsuIEl0IHNvdW5kcwpsaWtlIHdlIGFyZSBvayBvbiB0aGUgc3VnZ2VzdGVkIGxhbmd1YWdl IG9uIHRoZSBvdGhlciB0aHJlYWQsIHNvIEkmIzM5O20gaG9waW5nCnRoYXQgd2UgY2FuIHB1dCAm cXVvdDttaXMmcXVvdDsgdG8gYmVkLjxicj4KPGJyPgpNYXJrPC9wPgoKPGRpdj4KCjxwPjxzcGFu Pk9uIDYvMTYvMDcsIDxiPlBldGVyIENvbnN0YWJsZTwvYj4KJmx0OzxhIGhyZWY9Im1haWx0bzpw ZXRlcmNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnBldGVyY29uQG1pY3Jvc29mdC5j b20KPC9hPiZndDsgd3JvdGU6PC9zcGFuPjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAx MnB0OyI+RnJvbTogS2VudCBLYXJsc3NvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzprZW50Lmth cmxzc29uMTRAY29taGVtLnNlIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5q cy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgprZW50Lmthcmxzc29uMTRAY29taGVt LnNlPC9hPl08YnI+Cjxicj4KJmd0OyBXaXRoIHRoZSAmcXVvdDtvbGQgbWlzJnF1b3Q7IG9uZSBj b3VsZCBjb3JyZWN0bHkgYXBwbHkgJiMzOTttaXMmIzM5OyBhcyBhIGxhbmd1YWdlPGJyPgomZ3Q7 IGNvZGUgZm9yIGFueSBsYW5ndWFnZTxicj4KPGJyPgpUaGF0IGhhcyAqbmV2ZXIqIGJlZW4gdGhl IGludGVudCBvZiBJU08gNjM5LiBJdCBpcyBhbiBleHRlcm5hbCBpbnRlcnByZXRhdGlvbiwKYWRt aXR0ZWRseSBwb3NzaWJsZSBiZWNhdXNlIElTTyA2Mzkgd2FzIG5vdCBmdWxseSBleHBsaWNpdCB1 cCB0byBub3cuIEJ1dCBmcm9tCnRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgSkFDLCB0aGUgJnF1b3Q7 bmV3IG1pcyZxdW90OyBpcyBleGFjdGx5IHRoZSBzYW1lCiZxdW90O21pcyZxdW90OyBhcyB0aGUg JnF1b3Q7b2xkIG1pcyZxdW90Oy4gPGJyPgo8YnI+Cjxicj4KUGV0ZXI8L3A+Cgo8L2Rpdj4KCjxw Pjxicj4KPGJyIGNsZWFyPSJhbGwiPgo8YnI+Ci0tIDxicj4KTWFyayA8L3A+PC9zcGFuPjwvZGl2 PgoKPC9zcGFuPjwvZm9udD48L2Rpdj48L2Rpdj4KCjwvZGl2PjxzcGFuIGNsYXNzPSJxIj4KCgo8 Zm9udCBzaXplPSIyIj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5r KHdpbmRvdyxldmVudCx0aGlzKSI+THRydUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KCmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj48L2Zv bnQ+PC9zcGFuPjwvYmxvY2txdW90ZT48L2Rpdj48Zm9udCBzaXplPSIyIj48YnI+PGJyIGNsZWFy PSJhbGwiPjxicj4tLSA8YnI+PHNwYW4gY2xhc3M9InNnIj5NYXJrCjwvc3Bhbj48L2ZvbnQ+Cjxi ciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_75135_6720353.1182204173775-- --===============1804691999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1804691999==-- From ltru-bounces@ietf.org Mon Jun 18 20:52:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RxV-0008NG-RU; Mon, 18 Jun 2007 20:52:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0RxU-0008Fh-4B for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 20:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0RxT-0008FZ-Qj for ltru@ietf.org; Mon, 18 Jun 2007 20:52:35 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0RxS-00041t-NV for ltru@ietf.org; Mon, 18 Jun 2007 20:52:35 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 18 Jun 2007 17:51:14 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 18 Jun 2007 17:52:33 -0700 From: Peter Constable To: Mark Davis Date: Mon, 18 Jun 2007 17:52:31 -0700 Subject: RE: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Index: Acex6iu9WrBjerd6Q5KhaCzVRemjtgAHoyHg Message-ID: References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> In-Reply-To: <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9 Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , LTRU Working Group , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832729561==" Errors-To: ltru-bounces@ietf.org --===============0832729561== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4DD4F7FNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4DD4F7FNAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Suggesting that 'root' avoids problems is, IMO, rather a bit of false econo= my. Sure, if a tag means 'some language', then content so tagged never beco= mes *incorrectly* tagged when an ID for the given language is added. But le= t's consider whether it is *usefully* tagged: changing things so that it co= uld continue to be *correctly* tagged wouldn't make it more *usefully* tagg= ed, and arguably makes it less so. To suggest that users needn't worry about their content tagged 'root' after= a new language is coded is IMO bad advice. They certainly *should* worry i= f they want their data to be useful: they'll want to re-tag the relevant co= ntent with the newly-coded ID, else they end up with data that won't compar= e. At least if they know that the addition will narrow the extension and po= tentially invalidate tagging on some of their content, they're more likely = to pay attention; what you suggest can give the impression that they don't = have any particular worry, which is not the case. A tag with the 'root' semantic can always mean anything - which means it's = nearly void of meaning and is about as useful as not having tagged it at al= l in the first place. (The 'root' semantic would be equivalent to 'not zxx'= .) That's not *usefully* tagged, but it's vacuously always going to be vali= dly tagged - big deal. At least with the 'uncoded' semantic they can use ch= ange history for the code table and the record date to derive a short list = of what languages "mis" content might be in - a pain, but that's actually m= ore useful that 'some language'. Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Monday, June 18, 2007 1:49 PM To: Peter Constable Cc: LTRU Working Group; ietf-languages@iana.org; iso639-2@loc.gov; isojac@l= oc.gov; iso639@dkuug.dk Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" I really didn't want to start a flame about this; I'm sorry if what I said = was be considered incendiary. This whole issue is not really connected with the change from part 2 to par= t 3, at all. Take your example: it is a problem with your definition of "mi= s" in BCP 47 whether "brk" were added because of 639-3 OR just because it w= ere added to ISO 639-2! It is an issue whenever new codes could be added th= at would invalidate previous usage of "mis". And the sad thing is that this instability in ISO codes is completely avoid= able. There is a perfectly good way to have the same functionality *without= * being unstable. * Have a code I'll call here "root" (to avoid any misunderstanding about= the meaning of "mis".) * Have it be valid to tag any language content with "root". * State that one SHOULD tag as narrowly as possible, thus avoid "root" i= f there is a more specific language code. This completely takes the place of the need you see for "mis", *without bei= ng unstable*. If I have some Burushaski content, where a code doesn't exist= , I tag it with "root". That is valid now, and remains valid forever, even = once "brk" is added -- whether "brk" were added because of 639-3 or just be= cause it were added to ISO 639-2. Mark On 6/18/07, Peter Constable > wrote: As far as the JAC is concerned, the intentional semantic of "mis" is what i= t has always been. As for the extension, when 639-2 was the only alpha-3 co= de, there was only one context to evaluate the extension that would be deri= ved by that intention; 639-2 did not document the extension, though at leas= t one application of 639-2 - MARC - did. With the introduction of 639-3 and= the pending introduction of 639-5 as additions to the alpha-3 space, it be= comes clear that the extension must be determined within a context: the cas= es where you'd want to use "mis" differ if you're using 639-3 rather than 6= 39-2. But for an application of a given part of 639, the change of referenc= e name has had no effect on the extension for that context: the languages e= ncompassed by "mis" in a 639-2 application, for instance, are the same as t= hey were before. When it comes to BCP 47, the change of reference name for "mis" is basicall= y irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 wi= ll change from being an application of 639-1 and -2 to being an application= of 639-1, -2 and -3. That change of context is what creates the issue wrt = interoperability of "mis" in applications of BCP 47: Under RFC 4646, Burush= aski content would be tagged "mis"; under RFC 4646bis, one would expect new= Burushaski content to be tagged "bsk". There's no basis for matching: that= 's an interop problem. And note that it has nothing to do with stability of= "mis" supposedly introduced with the name change: with or without that cha= nge, Burushaski content would be tagged differently before and after. And note that this issue exists whether one considers "old mis" to have the= semantic that Keld is stuck on, 'all languages', or the semantic that the = JAC has always intended: either way, it is the addition of 639-3 to BCP 47 = that creates an issue for uses of "mis" under BCP 47, not the name change. And even without the addition of 639-3, "mis" would have interop issues: as= suming the semantic the JAC has always assumed, the extension in the contex= t of 639-2 could narrow - inherently by the nature of the semantic - any ti= me a new entry was added; but assuming the 'all languages' semantic, one co= uld end up with comparable content tagged in non-comparable ways, "mis" and= something else. Therefore, I suggest that beating up ISO as not being in tune with the need= s of the IT community is both fruitless and baseless, and is ignoring the f= act that IETF has problems all of its own making. If IETF really wanted to = avoid any stability or interop problems related to "mis", it should never h= ave permitted its use in language tags, starting back in RFC 1766, because = "mis" has always had stability / interop issues. But that horse is long out= of the barn: "mis" *can* be used in language tags under RFCs from 1766 to = 4646. The LTRU WG within IETF needs to decide what to do about that in RFC = 4646bis. That's a job for IETF; we don't need to continue bothering JAC mem= bers with IETF issues. Peter From: mark.edward.davis@gmail.com [mail= to: mark.edward.davis@gmail.com] On Beh= alf Of Mark Davis Sent: Monday, June 18, 2007 9:23 AM To: Peter Constable Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639@dkuug.dk; ietf-languages@iana.org; i= so639-2@loc.gov; isojac@loc.gov; HHj@standard.no; LTRU Working Group Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis" Unfortunately, ISO codes have somewhat of an impedance mismatch with the ne= eds of the IT community; in particular, stability. Thus BCP 47 has to stabi= lize those codes; one of the main reasons for the existence of RFC 4646. Wh= at that means is that if ISO tries to narrow the meaning of *any* code, whe= ther it is a "clarification" or not, we have really only two choices: 1. Keep the broader semantic, which encompasses the new ISO narrow one, or 2. Deprecate the code (in one way or another). Unlike many other codes, "mis" is one that we can do without, so #2 was a r= easonable choice. What I was trying to come up with language that we could agree on even thou= gh we have very different views on the utility and meaning of 'mis'. It sou= nds like we are ok on the suggested language on the other thread, so I'm ho= ping that we can put "mis" to bed. Mark On 6/16/07, Peter Constable > wrote: From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > With the "old mis" one could correctly apply 'mis' as a language > code for any language That has *never* been the intent of ISO 639. It is an external interpretati= on, admittedly possible because ISO 639 was not fully explicit up to now. B= ut from the perspective of the JAC, the "new mis" is exactly the same "mis"= as the "old mis". Peter -- Mark _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4DD4F7FNAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Suggesting that ‘root’ avoids problems is, IMO, = rather a bit of false economy. Sure, if a tag means ‘some language’, t= hen content so tagged never becomes *incorrectly* tagged when an ID for = the given language is added. But let’s consider whether it is *usefull= y* tagged: changing things so that it could continue to be *correctly* tagged wouldn’t make it more *usefully* tagged, and arguably m= akes it less so.

 

To suggest that users needn’t worry about their conten= t tagged ‘root’ after a new language is coded is IMO bad advice. = They certainly *should* worry if they want their data to be useful: they&= #8217;ll want to re-tag the relevant content with the newly-coded ID, else they end = up with data that won’t compare. At least if they know that the addition will narrow the extension and potentially invalidate tagging on some of the= ir content, they’re more likely to pay attention; what you suggest can g= ive the impression that they don’t have any particular worry, which is no= t the case.

 

A tag with the ‘root’ semantic can always mean anything – which means it’s nearly void of meaning and is about= as useful as not having tagged it at all in the first place. (The ‘root&= #8217; semantic would be equivalent to ‘not zxx’.) That’s not *<= b>usefully* tagged, but it’s vacuously always going to be validly tagged – = big deal. At least with the ‘uncoded’ semantic they can use change histor= y for the code table and the record date to derive a short list of what languages= “mis” content might be in – a pain, but that’s actually more useful t= hat ‘some language’.

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Beha= lf Of Mark Davis
Sent: Monday, June 18, 2007 1:49 PM
To: Peter Constable
Cc: LTRU Working Group; ietf-languages@iana.org; iso639-2@loc.gov; isojac@loc.gov; iso639@dkuug.dk
Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis"

 

I really didn't want = to start a flame about this; I'm sorry if what I said was be considered incendiary.<= br>
This whole issue is not really connected with the change from part 2 to par= t 3, at all. Take your example: it is a problem with your definition of "mis" in BCP 47 whether "brk" were added because of 639= -3 OR just because it were added to ISO 639-2! It is an issue whenever new cod= es could be added that would invalidate previous usage of "mis".
And the sad thing is that this instability in ISO codes is completely avoidable. There is a perfectly good way to have the same functionality *without* being unstable.

  • Have a code = I'll call here "root" (to avoid any misunderstanding about the meaning of "mis".)
  • Have it be v= alid to tag any language content with "root".
  • State that o= ne SHOULD tag as narrowly as possible, thus avoid "root" if the= re is a more specific language code.

This completely takes the place of the need you see for "mis", *withou= t being unstable*. If I have some Burushaski content, where a code doesn't exist, I tag it with "root". That is valid n= ow, and remains valid forever, even once "brk" is added -- whether "brk" were added because of 639-3 or just because it were added t= o ISO 639-2.

Mark

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

As far as the JAC is conc= erned, the intentional semantic of "mis" is what it has always been. As = for the extension, when 639-2 was the only alpha-3 code, there was only one con= text to evaluate the extension that would be derived by that intention; 639-2 di= d not document the extension, though at least one application of 639-2 –= ; MARC – did. With the introduction of 639-3 and the pending introducti= on of 639-5 as additions to the alpha-3 space, it becomes clear that the exten= sion must be determined within a context: the cases where you'd want to use "mis" differ if you're using 639-3 rather than 639-2. But for an application of a given part of 639, the change of reference name has had no effect on the extension for that context: the languages encompassed by "mis" in a 639-2 application, for instance, are the same as they = were before.

 <= /p>

When it comes to BCP 47, = the change of reference name for "mis" is basically irrelevant becaus= e there is a much bigger issue: in RFC4646bis, BCP 47 will change from being = an application of 639-1 and -2 to being an application of 639-1, -2 and -3. Th= at change of context is what creates the issue wrt interoperability of "mis" in applications of BCP 47: Under RFC 4646, Burushaski conte= nt would be tagged "mis"; under RFC 4646bis, one would expect new Burushaski content to be tagged "bsk". There's no basis for match= ing: that's an interop problem. And note that it has nothing to do with stabilit= y of "mis" supposedly introduced with the name change: with or without that change, Burushaski content would be tagged differently before and afte= r.

 <= /p>

And note that this issue = exists whether one considers "old mis" to have the semantic that Keld is stuck on, 'all languages', or the semantic that the JAC has always intended= : either way, it is the addition of 639-3 to BCP 47 that creates an issue for uses of "mis" under BCP 47, not the name change.

 <= /p>

And even without the addi= tion of 639-3, "mis" would have interop issues: assuming the semantic = the JAC has always assumed, the extension in the context of 639-2 could narrow – inherently by the nature of the semantic – any time a new ent= ry was added; but assuming the 'all languages' semantic, one could end up with comparable content tagged in non-comparable ways, "mis" and somet= hing else.

 <= /p>

Therefore, I suggest that beating up ISO as not being in tune with the needs of the IT community is b= oth fruitless and baseless, and is ignoring the fact that IETF has problems all= of its own making. If IETF really wanted to avoid any stability or interop problems related to "mis", it should never have permitted its use= in language tags, starting back in RFC 1766, because "mis" has alway= s had stability / interop issues. But that horse is long out of the barn: "mis" *can* be used in language tags under RFCs from 1766 = to 4646. The LTRU WG within IETF needs to decide what to do about that in RFC 4646bis. That's a job for IETF; we don't need to continue bothering JAC mem= bers with IETF issues.

 <= /p>

 <= /p>

Peter

 <= /p>

From: m= ark.edward.davis@gmail.com [mailto: mark.edward.davis@gmail.com] On Behalf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639@dkuug.dk; ietf-languages@ia= na.org; iso639-2@loc.gov;= isojac@loc.gov; HHj@standard.no; LTRU= Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"

 

Unfortun= ately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those cod= es; one of the main reasons for the existence of RFC 4646. What that means is t= hat if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices:

1. Keep the broader semantic, which encompasses the new ISO narrow one, or<= br> 2. Deprecate the code (in one way or another).

Unlike many other codes, "mis" is one that we can do without, so = #2 was a reasonable choice.

What I was trying to come up with language that we could agree on even thou= gh we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed.

Mark

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

From: Ke= nt Karlsson [mailto: kent.karlsson14@comhem.se]

> With the "old mis" one could correctly apply 'mis' as a lang= uage
> code for any language

That has *never* been the intent of ISO 639. It is an external interpretati= on, admittedly possible because ISO 639 was not fully explicit up to now. But f= rom the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis".


Peter




--
Mark


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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357955FB4DD4F7FNAEXMSGC117re_-- --===============0832729561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0832729561==-- From ltru-bounces@ietf.org Mon Jun 18 21:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ScA-0003ci-J8; Mon, 18 Jun 2007 21:34:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Sc8-0003bC-TO for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 21:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Sc8-0003b4-Jw for ltru@ietf.org; Mon, 18 Jun 2007 21:34:36 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Sc6-0003RW-AF for ltru@ietf.org; Mon, 18 Jun 2007 21:34:36 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0Sc5-0006a7-4f; Mon, 18 Jun 2007 21:34:33 -0400 Date: Mon, 18 Jun 2007 21:34:33 -0400 To: Mark Davis Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619013433.GA15048@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > We added extlang to allow ourselves the freedom to make choices > when 639-3 came along. We *very clearly did not define its meaning*, > because we didn't know what 639-3 was finally going to look like, Not so much. We had an excellent idea of what 639-3 would both look and actually be like when 4646 was finalized. We couldn't include 639-3 or extlangs because 639-3 itself was not yet final. > nor did we have agreement on what we should actually do. We had at least the consensus of silence; at least, I don't remember any complaints at the time. Remember that the development of 4646 started at least a year before LTRU was formally created. > We *already* had macrolanguages with ISO 639-2 in RFC 4646 and we *did > not* use extlang for them: examples are "sr", "hr", "nb", etc. (Rather, these are examples of languages *encompassed* by macrolanguages, henceforth "encompassed languages". I realize that's just a slip.) > We are not going to (and cannot) be forcing users to encode nb as no-nb, > nor sr as sh-sr. Nobody has ever proposed that. Language subtags coming from 639-1 or 639-2 will not change, even if 639-3 says they encode encompassed languages. > When we ("Google") tried implementing matching with "zh-yue" and others, > we found it made things *more* difficult, not less. Respectfully I suggest that because you ("Google") assign tags to incoming rather than outgoing content, your use of BCP 47 is essentially private rather than in interchange. That makes it potentially important, but definitely not prototypical. > Matching "zh" and "yue" is not something you want to do > automatically. Moreover, because of #2 we had to have a mechanism for > dealing with macrolanguages in RFC 4646 *anyway*. Very plausible in your circumstances. But note that Yue (Cantonese) content is *already* properly tagged "zh-yue" on precisely the theory that's being applied to 639-3 encompassed languages. I realize that this cause is probably not important to you, because you can (comparatively) easily change all "zh-yue" tags to "yue", but this is not the case for other users of BCP 47 on and off the Internet, who will never even hear about the change. > Thus to make a proposed change from 4646 to use the extlang mechanism > for languages that have macrolanguages, we need a very compelling > case that the additional complication solves more problems than it > creates. We haven't seen that yet, and certainly have no consensus > that it is the case. On the contrary, the burden of persuasion is with you. Tags like zh-yue are already present in 4646, and it's up to you to provide a convincing argument to deprecate them. Furthermore, LTRU and its ad hoc predecessor has been assuming the extlang structure since at least 2004. Derailing that is what will take a "very compelling case". > A. [Don't use extlangs.] I continue in opposition to this. > B. (optional) Add a field Macrolanguage: to the language subtag > registry. I am not opposed to this, precisely because encompassed languages and the corresponding macrolanguage cannot be identified syntactically. -- May the hair on your toes never fall out! John Cowan --Thorin Oakenshield (to Bilbo) cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 18 23:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0U5E-00045k-On; Mon, 18 Jun 2007 23:08:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0U5D-00045b-NN for ltru-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 23:08:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0U5D-00045T-DY for ltru@ietf.org; Mon, 18 Jun 2007 23:08:43 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0U5C-00072W-5P for ltru@ietf.org; Mon, 18 Jun 2007 23:08:43 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 18 Jun 2007 20:07:21 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Mon, 18 Jun 2007 20:08:41 -0700 From: Peter Constable To: LTRU Working Group Date: Mon, 18 Jun 2007 20:08:26 -0700 Subject: RE: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Thread-Topic: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Thread-Index: AceyEgJBdCoI5q4ORWyDkOjoaZMSKQADGtTQ Message-ID: References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> In-Reply-To: <20070619013433.GA15048@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org] > But note that Yue (Cantonese) > content is *already* properly tagged "zh-yue" on precisely > the theory that's being applied to 639-3 encompassed > languages. Just to clarify something, in case anyone isn't familiar or doesn't remembe= r: note that the tag "zh-yue" was not proposed because a scheme based on 63= 9-3 macrolanguages was anticipated. Rather, this and other tags were regist= ered several years before the notion of macrolanguages was first considered= for 639-3. In fact, the other way around: it was this and other similar re= gistered language tags that led to the idea of macrolanguages for 639-3. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOX-0006iJ-Vf; Tue, 19 Jun 2007 00:32:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0VOW-0006i1-QE for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOW-0006ht-GV for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VOU-0006Zx-Dj for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J4WaUB024530 for ; Tue, 19 Jun 2007 13:32:39 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2c06_1b042308_1e1e_11dc_8af6_0014221f2a2d; Tue, 19 Jun 2007 13:32:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55962) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 13:30:41 +0900 Message-Id: <6.0.0.20.2.20070619111443.0a1868a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 11:17:10 +0900 To: "Debbie Garside" , "'Frank Ellermann'" , From: Martin Duerst Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 In-Reply-To: <200706181152.l5IBqVkp008391@scmailgw2.scop.aoyama.ac.jp> References: <6.0.0.20.2.20070618185934.03b95010@localhost> <200706181152.l5IBqVkp008391@scmailgw2.scop.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 20:52 07/06/18, Debbie Garside wrote: >Martin wrote: > >> No. There is no old registry. There is only one registry. > >I would have to disagree here. I can see applications for using an "old" >registry in order to update to a "new" registry. Hello Debbie, I'm not sure I can parse the above sentence correctly. Are you saying that somebody could, now, make an application for registration on http://www.iana.org/assignments/language-tags according to RFC 3066? At http://www.iana.org/numbers.html#L, it explicitly says "No further registrations in this registry.". Or are you talking about something else? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOY-0006iN-1h; Tue, 19 Jun 2007 00:32:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0VOX-0006iE-7j for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOW-0006i6-UW for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VOV-0006Zz-0K for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J4Wf7c016029 for ; Tue, 19 Jun 2007 13:32:41 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1b22_1e1aa544_1e1e_11dc_86d3_0014221fa3c9; Tue, 19 Jun 2007 13:32:41 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55962) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 13:30:46 +0900 Message-Id: <6.0.0.20.2.20070619120110.05e2fec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 12:21:11 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 In-Reply-To: <46766F0B.19B6@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@localhost> <46766F0B.19B6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Hollenbeck, Scott" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 20:39 07/06/18, Frank Ellermann wrote: >Martin Duerst wrote: > > [I've stripped "ietf-provreg" from the Cc: list] >> Randy made the procedural argument (both RFC 3066 and RFC 4646 >> are BCPs). > >Just to clarify, I think you or Randy mean "RFC 3066 used to be >a BCP before RFC 4646 obsoleted it". Well, yes, very good point. In that sense, using RFC 3066 instead of RFC 4646 is actually a bad idea, it means that you are going to Draft Standard with a reference to something that was a BCP rather than with a reference to an actual BCP. >> I have absolutely no clue what could break in an implementation >> when using a tag that became legal in RFC 4646. > >Matching is tricky in the presence of script subtags (and other >less likely scenarios), it was one line in RFC 3066, now it's a >separate document. Yes, that's a valid point (but probably the only one). That means that in RFC 4930, it might have said something like "this protocol uses Basic Filtering as defined in RFC 4647 for matching language tags". But my guess is that not even this is needed. The protocol just sends languages that the server has available, and the client is free to use that to pick whichever it thinks might work (including, e.g., showing the list to a user). Also, the protocol has some elements where the language can be indicated. Here is an example, taken directly from the spec: - A element containing a human-readable description of the response code. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). There is nothing in terms of matching here, just simple identfication. [As an aside, there are several points in the above text that are suboptimal. The first is the use of lang instead of xml:lang. (Of course, that's difficult to change when going to Draft, it should have been cought much earlier.) The second is the last sentence, which seems to prescribe a value for an attribute that is optional. It would be better if it were reworded as "If not specified, the implied attribute value is "en" (English)." A MUST might be appropriate e.g. to say that the content of the element has to be English in the absence of a lang attribute. Using 'implied' is much clearer, because it's the terminology that XML is using. The third problem is the use of "en" rather than "i-default". The later is specifically defined for this fallback purpose. >It makes perfect sense to exclude some constructs. When I try >the language option of a "popular" search engine I won't find >de-1996 pages while looking for de, or en-GB-oed pages while >looking for en (I'm too lazy to check what it was, maybe both). It makes perfect sense for some servers to exclude some languages, to translate into all languages that even RFC 3066 allows for tagging would be quite expensive. But that has nothing to do with the question of which spec to references, it is purely an implementation/data issue. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOX-0006iJ-Vf; Tue, 19 Jun 2007 00:32:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0VOW-0006i1-QE for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOW-0006ht-GV for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VOU-0006Zx-Dj for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J4WaUB024530 for ; Tue, 19 Jun 2007 13:32:39 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2c06_1b042308_1e1e_11dc_8af6_0014221f2a2d; Tue, 19 Jun 2007 13:32:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55962) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 13:30:41 +0900 Message-Id: <6.0.0.20.2.20070619111443.0a1868a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 11:17:10 +0900 To: "Debbie Garside" , "'Frank Ellermann'" , From: Martin Duerst Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 In-Reply-To: <200706181152.l5IBqVkp008391@scmailgw2.scop.aoyama.ac.jp> References: <6.0.0.20.2.20070618185934.03b95010@localhost> <200706181152.l5IBqVkp008391@scmailgw2.scop.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 20:52 07/06/18, Debbie Garside wrote: >Martin wrote: > >> No. There is no old registry. There is only one registry. > >I would have to disagree here. I can see applications for using an "old" >registry in order to update to a "new" registry. Hello Debbie, I'm not sure I can parse the above sentence correctly. Are you saying that somebody could, now, make an application for registration on http://www.iana.org/assignments/language-tags according to RFC 3066? At http://www.iana.org/numbers.html#L, it explicitly says "No further registrations in this registry.". Or are you talking about something else? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOY-0006iN-1h; Tue, 19 Jun 2007 00:32:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0VOX-0006iE-7j for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOW-0006i6-UW for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VOV-0006Zz-0K for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J4Wf7c016029 for ; Tue, 19 Jun 2007 13:32:41 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1b22_1e1aa544_1e1e_11dc_86d3_0014221fa3c9; Tue, 19 Jun 2007 13:32:41 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55962) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 13:30:46 +0900 Message-Id: <6.0.0.20.2.20070619120110.05e2fec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 12:21:11 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 In-Reply-To: <46766F0B.19B6@xyzzy.claranet.de> References: <046F43A8D79C794FA4733814869CDF0791702D@dul1wnexmb01.vcorp.ad.vrsn.com> <46764588.6AC6@xyzzy.claranet.de> <6.0.0.20.2.20070618185934.03b95010@localhost> <46766F0B.19B6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Hollenbeck, Scott" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 20:39 07/06/18, Frank Ellermann wrote: >Martin Duerst wrote: > > [I've stripped "ietf-provreg" from the Cc: list] >> Randy made the procedural argument (both RFC 3066 and RFC 4646 >> are BCPs). > >Just to clarify, I think you or Randy mean "RFC 3066 used to be >a BCP before RFC 4646 obsoleted it". Well, yes, very good point. In that sense, using RFC 3066 instead of RFC 4646 is actually a bad idea, it means that you are going to Draft Standard with a reference to something that was a BCP rather than with a reference to an actual BCP. >> I have absolutely no clue what could break in an implementation >> when using a tag that became legal in RFC 4646. > >Matching is tricky in the presence of script subtags (and other >less likely scenarios), it was one line in RFC 3066, now it's a >separate document. Yes, that's a valid point (but probably the only one). That means that in RFC 4930, it might have said something like "this protocol uses Basic Filtering as defined in RFC 4647 for matching language tags". But my guess is that not even this is needed. The protocol just sends languages that the server has available, and the client is free to use that to pick whichever it thinks might work (including, e.g., showing the list to a user). Also, the protocol has some elements where the language can be indicated. Here is an example, taken directly from the spec: - A element containing a human-readable description of the response code. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). There is nothing in terms of matching here, just simple identfication. [As an aside, there are several points in the above text that are suboptimal. The first is the use of lang instead of xml:lang. (Of course, that's difficult to change when going to Draft, it should have been cought much earlier.) The second is the last sentence, which seems to prescribe a value for an attribute that is optional. It would be better if it were reworded as "If not specified, the implied attribute value is "en" (English)." A MUST might be appropriate e.g. to say that the content of the element has to be English in the absence of a lang attribute. Using 'implied' is much clearer, because it's the terminology that XML is using. The third problem is the use of "en" rather than "i-default". The later is specifically defined for this fallback purpose. >It makes perfect sense to exclude some constructs. When I try >the language option of a "popular" search engine I won't find >de-1996 pages while looking for de, or en-GB-oed pages while >looking for en (I'm too lazy to check what it was, maybe both). It makes perfect sense for some servers to exclude some languages, to translate into all languages that even RFC 3066 allows for tagging would be quite expensive. But that has nothing to do with the question of which spec to references, it is purely an implementation/data issue. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOb-0006l6-4u; Tue, 19 Jun 2007 00:32:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0VOY-0006iZ-DE for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VOY-0006iQ-2y for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:46 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VOW-0006bN-CV for ltru@lists.ietf.org; Tue, 19 Jun 2007 00:32:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J4Whp0016041 for ; Tue, 19 Jun 2007 13:32:43 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2b97_1f06ca96_1e1e_11dc_8598_0014221f2a2d; Tue, 19 Jun 2007 13:32:42 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55962) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 13:30:47 +0900 Message-Id: <6.0.0.20.2.20070619122139.0b4df880@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 12:40:31 +0900 To: "Hollenbeck, Scott" , "Stephane Bortzmeyer" , From: Martin Duerst Subject: Re: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930 In-Reply-To: <046F43A8D79C794FA4733814869CDF0701DE53EA@dul1wnexmb01.vcor p.ad.vrsn.com> References: <20070617192652.GA18085@sources.org> <046F43A8D79C794FA4733814869CDF0701DE53EA@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 21:39 07/06/18, Hollenbeck, Scott wrote: >After a private exchange with Randy Presuhn of the LTRU working group I >realized it might be helpful if I provide more info to explain why 4930 >references 3066 instead of 4646. First, let me confirm that this wasn't >an oversight. It was a conscious decision made with the concurrence of >the IESG as we looked at the normative references and the standards >track status of those references. Okay, but on hindsight, and looking at things in detail, I still think that this decision was wrong, and that it shouldn't be repeated. >Rationale: > >1. 4930 is the draft standard version of 3730, updated to document >implementation experience with 3730. 3730 references 3066. The first >drafts of what would become 4930 referenced 3066 before 4646 was >approved and published. Implementers of 3730 and 4930 wrote code per >3066. If you could explain how writing code per 3066 and writing code per 4646 would lead to any difference in the actual code or the observable protocol behavior, that would help us to accept this point. >2. 3730 and 4930 include a language tag reference because language tags >are used within XML Schema elements. The October 2004 edition of the >normative XML Schema datatypes reference cites 3066: > >http://www.w3.org/TR/xmlschema-2/#language If you look at this, you will easily see that: - The lexical space defined is in no conflict at all with the syntax of RFC 4646. - RFC 4930, in its normative prose, only says that language tags must be "structured as documented in [RFC3066]". While RFC 3066 didn't use these terms, it essentially means that they must be "RFC 3066 well-formed", not "RFC 3066 valid". The only point you might be able to claim here is that changing this to RFC 4646 might create a requirement for implementations to check for RFC 4646 well-formedness, which is admittedly a bit tighter than RFC 3066. But the MUST is on the sender, where we can assume that only valid stuff is used anyway, and you have no error message for non-well-strucured-language-code, which makes sense because the usual behavior, "language not available", is just good enough. >Consistency was thus thought to be a good thing. The problem is that with this, you may have excluded a lot of languages from potentially being used in your protocol, and you have created the impression that updating from RFC 3066 to RFC 4646 is a major undertaking, which in most cases, it is not. >If this were new work >I'd agree that 4646 would be the more appropriate reference, but that >would also depend on the XML specifications picking up 4646 as well. XML already has (see http://www.w3.org/TR/REC-xml/#sec-lang-tag). For a previous version (http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag), it already says "RFC 3066 or its successor". As for XML Schema, I'm very sure they'll make the move. A previous version was on RFC 1766. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#language If in doubt, it would have been easy for the WG or the IESG to check with W3C. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 00:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Vo2-0002mg-Rc; Tue, 19 Jun 2007 00:59:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Vo1-0002mX-A6 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Vo1-0002mO-0a for ltru@ietf.org; Tue, 19 Jun 2007 00:59:05 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Vnz-0004Jr-Ok for ltru@ietf.org; Tue, 19 Jun 2007 00:59:04 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 18 Jun 2007 21:57:43 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Mon, 18 Jun 2007 21:59:03 -0700 From: Peter Constable To: Peter Constable , LTRU Working Group Date: Mon, 18 Jun 2007 21:58:48 -0700 Subject: RE: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Topic: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" Thread-Index: AcexxPslZyJqWBveROWa6SXMDO/00wAAe53AABnGobA= Message-ID: References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Peter Constable [mailto:petercon@microsoft.com] Sent: Monday, June 18, 2007 10:17 AM > And note that this issue exists whether one considers > "old mis" to have the semantic that Keld is stuck on... My sincere apologies for having gotten these Swedes mixed up. I should have= referred to Kent Karlsson here, not Keld (who, I don't think, is even acti= ve here). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 01:48:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Wa4-0000ED-Ew; Tue, 19 Jun 2007 01:48:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Wa3-0000E2-6b for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 01:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Wa2-0000C0-MG for ltru@ietf.org; Tue, 19 Jun 2007 01:48:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0WZz-0005z8-Rv for ltru@ietf.org; Tue, 19 Jun 2007 01:48:42 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J5maX0027705 for ; Tue, 19 Jun 2007 14:48:36 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2c0e_b918c6fc_1e28_11dc_80ae_0014221f2a2d; Tue, 19 Jun 2007 14:48:36 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:34963) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 14:46:41 +0900 Message-Id: <6.0.0.20.2.20070619144745.03bc0e40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 14:48:12 +0900 To: Peter Constable , Peter Constable , LTRU Working Group From: Martin Duerst Subject: RE: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <20070613205820.GL4585@mercury.ccil.org> <30b660a20706131455w2adb40fbt233041fbc6ed27e5@mail.gmail.com> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 13:58 07/06/19, Peter Constable wrote: >From: Peter Constable [mailto:petercon@microsoft.com] >Sent: Monday, June 18, 2007 10:17 AM > >> And note that this issue exists whether one considers >> "old mis" to have the semantic that Keld is stuck on... > >My sincere apologies for having gotten these Swedes mixed up. I should have >referred to Kent Karlsson here, not Keld (who, I don't think, is even >active here). And who isn't Swedish, but Danish, as far as I know. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 02:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ws4-0005KO-7Y; Tue, 19 Jun 2007 02:07:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0Ws2-0005KG-Ko for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 02:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ws1-0005K5-W7 for ltru@ietf.org; Tue, 19 Jun 2007 02:07:17 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ws0-0001Sd-Lx for ltru@ietf.org; Tue, 19 Jun 2007 02:07:17 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070619060716.FTZD3934.mta11.adelphia.net@DGBP7M81>; Tue, 19 Jun 2007 02:07:16 -0400 Message-ID: <003701c7b238$16124fc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Date: Mon, 18 Jun 2007 23:07:15 -0700 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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John did a fine job articulating most of my position. Anything not explicitly responded to here is +1. John Cowan wrote: > Mark Davis scripsit: > >> We added extlang to allow ourselves the freedom to make choices when >> 639-3 came along. We *very clearly did not define its meaning*, because >> we didn't know what 639-3 was finally going to look like, > > Not so much. We had an excellent idea of what 639-3 would both look and > actually be like when 4646 was finalized. We couldn't include 639-3 or > extlangs because 639-3 itself was not yet final. In particular, we knew there would be macrolanguages and encompassed languages. This was spelled out by Peter Constable on 2004-01-30 in a post which laid out the extlang concept for the first time: http://www.alvestrand.no/pipermail/ietf-languages/2004-January/001658.html >> nor did we have agreement on what we should actually do. > > We had at least the consensus of silence; at least, I don't remember any > complaints at the time. Remember that the development of 4646 started at > least a year before LTRU was formally created. I thought it was stronger than that, that just about everyone's expectation and understanding was that extlangs were intended for encompassed languages, and that encompassed languages would be represented by extlangs. Tags like "zh-cmn" were registered at ietf-languages specifically so they would conform to this well-understood model. >> Matching "zh" and "yue" is not something you want to do automatically. That's only half true. All Cantonese is Chinese, and since it's only been possible up to this point to tag Cantonese as "zh-something", it's reasonable to assume that much of it will continue to be tagged as "zh-something" in the future. >> B. (optional) Add a field Macrolanguage: to the language subtag registry. > > I am not opposed to this, precisely because encompassed languages and the > corresponding macrolanguage cannot be identified syntactically. So, for example: Type: language Subtag: qvc Description: Cajamarca Quechua Description: Quechua, Cajamarca Added: 20xx-xx-xx Macrolanguage: que Would content in Cajamarca Quechua be required to be tagged as "qvc", or would "qu" also be acceptable? (We all know "qu" would be widely used.) Would matching engines be permitted to perform one- or two-way matching between "qvc" and "qu"? What about users who expect we will go through with the "qu-qvc" model, and the Web pages that have already started listing such tags? (See www.udhrinunicode.org, for instance.) Would all this require an update to 4647? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 05:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aA9-0004g1-Ne; Tue, 19 Jun 2007 05:38:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0aA8-0004fw-Rr for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 05:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aA8-0004fo-II for ltru@lists.ietf.org; Tue, 19 Jun 2007 05:38:12 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0aA5-000058-4V for ltru@lists.ietf.org; Tue, 19 Jun 2007 05:38:12 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 19 Jun 2007 10:38:06 +0100 From: "Debbie Garside" To: , "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 Date: Tue, 19 Jun 2007 10:37:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.0.0.20.2.20070619111443.0a1868a0@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AceyKwT33cBIxoh+T+mJ0hE+X0MmxwAKcBvg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Message-Id: Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Martin No I did not mean to register new subtags according to 3066. What I mean is that I can see an application for doing (say) a transaction within a database that will bring out all records that match the Registry as it stood in the 3066 era. Perhaps in a housekeeping/update routine. Is there a way to pull that historical registry once ISO 639-3 is added? Best regards Debbie > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 19 June 2007 03:17 > To: Debbie Garside; 'Frank Ellermann'; ltru@lists.ietf.org > Cc: ietf-provreg@cafax.se > Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 > > At 20:52 07/06/18, Debbie Garside wrote: > >Martin wrote: > > > >> No. There is no old registry. There is only one registry. > > > >I would have to disagree here. I can see applications for > using an "old" > >registry in order to update to a "new" registry. > > Hello Debbie, > > I'm not sure I can parse the above sentence correctly. Are > you saying that somebody could, now, make an application for > registration on http://www.iana.org/assignments/language-tags > according to RFC 3066? > At http://www.iana.org/numbers.html#L, it explicitly says "No > further registrations in this registry.". > Or are you talking about something else? > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 05:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aNH-00073z-2B; Tue, 19 Jun 2007 05:51:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0aNF-00073j-C3 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 05:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aNF-00073b-2O for ltru@ietf.org; Tue, 19 Jun 2007 05:51:45 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0aNE-00045W-2O for ltru@ietf.org; Tue, 19 Jun 2007 05:51:45 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 19 Jun 2007 10:51:40 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" Date: Tue, 19 Jun 2007 10:51:30 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcexxPslZyJqWBveROWa6SXMDO/00wAAe53AACQd8hA= X-Spam-Score: 1.3 (+) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b Message-Id: Cc: ietf-languages@iana.org, iso639-2@loc.gov, isojac@loc.gov, iso639@dkuug.dk Subject: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953638798==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0953638798== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01C7B25F.CBC103D0" This is a multi-part message in MIME format. ------=_NextPart_000_0178_01C7B25F.CBC103D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 _____ From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Peter Constable Sent: 18 June 2007 18:17 To: LTRU Working Group Cc: ietf-languages@iana.org; iso639-2@loc.gov; isojac@loc.gov; iso639@dkuug.dk Subject: RE: (iso639.2708) RE: ISO 639-2 decision: "mis" As far as the JAC is concerned, the intentional semantic of "mis" is what it has always been. As for the extension, when 639-2 was the only alpha-3 code, there was only one context to evaluate the extension that would be derived by that intention; 639-2 did not document the extension, though at least one application of 639-2 - MARC - did. With the introduction of 639-3 and the pending introduction of 639-5 as additions to the alpha-3 space, it becomes clear that the extension must be determined within a context: the cases where you'd want to use "mis" differ if you're using 639-3 rather than 639-2. But for an application of a given part of 639, the change of reference name has had no effect on the extension for that context: the languages encompassed by "mis" in a 639-2 application, for instance, are the same as they were before. When it comes to BCP 47, the change of reference name for "mis" is basically irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 will change from being an application of 639-1 and -2 to being an application of 639-1, -2 and -3. That change of context is what creates the issue wrt interoperability of "mis" in applications of BCP 47: Under RFC 4646, Burushaski content would be tagged "mis"; under RFC 4646bis, one would expect new Burushaski content to be tagged "bsk". There's no basis for matching: that's an interop problem. And note that it has nothing to do with stability of "mis" supposedly introduced with the name change: with or without that change, Burushaski content would be tagged differently before and after. And note that this issue exists whether one considers "old mis" to have the semantic that Keld is stuck on, 'all languages', or the semantic that the JAC has always intended: either way, it is the addition of 639-3 to BCP 47 that creates an issue for uses of "mis" under BCP 47, not the name change. And even without the addition of 639-3, "mis" would have interop issues: assuming the semantic the JAC has always assumed, the extension in the context of 639-2 could narrow - inherently by the nature of the semantic - any time a new entry was added; but assuming the 'all languages' semantic, one could end up with comparable content tagged in non-comparable ways, "mis" and something else. Therefore, I suggest that beating up ISO as not being in tune with the needs of the IT community is both fruitless and baseless, and is ignoring the fact that IETF has problems all of its own making. If IETF really wanted to avoid any stability or interop problems related to "mis", it should never have permitted its use in language tags, starting back in RFC 1766, because "mis" has always had stability / interop issues. But that horse is long out of the barn: "mis" *can* be used in language tags under RFCs from 1766 to 4646. The LTRU WG within IETF needs to decide what to do about that in RFC 4646bis. That's a job for IETF; we don't need to continue bothering JAC members with IETF issues. Peter From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis Sent: Monday, June 18, 2007 9:23 AM To: Peter Constable Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639@dkuug.dk; ietf-languages@iana.org; iso639-2@loc.gov; isojac@loc.gov; HHj@standard.no; LTRU Working Group Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis" Unfortunately, ISO codes have somewhat of an impedance mismatch with the needs of the IT community; in particular, stability. Thus BCP 47 has to stabilize those codes; one of the main reasons for the existence of RFC 4646. What that means is that if ISO tries to narrow the meaning of *any* code, whether it is a "clarification" or not, we have really only two choices: 1. Keep the broader semantic, which encompasses the new ISO narrow one, or 2. Deprecate the code (in one way or another). Unlike many other codes, "mis" is one that we can do without, so #2 was a reasonable choice. What I was trying to come up with language that we could agree on even though we have very different views on the utility and meaning of 'mis'. It sounds like we are ok on the suggested language on the other thread, so I'm hoping that we can put "mis" to bed. Mark On 6/16/07, Peter Constable > wrote: From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > With the "old mis" one could correctly apply 'mis' as a language > code for any language That has *never* been the intent of ISO 639. It is an external interpretation, admittedly possible because ISO 639 was not fully explicit up to now. But from the perspective of the JAC, the "new mis" is exactly the same "mis" as the "old mis". Peter -- Mark ------=_NextPart_000_0178_01C7B25F.CBC103D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

From: = ietf-languages-bounces@alvestrand.no=20 [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of = Peter=20 Constable
Sent: 18 June 2007 18:17
To: LTRU = Working=20 Group
Cc: ietf-languages@iana.org; iso639-2@loc.gov; = isojac@loc.gov;=20 iso639@dkuug.dk
Subject: RE: (iso639.2708) RE: ISO 639-2 = decision:=20 "mis"

As=20 far as the JAC is concerned, the intentional semantic of = “mis” is what it has=20 always been. As for the extension, when 639-2 was the only alpha-3 = code, there=20 was only one context to evaluate the extension that would be derived = by that=20 intention; 639-2 did not document the extension, though at least one=20 application of 639-2 – MARC – did. With the introduction = of 639-3 and the=20 pending introduction of 639-5 as additions to the alpha-3 space, it = becomes=20 clear that the extension must be determined within a context: the = cases where=20 you’d want to use “mis” differ if you’re using = 639-3 rather than 639-2. But=20 for an application of a given part of 639, the change of reference = name has=20 had no effect on the extension for that context: the languages = encompassed by=20 “mis” in a 639-2 application, for instance, are the same = as they were=20 before.

 

When=20 it comes to BCP 47, the change of reference name for “mis” = is basically=20 irrelevant because there is a much bigger issue: in RFC4646bis, BCP 47 = will=20 change from being an application of 639-1 and -2 to being an = application of=20 639-1, -2 and -3. That change of context is what creates the issue wrt = interoperability of “mis” in applications of BCP 47: Under = RFC 4646,=20 Burushaski content would be tagged “mis”; under RFC = 4646bis, one would expect=20 new Burushaski content to be tagged “bsk”. There’s = no basis for matching:=20 that’s an interop problem. And note that it has nothing to do = with stability=20 of “mis” supposedly introduced with the name change: with = or without that=20 change, Burushaski content would be tagged differently before and = after.=20

 

And=20 note that this issue exists whether one considers “old = mis” to have the=20 semantic that Keld is stuck on, ‘all languages’, or the = semantic that the JAC=20 has always intended: either way, it is the addition of 639-3 to BCP 47 = that=20 creates an issue for uses of “mis” under BCP 47, not the = name change.=20

 

And=20 even without the addition of 639-3, “mis” would have = interop issues: assuming=20 the semantic the JAC has always assumed, the extension in the context = of 639-2=20 could narrow – inherently by the nature of the semantic – = any time a new entry=20 was added; but assuming the ‘all languages’ semantic, one = could end up with=20 comparable content tagged in non-comparable ways, “mis” = and something=20 else.

 

Therefore,=20 I suggest that beating up ISO as not being in tune with the needs of = the IT=20 community is both fruitless and baseless, and is ignoring the fact = that IETF=20 has problems all of its own making. If IETF really wanted to avoid any = stability or interop problems related to “mis”, it should = never have permitted=20 its use in language tags, starting back in RFC 1766, because = “mis” has always=20 had stability / interop issues. But that horse is long out of the = barn: “mis”=20 *can* be used in language tags under RFCs from 1766 to 4646. = The LTRU=20 WG within IETF needs to decide what to do about that in RFC 4646bis. = That’s a=20 job for IETF; we don’t need to continue bothering JAC members = with IETF=20 issues.

 

 

Peter

 

From:=20 mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On = Behalf=20 Of Mark Davis
Sent: Monday, June 18, 2007 9:23 = AM
To:=20 Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John = Cowan;=20 iso639@dkuug.dk; ietf-languages@iana.org; iso639-2@loc.gov; = isojac@loc.gov;=20 HHj@standard.no; LTRU Working Group
Subject: Re: = (iso639.2708) RE:=20 ISO 639-2 decision: "mis"

 

Unfortunately, ISO = codes have=20 somewhat of an impedance mismatch with the needs of the IT community; = in=20 particular, stability. Thus BCP 47 has to stabilize those codes; one = of the=20 main reasons for the existence of RFC 4646. What that means is that if = ISO=20 tries to narrow the meaning of *any* code, whether it is a = "clarification" or=20 not, we have really only two choices:

1. Keep the broader = semantic,=20 which encompasses the new ISO narrow one, or
2. Deprecate the code = (in one=20 way or another).

Unlike many other codes, "mis" is one that we = can do=20 without, so #2 was a reasonable choice.

What I was trying to = come up=20 with language that we could agree on even though we have very = different views=20 on the utility and meaning of 'mis'. It sounds like we are ok on the = suggested=20 language on the other thread, so I'm hoping that we can put "mis" to=20 bed.

Mark

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

From: Kent Karlsson = [mailto:=20 kent.karlsson14@comhem.se]

> With the "old mis" one = could=20 correctly apply 'mis' as a language
> code for any = language

That=20 has *never* been the intent of ISO 639. It is an external = interpretation,=20 admittedly possible because ISO 639 was not fully explicit up to now. = But from=20 the perspective of the JAC, the "new mis" is exactly the same "mis" as = the=20 "old mis".


Peter




--
Mark=20

------=_NextPart_000_0178_01C7B25F.CBC103D0-- --===============0953638798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0953638798==-- From ltru-bounces@ietf.org Tue Jun 19 06:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0act-0005Py-6U; Tue, 19 Jun 2007 06:07:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0acr-0005M8-B7 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 06:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0acq-0005Lc-UV for ltru@lists.ietf.org; Tue, 19 Jun 2007 06:07:52 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0aaR-0007bt-SU for ltru@lists.ietf.org; Tue, 19 Jun 2007 06:05:27 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 19 Jun 2007 11:05:15 +0100 From: "Debbie Garside" To: , , "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 Date: Tue, 19 Jun 2007 11:04:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AceyKwT33cBIxoh+T+mJ0hE+X0MmxwAKcBvgAADzqoA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Message-Id: Cc: ietf-provreg@cafax.se X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is exactly the sort of application I had in mind when I proposed (many moons ago) that the syntax be changed to include "[RFC3066]" within the tag (something similar was originally proposed within Dublin Core). How much easier it would be for those within archive industries. Best regards Debbie > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 19 June 2007 10:38 > To: duerst@it.aoyama.ac.jp; 'Frank Ellermann'; ltru@lists.ietf.org > Cc: ietf-provreg@cafax.se > Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 > > Hi Martin > > No I did not mean to register new subtags according to 3066. > What I mean is that I can see an application for doing (say) > a transaction within a database that will bring out all > records that match the Registry as it stood in the 3066 era. > Perhaps in a housekeeping/update routine. Is there a way to > pull that historical registry once ISO 639-3 is added? > > Best regards > > Debbie > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: 19 June 2007 03:17 > > To: Debbie Garside; 'Frank Ellermann'; ltru@lists.ietf.org > > Cc: ietf-provreg@cafax.se > > Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930 > > > > At 20:52 07/06/18, Debbie Garside wrote: > > >Martin wrote: > > > > > >> No. There is no old registry. There is only one registry. > > > > > >I would have to disagree here. I can see applications for > > using an "old" > > >registry in order to update to a "new" registry. > > > > Hello Debbie, > > > > I'm not sure I can parse the above sentence correctly. Are > you saying > > that somebody could, now, make an application for registration on > > http://www.iana.org/assignments/language-tags > > according to RFC 3066? > > At http://www.iana.org/numbers.html#L, it explicitly says > "No further > > registrations in this registry.". > > Or are you talking about something else? > > > > Regards, Martin. > > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp > > mailto:duerst@it.aoyama.ac.jp > > > > > > > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 09:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0drY-0002ue-Dg; Tue, 19 Jun 2007 09:35:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0drW-0002ox-Fr for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0drW-0002mX-4u for ltru@ietf.org; Tue, 19 Jun 2007 09:35:14 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0drU-0003eU-T5 for ltru@ietf.org; Tue, 19 Jun 2007 09:35:14 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070619133510.KWUA3934.mta11.adelphia.net@DGBP7M81>; Tue, 19 Jun 2007 09:35:10 -0400 Message-ID: <007501c7b276$a81a4f10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Jun 2007 06:35:08 -0700 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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote: > Type: language > Subtag: qvc > Description: Cajamarca Quechua > Description: Quechua, Cajamarca > Added: 20xx-xx-xx > Macrolanguage: que Should have been: Macrolanguage: qu -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 10:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eLE-0002yR-1I; Tue, 19 Jun 2007 10:05:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0eLB-0002wi-Ss for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eLB-0002wa-JQ for ltru@ietf.org; Tue, 19 Jun 2007 10:05:53 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eL9-0002aq-CS for ltru@ietf.org; Tue, 19 Jun 2007 10:05:53 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0eL5-0001K0-Sh; Tue, 19 Jun 2007 10:05:47 -0400 Date: Tue, 19 Jun 2007 10:05:47 -0400 To: Doug Ewell Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619140547.GB30227@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <003701c7b238$16124fc0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > That's only half true. All Cantonese is Chinese, and since it's only > been possible up to this point to tag Cantonese as "zh-something", it's > reasonable to assume that much of it will continue to be tagged as > "zh-something" in the future. Or, indeed, as "zh" simpliciter, which is probably how most of it is tagged based on a simplistic subset of RFC 1766. -- Híggledy-pìggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowan Incontrovertibly / What we need more of is cowan@ccil.org Unicode weenies and / François Yergeaus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 11:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fEg-0005ux-Ob; Tue, 19 Jun 2007 11:03:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0fEf-0005uk-BN for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fEf-0005uc-1y for ltru@ietf.org; Tue, 19 Jun 2007 11:03:13 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fEc-0002iA-Oj for ltru@ietf.org; Tue, 19 Jun 2007 11:03:13 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 465921C00FC for ; Tue, 19 Jun 2007 17:03:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 423051C00F4 for ; Tue, 19 Jun 2007 17:03:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3588758EBE8 for ; Tue, 19 Jun 2007 17:03:09 +0200 (CEST) Date: Tue, 19 Jun 2007 17:03:09 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20070619150309.GA29854@nic.fr> References: <20070611073211.GA2807@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070611073211.GA2807@nic.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ltru] Re: Plans for www.langtag.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: , Errors-To: ltru-bounces@ietf.org On Mon, Jun 11, 2007 at 09:32:11AM +0200, Stephane Bortzmeyer wrote a message of 66 lines which said: > * the ability to give write-access to people other than me. BTW, anonymous read-only access to the Subversion repository is now available: https://svn.langtag.net/langtag _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 11:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fNE-0000HZ-9Z; Tue, 19 Jun 2007 11:12:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0fND-0000Gv-1r for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fNC-0000Fg-M0 for ltru@ietf.org; Tue, 19 Jun 2007 11:12:02 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fLa-0004JB-9i for ltru@ietf.org; Tue, 19 Jun 2007 11:10:23 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070619151021.TBUV3934.mta11.adelphia.net@DGBP7M81> for ; Tue, 19 Jun 2007 11:10:21 -0400 Message-ID: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 19 Jun 2007 08:10:20 -0700 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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > Is there a way to pull that historical registry once ISO 639-3 is added? In theory it's always possible to recover a historical version of the RFC *4646* Registry by looking at the "Added" dates. This actually doesn't work perfectly because modifications don't affect the Added date. Extracting the RFC *3066* registry is a different problem, because the nature of the records to be extracted isn't the same. Not only were there no script subtags, but language and region subtags weren't defined within the 3066 registry, but rather within ISO 639 and 3166 (so users had to dig through the standards to find valid code elements, and the status of "withdrawn" code elements was unclear). The 3066 registry contained only things that we would today consider for "variant" status. Going from 4646 to 3066 has more to do with understanding the two specifications and registries, and the differences between them, than with the actual data. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 11:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fZH-0001pv-FJ; Tue, 19 Jun 2007 11:24:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0fZG-0001lU-ET for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fZG-0001lM-4f for ltru@ietf.org; Tue, 19 Jun 2007 11:24:30 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fZE-00088m-NV for ltru@ietf.org; Tue, 19 Jun 2007 11:24:30 -0400 Received: from [10.72.76.125] (snvvpn2-10-72-76-c125.corp.yahoo.com [10.72.76.125]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5JFODQQ077829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 08:24:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=KMV0ai7YN6/2a/DDbPY/U9UnU8nqra42mQVuYivFKopnFynbyK4gfnGCkdGwM+fb Message-ID: <4677F51D.7000600@yahoo-inc.com> Date: Tue, 19 Jun 2007 08:24:13 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 References: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> In-Reply-To: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Proposal: RFC4645bis should preserve existing dates in the 4646-based registry. Then pulling the "historical" (4646) registry would be possible. Probably this is what you're doing already, Doug, but the text doesn't say so. Addison Doug Ewell wrote: > Debbie Garside wrote: > >> Is there a way to pull that historical registry once ISO 639-3 is added? > > In theory it's always possible to recover a historical version of the > RFC *4646* Registry by looking at the "Added" dates. This actually > doesn't work perfectly because modifications don't affect the Added date. > > Extracting the RFC *3066* registry is a different problem, because the > nature of the records to be extracted isn't the same. Not only were > there no script subtags, but language and region subtags weren't defined > within the 3066 registry, but rather within ISO 639 and 3166 (so users > had to dig through the standards to find valid code elements, and the > status of "withdrawn" code elements was unclear). The 3066 registry > contained only things that we would today consider for "variant" > status. Going from 4646 to 3066 has more to do with understanding the > two specifications and registries, and the differences between them, > than with the actual data. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 11:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fbK-0003Uw-4S; Tue, 19 Jun 2007 11:26:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0fbJ-0003Uj-JH for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fbJ-0003Ub-9m for ltru@ietf.org; Tue, 19 Jun 2007 11:26:37 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fb3-0008QB-3z for ltru@ietf.org; Tue, 19 Jun 2007 11:26:37 -0400 Received: from [10.72.76.125] (snvvpn2-10-72-76-c125.corp.yahoo.com [10.72.76.125]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5JFQ1Yk077999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 08:26:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2m96iLBMXNlQqny0U2LIoxL9CUgQeZqRGNRPSxt45ChASCOtB50GcN6aa6u8eznz Message-ID: <4677F589.3090003@yahoo-inc.com> Date: Tue, 19 Jun 2007 08:26:01 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> In-Reply-To: <20070619140547.GB30227@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Doug and John's comments over the past couple of days. I also agree with Mark that there are certain problems with extended language subtagging. Notably, there are matching implications. I was able to address that in my own implementations by: - using extended rather than basic filtering - treating the primary plus extlang sequence as atomic in lookup That is, the fallback from zh-yue-Hant goes: zh-yue-Hant zh-yue (default) I guess I agree about adding "Macrolanguage" to the registry, except that extlang, if preserved, already indicates this with "Prefix". Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. John Cowan wrote: > Doug Ewell scripsit: > >> That's only half true. All Cantonese is Chinese, and since it's only >> been possible up to this point to tag Cantonese as "zh-something", it's >> reasonable to assume that much of it will continue to be tagged as >> "zh-something" in the future. > > Or, indeed, as "zh" simpliciter, which is probably how most of it is > tagged based on a simplistic subset of RFC 1766. > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 12:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gTB-0006fR-E1; Tue, 19 Jun 2007 12:22:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0gTA-0006eN-DF for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gTA-0006e1-3F for ltru@ietf.org; Tue, 19 Jun 2007 12:22:16 -0400 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 1I0gT8-0005du-PG for ltru@ietf.org; Tue, 19 Jun 2007 12:22:16 -0400 Received: by rap.rap.dk (Postfix, from userid 500) id 6B441275D9; Tue, 19 Jun 2007 16:21:57 +0000 (UTC) Date: Tue, 19 Jun 2007 18:21:57 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Martin Duerst Subject: Re: (iso639.2732) RE: [Ltru] RE: RE: ISO 639-2 decision: "mis" Message-ID: <20070619162157.GA3941@rap.rap.dk> References: <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <200706191116.l5JBGXeI090743@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706191116.l5JBGXeI090743@dkuug.dk> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group , "isojac@loc.gov" , "iso639-2@loc.gov" , "ietf-languages@iana.org" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jun 19, 2007 at 02:48:12PM +0900, Martin Duerst wrote: > At 13:58 07/06/19, Peter Constable wrote: > >From: Peter Constable [mailto:petercon@microsoft.com] > >Sent: Monday, June 18, 2007 10:17 AM > > > >> And note that this issue exists whether one considers > >> "old mis" to have the semantic that Keld is stuck on... > > > >My sincere apologies for having gotten these Swedes mixed up. I should have > >referred to Kent Karlsson here, not Keld (who, I don't think, is even > >active here). > > And who isn't Swedish, but Danish, as far as I know. I can comfirm that I am Danish, and that I listen in on this. Bu, indeed, my activity is low here. best regards Keld _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 13:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0htj-0004kJ-VW; Tue, 19 Jun 2007 13:53:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0hti-0004g8-8t for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 13:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hth-0004g0-Va for ltru@ietf.org; Tue, 19 Jun 2007 13:53:45 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0htg-00021K-MV for ltru@ietf.org; Tue, 19 Jun 2007 13:53:45 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 19 Jun 2007 10:52:23 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Tue, 19 Jun 2007 10:53:43 -0700 From: Peter Constable To: LTRU Working Group Date: Tue, 19 Jun 2007 10:53:42 -0700 Thread-Topic: * in extended filtering Thread-Index: AceyhjxfnCDqQzG2RSuMu+Z/ausF1gAE7GFw Message-ID: References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> In-Reply-To: <4677F589.3090003@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] * in extended 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: , Errors-To: ltru-bounces@ietf.org Can someone explain this statement in 3.3.2 (Extended Filtering) of RFC 464= 7: "This is the reason why a wildcard in the extended language range is signif= icant in the first position but is ignored in all other positions." I don't see how "*" is said to be ignored in non-initial position of a rang= e. Step 1 says, "Two subtags match if either they are the same when compare= d case-insensitively or the language range's subtag is the wildcard '*'." S= teps 2 and 3 refer to subtags "match[ing]", where "match" is defined in ste= p 1, and these steps apply only to non-initial positions. Step 3.A also mak= es explicit reference to "*" in the range subtag -- again, this being non-i= nitial subtags. I can't figure that sentence out. Thanks Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 14:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i39-0001mg-Na; Tue, 19 Jun 2007 14:03:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0i38-0001mb-P7 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i38-0001mP-FY for ltru@ietf.org; Tue, 19 Jun 2007 14:03:30 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0i37-0005Bx-27 for ltru@ietf.org; Tue, 19 Jun 2007 14:03:30 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5JI36OB072202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 11:03:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=J4XqBewLSWMytQrobn5OA1XxdgPz9F7tsQVIX+D6NP9yNmOuYfbXk8Au1bi2ifsE Message-ID: <46781A5A.6060506@yahoo-inc.com> Date: Tue, 19 Jun 2007 11:03:06 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] * in extended filtering References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ignored is probably the wrong word. The sentence really means: "[t]his is the reason why a wildcard in the extended language range is only a significant difference in the first position but whose inclusion (or omission) has no effect elsewhere in the range." Addison Peter Constable wrote: > Can someone explain this statement in 3.3.2 (Extended Filtering) of RFC 4647: > > "This is the reason why a wildcard in the extended language range is significant in the first position but is ignored in all other positions." > > I don't see how "*" is said to be ignored in non-initial position of a range. Step 1 says, "Two subtags match if either they are the same when compared case-insensitively or the language range's subtag is the wildcard '*'." Steps 2 and 3 refer to subtags "match[ing]", where "match" is defined in step 1, and these steps apply only to non-initial positions. Step 3.A also makes explicit reference to "*" in the range subtag -- again, this being non-initial subtags. > > I can't figure that sentence out. > > > Thanks > Peter > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 14:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iTc-0003ge-Lp; Tue, 19 Jun 2007 14:30:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0iTb-0003gZ-NU for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iTb-0003gR-Df for ltru@ietf.org; Tue, 19 Jun 2007 14:30:51 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0iTa-0001Tf-Ko for ltru@ietf.org; Tue, 19 Jun 2007 14:30:51 -0400 Received: by wr-out-0506.google.com with SMTP id 70so1293443wra for ; Tue, 19 Jun 2007 11:30:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Kb5gXSvH7TK38K2hPoUcaFn6IqgRpr1lOaSkpRTJ34bSNT6aNVsCRTzyr2csz+lSY5biiMWdydazUE0hfbNVZjAuRnECF8q4pH27M3J/6W+43qU/b60ka/8BrTchqBUNMxG5MaMEBmLMGu/92FXXc2sFgAYaQTw9iDKWu9EzgJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=m9T9cegY8N92ghm8crWDSSYLMWmSxetrgrFYhMokjWDPHnn1dLfX+OTBA2ZCnMAaRRtdYB/0iTOdTIODXMMYNvsAuQGM2OhGstPyPVP8TOo5RRXDinK3NvTJNK55Cqdu06I97gGX+JQs/2XHMu8nCWYrmgpF3fkwJAVpbzw6xqY= Received: by 10.143.11.13 with SMTP id o13mr475268wfi.1182277849680; Tue, 19 Jun 2007 11:30:49 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 19 Jun 2007 11:30:49 -0700 (PDT) Message-ID: <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> Date: Tue, 19 Jun 2007 11:30:49 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) In-Reply-To: <20070619013433.GA15048@mercury.ccil.org> MIME-Version: 1.0 References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> X-Google-Sender-Auth: 91afc0721ac8b391 X-Spam-Score: 0.5 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103493850==" Errors-To: ltru-bounces@ietf.org --===============2103493850== Content-Type: multipart/alternative; boundary="----=_Part_96582_1289725.1182277849641" ------=_Part_96582_1289725.1182277849641 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/18/07, John Cowan wrote: > > Mark Davis scripsit: > > > We added extlang to allow ourselves the freedom to make choices > > when 639-3 came along. We *very clearly did not define its meaning*, > > because we didn't know what 639-3 was finally going to look like, > > Not so much. We had an excellent idea of what 639-3 would both look and > actually be like when 4646 was finalized. We couldn't include 639-3 or > extlangs because 639-3 itself was not yet final. I think perhaps both of our "we"s are overstated. Since we disagree on this point, neither my "we" nor your "we" is inclusive. For example, you can't mean that every member of the working group had looked it over thoroughly, and explored all the implementation ramifications. I'd like to see a show of hands for those who did -- maybe everyone except for me had, but I'd be rather surprised at that. > nor did we have agreement on what we should actually do. > > We had at least the consensus of silence; at least, I don't remember any > complaints at the time. Remember that the development of 4646 started at > least a year before LTRU was formally created. I don't think everyone had reviewed it in detail, but perhaps the show of hands would prove me the only one. > We *already* had macrolanguages with ISO 639-2 in RFC 4646 and we *did > > not* use extlang for them: examples are "sr", "hr", "nb", etc. > > (Rather, these are examples of languages *encompassed* by macrolanguages, > henceforth "encompassed languages". I realize that's just a slip.) True, thanks. > We are not going to (and cannot) be forcing users to encode nb as no-nb, > > nor sr as sh-sr. > > Nobody has ever proposed that. Language subtags coming from 639-1 > or 639-2 will not change, even if 639-3 says they encode encompassed > languages. My point was that anyone who wants to deal with macro languages, has to already deal with sr, hr, etc. as primary subtags, not as secondary. Thus whatever mechanisms people have to work with sh, etc. can be extended to other cases without the extlang mechanism. > When we ("Google") tried implementing matching with "zh-yue" and others, > > we found it made things *more* difficult, not less. > > Respectfully I suggest that because you ("Google") assign tags to incoming > rather than outgoing content, your use of BCP 47 is essentially private > rather than in interchange. That makes it potentially important, but > definitely not prototypical. First of all, that isn't true (but thanks for the "respectfully"!) We actually use language tags in a huge number of products, many of which have APIs. We are not fully BCP 47 compliant, but are working towards that. But the main point is, I want those people who have tried to implement -- professionally, not just in toy programs -- extlang to speak up about their experiences. So if you want to speak to your experience implementing this professionally, I'm all ears. Addison mentions that fallback matching is not a problem. Mechanically it is a no-brainer. But the *results* of that fallback are what we are having problems with. And *that's* why I raise this issue, and call it "baking in an assumption". Let me try to set this out, yet again. I'll call the "languages encompassed by a macrolanguage" by the term "microlanguage", just as a term. I see two options. I may have captured the extlang reasoning incorrectly, so please bear with me. And if there are other reasons for having extlang, that'd be good to hear. Premises 1. The reason for making microlanguages be extlang instead of primary sublanguages is so that truncation-style matching will have better results. 2. Fallback works when there is mutual comprehensibility (not necessarily 100%, but to a high degree); if you fallback to something that is not comprehensible, then fallback has failed. Option A. 1. Thus for extlang to work for microlanguages, the speakers of any microlanguages sharing a macrolanguage need to be able to understand the speakers of any other microlanguages sharing that macrolanguage. 2. Peter and the ISO JAC can verify that A1 is true; that every speaker of Hakka can understand Jinyu; every speaker of Shihhi Arabic can understand Cypriot Arabic; and so on). 3. Everything is hunky-dory. Option B. 1. The macrolanguage alone is always assumed to be the "standard", and that can be identified. That is, "zh" is always assumed to be Mandarin, "ar" is always assumed to be "Standard Arabic", etc. (That is, I think, the correct approach, but is *not* currently in the spec.) 2. Thus for extlang to work for microlanguages, the speakers of any microlanguages sharing a macrolanguage need to be able to understand the speakers of the standard used for that macro language. 3. Peter and the ISO JAC can verify that B21 is true; that every speaker of Hakka can understand Mandarin; every speaker of Shihhi Arabic can understand Cypriot Arabic, and so on). 4. Everything is hunky-dory. If both A and B are not plausible, and we can't find something other compelling reason to have extlangs, it is *far* better to add the Macrolanguage field to the registry, and let people implement their own matching making use of that AND other factors. After all, it is trivial to make a 4647bis that adds an optional step for microlanguages, which is that when you get to a microlanguage, the next step is to look at its macrolanguage before falling back to the default. That has the same result (and same problems) as extlang, but is something that is not baked into the standard -- is something that people can implement if they want without impacting matching for everyone else. > Matching "zh" and "yue" is not something you want to do > > automatically. Moreover, because of #2 we had to have a mechanism for > > dealing with macrolanguages in RFC 4646 *anyway*. > > Very plausible in your circumstances. But note that Yue (Cantonese) > content is *already* properly tagged "zh-yue" on precisely the theory > that's being applied to 639-3 encompassed languages. > > I realize that this cause is probably not important to you, because > you can (comparatively) easily change all "zh-yue" tags to "yue", but > this is not the case for other users of BCP 47 on and off the Internet, > who will never even hear about the change. These are irregular tags anyway, and can stay irregular tags afterwards. We and everyone else already have to deal with equivalences with grandfathered and irregular tags anyway; these are not a real problem. > Thus to make a proposed change from 4646 to use the extlang mechanism > > for languages that have macrolanguages, we need a very compelling > > case that the additional complication solves more problems than it > > creates. We haven't seen that yet, and certainly have no consensus > > that it is the case. > > On the contrary, the burden of persuasion is with you. Tags like > zh-yue are already present in 4646, and it's up to you to provide a > convincing argument to deprecate them. Furthermore, LTRU and its ad hoc > predecessor has been assuming the extlang structure since at least 2004. > Derailing that is what will take a "very compelling case". I disagree strongly. If you can't make a compelling case that extlang will make BCP 47 better instead of worse, and won't even look at the reasons not to do it, nor even bother to set out a case for it, then why should we add it? > A. [Don't use extlangs.] > > I continue in opposition to this. > > > B. (optional) Add a field Macrolanguage: to the language subtag > > registry. > > I am not opposed to this, precisely because encompassed languages and > the corresponding macrolanguage cannot be identified syntactically. Good. -- > May the hair on your toes never fall out! John Cowan > --Thorin Oakenshield (to Bilbo) cowan@ccil.org > I hope not.... -- Mark ------=_Part_96582_1289725.1182277849641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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

> We added extlang to allow ourselves the freedom to make choices
> when 639-3 came along. We *very clearly did not define its meaning*,
> because we didn't know what 639-3 was finally going to look like,

Not so much.  We had an excellent idea of what 639-3 would both look and
actually be like when 4646 was finalized.  We couldn't include 639-3 or
extlangs because 639-3 itself was not yet final.

I think perhaps both of our "we"s are overstated. Since we disagree on this point, neither my "we" nor your "we" is inclusive.

For example, you can't mean that every member of the working group had looked it over thoroughly, and explored all the implementation ramifications. I'd like to see a show of hands for those who did -- maybe everyone except for me had, but I'd be rather surprised at that.

> nor did we have agreement on what we should actually do.

We had at least the consensus of silence; at least, I don't remember any
complaints at the time.  Remember that the development of 4646 started at
least a year before LTRU was formally created.

I don't think everyone had reviewed it in detail, but perhaps the show of hands would prove me the only one.

> We *already* had macrolanguages with ISO 639-2 in RFC 4646 and we *did
> not* use extlang for them: examples are "sr", "hr", "nb", etc.

(Rather, these are examples of languages *encompassed* by macrolanguages,
henceforth "encompassed languages".  I realize that's just a slip.)

True, thanks.

> We are not going to (and cannot) be forcing users to encode nb as no-nb,
> nor sr as sh-sr.

Nobody has ever proposed that.  Language subtags coming from 639-1
or 639-2 will not change, even if 639-3 says they encode encompassed
languages.

My point was that anyone who wants to deal with macro languages, has to already deal with sr, hr, etc. as primary subtags, not as secondary. Thus whatever mechanisms people have to work with sh, etc. can be extended to other cases without the extlang mechanism.

> When we ("Google") tried implementing matching with "zh-yue" and others,
> we found it made things *more* difficult, not less.

Respectfully I suggest that because you ("Google") assign tags to incoming
rather than outgoing content, your use of BCP 47 is essentially private
rather than in interchange.  That makes it potentially important, but
definitely not prototypical.

First of all, that isn't true (but thanks for the "respectfully"!) We actually use language tags in a huge number of products, many of which have APIs. We are not fully BCP 47 compliant, but are working towards that.

But the main point is, I want those people who have tried to implement -- professionally, not just in toy programs -- extlang to speak up about their experiences. So if you want to speak to your experience implementing this professionally, I'm all ears.

Addison mentions that fallback matching is not a problem. Mechanically it is a no-brainer. But the *results* of that fallback are what we are having problems with. And *that's* why I raise this issue, and call it "baking in an assumption". Let me try to set this out, yet again. I'll call the "languages encompassed by a macrolanguage" by the term "microlanguage", just as a term.

I see two options. I may have captured the extlang reasoning incorrectly, so please bear with me. And if there are other reasons for having extlang, that'd be good to hear.

Premises
  1. The reason for making microlanguages be extlang instead of primary sublanguages is so that truncation-style matching will have better results.
  2. Fallback works when there is mutual comprehensibility (not necessarily 100%, but to a high degree); if you fallback to something that is not comprehensible, then fallback has failed.
Option A.
  1. Thus for extlang to work for microlanguages, the speakers of any microlanguages sharing a macrolanguage need to be able to understand the speakers of any other microlanguages sharing that macrolanguage.
  2. Peter and the ISO JAC can verify that A1 is true; that every speaker of Hakka can understand Jinyu; every speaker of Shihhi Arabic can understand Cypriot Arabic; and so on).
  3. Everything is hunky-dory.
Option B.
  1. The macrolanguage alone is always assumed to be the "standard", and that can be identified. That is, "zh" is always assumed to be Mandarin, "ar" is always assumed to be "Standard Arabic", etc. (That is, I think, the correct approach, but is *not* currently in the spec.)
  2. Thus for extlang to work for microlanguages, the speakers of any microlanguages sharing a macrolanguage need to be able to understand the speakers of the standard used for that macro language.
  3. Peter and the ISO JAC can verify that B21 is true; that every speaker of Hakka can understand Mandarin; every speaker of Shihhi Arabic can understand Cypriot Arabic, and so on).
  4. Everything is hunky-dory.
If both A and B are not plausible, and we can't find something other compelling reason to have extlangs, it is *far* better to add the Macrolanguage field to the registry, and let people implement their own matching making use of that AND other factors.

After all, it is trivial to make a 4647bis that adds an optional step for microlanguages, which is that when you get to a microlanguage, the next step is to look at its macrolanguage before falling back to the default. That has the same result (and same problems) as extlang, but is something that is not baked into the standard -- is something that people can implement if they want without impacting matching for everyone else.

> Matching "zh" and "yue" is not something you want to do
> automatically. Moreover, because of #2 we had to have a mechanism for
> dealing with macrolanguages in RFC 4646 *anyway*.

Very plausible in your circumstances.  But note that Yue (Cantonese)
content is *already* properly tagged "zh-yue" on precisely the theory
that's being applied to 639-3 encompassed languages.

I realize that this cause is probably not important to you, because
you can (comparatively) easily change all "zh-yue" tags to "yue", but
this is not the case for other users of BCP 47 on and off the Internet,
who will never even hear about the change.

These are irregular tags anyway, and can stay irregular tags afterwards. We and everyone else already have to deal with equivalences with grandfathered and irregular tags anyway; these are not a real problem.

> Thus to make a proposed change from 4646 to use the extlang mechanism
> for languages that have macrolanguages, we need a very compelling
> case that the additional complication solves more problems than it
> creates. We haven't seen that yet, and certainly have no consensus
> that it is the case.

On the contrary, the burden of persuasion is with you.  Tags like
zh-yue are already present in 4646, and it's up to you to provide a
convincing argument to deprecate them.  Furthermore, LTRU and its ad hoc
predecessor has been assuming the extlang structure since at least 2004.
Derailing that is what will take a "very compelling case".

I disagree strongly. If you can't make a compelling case that extlang will make BCP 47 better instead of worse, and won't even look at the reasons not to do it, nor even bother to set out a case for it, then why should we add it?

> A. [Don't use extlangs.]

I continue in opposition to this.

> B. (optional) Add a field Macrolanguage: to the language subtag
> registry.

I am not opposed to this, precisely because encompassed languages and
the corresponding macrolanguage cannot be identified syntactically.

Good.

--
May the hair on your toes never fall out!       John Cowan
        --Thorin Oakenshield (to Bilbo)         cowan@ccil.org

I hope not....


--
Mark ------=_Part_96582_1289725.1182277849641-- --===============2103493850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2103493850==-- From ltru-bounces@ietf.org Tue Jun 19 14:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ig0-00078r-Gg; Tue, 19 Jun 2007 14:43:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0cEd-0007wz-95 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 07:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cEc-0007wr-Vq for ltru@lists.ietf.org; Tue, 19 Jun 2007 07:50:58 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cEc-0000by-Mg for ltru@lists.ietf.org; Tue, 19 Jun 2007 07:50:58 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l5JBmuqt027360; Tue, 19 Jun 2007 07:48:56 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 07:50:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930 Date: Tue, 19 Jun 2007 07:50:59 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0701DE5519@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <6.0.0.20.2.20070619122139.0b4df880@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930 Thread-Index: AceyKuUHSQsE9JhPRSqrRQsPmc+J/wANjL4A From: "Hollenbeck, Scott" To: "Martin Duerst" , "Stephane Bortzmeyer" , X-OriginalArrivalTime: 19 Jun 2007 11:50:50.0925 (UTC) FILETIME=[156E6DD0:01C7B268] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Tue, 19 Jun 2007 14:43:39 -0400 Cc: ietf-provreg@cafax.se, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin, The bottom line in my opinion is that 3730 implementers weren't writing code with 4646 as a reference and it didn't seem wise to introduce a reference change *that allows the possibility of required code changes* and is *inconsistent with other normative references* when going from proposed to draft. More below. -Scott-=20 > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp]=20 > Sent: Monday, June 18, 2007 11:41 PM > To: Hollenbeck, Scott; Stephane Bortzmeyer; rfc-editor@rfc-editor.org > Cc: ietf-provreg@cafax.se; ltru@lists.ietf.org > Subject: Re: [Ltru] RE: [ietf-provreg] Small bibliography=20 > error in RFC 4930 >=20 > At 21:39 07/06/18, Hollenbeck, Scott wrote: > >After a private exchange with Randy Presuhn of the LTRU=20 > working group I > >realized it might be helpful if I provide more info to=20 > explain why 4930 > >references 3066 instead of 4646. First, let me confirm that=20 > this wasn't > >an oversight. It was a conscious decision made with the=20 > concurrence of > >the IESG as we looked at the normative references and the standards > >track status of those references. >=20 > Okay, but on hindsight, and looking at things in detail, I still > think that this decision was wrong, and that it shouldn't be > repeated. >=20 > >Rationale: > > > >1. 4930 is the draft standard version of 3730, updated to document > >implementation experience with 3730. 3730 references 3066. =20 > The first > >drafts of what would become 4930 referenced 3066 before 4646 was > >approved and published. Implementers of 3730 and 4930 wrote code per > >3066. >=20 > If you could explain how writing code per 3066 and writing code per > 4646 would lead to any difference in the actual code or the observable > protocol behavior, that would help us to accept this point. You touched on this yourself below. Additional language tags are possible. While I agree that this should be transparent to EPP, I didn't see any compelling reason to require implementations and the user interface code above those implementations to deal with the possibility. I also had no assurances that existing XML Schema processors would remain unaffected given that the 2004 XML Schema specs still cite 3066. > >2. 3730 and 4930 include a language tag reference because=20 > language tags > >are used within XML Schema elements. The October 2004 edition of the > >normative XML Schema datatypes reference cites 3066: > > > >http://www.w3.org/TR/xmlschema-2/#language >=20 > If you look at this, you will easily see that: > - The lexical space defined is in no conflict at all with the syntax > of RFC 4646. > - RFC 4930, in its normative prose, only says that language tags must > be "structured as documented in [RFC3066]". While RFC 3066 didn't > use these terms, it essentially means that they must be "RFC 3066 > well-formed", not "RFC 3066 valid". > The only point you might be able to claim here is that changing this > to RFC 4646 might create a requirement for implementations to check > for RFC 4646 well-formedness, which is admittedly a bit tighter than > RFC 3066. But the MUST is on the sender, where we can assume that > only valid stuff is used anyway, and you have no error message for > non-well-strucured-language-code, which makes sense because > the usual behavior, "language not available", is just good enough. So you see no problem with including a normative reference to 4646 even though the normative XML Schema spec cites 3066? I do, and I believe the IESG would have as well. > >Consistency was thus thought to be a good thing. >=20 > The problem is that with this, you may have excluded a lot of=20 > languages > from potentially being used in your protocol, and you have created the > impression that updating from RFC 3066 to RFC 4646 is a major=20 > undertaking, > which in most cases, it is not. I've created no such impression. I left the reference exactly as it was when 3730 was approved by the IESG. There haven't been any EPP implementers screaming for support for 4646 language tags, so with 4930 NOT being new work there was no compelling reason to change the reference. > >If this were new work > >I'd agree that 4646 would be the more appropriate reference, but that > >would also depend on the XML specifications picking up 4646 as well. >=20 > XML already has (see http://www.w3.org/TR/REC-xml/#sec-lang-tag). > For a previous version > (http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag), > it already says "RFC 3066 or its successor". >=20 > As for XML Schema, I'm very sure they'll make the move. A previous > version was on RFC 1766. > http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#language > If in doubt, it would have been easy for the WG or the IESG to > check with W3C. They might, but they haven't, and that creates a consistency problem. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 14:51:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0io2-0001NR-UN; Tue, 19 Jun 2007 14:51:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0io1-0001NM-VY for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0io1-0001NE-M0 for ltru@ietf.org; Tue, 19 Jun 2007 14:51:57 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0io0-0004AK-FR for ltru@ietf.org; Tue, 19 Jun 2007 14:51:57 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0inx-0003w4-Gi; Tue, 19 Jun 2007 14:51:53 -0400 Date: Tue, 19 Jun 2007 14:51:53 -0400 To: Addison Phillips Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619185153.GB12168@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4677F589.3090003@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > I guess I agree about adding "Macrolanguage" to the registry, except > that extlang, if preserved, already indicates this with "Prefix". Except for the cases where the encompassed language is a 639-2 language. -- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 15:16:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jC3-0003PP-Iv; Tue, 19 Jun 2007 15:16:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0jC2-0003NT-3N for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jC1-0003NJ-Pm for ltru@ietf.org; Tue, 19 Jun 2007 15:16:45 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jBi-0001Cb-Sd for ltru@ietf.org; Tue, 19 Jun 2007 15:16:45 -0400 Received: by wr-out-0506.google.com with SMTP id 70so1308264wra for ; Tue, 19 Jun 2007 12:16:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=B9lxxz2Ul4MOXj9oLk06qhCquJJB/CWaRhomxkCNmeVRNdrKuMts76j8BQLpztqry5hUijp8PMS1ELBFFyY8lsIvC6a9G9i9FDrT9kqXfVemaejL+ivViMAwksPB09kl23+OJO9tYDeprw9a2GJgcZ8teW8E2x650/zHD8r/tL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JwoAToTaoAhmtj+JEyR+VGTUg/G3SSFUfGASnTwVURgHI47RkZ8SAU5wGSmisCNx7euquFuV6ccLu9GYfzOtZIoriIsyoHULh8IyrnhV0/cdeAHgZdPPAayTsDXjx1+vilI7LfUwBXXPcRMFVRzivCvKNQgzY9QtUtjFJBddgBg= Received: by 10.142.111.14 with SMTP id j14mr502869wfc.1182280585644; Tue, 19 Jun 2007 12:16:25 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 19 Jun 2007 12:16:25 -0700 (PDT) Message-ID: <30b660a20706191216w70bda8e4y41c5c6bae0819a8e@mail.gmail.com> Date: Tue, 19 Jun 2007 12:16:25 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: MIME-Version: 1.0 References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> X-Google-Sender-Auth: cd7558c5047b0ab4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , LTRU Working Group , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492211750==" Errors-To: ltru-bounces@ietf.org --===============0492211750== Content-Type: multipart/alternative; boundary="----=_Part_97738_29474851.1182280585575" ------=_Part_97738_29474851.1182280585575 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline InJvb3QiIHdvdWxkIGJlIGp1c3QgYXMgdXNlZnVsIGFzICJtaXMiLCBpZiB5b3Ugc3RpcHVsYXRp b24gdGhhdCBwZW9wbGUKc2hvdWxkIHRhZyB3aXRoIGFzIG11Y2ggaW5mb3JtYXRpb24gYXMgdGhl eSBoYXZlLiBUaGUgcHJhY3RpY2FsIGVmZmVjdCB3b3VsZApiZSBsaXR0bGUgZGlmZmVyZW50IGV4 Y2VwdCB0aGF0ICJyb290IiB3b3VsZCByZW1haW4gdmFsaWQuCgpCdXQgdGhlIGZ1bmRhbWVudGFs IHByb2JsZW0gd2l0aCAibWlzIiBpcyB0aGF0IGl0IGlzIHVuc3RhYmxlLCBhbmQKaWxsLWRlZmlu ZWQuIElmIEkgZ2V0ICJtaXMiIGluIGEgeWVhciBmcm9tIG5vdyBJIGhhdmUgbm8gaWRlYSB3aGV0 aGVyIHRoZQpvcmlnaW5hbCBpdGVtIHdhcyB0YWdnZWQgd2hlbiAibWlzIiBmaXJzdCBjYW1lIG91 dCAoMTk5OD8pLCBvciBpbiA0NjQ2LCBvcgppbiA0NjQ2YmlzOyBJIGp1c3QgZG9uJ3Qga25vdyBh bmQgY2FuJ3Qga25vdy4gSWYgeW91IGhhZCBkZWZpbmVkICJtaXMiIHRvIGJlCiJ3aGF0ZXZlciBk aWRuJ3QgaGF2ZSBhIGNvZGUgaW4gMTk5OCIsIHRoYXQgd291bGQgYXQgbGVhc3QgYmUgc3RhYmxl LCBhbmQKYWxsb3cgdmFsaWQgdGFncyB0byByZW1haW4gdmFsaWQuCgpBbmQgZnJhbmtseSwgaWYg eW91IGFyZSBnb2luZyB0byB0aGUgdHJvdWJsZSB0byB0YWcgY29udGVudCB0aGF0IHlvdSdyZQpn b2luZyB0byBsYXRlciByZXZpc2l0LCB5b3UnZCBiZSBmYXIgYmV0dGVyIG9mZiB0byB1c2UgYSB1 bmlxdWUgcHJpdmF0ZSB1c2UKY29kZSBmb3IgZWFjaCBtaXNzaW5nIGl0ZW0uIFRoYXQgd2F5IHlv dSBkb24ndCBoYXZlIHRvIHJlLWFuYWx5c2UgZWFjaCBwaWVjZQpvZiBjb250ZW50IGhhdmluZyAi bWlzIiBvbiBpdC4KCkFueXdheSwgaXQgc291bmRzIGxpa2UgdGhlIGxhc3QgbGFuZ3VhZ2UgcHJv cG9zZWQgZm9yICJtaXMiIGlzIG9rIHdpdGgKZXZlcnlvbmUsIHNvIHRoaXMgZGlzY3Vzc2lvbiBp cyByZWFsbHkgbW9vdC4gU29ycnkgdG8gaGF2ZSByYWlzZWQgeW91cgpoYWNrbGVzIHdpdGggbXkg b3JpZ2luYWwgbWVzc2FnZS4KCk1hcmsKCk9uIDYvMTgvMDcsIFBldGVyIENvbnN0YWJsZSA8cGV0 ZXJjb25AbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiAgU3VnZ2VzdGluZyB0aGF0ICdyb290JyBh dm9pZHMgcHJvYmxlbXMgaXMsIElNTywgcmF0aGVyIGEgYml0IG9mIGZhbHNlCj4gZWNvbm9teS4g U3VyZSwgaWYgYSB0YWcgbWVhbnMgJ3NvbWUgbGFuZ3VhZ2UnLCB0aGVuIGNvbnRlbnQgc28gdGFn Z2VkIG5ldmVyCj4gYmVjb21lcyAqKmluY29ycmVjdGx5KiogdGFnZ2VkIHdoZW4gYW4gSUQgZm9y IHRoZSBnaXZlbiBsYW5ndWFnZSBpcyBhZGRlZC4KPiBCdXQgbGV0J3MgY29uc2lkZXIgd2hldGhl ciBpdCBpcyAqKnVzZWZ1bGx5KiogdGFnZ2VkOiBjaGFuZ2luZyB0aGluZ3Mgc28KPiB0aGF0IGl0 IGNvdWxkIGNvbnRpbnVlIHRvIGJlICoqY29ycmVjdGx5KiogdGFnZ2VkIHdvdWxkbid0IG1ha2Ug aXQgbW9yZSAqKgo+IHVzZWZ1bGx5KiogdGFnZ2VkLCBhbmQgYXJndWFibHkgbWFrZXMgaXQgbGVz cyBzby4KPgo+Cj4KPiBUbyBzdWdnZXN0IHRoYXQgdXNlcnMgbmVlZG4ndCB3b3JyeSBhYm91dCB0 aGVpciBjb250ZW50IHRhZ2dlZCAncm9vdCcKPiBhZnRlciBhIG5ldyBsYW5ndWFnZSBpcyBjb2Rl ZCBpcyBJTU8gYmFkIGFkdmljZS4gVGhleSBjZXJ0YWlubHkgKipzaG91bGQqKgo+IHdvcnJ5IGlm IHRoZXkgd2FudCB0aGVpciBkYXRhIHRvIGJlIHVzZWZ1bDogdGhleSdsbCB3YW50IHRvIHJlLXRh ZyB0aGUKPiByZWxldmFudCBjb250ZW50IHdpdGggdGhlIG5ld2x5LWNvZGVkIElELCBlbHNlIHRo ZXkgZW5kIHVwIHdpdGggZGF0YSB0aGF0Cj4gd29uJ3QgY29tcGFyZS4gQXQgbGVhc3QgaWYgdGhl eSBrbm93IHRoYXQgdGhlIGFkZGl0aW9uIHdpbGwgbmFycm93IHRoZQo+IGV4dGVuc2lvbiBhbmQg cG90ZW50aWFsbHkgaW52YWxpZGF0ZSB0YWdnaW5nIG9uIHNvbWUgb2YgdGhlaXIgY29udGVudCwK PiB0aGV5J3JlIG1vcmUgbGlrZWx5IHRvIHBheSBhdHRlbnRpb247IHdoYXQgeW91IHN1Z2dlc3Qg Y2FuIGdpdmUgdGhlCj4gaW1wcmVzc2lvbiB0aGF0IHRoZXkgZG9uJ3QgaGF2ZSBhbnkgcGFydGlj dWxhciB3b3JyeSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLgo+Cj4KPgo+Cj4gQSB0YWcgd2l0aCB0 aGUgJ3Jvb3QnIHNlbWFudGljIGNhbiBhbHdheXMgbWVhbiBhbnl0aGluZyDigJMgd2hpY2ggbWVh bnMgaXQncwo+IG5lYXJseSB2b2lkIG9mIG1lYW5pbmcgYW5kIGlzIGFib3V0IGFzIHVzZWZ1bCBh cyBub3QgaGF2aW5nIHRhZ2dlZCBpdCBhdCBhbGwKPiBpbiB0aGUgZmlyc3QgcGxhY2UuIChUaGUg J3Jvb3QnIHNlbWFudGljIHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8gJ25vdCB6eHgnLikKPiBUaGF0 J3Mgbm90ICoqdXNlZnVsbHkqKiB0YWdnZWQsIGJ1dCBpdCdzIHZhY3VvdXNseSBhbHdheXMgZ29p bmcgdG8gYmUKPiB2YWxpZGx5IHRhZ2dlZCDigJMgYmlnIGRlYWwuIEF0IGxlYXN0IHdpdGggdGhl ICd1bmNvZGVkJyBzZW1hbnRpYyB0aGV5IGNhbiB1c2UKPiBjaGFuZ2UgaGlzdG9yeSBmb3IgdGhl IGNvZGUgdGFibGUgYW5kIHRoZSByZWNvcmQgZGF0ZSB0byBkZXJpdmUgYSBzaG9ydCBsaXN0Cj4g b2Ygd2hhdCBsYW5ndWFnZXMgIm1pcyIgY29udGVudCBtaWdodCBiZSBpbiDigJMgYSBwYWluLCBi dXQgdGhhdCdzIGFjdHVhbGx5Cj4gbW9yZSB1c2VmdWwgdGhhdCAnc29tZSBsYW5ndWFnZScuCj4K Pgo+Cj4KPgo+IFBldGVyCj4KPgo+Cj4gKkZyb206KiBtYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5j b20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dICpPbgo+IEJlaGFsZiBPZiAq TWFyayBEYXZpcwo+ICpTZW50OiogTW9uZGF5LCBKdW5lIDE4LCAyMDA3IDE6NDkgUE0KPiAqVG86 KiBQZXRlciBDb25zdGFibGUKPiAqQ2M6KiBMVFJVIFdvcmtpbmcgR3JvdXA7IGlldGYtbGFuZ3Vh Z2VzQGlhbmEub3JnOyBpc282MzktMkBsb2MuZ292Owo+IGlzb2phY0Bsb2MuZ292OyBpc282MzlA ZGt1dWcuZGsKPiAqU3ViamVjdDoqIFJlOiBbTHRydV0gUkU6IChpc282MzkuMjcwOCkgUkU6IElT TyA2MzktMiBkZWNpc2lvbjogIm1pcyIKPgo+Cj4KPiBJIHJlYWxseSBkaWRuJ3Qgd2FudCB0byBz dGFydCBhIGZsYW1lIGFib3V0IHRoaXM7IEknbSBzb3JyeSBpZiB3aGF0IEkgc2FpZAo+IHdhcyBi ZSBjb25zaWRlcmVkIGluY2VuZGlhcnkuCj4KPiBUaGlzIHdob2xlIGlzc3VlIGlzIG5vdCByZWFs bHkgY29ubmVjdGVkIHdpdGggdGhlIGNoYW5nZSBmcm9tIHBhcnQgMiB0bwo+IHBhcnQgMywgYXQg YWxsLiBUYWtlIHlvdXIgZXhhbXBsZTogaXQgaXMgYSBwcm9ibGVtIHdpdGggeW91ciBkZWZpbml0 aW9uIG9mCj4gIm1pcyIgaW4gQkNQIDQ3IHdoZXRoZXIgImJyayIgd2VyZSBhZGRlZCBiZWNhdXNl IG9mIDYzOS0zIE9SIGp1c3QgYmVjYXVzZSBpdAo+IHdlcmUgYWRkZWQgdG8gSVNPIDYzOS0yISBJ dCBpcyBhbiBpc3N1ZSB3aGVuZXZlciBuZXcgY29kZXMgY291bGQgYmUgYWRkZWQKPiB0aGF0IHdv dWxkIGludmFsaWRhdGUgcHJldmlvdXMgdXNhZ2Ugb2YgIm1pcyIuCj4KPiBBbmQgdGhlIHNhZCB0 aGluZyBpcyB0aGF0IHRoaXMgaW5zdGFiaWxpdHkgaW4gSVNPIGNvZGVzIGlzIGNvbXBsZXRlbHkK PiBhdm9pZGFibGUuIFRoZXJlIGlzIGEgcGVyZmVjdGx5IGdvb2Qgd2F5IHRvIGhhdmUgdGhlIHNh bWUgZnVuY3Rpb25hbGl0eQo+ICp3aXRob3V0KiBiZWluZyB1bnN0YWJsZS4KPgo+ICAgIC0gSGF2 ZSBhIGNvZGUgSSdsbCBjYWxsIGhlcmUgInJvb3QiICh0byBhdm9pZCBhbnkgbWlzdW5kZXJzdGFu ZGluZwo+ICAgIGFib3V0IHRoZSBtZWFuaW5nIG9mICJtaXMiLikKPiAgICAtIEhhdmUgaXQgYmUg dmFsaWQgdG8gdGFnIGFueSBsYW5ndWFnZSBjb250ZW50IHdpdGggInJvb3QiLgo+ICAgIC0gU3Rh dGUgdGhhdCBvbmUgU0hPVUxEIHRhZyBhcyBuYXJyb3dseSBhcyBwb3NzaWJsZSwgdGh1cyBhdm9p ZAo+ICAgICJyb290IiBpZiB0aGVyZSBpcyBhIG1vcmUgc3BlY2lmaWMgbGFuZ3VhZ2UgY29kZS4K Pgo+IFRoaXMgY29tcGxldGVseSB0YWtlcyB0aGUgcGxhY2Ugb2YgdGhlIG5lZWQgeW91IHNlZSBm b3IgIm1pcyIsICp3aXRob3V0Cj4gYmVpbmcgdW5zdGFibGUqLiBJZiBJIGhhdmUgc29tZSBCdXJ1 c2hhc2tpIGNvbnRlbnQsIHdoZXJlIGEgY29kZSBkb2Vzbid0Cj4gZXhpc3QsIEkgdGFnIGl0IHdp dGggInJvb3QiLiBUaGF0IGlzIHZhbGlkIG5vdywgYW5kIHJlbWFpbnMgdmFsaWQgZm9yZXZlciwK PiBldmVuIG9uY2UgImJyayIgaXMgYWRkZWQgLS0gd2hldGhlciAiYnJrIiB3ZXJlIGFkZGVkIGJl Y2F1c2Ugb2YgNjM5LTMgb3IKPiBqdXN0IGJlY2F1c2UgaXQgd2VyZSBhZGRlZCB0byBJU08gNjM5 LTIuCj4KPiBNYXJrCj4KPiBPbiA2LzE4LzA3LCAqUGV0ZXIgQ29uc3RhYmxlKiA8cGV0ZXJjb25A bWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiBBcyBmYXIgYXMgdGhlIEpBQyBpcyBjb25jZXJuZWQs IHRoZSBpbnRlbnRpb25hbCBzZW1hbnRpYyBvZiAibWlzIiBpcyB3aGF0Cj4gaXQgaGFzIGFsd2F5 cyBiZWVuLiBBcyBmb3IgdGhlIGV4dGVuc2lvbiwgd2hlbiA2MzktMiB3YXMgdGhlIG9ubHkgYWxw aGEtMwo+IGNvZGUsIHRoZXJlIHdhcyBvbmx5IG9uZSBjb250ZXh0IHRvIGV2YWx1YXRlIHRoZSBl eHRlbnNpb24gdGhhdCB3b3VsZCBiZQo+IGRlcml2ZWQgYnkgdGhhdCBpbnRlbnRpb247IDYzOS0y IGRpZCBub3QgZG9jdW1lbnQgdGhlIGV4dGVuc2lvbiwgdGhvdWdoIGF0Cj4gbGVhc3Qgb25lIGFw cGxpY2F0aW9uIG9mIDYzOS0yIOKAkyBNQVJDIOKAkyBkaWQuIFdpdGggdGhlIGludHJvZHVjdGlv biBvZiA2MzktMwo+IGFuZCB0aGUgcGVuZGluZyBpbnRyb2R1Y3Rpb24gb2YgNjM5LTUgYXMgYWRk aXRpb25zIHRvIHRoZSBhbHBoYS0zIHNwYWNlLCBpdAo+IGJlY29tZXMgY2xlYXIgdGhhdCB0aGUg ZXh0ZW5zaW9uIG11c3QgYmUgZGV0ZXJtaW5lZCB3aXRoaW4gYSBjb250ZXh0OiB0aGUKPiBjYXNl cyB3aGVyZSB5b3UnZCB3YW50IHRvIHVzZSAibWlzIiBkaWZmZXIgaWYgeW91J3JlIHVzaW5nIDYz OS0zIHJhdGhlciB0aGFuCj4gNjM5LTIuIEJ1dCBmb3IgYW4gYXBwbGljYXRpb24gb2YgYSBnaXZl biBwYXJ0IG9mIDYzOSwgdGhlIGNoYW5nZSBvZgo+IHJlZmVyZW5jZSBuYW1lIGhhcyBoYWQgbm8g ZWZmZWN0IG9uIHRoZSBleHRlbnNpb24gZm9yIHRoYXQgY29udGV4dDogdGhlCj4gbGFuZ3VhZ2Vz IGVuY29tcGFzc2VkIGJ5ICJtaXMiIGluIGEgNjM5LTIgYXBwbGljYXRpb24sIGZvciBpbnN0YW5j ZSwgYXJlIHRoZQo+IHNhbWUgYXMgdGhleSB3ZXJlIGJlZm9yZS4KPgo+Cj4KPiBXaGVuIGl0IGNv bWVzIHRvIEJDUCA0NywgdGhlIGNoYW5nZSBvZiByZWZlcmVuY2UgbmFtZSBmb3IgIm1pcyIgaXMK PiBiYXNpY2FsbHkgaXJyZWxldmFudCBiZWNhdXNlIHRoZXJlIGlzIGEgbXVjaCBiaWdnZXIgaXNz dWU6IGluIFJGQzQ2NDZiaXMsCj4gQkNQIDQ3IHdpbGwgY2hhbmdlIGZyb20gYmVpbmcgYW4gYXBw bGljYXRpb24gb2YgNjM5LTEgYW5kIC0yIHRvIGJlaW5nIGFuCj4gYXBwbGljYXRpb24gb2YgNjM5 LTEsIC0yIGFuZCAtMy4gVGhhdCBjaGFuZ2Ugb2YgY29udGV4dCBpcyB3aGF0IGNyZWF0ZXMgdGhl Cj4gaXNzdWUgd3J0IGludGVyb3BlcmFiaWxpdHkgb2YgIm1pcyIgaW4gYXBwbGljYXRpb25zIG9m IEJDUCA0NzogVW5kZXIgUkZDCj4gNDY0NiwgQnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRh Z2dlZCAibWlzIjsgdW5kZXIgUkZDIDQ2NDZiaXMsIG9uZSB3b3VsZAo+IGV4cGVjdCBuZXcgQnVy dXNoYXNraSBjb250ZW50IHRvIGJlIHRhZ2dlZCAiYnNrIi4gVGhlcmUncyBubyBiYXNpcyBmb3IK PiBtYXRjaGluZzogdGhhdCdzIGFuIGludGVyb3AgcHJvYmxlbS4gQW5kIG5vdGUgdGhhdCBpdCBo YXMgbm90aGluZyB0byBkbyB3aXRoCj4gc3RhYmlsaXR5IG9mICJtaXMiIHN1cHBvc2VkbHkgaW50 cm9kdWNlZCB3aXRoIHRoZSBuYW1lIGNoYW5nZTogd2l0aCBvcgo+IHdpdGhvdXQgdGhhdCBjaGFu Z2UsIEJ1cnVzaGFza2kgY29udGVudCB3b3VsZCBiZSB0YWdnZWQgZGlmZmVyZW50bHkgYmVmb3Jl Cj4gYW5kIGFmdGVyLgo+Cj4KPgo+IEFuZCBub3RlIHRoYXQgdGhpcyBpc3N1ZSBleGlzdHMgd2hl dGhlciBvbmUgY29uc2lkZXJzICJvbGQgbWlzIiB0byBoYXZlCj4gdGhlIHNlbWFudGljIHRoYXQg S2VsZCBpcyBzdHVjayBvbiwgJ2FsbCBsYW5ndWFnZXMnLCBvciB0aGUgc2VtYW50aWMgdGhhdAo+ IHRoZSBKQUMgaGFzIGFsd2F5cyBpbnRlbmRlZDogZWl0aGVyIHdheSwgaXQgaXMgdGhlIGFkZGl0 aW9uIG9mIDYzOS0zIHRvIEJDUAo+IDQ3IHRoYXQgY3JlYXRlcyBhbiBpc3N1ZSBmb3IgdXNlcyBv ZiAibWlzIiB1bmRlciBCQ1AgNDcsIG5vdCB0aGUgbmFtZQo+IGNoYW5nZS4KPgo+Cj4KPiBBbmQg ZXZlbiB3aXRob3V0IHRoZSBhZGRpdGlvbiBvZiA2MzktMywgIm1pcyIgd291bGQgaGF2ZSBpbnRl cm9wIGlzc3VlczoKPiBhc3N1bWluZyB0aGUgc2VtYW50aWMgdGhlIEpBQyBoYXMgYWx3YXlzIGFz c3VtZWQsIHRoZSBleHRlbnNpb24gaW4gdGhlCj4gY29udGV4dCBvZiA2MzktMiBjb3VsZCBuYXJy b3cg4oCTIGluaGVyZW50bHkgYnkgdGhlIG5hdHVyZSBvZiB0aGUgc2VtYW50aWMg4oCTCj4gYW55 IHRpbWUgYSBuZXcgZW50cnkgd2FzIGFkZGVkOyBidXQgYXNzdW1pbmcgdGhlICdhbGwgbGFuZ3Vh Z2VzJyBzZW1hbnRpYywKPiBvbmUgY291bGQgZW5kIHVwIHdpdGggY29tcGFyYWJsZSBjb250ZW50 IHRhZ2dlZCBpbiBub24tY29tcGFyYWJsZSB3YXlzLAo+ICJtaXMiIGFuZCBzb21ldGhpbmcgZWxz ZS4KPgo+Cj4KPiBUaGVyZWZvcmUsIEkgc3VnZ2VzdCB0aGF0IGJlYXRpbmcgdXAgSVNPIGFzIG5v dCBiZWluZyBpbiB0dW5lIHdpdGggdGhlCj4gbmVlZHMgb2YgdGhlIElUIGNvbW11bml0eSBpcyBi b3RoIGZydWl0bGVzcyBhbmQgYmFzZWxlc3MsIGFuZCBpcyBpZ25vcmluZwo+IHRoZSBmYWN0IHRo YXQgSUVURiBoYXMgcHJvYmxlbXMgYWxsIG9mIGl0cyBvd24gbWFraW5nLiBJZiBJRVRGIHJlYWxs eSB3YW50ZWQKPiB0byBhdm9pZCBhbnkgc3RhYmlsaXR5IG9yIGludGVyb3AgcHJvYmxlbXMgcmVs YXRlZCB0byAibWlzIiwgaXQgc2hvdWxkIG5ldmVyCj4gaGF2ZSBwZXJtaXR0ZWQgaXRzIHVzZSBp biBsYW5ndWFnZSB0YWdzLCBzdGFydGluZyBiYWNrIGluIFJGQyAxNzY2LCBiZWNhdXNlCj4gIm1p cyIgaGFzIGFsd2F5cyBoYWQgc3RhYmlsaXR5IC8gaW50ZXJvcCBpc3N1ZXMuIEJ1dCB0aGF0IGhv cnNlIGlzIGxvbmcgb3V0Cj4gb2YgdGhlIGJhcm46ICJtaXMiICoqY2FuKiogYmUgdXNlZCBpbiBs YW5ndWFnZSB0YWdzIHVuZGVyIFJGQ3MgZnJvbSAxNzY2Cj4gdG8gNDY0Ni4gVGhlIExUUlUgV0cg d2l0aGluIElFVEYgbmVlZHMgdG8gZGVjaWRlIHdoYXQgdG8gZG8gYWJvdXQgdGhhdCBpbgo+IFJG QyA0NjQ2YmlzLiBUaGF0J3MgYSBqb2IgZm9yIElFVEY7IHdlIGRvbid0IG5lZWQgdG8gY29udGlu dWUgYm90aGVyaW5nIEpBQwo+IG1lbWJlcnMgd2l0aCBJRVRGIGlzc3Vlcy4KPgo+Cj4KPgo+Cj4g UGV0ZXIKPgo+Cj4KPiAqRnJvbToqIG1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSBbbWFpbHRv OiBtYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dCj4gKk9uIEJlaGFsZiBPZiAqTWFyayBEYXZp cwo+ICpTZW50OiogTW9uZGF5LCBKdW5lIDE4LCAyMDA3IDk6MjMgQU0KPiAqVG86KiBQZXRlciBD b25zdGFibGUKPiAqQ2M6KiBLZW50IEthcmxzc29uOyBNaWxpY2VudCBLIFdld2Vya2E7IEpvaG4g Q293YW47IGlzbzYzOUBka3V1Zy5kazsKPiBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsgaXNvNjM5 LTJAbG9jLmdvdjsgaXNvamFjQGxvYy5nb3Y7IEhIakBzdGFuZGFyZC5ubzsKPiBMVFJVIFdvcmtp bmcgR3JvdXAKPiAqU3ViamVjdDoqIFJlOiAoaXNvNjM5LjI3MDgpIFJFOiBJU08gNjM5LTIgZGVj aXNpb246ICJtaXMiCj4KPgo+Cj4gVW5mb3J0dW5hdGVseSwgSVNPIGNvZGVzIGhhdmUgc29tZXdo YXQgb2YgYW4gaW1wZWRhbmNlIG1pc21hdGNoIHdpdGggdGhlCj4gbmVlZHMgb2YgdGhlIElUIGNv bW11bml0eTsgaW4gcGFydGljdWxhciwgc3RhYmlsaXR5LiBUaHVzIEJDUCA0NyBoYXMgdG8KPiBz dGFiaWxpemUgdGhvc2UgY29kZXM7IG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIGZvciB0aGUgZXhp c3RlbmNlIG9mIFJGQwo+IDQ2NDYuIFdoYXQgdGhhdCBtZWFucyBpcyB0aGF0IGlmIElTTyB0cmll cyB0byBuYXJyb3cgdGhlIG1lYW5pbmcgb2YgKmFueSoKPiBjb2RlLCB3aGV0aGVyIGl0IGlzIGEg ImNsYXJpZmljYXRpb24iIG9yIG5vdCwgd2UgaGF2ZSByZWFsbHkgb25seSB0d28KPiBjaG9pY2Vz Ogo+Cj4gMS4gS2VlcCB0aGUgYnJvYWRlciBzZW1hbnRpYywgd2hpY2ggZW5jb21wYXNzZXMgdGhl IG5ldyBJU08gbmFycm93IG9uZSwgb3IKPiAyLiBEZXByZWNhdGUgdGhlIGNvZGUgKGluIG9uZSB3 YXkgb3IgYW5vdGhlcikuCj4KPiBVbmxpa2UgbWFueSBvdGhlciBjb2RlcywgIm1pcyIgaXMgb25l IHRoYXQgd2UgY2FuIGRvIHdpdGhvdXQsIHNvICMyIHdhcyBhCj4gcmVhc29uYWJsZSBjaG9pY2Uu Cj4KPiBXaGF0IEkgd2FzIHRyeWluZyB0byBjb21lIHVwIHdpdGggbGFuZ3VhZ2UgdGhhdCB3ZSBj b3VsZCBhZ3JlZSBvbiBldmVuCj4gdGhvdWdoIHdlIGhhdmUgdmVyeSBkaWZmZXJlbnQgdmlld3Mg b24gdGhlIHV0aWxpdHkgYW5kIG1lYW5pbmcgb2YgJ21pcycuIEl0Cj4gc291bmRzIGxpa2Ugd2Ug YXJlIG9rIG9uIHRoZSBzdWdnZXN0ZWQgbGFuZ3VhZ2Ugb24gdGhlIG90aGVyIHRocmVhZCwgc28g SSdtCj4gaG9waW5nIHRoYXQgd2UgY2FuIHB1dCAibWlzIiB0byBiZWQuCj4KPiBNYXJrCj4KPiBP biA2LzE2LzA3LCAqUGV0ZXIgQ29uc3RhYmxlKiA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSA+IHdy b3RlOgo+Cj4gRnJvbTogS2VudCBLYXJsc3NvbiBbbWFpbHRvOiBrZW50Lmthcmxzc29uMTRAY29t aGVtLnNlXQo+Cj4gPiBXaXRoIHRoZSAib2xkIG1pcyIgb25lIGNvdWxkIGNvcnJlY3RseSBhcHBs eSAnbWlzJyBhcyBhIGxhbmd1YWdlCj4gPiBjb2RlIGZvciBhbnkgbGFuZ3VhZ2UKPgo+IFRoYXQg aGFzICpuZXZlciogYmVlbiB0aGUgaW50ZW50IG9mIElTTyA2MzkuIEl0IGlzIGFuIGV4dGVybmFs Cj4gaW50ZXJwcmV0YXRpb24sIGFkbWl0dGVkbHkgcG9zc2libGUgYmVjYXVzZSBJU08gNjM5IHdh cyBub3QgZnVsbHkgZXhwbGljaXQKPiB1cCB0byBub3cuIEJ1dCBmcm9tIHRoZSBwZXJzcGVjdGl2 ZSBvZiB0aGUgSkFDLCB0aGUgIm5ldyBtaXMiIGlzIGV4YWN0bHkgdGhlCj4gc2FtZSAibWlzIiBh cyB0aGUgIm9sZCBtaXMiLgo+Cj4KPiBQZXRlcgo+Cj4KPgo+Cj4gLS0KPiBNYXJrCj4KPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWls aW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydQo+Cj4KPgo+Cj4gLS0KPiBNYXJrCj4KCgoKLS0gCk1hcmsK ------=_Part_97738_29474851.1182280585575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline JnF1b3Q7cm9vdCZxdW90OyB3b3VsZCBiZSBqdXN0IGFzIHVzZWZ1bCBhcyAmcXVvdDttaXMmcXVv dDssIGlmIHlvdSBzdGlwdWxhdGlvbiB0aGF0IHBlb3BsZSBzaG91bGQgdGFnIHdpdGggYXMgbXVj aCBpbmZvcm1hdGlvbiBhcyB0aGV5IGhhdmUuIFRoZSBwcmFjdGljYWwgZWZmZWN0IHdvdWxkIGJl IGxpdHRsZSBkaWZmZXJlbnQgZXhjZXB0IHRoYXQgJnF1b3Q7cm9vdCZxdW90OyB3b3VsZCByZW1h aW4gdmFsaWQuCjxicj48YnI+QnV0IHRoZSBmdW5kYW1lbnRhbCBwcm9ibGVtIHdpdGggJnF1b3Q7 bWlzJnF1b3Q7IGlzIHRoYXQgaXQgaXMgdW5zdGFibGUsIGFuZCBpbGwtZGVmaW5lZC4gSWYgSSBn ZXQgJnF1b3Q7bWlzJnF1b3Q7IGluIGEgeWVhciBmcm9tIG5vdyBJIGhhdmUgbm8gaWRlYSB3aGV0 aGVyIHRoZSBvcmlnaW5hbCBpdGVtIHdhcyB0YWdnZWQgd2hlbiAmcXVvdDttaXMmcXVvdDsgZmly c3QgY2FtZSBvdXQgKDE5OTg/KSwgb3IgaW4gNDY0Niwgb3IgaW4gNDY0NmJpczsgSSBqdXN0IGRv biYjMzk7dCBrbm93IGFuZCBjYW4mIzM5O3Qga25vdy4gSWYgeW91IGhhZCBkZWZpbmVkICZxdW90 O21pcyZxdW90OyB0byBiZSAmcXVvdDt3aGF0ZXZlciBkaWRuJiMzOTt0IGhhdmUgYSBjb2RlIGlu IDE5OTgmcXVvdDssIHRoYXQgd291bGQgYXQgbGVhc3QgYmUgc3RhYmxlLCBhbmQgYWxsb3cgdmFs aWQgdGFncyB0byByZW1haW4gdmFsaWQuCjxicj48YnI+QW5kIGZyYW5rbHksIGlmIHlvdSBhcmUg Z29pbmcgdG8gdGhlIHRyb3VibGUgdG8gdGFnIGNvbnRlbnQgdGhhdCB5b3UmIzM5O3JlIGdvaW5n IHRvIGxhdGVyIHJldmlzaXQsIHlvdSYjMzk7ZCBiZSBmYXIgYmV0dGVyIG9mZiB0byB1c2UgYSB1 bmlxdWUgcHJpdmF0ZSB1c2UgY29kZSBmb3IgZWFjaCBtaXNzaW5nIGl0ZW0uIFRoYXQgd2F5IHlv dSBkb24mIzM5O3QgaGF2ZSB0byByZS1hbmFseXNlIGVhY2ggcGllY2Ugb2YgY29udGVudCBoYXZp bmcgJnF1b3Q7bWlzJnF1b3Q7IG9uIGl0Lgo8YnI+PGJyPkFueXdheSwgaXQgc291bmRzIGxpa2Ug dGhlIGxhc3QgbGFuZ3VhZ2UgcHJvcG9zZWQgZm9yICZxdW90O21pcyZxdW90OyBpcyBvayB3aXRo IGV2ZXJ5b25lLCBzbyB0aGlzIGRpc2N1c3Npb24gaXMgcmVhbGx5IG1vb3QuIFNvcnJ5IHRvIGhh dmUgcmFpc2VkIHlvdXIgaGFja2xlcyB3aXRoIG15IG9yaWdpbmFsIG1lc3NhZ2UuPGJyPjxicj5N YXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+Ck9uIDYvMTgvMDcsIDxi IGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBocmVm PSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQg MHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCgoKCgoKCgoKPGRpdiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5TdWdnZXN0aW5nIHRo YXQgJ3Jvb3QnIGF2b2lkcyBwcm9ibGVtcyBpcywgSU1PLCByYXRoZXIKYSBiaXQgb2YgZmFsc2Ug ZWNvbm9teS4gU3VyZSwgaWYgYSB0YWcgbWVhbnMgJ3NvbWUgbGFuZ3VhZ2UnLCB0aGVuCmNvbnRl bnQgc28gdGFnZ2VkIG5ldmVyIGJlY29tZXMgKjxiPmluY29ycmVjdGx5PC9iPiogdGFnZ2VkIHdo ZW4gYW4gSUQgZm9yIHRoZQpnaXZlbiBsYW5ndWFnZSBpcyBhZGRlZC4gQnV0IGxldCdzIGNvbnNp ZGVyIHdoZXRoZXIgaXQgaXMgKjxiPnVzZWZ1bGx5PC9iPioKdGFnZ2VkOiBjaGFuZ2luZyB0aGlu Z3Mgc28gdGhhdCBpdCBjb3VsZCBjb250aW51ZSB0byBiZSAqPGI+Y29ycmVjdGx5PC9iPioKdGFn Z2VkIHdvdWxkbid0IG1ha2UgaXQgbW9yZSAqPGI+dXNlZnVsbHk8L2I+KiB0YWdnZWQsIGFuZCBh cmd1YWJseSBtYWtlcwppdCBsZXNzIHNvLiA8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9w PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7Ij5UbyBzdWdnZXN0IHRoYXQgdXNlcnMgbmVlZG4ndCB3b3JyeSBhYm91dCB0aGVpciBjb250 ZW50CnRhZ2dlZCAncm9vdCcgYWZ0ZXIgYSBuZXcgbGFuZ3VhZ2UgaXMgY29kZWQgaXMgSU1PIGJh ZCBhZHZpY2UuIFRoZXkKY2VydGFpbmx5ICo8Yj5zaG91bGQ8L2I+KiB3b3JyeSBpZiB0aGV5IHdh bnQgdGhlaXIgZGF0YSB0byBiZSB1c2VmdWw6IHRoZXknbGwKd2FudCB0byByZS10YWcgdGhlIHJl bGV2YW50IGNvbnRlbnQgd2l0aCB0aGUgbmV3bHktY29kZWQgSUQsIGVsc2UgdGhleSBlbmQgdXAK d2l0aCBkYXRhIHRoYXQgd29uJ3QgY29tcGFyZS4gQXQgbGVhc3QgaWYgdGhleSBrbm93IHRoYXQg dGhlIGFkZGl0aW9uCndpbGwgbmFycm93IHRoZSBleHRlbnNpb24gYW5kIHBvdGVudGlhbGx5IGlu dmFsaWRhdGUgdGFnZ2luZyBvbiBzb21lIG9mIHRoZWlyCmNvbnRlbnQsIHRoZXkncmUgbW9yZSBs aWtlbHkgdG8gcGF5IGF0dGVudGlvbjsgd2hhdCB5b3Ugc3VnZ2VzdCBjYW4gZ2l2ZQp0aGUgaW1w cmVzc2lvbiB0aGF0IHRoZXkgZG9uJ3QgaGF2ZSBhbnkgcGFydGljdWxhciB3b3JyeSwgd2hpY2gg aXMgbm90CnRoZSBjYXNlLiA8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BIHRh ZyB3aXRoIHRoZSAncm9vdCcgc2VtYW50aWMgY2FuIGFsd2F5cyBtZWFuCmFueXRoaW5nIOKAkyB3 aGljaCBtZWFucyBpdCdzIG5lYXJseSB2b2lkIG9mIG1lYW5pbmcgYW5kIGlzIGFib3V0IGFzCnVz ZWZ1bCBhcyBub3QgaGF2aW5nIHRhZ2dlZCBpdCBhdCBhbGwgaW4gdGhlIGZpcnN0IHBsYWNlLiAo VGhlICdyb290JwpzZW1hbnRpYyB3b3VsZCBiZSBlcXVpdmFsZW50IHRvICdub3Qgenh4Jy4pIFRo YXQncyBub3QgKjxiPnVzZWZ1bGx5PC9iPioKdGFnZ2VkLCBidXQgaXQncyB2YWN1b3VzbHkgYWx3 YXlzIGdvaW5nIHRvIGJlIHZhbGlkbHkgdGFnZ2VkIOKAkyBiaWcgZGVhbC4KQXQgbGVhc3Qgd2l0 aCB0aGUgJ3VuY29kZWQnIHNlbWFudGljIHRoZXkgY2FuIHVzZSBjaGFuZ2UgaGlzdG9yeSBmb3IK dGhlIGNvZGUgdGFibGUgYW5kIHRoZSByZWNvcmQgZGF0ZSB0byBkZXJpdmUgYSBzaG9ydCBsaXN0 IG9mIHdoYXQgbGFuZ3VhZ2VzICJtaXMiCmNvbnRlbnQgbWlnaHQgYmUgaW4g4oCTIGEgcGFpbiwg YnV0IHRoYXQncyBhY3R1YWxseSBtb3JlIHVzZWZ1bCB0aGF0ICdzb21lCmxhbmd1YWdlJy48L3Nw YW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5QZXRl cjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8ZGl2IHN0eWxlPSJib3JkZXItc3R5 bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMykgLW1v ei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yOyBib3JkZXItd2lkdGg6IDFwdCBt ZWRpdW0gbWVkaXVtOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPgoKPHA+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyI+CjxhIGhyZWY9Im1haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+bWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cm1h cmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbTwvYT5dIDxiPk9uIEJlaGFsZgpPZiA8L2I+TWFyayBE YXZpczxicj4KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxOCwgMjAwNyAxOjQ5IFBNPGJyPgo8 Yj5Ubzo8L2I+IFBldGVyIENvbnN0YWJsZTxicj4KPGI+Q2M6PC9iPiBMVFJVIFdvcmtpbmcgR3Jv dXA7IDxhIGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlc0BpYW5hLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5pZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppc282MzktMkBs b2MuZ292IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiPgppc282MzktMkBsb2MuZ292PC9hPjsKPGEgaHJlZj0ibWFp bHRvOmlzb2phY0Bsb2MuZ292IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5q cy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlzb2phY0Bsb2MuZ292PC9hPjsgPGEg aHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1Zy5kayIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KaXNvNjM5QGRrdXVn LmRrPC9hPjxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHRydV0gUkU6IChpc282MzkuMjcwOCkg UkU6IElTTyA2MzktMiBkZWNpc2lvbjoKJnF1b3Q7bWlzJnF1b3Q7PC9zcGFuPjwvcD4KCjwvZGl2 PjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExMzQxNzc4ZWUwODg3OWVfMSI+Cgo8cD4mbmJz cDs8L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+SSByZWFsbHkgZGlkbiYj Mzk7dCB3YW50IHRvIHN0YXJ0CmEgZmxhbWUgYWJvdXQgdGhpczsgSSYjMzk7bSBzb3JyeSBpZiB3 aGF0IEkgc2FpZCB3YXMgYmUgY29uc2lkZXJlZCBpbmNlbmRpYXJ5Ljxicj4KPGJyPgpUaGlzIHdo b2xlIGlzc3VlIGlzIG5vdCByZWFsbHkgY29ubmVjdGVkIHdpdGggdGhlIGNoYW5nZSBmcm9tIHBh cnQgMiB0byBwYXJ0IDMsCmF0IGFsbC4gVGFrZSB5b3VyIGV4YW1wbGU6IGl0IGlzIGEgcHJvYmxl bSB3aXRoIHlvdXIgZGVmaW5pdGlvbiBvZgomcXVvdDttaXMmcXVvdDsgaW4gQkNQIDQ3IHdoZXRo ZXIgJnF1b3Q7YnJrJnF1b3Q7IHdlcmUgYWRkZWQgYmVjYXVzZSBvZiA2MzktMwpPUiBqdXN0IGJl Y2F1c2UgaXQgd2VyZSBhZGRlZCB0byBJU08gNjM5LTIhIEl0IGlzIGFuIGlzc3VlIHdoZW5ldmVy IG5ldyBjb2Rlcwpjb3VsZCBiZSBhZGRlZCB0aGF0IHdvdWxkIGludmFsaWRhdGUgcHJldmlvdXMg dXNhZ2Ugb2YgJnF1b3Q7bWlzJnF1b3Q7LiA8YnI+Cjxicj4KQW5kIHRoZSBzYWQgdGhpbmcgaXMg dGhhdCB0aGlzIGluc3RhYmlsaXR5IGluIElTTyBjb2RlcyBpcyBjb21wbGV0ZWx5CmF2b2lkYWJs ZS4gVGhlcmUgaXMgYSBwZXJmZWN0bHkgZ29vZCB3YXkgdG8gaGF2ZSB0aGUgc2FtZSBmdW5jdGlv bmFsaXR5Cip3aXRob3V0KiBiZWluZyB1bnN0YWJsZS4gPC9zcGFuPjwvcD4KCjx1bCB0eXBlPSJk aXNjIj4KIDxsaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+SGF2ZSBhIGNvZGUgSSYj Mzk7bGwKICAgICBjYWxsIGhlcmUgJnF1b3Q7cm9vdCZxdW90OyAodG8gYXZvaWQgYW55IG1pc3Vu ZGVyc3RhbmRpbmcgYWJvdXQgdGhlCiAgICAgbWVhbmluZyBvZiAmcXVvdDttaXMmcXVvdDsuKSA8 L3NwYW4+PC9saT4KIDxsaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+SGF2ZSBpdCBi ZSB2YWxpZAogICAgIHRvIHRhZyBhbnkgbGFuZ3VhZ2UgY29udGVudCB3aXRoICZxdW90O3Jvb3Qm cXVvdDsuPC9zcGFuPjwvbGk+CiA8bGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPlN0 YXRlIHRoYXQgb25lCiAgICAgU0hPVUxEIHRhZyBhcyBuYXJyb3dseSBhcyBwb3NzaWJsZSwgdGh1 cyBhdm9pZCAmcXVvdDtyb290JnF1b3Q7IGlmIHRoZXJlCiAgICAgaXMgYSBtb3JlIHNwZWNpZmlj IGxhbmd1YWdlIGNvZGUuIDwvc3Bhbj48L2xpPgo8L3VsPgoKPHAgc3R5bGU9Im1hcmdpbi1ib3R0 b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+VGhpcwpjb21wbGV0ZWx5 IHRha2VzIHRoZSBwbGFjZSBvZiB0aGUgbmVlZCB5b3Ugc2VlIGZvciAmcXVvdDttaXMmcXVvdDss ICp3aXRob3V0CmJlaW5nIHVuc3RhYmxlKi4gSWYgSSBoYXZlIHNvbWUgPC9zcGFuPkJ1cnVzaGFz a2kgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPmNvbnRlbnQsCndoZXJlIGEgY29kZSBk b2VzbiYjMzk7dCBleGlzdCwgSSB0YWcgaXQgd2l0aCAmcXVvdDtyb290JnF1b3Q7LiBUaGF0IGlz IHZhbGlkIG5vdywKYW5kIHJlbWFpbnMgdmFsaWQgZm9yZXZlciwgZXZlbiBvbmNlICZxdW90O2Jy ayZxdW90OyBpcyBhZGRlZCAtLSB3aGV0aGVyCiZxdW90O2JyayZxdW90OyB3ZXJlIGFkZGVkIGJl Y2F1c2Ugb2YgNjM5LTMgb3IganVzdCBiZWNhdXNlIGl0IHdlcmUgYWRkZWQgdG8KSVNPIDYzOS0y LiA8YnI+Cjxicj4KTWFyazwvc3Bhbj48L3A+Cgo8ZGl2PgoKPHA+PHNwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsiPk9uCjYvMTgvMDcsIDxiPlBldGVyIENvbnN0YWJsZTwvYj4gJmx0 OzxhIGhyZWY9Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayIg b25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnBl dGVyY29uQG1pY3Jvc29mdC5jb208L2E+Jmd0Owp3cm90ZTo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7Ij4gPC9zcGFuPjwvcD4KCjxkaXY+Cgo8ZGl2PgoKPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BcyBm YXIgYXMgdGhlIEpBQyBpcyBjb25jZXJuZWQsCnRoZSBpbnRlbnRpb25hbCBzZW1hbnRpYyBvZiAm cXVvdDttaXMmcXVvdDsgaXMgd2hhdCBpdCBoYXMgYWx3YXlzIGJlZW4uIEFzIGZvcgp0aGUgZXh0 ZW5zaW9uLCB3aGVuIDYzOS0yIHdhcyB0aGUgb25seSBhbHBoYS0zIGNvZGUsIHRoZXJlIHdhcyBv bmx5IG9uZSBjb250ZXh0CnRvIGV2YWx1YXRlIHRoZSBleHRlbnNpb24gdGhhdCB3b3VsZCBiZSBk ZXJpdmVkIGJ5IHRoYXQgaW50ZW50aW9uOyA2MzktMiBkaWQKbm90IGRvY3VtZW50IHRoZSBleHRl bnNpb24sIHRob3VnaCBhdCBsZWFzdCBvbmUgYXBwbGljYXRpb24gb2YgNjM5LTIg4oCTCk1BUkMg 4oCTIGRpZC4gV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIDYzOS0zIGFuZCB0aGUgcGVuZGluZyBp bnRyb2R1Y3Rpb24Kb2YgNjM5LTUgYXMgYWRkaXRpb25zIHRvIHRoZSBhbHBoYS0zIHNwYWNlLCBp dCBiZWNvbWVzIGNsZWFyIHRoYXQgdGhlIGV4dGVuc2lvbgptdXN0IGJlIGRldGVybWluZWQgd2l0 aGluIGEgY29udGV4dDogdGhlIGNhc2VzIHdoZXJlIHlvdSYjMzk7ZCB3YW50IHRvIHVzZQomcXVv dDttaXMmcXVvdDsgZGlmZmVyIGlmIHlvdSYjMzk7cmUgdXNpbmcgNjM5LTMgcmF0aGVyIHRoYW4g NjM5LTIuIEJ1dCBmb3IgYW4KYXBwbGljYXRpb24gb2YgYSBnaXZlbiBwYXJ0IG9mIDYzOSwgdGhl IGNoYW5nZSBvZiByZWZlcmVuY2UgbmFtZSBoYXMgaGFkIG5vCmVmZmVjdCBvbiB0aGUgZXh0ZW5z aW9uIGZvciB0aGF0IGNvbnRleHQ6IHRoZSBsYW5ndWFnZXMgZW5jb21wYXNzZWQgYnkKJnF1b3Q7 bWlzJnF1b3Q7IGluIGEgNjM5LTIgYXBwbGljYXRpb24sIGZvciBpbnN0YW5jZSwgYXJlIHRoZSBz YW1lIGFzIHRoZXkgd2VyZQpiZWZvcmUuPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4K CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+V2hlbiBpdCBjb21lcyB0byBCQ1AgNDcsIHRoZQpjaGFuZ2Ugb2YgcmVmZXJlbmNlIG5hbWUg Zm9yICZxdW90O21pcyZxdW90OyBpcyBiYXNpY2FsbHkgaXJyZWxldmFudCBiZWNhdXNlCnRoZXJl IGlzIGEgbXVjaCBiaWdnZXIgaXNzdWU6IGluIFJGQzQ2NDZiaXMsIEJDUCA0NyB3aWxsIGNoYW5n ZSBmcm9tIGJlaW5nIGFuCmFwcGxpY2F0aW9uIG9mIDYzOS0xIGFuZCAtMiB0byBiZWluZyBhbiBh cHBsaWNhdGlvbiBvZiA2MzktMSwgLTIgYW5kIC0zLiBUaGF0CmNoYW5nZSBvZiBjb250ZXh0IGlz IHdoYXQgY3JlYXRlcyB0aGUgaXNzdWUgd3J0IGludGVyb3BlcmFiaWxpdHkgb2YKJnF1b3Q7bWlz JnF1b3Q7IGluIGFwcGxpY2F0aW9ucyBvZiBCQ1AgNDc6IFVuZGVyIFJGQyA0NjQ2LCBCdXJ1c2hh c2tpIGNvbnRlbnQKd291bGQgYmUgdGFnZ2VkICZxdW90O21pcyZxdW90OzsgdW5kZXIgUkZDIDQ2 NDZiaXMsIG9uZSB3b3VsZCBleHBlY3QgbmV3CkJ1cnVzaGFza2kgY29udGVudCB0byBiZSB0YWdn ZWQgJnF1b3Q7YnNrJnF1b3Q7LiBUaGVyZSYjMzk7cyBubyBiYXNpcyBmb3IgbWF0Y2hpbmc6CnRo YXQmIzM5O3MgYW4gaW50ZXJvcCBwcm9ibGVtLiBBbmQgbm90ZSB0aGF0IGl0IGhhcyBub3RoaW5n IHRvIGRvIHdpdGggc3RhYmlsaXR5IG9mCiZxdW90O21pcyZxdW90OyBzdXBwb3NlZGx5IGludHJv ZHVjZWQgd2l0aCB0aGUgbmFtZSBjaGFuZ2U6IHdpdGggb3Igd2l0aG91dAp0aGF0IGNoYW5nZSwg QnVydXNoYXNraSBjb250ZW50IHdvdWxkIGJlIHRhZ2dlZCBkaWZmZXJlbnRseSBiZWZvcmUgYW5k IGFmdGVyLiA8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BbmQgbm90ZSB0aGF0 IHRoaXMgaXNzdWUgZXhpc3RzCndoZXRoZXIgb25lIGNvbnNpZGVycyAmcXVvdDtvbGQgbWlzJnF1 b3Q7IHRvIGhhdmUgdGhlIHNlbWFudGljIHRoYXQgS2VsZCBpcwpzdHVjayBvbiwgJiMzOTthbGwg bGFuZ3VhZ2VzJiMzOTssIG9yIHRoZSBzZW1hbnRpYyB0aGF0IHRoZSBKQUMgaGFzIGFsd2F5cyBp bnRlbmRlZDoKZWl0aGVyIHdheSwgaXQgaXMgdGhlIGFkZGl0aW9uIG9mIDYzOS0zIHRvIEJDUCA0 NyB0aGF0IGNyZWF0ZXMgYW4gaXNzdWUgZm9yCnVzZXMgb2YgJnF1b3Q7bWlzJnF1b3Q7IHVuZGVy IEJDUCA0Nywgbm90IHRoZSBuYW1lIGNoYW5nZS4gPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFu PjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+QW5kIGV2ZW4gd2l0aG91dCB0aGUgYWRkaXRpb24Kb2YgNjM5LTMsICZxdW90O21p cyZxdW90OyB3b3VsZCBoYXZlIGludGVyb3AgaXNzdWVzOiBhc3N1bWluZyB0aGUgc2VtYW50aWMg dGhlCkpBQyBoYXMgYWx3YXlzIGFzc3VtZWQsIHRoZSBleHRlbnNpb24gaW4gdGhlIGNvbnRleHQg b2YgNjM5LTIgY291bGQgbmFycm93CuKAkyBpbmhlcmVudGx5IGJ5IHRoZSBuYXR1cmUgb2YgdGhl IHNlbWFudGljIOKAkyBhbnkgdGltZSBhIG5ldyBlbnRyeQp3YXMgYWRkZWQ7IGJ1dCBhc3N1bWlu ZyB0aGUgJiMzOTthbGwgbGFuZ3VhZ2VzJiMzOTsgc2VtYW50aWMsIG9uZSBjb3VsZCBlbmQgdXAg d2l0aApjb21wYXJhYmxlIGNvbnRlbnQgdGFnZ2VkIGluIG5vbi1jb21wYXJhYmxlIHdheXMsICZx dW90O21pcyZxdW90OyBhbmQgc29tZXRoaW5nCmVsc2UuPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9z cGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+VGhlcmVmb3JlLCBJIHN1Z2dlc3QgdGhhdApiZWF0aW5nIHVwIElTTyBhcyBu b3QgYmVpbmcgaW4gdHVuZSB3aXRoIHRoZSBuZWVkcyBvZiB0aGUgSVQgY29tbXVuaXR5IGlzIGJv dGgKZnJ1aXRsZXNzIGFuZCBiYXNlbGVzcywgYW5kIGlzIGlnbm9yaW5nIHRoZSBmYWN0IHRoYXQg SUVURiBoYXMgcHJvYmxlbXMgYWxsIG9mCml0cyBvd24gbWFraW5nLiBJZiBJRVRGIHJlYWxseSB3 YW50ZWQgdG8gYXZvaWQgYW55IHN0YWJpbGl0eSBvciBpbnRlcm9wCnByb2JsZW1zIHJlbGF0ZWQg dG8gJnF1b3Q7bWlzJnF1b3Q7LCBpdCBzaG91bGQgbmV2ZXIgaGF2ZSBwZXJtaXR0ZWQgaXRzIHVz ZSBpbgpsYW5ndWFnZSB0YWdzLCBzdGFydGluZyBiYWNrIGluIFJGQyAxNzY2LCBiZWNhdXNlICZx dW90O21pcyZxdW90OyBoYXMgYWx3YXlzCmhhZCBzdGFiaWxpdHkgLyBpbnRlcm9wIGlzc3Vlcy4g QnV0IHRoYXQgaG9yc2UgaXMgbG9uZyBvdXQgb2YgdGhlIGJhcm46CiZxdW90O21pcyZxdW90OyAq PGI+Y2FuPC9iPiogYmUgdXNlZCBpbiBsYW5ndWFnZSB0YWdzIHVuZGVyIFJGQ3MgZnJvbSAxNzY2 IHRvCjQ2NDYuIFRoZSBMVFJVIFdHIHdpdGhpbiBJRVRGIG5lZWRzIHRvIGRlY2lkZSB3aGF0IHRv IGRvIGFib3V0IHRoYXQgaW4gUkZDCjQ2NDZiaXMuIFRoYXQmIzM5O3MgYSBqb2IgZm9yIElFVEY7 IHdlIGRvbiYjMzk7dCBuZWVkIHRvIGNvbnRpbnVlIGJvdGhlcmluZyBKQUMgbWVtYmVycwp3aXRo IElFVEYgaXNzdWVzLjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwv c3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPlBldGVyPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxkaXYg c3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItY29sb3I6IC1tb3ot dXNlLXRleHQtY29sb3I7IGJvcmRlci13aWR0aDogMXB0IG1lZGl1bSBtZWRpdW07IHBhZGRpbmc6 IDNwdCAwaW4gMGluOyI+Cgo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij4gPGEgaHJlZj0ibWFp bHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9 InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5tYXJrLmVkd2Fy ZC5kYXZpc0BnbWFpbC5jb20KPC9hPgpbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJrLmVkd2Fy ZC5kYXZpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpz Lk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cm1hcmsuZWR3YXJkLmRhdmlzQGdtYWls LmNvbTwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyayBEYXZpczxicj4KPGI+U2VudDo8L2I+ IE1vbmRheSwgSnVuZSAxOCwgMjAwNyA5OjIzIEFNPGJyPgo8Yj5Ubzo8L2I+IFBldGVyIENvbnN0 YWJsZTxicj4KPGI+Q2M6PC9iPiBLZW50IEthcmxzc29uOyBNaWxpY2VudCBLIFdld2Vya2E7IEpv aG4gQ293YW47IDxhIGhyZWY9Im1haWx0bzppc282MzlAZGt1dWcuZGsiIHRhcmdldD0iX2JsYW5r IiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+ aXNvNjM5QGRrdXVnLmRrPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGYtbGFuZ3VhZ2VzQGlhbmEu b3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3 aW5kb3csZXZlbnQsdGhpcykiPgppZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzwvYT47CjxhIGhyZWY9 Im1haWx0bzppc282MzktMkBsb2MuZ292IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJu IHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlzbzYzOS0yQGxvYy5nb3Y8 L2E+OyA8YSBocmVmPSJtYWlsdG86aXNvamFjQGxvYy5nb3YiIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cmlzb2ph Y0Bsb2MuZ292PC9hPjsgPGEgaHJlZj0ibWFpbHRvOkhIakBzdGFuZGFyZC5ubyIgdGFyZ2V0PSJf YmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRo aXMpIj5ISGpAc3RhbmRhcmQubm88L2E+OyBMVFJVIFdvcmtpbmcKR3JvdXA8YnI+CjxiPlN1Ympl Y3Q6PC9iPiBSZTogKGlzbzYzOS4yNzA4KSBSRTogSVNPIDYzOS0yIGRlY2lzaW9uOiAmcXVvdDtt aXMmcXVvdDs8L3NwYW4+PC9wPgoKPC9kaXY+Cgo8ZGl2PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTog MTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5VbmZvcnR1bmF0ZWx5LApJU08g Y29kZXMgaGF2ZSBzb21ld2hhdCBvZiBhbiBpbXBlZGFuY2UgbWlzbWF0Y2ggd2l0aCB0aGUgbmVl ZHMgb2YgdGhlIElUCmNvbW11bml0eTsgaW4gcGFydGljdWxhciwgc3RhYmlsaXR5LiBUaHVzIEJD UCA0NyBoYXMgdG8gc3RhYmlsaXplIHRob3NlIGNvZGVzOwpvbmUgb2YgdGhlIG1haW4gcmVhc29u cyBmb3IgdGhlIGV4aXN0ZW5jZSBvZiBSRkMgNDY0Ni4gV2hhdCB0aGF0IG1lYW5zIGlzIHRoYXQK aWYgSVNPIHRyaWVzIHRvIG5hcnJvdyB0aGUgbWVhbmluZyBvZiAqYW55KiBjb2RlLCB3aGV0aGVy IGl0IGlzIGEKJnF1b3Q7Y2xhcmlmaWNhdGlvbiZxdW90OyBvciBub3QsIHdlIGhhdmUgcmVhbGx5 IG9ubHkgdHdvIGNob2ljZXM6IDxicj4KPGJyPgoxLiBLZWVwIHRoZSBicm9hZGVyIHNlbWFudGlj LCB3aGljaCBlbmNvbXBhc3NlcyB0aGUgbmV3IElTTyBuYXJyb3cgb25lLCBvcjxicj4KMi4gRGVw cmVjYXRlIHRoZSBjb2RlIChpbiBvbmUgd2F5IG9yIGFub3RoZXIpLjxicj4KPGJyPgpVbmxpa2Ug bWFueSBvdGhlciBjb2RlcywgJnF1b3Q7bWlzJnF1b3Q7IGlzIG9uZSB0aGF0IHdlIGNhbiBkbyB3 aXRob3V0LCBzbyAjMgp3YXMgYSByZWFzb25hYmxlIGNob2ljZS4gPGJyPgo8YnI+CldoYXQgSSB3 YXMgdHJ5aW5nIHRvIGNvbWUgdXAgd2l0aCBsYW5ndWFnZSB0aGF0IHdlIGNvdWxkIGFncmVlIG9u IGV2ZW4gdGhvdWdoCndlIGhhdmUgdmVyeSBkaWZmZXJlbnQgdmlld3Mgb24gdGhlIHV0aWxpdHkg YW5kIG1lYW5pbmcgb2YgJiMzOTttaXMmIzM5Oy4gSXQgc291bmRzCmxpa2Ugd2UgYXJlIG9rIG9u IHRoZSBzdWdnZXN0ZWQgbGFuZ3VhZ2Ugb24gdGhlIG90aGVyIHRocmVhZCwgc28gSSYjMzk7bSBo b3BpbmcKdGhhdCB3ZSBjYW4gcHV0ICZxdW90O21pcyZxdW90OyB0byBiZWQuPGJyPgo8YnI+Ck1h cms8L3NwYW4+PC9wPgoKPGRpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5P biA2LzE2LzA3LCA8Yj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0 ZXJjb25AbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29t IDwvYT4mZ3Q7Cndyb3RlOjwvc3Bhbj48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJw dDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5Gcm9tOiBLZW50Ckthcmxzc29uIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmtlbnQua2FybHNzb24xNEBjb21oZW0uc2UiIHRhcmdldD0i X2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSI+CmtlbnQua2FybHNzb24xNEBjb21oZW0uc2U8L2E+XTxicj4KPGJyPgomZ3Q7IFdpdGgg dGhlICZxdW90O29sZCBtaXMmcXVvdDsgb25lIGNvdWxkIGNvcnJlY3RseSBhcHBseSAmIzM5O21p cyYjMzk7IGFzIGEgbGFuZ3VhZ2U8YnI+CiZndDsgY29kZSBmb3IgYW55IGxhbmd1YWdlPGJyPgo8 YnI+ClRoYXQgaGFzICpuZXZlciogYmVlbiB0aGUgaW50ZW50IG9mIElTTyA2MzkuIEl0IGlzIGFu IGV4dGVybmFsIGludGVycHJldGF0aW9uLAphZG1pdHRlZGx5IHBvc3NpYmxlIGJlY2F1c2UgSVNP IDYzOSB3YXMgbm90IGZ1bGx5IGV4cGxpY2l0IHVwIHRvIG5vdy4gQnV0IGZyb20KdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSBKQUMsIHRoZSAmcXVvdDtuZXcgbWlzJnF1b3Q7IGlzIGV4YWN0bHkgdGhl IHNhbWUKJnF1b3Q7bWlzJnF1b3Q7IGFzIHRoZSAmcXVvdDtvbGQgbWlzJnF1b3Q7LiA8YnI+Cjxi cj4KPGJyPgpQZXRlcjwvc3Bhbj48L3A+Cgo8L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7Ij48YnI+CjxiciBjbGVhcj0iYWxsIj4KPGJyPgotLSA8YnI+Ck1hcmsgPC9zcGFu PjwvcD4KCjwvZGl2PgoKPC9kaXY+Cgo8L2Rpdj4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAx MnB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPjxicj4KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Ckx0cnUgbWFpbGluZyBsaXN0PGJy Pgo8YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9 InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5MdHJ1QGlldGYu b3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sdHJ1PC9hPjwvc3Bhbj48L3A+Cgo8L2Rpdj4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7Ij48YnI+CjxiciBjbGVhcj0iYWxsIj4KPGJyPgotLSA8YnI+Ck1hcmsgPC9zcGFu PjwvcD4KCjwvc3Bhbj48L2Rpdj48L2Rpdj4KCjwvZGl2PgoKCjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFyawo= ------=_Part_97738_29474851.1182280585575-- --===============0492211750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0492211750==-- From ltru-bounces@ietf.org Tue Jun 19 15:25:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jK2-0004Or-P4; Tue, 19 Jun 2007 15:25:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0jK2-0004Om-I1 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jK2-0004Oe-8F for ltru@ietf.org; Tue, 19 Jun 2007 15:25:02 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jK0-0002q8-PI for ltru@ietf.org; Tue, 19 Jun 2007 15:25:02 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Oh86wwbEKGi0fw99vRBS/bVjM1GnNjynJo8uuEFV46SJIbIbUc1S13fQ9WhbW+iX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.203.13] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I0jJw-0007l0-3J for ltru@ietf.org; Tue, 19 Jun 2007 15:24:56 -0400 Message-ID: <00a501c7b2a7$8c20f080$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local><30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com><200706140947.l5E9lluo064252@dkuug.dk><4670F357020000DD00012ECE@ntgwgate.loc.gov><000101c7afe2$0c082ac0$a163f853@streamserve.com><30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com><30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> <30b660a20706181502u76e3e31dia7138ef721dd3734@mail.gmail.com> Date: Tue, 19 Jun 2007 12:25:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356dbe1565d074076db0269245f14426de9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Cross-posting X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "LTRU Working Group" > Cc: ; ; ; > Sent: Monday, June 18, 2007 3:02 PM > Subject: Fwd: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" > > Bounced again. It's a pain that the recipient limit is so low on LTRU. ... As cranky list admin and co-chair - With no comment on this specific message, I would ask that all posters to this list carefully consider: (1) does my post help advance the completion of the ltru WG's work? (e.g., address a specific problem by proposing specific text for the documents we are working on) (2) if cross-posting, does the message also advance the progress of the other mailing lists' work? (3) if you still think you need to cross-post, consider whether the issue might need to be split up into distinct questions to be addressed on the appropriate list. I'm actually starting to suspect the recipient threshold isn't low enough; the overwhelming majority of the ltru/ietf-languages crossposts have been, in my opinion, questionable if not simply inappropriate. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kq8-00062f-Uh; Tue, 19 Jun 2007 17:02:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0kq8-0005zY-BW for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kq8-0005yO-1K for ltru@ietf.org; Tue, 19 Jun 2007 17:02:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kq6-0001HN-PL for ltru@ietf.org; Tue, 19 Jun 2007 17:02:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 2EC8B240826; Tue, 19 Jun 2007 23:02:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 4C89012BF1; Tue, 19 Jun 2007 22:58:55 +0200 (CEST) Date: Tue, 19 Jun 2007 22:58:55 +0200 From: Stephane Bortzmeyer To: Addison Phillips Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619205855.GA19853@sources.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4677F589.3090003@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.7 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jun 19, 2007 at 08:26:01AM -0700, Addison Phillips wrote a message of 47 lines which said: > I guess I agree about adding "Macrolanguage" to the registry, except > that extlang, if preserved, already indicates this with "Prefix". Let me check that I understand. The only way, currently, to see if a language is a macrolanguage is to check if there exists at least one extlang which references it in its Prefix field? Correct? So, in SQL: SELECT Languages.code AS macrolanguage, count(Extlangs.code) AS Extlangs FROM Languages,Extlangs WHERE Extlangs.prefix = Languages.code GROUP BY Languages.code ORDER BY Languages.code; Which yields 54 macrolanguages in 4645bis, zap (Zapotec) being the one with the most extlangs, 58 (if we do not count the sign languages). Am I correct? (Sorry for using the IETF for my e-learning but I prefer to check before commenting.) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l2Z-000716-Ey; Tue, 19 Jun 2007 17:15:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0l2Y-000711-9S for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l2Y-00070t-04 for ltru@ietf.org; Tue, 19 Jun 2007 17:15:06 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0l2W-0004vU-LQ for ltru@ietf.org; Tue, 19 Jun 2007 17:15:05 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5JLEgba015947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 14:14:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=QNQpg9VvxtPPs+Wp54WV/F5vbTS03cFhpz5bGfRWOqq/uEBf9IUEd+IH/wh2gOw8 Message-ID: <46784742.9080009@yahoo-inc.com> Date: Tue, 19 Jun 2007 14:14:42 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> In-Reply-To: <20070619205855.GA19853@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Tue, Jun 19, 2007 at 08:26:01AM -0700, > Addison Phillips wrote > a message of 47 lines which said: > >> I guess I agree about adding "Macrolanguage" to the registry, except >> that extlang, if preserved, already indicates this with "Prefix". > > Let me check that I understand. The only way, currently, to see if a > language is a macrolanguage is to check if there exists at least one > extlang which references it in its Prefix field? Correct? > > So, in SQL: > > SELECT Languages.code AS macrolanguage, count(Extlangs.code) AS Extlangs > FROM Languages,Extlangs WHERE Extlangs.prefix = Languages.code > GROUP BY Languages.code ORDER BY Languages.code; > > Which yields 54 macrolanguages in 4645bis, zap (Zapotec) being the one > with the most extlangs, 58 (if we do not count the sign languages). > > Am I correct? (Sorry for using the IETF for my e-learning but I prefer > to check before commenting.) Essentially correct. Note that the proposals I've seen weren't to add pointers in the macrolanguage's record to the extlangs, but rather an additional pointer in the extlang to the macrolanguage. That strikes me as pointless except for the grandfathered ISO 639-2 codes enclosed by macrolanguages that can't be extlang. I take it you're suggesting (or interpreted the proposal) to mean that the macrolanguage would contain a pointer or pointers to its sublanguages. Hence something like: %% Type: language Subtag: zh Description: Chinese ... Encloses: yue,cmn,..... %% Is that what you had in mind? Note that this type of field could apply even when various grandfathering rules (hello "sh", etc.) don't permit the use of extlangs. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l9u-00027g-8t; Tue, 19 Jun 2007 17:22:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0l9t-00027b-Af for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l9t-00027O-0X for ltru@ietf.org; Tue, 19 Jun 2007 17:22:41 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0l9r-0006Yk-QH for ltru@ietf.org; Tue, 19 Jun 2007 17:22:40 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0l9f-0005hL-MD; Tue, 19 Jun 2007 17:22:27 -0400 Date: Tue, 19 Jun 2007 17:22:27 -0400 To: Addison Phillips Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619212227.GF12168@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46784742.9080009@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Note that the proposals I've seen weren't to add pointers in the > macrolanguage's record to the extlangs, but rather an additional pointer > in the extlang to the macrolanguage. That strikes me as pointless except > for the grandfathered ISO 639-2 codes enclosed by macrolanguages that > can't be extlang. Also 639-3 languages that aren't encompassed now but become so in future. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Economists were put on this planet to make astrologers look good. --Leo McGarry _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:23:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lAg-0002nP-M6; Tue, 19 Jun 2007 17:23:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lAf-0002k1-Ha for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lAf-0002jq-7w for ltru@ietf.org; Tue, 19 Jun 2007 17:23:29 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lAd-0006kX-SK for ltru@ietf.org; Tue, 19 Jun 2007 17:23:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DANgOrOelj/XNhbNbufelWFU9rg7+ly/w/RnDGFxes71xA9ORaAgpUM+t5FBXp/Y; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.203.13] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I0lAY-0003Ac-KI for ltru@ietf.org; Tue, 19 Jun 2007 17:23:23 -0400 Message-ID: <000801c7b2b8$183fa7e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com><007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81><30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com><20070619013433.GA15048@mercury.ccil.org><003701c7b238$16124fc0$6401a8c0@DGBP7M81><20070619140547.GB30227@mercury.ccil.org><4677F589.3090003@yahoo-inc.com><20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> Date: Tue, 19 Jun 2007 14:23:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93564e8028122784ade2011e1a934f7ba9cf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Stephane Bortzmeyer" > Cc: "LTRU Working Group" ; "Doug Ewell" > Sent: Tuesday, June 19, 2007 2:14 PM > Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE:ISO 639-2 decision: "mis")) ... > I take it you're suggesting (or interpreted the proposal) to mean that > the macrolanguage would contain a pointer or pointers to its > sublanguages. Hence something like: ... I don't think that is being proposed at all. Stephane just asked: > > Let me check that I understand. The only way, currently, to see if a > > language is a macrolanguage is to check if there exists at least one > > extlang which references it in its Prefix field? Correct? If whether a language is a macrolanguage is an important property, then it is worth discussing whether it should be flagged in its record, rather than requiring it to be computed by examining all other records. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lG4-0007Nt-S3; Tue, 19 Jun 2007 17:29:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lG3-0007No-Qn for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lG3-0007Ng-HK for ltru@ietf.org; Tue, 19 Jun 2007 17:29:03 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lG2-0000Qu-AB for ltru@ietf.org; Tue, 19 Jun 2007 17:29:03 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fKACRQLsaX+n7//UEwcbHLyCZq7FDyqOTo1qx79CW5AACy130vqAfT/kgtVsKRWQ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.203.13] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I0lFw-0006In-No for ltru@ietf.org; Tue, 19 Jun 2007 17:28:57 -0400 Message-ID: <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com><007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81><30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com><20070619013433.GA15048@mercury.ccil.org><003701c7b238$16124fc0$6401a8c0@DGBP7M81><20070619140547.GB30227@mercury.ccil.org><4677F589.3090003@yahoo-inc.com><20070619205855.GA19853@sources.org><46784742.9080009@yahoo-inc.com> <20070619212227.GF12168@mercury.ccil.org> Date: Tue, 19 Jun 2007 14:28:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93561ee9399a92ff7936810eb1ca6df2a06c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Addison Phillips" > Cc: "LTRU Working Group" ; "Doug Ewell" > Sent: Tuesday, June 19, 2007 2:22 PM > Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE:ISO 639-2 decision: "mis")) ... > Also 639-3 languages that aren't encompassed now but become so in > future. ... If there is a real expectation that this will happen, this will be critical to the extlang discussion, due to the implications for stability in encoding. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lLN-0003kL-U6; Tue, 19 Jun 2007 17:34:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lLM-0003kA-Qi for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lLM-0003jP-Go for ltru@ietf.org; Tue, 19 Jun 2007 17:34:32 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lLK-0001SJ-5g for ltru@ietf.org; Tue, 19 Jun 2007 17:34:32 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5JLYPXD096162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 14:34:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=dwVEZsncBqd0jQ+DWO9XUfgJE6MJtZP2Vy4eNxOGBcojEatTVJDnwpeD91eWuCjS Message-ID: <46784BE1.7000205@yahoo-inc.com> Date: Tue, 19 Jun 2007 14:34:25 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: extlang References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com><007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81><30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com><20070619013433.GA15048@mercury.ccil.org><003701c7b238$16124fc0$6401a8c0@DGBP7M81><20070619140547.GB30227@mercury.ccil.org><4677F589.3090003@yahoo-inc.com><20070619205855.GA19853@sources.org><46784742.9080009@yahoo-inc.com> <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> In-Reply-To: <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > ... >> Also 639-3 languages that aren't encompassed now but become so in >> future. > ... > > If there is a real expectation that this will happen, this > will be critical to the extlang discussion, due to the > implications for stability in encoding. > Yes, although I think we dealt with that: the encoding is stable and the newly enclosed language remains a primary language. Such an eventuality would be supremely icky. There was also a proposal (I think I made it) to limit extlangs to "at 4646bis birth only"---that is, only currently enclosed languages that are otherwise unencoded would be extlangs. This gets us the (for example) the enclosed Chinese dialects (etc.), but not any future extlangs. Future registrations would be primary language subtags only. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lOb-0005lQ-AW; Tue, 19 Jun 2007 17:37:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lOa-0005lG-78 for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lOZ-0005l7-Ts for ltru@ietf.org; Tue, 19 Jun 2007 17:37:51 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lOY-0002HF-Mo for ltru@ietf.org; Tue, 19 Jun 2007 17:37:51 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0lOY-0006bW-CZ; Tue, 19 Jun 2007 17:37:50 -0400 Date: Tue, 19 Jun 2007 17:37:50 -0400 To: Randy Presuhn Subject: Re: [Ltru] Re: extlang Message-ID: <20070619213750.GG12168@mercury.ccil.org> References: <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > If there is a real expectation that this will happen, I think it will. > this will be critical to the extlang discussion, due to the > implications for stability in encoding. I don't see why. Stability says that once a language subtag, always a language subtag: nothing is demoted to extlang subtag status. So languages that are encompassed in 639-2 today have the same status (language subtag) as languages encompassed in 639-3 later on. The more serious case is when an encompassed language is no longer encompassed or its macrolanguage is changed. We'd be free to change the proposed Macrolanguage: field, but the Prefix: field and Type: fields would have to remain. -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lVr-0000rx-I1; Tue, 19 Jun 2007 17:45:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lVr-0000rs-6c for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lVq-0000rk-TT for ltru@ietf.org; Tue, 19 Jun 2007 17:45:22 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lVo-000497-MW for ltru@ietf.org; Tue, 19 Jun 2007 17:45:22 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0lVh-0007Pe-8A; Tue, 19 Jun 2007 17:45:13 -0400 Date: Tue, 19 Jun 2007 17:45:13 -0400 To: Stephane Bortzmeyer Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070619214513.GH12168@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070619205855.GA19853@sources.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > Let me check that I understand. The only way, currently, to see if a > language is a macrolanguage is to check if there exists at least one > extlang which references it in its Prefix field? Correct? Alternatively, to look back at 639-3. There are currently two such properties in 639-6 that are not represented in the LSR: scope (individual, macrolanguage, collective) and type (living, [recently] extinct, ancient, historic [stage of a living language], constructed). I am neither for nor against including these properties in the LSR. They aren't necessary for validation, but they are probably useful in some circumstances. -- John Cowan http://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 17:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lhS-0000Iw-UP; Tue, 19 Jun 2007 17:57:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lhS-0000Ir-Et for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lhS-0000Ij-5L for ltru@ietf.org; Tue, 19 Jun 2007 17:57:22 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lhQ-0007VV-TN for ltru@ietf.org; Tue, 19 Jun 2007 17:57:22 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZspzT82MJLXxviGyNKfowQ6nyqpGh2MFwKhPNia498INWZpZJbzd5ZGW5HslMa32; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.203.13] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I0lhQ-0004mv-44 for ltru@ietf.org; Tue, 19 Jun 2007 17:57:20 -0400 Message-ID: <002401c7b2bc$d6d49400$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com><007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81><30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com><20070619013433.GA15048@mercury.ccil.org><003701c7b238$16124fc0$6401a8c0@DGBP7M81><20070619140547.GB30227@mercury.ccil.org><4677F589.3090003@yahoo-inc.com><20070619205855.GA19853@sources.org><46784742.9080009@yahoo-inc.com> <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> <46784BE1.7000205@yahoo-inc.com> Subject: Re: [Ltru] Re: extlang Date: Tue, 19 Jun 2007 14:57:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93564e9d60621ab4e94915b96f20cf86ce16350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Tuesday, June 19, 2007 2:34 PM > Subject: Re: [Ltru] Re: extlang ... > There was also a proposal (I think I made it) to limit extlangs to "at > 4646bis birth only"---that is, only currently enclosed languages that > are otherwise unencoded would be extlangs. This gets us the (for > example) the enclosed Chinese dialects (etc.), but not any future > extlangs. Future registrations would be primary language subtags only. ... I think it's important to keep in mind the "division of labor" between the ltru WG and the function of the ietf-languages@iana.org list. Here in the WG, we need to ensure that the registry and registration process ensure that the right bits get recorded in the right spots, and that the resulting language tag structure works. We only have to agree that there are cases of "enclosing languages" that make it worthwhile to represent this property in the regsitry, and to account for in in our matching algorithms. Deciding which specific languages are to be given such treatment does not belong here. We only need to concern oursevles with the question of whether it is a requirement (that seems to be agreed). If we cannot agree on a uniform way to handle these cases for the big batch of tags we'd like add, based entirely on the data from the standards from which we're importing this information, then I suggest that those details would most properly be hashed out on the ietf-languages list on a case-by-case basis. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 18:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0llS-0005TU-Q1; Tue, 19 Jun 2007 18:01:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0llR-0005FS-1S for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:01:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0llQ-0005FK-O4 for ltru@ietf.org; Tue, 19 Jun 2007 18:01:28 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0llP-0001S9-94 for ltru@ietf.org; Tue, 19 Jun 2007 18:01:28 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 19 Jun 2007 15:00:05 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 19 Jun 2007 15:01:26 -0700 From: Peter Constable To: LTRU Working Group Date: Tue, 19 Jun 2007 15:01:24 -0700 Subject: RE: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Thread-Topic: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Thread-Index: AceyoAZFFnRVjRlQQbKKgFRSsTM8CAAFn/Kw Message-ID: References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> In-Reply-To: <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Mark: the quoting behavior of your mail client is not consistent and extre= mely hard to follow.] From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Tuesday, June 19, 2007 11:31 AM > Premises > 1. The reason for making microlanguages be extlang > instead of primary sublanguages is so that > truncation-style matching will have better results. > 2. Fallback works when there is mutual comprehensibility (not necessarily= 100%, but to a high degree); if you fallback to something that is not comp= rehensible, then fallback has failed. I'd put this differently. Given macro ID "xxx" and encompassed micro ID "yy= y": 1. There is no direct connection between primary subtags "xxx" and "yyy"; a= connection would have to be maintained by tables in matching processes. Bu= t, if "yyy" always required "xxx" as a prefix, then that relationship is ca= rried in the tag itself, and because truncation gets used in matching (it's= part of basic filtering, extended filtering and lookup in 4647), a relatio= nship falls out from the matching process. 2. The relationship is important because there is a significant level of ex= isting usage of "xxx", and we want to allow for future usage of "yyy". The point about existing usage is significant here, I think. If "xxx" and "= yyy" were introduced at the same time and users adopted "yyy" while "xxx" n= ever took off, then there's no particular need to relate them. But if both = are going to get used (i.e. "xxx" would get used apart from "yyy", and "yyy= " would also get used -- whether that is with or without "xxx"), then we pr= obably want the relationship to be captured. > Option A. > 1. Thus for extlang to work for microlanguages, the > speakers of any microlanguages sharing a macrolanguage > need to be able to understand the speakers of any > other microlanguages sharing that macrolanguage. > 2. Peter and the ISO JAC can verify that A1 is true... A.2 may be a little more than JAC can guarantee. The idea I worked with is = that macrolanguages are coded because in some application the group of micr= olanguages are being coded as one -- they are not distinguished. Presumably= that would happen because they are mutually intelligible, though that may = not always be the case. I don't assume that Mandarin and Cantonese are mutually intelligible at a f= unctional level (though perhaps in their written forms they may be); approp= riately or not -- perhaps an accident of history -- a single ID "zh" has be= en used for both. What we need to do is to be able to relate *as appropriat= e* "zh" content with "Cantonese", "Mandarin", etc., or Cantonese, etc. cont= ent with requests for "zh". Similarly for other cases in which -- for whate= ver reason -- things are, in practice, sometimes split but sometimes clumpe= d. > Option B. > 1. The macrolanguage alone is always assumed to be > the "standard", and that can be identified. That is, > "zh" is always assumed to be Mandarin, "ar" is > always assumed to be "Standard Arabic", etc. (That > is, I think, the correct approach, but is *not* > currently in the spec.) Of course, this assumes that for macro/micro cases there always *is* one va= riety that can be considered *the* major variety. When Gary Simons first began to analyze 639-2 with a view to how to map it = onto Ethnologue, the original operational principles we established looked = for just that -- we referred to it as the "major language variety (MLV) pri= nciple". (See http://www.sil.org/silewp/2002/SILEWP2002-004.pdf, page 7.) T= he idea was that we would equate the existing 639-2 ID with *the* major var= iety, when one could be identified. Of course, we immediately encountered a= reality that there isn't always *one* major variety. See http://www.ethnol= ogue.com/14/iso639/analysis.asp#U for cases we found in our initial analysi= s that we could not resolve. I had expected we would try to work with the JAC to come up with some resol= ution for those cases. That was until the macrolanguage concept occurred to= me. And a key thing that prompted it was the pre-existing IANA registratio= ns involving zh: we could not equate "zh" with Mandarin because in existing= usage it was clearly being used for Mandarin, Cantonese, Minnan, etc. An a= vailable alternative was to consider "zh" to be a collection (and that was,= in fact, what we did in our initial analysis), but that just didn't reflec= t the way it was actually being used: "zh" was in widespread use as though = it represented an individual language. Somehow, I had to marry those two: i= n use as though it represents an individual language, but also in use for m= ultiple languages. Hence the prototype for macrolanguage. Now, you're introducing the possibility of having the one-language/many-lan= guage dichotomy while also maintaining the MLV principle. (Of course, the m= ost widespread use for an *individual* language would have involved for Man= darin.) Of course, that's not formalized in 639-3, but that doesn't block i= t from being a useful idea. One issue that would need to be worked out is w= hen "xxx" as an individual language is the MLV-preferred microlanguage, whe= n it's the undifferentiated group of microlanguages, or if this difference = matters in practice. But there's also the other issue: not all macrolanguages have one microlang= uage that's clearly picked out by the MLV principle. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 18:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lpp-0000RQ-Aa; Tue, 19 Jun 2007 18:06:01 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lpn-0000RG-PK for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lpn-0000R8-Fn for ltru@ietf.org; Tue, 19 Jun 2007 18:05:59 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lpm-0002Ee-68 for ltru@ietf.org; Tue, 19 Jun 2007 18:05:59 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 19 Jun 2007 15:04:36 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Tue, 19 Jun 2007 15:05:57 -0700 From: Peter Constable To: Randy Presuhn , LTRU Working Group Date: Tue, 19 Jun 2007 15:05:51 -0700 Subject: RE: [Ltru] Re: extlang Thread-Topic: [Ltru] Re: extlang Thread-Index: AceyuN63F1YZ4BK+T66UHd2ep/N6nQABNHIA Message-ID: References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com><007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81><30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com><20070619013433.GA15048@mercury.ccil.org><003701c7b238$16124fc0$6401a8c0@DGBP7M81><20070619140547.GB30227@mercury.ccil.org><4677F589.3090003@yahoo-inc.com><20070619205855.GA19853@sources.org><46784742.9080009@yahoo-inc.com> <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> In-Reply-To: <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It may help to consider realistic scenarios for future changes in 639, real= istic scenarios for usage of language tags, and weigh the value of comparis= on between two different tags that may be used for comparable content. Peter -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, June 19, 2007 2:29 PM To: LTRU Working Group Subject: [Ltru] Re: extlang Hi - As a technical contributor... > From: "John Cowan" > To: "Addison Phillips" > Cc: "LTRU Working Group" ; "Doug Ewell" > Sent: Tuesday, June 19, 2007 2:22 PM > Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE= :ISO 639-2 decision: "mis")) ... > Also 639-3 languages that aren't encompassed now but become so in > future. ... If there is a real expectation that this will happen, this will be critical to the extlang discussion, due to the implications for stability in encoding. 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 Tue Jun 19 18:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lvc-0006dr-BL; Tue, 19 Jun 2007 18:12:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0lvb-0006dl-Dz for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lvb-0006dd-4Q for ltru@ietf.org; Tue, 19 Jun 2007 18:11:59 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lvZ-00035f-QE for ltru@ietf.org; Tue, 19 Jun 2007 18:11:59 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 19 Jun 2007 15:10:35 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Tue, 19 Jun 2007 15:11:56 -0700 From: Peter Constable To: LTRU Working Group Date: Tue, 19 Jun 2007 15:11:54 -0700 Subject: RE: [Ltru] Re: extlang Thread-Topic: [Ltru] Re: extlang Thread-Index: AceyuhjN00DfjwzUSkeEyNFiIxcbgwABBBkA Message-ID: References: <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> <20070619213750.GG12168@mercury.ccil.org> In-Reply-To: <20070619213750.GG12168@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Is there a possibility of an encompassed language getting changed not to be= encompassed? If "xxx" is a macrolanguage and "yyy" an encompassed "microla= nguage" (to use Mark's term), I could perhaps see "xxx" getting deprecated,= but "yyy" getting dissociated from "xxx"? It really shouldn't happen: ther= e should have been *some* good reason for associated "yyy" with "xxx" in th= e first place, and that shouldn't go away. Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Tuesday, June 19, 2007 2:38 PM To: Randy Presuhn Cc: LTRU Working Group Subject: Re: [Ltru] Re: extlang Randy Presuhn scripsit: > If there is a real expectation that this will happen, I think it will. > this will be critical to the extlang discussion, due to the > implications for stability in encoding. I don't see why. Stability says that once a language subtag, always a language subtag: nothing is demoted to extlang subtag status. So languages that are encompassed in 639-2 today have the same status (language subtag) as languages encompassed in 639-3 later on. The more serious case is when an encompassed language is no longer encompassed or its macrolanguage is changed. We'd be free to change the proposed Macrolanguage: field, but the Prefix: field and Type: fields would have to remain. -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 19 20:38:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oDH-0005NK-NM; Tue, 19 Jun 2007 20:38:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0oDG-0005NF-GM for ltru-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 20:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oDG-0005N7-6s for ltru@ietf.org; Tue, 19 Jun 2007 20:38:22 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0oDF-0004rr-0E for ltru@ietf.org; Tue, 19 Jun 2007 20:38:22 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I0oDE-0002mA-1c; Tue, 19 Jun 2007 20:38:20 -0400 Date: Tue, 19 Jun 2007 20:38:20 -0400 To: Peter Constable Subject: Re: [Ltru] Re: extlang Message-ID: <20070620003819.GI12168@mercury.ccil.org> References: <20070619212227.GF12168@mercury.ccil.org> <000d01c7b2b8$dc7aa420$6601a8c0@oemcomputer> <20070619213750.GG12168@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > Is there a possibility of an encompassed language getting changed not to > be encompassed? If "xxx" is a macrolanguage and "yyy" an encompassed > "microlanguage" (to use Mark's term), I could perhaps see "xxx" > getting deprecated, but "yyy" getting dissociated from "xxx"? It > really shouldn't happen: there should have been *some* good reason > for associated "yyy" with "xxx" in the first place, and that shouldn't > go away. Human error would be the obvious candidate. "Oh, we thought Foovian was part of the Slobbovian macrolanguage, but that was because Dr. X put the wrong code on the form back in 2008." -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 20 02:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tuu-0005YL-Vx; Wed, 20 Jun 2007 02:43:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0tut-0005Y8-AP for ltru-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 02:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tus-0005Xt-Sw for ltru@ietf.org; Wed, 20 Jun 2007 02:43:46 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0tur-0001BU-3f for ltru@ietf.org; Wed, 20 Jun 2007 02:43:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5K6hgSw018207 for ; Wed, 20 Jun 2007 15:43:43 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 648b_962dfbf4_1ef9_11dc_9dd3_0014221f2a2d; Wed, 20 Jun 2007 15:43:42 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47711) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 20 Jun 2007 15:41:46 +0900 Message-Id: <6.0.0.20.2.20070620142945.0c911070@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 20 Jun 2007 14:31:35 +0900 To: "Mark Davis" , "John Cowan" From: Martin Duerst Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO639-2 decision: "mis")) In-Reply-To: <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com > References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:30 07/06/20, Mark Davis wrote: >But the main point is, I want those people who have tried to implement -- professionally, not just in toy programs -- extlang to speak up about their experiences. So if you want to speak to your experience implementing this professionally, I'm all ears. Hello Mark, I seem to remember that you said that you tried to implement them at Google and found them difficult. But I don't remember you having explained what exactly the problem is. If you have explained that, could you point to the relevant message? If not, would you care to give some more details? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 20 02:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tuv-0005YU-2k; Wed, 20 Jun 2007 02:43:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I0tut-0005Y9-AM for ltru-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 02:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tus-0005Xs-St for ltru@ietf.org; Wed, 20 Jun 2007 02:43:46 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0tur-0001BV-62 for ltru@ietf.org; Wed, 20 Jun 2007 02:43:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5K6hfui018099 for ; Wed, 20 Jun 2007 15:43:41 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6403_95275782_1ef9_11dc_965b_0014221f2a2d; Wed, 20 Jun 2007 15:43:40 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47711) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 20 Jun 2007 15:41:43 +0900 Message-Id: <6.0.0.20.2.20070620141534.0c910780@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 20 Jun 2007 14:17:02 +0900 To: "Mark Davis" , "Peter Constable" From: Martin Duerst Subject: Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: <30b660a20706191216w70bda8e4y41c5c6bae0819a8e@mail.gmail.co m> References: <5047AE57DE65594D80580AA61016E14A017C7F74@I2V-E2K3-004.i04.local> <30b660a20706132109y766cdecbu34d076bee7004af4@mail.gmail.com> <200706140947.l5E9lluo064252@dkuug.dk> <4670F357020000DD00012ECE@ntgwgate.loc.gov> <000101c7afe2$0c082ac0$a163f853@streamserve.com> <30b660a20706180923n7d1bd302r5a08d0db8afc727e@mail.gmail.com> <30b660a20706181349n7455f8a5o95d7541120739403@mail.gmail.com> <30b660a20706191216w70bda8e4y41c5c6bae0819a8e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "ietf-languages@iana.org" , "iso639-2@loc.gov" , LTRU Working Group , "isojac@loc.gov" , "iso639@dkuug.dk" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:16 07/06/20, Mark Davis wrote: >And frankly, if you are going to the trouble to tag content that you're going to later revisit, you'd be far better off to use a unique private use code for each missing item. That way you don't have to re-analyse each piece of content having "mis" on it. It may be possible that such a thing is used interally, but not sent out over the Internet, i.e. that "mis" is used on the Internet. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 20 13:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13lv-0004E9-OT; Wed, 20 Jun 2007 13:15:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I13lu-0004Ds-Qr for ltru-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 13:15:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13lu-0004DW-Ds for ltru@ietf.org; Wed, 20 Jun 2007 13:15:10 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I13lr-0008Ua-RG for ltru@ietf.org; Wed, 20 Jun 2007 13:15:10 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I13lm-000540-Tb; Wed, 20 Jun 2007 13:15:03 -0400 Date: Wed, 20 Jun 2007 13:15:02 -0400 To: Mark Davis Subject: Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070620171502.GL12168@mercury.ccil.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > My point was that anyone who wants to deal with macro languages, has to > already deal with sr, hr, etc. as primary subtags, not as secondary. It's not a MUST, it's a MAY. Matchers are allowed to take into account any information outside the purely syntactic match algorithms that they happen to have -- and find useful For example, a fallback from Scots to English probably makes sense everywhere -- if you know Scots, you know English. On the other hand, a fallback from Swedish to Finnish would be a Really Bad Idea, except within Finland, where it might make all the sense in the world. (Falling back from English to Scots or Finnish to Swedish essentially never makes sense.) So while there is no reason to prevent such nonsyntactic matching, and 4647 explicitly licenses it, there is no reason to require that every matcher use it either. The point of the extlang tags, like their currently-grandfathered predecessors, is to make additional matches easy. > 1. The reason for making microlanguages be extlang instead of primary > sublanguages is so that truncation-style matching will have better > results. Agreed. > 2. Fallback works when there is mutual comprehensibility (not > necessarily 100%, but to a high degree); if you fallback to something > that is not comprehensible, then fallback has failed. Two caveats: (a) fallback is one-way, so *mutual* comprehensibility is not required; (b) Mohawk and English aren't comprehensible at all, mutually or asymmetrically, but it so happens that the few hundred Mohawk-speakers know English too. Also, fallback is a matter of best effort; it does not have to work in every case to be useful in many cases. In particular, a failed fallback leaves you no worse off than before. > Option A. > > 1. Thus for extlang to work for microlanguages, the speakers of any > microlanguages sharing a macrolanguage need to be able to understand > the speakers of any other microlanguages sharing that macrolanguage. Not necessarily all, though the more the better, of course. > 2. Peter and the ISO JAC can verify that A1 is true; that every > speaker of Hakka can understand Jinyu; every speaker of Shihhi Arabic > can understand Cypriot Arabic; and so on). Of course that's not the case, as you must know. Even if true in any particular case, "every speaker" is an inappropriate standard. If there are one or two ancient Mohawks who don't have sufficient command of English, it can't be helped. > 3. Everything is hunky-dory. "Hunky-dory" is the wrong standard. > Option B. This doesn't differ much from Option A, except that it changes the semantics of macrolanguages in a way inconsistent with 639-3: > 1. The macrolanguage alone is always assumed to be the "standard", Otherwise my comments above apply. > After all, it is trivial to make a 4647bis that adds an optional step > for microlanguages, which is that when you get to a microlanguage, > the next step is to look at its macrolanguage before falling back to > the default. That has the same result (and same problems) as extlang, > but is something that is not baked into the standard -- is something > that people can implement if they want without impacting matching for > everyone else. True enough, but it disregards the behavior of the large number of naive matchers already out there that lack nonsyntactic information. It also disregards the well-chosen grandfathered tags (which will become for the most part redundant in 4646bis along the current lines), which were picked precisely because they worked tolerably, if not perfectly, with naive matchers. This is the primary argument for using extlangs: they are a conservative extension of what has already been done and what tags have already been assigned to documents. Your argument also proves too much: we find it useful to fall back from az-Cyrl, az-Latn, and az-Arab to plain az (or vice versa for filtering) without requiring that these be mutually intercomprehensible (your Option A) or that one of them is the standard (your Option B). The results may be less than ideal, but we live with it. > We and everyone else already have to deal with equivalences with > grandfathered and irregular tags anyway; these are not a real problem. Again, every one else does not *have to* deal with them; they MAY treat them just like all other tags, at the expense of missing some reasonable matches. 4647 makes such matches entirely optional. > I disagree strongly. If you can't make a compelling case that extlang > will make BCP 47 better instead of worse, and won't even look at the > reasons not to do it, nor even bother to set out a case for it, then > why should we add it? It's true, as Dr. Johnson said: "Of an opinion which is no longer doubted, the evidence ceases to be examined." I've done my best above. But I don't understand yet how extlangs make BCP 47 worse, and I think they actually help given legacy documents and legacy matchers. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Is it not written, "That which is written, is written"? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 01:24:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1FA6-00079x-UP; Thu, 21 Jun 2007 01:24:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1FA5-00079l-K3 for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 01:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1FA5-00079d-8B for ltru@ietf.org; Thu, 21 Jun 2007 01:24:53 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1FA3-00080I-Tw for ltru@ietf.org; Thu, 21 Jun 2007 01:24:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070621052451.EAHI28813.mta9.adelphia.net@DGBP7M81> for ; Thu, 21 Jun 2007 01:24:51 -0400 Message-ID: <003901c7b3c4$7e681220$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> <20070620171502.GL12168@mercury.ccil.org> Date: Wed, 20 Jun 2007 22:24:51 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As one of the people who got this thread started, I'm not ignoring it or anyone's position on it. Things just suddenly got very busy for me. I promise (or threaten, depending) to jump in as soon as I have more than two consecutive minutes to think about it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 01:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1FLS-0006f0-HC; Thu, 21 Jun 2007 01:36:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1FLR-0006es-Vi for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 01:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1FLR-0006ek-GZ for ltru@ietf.org; Thu, 21 Jun 2007 01:36:37 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1FLQ-0001ib-5l for ltru@ietf.org; Thu, 21 Jun 2007 01:36:37 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070621053635.IVCD3928.mta15.adelphia.net@DGBP7M81>; Thu, 21 Jun 2007 01:36:35 -0400 Message-ID: <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> <4677F51D.7000600@yahoo-inc.com> Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930 Date: Wed, 20 Jun 2007 22:36:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Proposal: RFC4645bis should preserve existing dates in the 4646-based > registry. Then pulling the "historical" (4646) registry would be possible. > Probably this is what you're doing already, Doug, but the text doesn't say > so. That is exactly what I'm doing, and thank you for bringing it up. In RFC 4645bis, existing records may be changed slightly to add language names listed in ISO 639-3, and to put the 639-3 "reference name" first, but in no case will the Added date of an existing record be changed. Thanks for the comment on RFC 4645bis -- there have been very few of those up to this point! -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 04:52:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IOq-0006o7-VQ; Thu, 21 Jun 2007 04:52:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1IOq-0006o2-Hu for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 04:52:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IOq-0006nu-3C for ltru@ietf.org; Thu, 21 Jun 2007 04:52:20 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1IOo-0005zx-Qi for ltru@ietf.org; Thu, 21 Jun 2007 04:52:20 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5C1561C011B; Thu, 21 Jun 2007 10:52:18 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 57A2A1C0090; Thu, 21 Jun 2007 10:52:17 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5407E58EB9C; Thu, 21 Jun 2007 10:52:17 +0200 (CEST) Date: Thu, 21 Jun 2007 10:52:17 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070621085217.GA14125@nic.fr> References: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> <4677F51D.7000600@yahoo-inc.com> <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group Subject: [Ltru] Modification of the Added field (Was: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Jun 20, 2007 at 10:36:35PM -0700, Doug Ewell wrote a message of 27 lines which said: > That is exactly what I'm doing, and thank you for bringing it up. > In RFC 4645bis, existing records may be changed slightly to add > language names listed in ISO 639-3, and to put the 639-3 "reference > name" first, but in no case will the Added date of an existing > record be changed. Is it already the case with 4646? Yes, according to section 3.4. "Stability of IANA Registry Entries" But, yesterday, the subtag baku1926 was modified (change in the Comments) and the Added field *was* modified, from 2007-04-18 to 2007-04-20, which puzzles me (why changing it and why for a date two months in the past?) IANA's blunder or ambiguity in the procedures/RFCs? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 11:19:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ORe-0007Mu-Bi; Thu, 21 Jun 2007 11:19:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1ORd-0007MP-Vk for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ORd-0007M4-M6 for ltru@ietf.org; Thu, 21 Jun 2007 11:19:37 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ORb-0003M9-6y for ltru@ietf.org; Thu, 21 Jun 2007 11:19:37 -0400 Received: by wa-out-1112.google.com with SMTP id j5so425828wah for ; Thu, 21 Jun 2007 08:19:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qipffp7iA5C8HzUWGX+EHc5LdUMa82+/fO7U+PE4iK6/JQWOtl+HZqbgZfZfbWBq9m4Y7JRK9QcWZUuBdzx6DTIF8YQl1BBflHFnXHjNswSr3r/RAW7EHTo10BD1IhEtl9m+NEyUGPz22bOwlK2bLT4ZuTYP9reL2CEy5MeKMlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UA0ehKxIyqwQ5GMNv4zIWB4ZQR6yiSLyhI4uu+HTMMmuh6vk9NGtb9L46uztTztCrZiiiPsiTwyq6k5jn66NTte/jdhNgDf48syJhOyg7vliMFL28AJq95aERIqOXlXGG6axYLGfWYdHcEGH5ob+IgMkKEJEx2D2fJZuOHoFsn4= Received: by 10.114.190.6 with SMTP id n6mr1712714waf.1182439174101; Thu, 21 Jun 2007 08:19:34 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Thu, 21 Jun 2007 08:19:34 -0700 (PDT) Message-ID: <30b660a20706210819j6804b6ber66817c009a03ab12@mail.gmail.com> Date: Thu, 21 Jun 2007 08:19:34 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: extlang In-Reply-To: <003901c7b3c4$7e681220$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <30b660a20706191130x2a83134ned38aed061d551b1@mail.gmail.com> <20070620171502.GL12168@mercury.ccil.org> <003901c7b3c4$7e681220$6401a8c0@DGBP7M81> X-Google-Sender-Auth: b394fdd1b7fa0065 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0748034246==" Errors-To: ltru-bounces@ietf.org --===============0748034246== Content-Type: multipart/alternative; boundary="----=_Part_21019_16019361.1182439174053" ------=_Part_21019_16019361.1182439174053 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I too will be very busy until the end of the month, and won't have a chance to do much on this until then. MD On 6/20/07, Doug Ewell wrote: > > As one of the people who got this thread started, I'm not ignoring it or > anyone's position on it. Things just suddenly got very busy for me. I > promise (or threaten, depending) to jump in as soon as I have more than > two > consecutive minutes to think about it. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_21019_16019361.1182439174053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I too will be very busy until the end of the month, and won't have a chance to do much on this until then. MD

On 6/20/07, Doug Ewell < dewell@roadrunner.com> wrote:
As one of the people who got this thread started, I'm not ignoring it or
anyone's position on it.  Things just suddenly got very busy for me.  I
promise (or threaten, depending) to jump in as soon as I have more than two
consecutive minutes to think about it.

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



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



--
Mark ------=_Part_21019_16019361.1182439174053-- --===============0748034246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0748034246==-- From ltru-bounces@ietf.org Thu Jun 21 11:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OnX-0006wP-7x; Thu, 21 Jun 2007 11:42:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1OnW-0006so-1U for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OnV-0006rr-N2 for ltru@ietf.org; Thu, 21 Jun 2007 11:42:13 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1OnU-0000SX-Al for ltru@ietf.org; Thu, 21 Jun 2007 11:42:13 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 70BC5240828; Thu, 21 Jun 2007 17:42:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id EB1B71110C; Thu, 21 Jun 2007 17:41:04 +0200 (CEST) Date: Thu, 21 Jun 2007 17:41:04 +0200 From: Stephane Bortzmeyer To: Addison Phillips Subject: Flagging macrolanguages in the LSR (Was: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070621154104.GA25638@sources.org> References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46784742.9080009@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.7 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jun 19, 2007 at 02:14:42PM -0700, Addison Phillips wrote a message of 58 lines which said: > I take it you're suggesting (or interpreted the proposal) to mean > that the macrolanguage would contain a pointer or pointers to its > sublanguages. No, I was not suggesting it myself but it is a good opportunity to discuss it. > %% > Type: language > Subtag: zh > Description: Chinese > ... > Encloses: yue,cmn,..... > %% It seems reasonable to enumerate a macrolanguage "members "in the macrolanguage itself. But I see some issues with this proposal: 1) What will be the stability rules for Encloses? Can an extlang be dropped from a Encloses field? (if advances in linguistics show that it was wrongly added here, for instance.) And can an extlang be added to an Encloses? If yes (which seems reasonable), it means that the macrolanguage entry can change quite often (consider Zapotec with its dozens of enclosed extlangs). 2) It introduces a redundancy in the registry, an information which was already there and could be computed from other records. Randy Presuhn noticed it can be seen as a good thing ("it should be flagged in its record, rather than requiring it to be computed by examining all other records"). But more redundancy means more possibilities to introduce contradictions. 3) 4646bis does not indicate an upper bound for the length of a field ("The content of this field is not restricted, except by [...] reasonable practical size limitations."). Zapotec's "Encloses:" will be at least 232 bytes long and sign langauges will be worse. While there is a long discussion of length issues for tags, it seems there is none for registry-parsing applications. I suspect that some of them may have hard-wired limits for field lengths. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 11:51:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Owg-0001KN-Bl; Thu, 21 Jun 2007 11:51:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Owf-0001KI-R6 for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Owf-0001KA-He for ltru@ietf.org; Thu, 21 Jun 2007 11:51:41 -0400 Received: from bay0-omc3-s13.bay0.hotmail.com ([65.54.246.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Owe-0002LX-8H for ltru@ietf.org; Thu, 21 Jun 2007 11:51:41 -0400 Received: from hotmail.com ([65.54.169.42]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Jun 2007 08:51:38 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Jun 2007 08:51:39 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Thu, 21 Jun 2007 15:51:36 GMT X-Originating-IP: [74.255.101.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com From: "CE Whitehead" To: ltru@ietf.org Bcc: Date: Thu, 21 Jun 2007 11:51:36 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jun 2007 15:51:39.0572 (UTC) FILETIME=[0E527F40:01C7B41C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] (iso639.2708) RE: ISO 639-2 decision: "mis" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I am wondering if something on mis and the time frames in which 639-1, 639-2, and 639-3 apply can be added to the specifications describing the matching of language tags??? The trick would be for applications to note the date on which content was tagged, and then apply 639-1, 639-2, or 639-3 according to the date; content creators would of course need to include in their documents the last date each was updated. Maybe this could be incorporated into the standards for matching language tags??? (If anyone else thinks so??? ) --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 11:58:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P3B-0003AP-4E; Thu, 21 Jun 2007 11:58:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1P3A-0003AF-0a for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P39-0003A7-NM for ltru@ietf.org; Thu, 21 Jun 2007 11:58:23 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1P38-0003K7-Cs for ltru@ietf.org; Thu, 21 Jun 2007 11:58:23 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070621155817.YGIZ27139.mta13.adelphia.net@DGBP7M81>; Thu, 21 Jun 2007 11:58:17 -0400 Message-ID: <006501c7b41c$fbaea840$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> <4677F51D.7000600@yahoo-inc.com> <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> <20070621085217.GA14125@nic.fr> Date: Thu, 21 Jun 2007 08:58:16 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Modification of the Added field (Was: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > But, yesterday, the subtag baku1926 was modified (change in the Comments) > and the Added field *was* modified, from 2007-04-18 to 2007-04-20, which > puzzles me (why changing it and why for a date two months in the past?) > > IANA's blunder or ambiguity in the procedures/RFCs? Apparently an error in the second record that was sent to IANA, the one with Resat's replacement transcription. IANA perfectly reproduced the record they were sent. We'll ask them to fix the mistake. You can't get much less ambiguous than this: > 3.4. Stability of IANA Registry Entries > > 1. Values in the fields 'Type', 'Subtag', 'Tag', 'Added', > 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are > guaranteed to be stable over time. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 11:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P3m-0003Go-Hl; Thu, 21 Jun 2007 11:59:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1P3l-0003Gj-Fk for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P3l-0003Gb-6B for ltru@ietf.org; Thu, 21 Jun 2007 11:59:01 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1P3j-0003Or-Qy for ltru@ietf.org; Thu, 21 Jun 2007 11:59:01 -0400 Received: from [10.72.72.36] (snvvpn1-10-72-72-c36.corp.yahoo.com [10.72.72.36]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5LFwtTq082084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 08:58:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=tecT9Z/W7y8m/7PGoab3qpiFuHDAdZCfRSuaO+mUui1xFrxpdzVHxh+amhVpbdZ5 Message-ID: <467AA03E.5070506@yahoo-inc.com> Date: Thu, 21 Jun 2007 08:58:54 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: Flagging macrolanguages in the LSR (Was: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) References: <30b660a20706171252l3c61d451p464b96e864d1a515@mail.gmail.com> <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> <20070621154104.GA25638@sources.org> In-Reply-To: <20070621154104.GA25638@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.4 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > > It seems reasonable to enumerate a macrolanguage "members "in the > macrolanguage itself. But I see some issues with this proposal: > > 1) What will be the stability rules for Encloses? It's informative and thus could be changed. However, extlangs are permanent and stable (including their Prefix relationship), so they cannot be removed. Note that Encloses describes the function of the subtag, not necessarily the linguistic relationship (although in practice we hope that both are true). > Can an extlang be > dropped from a Encloses field? (if advances in linguistics show that > it was wrongly added here, for instance.) I would assume that an extlang can't be dropped from Encloses, since stability rules prevent the Prefix or status of an extlang from changing. And can an extlang be added > to an Encloses? If yes (which seems reasonable), it means that the > macrolanguage entry can change quite often (consider Zapotec with its > dozens of enclosed extlangs). You mean a new extlang? Of course new extlangs could be added as ISO 639-3 assigns new codes. But there is no such thing as an existing extlang acquiring a new Prefix (and thus a new Encloses relationship). It is banned by stability rules. > > 2) It introduces a redundancy in the registry, an information which > was already there and could be computed from other records. Randy > Presuhn noticed it can be seen as a good thing ("it should be flagged > in its record, rather than requiring it to be computed by examining > all other records"). But more redundancy means more possibilities to > introduce contradictions. The extlang records have a computable relationship. The main problem will be grandfathered primary language subtags that are enclosed by other subtags linguistically but not in terms of tagging practice. That is, not all possible macrolanguage relationships are described by or can be computed from entries in the registry. > > 3) 4646bis does not indicate an upper bound for the length of a field There isn't one. > ("The content of this field is not restricted, except by [...] > reasonable practical size limitations."). Zapotec's "Encloses:" will > be at least 232 bytes long and sign langauges will be worse. While > there is a long discussion of length issues for tags, it seems there > is none for registry-parsing applications. I suspect that some of them > may have hard-wired limits for field lengths. Note that some comments approach or even exceed the sizes you note above. I would tend to propose that we make Encloses a single field with structure simply because I find the multiple repetition of the same field unaesthetic. Of course, we went the other direction with Prefix, so there is some precedent for repeating the field. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 13:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qlm-0002Lj-5A; Thu, 21 Jun 2007 13:48:34 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Qll-0002Le-AS for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 13:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qll-0002LW-0w for ltru@ietf.org; Thu, 21 Jun 2007 13:48:33 -0400 Received: from ms-smtp-03.rdc-kc.rr.com ([24.94.166.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Qlj-0000Nk-5U for ltru@ietf.org; Thu, 21 Jun 2007 13:48:33 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-03.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5LHkK3w019812 for ; Thu, 21 Jun 2007 12:46:20 -0500 (CDT) Message-ID: <467ABA07.5010306@gmail.com> Date: Thu, 21 Jun 2007 12:48:55 -0500 From: =?ISO-8859-9?Q?=22Reshat_Sabiq_=28Re=FEat=29=22?= User-Agent: Mozilla Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ltru@ietf.org X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] UTF-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: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to get a feel for what the concerns are about using UTF-8 for subtag registry. Based on my testing locally, that works fine on IE, and firefox (the latter both on Windows and Linux). If anybody happens to use a shell or shell client that can't handle UTF-8, all they have to do when they see a mangled character is use one of many different clients that can handle UTF-8. There's hardly any problem, as far as i can see. P.S. I'm not a member of the list, but i'll try to track it down thru http interface. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:11371 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGeroHO75ytyYoOa8RAutbAJ9eAQWS48ybwBRwAOkBPpBJIdT7ngCgpJYv EGbdVWxdqs6c1hKnTL+iHP0= =BSNx -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 14:00:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qwu-0008Rw-A5; Thu, 21 Jun 2007 14:00:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Qwt-0008Rp-B0 for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qwt-0008Rh-1J for ltru@ietf.org; Thu, 21 Jun 2007 14:00:03 -0400 Received: from ms-smtp-04.rdc-kc.rr.com ([24.94.166.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Qwr-0002QQ-NG for ltru@ietf.org; Thu, 21 Jun 2007 14:00:03 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-04.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5LHxwTG023463 for ; Thu, 21 Jun 2007 12:59:59 -0500 (CDT) Message-ID: <467ABCB8.9050103@gmail.com> Date: Thu, 21 Jun 2007 13:00:24 -0500 From: =?ISO-8859-9?Q?=22Reshat_Sabiq_=28Re=FEat=29=22?= User-Agent: Mozilla Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ltru@ietf.org X-Enigmail-Version: 0.94.1.0 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ltru] XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess there is already software that can read the subtag registry as it is today, but i think if it was XML based, the whole process would work as it were on steroids, especially in the long run. Then one could use streaming XML APIs, and XSLT to read the registry. I'm not doing a schema for this sample just yet, but a sample of what they could look like follows below. One could have a parent element of Prefixes for an array of Prefix elements, but i think it could also be represented w/o it, as shown below. variant baku1926 Unified Turkic Latin Alphabet (Historical) 2007-04-18 az ba crh kk krc ky sah tk tt uz Denotes alphabet used in Turkic republics/regions of the former USSR in late 1920s, and throughout 1930s, which aspired to represent equivalent phonemes in a unified fashion. Also known as: New Turkic Alphabet; Birlәşdirilmiş Jeni Tyrk Әlifbasь; Jaŋalif. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:11371 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGery3O75ytyYoOa8RAlPLAKC1Sl4NC8EXhHkru5ZYIHiPN0joCgCcDU06 lyZkeyrriGnpi4vsypRcUtY= =7iu1 -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 14:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qyq-0000Ak-BF; Thu, 21 Jun 2007 14:02:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Qyp-0000Aa-8X for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:02:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qyo-0000AS-Ul for ltru@ietf.org; Thu, 21 Jun 2007 14:02:02 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Qyn-000322-Lh for ltru@ietf.org; Thu, 21 Jun 2007 14:02:02 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I1Qyl-00068t-07; Thu, 21 Jun 2007 14:01:59 -0400 Date: Thu, 21 Jun 2007 14:01:58 -0400 To: "\"Reshat Sabiq (Re?at)\"" Subject: Re: [Ltru] UTF-8 Message-ID: <20070621180158.GC9078@mercury.ccil.org> References: <467ABA07.5010306@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467ABA07.5010306@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "Reshat Sabiq (Re?at)" scripsit: > I'd like to get a feel for what the concerns are about using UTF-8 for > subtag registry. Based on my testing locally, that works fine on IE, and > firefox (the latter both on Windows and Linux). If anybody happens to > use a shell or shell client that can't handle UTF-8, all they have to do > when they see a mangled character is use one of many different clients > that can handle UTF-8. There's hardly any problem, as far as i can see. The issue is that email is an essential part of the process, and guaranteeing that email gets through the whole of the infrastructure unmangled is still difficult. -- Possession is said to be nine points of the law, John Cowan but that's not saying how many points the law might have. cowan@ccil.org --Thomas A. Cowan (law professor and my father) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 14:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ROC-0004gj-Lt; Thu, 21 Jun 2007 14:28:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1ROC-0004ge-2g for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ROB-0004gV-PM for ltru@ietf.org; Thu, 21 Jun 2007 14:28:15 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ROA-0001tf-CT for ltru@ietf.org; Thu, 21 Jun 2007 14:28:15 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RUmRQB/5WMrwGjrmFCzEdxm7C+xR2Qh7CX6Tk5hdmbCpio4jOuEdxZpOAWkiowB9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.77.12] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I1RO9-0002N2-9l for ltru@ietf.org; Thu, 21 Jun 2007 14:28:13 -0400 Message-ID: <005c01c7b431$f6b988e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> Subject: Re: [Ltru] UTF-8 Date: Thu, 21 Jun 2007 11:28:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356419ad29fd64fbec12709e0c8cadc2bf0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.77.12 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: ""Reshat Sabiq (Re?at)"" > Cc: > Sent: Thursday, June 21, 2007 11:01 AM > Subject: Re: [Ltru] UTF-8 ... > The issue is that email is an essential part of the process, and > guaranteeing that email gets through the whole of the infrastructure > unmangled is still difficult. ... A UTF-8 registry doesn't require that the format used to communicate additions and changes also be UTF-8. I think the real question is that of how much one is willing to rely on the good folks at IANA to handle the translation of whatever the updates look like into UTF-8. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 14:31:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RRa-0006Jd-MX; Thu, 21 Jun 2007 14:31:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1RRZ-0006JY-20 for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:31:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RRY-0006JQ-O8 for ltru@ietf.org; Thu, 21 Jun 2007 14:31:44 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1RRW-0004oW-Et for ltru@ietf.org; Thu, 21 Jun 2007 14:31:44 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I1RRW-0008Oq-54; Thu, 21 Jun 2007 14:31:42 -0400 Date: Thu, 21 Jun 2007 14:31:42 -0400 To: Randy Presuhn Subject: Re: [Ltru] UTF-8 Message-ID: <20070621183142.GD9078@mercury.ccil.org> References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <005c01c7b431$f6b988e0$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005c01c7b431$f6b988e0$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > A UTF-8 registry doesn't require that the format used to communicate > additions and changes also be UTF-8. I think the real question is that > of how much one is willing to rely on the good folks at IANA to handle > the translation of whatever the updates look like into UTF-8. Quite. My notion is that the less IANA has to do (considering what all else it has to do), the better. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 14:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rmf-0005XS-A3; Thu, 21 Jun 2007 14:53:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Rme-0005XN-Mz for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rme-0005XF-DS for ltru@ietf.org; Thu, 21 Jun 2007 14:53:32 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Rmd-0000Y2-TB for ltru@ietf.org; Thu, 21 Jun 2007 14:53:32 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1676528ugf for ; Thu, 21 Jun 2007 11:53:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YxOCBNTGqp0NbIZmAJ/N7HwCXmNdGsUdtJ9eUr8wgT2exlZGcwF2doz0XFG7pnCRNTuiWqdPFWwGLXWTXGL1UdFR47mmgMZ6jJweBCFhlsDic4OypVAKJ2kZLP2WCwwhdLp/pP/S8QT0TdMGro/O6SbjOa9UYnMJsSKj8IzfkO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mXJ1wTxr+GKjpbTaH2sAd3VrvddR8xETG08WZkBA0WmmjGohes++3Vrv1xegT3laMrP9MsGg09TYkRmdEQt+7KGuAQwpuNmiCI349XOotHP+OGmNGRytQM3ByJk6PATjqZNz2eMPnn2jWSKoLMzDGSZhnVBToQcfauSf8DxUktM= Received: by 10.82.136.4 with SMTP id j4mr4498263bud.1182452010836; Thu, 21 Jun 2007 11:53:30 -0700 (PDT) Received: by 10.82.185.13 with HTTP; Thu, 21 Jun 2007 11:53:30 -0700 (PDT) Message-ID: <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> Date: Thu, 21 Jun 2007 20:53:30 +0200 From: GerardM To: "John Cowan" Subject: Re: [Ltru] UTF-8 In-Reply-To: <20070621180158.GC9078@mercury.ccil.org> MIME-Version: 1.0 References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org, "Reshat Sabiq \(Re?at\)" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445215360==" Errors-To: ltru-bounces@ietf.org --===============1445215360== Content-Type: multipart/alternative; boundary="----=_Part_135525_14563444.1182452010817" ------=_Part_135525_14563444.1182452010817 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, It happens often that exactly because of the content is NOT UTF-8 that I get the information mangled. With UTF-8 you either get the message or it will be indicated that you have insufficient fonts installed. The notion that the current encoding always works is wrong. Thanks, Gerard On 6/21/07, John Cowan wrote: > > "Reshat Sabiq (Re?at)" scripsit: > > > I'd like to get a feel for what the concerns are about using UTF-8 for > > subtag registry. Based on my testing locally, that works fine on IE, and > > firefox (the latter both on Windows and Linux). If anybody happens to > > use a shell or shell client that can't handle UTF-8, all they have to do > > when they see a mangled character is use one of many different clients > > that can handle UTF-8. There's hardly any problem, as far as i can see. > > The issue is that email is an essential part of the process, and > guaranteeing that email gets through the whole of the infrastructure > unmangled is still difficult. > > -- > Possession is said to be nine points of the law, John Cowan > but that's not saying how many points the law might have. > cowan@ccil.org > --Thomas A. Cowan (law professor and my father) > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_135525_14563444.1182452010817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
It happens often that exactly because of the content is NOT UTF-8 that I get the information mangled. With UTF-8 you either get the message or it will be indicated that you have insufficient fonts installed. The notion that the current encoding always works is wrong.
Thanks,
    Gerard

On 6/21/07, John Cowan <cowan@ccil.org> wrote:
"Reshat Sabiq (Re?at)" scripsit:

> I'd like to get a feel for what the concerns are about using UTF-8 for
> subtag registry. Based on my testing locally, that works fine on IE, and
> firefox (the latter both on Windows and Linux). If anybody happens to
> use a shell or shell client that can't handle UTF-8, all they have to do
>  when they see a mangled character is use one of many different clients
> that can handle UTF-8. There's hardly any problem, as far as i can see.

The issue is that email is an essential part of the process, and
guaranteeing that email gets through the whole of the infrastructure
unmangled is still difficult.

--
Possession is said to be nine points of the law,                John Cowan
but that's not saying how many points the law might have.       cowan@ccil.org
        --Thomas A. Cowan (law professor and my father)


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

------=_Part_135525_14563444.1182452010817-- --===============1445215360== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1445215360==-- From ltru-bounces@ietf.org Thu Jun 21 14:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rr4-0007dX-LR; Thu, 21 Jun 2007 14:58:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Rr4-0007dS-5c for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:58:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rr3-0007dK-Rl for ltru@ietf.org; Thu, 21 Jun 2007 14:58:05 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Rr2-0005zT-GQ for ltru@ietf.org; Thu, 21 Jun 2007 14:58:05 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I1Rqc-0001ab-Dr; Thu, 21 Jun 2007 14:57:38 -0400 Date: Thu, 21 Jun 2007 14:57:38 -0400 To: GerardM Subject: Re: [Ltru] UTF-8 Message-ID: <20070621185738.GE9078@mercury.ccil.org> References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org, "Reshat Sabiq \(Re?at\)" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org GerardM scripsit: > It happens often that exactly because of the content is NOT UTF-8 that > I get the information mangled. With UTF-8 you either get the message > or it will be indicated that you have insufficient fonts installed. The > notion that the current encoding always works is wrong. It always works for ASCII text, and the Registry is restricted to ASCII text. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 15:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SSt-0006p7-Ug; Thu, 21 Jun 2007 15:37:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1SSt-0006p2-3b for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SSs-0006ou-QK for ltru@ietf.org; Thu, 21 Jun 2007 15:37:10 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SSq-0005FZ-EO for ltru@ietf.org; Thu, 21 Jun 2007 15:37:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DVwkGW/si66kfHiNDO//hctk9oX1YZfWyp6YRP+dnoBMQJ89MieJ7KRxuhIA/M7C; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.77.12] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I1SSp-0006Vi-Kl for ltru@ietf.org; Thu, 21 Jun 2007 15:37:07 -0400 Message-ID: <001201c7b43b$970e10a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <467ABA07.5010306@gmail.com><20070621180158.GC9078@mercury.ccil.org><41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> Subject: Re: [Ltru] UTF-8 Date: Thu, 21 Jun 2007 12:37:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356a365f19332f77dc4a7964ecb30f014c5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.77.12 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair... We've had this discussion several times. As long as there is an insistance that the format for the communication of updates is the same as that of the registry itself, I'm pretty sure the conclusion won't change in the forseeable future. Just on this list, we've all seen the picturesque results of various incompatible mailers (and even different configurations of the same mailer) mangling what should be simple UTF-8. Unfortunately, it doesn't appear to just be a question of having the right fonts. If this thread is to move forward to a different conclusion, the only path by which I can see it succeeding is to recognize that the email communication of changes might have to rely on a different coding of non-ASCII things from what the registry itself uses. If we can agree that the existing email format is adequate for purposes of communicating changes, then there are three decisions needed: (0) do we want to stick with email as our mechanism for communicating updates? (1) is a UTF-8 registry indeed desirable? (2) if so, are we willing to allow IANA to convert the apropriate bits of an update directive conveyed in ASCII into the "real" code points? But please, let's not rehash the discussion we've already had. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 15:48:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SeF-00022R-JN; Thu, 21 Jun 2007 15:48:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1SeE-0001zG-2E for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SeD-0001z8-Or for ltru@ietf.org; Thu, 21 Jun 2007 15:48:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SeB-0001JO-2j for ltru@ietf.org; Thu, 21 Jun 2007 15:48:53 -0400 Received: from [172.21.148.31] (wlanvpn-mc2e-246-31.corp.yahoo.com [172.21.148.31]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5LJmX1p084776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:48:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=KLIT555nOwk/pbyhTiYduDKSzkZH9N4gfXmZoKpIl2ah5f1GOZK5UNHSCRTUfcfj Message-ID: <467AD611.90002@yahoo-inc.com> Date: Thu, 21 Jun 2007 12:48:33 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] UTF-8 References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <005c01c7b431$f6b988e0$6601a8c0@oemcomputer> <20070621183142.GD9078@mercury.ccil.org> In-Reply-To: <20070621183142.GD9078@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.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: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> A UTF-8 registry doesn't require that the format used to communicate >> additions and changes also be UTF-8. I think the real question is that >> of how much one is willing to rely on the good folks at IANA to handle >> the translation of whatever the updates look like into UTF-8. > > Quite. My notion is that the less IANA has to do (considering what > all else it has to do), the better. > The question is: can the LSR and/or his/her proxy (i.e. Doug) manage to send email to IANA encoded as UTF-8. All other emails are "nice to have", but not required. I think the answer here is that they can manage it. The "compelling reason" against UTF-8 that I've seen has nothing to do with email or browser availability or IANA's skill set. It is simply that it is a change in the registry format and could break existing implementations that rely on the ASCII format. As the original (and long time) proponent of a UTF-8 registry, I find that argument to be the one sticking point for which I cannot find a good counter argument. If we change it, we will have to make a conscious decision to break with the past on that point. I note also that UTF-8 has failed to reach consensus on at least three separate occasions. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 16:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SrH-0008KG-7o; Thu, 21 Jun 2007 16:02:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1SrF-0008J8-RT for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Shd-0000kW-B0 for ltru@ietf.org; Thu, 21 Jun 2007 15:52:25 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ShS-0002bu-Ry for ltru@ietf.org; Thu, 21 Jun 2007 15:52:25 -0400 Received: from [172.21.148.31] (wlanvpn-mc2e-246-31.corp.yahoo.com [172.21.148.31]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5LJqAWI085090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:52:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kofcGxwXRon2c2fbNH23Qo/gWGnHz5fs642DoZVn+L6ODQClcweOulgNgGKTRiVV Message-ID: <467AD6E9.6020809@yahoo-inc.com> Date: Thu, 21 Jun 2007 12:52:09 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] UTF-8 References: <467ABA07.5010306@gmail.com><20070621180158.GC9078@mercury.ccil.org><41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> <001201c7b43b$970e10a0$6601a8c0@oemcomputer> In-Reply-To: <001201c7b43b$970e10a0$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think we should close this discussion. We're unlikely to make it further this time than last. I think UTF-8 is desirable and the procedural points can be solved to deal with it. But I don't think we'll find consensus down this path (or at least consensus that doesn't have multiple loud objections). Ditto on the XML proposal. Addison Randy Presuhn wrote: > Hi - > > As co-chair... > > We've had this discussion several times. As long as there is > an insistance that the format for the communication of updates > is the same as that of the registry itself, I'm pretty sure the conclusion > won't change in the forseeable future. Just on this list, we've all > seen the picturesque results of various incompatible mailers > (and even different configurations of the same mailer) mangling > what should be simple UTF-8. Unfortunately, it doesn't appear to > just be a question of having the right fonts. > > If this thread is to move forward to a different conclusion, the only > path by which I can see it succeeding is to recognize that the > email communication of changes might have to rely on a different > coding of non-ASCII things from what the registry itself uses. > If we can agree that the existing email format is adequate for purposes > of communicating changes, then there are three decisions needed: > (0) do we want to stick with email as our mechanism for communicating > updates? > (1) is a UTF-8 registry indeed desirable? > (2) if so, are we willing to allow IANA to convert the apropriate bits > of an update directive conveyed in ASCII into the "real" code points? > > But please, let's not rehash the discussion we've already had. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 16:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TK9-0007UY-C5; Thu, 21 Jun 2007 16:32:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1TK8-0007UP-3e for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TK7-0007UA-Po for ltru@ietf.org; Thu, 21 Jun 2007 16:32:11 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TK5-0005II-Fz for ltru@ietf.org; Thu, 21 Jun 2007 16:32:11 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 6A5A1240828; Thu, 21 Jun 2007 22:32:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 58777119E2; Thu, 21 Jun 2007 22:30:19 +0200 (CEST) Date: Thu, 21 Jun 2007 22:30:19 +0200 From: Stephane Bortzmeyer To: "Reshat Sabiq (Re?at)" Message-ID: <20070621203019.GA14054@sources.org> References: <467ABCB8.9050103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467ABCB8.9050103@gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org Subject: [Ltru] Re: XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Jun 21, 2007 at 01:00:24PM -0500, Reshat Sabiq (Re?at) wrote a message of 54 lines which said: > I guess there is already software that can read the subtag registry > as it is today, but i think if it was XML based, the whole process > would work as it were on steroids, especially in the long run. Then > one could use streaming XML APIs, and XSLT to read the registry. No need to dream, it is already there (and in many other formats, too). http://www.langtag.net/registries.html > I'm not doing a schema for this sample just yet, Your schema seems quite clsoe to mine (http://www.langtag.net/registries/ltru.rnc) and I suggest that people interested in moving this schema from the current draft to a "real" schema, production-ready, gather in private since XML work is not well received on the LTRU list. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 16:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TP1-0002UE-39; Thu, 21 Jun 2007 16:37:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1TOz-0002U6-6X for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TOy-0002Ty-TD for ltru@ietf.org; Thu, 21 Jun 2007 16:37:12 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TOx-0007xl-Ig for ltru@ietf.org; Thu, 21 Jun 2007 16:37:12 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E5B67240828; Thu, 21 Jun 2007 22:37:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 4AC1F11A60; Thu, 21 Jun 2007 22:33:59 +0200 (CEST) Date: Thu, 21 Jun 2007 22:33:59 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070621203359.GA28454@sources.org> References: <008101c7b283$f4864a90$6401a8c0@DGBP7M81> <4677F51D.7000600@yahoo-inc.com> <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c7b3c6$2229a6c0$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group Subject: [Ltru] Modified: field in the registry? (Was: Small bibliography error in RFC 4930 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Jun 20, 2007 at 10:36:35PM -0700, Doug Ewell wrote a message of 27 lines which said: > In RFC 4645bis, existing records may be changed slightly to add > language names listed in ISO 639-3, and to put the 639-3 "reference > name" first, but in no case will the Added date of an existing > record be changed. Isn't it a problem that there is no way to know the modification date? Should we work on a Modified: field in the registry? I ask so because the LSR syndication feed http://www.langtag.net/registries/lsr.atom would certainly benefit from it. Its format, Atom (RFC 4287), makes a difference between and (other syndication formats do it as well). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 16:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TTo-0003qj-NC; Thu, 21 Jun 2007 16:42:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1TTn-0003qY-Mp for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TTn-0003qQ-DG for ltru@ietf.org; Thu, 21 Jun 2007 16:42:11 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TTl-0001CS-TS for ltru@ietf.org; Thu, 21 Jun 2007 16:42:11 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id CF1FA240828; Thu, 21 Jun 2007 22:42:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 8BC1E11A75; Thu, 21 Jun 2007 22:40:12 +0200 (CEST) Date: Thu, 21 Jun 2007 22:40:12 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20070621204012.GA16675@sources.org> References: <20070621185738.GE9078@mercury.ccil.org> <001201c7b43b$970e10a0$6601a8c0@oemcomputer> <467AD6E9.6020809@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467AD6E9.6020809@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group Subject: [Ltru] Re: UTF-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: , Errors-To: ltru-bounces@ietf.org On Thu, Jun 21, 2007 at 12:52:09PM -0700, Addison Phillips wrote a message of 58 lines which said: > But I don't think we'll find consensus down this path (or at least > consensus that doesn't have multiple loud objections). Ditto on the > XML proposal. For UTF-8 and XML, a possible path is to have unofficial, automatically produced, copies of the registry in other formats (see http://www.langtag.net/registries.html). It would solve most of the use cases. XML is already there, UTF-8 is certainly possible (any volunteer to write the program?) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 17:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Twv-0007hf-Pa; Thu, 21 Jun 2007 17:12:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Twu-0007bW-CV for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 17:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Twu-0007bN-2t for ltru@ietf.org; Thu, 21 Jun 2007 17:12:16 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Tws-0007VE-9p for ltru@ietf.org; Thu, 21 Jun 2007 17:12:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id D97AF240834; Thu, 21 Jun 2007 23:12:10 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id D781911B50; Thu, 21 Jun 2007 23:10:31 +0200 (CEST) Date: Thu, 21 Jun 2007 23:10:31 +0200 From: Stephane Bortzmeyer To: Addison Phillips Subject: Re: Flagging macrolanguages in the LSR (Was: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) Message-ID: <20070621211031.GA22085@sources.org> References: <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> <20070621154104.GA25638@sources.org> <467AA03E.5070506@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467AA03E.5070506@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.7 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Jun 21, 2007 at 08:58:54AM -0700, Addison Phillips wrote a message of 73 lines which said: > You mean a new extlang? Yes. With Encloses: or a similar field, adding a new record (the new extlang) will change *another* record (its macrolanguage), which is questionable. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 17:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1U3F-0007W4-Sd; Thu, 21 Jun 2007 17:18:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1U3E-0007Vv-G1 for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 17:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1U3E-0007Vn-6G for ltru@ietf.org; Thu, 21 Jun 2007 17:18:48 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound1-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1U3B-00006G-Ri for ltru@ietf.org; Thu, 21 Jun 2007 17:18:48 -0400 Received: from outbound1-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-sin-R.bigfish.com (Postfix) with ESMTP id DC1EB867147 for ; Thu, 21 Jun 2007 21:18:43 +0000 (UTC) Received: from mail169-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound1-sin.bigfish.com (Postfix) with ESMTP id C7B511C90081 for ; Thu, 21 Jun 2007 21:18:43 +0000 (UTC) Received: from mail169-sin (localhost.localdomain [127.0.0.1]) by mail169-sin-R.bigfish.com (Postfix) with ESMTP id 8ACBB84818F for ; Thu, 21 Jun 2007 21:18:43 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail169-sin (MessageSwitch) id 1182460723510217_17446; Thu, 21 Jun 2007 21:18:43 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail169-sin.bigfish.com (Postfix) with ESMTP id CA849115805B for ; Thu, 21 Jun 2007 21:18:34 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007062114182969-310459 ; Thu, 21 Jun 2007 14:18:29 -0700 In-Reply-To: <20070621211031.GA22085@sources.org> To: ltru@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Thu, 21 Jun 2007 14:16:26 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 06/21/2007 14:16:27, Serialize complete at 06/21/2007 14:16:27, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/21/2007 02:18:29 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/21/2007 02:18:34 PM, Serialize complete at 06/21/2007 02:18:34 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] Langtag.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="===============1003113868==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1003113868== Content-Type: multipart/alternative; boundary="=_alternative 00750C6D88257301_=" This is a multipart message in MIME format. --=_alternative 00750C6D88257301_= Content-Type: text/plain; charset="US-ASCII" On the langtag.net site, it says, "List of grand-fathered *(tags which are no longer legal but maintained for compatibility*." Are zh-cmn and the other tags on the list now illegal? Or are they expected to become redundant as was previously discussed? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 00750C6D88257301_= Content-Type: text/html; charset="US-ASCII"
On the langtag.net site, it says, "List of grand-fathered *(tags which are no longer legal but maintained for compatibility*."

Are zh-cmn and the other tags on the list now illegal? Or are they expected to become redundant as was previously discussed?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384 --=_alternative 00750C6D88257301_=-- --===============1003113868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1003113868==-- From ltru-bounces@ietf.org Thu Jun 21 17:33:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UHd-0000vg-DZ; Thu, 21 Jun 2007 17:33:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1UHc-0000vb-Nz for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 17:33:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UHc-0000vT-Dm for ltru@ietf.org; Thu, 21 Jun 2007 17:33:40 -0400 Received: from netc-relay-2m.netcourrier.com ([194.158.104.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1UHa-0003Tz-GF for ltru@ietf.org; Thu, 21 Jun 2007 17:33:40 -0400 Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id 50D7226848 for ; Thu, 21 Jun 2007 23:33:37 +0200 (CEST) Received: from [89.2.186.89] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: =?iso-8859-1?Q?Re:_Suggested_language_for_"mis"_(Re:_[Ltru]_RE:_ISO_639-2?= =?iso-8859-1?Q?_decision:=09"mis")?= Date: Thu, 21 Jun 2007 23:33:37 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote = >That's going in the right direction, but doesn't not given enough guidanc= e >as to why to avoid it. My suggested language: > >The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According= to >ISO 639, it is used to identify linguistic content whose language is know= n >but which does not *currently* have a corresponding subtag. It is thus >intrinsically unstable -- the addition of other codes in the future can >render its application invalid at any point without any warning -- and he= nce >incompatible with the stability goals of BCP 47. It is thus always >preferable to use other subtags: either =22und=22 or -- with prior agreem= ent -- >private use subtags. What do you plan for = afa Afro-Asiatic (Other) cpe Creoles and pidgins, English-based (Other) roa Romance (Other) wich are unstable too (but less than mis) ? = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 18:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Uv2-0004oY-P4; Thu, 21 Jun 2007 18:14:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1Uv1-0004oS-3S for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 18:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Uv0-0004oK-QI for ltru@ietf.org; Thu, 21 Jun 2007 18:14:22 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Uuz-0001oZ-FZ for ltru@ietf.org; Thu, 21 Jun 2007 18:14:22 -0400 Received: from [10.72.230.211] (UNKNOWN-10-72-230-211.yahoo.com [10.72.230.211] (may be forged)) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5LMEEmN000158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:14:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=xgts8Xc11SCzLvn9Oiz4hB6//ic1y8Mun27Um4RkJsO1u3AId4kkl0MPIUZaiIE3 Message-ID: <467AF836.6070501@yahoo-inc.com> Date: Thu, 21 Jun 2007 15:14:14 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: Flagging macrolanguages in the LSR (Was: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")) References: <007f01c7b166$8ef7bf10$6401a8c0@DGBP7M81> <30b660a20706181006x3efbf772t9a0751feb070a6cb@mail.gmail.com> <20070619013433.GA15048@mercury.ccil.org> <003701c7b238$16124fc0$6401a8c0@DGBP7M81> <20070619140547.GB30227@mercury.ccil.org> <4677F589.3090003@yahoo-inc.com> <20070619205855.GA19853@sources.org> <46784742.9080009@yahoo-inc.com> <20070621154104.GA25638@sources.org> <467AA03E.5070506@yahoo-inc.com> <20070621211031.GA22085@sources.org> In-Reply-To: <20070621211031.GA22085@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.4 (--------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > >> You mean a new extlang? > > Yes. > > With Encloses: or a similar field, adding a new record (the new > extlang) will change *another* record (its macrolanguage), which is > questionable. > I don't think it's questionable. Inserting a new record that obsoletes an existing item can cause deprecation, change from grandfathered->redundant, or other changes. It *does* mean that inserting an extlang requires two records to be submitted to IANA, instead of just one. Ultimately, though, the question is whether having the information adds value in the registry in proportion to the disruption that adding more fields, maintenance rules, and so forth adds. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 21 18:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V0u-0005CO-E9; Thu, 21 Jun 2007 18:20:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1V0t-0005CE-Tw for ltru-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 18:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V0t-00059t-JA for ltru@ietf.org; Thu, 21 Jun 2007 18:20:27 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1UxN-000231-4R for ltru@ietf.org; Thu, 21 Jun 2007 18:16:50 -0400 Received: from [10.72.230.211] (UNKNOWN-10-72-230-211.yahoo.com [10.72.230.211] (may be forged)) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5LMGihO000452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:16:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=OokkSZaCcroaxl5XyXsHz+MKP2jLYvwhNKa8VQaz+Uuj2Yf2NYfX3Ub0T9XIMIbt Message-ID: <467AF8CC.8090707@yahoo-inc.com> Date: Thu, 21 Jun 2007 15:16:44 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Langtag.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org No. The text on langtag.net is wrong. Grandfathered tags are always legal. These particular ones may become redundant (assuming Mark's idea of not implementing extlangs doesn't go forwards). But they'll always be legal. I think what Stephane means is "tags which would otherwise be illegal but are maintained for compatibility". Addison Karen_Broome@spe.sony.com wrote: > > On the langtag.net site, it says, "List of _grand-fathered_ > *(tags which > are no longer legal but maintained for compatibility*." > > Are zh-cmn and the other tags on the list now illegal? Or are they > expected to become redundant as was previously discussed? > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 00:27:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ajf-0004TS-3R; Fri, 22 Jun 2007 00:27:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1ajd-0004TN-Gv for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 00:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ajd-0004TF-5d for ltru@ietf.org; Fri, 22 Jun 2007 00:27:01 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ajb-00071a-VS for ltru@ietf.org; Fri, 22 Jun 2007 00:27:01 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I1ajb-0004fc-97; Fri, 22 Jun 2007 00:26:59 -0400 Date: Fri, 22 Jun 2007 00:26:59 -0400 To: Nicolas Krebs Subject: Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision:?"mis") Message-ID: <20070622042659.GK9078@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs scripsit: > What do you plan for > afa Afro-Asiatic (Other) > cpe Creoles and pidgins, English-based (Other) > roa Romance (Other) > wich are unstable too (but less than mis) ? The ISO 639 committee intends (as far as I understand) to remove "(Other)" from these, widening them. It will of course remain best practice not to use them if more specific coding is available and known to the coder. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 02:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ctc-0005sx-H5; Fri, 22 Jun 2007 02:45:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1ctb-0005qk-Qu for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 02:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ctX-0005WV-Ks for ltru@ietf.org; Fri, 22 Jun 2007 02:45:23 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ctU-0002UG-Nd for ltru@ietf.org; Fri, 22 Jun 2007 02:45:23 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5M6jDnI028782 for ; Fri, 22 Jun 2007 15:45:13 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5665_20c342a4_208c_11dc_81df_0014221f2a2d; Fri, 22 Jun 2007 15:45:12 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50877) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Jun 2007 15:43:15 +0900 Message-Id: <6.0.0.20.2.20070622154148.08b36570@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Jun 2007 15:44:37 +0900 To: Stephane Bortzmeyer , "Reshat Sabiq (Re?at)" From: Martin Duerst Subject: Re: [Ltru] Re: XML In-Reply-To: <20070621203019.GA14054@sources.org> References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 05:30 07/06/22, Stephane Bortzmeyer wrote: >Your schema seems quite clsoe to mine >(http://www.langtag.net/registries/ltru.rnc) and I suggest that people >interested in moving this schema from the current draft to a "real" >schema, production-ready, gather in private since XML work is not well >received on the LTRU list. The statement in the last clause is only partially true. When I made an attempt at a consensus call on this issue (many months ago), my recollection was that a slight majority of the people responding favored moving to XML, but that that majority wasn't strong enough to make the change, in particular because the people who would have had to do the actual work (read: editors) weren't very excited. It is true that if we stay with the current state (no XML), then we shouldn't use the list to discuss XML, because we want to concentrate to get our documents out. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 02:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1d6E-0003nE-PH; Fri, 22 Jun 2007 02:58:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1d6C-0003ms-VI for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 02:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1d6C-0003mk-LS for ltru@ietf.org; Fri, 22 Jun 2007 02:58:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1d6B-0003vb-8T for ltru@ietf.org; Fri, 22 Jun 2007 02:58:28 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1963131ugf for ; Thu, 21 Jun 2007 23:58:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=nAshbxZ6/jD5E4GDaHAf/BnbJG7GUB6aLiZ6sva6hAh8FODawEOpqC+tNWTYvKA1WnxrC3ZQDXOPBayVaX0B5o01x9dGPCsH9Lr4MxzdGHtrRmhLKzeZ3fAuiZ9RAW9apnZlQuuPfD23ZBnNlWNvfrSARzxk4Nhwh2v7CZGjJaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=KrluZj6l1laUZcUopICdjmuq8x8LO4gGf03UbRRhYFUxnTZIK5clE4m6rq39umAhAmCzHAeesEfvHmNzcau8ETF6hLeYSX8MhBz/7RKJiClQDxv0NXajiKxohqw1BQmfrZskUzdEr9V/gt+UVVKbGk5nwTc9q5lgGYp0VKJeO0g= Received: by 10.82.183.19 with SMTP id g19mr5680587buf.1182495506394; Thu, 21 Jun 2007 23:58:26 -0700 (PDT) Received: by 10.82.185.13 with HTTP; Thu, 21 Jun 2007 23:58:26 -0700 (PDT) Message-ID: <41a006820706212358r4aa63497qbae1402c2b456489@mail.gmail.com> Date: Fri, 22 Jun 2007 08:58:26 +0200 From: GerardM To: ltru@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] scripts on langtag.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="===============1878720276==" Errors-To: ltru-bounces@ietf.org --===============1878720276== Content-Type: multipart/alternative; boundary="----=_Part_143379_26199305.1182495506369" ------=_Part_143379_26199305.1182495506369 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, When it is argued that the content should be in ASCII in order to be readable, then please make it so that the content of the website parses well. I get for instance "Ethiopic (Geʻez) / Ethiopic (Ge'ez)". This is nor humanly readable. To me this notion that UTF-8 cannot be used because it might break things is rather odd when I cannot properly read all the names of scripts on langtag.net. To me it seems that things are broken anyway. Thanks, Gerard ------=_Part_143379_26199305.1182495506369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
When it is argued that the content should be in ASCII in order to be readable, then please make it so that the content of the website parses well. I get for instance " Ethiopic (Ge&#x2BB;ez) / Ethiopic (Ge'ez)". This is nor humanly readable. 
To me this notion that UTF-8 cannot be used because it might break things is rather odd when I cannot properly read all the names of scripts on 
langtag.net. To me it seems that things are broken anyway. 

Thanks,
    Gerard
------=_Part_143379_26199305.1182495506369-- --===============1878720276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1878720276==-- From ltru-bounces@ietf.org Fri Jun 22 03:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dYU-0002N8-Ah; Fri, 22 Jun 2007 03:27:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1dYS-0002Mw-VS for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 03:27:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dYS-0002Ml-J0 for ltru@ietf.org; Fri, 22 Jun 2007 03:27:40 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1dYR-0000gH-8g for ltru@ietf.org; Fri, 22 Jun 2007 03:27:40 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 76AB81C0188; Fri, 22 Jun 2007 09:27:08 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 71AB81C0181; Fri, 22 Jun 2007 09:27:07 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 65BFF58EB54; Fri, 22 Jun 2007 09:27:07 +0200 (CEST) Date: Fri, 22 Jun 2007 09:27:07 +0200 From: Stephane Bortzmeyer To: Karen_Broome@spe.sony.com Message-ID: <20070622072707.GA18927@nic.fr> References: <20070621211031.GA22085@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ltru@ietf.org Subject: [Ltru] Re: Langtag.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: , Errors-To: ltru-bounces@ietf.org On Thu, Jun 21, 2007 at 02:16:26PM -0700, Karen_Broome@spe.sony.com wrote a message of 59 lines which said: > On the langtag.net site, it says, "List of grand-fathered *(tags > which are no longer legal but maintained for compatibility*." Fixed. Sorry. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 03:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dr9-0005rG-99; Fri, 22 Jun 2007 03:46:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1dr7-0005pS-Q0 for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 03:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dr6-0005ny-WB for ltru@ietf.org; Fri, 22 Jun 2007 03:46:57 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1dr5-0001We-Lz for ltru@ietf.org; Fri, 22 Jun 2007 03:46:56 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 29AF31C012E; Fri, 22 Jun 2007 09:46:55 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 248061C0128; Fri, 22 Jun 2007 09:46:54 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2153358EB54; Fri, 22 Jun 2007 09:46:54 +0200 (CEST) Date: Fri, 22 Jun 2007 09:46:54 +0200 From: Stephane Bortzmeyer To: GerardM Message-ID: <20070622074654.GB18927@nic.fr> References: <41a006820706212358r4aa63497qbae1402c2b456489@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41a006820706212358r4aa63497qbae1402c2b456489@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ltru@ietf.org Subject: [Ltru] Re: scripts on langtag.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: , Errors-To: ltru-bounces@ietf.org [I assume you refer to http://www.langtag.net/registries/lsr-script.txt] On Fri, Jun 22, 2007 at 08:58:26AM +0200, GerardM wrote a message of 48 lines which said: > When it is argued that the content should be in ASCII in order to be > readable, then please make it so that the content of the website > parses well. I get for instance "Ethiopic (Geʻez) / Ethiopic > (Ge'ez)". This is nor humanly readable. Do you prefer: Ethiopic (Ge'ez) only? If so, I can create an ASCII file where all descriptions with numeric entities omitted. There is no general way to translate from these entities to ASCII (that's why Unicode was invented, after all). And note that, in scripts only, four subtags have no pure-ASCII description (Hano, Nkoo, Lepc and Hang) so this would mean not only selecting some descriptions but also parsing words inside descriptions. [Side note: the registry seems a bit inconsistent. Why: Subtag: Ethi Description: Ethiopic (Geʻez) Description: Ethiopic (Ge'ez) and: Subtag: Hang Description: Hangul (Hangŭl, Hangeul) Why not: Subtag: Hang Description: Hangul (Hangŭl) Description: Hangul (Hangeul) ? End of side note] > To me this notion that UTF-8 cannot be used because it might break > things is rather odd when I cannot properly read all the names of > scripts on langtag.net. To me it seems that things are broken > anyway. I would be glad to provide plain-text UTF8 versions of the registry as soon as I have time to write the program. Since langtag.net is a cooperative effort, any cooperation is welcome (probably better off-list). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 05:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fB5-0006Pi-Jt; Fri, 22 Jun 2007 05:11:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1fB1-0006PK-It for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 05:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fB1-0006PC-4T for ltru@ietf.org; Fri, 22 Jun 2007 05:11:35 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fAx-000074-6i for ltru@ietf.org; Fri, 22 Jun 2007 05:11:35 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5M9BPBh011249 for ; Fri, 22 Jun 2007 18:11:25 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5722_8d745c44_20a0_11dc_82fe_0014221f2a2d; Fri, 22 Jun 2007 18:11:24 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49880) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Jun 2007 18:09:27 +0900 Message-Id: <6.0.0.20.2.20070622175307.058fc2e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Jun 2007 17:57:18 +0900 To: "CE Whitehead" , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] (iso639.2708) RE: ISO 639-2 decision: "mis" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As remarked recently in a different thread, applications are allowed to use additional knowledge when matching. The main problem with the idea proposed below seems that it relies on information external to the language tag, information often not available at all (in HTTP, there are quite some dates, but none of them may be the date on which the language tagging occurred). If enough people (which wouldn't include me) really care, this might be an area for an extension. With 8 digits per label, a 'date' extension would come out rather nicely (ignoring for the moment the y10k problem :-): mis-d-20070622 (assuming this extension gets the letter d). Regards, Martin. At 00:51 07/06/22, CE Whitehead wrote: >I am wondering if something on mis and the time frames in which 639-1, >639-2, and 639-3 apply can be added to the specifications describing the >matching of language tags??? > >The trick would be for applications to note the date on which content was >tagged, and then apply 639-1, 639-2, or 639-3 according to the date; >content creators would of course need to include in their documents the last >date each was updated. > >Maybe this could be incorporated into the standards for matching language >tags??? > >(If anyone else thinks so??? ) > > >--C. E. Whitehead >cewcathar@hotmail.com > >_________________________________________________________________ >Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 12:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lrn-0001rP-Rp; Fri, 22 Jun 2007 12:20:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1lrl-0001rK-T8 for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 12:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lrl-0001r9-JU for ltru@ietf.org; Fri, 22 Jun 2007 12:20:09 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1lrj-0005zt-9z for ltru@ietf.org; Fri, 22 Jun 2007 12:20:09 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 22 Jun 2007 09:18:39 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Fri, 22 Jun 2007 09:20:06 -0700 From: Peter Constable To: Addison Phillips , Randy Presuhn Date: Fri, 22 Jun 2007 09:20:04 -0700 Subject: RE: [Ltru] UTF-8 Thread-Topic: [Ltru] UTF-8 Thread-Index: Ace0PxsXPX71+8MJQbeZmmJtH9ewqQApqKQw Message-ID: References: <467ABA07.5010306@gmail.com><20070621180158.GC9078@mercury.ccil.org><41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> <001201c7b43b$970e10a0$6601a8c0@oemcomputer> <467AD6E9.6020809@yahoo-inc.com> In-Reply-To: <467AD6E9.6020809@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Addison Phillips [mailto:addison@yahoo-inc.com] > I think we should close this discussion. We're unlikely to make it > further this time than last... Before we kill this off too quickly... I don't remember all the discussion from the last time around, but seems to= me we at least have identified a small set of core issues: 1) Would UTF-8 be desirable (all other things being equal)? 2) Is such a breaking change in the registry acceptable? 3) Does the content of a registry edit have to be exchanged in email bodies= on IETF-languages and be in the same encoding in those emails? Randy broke 3 into two parts, which I'll modify slightly: 3a) Do we need or want to stick with communicating proposed registry edits = solely in the body of emails? 3b) If "yes" to 3a, then can we use a different representation in discussio= n on IETF-languages and depend on the LST Reviewer (or his assistants) and = IANA between them to convert the content as needed? I think there is consensus on 1. If we are willing to discuss this a bit fu= rther, it might be helpful to focus on 2 before 3. Wrt 2: Non-ASCII content would appear in certain attribute fields accompany= ing a subtag: only in description or comment fields. Would there really be = parsers that make assumptions about the content of these fields, or that as= sume only byte values within the range 0x20 - 0x7E would be encountered? Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 12:55:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mPZ-0001aO-PV; Fri, 22 Jun 2007 12:55:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1mPY-0001aD-BN for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 12:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mPY-0001a5-1v for ltru@ietf.org; Fri, 22 Jun 2007 12:55:04 -0400 Received: from ms-smtp-01.rdc-kc.rr.com ([24.94.166.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mPV-0005jZ-Mw for ltru@ietf.org; Fri, 22 Jun 2007 12:55:04 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-01.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5MGreme010844; Fri, 22 Jun 2007 11:53:41 -0500 (CDT) Message-ID: <467BFEF5.7010901@gmail.com> Date: Fri, 22 Jun 2007 11:55:17 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: XML References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> <6.0.0.20.2.20070622154148.08b36570@localhost> In-Reply-To: <6.0.0.20.2.20070622154148.08b36570@localhost> X-Enigmail-Version: 0.95.1 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-01.rdc-kc.rr.com id l5MGreme010844 X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Duerst yazm=C4=B1=C5=9F: > At 05:30 07/06/22, Stephane Bortzmeyer wrote: >=20 >> Your schema seems quite clsoe to mine >> (http://www.langtag.net/registries/ltru.rnc) and I suggest that people >> interested in moving this schema from the current draft to a "real" >> schema, production-ready, gather in private since XML work is not well >> received on the LTRU list. OK, looks like you guys have it covered. I would just prefer using XML Schema for schema, because i think it's the most standard way, and while i'm not an XML guru per se, it is likely to be the most powerful as well. Also, it might be worth considering supporting multiple languages for some textual elements (by requiring a lang attribute), as in: Unified Turkic Latin Alphabet (Historical) >=20 > The statement in the last clause is only partially true. > When I made an attempt at a consensus call on this issue (many months a= go), > my recollection was that a slight majority of the people responding > favored moving to XML, but that that majority wasn't strong enough > to make the change, in particular because the people who would have > had to do the actual work (read: editors) weren't very excited. >=20 > It is true that if we stay with the current state (no XML), then > we shouldn't use the list to discuss XML, because we want to > concentrate to get our documents out. For what it's worth, i'm ready to vote for XML. Lemme know if you folks ever need an extra vote. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGe/71O75ytyYoOa8RAoFTAKCpd2q1vXzHJa5uEDOL/I6MJDOk5gCgkQ90 2rSYixA8FS9e1aVhOFcSS3I=3D =3DVtBl -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 13:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mZ3-0006VW-42; Fri, 22 Jun 2007 13:04:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1mZ2-0006VM-49 for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mZ1-0006VE-Qy for ltru@ietf.org; Fri, 22 Jun 2007 13:04:51 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mYy-0007Oz-0P for ltru@ietf.org; Fri, 22 Jun 2007 13:04:51 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I1mYu-00071V-SM; Fri, 22 Jun 2007 13:04:44 -0400 Date: Fri, 22 Jun 2007 13:04:44 -0400 To: "\"Reshat Sabiq (Re??at)\"" Subject: Re: [Ltru] Re: XML Message-ID: <20070622170444.GM9078@mercury.ccil.org> References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> <6.0.0.20.2.20070622154148.08b36570@localhost> <467BFEF5.7010901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467BFEF5.7010901@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "Reshat Sabiq (Re??at)" scripsit: > OK, looks like you guys have it covered. I would just prefer using XML > Schema for schema, because i think it's the most standard way, and while > i'm not an XML guru per se, it is likely to be the most powerful as well. It is neither the most standard nor the most powerful. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 13:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mgf-00059J-IM; Fri, 22 Jun 2007 13:12:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1mgd-000533-SN for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mgd-00052m-IV for ltru@ietf.org; Fri, 22 Jun 2007 13:12:43 -0400 Received: from ms-smtp-01.rdc-kc.rr.com ([24.94.166.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mgc-0001rI-7x for ltru@ietf.org; Fri, 22 Jun 2007 13:12:43 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-01.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5MHBQij024038; Fri, 22 Jun 2007 12:11:26 -0500 (CDT) Message-ID: <467C031F.4070509@gmail.com> Date: Fri, 22 Jun 2007 12:13:03 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] UTF-8 References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> In-Reply-To: <20070621185738.GE9078@mercury.ccil.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-01.rdc-kc.rr.com id l5MHBQij024038 X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ltru@ietf.org, GerardM X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Cowan yazm=C4=B1=C5=9F: > GerardM scripsit: >=20 >> It happens often that exactly because of the content is NOT UTF-8 that >> I get the information mangled. With UTF-8 you either get the message >> or it will be indicated that you have insufficient fonts installed. Th= e >> notion that the current encoding always works is wrong. >=20 > It always works for ASCII text, and the Registry is restricted to > ASCII text. Well, i think for me the interest is whether the next release could mandate UTF-8, so that we don't have to deal w/ escapes. I guess there are 2 issues: 1. Email clients 2. Browser clients On 1: If you can see s w/ cedilla on the first line above, then your email client handled UTF-8; if not maybe you could try choosing UTF-8 encoding manually. I know that Thunderbird and Outlook don't have a problem w/ UTF-8. What other email clients are we talking about? If your pine client thru your shell can't handle it, then really you will only have few characters mangled, because charactes overlapping w/ ASCII are rendered the same whether it's UTF-8 or ISO-8859-1. Then you still have an option of using another email client to UTF-8 appropriately when you really care. On 2: I don't think any up-to-date browsers have any problem w/ UTF-8 (IE, firefox, seamonkey, opera). The only ones that would have problem could be cell-phone based ones that don't belong to one of the brands above and some shell-based ones, which probably depends on what shell is being used. And then again i'd say it's not a big deal, because you can use another client to read stuff if you care. Besides the pros of not having to deal w/ escapes outweigh the cons of not having UTF-8 support on some cell-phone devices and some shells. So what exactly email and browser clients are we talking about that don't support UTF-8? If it's only a matter of email, we could say: "when using email, you can send requests using escapes, but these escapes will be posted in UTF-8 in the registry"? If we adopt UTF-8 for new submissions, we could also say "starting on all character escapes in the registry will be converted to UTF-8." Most importantly, if UTF-8 is going to be easier for 95% of mainstream users, couldn't we tell 5% of peculiar users to deal w/ it? The registry for the internet should probably be based on up-to-date technologies, rather than trying to accommodate obsolete ones as well, which i think are used to rarely to be cared about anyway. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGfAMfO75ytyYoOa8RAmvdAKCFyK9AXwVpB0t1zFleyELBVrtHlACfcjp7 WxouWLWqXt+rq6xf4I9iwgQ=3D =3D4ilM -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 13:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1n1W-0004cw-L7; Fri, 22 Jun 2007 13:34:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1n1V-0004ak-PC for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1n1V-0004ac-Fa for ltru@ietf.org; Fri, 22 Jun 2007 13:34:17 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1n1U-0007Yo-47 for ltru@ietf.org; Fri, 22 Jun 2007 13:34:17 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 753D71E1590; Fri, 22 Jun 2007 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at sharplabs.com Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRP7XgoZP6b4; Fri, 22 Jun 2007 10:34:10 -0700 (PDT) Received: from wabex1.enet.sharplabs.com (wabex1.sharpamericas.com [172.29.224.8]) by mail2.sharplabs.com (Postfix) with ESMTP id 128B81E1374; Fri, 22 Jun 2007 10:34:10 -0700 (PDT) Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 10:34:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] UTF-8 Date: Fri, 22 Jun 2007 10:34:09 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] UTF-8 Thread-Index: Ace0PxsXPX71+8MJQbeZmmJtH9ewqQApqKQwAAU7HBA= From: "McDonald, Ira" To: "Peter Constable" , "Addison Phillips" , "Randy Presuhn" X-OriginalArrivalTime: 22 Jun 2007 17:34:09.0616 (UTC) FILETIME=[8A727D00:01C7B4F3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, A suggested refinement to 3b below: * Email discussion remains 7-bit ASCII with some escape convention. * LSR (and helpers) send all official approved updates to IANA as plaintext email in US-ASCII with an attachment of the UTF-8 text for cut-and-paste into the Registry. The necessary effort to use the ASCII to UTF-8 conversion tool is moved back into the LSR's scope. Hmm? Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Peter Constable [mailto:petercon@microsoft.com] Sent: Friday, June 22, 2007 11:20 AM To: Addison Phillips; Randy Presuhn Cc: LTRU Working Group Subject: RE: [Ltru] UTF-8 > From: Addison Phillips [mailto:addison@yahoo-inc.com] > I think we should close this discussion. We're unlikely to make it > further this time than last... Before we kill this off too quickly... <...snip...> 3) Does the content of a registry edit have to be exchanged in email = bodies on IETF-languages and be in the same encoding in those emails? Randy broke 3 into two parts, which I'll modify slightly: 3a) Do we need or want to stick with communicating proposed registry = edits solely in the body of emails? 3b) If "yes" to 3a, then can we use a different representation in = discussion on IETF-languages and depend on the LST Reviewer (or his = assistants) and IANA between them to convert the content as needed? I think there is consensus on 1. If we are willing to discuss this a bit = further, it might be helpful to focus on 2 before 3. No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.472 / Virus Database: 269.9.4/860 - Release Date: 6/21/2007 = 5:53 PM =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 13:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1n2U-0005FI-Ji; Fri, 22 Jun 2007 13:35:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1n2S-0005BU-1x for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1n2R-0005Au-Ij for ltru@ietf.org; Fri, 22 Jun 2007 13:35:15 -0400 Received: from ms-smtp-04.rdc-kc.rr.com ([24.94.166.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1n2Q-0007gf-6Z for ltru@ietf.org; Fri, 22 Jun 2007 13:35:15 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-04.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5MHZ3Ho003084; Fri, 22 Jun 2007 12:35:03 -0500 (CDT) Message-ID: <467C0864.9070100@gmail.com> Date: Fri, 22 Jun 2007 12:35:32 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] UTF-8 References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> <467C031F.4070509@gmail.com> In-Reply-To: <467C031F.4070509@gmail.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-04.rdc-kc.rr.com id l5MHZ3Ho003084 X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org, GerardM X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reshat Sabiq (Re=C5=9Fat) yazm=C4=B1=C5=9F: > Most importantly, if UTF-8 is going to be easier for 95% of mainstream > users, couldn't we tell 5% of peculiar users to deal w/ it? The registr= y > for the internet should probably be based on up-to-date technologies, > rather than trying to accommodate obsolete ones as well, which i think > are used to rarely to be cared about anyway. I just read the updates thru http, and i agree w/ Randy and Addison's idea of converting escapes to UTF-8 after the email phase. The submitter can always verify the correctness thereof thru http, and object if there are any mistakes. If this is done by a little program, that is written w/ some unit tests, and tested, then errors should be minimal. As far as passivity, if this takes effect w/ the next release of the registry spec, and people know about it in advance, then it's natural for it to not be passive. For temporary passivity, the old registry could continue to exist w/o updates at the existing URL, and the new registry to be updated could be exposed thru a new URL. That happened in java betweem 1.3 and 1.4, and 1.4 and 5: it's inevitable at early stages, and maybe even beyond. Deep down, do we not all know that it will be UTF-8 and XML at some point? I think we do, so passivity question will come up anyway, it's just a matter of managing it well. - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGfAhjO75ytyYoOa8RAr46AKCS1xewkVIBkDeF2hWnAbr/4IJ5OACglfGh nd9m3loc749N0Pyy0aOWNh4=3D =3Dt4Pf -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 13:45:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nBx-0003nw-UM; Fri, 22 Jun 2007 13:45:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1nBw-0003nr-VS for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:45:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nBw-0003nj-Lt for ltru@ietf.org; Fri, 22 Jun 2007 13:45:04 -0400 Received: from ms-smtp-03.rdc-kc.rr.com ([24.94.166.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1nBv-00012X-8O for ltru@ietf.org; Fri, 22 Jun 2007 13:45:04 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-03.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l5MHglu3021468; Fri, 22 Jun 2007 12:42:48 -0500 (CDT) Message-ID: <467C0AB5.6050005@gmail.com> Date: Fri, 22 Jun 2007 12:45:25 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: XML References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> <6.0.0.20.2.20070622154148.08b36570@localhost> <467BFEF5.7010901@gmail.com> <467C0701.1030307@yahoo-inc.com> In-Reply-To: <467C0701.1030307@yahoo-inc.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-03.rdc-kc.rr.com id l5MHglu3021468 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Addison Phillips yazm=C4=B1=C5=9F: > XML has already been rejected several times. >=20 > Whether or not I like the idea of an XML registry, I absolutely oppose, > at this late date, changing the registry format to XML. Stephane, et al= , > have provided some very nice XML versions/transformations of the > registry. If you like XML, use those. The canonical registry, though, i= s > in the record-jar format. Yes, it's an option as a work-around, but it being unofficial will cause people to avoid it most of the time. Some notes: http://www.langtag.net/registries/language-subtag-registry.xml this has missing comments. http://www.langtag.net/registries/language-subtag-registry2.xml This shows UTF-8 and XML together quite well, although i'd lean towards making tag an element rather than attribute. - From baku1926 in the latter, does it seem to you redundant to have ASCI= I escapes next to UTF-8? I think it seems redundant to me, despite some really made up characters in that alphabet. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGfAq1O75ytyYoOa8RAoOiAJ9Qj/CrvQb3krD88W1MSAcP4sEwUwCgg5xA aoURQlf06L3ylKtISpxQWEc=3D =3DAYol -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 17:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qGl-0001dZ-77; Fri, 22 Jun 2007 17:02:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1qGk-0001cl-CG for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 17:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qGk-0001cQ-1Q for ltru@ietf.org; Fri, 22 Jun 2007 17:02:14 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qGi-0003Fr-P4 for ltru@ietf.org; Fri, 22 Jun 2007 17:02:14 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7FB2424080E; Fri, 22 Jun 2007 23:02:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 449F311A6B; Fri, 22 Jun 2007 22:57:57 +0200 (CEST) Date: Fri, 22 Jun 2007 22:57:57 +0200 From: Stephane Bortzmeyer To: "Reshat Sabiq (Re?at)" Message-ID: <20070622205757.GA16543@sources.org> References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> <6.0.0.20.2.20070622154148.08b36570@localhost> <467BFEF5.7010901@gmail.com> <467C0701.1030307@yahoo-inc.com> <467C0AB5.6050005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467C0AB5.6050005@gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] Re: XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Jun 22, 2007 at 12:45:25PM -0500, Reshat Sabiq (Re?at) wrote a message of 45 lines which said: > Some notes: > http://www.langtag.net/registries/language-subtag-registry.xml this > has missing comments. I though nobody would notice :-) Anyway, it was simple to fix. Done. > http://www.langtag.net/registries/language-subtag-registry2.xml This > shows UTF-8 and XML together quite well, although i'd lean towards > making tag an element rather than attribute. [Aaahhh, the famous "element vs. attribute" fight of every XML-related discussion :-) ] There is no official XML schema for the LSR. If some people are interested, we can set up a group to try to define one? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 22 17:07:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qLc-0006JI-Oj; Fri, 22 Jun 2007 17:07:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I1qLZ-00069d-GZ for ltru-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 17:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qLZ-00069V-75 for ltru@ietf.org; Fri, 22 Jun 2007 17:07:13 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qLW-0004Cm-US for ltru@ietf.org; Fri, 22 Jun 2007 17:07:13 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7FE5124080E; Fri, 22 Jun 2007 23:07:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 6579611B7F; Fri, 22 Jun 2007 23:05:19 +0200 (CEST) Date: Fri, 22 Jun 2007 23:05:19 +0200 From: Stephane Bortzmeyer To: "Reshat Sabiq (Re?at)" Message-ID: <20070622210519.GB16543@sources.org> References: <467ABCB8.9050103@gmail.com> <20070621203019.GA14054@sources.org> <6.0.0.20.2.20070622154148.08b36570@localhost> <467BFEF5.7010901@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467BFEF5.7010901@gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org Subject: [Ltru] [OT] XML schemas languages (Was: XML X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Jun 22, 2007 at 11:55:17AM -0500, Reshat Sabiq (Re?at) wrote a message of 42 lines which said: > I would just prefer using XML Schema for schema, > because i think it's the most standard way, Standard? In what way? RFC 3470 "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols" does not give it any special status. Some RFC use W3C XML Schema (RFC 4931), some use another schema langage (RFC 4287). Even at its birthplace of W3C, they now use Relax NG for some standards (http://www.w3.org/TR/SVG12/). > and while i'm not an XML guru per se, it is likely to be the most > powerful as well. Sorry, as you say, you are not a guru. One can say many things about the strengths and weaknesses of the various XML schema languages but I believe that there is a clear consensus that Relax NG is by far the most powerful. > Also, it might be worth considering supporting multiple languages for > some textual elements (by requiring a lang attribute), as in: > > Unified Turkic Latin Alphabet (Historical) > This is not possible for the recordjar2anything converters because the information is not, unfortunately, in the registry. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 19:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bYu-00031j-Rn; Sun, 24 Jun 2007 19:32:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2bYt-00031e-Eg for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 19:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bYt-00031P-55 for ltru@ietf.org; Sun, 24 Jun 2007 19:32:07 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2bYr-0005Y1-R9 for ltru@ietf.org; Sun, 24 Jun 2007 19:32:07 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070624233204.WIXY26470.mta15.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 19:32:04 -0400 Message-ID: <006f01c7b6b7$dfb3a030$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 16:32:04 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Which yields 54 macrolanguages in 4645bis, zap (Zapotec) being the one > with the most extlangs, 58 (if we do not count the sign languages). I assume that if the extlang mechanism were abolished, then the special-case handling of "sgn" would not occur either, and American Sign Language would be indicated as simply "ase" (not "sgn-ase"), and "sgn-US" would be deprecated in favor of "ase". -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 19:35:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bcX-0004YK-6m; Sun, 24 Jun 2007 19:35:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2bcV-0004YF-K0 for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 19:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bcV-0004Y7-9x for ltru@ietf.org; Sun, 24 Jun 2007 19:35:51 -0400 Received: from mta3.adelphia.net ([68.168.78.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2bcU-0006RC-V2 for ltru@ietf.org; Sun, 24 Jun 2007 19:35:51 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070624232847.PWZD6326.mta9.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 19:28:47 -0400 Message-ID: <006d01c7b6b7$6a752140$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 16:28:47 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'm doing a lot of catching up, which means reading over a lot of material that others have already replied to. So I apologize in advance if I rehash anything that's been decided. Mark Davis quoted John Cowan: >> [...] We had an excellent idea of what 639-3 would both look and actually >> be like when 4646 was finalized. We couldn't include 639-3 or extlangs >> because 639-3 itself was not yet final. > ... > For example, you can't mean that every member of the working group had > looked it over thoroughly, and explored all the implementation > ramifications. I'd like to see a show of hands for those who did -- maybe > everyone except for me had, but I'd be rather surprised at that. That isn't fair. I doubt it could be said of any standard, or specification, or protocol, that every conceivable implementation ramification has been fully explored. I agree with John on this point. We did have an excellent idea of what ISO 639-3 would be like by this time. There have been virtually no structural changes in 639-3 since Peter originally formulated the extlang concept and we discussed it. Of course somebody will have missed a detail somewhere, but we had the general idea. > After all, it is trivial to make a 4647bis that adds an optional step for > microlanguages, which is that when you get to a microlanguage, the next > step is to look at its macrolanguage before falling back to the default. > That has the same result (and same problems) as extlang, but is something > that is not baked into the standard -- is something that people can > implement if they want without impacting matching for everyone else. I can see value in this approach, because I can see value in updating my implementation. But we have shed so much digital blood over Suppress-Script on the basis that matching implementations won't be smart enough to match "nl-Latn-NL" with "nl-NL", and won't be updated to do so, that I continue not to understand why we should assume any will be updated to fall back to macrolanguages. I have a real problem with the idea that tag producers should be encouraged to tag Cantonese as "yue", thereby drastically reducing the likelihood that tag consumers searching for "zh" or "zh-yue" will find it. The outcome of such an scenario will be that tag producers will be reluctant to use the new 4646bis subtags in general, and may ignore other changes from 4646 to 4646bis. >> I realize that this cause is probably not important to you, because you >> can (comparatively) easily change all "zh-yue" tags to "yue", but this is >> not the case for other users of BCP 47 on and off the Internet, who will >> never even hear about the change. > > These are irregular tags anyway, and can stay irregular tags afterwards. > We and everyone else already have to deal with equivalences with > grandfathered and irregular tags anyway; these are not a real problem. I feel as though we are recanting what was said on ietf-languages at the time "zh-cmn" and friends were registered, that they would eventually become generative tags and wouldn't add to the grandfathered-redundant slag heap. > If you can't make a compelling case that extlang will make BCP 47 better > instead of worse, and won't even look at the reasons not to do it, nor > even bother to set out a case for it, then why should we add it? My case for extlang is that it allows simplistic RFR matching engines to retrieve "zh-yue" content when handed "zh", but still identifies the content as Cantonese for more sophisticated matching engines that can take advantage of extlang. It puts the additional burden of identifying the content on the tag producer, where it belongs, not on the tag consumer. The Suppress-Script argument shows that we don't trust tag consumers to be very sophisticated. >>> B. (optional) Add a field Macrolanguage: to the language subtag >>> registry. >> >> I am not opposed to this, precisely because encompassed languages and the >> corresponding macrolanguage cannot be identified syntactically. > > Good. But there is no sense in having a Macrolanguage field unless we define a specific use for this information in 4646bis. Just saying "this language has a macrolanguage" (or alternatively, "this is a macrolanguage that has this list of encompassed languages") doesn't add anything to tagging. Some months ago I suggested a Language-Type field that would reflect the ISO 639-3 classifications, and several people pointed out that it didn't add anything to tagging. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 19:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bfT-0007NC-QR; Sun, 24 Jun 2007 19:38:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2bfR-00078l-UH for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 19:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bfR-00075c-H6 for ltru@ietf.org; Sun, 24 Jun 2007 19:38:53 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2bfR-0006eN-6Q for ltru@ietf.org; Sun, 24 Jun 2007 19:38:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070624233852.FFQH27139.mta13.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 19:38:52 -0400 Message-ID: <007701c7b6b8$d310cdc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 16:38:52 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Re: extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I take it you're suggesting (or interpreted the proposal) to mean that the > macrolanguage would contain a pointer or pointers to its sublanguages. > Hence something like: > > %% > Type: language > Subtag: zh > Description: Chinese > ... > Encloses: yue,cmn,..... > %% I don't like this, for at least two reasons: 1. If the goal if to facilitate matching, then the direction of fallback ought to be from "yue" (or "cmn", etc.) back to "zh". It doesn't make sense to put the fallback information in "zh" in that case. 2. As Addison noted, we already have a precedent for using multiple fields to indicate multiple Prefix values. I see no point in putting multiple values in a single "Encloses" field and introducing a new comma-separation convention for just this field. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 19:48:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2boh-0004YG-1m; Sun, 24 Jun 2007 19:48:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2bof-0004YB-PF for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 19:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bof-0004Y2-Fj for ltru@ietf.org; Sun, 24 Jun 2007 19:48:25 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2boe-0000MU-62 for ltru@ietf.org; Sun, 24 Jun 2007 19:48:25 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070624234823.XKIA26470.mta15.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 19:48:23 -0400 Message-ID: <007e01c7b6ba$27807210$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 16:48:23 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Re: UTF-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: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > The question is: can the LSR and/or his/her proxy (i.e. Doug) manage to > send email to IANA encoded as UTF-8. All other emails are "nice to have", > but not required. I think the answer here is that they can manage it. I would be happy to jump through whatever hoops are needed to get the Registry established and maintained in UTF-8, if that is the wish of the WG. Certainly I can send mail in UTF-8, and even if I couldn't, I could attach a file. I believe other people in the WG had arguments against a UTF-8 Registry. I suspect they are using systems or applications that are not fully Unicode-enabled. I would like to reiterate that browsers and fonts are by no means the only parts of a computer system that determine whether UTF-8 is supported or not. > The "compelling reason" against UTF-8 that I've seen has nothing to do > with email or browser availability or IANA's skill set. It is simply that > it is a change in the registry format and could break existing > implementations that rely on the ASCII format. This is true. RFC 4646bis could specify that either UTF-8 or hex escapes are acceptable formats for the Registry, which would allow new implementation to read old copies of the Registry, but I don't know how to solve the reverse problem (if such it is). > I note also that UTF-8 has failed to reach consensus on at least three > separate occasions. One problem is that it's been conflated with other issues, such as XML I applaud Randy's efforts to separate the discussions and get each question answered one by one. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 19:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bub-0000Hc-RE; Sun, 24 Jun 2007 19:54:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2bua-0000HX-DN for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 19:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2bua-0000HP-40 for ltru@ietf.org; Sun, 24 Jun 2007 19:54:32 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2buY-0001bj-Rv for ltru@ietf.org; Sun, 24 Jun 2007 19:54:32 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070624235430.OORI8388.mta11.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 19:54:30 -0400 Message-ID: <008001c7b6bb$01e31f70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 16:54:30 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: Modified: field in the registry? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Isn't it a problem that there is no way to know the modification date? > Should we work on a Modified: field in the registry? We should first make sure we understand the purpose for adding this information. We have an Added date so that tag users can see which subtags were available at any given time. But because of certain stability measures we have taken, once a subtag is added, it should always be valid from that point on, with essentially the same meaning. A Modified date might imply that the meaning of a subtag changed on that date, which isn't supposed to happen. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 24 20:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2c8o-0006at-8f; Sun, 24 Jun 2007 20:09:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2c8n-0006ao-NL for ltru-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 20:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2c8n-0006ag-Dn for ltru@ietf.org; Sun, 24 Jun 2007 20:09:13 -0400 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2c8l-0002yE-2E for ltru@ietf.org; Sun, 24 Jun 2007 20:09:13 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070625000910.HHEM14967.mta16.adelphia.net@DGBP7M81> for ; Sun, 24 Jun 2007 20:09:10 -0400 Message-ID: <009001c7b6bd$0e5f0190$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 24 Jun 2007 17:09:10 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Re: scripts on langtag.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: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > [Side note: the registry seems a bit inconsistent. Why: > > Subtag: Ethi > Description: Ethiopic (Geʻez) > Description: Ethiopic (Ge'ez) > > and: > > Subtag: Hang > Description: Hangul (Hangŭl, Hangeul) > > Why not: > > Subtag: Hang > Description: Hangul (Hangŭl) > Description: Hangul (Hangeul) > > ? I split these out in draft-ietf-ltru-4645bis-01: Subtag: Hang Description: Hangul Description: Hangŭl Description: Hangeul > I would be glad to provide plain-text UTF8 versions of the registry as > soon as I have time to write the program. Since langtag.net is a > cooperative effort, any cooperation is welcome (probably better off-list). Just load the Registry into any editor that can convert hex NCRs. Both UniPad and BabelPad can do this; there are probably others. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 25 04:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jpn-0001M4-1Q; Mon, 25 Jun 2007 04:22:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2jpl-0001Lp-OL for ltru-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 04:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jpl-0001Lh-BT for ltru@ietf.org; Mon, 25 Jun 2007 04:22:05 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2jpj-0000sx-0H for ltru@ietf.org; Mon, 25 Jun 2007 04:22:05 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7436A1C0355; Mon, 25 Jun 2007 10:22:02 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6F1491C0354; Mon, 25 Jun 2007 10:22:01 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6BB7858EBF3; Mon, 25 Jun 2007 10:22:01 +0200 (CEST) Date: Mon, 25 Jun 2007 10:22:01 +0200 From: Stephane Bortzmeyer To: GerardM Message-ID: <20070625082201.GA15468@nic.fr> References: <41a006820706212358r4aa63497qbae1402c2b456489@mail.gmail.com> <20070622074654.GB18927@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20070622074654.GB18927@nic.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org Subject: [Ltru] Re: scripts on langtag.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: , Errors-To: ltru-bounces@ietf.org --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 22, 2007 at 09:46:54AM +0200, Stephane Bortzmeyer wrote a message of 63 lines which said: > I would be glad to provide plain-text UTF8 versions of the registry > as soon as I have time to write the program.k Done (the program is attached for the curious). Available at: http://www.langtag.net/registries/language-subtag-registry.utf8 --envbJBWh7q8WU6mo Content-Type: text/x-python; charset=us-ascii Content-Disposition: attachment; filename="ncr2utf8.py" #!/usr/bin/python import sys import re ncr = re.compile("&#x([0-9A-F]+);", re.IGNORECASE) def convert(thematch): codepoint = long(thematch.group(1), 16) return unichr(codepoint) for ifilename in sys.argv[1:]: print "Converting %s..." % ifilename ofilename = ifilename + ".utf8" ifile = open(ifilename, "r") ofile = open(ofilename, "w") data = unicode(ifile.read(), "ascii") udata = re.sub(ncr, convert, data) ifile.close() ofile.write(udata.encode("utf-8")) ofile.close() --envbJBWh7q8WU6mo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --envbJBWh7q8WU6mo-- From ltru-bounces@ietf.org Mon Jun 25 13:26:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sKJ-0000J7-22; Mon, 25 Jun 2007 13:26:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I2sKH-0000IN-AG for ltru-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 13:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sKH-0000IF-0m for ltru@ietf.org; Mon, 25 Jun 2007 13:26:09 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sKF-0002e0-KS for ltru@ietf.org; Mon, 25 Jun 2007 13:26:09 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5PHQ3vx084094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2007 10:26:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=w/77rxYQbCWThT8YIgCgDZSVrCAIqwsQVI6mREk1lhYZe3PjnhiulkoDKWE0jbZl Message-ID: <467FFAAA.6070608@yahoo-inc.com> Date: Mon, 25 Jun 2007 10:26:02 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Modified: field in the registry? References: <008001c7b6bb$01e31f70$6401a8c0@DGBP7M81> In-Reply-To: <008001c7b6bb$01e31f70$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Doug Ewell wrote: > Stephane Bortzmeyer wrote: > >> Isn't it a problem that there is no way to know the modification date? >> Should we work on a Modified: field in the registry? > > We should first make sure we understand the purpose for adding this > information. We have an Added date so that tag users can see which > subtags were available at any given time. But because of certain > stability measures we have taken, once a subtag is added, it should > always be valid from that point on, with essentially the same meaning. > A Modified date might imply that the meaning of a subtag changed on that > date, which isn't supposed to happen. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 25 23:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I31Je-0003Ej-N6; Mon, 25 Jun 2007 23:02:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I31Je-0003Ee-6H for ltru-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 23:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I31Jd-0003EW-RG for ltru@ietf.org; Mon, 25 Jun 2007 23:02:05 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I31JY-0002mn-FI for ltru@ietf.org; Mon, 25 Jun 2007 23:02:05 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070626030159.ORMO6326.mta9.adelphia.net@DGBP7M81>; Mon, 25 Jun 2007 23:01:59 -0400 Message-ID: <000d01c7b79e$5d996c00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 25 Jun 2007 20:01:59 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: scripts on langtag.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: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Available at: > > http://www.langtag.net/registries/language-subtag-registry.utf8 I'd like to suggest that the other "distilled" data at langtag.net be similarly converted from hex escapes to real Unicode characters. The Registry contains hex escapes because it has to, not because the country denoted by CI is really called Côte d'Ivoire. As long as you're doing one type of processing, you may as well do the other. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 26 05:38:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37UQ-0006xS-1Z; Tue, 26 Jun 2007 05:37:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I37UO-0006wj-KN for ltru-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 05:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37UO-0006wA-1v for ltru@ietf.org; Tue, 26 Jun 2007 05:37:36 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I37Tz-00061h-Lg for ltru@ietf.org; Tue, 26 Jun 2007 05:37:36 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3B9AB240826; Tue, 26 Jun 2007 11:37:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id E3BF3110EB; Tue, 26 Jun 2007 11:34:38 +0200 (CEST) Date: Tue, 26 Jun 2007 11:34:38 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070626093438.GA22349@sources.org> References: <000d01c7b79e$5d996c00$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01c7b79e$5d996c00$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group Subject: [Ltru] Re: scripts on langtag.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: , Errors-To: ltru-bounces@ietf.org On Mon, Jun 25, 2007 at 08:01:59PM -0700, Doug Ewell wrote a message of 17 lines which said: > I'd like to suggest that the other "distilled" data at langtag.net > be similarly converted from hex escapes to real Unicode characters. Done for the tab-separated text files and for the SQL files. UTF-8 SQL files have been tested with PostgreSQL and work fine. Anyone to test tab-separated UTF-8 text files with MS Excel or a similar tool? I did not convert the XML files, because any XML processor is supposed to read hex escapes. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 26 10:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BoH-0008Ky-KX; Tue, 26 Jun 2007 10:14:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I3BoG-0008K8-3Q for ltru-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 10:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BoF-0008J4-Jt for ltru@ietf.org; Tue, 26 Jun 2007 10:14:23 -0400 Received: from bay0-omc1-s2.bay0.hotmail.com ([65.54.246.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Bnn-0003qm-I0 for ltru@ietf.org; Tue, 26 Jun 2007 10:14:23 -0400 Received: from hotmail.com ([65.54.169.27]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 26 Jun 2007 07:13:55 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Jun 2007 07:13:54 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Tue, 26 Jun 2007 14:13:51 GMT X-Originating-IP: [74.255.101.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com From: "CE Whitehead" To: ietf-languages@iana.org Bcc: Date: Tue, 26 Jun 2007 10:13:51 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jun 2007 14:13:54.0739 (UTC) FILETIME=[3AACC030:01C7B7FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ltru@ietf.org Subject: [Ltru] [OT] Converting non-ASCII to ASCII X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, my response is below! Thx. --C. E. Whitehead cewcathar@hotmail.com Stephane Bortzmeyer bortzmeyer at nic.fr Mon Jun 25 21:46:40 CEST 2007 >Specially, having escape sequences (&#NNN;) *plus* the UTF-8 is >questionable since it is trivial to produce one from the other, >automatically (transliterations are a different thing). Sorry, it's not quite trivial; I cannot produce the escape sequences for those utf-8 characters I cannot get to display (I'm sorry to say there is no way here! Seriously we do not have the fonts available on most library computers; and no, patrons are not authorized to download any updated fonts for viewing characters, or an updated browser, etc. You Geeks forget that not everyone has internet access at home! or works from a work computer! in the U.S., in a lot of places, people use the internet at the library; they have Microsoft Windows, games, music at home, but not the internet! I've tried to set my browser to unicode encoding--when it's available; I've set my font to Lucida; I cannot get the characters people include in documents to read but ??? and the little rectangles; what else can I do??? Thx. (Thus, while I like the utf-8 version of the registry you now have, I hope you will keep the ascii version with the escape sequences http://www.iana.org/assignments/language-subtag-registry and that we will add to it the transliterations! Another option: (1) encode an html version, using the escape sequences in the text source make sure to point to the fonts that most people do not have (see: http://www.w3.org/International/questions/qa-utf8-upgrade "Fonts not available in a standard installation can often be downloaded from free sites by users, and you can point to those sites from your pages. It is not desirable to embed fonts in pages because the technology for that is proprietary and browser-specific.") (More Notes: http://www.w3.org/International/questions/qa-utf8-upgrade "Although many mobile phones support UTF-8, some do not. " Also older Windows operating systems do not support Unicode. ) --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 29 18:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OcT-0001tb-3c; Fri, 29 Jun 2007 18:07:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I4OcS-0001tV-HL for ltru-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 18:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OcR-0001sn-Sg for ltru@ietf.org; Fri, 29 Jun 2007 18:07:11 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Obu-000136-LB for ltru@ietf.org; Fri, 29 Jun 2007 18:07:11 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1555274waf for ; Fri, 29 Jun 2007 15:06:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=UbQWkSNUrfqR1p7JBrzWP83eQRfUmnpVnm5GPRDbIkK+NaOzuyXYJlzrUI1NyRg2l4lvDBFmsFKGP1cde7wBaQIrEgSgDc8wBlBx4FLDKYLIG1HHwYMxB+TO22XO2OIrjhIO76ToPKa68hw1nfUwOqwYE916TpwRqqQed5U+Hak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ltYahELFI978Lxto5V5wNTgjUe7FDqOg/ep07f/r8wOBmZXNyHnWXPLQ14uhG562+w6YZFwiw31geAz330BZJzi2Q5K3Z1Nb5X1XLFCz2nWXVFbayfL+wRTCR6SqASlMtjFrzBwoBSCwAAbD53erN+ZhVRU0/e+sudolAhvNuhU= Received: by 10.115.89.1 with SMTP id r1mr3012035wal.1183154797316; Fri, 29 Jun 2007 15:06:37 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Fri, 29 Jun 2007 15:06:37 -0700 (PDT) Message-ID: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> Date: Fri, 29 Jun 2007 15:06:37 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 60033eae17cced94 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Resolving issues X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132573126==" Errors-To: ltru-bounces@ietf.org --===============1132573126== Content-Type: multipart/alternative; boundary="----=_Part_100348_1401258.1183154797287" ------=_Part_100348_1401258.1183154797287 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Addison and I have been looking over some of the remaining issues, and have worked out some suggested language to resolve some open issues. http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html The IESG will solicit nominees for the position (initially or upon a vacancy) and seek to ascertain the candidates' qualifications. => The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications. Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters. -- Mark ------=_Part_100348_1401258.1183154797287 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Addison and I have been looking over some of the remaining issues, and have worked out some suggested language to resolve some open issues.

http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html

The IESG will solicit nominees for the position (initially or upon a vacancy) and seek to ascertain the candidates' qualifications.

=>

The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications.

Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters.

--
Mark ------=_Part_100348_1401258.1183154797287-- --===============1132573126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1132573126==-- From ltru-bounces@ietf.org Fri Jun 29 23:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4U16-0007Qe-DC; Fri, 29 Jun 2007 23:53:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I4U14-0007PE-HG for ltru-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 23:52:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4U14-0007Oz-6K for ltru@ietf.org; Fri, 29 Jun 2007 23:52:58 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4U13-0001IX-Uk for ltru@ietf.org; Fri, 29 Jun 2007 23:52:58 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=je9IVYxSqBKHZ6hSO1KVPks/7NvIE0g2FJgcnGVe6L4eOG+jDz0Oap4NOBJnwP+5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.225] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I4U0X-00007B-55 for ltru@ietf.org; Fri, 29 Jun 2007 23:52:25 -0400 Message-ID: <001e01c7baca$277222a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> Subject: Re: [Ltru] Resolving issues Date: Fri, 29 Jun 2007 20:53:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93569d6e487d4226cacd8185584e82353f41350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.225 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Mark Davis" > To: "LTRU Working Group" > Sent: Friday, June 29, 2007 3:06 PM > Subject: [Ltru] Resolving issues ... > The IESG will solicit nominees for the position (upon adoption of this > document or upon a vacancy) and then solicit feedback on the nominees' > qualifications. Does "adoption" mean "IESG approval" or "RFC publication"? Is the intent to cause the position to become vacant upon approval, until the IESG is able to make an appointment? > Qualified candidates should be familiar with BCP 47 and its requirements; be > willing to fairly, responsively, and judiciously administer the registration > process; and be suitably informed about the issues of language > identification so that they can draw upon and assess the claim and > contributions of language experts and subtag requesters. "claim" -> "claims" ? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru