From ltru-bounces@ietf.org Thu Jan 03 07:50:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAPWf-0005rj-HN; Thu, 03 Jan 2008 07:50:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JAPWe-0005ra-9g for ltru-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 07:50:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAPWd-0005rR-LM for ltru@ietf.org; Thu, 03 Jan 2008 07:50:19 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAPWd-0006Fc-9b for ltru@ietf.org; Thu, 03 Jan 2008 07:50:19 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 11B851C00D3 for ; Thu, 3 Jan 2008 13:50:18 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0D6D01C0094 for ; Thu, 3 Jan 2008 13:50:18 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0047C58EBBE for ; Thu, 3 Jan 2008 13:50:18 +0100 (CET) Date: Thu, 3 Jan 2008 13:50:17 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20080103125017.GA24326@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Happy International Year of Languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Happy New Year to everyone! http://portal.unesco.org/culture/en/ev.php-URL_ID=35344&URL_DO=DO_TOPIC&URL_SECTION=201.html 2008, International Year of Languages Languages matter ! On 16 May 2007, the United Nations General Assembly proclaimed 2008 to be the International Year of Languages. As language issues are central to UNESCO's mandate in education, science, social and human sciences, culture, and communication and information, the Organization has been named the lead agency for this event. I owe to Don Osborn a reference to that excellent paper on languages and what can we do for the IYL: http://www.crystalreference.com/DC_articles/Langdeath20.pdf What can we do ourselves for the IYL? Finishing 4646bis? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 03 14:37:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVso-0003Ts-C8; Thu, 03 Jan 2008 14:37:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JAVsn-0003Tj-8w for ltru-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 14:37:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVsm-0003Tb-TK for ltru@ietf.org; Thu, 03 Jan 2008 14:37:36 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound9-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAVsl-0007E3-5A for ltru@ietf.org; Thu, 03 Jan 2008 14:37:36 -0500 Received: from outbound9-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound9-sin-R.bigfish.com (Postfix) with ESMTP id E88001128CC8; Thu, 3 Jan 2008 19:34:42 +0000 (UTC) Received: from mail15-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound9-sin.bigfish.com (Postfix) with ESMTP id E6CEA440066; Thu, 3 Jan 2008 19:34:42 +0000 (UTC) Received: from mail15-sin (localhost.localdomain [127.0.0.1]) by mail15-sin-R.bigfish.com (Postfix) with ESMTP id 61CA910A80FF; Thu, 3 Jan 2008 19:33:28 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail15-sin (MessageSwitch) id 1199388808301395_18369; Thu, 3 Jan 2008 19:33:28 +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 mail15-sin.bigfish.com (Postfix) with ESMTP id ADFDCF58070; Thu, 3 Jan 2008 19:33:27 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2008010311360140-47813 ; Thu, 3 Jan 2008 11:36:01 -0800 In-Reply-To: <20080103102449.GA8966@nic.fr> To: Stephane Bortzmeyer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Thu, 3 Jan 2008 11:33:19 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/03/2008 11:33:19, Serialize complete at 01/03/2008 11:33:19, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/03/2008 11:36:01 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/03/2008 11:36:10 AM, Serialize complete at 01/03/2008 11:36:10 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Addition request: alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0871637654==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0871637654== Content-Type: multipart/alternative; boundary="=_alternative 006B773E882573C5_=" This is a multipart message in MIME format. --=_alternative 006B773E882573C5_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" I have no objection to this tag. However, it does seem to create the=20 possibility (mentioned before) that the same dialect could be identified=20 as gsw-FR (assuming there are no other gsw dialects in France).=20 Is it simply up to the user to decide whether to use regional or variant=20 tagging? Or should some guidelines be written to indicate a preference for = variant tagging over regional tagging if both exist? Regards, Karen Broome Stephane Bortzmeyer =20 Sent by: ietf-languages-bounces@alvestrand.no 01/03/2008 02:24 AM To ietf-languages@iana.org cc Subject Re: Addition request: alsatian Request in the body, for the MIME-impaired. LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Stéphane Bortzmeyer 2. E-mail address of requester: bortzmeyer+langtag@nic.fr 3. Record Requested:=20 Type: variant Subtag: alsatian Description: Alsatian variant of Alemannic Description: Elsässisch Prefix: gsw Comments:=20 4. Intended meaning of the subtag: There is a distinct variety of Alemannic spoken in Alsace. It is distinct from the language spoken in Germany and Switzerland partly for political reasons, because Alsace has been a french province for a long time. 5. Reference to published description of the language (book or article): * (fr) "L'alsacien, deuxi=E8me langue r=E9gionale de France" Insee, Chiffres pour l'Alsace no. 12, December 2002 http://www.insee.fr/fr/insee=5Fregions/alsace/rfc/docs/cpar12=5F1.pdf * (fr) Brunner, Jean-Jacques. L'alsacien sans peine. ASSiMiL, 2001. ISBN 2-7005-0222-1 * (fr) Laugel-Erny, Elsa. Cours d'alsacien. Les Editions du Quai, 1999. ISBN 978-2903548018 * (fr) Matzen, Raymond, and L=E9on Daul. Wie Geht's ? Le dialecte =E0 la port=E9e de tous La Nu=E9e Bleue, 1999. ISBN 2-7165-0464-4 * (fr) Matzen, Raymond, and L=E9on Daul. Wie Steht's ? Lexiques alsacien et fran=E7ais, Variantes dialectales, Grammaire La Nu=E9e Bleue, 2000. ISBN 2-7165-0525-X * (de) Fr=E9d=E9ric Hartweg: Die Sprachen im Elsass: Kalter Krieg oder vers=F6hntes Miteinander?. In: Ingo Kolboom und Bernd Rill (Hrsg.): Frankophonie -- nationale und internationale Dimensionen. Argumente und Materialien zum Zeitgeschehen 35, M=FCnchen: Hanns Seidel Stiftung, ISBN 3-88795-249-9.=20 http://www.hss.de/downloads/argumente=5Fmaterialien=5F35.pdf * (de) Hubert Klausmann, Konrad Kunze und Renate Schrambke (1994): Kleiner Dialektatlas - Alemannisch und Schw=E4bisch in Baden-W=FCrttemberg. Ver=F6ff. Alem. Inst. Frbg. Themen der Landeskunde 6, B=FChl (Baden): Konkordia, 1994. * (de) Friedrich Maurer: Neue Forschungen zur s=FCdwestdeutschen Sprachgeschichte. In: Sprachgeographie Beih. Wirkendes Wort. 21, S. 119-163, D=FCsseldorf: Schwann, 1972. 6. Any other relevant information: Do note there exists several "sub-dialects" (specifically between North and South of Alsace) but I do not know if there is a comprehensive list of them yet. Do note also that some alsatian local dialects are *not* variant of Alemannic at all but Franconian or even Roman languages. Alsatian is still in common use in Alsace, spoken and written. There is a localization of Microsoft Word ( http://www.faz.net/s/Rub4C34FD0B1A7E46B88B0653D6358499FF/Doc~E7E48128AB8C34= 8E1BCEB1EAF2D4105EA~ATpl~Ecommon~Scontent.html ) but I do not know if they use proper language tags. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages --=_alternative 006B773E882573C5_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
I have no objection to this tag. How= ever, it does seem to create the possibility (mentioned before) that the same dialect could be identified as gsw-FR (assuming there are no other gsw dialects in France).  

Is it simply up to the user to decide whether to use regional or variant tagging? Or should some guidelines be written to indicate a preference for variant tagging over regional tagging if both exist?

Regards,

Karen Broome




Stephane Bortzmeyer &= lt;bortzmeyer@nic.fr>
Sent by: ietf-languages-bounces@alve= strand.no

01/03/2008 02:24 AM

To
ietf-languages@iana.org
cc
Subject
Re: Addition request: alsatian





Request in the body, for the MIME-impaired.

LANGUAGE SUBTAG REGISTRATION FORM

1. Name of requester: St&#xE9;phane Bortzmeyer

2. E-mail address of requester: bortzmeyer+langtag@nic.fr

3. Record Requested:

  Type: variant
  Subtag: alsatian
  Description: Alsatian variant of Alemannic
  Description: Els&#xE4;ssisch
  Prefix: gsw
  Comments:

4. Intended meaning of the subtag: There is a distinct variety of
Alemannic spoken in Alsace. It is distinct from the language spoken in
Germany and Switzerland partly for political reasons, because Alsace
has been a french province for a long time.

5. Reference to published description
of the language (book or article):

   * (fr) "L'alsacien, deuxi=E8me langue r=E9gionale de Fra= nce" Insee,
   Chiffres pour l'Alsace no. 12, December 2002
   http://www.insee.fr/fr/insee=5Fregions/alsace/rfc/docs/cpar12= =5F1.pdf

   * (fr) Brunner, Jean-Jacques. L'alsacien sans peine. ASSiMiL,=
     2001. ISBN 2-7005-0222-1

   * (fr) Laugel-Erny, Elsa. Cours d'alsacien. Les Editions du Quai,
     1999. ISBN 978-2903548018

   * (fr) Matzen, Raymond, and L=E9on Daul. Wie Geht's ? Le dial= ecte =E0
     la port=E9e de tous La Nu=E9e Bleue, 1999. ISBN 2-7165= -0464-4

   * (fr) Matzen, Raymond, and L=E9on Daul. Wie Steht's ? Lexiqu= es
     alsacien et fran=E7ais, Variantes dialectales, Grammai= re La Nu=E9e
     Bleue, 2000. ISBN 2-7165-0525-X

   * (de) Fr=E9d=E9ric Hartweg: Die Sprachen im Elsass: Kalter K= rieg oder
     vers=F6hntes Miteinander?. In: Ingo Kolboom und Bernd Rill
     (Hrsg.): Frankophonie -- nationale und internationale<= br>      Dimensionen. Argumente und Materialien zum Zeitgescheh= en 35,
     M=FCnchen: Hanns Seidel Stiftung, ISBN
     3-88795-249-9. http://www.hss.de/downloads/argumente= =5Fmaterialien=5F35.pdf

   * (de) Hubert Klausmann, Konrad Kunze und Renate Schrambke (1994):
     Kleiner Dialektatlas - Alemannisch und Schw=E4bisch in
     Baden-W=FCrttemberg. Ver=F6ff. Alem. Inst. Frbg. Themen der
     Landeskunde 6, B=FChl (Baden): Konkordia, 1994.

   * (de) Friedrich Maurer: Neue Forschungen zur s=FCdwestdeutsc= hen
     Sprachgeschichte. In: Sprachgeographie Beih. Wirkendes Wort. 21,
     S. 119-163, D=FCsseldorf: Schwann, 1972.

6. Any other relevant information: Do note there exists several
"sub-dialects" (specifically between North and South of Alsace) but I
do not know if there is a comprehensive list of them yet. Do note also
that some alsatian local dialects are *not* variant of Alemannic at
all but Franconian or even Roman languages. Alsatian is still in
common use in Alsace, spoken and written. There is a localization of
Microsoft Word
(http://www.faz.net/s/Rub4C34FD0B1A7E46B88B0653D6358499FF/Doc~E7E48128AB8C3= 48E1BCEB1EAF2D4105EA~ATpl~Ecommon~Scontent.html)
but I do not know if they use proper language tags.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
--=_alternative 006B773E882573C5_=-- --===============0871637654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0871637654==-- From ltru-bounces@ietf.org Fri Jan 04 05:29:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAjnV-0007s9-Mv; Fri, 04 Jan 2008 05:29:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JAjnU-0007s4-DS for ltru-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 05:29:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAjnU-0007rw-39 for ltru@ietf.org; Fri, 04 Jan 2008 05:29:04 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAjnT-0005Mb-NH for ltru@ietf.org; Fri, 04 Jan 2008 05:29:03 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 019E91C0120 for ; Fri, 4 Jan 2008 11:29:03 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id F07511C00DB for ; Fri, 4 Jan 2008 11:29:02 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9D7DB58EBBE for ; Fri, 4 Jan 2008 11:29:02 +0100 (CET) Date: Fri, 4 Jan 2008 11:29:02 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20080104102902.GA28049@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org A registration request of a variant recently triggered a discussion on wether we should be able to add Description fields to tags, not just subtags (ignoring the specific issue of grandfathered tags). For instance, if we use "alsatian" to refer to the variant of alemannic spoken in Alsace (France), we cannot put a: Description: Alsatian Description: Elsässisch to the tag gsw-FR. Is it a real problem? Should we address it? How? Markus Scherer wrote: The Unicode Consortium encountered the same sort of problem for "encode this 'character' as that sequence of Unicode code points". A partial solution was to register names for some of those recommended sequences. Adding registration for select language tags, not just subtags, might help here as well. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 04 11:19:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApGw-0002Zl-HQ; Fri, 04 Jan 2008 11:19:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JApGv-0002ZG-Mx for ltru-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApGv-0002Yy-Bx for ltru@ietf.org; Fri, 04 Jan 2008 11:19:49 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JApGu-0007AF-VR for ltru@ietf.org; Fri, 04 Jan 2008 11:19:49 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080104161948.BBAX12952.mta13.adelphia.net@DGBP7M81> for ; Fri, 4 Jan 2008 11:19:48 -0500 Message-ID: <005501c84eed$a0579850$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 4 Jan 2008 08:19:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.2 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > A registration request of a variant recently triggered a discussion on > wether we should be able to add Description fields to tags, not just > subtags (ignoring the specific issue of grandfathered tags). > > For instance, if we use "alsatian" to refer to the variant of > alemannic spoken in Alsace (France), we cannot put a: > > Description: Alsatian > Description: Elsässisch > > to the tag gsw-FR. > > Is it a real problem? Should we address it? How? It might be a real problem, if the dialect or other language variant is commonly known by a distinct name (not just, say, "Australian English") and if tag users are unlikely to associate the dialect with the name of the base language. In http://www.alvestrand.no/pipermail/ietf-languages/2008-January/007279.html I proposed using the Comments field for this purpose, to avoid introducing a new mechanism that would probably be used by only a handful of (cherry-picked) variations: Type: language Subtag: gsw Description: Swiss German Description: Alemannic Added: 2006-03-08 Suppress-Script: Latn Comment: gsw-FR represents the Alsatian dialect -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 04 11:51:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAplW-0001mW-N6; Fri, 04 Jan 2008 11:51:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JAplW-0001mR-11 for ltru-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:51:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAplV-0001mJ-Nd for ltru@ietf.org; Fri, 04 Jan 2008 11:51:25 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAplT-0007gm-5v for ltru@ietf.org; Fri, 04 Jan 2008 11:51:25 -0500 Received: from [10.72.72.26] (snvvpn1-10-72-72-c26.corp.yahoo.com [10.72.72.26]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m04GpM98086742; Fri, 4 Jan 2008 08:51:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=VYhydpbu2o23ECmEVKXGyySQeUvuNxt3UNl66Ni4WTFMsslNQ6FTll5djCjOkByt Message-ID: <477E6409.5060300@yahoo-inc.com> Date: Fri, 04 Jan 2008 08:51:21 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Description on tags, not just subtags? References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> In-Reply-To: <005501c84eed$a0579850$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > In > http://www.alvestrand.no/pipermail/ietf-languages/2008-January/007279.html > I proposed using the Comments field for this purpose, to avoid > introducing a new mechanism that would probably be used by only a > handful of (cherry-picked) variations: > > Type: language > Subtag: gsw > Description: Swiss German > Description: Alemannic > Added: 2006-03-08 > Suppress-Script: Latn > Comment: gsw-FR represents the Alsatian dialect > I dislike this idea. We already have experience with it and its "unintended consequences". See: sign language tags. For that matter, we have ample experience with region subtags being imbued with artificial meaning. For a long time, "zh-TW" 'meant' Traditional Chinese, for example. Part of the reason behind this whole effort is to reduce the need to attach artificial meaning to subtags. This isn't to say that the tag "gsw-FR" doesn't encompass or "mean" the Alsatian dialect of Alemannic. It certainly encompasses Alsatian. But to start packing the registry with these sorts of comments (and the registration process with requests for same) strikes me as counter-productive to the point that I'd almost favor adding a MUST NOT to draft-4646bis. Guidance on tag formation should, incidentally and in my opinion, be in the form of external documentation (such as on Langtag.net, in CLDR, or via the W3C articles on same, just to name a few) or in an additional informational documents (possibly an Informational RFC). Burying tag choice information like this in the registry seems complicated and haphazard. 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 Jan 04 19:25:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwrN-0003XH-OD; Fri, 04 Jan 2008 19:25:57 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JAwrL-0003XB-Te for ltru-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 19:25:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwrL-0003X2-HR for ltru@ietf.org; Fri, 04 Jan 2008 19:25:55 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAwrK-0007Ph-SI for ltru@ietf.org; Fri, 04 Jan 2008 19:25:55 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nwZrO19A78kUoBjZ8Q7LZsRRhbxo+Mq7y1Xae25+R/qt7v5YbS/2K/hrDJDxqD8s; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.137.162] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JAwrJ-0001H5-US for ltru@ietf.org; Fri, 04 Jan 2008 19:25:54 -0500 Message-ID: <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> Subject: Re: [Ltru] Re: Description on tags, not just subtags? Date: Fri, 4 Jan 2008 16:29:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a3a477c06b87efe8def0e89786f287816350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.162 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Friday, January 04, 2008 8:51 AM > Subject: Re: [Ltru] Re: Description on tags, not just subtags? ... > > Comment: gsw-FR represents the Alsatian dialect > > > > I dislike this idea. We already have experience with it and its > "unintended consequences". See: sign language tags. > > For that matter, we have ample experience with region subtags being > imbued with artificial meaning. For a long time, "zh-TW" 'meant' > Traditional Chinese, for example. Part of the reason behind this whole > effort is to reduce the need to attach artificial meaning to subtags. > > This isn't to say that the tag "gsw-FR" doesn't encompass or "mean" the > Alsatian dialect of Alemannic. It certainly encompasses Alsatian. But to > start packing the registry with these sorts of comments (and the > registration process with requests for same) strikes me as > counter-productive to the point that I'd almost favor adding a MUST NOT > to draft-4646bis. > > Guidance on tag formation should, incidentally and in my opinion, be in > the form of external documentation (such as on Langtag.net, in CLDR, or > via the W3C articles on same, just to name a few) or in an additional > informational documents (possibly an Informational RFC). Burying tag > choice information like this in the registry seems complicated and > haphazard. ... There are multiple questions here. 1) Do we need to be explicit about the conditions under which a registration request would be considered to refer to something which can be clearly expressed with existing subtags? (That is, should a request for "alsation" be denied because it would mean precisely the same thing as "gsw-FR"? (I leave it to experts in this language to determine whether that is indeed the case.)) 2) There may be cases where the correct tag for a particular language may not be immediately obvious from the data in the registry. I can see several possible responses: a) attempt to add the information to the registry b) (as a WG) take on the effort of defining a repository for this information c) leave the documentation of such cases to others 3) Do we need to provide additional clarification of precisely what is meant by the use of a region subtag? The concept seems to be relatively fuzzy, encompassing both dialect and orthography. My own answers: (1) I think some additional clarification might be helpful, as the Alsation request shows. (2) I'm inclined to go along with (a), but only so far as to recognize that this would not be systematic or comprehensive by any stretch of the imagination. As soon as we had more than a handful of "Alsation" cases, my preference would shift to (c). (3) I think the fuzziness is a feature (meaning a bug a we can't fix). Getting rid of the fuzziness would require a re-architecting of language tagging in general, but this shouldn't come as a surprise to anyone who has waded through the discussions on scripts and modalities and orthographies and historical forms over the years. Consequently, I do not think we need additional clarification on this point. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 09:53:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtMA-0001FD-4u; Mon, 07 Jan 2008 09:53:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBtM9-0001Br-5U for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:53:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBtM8-0001AY-RW for ltru@ietf.org; Mon, 07 Jan 2008 09:53:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBsrc-0004Ur-G3 for ltru@ietf.org; Mon, 07 Jan 2008 09:22:04 -0500 Received: from mk-outboundfilter-3.mail.uk.tiscali.com ([212.74.114.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBsrb-0000C7-M9 for ltru@ietf.org; Mon, 07 Jan 2008 09:22:04 -0500 X-Trace: 13935120/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/195.137.85.17 X-SBRS: None X-RemoteIP: 195.137.85.17 X-IP-MAIL-FROM: contact@nickshanks.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJTEgUfDiVUR/2dsb2JhbAAIp2g Received: from home.nickshanks.com (HELO [192.168.1.17]) ([195.137.85.17]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/AES128-SHA; 07 Jan 2008 14:22:01 +0000 Message-Id: <99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com> From: Nicholas Shanks To: ltru@ietf.org In-Reply-To: <20080104195941.GE26881@mercury.ccil.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 7 Jan 2008 14:21:57 +0000 References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <20080104195941.GE26881@mercury.ccil.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d X-TMDA-Confirmed: Mon, 07 Jan 2008 09:53:36 -0500 Cc: Subject: [Ltru] =?windows-1252?q?Re=3A_Progressing_beyond_borders=97makin?= =?windows-1252?q?g_subtags_inclusive?= X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1547934815==" Errors-To: ltru-bounces@ietf.org --===============1547934815== Content-Type: multipart/signed; boundary=Apple-Mail-1-217702025; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-1-217702025 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Note: I haven't yet read most of the other replies to my email yet, =20 sorry if I overlap with what others have said. Also moved email to new =20= list per request from Mister Presuhn. On 4 Jan 2008, at 19:59, John Cowan wrote: > Nicholas Shanks scripsit: > >> the guy that submitted the scouse request has a vested >> interest in his own dialect, > > Actually not: I speak pure old classical East Coast American. Oh. I was pretty sure in my mind that the person who registered it =20 (who's name I could not recall) had referenced a dictionary that he =20 had authored himself, partly it had stuck in my mind, and this book =20 was published in the city of Liverpool, so I assumed he was from that =20= area too. I visited a website referred to by the registration and it =20 was all about why his accent was better than everyone else's and =20 seemed generally derogatory to non-scousers. It offended me. Maybe my =20= memory is playing tricks on me, in which case I apologise unreservedly. >> en-US represents a cluster of dialects and accents, with a unified >> orthography, and en-GB represents a cluster of accents and dialects >> (some overlapping with en-US), but a different orthography. Thus >> en-GB/US is pretty useless to people who are tagging audio data, >> but quite useful to those tagging written data. > > Although of course there are many individual isoglosses that cross the > Atlantic, I think you greatly overstate the case. My point was not that there are accents similar on both sides, but =20 more that there is no unified "en-US" accent, but there is a single en-=20= US orthography. Likewise for -GB. thus the country codes aren't a =20 precise way of identifying an accent, but are a precise way of =20 disambiguating dates and the meaning of words, especially potentially =20= upsetting ones like 'fanny'. > I don't think there are any U.K. varieties that even a half-trained =20= > person could mistake for > American ones, and certainly not vice versa. I agree >> I believe that having a subtag registered is at present too difficult >> (requirement for dictionaries!? what if it's mostly just an accent >> with only phonemic changes relative to surrounding accents). > > Dictionaries are not required; they are just an example of the kind > of documentation that's acceptable. We need to be sure, when we are > registering a tag, that it is not substantially identical with some > existing tag, that's all, so there must exist documentation of the > variety being tagged. This sounds like an "en-scots" vs. "sco" kind of debate. >> As an example, things like the supposedly "British English" speech >> synthesizer voices on my computer (which the OS processes using the >> tag "en_GB" from the voice's property list) sound nothing like most =20= >> of >> the accents of the United Kingdom, > > I doubt the en-US accent is much like the vast majority of U.S. =20 > speakers > nowadays either. precisely :) >> they would be better marked as "en-received" or similar. > > Register it, then. Okay. All in favo(u)r say "Aye". ;-) > If the document was tagged "en-US-dixie", then a synth with an "en-US" > voice (probably so-called General American) would at least get it > approximately right (assuming, that is, that it doesn't speak =20 > Hawkingese, > which sounds American to the English and pseudo-Swedish to the =20 > Americans). "Dixie" =97 I forgot what it was called! Didn't quite get whether you were agreeing or disagreeing with me here. What I was thinking was to allow content written with one orthography =20= be read by a voice designed for a different one. Some conversion could =20= happen e.g. if an american voice was reading aluminium it could drop =20 the penultimate syllable and move the stress, instead of trying to =20 pronounce it with a Gen. Am. accent. >> I'm sure we can all agree on commonly recognised dialects for =20 >> English, > > I wish I shared your certitude. Which ones would you suggest as being problematic? I suggested en-=20 scots above, though I can;t think of any more. I would have thought looking through the lexicon of a language and =20 seeing which accents/dialects/patois already have their own names =20 would be a good start. Am I wrong? - Nicholas.= --Apple-Mail-1-217702025 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLTCCAuYw ggJPoAMCAQICEGKqZrHuUP0yta79Nvpn/q4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyNDA4NDA1OFoXDTA4MTEyMzA4NDA1 OFowSDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWY29u dGFjdEBuaWNrc2hhbmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL5kw0vl ChNl7F/Hh7ktxu/eVUcWILoufdDLbBfzjRS/JujWyt4yYcuQo6p2nuivF3zncknuvMkSwyHBQMpG gbfaDNmiGQys2wWRZZYES8fHzC3driUVLhheXbtQiZFzrb2VqP7trkhs0dPhcHfj7YW1bvwUUCm9 XXxZ4kaM3WPTFJBDKFlMzdbIe9mKzrSCoIA8eOCkNuRlLgA6rA/K2eBozp95lkYrdL5MkgLoJ9G/ KL6rGIkk7cRk8QDnv0xQVWo25TdP6id1dq/effxGRTTAdt3Xoarr7+nHuE+R5OGgEYYe4xJaTNTJ +kcVwytfJhV84ksZwFvsGSvkLXB157ECAwEAAaMzMDEwIQYDVR0RBBowGIEWY29udGFjdEBuaWNr c2hhbmtzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABYqeMPReruBbl6mBzAJ 85r3PdVYHBNVrEt7wzsI1jUutUMHHbAJQS6V8V6syQK1d98bSUgHN33x+PwEM30d0u9qcAbJYD3Y B7jo5AkgKEWGDXWbfiEsBhHISUMc6fTRm+5WwoqM1VFrJhERsT5Q/nPdDA7Tqft3It9CYRoMgdx6 MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpU hQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxD QS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+q LZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBiqmax7lD9MrWu/Tb6Z/6uMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4 MDEwNzE0MjE1OFowIwYJKoZIhvcNAQkEMRYEFLlfiKk+tCfIYUv82CdaZRCY5JJpMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQYqpm se5Q/TK1rv02+mf+rjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQYqpmse5Q/TK1rv02+mf+rjANBgkqhkiG9w0BAQEFAASCAQBd hBmf6s6GuUqMEnV85vyqzD8/4mwE5kHWR+WQotFv0AzgBYKQ5vBQgJcPxelEbAvbvvnUK/ws2UnT ZwdsRyTiX9rNQUYoYbo7xOsdSGj/eM8+LrziI97yvXILX7Yi80LNyEFIY77l+oJr9+0e6Dlym2Hv /0sYaEy2WbgSmQth9oKenKau/U5GglGWW+lCLrlLDVDru6vfgKJwAlSg/bArrc2fGUOZ84g+cA/m kM1NThtu9b6tRIpO8qTqAsNd333lZN0pEv6CasnOS14sDVhcmDH7+LrmiQvSeaiObxK2VpH3Xfmn +zsJ5gZMIQhY7HjFERDpfWea8+/yOO9W7tq6AAAAAAAA --Apple-Mail-1-217702025-- --===============1547934815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1547934815==-- From ltru-bounces@ietf.org Mon Jan 07 10:02:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtUw-0001xa-SE; Mon, 07 Jan 2008 10:02:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBtUv-0001xE-8Y for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 10:02:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtUu-0001x6-Qk for ltru@ietf.org; Mon, 07 Jan 2008 10:02:40 -0500 Received: from mk-outboundfilter-4.mail.uk.tiscali.com ([212.74.114.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBtUt-00011l-RP for ltru@ietf.org; Mon, 07 Jan 2008 10:02:40 -0500 X-Trace: 8047987/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/195.137.85.17 X-SBRS: None X-RemoteIP: 195.137.85.17 X-IP-MAIL-FROM: contact@nickshanks.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADPOgUfDiVUR/2dsb2JhbAAIkV6WBg Received: from home.nickshanks.com (HELO [192.168.1.17]) ([195.137.85.17]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/AES128-SHA; 07 Jan 2008 15:02:38 +0000 Message-Id: <700092AE-4A06-4A67-A34F-65F2B91C0561@nickshanks.com> From: Nicholas Shanks To: ltru@ietf.org In-Reply-To: <003801c84f10$615b3ee0$6801a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v915) X-Priority: 3 Date: Mon, 7 Jan 2008 15:02:37 +0000 References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <003801c84f10$615b3ee0$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.3 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Subject: [Ltru] Re: Progressing beyond borders-making subtags inclusive X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1492133984==" Errors-To: ltru-bounces@ietf.org --===============1492133984== Content-Type: multipart/signed; boundary=Apple-Mail-3-220141742; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-3-220141742 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 4 Jan 2008, at 20:28, Randy Presuhn wrote: >> I say this because en-US represents a cluster of >> dialects and accents, with a unified orthography, and en-GB >> represents >> a cluster of accents and dialects (some overlapping with en-US), > > Could you give an example of such an overlap? The divergence in > pronunciation was already marked in the 1700s. I have personally noticed a lot of convergence is occurring here in the UK, with the large quantity of US sitcoms and music consumed. US speech patterns and pronunciations, especially when used in specific phrases, but also in the general patterns of speech. I don't believe it causes people to gradually start speaking with a different accent, but certainly can lead to blended speech in the young which differs from that of their parents. I have not looked for academic evidence for this though. >> I believe that having a subtag registered is at present too difficult >> (requirement for dictionaries!? what if it's mostly just an accent >> with only phonemic changes relative to surrounding accents). A >> relaxation of the barriers would lead to more de facto recognised >> dialects being available to choose from. > > I'm not able to figure out what you're trying to say here. I want to say "Here's some subtags for English that I think should be registered. Anyone disagree?" and just list them by name, using commonly understood terms that lay people wanting to use the tags will be able to identify with ease. By lay people I mean tens of millions of folks like my girlfriend, who wants to make a website about dolphins, and uses one of ov dem HMTL programs to do so. >> As an example, things like the supposedly "British English" speech >> synthesizer voices on my computer (which the OS processes using the >> tag "en_GB" from the voice's property list) sound nothing like most >> of >> the accents of the United Kingdom, they would be better marked as >> "en- >> received" or similar. > > This is not a tagging problem. It's a complaint about a speech > synthesizer I disagree here. It's not the synthesizer and/or website's fault that the palette of choices is so restricted. If those creating the voice were to have a wider choice of subtags, they could more accurately mark it up. The synth was just one example of electronic consumption of content. It may be a search engine or something as yet undreamt of. Age and the rural/urban split also have significant influences on language, though those are at present not dealt with. > and could be made for any language not tagged right > down to the level of some person's idiolect. Agreed. The line has to be drawn somewhere. I just think it's too course at present. We have the facility for creating 'approved' subtags without anything breaking. We might as well use it to the maximum :-) >> I'm sure we can all agree on commonly recognised dialects for >> English, > > I'd be surprised. The "cowboy" dialects spoken by my relatives in > South Dakota differ from what the ones in Wyoming speak, and > neither sounds much like Bush-speak. With variation seemingly on > the rise in US English, compiling an agreed list might be harder > than you think. Should have used 'dixie' as was pointed out, but as I am not familiar with US dialects in general I wouldn't be suggesting any :) >> as it is a first langauge for many people on this list, and familiar >> for many others. For other languages compiling a list might involve >> asking a scholar for suggestions. > > That's not how ietf-languages@iana.org is supposed to work. Okay. You referred to the mailing list. I was more referring to how the standard should be created. I presume there are people out there (and on these lists) who get paid to create these things. These people would conduct or locate relevant research and create a map, rather like a barometric or elevation map, with contours encircling different dialects. > Rather, someone (anyone) who has a need of a subtag for a > particular dialect submits a registration request, the request is > discussed, and the Language Subtag Reviewer decides whether > to accept the registration. The thing is most people using them in my field (web authors) have no idea this list exists, nor that they even have the need for a new subtag when they are creating new content. Quite often the tags are added without the author even knowing. The tags have to be created beforehand and given as options on a platter to these people by the software. If you expect users to register their own codes, would you like to see dialog boxes like this when people press 'save as HTML' ? Please choose the most appropriate language tag for this page: [ ] en English (language WizzoWebWhacker is running in) [ ] en-IE Hibernian English (taken from your time zone) [x] en-enteryourdialecthere (automatically sends a registration email to IETF) [Cancel] [Okay] (I write that only half in jest) >> It occurred to me while writing this that perhaps a good solution >> would be to use country codes for written content that uses the >> national orthography, and dialect tags when transcribing spoken >> content or for audio data. You would only combine the two if you were >> transcribing the speech of someone with that dialect into the >> orthography of a country (maybe not the country of the speaker). > > Interesting idea. Discussion of such a proposal belongs on ltru@ietf.org > , > not here. Moved. No comments on this? Obviously changes like this would have to be best practice suggestions, and not rules, for compatibility. - Nicholas. --Apple-Mail-3-220141742 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLTCCAuYw ggJPoAMCAQICEGKqZrHuUP0yta79Nvpn/q4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyNDA4NDA1OFoXDTA4MTEyMzA4NDA1 OFowSDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWY29u dGFjdEBuaWNrc2hhbmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL5kw0vl ChNl7F/Hh7ktxu/eVUcWILoufdDLbBfzjRS/JujWyt4yYcuQo6p2nuivF3zncknuvMkSwyHBQMpG gbfaDNmiGQys2wWRZZYES8fHzC3driUVLhheXbtQiZFzrb2VqP7trkhs0dPhcHfj7YW1bvwUUCm9 XXxZ4kaM3WPTFJBDKFlMzdbIe9mKzrSCoIA8eOCkNuRlLgA6rA/K2eBozp95lkYrdL5MkgLoJ9G/ KL6rGIkk7cRk8QDnv0xQVWo25TdP6id1dq/effxGRTTAdt3Xoarr7+nHuE+R5OGgEYYe4xJaTNTJ +kcVwytfJhV84ksZwFvsGSvkLXB157ECAwEAAaMzMDEwIQYDVR0RBBowGIEWY29udGFjdEBuaWNr c2hhbmtzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABYqeMPReruBbl6mBzAJ 85r3PdVYHBNVrEt7wzsI1jUutUMHHbAJQS6V8V6syQK1d98bSUgHN33x+PwEM30d0u9qcAbJYD3Y B7jo5AkgKEWGDXWbfiEsBhHISUMc6fTRm+5WwoqM1VFrJhERsT5Q/nPdDA7Tqft3It9CYRoMgdx6 MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpU hQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxD QS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+q LZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBiqmax7lD9MrWu/Tb6Z/6uMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4 MDEwNzE1MDIzN1owIwYJKoZIhvcNAQkEMRYEFE/8i63G9KgBAW/EdmzR7IAcgn+hMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQYqpm se5Q/TK1rv02+mf+rjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQYqpmse5Q/TK1rv02+mf+rjANBgkqhkiG9w0BAQEFAASCAQB6 v5ovZiDxbFvnKFb8eNJEOlY+YhrZSzc6ufJgG6hkkKk4muO7Ng1QEUUDeXVoSRQtTZ4m8lNzuBXB bN8rXt/FEX+8f8GV4RilDzrgkmsCH/oTKAzIK+Miq+cE1geCTfAL/Ye5yVLmC5iIG2/KYiRxqsH/ yjlFhxdCOh4LC2deqnSWfMsSF/VgvxZhESJOJ78tQqwrrY1RLdLASXJAmz8nOgMZJdOFdo5Zz5LC rnUxNx2dHW3zNniOFFwx5ijnL4JGYMss09clWlu0k1MOeGMVNtMTUsbTeszbsZLaI9prcoz0SBHm izY9cpTLPp8/lv7XXtcH1e2E3aY7zXAHBp26AAAAAAAA --Apple-Mail-3-220141742-- --===============1492133984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1492133984==-- From ltru-bounces@ietf.org Mon Jan 07 10:23:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtoX-0001j5-QL; Mon, 07 Jan 2008 10:22:57 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBtoW-0001aq-PC for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 10:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtoW-0001Zn-Es for ltru@ietf.org; Mon, 07 Jan 2008 10:22:56 -0500 Received: from mk-outboundfilter-3.mail.uk.tiscali.com ([212.74.114.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtoV-0007ue-HP for ltru@ietf.org; Mon, 07 Jan 2008 10:22:56 -0500 X-Trace: 13999806/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/195.137.85.17 X-SBRS: None X-RemoteIP: 195.137.85.17 X-IP-MAIL-FROM: contact@nickshanks.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKTSgUfDiVUR/2dsb2JhbAAIkV6WMg Received: from home.nickshanks.com (HELO [192.168.1.17]) ([195.137.85.17]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/AES128-SHA; 07 Jan 2008 15:22:54 +0000 Message-Id: <774BCF7F-4500-497E-95F1-F2C2003B1A80@nickshanks.com> From: Nicholas Shanks To: ltru@ietf.org In-Reply-To: <20080107074017.GA9068@laperouse.bortzmeyer.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 7 Jan 2008 15:22:53 +0000 References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <20080107074017.GA9068@laperouse.bortzmeyer.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: -0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Ltru] Re: Progressing beyond borders?making subtags inclusive X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0697497807==" Errors-To: ltru-bounces@ietf.org --===============0697497807== Content-Type: multipart/signed; boundary=Apple-Mail-4-221357824; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-4-221357824 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 7 Jan 2008, at 07:40, Stephane Bortzmeyer wrote: > This is a bad start for the discussion. If you call each proposal > "partizan", we will soon go to flame wars... Well that's why I want someone who can be seen to be impartial to go through and do them all! >> If I requested the registration of "alsatian" and not a general > registration of all alemannic dialects, it's because I know about this > dialect (or knows where to find information). Well you probably know enough about the others to decide how many there are and give them names. It will then be up to users to pick the closest/most appropriate for their use case. >> nobody has bothered to register the others. > > The IETF is volunteer work. Well the standards produced are used by corporations like Sony. Couldn't there be a clause that public companies contribute some nominal fee to get things looked after professionally? Do these standards not get adopted by the ISO, IEEE and W3C, all of whom have money? They could also pay someone to do a thorough job. >> I believe that having a subtag registered is at present too >> difficult > > I would partly agree (I wrote some of the texts on > http://www.langtag.net/ because I wanted to help registration > beginners) but only partly because registration of a subtag is a > serious matter (once a subtag, always a subtag, there is no way back) > and should not be done lightly. Thanks for the URL! I will go through the registration page and see if I can get many UK dialects of English officially sanctioned by the end of this. It looks very useful for pointing beginners and not-beginners- but-not-experts-either at. Thanks for creating this resource :-) >> I'm sure we can all agree on commonly recognised dialects for >> English, as it is a first langauge for many people on this list, and >> familiar for many others. > > I am not sure you properly assert the amount of work it > means. Perhaps not for some dialects, but surely every language has low- hanging fruit that all can agree on? Getting all of these would at least be a start. >> For other languages compiling a list might involve asking a scholar >> for suggestions. > > This would be a huge change from "Anyone can request a registration, > if he backs his request with serious facts" from "A committee playing > ISO-639, but without the resources of SIL". I'm note sure I would > approve it. But, anyway, this discussion belongs to the LTRU Working > Group. The SIL could help. Good idea :) - Nicholas. --Apple-Mail-4-221357824 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLTCCAuYw ggJPoAMCAQICEGKqZrHuUP0yta79Nvpn/q4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyNDA4NDA1OFoXDTA4MTEyMzA4NDA1 OFowSDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWY29u dGFjdEBuaWNrc2hhbmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL5kw0vl ChNl7F/Hh7ktxu/eVUcWILoufdDLbBfzjRS/JujWyt4yYcuQo6p2nuivF3zncknuvMkSwyHBQMpG gbfaDNmiGQys2wWRZZYES8fHzC3driUVLhheXbtQiZFzrb2VqP7trkhs0dPhcHfj7YW1bvwUUCm9 XXxZ4kaM3WPTFJBDKFlMzdbIe9mKzrSCoIA8eOCkNuRlLgA6rA/K2eBozp95lkYrdL5MkgLoJ9G/ KL6rGIkk7cRk8QDnv0xQVWo25TdP6id1dq/effxGRTTAdt3Xoarr7+nHuE+R5OGgEYYe4xJaTNTJ +kcVwytfJhV84ksZwFvsGSvkLXB157ECAwEAAaMzMDEwIQYDVR0RBBowGIEWY29udGFjdEBuaWNr c2hhbmtzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABYqeMPReruBbl6mBzAJ 85r3PdVYHBNVrEt7wzsI1jUutUMHHbAJQS6V8V6syQK1d98bSUgHN33x+PwEM30d0u9qcAbJYD3Y B7jo5AkgKEWGDXWbfiEsBhHISUMc6fTRm+5WwoqM1VFrJhERsT5Q/nPdDA7Tqft3It9CYRoMgdx6 MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpU hQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxD QS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+q LZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBiqmax7lD9MrWu/Tb6Z/6uMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4 MDEwNzE1MjI1M1owIwYJKoZIhvcNAQkEMRYEFLVg/xWxcm3o8K2pyjtP4YNSwnS9MIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQYqpm se5Q/TK1rv02+mf+rjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQYqpmse5Q/TK1rv02+mf+rjANBgkqhkiG9w0BAQEFAASCAQBS VT87iXMiE3qF+60J51a4LziV4ZQSxoyftvEJ+VXsbzpdhK369hS+JiYWpq5GCtkC0eIR8i+ke4vr s/T1Arsi8VhyBrsKWLrMPEh3SBlY9h25nki7M6GT44TITcT5S/gEAArSqnJLMfv3BatOjFeOICW0 d6L5Fp4Ty4Rg1Yk1nsgPyphH1RREfhO+L9xSlSqxT2pNcQhZP4ufLFoCKgSnlXwss82dcTePJh5M JRJGaL1vVj4Kl9CO5/Hvu2Kbx7ObCu0lF8pNfrGUFAAGXOWlfzIwHRq4CqrNyr/4m2ZFLBKZRH16 HI/3ISYZF3GBqICdn6kCiVRTIkFD73Ii315eAAAAAAAA --Apple-Mail-4-221357824-- --===============0697497807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0697497807==-- From ltru-bounces@ietf.org Mon Jan 07 10:36:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBu20-0001BV-RE; Mon, 07 Jan 2008 10:36:52 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBu20-0001BQ-8m for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 10:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBu1z-0001BI-VE for ltru@ietf.org; Mon, 07 Jan 2008 10:36:51 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBu1x-0008Ar-0G for ltru@ietf.org; Mon, 07 Jan 2008 10:36:51 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JBu1t-0000d1-GI; Mon, 07 Jan 2008 10:36:45 -0500 Date: Mon, 7 Jan 2008 10:36:45 -0500 To: Nicholas Shanks Message-ID: <20080107153645.GA27859@mercury.ccil.org> References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <20080104195941.GE26881@mercury.ccil.org> <99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.5 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: ltru@ietf.org Subject: [Ltru] Re: Progressing beyond =?utf-8?b?Ym9yZGVyc++/vT8/bWFraW5n?= subtags inclusive X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicholas Shanks scripsit: > Oh. I was pretty sure in my mind that the person who registered it > (who's name I could not recall) had referenced a dictionary that he > had authored himself, partly it had stuck in my mind, and this book > was published in the city of Liverpool, so I assumed he was from that > area too. I visited a website referred to by the registration and it > was all about why his accent was better than everyone else's and > seemed generally derogatory to non-scousers. It offended me. Maybe my > memory is playing tricks on me, in which case I apologise unreservedly. No problem. Both Stan Kelly-Bootle and I are Olde Hacqueres these days (born in 1929 and 1958 respectively), but we are quite distinct. For example, while we both have written folk songs, his have actually been performed by singers of note, whereas mine have been sung only by myself. His book on Scouse is in its sixteenth edition, whereas my book on Lojban is still mired between its first and second edition, without much prospect of progress. He was awarded the first Diploma in Computer Science from Cambridge University, whereas I have no degrees at all. There are many other such points. As for Kelly-Bootle's alleged belief in the superiority of his own accent: given his known and evil sense of humor, I diffidently suggest that he was taking the Minnie out of you, as I believe y'all say in Rightpondia. ("The English-speaking nations are Rightpondia and Begrudgeria in Europe, Leftpondia and Northicia (pronounced with four syllables) in America, Bharattia in Asia, Sarfeffrica and Cecilia (now called Zimbabwe) in Africa, and Downundria and Aotearoa in Oceania. Rightpondia may further be divided into the four sub-nations of Londonia, Eboracia, Bagpipia, and Quaint." -- me) > This sounds like an "en-scots" vs. "sco" kind of debate. A fine example of why trying to make firm decisions about dialects is a tricky business. > >>they would be better marked as "en-received" or similar. > > > >Register it, then. > > Okay. All in favo(u)r say "Aye". ;-) Not so fast. You have to follow the RFC 4646 procedures, and do it back on ietf-languages. > Didn't quite get whether you were agreeing or disagreeing with me here. > What I was thinking was to allow content written with one orthography > be read by a voice designed for a different one. Some conversion could > happen e.g. if an american voice was reading aluminium it could drop > the penultimate syllable and move the stress, instead of trying to > pronounce it with a Gen. Am. accent. Quite. I was addressing your point that "en-dixie" is superior to "en-US-dixie" by pointing out that on the contrary the latter has better default fallback properties. A synthesizer that can recognize the "en-US" part can produce at least some American voice, whereas with "en-dixie" it will probably produce its default "en", which may or may not be American. > Which ones would you suggest as being problematic? I suggested en- > scots above, though I can;t think of any more. (I believe we settled on "en-scotland".) The difficulty is to know where to stop. For example, the American South is a fairly well-defined dialect area, but how many dialects does it contain? There is the centuries-old distinction between the northern and the southern portions, and a more recent split (of the last fifty years or so) between the inland and coastal parts of the latter. But much finer subdivision can be and has been done when necessary and appropriate. ietf-languages has therefore always taken an agnostic approach, waiting for people to declare their actual needs rather than trying to impose a particular systematism on the data ("en-scouse" and "en-boont" were in the way of test cases rather than ones required by my personal needs). > I would have thought looking through the lexicon of a language and > seeing which accents/dialects/patois already have their own names > would be a good start. Am I wrong? It isn't very reliable, as dialects often don't become popularly visible for a long time after they are tenaciously established. For example, the "Northern Cities" accent of en-us is a matter of the last fifty years or so, like the Inland South I mentioned above, yet very few Americans, *including the speakers*, are even aware of its existence. Yet it is radically different phonologically, having massive differences in the short vowels as great as (but not the same as) traditional Cockney, Australian, or New Zealander. Only when specific instances arise, as when a boy moved "Ian" newly named to the region is teased because his peers hear his name as "Ann", does any awareness of a dialect spoken by millions of people in the U.S. come to the surface. (The U.S. isn't the only place with new dialects; Scouse only arose in 19th century, when the Liverpool's original dialect became heavily mixed with Hiberno-English.) [from another email] > I have personally noticed a lot of convergence is occurring here in > the UK, with the large quantity of US sitcoms and music consumed. US > speech patterns and pronunciations, especially when used in specific > phrases, but also in the general patterns of speech. I don't believe > it causes people to gradually start speaking with a different accent, > but certainly can lead to blended speech in the young which differs > from that of their parents. I have not looked for academic evidence > for this though. Quite right: convergence is going on. But divergence is too. > I want to say "Here's some subtags for English that I think should be > registered. Anyone disagree?" and just list them by name, using > commonly understood terms that lay people wanting to use the tags will > be able to identify with ease. Unfortunately, counterexamples like Northern Cities make that impossible -- it unquestionably exists, but most people haven't heard of it. > Agreed. The line has to be drawn somewhere. I just think it's too > course at present. We have the facility for creating 'approved' > subtags without anything breaking. We might as well use it to the > maximum :-) To, but not beyond. Waiting (for the most part) for actual need rather than pre-registering en masse is an attempt to avoid such false positives, particularly since "once registered, always registered". > I presume there are people out there (and on these lists) who get paid > to create these things. These people would conduct or locate relevant > research and create a map, rather like a barometric or elevation map, > with contours encircling different dialects. Things are not so cut and dried, not even at the level of languages. We have (for better and worse) adopted ISO 639-3, which is a splitter among language taxonomies -- that is, it is much more likely to call a difference between varieties a language rather than a dialect difference than other taxonomies are. What's left we have to work our way through carefully. > The thing is most people using them in my field (web authors) have no > idea this list exists, nor that they even have the need for a new > subtag when they are creating new content. Quite often the tags are > added without the author even knowing. Indeed, search engines are known to entirely discard all "en" tags, as they are applied by broken software to texts in entirely different languages so often as to be worthless. Fortunately, authorial tagging of random Web documents is not the only BCP 47 application. > The tags have to be created beforehand and given as options on a > platter to these people by the software. True, which means it waits until some volunteer armed with sufficient knowledge, documentation, and dedication steps forward (whether the volunteer is paid by someone else to do it is not a consideration in the IETF). Fortunately, even a little accurate tagging goes a long way. > Moved. No comments on this? Obviously changes like this would have to > be best practice suggestions, and not rules, for compatibility. We do have similar remarks in the current RFC 4646bis draft. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 10:54:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuIv-000406-4t; Mon, 07 Jan 2008 10:54:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBuIu-0003ze-Ob for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 10:54:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuIu-0003zW-EK for ltru@ietf.org; Mon, 07 Jan 2008 10:54:20 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBuIu-0002J9-4K for ltru@ietf.org; Mon, 07 Jan 2008 10:54:20 -0500 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.1.222.3; Mon, 7 Jan 2008 07:54:19 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Mon, 7 Jan 2008 07:54:19 -0800 From: Peter Constable To: "ltru@ietf.org" Date: Mon, 7 Jan 2008 07:54:08 -0800 Subject: RE: [Ltru] Re: Progressing beyond borders-making subtags inclusive Thread-Topic: [Ltru] Re: Progressing beyond borders-making subtags inclusive Thread-Index: AchRPl2mLDNiFttXSIy1XYBZAjPMTQABnd8A Message-ID: References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <003801c84f10$615b3ee0$6801a8c0@oemcomputer> <700092AE-4A06-4A67-A34F-65F2B91C0561@nickshanks.com> In-Reply-To: <700092AE-4A06-4A67-A34F-65F2B91C0561@nickshanks.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: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Nicholas Shanks [mailto:contact@nickshanks.com] > I disagree here. It's not the synthesizer and/or website's fault that > the palette of choices is so restricted. If those creating the voice > were to have a wider choice of subtags, they could more accurately mark > it up. Trying to come up with a universal inventory of dialect tags is the wrong a= pproach. If the developers of the synthesizer are simply missing the right = dialect tag, then they should register it. IMO, the correct approach to dia= lect sub-tags is to let them be registered as individual needs are identifi= ed. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 12:43:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw0d-0006Kg-Vj; Mon, 07 Jan 2008 12:43:35 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBw0d-0006FX-3E for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:43:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw0c-0006FI-Mr for ltru@ietf.org; Mon, 07 Jan 2008 12:43:34 -0500 Received: from mk-outboundfilter-4.mail.uk.tiscali.com ([212.74.114.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBw0b-000094-Kd for ltru@ietf.org; Mon, 07 Jan 2008 12:43:34 -0500 X-Trace: 8179044/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/195.137.85.17 X-SBRS: None X-RemoteIP: 195.137.85.17 X-IP-MAIL-FROM: contact@nickshanks.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOvzgUfDiVUR/2dsb2JhbAAIkV6WPg Received: from home.nickshanks.com (HELO [192.168.1.17]) ([195.137.85.17]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/AES128-SHA; 07 Jan 2008 17:43:32 +0000 Message-Id: <22F2281F-688C-433A-93DC-5C84F0C9BBB4@nickshanks.com> From: Nicholas Shanks To: ltru@ietf.org In-Reply-To: <20080107153645.GA27859@mercury.ccil.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 7 Jan 2008 17:43:31 +0000 References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com> <20080104195941.GE26881@mercury.ccil.org> <99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com> <20080107153645.GA27859@mercury.ccil.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Subject: [Ltru] =?windows-1252?q?Re=3A_Progressing_beyond_borders=97makin?= =?windows-1252?q?g_subtags_inclusive?= X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1434710160==" Errors-To: ltru-bounces@ietf.org --===============1434710160== Content-Type: multipart/signed; boundary=Apple-Mail-6-229795738; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-6-229795738 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 7 Jan 2008, at 15:36, John Cowan wrote: > As for Kelly-Bootle's alleged belief in the superiority of his own > accent: > given his known and evil sense of humor, I diffidently suggest that he > was taking the Minnie out of you, as I believe y'all say in > Rightpondia. My father says "extracting the Michael" ;-) > ("The English-speaking nations are Rightpondia and Begrudgeria in > Europe, > Leftpondia and Northicia (pronounced with four syllables) in America, > Bharattia in Asia, Sarfeffrica and Cecilia (now called Zimbabwe) in > Africa, and Downundria and Aotearoa in Oceania. Rightpondia may > further > be divided into the four sub-nations of Londonia, Eboracia, Bagpipia, > and Quaint." -- me) You now have me thoroughly befuddled. How can Northicia be pronounced with anything other than four syllables? I would have thought you'd use http://en.wikipedia.org/wiki/Londonistan >> Okay. All in favo(u)r say "Aye". ;-) > > Not so fast. You have to follow the RFC 4646 procedures, and do it > back > on ietf-languages. So that one is just for proposals and ensuing stick-beating, and this one is for general chit-chat? >> Didn't quite get whether you were agreeing or disagreeing with me >> here. >> What I was thinking was to allow content written with one orthography >> be read by a voice designed for a different one. Some conversion >> could >> happen e.g. if an american voice was reading aluminium it could drop >> the penultimate syllable and move the stress, instead of trying to >> pronounce it with a Gen. Am. accent. > > Quite. I was addressing your point that "en-dixie" is superior to > "en-US-dixie" by pointing out that on the contrary the latter has > better default fallback properties. You're right. I think I was getting a bit muddled with my original email because I kept going back and forth within it changing things. I prefer en-US-dixie for fallback reasons, unless that orthography suggestion were to come into play, in which case "en-GB-dixie" would be representing a Southerner transcribed into British English (or maybe an expat Southerner come to live in Blighty) > A synthesizer that can > recognize the "en-US" part can produce at least some American voice, > whereas with "en-dixie" it will probably produce its default "en", > which may or may not be American. Things processing accents would need to know that it can drop the country code too. Foe example en-scouse and en-GB-scouse both represent the same thing. (yes, I know the second isn't technically registered, but people will still use those kinds of constructs because they don't know any better). Same with en-GB-oed. > The difficulty is to know where to stop. I suggested just having those dialects that have names in the general lexicon of speakers of the host language. Specific needs can continue to be catered for by individual requests. > waiting > for people to declare their actual needs rather than trying to > impose a > particular systematism on the data ("en-scouse" and "en-boont" were in > the way of test cases rather than ones required by my personal needs). I have absolutely no idea who a boont is :) >> I want to say "Here's some subtags for English that I think should be >> registered. Anyone disagree?" and just list them by name, using >> commonly understood terms that lay people wanting to use the tags >> will >> be able to identify with ease. > > Unfortunately, counterexamples like Northern Cities make that > impossible -- > it unquestionably exists, but most people haven't heard of it. People don't have to see the actual tag, or know what it's called. They could simply pick "New England (Wash./NYC/Boston)" from a list, and the software would put in the right tag, if that's the level of granularity available. > To, but not beyond. Waiting (for the most part) for actual need > rather than pre-registering en masse is an attempt to avoid such > false positives, particularly since "once registered, always > registered". Many of the tags already registered will become obsolete in a few centuries anyway. Unless you have two tags that denote the same dialect. False positives can have notes added saying "This has been reclassified as being xx- foobar. Use that tag instead." and it reduced to the role of synonym. There are already many tags floating around that are made up (see how widespread "en-cockney" has become after being used as an example for the Content-Language HTTP header). I don't think registering them all and categorising some as synonyms of others is all that problematic, indeed it removes ambiguity of having to process an unregistered tag. >> The thing is most people using them in my field (web authors) have no >> idea this list exists, nor that they even have the need for a new >> subtag when they are creating new content. Quite often the tags are >> added without the author even knowing. > > Indeed, search engines are known to entirely discard all "en" tags, > as they are applied by broken software to texts in entirely different > languages so often as to be worthless. Fortunately, authorial tagging > of random Web documents is not the only BCP 47 application. It is the one I care most about, however. The other being how my OS uses them to do various stuff. For example, if I set my locale to en_DE so that I get the Euro currency symbol by default, and the right Summer/Winter Time dates, VLC comes up in German (i.e. that particular software ignores the language code and changes it's language based on the country code!). I already mentioned it's use by the TTS system. >> The tags have to be created beforehand and given as options on a >> platter to these people by the software. > > True, which means it waits until some volunteer armed with sufficient > knowledge, documentation, and dedication steps forward (whether the > volunteer is paid by someone else to do it is not a consideration in > the IETF). Fortunately, even a little accurate tagging goes a long > way. I guess that means me, right? Okay, so here's a list of 'named' British accents that I can think of. Please add/remove from this list and when it reaches stability I will try and find some documentation for each one so it can get added. I tried to go one level down from en-GB and en-IE without getting too picky. Class-based accents: received (pronunciation) Geographically-based accents: wales scotland ireland (aka hiberno; to cover both North and South, whereas a cc can't) cockney estuary brummie (inc. black country) scouse mancunian yorkshire (tyke; all ridings) geordie (inc. maccam) Age-based orthographies: txtspk Fictional English which might occur: newspeak Some of the above cribbed from http://en.wikipedia.org/wiki/List_of_dialects_of_the_English_language - Nicholas. --Apple-Mail-6-229795738 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLTCCAuYw ggJPoAMCAQICEGKqZrHuUP0yta79Nvpn/q4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyNDA4NDA1OFoXDTA4MTEyMzA4NDA1 OFowSDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWY29u dGFjdEBuaWNrc2hhbmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL5kw0vl ChNl7F/Hh7ktxu/eVUcWILoufdDLbBfzjRS/JujWyt4yYcuQo6p2nuivF3zncknuvMkSwyHBQMpG gbfaDNmiGQys2wWRZZYES8fHzC3driUVLhheXbtQiZFzrb2VqP7trkhs0dPhcHfj7YW1bvwUUCm9 XXxZ4kaM3WPTFJBDKFlMzdbIe9mKzrSCoIA8eOCkNuRlLgA6rA/K2eBozp95lkYrdL5MkgLoJ9G/ KL6rGIkk7cRk8QDnv0xQVWo25TdP6id1dq/effxGRTTAdt3Xoarr7+nHuE+R5OGgEYYe4xJaTNTJ +kcVwytfJhV84ksZwFvsGSvkLXB157ECAwEAAaMzMDEwIQYDVR0RBBowGIEWY29udGFjdEBuaWNr c2hhbmtzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABYqeMPReruBbl6mBzAJ 85r3PdVYHBNVrEt7wzsI1jUutUMHHbAJQS6V8V6syQK1d98bSUgHN33x+PwEM30d0u9qcAbJYD3Y B7jo5AkgKEWGDXWbfiEsBhHISUMc6fTRm+5WwoqM1VFrJhERsT5Q/nPdDA7Tqft3It9CYRoMgdx6 MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpU hQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxD QS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+q LZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBiqmax7lD9MrWu/Tb6Z/6uMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4 MDEwNzE3NDMzMVowIwYJKoZIhvcNAQkEMRYEFDd0KSdcejdNLGzRWIJguXSWOToaMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQYqpm se5Q/TK1rv02+mf+rjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQYqpmse5Q/TK1rv02+mf+rjANBgkqhkiG9w0BAQEFAASCAQC1 3qfrmgMhtWvwRLIChbmOTVACNJMeuYTDuxWlVorTFTvKsy8i06R+5iQDUtOXeHoH1ppSJR3UHoaj g9ztzrPTIb8kjMLmExWxufYfH8u/oZDJE7hLQf/Po6piywNhW5BlokwdrU+YovHg3yIrRJi1nI97 8p0psGPIKDebEAPIboxNboXsoidGR2eHOFRZBe89ehm9lHT+zFpW7vJpU8uSCPV3zR1ugW45a1CJ bgddD+q1KUU2yVdc+QjAMga2b1vgZ8F8NQAlaeXZ/qEfiAo7oyR4asY8wO22CcE7igmU7KYRCpta 9kRn91XTUwgdSMgTnTytneQ0kZMy0CqIFl4gAAAAAAAA --Apple-Mail-6-229795738-- --===============1434710160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1434710160==-- From ltru-bounces@ietf.org Mon Jan 07 14:24:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxag-0003Xl-9B; Mon, 07 Jan 2008 14:24:54 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBxae-0003Xf-FG for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 14:24:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxae-0003XX-3N for ltru@ietf.org; Mon, 07 Jan 2008 14:24:52 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBxad-0004Pk-Dd for ltru@ietf.org; Mon, 07 Jan 2008 14:24:52 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X8QaMGGxjnuWZmCmbl8xsMeuC2tJJZHSBn3NOsptvkFQEFRubKgCBFVpIKMuIwlZ; 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.94] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JBxaa-0007s5-F7 for ltru@ietf.org; Mon, 07 Jan 2008 14:24:48 -0500 Message-ID: <007d01c85163$216776a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com><20080104195941.GE26881@mercury.ccil.org><99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com><20080107153645.GA27859@mercury.ccil.org> <22F2281F-688C-433A-93DC-5C84F0C9BBB4@nickshanks.com> Subject: =?iso-8859-1?Q?Re:_=5BLtru=5D_Re:_Progressing_beyond_borders-making_subta?= =?iso-8859-1?Q?gs_inclusive?= Date: Mon, 7 Jan 2008 11:25:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31abcf3879d97ec54d1e83626b10a1bb4fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.94 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Nicholas Shanks" > To: > Sent: Monday, January 07, 2008 9:43 AM > Subject: [Ltru] Re: Progressing beyond borders-making subtags inclusive ... > You now have me thoroughly befuddled. How can Northicia be pronounced > with anything other than four syllables? I would have thought you'd > use http://en.wikipedia.org/wiki/Londonistan In my accent the sequence -icia is normally pronounced the same as the sequence -isha. Two syllables. I had to think about the "four syllables" a bit, and still am unsure whether the "c" would be an "s" or "sh" or possibly "ch" or "ts". > > Not so fast. You have to follow the RFC 4646 procedures, and do it > > back > > on ietf-languages. > > So that one is just for proposals and ensuing stick-beating, and this > one is for general chit-chat? ietf-languages@iana.org is for specific registration requests. Talk about what the procedures or syntax should be (not "general chit-chat") belongs on ltru@ietf.org .... > > The difficulty is to know where to stop. > > I suggested just having those dialects that have names in the general > lexicon of speakers of the host language. Specific needs can continue > to be catered for by individual requests. A couple of obstacles exist to using this kind of approach: (1) there are *lots* of languages out there, and the folks on ietf-languages@ietf.org probably do not have that level of expertise in most of them, and must thus rely on others to determine whether there is a need to tag a particular distinction. (2) the names and distinctions observed in the general lexicon of the speakers of a host language are at best only a starting point. For example, my brother and sister have clearly different accents. An untrained native speaker from the region might say "South Dakota cowboy" and "rural Minnesota". A dialectologist would use different terms, and for some purposes might choose to lump them together (as does the Wikipedia article you cited), since there are some common features, even though anyone from the region will tell they're different. (3) How does one decide that one has gathered an adequate set for a particular language? It could easily be misunderstood as "endorsing" or "recognizing" a particular set of dialects, potentially politicizing work. > > Unfortunately, counterexamples like Northern Cities make that > > impossible -- > > it unquestionably exists, but most people haven't heard of it. > > People don't have to see the actual tag, or know what it's called. > They could simply pick "New England (Wash./NYC/Boston)" from a list, > and the software would put in the right tag, if that's the level of > granularity available. The philosophy has been to not try to second-guess the level of granularity needed. For example, I'd be quite amazed to find Washington lumped in with the accents of New England. There are historically several different accents associated with Boston, and one can still hear them in use. My expectation as a user of a tool that was able to distinguish Washington and New York City forms of speech would be that it would distinguish the various accents of Boston, since the differences are at least as great. But the point is that we don't have the resources to do this, in advance of any stated need, for all the dialects of all the languages in the registry. ... > It is the one I care most about, however. The other being how my OS > uses them to do various stuff. For example, if I set my locale to > en_DE so that I get the Euro currency symbol by default, and the right > Summer/Winter Time dates, VLC comes up in German (i.e. that particular > software ignores the language code and changes it's language based on > the country code!). I already mentioned it's use by the TTS system. Let's not confuse locales with language tags, despite the fact that some strings are would be well-formed in either role. .... > > True, which means it waits until some volunteer armed with sufficient > > knowledge, documentation, and dedication steps forward (whether the > > volunteer is paid by someone else to do it is not a consideration in > > the IETF). Fortunately, even a little accurate tagging goes a long > > way. > > I guess that means me, right? > Okay, so here's a list of 'named' British accents that I can think of. > Please add/remove from this list and when it reaches stability I will > try and find some documentation for each one so it can get added. I > tried to go one level down from en-GB and en-IE without getting too > picky. As co-chair: Now, registration requests for specific subtags belong on ietf-languages@iana.org General principles here, specific cases there. I'm inclined to tolerate discussion of such a list ere only to the extent that it helps the WG decide whether it would make sense to change the existing modus operandi with respect to subtags for dialects. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 15:44:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBypG-0007hL-HR; Mon, 07 Jan 2008 15:44:02 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBypF-0007b2-7T for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 15:44:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBypE-0007at-Tr for ltru@ietf.org; Mon, 07 Jan 2008 15:44:00 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBypE-000066-IL for ltru@ietf.org; Mon, 07 Jan 2008 15:44:00 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JBypE-0003qk-49; Mon, 07 Jan 2008 15:44:00 -0500 Date: Mon, 7 Jan 2008 15:44:00 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: Progressing beyond borders-making subtags inclusive Message-ID: <20080107204400.GE24108@mercury.ccil.org> References: <22F2281F-688C-433A-93DC-5C84F0C9BBB4@nickshanks.com> <007d01c85163$216776a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007d01c85163$216776a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cowan@ccil.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Off-topic post; I've set Reply-To to me.] Randy Presuhn scripsit: > In my accent the sequence -icia is normally pronounced the same as the > sequence -isha. Two syllables. I had to think about the "four syllables" > a bit, and still am unsure whether the "c" would be an "s" or "sh" or > possibly "ch" or "ts". An "s"; the intention was North-Icy-a. The other jokes will be explained off-list to enquirers. > But the point is that we don't have the resources to do this, > in advance of any stated need, for all the dialects of all the languages in the > registry. Indeed. Some say the world will end in fire, Some say in ice. From what I've tasted of desire I hold with those who favor fire. But if it had to perish twice, I think I know enough of hate To know that for destruction ice Is also great And would suffice. --Robert Frost (1920) -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 16:00:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBz5Q-0000FD-QO; Mon, 07 Jan 2008 16:00:44 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JBz5P-0000F8-NM for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 16:00:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBz5P-0000F0-CH for ltru@ietf.org; Mon, 07 Jan 2008 16:00:43 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBz5P-0006xt-0b for ltru@ietf.org; Mon, 07 Jan 2008 16:00:43 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 7 Jan 2008 13:00:41 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon, 7 Jan 2008 13:00:41 -0800 From: Peter Constable To: LTRU Working Group Date: Mon, 7 Jan 2008 13:00:37 -0800 Subject: RE: [Ltru] Re: Progressing beyond borders-making subtags inclusive Thread-Topic: [Ltru] Re: Progressing beyond borders-making subtags inclusive Thread-Index: AchRYwEWGn5ymImLTMWIYJooF2r1bQADI/Kg Message-ID: References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com><20080104195941.GE26881@mercury.ccil.org><99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com><20080107153645.GA27859@mercury.ccil.org> <22F2281F-688C-433A-93DC-5C84F0C9BBB4@nickshanks.com> <007d01c85163$216776a0$6801a8c0@oemcomputer> In-Reply-To: <007d01c85163$216776a0$6801a8c0@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: 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 > From: Randy Presuhn > > I suggested just having those dialects that have names in the general > > lexicon of speakers of the host language. Specific needs can continue > > to be catered for by individual requests. > > A couple of obstacles exist to using this kind of approach: > > (1) there are *lots* of languages out there... > (2) the names and distinctions observed in the general lexicon of > the speakers of a host language are at best only a starting > point... +1 on both points. Even if there weren't lots of languages, there is no one= convention for tiling the plane of dialects. (It's hard enough to agree on= tiling the plane of languages.) With some many individual axes of variatio= n, dialect variation in the wild can sometimes amount to idiolects as point= s in a nearly-continuous field. There's no need for dialect sub-tags unless= there is a conventionally-recognized distinction that is a useful distinct= ion to make in language resources. Again, I think the best approach is to r= egister those on a case-by-case basis as needs are identified. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 17:42:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0gB-0005PT-AE; Mon, 07 Jan 2008 17:42:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC0g9-00051s-IU for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:42:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0g9-0004xg-5j for ltru@lists.ietf.org; Mon, 07 Jan 2008 17:42:45 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0g7-0002ID-HD for ltru@lists.ietf.org; Mon, 07 Jan 2008 17:42:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JC0g4-00073j-H6 for ltru@lists.ietf.org; Mon, 07 Jan 2008 22:42:40 +0000 Received: from c-180-160-123.hh.dial.de.ignite.net ([62.180.160.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jan 2008 22:42:40 +0000 Received: from nobody by c-180-160-123.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jan 2008 22:42:40 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 7 Jan 2008 23:42:51 +0100 Organization: Lines: 19 Message-ID: References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-123.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I dislike this idea. +1 Comments should be reserved for exceptional cases, e.g. the new "mis" description is far better than to amend the old description with a comment. =20 Using comments as "search engine optimization" is a dubious idea, registering alsatian is fine. =20 > I'd almost favor adding a MUST NOT to draft-4646bis. No, let the subtag review list decide what they do with comments. We should make clear in 4646bis that creative (ab)uses of region codes to emulate missing variants are at best that, emulations. =20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 18:46:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1gB-00047f-0X; Mon, 07 Jan 2008 18:46:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC1g9-00047W-P2 for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 18:46:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1g9-00047O-9X for ltru@lists.ietf.org; Mon, 07 Jan 2008 18:46:49 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC1g8-0003Bb-DF for ltru@lists.ietf.org; Mon, 07 Jan 2008 18:46:49 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 7 Jan 2008 15:46:47 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Mon, 7 Jan 2008 15:46:47 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Mon, 7 Jan 2008 15:46:43 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: Acgyn94y8HERwju4QjmIYjgxIMoq3AAAfMGwB7lMpMA= Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> <30b660a20711290752l1461e009h53dce8c0244962cd@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 MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1345573535==" Errors-To: ltru-bounces@ietf.org --===============1345573535== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1723NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1723NAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXBkYXRlIG9uIHRoaXM6IEnigJl2ZSBnb3QgYWdyZWVtZW50IGluIHByaW5jaXBsZSBmcm9tIExP QyB0byBjaGFuZ2UgZW50cmllcyBvZiB0aGUgZm9ybSDigJxGb28gKE90aGVyKeKAnSB0byDigJxG b28gbGFuZ3VhZ2Vz4oCdIGluIElTTyA2MzktMi4gSW4gZG9pbmcgdGhpcywgdGhleSB3YW50IHRv IHByb3ZpZGUgc29tZSBpbmZvIGFzIHRvIHdoaWNoIGluZGl2aWR1YWwtbGFuZ3VhZ2UgZW50cmll cyBpbiA2MzktMiBhcmUgZW5jb21wYXNzZWQgd2l0aGluIGVhY2ggY29sbGVjdGlvbiBzbyB0aGF0 IGFwcGxpY2F0aW9ucyBjYW4gZGVyaXZlIOKAnG90aGVy4oCdIGdyb3VwcyBpZiB0aGF04oCZcyBo b3cgdGhleSB3YW50IHRvIHVzZSB0aGVtLiBTbywgSeKAmW0gbm90IHN1cmUganVzdCBob3cgcXVp Y2tseSB0aGF0IGNoYW5nZSB3aWxsIGFwcGVhciBpbiB0aGUgY29kZSB0YWJsZXMgb24gdGhlIDYz OS0yIHNpdGUuIChJIHdvdWxkbuKAmXQgZXhwZWN0IHRvIHNlZSBhIGNoYW5nZSBvbiB0aGUgNjM5 LTMgc2l0ZSB1bnRpbCB0aGF0IGhhcyBjaGFuZ2VkIG9uIHRoZSA2MzktMiBzaXRlLikNCg0KDQpQ ZXRlcg0KDQpGcm9tOiBQZXRlciBDb25zdGFibGUgW21haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQu Y29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDA3IDg6MTMgQU0NClRvOiBsdHJ1 QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBhY3Rpb24gaXRlbTogIm90 aGVyIiBjb2xsZWN0aW9ucyBpbiA2MzkNCg0KTGV0IG1lIGNsYXJpZnkgdGhpcyBzdWItdGhyZWFk OiBJIGhhdmUgcXVlc3Rpb25lZCBpbiB0aGUgcGFzdCB3aGV0aGVyIGxhbmd1YWdlIGNvbGxlY3Rp b24gSUQgb2YgYW55IGtpbmQgYXJlIHVzZWZ1bCBpbiBJRVRGIGxhbmd1YWdlIHRhZ3MuIFdoZW5l dmVyIEkgbWFkZSB0aGF0IHN1Z2dlc3Rpb24sIHRoZXJlIHdlcmUgb3RoZXJzIGhlcmUgaW5zaXN0 aW5nIHRoYXQgdGhleSB3YW50ZWQgdGhlbSBrZXB0Lg0KDQpJIGFtIG5vdCBwcm9wb3NpbmcgYW55 IGNoYW5nZSBpbiB0aGlzIHJlZ2FyZCBhdCB0aGlzIHRpbWUuIFRoaXMgb25seSBjYW1lIHVwIGJl Y2F1c2UgSSBoYWQgcG9vcmx5IHdvcmRlZCBteSBzdGF0ZW1lbnQgYWJvdXQgZ2V0dGluZyByaWQg b2Yg4oCcKE90aGVyKeKAnSBmcm9tIGxhbmd1YWdlLWNvbGxlY3Rpb24gbmFtZXMsIGFuZCBEb3Vn IHRob3VnaHQgSSB3YXMgc3VnZ2VzdGluZyB0aGF0IElTTyA2Mzkg4oCcd2l0aGRyYXfigJ0gdGhv c2UgZW50cmllcyDigJMgSSB3YXMgbm90IHN1Z2dlc3RpbmcgdGhhdC4NCg0KTGV0IG1lIGNsYXJp Znkgd2hhdCBjaGFuZ2UgSSBhbSBwdXJzdWluZzogSSBhbSBhc2tpbmcgdGhlIEpBQyB0byByZW1v dmUg4oCcKE90aGVyKeKAnSBmcm9tIHRoZSBuYW1lcyBvZiBsYW5ndWFnZS1jb2xsZWN0aW9uIGVu dHJpZXMgdGhhdCBjdXJyZW50bHkgY29udGFpbiB0aGF0IHN0cmluZy4gVGhhdCBpcyAqYWxsKiB0 aGlzIHRocmVhZCB3YXMgaW50ZW5kZWQgdG8gYmUgYWJvdXQuDQoNCg0KUGV0ZXINCg0KRnJvbTog TWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KU2VudDogVGh1 cnNkYXksIE5vdmVtYmVyIDI5LCAyMDA3IDc6NTMgQU0NClRvOiBGcmFuayBFbGxlcm1hbm4NCkNj OiBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBhY3Rpb24gaXRl bTogIm90aGVyIiBjb2xsZWN0aW9ucyBpbiA2MzkNCg0KTm9ib2R5IGlzIGNhbGxpbmcgZm9yIHJl bW92aW5nLiBQZXRlcidzIGFjdGlvbiB3YXMgdG8gdGFrZSAiKE90aGVyKSIgb3V0IG9mIHRoZSBu YW1lcywgdGhhdCdzIGFsbC4NCg0KTWFyaw0KT24gTm92IDI5LCAyMDA3IDc6MjUgQU0sIEZyYW5r IEVsbGVybWFubiA8IG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTxtYWlsdG86bm9ib2R5QHh5enp5 LmNsYXJhbmV0LmRlPj4gd3JvdGU6DQpQZXRlciBDb25zdGFibGUgd3JvdGU6DQoNCj4gSSd2ZSBz dWdnZXN0ZWQgaW4gdGhlIHBhc3QgdGhhdCByZW1vdmluZyBjb2xsZWN0aW9uIElEcyBmcm9tDQo+ IEJDUDQ3IG1pZ2h0IG5vdCBiZSBhIGJhZCBpZGVhLCBidXQgb24gc2V2ZXJhbCBvY2Nhc2lvbnMg cGVvcGxlDQo+IGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSB3aXNoIHRvIGhhdmUgdGhlIGNvbGxl Y3Rpb25zIGtlcHQuDQoiUmVtb3ZpbmciIGNhbid0IGZseS4gIERvIHlvdSBtZWFuICJub3QgYWRk IG5ldyIgKGluIHRoZSA0NjQ1YmlzDQpidWxrIHVwZGF0ZSksICJkZXByZWNhdGUgb2xkIiwgb3Ig Ym90aCA/DQoNCiBGcmFuaw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnPG1haWx0bzpM dHJ1QGlldGYub3JnPg0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dQ0KDQoNCg0KLS0NCk1hcmsNCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1723NAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1 bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1T dW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9u MTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K ICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5VcGRhdGUgb24gdGhpczogSeKAmXZlIGdvdCBhZ3Jl ZW1lbnQgaW4gcHJpbmNpcGxlIGZyb20gTE9DIHRvIGNoYW5nZQ0KZW50cmllcyBvZiB0aGUgZm9y bSDigJxGb28gKE90aGVyKeKAnSB0byDigJxGb28gbGFuZ3VhZ2Vz4oCdIGluIElTTyA2MzktMi4g SW4gZG9pbmcNCnRoaXMsIHRoZXkgd2FudCB0byBwcm92aWRlIHNvbWUgaW5mbyBhcyB0byB3aGlj aCBpbmRpdmlkdWFsLWxhbmd1YWdlIGVudHJpZXMgaW4NCjYzOS0yIGFyZSBlbmNvbXBhc3NlZCB3 aXRoaW4gZWFjaCBjb2xsZWN0aW9uIHNvIHRoYXQgYXBwbGljYXRpb25zIGNhbiBkZXJpdmUg4oCc b3RoZXLigJ0NCmdyb3VwcyBpZiB0aGF04oCZcyBob3cgdGhleSB3YW50IHRvIHVzZSB0aGVtLiBT bywgSeKAmW0gbm90IHN1cmUganVzdCBob3cgcXVpY2tseQ0KdGhhdCBjaGFuZ2Ugd2lsbCBhcHBl YXIgaW4gdGhlIGNvZGUgdGFibGVzIG9uIHRoZSA2MzktMiBzaXRlLiAoSSB3b3VsZG7igJl0DQpl eHBlY3QgdG8gc2VlIGEgY2hhbmdlIG9uIHRoZSA2MzktMyBzaXRlIHVudGlsIHRoYXQgaGFzIGNo YW5nZWQgb24gdGhlIDYzOS0yDQpzaXRlLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz5QZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPiBQZXRlciBDb25zdGFibGUNClttYWlsdG86cGV0ZXJjb25AbWlj cm9zb2Z0LmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAyOSwgMjAw NyA4OjEzIEFNPGJyPg0KPGI+VG86PC9iPiBsdHJ1QGxpc3RzLmlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbTHRydV0gUmU6IGFjdGlvbiBpdGVtOiAmcXVvdDtvdGhlciZxdW90OyBj b2xsZWN0aW9ucyBpbg0KNjM5PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5MZXQgbWUgY2xhcmlmeSB0aGlz IHN1Yi10aHJlYWQ6IEkgaGF2ZSBxdWVzdGlvbmVkIGluIHRoZSBwYXN0DQp3aGV0aGVyIGxhbmd1 YWdlIGNvbGxlY3Rpb24gSUQgb2YgYW55IGtpbmQgYXJlIHVzZWZ1bCBpbiBJRVRGIGxhbmd1YWdl IHRhZ3MuDQpXaGVuZXZlciBJIG1hZGUgdGhhdCBzdWdnZXN0aW9uLCB0aGVyZSB3ZXJlIG90aGVy cyBoZXJlIGluc2lzdGluZyB0aGF0IHRoZXkNCndhbnRlZCB0aGVtIGtlcHQuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+SSBhbSBub3QgcHJvcG9zaW5nIGFueSBjaGFuZ2UgaW4gdGhp cyByZWdhcmQgYXQgdGhpcyB0aW1lLiBUaGlzDQpvbmx5IGNhbWUgdXAgYmVjYXVzZSBJIGhhZCBw b29ybHkgd29yZGVkIG15IHN0YXRlbWVudCBhYm91dCBnZXR0aW5nIHJpZCBvZg0K4oCcKE90aGVy KeKAnSBmcm9tIGxhbmd1YWdlLWNvbGxlY3Rpb24gbmFtZXMsIGFuZCBEb3VnIHRob3VnaHQgSSB3 YXMgc3VnZ2VzdGluZw0KdGhhdCBJU08gNjM5IOKAnHdpdGhkcmF34oCdIHRob3NlIGVudHJpZXMg 4oCTIEkgd2FzIG5vdCBzdWdnZXN0aW5nIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz5MZXQgbWUgY2xhcmlmeSB3aGF0IGNoYW5nZSBJIGFtIHB1cnN1aW5nOiBJIGFtIGFza2lu ZyB0aGUgSkFDIHRvDQpyZW1vdmUg4oCcKE90aGVyKeKAnSBmcm9tIHRoZSBuYW1lcyBvZiBsYW5n dWFnZS1jb2xsZWN0aW9uIGVudHJpZXMgdGhhdCBjdXJyZW50bHkNCmNvbnRhaW4gdGhhdCBzdHJp bmcuIFRoYXQgaXMgKjxiPmFsbDwvYj4qIHRoaXMgdGhyZWFkIHdhcyBpbnRlbmRlZCB0byBiZSBh Ym91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5Q ZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBN YXJrIERhdmlzDQpbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXSA8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDA3IDc6NTMgQU08YnI+DQo8Yj5Ubzo8 L2I+IEZyYW5rIEVsbGVybWFubjxicj4NCjxiPkNjOjwvYj4gbHRydUBsaXN0cy5pZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0x0cnVdIFJlOiBhY3Rpb24gaXRlbTogJnF1b3Q7b3Ro ZXImcXVvdDsgY29sbGVjdGlvbnMgaW4NCjYzOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPk5vYm9k eSBpcyBjYWxsaW5nIGZvciByZW1vdmluZy4NClBldGVyJ3MgYWN0aW9uIHdhcyB0byB0YWtlICZx dW90OyhPdGhlcikmcXVvdDsgb3V0IG9mIHRoZSBuYW1lcywgdGhhdCdzIGFsbC48YnI+DQo8YnI+ DQpNYXJrPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5PbiBO b3YgMjksIDIwMDcgNzoyNSBBTSwgRnJhbmsgRWxsZXJtYW5uICZsdDs8YQ0KaHJlZj0ibWFpbHRv Om5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZSI+IG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5QZXRlciBDb25zdGFibGUgd3JvdGU6PGJyPg0K PGJyPg0KJmd0OyBJJ3ZlIHN1Z2dlc3RlZCBpbiB0aGUgcGFzdCB0aGF0IHJlbW92aW5nIGNvbGxl Y3Rpb24gSURzIGZyb208YnI+DQomZ3Q7IEJDUDQ3IG1pZ2h0IG5vdCBiZSBhIGJhZCBpZGVhLCBi dXQgb24gc2V2ZXJhbCBvY2Nhc2lvbnMgcGVvcGxlPGJyPg0KJmd0OyBoYXZlIGluZGljYXRlZCB0 aGF0IHRoZXkgd2lzaCB0byBoYXZlIHRoZSBjb2xsZWN0aW9ucyBrZXB0LjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90O1JlbW92aW5nJnF1b3Q7IGNh bid0IGZseS4gJm5ic3A7RG8geW91IG1lYW4gJnF1b3Q7bm90DQphZGQgbmV3JnF1b3Q7IChpbiB0 aGUgNDY0NWJpczxicj4NCmJ1bGsgdXBkYXRlKSwgJnF1b3Q7ZGVwcmVjYXRlIG9sZCZxdW90Oywg b3IgYm90aCA/PGJyPg0KPHNwYW4gc3R5bGU9J2NvbG9yOiM4ODg4ODgnPjxicj4NCiZuYnNwO0Zy YW5rPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpMdHJ1IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo8L2E+PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48YnI+DQo8YnIgY2xlYXI9YWxsPg0KPGJyPg0KLS0gPGJyPg0KTWFyayA8bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1723NAEXMSGC117re_-- --===============1345573535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1345573535==-- From ltru-bounces@ietf.org Mon Jan 07 18:53:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1mZ-0006LN-DR; Mon, 07 Jan 2008 18:53:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC1mX-0006Ji-Ds for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 18:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1mX-0006Ja-46 for ltru@lists.ietf.org; Mon, 07 Jan 2008 18:53:25 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC1mW-0003G1-BG for ltru@lists.ietf.org; Mon, 07 Jan 2008 18:53:25 -0500 Received: by py-out-1112.google.com with SMTP id f47so10622291pye.8 for ; Mon, 07 Jan 2008 15:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=WKTBmW9EHgxoxt2TAVjA0jdcBfbIapWKYGnjf/Fcm1A=; b=e1txS4mc/7yudE+LKrsMY8Xk3OPFGAKjlCt8W+1+OvaZlfvZD6P4F87/di79KafiPO/OPgKexm4QzaAlXInKrhXQtWgzFbSwQctS1vsuWNLpa1ceinlJFj8DRLg2j8/TJPWeNx8/2sgE9UT8+//hjyX5soyBTmyDhtf8Mct7tKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=BnF8wYLawxZz+SsijvADUJ7ml9Tx9vkuKPdNFDVevwRGZaW3LFwsI+bmtq0BBGeLSa+tzVjD0Dc9aKIa4bY2DTvw8ZMbGe15GntdHFaqavkZ7pteTuzh4fur5vM4gbn/8IX1AxYWfCJGQt64abwxYqXaK2B1YIsK4NlX74nOIrI= Received: by 10.142.128.6 with SMTP id a6mr7635wfd.74.1199750003230; Mon, 07 Jan 2008 15:53:23 -0800 (PST) Received: by 10.143.8.19 with HTTP; Mon, 7 Jan 2008 15:53:23 -0800 (PST) Message-ID: <30b660a20801071553n498a79b5m33880462c46bd10b@mail.gmail.com> Date: Mon, 7 Jan 2008 15:53:23 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: action item: "other" collections in 639 In-Reply-To: MIME-Version: 1.0 References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> <30b660a20711290752l1461e009h53dce8c0244962cd@mail.gmail.com> X-Google-Sender-Auth: ccb9cad3ad71a56e X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0047646411==" Errors-To: ltru-bounces@ietf.org --===============0047646411== Content-Type: multipart/alternative; boundary="----=_Part_38783_25784268.1199750003232" ------=_Part_38783_25784268.1199750003232 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline R3JlYXQgbmV3cywgdGhhbmtzIGZvciBtYW5hZ2luZyB0aGlzIQoKTWFyawoKT24gSmFuIDcsIDIw MDggMzo0NiBQTSwgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3cm90 ZToKCj4gIFVwZGF0ZSBvbiB0aGlzOiBJJ3ZlIGdvdCBhZ3JlZW1lbnQgaW4gcHJpbmNpcGxlIGZy b20gTE9DIHRvIGNoYW5nZQo+IGVudHJpZXMgb2YgdGhlIGZvcm0gIkZvbyAoT3RoZXIpIiB0byAi Rm9vIGxhbmd1YWdlcyIgaW4gSVNPIDYzOS0yLiBJbiBkb2luZwo+IHRoaXMsIHRoZXkgd2FudCB0 byBwcm92aWRlIHNvbWUgaW5mbyBhcyB0byB3aGljaCBpbmRpdmlkdWFsLWxhbmd1YWdlIGVudHJp ZXMKPiBpbiA2MzktMiBhcmUgZW5jb21wYXNzZWQgd2l0aGluIGVhY2ggY29sbGVjdGlvbiBzbyB0 aGF0IGFwcGxpY2F0aW9ucyBjYW4KPiBkZXJpdmUgIm90aGVyIiBncm91cHMgaWYgdGhhdCdzIGhv dyB0aGV5IHdhbnQgdG8gdXNlIHRoZW0uIFNvLCBJJ20gbm90IHN1cmUKPiBqdXN0IGhvdyBxdWlj a2x5IHRoYXQgY2hhbmdlIHdpbGwgYXBwZWFyIGluIHRoZSBjb2RlIHRhYmxlcyBvbiB0aGUgNjM5 LTIKPiBzaXRlLiAoSSB3b3VsZG4ndCBleHBlY3QgdG8gc2VlIGEgY2hhbmdlIG9uIHRoZSA2Mzkt MyBzaXRlIHVudGlsIHRoYXQgaGFzCj4gY2hhbmdlZCBvbiB0aGUgNjM5LTIgc2l0ZS4pCj4KPgo+ Cj4KPgo+IFBldGVyCj4KPgo+Cj4gKkZyb206KiBQZXRlciBDb25zdGFibGUgW21haWx0bzpwZXRl cmNvbkBtaWNyb3NvZnQuY29tXQo+ICpTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDA3 IDg6MTMgQU0KPiAqVG86KiBsdHJ1QGxpc3RzLmlldGYub3JnCj4gKlN1YmplY3Q6KiBSRTogW0x0 cnVdIFJlOiBhY3Rpb24gaXRlbTogIm90aGVyIiBjb2xsZWN0aW9ucyBpbiA2MzkKPgo+Cj4KPiBM ZXQgbWUgY2xhcmlmeSB0aGlzIHN1Yi10aHJlYWQ6IEkgaGF2ZSBxdWVzdGlvbmVkIGluIHRoZSBw YXN0IHdoZXRoZXIKPiBsYW5ndWFnZSBjb2xsZWN0aW9uIElEIG9mIGFueSBraW5kIGFyZSB1c2Vm dWwgaW4gSUVURiBsYW5ndWFnZSB0YWdzLgo+IFdoZW5ldmVyIEkgbWFkZSB0aGF0IHN1Z2dlc3Rp b24sIHRoZXJlIHdlcmUgb3RoZXJzIGhlcmUgaW5zaXN0aW5nIHRoYXQgdGhleQo+IHdhbnRlZCB0 aGVtIGtlcHQuCj4KPgo+Cj4gSSBhbSBub3QgcHJvcG9zaW5nIGFueSBjaGFuZ2UgaW4gdGhpcyBy ZWdhcmQgYXQgdGhpcyB0aW1lLiBUaGlzIG9ubHkgY2FtZQo+IHVwIGJlY2F1c2UgSSBoYWQgcG9v cmx5IHdvcmRlZCBteSBzdGF0ZW1lbnQgYWJvdXQgZ2V0dGluZyByaWQgb2YgIihPdGhlcikiCj4g ZnJvbSBsYW5ndWFnZS1jb2xsZWN0aW9uIG5hbWVzLCBhbmQgRG91ZyB0aG91Z2h0IEkgd2FzIHN1 Z2dlc3RpbmcgdGhhdCBJU08KPiA2MzkgIndpdGhkcmF3IiB0aG9zZSBlbnRyaWVzIOKAkyBJIHdh cyBub3Qgc3VnZ2VzdGluZyB0aGF0Lgo+Cj4KPgo+IExldCBtZSBjbGFyaWZ5IHdoYXQgY2hhbmdl IEkgYW0gcHVyc3Vpbmc6IEkgYW0gYXNraW5nIHRoZSBKQUMgdG8gcmVtb3ZlCj4gIihPdGhlciki IGZyb20gdGhlIG5hbWVzIG9mIGxhbmd1YWdlLWNvbGxlY3Rpb24gZW50cmllcyB0aGF0IGN1cnJl bnRseQo+IGNvbnRhaW4gdGhhdCBzdHJpbmcuIFRoYXQgaXMgKiphbGwqKiB0aGlzIHRocmVhZCB3 YXMgaW50ZW5kZWQgdG8gYmUgYWJvdXQuCj4KPgo+Cj4KPgo+IFBldGVyCj4KPgo+Cj4gKkZyb206 KiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddCj4gKlNlbnQ6 KiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMDcgNzo1MyBBTQo+ICpUbzoqIEZyYW5rIEVsbGVy bWFubgo+ICpDYzoqIGx0cnVAbGlzdHMuaWV0Zi5vcmcKPiAqU3ViamVjdDoqIFJlOiBbTHRydV0g UmU6IGFjdGlvbiBpdGVtOiAib3RoZXIiIGNvbGxlY3Rpb25zIGluIDYzOQo+Cj4KPgo+IE5vYm9k eSBpcyBjYWxsaW5nIGZvciByZW1vdmluZy4gUGV0ZXIncyBhY3Rpb24gd2FzIHRvIHRha2UgIihP dGhlcikiIG91dAo+IG9mIHRoZSBuYW1lcywgdGhhdCdzIGFsbC4KPgo+IE1hcmsKPgo+IE9uIE5v diAyOSwgMjAwNyA3OjI1IEFNLCBGcmFuayBFbGxlcm1hbm4gPCBub2JvZHlAeHl6enkuY2xhcmFu ZXQuZGU+Cj4gd3JvdGU6Cj4KPiBQZXRlciBDb25zdGFibGUgd3JvdGU6Cj4KPiA+IEkndmUgc3Vn Z2VzdGVkIGluIHRoZSBwYXN0IHRoYXQgcmVtb3ZpbmcgY29sbGVjdGlvbiBJRHMgZnJvbQo+ID4g QkNQNDcgbWlnaHQgbm90IGJlIGEgYmFkIGlkZWEsIGJ1dCBvbiBzZXZlcmFsIG9jY2FzaW9ucyBw ZW9wbGUKPiA+IGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSB3aXNoIHRvIGhhdmUgdGhlIGNvbGxl Y3Rpb25zIGtlcHQuCj4KPiAiUmVtb3ZpbmciIGNhbid0IGZseS4gIERvIHlvdSBtZWFuICJub3Qg YWRkIG5ldyIgKGluIHRoZSA0NjQ1YmlzCj4gYnVsayB1cGRhdGUpLCAiZGVwcmVjYXRlIG9sZCIs IG9yIGJvdGggPwo+Cj4gIEZyYW5rCj4KPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9y Zwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+Cj4KPgo+ IC0tCj4gTWFyawo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4KPgoKCi0tIApNYXJrCg== ------=_Part_38783_25784268.1199750003232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline R3JlYXQgbmV3cywgdGhhbmtzIGZvciBtYW5hZ2luZyB0aGlzITxicj48YnI+TWFyazxicj48YnI+ PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEphbiA3LCAyMDA4IDM6NDYgUE0sIFBldGVyIENv bnN0YWJsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iPnBldGVy Y29uQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIw NCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoKCgoK CgoKCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iRU4tVVMiPgoKPGRpdj4K CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+VXBkYXRlIG9uIHRoaXM6IEkndmUgZ290IGFncmVlbWVudCBpbiBwcmluY2lwbGUgZnJvbSBM T0MgdG8gY2hhbmdlCmVudHJpZXMgb2YgdGhlIGZvcm0gIkZvbyAoT3RoZXIpIiB0byAiRm9vIGxh bmd1YWdlcyIgaW4gSVNPIDYzOS0yLiBJbiBkb2luZwp0aGlzLCB0aGV5IHdhbnQgdG8gcHJvdmlk ZSBzb21lIGluZm8gYXMgdG8gd2hpY2ggaW5kaXZpZHVhbC1sYW5ndWFnZSBlbnRyaWVzIGluCjYz OS0yIGFyZSBlbmNvbXBhc3NlZCB3aXRoaW4gZWFjaCBjb2xsZWN0aW9uIHNvIHRoYXQgYXBwbGlj YXRpb25zIGNhbiBkZXJpdmUgIm90aGVyIgpncm91cHMgaWYgdGhhdCdzIGhvdyB0aGV5IHdhbnQg dG8gdXNlIHRoZW0uIFNvLCBJJ20gbm90IHN1cmUganVzdCBob3cgcXVpY2tseQp0aGF0IGNoYW5n ZSB3aWxsIGFwcGVhciBpbiB0aGUgY29kZSB0YWJsZXMgb24gdGhlIDYzOS0yIHNpdGUuIChJIHdv dWxkbid0CmV4cGVjdCB0byBzZWUgYSBjaGFuZ2Ugb24gdGhlIDYzOS0zIHNpdGUgdW50aWwgdGhh dCBoYXMgY2hhbmdlZCBvbiB0aGUgNjM5LTIKc2l0ZS4pPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9z cGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+UGV0ZXI8L3NwYW4+PC9wPgoKPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJz cDs8L3NwYW4+PC9wPgoKPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBz b2xpZDsgYm9yZGVyLWNvbG9yOiAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29s b3IgLW1vei11c2UtdGV4dC1jb2xvciBibHVlOyBib3JkZXItd2lkdGg6IG1lZGl1bSBtZWRpdW0g bWVkaXVtIDEuNXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7Ij4KCjxkaXY+Cgo8ZGl2IHN0 eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgx LCAxOTYsIDIyMykgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yOyBib3Jk ZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPgoKPHA+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyI+IFBldGVyIENvbnN0YWJsZQpbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGV0ZXJjb25A bWljcm9zb2Z0LmNvbTwvYT5dIDxicj4KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAy OSwgMjAwNyA4OjEzIEFNPGJyPgo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpsdHJ1QGxpc3Rz LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHRydUBsaXN0cy5pZXRmLm9yZzwvYT48YnI+Cjxi PlN1YmplY3Q6PC9iPiBSRTogW0x0cnVdIFJlOiBhY3Rpb24gaXRlbTogJnF1b3Q7b3RoZXImcXVv dDsgY29sbGVjdGlvbnMgaW4KNjM5PC9zcGFuPjwvcD4KCjwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2 PjwvZGl2PjxkaXYgY2xhc3M9IldqM0M3YyI+Cgo8cD4mbmJzcDs8L3A+Cgo8cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkxldCBtZSBjbGFy aWZ5IHRoaXMgc3ViLXRocmVhZDogSSBoYXZlIHF1ZXN0aW9uZWQgaW4gdGhlIHBhc3QKd2hldGhl ciBsYW5ndWFnZSBjb2xsZWN0aW9uIElEIG9mIGFueSBraW5kIGFyZSB1c2VmdWwgaW4gSUVURiBs YW5ndWFnZSB0YWdzLgpXaGVuZXZlciBJIG1hZGUgdGhhdCBzdWdnZXN0aW9uLCB0aGVyZSB3ZXJl IG90aGVycyBoZXJlIGluc2lzdGluZyB0aGF0IHRoZXkKd2FudGVkIHRoZW0ga2VwdC4gPC9zcGFu PjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SSBhbSBub3QgcHJvcG9zaW5nIGFueSBjaGFu Z2UgaW4gdGhpcyByZWdhcmQgYXQgdGhpcyB0aW1lLiBUaGlzCm9ubHkgY2FtZSB1cCBiZWNhdXNl IEkgaGFkIHBvb3JseSB3b3JkZWQgbXkgc3RhdGVtZW50IGFib3V0IGdldHRpbmcgcmlkIG9mCiIo T3RoZXIpIiBmcm9tIGxhbmd1YWdlLWNvbGxlY3Rpb24gbmFtZXMsIGFuZCBEb3VnIHRob3VnaHQg SSB3YXMgc3VnZ2VzdGluZwp0aGF0IElTTyA2MzkgIndpdGhkcmF3IiB0aG9zZSBlbnRyaWVzIOKA kyBJIHdhcyBub3Qgc3VnZ2VzdGluZyB0aGF0Ljwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48 L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPkxldCBtZSBjbGFyaWZ5IHdoYXQgY2hhbmdlIEkgYW0gcHVyc3Vpbmc6IEkgYW0gYXNr aW5nIHRoZSBKQUMgdG8KcmVtb3ZlICIoT3RoZXIpIiBmcm9tIHRoZSBuYW1lcyBvZiBsYW5ndWFn ZS1jb2xsZWN0aW9uIGVudHJpZXMgdGhhdCBjdXJyZW50bHkKY29udGFpbiB0aGF0IHN0cmluZy4g VGhhdCBpcyAqPGI+YWxsPC9iPiogdGhpcyB0aHJlYWQgd2FzIGludGVuZGVkIHRvIGJlIGFib3V0 Ljwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48L3A+Cgo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PlBldGVyPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxkaXYgc3R5bGU9ImJvcmRl ci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1jb2xvcjogLW1vei11c2UtdGV4 dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgYmx1ZTsgYm9y ZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgcGFkZGluZzogMGluIDBpbiAw aW4gNHB0OyI+Cgo8ZGl2PgoKPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5v bmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpIC1tb3otdXNlLXRleHQtY29sb3Ig LW1vei11c2UtdGV4dC1jb2xvcjsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgcGFk ZGluZzogM3B0IDBpbiAwaW47Ij4KCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPiBNYXJrIERh dmlzClttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+XSA8YnI+CjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMDcgNzo1MyBBTTxicj4KPGI+VG86PC9i PiBGcmFuayBFbGxlcm1hbm48YnI+CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmx0cnVAbGlz dHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sdHJ1QGxpc3RzLmlldGYub3JnPC9hPjxicj4K PGI+U3ViamVjdDo8L2I+IFJlOiBbTHRydV0gUmU6IGFjdGlvbiBpdGVtOiAmcXVvdDtvdGhlciZx dW90OyBjb2xsZWN0aW9ucyBpbgo2Mzk8L3NwYW4+PC9wPgoKPC9kaXY+Cgo8L2Rpdj4KCjxwPiZu YnNwOzwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+Tm9ib2R5IGlzIGNhbGxp bmcgZm9yIHJlbW92aW5nLgpQZXRlciYjMzk7cyBhY3Rpb24gd2FzIHRvIHRha2UgJnF1b3Q7KE90 aGVyKSZxdW90OyBvdXQgb2YgdGhlIG5hbWVzLCB0aGF0JiMzOTtzIGFsbC48YnI+Cjxicj4KTWFy azwvcD4KCjxkaXY+Cgo8cD5PbiBOb3YgMjksIDIwMDcgNzoyNSBBTSwgRnJhbmsgRWxsZXJtYW5u ICZsdDs8YSBocmVmPSJtYWlsdG86bm9ib2R5QHh5enp5LmNsYXJhbmV0LmRlIiB0YXJnZXQ9Il9i bGFuayI+IG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZTwvYT4mZ3Q7IHdyb3RlOjwvcD4KCjxkaXY+ Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPlBldGVyIENvbnN0YWJsZSB3cm90ZTo8 YnI+Cjxicj4KJmd0OyBJJiMzOTt2ZSBzdWdnZXN0ZWQgaW4gdGhlIHBhc3QgdGhhdCByZW1vdmlu ZyBjb2xsZWN0aW9uIElEcyBmcm9tPGJyPgomZ3Q7IEJDUDQ3IG1pZ2h0IG5vdCBiZSBhIGJhZCBp ZGVhLCBidXQgb24gc2V2ZXJhbCBvY2Nhc2lvbnMgcGVvcGxlPGJyPgomZ3Q7IGhhdmUgaW5kaWNh dGVkIHRoYXQgdGhleSB3aXNoIHRvIGhhdmUgdGhlIGNvbGxlY3Rpb25zIGtlcHQuPC9wPgoKPC9k aXY+Cgo8cD4mcXVvdDtSZW1vdmluZyZxdW90OyBjYW4mIzM5O3QgZmx5LiAmbmJzcDtEbyB5b3Ug bWVhbiAmcXVvdDtub3QKYWRkIG5ldyZxdW90OyAoaW4gdGhlIDQ2NDViaXM8YnI+CmJ1bGsgdXBk YXRlKSwgJnF1b3Q7ZGVwcmVjYXRlIG9sZCZxdW90Oywgb3IgYm90aCA/PGJyPgo8c3BhbiBzdHls ZT0iY29sb3I6IHJnYigxMzYsIDEzNiwgMTM2KTsiPjxicj4KJm5ic3A7RnJhbms8L3NwYW4+PC9w PgoKPGRpdj4KCjxkaXY+Cgo8cD48YnI+Cjxicj4KPGJyPgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KTHRydSBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhy ZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+THRydUBpZXRmLm9yZzwv YT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sdHJ1CjwvYT48L3A+Cgo8L2Rpdj4KCjwvZGl2PgoKPC9kaXY+Cgo8cD48YnI+CjxiciBjbGVh cj0iYWxsIj4KPGJyPgotLSA8YnI+Ck1hcmsgPC9wPgoKPC9kaXY+Cgo8L2Rpdj48L2Rpdj48L2Rp dj4KCjwvZGl2PgoKPC9kaXY+CgoKPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpM dHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo8L2E+PGJyPjxicj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_38783_25784268.1199750003232-- --===============0047646411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0047646411==-- From ltru-bounces@ietf.org Mon Jan 07 19:27:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2Jn-0007aP-H1; Mon, 07 Jan 2008 19:27:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC2Jl-0007LO-RX for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 19:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2Jl-0007Ic-GQ for ltru@lists.ietf.org; Mon, 07 Jan 2008 19:27:45 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC2Jk-0003hl-LE for ltru@lists.ietf.org; Mon, 07 Jan 2008 19:27:45 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JC2Jk-0000RF-F1; Mon, 07 Jan 2008 19:27:44 -0500 Date: Mon, 7 Jan 2008 19:27:44 -0500 To: Peter Constable Subject: Re: [Ltru] Re: action item: "other" collections in 639 Message-ID: <20080108002744.GA18074@mercury.ccil.org> References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> <30b660a20711290752l1461e009h53dce8c0244962cd@mail.gmail.com> <30b660a20801071553n498a79b5m33880462c46bd10b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30b660a20801071553n498a79b5m33880462c46bd10b@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > Update on this: I've got agreement in principle from LOC to change > entries of the form "Foo (Other)" to "Foo languages" in ISO 639-2. In doing > this, they want to provide some info as to which individual-language entries > in 639-2 are encompassed within each collection so that applications can > derive "other" groups if that's how they want to use them. So, I'm not sure > just how quickly that change will appear in the code tables on the 639-2 > site. (I wouldn't expect to see a change on the 639-3 site until that has > changed on the 639-2 site.) Pulling together the Ethnologue 14 data, we find the following, which is probably out of date in some places -- someone needs to go through the 639-2 registrations since 2002 (Doug?) Afro-Asiatic (Other) [afa] includes: ber Berber (Other) [collective] cop Coptic cus Cushitic (Other) [collective] hau Hausa sem Semitic (Other) [collective] wal Walamo Altaic (Other) [tut] includes: aze Azerbaijani bak Bashkir bua Buriat chg Chagatai chv Chuvash kaa Kara-Kalpak kaz Kazakh kir Kirghiz kum Kumyk mnc Manchu mon Mongolian tat Tatar tur Turkish ota Turkish, Ottoman (1500-1928) tuk Turkmen tyv Tuvinian uig Uighur uzb Uzbek sah Yakut Austronesian (Other) [map] includes: ace Achinese ban Balinese btk Batak (Indonesia) bug Buginese cmc Chamic languages [collective] cha Chamorro chk Chuukese day Dayak fij Fijian gay Gayo gil Gilbertese gor Gorontalo haw Hawaiian iba Iban ind Indonesian jav Javanese kos Kosraean mad Madurese mak Makasar mlg Malagasy may Malay mdr Mandar mao Maori mah Marshall min Minangkabau nau Nauru nia Nias niu Niuean pau Palauan phi Philippine (Other) [collective] pon Pohnpeian rap Rapanui rar Rarotongan smo Samoan sas Sasak sun Sundanese tah Tahitian tet Tetum tkl Tokelau ton Tonga (Tonga Islands) tvl Tuvalu yap Yapese Baltic (Other) [bal] includes: lav Latvian lit Lithuanian Bantu (Other) [bnt] includes: bai Bamileke languages [collective] bas Basa bem Bemba nya Chichewa; Nyanja dua Duala eka Ekajuk ewo Ewondo fan Fang lug Ganda her Herero kam Kamba kik Kikuyu kmb Kimbundu kin Kinyarwanda kon Kongo kua Kuanyama lam Lamba lin Lingala loz Lozi lub Luba-Katanga lua Luba-Lulua lun Lunda lol Mongo nde Ndebele, North nbl Ndebele, South ndo Ndonga nym Nyamwezi nyn Nyankole nyo Nyoro run Rundi sna Shona nso Sotho, Northern sot Sotho, Southern suk Sukuma swa Swahili ssw Swati tiv Tiv tog Tonga (Nyasa) tso Tsonga tsn Tswana tum Tumbuka umb Umbundu ven Venda xho Xhosa yao Yao zul Zulu Berber (Other) [ber] includes: kab Kabyle tmh Tamashek zen Zenaga Celtic (Other) [cel] includes: bre Breton cor Cornish gla Gaelic (Scots) gle Irish glv Manx wel Welsh Creoles and Pidgins (Other) [crp] includes: chn Chinook jargon cpe Creoles and pidgins, English based (Other) [collective] cpf Creoles and pidgins, French-based (Other) [collective] cpp Creoles and pidgins, Portuguese-based (Other) [collective] hmo Hiri Motu pap Papiamento sag Sango Creoles and pidgins, English based (Other) [cpe] includes: bis Bislama tpi Tok Pisin Creoles and pidgins, French-based (Other) [cpf] includes: nothing Creoles and pidgins, Portuguese-based (Other) [cpp] includes: nothing Cushitic (Other) [cus] includes: aar Afar bej Beja orm Oromo sid Sidamo som Somali Dravidian (Other) [dra] includes: gon Gondi kan Kannada kru Kurukh mal Malayalam tam Tamil tel Telugu Finno-Ugrian (Other) [fiu] includes: est Estonian fin Finnish hun Hungarian kom Komi chm Mari smi Sami languages (Other) [collective] vot Votic Germanic (Other) [gem] includes: afr Afrikaans dan Danish dut Dutch eng English fao Faroese fry Frisian ger German got Gothic ice Icelandic ltz Letzeburgesch nds Low German; Low Saxon nor Norwegian sco Scots swe Swedish Indic (Other) [inc] includes: asm Assamese awa Awadhi ben Bengali bho Bhojpuri bih Bihari bra Braj div Divehi doi Dogri guj Gujarati him Himachali hin Hindi kas Kashmiri kok Konkani lah Lahnda mag Magahi mai Maithili mar Marathi mwr Marwari nep Nepali ori Oriya pli Pali pan Panjabi raj Rajasthani rom Romany san Sanskrit snd Sindhi sin Sinhalese urd Urdu Indo-European (Other) [ine] includes: alb Albanian arm Armenian bat Baltic (Other) [collective] cel Celtic (Other) [collective] gem Germanic (Other) [collective] grc Greek, Ancient (to 1453) gre Greek, Modern (1453-) inc Indic (Other) [collective] ira Iranian (Other) [collective] lat Latin roa Romance (Other) [collective] sla Slavic (Other) [collective] Iranian (Other) [ira] includes: ave Avestan bal Baluchi jpr Judeo-Persian kur Kurdish oss Ossetian; Ossetic per Persian pus Pushto tgk Tajik Khoisan (Other) [khi] includes: sad Sandawe Mon-Khmer (Other) includes: kha Khasi khm Khmer vie Vietnamese Niger-Kordofanian (Other) [nic] includes: ada Adangme aka Akan bam Bambara bad Banda bnt Bantu (Other) [collective] bin Bini dyu Dyula efi Efik ewe Ewe fat Fanti fon Fon ful Fulah gaa Ga gba Gbaya ibo Igbo ijo Ijo kpe Kpelle kro Kru man Mandingo men Mende mos Mossi nzi Nzima srr Serer snk Soninke sus Susu tem Timne twi Twi vai Vai wol Wolof yor Yoruba znd Zande Nilo-Saharan (Other) [ssa] includes: ach Acoli din Dinka kau Kanuri luo Luo (Kenya and Tanzania) mas Masai nub Nubian languages [collective] son Songhai Romance (Other) [roa] includes: ast Asturian; Bable cat Catalan cos Corsican fre French fur Friulian glg Gallegan ita Italian lad Ladino mol Moldavian oci Occitan (post 1500); Proven�al por Portuguese roh Raeto-Romance rum Romanian srd Sardinian spa Spanish Sami languages (Other) [smi] includes: sme Northern Sami Semitic (Other) [sem] includes: amh Amharic ara Arabic arc Aramaic gez Geez heb Hebrew jrb Judeo-Arabic mlt Maltese sam Samaritan Aramaic syr Syriac tig Tigre tir Tigrinya Sino-Tibetan (Other) [sit] includes: bur Burmese chi Chinese dzo Dzongkha kac Kachin kar Karen lus Lushai mni Manipuri new Newari tib Tibetan Slavic (Other) [sla] includes: bel Belarusian bos Bosnian bul Bulgarian chu Church Slavic scr Croatian cze Czech mac Macedonian pol Polish rus Russian scc Serbian slo Slovak slv Slovenian wen Sorbian languages [collective] ukr Ukrainian Tai (Other) [tai] includes: lao Lao shn Shan tha Thai zha Zhuang -- A witness cannot give evidence of his John Cowan age unless he can remember being born. cowan@ccil.org --Judge Blagden http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 07 21:05:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3q2-00019l-IH; Mon, 07 Jan 2008 21:05:10 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC3q1-00019f-CD for ltru-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 21:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3q1-00019X-2T for ltru@lists.ietf.org; Mon, 07 Jan 2008 21:05:09 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC3q0-0005Wf-Pu for ltru@lists.ietf.org; Mon, 07 Jan 2008 21:05:09 -0500 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.1.222.3; Mon, 7 Jan 2008 18:05:07 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon, 7 Jan 2008 18:05:07 -0800 From: Peter Constable To: John Cowan Date: Mon, 7 Jan 2008 18:04:59 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: AchRjU6/WTp1n04oSVKKbviHfzDzggADPptA Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> <30b660a20711290752l1461e009h53dce8c0244962cd@mail.gmail.com> <30b660a20801071553n498a79b5m33880462c46bd10b@mail.gmail.com> <20080108002744.GA18074@mercury.ccil.org> In-Reply-To: <20080108002744.GA18074@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598844498==" Errors-To: ltru-bounces@ietf.org --===============1598844498== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBKb2huIENvd2FuDQoNCj4gPiBJbiBkb2luZw0KPiA+IHRoaXMsIHRoZXkgd2FudCB0 byBwcm92aWRlIHNvbWUgaW5mbyBhcyB0byB3aGljaCBpbmRpdmlkdWFsLWxhbmd1YWdlDQo+IGVu dHJpZXMNCj4gPiBpbiA2MzktMiBhcmUgZW5jb21wYXNzZWQgd2l0aGluIGVhY2ggY29sbGVjdGlv biBzbyB0aGF0IGFwcGxpY2F0aW9ucw0KPiBjYW4NCj4gPiBkZXJpdmUgIm90aGVyIiBncm91cHMg aWYgdGhhdCdzIGhvdyB0aGV5IHdhbnQgdG8gdXNlIHRoZW0uIFNvLCBJJ20NCj4gbm90IHN1cmUN Cj4gPiBqdXN0IGhvdyBxdWlja2x5IHRoYXQgY2hhbmdlIHdpbGwgYXBwZWFyIGluIHRoZSBjb2Rl IHRhYmxlcyBvbiB0aGUNCj4gNjM5LTINCj4gPiBzaXRlLiAoSSB3b3VsZG4ndCBleHBlY3QgdG8g c2VlIGEgY2hhbmdlIG9uIHRoZSA2MzktMyBzaXRlIHVudGlsIHRoYXQNCj4gaGFzDQo+ID4gY2hh bmdlZCBvbiB0aGUgNjM5LTIgc2l0ZS4pDQo+DQo+IFB1bGxpbmcgdG9nZXRoZXIgdGhlIEV0aG5v bG9ndWUgMTQgZGF0YSwgd2UgZmluZCB0aGUgZm9sbG93aW5nLCB3aGljaA0KPiBpcyBwcm9iYWJs eSBvdXQgb2YgZGF0ZSBpbiBzb21lIHBsYWNlcyAtLSBzb21lb25lIG5lZWRzIHRvIGdvIHRocm91 Z2gNCj4gdGhlIDYzOS0yIHJlZ2lzdHJhdGlvbnMgc2luY2UgMjAwMg0KDQpKb2FuIFNwYW5uZSAo U0lMLCA2MzktMyBSQSkgaGFzIGJlZW4gd29ya2luZyBvbiByZWxhdGlvbnNoaXBzIGJldHdlZW4g Y29sbGVjdGlvbnMsIG1hY3JvbGFuZ3VhZ2VzIGFuZCBpbmRpdmlkdWFsIGxhbmd1YWdlcywgYW5k IHdpbGwgYmUgZm9sbG93aW5nIHVwIHdpdGggTE9DIHRvIGhlbHAgZ2V0IHRoaXMgZG9uZS4NCg0K DQoNClBldGVyDQo= --===============1598844498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1598844498==-- From ltru-bounces@ietf.org Tue Jan 08 00:16:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6pN-0006Wo-5i; Tue, 08 Jan 2008 00:16:41 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC6pL-0006WU-Vi for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 00:16:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6pL-0006Vr-7Z for ltru@ietf.org; Tue, 08 Jan 2008 00:16:39 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC6pK-0000UP-Td for ltru@ietf.org; Tue, 08 Jan 2008 00:16:39 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080108051636.UYBG12121.mta11.adelphia.net@DGBP7M81> for ; Tue, 8 Jan 2008 00:16:36 -0500 Message-ID: <001701c851b5$a4dbfc70$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 7 Jan 2008 21:16:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Progressing beyond borders-making subtags inclusive X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicholas Shanks wrote: > Foe example en-scouse and en-GB-scouse both represent the same thing. > (yes, I know the second isn't technically registered, but people will > still use those kinds of constructs because they don't know any > better). Same with en-GB-oed. Actually, 'scouse' is now a registered variant subtag (since September 2006), not just a piece of the grandfathered tag "en-scouse". This means "en-GB-scouse" is just as valid as "en-scouse", and probably better for fans of remove-from-right fallback. 'oed', on the other hand, can never be a variant on its own because of its length. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 08 00:23:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6w7-0002Zc-Ac; Tue, 08 Jan 2008 00:23:39 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC6w5-0002ZW-Pd for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 00:23:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6w5-0002ZO-FK for ltru@ietf.org; Tue, 08 Jan 2008 00:23:37 -0500 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC6w5-0000ac-3F for ltru@ietf.org; Tue, 08 Jan 2008 00:23:37 -0500 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 <20080108052336.REFC7875.mta16.adelphia.net@DGBP7M81> for ; Tue, 8 Jan 2008 00:23:36 -0500 Message-ID: <001901c851b6$9ed84350$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 7 Jan 2008 21:23:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Update on this: I’ve got agreement in principle from LOC to change > entries of the form “Foo (Other)” to “Foo languages” in ISO 639-2. In > doing this, they want to provide some info as to which > individual-language entries in 639-2 are encompassed within each > collection so that applications can derive “other” groups if that’s > how they want to use them. So, I’m not sure just how quickly that > change will appear in the code tables on the 639-2 site. (I wouldn’t > expect to see a change on the 639-3 site until that has changed on the > 639-2 site.) Am I correct in thinking the group will want to delay 4645bis again for this? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 08 01:22:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC7rT-0003n8-9A; Tue, 08 Jan 2008 01:22:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JC7rS-0003jc-26 for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 01:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC7rR-0003fI-Ha for ltru@ietf.org; Tue, 08 Jan 2008 01:22:53 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC7rR-0000bG-5p for ltru@ietf.org; Tue, 08 Jan 2008 01:22:53 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JC7rR-0003vM-1H; Tue, 08 Jan 2008 01:22:53 -0500 Date: Tue, 8 Jan 2008 01:22:53 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: action item: "other" collections in 639 Message-ID: <20080108062252.GF27859@mercury.ccil.org> References: <001901c851b6$9ed84350$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c851b6$9ed84350$6501a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: > Am I correct in thinking the group will want to delay 4645bis again for > this? I don't see why. It has no structural effect, and it's just a matter of 34 name changes later. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 04:06:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAPi-0006M9-Vk; Tue, 08 Jan 2008 04:06:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCAPh-0006Jg-Hm for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 04:06:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAPh-0006JY-79 for ltru@ietf.org; Tue, 08 Jan 2008 04:06:25 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCAPg-0004lE-RO for ltru@ietf.org; Tue, 08 Jan 2008 04:06:25 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id E6BA31C00FC; Tue, 8 Jan 2008 10:06:23 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E14821C00E4; Tue, 8 Jan 2008 10:06:23 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DE1F958ECBB; Tue, 8 Jan 2008 10:06:23 +0100 (CET) Date: Tue, 8 Jan 2008 10:06:23 +0100 From: Stephane Bortzmeyer To: Randy Presuhn Message-ID: <20080108090623.GA18206@nic.fr> References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Jan 04, 2008 at 04:29:01PM -0800, Randy Presuhn wrote a message of 83 lines which said: > 2) There may be cases where the correct tag for a particular > language may not be immediately obvious from the data in the > registry. IMHO, that's the big issue we have with the "alsatian" registration request. How to help people find the tag when the name they use for their language is not in the registry? > I can see several possible responses: ... > c) leave the documentation of such cases to others How do you ensure consistency in that case? Today, some people tag alsatian as "de-FR", some (very rare, apparently) as "gsw-FR", some as "gsw-x-alsatian" and some as the (invalid) "gsw-alsatian" or "alsatian" or "als". It seems that, for consistent tagging, we need one (1) authoritative source (wether it is the LSR or a yet-to-be-done companion registry). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 04:29:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAlt-0007Fi-Eh; Tue, 08 Jan 2008 04:29:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCAls-0007FQ-D7 for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 04:29:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAls-0007Dc-1A for ltru@ietf.org; Tue, 08 Jan 2008 04:29:20 -0500 Received: from mk-outboundfilter-3.mail.uk.tiscali.com ([212.74.114.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCAlr-0005LL-M4 for ltru@ietf.org; Tue, 08 Jan 2008 04:29:19 -0500 X-Trace: 14562520/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/195.137.85.17 X-SBRS: None X-RemoteIP: 195.137.85.17 X-IP-MAIL-FROM: contact@nickshanks.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO/QgkfDiVUR/2dsb2JhbAAIqQk Received: from home.nickshanks.com (HELO [192.168.1.17]) ([195.137.85.17]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/AES128-SHA; 08 Jan 2008 09:29:18 +0000 Message-Id: <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> From: Nicholas Shanks To: LTRU Working Group In-Reply-To: <20080108090623.GA18206@nic.fr> Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 8 Jan 2008 09:29:17 +0000 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1923661635==" Errors-To: ltru-bounces@ietf.org --===============1923661635== Content-Type: multipart/signed; boundary=Apple-Mail-10-286541796; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-10-286541796 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 8 Jan 2008, at 09:06, Stephane Bortzmeyer wrote: > How do you ensure consistency in that case? Today, some people tag > alsatian as "de-FR", some (very rare, apparently) as "gsw-FR", some as > "gsw-x-alsatian" and some as the (invalid) "gsw-alsatian" or > "alsatian" or "als". > > It seems that, for consistent tagging, we need one (1) authoritative > source I'll wager that those using de-FR, als and so on are not even looking at the registry, and probably don't know it exists. They're just applying their existing knowledge of how the system works and coming up with a less than correct result. As I suggested yesterday, I think it would be a good idea to create a separate list of synonyms encountered 'in the wild' and which actual tags processors (human and mechanical) should map them to. - Nicholas. --Apple-Mail-10-286541796 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLTCCAuYw ggJPoAMCAQICEGKqZrHuUP0yta79Nvpn/q4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyNDA4NDA1OFoXDTA4MTEyMzA4NDA1 OFowSDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWY29u dGFjdEBuaWNrc2hhbmtzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL5kw0vl ChNl7F/Hh7ktxu/eVUcWILoufdDLbBfzjRS/JujWyt4yYcuQo6p2nuivF3zncknuvMkSwyHBQMpG gbfaDNmiGQys2wWRZZYES8fHzC3driUVLhheXbtQiZFzrb2VqP7trkhs0dPhcHfj7YW1bvwUUCm9 XXxZ4kaM3WPTFJBDKFlMzdbIe9mKzrSCoIA8eOCkNuRlLgA6rA/K2eBozp95lkYrdL5MkgLoJ9G/ KL6rGIkk7cRk8QDnv0xQVWo25TdP6id1dq/effxGRTTAdt3Xoarr7+nHuE+R5OGgEYYe4xJaTNTJ +kcVwytfJhV84ksZwFvsGSvkLXB157ECAwEAAaMzMDEwIQYDVR0RBBowGIEWY29udGFjdEBuaWNr c2hhbmtzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABYqeMPReruBbl6mBzAJ 85r3PdVYHBNVrEt7wzsI1jUutUMHHbAJQS6V8V6syQK1d98bSUgHN33x+PwEM30d0u9qcAbJYD3Y B7jo5AkgKEWGDXWbfiEsBhHISUMc6fTRm+5WwoqM1VFrJhERsT5Q/nPdDA7Tqft3It9CYRoMgdx6 MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpU hQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxD QS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+q LZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBiqmax7lD9MrWu/Tb6Z/6uMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4 MDEwODA5MjkxN1owIwYJKoZIhvcNAQkEMRYEFIwlFL6LsDy8KzWuAFsnKaUGaHDNMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQYqpm se5Q/TK1rv02+mf+rjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQYqpmse5Q/TK1rv02+mf+rjANBgkqhkiG9w0BAQEFAASCAQBb kJUBswTakxsLWDTFmbVUOEv1RyfEqqMzmcz8unFKMUojzzBrg4T0f1y+HNgVWahlZ6Uk3WynxpXk Q9pQDOUe653tXYNuT19CTfFhOeqXcDDODFrOYp4eJ6LseoDAXT5/PNi2+h7T3DONZYWFYwFLKOCT +9zQaMQgVtwLhzxbSN8pCsLJRk5oPyxEmaYFEun4rasZj2LcyYCgpBCPSIy4m3QNDmZie8Ji6Xrn Krq/u99NqMwGZE8559hvjLSEb8pkopHh/z58ifuLlEOJ4Olu6OdtgRe0KpQhli3jcQyYNeRF/mBT TvI5RAYTHxYTvrmk8YQM5X7hHE0gHni8h3fSAAAAAAAA --Apple-Mail-10-286541796-- --===============1923661635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1923661635==-- From ltru-bounces@ietf.org Tue Jan 08 05:15:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBUC-0007ua-8m; Tue, 08 Jan 2008 05:15:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCBUA-0007uV-Ru for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBUA-0007uN-I8 for ltru@lists.ietf.org; Tue, 08 Jan 2008 05:15:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCBU8-0004PX-Pw for ltru@lists.ietf.org; Tue, 08 Jan 2008 05:15:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JCBU2-0004lf-Ru for ltru@lists.ietf.org; Tue, 08 Jan 2008 10:14:58 +0000 Received: from c-180-160-29.hh.dial.de.ignite.net ([62.180.160.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2008 10:14:58 +0000 Received: from nobody by c-180-160-29.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2008 10:14:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Tue, 8 Jan 2008 11:15:08 +0100 Organization: Lines: 22 Message-ID: References: <005501c84eed$a0579850$6501a8c0@DGBP7M81><477E6409.5060300@yahoo-inc.com><000f01c84f31$f8f29b60$6801a8c0@oemcomputer><20080108090623.GA18206@nic.fr> <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-29.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicholas Shanks wrote: > I'll wager that those using de-FR, als and so on are not even > looking at the registry, and probably don't know it exists. "de-FR" and "als" are rather different, the latter is just wrong. The former was a sound workaround for Alsatian before the new=20 "gsw" was introduced (2006), and until everybody learns that it exists, and that it's supposed to encompass Alsatian. =20 "de-FR" is still a good workaround for any German language used in France if the tagger has no clue which of these languages it is - Alsatian isn't the only game in twown ;-) =20 contains some examples, in this or another article I found that the=20 German language spoken in Strasbourg is neither "Franconian" nor "Alemanic" but a variant of "High German". St=E9phane picked an interesting can of worms with his proposal. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 11:29:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHKc-0002To-CU; Tue, 08 Jan 2008 11:29:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCHKa-00022v-BS for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:29:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHKY-0001yw-HT for ltru@ietf.org; Tue, 08 Jan 2008 11:29:34 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCHKY-0007l6-25 for ltru@ietf.org; Tue, 08 Jan 2008 11:29:34 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 8 Jan 2008 08:29:33 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Tue, 8 Jan 2008 08:29:33 -0800 From: Peter Constable To: LTRU Working Group Date: Tue, 8 Jan 2008 08:29:31 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: AchRvuoDLB1wBeaeQVGgGTIXfLcsuAAVHh1A Message-ID: References: <001901c851b6$9ed84350$6501a8c0@DGBP7M81> <20080108062252.GF27859@mercury.ccil.org> In-Reply-To: <20080108062252.GF27859@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 > > Am I correct in thinking the group will want to delay 4645bis again > for > > this? > > I don't see why. It has no structural effect, and it's just a matter > of 34 name changes later. I agree: there's no reason for delaying 4646bis for this, unless someone th= inks we need some text somewhere pertaining to collections or stability tha= t could not take effect until the change is made in ISO 639-2. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 12:39:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCIPl-0006SA-3t; Tue, 08 Jan 2008 12:39:01 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCIPk-0006Pl-BB for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCIPk-0006PP-1M for ltru@ietf.org; Tue, 08 Jan 2008 12:39:00 -0500 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCIPj-0004bM-KZ for ltru@ietf.org; Tue, 08 Jan 2008 12:39:00 -0500 Received: by wx-out-0506.google.com with SMTP id s8so3389412wxc.31 for ; Tue, 08 Jan 2008 09:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=3DH/nO5yP8sFHPBCfi9FTAn14MJ9jg2NDSc+NsZe1N4=; b=xxPKLwzxQbIpxx5WU0vOPNEKDmx38inEfzSHQdufF5HRZpGsmFLHN+FTShkHSSTO6sS+bNJlugIpTXH+kBOfy4EFRz0UyYq0q/E2Rmgl6k9AnQQl8dp5ByoMzg6rl56NHIKww8qTv4HbXDNjTv3F0jEPhVZFgpXHRaXlAgvqGtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=xDRJzVOI/Kk57xeXEquRnakgySVrQTwUrClugGRivHvWIfILyuNe1l2M+cAyZrsK9F1QHtwzWhzuL7TyO71PoslIApbEK34SClwX7HbVk/fJMUZffyfbEU0pkyP5VKCpMAhK5SzyWF2G0p4HhYk0NciB5GlHpqE8JBOZTrZz1HU= Received: by 10.142.89.9 with SMTP id m9mr389305wfb.116.1199813938648; Tue, 08 Jan 2008 09:38:58 -0800 (PST) Received: by 10.143.8.19 with HTTP; Tue, 8 Jan 2008 09:38:58 -0800 (PST) Message-ID: <30b660a20801080938x64156fbfgb4ad57cbc4ed9c15@mail.gmail.com> Date: Tue, 8 Jan 2008 09:38:58 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: action item: "other" collections in 639 In-Reply-To: MIME-Version: 1.0 References: <001901c851b6$9ed84350$6501a8c0@DGBP7M81> <20080108062252.GF27859@mercury.ccil.org> X-Google-Sender-Auth: c265409c6aed8c0f 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: , Content-Type: multipart/mixed; boundary="===============1081857928==" Errors-To: ltru-bounces@ietf.org --===============1081857928== Content-Type: multipart/alternative; boundary="----=_Part_44073_26739067.1199813938643" ------=_Part_44073_26739067.1199813938643 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed -- no need to delay; since we know this change is coming we can just make sure the wording is neutral. Mark On Jan 8, 2008 8:29 AM, Peter Constable wrote: > > From: John Cowan > > > > Am I correct in thinking the group will want to delay 4645bis again > > for > > > this? > > > > I don't see why. It has no structural effect, and it's just a matter > > of 34 name changes later. > > I agree: there's no reason for delaying 4646bis for this, unless someone > thinks we need some text somewhere pertaining to collections or stability > that could not take effect until the change is made in ISO 639-2. > > > > Peter > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_44073_26739067.1199813938643 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed -- no need to delay; since we know this change is coming we can just make sure the wording is neutral.

Mark

On Jan 8, 2008 8:29 AM, Peter Constable < petercon@microsoft.com> wrote:
> From: John Cowan

> > Am I correct in thinking the group will want to delay 4645bis again
> for
> > this?
>
> I don't see why.  It has no structural effect, and it's just a matter
> of 34 name changes later.

I agree: there's no reason for delaying 4646bis for this, unless someone thinks we need some text somewhere pertaining to collections or stability that could not take effect until the change is made in ISO 639-2.



Peter


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



--
Mark ------=_Part_44073_26739067.1199813938643-- --===============1081857928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1081857928==-- From ltru-bounces@ietf.org Tue Jan 08 14:03:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJjN-00062H-8Q; Tue, 08 Jan 2008 14:03:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCJjM-000625-3e for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 14:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJjL-00061s-Pn for ltru@lists.ietf.org; Tue, 08 Jan 2008 14:03:19 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCJj9-0005tc-3Y for ltru@lists.ietf.org; Tue, 08 Jan 2008 14:03:19 -0500 Received: by rv-out-0910.google.com with SMTP id k20so7555095rvb.1 for ; Tue, 08 Jan 2008 11:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0wLwA8axkU2S8FWGku7FCvj8SiFc/VHVjLghS7w6vFw=; b=M0+pV1Kqzpq6Opxm1rNg9UUp3cTMha4FD+XbqxfF8KvyWEx/U1uSS0/04KPE/8YSZn6K5jloMNIFrphvvbIHc9KxfosfuCiEwulLJ7nk67YRdvLbl3+XuVJlBX5fZl0FIe94ul1e0+YV7seNe6ZLKOcYWTDZl91UmWvkCyn+1K0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=l6KhpAbIof03Aqv/vLo5rpUBNPbleeIue+gNzwF3X8E8CuPHUHwKWJWRHd8GE5xJaej2g+1jp6+eJwk9oh+m9CwHAlFLDS8qVBSRrmZ8rr15gO9u/j7QTCH/8033qMnlPT0PSaSlIe6JWbp1V5ZZnqecVPNGYngCi2IVo+NlmUg= Received: by 10.140.172.6 with SMTP id u6mr11601984rve.257.1199818984576; Tue, 08 Jan 2008 11:03:04 -0800 (PST) Received: by 10.140.166.2 with HTTP; Tue, 8 Jan 2008 11:03:04 -0800 (PST) Message-ID: <5b0cbc7c0801081103h20eecb72o331d8e57e571522d@mail.gmail.com> Date: Tue, 8 Jan 2008 20:03:04 +0100 From: LB To: "Frank Ellermann" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0307795346==" Errors-To: ltru-bounces@ietf.org --===============0307795346== Content-Type: multipart/alternative; boundary="----=_Part_9001_2524498.1199818984570" ------=_Part_9001_2524498.1199818984570 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To avoid resuming the 1870 war, could it be agreed that: 1. linguistics is not an exact science 2. several langtags can refer to the same language name, content, classification, filtering, locale file, ... whatever they are used for? 3. the authoritative reference is the locutor/allocutor couple? What is discussed here belongs to local documentation organization (langtag= s concatenation), not to IETF protocols. The RFC should simply explain how al= l the possible forms of tagging can be handled at local application layer. Ho= w new real life tagging can be discovered and supported. IMHO going any further leads to being trapped into nationalistic issues, as expressed by Frank. They may have local but have no global legitimacy. 2008/1/8, Frank Ellermann : > > Nicholas Shanks wrote: > > > I'll wager that those using de-FR, als and so on are not even > > looking at the registry, and probably don't know it exists. > > "de-FR" and "als" are rather different, the latter is just wrong. > > The former was a sound workaround for Alsatian before the new > "gsw" was introduced (2006), and until everybody learns that it > exists, and that it's supposed to encompass Alsatian. > > "de-FR" is still a good workaround for any German language used > in France if the tagger has no clue which of these languages it > is - Alsatian isn't the only game in twown ;-) > > contains > some examples, in this or another article I found that the > German language spoken in Strasbourg is neither "Franconian" > nor "Alemanic" but a variant of "High German". St=E9phane picked > an interesting can of worms with his proposal. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > --=20 LB ------=_Part_9001_2524498.1199818984570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To avoid resuming the 1870 war, could it be agreed that:

1. linguist= ics is not an exact science
2. several langtags can refer to the same language name, content, classification, filtering, locale file, ... whatever they are used for?
3. the authoritative reference is the locutor/allocutor couple?

= What is discussed here belongs to local documentation organization (langtags concatenation), not to IETF protocols. The RFC should simply explain how all the possible forms of tagging can be handled at local application layer. How new real life tagging can be discovered and supported. IMHO going any further leads to being trapped into nationalistic issues, as expressed by Frank. They may have local but have no global legitimacy.


200= 8/1/8, Frank Ellermann <nobo= dy@xyzzy.claranet.de>:
Nicholas Shanks wrote:

> I'll wager that those using de-FR, a= ls and so on are not even
> looking at the registry, and probably don= 't know it exists.

"de-FR" and "als" are rat= her different, the latter is just wrong.

The former was a sound workaround for Alsatian before the new
&q= uot;gsw" was introduced (2006), and until everybody learns that it
= exists, and that it's supposed to encompass Alsatian.

"de-F= R" is still a good workaround for any German language used
in France if the tagger has no clue which of these languages it
is -= Alsatian isn't the only game in twown ;-)

<http://en.wikipedia.org/wiki/F= ranconian_languages > contains
some examples, in this or another article I found that= the
German language spoken in Strasbourg is neither "Franconian&qu= ot;
nor "Alemanic" but a variant of "High German".&n= bsp; St=E9phane picked
an interesting can of worms with his proposal.

Frank


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

<= br clear=3D"all">
--
LB ------=_Part_9001_2524498.1199818984570-- --===============0307795346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0307795346==-- From ltru-bounces@ietf.org Tue Jan 08 14:27:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCK6q-0004CE-L9; Tue, 08 Jan 2008 14:27:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCK6o-00049W-Qg for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 14:27:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCK6o-00048U-Ez for ltru@ietf.org; Tue, 08 Jan 2008 14:27:34 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCK6m-0004cr-Cf for ltru@ietf.org; Tue, 08 Jan 2008 14:27:33 -0500 Received: by wx-out-0506.google.com with SMTP id s8so3434048wxc.31 for ; Tue, 08 Jan 2008 11:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=yfzlOwSb4sXGO1i1dDo2U7dQwBmrO76wDj8uqhY1f7g=; b=rdrxbYYXpZ0qDhNtzYmAt/IEG+eGnpo75N/sy4elzP7fKU28Mvw9kW5rUqgFn62hoaB50iQ3eLGhEyGLM+MaHRRW1yvyAYz/XCS+qYrrr9Xl5+UeGsKPNic87q/rRHBBV8XUu1TfCdFcw9Kfc6NsurBRYzsipKVr1IYTFS1aYi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=nW/CNhPjTQg4zrvv9G9G9xjUGdKN7W88u2YYXDGLU8TmEQdM7fNx/RFVVRdMKyrBPFV9Qy6FElUhnh8g4QNr+HYhZIICiMhHrENCgkXpKwr77XclQ8768J+g7dBMtGEnTbrPs9SWv41A0E3mcVm9nJ7AyHJwTC0+gmptWiXeeUo= Received: by 10.143.161.3 with SMTP id n3mr5085109wfo.32.1199820451147; Tue, 08 Jan 2008 11:27:31 -0800 (PST) Received: by 10.143.8.19 with HTTP; Tue, 8 Jan 2008 11:27:31 -0800 (PST) Message-ID: <30b660a20801081127o6bef17c7g70e7ecc655967dd9@mail.gmail.com> Date: Tue, 8 Jan 2008 11:27:31 -0800 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: <20080108090623.GA18206@nic.fr> MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> X-Google-Sender-Auth: e3623d2b70fad715 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992420350==" Errors-To: ltru-bounces@ietf.org --===============0992420350== Content-Type: multipart/alternative; boundary="----=_Part_44794_23027589.1199820451104" ------=_Part_44794_23027589.1199820451104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline gsw faces the same issue that encompassed languages from 639-3 do. That is, "de" meaning German was the only available tag, so de-CH was ambiguous: meaning either - Swiss High German (High German as used in Switzerland), OR - Swiss German (Schwytzerduetsch) Then -- and not so long ago: 2006-03-08 -- gsw was introduced for Swiss German (and broadened to mean any Alemanic despite the letters). From that point in time, ideally de-CH would be used only for Swiss High German, and gsw-CH unambiguously means Swiss German. However, applications that deal with incoming tags need to be cognizant of the fact that a de-CH may be ambiguous, either because content was tagged before 2006, or because people didn't realize after 2006 that gsw was available, and how it should be used. The registry (and the source standards) do not make this situation clear. The relevant records are merely: Type: language Subtag: de Description: German Added: 2005-10-16 Suppress-Script: Latn Type: language Subtag: gsw Description: Swiss German Description: Alemannic Added: 2006-03-08 Suppress-Script: Latn In my opinion, the goal of all the descriptions and comments are to provide *all and only* the minimal information needed to help people chose the appropriate tag. That is, we don't want the description to be the wikipedia article on the language, but we do want and need to provide enough information so that if someone is faced with two possible plausible choices of tags, the information disambiguates that choice. Thus we should add comments and/or descriptions to the language-subtag-registry where we need to make situations like this clear. For example, we could add to de: Comment: For Alemanic (including Alsatian and Swiss German), see gsw. and to gsw: Comment: gsw-FR is used for varieties of Alemanic as used in France, notably Alsatian. Similarly, gsw-CH is used for Swiss German (where it needs to be distinguished from other forms of Alemanic). Mark On Jan 8, 2008 1:06 AM, Stephane Bortzmeyer wrote: > On Fri, Jan 04, 2008 at 04:29:01PM -0800, > Randy Presuhn wrote > a message of 83 lines which said: > > > 2) There may be cases where the correct tag for a particular > > language may not be immediately obvious from the data in the > > registry. > > IMHO, that's the big issue we have with the "alsatian" registration > request. How to help people find the tag when the name they use for > their language is not in the registry? > > > I can see several possible responses: > ... > > c) leave the documentation of such cases to others > > How do you ensure consistency in that case? Today, some people tag > alsatian as "de-FR", some (very rare, apparently) as "gsw-FR", some as > "gsw-x-alsatian" and some as the (invalid) "gsw-alsatian" or > "alsatian" or "als". > > It seems that, for consistent tagging, we need one (1) authoritative > source (wether it is the LSR or a yet-to-be-done companion registry). > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_44794_23027589.1199820451104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline gsw faces the same issue that encompassed languages from 639-3 do. That is, "de" meaning German was the only available tag, so de-CH was ambiguous: meaning either
  • Swiss High German (High German as used in Switzerland), OR
  • Swiss German (Schwytzerduetsch)
Then -- and not so long ago: 2006-03-08 -- gsw was introduced for Swiss German (and broadened to mean any Alemanic despite the letters). From that point in time, ideally de-CH would be used only for Swiss High German, and gsw-CH unambiguously means Swiss German.

However, applications that deal with incoming tags need to be cognizant of the fact that a de-CH may be ambiguous, either because content was tagged before 2006, or because people didn't realize after 2006 that gsw was available, and how it should be used. The registry (and the source standards) do not make this situation clear.

The relevant records are merely:

Type: language
Subtag: de
Description: German
Added: 2005-10-16
Suppress-Script: Latn
Type: language
Subtag: gsw
Description: Swiss German

Description: Alemannic
Added: 2006-03-08
Suppress-Script: Latn

In my opinion, the goal of all the descriptions and comments are to provide all and only the minimal information needed to help people chose the appropriate tag. That is, we don't want the description to be the wikipedia article on the language, but we do want and need to provide enough information so that if someone is faced with two possible plausible choices of tags, the information disambiguates that choice. Thus we should add comments and/or descriptions to the language-subtag-registry where we need to make situations like this clear. For example, we could add to de:

Comment: For Alemanic (including Alsatian and Swiss German), see gsw.

and to gsw:

Comment: gsw-FR is used for varieties of Alemanic as used in France, notably Alsatian. Similarly, gsw-CH is used for Swiss German (where it needs to be distinguished from other forms of Alemanic).

Mark

On Jan 8, 2008 1:06 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Fri, Jan 04, 2008 at 04:29:01PM -0800,
 Randy Presuhn <randy_presuhn@mindspring.com> wrote
 a message of 83 lines which said:

>     2) There may be cases where the correct tag for a particular
>     language may not be immediately obvious from the data in the
>     registry.

IMHO, that's the big issue we have with the "alsatian" registration
request. How to help people find the tag when the name they use for
their language is not in the registry?

> I can see several possible responses:
...
>            c) leave the documentation of such cases to others

How do you ensure consistency in that case? Today, some people tag
alsatian as "de-FR", some (very rare, apparently) as "gsw-FR", some as
"gsw-x-alsatian" and some as the (invalid) "gsw-alsatian" or
"alsatian" or "als".

It seems that, for consistent tagging, we need one (1) authoritative
source (wether it is the LSR or a yet-to-be-done companion registry).


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



--
Mark ------=_Part_44794_23027589.1199820451104-- --===============0992420350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0992420350==-- From ltru-bounces@ietf.org Tue Jan 08 14:52:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKUz-0008OX-Ru; Tue, 08 Jan 2008 14:52:33 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCKUy-0008OQ-Bj for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 14:52:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKUy-0008OI-21 for ltru@ietf.org; Tue, 08 Jan 2008 14:52:32 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCKUw-0007Tp-Hi for ltru@ietf.org; Tue, 08 Jan 2008 14:52:31 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=j4ZXBaGxFBlpjVVADqY4I9X4aWm0+F4FmMwQGXFa+CqwjUFj7X369GR5cUyjW74O; 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.87] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JCKUv-00005B-OZ for ltru@ietf.org; Tue, 08 Jan 2008 14:52:30 -0500 Message-ID: <00fd01c85230$2b64e700$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005501c84eed$a0579850$6501a8c0@DGBP7M81><477E6409.5060300@yahoo-inc.com><000f01c84f31$f8f29b60$6801a8c0@oemcomputer><20080108090623.GA18206@nic.fr><5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> <5b0cbc7c0801081103h20eecb72o331d8e57e571522d@mail.gmail.com> Subject: Re: [Ltru] Re: Description on tags, not just subtags? Date: Tue, 8 Jan 2008 11:53:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a59aed16f5e25957850438b78906774c7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.87 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 Hi - As a technical contributor... > From: "LB" > To: "Frank Ellermann" > Cc: > Sent: Tuesday, January 08, 2008 11:03 AM > Subject: Re: [Ltru] Re: Description on tags, not just subtags? > > To avoid resuming the 1870 war, could it be agreed that: ... > 2. several langtags can refer to the same language name, content, > classification, filtering, locale file, ... whatever they are used for? No. Having multiple distinct (not merely more-precise and less-precise) language tags for the same language would be a very bad thing. The fact that the same string might be well-formed both when understood as a language tag or when understoof as a locale does not mean that it *is* both. > 3. the authoritative reference is the locutor/allocutor couple? No. The entity tagging the data makes its decision how to tag the data. That decision may be incorrect, and another entity may choose to ignore that tag an apply some other. > What is discussed here belongs to local documentation organization (langtags > concatenation), not to IETF protocols. Disagree. The semantics of tag composition from subtags is very much within this group's domain. > The RFC should simply explain how all the possible forms of tagging can > be handled at local application layer. How new real life tagging can be > discovered and supported. IMHO going any further leads to being trapped > into nationalistic issues, as expressed by Frank. They may have local but > have no global legitimacy. The discussion of specific registration requests is not handled on this list. However, discussing specific *examples* can be very helpful in the identification of issues and learning how principles might be best applied. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 16:02:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLam-0005mb-VN; Tue, 08 Jan 2008 16:02:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCLal-0005lM-16 for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 16:02:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLak-0005j8-Ho for ltru@ietf.org; Tue, 08 Jan 2008 16:02:34 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCLaj-0006cY-Bk for ltru@ietf.org; Tue, 08 Jan 2008 16:02:34 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 8 Jan 2008 13:02:28 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Tue, 8 Jan 2008 13:02:32 -0800 From: Peter Constable To: LTRU Working Group Date: Tue, 8 Jan 2008 13:02:30 -0800 Subject: RE: [Ltru] Re: Description on tags, not just subtags? Thread-Topic: [Ltru] Re: Description on tags, not just subtags? Thread-Index: AchSLI/rK8Sy0OrxQeWojnWm7t74MAADL8iQ Message-ID: References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <30b660a20801081127o6bef17c7g70e7ecc655967dd9@mail.gmail.com> In-Reply-To: <30b660a20801081127o6bef17c7g70e7ecc655967dd9@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0043588401==" Errors-To: ltru-bounces@ietf.org --===============0043588401== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1B5CNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1B5CNAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIGdzdyB3YXMgaW50cm9kdWNlZCBmb3IgU3dpc3MgR2VybWFuIChhbmQgYnJvYWRlbmVkIHRv IG1lYW4gYW55IEFsZW1hbmljIGRlc3BpdGUgdGhlIGxldHRlcnMpDQoNCkNsYXJpZmljYXRpb246 IGdzdyB3YXMgaW50cm9kdWNlZCB3aXRoIHRoZSBzZW1hbnRpYyBkb2N1bWVudGVkIGJ5IHRoZSBJ U08gNjM5LTMgUkEsIHdoaWNoIGluIHR1cm4gaXMgYSBwb2ludGVyIHRvIHRoZSBFdGhub2xvZ3Vl IDE1IGVudHJ5IGZvciBnc3cuIElJUkMsIHRoYXQgZGlkIG5vdCBjaGFuZ2UgYmVmb3JlIG9yIHNp bmNlIGdzdyB3YXMgaW50cm9kdWNlZCBpbnRvIHRoZSBMU1RSOyBpdCBhbHdheXMgaW5jbHVkZWQg KGZvciBpbnN0YW5jZSkg4oCcQWxzYXRpYW7igJ0gKHRoZSBBbGxlbWFuaWMgdmFyaWV0eSBzcG9r ZW4gcHJpbWFyaWx5IGluIEFsc2FjZSksIGFuZCBpdCBhbHdheXMgZXhjbHVkZWQgKGZvciBpbnN0 YW5jZSkg4oCcU3dhYmlhbuKAnS4NCg0KDQpQZXRlcg0KDQpGcm9tOiBNYXJrIERhdmlzIFttYWls dG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA4 LCAyMDA4IDExOjI4IEFNDQpUbzogU3RlcGhhbmUgQm9ydHptZXllcg0KQ2M6IExUUlUgV29ya2lu ZyBHcm91cA0KU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogRGVzY3JpcHRpb24gb24gdGFncywgbm90 IGp1c3Qgc3VidGFncz8NCg0KZ3N3IGZhY2VzIHRoZSBzYW1lIGlzc3VlIHRoYXQgZW5jb21wYXNz ZWQgbGFuZ3VhZ2VzIGZyb20gNjM5LTMgZG8uIFRoYXQgaXMsICJkZSIgbWVhbmluZyBHZXJtYW4g d2FzIHRoZSBvbmx5IGF2YWlsYWJsZSB0YWcsIHNvIGRlLUNIIHdhcyBhbWJpZ3VvdXM6IG1lYW5p bmcgZWl0aGVyDQoNCiAqICAgU3dpc3MgSGlnaCBHZXJtYW4gKEhpZ2ggR2VybWFuIGFzIHVzZWQg aW4gU3dpdHplcmxhbmQpLCBPUg0KICogICBTd2lzcyBHZXJtYW4gKFNjaHd5dHplcmR1ZXRzY2gp DQpUaGVuIC0tIGFuZCBub3Qgc28gbG9uZyBhZ286IDIwMDYtMDMtMDggLS0gZ3N3IHdhcyBpbnRy b2R1Y2VkIGZvciBTd2lzcyBHZXJtYW4gKGFuZCBicm9hZGVuZWQgdG8gbWVhbiBhbnkgQWxlbWFu aWMgZGVzcGl0ZSB0aGUgbGV0dGVycykuIEZyb20gdGhhdCBwb2ludCBpbiB0aW1lLCBpZGVhbGx5 IGRlLUNIIHdvdWxkIGJlIHVzZWQgb25seSBmb3IgU3dpc3MgSGlnaCBHZXJtYW4sIGFuZCBnc3ct Q0ggdW5hbWJpZ3VvdXNseSBtZWFucyBTd2lzcyBHZXJtYW4uDQoNCkhvd2V2ZXIsIGFwcGxpY2F0 aW9ucyB0aGF0IGRlYWwgd2l0aCBpbmNvbWluZyB0YWdzIG5lZWQgdG8gYmUgY29nbml6YW50IG9m IHRoZSBmYWN0IHRoYXQgYSBkZS1DSCBtYXkgYmUgYW1iaWd1b3VzLCBlaXRoZXIgYmVjYXVzZSBj b250ZW50IHdhcyB0YWdnZWQgYmVmb3JlIDIwMDYsIG9yIGJlY2F1c2UgcGVvcGxlIGRpZG4ndCBy ZWFsaXplIGFmdGVyIDIwMDYgdGhhdCBnc3cgd2FzIGF2YWlsYWJsZSwgYW5kIGhvdyBpdCBzaG91 bGQgYmUgdXNlZC4gVGhlIHJlZ2lzdHJ5IChhbmQgdGhlIHNvdXJjZSBzdGFuZGFyZHMpIGRvIG5v dCBtYWtlIHRoaXMgc2l0dWF0aW9uIGNsZWFyLg0KDQpUaGUgcmVsZXZhbnQgcmVjb3JkcyBhcmUg bWVyZWx5Og0KDQpUeXBlOiBsYW5ndWFnZQ0KDQpTdWJ0YWc6IGRlDQoNCkRlc2NyaXB0aW9uOiBH ZXJtYW4NCg0KQWRkZWQ6IDIwMDUtMTAtMTYNCg0KU3VwcHJlc3MtU2NyaXB0OiBMYXRuDQoNClR5 cGU6IGxhbmd1YWdlDQoNClN1YnRhZzogZ3N3DQoNCkRlc2NyaXB0aW9uOiBTd2lzcyBHZXJtYW4N Cg0KDQpEZXNjcmlwdGlvbjogQWxlbWFubmljDQoNCkFkZGVkOiAyMDA2LTAzLTA4DQoNClN1cHBy ZXNzLVNjcmlwdDogTGF0bg0KDQpJbiBteSBvcGluaW9uLCB0aGUgZ29hbCBvZiBhbGwgdGhlIGRl c2NyaXB0aW9ucyBhbmQgY29tbWVudHMgYXJlIHRvIHByb3ZpZGUgYWxsIGFuZCBvbmx5IHRoZSBt aW5pbWFsIGluZm9ybWF0aW9uIG5lZWRlZCB0byBoZWxwIHBlb3BsZSBjaG9zZSB0aGUgYXBwcm9w cmlhdGUgdGFnLiBUaGF0IGlzLCB3ZSBkb24ndCB3YW50IHRoZSBkZXNjcmlwdGlvbiB0byBiZSB0 aGUgd2lraXBlZGlhIGFydGljbGUgb24gdGhlIGxhbmd1YWdlLCBidXQgd2UgZG8gd2FudCBhbmQg bmVlZCB0byBwcm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBzbyB0aGF0IGlmIHNvbWVvbmUgaXMg ZmFjZWQgd2l0aCB0d28gcG9zc2libGUgcGxhdXNpYmxlIGNob2ljZXMgb2YgdGFncywgdGhlIGlu Zm9ybWF0aW9uIGRpc2FtYmlndWF0ZXMgdGhhdCBjaG9pY2UuIFRodXMgd2Ugc2hvdWxkIGFkZCBj b21tZW50cyBhbmQvb3IgZGVzY3JpcHRpb25zIHRvIHRoZSBsYW5ndWFnZS1zdWJ0YWctcmVnaXN0 cnkgd2hlcmUgd2UgbmVlZCB0byBtYWtlIHNpdHVhdGlvbnMgbGlrZSB0aGlzIGNsZWFyLiBGb3Ig ZXhhbXBsZSwgd2UgY291bGQgYWRkIHRvIGRlOg0KDQpDb21tZW50OiBGb3IgQWxlbWFuaWMgKGlu Y2x1ZGluZyBBbHNhdGlhbiBhbmQgU3dpc3MgR2VybWFuKSwgc2VlIGdzdy4NCg0KYW5kIHRvIGdz dzoNCg0KQ29tbWVudDogZ3N3LUZSIGlzIHVzZWQgZm9yIHZhcmlldGllcyBvZiBBbGVtYW5pYyBh cyB1c2VkIGluIEZyYW5jZSwgbm90YWJseSBBbHNhdGlhbi4gU2ltaWxhcmx5LCBnc3ctQ0ggaXMg dXNlZCBmb3IgU3dpc3MgR2VybWFuICh3aGVyZSBpdCBuZWVkcyB0byBiZSBkaXN0aW5ndWlzaGVk IGZyb20gb3RoZXIgZm9ybXMgb2YgQWxlbWFuaWMpLg0KDQpNYXJrDQpPbiBKYW4gOCwgMjAwOCAx OjA2IEFNLCBTdGVwaGFuZSBCb3J0em1leWVyIDxib3J0em1leWVyQG5pYy5mcjxtYWlsdG86Ym9y dHptZXllckBuaWMuZnI+PiB3cm90ZToNCk9uIEZyaSwgSmFuIDA0LCAyMDA4IGF0IDA0OjI5OjAx UE0gLTA4MDAsDQogUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbTxt YWlsdG86cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4+IHdyb3RlDQogYSBtZXNzYWdlIG9m IDgzIGxpbmVzIHdoaWNoIHNhaWQ6DQoNCj4gICAgIDIpIFRoZXJlIG1heSBiZSBjYXNlcyB3aGVy ZSB0aGUgY29ycmVjdCB0YWcgZm9yIGEgcGFydGljdWxhcg0KPiAgICAgbGFuZ3VhZ2UgbWF5IG5v dCBiZSBpbW1lZGlhdGVseSBvYnZpb3VzIGZyb20gdGhlIGRhdGEgaW4gdGhlDQo+ICAgICByZWdp c3RyeS4NCklNSE8sIHRoYXQncyB0aGUgYmlnIGlzc3VlIHdlIGhhdmUgd2l0aCB0aGUgImFsc2F0 aWFuIiByZWdpc3RyYXRpb24NCnJlcXVlc3QuIEhvdyB0byBoZWxwIHBlb3BsZSBmaW5kIHRoZSB0 YWcgd2hlbiB0aGUgbmFtZSB0aGV5IHVzZSBmb3INCnRoZWlyIGxhbmd1YWdlIGlzIG5vdCBpbiB0 aGUgcmVnaXN0cnk/DQoNCj4gSSBjYW4gc2VlIHNldmVyYWwgcG9zc2libGUgcmVzcG9uc2VzOg0K Li4uDQo+ICAgICAgICAgICAgYykgbGVhdmUgdGhlIGRvY3VtZW50YXRpb24gb2Ygc3VjaCBjYXNl cyB0byBvdGhlcnMNCkhvdyBkbyB5b3UgZW5zdXJlIGNvbnNpc3RlbmN5IGluIHRoYXQgY2FzZT8g VG9kYXksIHNvbWUgcGVvcGxlIHRhZw0KYWxzYXRpYW4gYXMgImRlLUZSIiwgc29tZSAodmVyeSBy YXJlLCBhcHBhcmVudGx5KSBhcyAiZ3N3LUZSIiwgc29tZSBhcw0KImdzdy14LWFsc2F0aWFuIiBh bmQgc29tZSBhcyB0aGUgKGludmFsaWQpICJnc3ctYWxzYXRpYW4iIG9yDQoiYWxzYXRpYW4iIG9y ICJhbHMiLg0KDQpJdCBzZWVtcyB0aGF0LCBmb3IgY29uc2lzdGVudCB0YWdnaW5nLCB3ZSBuZWVk IG9uZSAoMSkgYXV0aG9yaXRhdGl2ZQ0Kc291cmNlICh3ZXRoZXIgaXQgaXMgdGhlIExTUiBvciBh IHlldC10by1iZS1kb25lIGNvbXBhbmlvbiByZWdpc3RyeSkuDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1 QGlldGYub3JnPG1haWx0bzpMdHJ1QGlldGYub3JnPg0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydQ0KDQoNCg0KLS0NCk1hcmsNCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1B5CNAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg NCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQog QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzM1MTEwMDUxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoyMDM1OTQ0NzEwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6Mzg1NTczNDk4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczozNDIzNjU4NzQgNTg3ODk5MjcwIDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT4NCjwvc3R5bGU+ DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRp diBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz O2NvbG9yOiMxRjQ5N0QnPjxzcGFuDQpzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7DmDxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuDQpkaXI9TFRSPjwvc3Bhbj5nc3cgd2FzIGludHJvZHVjZWQg Zm9yIFN3aXNzIEdlcm1hbiAoYW5kIGJyb2FkZW5lZCB0byBtZWFuIGFueQ0KQWxlbWFuaWMgZGVz cGl0ZSB0aGUgbGV0dGVycyk8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz5DbGFyaWZpY2F0aW9uOiBnc3cgd2FzIGludHJvZHVjZWQgd2l0aCB0 aGUgc2VtYW50aWMgZG9jdW1lbnRlZA0KYnkgdGhlIElTTyA2MzktMyBSQSwgd2hpY2ggaW4gdHVy biBpcyBhIHBvaW50ZXIgdG8gdGhlIEV0aG5vbG9ndWUgMTUgZW50cnkgZm9yDQpnc3cuIElJUkMs IHRoYXQgZGlkIG5vdCBjaGFuZ2UgYmVmb3JlIG9yIHNpbmNlIGdzdyB3YXMgaW50cm9kdWNlZCBp bnRvIHRoZSBMU1RSOw0KaXQgYWx3YXlzIGluY2x1ZGVkIChmb3IgaW5zdGFuY2UpIOKAnEFsc2F0 aWFu4oCdICh0aGUgQWxsZW1hbmljIHZhcmlldHkgc3Bva2VuDQpwcmltYXJpbHkgaW4gQWxzYWNl KSwgYW5kIGl0IGFsd2F5cyBleGNsdWRlZCAoZm9yIGluc3RhbmNlKSDigJxTd2FiaWFu4oCdLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlBldGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1hcmsgRGF2 aXMNClttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddIDxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBKYW51YXJ5IDA4LCAyMDA4IDExOjI4IEFNPGJyPg0KPGI+VG86PC9iPiBTdGVw aGFuZSBCb3J0em1leWVyPGJyPg0KPGI+Q2M6PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtMdHJ1XSBSZTogRGVzY3JpcHRpb24gb24gdGFncywgbm90IGp1 c3Qgc3VidGFncz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+Z3N3IGZhY2VzIHRoZSBzYW1lIGlzc3VlIHRoYXQgZW5jb21wYXNzZWQgbGFuZ3VhZ2Vz IGZyb20NCjYzOS0zIGRvLiBUaGF0IGlzLCAmcXVvdDtkZSZxdW90OyBtZWFuaW5nIEdlcm1hbiB3 YXMgdGhlIG9ubHkgYXZhaWxhYmxlIHRhZywgc28NCmRlLUNIIHdhcyBhbWJpZ3VvdXM6IG1lYW5p bmcgZWl0aGVyPG86cD48L286cD48L3A+DQoNCjx1bCB0eXBlPWRpc2M+DQogPGxpIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQogICAgIG1zby1saXN0OmwwIGxldmVsMSBsZm8xJz5Td2lzcyBIaWdoIEdlcm1h biAoSGlnaCBHZXJtYW4gYXMgdXNlZCBpbg0KICAgICBTd2l0emVybGFuZCksIE9SIDxvOnA+PC9v OnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPlN3aXNzIEdlcm1hbiAoU2Nod3l0emVyZHVldHNjaCk8bzpwPjwvbzpwPjwvbGk+DQo8 L3VsPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5U aGVuIC0tIGFuZCBub3Qgc28gbG9uZyBhZ286DQoyMDA2LTAzLTA4IC0tIGdzdyB3YXMgaW50cm9k dWNlZCBmb3IgU3dpc3MgR2VybWFuIChhbmQgYnJvYWRlbmVkIHRvIG1lYW4gYW55DQpBbGVtYW5p YyBkZXNwaXRlIHRoZSBsZXR0ZXJzKS4gRnJvbSB0aGF0IHBvaW50IGluIHRpbWUsIGlkZWFsbHkg ZGUtQ0ggd291bGQgYmUNCnVzZWQgb25seSBmb3IgU3dpc3MgSGlnaCBHZXJtYW4sIGFuZCBnc3ct Q0ggdW5hbWJpZ3VvdXNseSBtZWFucyBTd2lzcyBHZXJtYW4uIDxicj4NCjxicj4NCkhvd2V2ZXIs IGFwcGxpY2F0aW9ucyB0aGF0IGRlYWwgd2l0aCBpbmNvbWluZyB0YWdzIG5lZWQgdG8gYmUgY29n bml6YW50IG9mIHRoZQ0KZmFjdCB0aGF0IGEgZGUtQ0ggbWF5IGJlIGFtYmlndW91cywgZWl0aGVy IGJlY2F1c2UgY29udGVudCB3YXMgdGFnZ2VkIGJlZm9yZQ0KMjAwNiwgb3IgYmVjYXVzZSBwZW9w bGUgZGlkbid0IHJlYWxpemUgYWZ0ZXIgMjAwNiB0aGF0IGdzdyB3YXMgYXZhaWxhYmxlLCBhbmQN CmhvdyBpdCBzaG91bGQgYmUgdXNlZC4gVGhlIHJlZ2lzdHJ5IChhbmQgdGhlIHNvdXJjZSBzdGFu ZGFyZHMpIGRvIG5vdCBtYWtlIHRoaXMNCnNpdHVhdGlvbiBjbGVhci4gPGJyPg0KPGJyPg0KVGhl IHJlbGV2YW50IHJlY29yZHMgYXJlIG1lcmVseTo8bzpwPjwvbzpwPjwvcD4NCg0KPHByZT5UeXBl OiBsYW5ndWFnZTxicj4NClN1YnRhZzogZGU8YnI+DQpEZXNjcmlwdGlvbjogR2VybWFuPGJyPg0K QWRkZWQ6IDIwMDUtMTAtMTY8YnI+DQpTdXBwcmVzcy1TY3JpcHQ6IExhdG48bzpwPjwvbzpwPjwv cHJlPjxwcmU+VHlwZTogbGFuZ3VhZ2U8YnI+DQpTdWJ0YWc6IGdzdzxicj4NCkRlc2NyaXB0aW9u OiBTd2lzcyBHZXJtYW48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGJyPg0KRGVzY3JpcHRpb246IEFs ZW1hbm5pYzxicj4NCkFkZGVkOiAyMDA2LTAzLTA4PGJyPg0KU3VwcHJlc3MtU2NyaXB0OiBMYXRu PG86cD48L286cD48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90 dG9tOjEyLjBwdCc+PGJyPg0KSW4gbXkgb3BpbmlvbiwgdGhlIGdvYWwgb2YgYWxsIHRoZSBkZXNj cmlwdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB0byBwcm92aWRlIDxpPmFsbA0KYW5kIG9ubHk8L2k+ IHRoZSBtaW5pbWFsIGluZm9ybWF0aW9uIG5lZWRlZCB0byBoZWxwIHBlb3BsZSBjaG9zZSB0aGUN CmFwcHJvcHJpYXRlIHRhZy4gVGhhdCBpcywgd2UgZG9uJ3Qgd2FudCB0aGUgZGVzY3JpcHRpb24g dG8gYmUgdGhlIHdpa2lwZWRpYQ0KYXJ0aWNsZSBvbiB0aGUgbGFuZ3VhZ2UsIGJ1dCB3ZSBkbyB3 YW50IGFuZCBuZWVkIHRvIHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uDQpzbyB0aGF0IGlmIHNv bWVvbmUgaXMgZmFjZWQgd2l0aCB0d28gcG9zc2libGUgcGxhdXNpYmxlIGNob2ljZXMgb2YgdGFn cywgdGhlDQppbmZvcm1hdGlvbiBkaXNhbWJpZ3VhdGVzIHRoYXQgY2hvaWNlLiBUaHVzIHdlIHNo b3VsZCBhZGQgY29tbWVudHMgYW5kL29yDQpkZXNjcmlwdGlvbnMgdG8gdGhlIGxhbmd1YWdlLXN1 YnRhZy1yZWdpc3RyeSB3aGVyZSB3ZSBuZWVkIHRvIG1ha2Ugc2l0dWF0aW9ucw0KbGlrZSB0aGlz IGNsZWFyLiBGb3IgZXhhbXBsZSwgd2UgY291bGQgYWRkIHRvIGRlOiA8YnI+DQo8YnI+DQpDb21t ZW50OiBGb3IgQWxlbWFuaWMgKGluY2x1ZGluZyBBbHNhdGlhbiBhbmQgU3dpc3MgR2VybWFuKSwg c2VlIGdzdy48YnI+DQo8YnI+DQphbmQgdG8gZ3N3Ojxicj4NCjxicj4NCkNvbW1lbnQ6IGdzdy1G UiBpcyB1c2VkIGZvciB2YXJpZXRpZXMgb2YgQWxlbWFuaWMgYXMgdXNlZCBpbiBGcmFuY2UsIG5v dGFibHkNCkFsc2F0aWFuLiBTaW1pbGFybHksIGdzdy1DSCBpcyB1c2VkIGZvciBTd2lzcyBHZXJt YW4gKHdoZXJlIGl0IG5lZWRzIHRvIGJlDQpkaXN0aW5ndWlzaGVkIGZyb20gb3RoZXIgZm9ybXMg b2YgQWxlbWFuaWMpLiA8YnI+DQo8YnI+DQpNYXJrPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD5PbiBKYW4gOCwgMjAwOCAxOjA2IEFNLCBTdGVwaGFuZSBCb3J0 em1leWVyICZsdDs8YQ0KaHJlZj0ibWFpbHRvOmJvcnR6bWV5ZXJAbmljLmZyIj5ib3J0em1leWVy QG5pYy5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+T24gRnJpLCBKYW4gMDQsIDIwMDggYXQgMDQ6Mjk6MDFQTSAtMDgwMCw8YnI+DQombmJzcDtS YW5keSBQcmVzdWhuICZsdDs8YSBocmVmPSJtYWlsdG86cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5n LmNvbSI+cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbTwvYT4mZ3Q7DQp3cm90ZTxvOnA+PC9v OnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz4mbmJzcDthIG1lc3NhZ2Ugb2YgODMgbGluZXMNCndoaWNoIHNhaWQ6PGJyPg0K PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IDIpIFRoZXJlIG1heSBiZSBjYXNlcyB3aGVyZSB0aGUg Y29ycmVjdCB0YWcgZm9yIGEgcGFydGljdWxhcg0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGxh bmd1YWdlIG1heSBub3QgYmUgaW1tZWRpYXRlbHkgb2J2aW91cyBmcm9tIHRoZSBkYXRhIGluIHRo ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZWdpc3RyeS48bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JTUhPLCB0aGF0J3MgdGhlIGJpZyBpc3N1ZSB3ZSBo YXZlIHdpdGggdGhlDQomcXVvdDthbHNhdGlhbiZxdW90OyByZWdpc3RyYXRpb248YnI+DQpyZXF1 ZXN0LiBIb3cgdG8gaGVscCBwZW9wbGUgZmluZCB0aGUgdGFnIHdoZW4gdGhlIG5hbWUgdGhleSB1 c2UgZm9yIDxicj4NCnRoZWlyIGxhbmd1YWdlIGlzIG5vdCBpbiB0aGUgcmVnaXN0cnk/PG86cD48 L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQomZ3Q7IEkgY2Fu IHNlZSBzZXZlcmFsIHBvc3NpYmxlIHJlc3BvbnNlczo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4uLi48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtjKSBsZWF2ZSB0aGUgZG9jdW1lbnRh dGlvbiBvZiBzdWNoIGNhc2VzIHRvIG90aGVyczxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPkhvdyBkbyB5b3UgZW5zdXJlIGNvbnNpc3RlbmN5IGluIHRoYXQg Y2FzZT8gVG9kYXksIHNvbWUNCnBlb3BsZSB0YWc8YnI+DQphbHNhdGlhbiBhcyAmcXVvdDtkZS1G UiZxdW90Oywgc29tZSAodmVyeSByYXJlLCBhcHBhcmVudGx5KSBhcw0KJnF1b3Q7Z3N3LUZSJnF1 b3Q7LCBzb21lIGFzPGJyPg0KJnF1b3Q7Z3N3LXgtYWxzYXRpYW4mcXVvdDsgYW5kIHNvbWUgYXMg dGhlIChpbnZhbGlkKSAmcXVvdDtnc3ctYWxzYXRpYW4mcXVvdDsNCm9yIDxicj4NCiZxdW90O2Fs c2F0aWFuJnF1b3Q7IG9yICZxdW90O2FscyZxdW90Oy48YnI+DQo8YnI+DQpJdCBzZWVtcyB0aGF0 LCBmb3IgY29uc2lzdGVudCB0YWdnaW5nLCB3ZSBuZWVkIG9uZSAoMSkgYXV0aG9yaXRhdGl2ZTxi cj4NCnNvdXJjZSAod2V0aGVyIGl0IGlzIHRoZSBMU1Igb3IgYSB5ZXQtdG8tYmUtZG9uZSBjb21w YW5pb24gcmVnaXN0cnkpLjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpMdHJ1IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo8L2E+PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48YnI+DQo8YnIgY2xlYXI9YWxsPg0KPGJyPg0KLS0gPGJyPg0KTWFyayA8bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561E62F1B5CNAEXMSGC117re_-- --===============0043588401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0043588401==-- From ltru-bounces@ietf.org Tue Jan 08 16:22:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLth-0003NB-Q5; Tue, 08 Jan 2008 16:22:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCLtg-0003N6-98 for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 16:22:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLtf-0003My-V5 for ltru@ietf.org; Tue, 08 Jan 2008 16:22:07 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCLtf-00077L-JS for ltru@ietf.org; Tue, 08 Jan 2008 16:22:07 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 32DA624080E; Tue, 8 Jan 2008 22:22:05 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 2795D125EA; Tue, 8 Jan 2008 22:19:15 +0100 (CET) Date: Tue, 8 Jan 2008 22:19:15 +0100 From: Stephane Bortzmeyer To: Randy Presuhn Message-ID: <20080108211915.GA10303@sources.org> References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Jan 04, 2008 at 04:29:01PM -0800, Randy Presuhn wrote a message of 83 lines which said: > 2) There may be cases where the correct tag for a particular > language may not be immediately obvious from the data in > the registry. I can see several possible responses: > a) attempt to add the information to the registry > b) (as a WG) take on the effort of defining a repository > for this information > c) leave the documentation of such cases to others OK, in any case, it may be better to explain to people where to find a subtag, in the spirit of Unicode's "Where is my character?" (http://www.unicode.org/standard/where/). What do people think of this first attempt: http://www.langtag.net/find-subtags.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 16:27:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLyX-0007OP-Rk; Tue, 08 Jan 2008 16:27:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCLyW-0007O7-OB for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 16:27:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLyW-0007Nx-Dn for ltru@ietf.org; Tue, 08 Jan 2008 16:27:08 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCLyW-0007GI-0C for ltru@ietf.org; Tue, 08 Jan 2008 16:27:08 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 32B6124080E; Tue, 8 Jan 2008 22:27:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 1DEC5125F8; Tue, 8 Jan 2008 22:22:52 +0100 (CET) Date: Tue, 8 Jan 2008 22:22:52 +0100 From: Stephane Bortzmeyer To: Randy Presuhn Message-ID: <20080108212251.GB10303@sources.org> References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108090623.GA18206@nic.fr> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 08, 2008 at 10:06:23AM +0100, Stephane Bortzmeyer wrote a message of 29 lines which said: > It seems that, for consistent tagging, we need one (1) authoritative > source (wether it is the LSR or a yet-to-be-done companion registry). Small show of hands about the possibility of a yet-to-be-done companion registry, dedicated to "extra" information to help people find the right tag. Do you consider it to be: 1) A good idea 2) A bad idea (I believe that it is a good summary of Mark Davis' posting http://www1.ietf.org/mail-archive/web/ltru/current/msg09271.html) If the answer is 1) (a good idea), would you prefer it to be: 1a) A formal registry, with registration procedures described in a RFC. 1b) A "Web 2.0" site, hosted for instance at www.langtag.net, allowing anyone to add information at will. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 16:47:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMI6-00083R-KG; Tue, 08 Jan 2008 16:47:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCMI4-00083M-Pr for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 16:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMI4-00083E-Fp for ltru@lists.ietf.org; Tue, 08 Jan 2008 16:47:20 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCMHz-0000rP-2H for ltru@lists.ietf.org; Tue, 08 Jan 2008 16:47:20 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4889A240823; Tue, 8 Jan 2008 22:47:13 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 0A760125FC; Tue, 8 Jan 2008 22:46:48 +0100 (CET) Date: Tue, 8 Jan 2008 22:46:48 +0100 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20080108214648.GB12152@sources.org> References: <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 08, 2008 at 11:15:08AM +0100, Frank Ellermann wrote=20 a message of 29 lines which said: > St=E9phane picked an interesting can of worms with his proposal. It seems that, since the publication of RFC 4646, most proposals on ietf-languages raised a discussion on LTRU. It may indicate that we are not stable yet, regarding the registration process. The beta testing phase goes on? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 16:54:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMPQ-0007ze-6v; Tue, 08 Jan 2008 16:54:56 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCMPP-0007zX-3g for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 16:54:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMPO-0007zP-QB for ltru@lists.ietf.org; Tue, 08 Jan 2008 16:54:54 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCMPM-00011y-Kh for ltru@lists.ietf.org; Tue, 08 Jan 2008 16:54:54 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JCMPJ-0000u6-UX; Tue, 08 Jan 2008 16:54:49 -0500 Date: Tue, 8 Jan 2008 16:54:49 -0500 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Description on tags, not just subtags? Message-ID: <20080108215449.GA26996@mercury.ccil.org> References: <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> <20080108214648.GB12152@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108214648.GB12152@sources.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > It may indicate that we are not stable yet, regarding the registration > process. The beta testing phase goes on? It's more like this: ietf-languages is permanent, LTRU is transient or at most recurrent. When an instance of LTRU exists, it makes sense to scrutinize the cases discussed in ietf-languages to see if anything should be changed in the new version of BCP 47 under discussion. Most of the time, when there is no LTRU process, ietf-languages will have to evolve its own standing rules and best practices. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 08 17:28:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMw1-0001SQ-Rr; Tue, 08 Jan 2008 17:28:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCMw0-0001SL-Ko for ltru-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 17:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMw0-0001SC-B3 for ltru@ietf.org; Tue, 08 Jan 2008 17:28:36 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCMvw-0001cV-9T for ltru@ietf.org; Tue, 08 Jan 2008 17:28:36 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1863928nzf.4 for ; Tue, 08 Jan 2008 14:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=c/HI2IkWXlVfkjm3jEWT32bU1SE+ouLMOftlc3jKU/o=; b=YZbIUIqPKd2mqndvmfBQSGzn0GApMzjQMR7jcocNJ4a+T8gADvHcv8DQoHaGlu/1VCn4DHuqlheHRpqnI8e28HB/kvtWvtvWBMcr0QBJqfHSAcvdkJqH1a/tZfzSrlZg1ghmf2uHNztwTHMQAa5sIptDNNbbcf4BcY9kyM0oVFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=LDnX/m1gXmnVqTsUDtDqw7om2b1aMsYH8MeiwZJGMSWjYMFTJzfcsaYaMBcezE1APN2ZYcalPUO1ehAov6PU1fnK+ABpcP5LnGMLT5nVcq3B+ZpjJpg/CudwoB6O54dKZwChQ9C8OTXKvMNV6M8dX+aVrr1iDqzLeZWkCjSRV3E= Received: by 10.142.52.9 with SMTP id z9mr635600wfz.134.1199831310611; Tue, 08 Jan 2008 14:28:30 -0800 (PST) Received: by 10.143.8.19 with HTTP; Tue, 8 Jan 2008 14:28:30 -0800 (PST) Message-ID: <30b660a20801081428w46c1da79g5d16a371bb744963@mail.gmail.com> Date: Tue, 8 Jan 2008 14:28:30 -0800 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: <20080108212251.GB10303@sources.org> MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <20080108212251.GB10303@sources.org> X-Google-Sender-Auth: 2f7a2fdbccd1a15d X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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="===============1272065018==" Errors-To: ltru-bounces@ietf.org --===============1272065018== Content-Type: multipart/alternative; boundary="----=_Part_46007_32472238.1199831310605" ------=_Part_46007_32472238.1199831310605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBoYXZpbmcgY29tcGFuaW9uIGluZm9ybWF0aXZlIGRhdGEgd291bGQgYmUgZ29vZCwg KmlmKiBwZW9wbGUgYXJlCnNpZ25lZCB1cCB0byBtYWludGFpbiBpdC4KCkhvd2V2ZXIsIEkgdGhp bmsgdGhlIGNvcmUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGlkZW50aWZ5IHRoZSB0YWdzICh3 aGljaApzaG91bGQgYmUgdXNlZCBmb3Igd2hhdCkgc2hvdWxkIGJlIGluIHRoZSByZWdpc3RyeSAo YXMgcGVyIG15IG1lc3NhZ2UpLgoKQXMgZmFyIGFzIHlvdXIgcGFnZSBnb2VzLCBpdCBsb29rcyBs aWtlIGEgZ29vZCBzdGFydC4gRm9yIHRoZSBjb3JlIG1lc3NhZ2UsCmhvd2V2ZXIsIGl0IG5lZWRz IGEgYml0IG1vcmUgZXhwbGFuYXRpb24uCgo+IEJvdGggUmljaGFyZCBJc2hpZGEncyBXZWIgc2Vy dmljZSBhbmQgdGhlIGFib3ZlIG1ldGhvZCBoYXZlIGEgbGltaXQ6IHRoZXkKb25seSB1c2UgZGF0 YSB0aGF0IGlzIGluIHRoZSByZWdpc3RyeS4gSWYgaXQgaXMgbm90IHdyaXR0ZW4gdGhlcmUsIHlv dSB3aWxsCm5vdCBmaW5kIGl0LiBGb3IgaW5zdGFuY2UsIGlmIHlvdSB3YW50IHRvIHdyaXRlIHRl eHRzIGluCkFsc2F0aWFuPGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQWxzYXRpYW4lMjBs YW5ndWFnZT4sCmFuZCBzZWFyY2ggdGhpcyB3b3JkIGluIHRoZSByZWdpc3RyeSwgeW91IHdvbid0 IGZpbmQgaXQuCgo9PiBCb3RoIFJpY2hhcmQgSXNoaWRhJ3MgV2ViIHNlcnZpY2UgYW5kIHRoZSBh Ym92ZSBtZXRob2QgaGF2ZSBhIGxpbWl0OiB0aGV5Cm9ubHkgdXNlIGRhdGEgdGhhdCBpcyBpbiB0 aGUgcmVnaXN0cnkuIElmIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBjb21tb24KbmFtZXMgYW5k IHRoZSB0YWdzIGlzIG5vdCBpbiB0aGUgcmVnaXN0cnksIHlvdSB3aWxsIG5vdCBmaW5kIGl0LiBG b3IKaW5zdGFuY2UsIGlmIHlvdSB3YW50IHRvIGlkZW50aWZ5ICJCcml0aXNoIEVuZ2xpc2giLCB5 b3UgaGF2ZSB0byByZWFsaXplCnRoYXQgdGhhdCBpcyBkb25lIGJ5IGNvbnN0cnVjdGluZyB0aGUg dGFnICJlbi1HQiIgKG5vdCAqImVuLVVLIikgZnJvbQpzdWJ0YWdzIGluIHRoZSByZWdpc3RyeS4g U2ltaWxhcmx5LCBpZiB5b3Ugd2FudCB0byBpZGVudGlmeQpBbHNhdGlhbjxodHRwOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0Fsc2F0aWFuJTIwbGFuZ3VhZ2U+LAphbmQgc2VhcmNoIHRoaXMgd29y ZCBpbiB0aGUgcmVnaXN0cnksIHlvdSB3b24ndCBmaW5kIHRoYXQgImdzdy1GUiIgaXMgdGhlCnJp Z2h0IHRhZyB0byB1c2UuCgo+IEZvciBpbnN0YW5jZSwgdGhlIGFydGljbGUgb24gQWxzYXRpYW4g d2lsbCBzaG93IHRoZSBsYW5ndWFnZSBjb2RlIGdzdyAoCkFsZW1hbm5pYyA8aHR0cDovL2VuLndp a2lwZWRpYS5vcmcvd2lraS9BbGVtYW5uaWMlMjBHZXJtYW4+KSwgd2hpY2gsIGV2ZW4gaWYKaXQg ZG9lcyBub3Qgc3BlY2lmaWNhbGx5IGluZGljYXRlIHRoZSBhbHNhdGlhbiBkaWFsZWN0LCBpcyBh IGdvb2Qgc3RhcnQuCgo9PiBGb3IgaW5zdGFuY2UsIHRoZSBhcnRpY2xlIG9uIEFsc2F0aWFuIHdp bGwgc2hvdyB0aGUgbGFuZ3VhZ2UgY29kZSBnc3cgKApBbGVtYW5uaWMgPGh0dHA6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvQWxlbWFubmljJTIwR2VybWFuPiksIHdoaWNoLCBldmVuIGlmCml0IGlz IGJyb2FkZXIgdGhhbiBBbHNhdGlhbiwgd2lsbCBiZSBwYXJ0IG9mIHRoZSBsYW5ndWFnZSB0YWcg dGhhdCB5b3UgbmVlZC4KCj4KQnV0IGJlIGNhcmVmdWw6IEV0aG5vbG9ndWUgZGlzcGxheXMgb25s eSAzLWxldHRlcnMgY29kZSwgd2hpbGUgdGhlIHJlZ2lzdHJ5CnNvbWV0aW1lcyB1c2UgMi1sZXR0 ZXJzIGNvZGUuCgo9PiBCdXQgYmUgY2FyZWZ1bDogRXRobm9sb2d1ZSBkaXNwbGF5cyBvbmx5IDMt bGV0dGVycyBjb2RlLCB3aGlsZSB0aGUKcmVnaXN0cnkgcmVxdWlyZXMgMi1sZXR0ZXJzIGNvZGVz IHdoZW5ldmVyIHRoZXkgYXJlIGF2YWlsYWJsZS4KCj4gSXQgaGFzIGEgc2VhcmNoIGZ1bmN0aW9u IDxodHRwOi8vd3d3LmV0aG5vbG9ndWUuY29tL3NpdGVfc2VhcmNoLmFzcD4gdGhhdAphbGxvd3Mg eW91IHRvIHVzZSB3b3JkcyB0aGF0IGFyZSBub3QgaW4gdGhlIGZvcm1hbCBzdGFuZGFyZCwgc3Vj aCBhcwphbHNhdGlhbi4KCj0+IEl0IGhhcyBhIHNlYXJjaCBmdW5jdGlvbiA8aHR0cDovL3d3dy5l dGhub2xvZ3VlLmNvbS9zaXRlX3NlYXJjaC5hc3A+IHRoYXQKYWxsb3dzIHlvdSB0byB1c2Ugd29y ZHMgdGhhdCBhcmUgbm90IGluIHRoZSBmb3JtYWwgc3RhbmRhcmQuIEZvciBleGFtcGxlLApzZWFy Y2hpbmcgZm9yICJBbHNhdGlhbiIsIHlvdSdsbCBmaW5kCmh0dHA6Ly93d3cuZXRobm9sb2d1ZS5j b20vc2hvd19sYW5ndWFnZS5hc3A/Y29kZT1nc3csIHdoZXJlIHRoZXJlIGlzIHRoZQpjb21tZW50 OiAiQ2FsbGVkICdTY2h3eXplcmTDvHRzY2gnIGluIFN3aXR6ZXJsYW5kLCBhbmQgJ0Fsc2F0aWFu JyBpbiBGcmFuY2UuIgoKTWFyawoKTWlub3I6ICJhbHNhdGlhbiIgPT4gIkFsc2F0aWFuIiBpbiBF bmdsaXNoLgoKT24gSmFuIDgsIDIwMDggMToyMiBQTSwgU3RlcGhhbmUgQm9ydHptZXllciA8Ym9y dHptZXllckBuaWMuZnI+IHdyb3RlOgoKPiBPbiBUdWUsIEphbiAwOCwgMjAwOCBhdCAxMDowNjoy M0FNICswMTAwLAo+ICBTdGVwaGFuZSBCb3J0em1leWVyIDxib3J0em1leWVyQG5pYy5mcj4gd3Jv dGUKPiAgYSBtZXNzYWdlIG9mIDI5IGxpbmVzIHdoaWNoIHNhaWQ6Cj4KPiA+IEl0IHNlZW1zIHRo YXQsIGZvciBjb25zaXN0ZW50IHRhZ2dpbmcsIHdlIG5lZWQgb25lICgxKSBhdXRob3JpdGF0aXZl Cj4gPiBzb3VyY2UgKHdldGhlciBpdCBpcyB0aGUgTFNSIG9yIGEgeWV0LXRvLWJlLWRvbmUgY29t cGFuaW9uIHJlZ2lzdHJ5KS4KPgo+IFNtYWxsIHNob3cgb2YgaGFuZHMgYWJvdXQgdGhlIHBvc3Np YmlsaXR5IG9mIGEgeWV0LXRvLWJlLWRvbmUKPiBjb21wYW5pb24gcmVnaXN0cnksIGRlZGljYXRl ZCB0byAiZXh0cmEiIGluZm9ybWF0aW9uIHRvIGhlbHAgcGVvcGxlCj4gZmluZCB0aGUgcmlnaHQg dGFnLiBEbyB5b3UgY29uc2lkZXIgaXQgdG8gYmU6Cj4KPiAxKSBBIGdvb2QgaWRlYQo+IDIpIEEg YmFkIGlkZWEgKEkgYmVsaWV2ZSB0aGF0IGl0IGlzIGEgZ29vZCBzdW1tYXJ5IG9mIE1hcmsgRGF2 aXMnCj4gcG9zdGluZyBodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUv Y3VycmVudC9tc2cwOTI3MS5odG1sKQo+Cj4gSWYgdGhlIGFuc3dlciBpcyAxKSAoYSBnb29kIGlk ZWEpLCB3b3VsZCB5b3UgcHJlZmVyIGl0IHRvIGJlOgo+Cj4gMWEpIEEgZm9ybWFsIHJlZ2lzdHJ5 LCB3aXRoIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiBhIFJGQy4KPiAxYikg QSAiV2ViIDIuMCIgc2l0ZSwgaG9zdGVkIGZvciBpbnN0YW5jZSBhdCB3d3cubGFuZ3RhZy5uZXQs IGFsbG93aW5nCj4gYW55b25lIHRvIGFkZCBpbmZvcm1hdGlvbiBhdCB3aWxsLgo+Cj4KPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWls aW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydQo+CgoKCi0tIApNYXJrCg== ------=_Part_46007_32472238.1199831310605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBoYXZpbmcgY29tcGFuaW9uIGluZm9ybWF0aXZlIGRhdGEgd291bGQgYmUgZ29vZCwg KmlmKiBwZW9wbGUgYXJlIHNpZ25lZCB1cCB0byBtYWludGFpbiBpdC48YnI+PGJyPkhvd2V2ZXIs IEkgdGhpbmsgdGhlIGNvcmUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGlkZW50aWZ5IHRoZSB0 YWdzICh3aGljaCBzaG91bGQgYmUgdXNlZCBmb3Igd2hhdCkgc2hvdWxkIGJlIGluIHRoZSByZWdp c3RyeSAoYXMgcGVyIG15IG1lc3NhZ2UpLgo8YnI+PGJyPkFzIGZhciBhcyB5b3VyIHBhZ2UgZ29l cywgaXQgbG9va3MgbGlrZSBhIGdvb2Qgc3RhcnQuIEZvciB0aGUgY29yZSBtZXNzYWdlLCBob3dl dmVyLCBpdCBuZWVkcyBhIGJpdCBtb3JlIGV4cGxhbmF0aW9uLjxicj48YnI+Jmd0OyBCb3RoIFJp Y2hhcmQgSXNoaWRhJiMzOTtzIFdlYiBzZXJ2aWNlIGFuZCB0aGUgYWJvdmUgbWV0aG9kIGhhdmUg YQpsaW1pdDogdGhleSBvbmx5IHVzZSBkYXRhIHRoYXQgaXMgaW4gdGhlIHJlZ2lzdHJ5LiBJZiBp dCBpcyBub3QKd3JpdHRlbiB0aGVyZSwgeW91IHdpbGwgbm90IGZpbmQgaXQuIEZvciBpbnN0YW5j ZSwgaWYgeW91IHdhbnQgdG8Kd3JpdGUgdGV4dHMgaW4gPGEgaHJlZj0iaHR0cDovL2VuLndpa2lw ZWRpYS5vcmcvd2lraS9BbHNhdGlhbiUyMGxhbmd1YWdlIj5BbHNhdGlhbjwvYT4sIGFuZCBzZWFy Y2ggdGhpcyB3b3JkCmluIHRoZSByZWdpc3RyeSwgeW91IHdvbiYjMzk7dCBmaW5kIGl0Ljxicj48 YnI+PSZndDsgQm90aCBSaWNoYXJkIElzaGlkYSYjMzk7cyBXZWIgc2VydmljZSBhbmQgdGhlIGFi b3ZlIG1ldGhvZCBoYXZlIGEKbGltaXQ6IHRoZXkgb25seSB1c2UgZGF0YSB0aGF0IGlzIGluIHRo ZSByZWdpc3RyeS4gSWYgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGNvbW1vbiBuYW1lcyBhbmQg dGhlIHRhZ3MgaXMgbm90IGluIHRoZSByZWdpc3RyeSwgeW91IHdpbGwgbm90IGZpbmQgaXQuIEZv ciBpbnN0YW5jZSwgaWYgeW91IHdhbnQgdG8gaWRlbnRpZnkgJnF1b3Q7QnJpdGlzaCBFbmdsaXNo JnF1b3Q7LCB5b3UgaGF2ZSB0byByZWFsaXplIHRoYXQgdGhhdCBpcyBkb25lIGJ5IGNvbnN0cnVj dGluZyB0aGUgdGFnICZxdW90O2VuLUdCJnF1b3Q7IChub3QgKiZxdW90O2VuLVVLJnF1b3Q7KSBm cm9tIHN1YnRhZ3MgaW4gdGhlIHJlZ2lzdHJ5LiBTaW1pbGFybHksIGlmIHlvdSB3YW50IHRvIGlk ZW50aWZ5IAo8YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Fsc2F0aWFuJTIw bGFuZ3VhZ2UiPkFsc2F0aWFuPC9hPiwgYW5kIHNlYXJjaCB0aGlzIHdvcmQKaW4gdGhlIHJlZ2lz dHJ5LCB5b3Ugd29uJiMzOTt0IGZpbmQgdGhhdCAmcXVvdDtnc3ctRlImcXVvdDsgaXMgdGhlIHJp Z2h0IHRhZyB0byB1c2UuPGJyPjxicj4mZ3Q7IEZvciBpbnN0YW5jZSwgdGhlIGFydGljbGUgb24g QWxzYXRpYW4gd2lsbApzaG93IHRoZSBsYW5ndWFnZSBjb2RlIDxjb2RlPmdzdzwvY29kZT4KKDxh IGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQWxlbWFubmljJTIwR2VybWFuIj5B bGVtYW5uaWM8L2E+KSwgd2hpY2gsIGV2ZW4gaWYgaXQgZG9lcyBub3QKc3BlY2lmaWNhbGx5IGlu ZGljYXRlIHRoZSBhbHNhdGlhbiBkaWFsZWN0LCBpcyBhIGdvb2Qgc3RhcnQuPGJyPjxicj49Jmd0 OyBGb3IgaW5zdGFuY2UsIHRoZSBhcnRpY2xlIG9uIEFsc2F0aWFuIHdpbGwKc2hvdyB0aGUgbGFu Z3VhZ2UgY29kZSA8Y29kZT5nc3c8L2NvZGU+Cig8YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlh Lm9yZy93aWtpL0FsZW1hbm5pYyUyMEdlcm1hbiI+QWxlbWFubmljPC9hPiksIHdoaWNoLCBldmVu IGlmIGl0IGlzIGJyb2FkZXIgdGhhbiBBbHNhdGlhbiwgd2lsbCBiZSBwYXJ0IG9mIHRoZSBsYW5n dWFnZSB0YWcgdGhhdCB5b3UgbmVlZC48YnI+PGJyPiZndDs8YnI+QnV0IGJlIGNhcmVmdWw6CkV0 aG5vbG9ndWUgZGlzcGxheXMgb25seSAzLWxldHRlcnMgY29kZSwgd2hpbGUgdGhlIHJlZ2lzdHJ5 IHNvbWV0aW1lcwp1c2UgMi1sZXR0ZXJzIGNvZGUuIDxicj48YnI+PSZndDsgQnV0IGJlIGNhcmVm dWw6CkV0aG5vbG9ndWUgZGlzcGxheXMgb25seSAzLWxldHRlcnMgY29kZSwgd2hpbGUgdGhlIHJl Z2lzdHJ5IHJlcXVpcmVzIDItbGV0dGVycyBjb2RlcyB3aGVuZXZlciB0aGV5IGFyZSBhdmFpbGFi bGUuPGJyPjxicj4mZ3Q7IEl0CmhhcyBhIDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRobm9sb2d1ZS5j b20vc2l0ZV9zZWFyY2guYXNwIj5zZWFyY2ggZnVuY3Rpb248L2E+IHRoYXQgYWxsb3dzIHlvdSB0 byB1c2Ugd29yZHMgdGhhdCBhcmUgbm90IGluIHRoZQpmb3JtYWwgc3RhbmRhcmQsIHN1Y2ggYXMg YWxzYXRpYW4uPGJyPjxicj49Jmd0OyBJdApoYXMgYSA8YSBocmVmPSJodHRwOi8vd3d3LmV0aG5v bG9ndWUuY29tL3NpdGVfc2VhcmNoLmFzcCI+c2VhcmNoIGZ1bmN0aW9uPC9hPiB0aGF0IGFsbG93 cyB5b3UgdG8gdXNlIHdvcmRzIHRoYXQgYXJlIG5vdCBpbiB0aGUKZm9ybWFsIHN0YW5kYXJkLiBG b3IgZXhhbXBsZSwgc2VhcmNoaW5nIGZvciAmcXVvdDtBbHNhdGlhbiZxdW90OywgeW91JiMzOTts bCBmaW5kIDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20vc2hvd19sYW5ndWFnZS5h c3A/Y29kZT1nc3ciPmh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20vc2hvd19sYW5ndWFnZS5hc3A/ Y29kZT1nc3c8L2E+LCB3aGVyZSB0aGVyZSBpcyB0aGUgY29tbWVudDogJnF1b3Q7Q2FsbGVkICYj Mzk7U2Nod3l6ZXJkw7x0c2NoJiMzOTsgaW4gU3dpdHplcmxhbmQsIGFuZCAmIzM5O0Fsc2F0aWFu JiMzOTsgaW4gRnJhbmNlLiZxdW90Owo8YnI+PGJyPk1hcms8YnI+PGJyPk1pbm9yOiAmcXVvdDth bHNhdGlhbiZxdW90OyA9Jmd0OyAmcXVvdDtBbHNhdGlhbiZxdW90OyBpbiBFbmdsaXNoLjxicj48 YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEphbiA4LCAyMDA4IDE6MjIgUE0sIFN0ZXBo YW5lIEJvcnR6bWV5ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpib3J0em1leWVyQG5pYy5mciI+Ym9y dHptZXllckBuaWMuZnI8L2E+CiZndDsgd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQp OyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPk9uIFR1ZSwg SmFuIDA4LCAyMDA4IGF0IDEwOjA2OjIzQU0gKzAxMDAsPGJyPjxkaXYgY2xhc3M9IkloMkUzZCI+ Jm5ic3A7U3RlcGhhbmUgQm9ydHptZXllciAmbHQ7CjxhIGhyZWY9Im1haWx0bzpib3J0em1leWVy QG5pYy5mciI+Ym9ydHptZXllckBuaWMuZnI8L2E+Jmd0OyB3cm90ZTxicj48L2Rpdj48ZGl2IGNs YXNzPSJJaDJFM2QiPiZuYnNwO2EgbWVzc2FnZSBvZiAyOSBsaW5lcyB3aGljaCBzYWlkOjxicj48 YnI+Jmd0OyBJdCBzZWVtcyB0aGF0LCBmb3IgY29uc2lzdGVudCB0YWdnaW5nLCB3ZSBuZWVkIG9u ZSAoMSkgYXV0aG9yaXRhdGl2ZTxicj4mZ3Q7IHNvdXJjZSAod2V0aGVyIGl0IGlzIHRoZSBMU1Ig b3IgYSB5ZXQtdG8tYmUtZG9uZSBjb21wYW5pb24gcmVnaXN0cnkpLgo8YnI+PGJyPjwvZGl2PlNt YWxsIHNob3cgb2YgaGFuZHMgYWJvdXQgdGhlIHBvc3NpYmlsaXR5IG9mIGEgeWV0LXRvLWJlLWRv bmU8YnI+Y29tcGFuaW9uIHJlZ2lzdHJ5LCBkZWRpY2F0ZWQgdG8gJnF1b3Q7ZXh0cmEmcXVvdDsg aW5mb3JtYXRpb24gdG8gaGVscCBwZW9wbGU8YnI+ZmluZCB0aGUgcmlnaHQgdGFnLiBEbyB5b3Ug Y29uc2lkZXIgaXQgdG8gYmU6PGJyPjxicj4xKSBBIGdvb2QgaWRlYQo8YnI+MikgQSBiYWQgaWRl YSAoSSBiZWxpZXZlIHRoYXQgaXQgaXMgYSBnb29kIHN1bW1hcnkgb2YgTWFyayBEYXZpcyYjMzk7 PGJyPnBvc3RpbmcgPGEgaHJlZj0iaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9sdHJ1L2N1cnJlbnQvbXNnMDkyNzEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cx LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRydS9jdXJyZW50L21zZzA5MjcxLmh0bWwKPC9h Pik8YnI+PGJyPklmIHRoZSBhbnN3ZXIgaXMgMSkgKGEgZ29vZCBpZGVhKSwgd291bGQgeW91IHBy ZWZlciBpdCB0byBiZTo8YnI+PGJyPjFhKSBBIGZvcm1hbCByZWdpc3RyeSwgd2l0aCByZWdpc3Ry YXRpb24gcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gYSBSRkMuPGJyPjFiKSBBICZxdW90O1dlYiAy LjAmcXVvdDsgc2l0ZSwgaG9zdGVkIGZvciBpbnN0YW5jZSBhdCA8YSBocmVmPSJodHRwOi8vd3d3 Lmxhbmd0YWcubmV0IiB0YXJnZXQ9Il9ibGFuayI+Cnd3dy5sYW5ndGFnLm5ldDwvYT4sIGFsbG93 aW5nPGJyPmFueW9uZSB0byBhZGQgaW5mb3JtYXRpb24gYXQgd2lsbC48YnI+PGRpdj48ZGl2Pjwv ZGl2PjxkaXYgY2xhc3M9IldqM0M3YyI+PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJl Zj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPgpMdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+PC9k aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxi cj5NYXJrCg== ------=_Part_46007_32472238.1199831310605-- --===============1272065018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1272065018==-- From ltru-bounces@ietf.org Wed Jan 09 01:23:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCULR-0005ZV-MD; Wed, 09 Jan 2008 01:23:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCULP-0005ZP-QO for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 01:23:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCULP-0005ZH-Eu for ltru@ietf.org; Wed, 09 Jan 2008 01:23:19 -0500 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 1JCULO-0008HB-Nr for ltru@ietf.org; Wed, 09 Jan 2008 01:23:19 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080109062318.XYQA11986.mta13.adelphia.net@DGBP7M81> for ; Wed, 9 Jan 2008 01:23:18 -0500 Message-ID: <000f01c85288$1fde4770$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 8 Jan 2008 22:23:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >>> Am I correct in thinking the group will want to delay 4645bis again >>> for this? >> >> I don't see why. It has no structural effect, and it's just a matter >> of 34 name changes later. > > I agree: there's no reason for delaying 4646bis for this, unless > someone thinks we need some text somewhere pertaining to collections > or stability that could not take effect until the change is made in > ISO 639-2. I specifically referred to 4645bis, which (in draft form) contains the reloaded Registry, which will be expected to be fairly stable throughout the IETF Last Call and RFC Editor waiting periods. I can't think why anyone would want to delay 4646bis for this. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 01:36:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCUY1-0007Y7-VH; Wed, 09 Jan 2008 01:36:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCUXz-0007Y2-DA for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 01:36:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCUXy-0007Xu-Uj for ltru@ietf.org; Wed, 09 Jan 2008 01:36:18 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCUXy-0008Qe-HJ for ltru@ietf.org; Wed, 09 Jan 2008 01:36:18 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JCUXv-0005yn-Sc; Wed, 09 Jan 2008 01:36:15 -0500 Date: Wed, 9 Jan 2008 01:36:15 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: action item: "other" collections in 639 Message-ID: <20080109063615.GC9253@mercury.ccil.org> References: <000f01c85288$1fde4770$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c85288$1fde4770$6501a8c0@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: > I specifically referred to 4645bis, which (in draft form) contains the > reloaded Registry, which will be expected to be fairly stable throughout > the IETF Last Call and RFC Editor waiting periods. It just means that if the changes go through during the waiting period, the registry doesn't catch up until later. This is not a structural shift like the 3066-4646 transition, just a bulk load of new data. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 04:21:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCX7g-0001eq-0T; Wed, 09 Jan 2008 04:21:20 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCX7e-0001eg-B3 for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 04:21:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCX7X-0001eQ-P8 for ltru@ietf.org; Wed, 09 Jan 2008 04:21:11 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCX7S-0004ca-2x for ltru@ietf.org; Wed, 09 Jan 2008 04:21:10 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m099L2TW005475 for ; Wed, 9 Jan 2008 18:21:03 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 01c5_32a57c48_be94_11dc_952b_0014221fa3c9; Wed, 09 Jan 2008 18:21:02 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36391) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 9 Jan 2008 18:16:53 +0900 Message-Id: <6.0.0.20.2.20080109123648.0aaf1ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 09 Jan 2008 17:46:46 +0900 To: "Mark Davis" , "Stephane Bortzmeyer" From: Martin Duerst Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: <30b660a20801081127o6bef17c7g70e7ecc655967dd9@mail.gmail.co m> References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <30b660a20801081127o6bef17c7g70e7ecc655967dd9@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: 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 04:27 08/01/09, Mark Davis wrote: >gsw faces the same issue that encompassed languages from 639-3 do. That is, "de" meaning German was the only available tag, so de-CH was ambiguous: meaning either > * Swiss High German (High German as used in Switzerland), OR > * Swiss German (Schwytzerduetsch) >Then -- and not so long ago: 2006-03-08 -- gsw was introduced for Swiss German (and broadened to mean any Alemanic despite the letters). From that point in time, ideally de-CH would be used only for Swiss High German, and gsw-CH unambiguously means Swiss German. We (while I was at W3C) have always advised against the use of de-CH for Swiss German. Of course, that doesn't mean that nobody has used it, but at least for written content, I'd expect there is tons more of High German with Swiss orthography than Swiss German. And both for spoken and for written Swiss German, you really need a finer regional distinction than just "Swiss German" to be of much use. 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 Jan 09 06:17:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCYwN-0004Np-RU; Wed, 09 Jan 2008 06:17:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCYwM-0004Nj-7j for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 06:17:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCYwL-0004Nb-Ok for ltru@ietf.org; Wed, 09 Jan 2008 06:17:45 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCYwL-0006lg-EO for ltru@ietf.org; Wed, 09 Jan 2008 06:17:45 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E8CB324082F; Wed, 9 Jan 2008 12:17:41 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 3746C93C2C; Wed, 9 Jan 2008 11:44:14 +0100 (CET) Date: Wed, 9 Jan 2008 11:44:14 +0100 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20080109104414.GB20839@laperouse.bortzmeyer.org> References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <20080108212251.GB10303@sources.org> <30b660a20801081428w46c1da79g5d16a371bb744963@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20801081428w46c1da79g5d16a371bb744963@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: LTRU Working Group Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 08, 2008 at 02:28:30PM -0800, Mark Davis wrote a message of 159 lines which said: > For the core message, however, it needs a bit more explanation. Thanks. Integrated. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 06:22:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCZ0W-0005Yh-16; Wed, 09 Jan 2008 06:22:04 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCZ0U-0005X4-4q for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 06:22:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCZ0T-0005V2-Nm for ltru@ietf.org; Wed, 09 Jan 2008 06:22:01 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCZ0S-0004dC-WF for ltru@ietf.org; Wed, 09 Jan 2008 06:22:01 -0500 Received: by rv-out-0910.google.com with SMTP id l15so184057rvb.49 for ; Wed, 09 Jan 2008 03:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=rl4p8K0/h+7cI/RyosME3Pz7+oE02sdcmjGeQP4CLGc=; b=R9T6dBO9ZpWm/1iz2OhVPNm17uVkJHvPqOm4vXtJGaE1AF/I1+jIdlNlofaFYoJyGmV3x+Wue2m2SoLDGkjx9U5IFPTfuZoARfWMeaYFh0Ss42FmjKQq1Y2h9RS51OzHm/J8OnnoTJXrFViEaR3jSQxstZG/xYYsOorOi3Hz2ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=p3FQqEMpdPHB9cRoKHhbu4abQ20KdjRfDSWDZtf4t2yyMf7pK65MNvb/Vn9haW7LyP1X74gZ+OC952e+iw0sA9ET1E29dcTY0rbMHmEPjQbRegjAV9teisqks0iXjaXUkJObqVH4OfQI9c8tAPaXxTaCl74C9n3awarjH0RSBho= Received: by 10.141.180.5 with SMTP id h5mr307347rvp.287.1199877718731; Wed, 09 Jan 2008 03:21:58 -0800 (PST) Received: by 10.140.166.2 with HTTP; Wed, 9 Jan 2008 03:21:58 -0800 (PST) Message-ID: <5b0cbc7c0801090321u5e2c8fadk32561f0e0c5a4b96@mail.gmail.com> Date: Wed, 9 Jan 2008 12:21:58 +0100 From: LB To: "Randy Presuhn" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: <00fd01c85230$2b64e700$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> <5b0cbc7c0801081103h20eecb72o331d8e57e571522d@mail.gmail.com> <00fd01c85230$2b64e700$6801a8c0@oemcomputer> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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="===============1533188541==" Errors-To: ltru-bounces@ietf.org --===============1533188541== Content-Type: multipart/alternative; boundary="----=_Part_9952_13754184.1199877718726" ------=_Part_9952_13754184.1199877718726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Randy, 2008/1/8, Randy Presuhn : > > Hi - > As a technical contributor... > > > 2. several langtags can refer to the same language name, content, > > classification, filtering, locale file, ... whatever they are used for? > > No. Having multiple distinct (not merely more-precise and less-precise) > language tags for the same language would be a very bad thing. > The fact that the same string might be well-formed both when understood > as a language tag or when understoof as a locale does not mean that it > *is* > both. I am sorry, I do not understand. What I mean is that if the same language name is associated to several langtags will not create any problem. The same as the same actual language can have several language names and ISO entries ? What is the problem if one refers French as "fr" or as "fra", or as "x-fran=E7ais" as long as the allocutors agree ? > 3. the authoritative reference is the locutor/allocutor couple? > > No. The entity tagging the data makes its decision how to tag > the data. That decision may be incorrect, and another entity > may choose to ignore that tag an apply some other. You mean that there can be several LSR? > What is discussed here belongs to local documentation organization > (langtags > > concatenation), not to IETF protocols. > > Disagree. The semantics of tag composition from subtags is very much > within this group's domain. You mean the syntax? Agreed. But I understood the terminology was with the Reviewer? The discussion of specific registration requests is not handled on this > list. > However, discussing specific *examples* can be very helpful in the > identification > of issues and learning how principles might be best applied. Full agreement. However, examples should be kept as neutral as possible, carrying no pragmatic. A "de-FR" tag has a significant context attached. --=20 LB ------=_Part_9952_13754184.1199877718726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Randy,

2008/1/8, Randy Presuhn= <randy_presuhn@mindspri= ng.com>:
Hi -
As a technical contributor...

> 2. several langtags can r= efer to the same language name, content,
> classification, filtering,= locale file, ... whatever they are used for?

No.  Having = multiple distinct (not merely more-precise and less-precise)
language tags for the same language would be a very bad thing.
The f= act that the same string might be well-formed both when understood
as a = language tag or when understoof as a locale does not mean that it *is*
both.

I am sorry, I do not understand.  What I me= an is that if the same language name is associated  to several langtag= s will not create any problem.  The same as the same actual language c= an have several language names and ISO entries ? What is the problem if one= refers French as "fr" or as "fra", or as "x-fran= =E7ais" as long as the allocutors agree ? =20

>= ; 3. the authoritative reference is the locutor/allocutor couple?

No= .  The entity tagging the data makes its decision how to tag
the data.  That decision may be incorrect, and another entity=
may choose to ignore that tag an apply some other.
You mean that there can be several LSR?

> What is discussed here belongs to local documentation organization (la= ngtags
> concatenation), not to IETF protocols.

Disagree. = ; The semantics of tag composition from subtags is very much
within= this group's domain.

You mean the syntax? Agreed.
But I understood the= terminology was with the Reviewer?

The discussion of specific registration requests is not handled on this lis= t.
However, discussing specific *examples* can be very helpful in the id= entification
of issues and learning how principles might be best applied= .

Full agreement.
However, examples should  be= kept as neutral as possible, carrying no pragmatic.
A "de-FR"= ; tag has a significant context attached.

--
LB ------=_Part_9952_13754184.1199877718726-- --===============1533188541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1533188541==-- From ltru-bounces@ietf.org Wed Jan 09 08:29:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCazc-0008TT-As; Wed, 09 Jan 2008 08:29:16 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCaza-0008Rc-JN for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 08:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaza-0008RU-9O for ltru@lists.ietf.org; Wed, 09 Jan 2008 08:29:14 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCazY-00075k-Fz for ltru@lists.ietf.org; Wed, 09 Jan 2008 08:29:14 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JCazW-0004Rt-E3 for ltru@lists.ietf.org; Wed, 09 Jan 2008 13:29:10 +0000 Received: from c-134-88-143.hh.dial.de.ignite.net ([62.134.88.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2008 13:29:10 +0000 Received: from nobody by c-134-88-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2008 13:29:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 9 Jan 2008 14:29:20 +0100 Organization: Lines: 40 Message-ID: References: <005501c84eed$a0579850$6501a8c0@DGBP7M81><477E6409.5060300@yahoo-inc.com><000f01c84f31$f8f29b60$6801a8c0@oemcomputer><20080108090623.GA18206@nic.fr><5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com><5b0cbc7c0801081103h20eecb72o331d8e57e571522d@mail.gmail.com><00fd01c85230$2b64e700$6801a8c0@oemcomputer> <5b0cbc7c0801090321u5e2c8fadk32561f0e0c5a4b96@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-143.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org JFC wrote: > What I mean is that if the same language name is associated > to several langtags will not create any problem. We're trying to avoid this as it increases the registry, and it makes matching harder than necessary. When I'm looking for say Alsatian content I'm not necessarily interested in finding gsw pages with other Alemannic dialects, or any non-Alemannic pages roughly passing as "some kind of German language as spoken in France" when that's *not* Alsatian (e.g. if it is Franconian). >> The semantics of tag composition from subtags is very much >> within this group's domain. > You mean the syntax? Agreed. I guess he means semantics when he says semantics. The only syntactical problem was my proposal to use prefix gsw-FR for a variant Alsatian: For constructs like gsw-Brai-FR-alsatian I'm not sure if our definition of "prefix" covers them. > However, examples should be kept as neutral as possible, > carrying no pragmatic. NAK, it's far easier to look at practical examples where some of us have an idea what they actually are. > A "de-FR" tag has a significant context attached. "Some German language (or dialect) as spoken in France" is not significant enough to trigger only on Alsatian, if that's what you mean. Taggers not familiar with the fine print of gsw and lb, and how to tell what's what, might still try to use de-FR instead of gsw-FR / lb-FR if it reflects what they know. Besides the Wikipedia article suggests that High-German dialects also exist in France, making de-FR fuzzier, it could be "correct", not only "old" or "better than nothing". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 08:54:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCbNu-00056Y-Md; Wed, 09 Jan 2008 08:54:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCbNt-00056T-RS for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 08:54:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCbNt-00056L-Hq for ltru@lists.ietf.org; Wed, 09 Jan 2008 08:54:21 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCbNs-0008Fw-4F for ltru@lists.ietf.org; Wed, 09 Jan 2008 08:54:21 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3A9BA24080E; Wed, 9 Jan 2008 14:54:16 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 12043157A5A; Wed, 9 Jan 2008 14:49:38 +0100 (CET) Date: Wed, 9 Jan 2008 14:49:38 +0100 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20080109134938.GA14443@laperouse.bortzmeyer.org> References: <5b0cbc7c0801090321u5e2c8fadk32561f0e0c5a4b96@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Jan 09, 2008 at 02:29:20PM +0100, Frank Ellermann wrote a message of 47 lines which said: > JFC wrote: Are you sure LB is the One-Who-Must-Not-Be-Named? I found his style strange and confused and, now that you've detected Him, I admit there is some proximity, but not yet a proof... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 10:32:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCcv5-0005Qk-RG; Wed, 09 Jan 2008 10:32:43 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCcv4-0005KS-TW for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 10:32:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCcv4-0005IO-IR for ltru@ietf.org; Wed, 09 Jan 2008 10:32:42 -0500 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCcv4-0000Bm-5Q for ltru@ietf.org; Wed, 09 Jan 2008 10:32:42 -0500 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 <20080109153241.WDG29591.mta16.adelphia.net@DGBP7M81> for ; Wed, 9 Jan 2008 10:32:41 -0500 Message-ID: <000301c852d4$e00b9920$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 9 Jan 2008 07:32:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On the outside chance that this is not a sock puppet... LB wrote: > I am sorry, I do not understand. What I mean is that if the same > language name is associated to several langtags will not create any > problem. The same as the same actual language can have several > language names and ISO entries ? What is the problem if one refers > French as "fr" or as "fra", or as "x-français" as long as the > allocutors agree ? Coding systems exist so that senders and receivers can communicate in a clear, unequivocal way, without having to make any special arrangement other than to adhere to the published coding system. Having multiple code elements for the same entity does not aid this: it requires receivers to recognize multiple code elements and treat them as equivalent, which complicates matching with no real benefit to offset the cost. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 10:39:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCd1k-0001Xt-O5; Wed, 09 Jan 2008 10:39:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCd1j-0001Xo-3d for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 10:39:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCd1i-0001Xg-QJ for ltru@ietf.org; Wed, 09 Jan 2008 10:39:34 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCd1f-0003b3-Ka for ltru@ietf.org; Wed, 09 Jan 2008 10:39:34 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20080109153929.VYTV4230.mta15.adelphia.net@DGBP7M81> for ; Wed, 9 Jan 2008 10:39:29 -0500 Message-ID: <002f01c852d5$d34e87f0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 9 Jan 2008 07:39:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Small show of hands about the possibility of a yet-to-be-done > companion registry, dedicated to "extra" information to help people > find the right tag. Do you consider it to be: > > 1) A good idea > 2) A bad idea (I believe that it is a good summary of Mark Davis' > posting > http://www1.ietf.org/mail-archive/web/ltru/current/msg09271.html) The more formal it is, the worse an idea it is. People will rightly ask why two registries are needed. This might be a suitable project for the World Language Documentation Centre . -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 13:29:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfg5-0000MJ-FY; Wed, 09 Jan 2008 13:29:25 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCfg5-0000ME-09 for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 13:29:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfg4-0000M6-LC for ltru@ietf.org; Wed, 09 Jan 2008 13:29:24 -0500 Received: from hs-out-0708.google.com ([64.233.178.240] helo=hs-out-2122.google.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCfg3-0005od-Ul for ltru@ietf.org; Wed, 09 Jan 2008 13:29:24 -0500 Received: by hs-out-2122.google.com with SMTP id 54so312389hsz.5 for ; Wed, 09 Jan 2008 10:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=ASjK5Tx1aODxGnRkqRA29FGjUOVbE4e1BrYxS9HXK+E=; b=bMwWp3FHoOjAafUcePW8itP4HCHF0W63LyREup+fgkwKTa+4MKW3nYeWGQehQsfQvMcuFFXpshaIx7IQ3lkCye9zFQTzc9tctIOuVGhDVXd0WwWA1/lW7Y11Ox771/HDJ8Eq23KiTnOlLnCWC9EPzhsdPuvQTpbLrPPwWVGPjBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=IvfUoxBkODnbwPvcUW9VtzSXHsm99cKY9QdTJL0KfQi7PotnA8yMsXTVEgdmfC4RnAvDM5bzL9hq1nuaop/p/FxuKNTjSK33ncpIMwje4+WSkGv9j1AnKBpaAH5j9UcUXAvRMQwbhh2E1I2DThkbrRWtPj05qvoCa2h5ujZrQ7g= Received: by 10.142.131.18 with SMTP id e18mr464938wfd.207.1199903362408; Wed, 09 Jan 2008 10:29:22 -0800 (PST) Received: by 10.143.8.19 with HTTP; Wed, 9 Jan 2008 10:29:22 -0800 (PST) Message-ID: <30b660a20801091029p3fe7db28tfa787f0c4f399bc8@mail.gmail.com> Date: Wed, 9 Jan 2008 10:29:22 -0800 From: "Mark Davis" To: "LTRU Working Group" In-Reply-To: <001001c852cf$4f219d10$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <20080109014618.0C46D25971E@eikenes.alvestrand.no> <000501c85287$97e9e590$6501a8c0@DGBP7M81> <20080109063453.GB9253@mercury.ccil.org> <001001c852cf$4f219d10$6501a8c0@DGBP7M81> X-Google-Sender-Auth: b67290e260309178 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ltru] Fwd: Addition request: alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1715376962==" Errors-To: ltru-bounces@ietf.org --===============1715376962== Content-Type: multipart/alternative; boundary="----=_Part_51309_20915582.1199903362389" ------=_Part_51309_20915582.1199903362389 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21lIGxhbmd1YWdlIGxpa2UgdGhp cyBpbiB0aGUgc3BlYy4uLi4KRG91ZywgeW91IHdhbnQgdG8gdGFrZSBhIHBhc3MgYXQgZm9ybXVs YXRpbmcgaXQsIGFuZCBzdWdnZXN0aW5nIGEgbG9jYXRpb24/CgpPbiBKYW4gOSwgMjAwOCA2OjUy IEFNLCBEb3VnIEV3ZWxsIDxkZXdlbGxAcm9hZHJ1bm5lci5jb20+IHdyb3RlOgoKPiAuLi4KPgo+ ICJlbi1VUyIgYW5kICJlbi1DQSIgbWVhbiwgcm91Z2hseSwgRW5nbGlzaCB3aXRoIHNwZWNpZmlj IGZlYXR1cmVzCj4gZ2VuZXJhbGx5IHRob3VnaHQgdG8gYmUgY2hhcmFjdGVyaXN0aWMgb2YgdGhl IFVuaXRlZCBTdGF0ZXMgYW5kIENhbmFkYSwKPiByZXNwZWN0aXZlbHkuICBUaGV5IGRvIG5vdCBp bXBseSB0aGF0IGEgc2lnbmlmaWNhbnQgZGlhbGVjdGljYWwgYm91bmRhcnkKPiBleGlzdHMgYmV0 d2VlbiBhbnkgYXJiaXRyYXJpbHkgc2VsZWN0ZWQgcG9pbnQgaW4gdGhlIFUuUy4gYW5kIGFueQo+ IGFyYml0cmFyaWx5IHNlbGVjdGVkIHBvaW50IGluIENhbmFkYSwgd2hpY2ggYm91bmRhcnkgZG9l cyBub3QgZXhpc3QKPiBiZXR3ZWVuIHBvaW50cyB3aXRoaW4gdGhlIFUuUy4gb3Igd2l0aGluIENh bmFkYS4KPgo+IFJlZ2lvbiBzdWJ0YWdzIGFyZSBub3QgcHJlY2lzZS4gIFRoaXMgaXMgbm90IGEg Y3JpdGljYWwgcHJvYmxlbS4KPgo+IC0tCj4gRG91ZyBFd2VsbCAgKiAgRnVsbGVydG9uLCBDYWxp Zm9ybmlhLCBVU0EgICogIFJGQyA0NjQ1ICAqICBVVE4gIzE0Cj4gaHR0cDovL3d3dy5ld2VsbGlj Lm9yZwo+IGh0dHA6Ly93d3cxLmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbHRydS1jaGFydGVyLmh0 bWwKPiBodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1 YWdlcyAgy4YKPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBJZXRmLWxhbmd1YWdlcyBtYWlsaW5nIGxpc3QKPiBJZXRmLWxhbmd1YWdlc0BhbHZl c3RyYW5kLm5vCj4gaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0 Zi1sYW5ndWFnZXMKPgoKCgotLSAKTWFyawo= ------=_Part_51309_20915582.1199903362389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21lIGxhbmd1YWdlIGxpa2UgdGhp cyBpbiB0aGUgc3BlYy4uLi4gRG91ZywgeW91IHdhbnQgdG8gdGFrZSBhIHBhc3MgYXQgZm9ybXVs YXRpbmcgaXQsIGFuZCBzdWdnZXN0aW5nIGEgbG9jYXRpb24/PGJyPjxicj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gSmFuIDksIDIwMDggNjo1MiBBTSwgRG91ZyBFd2VsbCAmbHQ7CjxhIGhy ZWY9Im1haWx0bzpkZXdlbGxAcm9hZHJ1bm5lci5jb20iPmRld2VsbEByb2FkcnVubmVyLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2IGNsYXNzPSJJaDJFM2QiPgouLi48 YnI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9IkloMkUzZCI+JnF1b3Q7ZW4tVVMmcXVvdDsgYW5kICZx dW90O2VuLUNBJnF1b3Q7IG1lYW4sIHJvdWdobHksIEVuZ2xpc2ggd2l0aCBzcGVjaWZpYyBmZWF0 dXJlczxicj5nZW5lcmFsbHkgdGhvdWdodCB0byBiZSBjaGFyYWN0ZXJpc3RpYyBvZiB0aGUgVW5p dGVkIFN0YXRlcyBhbmQgQ2FuYWRhLDxicj48L2Rpdj5yZXNwZWN0aXZlbHkuICZuYnNwO1RoZXkg ZG8gbm90IGltcGx5IHRoYXQgYSBzaWduaWZpY2FudCBkaWFsZWN0aWNhbCBib3VuZGFyeQo8YnI+ ZXhpc3RzIGJldHdlZW4gYW55IGFyYml0cmFyaWx5IHNlbGVjdGVkIHBvaW50IGluIHRoZSBVLlMu IGFuZCBhbnk8YnI+YXJiaXRyYXJpbHkgc2VsZWN0ZWQgcG9pbnQgaW4gQ2FuYWRhLCB3aGljaCBi b3VuZGFyeSBkb2VzIG5vdCBleGlzdDxicj5iZXR3ZWVuIHBvaW50cyB3aXRoaW4gdGhlIFUuUy4g b3Igd2l0aGluIENhbmFkYS48YnI+PGJyPlJlZ2lvbiBzdWJ0YWdzIGFyZSBub3QgcHJlY2lzZS4g Jm5ic3A7VGhpcyBpcyBub3QgYSBjcml0aWNhbCBwcm9ibGVtLgo8YnI+PGRpdiBjbGFzcz0iSWgy RTNkIj48YnI+LS08YnI+RG91ZyBFd2VsbCAmbmJzcDsqICZuYnNwO0Z1bGxlcnRvbiwgQ2FsaWZv cm5pYSwgVVNBICZuYnNwOyogJm5ic3A7UkZDIDQ2NDUgJm5ic3A7KiAmbmJzcDtVVE4gIzE0PGJy PjxhIGhyZWY9Imh0dHA6Ly93d3cuZXdlbGxpYy5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmV3ZWxsaWMub3JnPC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3MS5pZXRmLm9yZy9odG1s LmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sIiB0YXJnZXQ9Il9ibGFuayI+Cmh0dHA6Ly93d3cx LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbHRydS1jaGFydGVyLmh0bWw8L2E+PGJyPjwvZGl2Pjxh IGhyZWY9Imh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFu Z3VhZ2VzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4v bGlzdGluZm8vaWV0Zi1sYW5ndWFnZXM8L2E+ICZuYnNwO8uGPGJyPjxkaXY+CjxkaXY+PC9kaXY+ PGRpdiBjbGFzcz0iV2ozQzdjIj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPklldGYtbGFuZ3VhZ2VzIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86SWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubyI+SWV0Zi1sYW5ndWFnZXNA YWx2ZXN0cmFuZC5ubzwvYT48YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21h aWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXMiIHRhcmdldD0iX2JsYW5rIj4KaHR0cDovL3d3 dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXM8L2E+PGJyPjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8 YnI+TWFyawo= ------=_Part_51309_20915582.1199903362389-- --===============1715376962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1715376962==-- From ltru-bounces@ietf.org Wed Jan 09 13:33:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfjl-00074F-9U; Wed, 09 Jan 2008 13:33:13 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCfjk-0006vK-4x for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 13:33:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfjj-0006so-QK for ltru@ietf.org; Wed, 09 Jan 2008 13:33:11 -0500 Received: from hs-out-0708.google.com ([64.233.178.245] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCfjh-0007pO-Uw for ltru@ietf.org; Wed, 09 Jan 2008 13:33:11 -0500 Received: by hs-out-2122.google.com with SMTP id 54so313417hsz.5 for ; Wed, 09 Jan 2008 10:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=opx2/zDvn0qhTxZIBtVJxBqOfPFcowLQh7FZk8ov/Ww=; b=OiICnuxRWt06dnb7VQ+4CqBDpcl/6FIk/PtP/ycxQDlZLZgCK23N3N/o0YTbBMnkPfjeIcObZKIMYExf3XgMngQnaUEyopMoalotisnnO2GPKsHIkpsOgkC4nRJq9boMkmnc03EBLfKzaQaM404gnyIgOdprr5gEWr06iCftwRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YZVBgZ8Q69fV/H0rZQXExfJ/cWQ3IZrk+Yf/eFslyd6ZVwh3bz7hoUcVsA1O6tb6FQq0BAMucVYIDP0E72YhynR0dT3gaHZ1CB28WhGRl2mOERlBiwCkaHbDkr7IA70fcyWfuvDfddb0mVFw+ZzNEew09BeGYd5R3u75zskFWjo= Received: by 10.143.6.1 with SMTP id j1mr477065wfi.45.1199903587846; Wed, 09 Jan 2008 10:33:07 -0800 (PST) Received: by 10.143.8.19 with HTTP; Wed, 9 Jan 2008 10:33:07 -0800 (PST) Message-ID: <30b660a20801091033v2605e8d1s724f813d97a63a6e@mail.gmail.com> Date: Wed, 9 Jan 2008 10:33:07 -0800 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: <6.0.0.20.2.20080109123648.0aaf1ec0@localhost> MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <30b660a20801081127o6bef17c7g70e7ecc655967dd9@mail.gmail.com> <6.0.0.20.2.20080109123648.0aaf1ec0@localhost> X-Google-Sender-Auth: 0c6a6f2db3e2cdc7 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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="===============1759527146==" Errors-To: ltru-bounces@ietf.org --===============1759527146== Content-Type: multipart/alternative; boundary="----=_Part_51340_5515887.1199903587846" ------=_Part_51340_5515887.1199903587846 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree completely with what you said, about what *should have been done.*What I was describing was what would happen unless people happened to get on the right lists or look at the right pages... That's why I think we want short xrefs in the registry itself. On Jan 9, 2008 12:46 AM, Martin Duerst wrote: > At 04:27 08/01/09, Mark Davis wrote: > >gsw faces the same issue that encompassed languages from 639-3 do. That > is, "de" meaning German was the only available tag, so de-CH was ambiguous: > meaning either > > * Swiss High German (High German as used in Switzerland), OR > > * Swiss German (Schwytzerduetsch) > >Then -- and not so long ago: 2006-03-08 -- gsw was introduced for Swiss > German (and broadened to mean any Alemanic despite the letters). From that > point in time, ideally de-CH would be used only for Swiss High German, and > gsw-CH unambiguously means Swiss German. > > We (while I was at W3C) have always advised against the use of de-CH > for Swiss German. Of course, that doesn't mean that nobody has used it, > but at least for written content, I'd expect there is tons more of > High German with Swiss orthography than Swiss German. And both for > spoken and for written Swiss German, you really need a finer > regional distinction than just "Swiss German" to be of much use. > > 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_51340_5515887.1199903587846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree completely with what you said, about what should have been done. What I was describing was what would happen unless people happened to get on the right lists or look at the right pages... That's why I think we want short xrefs in the registry itself.

On Jan 9, 2008 12:46 AM, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
At 04:27 08/01/09, Mark Davis wrote:
>gsw faces the same issue that encompassed languages from 639-3 do. That is, "de" meaning German was the only available tag, so de-CH was ambiguous: meaning either
>    * Swiss High German (High German as used in Switzerland), OR
>    * Swiss German (Schwytzerduetsch)
>Then -- and not so long ago: 2006-03-08 -- gsw was introduced for Swiss German (and broadened to mean any Alemanic despite the letters). From that point in time, ideally de-CH would be used only for Swiss High German, and gsw-CH unambiguously means Swiss German.

We (while I was at W3C) have always advised against the use of de-CH
for Swiss German. Of course, that doesn't mean that nobody has used it,
but at least for written content, I'd expect there is tons more of
High German with Swiss orthography than Swiss German. And both for
spoken and for written Swiss German, you really need a finer
regional distinction than just "Swiss German" to be of much use.

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_51340_5515887.1199903587846-- --===============1759527146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1759527146==-- From ltru-bounces@ietf.org Wed Jan 09 17:24:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjLk-0002Y6-7W; Wed, 09 Jan 2008 17:24:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCjLj-0002XD-BW for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 17:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjLj-0002Wi-1Z for ltru@lists.ietf.org; Wed, 09 Jan 2008 17:24:39 -0500 Received: from relay-2.mailobj.net ([195.234.90.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCjLg-0003U7-PS for ltru@lists.ietf.org; Wed, 09 Jan 2008 17:24:39 -0500 Received: from netcourrier.com (webmail-1.in.mailobj.net [192.168.90.138]) by relay-2.mailobj.net (Postfix) with SMTP id 759DF14CE45 for ; Wed, 9 Jan 2008 23:24:35 +0100 (CET) Received: from [89.2.186.89] by webmail-1.netcourrier.com via html interface From: Nicolas Krebs To: ltru@lists.ietf.org Date: Wed, 9 Jan 2008 23:24:35 +0100 Mime-Version: 1.0 X-Priority: 5 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >To: ltru=40lists.ietf.org >From: =22Frank Ellermann=22 >Nicholas Shanks wrote: > >> I'll wager that those using de-FR, als and so on are not even >> looking at the registry, and probably don't know it exists. > >=22de-FR=22 and =22als=22 are rather different, the latter is just wrong. > >The former was a sound workaround for Alsatian before the new = >=22gsw=22 was introduced (2006), and until everybody learns that it >exists, and that it's supposed to encompass Alsatian. = > >=22de-FR=22 is still a good workaround for any German language used >in France if the tagger has no clue which of these languages it >is - Alsatian isn't the only game in twown ;-) = A little remark: = Currently ( see http://www.langtag.net/registries/lsr-language-utf8.txt ),= = =22de=22 is for German language only, not for all German languages or = all Germanic languages, in the same way that =22fr=22 do not inclue =22wa=22= (Walloon) or =22pcd=22, and =22en=22 do note include sco (Scots). = If if =22gem=22 where for all Germanic languages (see http://www1.ietf.org/mail-archive/web/ltru/current/msg09258.html http://www1.ietf.org/mail-archive/web/ltru/current/msg09260.html ), = and without other subtag, = gem-fr would be the best tag for all germanic idioms of/in France. = > contains >some examples, in this or another article I found that the = >German language spoken in Strasbourg is neither =22Franconian=22 >nor =22Alemanic=22 but a variant of =22High German=22. St=E9phane picked >an interesting can of worms with his proposal. > > Frank I think that gem-alemanic-gsw-alsacian-Latn-fr could be... hmm, no, forget= this. = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 09 19:16:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCl5u-00062a-5j; Wed, 09 Jan 2008 19:16:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCl5t-00062V-2v for ltru-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 19:16:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCl5s-00062L-PK for ltru@lists.ietf.org; Wed, 09 Jan 2008 19:16:24 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCl5r-0004nI-55 for ltru@lists.ietf.org; Wed, 09 Jan 2008 19:16:24 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JCl5n-0005qj-OA for ltru@lists.ietf.org; Thu, 10 Jan 2008 00:16:19 +0000 Received: from c-180-160-14.hh.dial.de.ignite.net ([62.180.160.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jan 2008 00:16:19 +0000 Received: from nobody by c-180-160-14.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jan 2008 00:16:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 10 Jan 2008 01:16:30 +0100 Organization: Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-14.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs wrote: =20 > Currently "de" is for German language only, not for all German > languages or all Germanic languages, in the same way that "fr" > do not inclue "wa" (Walloon) or "pcd", and "en" do note include > sco (Scots).=20 Yes, Karen mentioned it on the other list, but as St=E9phane noted some days ago some gem languages (not limited to gsw) are close to de, while others such as frr are not. From my POV gsw could also pass as de variant, while frr is a foreign language. Maybe it's similar for wa wrt fr, sco wrt en, etc. > gem-fr would be the best tag for all germanic idioms of/in=20 > France.=20 In theory. It loses the important detail of a close relationship to only one of fr / en / de (etc.) for the corresponding idioms. At some point we're down to what the tagger *knows* and *intends*. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 10 02:55:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsGT-0001Y3-Eb; Thu, 10 Jan 2008 02:55:49 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCsGR-0001Xy-SH for ltru-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 02:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsGL-0001XE-8C for ltru@ietf.org; Thu, 10 Jan 2008 02:55:41 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCsGI-0001oX-UD for ltru@ietf.org; Thu, 10 Jan 2008 02:55:41 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m0A7taY7001567 for ; Thu, 10 Jan 2008 16:55:36 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 229d_6d4f6e0e_bf51_11dc_8c5f_0014221f2a2d; Thu, 10 Jan 2008 16:55:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:57542) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 10 Jan 2008 16:51:26 +0900 Message-Id: <6.0.0.20.2.20080110163909.0aabc5f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 10 Jan 2008 16:40:38 +0900 To: "Mark Davis" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Fwd: Addition request: alsatian In-Reply-To: <30b660a20801091029p3fe7db28tfa787f0c4f399bc8@mail.gmail.co m> References: <20080109014618.0C46D25971E@eikenes.alvestrand.no> <000501c85287$97e9e590$6501a8c0@DGBP7M81> <20080109063453.GB9253@mercury.ccil.org> <001001c852cf$4f219d10$6501a8c0@DGBP7M81> <30b660a20801091029p3fe7db28tfa787f0c4f399bc8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by scmailgw1.scop.aoyama.ac.jp id m0A7taY7001567 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 03:29 08/01/10, Mark Davis wrote: >I think it would be useful to have some language like this in the spec..= .. Doug, you want to take a pass at formulating it, and suggesting a loca= tion? > >On Jan 9, 2008 6:52 AM, Doug Ewell < dewel= l@roadrunner.com> wrote: >>... >> >>"en-US" and "en-CA" mean, roughly, English with specific features >>generally thought to be characteristic of the United States and Canada, >>respectively. They do not imply that a significant dialectical boundar= y=20 >>exists between any arbitrarily selected point in the U.S. and any >>arbitrarily selected point in Canada, which boundary does not exist >>between points within the U.S. or within Canada. I agree with Mark that this is language that should go into our spec. I'd only change one thing: 'characteristic of the United States and Canada' -> 'characteristic of English as used in the United States and Canada' Regards, Martin. >>Region subtags are not precise. This is not a critical problem.=20 >> >>-- >>Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >>http://www.ewellic.org >>http://www1.ietf.org/html.charters/ltru-charter.html >>http://www.al= vestrand.no/mailman/listinfo/ietf-languages =1B$B%R+=EE=1B(B >> >> >>_______________________________________________ >>Ietf-languages mailing list >>Ietf-languages@alvestrand.no >>http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > >--=20 >Mark=20 >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp = =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 10 05:28:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCudl-00063x-GG; Thu, 10 Jan 2008 05:28:01 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JCudk-00063s-30 for ltru-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 05:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCudj-00063e-PE for ltru@lists.ietf.org; Thu, 10 Jan 2008 05:27:59 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCudh-0003sB-AN for ltru@lists.ietf.org; Thu, 10 Jan 2008 05:27:59 -0500 Received: by rv-out-0910.google.com with SMTP id k20so538734rvb.1 for ; Thu, 10 Jan 2008 02:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=sVR8AGJMlvNSHiHXO88SeacPt3T/v5fMaR7gjNlrXic=; b=ZBv4w/13hx4cNYFYkP5XvytYI/ezn72aPftxTkEsTmbANu1GYQp6dod3sXDTLGS3ZmmQQ4PHipvuynLg8IeOwnKj4OzLyMJ7lqibTdEPKGT79x43Z5kTubKaXnTVw4ddOepL6h4UpXU1eDsdISXqYxKeh8zVZKs7tY+9y2WwN+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lAR2Qp5z4BGjkCrF6b6qRXjUOa2kKKv2ytgMQWqpqDyOEnh+xBbhCZxpfiW68kNS3EFsbMC/LrzEWyGNc6ucWWJdxRedr7NHJ028/QqYCXaJzxUTGoRRsYpi1yXH2xdiFmrqW5BMymmpeXfHvTALfG36OGW3RZkZgFR//94X1to= Received: by 10.141.15.19 with SMTP id s19mr1066578rvi.161.1199960876574; Thu, 10 Jan 2008 02:27:56 -0800 (PST) Received: by 10.140.166.2 with HTTP; Thu, 10 Jan 2008 02:27:56 -0800 (PST) Message-ID: <5b0cbc7c0801100227t46bae5b5w802d03efe440a5f1@mail.gmail.com> Date: Thu, 10 Jan 2008 11:27:56 +0100 From: LB To: "Frank Ellermann" Subject: Re: [Ltru] Re: Description on tags, not just subtags? In-Reply-To: MIME-Version: 1.0 References: <005501c84eed$a0579850$6501a8c0@DGBP7M81> <477E6409.5060300@yahoo-inc.com> <000f01c84f31$f8f29b60$6801a8c0@oemcomputer> <20080108090623.GA18206@nic.fr> <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> <5b0cbc7c0801081103h20eecb72o331d8e57e571522d@mail.gmail.com> <00fd01c85230$2b64e700$6801a8c0@oemcomputer> <5b0cbc7c0801090321u5e2c8fadk32561f0e0c5a4b96@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594804494==" Errors-To: ltru-bounces@ietf.org --===============1594804494== Content-Type: multipart/alternative; boundary="----=_Part_10790_4801051.1199960876552" ------=_Part_10790_4801051.1199960876552 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/1/9, Frank Ellermann : > > We're trying to avoid this as it increases the registry, and it > makes matching harder than necessary. Dear Frank, matching means a locutor's and an allocutor's visions being matched. This means some trade-off. If you make it too hard from one of them you will have no match because you will have nothing. When I'm looking for say > Alsatian content I'm not necessarily interested in finding gsw > pages with other Alemannic dialects, or any non-Alemannic pages > roughly passing as "some kind of German language as spoken in > France" when that's *not* Alsatian (e.g. if it is Franconian). I did not react to what was said about my region (French/Breton). But I know Alsatians who would disagree with this. see below. >> The semantics of tag composition from subtags is very much > >> within this group's domain. > > > You mean the syntax? Agreed. > > I guess he means semantics when he says semantics. The only > syntactical problem was my proposal to use prefix gsw-FR for > a variant Alsatian: For constructs like gsw-Brai-FR-alsatian > I'm not sure if our definition of "prefix" covers them. This is a syntax standard. Semantics can only be about the content. Not about operational cases. Otherwise it is not a standard but an opinion. > However, examples should be kept as neutral as possible, > > carrying no pragmatic. > > NAK, it's far easier to look at practical examples where some > of us have an idea what they actually are. Correct, this is why it must be analytical pragmatics. One must not pay so much attention to historical context as you seem to do. > A "de-FR" tag has a significant context attached. > > "Some German language (or dialect) as spoken in France" is > not significant enough to trigger only on Alsatian, if that's > what you mean. Taggers not familiar with the fine print of > gsw and lb, and how to tell what's what, might still try to > use de-FR instead of gsw-FR / lb-FR if it reflects what they > know. Besides the Wikipedia article suggests that High-German > dialects also exist in France, making de-FR fuzzier, it could > be "correct", not only "old" or "better than nothing". Sorry, this is not what I mean. I mean that as a German you may have that context in mind, and as a French I have not the same. So, the example is of no use. The only thing I want to convey is that it will most probably be the same for every example. This is why, as a multilinguist, I am embarassed by some linguist's concepts on this list. They do not fit with ISO 639. Unless Randy is correct and you do not document a single LSR at network level, but an application level system. -- LB ------=_Part_10790_4801051.1199960876552 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/1/9, Frank Ellermann <nobody@xyzzy.claranet.de>:
We're trying to avoid this as it increases the registry, and it
makes matching harder than necessary. 

Dear Frank,
matching means a locutor's and an allocutor's visions being matched.
This means some trade-off. If you make it too hard from one of them
you will have no match because you will have nothing. 

 When I'm looking for say
Alsatian content I'm not necessarily interested in finding gsw
pages with other Alemannic dialects, or any non-Alemannic pages
roughly passing as "some kind of German language as spoken in
France" when that's *not* Alsatian (e.g. if it is Franconian).

I did not react to what was said about my region (French/Breton). 
But I know Alsatians who would disagree with this. see below.

>> The semantics of tag composition from subtags is very much
>> within this group's domain.

> You mean the syntax? Agreed.

I guess he means semantics when he says semantics.  The only
syntactical problem was my proposal to use prefix gsw-FR for
a variant Alsatian:  For constructs like gsw-Brai-FR-alsatian
I'm not sure if our definition of "prefix" covers them.

This is a syntax standard. Semantics can only be about the content.
Not about operational cases. Otherwise it is not a standard but an opinion. 

> However, examples should be kept as neutral as possible,
> carrying no pragmatic.

NAK, it's far easier to look at practical examples where some
of us have an idea what they actually are.

Correct, this is why it must be analytical pragmatics. One must not
pay so much attention to historical context as you seem to do. 

> A "de-FR" tag has a significant context attached.

"Some German language (or dialect) as spoken in France" is
not significant enough to trigger only on Alsatian, if that's
what you mean.  Taggers not familiar with the fine print of
gsw and lb, and how to tell what's what, might still try to
use de-FR instead of gsw-FR / lb-FR if it reflects what they
know.  Besides the Wikipedia article suggests that High-German
dialects also exist in France, making de-FR fuzzier, it could
be "correct", not only "old" or "better than nothing".

Sorry, this is not what I mean. I mean that as a German you 
may have that context in mind, and as a French I have not the 
same. So, the example is of no use. The only thing I want to
convey is that it will most probably be the same for every example.

This is why, as a multilinguist, I am embarassed by some
linguist's concepts on this list. They do not fit with ISO 639. Unless
Randy is correct and you do not document a single LSR at
network level, but an application level system.
--
LB ------=_Part_10790_4801051.1199960876552-- --===============1594804494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1594804494==-- From ltru-bounces@ietf.org Thu Jan 10 16:09:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD4eG-0000kF-4i; Thu, 10 Jan 2008 16:09:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JD4eF-0000k9-9j for ltru-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 16:09:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD4eE-0000k1-Vg for ltru@ietf.org; Thu, 10 Jan 2008 16:09:11 -0500 Received: from relay-1.mailobj.net ([195.234.90.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD4eE-00057h-Bl for ltru@ietf.org; Thu, 10 Jan 2008 16:09:10 -0500 Received: from netcourrier.com (webmail-1.in.mailobj.net [192.168.90.138]) by relay-1.mailobj.net (Postfix) with SMTP id 17BE647AC9 for ; Thu, 10 Jan 2008 22:09:08 +0100 (CET) Received: from [89.2.186.89] by webmail-1.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: Re: [Ltru] Re: Description on tags, not just subtags? Date: Thu, 10 Jan 2008 22:09:08 +0100 Mime-Version: 1.0 X-Priority: 5 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 >Date: Tue, 8 Jan 2008 20:03:04 +0100 >From: LB >To: =22Frank Ellermann=22 >CC: ltru=40lists.ietf.org >To avoid resuming the 1870 war, = Why avoid or no avoid =22resuming the 1870 war=22? = > could it be agreed that: > >1. linguistics is not an exact science >2. several langtags can refer to the same language name, content, >classification, filtering, locale file, ... whatever they are used for? >3. the authoritative reference is the locutor/allocutor couple? > >What is discussed here belongs to local documentation organization (langt= ags >concatenation), not to IETF protocols. The RFC should simply explain how = all >the possible forms of tagging can be handled at local application layer. = How >new real life tagging can be discovered and supported. IMHO going any >further leads to being trapped into nationalistic issues, as expressed by >Frank. They may have local but have no global legitimacy. No, there can not currently be agreement on this. Next question? = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 10 22:32:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDAd3-0007K4-Vr; Thu, 10 Jan 2008 22:32:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JDAd3-0007Jq-9H for ltru-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 22:32:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDAd2-0007GK-Ui for ltru@ietf.org; Thu, 10 Jan 2008 22:32:20 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDAd2-0003kV-La for ltru@ietf.org; Thu, 10 Jan 2008 22:32:20 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080111033219.UWVI5487.mta11.adelphia.net@DGBP7M81>; Thu, 10 Jan 2008 22:32:19 -0500 Message-ID: <006e01c85402$92bd0cb0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 10 Jan 2008 19:32:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.2 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Fwd: Addition request: alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I think it would be useful to have some language like this in the > spec.... Doug, you want to take a pass at formulating it, and > suggesting a location? Well, somewhere within Section 4.1 certainly seems appropriate. I'll try to come up with wording that avoids some of the unfortunate examples I've been choosing in this thread. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 15 13:17:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEqLV-0007DA-HO; Tue, 15 Jan 2008 13:17:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEqLU-0007Cu-MQ for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 13:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEqLU-0007Cf-6h for ltru@ietf.org; Tue, 15 Jan 2008 13:17:08 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEqLT-0002Mm-S0 for ltru@ietf.org; Tue, 15 Jan 2008 13:17:08 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JEqLT-0001wO-CP for ltru@ietf.org; Tue, 15 Jan 2008 13:17:07 -0500 Date: Tue, 15 Jan 2008 13:17:07 -0500 To: ltru@ietf.org Message-ID: <20080115181707.GF16192@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I propose this language for inclusion as a note in the 4646bis section on well-formed and valid tags, because I have found myself typing it, or something like it, several times lately: Well-formed but not valid language tags are not like well-formed but not valid XML. They are much more like unassigned Unicode characters. That is, they should never be used by anyone for any purpose, because at any time they may be assigned an official meaning that will probably conflict with any user-assigned meaning. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! -- one of the verses not usually taught in U.S. schools _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 15 13:24:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEqSx-0005VY-Ko; Tue, 15 Jan 2008 13:24:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEqSv-0005VD-W6 for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 13:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEqSv-0005V3-Ly for ltru@ietf.org; Tue, 15 Jan 2008 13:24:49 -0500 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEqSv-0002WZ-5d for ltru@ietf.org; Tue, 15 Jan 2008 13:24:49 -0500 Received: by wx-out-0506.google.com with SMTP id s8so1958319wxc.31 for ; Tue, 15 Jan 2008 10:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=fGG0/IuRJWO/zjvvPmOX/i5Q5nnDF2o9THaLsVgI2jM=; b=tCCLc6dTlhXsWs4rrbMI2U0fbu+BfBPuUxp8lWX+tx1M9NRFitzMhT3agY4GAUAUP1oeXfkHEeThQWwfFP/ojch6mK7M53dooDYJhJoLMRpoSAZgHA6kvBacHSRSpGls3fuQrl6Uavdp6d7QPlKZsmAFw8RUXKSvYcVuJOJSq5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ins9HWzMOI/e4n51+yGpYmFj0TtswsoGtAVBYNyAxJVL8MfJmGFOpAdrbEqDnHvEE1ZlsUvDgjP0FUtQF851QsU6ZstyOGQCHT8ZfKRT0FakuLSu8OfEyA9PEr+xwcMLKj/W2B4c7bCVo9iw11vaZPQEozSMURBKQh5nyLkUyTU= Received: by 10.142.143.7 with SMTP id q7mr3332893wfd.3.1200421487917; Tue, 15 Jan 2008 10:24:47 -0800 (PST) Received: by 10.143.196.9 with HTTP; Tue, 15 Jan 2008 10:24:47 -0800 (PST) Message-ID: <30b660a20801151024m2e2833c3jaa485730f415092@mail.gmail.com> Date: Tue, 15 Jan 2008 10:24:47 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags In-Reply-To: <20080115181707.GF16192@mercury.ccil.org> MIME-Version: 1.0 References: <20080115181707.GF16192@mercury.ccil.org> X-Google-Sender-Auth: 47dfcee3e665c22a X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1155194226==" Errors-To: ltru-bounces@ietf.org --===============1155194226== Content-Type: multipart/alternative; boundary="----=_Part_2971_26658870.1200421487914" ------=_Part_2971_26658870.1200421487914 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline agreed, with one minor wording change. On Jan 15, 2008 10:17 AM, John Cowan wrote: > I propose this language for inclusion as a note in the 4646bis section > on well-formed and valid tags, because I have found myself typing it, > or something like it, several times lately: > > Well-formed but not valid language tags are not like well-formed > but not valid XML. They are much more like unassigned Unicode > characters. That is, they should never be used by anyone for any > purpose, because at any time they may be assigned an official > meaning that will probably conflict with any user-assigned that would conflict with the user-assigned [we only need one "may" in the sentence.] > > meaning. > > -- > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > O beautiful for patriot's dream that sees beyond the years > Thine alabaster cities gleam undimmed by human tears! > America! America! God mend thine every flaw, > Confirm thy soul in self-control, thy liberty in law! > -- one of the verses not usually taught in U.S. schools > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_2971_26658870.1200421487914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline agreed, with one minor wording change.

On Jan 15, 2008 10:17 AM, John Cowan <cowan@ccil.org> wrote:
I propose this language for inclusion as a note in the 4646bis section
on well-formed and valid tags, because I have found myself typing it,
or something like it, several times lately:

       Well-formed but not valid language tags are not like well-formed
       but not valid XML.  They are much more like unassigned Unicode
       characters.  That is, they should never be used by anyone for any
       purpose, because at any time they may be assigned an official
       meaning that will probably conflict with any user-assigned
that would conflict with the user-assigned
[we only need one "may" in the sentence.]

       meaning.

--
John Cowan  cowan@ccil.org   http://www.ccil.org/~cowan
O beautiful for patriot's dream that sees beyond the years
Thine alabaster cities gleam undimmed by human tears!
America! America!  God mend thine every flaw,
Confirm thy soul in self-control, thy liberty in law!
       -- one of the verses not usually taught in U.S . schools


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



--
Mark ------=_Part_2971_26658870.1200421487914-- --===============1155194226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1155194226==-- From ltru-bounces@ietf.org Tue Jan 15 15:12:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEs9Y-0004qO-Lo; Tue, 15 Jan 2008 15:12:56 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEs9X-0004nV-86 for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:12:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEs9W-0004nN-T7 for ltru@ietf.org; Tue, 15 Jan 2008 15:12:54 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEs9W-0004gr-BG for ltru@ietf.org; Tue, 15 Jan 2008 15:12:54 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007667439.msg for ; Tue, 15 Jan 2008 20:18:53 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 15 Jan 2008 20:12:46 +0000 From: "Debbie Garside" To: "'Peter Constable'" , "'LTRU Working Group'" References: <8F16F2FB-10D0-4BCA-A4A4-A6C04B7B4852@nickshanks.com><20080104195941.GE26881@mercury.ccil.org><99753C3B-E04E-4BDA-AF7E-6FCBCABAEF22@nickshanks.com><20080107153645.GA27859@mercury.ccil.org><22F2281F-688C-433A-93DC-5C84F0C9BBB4@nickshanks.com><007d01c85163$216776a0$6801a8c0@oemcomputer> Subject: RE: [Ltru] Re: Progressing beyond borders-making subtags inclusive Date: Tue, 15 Jan 2008 20:10:49 -0000 Message-ID: <17d401c857b2$bba72df0$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchRYwEWGn5ymImLTMWIYJooF2r1bQADI/KgAZC6lBA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:18:53 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=19009c27a7=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:18:53 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter wrote: Even if there weren't lots of languages, > there is no one convention for tiling the plane of dialects. > (It's hard enough to agree on tiling the plane of languages.) > With some many individual axes of variation, dialect > variation in the wild can sometimes amount to idiolects as > points in a nearly-continuous field. There's no need for > dialect sub-tags unless there is a conventionally-recognized > distinction that is a useful distinction to make in language > resources. Again, I think the best approach is to register > those on a case-by-case basis as needs are identified. I fear the true question is "what is a language/dialect"? Better to work on linguistic entities methinks! Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 07 January 2008 21:01 > To: LTRU Working Group > Subject: RE: [Ltru] Re: Progressing beyond borders-making > subtags inclusive > > > From: Randy Presuhn > > > > I suggested just having those dialects that have names in the > > > general lexicon of speakers of the host language. > Specific needs can > > > continue to be catered for by individual requests. > > > > A couple of obstacles exist to using this kind of approach: > > > > (1) there are *lots* of languages out there... > > > (2) the names and distinctions observed in the general lexicon of > > the speakers of a host language are at best only a starting > > point... > > +1 on both points. Even if there weren't lots of languages, > there is no one convention for tiling the plane of dialects. > (It's hard enough to agree on tiling the plane of languages.) > With some many individual axes of variation, dialect > variation in the wild can sometimes amount to idiolects as > points in a nearly-continuous field. There's no need for > dialect sub-tags unless there is a conventionally-recognized > distinction that is a useful distinction to make in language > resources. Again, I think the best approach is to register > those on a case-by-case basis as needs are identified. > > > > Peter > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 15 15:17:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsE8-0000WI-PV; Tue, 15 Jan 2008 15:17:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEsE8-0000WA-2A for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:17:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsE7-0000Uj-N5 for ltru@ietf.org; Tue, 15 Jan 2008 15:17:39 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEsE7-000587-AF for ltru@ietf.org; Tue, 15 Jan 2008 15:17:39 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007667448.msg for ; Tue, 15 Jan 2008 20:23:38 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 15 Jan 2008 20:17:32 +0000 From: "Debbie Garside" To: "'Nicholas Shanks'" , "'LTRU Working Group'" References: <005501c84eed$a0579850$6501a8c0@DGBP7M81><477E6409.5060300@yahoo-inc.com><000f01c84f31$f8f29b60$6801a8c0@oemcomputer><20080108090623.GA18206@nic.fr> <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> Subject: RE: [Ltru] Re: Description on tags, not just subtags? Date: Tue, 15 Jan 2008 20:15:39 -0000 Message-ID: <17db01c857b3$65ab8080$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchR2QyHa4E5fRD8QeaoRxoJzM6ZaAF2djGA In-Reply-To: <5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:23:38 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=19009c27a7=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:23:38 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicholas wrote: > As I suggested yesterday, I think it would be a good idea to > create a separate list of synonyms encountered 'in the wild' > and which actual tags processors (human and > mechanical) should map them to. I agree. ISO's Standards as Databases initiative should facilitate this. This is also something that I mentioned many moons ago here on LTRU. Best regards Debbie > -----Original Message----- > From: Nicholas Shanks [mailto:contact@nickshanks.com] > Sent: 08 January 2008 09:29 > To: LTRU Working Group > Subject: [Ltru] Re: Description on tags, not just subtags? > > On 8 Jan 2008, at 09:06, Stephane Bortzmeyer wrote: > > > How do you ensure consistency in that case? Today, some people tag > > alsatian as "de-FR", some (very rare, apparently) as > "gsw-FR", some as > > "gsw-x-alsatian" and some as the (invalid) "gsw-alsatian" or > > "alsatian" or "als". > > > > It seems that, for consistent tagging, we need one (1) > authoritative > > source > > I'll wager that those using de-FR, als and so on are not even > looking at the registry, and probably don't know it exists. > They're just applying their existing knowledge of how the > system works and coming up with a less than correct result. > As I suggested yesterday, I think it would be a good idea to > create a separate list of synonyms encountered 'in the wild' > and which actual tags processors (human and > mechanical) should map them to. > > - Nicholas. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 15 15:40:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsZn-0000E9-Hc; Tue, 15 Jan 2008 15:40:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEsZm-0000E3-5U for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsZl-0000Dv-S0 for ltru@ietf.org; Tue, 15 Jan 2008 15:40:01 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEsZk-0005J3-1H for ltru@ietf.org; Tue, 15 Jan 2008 15:40:01 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007667484.msg for ; Tue, 15 Jan 2008 20:45:59 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 15 Jan 2008 20:39:49 +0000 From: "Debbie Garside" To: "'John Cowan'" , References: <20080115181707.GF16192@mercury.ccil.org> Subject: RE: [Ltru] Proposed note on well-formed but not valid language tags Date: Tue, 15 Jan 2008 20:37:55 -0000 Message-ID: <17df01c857b6$82606940$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchXo1gikGMS5EweSC2RZ5vpyD/sKAAEVOeg In-Reply-To: <20080115181707.GF16192@mercury.ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:45:59 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=19009c27a7=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 15 Jan 2008 20:45:59 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John wrote: > Well-formed but not valid language tags are not like well-formed > but not valid XML. They are much more like unassigned Unicode > characters. That is, they should never be used by > anyone for any > purpose, because at any time they may be assigned an official > meaning that will probably conflict with any user-assigned > meaning. I really don't like language that refers the end user to standards that they may be unfamiliar with and that have, as such, nothing to do with language encoding. How about: --- Language tags may be well formed in terms of syntax but not valid in terms of content. Users SHOULD NOT assign and use their own subtags, other than private use codes as designated within the underlying standards, as they may find an as yet unassigned subtag may be officially assigned at a later date with a different meaning. --- Best regards Debbie > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 15 January 2008 18:17 > To: ltru@ietf.org > Subject: [Ltru] Proposed note on well-formed but not valid > language tags > > I propose this language for inclusion as a note in the > 4646bis section on well-formed and valid tags, because I have > found myself typing it, or something like it, several times lately: > > Well-formed but not valid language tags are not like well-formed > but not valid XML. They are much more like unassigned Unicode > characters. That is, they should never be used by > anyone for any > purpose, because at any time they may be assigned an official > meaning that will probably conflict with any user-assigned > meaning. > > -- > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > O beautiful for patriot's dream that sees beyond the years > Thine alabaster cities gleam undimmed by human tears! > America! America! God mend thine every flaw, Confirm thy > soul in self-control, thy liberty in law! > -- one of the verses not usually taught in U.S. schools > > > _______________________________________________ > 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 Jan 15 15:44:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEse2-0004r7-W5; Tue, 15 Jan 2008 15:44:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEse1-0004qk-R9 for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:44:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEse1-0004qc-Es for ltru@ietf.org; Tue, 15 Jan 2008 15:44:25 -0500 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail60-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEse0-0005pD-A9 for ltru@ietf.org; Tue, 15 Jan 2008 15:44:25 -0500 Received: from mail60-dub (localhost.localdomain [127.0.0.1]) by mail60-dub-R.bigfish.com (Postfix) with ESMTP id 1FA9AD30BF2 for ; Tue, 15 Jan 2008 20:43:40 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail60-dub (MessageSwitch) id 1200429815964445_3480; Tue, 15 Jan 2008 20:43:35 +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 mail60-dub.bigfish.com (Postfix) with ESMTP id 27C2FE08088 for ; Tue, 15 Jan 2008 20:43:35 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2008011512433309-53735 ; Tue, 15 Jan 2008 12:43:33 -0800 In-Reply-To: <17df01c857b6$82606940$0b00a8c0@CPQ86763045110> To: ltru@ietf.org Subject: RE: [Ltru] Proposed note on well-formed but not valid language tags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 15 Jan 2008 12:40:49 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/15/2008 12:40:49, Serialize complete at 01/15/2008 12:40:49, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/15/2008 12:43:33 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/15/2008 12:43:35 PM, Serialize complete at 01/15/2008 12:43:35 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1354676518==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1354676518== Content-Type: multipart/alternative; boundary="=_alternative 0071D96F882573D1_=" This is a multipart message in MIME format. --=_alternative 0071D96F882573D1_= Content-Type: text/plain; charset="US-ASCII" >From my perspective, Debbie's suggestion would be more clear to your average end user of the RFC. Karen Broome "Debbie Garside" wrote on 01/15/2008 12:37:55 PM: > John wrote: > > > Well-formed but not valid language tags are not like well-formed > > but not valid XML. They are much more like unassigned Unicode > > characters. That is, they should never be used by > > anyone for any > > purpose, because at any time they may be assigned an official > > meaning that will probably conflict with any user-assigned > > meaning. > > I really don't like language that refers the end user to standards that they > may be unfamiliar with and that have, as such, nothing to do with language > encoding. > > How about: > --- > > Language tags may be well formed in terms of syntax but not valid in terms > of content. Users SHOULD NOT assign and use their own subtags, other than > private use codes as designated within the underlying standards, as they may > find an as yet unassigned subtag may be officially assigned at a later date > with a different meaning. > > --- > > Best regards > > Debbie > > > > -----Original Message----- > > From: John Cowan [mailto:cowan@ccil.org] > > Sent: 15 January 2008 18:17 > > To: ltru@ietf.org > > Subject: [Ltru] Proposed note on well-formed but not valid > > language tags > > > > I propose this language for inclusion as a note in the > > 4646bis section on well-formed and valid tags, because I have > > found myself typing it, or something like it, several times lately: > > > > Well-formed but not valid language tags are not like well-formed > > but not valid XML. They are much more like unassigned Unicode > > characters. That is, they should never be used by > > anyone for any > > purpose, because at any time they may be assigned an official > > meaning that will probably conflict with any user-assigned > > meaning. > > > > -- > > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > O beautiful for patriot's dream that sees beyond the years > > Thine alabaster cities gleam undimmed by human tears! > > America! America! God mend thine every flaw, Confirm thy > > soul in self-control, thy liberty in law! > > -- one of the verses not usually taught in U.S. schools > > > > > > _______________________________________________ > > 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 0071D96F882573D1_= Content-Type: text/html; charset="US-ASCII"
From my perspective, Debbie's suggestion would be more clear to your average end user of the RFC.

Karen Broome

"Debbie Garside" <debbie@ictmarketing.co.uk> wrote on 01/15/2008 12:37:55 PM:

> John wrote:
>
> >    Well-formed but not valid language tags are not like well-formed
> >    but not valid XML.  They are much more like unassigned Unicode
> >    characters.  That is, they should never be used by
> > anyone for any
> >    purpose, because at any time they may be assigned an official
> >    meaning that will probably conflict with any user-assigned
> >    meaning.
>
> I really don't like language that refers the end user to standards that they
> may be unfamiliar with and that have, as such, nothing to do with language
> encoding.
>
> How about:
> ---
>
> Language tags may be well formed in terms of syntax but not valid in terms
> of content.  Users SHOULD NOT assign and use their own subtags, other than
> private use codes as designated within the underlying standards, as they may
> find an as yet unassigned subtag may be officially assigned at a later date
> with a different meaning.
>
> ---
>
> Best regards
>
> Debbie
>
>
> > -----Original Message-----
> > From: John Cowan [mailto:cowan@ccil.org]
> > Sent: 15 January 2008 18:17
> > To: ltru@ietf.org
> > Subject: [Ltru] Proposed note on well-formed but not valid
> > language tags
> >
> > I propose this language for inclusion as a note in the
> > 4646bis section on well-formed and valid tags, because I have
> > found myself typing it, or something like it, several times lately:
> >
> >    Well-formed but not valid language tags are not like well-formed
> >    but not valid XML.  They are much more like unassigned Unicode
> >    characters.  That is, they should never be used by
> > anyone for any
> >    purpose, because at any time they may be assigned an official
> >    meaning that will probably conflict with any user-assigned
> >    meaning.
> >
> > --
> > John Cowan  cowan@ccil.org   http://www.ccil.org/~cowan
> > O beautiful for patriot's dream that sees beyond the years
> > Thine alabaster cities gleam undimmed by human tears!
> > America! America!  God mend thine every flaw, Confirm thy
> > soul in self-control, thy liberty in law!
> >         -- one of the verses not usually taught in U.S. schools
> >
> >
> > _______________________________________________
> > 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 0071D96F882573D1_=-- --===============1354676518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1354676518==-- From ltru-bounces@ietf.org Tue Jan 15 16:38:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtUY-00053w-Nv; Tue, 15 Jan 2008 16:38:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEtUX-0004yu-Q5 for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 16:38:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtUX-0004ym-El for ltru@ietf.org; Tue, 15 Jan 2008 16:38:41 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEtUW-0007EE-Pm for ltru@ietf.org; Tue, 15 Jan 2008 16:38:41 -0500 Received: from [10.72.9.244] (wlanvpn-b4-9-244.burbank.corp.yahoo.com [10.72.9.244]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m0FLcVhd082073; Tue, 15 Jan 2008 13:38:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Xug+Ly0moCFAgUwVe9tZhgcR2isQ/+PWtH2B9GOQqZdivoJVxlQzgNa56SKuzUTo Message-ID: <478D27D7.4050404@yahoo-inc.com> Date: Tue, 15 Jan 2008 13:38:31 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags 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: 093efd19b5f651b2707595638f6c4003 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 Why not use MUST NOT instead of SHOULD NOT? MUST NOT does not prevent people from doing the wrong thing nor does it prevent well-formed-by-not-validating implementations from being written. But it does say, clearly, not to use unregistered junk. SHOULD NOT means "don't unless you have a really good reason to". I cannot think of a single case where there would be a really good reason to (not addressed by private-use codes). Note: to either proposed text, one might note that a validating processor would be within its rights to reject any such tag, making it inoperable. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. Karen_Broome@spe.sony.com wrote: > > From my perspective, Debbie's suggestion would be more clear to your > average end user of the RFC. > > Karen Broome > > > "Debbie Garside" wrote on 01/15/2008 > 12:37:55 PM: > > > John wrote: > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > I really don't like language that refers the end user to standards > that they > > may be unfamiliar with and that have, as such, nothing to do with > language > > encoding. > > > > How about: > > --- > > > > Language tags may be well formed in terms of syntax but not valid in > terms > > of content. Users SHOULD NOT assign and use their own subtags, other > than > > private use codes as designated within the underlying standards, as > they may > > find an as yet unassigned subtag may be officially assigned at a > later date > > with a different meaning. > > > > --- > > > > Best regards > > > > Debbie > > > > > > > -----Original Message----- > > > From: John Cowan [mailto:cowan@ccil.org] > > > Sent: 15 January 2008 18:17 > > > To: ltru@ietf.org > > > Subject: [Ltru] Proposed note on well-formed but not valid > > > language tags > > > > > > I propose this language for inclusion as a note in the > > > 4646bis section on well-formed and valid tags, because I have > > > found myself typing it, or something like it, several times lately: > > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > > > -- > > > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > > O beautiful for patriot's dream that sees beyond the years > > > Thine alabaster cities gleam undimmed by human tears! > > > America! America! God mend thine every flaw, Confirm thy > > > soul in self-control, thy liberty in law! > > > -- one of the verses not usually taught in U.S. schools > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 15 17:15:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEu3l-0001kx-KO; Tue, 15 Jan 2008 17:15:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEu3j-0001kW-Ot for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 17:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEu3j-0001kF-Ci for ltru@ietf.org; Tue, 15 Jan 2008 17:15:03 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEu3i-00082g-6X for ltru@ietf.org; Tue, 15 Jan 2008 17:15:03 -0500 Received: by nz-out-0506.google.com with SMTP id n1so16178nzf.4 for ; Tue, 15 Jan 2008 14:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=4338mfQL3c3uGAPopg7XINdQurHutoCONUDjxhyqPsI=; b=ohUOvhf/bI6tH8kAI5mg86sGLRZ/6craMqLPU9NsyZmWnOKI+I5i9Bi6oUh8cfjtDHzGRgLOqQ+VuYUPf8ZzQ3ql0600myPw+nvkPbvkCByrMy8cBBZOTsaCTHYdWJGFd6sht/99Kue6BqIq9iPUnRPwsnXi3hJ/dd+lKTvzrZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ogDO5QRi+ScAhKchSDB/Fe7mBi/ks+YiB5HMff3zK2wYPErtY2KKM1+Clzvdz70NqwA/n+XY9H7SCjq7pXrd8vsA8UyS/XL7mqcYE/1YMNKrqZwiK2jgw/PHMJU7hpGZ/WiFy2UODFIMsAR891D2z+MIn++OJeXJbMzJgMgrQIA= Received: by 10.142.194.1 with SMTP id r1mr3537008wff.176.1200435301093; Tue, 15 Jan 2008 14:15:01 -0800 (PST) Received: by 10.143.196.9 with HTTP; Tue, 15 Jan 2008 14:15:01 -0800 (PST) Message-ID: <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> Date: Tue, 15 Jan 2008 14:15:01 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags In-Reply-To: <478D27D7.4050404@yahoo-inc.com> MIME-Version: 1.0 References: <478D27D7.4050404@yahoo-inc.com> X-Google-Sender-Auth: b3a92f82b7662494 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Karen_Broome@spe.sony.com, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0318677874==" Errors-To: ltru-bounces@ietf.org --===============0318677874== Content-Type: multipart/alternative; boundary="----=_Part_4794_14438234.1200435301124" ------=_Part_4794_14438234.1200435301124 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Even better. And since conformance to the spec requires it, MUST NOT is the right choice. And I would make your note stronger: A validating processor will reject any such tag, making it inoperable. On Jan 15, 2008 1:38 PM, Addison Phillips wrote: > Why not use MUST NOT instead of SHOULD NOT? > > MUST NOT does not prevent people from doing the wrong thing nor does it > prevent well-formed-by-not-validating implementations from being > written. But it does say, clearly, not to use unregistered junk. SHOULD > NOT means "don't unless you have a really good reason to". I cannot > think of a single case where there would be a really good reason to (not > addressed by private-use codes). > > Note: to either proposed text, one might note that a validating > processor would be within its rights to reject any such tag, making it > inoperable. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > Karen_Broome@spe.sony.com wrote: > > > > From my perspective, Debbie's suggestion would be more clear to your > > average end user of the RFC. > > > > Karen Broome > > > > > > "Debbie Garside" wrote on 01/15/2008 > > 12:37:55 PM: > > > > > John wrote: > > > > > > > Well-formed but not valid language tags are not like well-formed > > > > but not valid XML. They are much more like unassigned Unicode > > > > characters. That is, they should never be used by > > > > anyone for any > > > > purpose, because at any time they may be assigned an official > > > > meaning that will probably conflict with any user-assigned > > > > meaning. > > > > > > I really don't like language that refers the end user to standards > > that they > > > may be unfamiliar with and that have, as such, nothing to do with > > language > > > encoding. > > > > > > How about: > > > --- > > > > > > Language tags may be well formed in terms of syntax but not valid in > > terms > > > of content. Users SHOULD NOT assign and use their own subtags, other > > than > > > private use codes as designated within the underlying standards, as > > they may > > > find an as yet unassigned subtag may be officially assigned at a > > later date > > > with a different meaning. > > > > > > --- > > > > > > Best regards > > > > > > Debbie > > > > > > > > > > -----Original Message----- > > > > From: John Cowan [mailto:cowan@ccil.org] > > > > Sent: 15 January 2008 18:17 > > > > To: ltru@ietf.org > > > > Subject: [Ltru] Proposed note on well-formed but not valid > > > > language tags > > > > > > > > I propose this language for inclusion as a note in the > > > > 4646bis section on well-formed and valid tags, because I have > > > > found myself typing it, or something like it, several times lately: > > > > > > > > Well-formed but not valid language tags are not like well-formed > > > > but not valid XML. They are much more like unassigned Unicode > > > > characters. That is, they should never be used by > > > > anyone for any > > > > purpose, because at any time they may be assigned an official > > > > meaning that will probably conflict with any user-assigned > > > > meaning. > > > > > > > > -- > > > > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > > > O beautiful for patriot's dream that sees beyond the years > > > > Thine alabaster cities gleam undimmed by human tears! > > > > America! America! God mend thine every flaw, Confirm thy > > > > soul in self-control, thy liberty in law! > > > > -- one of the verses not usually taught in U.S. schools > > > > > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_4794_14438234.1200435301124 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Even better. And since conformance to the spec requires it, MUST NOT is the right choice. And I would make your note stronger:

A validating processor will reject any such tag, making it inoperable.

On Jan 15, 2008 1:38 PM, Addison Phillips <addison@yahoo-inc.com> wrote:
Why not use MUST NOT instead of SHOULD NOT?

MUST NOT does not prevent people from doing the wrong thing nor does it
prevent well-formed-by-not-validating implementations from being
written. But it does say, clearly, not to use unregistered junk. SHOULD
NOT means "don't unless you have a really good reason to". I cannot
think of a single case where there would be a really good reason to (not
addressed by private-use codes).

Note: to either proposed text, one might note that a validating
processor would be within its rights to reject any such tag, making it
inoperable.

Addison

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

Internationalization is an architecture.
It is not a feature.


Karen_Broome@spe.sony.com wrote:
>
>  From my perspective, Debbie's suggestion would be more clear to your
> average end user of the RFC.
>
> Karen Broome
>
>
> "Debbie Garside" <debbie@ictmarketing.co.uk> wrote on 01/15/2008
> 12:37:55 PM:
>
>  > John wrote:
>  >
>  > >    Well-formed but not valid language tags are not like well-formed
>  > >    but not valid XML.  They are much more like unassigned Unicode
>  > >    characters.  That is, they should never be used by
>  > > anyone for any
>  > >    purpose, because at any time they may be assigned an official
>  > >    meaning that will probably conflict with any user-assigned
>  > >    meaning.
>  >
>  > I really don't like language that refers the end user to standards
> that they
>  > may be unfamiliar with and that have, as such, nothing to do with
> language
>  > encoding.
>  >
>  > How about:
>  > ---
>  >
>  > Language tags may be well formed in terms of syntax but not valid in
> terms
>  > of content.  Users SHOULD NOT assign and use their own subtags, other
> than
>  > private use codes as designated within the underlying standards, as
> they may
>  > find an as yet unassigned subtag may be officially assigned at a
> later date
>  > with a different meaning.
>  >
>  > ---
>  >
>  > Best regards
>  >
>  > Debbie
>  >
>  >
>  > > -----Original Message-----
>  > > From: John Cowan [mailto: cowan@ccil.org]
>  > > Sent: 15 January 2008 18:17
>  > > To: ltru@ietf.org
>  > > Subject: [Ltru] Proposed note on well-formed but not valid
>  > > language tags
>  > >
>  > > I propose this language for inclusion as a note in the
>  > > 4646bis section on well-formed and valid tags, because I have
>  > > found myself typing it, or something like it, several times lately:
>  > >
>  > >    Well-formed but not valid language tags are not like well-formed
>  > >    but not valid XML.  They are much more like unassigned Unicode
>  > >    characters.  That is, they should never be used by
>  > > anyone for any
>  > >    purpose, because at any time they may be assigned an official
>  > >    meaning that will probably conflict with any user-assigned
>  > >    meaning.
>  > >
>  > > --
>  > > John Cowan  cowan@ccil.org   http://www.ccil.org/~cowan
>  > > O beautiful for patriot's dream that sees beyond the years
>  > > Thine alabaster cities gleam undimmed by human tears!
>  > > America! America!  God mend thine every flaw, Confirm thy
>  > > soul in self-control, thy liberty in law!
>  > >         -- one of the verses not usually taught in U.S. schools
>  > >
>  > >
>  > > _______________________________________________
>  > > Ltru mailing list
>  > > Ltru@ietf.org
>  > > https://www1.ietf.org/mailman/listinfo/ltru
>  > >
>  > >
>  > >
>  >
>  >
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Ltru mailing list
>  > Ltru@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/ltru
>  >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru


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



--
Mark ------=_Part_4794_14438234.1200435301124-- --===============0318677874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0318677874==-- From ltru-bounces@ietf.org Tue Jan 15 19:22:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEw31-0000fM-TF; Tue, 15 Jan 2008 19:22:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JEw30-0000fG-Lu for ltru-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 19:22:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEw30-0000f7-BH for ltru@ietf.org; Tue, 15 Jan 2008 19:22:26 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEw30-0002ny-2l for ltru@ietf.org; Tue, 15 Jan 2008 19:22:26 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JEw2y-00020f-V6; Tue, 15 Jan 2008 19:22:24 -0500 Date: Tue, 15 Jan 2008 19:22:24 -0500 To: Addison Phillips Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags Message-ID: <20080116002224.GA7464@mercury.ccil.org> References: <478D27D7.4050404@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478D27D7.4050404@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Karen_Broome@spe.sony.com, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Why not use MUST NOT instead of SHOULD NOT? I had meant this to be just a note, but if it's going to have RFC 2119 verbs in it, then MUST NOT is certainly correct. -- John Cowan http://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 03:16:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3RR-0006tJ-D7; Wed, 16 Jan 2008 03:16:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF3RP-0006tE-MD for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:16:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3RI-0006sj-BG for ltru@ietf.org; Wed, 16 Jan 2008 03:16:00 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3RG-0007jv-RS for ltru@ietf.org; Wed, 16 Jan 2008 03:16:00 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 013211C00F5; Wed, 16 Jan 2008 09:15:58 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id F07DE1C00ED; Wed, 16 Jan 2008 09:15:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id EDDD858EB7A; Wed, 16 Jan 2008 09:15:57 +0100 (CET) Date: Wed, 16 Jan 2008 09:15:57 +0100 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20080116081557.GA32590@nic.fr> References: <478D27D7.4050404@yahoo-inc.com> <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org Subject: [Ltru] Re: Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 15, 2008 at 02:15:01PM -0800, Mark Davis wrote a message of 203 lines which said: > A validating processor will reject any such tag, It seems a very dangerous idea. Since what is valid for one processor is invalid for another (because they do not use the same version of the LSR, remember that a processor is not forced to fetch the LSR each time it valids) the robustness principle should mean that even validating processors should think twice before rejecting a tag. If the entire purpose of the processor is to validate, for instance, before a publication, yes, I understand the rejection. But in general, it is dangerous. Asking people to *not* produce well-formed-but-invalid tags is one thing. Asking consumers to reject them is another, much more questionable. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 03:43:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3rv-0001Pg-5T; Wed, 16 Jan 2008 03:43:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF3ru-0001PJ-8v for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3rt-0001PB-S1 for ltru@lists.ietf.org; Wed, 16 Jan 2008 03:43:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3rr-0008CW-QS for ltru@lists.ietf.org; Wed, 16 Jan 2008 03:43:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JF3rl-0008TL-Sw for ltru@lists.ietf.org; Wed, 16 Jan 2008 08:43:21 +0000 Received: from c-180-160-2.hh.dial.de.ignite.net ([62.180.160.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 08:43:21 +0000 Received: from nobody by c-180-160-2.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 08:43:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 16 Jan 2008 09:43:43 +0100 Organization: Lines: 9 Message-ID: References: <005501c84eed$a0579850$6501a8c0@DGBP7M81><477E6409.5060300@yahoo-inc.com><000f01c84f31$f8f29b60$6801a8c0@oemcomputer><20080108090623.GA18206@nic.fr><5E36DE2C-6305-4ED0-B9AD-5E5375070304@nickshanks.com> <17db01c857b3$65ab8080$0b00a8c0@CPQ86763045110> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-2.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Description on tags, not just subtags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: [synonyms] > This is also something that I mentioned > many moons ago here on LTRU. Pointer please, I fear I missed this. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 03:49:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3xR-0000yF-0Y; Wed, 16 Jan 2008 03:49:13 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF3xP-0000yA-S8 for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3xP-0000y1-H2 for ltru@lists.ietf.org; Wed, 16 Jan 2008 03:49:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3xP-0008Mx-7O for ltru@lists.ietf.org; Wed, 16 Jan 2008 03:49:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JF3xK-0000Gl-6w for ltru@lists.ietf.org; Wed, 16 Jan 2008 08:49:06 +0000 Received: from c-180-160-2.hh.dial.de.ignite.net ([62.180.160.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 08:49:06 +0000 Received: from nobody by c-180-160-2.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 08:49:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 16 Jan 2008 09:49:33 +0100 Organization: Lines: 10 Message-ID: References: <20080115181707.GF16192@mercury.ccil.org> <17df01c857b6$82606940$0b00a8c0@CPQ86763045110> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-2.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: =20 > I really don't like language that refers the end user to > standards that they may be unfamiliar with and that have, > as such, nothing to do with language encoding. Strong ACK. For obvious reasons we use some ISO standards here. But we do NOT need TUS details, XML, and what else.=20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 05:02:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF56U-0000q3-57; Wed, 16 Jan 2008 05:02:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF56T-0000ox-Ip for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF56S-0000gf-IY for ltru@ietf.org; Wed, 16 Jan 2008 05:02:36 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF56P-0001Oq-N5 for ltru@ietf.org; Wed, 16 Jan 2008 05:02:36 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007669076.msg for ; Wed, 16 Jan 2008 10:08:30 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 16 Jan 2008 10:02:25 +0000 From: "Debbie Garside" To: "'Mark Davis'" , "'Addison Phillips'" References: <478D27D7.4050404@yahoo-inc.com> <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> Subject: RE: [Ltru] Proposed note on well-formed but not valid language tags Date: Wed, 16 Jan 2008 10:00:29 -0000 Message-ID: <18df01c85826$a028d050$0b00a8c0@CPQ86763045110> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchXxHPqRYjGbCpPRFGjpi65hbbBQwAYgJlQ In-Reply-To: <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Wed, 16 Jan 2008 10:08:30 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1901581f20=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Wed, 16 Jan 2008 10:08:30 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: Karen_Broome@spe.sony.com, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0473963068==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0473963068== Content-Type: multipart/alternative; boundary="----=_NextPart_000_18E0_01C85826.A028D050" This is a multi-part message in MIME format. ------=_NextPart_000_18E0_01C85826.A028D050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So do you agree with the following? Language tags may be well formed in terms of syntax but not valid in terms of content. Users MUST NOT assign and use their own subtags, other than private use codes as designated within the underlying standards, as they may find an as yet unassigned subtag may be officially assigned at a later date with a different meaning. Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 15 January 2008 22:15 To: Addison Phillips Cc: Karen_Broome@spe.sony.com; ltru@ietf.org Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags Even better. And since conformance to the spec requires it, MUST NOT is the right choice. And I would make your note stronger: A validating processor will reject any such tag, making it inoperable. On Jan 15, 2008 1:38 PM, Addison Phillips wrote: Why not use MUST NOT instead of SHOULD NOT? MUST NOT does not prevent people from doing the wrong thing nor does it prevent well-formed-by-not-validating implementations from being written. But it does say, clearly, not to use unregistered junk. SHOULD NOT means "don't unless you have a really good reason to". I cannot think of a single case where there would be a really good reason to (not addressed by private-use codes). Note: to either proposed text, one might note that a validating processor would be within its rights to reject any such tag, making it inoperable. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. Karen_Broome@spe.sony.com wrote: > > From my perspective, Debbie's suggestion would be more clear to your > average end user of the RFC. > > Karen Broome > > > "Debbie Garside" wrote on 01/15/2008 > 12:37:55 PM: > > > John wrote: > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > I really don't like language that refers the end user to standards > that they > > may be unfamiliar with and that have, as such, nothing to do with > language > > encoding. > > > > How about: > > --- > > > > Language tags may be well formed in terms of syntax but not valid in > terms > > of content. Users SHOULD NOT assign and use their own subtags, other > than > > private use codes as designated within the underlying standards, as > they may > > find an as yet unassigned subtag may be officially assigned at a > later date > > with a different meaning. > > > > --- > > > > Best regards > > > > Debbie > > > > > > > -----Original Message----- > > > From: John Cowan [mailto: cowan@ccil.org] > > > Sent: 15 January 2008 18:17 > > > To: ltru@ietf.org > > > Subject: [Ltru] Proposed note on well-formed but not valid > > > language tags > > > > > > I propose this language for inclusion as a note in the > > > 4646bis section on well-formed and valid tags, because I have > > > found myself typing it, or something like it, several times lately: > > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > > > -- > > > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > > O beautiful for patriot's dream that sees beyond the years > > > Thine alabaster cities gleam undimmed by human tears! > > > America! America! God mend thine every flaw, Confirm thy > > > soul in self-control, thy liberty in law! > > > -- one of the verses not usually taught in U.S. schools > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark ------=_NextPart_000_18E0_01C85826.A028D050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So do you agree with the following?
 

Language tags may be well formed in terms of syntax = but not=20 valid in terms of content. Users MUST=20 NOT assign and use their own subtags, other than private use = codes as=20 designated within the underlying standards, as they may find an as yet=20 unassigned subtag may be officially assigned at a later date with a = different=20 meaning.

 

Debbie


From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 15 January 2008=20 22:15
To: Addison Phillips
Cc: = Karen_Broome@spe.sony.com;=20 ltru@ietf.org
Subject: Re: [Ltru] Proposed note on = well-formed but=20 not valid language tags

Even better. And since conformance to the spec requires it, = MUST=20 NOT is the right choice. And I would make your note stronger:

A = validating processor will reject any such tag, making it = inoperable.

On Jan 15, 2008 1:38 PM, Addison Phillips = <addison@yahoo-inc.com> = wrote:
Why=20 not use MUST NOT instead of SHOULD NOT?

MUST NOT does not = prevent=20 people from doing the wrong thing nor does it
prevent=20 well-formed-by-not-validating implementations from being
written. = But it=20 does say, clearly, not to use unregistered junk. SHOULD
NOT = means "don't=20 unless you have a really good reason to". I cannot
think of a = single case=20 where there would be a really good reason to (not
addressed by=20 private-use codes).

Note: to either proposed text, one might = note=20 that a validating
processor would be within its rights to reject = any=20 such tag, making it
inoperable.

Addison

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

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


Karen_Broome@spe.sony.com=20 wrote:
>
>  From my perspective, Debbie's = suggestion would=20 be more clear to your
> average end user of the = RFC.
>
>=20 Karen Broome
>
>
> "Debbie Garside" <debbie@ictmarketing.co.uk&g= t;=20 wrote on 01/15/2008
> 12:37:55 PM:
>
>  > = John=20 wrote:
>  >
>  > >   =  Well-formed=20 but not valid language tags are not like well-formed
> =  > >=20    but not valid XML.  They are much more like = unassigned=20 Unicode
>  > >    characters.  That = is,=20 they should never be used by
>  > > anyone for = any
>=20  > >    purpose, because at any time they may = be=20 assigned an official
>  > >    meaning = that will=20 probably conflict with any user-assigned
>  > > =  =20  meaning.
>  >
>  > I really don't = like=20 language that refers the end user to standards
> that = they
>=20  > may be unfamiliar with and that have, as such, nothing to = do with=20
> language
>  > encoding.
> =  >
>=20  > How about:
>  > ---
> =  >
>=20  > Language tags may be well formed in terms of syntax but = not valid=20 in
> terms
>  > of content.  Users SHOULD = NOT=20 assign and use their own subtags, other
> than
> =  >=20 private use codes as designated within the underlying standards, = as
>=20 they may
>  > find an as yet unassigned subtag may be=20 officially assigned at a
> later date
>  > with = a=20 different meaning.
>  >
>  > = ---
>=20  >
>  > Best regards
> =  >
>=20  > Debbie
>  >
>  >
> =  >=20 > -----Original Message-----
>  > > From: John = Cowan=20 [mailto: cowan@ccil.org]
>=20  > > Sent: 15 January 2008 18:17
>  > > = To: ltru@ietf.org
>  > = >=20 Subject: [Ltru] Proposed note on well-formed but not valid
>=20  > > language tags
>  > >
> =  >=20 > I propose this language for inclusion as a note in the
>=20  > > 4646bis section on well-formed and valid tags, = because I=20 have
>  > > found myself typing it, or something = like it,=20 several times lately:
>  > >
>  > = >=20    Well-formed but not valid language tags are not like=20 well-formed
>  > >    but not valid XML.=20  They are much more like unassigned Unicode
>  > = >=20    characters.  That is, they should never be used by =
>  > > anyone for any
>  > > =  =20  purpose, because at any time they may be assigned an = official
>=20  > >    meaning that will probably conflict = with any=20 user-assigned
>  > >    meaning.
> =  > >
>  > > --
>  > > = John=20 Cowan  cowan@ccil.org =   http://www.ccil.org/~cowan
>  > = > O=20 beautiful for patriot's dream that sees beyond the years
> =  >=20 > Thine alabaster cities gleam undimmed by human tears!
>=20  > > America! America!  God mend thine every flaw, = Confirm=20 thy
>  > > soul in self-control, thy liberty in=20 law!
>  > >         -- one of = the=20 verses not usually taught in U.S. schools
>  > = >
>=20  > >
>  > >=20 _______________________________________________
>  > = > Ltru=20 mailing list
>  > > Ltru@ietf.org
>  > = > https://www1.ietf.org/mailman/listinfo/ltru
>=20  > >
>  > >
>  > = >
>=20  >
>  >
>  >
> =  >
>=20  >
>  >
>  >=20 _______________________________________________
>  > = Ltru=20 mailing list
>  > Ltru@ietf.org
>  > = https://www1.ietf.org/mailman/listinfo/ltru
>=20  >
>
>
>=20 = ------------------------------------------------------------------------ =
>
>=20 _______________________________________________
> Ltru mailing = list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

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


--
Mark ------=_NextPart_000_18E0_01C85826.A028D050-- --===============0473963068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0473963068==-- From ltru-bounces@ietf.org Wed Jan 16 09:47:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9Xs-0004HN-1N; Wed, 16 Jan 2008 09:47:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF9Xq-0004HC-TT for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:47:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9Xq-0004H1-JF for ltru@ietf.org; Wed, 16 Jan 2008 09:47:10 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9Xq-00056Z-7S for ltru@ietf.org; Wed, 16 Jan 2008 09:47:10 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080116144709.ECIE5487.mta11.adelphia.net@DGBP7M81> for ; Wed, 16 Jan 2008 09:47:09 -0500 Message-ID: <002d01c8584e$ac6d3270$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 16 Jan 2008 06:47:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > I really don't like language that refers the end user to standards > that they may be unfamiliar with and that have, as such, nothing to do > with language encoding. I agree with this sentiment, and agree with Debbie's proposed rewording, except that it should use "MUST NOT" if it is meant to contain RFC 2119 verbs and "must not" otherwise. I would also hyphenate "as-yet", but that is just me. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 10:01:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9mA-0004fc-BJ; Wed, 16 Jan 2008 10:01:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF9m9-0004Uj-1D for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9m8-0004Rp-LX for ltru@ietf.org; Wed, 16 Jan 2008 10:01:56 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF9m7-0008Sj-63 for ltru@ietf.org; Wed, 16 Jan 2008 10:01:56 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080116150154.OZAU3079.mta10.adelphia.net@DGBP7M81> for ; Wed, 16 Jan 2008 10:01:54 -0500 Message-ID: <002f01c85850$bbe3de00$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 16 Jan 2008 07:01:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ltru] Re: Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stéphane Bortzmeyer wrote: >> A validating processor will reject any such tag, > > It seems a very dangerous idea. Since what is valid for one processor > is invalid for another (because they do not use the same version of > the LSR, remember that a processor is not forced to fetch the LSR each > time it valids) the robustness principle should mean that even > validating processors should think twice before rejecting a tag. In 4646, a validating processor (as opposed to a well-formed processor) is supposed to do exactly this kind of checking. It is also supposed to do things like replacing deprecated subtags with their Preferred-Value (if any) and checking prefixes. A validating processor is required to identify the date of the Registry used for its validity checking, which can then be checked to ensure it is the latest version. Draft-4646bis has replaced the concept of validating and well-formed *processors* with definitions for valid and well-formed *tags*, but the principle is still the same. A validating processor is one that checks a tag to see if it is valid. > If the entire purpose of the processor is to validate, for instance, > before a publication, yes, I understand the rejection. But in general, > it is dangerous. That's what validation is. Not all processors have to be validating (going by the "old" 4646 definition); as you say, there are some circumstances where this is not desired. BTW, while checking Section 2.2.9, I found the following nits: > A tag is considered "valid" if it well-formed and it also satisfies > these conditions: "... if it is well-formed..." " o The tag is either a grandfathered tag, or all of its language, extended language, script, region, and variant subtags appear in the IANA language subtag registry as of the particular registry date." I think the reference to extended language subtags should be removed, since none can appear in the LSR by definition. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 10:09:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9t8-0005a9-Cb; Wed, 16 Jan 2008 10:09:10 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JF9t7-0005a3-Lu for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:09:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9t7-0005Zu-BP for ltru@ietf.org; Wed, 16 Jan 2008 10:09:09 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9t7-0005b5-0i for ltru@ietf.org; Wed, 16 Jan 2008 10:09:09 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080116150908.PFUP3079.mta10.adelphia.net@DGBP7M81> for ; Wed, 16 Jan 2008 10:09:08 -0500 Message-ID: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 16 Jan 2008 07:09:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Update on draft-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ISO 639-3 has announced the results of their latest round of change requests, on time. There were a whopping 258 change requests during the past 6 months, which might indicate that the expected level of churn within 639-3, while not continuing at this pace, will still be quite a bit higher than what ietf-languages is accustomed to. The remaining 10 changes are only promised to be announced "in the coming weeks," so draft-4645bis-04 will probably not be submitted to the RFC Editor until that point. However, I'll post a revision soon that captures the other 248 changes. Can I ask list members to review the text portion of draft-4645bis at least? That part is unlikely to change as the result of future changes to ISO standards. We need to agree (knowledgeably) on the procedure for filling the Registry before presenting it for WG Last Call and IETF Last Call. http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-03.txt I'll make special text-only and data-only copies available, for those who have requested them. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 11:27:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFB69-0002Bi-27; Wed, 16 Jan 2008 11:26:41 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFB67-0002Ba-UX for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:26:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFB67-0002BS-KY for ltru@ietf.org; Wed, 16 Jan 2008 11:26:39 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFB5y-0003Oy-2m for ltru@ietf.org; Wed, 16 Jan 2008 11:26:39 -0500 Received: from [10.72.74.70] (snvvpn1-10-72-74-c70.corp.yahoo.com [10.72.74.70]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m0GGP1UY087762; Wed, 16 Jan 2008 08:25:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Lq0NHMtIknboi7gY5TAiKDyEHteJQaz/IWlNtUGITp3MAhI+jaEmFiJv4EgYyf09 Message-ID: <478E2FDD.1070008@yahoo-inc.com> Date: Wed, 16 Jan 2008 08:25:01 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags References: <478D27D7.4050404@yahoo-inc.com> <30b660a20801151415lf48393ew2b637117dbac6e57@mail.gmail.com> <18df01c85826$a028d050$0b00a8c0@CPQ86763045110> In-Reply-To: <18df01c85826$a028d050$0b00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Karen_Broome@spe.sony.com, 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 I agree with the sentiment but think some editing is in order. Notably, the private use codes you mention are in the registry, while what I had in mind were -x- type private use sequences. Also: I think we have similar text elsewhere in the document and would like to look at the whole and see what makes the most sense. Addison Debbie Garside wrote: > So do you agree with the following? > > > Language tags may be well formed in terms of syntax but not valid in > terms of content. Users MUST NOT assign and use their own subtags, other > than private use codes as designated within the underlying standards, as > they may find an as yet unassigned subtag may be officially assigned at > a later date with a different meaning. > > > > Debbie > > > ------------------------------------------------------------------------ > *From:* Mark Davis [mailto:mark.davis@icu-project.org] > *Sent:* 15 January 2008 22:15 > *To:* Addison Phillips > *Cc:* Karen_Broome@spe.sony.com; ltru@ietf.org > *Subject:* Re: [Ltru] Proposed note on well-formed but not valid > language tags > > Even better. And since conformance to the spec requires it, MUST NOT > is the right choice. And I would make your note stronger: > > A validating processor will reject any such tag, making it inoperable. > > On Jan 15, 2008 1:38 PM, Addison Phillips > wrote: > > Why not use MUST NOT instead of SHOULD NOT? > > MUST NOT does not prevent people from doing the wrong thing nor > does it > prevent well-formed-by-not-validating implementations from being > written. But it does say, clearly, not to use unregistered junk. > SHOULD > NOT means "don't unless you have a really good reason to". I cannot > think of a single case where there would be a really good reason > to (not > addressed by private-use codes). > > Note: to either proposed text, one might note that a validating > processor would be within its rights to reject any such tag, > making it > inoperable. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > Karen_Broome@spe.sony.com wrote: > > > > From my perspective, Debbie's suggestion would be more clear > to your > > average end user of the RFC. > > > > Karen Broome > > > > > > "Debbie Garside" > wrote on 01/15/2008 > > 12:37:55 PM: > > > > > John wrote: > > > > > > > Well-formed but not valid language tags are not like > well-formed > > > > but not valid XML. They are much more like > unassigned Unicode > > > > characters. That is, they should never be used by > > > > anyone for any > > > > purpose, because at any time they may be assigned an > official > > > > meaning that will probably conflict with any > user-assigned > > > > meaning. > > > > > > I really don't like language that refers the end user to > standards > > that they > > > may be unfamiliar with and that have, as such, nothing to > do with > > language > > > encoding. > > > > > > How about: > > > --- > > > > > > Language tags may be well formed in terms of syntax but > not valid in > > terms > > > of content. Users SHOULD NOT assign and use their own > subtags, other > > than > > > private use codes as designated within the underlying > standards, as > > they may > > > find an as yet unassigned subtag may be officially > assigned at a > > later date > > > with a different meaning. > > > > > > --- > > > > > > Best regards > > > > > > Debbie > > > > > > > > > > -----Original Message----- > > > > From: John Cowan [mailto: cowan@ccil.org > ] > > > > Sent: 15 January 2008 18:17 > > > > To: ltru@ietf.org > > > > Subject: [Ltru] Proposed note on well-formed but not valid > > > > language tags > > > > > > > > I propose this language for inclusion as a note in the > > > > 4646bis section on well-formed and valid tags, because I > have > > > > found myself typing it, or something like it, several > times lately: > > > > > > > > Well-formed but not valid language tags are not like > well-formed > > > > but not valid XML. They are much more like > unassigned Unicode > > > > characters. That is, they should never be used by > > > > anyone for any > > > > purpose, because at any time they may be assigned an > official > > > > meaning that will probably conflict with any > user-assigned > > > > meaning. > > > > > > > > -- > > > > John Cowan cowan@ccil.org > http://www.ccil.org/~cowan > > > > O beautiful for patriot's dream that sees beyond the years > > > > Thine alabaster cities gleam undimmed by human tears! > > > > America! America! God mend thine every flaw, Confirm thy > > > > soul in self-control, thy liberty in law! > > > > -- one of the verses not usually taught in U.S. > schools > > > > > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 12:00:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBdJ-0002wo-GT; Wed, 16 Jan 2008 12:00:57 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFBdI-0002w0-2e for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:00:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBdH-0002vs-Ov for ltru@ietf.org; Wed, 16 Jan 2008 12:00:55 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFBdG-0004Ly-Ah for ltru@ietf.org; Wed, 16 Jan 2008 12:00:55 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 16 Jan 2008 09:00:53 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Wed, 16 Jan 2008 09:00:53 -0800 From: Peter Constable To: Doug Ewell , LTRU Working Group Date: Wed, 16 Jan 2008 09:00:52 -0800 Subject: RE: [Ltru] Update on draft-4645bis Thread-Topic: [Ltru] Update on draft-4645bis Thread-Index: AchYUcQb9VeTHNuAT3eTsRPq7pNBsgADZyIQ Message-ID: References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> In-Reply-To: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0046696723==" Errors-To: ltru-bounces@ietf.org --===============0046696723== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNiwgMjAwOCA3 OjA5IEFNDQoNCj4gSVNPIDYzOS0zIGhhcyBhbm5vdW5jZWQgdGhlIHJlc3VsdHMgb2YgdGhlaXIg bGF0ZXN0IHJvdW5kIG9mIGNoYW5nZQ0KPiByZXF1ZXN0cy4uLg0KDQpUaGVyZSBpcyBvbmUgY2hh bmdlIHRoYXQgSSdtIHF1ZXN0aW9uaW5nOiByZW1vdmFsIG9mIGEgbWFjcm9sYW5ndWFnZSBtYXBw aW5nLg0KDQpUaGUgZW50cnkgemhhICJaaHVhbmciIGlzIGEgbWFjcm9sYW5ndWFnZTsgaXQgZm9y bWVybHkgaGFkIHR3byBlbmNvbXBhc3NlZCBsYW5ndWFnZXMsIGNjeCAiTm9ydGhlcm4gWmh1YW5n IiBhbmQgY2N5ICJTb3V0aGVybiBaaHVhbmciLiBUaGlzIHdhcyB0aGUgc3RhdGUgYXQgaW5pdGlh bCBwdWJsaWNhdGlvbiBvZiBJU08gNjM5LTMuIE5vdywgcmVzZWFyY2hlcnMgaGF2ZSBkZXRlcm1p bmVkIChub3QgYXQgYWxsIHN1cnByaXNpbmdseSkgdGhhdCB0aGUgWmh1YW5nIGZhbWlseSBpcyBy ZWFsbHkgbWFkZSB1cCBvZiBtb3JlIHRoYW4gdHdvIGluZGl2aWR1YWwgbGFuZ3VhZ2VzLiBUaHVz LCBvbmUgb2YgdGhpcyByb3VuZCBvZiBjaGFuZ2VzIGhhcyBiZWVuIHRvIHNwbGl0IE5vcnRoZXJu IFpodWFuZyBpbnRvIHRlbiBsYW5ndWFnZXMgLS0gaS5lLiwgdG8gZGVwcmVjYXRlIGNjeCByZWNv bW1lbmRpbmcgdGhlIHVzZSBvZiB0ZW4gbmV3IElEcyBpbnN0ZWFkLiBUaGVzZSB0ZW4gbmV3IGVu dHJpZXMgYXJlIGdpdmVuIG1hY3JvbGFuZ3VhZ2UgbWFwcGluZ3MgdG8gemhhLiBBbGwgb2YgdGhh dCBpcyBmaW5lLiBIb3dldmVyLCBpbiBkZXByZWNhdGluZyBjY3gsIHRoZSBJU08gNjM5LTMvUkEg aGFzIGFsc28gcmVtb3ZlZCBpdHMgbWFjcm9sYW5ndWFnZSBtYXBwaW5nIHRvIHpoYS4NCg0KSSBo YWRuJ3QgcmVhbGl6ZWQgKG9yIGRvbid0IHJlY2FsbCBub3RpY2luZykgdGhhdCBhIHNpbWlsYXIg Y2hhbmdlIHdhcyBtYWRlIGR1cmluZyAyMDA2IHdydCBTb3V0aGVybiBaaHVhbmcsIHdpdGggaXRz IG1hY3JvbGFuZ3VhZ2UgbWFwcGluZyB0byB6aGEgYWxzbyByZW1vdmVkLg0KDQpGb3Igb3VyIHB1 cnBvc2VzICh0aGlua2luZyBpbiB0ZXJtcyBvZiBvbi1nb2luZyBvcGVyYXRpb25hbCBwcm9jZWR1 cmVzLCBzbyBzcGVha2luZyBoZXJlIGZvciBzYWtlIG9mIGRpc2N1c3Npb24gYXMgdGhvdWdoIDQ2 NDZiaXMgd2VyZSBhbHJlYWR5IGFwcHJvdmVkKSwgd2UgY2FuIGNlcnRhaW5seSBkZXByZWNhdGUg Y2N4IGFuZCBjY3ksIGJ1dCBJIHdvdWxkIHRoaW5rIHdlIHdvdWxkIG5vdCB3YW50IHRvIHJlbW92 ZSB0aGUgTWFjcm9sYW5ndWFnZSBmaWVsZCBmcm9tIHRob3NlIGVudHJpZXMuDQoNCk9yIGRvIHdl IGNhcmU/DQoNCg0KUGV0ZXINCg== --===============0046696723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0046696723==-- From ltru-bounces@ietf.org Wed Jan 16 12:23:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBzF-0004NZ-2u; Wed, 16 Jan 2008 12:23:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFBzE-0004NP-MH for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBzE-0004NH-CP for ltru@ietf.org; Wed, 16 Jan 2008 12:23:36 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFBzE-0004yE-2o for ltru@ietf.org; Wed, 16 Jan 2008 12:23:36 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JFBzB-000155-ET; Wed, 16 Jan 2008 12:23:33 -0500 Date: Wed, 16 Jan 2008 12:23:33 -0500 To: Peter Constable Subject: Re: [Ltru] Update on draft-4645bis Message-ID: <20080116172332.GJ14010@mercury.ccil.org> References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Peter Constable scripsit: > For our purposes (thinking in terms of on-going operational procedures, > so speaking here for sake of discussion as though 4646bis were already > approved), we can certainly deprecate ccx and ccy, but I would think > we would not want to remove the Macrolanguage field from those entries. I think the general principle is that we don't remove anything, because of backward compatibility. The exception would be an old name that is a trivial variant of the new name (typo, or added hyphen, or some such) or is offensive. We already provide for the former case, but we may need new language for the latter. (Addison?) > Or do we care? Nobody knows if we care or not, because nobody knows what uptake the Macrolanguage: header will have, if any. I wish that SIL had made Northern and Southern Zhang into nested macrolanguages instead of just deprecating them, since they are pretty well recognized terms. -- There are three kinds of people in the world: John Cowan those who can count, cowan@ccil.org and those who can't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 12:24:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFC0N-0004zL-LR; Wed, 16 Jan 2008 12:24:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFC0L-0004yT-TZ for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:24:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFC0L-0004yL-Jt for ltru@ietf.org; Wed, 16 Jan 2008 12:24:45 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFC0K-0004zG-21 for ltru@ietf.org; Wed, 16 Jan 2008 12:24:45 -0500 Received: from [10.72.74.70] (snvvpn1-10-72-74-c70.corp.yahoo.com [10.72.74.70]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m0GHOTxk037762; Wed, 16 Jan 2008 09:24:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=wqX23g9ozOnCGSmggWXYMoaUzRQgqDsVYf3ozbb6YpAsPlRryIzLl2EnaLj3oeMP Message-ID: <478E3DCC.40102@yahoo-inc.com> Date: Wed, 16 Jan 2008 09:24:28 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Update on draft-4645bis References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Peter Constable wrote: >> From: Doug Ewell >> Sent: Wednesday, January 16, 2008 7:09 AM > >> ISO 639-3 has announced the results of their latest round of change >> requests... > > There is one change that I'm questioning: removal of a macrolanguage mapping. > > The entry zha "Zhuang" is a macrolanguage; it formerly had two encompassed languages, ccx "Northern Zhuang" and ccy "Southern Zhuang". This was the state at initial publication of ISO 639-3. Now, researchers have determined (not at all surprisingly) that the Zhuang family is really made up of more than two individual languages. Thus, one of this round of changes has been to split Northern Zhuang into ten languages -- i.e., to deprecate ccx recommending the use of ten new IDs instead. These ten new entries are given macrolanguage mappings to zha. All of that is fine. However, in deprecating ccx, the ISO 639-3/RA has also removed its macrolanguage mapping to zha. > > I hadn't realized (or don't recall noticing) that a similar change was made during 2006 wrt Southern Zhuang, with its macrolanguage mapping to zha also removed. > > For our purposes (thinking in terms of on-going operational procedures, so speaking here for sake of discussion as though 4646bis were already approved), we can certainly deprecate ccx and ccy, but I would think we would not want to remove the Macrolanguage field from those entries. > > Or do we care? > > One thing this suggests: perhaps we should provide a mechanism for doing smaller "bulk" updates from ISO 639-3 (etc.) in which more than a single record can be updated/inserted. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 16 15:35:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEyd-00068W-Aq; Wed, 16 Jan 2008 15:35:11 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFEyb-00066r-US for ltru-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 15:35:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEyb-00066j-KF for ltru@lists.ietf.org; Wed, 16 Jan 2008 15:35:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFEyZ-0001uB-CG for ltru@lists.ietf.org; Wed, 16 Jan 2008 15:35:09 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JFEyU-0005OO-9Q for ltru@lists.ietf.org; Wed, 16 Jan 2008 20:35:02 +0000 Received: from c-180-160-2.hh.dial.de.ignite.net ([62.180.160.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 20:35:02 +0000 Received: from nobody by c-180-160-2.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2008 20:35:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 16 Jan 2008 21:34:47 +0100 Organization: Lines: 9 Message-ID: References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-2.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Update on draft-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Or do we care? Yes. I think it's the idea of the Macrolanguage field that=20 the registry can reflect the state of the art in 639-3, and isn't forced to preserve an old state in the form of extlang. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 17 16:56:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFciK-00011e-KL; Thu, 17 Jan 2008 16:55:56 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFciJ-0000zA-OC for ltru-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 16:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFciJ-0000we-DP for ltru@ietf.org; Thu, 17 Jan 2008 16:55:55 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFciI-0007Nl-SW for ltru@ietf.org; Thu, 17 Jan 2008 16:55:55 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m0HLteZ8027875; Thu, 17 Jan 2008 13:55:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=C/s/wEcaXIudeN/ffK0NcKe2YXtTzBuiuaElfL+Q6p0f2kPSRchKx69Tctk1Ot0R Message-ID: <478FCEDB.1080102@yahoo-inc.com> Date: Thu, 17 Jan 2008 13:55:39 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: public-i18n-core@w3.org Subject: [Ltru] ABNF guidance X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, (This note is being sent on behalf of the W3C Internationalization Core Working Group, which I happen to chair. Note that this also means that it is as a technical contributor and not as editor of 4646bis) During our most recent teleconference [1], the I18N Core WG discussed the changes proposed for the ABNF by LTRU (to remove the extlang production). I was tasked with reporting some concerns about how to address this with Spec writers at W3C and elsewhere. The concern is that the I18N Core WG has been recommending that references to RFC 3066 be changed to reference BCP 47 (rather than a specific RFC number). In one particular case (XML Schema 1.1) we requested that their language production be derived from the ABNF in BCP 47, that is, from the ABNF in RFC 4646. The problem is that productions included into XML DTDs are then relied upon by implementations and difficult to change. There is naturally some resistance to changing the production in XML Schema and some concern that the grammar isn't fully stabilized. There is thus concern about the future stability of the ABNF. The I18N Core WG would therefore like to know: - if LTRU can make a stability statement about the ABNF in 4646bis (e.g. what may change in the future and what is unlikely to change) - if LTRU could include text about compatibility between 4646 ABNF and 4646bis ABNF in 4646bis - if LTRU would recommend a particular reference to an RFC or continue to recommend the BCP reference for this purpose Best Regards, Addison [1] http://www.w3.org/2008/01/16-core-minutes#item06 -- 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 Jan 18 00:51:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFk8s-0001SP-6N; Fri, 18 Jan 2008 00:51:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFk8q-0001Pl-UV for ltru-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFk8q-0001Pc-Kg for ltru@ietf.org; Fri, 18 Jan 2008 00:51:48 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFk8p-0006yL-1O for ltru@ietf.org; Fri, 18 Jan 2008 00:51:48 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=g4NsTWyQ4vDUtvaH0XTSUDD4BdmA6u4iqq+wKNdWI8c2CUQZ8eMwccTg6ARqP87L; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.159] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JFk8o-00037o-CW for ltru@ietf.org; Fri, 18 Jan 2008 00:51:46 -0500 Message-ID: <000d01c85996$6ff73ea0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 17 Jan 2008 21:53:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117fd1b20bc1a9441c59a56e7813a550246350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.159 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, 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 - For your information.... Randy > From: > To: > Sent: Thursday, January 17, 2008 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA > > > There are two (2) Internet-Draft cutoff dates for the 71st > IETF Meeting in Philadelphia, PA, USA: > > February 18th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for > version -00 WG drafts that replace existing non-WG drafts. Such drafts > may be submitted until the cutoff date for version -01 and higher > drafts. > 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, February 11th at 9:00 AM ET (14:00 UTC/GMT). > > February (14:00 UTC/GMT): 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, February 25th at 9:00 AM ET (14:00 UTC/GMT). > > 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, March 10th at 9:00 > AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via the > Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. > If you are unable to do so, then you may still submit your Internet- > Drafts manually by sending them to internet-drafts@ietf.org. If you > are submitting a version -00 WG draft that replaces non-WG draft, then > you must submit it manually as the current IDST cannot handle > replacements. Please be sure to state that one draft replaces another > in the cover note that accompanies your submission. Also, please note > that the IDST will not accept drafts submitted after their respective > cutoff dates. > > 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 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.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 Jan 18 04:04:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFn8p-0007YT-IX; Fri, 18 Jan 2008 04:03:59 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFn8o-0007YO-3l for ltru-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFn8n-0007YG-Q8 for ltru@lists.ietf.org; Fri, 18 Jan 2008 04:03:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFn8l-00028a-U4 for ltru@lists.ietf.org; Fri, 18 Jan 2008 04:03:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JFn8h-0001k7-N1 for ltru@lists.ietf.org; Fri, 18 Jan 2008 09:03:51 +0000 Received: from c-134-88-10.hh.dial.de.ignite.net ([62.134.88.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2008 09:03:51 +0000 Received: from nobody by c-134-88-10.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2008 09:03:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Fri, 18 Jan 2008 10:04:14 +0100 Organization: Lines: 65 Message-ID: References: <478FCEDB.1080102@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-10.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Ltru] Re: ABNF guidance X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I was tasked with reporting some concerns Note it as *done*. > In one particular case (XML Schema 1.1) we requested that their > language production be derived from the ABNF in BCP 47, that is, > from the ABNF in RFC 4646. Is that about ? That says [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* based on RFC 3066, perfectly compatible with 4646 or 4646bis. For I'm not sure what it means, but it's no "help, the IETF screwed up". And in the second comment did not yet hardwire any soon obsolete 4646 ABNF.=20 > There is naturally some resistance to changing the production > in XML Schema and some concern that the grammar isn't fully > stabilized. There is thus concern about the future stability > of the ABNF. "Stablity" can mean lots of things. A future extension could introduce a limit "6" for its own hyphen-separated "items". It can't introduce "9" without breaking the old RFC 3066 limits, of course RFC 4646 and likely I-D.4646bis also don't allow "9". > - if LTRU can make a stability statement about the ABNF in > 4646bis (e.g. what may change in the future and what is > unlikely to change) =20 I certainly expect 4646bis to be backwards compatible with 4646 and 3066. I'd have some reservations about 4646bis stability statements. The proposed "fantasy island" codes are not funny, at the moment it's not clear that 4646bis survives a Last Call. > - if LTRU could include text about compatibility between 4646 > ABNF and 4646bis ABNF in 4646bis LTRU could, but it's completely beside the point, the *reserved* contruct was removed. 4646 parsers accepting it will continue to work for 4646bis tags, that was precisely the point of the reservation. The opposite case, 4646bis introduces a new contruct breaking 4646 parsers, would be bad, and 4646 saw to it that it won't happen. If that doesn't talk for itself then more text about this historical curiosity also won't help.=20 > - if LTRU would recommend a particular reference to an RFC or > continue to recommend the BCP reference for this purpose That's up to the specification using it, e.g. an implementation expecting US-ASCII with hex. NCRs in the "BCP 47 registry" will fail miserably when 4646bis introduces UTF-8 without NCRs. So in that case referencing RFC 4646 would have been clearer, even if it doesn't help to fix the implementation. =20 OTOH HTTPbis can pick whatever it likes, BCP 47 or RFC 4646, it does not depend on the version, it has to fix the RFC 2616 ABNF for language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 18 08:37:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrP2-0002Al-JS; Fri, 18 Jan 2008 08:37:00 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JFrP1-00024a-GZ for ltru-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:36:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrP1-00024D-6P for ltru@ietf.org; Fri, 18 Jan 2008 08:36:59 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFrP0-0007oQ-Iq for ltru@ietf.org; Fri, 18 Jan 2008 08:36:59 -0500 Received: by py-out-1112.google.com with SMTP id x19so1262464pyg.24 for ; Fri, 18 Jan 2008 05:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=B0h0dNBvkyKU6SvzzK/v0U5POD8YP3pvpMY7KvfPvAI=; b=MYUaS8S5bWU1gJXyha+/h+T+ZxjeDunMKwOU96SUf8kBvt6JlYPIsaSaDLSwEWRrcb8EGTKeeN0ZAGAr11v7ePDz9c7ZX45ndzJdlpUQSwYbRY02PQg6dE0SJYzG9He69iBkziYPamMLk7PbwXOuqu3C2vEDWs+bJ64EreXnC7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dCHomqjtmF0TDVSm6D5tiuOyHlsW8eFoeQoqKwUfxhhaTnbNWTxZnpLvcpKTZuNNVZdQeHpXlCTRNXv3UtuWTzfMTZigBQTy5vsyFyLZfjaI2+G1GPvA+7i96CQ6haSasjp7crDkTGsjiN+NERW1f/KLnMfS/ObvQV12AFluADw= Received: by 10.140.251.1 with SMTP id y1mr2379933rvh.107.1200663415526; Fri, 18 Jan 2008 05:36:55 -0800 (PST) Received: by 10.140.166.2 with HTTP; Fri, 18 Jan 2008 05:36:55 -0800 (PST) Message-ID: <5b0cbc7c0801180536y2c90c45eg1288d92ffd1dc67d@mail.gmail.com> Date: Fri, 18 Jan 2008 14:36:55 +0100 From: LB To: ltru@ietf.org Subject: Fwd: [Ltru] Proposed note on well-formed but not valid language tags In-Reply-To: <5b0cbc7c0801170945hb4fd125xdb9c8e89b596972e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17df01c857b6$82606940$0b00a8c0@CPQ86763045110> <5b0cbc7c0801170945hb4fd125xdb9c8e89b596972e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 do not know why this mail did not make it to the list. Sorry. LB ---------- Forwarded message ---------- From: LB Date: Thu, 17 Jan 2008 18:45:19 +0100 Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags To: "Karen_Broome@spe.sony.com" 2008/1/15, Karen_Broome@spe.sony.com : > > > From my perspective, Debbie's suggestion would be more clear to your > average end user of the RFC. Respectfully, there is no "RFC end user", only "RFC users". I cannot make my mind about this important wording. I need Randy to answer first the question he made me to prompt. If RFC 4646 is not only for the IANA LSR the wording should take it into account. Methink straight ISO 639-3 (and ISO 639-6) code elements would be simpler for those Karen refers to. -- LB Karen Broome > > > "Debbie Garside" wrote on 01/15/2008 12:37:55 > PM: > > > John wrote: > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > I really don't like language that refers the end user to standards that > they > > may be unfamiliar with and that have, as such, nothing to do with > language > > encoding. > > > > How about: > > --- > > > > Language tags may be well formed in terms of syntax but not valid in > terms > > of content. Users SHOULD NOT assign and use their own subtags, other > than > > private use codes as designated within the underlying standards, as they > may > > find an as yet unassigned subtag may be officially assigned at a later > date > > with a different meaning. > > > > --- > > > > Best regards > > > > Debbie > > > > > > > -----Original Message----- > > > From: John Cowan [mailto:cowan@ccil.org] > > > Sent: 15 January 2008 18:17 > > > To: ltru@ietf.org > > > Subject: [Ltru] Proposed note on well-formed but not valid > > > language tags > > > > > > I propose this language for inclusion as a note in the > > > 4646bis section on well-formed and valid tags, because I have > > > found myself typing it, or something like it, several times lately: > > > > > > Well-formed but not valid language tags are not like well-formed > > > but not valid XML. They are much more like unassigned Unicode > > > characters. That is, they should never be used by > > > anyone for any > > > purpose, because at any time they may be assigned an official > > > meaning that will probably conflict with any user-assigned > > > meaning. > > > > > > -- > > > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > > O beautiful for patriot's dream that sees beyond the years > > > Thine alabaster cities gleam undimmed by human tears! > > > America! America! God mend thine every flaw, Confirm thy > > > soul in self-control, thy liberty in law! > > > -- one of the verses not usually taught in U.S. schools > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- LB -- LB _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 19 13:01:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGI0S-0006Ts-RI; Sat, 19 Jan 2008 13:01:24 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGI0S-0006Tn-Jq for ltru-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 13:01:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGI0S-0006Tf-AJ for ltru@ietf.org; Sat, 19 Jan 2008 13:01:24 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGI0Q-0003xi-Sb for ltru@ietf.org; Sat, 19 Jan 2008 13:01:24 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080119180121.BYJS24798.mta13.adelphia.net@DGBP7M81> for ; Sat, 19 Jan 2008 13:01:21 -0500 Message-ID: <000d01c85ac5$4d7835c0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 19 Jan 2008 10:01:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Re: Proposed note on well-formed but not valid language tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips replied to Debbie Garside: >> Language tags may be well formed in terms of syntax but not valid in >> terms of content. Users MUST NOT assign and use their own subtags, >> other >> than private use codes as designated within the underlying standards, >> as >> they may find an as yet unassigned subtag may be officially assigned >> at >> a later date with a different meaning. > > I agree with the sentiment but think some editing is in order. > Notably, > the private use codes you mention are in the registry, while what I > had > in mind were -x- type private use sequences. Also: I think we have > similar text elsewhere in the document and would like to look at the > whole and see what makes the most sense. I don't see why the private-use subtags in the Registry wouldn't be at least as appropriate as the x-type sequences for this and other uses. They do have the advantage that you can parse them and figure out syntactically what kind of entity they represent: qaa -- definitely some language nl-Qaaa -- definitely Dutch written in some script nl-AA -- definitely Dutch as used in some region nl-x-ongeacht -- can't tell what kind of entity "ongeacht" is -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 19 13:09:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGI8i-0001xR-By; Sat, 19 Jan 2008 13:09:56 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGI8h-0001tu-G2 for ltru-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 13:09:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGI8h-0001tl-5k for ltru@ietf.org; Sat, 19 Jan 2008 13:09:55 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGI8g-000126-SY for ltru@ietf.org; Sat, 19 Jan 2008 13:09:55 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080119180954.SNQI5487.mta11.adelphia.net@DGBP7M81> for ; Sat, 19 Jan 2008 13:09:54 -0500 Message-ID: <001101c85ac6$7ea7a6c0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 19 Jan 2008 10:09:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: ABNF guidance X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > I'd have some reservations about 4646bis stability statements. The > proposed "fantasy island" codes are not funny, at the moment it's not > clear that 4646bis survives a Last Call. As much as I dislike adding the exceptionally reserved ISO 3166 code elements --especially since the reason was to facilitate 'EU' for locale-type usage rather than language tagging -- this decision has nothing to do with stability of the ABNF or anything else. The only impact they could have on stability would be if they were deleted at some later date, instead of deprecated. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 19 13:19:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIHj-0004PL-Vz; Sat, 19 Jan 2008 13:19:15 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGIHj-0004PD-6C for ltru-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 13:19:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIHi-0004Oz-Rk for ltru@ietf.org; Sat, 19 Jan 2008 13:19:14 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGIHi-0001Hm-Ih for ltru@ietf.org; Sat, 19 Jan 2008 13:19:14 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080119181913.EKGH3079.mta10.adelphia.net@DGBP7M81>; Sat, 19 Jan 2008 13:19:13 -0500 Message-ID: <001a01c85ac7$cc3eab30$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> <20080116172332.GJ14010@mercury.ccil.org> Subject: Re: [Ltru] Update on draft-4645bis Date: Sat, 19 Jan 2008 10:19:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I wish that SIL had made Northern and Southern Zhang into nested > macrolanguages instead of just deprecating them, since they are pretty > well recognized terms. Is there any indication that ISO 639-3 (the standard or the RA) recognizes the concept of nested macrolanguages? I haven't seen any. I know the rejected extlang mechanism would have allowed for up to three levels, just in case they did exist. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 19 13:39:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIbF-0002DJ-9c; Sat, 19 Jan 2008 13:39:25 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGIbE-0002Cc-CT for ltru-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 13:39:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIbE-0002CU-29 for ltru@ietf.org; Sat, 19 Jan 2008 13:39:24 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGIbD-0001lP-QX for ltru@ietf.org; Sat, 19 Jan 2008 13:39:23 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JGIb9-0002jj-TR; Sat, 19 Jan 2008 13:39:19 -0500 Date: Sat, 19 Jan 2008 13:39:19 -0500 To: Doug Ewell Subject: Re: [Ltru] Update on draft-4645bis Message-ID: <20080119183919.GC1427@mercury.ccil.org> References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> <20080116172332.GJ14010@mercury.ccil.org> <001a01c85ac7$cc3eab30$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c85ac7$cc3eab30$6501a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Is there any indication that ISO 639-3 (the standard or the RA) > recognizes the concept of nested macrolanguages? I haven't seen any. No, but nor is there any indication that they accept or even understand the concept, either. -- When I'm stuck in something boring John Cowan where reading would be impossible or (who loves Asimov too) rude, I often set up math problems for cowan@ccil.org myself and solve them as a way to pass http://www.ccil.org/~cowan the time. --John Jenkins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 19 22:44:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGR74-0007ZM-G4; Sat, 19 Jan 2008 22:44:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGR73-0007ZH-Ac for ltru-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 22:44:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGR72-0007Z9-Vb for ltru@ietf.org; Sat, 19 Jan 2008 22:44:49 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGR72-0007Jn-CU for ltru@ietf.org; Sat, 19 Jan 2008 22:44:48 -0500 Received: from [10.72.76.106] (snvvpn2-10-72-76-c106.corp.yahoo.com [10.72.76.106]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id m0K3iWa8028928; Sat, 19 Jan 2008 19:44:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=gfB6JSjquHqHjgyzhmcUuFryMWtQaezCaPzmOArrRQEYcNf8SYubd9ridPWArZwX Message-ID: <4792C3A0.5030602@yahoo-inc.com> Date: Sat, 19 Jan 2008 19:44:32 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Proposed note on well-formed but not valid language tags References: <000d01c85ac5$4d7835c0$6501a8c0@DGBP7M81> In-Reply-To: <000d01c85ac5$4d7835c0$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Addison Phillips replied to Debbie > Garside: > >>> Language tags may be well formed in terms of syntax but not valid in >>> terms of content. Users MUST NOT assign and use their own subtags, other >>> than private use codes as designated within the underlying standards, as >>> they may find an as yet unassigned subtag may be officially assigned at >>> a later date with a different meaning. >> >> I agree with the sentiment but think some editing is in order. Notably, >> the private use codes you mention are in the registry, while what I had >> in mind were -x- type private use sequences. Also: I think we have >> similar text elsewhere in the document and would like to look at the >> whole and see what makes the most sense. > > I don't see why the private-use subtags in the Registry wouldn't be at > least as appropriate as the x-type sequences for this and other uses. I didn't say that they weren't. What I said was: those private use codes are in the registry, while Debbie's suggested text suggests otherwise (and makes no mention of -x private use sequences). Both are valid ways of "assigning and using" one's own subtags. Both need to be recommended in their proper place. > They do have the advantage that you can parse them and figure out > syntactically what kind of entity they represent: > Agreed. I think Mark and I (and you) were making that argument a year or two ago :-). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 20 01:13:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGTQw-0001u0-Ep; Sun, 20 Jan 2008 01:13:30 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGTQv-0001px-0u for ltru-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 01:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGTQu-0001pK-Mi for ltru@ietf.org; Sun, 20 Jan 2008 01:13:28 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGTQs-0008UV-CZ for ltru@ietf.org; Sun, 20 Jan 2008 01:13:28 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m0K6DOLW010758 for ; Sun, 20 Jan 2008 15:13:24 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5992_ce88f468_c71e_11dc_8988_0014221f2a2d; Sun, 20 Jan 2008 15:13:24 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36295) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 20 Jan 2008 15:09:11 +0900 Message-Id: <6.0.0.20.2.20080120092654.08453100@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 20 Jan 2008 09:30:54 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Proposed note on well-formed but not valid language tags In-Reply-To: <000d01c85ac5$4d7835c0$6501a8c0@DGBP7M81> References: <000d01c85ac5$4d7835c0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think Addison's comment was purely editorial: Because things such as qaa are in the registry, they are not "their own subtags". They are private use semantically, but they are not just made up because they are in the registry, and this new text is warning about 'just made up' stuff. Semantically, of course you know that qaa is a language and so on, but with x-, there are many more subtags available for distinction, and it may be possible to use words that at least to the tagger actually mean something, which makes handling quite a bit easier. Regards, Martin. At 03:01 08/01/20, Doug Ewell wrote: >Addison Phillips replied to Debbie Garside: > >>> Language tags may be well formed in terms of syntax but not valid in >>> terms of content. Users MUST NOT assign and use their own subtags, other >>> than private use codes as designated within the underlying standards, as >>> they may find an as yet unassigned subtag may be officially assigned at >>> a later date with a different meaning. >> >> I agree with the sentiment but think some editing is in order. Notably, >> the private use codes you mention are in the registry, while what I had >> in mind were -x- type private use sequences. Also: I think we have >> similar text elsewhere in the document and would like to look at the >> whole and see what makes the most sense. > >I don't see why the private-use subtags in the Registry wouldn't be at least as appropriate as the x-type sequences for this and other uses. They do have the advantage that you can parse them and figure out syntactically what kind of entity they represent: > >qaa -- definitely some language >nl-Qaaa -- definitely Dutch written in some script >nl-AA -- definitely Dutch as used in some region >nl-x-ongeacht -- can't tell what kind of entity "ongeacht" is > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://www.ewellic.org >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages $B".(B > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 20 03:28:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGVXF-0000Rj-AH; Sun, 20 Jan 2008 03:28:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JGVXE-0000Rd-4K for ltru-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 03:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGVX7-0000R9-4W for ltru@ietf.org; Sun, 20 Jan 2008 03:28:01 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGVX6-0003sm-Hg for ltru@ietf.org; Sun, 20 Jan 2008 03:28:01 -0500 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.1.240.5; Sun, 20 Jan 2008 00:27:59 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Sun, 20 Jan 2008 00:27:59 -0800 From: Peter Constable To: LTRU Working Group Date: Sun, 20 Jan 2008 00:27:51 -0800 Subject: RE: [Ltru] Update on draft-4645bis Thread-Topic: [Ltru] Update on draft-4645bis Thread-Index: Achayp24j7AT2vsoQRGZYmzWGhu+oAAbQEtQ Message-ID: References: <003301c85851$be6f4e60$6501a8c0@DGBP7M81> <20080116172332.GJ14010@mercury.ccil.org> <001a01c85ac7$cc3eab30$6501a8c0@DGBP7M81> <20080119183919.GC1427@mercury.ccil.org> In-Reply-To: <20080119183919.GC1427@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: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 > Doug Ewell scripsit: > > > Is there any indication that ISO 639-3 (the standard or the RA) > > recognizes the concept of nested macrolanguages? I haven't seen any. > > No, but nor is there any indication that they accept or even understand > the concept, either. At the moment, "Guibei Zhuang" (zgb) et al have macrolanguage mappings to "= Zhuang" (zha). Suppose these were given macrolanguage mappings to "Northern= " (ccx) or "Southern Zhuang" (ccy): since ccx and ccy are now deprecated, t= he relationship that is probably of most interest is that between zgb and z= ha. So, to capture that, one of two things would have to be done: - allow an entry like zgb to have multiple macrolanguage mappings, mapping = to both ccx and zha; or - define some kind of transitive relationship -- for sake of discussion, ca= ll it _derived macrolanguage mapping_ =3D=3D such that if MacrolanguageOf(z= gb) =3D ccx and MacrolanguageOf (ccx) =3D zha than DerivedMacrolanguageOf(z= gb) =3D zha. Since macrolanguage is a normatively-defined relationship in 639-3, then de= rived macrolanguage should also be defined normatively in 639-3. We could a= mend the standard for something like this, though it's not clear to me if i= t would be worth it. Note a couple of things: - if we can have multiple levels of macrolanguage embedding, then it's not = clear to me how the derived macrolanguage mapping should work. E.g., suppor= t a three level embedding involving languages W, X, Y and Z with Macrolangu= ageOf(W) =3D X, MacrolanguageOf(X) =3D Y and MacrolanguageOf(Y) =3D Z, then= what? DerivedMacrolanguageOf(W) =3D Z? DerivedMacrolanguageOf(W) =3D {X, Y, Z}? And if the latter, just how much formal, mathematical machinery do we reall= y want to use in building up ISO 639? - What's the practical application for these additional relationships? If c= cx is deprecated, do we expect people to create new uses that will also mak= e use of a zgb-ccx macrolanguage relationship? It seems like hierarchical macrlanguage mappings would entail a bunch of ne= w work when there's no indication of any application for using it. The main= point of the macrolanguage was to provide a way to deal with exceptional 6= 39-2 cases like zha. By saying that zha is a macrolanguage that encompasses= (now) zgb et al, then the zha is handled equally well as when we said (bef= ore) that zha encompasses ccx and ccy. We did not previously have a dichoto= mous quandary as to how to handle ccx and ccy: they were deemed individual = languages. I suppose now we might say that a dichotomy for ccx has been introduced in = that it has been used as an individual language but now we consider its den= otation range to be multiple individual languages -- which was the issue fo= r entries like zha. I guess the alternative path getting adopted is to say = that ccx is "retired" rather than say its scope has changed from individual= language to macrolanguage. I kind of wished that 639-2 had from the outset defined zha as "Zhuang lang= uages", or that in the course of adopting 639-3 we had changed it to that (= and never defined macrolanguage mappings). With recent research determining= that Zhuang is better analyzed as sixteen different languages rather than = two, it seems like considering zha to be a collection makes more sense. But= , the macrolanguage mappings to zha got defined, hence making it a macrolan= guage, and it seems to me that just getting rid of those macrolanguage mapp= ings could potentially be a problem for some existing implementations. No m= atter how we handle these kinds of things, we're taxonomists of human behav= iour, which is not inherently amenable to taxonomies of sharp-boundary cate= gories, so can never be said to be "perfect". So, I'm content to say that w= hat's being done is "good enough". Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 22 02:15:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDLh-0001qK-3E; Tue, 22 Jan 2008 02:15:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHDLf-0001qA-BC for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 02:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDLe-0001q1-Vq for ltru@ietf.org; Tue, 22 Jan 2008 02:15:06 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHDLc-0001Gi-Dy for ltru@ietf.org; Tue, 22 Jan 2008 02:15:06 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m0M7F1Pg006048 for ; Tue, 22 Jan 2008 16:15:01 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5fa0_befd0efc_c8b9_11dc_85d2_0014221f2a2d; Tue, 22 Jan 2008 16:15:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60417) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 22 Jan 2008 16:10:48 +0900 Message-Id: <6.0.0.20.2.20080122134408.0a152620@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Jan 2008 14:58:10 +0900 To: LTRU Working Group From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] Update of milestones X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The milestones for our WG have been updated as follows: (see http://www.ietf.org/html.charters/ltru-charter.html) Mar 2008 Submit registry procedure update draft for IETF Last Call Mar 2008 Submit registry data update draft for IETF Last Call I very much hope that we can move forward our work swiftly to meet these milestones. 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 Jan 22 02:53:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDwN-0006lB-Lv; Tue, 22 Jan 2008 02:53:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHDwM-0006l4-M5 for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 02:53:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDwE-0006iM-NJ for ltru@ietf.org; Tue, 22 Jan 2008 02:52:54 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHDwE-0000Wi-D1 for ltru@ietf.org; Tue, 22 Jan 2008 02:52:54 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id ADBAE1C0116; Tue, 22 Jan 2008 08:52:53 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A8A581C0115; Tue, 22 Jan 2008 08:52:53 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9B81C58EBEB; Tue, 22 Jan 2008 08:52:53 +0100 (CET) Date: Tue, 22 Jan 2008 08:52:53 +0100 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20080122075253.GA14498@nic.fr> References: <6.0.0.20.2.20080122134408.0a152620@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20080122134408.0a152620@localhost> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: LTRU Working Group Subject: [Ltru] Re: Update of milestones X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jan 22, 2008 at 02:58:10PM +0900, Martin Duerst wrote a message of 21 lines which said: > Mar 2008 Submit registry procedure update draft for IETF Last Call It means the WGLC must take place in the next days, no? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 22 15:00:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPIb-0004eD-JT; Tue, 22 Jan 2008 15:00:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHPIa-0004e8-SH for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 15:00:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPIa-0004dw-GT for ltru@ietf.org; Tue, 22 Jan 2008 15:00:44 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound8-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHPIZ-00086D-KS for ltru@ietf.org; Tue, 22 Jan 2008 15:00:44 -0500 Received: from outbound8-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-dub-R.bigfish.com (Postfix) with ESMTP id 6F8F598020E; Tue, 22 Jan 2008 19:57:26 +0000 (UTC) Received: from mail2-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound8-dub.bigfish.com (Postfix) with ESMTP id 60DCD1720043; Tue, 22 Jan 2008 19:57:26 +0000 (UTC) Received: from mail2-dub (localhost.localdomain [127.0.0.1]) by mail2-dub-R.bigfish.com (Postfix) with ESMTP id 208BD1500433; Tue, 22 Jan 2008 19:57:26 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail2-dub (MessageSwitch) id 1201031845876351_19252; Tue, 22 Jan 2008 19:57:25 +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 mail2-dub.bigfish.com (Postfix) with ESMTP id 4E19898054; Tue, 22 Jan 2008 19:57:24 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2008012211572118-102206 ; Tue, 22 Jan 2008 11:57:21 -0800 In-Reply-To: <479518DC.2090208@yahoo-inc.com> To: Addison Phillips MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 22 Jan 2008 11:54:34 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/22/2008 11:54:35, Serialize complete at 01/22/2008 11:54:35, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/22/2008 11:57:21 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/22/2008 11:57:24 AM, Serialize complete at 01/22/2008 11:57:24 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: LTRU Working Group , 'I18N' , member-i18n-core@w3.org Subject: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0075750236==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0075750236== Content-Type: multipart/alternative; boundary="=_alternative 006D9E8E882573D8_=" This is a multipart message in MIME format. --=_alternative 006D9E8E882573D8_= Content-Type: text/plain; charset="US-ASCII" Addison wrote: > > - Use 'cmn' when you need to indicate "Mandarin Chinese" as distinct > from Chinese in general. This case is rare and should be avoided > whenever possible. A better way to write that would be: "Do NOT use > 'cmn' unless you have a Very Good Reason." I'm a little worried by this text. These tags are intended to identify audio and text content. It is common for those classifying audiovisual content to maintain separate lists of "dubbing" (or audio language) and "subtitle" or (text languages). This strategy is built into many of the standards we use today. I need to distinguish dubbed Taiwanese Mandarin from Mainland Mandarin from Cantonese. With RFC 4646bis as it is currently written, I planned to consider "zh" to be a text or subtitle language, with extensions for script variants, and use "cmn" and "yue" for the audio languages with their own variants. (In subtitle form, I need to distinguish Mandarin, Taiwanese, and Cantonese.) Previous ISO language standards mostly ignored audio forms of Chinese creating a lot of dirty data in my industry because we need these classifications. I hope we're not making this mistake again. The problem with the strategy above is that I will then have two unique tags for the same language audience (dubbed or subtitled mainland Mandarin speakers, for example). I thought this was a good argument for extlang, which has been removed from RFC 4646bis. I don't think that the use of cmn will be "very rare" so I would not like to Addison's advice to avoid "cmn" written into any guidelines. This sounds more and more like there's a narrowing the semantic of the original "zh" tag. We've got a lot of Cantonese and Taiwanese content categorized against the zh tag today and I know this is true of the other massive content stores at other studios. Regards, Karen Broome Sony Pictures Entertainment --=_alternative 006D9E8E882573D8_= Content-Type: text/html; charset="US-ASCII"
Addison wrote:
>
> - Use 'cmn' when you need to indicate "Mandarin Chinese" as distinct
> from Chinese in general. This case is rare and should be avoided
> whenever possible. A better way to write that would be: "Do NOT use
> 'cmn' unless you have a Very Good Reason."

I'm a little worried by this text. These tags are intended to identify audio and text content. It is common for those classifying audiovisual content to maintain separate lists of "dubbing" (or audio language) and "subtitle" or (text languages). This strategy is built into many of the standards we use today.

I need to distinguish dubbed Taiwanese Mandarin from Mainland Mandarin from Cantonese. With RFC 4646bis as it is currently written, I planned to consider "zh" to be a text or subtitle language, with extensions for script variants, and use "cmn" and "yue" for the audio languages with their own variants. (In subtitle form, I need to distinguish Mandarin, Taiwanese, and Cantonese.) Previous ISO language standards mostly ignored audio forms of Chinese creating a lot of dirty data in my industry because we need these classifications. I hope we're not making this mistake again.

The problem with the strategy above is that I will then have two unique tags for the same language audience (dubbed or subtitled mainland Mandarin speakers, for example). I thought this was a good argument for extlang, which has been removed from RFC 4646bis.

I don't think that the use of cmn will be "very rare" so I would not like to Addison's advice to avoid "cmn" written into any guidelines.

This sounds more and more like there's a narrowing the semantic of the original "zh" tag. We've got a lot of Cantonese and Taiwanese content categorized against the zh tag today and I know this is true of the other massive content stores at other studios.

Regards,

Karen Broome
Sony Pictures Entertainment --=_alternative 006D9E8E882573D8_=-- --===============0075750236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0075750236==-- From ltru-bounces@ietf.org Tue Jan 22 15:53:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQ7E-00061D-0z; Tue, 22 Jan 2008 15:53:04 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHQ7C-0005xG-Ef for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 15:53:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQ7C-0005x3-48 for ltru@ietf.org; Tue, 22 Jan 2008 15:53:02 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHQ7B-0001Hk-Q9 for ltru@ietf.org; Tue, 22 Jan 2008 15:53:02 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JHQ7A-0005g6-BA; Tue, 22 Jan 2008 15:53:00 -0500 Date: Tue, 22 Jan 2008 15:53:00 -0500 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax Message-ID: <20080122205300.GH11346@mercury.ccil.org> References: <479518DC.2090208@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'I18N' , LTRU Working Group , member-i18n-core@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > I need to distinguish dubbed Taiwanese Mandarin from Mainland Mandarin > from Cantonese. With RFC 4646bis as it is currently written, I planned to > consider "zh" to be a text or subtitle language, with extensions for > script variants, and use "cmn" and "yue" for the audio languages with > their own variants. (In subtitle form, I need to distinguish Mandarin, > Taiwanese, and Cantonese.) That's the most sensible approach for audio. The warnings are basically about situations where there is a lot of pre-existing tagged content, which doesn't much apply to audio. > This sounds more and more like there's a narrowing the semantic of the > original "zh" tag. We've got a lot of Cantonese and Taiwanese content > categorized against the zh tag today and I know this is true of the other > massive content stores at other studios. No, it's just warning you that de facto it's been narrowed already, particularly in the text domain, since most written Chinese is in fact Mandarin. (And the same for Standard Arabic, and Swahili, and a bunch of other cases.) -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 22 20:23:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHUKh-0004zY-C7; Tue, 22 Jan 2008 20:23:15 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHUKg-0004zO-5i for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 20:23:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHUKf-0004zG-S3 for ltru@ietf.org; Tue, 22 Jan 2008 20:23:13 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound5-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHUKd-0005as-VE for ltru@ietf.org; Tue, 22 Jan 2008 20:23:13 -0500 Received: from outbound5-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-dub-R.bigfish.com (Postfix) with ESMTP id ED313134238C; Wed, 23 Jan 2008 01:23:10 +0000 (UTC) Received: from mail101-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound5-dub.bigfish.com (Postfix) with ESMTP id D5CCB1F0052; Wed, 23 Jan 2008 01:23:10 +0000 (UTC) Received: from mail101-dub (localhost.localdomain [127.0.0.1]) by mail101-dub-R.bigfish.com (Postfix) with ESMTP id 35178143045D; Wed, 23 Jan 2008 01:23:09 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail101-dub (MessageSwitch) id 1201051388198360_30990; Wed, 23 Jan 2008 01:23:08 +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 mail101-dub.bigfish.com (Postfix) with ESMTP id AD2674D0089; Wed, 23 Jan 2008 01:23:05 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2008012217230170-16638 ; Tue, 22 Jan 2008 17:23:01 -0800 In-Reply-To: <20080122205300.GH11346@mercury.ccil.org> To: John Cowan Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 22 Jan 2008 17:20:15 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/22/2008 17:20:16, Serialize complete at 01/22/2008 17:20:16, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/22/2008 05:23:01 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/22/2008 05:23:05 PM, Serialize complete at 01/22/2008 05:23:05 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'I18N' , LTRU Working Group , member-i18n-core@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0689672951==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0689672951== Content-Type: multipart/alternative; boundary="=_alternative 000799D0882573D9_=" This is a multipart message in MIME format. --=_alternative 000799D0882573D9_= Content-Type: text/plain; charset="US-ASCII" John Cowan wrote: > That's the most sensible approach for audio. The warnings are basically > about situations where there is a lot of pre-existing tagged content, > which doesn't much apply to audio. We have A LOT of historical audio tagged as zh and zho. Audio content wasn't invented yesterday or even the day before, so I think I disagree with your premise here. I'm concerned that if these warnings are too strongly worded, you might scare off those with a legitimate use for the tag. As I have pointed out before, web video content is increasing and clear guidelines should be in place. > > > This sounds more and more like there's a narrowing the semantic of the > > original "zh" tag. We've got a lot of Cantonese and Taiwanese content > > categorized against the zh tag today and I know this is true of the other > > massive content stores at other studios. > > No, it's just warning you that de facto it's been narrowed already, > particularly in the text domain, since most written Chinese is in > fact Mandarin. (And the same for Standard Arabic, and Swahili, > and a bunch of other cases.) I think this is an assumption that should be called into question. There are many audio archives, studios, web sites, and other audiovisual content producers with systems that now use either ISO 639-1 or ISO 639-2 to categorize "Chinese" audio content. There are fewer content collections categorized against RFC 3066 or later. I believe this could cause a lot of confusion amongst the owners of those collections as they sort out what they have on the more granular levels now allowed by RFC 4646 and 4646bis. I think the idea that "zh" is a synonym for Mandarin is rooted in the text mentality and the de facto narrowing you see there does not hold true for audio uses. Most archival standards today use "zho" or "chi" and there are a lot of audio and moving image archives out there. An increasing number of these moving image collections are being digitized for online formats. If zh=mandarin in both spoken and written contexts, any Cantonese or Taiwanese content in these collections today will be irretrievable until the collection owners can afford to hire language experts to separate the Cantonese apples from the Mandarin oranges. Regards, Karen Broome --=_alternative 000799D0882573D9_= Content-Type: text/html; charset="US-ASCII"
John Cowan wrote:


> That's the most sensible approach for audio.  The warnings are basically
> about situations where there is a lot of pre-existing tagged content,
> which doesn't much apply to audio.

We have A LOT of historical audio tagged as zh and zho. Audio content wasn't invented yesterday or even the day before, so I think I disagree with your premise here. I'm concerned that if these warnings are too strongly worded, you might scare off those with a legitimate use for the tag. As I have pointed out before, web video content is increasing and clear guidelines should be in place.

>
> > This sounds more and more like there's a narrowing the semantic of the
> > original "zh" tag. We've got a lot of Cantonese and Taiwanese content
> > categorized against the zh tag today and I know this is true of the other
> > massive content stores at other studios.
>
> No, it's just warning you that de facto it's been narrowed already,
> particularly in the text domain, since most written Chinese is in
> fact Mandarin.  (And the same for Standard Arabic, and Swahili,
> and a bunch of other cases.)
I think this is an assumption that should be called into question. There are many audio archives, studios, web sites, and other audiovisual content producers with systems that now use either ISO 639-1 or ISO 639-2 to categorize "Chinese" audio content. There are fewer content collections categorized against RFC 3066 or later. I believe this could cause a lot of confusion amongst the owners of those collections as they sort out what they have on the more granular levels now allowed by RFC 4646 and 4646bis.

I think the idea that "zh" is a synonym for Mandarin is rooted in the text mentality and the de facto narrowing you see there does not hold true for audio uses. Most archival standards today use "zho" or "chi" and there are a lot of audio and moving image archives out there. An increasing number of these moving image collections are being digitized for online formats. If zh=mandarin in both spoken and written contexts, any Cantonese or Taiwanese content in these collections today will be irretrievable until the collection owners can afford to hire language experts to separate the Cantonese apples from the Mandarin oranges.

Regards,

Karen Broome --=_alternative 000799D0882573D9_=-- --===============0689672951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0689672951==-- From ltru-bounces@ietf.org Tue Jan 22 23:47:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXWf-0002FQ-Gx; Tue, 22 Jan 2008 23:47:49 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHXWe-0002FJ-Jy for ltru-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 23:47:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXWe-0002FB-AB for ltru@ietf.org; Tue, 22 Jan 2008 23:47:48 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHXWe-0001nU-0T for ltru@ietf.org; Tue, 22 Jan 2008 23:47:48 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JHXWZ-0002xk-2A; Tue, 22 Jan 2008 23:47:43 -0500 Date: Tue, 22 Jan 2008 23:47:43 -0500 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax Message-ID: <20080123044742.GC12051@mercury.ccil.org> References: <20080122205300.GH11346@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'I18N' , LTRU Working Group , member-i18n-core@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > > That's the most sensible approach for audio. The warnings are basically > > about situations where there is a lot of pre-existing tagged content, > > which doesn't much apply to audio. > > We have A LOT of historical audio tagged as zh and zho. Audio content > wasn't invented yesterday or even the day before, so I think I disagree > with your premise here. Sure. But it could be any Chinese language; there's no presumption of Mandarin in the audio domain. > > No, it's just warning you that de facto it's been narrowed already, > > particularly in the text domain, since most written Chinese is in > > fact Mandarin. (And the same for Standard Arabic, and Swahili, > > and a bunch of other cases.) > > I think the idea that "zh" is a synonym for Mandarin is rooted in the text > mentality and the de facto narrowing you see there does not hold true for > audio uses. We are in violent agreement. -- De plichten van een docent zijn divers, John Cowan die van het gehoor ook. cowan@ccil.org --Edsger Dijkstra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 23 01:00:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYfG-0005MO-N4; Wed, 23 Jan 2008 01:00:46 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHYfF-0005MI-AM for ltru-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:00:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYfF-0005M5-0N for ltru@ietf.org; Wed, 23 Jan 2008 01:00:45 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHYfC-0003Ky-KU for ltru@ietf.org; Wed, 23 Jan 2008 01:00:44 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m0N60dq0004241 for ; Wed, 23 Jan 2008 15:00:39 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 45ea_85c57042_c978_11dc_9fee_0014221fa3c9; Wed, 23 Jan 2008 15:00:39 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36379) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 23 Jan 2008 14:55:44 +0900 Message-Id: <6.0.0.20.2.20080123145114.0a2dfc50@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 23 Jan 2008 14:52:06 +0900 To: Karen_Broome@spe.sony.com, John Cowan From: Martin Duerst Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax In-Reply-To: References: <20080122205300.GH11346@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: LTRU Working Group , 'I18N' , member-i18n-core@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen - Can you propose some text changes that would remove your concerns for this text? Regards, Martin. At 10:20 08/01/23, Karen_Broome@spe.sony.com wrote: >John Cowan wrote: > > >> That's the most sensible approach for audio. The warnings are basically >> about situations where there is a lot of pre-existing tagged content, >> which doesn't much apply to audio. > >We have A LOT of historical audio tagged as zh and zho. Audio content wasn't invented yesterday or even the day before, so I think I disagree with your premise here. I'm concerned that if these warnings are too strongly worded, you might scare off those with a legitimate use for the tag. As I have pointed out before, web video content is increasing and clear guidelines should be in place. > >> >> > This sounds more and more like there's a narrowing the semantic of the >> > original "zh" tag. We've got a lot of Cantonese and Taiwanese content >> > categorized against the zh tag today and I know this is true of the other >> > massive content stores at other studios. >> >> No, it's just warning you that de facto it's been narrowed already, >> particularly in the text domain, since most written Chinese is in >> fact Mandarin. (And the same for Standard Arabic, and Swahili, >> and a bunch of other cases.) > >I think this is an assumption that should be called into question. There are many audio archives, studios, web sites, and other audiovisual content producers with systems that now use either ISO 639-1 or ISO 639-2 to categorize "Chinese" audio content. There are fewer content collections categorized against RFC 3066 or later. I believe this could cause a lot of confusion amongst the owners of those collections as they sort out what they have on the more granular levels now allowed by RFC 4646 and 4646bis. > >I think the idea that "zh" is a synonym for Mandarin is rooted in the text mentality and the de facto narrowing you see there does not hold true for audio uses. Most archival standards today use "zho" or "chi" and there are a lot of audio and moving image archives out there. An increasing number of these moving image collections are being digitized for online formats. If zh=mandarin in both spoken and written contexts, any Cantonese or Taiwanese content in these collections today will be irretrievable until the collection owners can afford to hire language experts to separate the Cantonese apples from the Mandarin oranges. > >Regards, > >Karen Broome >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 23 01:10:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYoT-0007Aq-Lr; Wed, 23 Jan 2008 01:10:17 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHYoR-00075q-Dg for ltru-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYoQ-00073P-Jt for ltru@ietf.org; Wed, 23 Jan 2008 01:10:14 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHYoO-0003U7-4D for ltru@ietf.org; Wed, 23 Jan 2008 01:10:14 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JHYoJ-0007qJ-3D; Wed, 23 Jan 2008 01:10:07 -0500 Date: Wed, 23 Jan 2008 01:10:07 -0500 To: Martin Duerst Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax Message-ID: <20080123061006.GE12051@mercury.ccil.org> References: <20080122205300.GH11346@mercury.ccil.org> <6.0.0.20.2.20080123145114.0a2dfc50@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20080123145114.0a2dfc50@localhost> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group , Karen_Broome@spe.sony.com, 'I18N' , member-i18n-core@w3.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Karen - Can you propose some text changes that would remove your > concerns for this text? Please note that I have already provided text that generalizes the warning from Chinese to several additional languages, but Addison has not yet incorporated this. -- You escaped them by the will-death John Cowan and the Way of the Black Wheel. cowan@ccil.org I could not. --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 23 12:30:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHjQz-0007JN-B9; Wed, 23 Jan 2008 12:30:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHjQy-0007JI-Bz for ltru-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 12:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHjQy-0007JA-2D for ltru@ietf.org; Wed, 23 Jan 2008 12:30:44 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound6-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHjQx-0007HR-83 for ltru@ietf.org; Wed, 23 Jan 2008 12:30:44 -0500 Received: from outbound6-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-dub-R.bigfish.com (Postfix) with ESMTP id 186D1469600; Wed, 23 Jan 2008 17:30:42 +0000 (UTC) Received: from mail153-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound6-dub.bigfish.com (Postfix) with ESMTP id 033A1D58043; Wed, 23 Jan 2008 17:30:42 +0000 (UTC) Received: from mail153-dub (localhost.localdomain [127.0.0.1]) by mail153-dub-R.bigfish.com (Postfix) with ESMTP id 8055D440227; Wed, 23 Jan 2008 17:30:40 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail153-dub (MessageSwitch) id 1201109439171625_32694; Wed, 23 Jan 2008 17:30:39 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail153-dub.bigfish.com (Postfix) with ESMTP id A81FDE88088; Wed, 23 Jan 2008 17:30:37 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2008012309303385-4515 ; Wed, 23 Jan 2008 09:30:33 -0800 In-Reply-To: <20080123061006.GE12051@mercury.ccil.org> To: John Cowan Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 23 Jan 2008 09:27:47 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/23/2008 09:27:48, Serialize complete at 01/23/2008 09:27:48, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/23/2008 09:30:33 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/23/2008 09:30:37 AM, Serialize complete at 01/23/2008 09:30:37 AM X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620277154==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1620277154== Content-Type: multipart/alternative; boundary="=_alternative 00602E61882573D9_=" This is a multipart message in MIME format. --=_alternative 00602E61882573D9_= Content-Type: text/plain; charset="US-ASCII" John, If you send me your text, I'll take a look. I'm a bit buried in other duties right now and haven't read the latest drafts. I could probably take a look this weekend. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 www-international-request@w3.org wrote on 01/22/2008 10:10:07 PM: > > Martin Duerst scripsit: > > > Karen - Can you propose some text changes that would remove your > > concerns for this text? > > Please note that I have already provided text that generalizes the > warning from Chinese to several additional languages, but Addison has > not yet incorporated this. > > -- > You escaped them by the will-death John Cowan > and the Way of the Black Wheel. cowan@ccil.org > I could not. --Great-Souled Sam http://www.ccil.org/~cowan > > --=_alternative 00602E61882573D9_= Content-Type: text/html; charset="US-ASCII"
John,

If you send me your text, I'll take a look. I'm a bit buried in other duties right now and haven't read the latest drafts. I could probably take a look this weekend.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

www-international-request@w3.org wrote on 01/22/2008 10:10:07 PM:

>
> Martin Duerst scripsit:
>
> > Karen - Can you propose some text changes that would remove your
> > concerns for this text?
>
> Please note that I have already provided text that generalizes the
> warning from Chinese to several additional languages, but Addison has
> not yet incorporated this.
>
> --
> You escaped them by the will-death              John Cowan
> and the Way of the Black Wheel.                 cowan@ccil.org
> I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan
>
>
--=_alternative 00602E61882573D9_=-- --===============1620277154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1620277154==-- From ltru-bounces@ietf.org Wed Jan 23 14:25:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlDg-0002ST-7Q; Wed, 23 Jan 2008 14:25:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JHlDf-0002SM-28 for ltru-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 14:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlDe-0002SE-OZ for ltru@ietf.org; Wed, 23 Jan 2008 14:25:06 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHlDe-0002GF-Cy for ltru@ietf.org; Wed, 23 Jan 2008 14:25:06 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JHlDW-0007rA-Sp; Wed, 23 Jan 2008 14:24:58 -0500 Date: Wed, 23 Jan 2008 14:24:58 -0500 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Re: Upcoming changes to BCP47 (language tag) syntax Message-ID: <20080123192458.GL11346@mercury.ccil.org> References: <20080123061006.GE12051@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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > If you send me your text, I'll take a look. I'm a bit buried in other > duties right now and haven't read the latest drafts. I could probably take > a look this weekend. See http://www1.ietf.org/mail-archive/web/ltru/current/msg09238.html -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --"The Passage of the Marshes" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 25 12:33:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISQI-0006wz-3L; Fri, 25 Jan 2008 12:33:02 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JISQG-0006wT-6D for ltru-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 12:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISQF-0006wH-OH for ltru@lists.ietf.org; Fri, 25 Jan 2008 12:32:59 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JISQE-0004Z6-4v for ltru@lists.ietf.org; Fri, 25 Jan 2008 12:32:59 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JISQ8-0003cM-Qr for ltru@lists.ietf.org; Fri, 25 Jan 2008 17:32:52 +0000 Received: from c-134-88-207.hh.dial.de.ignite.net ([62.134.88.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 17:32:52 +0000 Received: from nobody by c-134-88-207.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 17:32:52 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Fri, 25 Jan 2008 18:33:07 +0100 Organization: Lines: 12 Message-ID: References: <033401c85e6d$f14953e0$4153f853@streamserve.com><20080124163323.GB21221@mercury.ccil.org><002a01c85ec8$69f2a940$1754f853@streamserve.com><20080124205655.GP11346@mercury.ccil.org><004901c85ed8$a66912f0$1754f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-207.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote on the language subtag review list: > To veto 639-3 because of issues in 0.04% of the code table > that had no bearing on the text of the standard and could > have been corrected at any time would have been folly. As soon as a 4646bis registry imported 639-3 wholesale later corrections of the 4646bis registry are intentionally limited, there's no way to "unregister" subtags after they're in. Can that happen in 639-3 ? Frank (jumping from "languages" to LTRU, it affects 4646bis) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 25 12:52:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISih-0004lC-R3; Fri, 25 Jan 2008 12:52:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JISig-0004f7-7G for ltru-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 12:52:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISif-0004dE-Sl for ltru@lists.ietf.org; Fri, 25 Jan 2008 12:52:01 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JISif-0005h3-F8 for ltru@lists.ietf.org; Fri, 25 Jan 2008 12:52:01 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JISif-0002IJ-6c; Fri, 25 Jan 2008 12:52:01 -0500 Date: Fri, 25 Jan 2008 12:52:01 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Principles of Operation Message-ID: <20080125175201.GA7239@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: 08170828343bcf1325e4a0fb4584481c 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: > As soon as a 4646bis registry imported 639-3 wholesale later > corrections of the 4646bis registry are intentionally limited, > there's no way to "unregister" subtags after they're in. Can > that happen in 639-3 ? 639-3 code elements can be, and have been, retired for any of a variety of reasons. (However, they will not be reused.) -- John Cowan cowan@ccil.org http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 25 13:24:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JITED-0008JQ-Ig; Fri, 25 Jan 2008 13:24:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JITEC-0008JL-U0 for ltru-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 13:24:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JITEC-0008JC-KO for ltru@lists.ietf.org; Fri, 25 Jan 2008 13:24:36 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JITEB-0006Qu-BQ for ltru@lists.ietf.org; Fri, 25 Jan 2008 13:24:36 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 25 Jan 2008 10:24:35 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Fri, 25 Jan 2008 10:24:29 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Fri, 25 Jan 2008 10:24:28 -0800 Subject: RE: [Ltru] Re: Principles of Operation Thread-Topic: [Ltru] Re: Principles of Operation Thread-Index: AchfewJMmYGYd1GGTheX8WTc+CttsAAA+a2w Message-ID: References: <20080125175201.GA7239@mercury.ccil.org> In-Reply-To: <20080125175201.GA7239@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan > Frank Ellermann scripsit: > > > As soon as a 4646bis registry imported 639-3 wholesale later > > corrections of the 4646bis registry are intentionally limited, > > there's no way to "unregister" subtags after they're in. Can > > that happen in 639-3 ? > > 639-3 code elements can be, and have been, retired for any of a variety > of reasons. (However, they will not be reused.) Right. If something like Scanian were coded once, it would always remain co= ded; but in the process of maintaining 639-3 such a code could be deprecate= d on the basis (say) that it is determined to be best considered a dialect = of another language rather than a separate individual language. Given the c= omprehensive scope of 639-3, such changes *are* going to happen because by = definition its scope extends to the limits of knowledge and understanding o= f the world's languages. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 25 14:37:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIUN2-0004p2-7a; Fri, 25 Jan 2008 14:37:48 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JIUN0-0004ot-Ks for ltru-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 14:37:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIUN0-0004ol-B9 for ltru@lists.ietf.org; Fri, 25 Jan 2008 14:37:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIUMy-0000tb-Ir for ltru@lists.ietf.org; Fri, 25 Jan 2008 14:37:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JIUMw-0001z3-Mz for ltru@lists.ietf.org; Fri, 25 Jan 2008 19:37:42 +0000 Received: from c-134-88-207.hh.dial.de.ignite.net ([62.134.88.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 19:37:42 +0000 Received: from nobody by c-134-88-207.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 19:37:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Fri, 25 Jan 2008 20:37:59 +0100 Organization: Lines: 37 Message-ID: References: <20080125175201.GA7239@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-207.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >> 639-3 code elements can be, and have been, retired for any of a >> variety of reasons. (However, they will not be reused.) > Right. If something like Scanian were coded once, it would always > remain coded; but in the process of maintaining 639-3 such a code > could be deprecated on the basis (say) that it is determined to be > best considered a dialect of another language rather than a separate > individual language. Given the comprehensive scope of 639-3, such > changes *are* going to happen because by definition its scope > extends to the limits of knowledge and understanding of the world's > languages. Okay, "deprecate" is good enough. But it could get tricky if it=20 gets a Preferred-Value that is actually a variant. Collisions of variants with registered languages could cause havoc, example: Language: foobar=20 [...] Language: err [...] Variant: foobar Prefix: fr-CA Prefix: fr-PM [...] Language "err" deprecated because it was found to be some dialect, as it happens the dialect registered as "foobar", unrelated to the language "foobar". =20 AFAIK we can't have preferred values fr-CA-foobar AND fr-PM-foobar, (please assume that this is important, it's only an example), and what we really want is Preferred-Value: foobar as a pointer to the variant, not the language. Are we stuck in this case ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 26 14:23:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIqcE-0007Dp-A6; Sat, 26 Jan 2008 14:22:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JIqcD-0007AP-M8 for ltru-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 14:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIqcD-00078h-BV for ltru@ietf.org; Sat, 26 Jan 2008 14:22:57 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIqcC-0005SA-R1 for ltru@ietf.org; Sat, 26 Jan 2008 14:22:57 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080126192256.XHCM14013.mta9.adelphia.net@DGBP7M81> for ; Sat, 26 Jan 2008 14:22:56 -0500 Message-ID: <019f01c86050$db8b0370$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 26 Jan 2008 11:22:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Okay, "deprecate" is good enough. But it could get tricky if it gets > a Preferred-Value that is actually a variant. Collisions of variants > with registered languages could cause havoc, example: > > Language: foobar > [...] > Language: err > [...] > Variant: foobar > Prefix: fr-CA > Prefix: fr-PM > [...] > > Language "err" deprecated because it was found to be some dialect, as > it happens the dialect registered as "foobar", unrelated to the > language "foobar". > > AFAIK we can't have preferred values fr-CA-foobar AND fr-PM-foobar, > (please assume that this is important, it's only an example), and what > we really want is Preferred-Value: foobar as a pointer to the variant, > not the language. Are we stuck in this case ? A Preferred-Value is a whole tag, not a subtag, so no, it is not possible for a variant subtag alone to serve as a P-V. Frank is correct that a subtag can't have two or more P-Vs. I would be surprised if this absolutely could not be generalized to "fr-foobar". Scouse is rather specifically a variant of en-GB, and Boontling is rather specifically a variant of en-US, but both of those variants have simply "en" as their P-V. More detail would be possible, but not necessary. Registered language subtags are one of the two items this group and ietf-languages seem rather strongly opposed to (the other being extensions), to the point where none might ever be created. If that is true, this scenario will not occur anyway. I think the real underlying question here is, "Will ietf-languages be careful to avoid painting themselves into corners like this?" and all I can say is, we will do our best. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 27 07:15:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ6PX-00015s-5B; Sun, 27 Jan 2008 07:14:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJ6PW-00014d-An for ltru-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 07:14:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ6PW-00013i-0F for ltru@lists.ietf.org; Sun, 27 Jan 2008 07:14:54 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ6PU-0000oD-5r for ltru@lists.ietf.org; Sun, 27 Jan 2008 07:14:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JJ6PR-0000lW-VV for ltru@lists.ietf.org; Sun, 27 Jan 2008 12:14:49 +0000 Received: from c-180-160-79.hh.dial.de.ignite.net ([62.180.160.79]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 12:14:49 +0000 Received: from nobody by c-180-160-79.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 12:14:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Sun, 27 Jan 2008 13:15:03 +0100 Organization: Lines: 25 Message-ID: References: <019f01c86050$db8b0370$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-79.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > A Preferred-Value is a whole tag, not a subtag, so no, it is > not possible for a variant subtag alone to serve as a P-V. Check the registry, there are quite a lot of Preferred-Values which are only subtags, starting with BU -> MM and DD -> DE. For languages "tag" and "subtag" are syntactically equivalent. There are only two Preferred-Values zh-hakka and zh-cmn which are clearly tags. | Preferred-Value | * For fields of type 'language', 'extlang', 'script', 'region', | and 'variant', 'Preferred-Value' contains the subtag of the | same 'Type' that is preferred for forming the language tag. | * For fields of type 'grandfathered' and 'redundant', a canonical | mapping to a complete language tag. At the moment we could not deprecate language "err" in favour=20 of a variant subtag "foobar" or a tag "fr-foobar". And that can happen for ``language=C2=B4=C2=B4 Europanto "eur" found by Michael: http://www.ethnologue.com/show_language.asp?code=3Deur Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 27 15:04:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDjg-0008FN-Tx; Sun, 27 Jan 2008 15:04:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJDjg-00088V-1n for ltru-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:04:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDjf-00082c-JG for ltru@ietf.org; Sun, 27 Jan 2008 15:04:11 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJDjf-0004BI-8H for ltru@ietf.org; Sun, 27 Jan 2008 15:04:11 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080127200410.ENMF5487.mta11.adelphia.net@DGBP7M81> for ; Sun, 27 Jan 2008 15:04:10 -0500 Message-ID: <01fb01c8611f$c926e8f0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 27 Jan 2008 12:04:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> A Preferred-Value is a whole tag, not a subtag, so no, it is not >> possible for a variant subtag alone to serve as a P-V. > > Check the registry, there are quite a lot of Preferred-Values which > are only subtags, starting with BU -> MM and DD -> DE. You are correct. I got confused switching back and forth between Prefix and Preferred-Value. My apologies. > At the moment we could not deprecate language "err" in favour of a > variant subtag "foobar" or a tag "fr-foobar". And that can happen for > ``language´´ Europanto "eur" found by Michael: > http://www.ethnologue.com/show_language.asp?code=eur While I'm not sure how this relates to Europanto, can you propose some text that would address your concerns about deprecating a language in favor of a language-variant combination? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 27 15:28:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE6n-00054E-RB; Sun, 27 Jan 2008 15:28:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJE6m-0004wS-GL for ltru-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE6m-0004wK-6h for ltru@lists.ietf.org; Sun, 27 Jan 2008 15:28:04 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJE6k-0004vy-Jd for ltru@lists.ietf.org; Sun, 27 Jan 2008 15:28:04 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JJE6f-000856-QQ for ltru@lists.ietf.org; Sun, 27 Jan 2008 20:27:57 +0000 Received: from c-180-160-129.hh.dial.de.ignite.net ([62.180.160.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 20:27:57 +0000 Received: from nobody by c-180-160-129.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 20:27:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Sun, 27 Jan 2008 21:28:11 +0100 Organization: Lines: 18 Message-ID: References: <01fb01c8611f$c926e8f0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-129.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: Principles of Operation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > can you propose some text that would address your concerns about > deprecating a language in favor of a language-variant combination? I fear it would need too many preconditions: limiting variants strictly to languages (or other variants), i.e. no variants for regions or scripts. After that we'd need to make sure that a variant subtag can never be the same string as a registered language (unless they refer to the same entity, one deprecated in favour of the other). Finally we could allow pointers to a variant (in the form of a Preferred-Value) from deprecated languages. It's more straight forward if we give the 639-3 folks some years to get a grip on "eur", "ork", and "sxu", and revisit 4646 later. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 28 00:19:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJMP4-0004Cf-Tc; Mon, 28 Jan 2008 00:19:30 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJMP4-0004Ca-HY for ltru-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 00:19:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJMP4-0004CR-7I for ltru@ietf.org; Mon, 28 Jan 2008 00:19:30 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJMP3-0008Lb-QJ for ltru@ietf.org; Mon, 28 Jan 2008 00:19:30 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080128051928.NXJJ3079.mta10.adelphia.net@DGBP7M81> for ; Mon, 28 Jan 2008 00:19:28 -0500 Message-ID: <001801c8616d$5b5a4030$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 27 Jan 2008 21:19:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Draft-4645bis, as you like it X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've created a new RFC 4645bis download page, in hopes of getting more people to review draft-ietf-ltru-4645bis in their own way, before it goes up for WG and IETF Last Calls. http://www.ewellic.org/rfc4645bis.html Here you can find both the current version (-03) and editor's copy (-04) of draft-ietf-ltru-4645bis, in text or HTML format, with or without the voluminous replacement Registry contents. You can also download the proposed Registry contents alone, with over 7,000 new subtags, in UTF-8. Some people have specifically asked for Registry-only, or Registry-free, versions of this draft. I hope providing them will encourage more people to review parts of the draft they are interested in. The main difference between -03 and -04 is updates to the references to draft-4646bis-11 and to the latest ISO 639-3 data files. Of course, the data files reflect hundreds of changes approved by ISO 639-3/RA, and consequently the Registry contents are quite different. There is one additional, very minor change: I changed the word "uninverted" in Section 2.1 to "non-inverted" to avoid giving the false impression that the 639-3 reference name ever appears in inverted form and must then be "uninverted." -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 28 17:37:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJcb3-0000G2-J5; Mon, 28 Jan 2008 17:36:57 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJcb1-0000Fx-TK for ltru-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 17:36:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJcb1-0000Fp-Ig for ltru@ietf.org; Mon, 28 Jan 2008 17:36:55 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJcb1-0006O8-AN for ltru@ietf.org; Mon, 28 Jan 2008 17:36:55 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JJcb0-0008Hx-LS; Mon, 28 Jan 2008 17:36:54 -0500 Date: Mon, 28 Jan 2008 17:36:54 -0500 To: Doug Ewell Subject: Re: [Ltru] Draft-4645bis, as you like it Message-ID: <20080128223654.GX11346@mercury.ccil.org> References: <001801c8616d$5b5a4030$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c8616d$5b5a4030$6501a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: > Here you can find both the current version (-03) and editor's copy (-04) > of draft-ietf-ltru-4645bis, in text or HTML format, with or without the > voluminous replacement Registry contents. You can also download the > proposed Registry contents alone, with over 7,000 new subtags, in UTF-8. I reviewed -03 sans Registry, and I'm happy. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 29 06:47:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJovS-0007T7-0G; Tue, 29 Jan 2008 06:46:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJovQ-0007L6-Ju for ltru-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 06:46:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJovQ-0007Jl-9W for ltru@ietf.org; Tue, 29 Jan 2008 06:46:48 -0500 Received: from mail19.svc.cra.dublin.eircom.net ([159.134.118.218]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJovP-0005Ca-QC for ltru@ietf.org; Tue, 29 Jan 2008 06:46:48 -0500 Received: (qmail 94112 messnum 7203975 invoked from network[194.125.174.105/ts09-105.dublin.indigo.ie]); 29 Jan 2008 11:46:46 -0000 Received: from ts09-105.dublin.indigo.ie (HELO ?194.125.174.105?) (194.125.174.105) by mail19.svc.cra.dublin.eircom.net (qp 94112) with SMTP; 29 Jan 2008 11:46:46 -0000 In-Reply-To: <20080129110003.D3EDF25976A@eikenes.alvestrand.no> References: <20080129110003.D3EDF25976A@eikenes.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Tue, 29 Jan 2008 11:47:39 +0000 To: ietf-languages@alvestrand.no, LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Shelta X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Arising out of a meeting in our university last night, I need to know =20= (a) what language tag was assigned to Shelta; (b) whether its main =20 variants have been subtagged; (c) whether there is any further =20 plannned ietf/ltru work which might affect the above in the near future. With no time today to conduct the usual web searches on this, I'd be =20 grateful if members of ietf/ltru could help. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 29 08:16:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqJL-00015G-A0; Tue, 29 Jan 2008 08:15:35 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JJqJK-00014F-4o for ltru-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 08:15:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqJJ-000146-Qo for ltru@ietf.org; Tue, 29 Jan 2008 08:15:33 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJqJJ-0001Uw-He for ltru@ietf.org; Tue, 29 Jan 2008 08:15:33 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JJqJH-00033k-Ab; Tue, 29 Jan 2008 08:15:31 -0500 Date: Tue, 29 Jan 2008 08:15:31 -0500 To: Marion Gunn Message-ID: <20080129131530.GI10550@mercury.ccil.org> References: <20080129110003.D3EDF25976A@eikenes.alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: Shelta X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn scripsit: > Arising out of a meeting in our university last night, I need to know > (a) what language tag was assigned to Shelta; (b) whether its main > variants have been subtagged; (c) whether there is any further > plannned ietf/ltru work which might affect the above in the near future. The 639-3 code element is 'sth'. Like all other code elements unique to 639-3, that is not yet a valid BCP 47 language tag, though it will become so in the near future if we ever get RFC 4646bis finished and out the door. Consequently, no variant subtags have been assigned, nor will they be unless someone requests them in due form after RFC 4646bis becomes effective. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Objective consideration of contemporary phenomena compel the conclusion that optimum or inadequate performance in the trend of competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account. --Ecclesiastes 9:11, Orwell/Brown version _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 12:47:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKH1p-0007jC-67; Wed, 30 Jan 2008 12:47:17 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKH1n-0007iP-9q for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 12:47:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKH1m-0007iH-VJ for ltru@ietf.org; Wed, 30 Jan 2008 12:47:14 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKH1m-0001Ce-Na for ltru@ietf.org; Wed, 30 Jan 2008 12:47:14 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JKH1l-0003b7-Fz; Wed, 30 Jan 2008 12:47:13 -0500 Date: Wed, 30 Jan 2008 12:47:13 -0500 To: ietf-languages@iana.org, ltru@ietf.org Message-ID: <20080130174713.GG7602@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Using the "eur" tag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Somewhat in advance of RFC 4646bis, I have tagged my post at http://recycledknowledge.blogspot.com/2005/05/eigensprach.html as Europanto using the "eur" tag. As I said: the language is a joke, the code element is not. -- We do, doodley do, doodley do, doodley do, John Cowan What we must, muddily must, muddily must, muddily must; Muddily do, muddily do, muddily do, muddily do, http://www.ccil.org/~cowan Until we bust, bodily bust, bodily bust, bodily bust. --Bokonon _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 13:30:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHhQ-000587-ML; Wed, 30 Jan 2008 13:30:16 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKHhP-000581-SF for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:30:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHhP-00057t-IL for ltru@ietf.org; Wed, 30 Jan 2008 13:30:15 -0500 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHhN-00069G-BR for ltru@ietf.org; Wed, 30 Jan 2008 13:30:15 -0500 Received: from c83-248-80-196.bredband.comhem.se ([83.248.80.196]:3123 helo=wgbgkka02x) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JKHhH-0006CQ-4F; Wed, 30 Jan 2008 19:30:07 +0100 From: "Kent Karlsson" To: "'John Cowan'" , , References: <20080130174713.GG7602@mercury.ccil.org> Date: Wed, 30 Jan 2008 19:30:05 +0100 Message-ID: <026901c8636e$23a2bfc0$c450f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080130174713.GG7602@mercury.ccil.org> Thread-Index: AchjaD9PoO93BQ0PQ/+WYlLV8InsJgABOiCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Originating-IP: 83.248.80.196 X-Scan-Result: No virus found in message 1JKHhH-0006CQ-4F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JKHhH-0006CQ-4F c09576cf5bb09b73a4030e813d1ccdf7 X-Spam-Score: -1.0 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] RE: Using the "eur" tag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > As I said: the language is a joke, the code element is not. It still makes the registration of a code element for this joke in the 639-3 registry a mistake. I hope that code element will be removed from there before we incorporate 639-3 code elements into the IETF language subtag registry. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 13:46:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHwe-0005bd-FP; Wed, 30 Jan 2008 13:46:00 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKHwd-0005Yo-3h for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:45:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHwc-0005Yg-Pv for ltru@ietf.org; Wed, 30 Jan 2008 13:45:58 -0500 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHwb-0006YD-6S for ltru@ietf.org; Wed, 30 Jan 2008 13:45:58 -0500 Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 88ED433FD4; Wed, 30 Jan 2008 20:45:56 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 18643-01-3; Wed, 30 Jan 2008 20:45:56 +0200 (EET) Received: from DOCENDO (a91-152-100-218.elisa-laajakaista.fi [91.152.100.218]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id E301F33FCB; Wed, 30 Jan 2008 20:45:55 +0200 (EET) Message-ID: <038b01c86370$59ca3450$0500000a@DOCENDO> From: "Jukka K. Korpela" To: , References: <20080130174713.GG7602@mercury.ccil.org> <026901c8636e$23a2bfc0$c450f853@streamserve.com> Subject: Re: [Ltru] RE: Using the "eur" tag Date: Wed, 30 Jan 2008 20:45:55 +0200 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Kent Karlsson wrote: > John Cowan wrote: >> As I said: the language is a joke, the code element is not. > > It still makes the registration of a code element for this joke > in the 639-3 registry a mistake. I tend to agree, on the grounds that "Europanto" is not a language under any normal meaning for "language". It is just an idea rather than consistent system in the sense that English, Swahili, or Esperanto is consistent. There are languages that are now extinct, but can we call something a language when it was never actually used for human communication in any normal sense? A purely imaginary language, such as those created by Tolkien, is a borderline case. It could exist as a mere joke. But Europanto doesn't. It's just a worn-out joke at the level of a vague idea of mixing different languages arbitrarily. Jukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 13:48:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHzN-0002h9-3r; Wed, 30 Jan 2008 13:48:49 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKHzL-0002h4-Td for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:48:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHzL-0002gw-J2 for ltru@ietf.org; Wed, 30 Jan 2008 13:48:47 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKHzL-0004hV-9S for ltru@ietf.org; Wed, 30 Jan 2008 13:48:47 -0500 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 10:48:47 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 30 Jan 2008 10:48:45 -0800 From: Peter Constable To: Kent Karlsson , 'John Cowan' , "ietf-languages@iana.org" , "ltru@ietf.org" Date: Wed, 30 Jan 2008 10:48:44 -0800 Subject: RE: [Ltru] RE: Using the "eur" tag Thread-Topic: [Ltru] RE: Using the "eur" tag Thread-Index: AchjaD9PoO93BQ0PQ/+WYlLV8InsJgABOiCAAADOkiA= Message-ID: References: <20080130174713.GG7602@mercury.ccil.org> <026901c8636e$23a2bfc0$c450f853@streamserve.com> In-Reply-To: <026901c8636e$23a2bfc0$c450f853@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: 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 > From: Kent Karlsson [mailto:kent.karlsson14@comhem.se] > John Cowan wrote: > > As I said: the language is a joke, the code element is not. > > It still makes the registration of a code element for this joke > in the 639-3 registry a mistake. I hope that code element will > be removed from there before we incorporate 639-3 code elements > into the IETF language subtag registry. Code elements do not get *removed* from 639-3; they may become deprecated (= the RA says "retired"), but they remain in the code table with a stable sem= antic. Of course, LTRU could consider not including anything in the initial popula= ting of the registry that is already deprecated in 639-3. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 13:51:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKI1q-0005fJ-Ml; Wed, 30 Jan 2008 13:51:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKI1p-0005fC-3d for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:51:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKI1o-0005f0-PS for ltru@ietf.org; Wed, 30 Jan 2008 13:51:20 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKI1o-0004mf-FX for ltru@ietf.org; Wed, 30 Jan 2008 13:51:20 -0500 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 10:51:20 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 30 Jan 2008 10:51:19 -0800 From: Peter Constable To: "Jukka K. Korpela" , "ietf-languages@iana.org" , "ltru@ietf.org" Date: Wed, 30 Jan 2008 10:51:18 -0800 Subject: RE: [Ltru] RE: Using the "eur" tag Thread-Topic: [Ltru] RE: Using the "eur" tag Thread-Index: AchjcF/gM/jbxrYuQ2OQAMVYXbAJgAAAHhIQ Message-ID: References: <20080130174713.GG7602@mercury.ccil.org> <026901c8636e$23a2bfc0$c450f853@streamserve.com> <038b01c86370$59ca3450$0500000a@DOCENDO> In-Reply-To: <038b01c86370$59ca3450$0500000a@DOCENDO> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] > > It still makes the registration of a code element for this joke > > in the 639-3 registry a mistake. > > I tend to agree, on the grounds that "Europanto" is not a language > under > any normal meaning for "language". Even if it is considered a mistake, we must be careful about what happens i= n a coding system: a semantic *has* been encoded in 639-3, and that semanti= c/code element pair is stable and will not disappear. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 14:22:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKIWA-0006SX-La; Wed, 30 Jan 2008 14:22:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKIW9-0006SI-NX for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 14:22:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKIW9-0006SA-CW for ltru@ietf.org; Wed, 30 Jan 2008 14:22:41 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKIW8-0005bf-Su for ltru@ietf.org; Wed, 30 Jan 2008 14:22:41 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JKIW6-0001xF-21; Wed, 30 Jan 2008 14:22:38 -0500 Date: Wed, 30 Jan 2008 14:22:38 -0500 To: "Jukka K. Korpela" Subject: Re: [Ltru] RE: Using the "eur" tag Message-ID: <20080130192237.GE11346@mercury.ccil.org> References: <20080130174713.GG7602@mercury.ccil.org> <026901c8636e$23a2bfc0$c450f853@streamserve.com> <038b01c86370$59ca3450$0500000a@DOCENDO> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <038b01c86370$59ca3450$0500000a@DOCENDO> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jukka K. Korpela scripsit: > I tend to agree, on the grounds that "Europanto" is not a language under > any normal meaning for "language". It is just an idea rather than > consistent system in the sense that English, Swahili, or Esperanto is > consistent. There are languages that are now extinct, but can we call > something a language when it was never actually used for human > communication in any normal sense? What do you mean, not used? I addressed my blog post to the readers of my blog, and the Europanto web site is addressed to all comers. It may not be used conversationally yet, but there definitely exists a body of written works. > A purely imaginary language, such as those created by Tolkien, is a > borderline case. It could exist as a mere joke. Quenya and Sindarin are far more than jokes: they are targets for translation and the creation of original works of literature. There exist third-party grammars and dictionaries for both of them. > It's just a worn-out joke at the level of a vague idea of mixing > different languages arbitrarily. Macaronic composition, which does exactly that, has a long and distinguished tradition going back to the Middle Ages. Europanto is just the latest outcrop of this perennial idea. You can call it worn-out if you want, but the decisions of this list ought not to depend on what sense of humor people have. This isn't Europanto, but it's relevant: THE ELDERLY GENTLEMAN MALUM OPUS By the side of a murmuring stream Prope ripam fluvii solus an elderly gentleman sat. A senex silently sat; On the top of his head was a wig, Super capitum ecce his wig, and a-top of his wig was his hat. Et wig super, ecce his hat. The wind it blew high and blew strong, Blew Zephyrus alte, acerbus, as the elderly gentleman sat; Dum elderly gentleman sat; And bore from his head in a trice, Et a capite took up quite torve and plunged in the river his hat. Et in rivum projecit his hat. The gentleman then took his cane Tunc soft maledixit the old man, which lay by his side as he sat; Tunc stooped from the bank where he sat And he dropped in the river his wig, Et cum scipio poked in the water, in attempting to get out his hat. Conatus servare his hat. His breast it grew cold with despair, Blew Zephyrus alte, acerbus, and full in his eye madness sat; The moment it saw him at that; So he flung in the river his cane Et whisked his novum scratch wig to swim with his wig, and his hat. In flumen, along with his hat. Cool reflection at last came across Ab imo pectore damnavit while this elderly gentleman sat; In coeruleus eye dolor sat; So he thought he would follow the stream Tunc despairingly threw in his cane and look for his cane, wig, and hat. Nare cum his wig and his hat. His head being thicker than common, Contra bonos mores, don't swear o'er-balanced the rest of his fat; It 'est wicked you know (verbum sat), And in plumped this son of a woman Si this tale habet no other moral to follow his wig, cane, and hat. Mehercle! You're gratus to that! --George Canning --James Appleton Morgan -- John Cowan http://www.ccil.org/~cowan It's like if you meet an really old, really rich guy covered in liver spots and breathing with an oxygen tank, and you say, "I want to be rich, too, so I'm going to start walking with a cane and I'm going to act crotchety and I'm going to get liver disease. --Wil Shipley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 15:47:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKJqM-0002Ys-6b; Wed, 30 Jan 2008 15:47:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKJqL-0002V7-C2 for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 15:47:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKJqL-0002UK-0v for ltru@ietf.org; Wed, 30 Jan 2008 15:47:37 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKJqK-0000jm-Jx for ltru@ietf.org; Wed, 30 Jan 2008 15:47:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ttppfyapdjyMoVGqvNwA0CPWk4YqyorIF5J4GQUqlib0am9wJ9Q152W4QPQXbOZo; 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.95] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JKJqJ-0004CV-To for ltru@ietf.org; Wed, 30 Jan 2008 15:47:36 -0500 Message-ID: <003c01c86381$5a00ec00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080130174713.GG7602@mercury.ccil.org><026901c8636e$23a2bfc0$c450f853@streamserve.com><038b01c86370$59ca3450$0500000a@DOCENDO> Subject: Re: [Ltru] RE: Using the "eur" tag Date: Wed, 30 Jan 2008 12:47:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911701b9f855b3263bf605124dfda7f66388350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.95 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 Hi - As a technical contributor... > From: "Peter Constable" > To: "Jukka K. Korpela" ; ; > Sent: Wednesday, January 30, 2008 10:51 AM > Subject: RE: [Ltru] RE: Using the "eur" tag ... > Even if it is considered a mistake, we must be careful about what > happens in a coding system: a semantic *has* been encoded in 639-3, > and that semantic/code element pair is stable and will not disappear. ... I strongly agree. We chartered to specify the operation of a registry which happens to use code elements specified elsewhere. Second- guessing other stamdards beyond what is necessary to ensure that the registry functions as such seems unwise. In the particular case of "eur", no one has described how including it would impair the operation of the registry, nor how it would cause problems for language tagging in general. On the other hand, excluding it would open a dreadful can of worms with respect to the potential for "cherry picking". It really doesn't matter whether the language was specified as a joke. The code has been assigned and it *does* have a meaning. Now let's get back to more interesting problems like Erzgebirgisch where there seem to be some question about what language that variety is a variety *of*, and whether there is any sensible guidance we could offer for the handling of such requests. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 16:15:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKHL-0002Fz-V8; Wed, 30 Jan 2008 16:15:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKKHK-0002Dm-GB for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 16:15:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKHK-0002BN-4n for ltru@ietf.org; Wed, 30 Jan 2008 16:15:30 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKKHJ-0001rW-RL for ltru@ietf.org; Wed, 30 Jan 2008 16:15:30 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080130211529.IYFM15146.mta11.adelphia.net@DGBP7M81>; Wed, 30 Jan 2008 16:15:29 -0500 Message-ID: <011e01c86385$3ccc20b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <20080130183120.984E725976E@eikenes.alvestrand.no> Date: Wed, 30 Jan 2008 13:15:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Excluding language subtag 'eur' (was: Re: Principles of Operation) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: >> As I said: the language is a joke, the code element is not. > > It still makes the registration of a code element for this joke in the > 639-3 registry a mistake. I hope that code element will be removed > from there before we incorporate 639-3 code elements into the IETF > language subtag registry. Speaking as editor of RFC 4645bis, I would need some specific wording in RFC 4646bis to authorize this. I cannot in good faith exclude any subtag from the 4645bis Registry without an objective justification, on the basis that members of ietf-languages feel the subtag is silly or a joke or a mistake. To do so would be a process failure in the truest sense of the phrase. (Speaking as a contributor, I absolutely agree that the "language" Europanto is silly and a joke, and that its inclusion in ISO 639-3 was a mistake.) -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 16:25:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKR5-0000mj-1C; Wed, 30 Jan 2008 16:25:35 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKKR3-0000md-Vj for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 16:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKR3-0000mV-M2 for ltru@ietf.org; Wed, 30 Jan 2008 16:25:33 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKR1-0002uW-BL for ltru@ietf.org; Wed, 30 Jan 2008 16:25:33 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=n7JrgQW9esvtS5Ei6ws9cZB0Dla1+ZdOa14OMUcjgGNmhz+ukO+HoUlUMhGh1vp8; 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.95] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JKKQy-0003DF-Hb for ltru@ietf.org; Wed, 30 Jan 2008 16:25:28 -0500 Message-ID: <000801c86386$a4d5c660$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20080130183120.984E725976E@eikenes.alvestrand.no> <011e01c86385$3ccc20b0$6501a8c0@DGBP7M81> Subject: Re: [Ltru] Excluding language subtag 'eur' (was: Re: Principles ofOperation) Date: Wed, 30 Jan 2008 13:25:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911775e6ca2619c19dab16a46c024c699865350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.203.95 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: "Doug Ewell" > To: ; "LTRU Working Group" > Sent: Wednesday, January 30, 2008 1:15 PM > Subject: [Ltru] Excluding language subtag 'eur' (was: Re: Principles ofOperation) ... > Speaking as editor of RFC 4645bis, I would need some specific wording in > RFC 4646bis to authorize this. I cannot in good faith exclude any > subtag from the 4645bis Registry without an objective justification, on > the basis that members of ietf-languages feel the subtag is silly or a > joke or a mistake. To do so would be a process failure in the truest > sense of the phrase. > > (Speaking as a contributor, I absolutely agree that the "language" > Europanto is silly and a joke, and that its inclusion in ISO 639-3 was a > mistake.) ... I object to making such exclusions. There is no operational or technical reason to justify such an exclusion. Making such an exclusion opens the door to accusations of cherry-picking. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 16:27:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKSt-0003Jx-3U; Wed, 30 Jan 2008 16:27:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKKSm-0003Aq-Fs for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 16:27:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKSm-00039l-0J for ltru@ietf.org; Wed, 30 Jan 2008 16:27:20 -0500 Received: from [74.86.129.163] (helo=sl14.dnsireland.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKSk-0002wK-Ki for ltru@ietf.org; Wed, 30 Jan 2008 16:27:19 -0500 Received: from murrisk2.westnet.ie ([88.81.100.235] helo=[192.168.1.126]) by sl14.dnsireland.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKKSj-00069P-C5; Wed, 30 Jan 2008 21:27:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <011e01c86385$3ccc20b0$6501a8c0@DGBP7M81> References: <20080130183120.984E725976E@eikenes.alvestrand.no> <011e01c86385$3ccc20b0$6501a8c0@DGBP7M81> Date: Wed, 30 Jan 2008 21:22:10 +0000 To: , "LTRU Working Group" From: Michael Everson Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl14.dnsireland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - evertype.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: Excluding language subtag 'eur' (was: Re: Principles of Operation) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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:15 -0800 2008-01-30, Doug Ewell wrote: >Speaking as editor of RFC 4645bis, I would need some specific >wording in RFC 4646bis to authorize this. I cannot in good faith >exclude any subtag from the 4645bis Registry without an objective >justification, on the basis that members of ietf-languages feel the >subtag is silly or a joke or a mistake. To do so would be a process >failure in the truest sense of the phrase. Life is too short for this nonsense. Do let's not gerrymander ISO 639-3. If it has crap in it, people just don't have to use the crap. And if they want to, let them. 4645bis should not be a language nanny. -- Michael Everson * http://www.evertype.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 30 16:42:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKhp-0006WW-Jv; Wed, 30 Jan 2008 16:42:53 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKKho-0006W6-9Y for ltru-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 16:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKhn-0006Vd-Iw for ltru@ietf.org; Wed, 30 Jan 2008 16:42:51 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKhl-0003F8-8V for ltru@ietf.org; Wed, 30 Jan 2008 16:42:51 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20080130214248.DKGR22143.mta10.adelphia.net@DGBP7M81> for ; Wed, 30 Jan 2008 16:42:48 -0500 Message-ID: <012401c86389$0dfccd80$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 30 Jan 2008 13:42:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] Re: Excluding language subtag 'eur' (was: Re: Principles of Operation) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 object to making such exclusions. There is no operational or > technical reason to justify such an exclusion. Making such an > exclusion opens the door to accusations of cherry-picking. I didn't say I favored such an exclusion. What I said was that I would not make the exclusion in the absence of wording that authorized it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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 Jan 31 10:51:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbhD-0008Aa-7J; Thu, 31 Jan 2008 10:51:23 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKbhB-0008AU-H8 for ltru-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 10:51:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbhB-000897-60 for ltru@lists.ietf.org; Thu, 31 Jan 2008 10:51:21 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKbh9-0000bo-M1 for ltru@lists.ietf.org; Thu, 31 Jan 2008 10:51:21 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JKbh9-0007Z3-Cn; Thu, 31 Jan 2008 10:51:19 -0500 Date: Thu, 31 Jan 2008 10:51:19 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Principles of Operation Message-ID: <20080131155119.GC1018@mercury.ccil.org> References: <019f01c86050$db8b0370$6501a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: > At the moment we could not deprecate language "err" in favour > of a variant subtag "foobar" or a tag "fr-foobar". No, we can't, but that's not a serious use case. If ISO 639 decides to merge two languages, we aren't going to follow; we'll just add the new merged code, and keep the two codes they retire. -- John Cowan http://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 31 13:28:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKe91-0000ru-Lr; Thu, 31 Jan 2008 13:28:15 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKe8z-0000r4-Kt for ltru-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 13:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKe8z-0000ql-Ag for ltru@lists.ietf.org; Thu, 31 Jan 2008 13:28:13 -0500 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKe8w-0004F1-Ho for ltru@lists.ietf.org; Thu, 31 Jan 2008 13:28:13 -0500 Received: from c83-248-80-196.bredband.comhem.se ([83.248.80.196]:2237 helo=wgbgkka02x) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JKe8u-0006q4-6M; Thu, 31 Jan 2008 19:28:09 +0100 From: "Kent Karlsson" To: "'John Cowan'" , "'Frank Ellermann'" References: <019f01c86050$db8b0370$6501a8c0@DGBP7M81> <20080131155119.GC1018@mercury.ccil.org> Subject: RE: [Ltru] Re: Principles of Operation Date: Thu, 31 Jan 2008 19:28:05 +0100 Message-ID: <030101c86437$076cf860$c450f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080131155119.GC1018@mercury.ccil.org> Thread-Index: AchkISSN/n/Vk2I2QkipOOQBYIjl7wAEa+yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Originating-IP: 83.248.80.196 X-Scan-Result: No virus found in message 1JKe8u-0006q4-6M. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JKe8u-0006q4-6M a3653c899804673b12e2c4bada61cdb3 X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Frank Ellermann scripsit: > > > At the moment we could not deprecate language "err" in favour > > of a variant subtag "foobar" or a tag "fr-foobar". > > No, we can't, but that's not a serious use case. If ISO 639 > decides to merge two languages, we aren't going to follow; > we'll just add the new merged code, and keep the two codes > they retire. They surely must be kept (if they ever got in to begin with), but I do hope that, by 639-3 RA, codes that become "retired" are "automatically" deprecated in LSR. I'm not sure if any new text in 4646bis is needed to say that more explicitly. If a 639-3 code is "retired" already before 4645bis is submitted in final form, it should not be part of 4645bis. I understand that current drafts are constructed without already retired "new" codes. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 31 13:41:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeMC-0000c1-4v; Thu, 31 Jan 2008 13:41:52 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1JKeMB-0000Te-1D for ltru-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 13:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeMA-0000RD-Kt for ltru@lists.ietf.org; Thu, 31 Jan 2008 13:41:50 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKeMA-0004WD-CL for ltru@lists.ietf.org; Thu, 31 Jan 2008 13:41:50 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1JKeM5-0002oz-7a; Thu, 31 Jan 2008 13:41:45 -0500 Date: Thu, 31 Jan 2008 13:41:45 -0500 To: Kent Karlsson Subject: Re: [Ltru] Re: Principles of Operation Message-ID: <20080131184145.GB31250@mercury.ccil.org> References: <20080131155119.GC1018@mercury.ccil.org> <030101c86437$076cf860$c450f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <030101c86437$076cf860$c450f853@streamserve.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > They surely must be kept (if they ever got in to begin with), > but I do hope that, by 639-3 RA, codes that become "retired" > are "automatically" deprecated in LSR. Yes, indeed. However, in the case of a split there can be no preferred alternative; in the case of a merge there can. > text in 4646bis is needed to say that more explicitly. > > If a 639-3 code is "retired" already before 4645bis is submitted > in final form, it should not be part of 4645bis. I understand > that current drafts are constructed without already retired > "new" codes. Correct. -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot cowan@ccil.org that I foolishly ate out of an illjudged faith http://ccil.org/~cowan in the benignancy of vegetables. --And Rosta _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru