From ltru-bounces@ietf.org Wed Nov 01 16:21:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNWF-0001H2-T7; Wed, 01 Nov 2006 16:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNWE-0001Et-6h for ltru@ietf.org; Wed, 01 Nov 2006 16:21:06 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNWC-0004QM-VQ for ltru@ietf.org; Wed, 01 Nov 2006 16:21:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dSsYm9R+MqcTYuQWu6CICA1Spa+3qQec6kd5lxvlmi7S5/tbRdJBtvQ8xtrRfYe9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.178] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GfNWC-0007z1-D3 for ltru@ietf.org; Wed, 01 Nov 2006 16:21:04 -0500 Message-ID: <008901c6fdfb$a70cf260$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002301c6fd46$0d54d800$6501a8c0@DGBP7M81> <20061101000004.GH8281@ccil.org> Subject: Re: [Ltru] Re: IPA as a script Date: Wed, 1 Nov 2006 13:21:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6463a2afd24d41f6994fefe1807959615350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.178 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Doug Ewell" > Cc: > Sent: Tuesday, October 31, 2006 4:00 PM > Subject: Re: [Ltru] Re: IPA as a script ... > > 1b. Roughly how many scripts have phonetic transcription systems based > > on them that need encoding? > > About one in common use; who knows how many individual oddities. ... I think we need to make a careful distinction here between "phonetic transcription systems" and the scripts used to write them. I don't know of any phonetic transcription system that is used with more than a single set of symbols; be identifying a transcription system you've identified the script. (In this regard a transcription system is rather like an orthography.) The only such script I would worry about is IPA. However, one can't make terribly useful inferences in the other direction. For example, knowing that something uses IPA to transcribe English will only give a general idea what symbols *might* be used to transcribe the "t" phoneme. Consequently, as soon as one has narrowed the search space to transcriptions of a language, the next interesting level is identifying the transcription system, rather than the script. However, I think we need to be realistic that there's a lot of stuff that we can recognize as being an IPA-based transcription, but more narrowly identifying the transcription system may not be practical for cataloguers. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 01 17:09:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOHW-0005L9-7N; Wed, 01 Nov 2006 17:09:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOHV-0005IJ-3M for ltru@ietf.org; Wed, 01 Nov 2006 17:09:57 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOHT-0006Pg-SL for ltru@ietf.org; Wed, 01 Nov 2006 17:09:57 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GfOHS-0002Qc-Gi; Wed, 01 Nov 2006 17:09:54 -0500 Date: Wed, 1 Nov 2006 17:09:54 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: IPA as a script Message-ID: <20061101220954.GB24819@ccil.org> References: <20061101000004.GH8281@ccil.org> <008901c6fdfb$a70cf260$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008901c6fdfb$a70cf260$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > I think we need to make a careful distinction here between > "phonetic transcription systems" and the scripts used to > write them. I don't know of any phonetic transcription > system that is used with more than a single set of symbols; > be identifying a transcription system you've identified the script. > (In this regard a transcription system is rather like an orthography.) Granted, but my point was that IPA and its friendly competitors (Americanist, UPA, LMA) use a subset of the Latin-script characters, and as such Latin is the only script generally used for phonetic transcription purposes (leaving out the novel, the idiosyncratic, and so on). > The only such script I would worry about is IPA. That strongly depends on which tradition of descriptive linguistics you belong to, which strongly depends on what language varieties you study. I wish it weren't so and everyone used IPA, but they don't. > However, I think we need to be realistic that there's a lot of stuff > that we can recognize as being an IPA-based transcription, > but more narrowly identifying the transcription system may not be > practical for cataloguers. Indeed. -- Barry gules and argent of seven and six, John Cowan on a canton azure fifty molets of the second. cowan@ccil.org --blazoning the U.S. flag http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 01 17:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOdq-0005KJ-5A; Wed, 01 Nov 2006 17:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOdo-0005Jo-Nz for ltru@ietf.org; Wed, 01 Nov 2006 17:33:00 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOdl-0002Co-Ep for ltru@ietf.org; Wed, 01 Nov 2006 17:33:00 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Wed, 1 Nov 2006 14:32:54 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:32:52 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: IPA as a script Date: Wed, 1 Nov 2006 14:30:41 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10947813B@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <20061101220954.GB24819@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb+AnrfaLQ2HBEBS6uRr1aKpdgxJgAAn6Vg References: <20061101000004.GH8281@ccil.org><008901c6fdfb$a70cf260$6601a8c0@oemcomputer> <20061101220954.GB24819@ccil.org> From: Peter Constable To: X-OriginalArrivalTime: 01 Nov 2006 22:32:53.0238 (UTC) FILETIME=[AB826960:01C6FE05] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Indeed, having worked on character encoding for systems of phonetic transcription in recent years, I know that there is more than just IPA in use out there.=20 Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 > The only such script I would worry about is IPA. That strongly depends on which tradition of descriptive linguistics you belong to, which strongly depends on what language varieties you study. I wish it weren't so and everyone used IPA, but they don't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 02 06:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaJ7-0001DP-Pn; Thu, 02 Nov 2006 06:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaJ6-0001DF-G6 for ltru@ietf.org; Thu, 02 Nov 2006 06:00:24 -0500 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfaJ5-0000fg-1M for ltru@ietf.org; Thu, 02 Nov 2006 06:00:24 -0500 Received: (qmail 50022 messnum 6404823 invoked from network[194.125.174.66/ts09-066.dublin.indigo.ie]); 2 Nov 2006 11:00:10 -0000 Received: from ts09-066.dublin.indigo.ie (HELO ?194.125.174.66?) (194.125.174.66) by mail00.svc.cra.dublin.eircom.net (qp 50022) with SMTP; 2 Nov 2006 11:00:10 -0000 Mime-Version: 1.0 (Apple Message framework v728) Message-Id: To: LTRU Working Group , TC46-L Information and Documentation Technology List From: Marion Gunn Date: Thu, 2 Nov 2006 11:03:53 +0000 X-Mailer: Apple Mail (2.728) X-Spam-Score: 2.2 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Subject: [Ltru] (no subject) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1031629891==" Errors-To: ltru-bounces@ietf.org --===============1031629891== Content-Type: multipart/alternative; boundary=Apple-Mail-3--525360091 --Apple-Mail-3--525360091 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Our petition is only for the _one_ additional script, Doug. I respect =20= your right to speak for ANSI, but please let nobody exaggerate this =20 Irish request as a "reason" to reject it (it being only as set out =20 below). Irish has a reasonable requirement for 4 script encodings: (a) Ancient (Ogham); (b) Traditional (Gaelic); (c) Modern (Roman); (d) Phonetic (IPA). What does Ireland (NSAI) have to do to register script (d)? mg On 31 Oct 2006, at 23:41, scr=EDobh Doug Ewell: > Mark Davis wrote: > > >> en-XXXX, where XXXX means that the 'en' is written in "some =20 >> phonetic transcription but we're not going to tell you what script =20= >> it is based on", I don't think would be particularly useful at all. >> > > Just to play devil's advocate here: > > 1a. Roughly how many phonetic transcription systems are there that =20= > need encoding? > > or > > 1b. Roughly how many scripts have phonetic transcription systems =20 > based on them that need encoding? > > 2. Do we want to petition ISO 15924/RA... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-3--525360091 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Our petition = is only for the _one_ additional script, Doug.=A0I respect your right to = speak for ANSI, but please let nobody exaggerate this Irish request as a = "reason" to reject it (it being only as set out below).=A0

Irish=A0has a reasonable = requirement for 4 script encodings:
(a) Ancient = (Ogham);
(b) Traditional (Gaelic);
(c) Modern = (Roman);
(d) Phonetic (IPA).

What does=A0 Ireland (NSAI) = have to do to register script (d)?
mg

On 31 Oct 2006, at = 23:41, scr=EDobh Doug Ewell:
Mark Davis <mark dot davis at icu dash = project dot org> wrote:


en-XXXX, where XXXX means that the 'en' is = written in "some phonetic transcription but we're not going to tell you = what script it is based on", I don't think would be particularly useful = at all.


Just to play = devil's advocate here:

1a.=A0 Roughly how = many phonetic transcription systems are there that need = encoding?

or

1b.=A0 Roughly how = many scripts have phonetic transcription systems based on them that need = encoding?

2.=A0 Do we want = to petition ISO 15924/RA...



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

= --Apple-Mail-3--525360091-- --===============1031629891== 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 --===============1031629891==-- From ltru-bounces@ietf.org Thu Nov 02 11:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffQu-00055L-Bp; Thu, 02 Nov 2006 11:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffQs-00054q-FW for ltru@lists.ietf.org; Thu, 02 Nov 2006 11:28: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 1GffQp-0003T9-1F for ltru@lists.ietf.org; Thu, 02 Nov 2006 11:28:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GffQY-0005lb-Gw for ltru@lists.ietf.org; Thu, 02 Nov 2006 17:28:27 +0100 Received: from d253154.dialin.hansenet.de ([80.171.253.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 17:28:26 +0100 Received: from nobody by d253154.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 17:28:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 02 Nov 2006 17:25:13 +0100 Organization: Lines: 34 Message-ID: <454A1BE9.4C96@xyzzy.claranet.de> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253154.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > ??!! Please forget it, I misunderstood what you want to do with Lphn... ;-) [LTRU "resolution" or similar] > That is certainly something I'd consider. This WG owns the 4646 LT > space, so if it seems like the sensible solution to us and the > 15924 JAC won't budge, we can ask them to reserve an ID. I'm guessing, and maybe it's completely wrong: I guess it's more in the "IETF style" if somebody (e.g. you) drafts a short text, then we discuss it until enough of us like it, "sign" it as individuals, and send it to somebody at the 15924-side. Noting that the individuals who signed it are currently working on 4646bis in the IETF LTRU WG. Like Harald's 3683 petition last year, everybody was free to sign it, some did, others didn't, and after some time Harald sent it to the IESG or maybe only Scott (the A-D at this time). For something more "official" we'd need to convince the Chairs and the A-D, that could get them into lots of trouble (appeals etc.), but what we do or don't as individuals is nobody's business but our own. Of course we would not claim to speak on behalf of LTRU, let alone the IETF. IMO LTRU doesn't "own" the LT space, it only proposes some rules to manage it, approved by the IESG on behalf of the IETF after a Last Call. The IETF is free to change those rules later (as it did for 1766 and 3066), and while they are in force the review list "owns" this space to some (small) degree, most of it is determined by the source standards following the approved rules. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 02 11:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GffkA-0002cA-IV; Thu, 02 Nov 2006 11:48:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gffk9-0002c1-7g for ltru@lists.ietf.org; Thu, 02 Nov 2006 11:48:41 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gffjt-0005bl-0g for ltru@lists.ietf.org; Thu, 02 Nov 2006 11:48:41 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Thu, 2 Nov 2006 08:48:24 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 08:47:34 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: IPA as a script Date: Thu, 2 Nov 2006 08:47:33 -0800 Message-ID: <19A328037921AA42847A717566D1D6A1094F8B8D@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <454A1BE9.4C96@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb+nA+jWO4zZNCUTOq011NMiwixUwAAfuqw References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com><45471F81.30AC@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> <454A1BE9.4C96@xyzzy.claranet.de> From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 02 Nov 2006 16:47:34.0129 (UTC) FILETIME=[985F0610:01C6FE9E] 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 Of course you're right here. What I was thinking of was that we could draft text in 4646bis that effectively defined a subtag as something proprietary to the LST registry rather than derived from a source standard -- which means the process you describe. Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 I'm guessing, and maybe it's completely wrong: I guess it's more in the "IETF style" if somebody (e.g. you) drafts a short text, then we discuss it until enough of us like it... IMO LTRU doesn't "own" the LT space, it only proposes some rules to manage it... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 02 13:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhTv-0001ab-Qt; Thu, 02 Nov 2006 13:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhTt-0001aW-U5 for ltru@ietf.org; Thu, 02 Nov 2006 13:40:01 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfhTo-0002AN-6f for ltru@ietf.org; Thu, 02 Nov 2006 13:40:01 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k8RM5wSVnHeOjS5oKVrLvEu2IbUdFeMliodCKGKp9PXkyjawgCDDZBvXFFyZgSPT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.246] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GfhTj-00037S-CE; Thu, 02 Nov 2006 13:39:53 -0500 Message-ID: <000001c6feae$4483f0e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "TC46-L Information and Documentation Technology List" , "Marion Gunn" References: Subject: Re: [Ltru] (no subject) Date: Thu, 2 Nov 2006 09:59:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6cab45c1c8630c875474634742a17000b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.246 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As IETF ltru working group co-chair: > From: "Marion Gunn" > To: "LTRU Working Group" ; "TC46-L Information and Documentation Technology List" > Sent: Thursday, November 02, 2006 3:03 AM > Subject: [Ltru] (no subject) > > Our petition is only for the _one_ additional script, Doug. I respect > your right to speak for ANSI, but please let nobody exaggerate this > Irish request as a "reason" to reject it (it being only as set out > below). ... RFC 2418 says it best. Note well the last sentence: There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 02:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GftY2-0000bY-U2; Fri, 03 Nov 2006 02:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GftY1-0000a4-RW for ltru@ietf.org; Fri, 03 Nov 2006 02:33:05 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GftOJ-00023I-Ib for ltru@ietf.org; Fri, 03 Nov 2006 02:23:04 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061103072302.XKOS24907.mta9.adelphia.net@DGBP7M81> for ; Fri, 3 Nov 2006 02:23:02 -0500 Message-ID: <004701c6ff18$e644bbc0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] (no subject) Date: Thu, 2 Nov 2006 23:23:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> From: "Marion Gunn" > >> Our petition is only for the _one_ additional script, Doug. I respect >> your right to speak for ANSI, but please let nobody exaggerate this >> Irish request as a "reason" to reject it (it being only as set out >> below). > ... > > RFC 2418 says it best. Note well the last sentence: > ... > Participation is by individual technical contributors, rather than > by formal representatives of organizations. To be honest, I have no idea where this bit about "speaking for ANSI" comes from. I didn't mention ANSI in my post, I'm not a member of ANSI, and I certainly don't claim to speak for them. I don't know what position ANSI has taken on this subject, if any, and I really don't care. When I said in my post, "Do we want to petition ISO 15924/RA..." I meant WE, the LTRU Working Group. Any time I use the word "we" on this list without further qualification, that is what I mean. And if the WG as a group is not permitted to make such a petition, then "we" should be interpreted as "individual members of the LTRU WG, acting as individuals." I've already stated more than once on this list that the fact that I'm an American does not make me a mouthpiece for American policymakers. My opinions are my own. They are not necessarily those of any government, SDO, or commercial interest. I would appreciate not having to make this vacuous and non-productive point again. Also, I did not have any specific request in mind when I wrote about petitioning ISO 15924/RA for more than one code element, and in particular I was not singling out Marion's request. Apparently lots of people want to have IPA declared a separate script. Peter had mentioned that there were other Latin-based transcription schemes besides IPA, and transcription schemes based on other writing systems (such as Hangul). -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 07:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfxi1-0002Vs-Bi; Fri, 03 Nov 2006 06:59:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfxi0-0002Vn-2f for ltru@ietf.org; Fri, 03 Nov 2006 06:59:40 -0500 Received: from mail02.svc.cra.dublin.eircom.net ([159.134.118.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gfxhw-0004bs-MY for ltru@ietf.org; Fri, 03 Nov 2006 06:59:40 -0500 Received: (qmail 87278 messnum 5252479 invoked from network[194.125.174.80/ts09-080.dublin.indigo.ie]); 3 Nov 2006 11:59:30 -0000 Received: from ts09-080.dublin.indigo.ie (HELO ?194.125.174.80?) (194.125.174.80) by mail02.svc.cra.dublin.eircom.net (qp 87278) with SMTP; 3 Nov 2006 11:59:30 -0000 In-Reply-To: <004701c6ff18$e644bbc0$6501a8c0@DGBP7M81> References: <004701c6ff18$e644bbc0$6501a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2CA490DB-6BED-465C-BFF2-6B434FF14033@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] (no subject) Date: Fri, 3 Nov 2006 12:03:14 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 3 Nov 2006, at 07:23, scr=EDobh Doug Ewell: > ... > I don't know what position ANSI has taken on this subject, if any, =20 > and I really don't care. US (ANSI?) currently holds a majority of seats on the ISO 15924/RA AC =20= which rejected IPA. > > When I said in my post, "Do we want to petition ISO 15924/RA..." I =20 > meant WE, the LTRU Working Group. Fine. > I would appreciate not having to make this vacuous and non-=20 > productive point again Ensuring internationally-balanced ACs would help - failing that, =20 please bear in mind that your own ISO National Body (which your =20 address tells me is ANSI) is still in the strongest position to help/=20 hinder all such requests. > Apparently lots of people want to have IPA declared a separate =20 > script.. Apparently. 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 Fri Nov 03 07:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfxwK-0005Xs-49; Fri, 03 Nov 2006 07:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfxwI-0005Xj-FR for ltru@ietf.org; Fri, 03 Nov 2006 07:14:26 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfxvw-0006i3-R1 for ltru@ietf.org; Fri, 03 Nov 2006 07:14:26 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kA3CDrco012660 for ; Fri, 3 Nov 2006 21:13:53 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 46e0_c55f1e2c_6b34_11db_9056_0014221f2a2d; Fri, 03 Nov 2006 21:13:52 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35630) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 3 Nov 2006 21:13:25 +0900 Message-Id: <6.0.0.20.2.20061103135059.04e0ab70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Nov 2006 18:06:44 +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: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Ltru] Factual correction X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat off] It has come to my attention that in my long mail addressing the points in JFC Morfin's IETF Last Call comments on our matching draft (archived at http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html), there was a factual incorrectness. In the paragraph that read: The commenter seems to claim that draft-ietf-ltru-matching conflicts with draft-ietf-ltru-registry (here called RFC 3066bis) because the later defines well-formed tags while the former does not require well-formed tags. The reason for not requiring checking for well-formed tags when matching was discussed extensively in the WG. There is a very clear reason: requiring this would require to check the IANA language subtag registry, potentially for every matching operation, which was considered operationally infeasible. It would also be an unnecessary performance punishment for those who actually use well-formed tags. In general, non-wellformed tags or ranges will simply not match anything, which is just fine. the sentence that said: There is a very clear reason: requiring this would require to check the IANA language subtag registry, potentially for every matching operation, which was considered operationally infeasible. was factually wrong. Well-formedness checking does not need online access to the registry, only one-time access when the checking software is built to get the list of grandfathered tags. Strictly speaking, not even validation does require online access to the registry, because validation can be done with respect to a specific registry date. The rest of the paragraph, in particular the following three sentences, are unaffected by this. The reason for not requiring checking for well-formed tags when matching was discussed extensively in the WG. It would also be an unnecessary performance punishment for those who actually use well-formed tags. In general, non-wellformed tags or ranges will simply not match anything, which is just fine. I would like to appologize for any confusion this may have created. I personally do not think there was anything unclear in the draft (now an RFC), or anything that the WG would have done differently. My guess is also that this problem would have been spotted very quickly by quite some WG participants if it hadn't been burried in the middle of a very long mail answering another very long mail. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 08:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfyyd-0008C2-8S; Fri, 03 Nov 2006 08:20:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfyyc-0008Bw-5d for ltru@ietf.org; Fri, 03 Nov 2006 08:20:54 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfyyW-0002RF-Re for ltru@ietf.org; Fri, 03 Nov 2006 08:20:54 -0500 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Fri, 3 Nov 2006 05:20:48 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Fri, 3 Nov 2006 05:19:58 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] (no subject) Date: Fri, 3 Nov 2006 05:19:36 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10956C03B@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <2CA490DB-6BED-465C-BFF2-6B434FF14033@egt.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] (no subject) Thread-Index: Acb/P5Z09QGWFzDBT/eEafTy4tggZAACoQVQ References: <004701c6ff18$e644bbc0$6501a8c0@DGBP7M81> <2CA490DB-6BED-465C-BFF2-6B434FF14033@egt.ie> From: Peter Constable To: Marion Gunn , LTRU Working Group X-OriginalArrivalTime: 03 Nov 2006 13:19:59.0002 (UTC) FILETIME=[C2F337A0:01C6FF4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The members of the 15924 JAC do not represent countries but rather represent ISO-appointed agencies:=20 - ISO/IEC JTC1/SC2 - ISO TC37 - ISO TC46 - ISO 639-2/RA - ISO 15924/RA Peter -----Original Message----- From: Marion Gunn [mailto:mgunn@egt.ie]=20 US (ANSI?) currently holds a majority of seats on the ISO 15924/RA AC =20 which rejected IPA. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 09:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0Iz-0008IV-J4; Fri, 03 Nov 2006 09:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0Iy-0008BN-O4 for ltru@ietf.org; Fri, 03 Nov 2006 09:46:00 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0Ip-0000ZA-Gt for ltru@ietf.org; Fri, 03 Nov 2006 09:46:00 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061103144546.DXOV11275.mta10.adelphia.net@DGBP7M81> for ; Fri, 3 Nov 2006 09:45:46 -0500 Message-ID: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 3 Nov 2006 06:45:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ltru] ANSI and ISO 15924 (was: Re: (no subject)) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: >> I don't know what position ANSI has taken on this subject, if any, >> and I really don't care. > > US (ANSI?) currently holds a majority of seats on the ISO 15924/RA AC > which rejected IPA. Neither the RA nor the JAC is defined in terms of representatives of nations (U.S.) or national SDOs (ANSI). If you mean that "Americans" currently hold a majority, then that is not the same thing, and once again implies that Americans cannot make independent decision or hold opinions outside of what their government or SDO tells them. The six-member JAC currently contains three members from the U.S. (not a majority), one from Norway, one from France, and one from Ireland. I know you do not consider Michael to be "from" Ireland but I guarantee you he does not consider himself an American mouthpiece. >> I would appreciate not having to make this vacuous and non- >> productive point again > > Ensuring internationally-balanced ACs would help - That is your opinion. It presumes that technical judgments, such as whether IPA is an application of the Latin script or a separate script altogether, are influenced by whether one is American or not. I don't see the connection there. It isn't related to the degree of adoption of IPA in the U.S. versus other countries; if anything, I would think that the relatively low usage of IPA in the U.S. would make it *more* likely to be viewed as a separate script. > failing that, please bear in mind that your own ISO National Body > (which your address tells me is ANSI) is still in the strongest > position to help/ hinder all such requests. Does ANSI in fact have influence over ISO 15924/RA-JAC? Does any national body? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 13:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg49e-0001Yt-QL; Fri, 03 Nov 2006 13:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg49e-0001Yo-BU for ltru@ietf.org; Fri, 03 Nov 2006 13:52:38 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg49b-00088f-0g for ltru@ietf.org; Fri, 03 Nov 2006 13:52:38 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dx/fFK8JDDqBf5MH/u16WfcMbyC3p7xy4nAgpbkzJh+O0hDui8iuzsAPdfFhydE1; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.215] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gg49W-0006l9-Sa for ltru@ietf.org; Fri, 03 Nov 2006 13:52:31 -0500 Message-ID: <001a01c6ff79$35c27560$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <004701c6ff18$e644bbc0$6501a8c0@DGBP7M81><2CA490DB-6BED-465C-BFF2-6B434FF14033@egt.ie> <19A328037921AA42847A717566D1D6A10956C03B@RED-MSG-42.redmond.corp.microsoft.com> Subject: Re: [Ltru] (no subject) Date: Fri, 3 Nov 2006 10:52:21 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6bd39beff2a93c47e7c685e05ae45f875350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.215 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Peter Constable" > To: "Marion Gunn" ; "LTRU Working Group" > Sent: Friday, November 03, 2006 5:19 AM > Subject: RE: [Ltru] (no subject) > > The members of the 15924 JAC do not represent countries but rather > represent ISO-appointed agencies: > > - ISO/IEC JTC1/SC2 > - ISO TC37 > - ISO TC46 > - ISO 639-2/RA > - ISO 15924/RA Thank you for the clarification. (Placing co-chair hat on): Now, can we leave this fascinating (I use the term loosely) and off-topic discussion and get back to the work at hand? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 14:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4JY-0004W4-4c; Fri, 03 Nov 2006 14:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4JW-0004SO-4o for ltru@ietf.org; Fri, 03 Nov 2006 14:02:50 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4JU-0000zo-U7 for ltru@ietf.org; Fri, 03 Nov 2006 14:02:50 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KB5GbEUFq/KflsMCSGhHaZXXkyugKa4UhLUWW9NGlo5Zcolbsdw4UjkTVs88Xj/a; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.215] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gg4JU-0004EE-HS for ltru@ietf.org; Fri, 03 Nov 2006 14:02:48 -0500 Message-ID: <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> Subject: Re: [Ltru] ANSI and ISO 15924 (was: Re: (no subject)) Date: Fri, 3 Nov 2006 11:03:00 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee68c2f5e2b0e460b5546b10195d28da756350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.215 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 - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, November 03, 2006 6:45 AM > Subject: [Ltru] ANSI and ISO 15924 (was: Re: (no subject)) ... > Does ANSI in fact have influence over ISO 15924/RA-JAC? Does any > national body? ... As WG co-chair: Speculation about ISO political problems (real or imagined) is not this WG's job. (I know Doug didn't initiate this; I'm just taking this opportunity to put the discussion back on track.) The question before us here is whether we believe IPA should be registered as a script. Before we get to *that* question, we need to reach consensus on how we'd like to handle transcriptions. We're progressing, but I'm not ready to say we're "there" yet. If the agreement we eventually reach requires registration of one or more scripts, then we can deal with figuring out how to make it happen. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 14:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4z0-0002If-5j; Fri, 03 Nov 2006 14:45:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4yz-0002IZ-Pd for ltru@ietf.org; Fri, 03 Nov 2006 14:45:41 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4yv-00076c-HH for ltru@ietf.org; Fri, 03 Nov 2006 14:45:41 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gg4yu-0004Jj-QQ; Fri, 03 Nov 2006 14:45:36 -0500 Date: Fri, 3 Nov 2006 14:45:36 -0500 To: Randy Presuhn Subject: Re: [Ltru] ANSI and ISO 15924 (was: Re: (no subject)) Message-ID: <20061103194536.GC6220@ccil.org> References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > The question before us here is whether we believe IPA should be > registered as a script. Before we get to *that* question, we > need to reach consensus on how we'd like to handle transcriptions. > We're progressing, but I'm not ready to say we're "there" yet. Here's my rough semantic model for the types of subtags. If a document is in the wrong *language*, you can't read it it all. If a document is in the wrong *script*, you can decipher it with more or less pain, but reading it fluently is too hard. If a document is in the wrong *variant*, you can read it but there will be occasional oddities, incongruities, and possible miscomprehensions; you probably couldn't write this document yourself but would use your own variant. We discriminate between national and other variants for reasons partly historical, partly practical. By this model, IPA, Americanist, UPA, LMA, etc. are functionally scripts, and things like broad vs. narrow transcriptions are functionally variants. > If the agreement we eventually reach requires registration of one > or more scripts, then we can deal with figuring out how to make it > happen. Unless, of course, we cannot make it happen at all. In which case we will need a new agreement. But I agree with you on the proper order of these things. -- 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 Fri Nov 03 16:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg6su-0002SE-Ep; Fri, 03 Nov 2006 16:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg6st-0002S4-72 for ltru@ietf.org; Fri, 03 Nov 2006 16:47:31 -0500 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg6sr-0005KJ-QS for ltru@ietf.org; Fri, 03 Nov 2006 16:47:31 -0500 Received: by nz-out-0102.google.com with SMTP id 13so568636nzn for ; Fri, 03 Nov 2006 13:47:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MtVL2POnS0mS28rsuHMfnBUv1lQiusuhsrqYs1UCnBQuqgVyFytizo7hsVB24TgUBE8I+iqMmxPuyaD4YS9K2BCvRqhmPAjJ1DJgqSOEGakLs30nPhWHpg7khPW6K2f9pVz/ks2l+B/XV3WqzStTMLgG2FvEiQW5eWbr/n5zicI= Received: by 10.64.27.7 with SMTP id a7mr1507716qba.1162590449246; Fri, 03 Nov 2006 13:47:29 -0800 (PST) Received: by 10.65.211.11 with HTTP; Fri, 3 Nov 2006 13:47:28 -0800 (PST) Message-ID: <30b660a20611031347m138e2392y92d8cd15e9e10fea@mail.gmail.com> Date: Fri, 3 Nov 2006 13:47:28 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] ANSI and ISO 15924 (was: Re: (no subject)) In-Reply-To: <20061103194536.GC6220@ccil.org> MIME-Version: 1.0 References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> <20061103194536.GC6220@ccil.org> X-Google-Sender-Auth: fa789d957563f123 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1154019867==" Errors-To: ltru-bounces@ietf.org --===============1154019867== Content-Type: multipart/alternative; boundary="----=_Part_25169_14961273.1162590448976" ------=_Part_25169_14961273.1162590448976 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree also with this analysis. On 11/3/06, John Cowan wrote: > > Randy Presuhn scripsit: > > > The question before us here is whether we believe IPA should be > > registered as a script. Before we get to *that* question, we > > need to reach consensus on how we'd like to handle transcriptions. > > We're progressing, but I'm not ready to say we're "there" yet. > > Here's my rough semantic model for the types of subtags. > > If a document is in the wrong *language*, you can't read it > it all. > > If a document is in the wrong *script*, you can decipher it with > more or less pain, but reading it fluently is too hard. > > If a document is in the wrong *variant*, you can read it but > there will be occasional oddities, incongruities, and possible > miscomprehensions; you probably couldn't write this document > yourself but would use your own variant. > > We discriminate between national and other variants for reasons partly > historical, partly practical. > > By this model, IPA, Americanist, UPA, LMA, etc. are functionally scripts, > and things like broad vs. narrow transcriptions are functionally variants. > > > If the agreement we eventually reach requires registration of one > > or more scripts, then we can deal with figuring out how to make it > > happen. > > Unless, of course, we cannot make it happen at all. In which case > we will need a new agreement. But I agree with you on the proper > order of these things. > > -- > 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 > ------=_Part_25169_14961273.1162590448976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree also with this analysis.

On 11/3/06, John Cowan <cowan@ccil.org> wrote:
Randy Presuhn scripsit:

> The question before us here is whether we believe IPA should be
> registered as a script.  Before we get to *that* question, we
> need to reach consensus on how we'd like to handle transcriptions.
> We're progressing, but I'm not ready to say we're "there" yet.

Here's my rough semantic model for the types of subtags.

        If a document is in the wrong *language*, you can't read it
        it all.

        If a document is in the wrong *script*, you can decipher it with
        more or less pain, but reading it fluently is too hard.

        If a document is in the wrong *variant*, you can read it but
        there will be occasional oddities, incongruities, and possible
        miscomprehensions; you probably couldn't write this document
        yourself but would use your own variant.

We discriminate between national and other variants for reasons partly
historical, partly practical.

By this model, IPA, Americanist, UPA, LMA, etc. are functionally scripts,
and things like broad vs. narrow transcriptions are functionally variants.

> If the agreement we eventually reach requires registration of one
> or more scripts, then we can deal with figuring out how to make it
> happen.

Unless, of course, we cannot make it happen at all.  In which case
we will need a new agreement.  But I agree with you on the proper
order of these things.

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

------=_Part_25169_14961273.1162590448976-- --===============1154019867== 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 --===============1154019867==-- From ltru-bounces@ietf.org Fri Nov 03 17:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg76d-00014j-7h; Fri, 03 Nov 2006 17:01:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg76c-00014e-9m for ltru@ietf.org; Fri, 03 Nov 2006 17:01:42 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg76a-0004Hr-Sr for ltru@ietf.org; Fri, 03 Nov 2006 17:01:42 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id kA3M1Bc6082692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Nov 2006 14:01:11 -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=I6/myR1nAhE3muUxpm4nueCmYFtR/jWJlTLjQxJOTasYF300voeIjSMN6AVBigOv Message-ID: <454BBC27.9070207@yahoo-inc.com> Date: Fri, 03 Nov 2006 14:01:11 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] ANSI and ISO 15924 References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> <20061103194536.GC6220@ccil.org> <30b660a20611031347m138e2392y92d8cd15e9e10fea@mail.gmail.com> In-Reply-To: <30b660a20611031347m138e2392y92d8cd15e9e10fea@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Mark Davis wrote: > I agree also with this analysis. > > On 11/3/06, *John Cowan* > wrote: > > Randy Presuhn scripsit: > > > The question before us here is whether we believe IPA should be > > registered as a script. Before we get to *that* question, we > > need to reach consensus on how we'd like to handle transcriptions. > > We're progressing, but I'm not ready to say we're "there" yet. > > Here's my rough semantic model for the types of subtags. > > If a document is in the wrong *language*, you can't read it > it all. > > If a document is in the wrong *script*, you can decipher it with > more or less pain, but reading it fluently is too hard. > > If a document is in the wrong *variant*, you can read it but > there will be occasional oddities, incongruities, and possible > miscomprehensions; you probably couldn't write this document > yourself but would use your own variant. > > We discriminate between national and other variants for reasons partly > historical, partly practical. > > By this model, IPA, Americanist, UPA, LMA, etc. are functionally > scripts, > and things like broad vs. narrow transcriptions are functionally > variants. > > > If the agreement we eventually reach requires registration of one > > or more scripts, then we can deal with figuring out how to make it > > happen. > > Unless, of course, we cannot make it happen at all. In which case > we will need a new agreement. But I agree with you on the proper > order of these things. > > -- > 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 17:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7zB-0000gY-JW; Fri, 03 Nov 2006 17:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7zA-0000gT-04 for ltru@ietf.org; Fri, 03 Nov 2006 17:58:04 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7z8-0005uB-PZ for ltru@ietf.org; Fri, 03 Nov 2006 17:58:03 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gg7z8-0004mT-1m; Fri, 03 Nov 2006 17:58:02 -0500 Date: Fri, 3 Nov 2006 17:58:02 -0500 To: Addison Phillips Subject: Re: [Ltru] ANSI and ISO 15924 Message-ID: <20061103225801.GE6220@ccil.org> References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> <20061103194536.GC6220@ccil.org> <30b660a20611031347m138e2392y92d8cd15e9e10fea@mail.gmail.com> <454BBC27.9070207@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454BBC27.9070207@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > > Here's my rough semantic model for the types of subtags. Maybe this text (improved a bit) should go somewhere in 4646bis? -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 03 18:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8Em-0001qU-U5; Fri, 03 Nov 2006 18:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8Em-0001qP-34 for ltru@ietf.org; Fri, 03 Nov 2006 18:14:12 -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 1Gg8Eg-0000ai-RA for ltru@ietf.org; Fri, 03 Nov 2006 18:14:12 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005445362.msg for ; Fri, 03 Nov 2006 23:16:41 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 03 Nov 2006 23:14:17 +0000 From: "Debbie Garside" To: , "'Addison Phillips'" Subject: RE: [Ltru] ANSI and ISO 15924 Date: Fri, 3 Nov 2006 23:13:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 In-Reply-To: <20061103225801.GE6220@ccil.org> Thread-Index: Acb/m8I2iu3Fpoz3Sb6Rase9opEuPQAAZZSw Message-ID: <79D6CC82F26940DC9EF05DEFC9963C56.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Fri, 03 Nov 2006 23:16:41 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 03 Nov 2006 23:16:42 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: > > Maybe this text (improved a bit) should go somewhere in 4646bis? I think that is a very good idea. I think it explains clearly the reasons for tagging content wisely. Best regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 04 00:36:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgECl-00052o-GG; Sat, 04 Nov 2006 00:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgECk-00052j-7i for ltru@lists.ietf.org; Sat, 04 Nov 2006 00:36:30 -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 1GgECi-0008Ad-Uo for ltru@lists.ietf.org; Sat, 04 Nov 2006 00:36:30 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GgECY-0007SI-6B for ltru@lists.ietf.org; Sat, 04 Nov 2006 06:36:18 +0100 Received: from pd9fbacf2.dip0.t-ipconnect.de ([217.251.172.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Nov 2006 06:36:18 +0100 Received: from nobody by pd9fbacf2.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Nov 2006 06:36:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 04 Nov 2006 06:34:11 +0100 Organization: Lines: 13 Message-ID: <454C2653.F12@xyzzy.claranet.de> References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81> <001f01c6ff7a$aef01360$6601a8c0@oemcomputer> <20061103194536.GC6220@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacf2.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: ANSI and ISO 15924 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > If a document is in the wrong *language*, you can't read it it all. > If a document is in the wrong *script*, you can decipher it with > more or less pain, but reading it fluently is too hard. Depends. For some languages I can more or less guess what it might be about, IFF they're Latn (or maybe Latf). For most scripts I'm lost, no matter what language. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 04 01:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEzd-0003w2-OE; Sat, 04 Nov 2006 01:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgEzb-0003vp-Ki for ltru@lists.ietf.org; Sat, 04 Nov 2006 01:26:59 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgEzX-0002AL-95 for ltru@lists.ietf.org; Sat, 04 Nov 2006 01:26:59 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Fri, 3 Nov 2006 22:26:54 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 22:26:54 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: ANSI and ISO 15924 Date: Fri, 3 Nov 2006 22:26:14 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <454C2653.F12@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: ANSI and ISO 15924 Thread-Index: Acb/00OXm19tMLSEQQWVWPF6NnhFZQAAtcpQ References: <006001c6ff56$bfbd91a0$6501a8c0@DGBP7M81><001f01c6ff7a$aef01360$6601a8c0@oemcomputer><20061103194536.GC6220@ccil.org> <454C2653.F12@xyzzy.claranet.de> From: Peter Constable To: X-OriginalArrivalTime: 04 Nov 2006 06:26:54.0267 (UTC) FILETIME=[388288B0:01C6FFDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Like Frank, John's statement wrt script seems flawed to me.=20 E.g., a Central Thai speaker would understand some of a Northern Thai text if it were written in Thai script but would not be able to make much sense of a Northern Thai text (or even a Central Thai text) if it were written in Lanna script. Granted, in this case, it would take less time to learn the other script than to learn the other language, but someone requesting content isn't typically doing so because they want to engage in a language-learning or script-learning exercise. E.g., consider this text: "In nujutsi na bitsiimal." You *can* read it, though you probably have no idea what it says and aren't sure if you are pronouncing it correctly. Or consider: "Il benti iyo xabayo" -- some of you might get a hunch at the meaning even thought it's not a "right" language for any of you (it's a hypothetical creation). In contrast, if you were to show most English speakers an English text in some shorthand, they wouldn't even know it was English.=20 If it's in the wrong language but the right script, your experience may range from it being somewhat understandable to effectively not readable at all, depending on *how* wrong the language is. If it's in the wrong script but the right language, your experience may range from it looking familiar and being decipherable with some scrutiny to being completely unrecognizable, depending on *how* wrong the script is. Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 Sent: Saturday, November 04, 2006 12:34 AM To: ltru@lists.ietf.org Subject: [Ltru] Re: ANSI and ISO 15924 John Cowan wrote: > If a document is in the wrong *language*, you can't read it it all. > If a document is in the wrong *script*, you can decipher it with > more or less pain, but reading it fluently is too hard. Depends. For some languages I can more or less guess what it might be about, IFF they're Latn (or maybe Latf). For most scripts I'm lost, no matter what language. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 04 10:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgNIw-0003mq-Td; Sat, 04 Nov 2006 10:19:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgNIu-0003iP-S9 for ltru@lists.ietf.org; Sat, 04 Nov 2006 10:19:28 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgNIs-0002MG-I2 for ltru@lists.ietf.org; Sat, 04 Nov 2006 10:19:28 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GgNIo-0000U7-1B; Sat, 04 Nov 2006 10:19:22 -0500 Date: Sat, 4 Nov 2006 10:19:22 -0500 To: Peter Constable Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061104151921.GI4884@ccil.org> References: <454C2653.F12@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: > E.g., a Central Thai speaker would understand some of a Northern Thai > text if it were written in Thai script Granted. Similarly, I can make something out of _Time_ magazine written in French (I was forced to attempt this once for lack of English-language reading matter), because there is some lexical similarity, especially in technical words, and I know what the current issues of the day are, whereas simpler French texts defeat me. (It seems to me that English, or the English/Scots pair, are exceptionally isolated as languages go; the nearest relatives have effectively zero cross-comprehension, and even the similarity to French is apparent only in writing and depends deeply on the subject matter.) Nevertheless, given two languages picked at random, the degree of mutual intelligibility will be zero. > but would not be able to make much sense of a Northern Thai text > (or even a Central Thai text) if it were written in Lanna script. When I said "decipher", I meant it literally: with the help of a cipher table mapping one to the other. In some truly multiscript languages like Mongolian, no such table is possible, admitted, and I could not read or even decipher English in Arabic script, because I can't tell when one letter stops and another begins -- it's all wiggle to me. Nevertheless, the effort to read en-kata, for example, would be hugely less, despite the inadequacy of the representation, than the effort to read Japanese itself. > E.g., consider this text: "In nujutsi na bitsiimal." You *can* read it, That's an equivoque on "read". When I use "read", I am referring to the primary sense, "to look at or otherwise scan (as letters or other symbols representing words or sentences) with mental formulation of the words or sentences represented" (NID3). Here there is no mental formulation: I don't know if this is "How now, brown cow!" or "In the beginning was the Word." (Two Google hits for "nujutsi", one in Greenlandic, another in German, evidently a parodic proper name; none at all for "bitsiimal".) > In contrast, if you were to show most English speakers an English text > in some shorthand, they wouldn't even know it was English. But with a table, they could decipher it (more easily than Arabic, though less easily than Greek or Cyrillic). > If it's in the wrong language but the right script, your experience may > range from it being somewhat understandable to effectively not readable > at all, depending on *how* wrong the language is. > > If it's in the wrong script but the right language, your experience may > range from it looking familiar and being decipherable with some scrutiny > to being completely unrecognizable, depending on *how* wrong the script > is. Agreed to both, but I don't think this constitutes a counter to my original rough model. -- Even the best of friends cannot John Cowan attend each others' funeral. cowan@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 05 05:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggf7J-0006gx-He; Sun, 05 Nov 2006 05:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggf7I-0006gs-Jk for ltru@ietf.org; Sun, 05 Nov 2006 05:20:40 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggf7E-0007KL-NX for ltru@ietf.org; Sun, 05 Nov 2006 05:20:40 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kA5AKMfx014228 for ; Sun, 5 Nov 2006 19:20:22 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 65e8_3ed915fe_6cb7_11db_9c89_0014221f2a2d; Sun, 05 Nov 2006 19:20:22 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43320) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 5 Nov 2006 19:19:55 +0900 Message-Id: <6.0.0.20.2.20061103212242.04e12060@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Nov 2006 21:30:22 +0900 To: "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Factual correction In-Reply-To: <6.0.0.20.2.20061103135059.04e0ab70@localhost> References: <6.0.0.20.2.20061103135059.04e0ab70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat on] As a co-chair, I have added a note on http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ with a pointer to the archived form of the mail below (issue 57). If anybody thinks that they would have made a different decision without this confusion, please speak up. Regards, Martin. At 18:06 06/11/03, Martin Duerst wrote: >[co-chair hat off] > >It has come to my attention that in my long mail addressing the points >in JFC Morfin's IETF Last Call comments on our matching draft (archived >at http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html), >there was a factual incorrectness. > >In the paragraph that read: > > The commenter seems to claim that draft-ietf-ltru-matching conflicts with > draft-ietf-ltru-registry (here called RFC 3066bis) because the later > defines well-formed tags while the former does not require well-formed > tags. The reason for not requiring checking for well-formed tags when > matching was discussed extensively in the WG. There is a very clear reason: > requiring this would require to check the IANA language subtag registry, > potentially for every matching operation, which was considered operationally > infeasible. It would also be an unnecessary performance punishment for > those who actually use well-formed tags. In general, non-wellformed > tags or ranges will simply not match anything, which is just fine. > >the sentence that said: > > There is a very clear reason: requiring this would require to check the > IANA language subtag registry, potentially for every matching operation, > which was considered operationally infeasible. > >was factually wrong. Well-formedness checking does not need online access >to the registry, only one-time access when the checking software is built >to get the list of grandfathered tags. Strictly speaking, not even validation >does require online access to the registry, because validation can be done >with respect to a specific registry date. > >The rest of the paragraph, in particular the following three >sentences, are unaffected by this. > > The reason for not requiring checking for well-formed tags when > matching was discussed extensively in the WG. > It would also be an unnecessary performance punishment for > those who actually use well-formed tags. In general, non-wellformed > tags or ranges will simply not match anything, which is just fine. > >I would like to appologize for any confusion this may have created. >I personally do not think there was anything unclear in the draft >(now an RFC), or anything that the WG would have done differently. >My guess is also that this problem would have been spotted very quickly >by quite some WG participants if it hadn't been burried in the middle >of a very long mail answering another very long mail. > >Regards, Martin. > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 02:48:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzDI-0005H9-Ld; Mon, 06 Nov 2006 02:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzDH-0005H0-QT for ltru@lists.ietf.org; Mon, 06 Nov 2006 02:48:11 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzDD-0007C7-V3 for ltru@lists.ietf.org; Mon, 06 Nov 2006 02:48:11 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kA67m6gI012795 for ; Mon, 6 Nov 2006 16:48:06 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6679_23b06ac0_6d6b_11db_96b5_0014221f2a2d; Mon, 06 Nov 2006 16:48:05 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:42813) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 6 Nov 2006 16:47:39 +0900 Message-Id: <6.0.0.20.2.20061106163605.0a095ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 06 Nov 2006 16:47:53 +0900 To: John Cowan , Peter Constable From: Martin Duerst Subject: Re: [Ltru] Re: ANSI and ISO 15924 In-Reply-To: <20061104151921.GI4884@ccil.org> References: <454C2653.F12@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> <20061104151921.GI4884@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 At 00:19 06/11/05, John Cowan wrote: >Peter Constable scripsit: >> but would not be able to make much sense of a Northern Thai text >> (or even a Central Thai text) if it were written in Lanna script. > >When I said "decipher", I meant it literally: with the help of a cipher >table mapping one to the other. In some truly multiscript languages like >Mongolian, no such table is possible, admitted, Why? Is it because you would need multiple tables, e.g. one for reading Mongolian-script Mongolian based on knowledge of Cyrillic, one for reading Mongolian-script Mongolian based on knowledge of Latin, one for reading Latin Mongolian based on the knowledge of the Mongolian script, and so on? A slight complication, but not something that breaks your model, in my opinion. >and I could not read or >even decipher English in Arabic script, because I can't tell when one >letter stops and another begins -- it's all wiggle to me. The effort for reading Arabic script isn't really much bigger than for a non-cursive script. Any script whatever at first is wiggles, or circles, or squares, or whatever, at a first look. For Arabic, if there are no vowels, that might make it a bit more difficult. >Nevertheless, >the effort to read en-kata, for example, would be hugely less, despite the >inadequacy of the representation, than the effort to read Japanese itself. Japanese and Chinese in and by itself of course need much more knowledge for reading than just the knowledge of the language and a simple script table, but your model seems to almost avoid this case because it looks at languages you know written with a script you don't know, and languages you don't know with a script you know. >> In contrast, if you were to show most English speakers an English text >> in some shorthand, they wouldn't even know it was English. > >But with a table, they could decipher it (more easily than Arabic, >though less easily than Greek or Cyrillic). I doubt shorthand would be easier than Arabic. Shorthand comes with many shorthands, and is very wiggly, too. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 03:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzUP-0005VE-Hv; Mon, 06 Nov 2006 03:05:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzUO-0005Sj-ON for ltru@ietf.org; Mon, 06 Nov 2006 03:05:52 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzUM-0001HS-S0 for ltru@ietf.org; Mon, 06 Nov 2006 03:05:52 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20061106075449.RDNO22435.mta15.adelphia.net@DGBP7M81> for ; Mon, 6 Nov 2006 02:54:49 -0500 Message-ID: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 6 Nov 2006 00:05:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Re: ANSI and ISO 15924 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > The question before us here is whether we believe IPA should be > registered as a script. "Registered as a script" could be interpreted in two different ways: 1. "registered in ISO 15924," which would result in no work at all for LTRU, as the 15924 code element would be automatically included in the Registry. 2. "registered by ietf-languages as a script subtag," which is impossible under the current RFC 4646 rules. 3. "registered by ietf-languages as a variant or extension," which is currently the only possible alternative. > Before we get to *that* question, we need to reach consensus on how > we'd like to handle transcriptions. We're progressing, but I'm not > ready to say we're "there" yet. If the agreement we eventually reach > requires registration of one or more scripts, then we can deal with > figuring out how to make it happen. If someone pushes ISO 15924/RA-JAC to register a code element for IPA, then mark me, someone else will want one for UPA and one for LMA and so forth, and there will be a chaotic and haphazard approach to the whole genre of phonetic transcription schemes that could have been avoided. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 03:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzW7-0005k8-0l; Mon, 06 Nov 2006 03:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzW6-0005k2-3Z for ltru@ietf.org; Mon, 06 Nov 2006 03:07:38 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzW4-0001Vg-CT for ltru@ietf.org; Mon, 06 Nov 2006 03:07:38 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061106080735.WLKT9037.mta13.adelphia.net@DGBP7M81> for ; Mon, 6 Nov 2006 03:07:35 -0500 Message-ID: <003e01c7017a$9f4cb1f0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 6 Nov 2006 00:07:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Of course you're right here. What I was thinking of was that we could > draft text in 4646bis that effectively defined a subtag as something > proprietary to the LST registry rather than derived from a source > standard -- which means the process you describe. Dissolving the relationship between script subtags and ISO 15924, and allowing ietf-languages to allocate its own alpha-4 script subtags outside the private-use zone set aside by 15924, simply because there is dissatisfaction over the non-allocation of a code element for IPA, should not by any stretch of the imagination be considered an option. I hope this is not what Peter was suggesting, and I merely misunderstood him. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 06:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2Kp-0000fg-OL; Mon, 06 Nov 2006 06:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2Ko-0000fQ-Fr for ltru@ietf.org; Mon, 06 Nov 2006 06:08:10 -0500 Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gh2Kj-0001FO-HF for ltru@ietf.org; Mon, 06 Nov 2006 06:08:10 -0500 Received: (qmail 40424 messnum 4218352 invoked from network[194.125.174.50/ts09-050.dublin.indigo.ie]); 6 Nov 2006 11:08:03 -0000 Received: from ts09-050.dublin.indigo.ie (HELO ?194.125.174.50?) (194.125.174.50) by mail13.svc.cra.dublin.eircom.net (qp 40424) with SMTP; 6 Nov 2006 11:08:03 -0000 In-Reply-To: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: ANSI and ISO 15924 Date: Mon, 6 Nov 2006 11:11:45 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My immediate preference is (1) below, Doug, because that immediately =20 unties the hands of Irish users put into this bind by the recent =20 negative decision taken by ISO 15924 AC. I repeat that all people =20 from Ireland are asking that AC for is to register IPA to complete =20 the set of scripts we need for our own use, without prejudice to any =20 other script applications ISO 15924 AC may wish to consider after =20 that. If what you suggest under (3) below is a cut-price offer, as it =20= were, a really good (high-functionality) workaround with a quick =20 turnaround, I'll accept that as a temporary measure to easy the =20 pressing problem for my own people (as well as many others). In all sincerity, mg On 6 Nov 2006, at 08:05, scr=EDobh Doug Ewell: > "Registered as a script" could be interpreted in two different ways: > > 1. "registered in ISO 15924," which would result in no work at all =20= > for LTRU, as the 15924 code element would be automatically included =20= > in the Registry. > > 2. "registered by ietf-languages as a script subtag," which is =20 > impossible under the current RFC 4646 rules. > > 3. "registered by ietf-languages as a variant or extension," which =20= > is currently the only possible alternative... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 08:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh4xj-0003gv-Ci; Mon, 06 Nov 2006 08:56:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh4xi-0003gn-3q for ltru@ietf.org; Mon, 06 Nov 2006 08:56:30 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh4xd-0003Tb-Vt for ltru@ietf.org; Mon, 06 Nov 2006 08:56:30 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gh4xd-0002rf-FG; Mon, 06 Nov 2006 08:56:25 -0500 Date: Mon, 6 Nov 2006 08:56:25 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061106135625.GP4884@ccil.org> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > If someone pushes ISO 15924/RA-JAC to register a code element for IPA, > then mark me, someone else will want one for UPA and one for LMA and so > forth, and there will be a chaotic and haphazard approach to the whole > genre of phonetic transcription schemes that could have been avoided. I'm not sure I understand how that would be chaotic and haphazard. I spent some time on a posting explaining how treating these radically different phonetic-transcription methods would be principled and reasonable. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 10:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh60H-0004xW-Gc; Mon, 06 Nov 2006 10:03:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh60G-0004xD-Ab for ltru@lists.ietf.org; Mon, 06 Nov 2006 10:03:12 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh60C-0004Wt-1U for ltru@lists.ietf.org; Mon, 06 Nov 2006 10:03:12 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gh608-0005O7-Qk; Mon, 06 Nov 2006 10:03:04 -0500 Date: Mon, 6 Nov 2006 10:03:04 -0500 To: Martin Duerst Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061106150304.GQ4884@ccil.org> References: <454C2653.F12@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> <20061104151921.GI4884@ccil.org> <6.0.0.20.2.20061106163605.0a095ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061106163605.0a095ec0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Is it because you would need multiple tables, e.g. one for > reading Mongolian-script Mongolian based on knowledge of Cyrillic, > one for reading Mongolian-script Mongolian based on knowledge of > Latin, one for reading Latin Mongolian based on the knowledge > of the Mongolian script, and so on? No, but because the scripts are not even close to transliterations. Mongolian script represents the phonology of 13th-century Mongolian language, but with the loss of several crucial distinctions in both vowels and consonants. Phagspha script (now obsolete) also represents 13th-century Mongolian, but more accurately. Latin (1931-37) and Cyrillic, OTOH, represent 20th-century Mongolian. The distinction is akin to, but more drastic than, the difference between English orthography (which represents 15th-century English) and a phonemic transcription of English in IPA. Learning to read mn-Mong when you know mn-Cyrl really is like learning to read all over again, not merely learning to associate new symbols with familiar sound patterns. Learning to write it is even harder. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. cowan@ccil.org --Isaac Asimov in Earth: Our Crowded Spaceship _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 11:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7J4-0001EJ-OV; Mon, 06 Nov 2006 11:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7J3-0001EE-TE for ltru@ietf.org; Mon, 06 Nov 2006 11:26:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7Iw-0007rV-DW for ltru@ietf.org; Mon, 06 Nov 2006 11:26:41 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6GQSIY025644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 08:26:29 -0800 Received: from [130.129.66.113] (vpn-10-50-0-26.qualcomm.com [10.50.0.26]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6GQPGu026638; Mon, 6 Nov 2006 08:26:26 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie> Date: Mon, 6 Nov 2006 08:26:25 -0800 To: Marion Gunn , LTRU Working Group From: Ted Hardie Subject: Re: [Ltru] Re: ANSI and ISO 15924 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ithilien.qualcomm.com id kA6GQSIY025644 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Two notes:=20 First, my reading of Doug's message does not seem to have possible actions for LTRU at this time, and the IETF-related list which might be appropriate for follow-up discussion appears to be ietf-languages. If the= re is a topic appropriate for LTRU here, a much stronger focus on the actio= ns LTRU would take needs to be made. Second, the IETF works by individual technical commentary, and contributo= rs are understood to speak for themselves. They can be informed, of course,= by their understanding of the needs of the world, but the message "as a technical contributor, I believe X is a reasonable short term worka= round for problem Y, but I think we need long term work of form Z" stands on its own. As noted in point one, we also have to be clear we're talking t= o the right lists of folks for both X and Z. regards, Ted Hardie At 11:11 AM +0000 11/6/06, Marion Gunn wrote: >My immediate preference is (1) below, Doug, because that immediately unt= ies the hands of Irish users put into this bind by the recent negative de= cision taken by ISO 15924 AC. I repeat that all people from Ireland are a= sking that AC for is to register IPA to complete the set of scripts we ne= ed for our own use, without prejudice to any other script applications IS= O 15924 AC may wish to consider after that. If what you suggest under (3)= below is a cut-price offer, as it were, a really good (high-functionalit= y) workaround with a quick turnaround, I'll accept that as a temporary me= asure to easy the pressing problem for my own people (as well as many oth= ers). > >In all sincerity, >mg > >On 6 Nov 2006, at 08:05, scr=EDobh Doug Ewell: > >>"Registered as a script" could be interpreted in two different ways: >> >>1. "registered in ISO 15924," which would result in no work at all for= LTRU, as the 15924 code element would be automatically included in the R= egistry. >> >>2. "registered by ietf-languages as a script subtag," which is impossi= ble under the current RFC 4646 rules. >> >>3. "registered by ietf-languages as a variant or extension," which is = currently the only possible alternative... > >- - >Marion Gunn * EGTeo (Estab.1991) >27 P=E1irc an Fh=E9ithlinn, Baile an >Bh=F3thair, Co. =C1tha Cliath, =C9ire. >* mgunn@egt.ie * eamonn@egt.ie * > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 11:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7gY-0000v0-Pv; Mon, 06 Nov 2006 11:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7gW-0000uq-Uc for ltru@ietf.org; Mon, 06 Nov 2006 11:50:56 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7gQ-0002Bs-VS for ltru@ietf.org; Mon, 06 Nov 2006 11:50:56 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gh7gQ-0000xq-Lk; Mon, 06 Nov 2006 11:50:50 -0500 Date: Mon, 6 Nov 2006 11:50:50 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061106165050.GV4884@ccil.org> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <20061106135625.GP4884@ccil.org> <001501c701b9$af4d3a40$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c701b9$af4d3a40$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > This model does, then, still call for separate script-level tagging for > IPA, Americanist, UPA, and so forth. My point was, will it be possible > to manage this potentially burgeoning set of subtags in a sensible way, > instead of looking as though they were registered at N different times > by N different groups with N different philosophies? Yes indeed, and probably not, respectively. But I do not see why it *matters* that the list of major phonetic-transcription conventions is chaotic. The list of scripts is itself chaotic, inevitably drawing lines in the shifting sand of varying conventions for writing. That's why ISO 15924 has a Registration *Authority*, a group which can make those decisions, even if it must do so somewhat arbitrarily on occasion. Are Yiddish and Hebrew separate scripts? No, though one is an alphabet and the other an abjad. Are Antiqua and Fraktur separate? They are subscripts of Latin. Are the three flavors of Syriac separate? Same answer, except that no one is dominant. Are katakana and hiragana separate? Definitely, though they can be mapped one-for-one. Are Latin upper and lower case separate, then? Definitely not, though there were periods when one used either one or the other depending on the nature of the writing. In short, let the users of the major transcription conventions make their cases clearly. Either they sell the RA/JAC on it, or they don't. > For example: When ietf-languages registered variants (*) for the German > orthographic variants, the subtags were "1901" and "1996". There was > originally a proposal to register abbreviation of the word "traditional" > instead of "1901", but a sound (IMHO) choice was made to keep the two > more or less parallel. "Traditional" would probably be more useful for the pre-1901 non-standardized set of conventions. -- 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 Nov 06 11:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7gm-0000zb-W4; Mon, 06 Nov 2006 11:51:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7gl-0000zP-5I for ltru@ietf.org; Mon, 06 Nov 2006 11:51:11 -0500 Received: from mta8.adelphia.net ([68.168.78.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7gh-0002FG-RM for ltru@ietf.org; Mon, 06 Nov 2006 11:51:11 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061106153901.VDXX9037.mta13.adelphia.net@DGBP7M81>; Mon, 6 Nov 2006 10:39:01 -0500 Message-ID: <001501c701b9$af4d3a40$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <20061106135625.GP4884@ccil.org> Subject: Re: [Ltru] Re: ANSI and ISO 15924 Date: Mon, 6 Nov 2006 07:39:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: >> If someone pushes ISO 15924/RA-JAC to register a code element for >> IPA, then mark me, someone else will want one for UPA and one for LMA >> and so forth, and there will be a chaotic and haphazard approach to >> the whole genre of phonetic transcription schemes that could have >> been avoided. > > I'm not sure I understand how that would be chaotic and haphazard. I > spent some time on a posting explaining how treating these radically > different phonetic-transcription methods would be principled and > reasonable. If John is referring to his "rough semantic model" post on Friday, I should point out that I agree rather strongly with that model. There are some minor snags, of the type Peter mentioned (e.g. I could read pt-Latn much more easily than en-Yiii although I make no claim to "knowing" Portuguese), but by and large the model is good. John had written: > By this model, IPA, Americanist, UPA, LMA, etc. are functionally > scripts, and things like broad vs. narrow transcriptions are > functionally variants. This model does, then, still call for separate script-level tagging for IPA, Americanist, UPA, and so forth. My point was, will it be possible to manage this potentially burgeoning set of subtags in a sensible way, instead of looking as though they were registered at N different times by N different groups with N different philosophies? For example: When ietf-languages registered variants (*) for the German orthographic variants, the subtags were "1901" and "1996". There was originally a proposal to register abbreviation of the word "traditional" instead of "1901", but a sound (IMHO) choice was made to keep the two more or less parallel. (*) Of course, at the time ietf-languages registered whole tags, not subtags, but the analogy is clear here. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 11:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7kd-0004DO-IG; Mon, 06 Nov 2006 11:55:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7kc-0004DJ-Nb for ltru@ietf.org; Mon, 06 Nov 2006 11:55:10 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7ka-0002l4-GD for ltru@ietf.org; Mon, 06 Nov 2006 11:55:10 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gh7kZ-00018A-Kh; Mon, 06 Nov 2006 11:55:07 -0500 Date: Mon, 6 Nov 2006 11:55:07 -0500 To: Ted Hardie Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061106165507.GW4884@ccil.org> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ted Hardie scripsit: > First, my reading of Doug's message does not seem to have possible > actions for LTRU at this time, and the IETF-related list which might be > appropriate for follow-up discussion appears to be ietf-languages. If > there is a topic appropriate for LTRU here, a much stronger focus on > the actions LTRU would take needs to be made. What we are discussing here is whether (1) we need a novel mechanism for tagging phonetic transcriptions, or whether (2) the existing mechanisms can be made to work by (a) expanding our rules slightly or (b) using the existing rules exactly and getting new subtags added. Only in case 2b is this a matter for ietf-languages alone. An example of 1 would be introducing a -t- extension. An example of 2a would be introducing a class of script tags that are not ISO 15924, such as "ipa0". -- John Cowan http://ccil.org/~cowan Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users have embraced efficiency but because markets are the best place to allow users to maximize their preferences, and very often their preferences are not for conservation of cheap resources. --Clay Shirkey _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 06 12:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8SF-0007fM-8y; Mon, 06 Nov 2006 12:40:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8SE-0007ep-6r for ltru@ietf.org; Mon, 06 Nov 2006 12:40:14 -0500 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gh8S9-0000MY-7C for ltru@ietf.org; Mon, 06 Nov 2006 12:40:14 -0500 Received: (qmail 84614 messnum 5077490 invoked from network[194.125.174.78/ts09-078.dublin.indigo.ie]); 6 Nov 2006 17:40:05 -0000 Received: from ts09-078.dublin.indigo.ie (HELO ?194.125.174.78?) (194.125.174.78) by mail17.svc.cra.dublin.eircom.net (qp 84614) with SMTP; 6 Nov 2006 17:40:05 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20061106165507.GW4884@ccil.org> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie> <20061106165507.GW4884@ccil.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: ANSI and ISO 15924 Date: Mon, 6 Nov 2006 17:43:46 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) 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 True, so the best way forward is for all groups concerned to keep one =20= another informed (to that end, please, anyone who feels some of my =20 postings on this topic belong more properly to IETF and/or related =20 lists, feel free to forward them there). With best wishes, mg On 6 Nov 2006, at 16:55, scr=EDobh John Cowan: > ... > What we are discussing here is whether (1) we need a novel =20 > mechanism for > tagging phonetic transcriptions, or whether (2) the existing =20 > mechanisms > can be made to work by (a) expanding our rules slightly or (b) > using the existing rules exactly and getting new subtags added. > Only in case 2b is this a matter for ietf-languages alone. > > An example of 1 would be introducing a -t- extension. An example of > 2a would be introducing a class of script tags that are not ISO 15924, > such as "ipa0". - - 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 Nov 07 01:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKR8-0002Ie-4g; Tue, 07 Nov 2006 01:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKR6-0002IT-T0 for ltru@ietf.org; Tue, 07 Nov 2006 01:27:52 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKR1-0001uX-Ft for ltru@ietf.org; Tue, 07 Nov 2006 01:27:52 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Mon, 6 Nov 2006 22:27:46 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 22:26:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI and ISO 15924 Date: Mon, 6 Nov 2006 22:25:23 -0800 Message-ID: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI and ISO 15924 Thread-Index: AccByqcd1Yp9tkJYTs+feNTZCM9NFgAHImng References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81><5E1D3587-2768-4A1B-A8CE-713E90AA4AA3@egt.ie><20061106165507.GW4884@ccil.org> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 07 Nov 2006 06:26:00.0886 (UTC) FILETIME=[97EE7D60:01C70235] 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 If I have understood John Cowan correctly, he proposes script subtags for each different system of phonetic transcription. I suspect that we would have a very difficult time selling that to the ISO 15924 RA, and for that reason have suggested we ask them for one script(-variant) ID, Latp, for Latin-based phonetic transcription, and that we use variants or an extension to differentiate between specific systems. If, however, the ISO 15924 RA would accept separate IDs for different systems of phonetic transcription, then I'd be open to consider that.=20 If people here think that an option using one or more 15924 IDs is what we'd prefer to see, then we should get a request in and start lobbying with the RA. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 07 01:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKW6-0007MU-RV; Tue, 07 Nov 2006 01:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKW4-0007M5-GB for ltru@ietf.org; Tue, 07 Nov 2006 01:33:00 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKW3-0002TB-5o for ltru@ietf.org; Tue, 07 Nov 2006 01:33:00 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061107063253.LWJH1470.mta11.adelphia.net@DGBP7M81>; Tue, 7 Nov 2006 01:32:53 -0500 Message-ID: <003301c70236$8ebe6380$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <20061106135625.GP4884@ccil.org> <001501c701b9$af4d3a40$6501a8c0@DGBP7M81> <20061106165050.GV4884@ccil.org> Subject: Re: [Ltru] Re: ANSI and ISO 15924 Date: Mon, 6 Nov 2006 22:32:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > ... But I do not see why it *matters* that the list of major > phonetic-transcription conventions is chaotic. The list of scripts is > itself chaotic, inevitably drawing lines in the shifting sand of > varying conventions for writing. That's why ISO 15924 has a > Registration *Authority*, a group which can make those decisions, even > if it must do so somewhat arbitrarily on occasion. I can't disagree that scripts change over time, as does the definition of what is and isn't a script. Scripts, like countries, can't be 100% stable over a long-enough period of time. Where I'd like to see order and stability is in the mechanism we use to tag them -- just as we have with countries. It would be suboptimal, to say the least, if we decided to use a script subtag to indicate one phonetic transcription models, a variant subtag to indicate another, and no mechanism at all to indicate a third, simply because we could not agree on which mechanism to use and our ability to plan a cohesive solution was outstripped by our haste to establish them one-by-one. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 07 01:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKZJ-00005x-Uc; Tue, 07 Nov 2006 01:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKZI-00005k-Au for ltru@ietf.org; Tue, 07 Nov 2006 01:36:20 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKZG-0002nL-W4 for ltru@ietf.org; Tue, 07 Nov 2006 01:36:20 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061107063614.QNTV9037.mta13.adelphia.net@DGBP7M81> for ; Tue, 7 Nov 2006 01:36:14 -0500 Message-ID: <003f01c70237$06535590$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 6 Nov 2006 22:36:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: ANSI and ISO 15924 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > What we are discussing here is whether (1) we need a novel mechanism > for tagging phonetic transcriptions, or whether (2) the existing > mechanisms can be made to work by (a) expanding our rules slightly or > (b) using the existing rules exactly and getting new subtags added. > Only in case 2b is this a matter for ietf-languages alone. > > An example of 1 would be introducing a -t- extension. An example of > 2a would be introducing a class of script tags that are not ISO 15924, > such as "ipa0". Once again, John has figured out how to say exactly what I would have said if I were anywhere near that eloquent. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 07 02:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLJI-0002rn-Br; Tue, 07 Nov 2006 02:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLJF-0002rR-9q for ltru@lists.ietf.org; Tue, 07 Nov 2006 02:23:49 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhLJB-0007yL-88 for ltru@lists.ietf.org; Tue, 07 Nov 2006 02:23:49 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kA77Nd4h018403 for ; Tue, 7 Nov 2006 16:23:42 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2414_e3c820b2_6e30_11db_90db_0014221fa3c9; Tue, 07 Nov 2006 16:23:39 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:38761) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 7 Nov 2006 16:23:11 +0900 Message-Id: <6.0.0.20.2.20061107162017.023d7ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 07 Nov 2006 16:23:28 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Re: ANSI and ISO 15924 In-Reply-To: <20061106150304.GQ4884@ccil.org> References: <454C2653.F12@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10956CA5C@RED-MSG-42.redmond.corp.microsoft.com> <20061104151921.GI4884@ccil.org> <6.0.0.20.2.20061106163605.0a095ec0@localhost> <20061106150304.GQ4884@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 At 00:03 06/11/07, John Cowan wrote: >No, but because the scripts are not even close to transliterations. >Mongolian script represents the phonology of 13th-century Mongolian >language, but with the loss of several crucial distinctions in both >vowels and consonants. Phagspha script (now obsolete) also represents >13th-century Mongolian, but more accurately. Latin (1931-37) and >Cyrillic, OTOH, represent 20th-century Mongolian. So this has nothing to do with the fact that Mongolian can conventionally be written with multiple scripts, but just applies to mn-Mong, and is just an example of the general fact that the less an orthography (language+script+convention) is phonemic, the more difficult it is to get used to it. Chinese, and even more Japanese, as I have mentioned before, would be more extreme examples. 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 Nov 07 10:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTLP-00060f-6t; Tue, 07 Nov 2006 10:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTLN-00060B-Ll for ltru@ietf.org; Tue, 07 Nov 2006 10:58:33 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTLI-0000Ie-6h for ltru@ietf.org; Tue, 07 Nov 2006 10:58:29 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GhTLH-0007cd-IP; Tue, 07 Nov 2006 10:58:27 -0500 Date: Tue, 7 Nov 2006 10:58:27 -0500 To: Peter Constable Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061107155827.GF4884@ccil.org> References: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > If I have understood John Cowan correctly, he proposes script subtags > for each different system of phonetic transcription. I suspect that we > would have a very difficult time selling that to the ISO 15924 RA, and > for that reason have suggested we ask them for one script(-variant) ID, > Latp, for Latin-based phonetic transcription, and that we use variants > or an extension to differentiate between specific systems. "Make no little plans; they have no power to fire men's blood." I'd rather ask for IPA first to establish the precedent that different phonetic systems deserve different script subtags, and then add the others as needed. But that's a tactical issue; we are in substantial agreement, I think. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 07 10:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTLY-00066P-Gd; Tue, 07 Nov 2006 10:58:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTLX-00065V-Cx for ltru@ietf.org; Tue, 07 Nov 2006 10:58:43 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTIZ-0008M3-Ue for ltru@ietf.org; Tue, 07 Nov 2006 10:55:42 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GhTIQ-0007Y0-VT; Tue, 07 Nov 2006 10:55:30 -0500 Date: Tue, 7 Nov 2006 10:55:30 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: ANSI and ISO 15924 Message-ID: <20061107155530.GE4884@ccil.org> References: <003401c7017a$5dadaf10$6501a8c0@DGBP7M81> <20061106135625.GP4884@ccil.org> <001501c701b9$af4d3a40$6501a8c0@DGBP7M81> <20061106165050.GV4884@ccil.org> <003301c70236$8ebe6380$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003301c70236$8ebe6380$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > It would be suboptimal, to say the least, if we decided to use a script > subtag to indicate one phonetic transcription models, a variant subtag > to indicate another, and no mechanism at all to indicate a third, simply > because we could not agree on which mechanism to use and our ability to > plan a cohesive solution was outstripped by our haste to establish them > one-by-one. No disagreement there. The issues now are: what do we think is the right way, and can we get the various RAs to go along with it? Everything else can be left up to ietf-languages, which I think has enough institutional memory to prevent the kind of chaos you are talking about. -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he cowan@ccil.org that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 07 13:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW22-0002fl-47; Tue, 07 Nov 2006 13:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW20-0002fX-V6 for ltru@lists.ietf.org; Tue, 07 Nov 2006 13:50:44 -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 1GhW1u-0006DP-EW for ltru@lists.ietf.org; Tue, 07 Nov 2006 13:50:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhW1o-0005BS-3k for ltru@lists.ietf.org; Tue, 07 Nov 2006 19:50:32 +0100 Received: from d254085.dialin.hansenet.de ([80.171.254.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 19:50:32 +0100 Received: from nobody by d254085.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 19:50:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 07 Nov 2006 19:49:40 +0100 Organization: Lines: 10 Message-ID: <4550D544.5E39@xyzzy.claranet.de> References: <711a73df0611071034m49df62e5m4890d3f1a1396815@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254085.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] FYI: rfc4646. Some analysis code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dave Pawson wrote in : > After much struggling, I've posted a first attempt at > parsing langtag from rfc4646. Seemingly there isn't any code > around. There is now. > http://www.dpawson.co.uk/java/rfc4646.html [...] Archived-At: _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 00:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghg2N-0003EO-Vh; Wed, 08 Nov 2006 00:31:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghg2M-0003EJ-Hi for ltru@ietf.org; Wed, 08 Nov 2006 00:31:46 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghg2L-00069E-9E for ltru@ietf.org; Wed, 08 Nov 2006 00:31:46 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=g58adfnQWUwYnc+6g7GCU518ei0igz5ZTKKZcwD7abkCEcAjtz3glgq7inLV97In; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.206] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ghg2J-0001ox-NH for ltru@ietf.org; Wed, 08 Nov 2006 00:31:44 -0500 Message-ID: <00e801c702f7$3b172a20$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> <20061107155827.GF4884@ccil.org> Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 Date: Tue, 7 Nov 2006 21:32:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee654b818a3e44423970805eac144dddfe2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.206 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Peter Constable" > Cc: > Sent: Tuesday, November 07, 2006 7:58 AM > Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 > > Peter Constable scripsit: ... > "Make no little plans; they have no power to fire men's blood." I'd rather > ask for IPA first to establish the precedent that different phonetic > systems deserve different script subtags, and then add the others as needed. > But that's a tactical issue; we are in substantial agreement, I think. ... The transcription systems I'm familiar with fall into two groups: those based on latin script and those based on IPA. I'm sure there are others, but I suspect that relatively few of these actually have a script that is exclusively their own. To get down to specific examples, consider a few of the systems that have been used for phonemic transcriptions of English. One of my old textbooks (Peter Ladefoged's "A Course in Phonetics" p. 64) shows a nice comparison chart for Kenyon & Knott, Trager & Smith, Prator & Robinette, Jones, and Webster's. With the exception of Webster's, they aren't distinguished by the characters used, but rather in the way those characters are associated with sounds. Consequently, I'd hope they'd be tagged with the same script subtag. What's the situation for transcription methods not based on IPA or lat*? (BTW, if the transcription system uses latn, would en's Suppress-Script still take effect for a transcription of English?) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 01:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgh2-00010I-4h; Wed, 08 Nov 2006 01:13:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgh0-00010A-FW for ltru@ietf.org; Wed, 08 Nov 2006 01:13:46 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghggz-0000vd-0j for ltru@ietf.org; Wed, 08 Nov 2006 01:13:46 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gY6wp4ZGokQ1goEkahQnEEDij9TwY5DNS4mubCYfCpZ2TipvU5kuyQLVHJfSHFhY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.206] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ghggu-0002cO-HB; Wed, 08 Nov 2006 01:13:40 -0500 Message-ID: <010b01c702fd$156b8d60$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Bill Fenner" , , References: <200611071650.kA7GoQaj024048@bright.research.att.com> Date: Tue, 7 Nov 2006 22:13:59 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6174cad337f7af4a25d0400efb37a2d8c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.206 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: LTRU Working Group , kessler@cisco.com, DMcW@dataconnection.com Subject: [Ltru] Re: Language Tag MIB Textual Convention X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - (I'm CC-ing the ltru WG as a courtesy, and writing as a technical contributor in SNMP-land with some knowledge of the ltru WG's work) > From: "Bill Fenner" > To: ; ; > Cc: ; > Sent: Tuesday, November 07, 2006 8:50 AM > Subject: Language Tag MIB Textual Convention > > > Randy, > > David McWalter and Andy Kessler are revising a IP Multicast Routing > MIB, which for odd reasons has a Textual Convention for an RFC1766 > Language Tag: > > -- Textual Conventions > > LanguageTag ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "100a" > STATUS current > DESCRIPTION > "An RFC 1766-style language tag, with all alphabetic This should refer to BCP 47. > characters converted to lowercase. This restriction is In RFC 4646 section 2.1 there is a differing RECOMMENDED practice, but I don't see this as sufficient reason to change this, particularly if there are already deployed implementations. > intended to make the lexical ordering imposed by SNMP useful > when applied to language tags. Note that it is This attributes more utility to SNMP "lexical" ordering than it deserves. The only advantage (from an SNMP indexing prespective) is that the case-mapping makes the index value unique. To drive home the point, here's an example, showing how some tags would be ordered, using SNMP's rules for "lexicographical" ordering: de en fr it zh frs mga en-us en-gb fr-ca zh-hant frs-arab zh-hans-tw Yes, this is a sorted list! I think you can agree with me that few would consider this particular ordering "useful." So I suggest saying something like: When this textual convention is used for an INDEX, the restriction to lower case ensures that all the possible representations for a particular tag will map to the same value, thus simplifying table lookups. More controversial might be this additional text: For user interface purposes, it is RECOMMENDED that values be displayed using upper and lower case in accordance with the recommendations of BCP 47, even though the value 'on the wire' MUST be lower case. > theoretically possible for a valid language tag to exceed > the allowed length of this syntax, and thus be impossible to > represent with this syntax. Sampling of language tags in > current use on the Internet suggests that this limit does > not pose a serious problem in practice." The limit sould indeed be adequate. See http://www.ietf.org/rfc/rfc4646.txt section 4.3.1 for supporting analysis. > SYNTAX OCTET STRING (SIZE (1..100)) > > We decided that this should at least be in a different MIB module, > so that it could be imported without caring about the IP Multicast > aspects, but then further discussion with Ted and Dan suggested > that it might be useful for it to be in a different document > altogether. Ted had thought that it might be good to create a URL > TC at the same time. I recall some past discussion of that - I have no problem with the idea. > Do you have any thoughts on this? See above. :-) > Thanks, > Bill Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 01:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgv4-0004B1-A0; Wed, 08 Nov 2006 01:28:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgv3-0004Av-1q for ltru@ietf.org; Wed, 08 Nov 2006 01:28:17 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghgv1-0004PD-Rm for ltru@ietf.org; Wed, 08 Nov 2006 01:28:17 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=O0ADeEK/AATNIEdNbBcqqriSJMfJpgS5ii4GMRSxo1eksCFVVj6TjiLi9Aca9ij5; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.206] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ghgv0-0002LC-Of; Wed, 08 Nov 2006 01:28:15 -0500 Message-ID: <012201c702ff$20472d00$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Randy Presuhn" , "Bill Fenner" , , References: <200611071650.kA7GoQaj024048@bright.research.att.com> <010b01c702fd$156b8d60$6601a8c0@oemcomputer> Subject: Re: [Ltru] Re: Language Tag MIB Textual Convention Date: Tue, 7 Nov 2006 22:28:36 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee666dffddef3a70382a2bc5425c79266f5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.206 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group , kessler@cisco.com, DMcW@dataconnection.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > en-us > en-gb oops - these two were reversed. The rest of the list is indeed sorted, according to SNMP's rules. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 04:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghjr9-0004UR-Dp; Wed, 08 Nov 2006 04:36:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghjr8-0004UK-8d for ltru@lists.ietf.org; Wed, 08 Nov 2006 04:36:26 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghjr3-0003x9-VL for ltru@lists.ietf.org; Wed, 08 Nov 2006 04:36:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 234FC26C23D; Wed, 8 Nov 2006 10:36:05 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id AC09426C23A; Wed, 8 Nov 2006 10:36:04 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9FC8358ED5C; Wed, 8 Nov 2006 10:36:04 +0100 (CET) Date: Wed, 8 Nov 2006 10:36:04 +0100 From: Stephane Bortzmeyer To: Frank Ellermann , Dave Pawson Message-ID: <20061108093604.GA20979@nic.fr> References: <711a73df0611071034m49df62e5m4890d3f1a1396815@mail.gmail.com> <4550D544.5E39@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4550D544.5E39@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-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: cf4fa59384e76e63313391b70cd0dd25 Cc: www-international@w3.org, ltru@lists.ietf.org Subject: [Ltru] Re: FYI: rfc4646. Some analysis code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Nov 07, 2006 at 07:49:40PM +0100, Frank Ellermann wrote a message of 10 lines which said: > Dave Pawson wrote in : > > > After much struggling, I've posted a first attempt at parsing > > langtag from rfc4646. Seemingly there isn't any code around. There > > is now. There was already. But it is nice to see more. http://www.bortzmeyer.org/gabuzomeu-parsing-language-tags.html It reminds me we should really have a "Language tags Web page" with pointers to code, to test cases, etc. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 05:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkiH-0002Vz-59; Wed, 08 Nov 2006 05:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkiG-0002Vu-4c for ltru@ietf.org; Wed, 08 Nov 2006 05:31:20 -0500 Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhkiE-0000fQ-SS for ltru@ietf.org; Wed, 08 Nov 2006 05:31:20 -0500 Received: (qmail 38130 messnum 277715 invoked from network[194.125.174.37/ts09-037.dublin.indigo.ie]); 8 Nov 2006 10:31:13 -0000 Received: from ts09-037.dublin.indigo.ie (HELO ?194.125.174.37?) (194.125.174.37) by mail03.svc.cra.dublin.eircom.net (qp 38130) with SMTP; 8 Nov 2006 10:31:13 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20061107155827.GF4884@ccil.org> References: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> <20061107155827.GF4884@ccil.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI and ISO 15924 Date: Wed, 8 Nov 2006 10:34:54 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So would I. We are. mg On 7 Nov 2006, at 15:58, scr=EDobh John Cowan: > Peter Constable scripsit: > >> If I have understood John Cowan correctly, he proposes... > > ... I'd rather > ask for IPA first to establish the precedent that different phonetic > systems deserve different script subtags, and then add the others =20 > as needed. > But that's a tactical issue; we are in substantial agreement, I think. On 8 Nov 2006, at 05:32, scr=EDobh Randy Presuhn: > ... The transcription systems I'm familiar with fall into two groups: > those based on latin script and those based on IPA. I'm sure > there are others, but I suspect that relatively few of these > actually have a script that is exclusively their own.... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 11:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqWH-0000dy-RP; Wed, 08 Nov 2006 11:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqWG-0000bc-NQ for ltru@lists.ietf.org; Wed, 08 Nov 2006 11:43:20 -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 1GhqQa-0005hd-2L for ltru@lists.ietf.org; Wed, 08 Nov 2006 11:37:30 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhqQ4-0003Ft-Qr for ltru@lists.ietf.org; Wed, 08 Nov 2006 17:36:56 +0100 Received: from d252145.dialin.hansenet.de ([80.171.252.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Nov 2006 17:36:56 +0100 Received: from nobody by d252145.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Nov 2006 17:36:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 08 Nov 2006 17:35:22 +0100 Organization: Lines: 17 Message-ID: <4552074A.607@xyzzy.claranet.de> References: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> <20061107155827.GF4884@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252145.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: subtags for phonetic transcriptions X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > "Make no little plans; they have no power to fire men's blood." I'd rather > ask for IPA first to establish the precedent that different phonetic > systems deserve different script subtags, and then add the others as needed. > But that's a tactical issue; we are in substantial agreement, I think. BTW, checking Grek for a case discussed on the W3C I18N list - a complete waste of time, because you answered it before me ;-) - I stumbled over Pldr. Is "Pldr" a useful precedent for our Latp / Lphn / Xphn / IPA discussions ? I've not the faintest idea what Plrd is, and I'm also too lazy to research what it might be, but its description mentions "phonetic". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 11:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqWN-0000yR-Fb; Wed, 08 Nov 2006 11:43:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqW6-0000Sh-Eb for ltru@ietf.org; Wed, 08 Nov 2006 11:43:10 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhqUr-00066s-Qv for ltru@ietf.org; Wed, 08 Nov 2006 11:41:56 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GhqUj-0005Jy-5y; Wed, 08 Nov 2006 11:41:45 -0500 Date: Wed, 8 Nov 2006 11:41:45 -0500 To: Randy Presuhn Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 Message-ID: <20061108164145.GP4884@ccil.org> References: <20061107155827.GF4884@ccil.org> <00e801c702f7$3b172a20$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e801c702f7$3b172a20$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > What's the situation for transcription methods not based on > IPA or lat*? Well, all standardized transcription methods are based on (extended) Latin script, including IPA. The question is, if you know IPA, can you cope with the others or do you need a mapping table? My sense is that the Americanist variants you mention are not much problem to people who know IPA, but that the Uralic Phonetic Alphabet and Laandsmalalfabetet are *really drastically* different, enough so that you won't have a clue if you just know IPA. > (BTW, if the transcription system uses latn, would > en's Suppress-Script still take effect for a transcription > of English?) Argh. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 12:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrB5-0005yf-Nf; Wed, 08 Nov 2006 12:25:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrB4-0005y8-2Q for ltru@lists.ietf.org; Wed, 08 Nov 2006 12:25:30 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrB0-000475-N8 for ltru@lists.ietf.org; Wed, 08 Nov 2006 12:25:30 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GhrAz-0007H0-IK; Wed, 08 Nov 2006 12:25:25 -0500 Date: Wed, 8 Nov 2006 12:25:25 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: subtags for phonetic transcriptions Message-ID: <20061108172525.GB22425@ccil.org> References: <19A328037921AA42847A717566D1D6A1096014A2@RED-MSG-42.redmond.corp.microsoft.com> <20061107155827.GF4884@ccil.org> <4552074A.607@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4552074A.607@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > I've not the faintest idea what Plrd is, and I'm also too lazy to research > what it might be, but its description mentions "phonetic". Pollard phonetic is a script used to write the A-Hmao variety of Hmong. It is an abugida, like Ethiopic or Indic. It has nothing to do with phonetic transcription. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 13:32:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsE1-0007yR-I5; Wed, 08 Nov 2006 13:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsE0-0007y3-Pa for ltru@ietf.org; Wed, 08 Nov 2006 13:32:36 -0500 Received: from nz-out-0102.google.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsDy-0006D3-4o for ltru@ietf.org; Wed, 08 Nov 2006 13:32:36 -0500 Received: by nz-out-0102.google.com with SMTP id 40so790857nzk for ; Wed, 08 Nov 2006 10:32:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=NmaZTITRGIqoU8KHcxVvNKRzIGOGFY2+ggzc+YQYLBfUWvukz5RzGJZAEL9j2fZ0JA2V2rlwDESqw3OYEh+FTmjcK31lhasFQ1p1WwIJjjiA7yLZuBSfIpodCtnyZor29cGVQ2VVvDFirpm3Vxk6ZaAimyJHqdlKzkacXTSFljQ= Received: by 10.64.208.20 with SMTP id f20mr1500815qbg.1163010747783; Wed, 08 Nov 2006 10:32:27 -0800 (PST) Received: by 10.65.211.11 with HTTP; Wed, 8 Nov 2006 10:32:27 -0800 (PST) Message-ID: <30b660a20611081032r599ba8dbqe56267f4fae40f36@mail.gmail.com> Date: Wed, 8 Nov 2006 10:32:27 -0800 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 3072320450936a0a X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] taq vs tmh? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1297721166==" Errors-To: ltru-bounces@ietf.org --===============1297721166== Content-Type: multipart/alternative; boundary="----=_Part_28767_6146570.1163010747748" ------=_Part_28767_6146570.1163010747748 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline When looking at the Ethnologue, it says: Tamasheq A language of Mali ISO/DIS 639-3: taq Population 250,000 in Mali (1991). Population total all countries: 281,169. Region Central, Timbuktu area, and northeast Mali. Also spoken in Algeria, Burkina Faso. Alternate names Kidal Tamasheq, Tomacheck, Tamashekin, "Tuareg", Timbuktu, Kidal Now, I don't have a copy of 639-3, but I assume that the Ethnologue has that correctly. However, how does Tamasheq (taq) differ from the already-in-ltru Tamashek (tmh)? That is, I hope this is not a duplicate. Mark ------=_Part_28767_6146570.1163010747748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline When looking at the Ethnologue, it says:

Tamasheq
A language of Mali

ISO/DIS 639-3: taq
Population     250,000 in Mali (1991). Population total all countries: 281,169.
Region     Central, Timbuktu area, and northeast Mali. Also spoken in Algeria, Burkina Faso.
Alternate names       Kidal Tamasheq, Tomacheck, Tamashekin, "Tuareg", Timbuktu, Kidal

Now, I don't have a copy of 639-3, but I assume that the Ethnologue has that correctly. However, how does Tamasheq (taq) differ from the already-in-ltru Tamashek (tmh)? That is, I hope this is not a duplicate.

Mark
------=_Part_28767_6146570.1163010747748-- --===============1297721166== 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 --===============1297721166==-- From ltru-bounces@ietf.org Wed Nov 08 13:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsP0-0003JS-Ui; Wed, 08 Nov 2006 13:43:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsOz-0003JF-Pm for ltru@ietf.org; Wed, 08 Nov 2006 13:43:57 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsOt-0007ry-R7 for ltru@ietf.org; Wed, 08 Nov 2006 13:43:57 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GhsOt-00022p-7D; Wed, 08 Nov 2006 13:43:51 -0500 Date: Wed, 8 Nov 2006 13:43:51 -0500 To: Mark Davis Subject: Re: [Ltru] taq vs tmh? Message-ID: <20061108184351.GB30946@ccil.org> References: <30b660a20611081032r599ba8dbqe56267f4fae40f36@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20611081032r599ba8dbqe56267f4fae40f36@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Now, I don't have a copy of 639-3, but I assume that the Ethnologue > has that correctly. However, how does Tamasheq (taq) differ from the > already-in-ltru Tamashek (tmh)? That is, I hope this is not a duplicate. It isn't. Tamashek (tmh) is a macrolanguage encompassing Tamasheq (taq), Tahaggart Tamahaq (thv), Tawallammat Tamajaq (ttg), and Tayart Tamajeq (thz). This is one of those cases where 693-3 makes finer distinctions than 639-2 did. Since macrolanguages don't get entries in Ethnologue, the easiest way to find this out is to use http://www.sil.org/iso639-3/documentation.asp?id=XXX , which will produce the right result for any 639-3 code element, including a link to the Ethnologue or Linguist List, or in the case of a macrolanguage links to the encompassed language. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 20:16:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyWe-0007eD-BG; Wed, 08 Nov 2006 20:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyWd-0007e8-EZ for ltru@ietf.org; Wed, 08 Nov 2006 20:16:15 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhyWb-0005Rb-2m for ltru@ietf.org; Wed, 08 Nov 2006 20:16:15 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YioXHscV6VvmwGcUEUjqRwoTtwj5/Kh4IgWLHLqVOxT14qLrV9Hya/xGah9O7Jie; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.11] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GhyWY-0000RX-0d for ltru@ietf.org; Wed, 08 Nov 2006 20:16:10 -0500 Message-ID: <001e01c7039c$a9fa8ea0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20061107155827.GF4884@ccil.org> <00e801c702f7$3b172a20$6601a8c0@oemcomputer> <20061108164145.GP4884@ccil.org> Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 Date: Wed, 8 Nov 2006 17:16:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6d8bb5934254b14cd4a76e63c9ef03962350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, November 08, 2006 8:41 AM > Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 > > Randy Presuhn scripsit: > > > What's the situation for transcription methods not based on > > IPA or lat*? > > Well, all standardized transcription methods are based on (extended) > Latin script, including IPA. The question is, if you know IPA, > can you cope with the others or do you need a mapping table? > > My sense is that the Americanist variants you mention are not much > problem to people who know IPA, but that the Uralic Phonetic Alphabet > and Laandsmalalfabetet are *really drastically* different, enough > so that you won't have a clue if you just know IPA. > > > (BTW, if the transcription system uses latn, would > > en's Suppress-Script still take effect for a transcription > > of English?) > > Argh. ... This leads me to conclude that having a script for something like "IPA and IPA-based systems" would be highly desirable, since it would otherwise leave us no way to tag something that is known to be a transcription when cataloguer lacks the expertise to identify the specific transcription system. It also leads me to conclude that although some cataloguers might only be able to tag something as being, for example, English transcribed using an IPA-based script, that there will be a real need for further subtags to specifically identify the system in use. The same sequence of symbols in the Trager & Smith and Prator & Robinette systems, for example, can have radically different pronunciations. What should the process for handling a registration request for a transcription system be? Is it necessary to demonstrate that it's being used by giving examples of documents where it has been used, or might it perhaps be more important to provide a reference that describes the transcription system iteself? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 21:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzXZ-0006aI-4A; Wed, 08 Nov 2006 21:21:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzXX-0006aD-Q1 for ltru@ietf.org; Wed, 08 Nov 2006 21:21:15 -0500 Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhzXW-0003ur-DV for ltru@ietf.org; Wed, 08 Nov 2006 21:21:15 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 02:21:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Ltru] Re: Language Tag MIB Textual Convention Date: Thu, 9 Nov 2006 02:21:08 -0000 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B46@enfimail2.datcon.co.uk> In-Reply-To: <012201c702ff$20472d00$6601a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Language Tag MIB Textual Convention Thread-Index: AccC/xRJZiuJggdWR4KNhorzEEYm+gApUMyw From: "David McWalter" To: "Randy Presuhn" , "Bill Fenner" , , X-OriginalArrivalTime: 09 Nov 2006 02:21:09.0480 (UTC) FILETIME=[B7FF5680:01C703A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: LTRU Working Group , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy, Thanks for your help. Below are TCs including your text. I'd welcome = any further advice. I'll put this in an individual submission at the same time I revise = IPMCAST MIB, I guess early next week. http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-03.txt= I was surprised no-one had defined a URL TC before, so I searched and = found: http://www1.ietf.org/mail-archive/web/imss/current/msg00516.html 'There is currently a discussion going on w.r.t. URL TC on SIP=20 list and some MIB doctors (like Juergen and Dan) are also involved.' I'm really happy to not do URLs if someone else has started on this = already. Cheers, David McWalter. dmcw@dataconnection.com LANGTAG-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; langTagMIB MODULE-IDENTITY LAST-UPDATED "200611080000Z" -- 8 November 2006 ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "EMail: ops-area@ietf.org" DESCRIPTION "The MIB module defines textual conventions for representing generic tags." REVISION "200611080000Z" -- 8 November 2006 DESCRIPTION "Initial revision, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { mib-2 yyyy } -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- -- This language tag is case insensitive. For user interface purposes, -- it is RECOMMENDED that values be displayed using upper and lower case -- in accordance with the recommendations of BCP 47, even though the -- value 'on the wire' MUST be lower case. -- LanguageTag ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "100a" STATUS current DESCRIPTION "A brief tag that identifies a language. A registry of tags is available at http://www.iana.org/assignments/language-tags. This value is case-insensitive. Conventions exist for the capitalization of some of the subtags, but these do not convey any meaning. It is theoretically possible for a valid language tag to exceed the allowed length of this syntax, and thus be impossible to represent with this syntax. Sampling of language tags in current use on the Internet suggests that this limit does not pose a problem in practice." REFERENCE "RFC 4646 BCP 47" SYNTAX OCTET STRING (SIZE (1..100)) Uri ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "A Uniform Resource Identifier (URI)." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (1..1024)) Url ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "A Uniform Resource Locator (URL)." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (1..1024)) -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: 07 November 2006 22:29 To: Randy Presuhn; Bill Fenner; hardie@qualcomm.com; dromasca@avaya.com Cc: LTRU Working Group; kessler@cisco.com; David McWalter Subject: Re: [Ltru] Re: Language Tag MIB Textual Convention Hi - > en-us > en-gb oops - these two were reversed. The rest of the list is indeed sorted, according to SNMP's rules. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 22:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi0JS-0007Pj-Oz; Wed, 08 Nov 2006 22:10:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi0JQ-0007PC-Ra for ltru@ietf.org; Wed, 08 Nov 2006 22:10:44 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi0JG-0001Bk-O0 for ltru@ietf.org; Wed, 08 Nov 2006 22:10:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NWdq5WCiZjd/pE0QtpTYawymrYjNfGJIxZBq79uKVBDdH7hc1nN0jnMS7wUUAE/7; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.11] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gi0J9-00006F-L0; Wed, 08 Nov 2006 22:10:27 -0500 Message-ID: <000801c703ac$a8b2d920$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "David McWalter" , "Bill Fenner" , , References: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B46@enfimail2.datcon.co.uk> Subject: Re: [Ltru] Re: Language Tag MIB Textual Convention Date: Wed, 8 Nov 2006 19:10:47 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee64ddc2650f178084912fd8f0b1e997d0b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: LTRU Working Group , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "David McWalter" > To: "Randy Presuhn" ; "Bill Fenner" ; ; > Cc: "LTRU Working Group" ; > Sent: Wednesday, November 08, 2006 6:21 PM > Subject: RE: [Ltru] Re: Language Tag MIB Textual Convention ... > -- This language tag is case insensitive. For user interface purposes, > -- it is RECOMMENDED that values be displayed using upper and lower case > -- in accordance with the recommendations of BCP 47, even though the > -- value 'on the wire' MUST be lower case. It's better to put this sort of thing in the DESCRIPTION rather than in an comment. > LanguageTag ::= TEXTUAL-CONVENTION > DISPLAY-HINT "100a" > STATUS current > DESCRIPTION > "A brief tag that identifies a language. A registry of tags > is available at > http://www.iana.org/assignments/language-tags. A sanity check might be in order. The registry is of sub-tags, which are combined using the syntax defined in BCP 47 to form a language tag. I think it would be better to say something like: A language tag, constructed in accordance with BCP 47. > This value is case-insensitive. Conventions exist for the > capitalization of some of the subtags, but these do not > convey any meaning. This does precisely the wrong thing if anyone ever wants to use one of these for an OBJECT-TYPE that will be used in an INDEX clause. I think there are two realistic alternatives: (a) limit everything to lower case, preserving compatibility with existing MIB objects (b) require it to conform to the RECOMMENDED case conventions of BCP 47 (a) is simpler and easier on agents. I think the user interface gains from (b) are negligible, since any serious user interface should supply a properly localized language name, rather than a tag, for user consumption. Consequently, I think (a) is a *slightly* better choice, primarily because it's harder for agent implementors to get it wrong, and because it would be easier for conformance testers to verify. > It is theoretically possible for a valid language tag to > exceed the allowed length of this syntax, and thus be > impossible to represent with this syntax. Sampling of > language tags in current use on the Internet suggests that > this limit does not pose a problem in practice." ... We can make a stronger statement than that last sentence. I suggest: The analysis of language tag lengths in BCP 47 confirms that this limit will not pose a problem in practice. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 08 23:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1vT-0000bU-1A; Wed, 08 Nov 2006 23:54:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1vR-0000aW-NI for ltru@ietf.org; Wed, 08 Nov 2006 23:54:05 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi1me-0004Cp-Ji for ltru@ietf.org; Wed, 08 Nov 2006 23:45:02 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gi1me-0000Nn-0V; Wed, 08 Nov 2006 23:45:00 -0500 Date: Wed, 8 Nov 2006 23:44:59 -0500 To: Randy Presuhn Subject: Re: subtags for phonetic transcriptions (was RE: [Ltru] Re: ANSI andISO 15924 Message-ID: <20061109044459.GE16691@ccil.org> References: <20061107155827.GF4884@ccil.org> <00e801c702f7$3b172a20$6601a8c0@oemcomputer> <20061108164145.GP4884@ccil.org> <001e01c7039c$a9fa8ea0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001e01c7039c$a9fa8ea0$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > The same sequence of symbols in > the Trager & Smith and Prator & Robinette systems, for > example, can have radically different pronunciations. Well, true. And the sentence "Johnny went to the bathroom in his pants" means radically different things in en-us and en-gb. That's still a variant-level distinction (as I mentioned, we treat country- and higher-level regional variants as separate from other variants for historical reasons and convenience, not because they are at a fundamentally different level). > > What should the process for handling a registration > request for a transcription system be? Is it necessary > to demonstrate that it's being used by giving > examples of documents where it has been used, > or might it perhaps be more important to provide a > reference that describes the transcription system iteself? The latter has been standard for other kinds of variants in the RFC 1766/3066/4646 tradition. Scripts haven't been much of a problem historically. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If a soldier is asked why he kills people who have done him no harm, or a terrorist why he kills innocent people with his bombs, they can always reply that war has been declared, and there are no innocent people in an enemy country in wartime. The answer is psychotic, but it is the answer that humanity has given to every act of aggression in history. --Northrop Frye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 00:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2pp-0002vX-N3; Thu, 09 Nov 2006 00:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2po-0002vP-QQ for ltru@ietf.org; Thu, 09 Nov 2006 00:52:20 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2pn-000531-Fw for ltru@ietf.org; Thu, 09 Nov 2006 00:52:20 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 05:52:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Ltru] Re: Language Tag MIB Textual Convention Date: Thu, 9 Nov 2006 05:52:17 -0000 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B4A@enfimail2.datcon.co.uk> In-Reply-To: <000801c703ac$a8b2d920$6601a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Language Tag MIB Textual Convention Thread-Index: AccDrJ2n9xW/FeSpTRy+wTN6zt87BwAEgG3w From: "David McWalter" To: "Randy Presuhn" , "Bill Fenner" , , X-OriginalArrivalTime: 09 Nov 2006 05:52:18.0673 (UTC) FILETIME=[376CC610:01C703C3] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: LTRU Working Group , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks, Randy. You're especially correct about the need for uniquely-determined case = values for indexes. I've taken a guess that this is the right thing to = do for URI/URLs as well. Revised text... DMcW. LANGTAG-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; langTagMIB MODULE-IDENTITY LAST-UPDATED "200611080000Z" -- 8 November 2006 ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "EMail: ops-area@ietf.org" DESCRIPTION "The MIB module defines textual conventions for representing generic tags." REVISION "200611080000Z" -- 8 November 2006 DESCRIPTION "Initial revision, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { mib-2 yyyy } -- RFC Ed.: replace yyyy with actual RFC number & remove this note LanguageTag ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "100a" STATUS current DESCRIPTION "A language tag, constructed in accordance with BCP 47. Only lowercase characters are allowed. The purpose of this restriction is to provide unique language tags for use as indexes. BCP 47 recommends case conventions for user interfaces, but objects using this convention MUST use only lowercase. In theory, BCP 47 language tags are of unlimited length. This language tag is of limited length. The analysis of language tag lengths in BCP 47 confirms that this limit will not pose a problem in practice." REFERENCE "RFC 4646 BCP 47" SYNTAX OCTET STRING (SIZE (1..100)) Uri ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "A Uniform Resource Identifier (URI) as defined by STD 66. Only lowercase characters are allowed. The purpose of this restriction is to provide unique URIs for use as indexes. URI normalization capitalizes letters in escape sequences, but objects using this convention MUST use only lowercase. STD 66 URIs are of unlimited length. This textual convention imposes a length limit on the URIs that it can represent." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (1..1024)) Url ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "A Uniform Resource Locator (URL) as defined by STD 66. Only lowercase characters are allowed. The purpose of this restriction is to provide unique URLs for use as indexes. URL normalization capitalizes letters in escape sequences, but objects using this convention MUST use only lowercase. STD 66 URLs are of unlimited length. This textual convention imposes a length limit on the URLs that it can represent." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (1..1024)) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 03:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5JF-00018l-ID; Thu, 09 Nov 2006 03:30:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5JE-00018f-MO for ltru@ietf.org; Thu, 09 Nov 2006 03:30:52 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi5J9-00064d-Bw for ltru@ietf.org; Thu, 09 Nov 2006 03:30:52 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061109083046.UWWL1470.mta11.adelphia.net@DGBP7M81> for ; Thu, 9 Nov 2006 03:30:46 -0500 Message-ID: <002501c703d9$5bb6c640$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 9 Nov 2006 00:30:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Re: Language Tag MIB Textual Convention X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> LanguageTag ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "100a" >> STATUS current >> DESCRIPTION >> "A brief tag that identifies a language. A registry of >> tags is available at >> http://www.iana.org/assignments/language-tags. > > A sanity check might be in order. The registry is of sub-tags, > which are combined using the syntax defined in BCP 47 to form > a language tag. It's worse than that; the URL cited is actually for the old RFC 3066 tag registry. If this document is to be updated to refer to RFC 4646, it should refer to the IANA Language Subtag Registry at http://www.iana.org/assignments/language-subtag-registry. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 13:42:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEqk-0000pe-8i; Thu, 09 Nov 2006 13:42:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEqj-0000pY-45 for ltru@ietf.org; Thu, 09 Nov 2006 13:42:05 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEqd-00049U-Nx for ltru@ietf.org; Thu, 09 Nov 2006 13:42:05 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OUFS5ZviyMNdNCTFrmFQN14lyUQj/WDb16lhRGQwEEiXyziD6lNkuffc6D6ZdFvD; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.81] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GiEqa-0004qx-UW; Thu, 09 Nov 2006 13:41:57 -0500 Message-ID: <000101c7042e$c31ccdc0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <002501c703d9$5bb6c640$6501a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Language Tag MIB Textual Convention Date: Thu, 9 Nov 2006 10:36:44 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6f18dc751cc17239675bebc24b8d81ccd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Bill Fenner , dromasca@avaya.com, kessler@cisco.com, David McWalter X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: Thursday, November 09, 2006 12:30 AM > Subject: [Ltru] Re: Language Tag MIB Textual Convention > > Randy Presuhn wrote: > > >> LanguageTag ::= TEXTUAL-CONVENTION > >> DISPLAY-HINT "100a" > >> STATUS current > >> DESCRIPTION > >> "A brief tag that identifies a language. A registry of > >> tags is available at > >> http://www.iana.org/assignments/language-tags. > > > > A sanity check might be in order. The registry is of sub-tags, > > which are combined using the syntax defined in BCP 47 to form > > a language tag. > > It's worse than that; the URL cited is actually for the old RFC 3066 tag > registry. If this document is to be updated to refer to RFC 4646, it > should refer to the IANA Language Subtag Registry at > http://www.iana.org/assignments/language-subtag-registry. ... Good point; this leads me to think that perhaps it's best to just refer to BCP 47. Giving the URL might tempt developers to skip the essential stuff in the BCP. This reminds me that the object's definition needs to say something about well-formedness and validity. I suggest something like: Values MUST be well-formed language tags, in conformance with the definition of well-formed tags in BCP 47. An implementation MAY further limit the values it accepts to those permitted by a 'validating' processor, as defined in BCP 47. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 21:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLhk-0006sD-OJ; Thu, 09 Nov 2006 21:01:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLhk-0006rc-81; Thu, 09 Nov 2006 21:01:16 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLhi-0008Ni-Ul; Thu, 09 Nov 2006 21:01:16 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iTHMTPJfcXFbH8N6IJWCN3UDKgKBVw4rwCkna4CumJYxaETSc/gK8+WBs73cK6IG; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.43] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GiLhg-000282-6j; Thu, 09 Nov 2006 21:01:12 -0500 Message-ID: <00b701c7046c$21450920$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors" References: Subject: Re: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention Date: Thu, 9 Nov 2006 18:01:19 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee649df9363af3ae1ad44d480bd4020d761350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.43 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Bill Fenner , LTRU Working Group , kessler@cisco.com, DMcW@dataconnection.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Romascanu, Dan (Dan)" > To: > Cc: "MIB Doctors" ; ; "Randy Presuhn" ; "LTRU Working Group" ; ; "Bill Fenner" > Sent: Thursday, November 09, 2006 10:53 AM > Subject: RE: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention ... > The need for a URI TC first time surfaced in the SIP MIB. Second here is > the LTRU WG facing or anticipating similar needs. ... Clarification - the ltru WG was cc-ed into this discussion as a courtesy. This is not part of its current work plan. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 21:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMXv-0008LP-U3; Thu, 09 Nov 2006 21:55:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMXu-0008Ky-6q; Thu, 09 Nov 2006 21:55:10 -0500 Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMXs-0002lG-Tl; Thu, 09 Nov 2006 21:55:10 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 02:55:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Nov 2006 02:55:02 -0000 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B59@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention Thread-Index: AccEbBlCQ3zsZhpbTPq2HpriTUTrmwAAverQ From: "David McWalter" To: "Randy Presuhn" , "Romascanu, Dan \(Dan\)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Nov 2006 02:55:03.0978 (UTC) FILETIME=[9F10D8A0:01C70473] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Bill Fenner , MIB Doctors , LTRU Working Group Subject: [Ltru] Re: Language Tag MIB Textual Convention X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Right - ltru didn't initiate uri/url. Ted/Bill suggested doing a url TC at the same time as moving the = LanguageTag to a separate module. We're not resolved on whether LanguageTag and uri/url belong in the same = MIB module. - Dan was happy to see a new module with LanguageTag and uri/url. - Juergen prefers an InetUri in INET-ADDRESS-MIB. I need a LanguageTag TC to reference from IPMCAST-MIB. For now I plan = to put out an individual submission containing it, and keep ltru = informed. Is this okay with everyone? Should I go with Dan's module structure or = Juergen's? DMcW. -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: 09 November 2006 18:01 To: MIB Doctors Cc: LTRU Working Group; David McWalter; Bill Fenner; kessler@cisco.com Subject: Re: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention Hi - > From: "Romascanu, Dan (Dan)" > To: > Cc: "MIB Doctors" ; ; = "Randy Presuhn" ; "LTRU Working Group" ; ; "Bill Fenner" = > Sent: Thursday, November 09, 2006 10:53 AM > Subject: RE: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual = Convention ... > The need for a URI TC first time surfaced in the SIP MIB. Second here = is > the LTRU WG facing or anticipating similar needs. ... Clarification - the ltru WG was cc-ed into this discussion as a courtesy. This is not part of its current work plan. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 09 22:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiN2o-0000EQ-Ii; Thu, 09 Nov 2006 22:27:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiF1s-0001a8-CD; Thu, 09 Nov 2006 13:53:36 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiF1q-0005jR-3a; Thu, 09 Nov 2006 13:53:36 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kA9IrQeG021159; Thu, 9 Nov 2006 13:53:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention Date: Thu, 9 Nov 2006 20:53:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention Thread-Index: AccEHDkFi6+grIT8Sx2RZmt/wAeM9AAE0nlw From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Thu, 09 Nov 2006 22:27:05 -0500 Cc: LTRU Working Group , DMcW@dataconnection.com, Bill Fenner , MIB Doctors , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I believe that cross-posting between LTRU WG and MIB-Doctors list is useful in this case.=20 Juergen, The need for a URI TC first time surfaced in the SIP MIB. Second here is the LTRU WG facing or anticipating similar needs.=20 Should we overload INET-ADDRESS-MIB with such information? I am not sure that maintaining one module for all well-known TCs is optimal. Maybe a better solution would be a small number of modules grouping well known TCs - like the one ltru are discussing now. We can point to those from the OPS Area Web pages, we plan to turn into wikis sometimes soon.=20 Dan =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Thursday, November 09, 2006 6:29 PM > To: Romascanu, Dan (Dan) > Cc: MIB Doctors; DMcW@dataconnection.com > Subject: Re: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB=20 > Textual Convention >=20 > On Thu, Nov 09, 2006 at 04:55:35PM +0200, Romascanu, Dan (Dan) wrote: >=20 > > Copying the MIB Doctors list. >=20 > So what do we do about this? We surely need generic URL/URI=20 > TCs and I think those things should be hidden in some strange=20 > MIBs but become a clearly identifyable reusable module. >=20 > Dan, do you have an overview where people are working already=20 > and URL/URI TCs? >=20 > > Uri ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "1024a" > > STATUS current > > DESCRIPTION > > "A Uniform Resource Identifier (URI)." > > REFERENCE "RFC 3986 STD 66 and RFC 3305" > > SYNTAX OCTET STRING (SIZE (1..1024)) > >=20 > > Url ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "1024a" > > STATUS current > > DESCRIPTION > > "A Uniform Resource Locator (URL)." > > REFERENCE "RFC 3986 STD 66 and RFC 3305" > > SYNTAX OCTET STRING (SIZE (1..1024)) >=20 > I am not sure what the difference really is between these two=20 > and when I should use which. I also checked the references=20 > and could not find a length limitation - so we should be=20 > careful to not over constrain these definitions but rather=20 > spell out in the descriptions that for SNMP purposes there=20 > might be length restrictions. I have not followed closely the=20 > IRI work - so I do not know what the internationalization=20 > aspect of this would be. >=20 > Since the INET-ADDRESS-MIB has already mutated into a=20 > collection of generic TC definitions (AS numbers, port=20 > numbers, IP protocol versions), one could also consider to=20 > revise the INET-ADDRESS-MIB and add something like InetUri to=20 > it (and if needed also InetUrl). Dan, do you have an idea how=20 > you want to deal with this issue? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > (Jacobs University Bremen as=20 > of Spring 2007) > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 02:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQXR-0002Ow-Ha; Fri, 10 Nov 2006 02:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQXP-0002Oo-IG for ltru@ietf.org; Fri, 10 Nov 2006 02:10:55 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiQXO-0004wU-9s for ltru@ietf.org; Fri, 10 Nov 2006 02:10:55 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061110071051.QEOY9644.mta9.adelphia.net@DGBP7M81> for ; Fri, 10 Nov 2006 02:10:51 -0500 Message-ID: <004e01c70497$5b5246c0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 9 Nov 2006 23:10:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: FYI: rfc4646. Some analysis code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > It reminds me we should really have a "Language tags Web page" with > pointers to code, to test cases, etc. I'm trying to find the time. Someday. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 02:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8L-0005q1-Su; Fri, 10 Nov 2006 02:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8K-0005pm-SD for ltru@ietf.org; Fri, 10 Nov 2006 02:49:04 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiR8H-00022X-TW for ltru@ietf.org; Fri, 10 Nov 2006 02:49:04 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAA7n0G3003629 for ; Fri, 10 Nov 2006 16:49:00 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1530_edb81ef4_708f_11db_9737_0014221f2a2d; Fri, 10 Nov 2006 16:49:00 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56094) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Nov 2006 16:48:31 +0900 Message-Id: <6.0.0.20.2.20061110152717.19ee8690@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 10 Nov 2006 15:47:30 +0900 To: "Romascanu, Dan \(Dan\)" , From: Martin Duerst Subject: RE: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Bill Fenner , MIB Doctors , LTRU Working Group , kessler@cisco.com, DMcW@dataconnection.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:53 06/11/10, Romascanu, Dan \(Dan\) wrote: >I believe that cross-posting between LTRU WG and MIB-Doctors list is >useful in this case. Very much so, probably. If you do, please try to expand a few acronyms more than usually. >Juergen, > >The need for a URI TC first time surfaced in the SIP MIB. Second here is >the LTRU WG facing or anticipating similar needs. Depending on how I read this sentence, I have to agree or disagree. The work of the LTRU WG points to a need for a "Language-Tag" TC (am I correct that this means "textual convention"?), which may be similar in its nature as a buliding block to an URI TC. But language tags are not URIs, so we (or language tag users who are also MIB users, to be exact) can't use an URI TC. >Should we overload INET-ADDRESS-MIB with such information? I am not sure >that maintaining one module for all well-known TCs is optimal. Maybe a >better solution would be a small number of modules grouping well known >TCs - like the one ltru are discussing now. We can point to those from >the OPS Area Web pages, we plan to turn into wikis sometimes soon. I can't say much here, I'm not a MIB expert. >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >> Sent: Thursday, November 09, 2006 6:29 PM >> On Thu, Nov 09, 2006 at 04:55:35PM +0200, Romascanu, Dan (Dan) wrote: >> >> > Copying the MIB Doctors list. >> >> So what do we do about this? We surely need generic URL/URI >> TCs and I think those things should be hidden in some strange >> MIBs but become a clearly identifyable reusable module. >> >> Dan, do you have an overview where people are working already >> and URL/URI TCs? >> >> > Uri ::= TEXTUAL-CONVENTION >> > DISPLAY-HINT "1024a" >> > STATUS current >> > DESCRIPTION >> > "A Uniform Resource Identifier (URI)." >> > REFERENCE "RFC 3986 STD 66 and RFC 3305" >> > SYNTAX OCTET STRING (SIZE (1..1024)) >> > >> > Url ::= TEXTUAL-CONVENTION >> > DISPLAY-HINT "1024a" >> > STATUS current >> > DESCRIPTION >> > "A Uniform Resource Locator (URL)." >> > REFERENCE "RFC 3986 STD 66 and RFC 3305" >> > SYNTAX OCTET STRING (SIZE (1..1024)) >> >> I am not sure what the difference really is between these two >> and when I should use which. I don't see any difference at all, except for the Identifier/Locator difference. RFC 3305 (http://www.ietf.org/rfc/rfc3305.txt), which you have explicitly as a reference, explains carefully why these are all one and the same thing. In particular, see section "2.2 Contemporary View" in RFC 3305. Unless there are some backwards compatibility issues, the best thing is to use only one of these. >> I also checked the references >> and could not find a length limitation - so we should be >> careful to not over constrain these definitions but rather >> spell out in the descriptions that for SNMP purposes there >> might be length restrictions. Yes, good point. >> I have not followed closely the >> IRI work - so I do not know what the internationalization >> aspect of this would be. I happen to have followed the IRI work :-). But I'm utterly unfamiliar with MIB stuff. Can a 'textual convention' include non-ASCII characters? If yes, how does it do so? What exactly is a 'textual convention'? Is it something the user sees directly? For IRI or URI/URL only related issues in followup mails, you may removed the LTRU WG, because the LTRU WG is about language tags, not IRIs or URI/URLs. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 02:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8P-0005rJ-2Z; Fri, 10 Nov 2006 02:49:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8N-0005qh-WE for ltru@ietf.org; Fri, 10 Nov 2006 02:49:08 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiR8M-000237-A4 for ltru@ietf.org; Fri, 10 Nov 2006 02:49:07 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kAA7n5Sb025452 for ; Fri, 10 Nov 2006 16:49:05 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 15cc_f03bed18_708f_11db_8e63_0014221f2a2d; Fri, 10 Nov 2006 16:49:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56094) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Nov 2006 16:48:35 +0900 Message-Id: <6.0.0.20.2.20061110155146.19e52920@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 10 Nov 2006 16:04:57 +0900 To: "Romascanu, Dan \(Dan\)" , "MIB Doctors" , , "Randy Presuhn" , "LTRU Working Group" , , "Bill Fenner" From: Martin Duerst Subject: Re: FW: [MIB-DOCTORS] FW: [Ltru] Re: Language Tag MIB Textual Convention In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 08:56 06/11/10, Romascanu, Dan \(Dan\) wrote: >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >Sent: Thursday, November 09, 2006 9:37 PM >> Uri ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "1024a" >> STATUS current >> DESCRIPTION >> "A Uniform Resource Identifier (URI) as defined by STD 66. >> >> Only lowercase characters are allowed. The purpose of >this >> restriction is to provide unique URIs for use as indexes. >> URI normalization capitalizes letters in escape sequences, >> but objects using this convention MUST use only lowercase. >> >> STD 66 URIs are of unlimited length. This textual >> convention imposes a length limit on the URIs that it can >> represent." >> REFERENCE "RFC 3986 STD 66 and RFC 3305" >> SYNTAX OCTET STRING (SIZE (1..1024)) >> >> Url ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "1024a" >> STATUS current >> DESCRIPTION >> "A Uniform Resource Locator (URL) as defined by STD 66. >> >> Only lowercase characters are allowed. The purpose of >this >> restriction is to provide unique URLs for use as indexes. >> URL normalization capitalizes letters in escape sequences, >> but objects using this convention MUST use only lowercase. >> >> STD 66 URLs are of unlimited length. This textual >> convention imposes a length limit on the URLs that it can >> represent." >> REFERENCE "RFC 3986 STD 66 and RFC 3305" >> SYNTAX OCTET STRING (SIZE (1..1024)) > >I have problems with these definitions: > >a) I dislike the arbitrary length restriction. If needed, define TCs >such > as Uri, Uri1024, Uri255 and so on so that MIB module writers can >choose > how constrained they want to be. Good idea. >b) I think the requirements for lowercase characters is broken. We >should > simply require normalized URIs as defined in section 6 of RFC 3986. > (Note that only parts of a URI are actually case-insensitive and that > there are other sources of variations for the same URI.) Very much so. In general, URIs are case sensitive. Also, in general, there are occasions where every case in every character counts. As an example, http://www.w3.org/1999/xhtml is the XML namespace for XHTML 1.0. If you click on http://Www.w3.org/1999/xhtml (note an uppercase 'W'), you get to the same page, but that URI won't be accepted as the XHTML 1.0 namespace URI, because XML namespaces are compared character-by-character, case-sensitively. For more details on URI comparison, please see Section 6, Normalization and Comparison, of http://www.ietf.org/rfc/rfc3986.txt. >c) I fail to see why we have a definition for a URI and a URL. RFC 3986 > says in section 1.1.3: > > [...] Future specifications and related documentation should > use the general term "URI" rather than the more restrictive terms > "URL" and "URN" [RFC3305]. > > There is more text in the RFC which explains that the distinction of > different classes of URIs is not very useful. I already agreed to that in another post! Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 02:49:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8T-0005tR-8a; Fri, 10 Nov 2006 02:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiR8R-0005sq-IO for ltru@ietf.org; Fri, 10 Nov 2006 02:49:11 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiR8O-00023O-SJ for ltru@ietf.org; Fri, 10 Nov 2006 02:49:11 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAA7n7OQ003679 for ; Fri, 10 Nov 2006 16:49:07 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 159e_f1dc505e_708f_11db_9567_0014221f2a2d; Fri, 10 Nov 2006 16:49:07 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56094) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Nov 2006 16:48:37 +0900 Message-Id: <6.0.0.20.2.20061110161109.05036c10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 10 Nov 2006 16:13:31 +0900 To: "David McWalter" , "Randy Presuhn" , "Bill Fenner" , , From: Martin Duerst Subject: RE: [Ltru] Re: Language Tag MIB Textual Convention In-Reply-To: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B46@enfimail2.datcon.co .uk> References: <012201c702ff$20472d00$6601a8c0@oemcomputer> <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B46@enfimail2.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: LTRU Working Group , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello David, Randy (who, in contrast to me, is a MIB expert) has spotted most of the language-tag related issues. Just one more issue below. At 11:21 06/11/09, David McWalter wrote: >LANGTAG-MIB DEFINITIONS ::= BEGIN > >IMPORTS > MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI > TEXTUAL-CONVENTION FROM SNMPv2-TC; > >langTagMIB MODULE-IDENTITY > LAST-UPDATED "200611080000Z" -- 8 November 2006 > ORGANIZATION "IETF Operations and Management Area" > CONTACT-INFO "EMail: ops-area@ietf.org" > DESCRIPTION > "The MIB module defines textual conventions for representing > generic tags." What kind of 'generic tags'? Can you please change this to DESCRIPTION "The MIB module defines textual conventions for representing generic language tags." Maybe the 'generic' can even be left out, I wouldn't know what it refers to (there are not 'specific' language tags). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 09:50:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXiT-0001WH-Uq; Fri, 10 Nov 2006 09:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXiR-0001Vr-GE; Fri, 10 Nov 2006 09:50:47 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXUs-0003Xm-5V; Fri, 10 Nov 2006 09:36:50 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GiXUr-0004OG-Cj; Fri, 10 Nov 2006 09:36:45 -0500 Date: Fri, 10 Nov 2006 09:36:45 -0500 To: Martin Duerst Message-ID: <20061110143645.GF610@ccil.org> References: <6.0.0.20.2.20061110152717.19ee8690@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061110152717.19ee8690@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: j.schoenwaelder@iu-bremen.de, LTRU Working Group , DMcW@dataconnection.com, Bill Fenner , MIB Doctors , "Romascanu, Dan \(Dan\)" , kessler@cisco.com Subject: [Ltru] Language-tag base URI (was: Language Tag MIB Textual Convention) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > But language tags are not URIs, Hmm. Syntactically, they look like relative references. Perhaps 4646bis should define a base URI so that people who want to use URIs in place of language tags have an easy way to do so? http://www.iana.org/assignments/language-tags/ is available. -- So that's the tune they play on John Cowan their fascist banjos, is it? cowan@ccil.org --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 Fri Nov 10 09:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXqh-0005pv-0A; Fri, 10 Nov 2006 09:59:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXqf-0005pm-J7; Fri, 10 Nov 2006 09:59:17 -0500 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXqe-0007n6-6r; Fri, 10 Nov 2006 09:59:17 -0500 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Fri, 10 Nov 2006 14:59:06 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J8I004PWSAI16@eupig2.dtc.lon.ime.reuters.com>; Fri, 10 Nov 2006 14:59:06 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 10 Nov 2006 14:59:06 +0000 Date: Fri, 10 Nov 2006 14:59:05 +0000 From: Misha Wolf Subject: RE: [Ltru] Language-tag base URI (was: Language Tag MIB Textual Convention) To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Language-tag base URI (was: Language Tag MIB Textual Convention) Thread-Index: AccE18xw/XODKHYwSsmowOvY2b06+wAAKwzgAAAPWgA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Nov 2006 14:59:06.0623 (UTC) FILETIME=[C4E668F0:01C704D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: j.schoenwaelder@iu-bremen.de, DMcW@dataconnection.com, Bill Fenner , MIB Doctors , "Romascanu, Dan \(Dan\)" , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > http://www.iana.org/assignments/language-tags/ is available. but obsolete. Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 14:11:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibmE-0004FI-Lf; Fri, 10 Nov 2006 14:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJB-0006Rs-LC; Fri, 10 Nov 2006 13:40:57 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gib74-0004LG-81; Fri, 10 Nov 2006 13:28:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5568C5AF0F; Fri, 10 Nov 2006 19:28:23 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31142-03; Fri, 10 Nov 2006 19:28:18 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 89C225AF1B; Fri, 10 Nov 2006 19:28:18 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 99EEA8C3630; Fri, 10 Nov 2006 19:28:18 +0100 (CET) Date: Fri, 10 Nov 2006 19:28:18 +0100 From: Juergen Schoenwaelder To: David McWalter Message-ID: <20061110182818.GC11161@boskop.local> Mail-Followup-To: David McWalter , Randy Presuhn , "Romascanu, Dan (Dan)" , LTRU Working Group , MIB Doctors , Bill Fenner References: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B59@enfimail2.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AC1AD08D396174DBC4E6D44EFACCFB1DB4B59@enfimail2.datcon.co.uk> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Fri, 10 Nov 2006 14:10:57 -0500 Cc: "Romascanu, Dan \(Dan\)" , Bill Fenner , LTRU Working Group , MIB Doctors Subject: [Ltru] Re: Language Tag MIB Textual Convention X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: 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, Nov 10, 2006 at 02:55:02AM -0000, David McWalter wrote: > We're not resolved on whether LanguageTag and uri/url belong in the > same MIB module. > - Dan was happy to see a new module with LanguageTag and uri/url. > - Juergen prefers an InetUri in INET-ADDRESS-MIB. Here is my reading of the situation: (a) I suggested to use the INET-ADDRESS-MIB for an InetUri since URIs can be seen as an application layer addressing mechanism and hence I believe this fits. (b) Dan seems to prefer a separate document which I do not object to. (c) I remain unconvinced that a URI TC belongs into a language tag module. /js -- Juergen Schoenwaelder International University Bremen (Jacobs University Bremen as of Spring 2007) P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 14:11:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibmE-0004Ek-I6; Fri, 10 Nov 2006 14:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXow-00052y-KP; Fri, 10 Nov 2006 09:57:30 -0500 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXov-0007Yv-7y; Fri, 10 Nov 2006 09:57:30 -0500 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Fri, 10 Nov 2006 14:57:27 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J8I0011OS7RXN@eupig2.dtc.lon.ime.reuters.com>; Fri, 10 Nov 2006 14:57:27 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 10 Nov 2006 14:57:26 +0000 Date: Fri, 10 Nov 2006 14:57:25 +0000 From: Misha Wolf Subject: RE: [Ltru] Language-tag base URI (was: Language Tag MIB Textual Convention) To: John Cowan , Martin Duerst Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Language-tag base URI (was: Language Tag MIB Textual Convention) Thread-Index: AccE18xw/XODKHYwSsmowOvY2b06+wAAKwzg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Nov 2006 14:57:26.0873 (UTC) FILETIME=[8971C490:01C704D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 10 Nov 2006 14:10:57 -0500 Cc: j.schoenwaelder@iu-bremen.de, LTRU Working Group , DMcW@dataconnection.com, Bill Fenner , Doctors , MIB, "Romascanu, Dan \(Dan\)" , kessler@cisco.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > http://www.iana.org/assignments/language-tags/ is available. but obsolete. Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 16:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gidd2-0003DD-Vb; Fri, 10 Nov 2006 16:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gidd2-0003D8-C7 for ltru@ietf.org; Fri, 10 Nov 2006 16:09:36 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gidcz-0000wv-4j for ltru@ietf.org; Fri, 10 Nov 2006 16:09:36 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gidcy-0002zh-2y for ltru@ietf.org; Fri, 10 Nov 2006 16:09:32 -0500 Date: Fri, 10 Nov 2006 16:09:31 -0500 To: ltru@ietf.org Message-ID: <20061110210931.GD25065@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It is now clear to me, from postings on ietf-languages and here, and from reading ISO 19524, that neither a blanket script code element for phonetic alphabets, nor individual script code elements for them, are going to be allocated within the 19524 framework. We now have three choices: 1) Use variant subtags and leave specific registration issues up to ietf-languages (in some cases, stacked variant subtags may be useful). 2) Do an end-run around ISO 15924 by allowing a registration procedure for script subtags using some syntax other than 4ALPHA, perhaps 1ALPHA + 3alphanum. 3) Do nothing. I think #2 would be a serious mistake, and when I think about some of the variants we now have, I no longer believe that #1 is truly problematic. -- If you understand, John Cowan things are just as they are; http://www.ccil.org/~cowan if you do not understand, cowan@ccil.org things are just as they are. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 16:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GidsX-0005Cq-8S; Fri, 10 Nov 2006 16:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GidsV-0005AT-K1 for ltru@ietf.org; Fri, 10 Nov 2006 16:25:35 -0500 Received: from mail6.microsoft.com ([205.248.106.32] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GidsS-00056d-8f for ltru@ietf.org; Fri, 10 Nov 2006 16:25:35 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.15; Fri, 10 Nov 2006 13:25:31 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:25:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Phonetic transcriptions: clearing the decks Date: Fri, 10 Nov 2006 13:24:47 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10977D08C@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <20061110210931.GD25065@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Phonetic transcriptions: clearing the decks Thread-Index: AccFDKzLPSYvWw4ZQrSephwDCINdAAAAcMYw From: Peter Constable To: John Cowan , X-OriginalArrivalTime: 10 Nov 2006 21:25:31.0530 (UTC) FILETIME=[C02E76A0:01C7050E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You're giving up when we have only really begun to engage with the 15924 RA to discuss this? "Make no little plans; they have no power to fire men's blood." =20 ;-) Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Friday, November 10, 2006 1:10 PM To: ltru@ietf.org Subject: [Ltru] Phonetic transcriptions: clearing the decks It is now clear to me, from postings on ietf-languages and here, and from reading ISO 19524, that neither a blanket script code element for phonetic alphabets, nor individual script code elements for them, are going to be allocated within the 19524 framework. We now have three choices: 1) Use variant subtags and leave specific registration issues up to ietf-languages (in some cases, stacked variant subtags may be useful). 2) Do an end-run around ISO 15924 by allowing a registration procedure for script subtags using some syntax other than 4ALPHA, perhaps 1ALPHA + 3alphanum. 3) Do nothing. I think #2 would be a serious mistake, and when I think about some of the variants we now have, I no longer believe that #1 is truly problematic. --=20 If you understand, John Cowan things are just as they are; http://www.ccil.org/~cowan if you do not understand, cowan@ccil.org things are just as they are. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 16:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie3Y-0001wX-6M; Fri, 10 Nov 2006 16:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie3X-0001uL-Rz for ltru@lists.ietf.org; Fri, 10 Nov 2006 16:36: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 1Gie3W-0007mn-IR for ltru@lists.ietf.org; Fri, 10 Nov 2006 16:36:59 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gie3Q-00024t-BV for ltru@lists.ietf.org; Fri, 10 Nov 2006 22:36:52 +0100 Received: from du-001-122.access.de.clara.net ([212.82.227.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Nov 2006 22:36:52 +0100 Received: from nobody by du-001-122.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Nov 2006 22:36:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 10 Nov 2006 22:32:53 +0100 Organization: Lines: 32 Message-ID: <4554F005.416E@xyzzy.claranet.de> References: <20061110210931.GD25065@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-122.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > We now have three choices: > 1) Use variant subtags and leave specific registration issues up to > ietf-languages (in some cases, stacked variant subtags may be useful). I'm not sure what stacked variant subtags are, is that something like variant phonetic, prefix *-Latn, variant ipa01, prefix *-Latn-phonetic ? No registered variant has a prefix starting with a wildcard at the moment, and introducing that would be utter dubious. [...] > 3) Do nothing. > I think #2 would be a serious mistake +1 > when I think about some of the variants we now have, I no longer > believe that #1 is truly problematic. Why are "stacked variant subtags" better than a proper extension, something in the direction of p-ipa (instead of phonetic-ipa01) ? We could even start that "p-" extension registry by a more creative interpretation of the WG Charter. Or as an individual submission. Frank (not volunteering for anything related to p-issues) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 16:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie6O-0004Hq-2N; Fri, 10 Nov 2006 16:39:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie6N-0004HD-4r for ltru@ietf.org; Fri, 10 Nov 2006 16:39:55 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gie6L-0008W1-UV for ltru@ietf.org; Fri, 10 Nov 2006 16:39:55 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gie6L-0003z5-Lv; Fri, 10 Nov 2006 16:39:53 -0500 Date: Fri, 10 Nov 2006 16:39:53 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks Message-ID: <20061110213953.GG25065@ccil.org> References: <20061110210931.GD25065@ccil.org> <4554F005.416E@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4554F005.416E@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Frank Ellermann scripsit: > No registered variant has a prefix starting with a wildcard at the > moment, and introducing that would be utter dubious. True. I was actually thinking about en-US-american-kandk vs. en-US-american-trasmith. > We could even start that "p-" extension registry by a more creative > interpretation of the WG Charter. Or as an individual submission. Yes, that is a fourth option. I think phonetic transcription is not orthogonal enough to justify the use of an extension, however. -- At the end of the Metatarsal Age, the dinosaurs John Cowan abruptly vanished. The theory that a single cowan@ccil.org catastrophic event may have been responsible http://www.ccil.org/~cowan has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 17:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GieTX-0003Be-RR; Fri, 10 Nov 2006 17:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GieTU-00037x-0O for ltru@ietf.org; Fri, 10 Nov 2006 17:03:48 -0500 Received: from mailb.microsoft.com ([205.248.106.30] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GieGt-0002Vd-SD for ltru@ietf.org; Fri, 10 Nov 2006 16:50:50 -0500 Received: from mailout4.microsoft.com (157.57.217.12) by SVC-EXGWY-E802.partners.extranet.microsoft.com (10.251.24.243) with Microsoft SMTP Server id 8.0.685.15; Fri, 10 Nov 2006 13:50:47 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:50:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Phonetic transcriptions: clearing the decks Date: Fri, 10 Nov 2006 13:49:55 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10977D0FA@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <20061110213953.GG25065@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Phonetic transcriptions: clearing the decks Thread-Index: AccFEMw3kaO54s/aTam55lUctF/U4wAAErsg From: Peter Constable To: X-OriginalArrivalTime: 10 Nov 2006 21:50:47.0037 (UTC) FILETIME=[477E7AD0:01C70512] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 was thinking you had in mind a variant subtag to capture all (Latin-based) phonetic transcriptions just as Latp would have done; e.g. something like=20 en-latnphon-amtrsmth=20 en-latnphon-amkandk (An extension in conjuction with this, e.g. en-latnphon-p-american-kandk, would be another possibility.) That would allow implementations one subtag they could look for to filter out phonetic transcriptions. Evidently that isn't what you were thinking; but I continue to think there's value in having one subtag to identify this general class of content, so if we are left without any solution from 15924 then I'd still suggest something like this. Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Friday, November 10, 2006 1:40 PM To: Frank Ellermann Cc: ltru@ietf.org Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks Frank Ellermann scripsit: > No registered variant has a prefix starting with a wildcard at the > moment, and introducing that would be utter dubious. True. I was actually thinking about en-US-american-kandk vs. en-US-american-trasmith. > We could even start that "p-" extension registry by a more creative > interpretation of the WG Charter. Or as an individual submission. Yes, that is a fourth option. I think phonetic transcription is not orthogonal enough to justify the use of an extension, however. --=20 At the end of the Metatarsal Age, the dinosaurs John Cowan abruptly vanished. The theory that a single cowan@ccil.org catastrophic event may have been responsible http://www.ccil.org/~cowan has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 19:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigip-0000zG-1x; Fri, 10 Nov 2006 19:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigin-0000yz-Jj for ltru@ietf.org; Fri, 10 Nov 2006 19:27:45 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gigim-0006XF-8b for ltru@ietf.org; Fri, 10 Nov 2006 19:27:45 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kAB0RDcf041686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Nov 2006 16:27:13 -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=LpXtuxgJqza/z2BER2wljAQYPmlHick02NZE57MF9G7eM8AATJlUsRoPGQ5SM6Kk Message-ID: <455518E0.40209@yahoo-inc.com> Date: Fri, 10 Nov 2006 16:27:12 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks References: <20061110210931.GD25065@ccil.org> In-Reply-To: <20061110210931.GD25065@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Number 2 is a non-starter for me. I think we have plenty of workarounds as it is. This case doesn't strike me as compelling enough to warrant one. I note that #1 is a variation of #3: we do nothing, occasionally ietf-languages will be petitioned to approve (or not) various ugly sugtags for specialists interested in such things. I note that elsewhere some have cited the possibility of an extension. Interestingly, I think this also falls under the rubric of #3, since it is an activity that we can encourage others to take up. I rather like the idea of "banishing" transcriptions (phonetic or otherwise) to an extension. Addison John Cowan wrote: > It is now clear to me, from postings on ietf-languages and here, and from > reading ISO 19524, that neither a blanket script code element for phonetic > alphabets, nor individual script code elements for them, are going to be > allocated within the 19524 framework. > > We now have three choices: > > 1) Use variant subtags and leave specific registration issues up to > ietf-languages (in some cases, stacked variant subtags may be useful). > > 2) Do an end-run around ISO 15924 by allowing a registration procedure > for script subtags using some syntax other than 4ALPHA, perhaps > 1ALPHA + 3alphanum. > > 3) Do nothing. > > I think #2 would be a serious mistake, and when I think about some of > the variants we now have, I no longer believe that #1 is truly problematic. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 19:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigvx-0002Eb-BF; Fri, 10 Nov 2006 19:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigvv-0002EV-PP for ltru@ietf.org; Fri, 10 Nov 2006 19:41:19 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gigvu-0007R5-E7 for ltru@ietf.org; Fri, 10 Nov 2006 19:41:19 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ShKQPeQbOgXaTciMugf2o72O1Aix44dbBamHjUFxsPYqHNgtLzsvalHqVKmHFTJa; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.43] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gigvt-0005H0-TB for ltru@ietf.org; Fri, 10 Nov 2006 19:41:18 -0500 Message-ID: <003701c7052a$2bb9a320$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <19A328037921AA42847A717566D1D6A10977D0FA@RED-MSG-42.redmond.corp.microsoft.com> Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks Date: Fri, 10 Nov 2006 16:41:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6bfe3213185e00ad197f1775383366b16350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.43 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Sent: Friday, November 10, 2006 1:49 PM > Subject: RE: [Ltru] Re: Phonetic transcriptions: clearing the decks > > I was thinking you had in mind a variant subtag to capture all > (Latin-based) phonetic transcriptions just as Latp would have done; e.g. > something like > > en-latnphon-amtrsmth > en-latnphon-amkandk I think a solution like this would be fairly good, especially if it appears the the resistance to registering a script code may be insurmountable. However, for the languages that lack Supress-Script, would anything unexpected happen? Beyond that, a few hypothetical test cases to consider: Russian transcribed using IPA, further details unknown Latin-based transcription of Russian, but manifestly not IPA Mongolian transcribed using IPA Latin-based transcription of Mongolian, but not IPA Cyrillic transcription of Mongolian, but not "standard" orthography With some of these, might the answer be "we don't need to be able to distinguish these?" > (An extension in conjuction with this, e.g. > en-latnphon-p-american-kandk, would be another possibility.) That would > allow implementations one subtag they could look for to filter out > phonetic transcriptions. > > Evidently that isn't what you were thinking; but I continue to think > there's value in having one subtag to identify this general class of > content, so if we are left without any solution from 15924 then I'd > still suggest something like this. ... "One" or "a very small number" would both work for me, when I think back on the work I did with this sort of stuff. For example, splitting things somewhat arbitrarily into phonetic, phonemic, and "pragmatic" (or ad hoc) transcriptions wouldn't have bothered me, nor would breaking them into large families based on the nominal script. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 10 19:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gih0m-0006at-HP; Fri, 10 Nov 2006 19:46:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gih0l-0006an-Dw for ltru@ietf.org; Fri, 10 Nov 2006 19:46:19 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gih0h-0007oR-Nz for ltru@ietf.org; Fri, 10 Nov 2006 19:46:19 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UDKUUoV7D7pLeNXmfn2CyP/q0UBo9K4yzCHnAdohAiG8M3duotmSQE3aVk2mqHbh; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.43] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gih0f-00016I-0m for ltru@ietf.org; Fri, 10 Nov 2006 19:46:13 -0500 Message-ID: <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks Date: Fri, 10 Nov 2006 16:46:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6b789b69110e5bad1273c9866d07e247e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.43 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair... > From: "Addison Phillips" > To: "John Cowan" > Cc: > Sent: Friday, November 10, 2006 4:27 PM > Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks ... > I note that elsewhere some have cited the possibility of an extension. > Interestingly, I think this also falls under the rubric of #3, since it > is an activity that we can encourage others to take up. I rather like > the idea of "banishing" transcriptions (phonetic or otherwise) to an > extension. ... Our WG charter says: The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. I would hope we'd be able to give more useful /specific guidance than just saying "use extensions". Do you have some specific text you'd like to propose? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 02:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GinfQ-00043V-DR; Sat, 11 Nov 2006 02:52:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GinfP-00043P-4f for ltru@ietf.org; Sat, 11 Nov 2006 02:52:43 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GinfL-0007Yj-PG for ltru@ietf.org; Sat, 11 Nov 2006 02:52:43 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20061111074135.OOHB25578.mta15.adelphia.net@DGBP7M81> for ; Sat, 11 Nov 2006 02:41:35 -0500 Message-ID: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 10 Nov 2006 23:52:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ltru] Re: Language-tag base URI (was: Language Tag MIB Textual Convention) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> But language tags are not URIs, > > Hmm. Syntactically, they look like relative references. Perhaps > 4646bis should define a base URI so that people who want to use URIs > in place of language tags have an easy way to do so? > > http://www.iana.org/assignments/language-tags/ is available. One well-known problem with http-style URIs like this is that people expect them to resolve to a resource, and become convinced that something is wrong or broken when they don't. That is what would happen in this case, unless someone volunteers to create an addressable resource for every possible generative language tag. Another possibility is RFC 4151 "tag" URIs, which are intended to be identifiers only, and not supposed to resolve to any resource. A few examples, made up purely for illustration, might be: tag:iana.org,1995-07:lsr:en tag:iana.org,1995-07:lsr:zh-Hans I should point out that this has nothing to do with the proposal made repeatedly last year by JFC Morfin to reserve a singleton ("0-") to introduce an RFC 4151 tag URI to a language tag, which would have made every such language tag "unique across space and time" (as stated in RFC 4151) and would have defeated the purpose of tag matching (as well as breaking the syntax of RFC 4646). Using tag URIs for the MIB application is exactly the opposite: it would map language tags onto the tag URI structure, not the other way around. I guess I'll get some "semi-private," bcc-addressed spam in my bit bucket tomorrow. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 03:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giny8-0005Qk-BO; Sat, 11 Nov 2006 03:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giny6-0005Pn-Of for ltru@ietf.org; Sat, 11 Nov 2006 03:12:02 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giny4-0000zm-Dx for ltru@ietf.org; Sat, 11 Nov 2006 03:12:02 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20061111075557.CCCW11888.mta16.adelphia.net@DGBP7M81> for ; Sat, 11 Nov 2006 02:55:57 -0500 Message-ID: <006401c70569$10521bf0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 11 Nov 2006 00:12:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > We now have three choices: > > 1) Use variant subtags and leave specific registration issues up to > ietf-languages (in some cases, stacked variant subtags may be useful). > > 2) Do an end-run around ISO 15924 by allowing a registration procedure > for script subtags using some syntax other than 4ALPHA, perhaps 1ALPHA > + 3alphanum. > > 3) Do nothing. 4) Draft an RFC in accordance with RFC 4646, section 3.7, to establish a registering authority for extension subtags that would indicate various types of phonetic and/or phonemic transcription and/or transliteration standards, conventions, and schemes. Suggest a singleton such as "p-" for "phonetic" or "t-" for "transcription." The RFC would contain all the rules necessary for dealing with the variety of systems in use, and could incorporate multiple levels of sub-subtags if desired, similar to "stacked variants." Consumers of language tags that would find this type of information useful, such as the implementations Peter has been describing, would be expected to examine language tags for the "p-" or "t-" extensions, and not discard extensions indiscriminately. Hopefully this proposal is a bit more useful and specific than just saying "use extensions." :-) -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 04:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GipZb-0003OO-81; Sat, 11 Nov 2006 04:54:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GipZZ-0003OJ-VL for ltru@ietf.org; Sat, 11 Nov 2006 04:54:49 -0500 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GipZY-0004M2-Kn for ltru@ietf.org; Sat, 11 Nov 2006 04:54:49 -0500 Received: (qmail 59662 messnum 3616521 invoked from network[194.125.174.46/ts09-046.dublin.indigo.ie]); 11 Nov 2006 09:54:46 -0000 Received: from ts09-046.dublin.indigo.ie (HELO ?194.125.174.46?) (194.125.174.46) by mail16.svc.cra.dublin.eircom.net (qp 59662) with SMTP; 11 Nov 2006 09:54:46 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20611101552n69b5799aob620584ffe0ea12@mail.gmail.com> References: <19A328037921AA42847A717566D1D6A10977D072@RED-MSG-42.redmond.corp.microsoft.com> <30b660a20611101552n69b5799aob620584ffe0ea12@mail.gmail.com> Message-Id: <81781A72-62EF-4225-90F5-314F99585820@egt.ie> From: Marion Gunn Date: Sat, 11 Nov 2006 09:58:26 +0000 To: IETF Languages Discussion , LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: [Ltru] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1024415513==" Errors-To: ltru-bounces@ietf.org --===============1024415513== Content-Type: multipart/alternative; boundary=Apple-Mail-3-248312397 --Apple-Mail-3-248312397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed +1 On 10 Nov 2006, at 23:52, scr=EDobh Mark Davis: > +1 > > On 11/10/06, Peter Constable wrote: > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-=20 > bounces@alvestrand.no] On Behalf Of Michael Everson > > >>Perhaps the ISO 15924 RA would like to suggest a alternative =20 > solution to > >>its user community in view of the request for a solution? > > > > It's not the RA's job to do that, really. > > It *is* the RAs job to register tags that users want to use, and to =20= > service the user needs for which ISO 15924 was created. If the RA =20 > does't feel a particular user need should be met using the standard =20= > when users are suggesting that it should, then IMO the RA should be =20= > prepared to suggest where an alternative solution might lie. Just =20 > the the ISO 639 JAC needs to be prepared to do. > > > > However, I (for my part) did suggest that the > > following might be used: > > Yes, but users are saying these alone are not considered sufficient =20= > for the needs, and you have not provided a solution to that extent... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-3-248312397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 +1=A0
On 10 Nov = 2006, at 23:52, scr=EDobh Mark Davis:

+1

On 11/10/06, Peter Constable <petercon@microsoft.com> = wrote:
From: ietf-languages-bounce= s@alvestrand.no [mailto:ietf-languages-bounce= s@alvestrand.no] On Behalf Of Michael Everson =

>>Perhaps the ISO 15924 RA would like to suggest a = alternative solution to
>>its user community in view of the = request for a solution?
>
> It's not the RA's job to do = that, really.

It *is* the RAs job to register tags that users = want to use, and to service the user needs for which ISO 15924 was = created. If the RA does't feel a particular user need should be met = using the standard when users are suggesting that it should, then IMO = the RA should be prepared to suggest where an alternative solution might = lie. Just the the ISO 639 JAC needs to be prepared to do. =


> However, I (for my part) did suggest that the
> = following might be used:

Yes, but users are saying these alone = are not considered sufficient for the needs, and you have not provided a = solution to that = extent...

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

= --Apple-Mail-3-248312397-- --===============1024415513== 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 --===============1024415513==-- From ltru-bounces@ietf.org Sat Nov 11 05:23:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giq1W-0005HY-5i; Sat, 11 Nov 2006 05:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giq1U-0005Gf-Rp for ltru@ietf.org; Sat, 11 Nov 2006 05:23:40 -0500 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giq1S-0007uG-5r for ltru@ietf.org; Sat, 11 Nov 2006 05:23:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 847A14667; Sat, 11 Nov 2006 19:23:23 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20266-09; Sat, 11 Nov 2006 19:23:23 +0900 (JST) Received: from [10.0.0.72] (unknown [67.132.23.68]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 77652453A; Sat, 11 Nov 2006 19:23:22 +0900 (JST) Message-ID: <4555A494.2090006@w3.org> Date: Sat, 11 Nov 2006 19:23:16 +0900 From: Felix Sasaki Organization: W3C User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks References: <006401c70569$10521bf0$6501a8c0@DGBP7M81> In-Reply-To: <006401c70569$10521bf0$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to this proposal, since it would provide a clear point of reference (the "to be drafted" RFC) for whose who are interest in the values used as extension subtags, but *independently* of language tags, e.g. as part of a different field (I had brought this use case a while ago, giving an example from SSML). Felix Doug Ewell wrote: > John Cowan wrote: > >> We now have three choices: >> >> 1) Use variant subtags and leave specific registration issues up to >> ietf-languages (in some cases, stacked variant subtags may be useful). >> >> 2) Do an end-run around ISO 15924 by allowing a registration procedure >> for script subtags using some syntax other than 4ALPHA, perhaps 1ALPHA >> + 3alphanum. >> >> 3) Do nothing. > > 4) Draft an RFC in accordance with RFC 4646, section 3.7, to establish a > registering authority for extension subtags that would indicate various > types of phonetic and/or phonemic transcription and/or transliteration > standards, conventions, and schemes. Suggest a singleton such as "p-" > for "phonetic" or "t-" for "transcription." > > The RFC would contain all the rules necessary for dealing with the > variety of systems in use, and could incorporate multiple levels of > sub-subtags if desired, similar to "stacked variants." > > Consumers of language tags that would find this type of information > useful, such as the implementations Peter has been describing, would be > expected to examine language tags for the "p-" or "t-" extensions, and > not discard extensions indiscriminately. > > Hopefully this proposal is a bit more useful and specific than just > saying "use extensions." :-) > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 07:07:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girdw-0000Ry-QW; Sat, 11 Nov 2006 07:07:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Girdv-0000Rt-Rj for ltru@lists.ietf.org; Sat, 11 Nov 2006 07:07:27 -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 1Girdu-0001Su-IJ for ltru@lists.ietf.org; Sat, 11 Nov 2006 07:07:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Girdn-00087J-2v for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:07:19 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:07:19 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:07:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 11 Nov 2006 13:04:36 +0100 Organization: Lines: 21 Message-ID: <4555BC54.7FB1@xyzzy.claranet.de> References: <006401c70569$10521bf0$6501a8c0@DGBP7M81> <4555A494.2090006@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Felix Sasaki wrote: > +1 to this proposal, since it would provide a clear point of reference > (the "to be drafted" RFC) for whose who are interest in the values used > as extension subtags, but *independently* of language tags, e.g. as part > of a different field (I had brought this use case a while ago, giving an > example from SSML). Far better than the "stacked variant subtags" approach for this purpose. After the p- or t- or whatever you pick the extansions can have any form you like, one or more levels of 2..8 letters and digits, separated by a hyphen-minus. I looked into the SSML spec. only shortly, IIRC they use x-anything for anything that's not IPA, the "x-" part wouldn't fly with an extension registry for 4646 tags. But you can have a registered anything, and say that it would be used as x-anything in SSML, or as ...-p-anything in a language tag. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 07:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GisKX-0001Xp-Sr; Sat, 11 Nov 2006 07:51:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GisKX-0001Xj-0P for ltru@lists.ietf.org; Sat, 11 Nov 2006 07:51: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 1GisKU-0007hh-MU for ltru@lists.ietf.org; Sat, 11 Nov 2006 07:51:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GisKM-0005hE-T5 for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:51:18 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:51:18 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 13:51:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 11 Nov 2006 13:50:28 +0100 Organization: Lines: 21 Message-ID: <4555C714.1872@xyzzy.claranet.de> References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: Language-tag base URI X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > people expect them to resolve to a resource, and become convinced > that something is wrong or broken when they don't Of course, if you'd want only an identifier why start it with http: ? If you'd insist on http: let the URLs at least redirect to a better page than some err404.html. It would be also bad if .../Latn and .../Lala both result in a 404. > examples, made up purely for illustration, might be: > tag:iana.org,1995-07:lsr:en > tag:iana.org,1995-07:lsr:zh-Hans That's very near to this idea: http://article.gmane.org/gmane.ietf.languages/2983 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 13:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixAL-0002oh-MQ; Sat, 11 Nov 2006 13:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixAL-0002oA-B2 for ltru@ietf.org; Sat, 11 Nov 2006 13:01:17 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gix48-0006kK-PR for ltru@ietf.org; Sat, 11 Nov 2006 12:54:53 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gix47-0005TS-OU; Sat, 11 Nov 2006 12:54:51 -0500 Date: Sat, 11 Nov 2006 12:54:51 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Language-tag base URI Message-ID: <20061111175451.GC19627@ccil.org> References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> <4555C714.1872@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4555C714.1872@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Of course, if you'd want only an identifier why start it with http: ? I'm not particularly in love with http:. My point (which is not satisfied by a set of tag: or urn:ietf: URIs) is to provide a single *base* URI against which language tags can be resolved as relative references according to the rules of STD 66. > If you'd insist on http: let the URLs at least redirect to a better > page than some err404.html. It would be very easy to write a dynamic application that served that purpose. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan|cowan@ccil.org|ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 13:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixUz-0000HH-HW; Sat, 11 Nov 2006 13:22:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixUy-0000FP-6c for ltru@ietf.org; Sat, 11 Nov 2006 13:22:36 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GixUv-0002AI-SL for ltru@ietf.org; Sat, 11 Nov 2006 13:22:36 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GixUv-0006YR-Hn; Sat, 11 Nov 2006 13:22:33 -0500 Date: Sat, 11 Nov 2006 13:22:33 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks Message-ID: <20061111182233.GE19627@ccil.org> References: <006401c70569$10521bf0$6501a8c0@DGBP7M81> <4555A494.2090006@w3.org> <4555BC54.7FB1@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4555BC54.7FB1@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Far better than the "stacked variant subtags" approach for this purpose. Why? I never objected to extensions, but I have yet to see convincing use cases for them; they need to be about something related to, yet orthogonal with, ordinary language tags. Orthography is a mainstream language-tag concern. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 13:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixsy-0006q4-VG; Sat, 11 Nov 2006 13:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixsy-0006pq-1D for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:47: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 1Gixsw-00039I-OF for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:47:24 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gixsq-00052x-EO for ltru@lists.ietf.org; Sat, 11 Nov 2006 19:47:16 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:47:16 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:47:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 11 Nov 2006 19:45:29 +0100 Organization: Lines: 19 Message-ID: <45561A49.4147@xyzzy.claranet.de> References: <006401c70569$10521bf0$6501a8c0@DGBP7M81> <4555A494.2090006@w3.org> <4555BC54.7FB1@xyzzy.claranet.de> <20061111182233.GE19627@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> Far better than the "stacked variant subtags" approach for this purpose. > Why? Felix could reuse "extension subtags" as is for SSML, without first filtering out unrelated cruft (from his POV) like "1901" or "boont". The proposal to use fonXXXXX variants is a kludge, at best it could be a convention. An extension registry is something real, it has its own RfC, a maintenance procedure, it can get its own list for this purpose, it could be (in practice) managed by the SSML folks. Adding more work to the LSR list is no plan, "we" are unable to do the most simple tasks like decide about JPAN in time, or fill out other missing Suppress-Scripts. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 13:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixye-0001h7-1M; Sat, 11 Nov 2006 13:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixyd-0001h0-NG for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:53:15 -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 1Gixyc-0003zI-Ea for ltru@lists.ietf.org; Sat, 11 Nov 2006 13:53:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GixyT-0006Fx-2M for ltru@lists.ietf.org; Sat, 11 Nov 2006 19:53:05 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:53:05 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 19:53:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 11 Nov 2006 19:52:41 +0100 Organization: Lines: 10 Message-ID: <45561BF9.32DB@xyzzy.claranet.de> References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> <4555C714.1872@xyzzy.claranet.de> <20061111175451.GC19627@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: Language-tag base URI X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > *base* URI ACK, I forgot that, my reply was more about Doug's tag: proposal. In theory PURLs could do that if IANA doesn't like thousands of redirections on their server. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 14:47:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyot-0003GU-Gn; Sat, 11 Nov 2006 14:47:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyos-0003GO-P5 for ltru@ietf.org; Sat, 11 Nov 2006 14:47:14 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giyor-0004WF-Ex for ltru@ietf.org; Sat, 11 Nov 2006 14:47:14 -0500 Received: from [10.72.76.251] (snvvpn2-10-72-76-c251.corp.yahoo.com [10.72.76.251]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kABJktEi083294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 11:46:58 -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=Cd5i5B5G7ZRjZpWQBUGsRF5D67RAKTXDIXSwH0PRNFa4xx8WkfztjOp11tEOCtmc Message-ID: <455628AF.3000102@yahoo-inc.com> Date: Sat, 11 Nov 2006 11:46:55 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> In-Reply-To: <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org A co-chair asked: > > > I would hope we'd be able to give more useful /specific guidance > than just saying "use extensions". Do you have some specific text > you'd like to propose? > Uh... no. Or rather, I'm proposing we not have specific text in 4646bis. ietf-languages can accept or reject variants. Banning variants for transcriptions or transliterations outright might not be good policy. Deciding on this list that we won't specially encode transcriptions formally in 4646bis via some new or different procedure doesn't require a textual change to the document. That's what I'm proposing. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 14:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyqi-0004UA-86; Sat, 11 Nov 2006 14:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyqh-0004Po-Gn for ltru@ietf.org; Sat, 11 Nov 2006 14:49:07 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giyqg-0004gK-9w for ltru@ietf.org; Sat, 11 Nov 2006 14:49:07 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Giyqf-0000xB-P9; Sat, 11 Nov 2006 14:49:05 -0500 Date: Sat, 11 Nov 2006 14:49:05 -0500 To: Addison Phillips Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks Message-ID: <20061111194905.GG19627@ccil.org> References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> <455628AF.3000102@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455628AF.3000102@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Uh... no. Or rather, I'm proposing we not have specific text in 4646bis. > ietf-languages can accept or reject variants. Banning variants for > transcriptions or transliterations outright might not be good policy. > Deciding on this list that we won't specially encode transcriptions > formally in 4646bis via some new or different procedure doesn't require > a textual change to the document. That's what I'm proposing. +1 -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see cowan@ccil.org it? Is the bust of Sir Philip Crampton lyrical, http://ccil.org/~cowan epical or dramatic? If a man hacking in fury at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 15:27:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizRS-0007oj-Kw; Sat, 11 Nov 2006 15:27:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizRR-0007oc-Ji for ltru@ietf.org; Sat, 11 Nov 2006 15:27:05 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizRQ-0004y3-7C for ltru@ietf.org; Sat, 11 Nov 2006 15:27:05 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r1LyNHbMDNS6iBp1Jc//TDAA0JayiiPiJYQHCDIkGGMw4ixYaqNhCrIEZ3xf8158; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.5] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GizR0-0002BH-AT for ltru@ietf.org; Sat, 11 Nov 2006 15:26:38 -0500 Message-ID: <008501c705cf$c4593be0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> <455628AF.3000102@yahoo-inc.com> Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks Date: Sat, 11 Nov 2006 12:27:10 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee60f2d71aed9fbde618d637e8c5c195687350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: > Sent: Saturday, November 11, 2006 11:46 AM > Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks ... > Uh... no. Or rather, I'm proposing we not have specific text in 4646bis. > ietf-languages can accept or reject variants. Banning variants for > transcriptions or transliterations outright might not be good policy. > Deciding on this list that we won't specially encode transcriptions > formally in 4646bis via some new or different procedure doesn't require > a textual change to the document. That's what I'm proposing. So, with respect to our charter's statement that: The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. As co-chair, I ask: Are you suggesting that we request that the charter be updated to exclude handling of transliterations and transcriptions, and that we believe ietf-languages@iana.org will "do the right thing" using some unwritten framework to ensure that these are handled in a coherent manner? As a technical contributor, I say: Given the past difficulty ietf-languages@iana.org has had in handling transcriptions and transliterations in a coherent manner, I strongly believe that we can't just "punt" this issue. We have several very real examples to deal with, and the procedures in 4646bis should ensure that 1) those wishing to register a transliteration or transcription system have sufficient information to fill out a registration request 2) the resulting registrations will provide subtags useful for matching Simple cases we should be able to handle: - russian in unspecified latin-based transliteration - russian in unspecified latin-based phonetic transcription - russian in a specific latin-based transliteration (e.g., GOST 16876-71) - english in unspecified IPA (latin, if you will) phonetic transcription - english in unspecified IPA (latin, if you will) phonemic transcription - english in a specific latin-based phonemic transcription (e.g., trager-smith) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 15:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizUL-0002Gu-Ay; Sat, 11 Nov 2006 15:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizUJ-0002Go-Pj for ltru@lists.ietf.org; Sat, 11 Nov 2006 15:30:03 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizUI-0005n3-H5 for ltru@lists.ietf.org; Sat, 11 Nov 2006 15:30:03 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UTwmAzdEy7W7AzxVSyncZUZWlQadoljShMPDm1hNLKveiSsmKsjLeLxptxrGf2Qm; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.5] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GizUI-0004aL-0B for ltru@lists.ietf.org; Sat, 11 Nov 2006 15:30:02 -0500 Message-ID: <008601c705d0$3dce1180$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81><4555C714.1872@xyzzy.claranet.de> <20061111175451.GC19627@ccil.org> <45561BF9.32DB@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Language-tag base URI Date: Sat, 11 Nov 2006 12:30:34 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee62ad7b2a4a71cf1756e02b03ef1d2d7ab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... This thread's recent messages make no sense whatsoever to me. The only reason that language tags and URIs were mentioned together initially in this thread is that in the SNMP community, a need for for a few new datatypes has been recognized. One of them would be for language tags, and another for URIs. All they have in common is: - they're both TEXTUAL CONVENTIONS (the only way to do this kind of thing in SNMP SMI) - the underlying syntax is OCTET STRING (really the only choice for things like this in SNMP SMI - the other base types are far too constraining) - they *might* be defined in the same MIB module (though there is absolutely no technical requirement to do so, and absolutely no technical reason to not do so) There is no need whatsoever in the SNMP community to somehow associate or connect the two. The questions of datatypes for the two things simply happened to come up at about the same time. Randy > From: "Frank Ellermann" > To: > Sent: Saturday, November 11, 2006 10:52 AM > Subject: [Ltru] Re: Language-tag base URI > > John Cowan wrote: > > > *base* URI > > ACK, I forgot that, my reply was more about Doug's tag: proposal. > In theory PURLs could do that if IANA doesn't like thousands of > redirections on their server. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizoJ-0007Ft-Fi; Sat, 11 Nov 2006 15:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizoI-0007DM-2K for ltru@ietf.org; Sat, 11 Nov 2006 15:50:42 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizoG-0001x1-Rx for ltru@ietf.org; Sat, 11 Nov 2006 15:50:42 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GizoG-0002xZ-EB; Sat, 11 Nov 2006 15:50:40 -0500 Date: Sat, 11 Nov 2006 15:50:40 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: Language-tag base URI Message-ID: <20061111205040.GA7514@ccil.org> References: <20061111175451.GC19627@ccil.org> <45561BF9.32DB@xyzzy.claranet.de> <008601c705d0$3dce1180$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008601c705d0$3dce1180$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > This thread's recent messages make no sense whatsoever to me. Probably my fault. I was not trying to contribute to the MIB thread (as noted by the change in subject line). I was simply urging us to consider promulgating a base URI for language tags, so that language tags could be reinterpreted as relative references (per STD 66) in environments where URIs are a requirement. This then led to the notion of a set of dereferenceable Web resources which would produce a representation of any valid language tag based on the current LSR. I suppose this would require a change in charter. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 16:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj03k-0007Ph-Cj; Sat, 11 Nov 2006 16:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj03i-0007OD-Qw for ltru@lists.ietf.org; Sat, 11 Nov 2006 16:06:38 -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 1Gj03h-0000oY-5M for ltru@lists.ietf.org; Sat, 11 Nov 2006 16:06:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gj03U-0005Am-J9 for ltru@lists.ietf.org; Sat, 11 Nov 2006 22:06:24 +0100 Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 22:06:24 +0100 Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Nov 2006 22:06:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 11 Nov 2006 22:05:23 +0100 Organization: Lines: 20 Message-ID: <45563B13.587@xyzzy.claranet.de> References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> <455628AF.3000102@yahoo-inc.com> <008501c705cf$c4593be0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: >| The working group will examine, and if necessary clarify or adjust, >| procedures and guidelines with respect to extended language subtags >| and variant subtags. Use cases include the identification of >| signed languages, transliterations, and transcriptions. We've examined the issue to some degree, discussed various approaches how to integrate it into the 4646 framework, and finally arrived at a point where an extension-registry appears to be the or a part of the solution. John, Peter, you, and others just explore "or a part of" wrt a script variant on the LSR list. Maybe we could state that the existing rules like 3.7 are meant to be used for cases including transliterations and transcriptions. We've already discussed to rule out any kind of "generic" variant, I still think that's an excellent idea. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 17:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1cy-0005Nf-GE; Sat, 11 Nov 2006 17:47:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1cx-0005NX-HD for ltru@ietf.org; Sat, 11 Nov 2006 17:47:07 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1cw-0007FQ-5i for ltru@ietf.org; Sat, 11 Nov 2006 17:47:07 -0500 Received: from [10.72.76.251] (snvvpn2-10-72-76-c251.corp.yahoo.com [10.72.76.251]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kABMl3TG081942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 14:47:03 -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=1hqAqoHhYJ8Qz/ZT17FIszMWx73/nAHY85QRmQNpNIEkEbBohfbtMQBOUnc1D1Cg Message-ID: <455652E6.1030107@yahoo-inc.com> Date: Sat, 11 Nov 2006 14:47:02 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Phonetic transcriptions: clearing the decks References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com> <003c01c7052a$dbec24c0$6601a8c0@oemcomputer> <455628AF.3000102@yahoo-inc.com> <008501c705cf$c4593be0$6601a8c0@oemcomputer> In-Reply-To: <008501c705cf$c4593be0$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > > As co-chair, I ask: > Are you suggesting that we request that the charter be updated to > exclude handling of transliterations and transcriptions, and that > we believe ietf-languages@iana.org will "do the right thing" > using some unwritten framework to ensure that these are handled > in a coherent manner? No, not at all. Our charter asked us to consider these things. We have been and are considering them. I am proposing a specific solution. Sometimes not doing anything is a good solution to a problem. > > As a technical contributor, I say: > Given the past difficulty ietf-languages@iana.org has had in handling > transcriptions and transliterations in a coherent manner, I strongly > believe that we can't just "punt" this issue. We have several very > real examples to deal with, and the procedures in 4646bis should ensure > that > 1) those wishing to register a transliteration or transcription system > have sufficient information to fill out a registration request > 2) the resulting registrations will provide subtags useful for matching > > Simple cases we should be able to handle: > > - russian in unspecified latin-based transliteration > - russian in unspecified latin-based phonetic transcription > - russian in a specific latin-based transliteration (e.g., GOST 16876-71) > - english in unspecified IPA (latin, if you will) phonetic transcription > - english in unspecified IPA (latin, if you will) phonemic transcription > - english in a specific latin-based phonemic transcription (e.g., trager-smith) > Well, I'd go a bit farther. Perhaps we should add text saying that language tags by themselves are not suitable for identifying transcriptions or other very specific language "modes" (note that there are auditory equivalents to transcription, for example). It might be worthwhile to provide strongly language about the limits of language tags and their applicability. There is a limit to the expressiveness of any identifier system. Language tags are no exception. At a certain point, additional tag granularity begins to detract from the usefulness of the tags in general purpose systems. Specialized use (which may include transcriptions, etc.) may invite greater granularity. I think at some point it becomes useful to decide that the specialists SHOULD use an extension to prevent such narrow applications from interfering with user's (sometimes fragile) understanding of how to use and apply language tags in the most common cases. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 18:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2kY-0006VS-PC; Sat, 11 Nov 2006 18:59:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2kW-0006VH-LS for ltru@ietf.org; Sat, 11 Nov 2006 18:59:00 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj2kS-0002jW-PH for ltru@ietf.org; Sat, 11 Nov 2006 18:59:00 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kABNwhsi025987 for ; Sun, 12 Nov 2006 08:58:43 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 36c2_8fbbe45a_71e0_11db_85b4_0014221f2a2d; Sun, 12 Nov 2006 08:58:43 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49338) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 12 Nov 2006 08:58:13 +0900 Message-Id: <6.0.0.20.2.20061111204031.0fb02d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 11 Nov 2006 20:47:19 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Language-tag base URI (was: Language Tag MIB TextualConvention) In-Reply-To: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 16:52 06/11/11, Doug Ewell wrote: >One well-known problem with http-style URIs like this is that people Some people do, yes. Some people don't, depending on where they are used. >expect them to resolve to a resource, and become convinced that something is wrong or broken when they don't. That is what would happen in this case, unless someone volunteers to create an addressable resource for every possible generative language tag. It wouldn't take a lot of volunteers. It can be done with a simple script at a higher level in the hierarchy, which takes the rest of the URI path as an argument (PathInfo). >Another possibility is RFC 4151 "tag" URIs, which are intended to be identifiers only, and not supposed to resolve to any resource. A few examples, made up purely for illustration, might be: > >tag:iana.org,1995-07:lsr:en >tag:iana.org,1995-07:lsr:zh-Hans For this kind of thing, the IETF also has some kind of URN namespace. [I'm sure Frank will come up with the relevant RFC numbers in seconds.] Not that I'm particularly fond of URNs, quite to the contrary. But just so that it has been mentioned. >Using tag URIs for the MIB application is exactly the opposite: it would > map language tags onto the tag URI structure, not the other way around. There may be other people who want to use language tags as URIs, but the MIB people don't. The subject of a language tag MIB just came up together with an URI MIB because both language tags and URIs are basic datatypes for Internet applications. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 23:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6gz-00029G-Je; Sat, 11 Nov 2006 23:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6gy-000298-5l for ltru@ietf.org; Sat, 11 Nov 2006 23:11:36 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj6gw-0005Ez-Rq for ltru@ietf.org; Sat, 11 Nov 2006 23:11:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=p+B2kql/ctb1xwII7+R5TibZbSY672Lb6CADtQ89IM5W8YNpbrHgroxVDX5Zu0vi; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.209] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gj6gt-0007eb-65 for ltru@ietf.org; Sat, 11 Nov 2006 23:11:31 -0500 Message-ID: <003801c70610$ad161f20$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061111175451.GC19627@ccil.org> <45561BF9.32DB@xyzzy.claranet.de> <008601c705d0$3dce1180$6601a8c0@oemcomputer> <20061111205040.GA7514@ccil.org> Subject: Re: [Ltru] Re: Language-tag base URI Date: Sat, 11 Nov 2006 20:11: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6b388dd359cf4a9abeaee99bd0d2230b6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.209 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Saturday, November 11, 2006 12:50 PM > Subject: Re: [Ltru] Re: Language-tag base URI > > Randy Presuhn scripsit: > > > This thread's recent messages make no sense whatsoever to me. > > Probably my fault. I was not trying to contribute to the MIB > thread (as noted by the change in subject line). I was simply > urging us to consider promulgating a base URI for language > tags, so that language tags could be reinterpreted as relative > references (per STD 66) in environments where URIs are a requirement. > > This then led to the notion of a set of dereferenceable Web > resources which would produce a representation of any valid language > tag based on the current LSR. Ah, much clearer. Thank you for the clarification. > I suppose this would require a change in charter. We could request such an addition. Before doing so, however, I think we should, in this order: 1) complete our current work items 2) determine whether the need for these real or merely theoretical 3) determine whether the WG is interested in doing that work Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Nov 11 23:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6xn-0002Ie-6w; Sat, 11 Nov 2006 23:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6xm-0002IU-IK for ltru@lists.ietf.org; Sat, 11 Nov 2006 23:28:58 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj6xl-0000uj-9w for ltru@lists.ietf.org; Sat, 11 Nov 2006 23:28:58 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aiqC1d58+PC1PASafkY3BAhIqyIp3UkfmtvMt48cJh2jHg2N9dVPK5S3wIRSyVuc; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.209] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gj6xl-0002Tp-1w for ltru@lists.ietf.org; Sat, 11 Nov 2006 23:28:57 -0500 Message-ID: <004a01c70613$22b549c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061110210931.GD25065@ccil.org> <455518E0.40209@yahoo-inc.com><003c01c7052a$dbec24c0$6601a8c0@oemcomputer><455628AF.3000102@yahoo-inc.com><008501c705cf$c4593be0$6601a8c0@oemcomputer> <45563B13.587@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks Date: Sat, 11 Nov 2006 20:29:24 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee65582e12480e79a3b08f6d3503e1401fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.209 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Frank Ellermann" > To: > Sent: Saturday, November 11, 2006 1:05 PM > Subject: [Ltru] Re: Phonetic transcriptions: clearing the decks ... > We've examined the issue to some degree, discussed various approaches > how to integrate it into the 4646 framework, and finally arrived at a > point where an extension-registry appears to be the or a part of the > solution. John, Peter, you, and others just explore "or a part of" > wrt a script variant on the LSR list. I'm not convinced that an extension-registry is the right way to go. In particular, if we *did* endorse that approach, we'd need to change the matching stuff, since some of it would no longer be correct. For example, this paragraph from 4647 would be incorrect if extensions were used across the board for transliterations and transcriptions: When working with tags and ranges, note that extensions and most private-use subtags are orthogonal to language tag matching, in that they specify additional attributes of the text not related to the goals of most matching schemes. Users SHOULD avoid using these subtags in language ranges, since they interfere with the selection of available content. When used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering (Section 3), since they appear at the end of the tag and will match all prefixes. Lookup (Section 3.4) implementations are advised to ignore unrecognized private-use and extension subtags when performing language tag fallback. > Maybe we could state that the existing rules like 3.7 are meant to be > used for cases including transliterations and transcriptions. We've > already discussed to rule out any kind of "generic" variant, I still > think that's an excellent idea. I understand the reasoning behind the disdain for "generic" variants. I think transcriptions and transliterations are quite different beasts from what has been discussed as potential "generic" variants. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 12 10:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjHgY-0003IJ-Nf; Sun, 12 Nov 2006 10:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjHgX-0003IC-4j for ltru@lists.ietf.org; Sun, 12 Nov 2006 10:55:53 -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 1GjHgR-0006rD-Ov for ltru@lists.ietf.org; Sun, 12 Nov 2006 10:55:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjHgP-0004uG-KQ for ltru@lists.ietf.org; Sun, 12 Nov 2006 16:55:45 +0100 Received: from pd9fba965.dip0.t-ipconnect.de ([217.251.169.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 16:55:45 +0100 Received: from nobody by pd9fba965.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Nov 2006 16:55:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 12 Nov 2006 16:53:21 +0100 Organization: Lines: 33 Message-ID: <45574371.3186@xyzzy.claranet.de> References: <003801c70566$5a10ec10$6501a8c0@DGBP7M81> <6.0.0.20.2.20061111204031.0fb02d80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba965.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] OT: URN (was: Language-tag base URI) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> tag:iana.org,1995-07:lsr:en >> tag:iana.org,1995-07:lsr:zh-Hans > For this kind of thing, the IETF also has some kind of URN namespace. > [I'm sure Frank will come up with the relevant RFC numbers in seconds.] All credits for finding RFC 2648 to John, please: Otherwise it's in RFC 3553, urn:ietf:params: > Not that I'm particularly fond of URNs, quite to the contrary. Misha said something in the same direction. But I'm not sure that this stuff really "works", my attempt to register a URN for the RFC 2070 DTD under the RFC 3688 rules got a ticket IANA #17903, but otherwise it had no effect so far. Otherwise we'd see something in the direction of... urn:ietf:params:xml:pi:-:IETF:DTD+HTML+i18N:EN ...in . That's an issue for Harald's 2434bis, a registry SHOULD NOT start empty, unless its format is 100% clear (as for the 4646 extension registry). And it SHOULD try to list anything published before the new registry was created. How should the authors of 1738 or 2070 know that somebody created obscure NAPTR or publicid registries more than a decade later ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 12 15:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM6Z-00084r-SU; Sun, 12 Nov 2006 15:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM6Y-00083b-EF for ltru@ietf.org; Sun, 12 Nov 2006 15:39:02 -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 1GjM6T-0007og-5S for ltru@ietf.org; Sun, 12 Nov 2006 15:39:02 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005645242.msg for ; Sun, 12 Nov 2006 20:41:44 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sun, 12 Nov 2006 20:39:09 +0000 From: "Debbie Garside" To: , "'IETF Languages Discussion'" Date: Sun, 12 Nov 2006 20:38:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20061112202054.GA29783@sources.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccGmGVw//VHNpVKRiOs5gUTrNcObwAAH92A Message-ID: <49B9F024FE5A4245A57D1C2B168B3B31.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Sun, 12 Nov 2006 20:41:44 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sun, 12 Nov 2006 20:41:44 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: gerardm@wiktionaryz.org, ltru@ietf.org Subject: [Ltru] RE: Wikimedia language codes 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 Fair comment. But I think there is a high probability that this need will increase in the not too distant future. Perhaps IETF-languages and more importantly the LTRU WG should start at least thinking about how this need could possibly be met in the future by ISO DIS 639-6 without necessarily obstructing RFC4646bis. Now is the time to consider ISO 639-6 in order that any requests for changes to the data structure can be considered and implemented where necessary, not in a years time when it will be virtually set in stone. Best regards Debbie Garside (cross posted to LTRU WG) > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: 12 November 2006 20:21 > To: Debbie Garside > Cc: gerardm@wiktionaryz.org; ietf-languages@iana.org > Subject: Re: Wikimedia language codes > > On Sun, Nov 12, 2006 at 06:16:35PM -0000, Debbie Garside > wrote a message of 119 lines which said: > > > Your need is for ISO 639-6. This part of the ISO 639 family > is due for > > publication in January 2008. > > I do not think that the Wikimedia Foundation (which has the problem > now) can wait and I do not see why RFC 4646 does not solve > the technical side of the problem today. > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 12 22:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjSP9-0006g6-MA; Sun, 12 Nov 2006 22:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjSP7-0006fy-SL for ltru@ietf.org; Sun, 12 Nov 2006 22:22:37 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjSP5-0005M7-HK for ltru@ietf.org; Sun, 12 Nov 2006 22:22:37 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J7+j5nu5GTlRT9x2uWti+Xn5Pna2ixWmV3e+dq7MXvLkFRMygMLYjwmDsPnOUHZ5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.66] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GjSP4-0008WJ-Ak for ltru@ietf.org; Sun, 12 Nov 2006 22:22:34 -0500 Message-ID: <005d01c706d3$0b5da0e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <49B9F024FE5A4245A57D1C2B168B3B31.MAI@home> Date: Sun, 12 Nov 2006 19:23:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee69322146aab87a9ceb155c65a34cf6d6d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.66 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Wikimedia language codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Debbie Garside" > To: ; "'IETF Languages Discussion'" > Cc: > Sent: Sunday, November 12, 2006 12:38 PM > Subject: RE: Wikimedia language codes > > Fair comment. But I think there is a high probability that this need will > increase in the not too distant future. Perhaps IETF-languages and more > importantly the LTRU WG should start at least thinking about how this need > could possibly be met in the future by ISO DIS 639-6 without necessarily > obstructing RFC4646bis. > > Now is the time to consider ISO 639-6 in order that any requests for changes > to the data structure can be considered and implemented where necessary, not > in a years time when it will be virtually set in stone. ... Can anyone summarize the syntax of 639-6 identifiers for us? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 12 22:31:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjSXP-0002qM-Fi; Sun, 12 Nov 2006 22:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjSXO-0002p1-2V for ltru@ietf.org; Sun, 12 Nov 2006 22:31:10 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjSXM-0006qs-TC for ltru@ietf.org; Sun, 12 Nov 2006 22:31:10 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GjSXJ-0007IP-Qr; Sun, 12 Nov 2006 22:31:05 -0500 Date: Sun, 12 Nov 2006 22:31:05 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: Wikimedia language codes Message-ID: <20061113033105.GA27789@ccil.org> References: <49B9F024FE5A4245A57D1C2B168B3B31.MAI@home> <005d01c706d3$0b5da0e0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005d01c706d3$0b5da0e0$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Can anyone summarize the syntax of 639-6 identifiers for us? Four alphabetic characters; lower case is canonical. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan|cowan@ccil.org|ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 02:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjVwU-00027F-Cy; Mon, 13 Nov 2006 02:09:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjVwS-000245-G2 for ltru@ietf.org; Mon, 13 Nov 2006 02:09:16 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjVwQ-0005ZC-58 for ltru@ietf.org; Mon, 13 Nov 2006 02:09:16 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20061113065813.EOK25578.mta15.adelphia.net@DGBP7M81> for ; Mon, 13 Nov 2006 01:58:13 -0500 Message-ID: <006201c706f2$a0103ee0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 12 Nov 2006 23:09:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: Language-tag base URI X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > We could request such an addition. Before doing so, > however, I think we should, in this order: > 1) complete our current work items I strongly agree with this point, and to that end I'd like to ask the group again to take up the topic of what to do with the Description fields in the various ISO standards. We need to decide whether to use them as they are without changes, invert them, uninvert them, fix spelling and spacing, etc. I can't generate an update to 4645bis-draft-00 until these critical questions are resolved. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 04:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYDo-0007tp-53; Mon, 13 Nov 2006 04:35:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYDn-0007tk-35 for ltru@ietf.org; Mon, 13 Nov 2006 04:35:19 -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 1GjYDk-0000Z4-PT for ltru@ietf.org; Mon, 13 Nov 2006 04:35:19 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005654612.msg for ; Mon, 13 Nov 2006 09:38:13 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Mon, 13 Nov 2006 09:35:35 +0000 From: "Debbie Garside" To: , "'Randy Presuhn'" Subject: RE: [Ltru] Re: Wikimedia language codes Date: Mon, 13 Nov 2006 09:35:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <005d01c706d3$0b5da0e0$6601a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccG0yOwjR+7FBKZQz2x8n/lUsxrnwAL++wg Message-ID: <74D0333E8CA4425D9428EF56B90CF27C.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Mon, 13 Nov 2006 09:38:13 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Mon, 13 Nov 2006 09:38:15 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Randy wrote: > Can anyone summarize the syntax of 639-6 identifiers for us? At the moment it is alpha-4 but discussions are in progress as to whether there should be an extension coding aspect mapped to ISO 639-6. Best regards Debbie > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 06:51:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaLB-0002QN-Gy; Mon, 13 Nov 2006 06:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaLA-0002QA-27 for ltru@lists.ietf.org; Mon, 13 Nov 2006 06:51:04 -0500 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjaL8-0002YJ-LB for ltru@lists.ietf.org; Mon, 13 Nov 2006 06:51:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id A4F5947BB; Mon, 13 Nov 2006 20:50:47 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18526-13; Mon, 13 Nov 2006 20:50:47 +0900 (JST) Received: from [192.168.1.3] (p3157-ipad407marunouchi.tokyo.ocn.ne.jp [222.146.155.157]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 52C2747B4; Mon, 13 Nov 2006 20:50:47 +0900 (JST) Message-ID: <45585C14.3030309@w3.org> Date: Mon, 13 Nov 2006 20:50:44 +0900 From: Felix Sasaki Organization: W3C User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Phonetic transcriptions: clearing the decks References: <006401c70569$10521bf0$6501a8c0@DGBP7M81> <4555A494.2090006@w3.org> <4555BC54.7FB1@xyzzy.claranet.de> <20061111182233.GE19627@ccil.org> <45561A49.4147@xyzzy.claranet.de> In-Reply-To: <45561A49.4147@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > John Cowan wrote: > >>> Far better than the "stacked variant subtags" approach for this purpose. >> Why? I was on travel and did not participate in this thread for a day. But thank you for stating my position. Felix > > Felix could reuse "extension subtags" as is for SSML, without first > filtering out unrelated cruft (from his POV) like "1901" or "boont". > > The proposal to use fonXXXXX variants is a kludge, at best it could > be a convention. An extension registry is something real, it has > its own RfC, a maintenance procedure, it can get its own list for > this purpose, it could be (in practice) managed by the SSML folks. > > Adding more work to the LSR list is no plan, "we" are unable to > do the most simple tasks like decide about JPAN in time, or fill > out other missing Suppress-Scripts. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 09:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjcst-0002Om-VC; Mon, 13 Nov 2006 09:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjcst-0002Oh-ER for ltru@lists.ietf.org; Mon, 13 Nov 2006 09:34:03 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjcsn-0003PV-Hk for ltru@lists.ietf.org; Mon, 13 Nov 2006 09:34:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9571926C30E for ; Mon, 13 Nov 2006 15:33:36 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D01B126C23C for ; Mon, 13 Nov 2006 15:33:35 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id CD93158ED1A for ; Mon, 13 Nov 2006 15:33:35 +0100 (CET) Date: Mon, 13 Nov 2006 15:33:35 +0100 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20061113143335.GA4330@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-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: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Subject: [Ltru] [gerardm@wiktionaryz.org: WiktionaryZ language codes] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The criticisms of RFC 4646 and of the LSR are, I believe, relevant to this working group. --azLHFNyN32YCQGCU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from maya.nic.fr [192.134.4.160] by batilda.nic.fr with POP3 (fetchmail-6.3.4) for (single-drop); Mon, 13 Nov 2006 13:58:01 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id kADCoXh6929605 for ; Mon, 13 Nov 2006 13:50:33 +0100 (CET) Received: by relay1.nic.fr (Postfix) id 63149A1DB2F; Mon, 13 Nov 2006 13:56:37 +0100 (CET) Delivered-To: bortzmeyer@nic.fr Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by relay1.nic.fr (Postfix) with ESMTP id 61210A1DADD for ; Mon, 13 Nov 2006 13:56:37 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 5481E94443 for ; Mon, 13 Nov 2006 13:56:37 +0100 (CET) Received: by mx1.nic.fr (Postfix, from userid 100) id F036894444; Mon, 13 Nov 2006 13:56:33 +0100 (CET) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by mx1.nic.fr (Postfix) with ESMTP id C2EEC94443 for ; Mon, 13 Nov 2006 13:56:33 +0100 (CET) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B5A52596F8; Mon, 13 Nov 2006 13:53:35 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01444-07; Mon, 13 Nov 2006 13:53:34 +0100 (CET) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9A372596FA; Mon, 13 Nov 2006 13:53:18 +0100 (CET) X-Original-To: ietf-languages@alvestrand.no Delivered-To: ietf-languages@alvestrand.no Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B55662596F8 for ; Mon, 13 Nov 2006 13:53:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01444-04 for ; Mon, 13 Nov 2006 13:53:07 +0100 (CET) X-Greylist: from auto-whitelisted by SQLgrey-1.6.7 Received: from pechora1.icann.org (pechora1.icann.org [192.0.34.36]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AC382596F7 for ; Mon, 13 Nov 2006 13:53:05 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by pechora1.icann.org (8.13.7/8.13.7) with ESMTP id kADCttNT009637 for ; Mon, 13 Nov 2006 04:56:01 -0800 Received: from [62.195.155.247] (helo=[192.168.0.2]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GjbLt2dAD-00009e; Mon, 13 Nov 2006 13:55:54 +0100 Message-ID: <45586B49.7010203@wiktionaryz.org> Date: Mon, 13 Nov 2006 13:55:37 +0100 Old-From: Gerard Meijssen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ietf-languages@iana.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:528303289ead4d3089a048dec30d9d30 X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (pechora1.icann.org [192.0.34.36]); Mon, 13 Nov 2006 04:56:01 -0800 (PST) Cc: Old-Subject: WiktionaryZ language codes X-BeenThere: ietf-languages@alvestrand.no X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Language tag discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-languages-bounces@alvestrand.no Errors-To: ietf-languages-bounces@alvestrand.no X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-UIDL: 6d8590883ee6b9697894bcba6dedc891 X-Bogosity: Unsure, tests=bogofilter, spamicity=0.500000, version=1.0.2 Subject: WiktionaryZ language codes From: Gerard Meijssen Received-SPF: on batilda: SPF-pass localhost is always allowed. spfquery: localhost is always allowed. Received-SPF: pass (spfquery: localhost is always allowed.) client-ip=127.0.0.1; envelope-from=; helo=localhost; Hoi, Yesterday I posted very much for the Wikimedia Foundation about issues to do with the use of language codes at the Wikimedia Foundation. I am digesting the results so far. I am also very grateful for the many reactions. There are other issues but these will be for another e-mail. This e-mail is only about the needs of the WiktionaryZ project. FYI The WiktionaryZ project is currently not a Wikimedia Foundation project. ==WiktionaryZ project== Introduction The WiktionaryZ project is a project that came into being out of frustration with the Wiktionary projects. Currently there are 170 Wiktionary projects and all aim to include all words of all languages. WiktionaryZ aims to be able to include all information of all Wiktionaries and make this information available to people of all languages. Consequently, it can include both lexicological, terminological and ontological information. The first parts of the user interface are now in the UI as chosen by the user, or in English if we do not have the content in their language or it is pot luck what is provided. We are about to have the language names in the UI language localised shortly; the code has been written, it just needs to be committed to the life version. I have had the privilege to show the functional data design to the professors Alan K. Melby and Sue Ellen Wright in December 2005. It was a privilege; they questioned me during two evenings and then told me they liked what they had seen. Our content Our first content was done by importing the EIONET GEMET thesaurus. A new and growing community has been adding content and working on the existing content. We are now at the verge where we will be able to import other thesauri. It has taken us some nine months to grow from one initial thesaurus to the point where we can have multiple thesauri or collections in WiktionaryZ and not create utter chaos. The next thesauri will be truly big. NB I write this to help you appreciate that this is a serious project. Standards WiktionaryZ uses the ISO-639-3 list to indicate languages. For each language we have or will be building a portal. We start with adding content for a language when it is requested. A record indicating a language, dialect or orthography is added to a table and it includes the Wikimedia Foundation code and the ISO-639-3 code. We do distinguish American and British English from English and use codes like eng-US. It is obvious that we can add a column in this language table and have your code in there as well. The ISO-639-3 codes is the biggest list of languages that have some form of recognition. It is therefore our best option to adopt this for our initial list of languages. There are issues with several of these codes but it allows for an operational start. It also has in Ethnologue a maintainer that earned its reputation as an organisation with a strong interest in linguistics. A "simple" single code allows people to find their language. It also helps us to force people to understand that WiktionaryZ does not have zh or zho and that we consequently do not accept words to be registered in that way. The IANA language subtag registry is not a list that would work for us as is, because it is based solely on ISO-639-1 and ISO-639-2 and from our perspective these just do not cut it. The registry is very much incomplete and consequently it is not as usable as ISO-639-3. The format the registry is in, does not help either. It is not ready for use in databases. This is another reason that prevents the adoption of this list as a resource. Right, having "insulted" you all, let me bring the good news. As we are creating the Expressions for the ISO-639-3 languages, we tag them with their code as part of the ISO-639-3 collection. We are quite happy to have a "IANA language subtag" collection whereby we advertise these codes as well. Ideally every ISO-639-3 tagged language will have a IANA language subtag. We do support ISO-15924. As WiktionaryZ extends MediaWiki, we do support Unicode and at some stage we hope to support the CLDR in our sorting. In many of the answers to the Wikimedia Foundation mail, people referred to things like a ISO-639-5 and 6. WiktionaryZ is able to have relations between its "DefinedMeanings". I understand that ISO-639-6 has relations, we can include these relations in WiktionaryZ. It can be an unofficial playground for the content of this standard. It will however be used for WiktionaryZ practically. Remember, WiktionaryZ aims to have all words of all languages. Labelling words correctly is essential to make WiktionaryZ useful. There are two aspects to this; recognition of a specific orthography or dialect and having a good name for it. Another aspect of orthography is, that there are different types of orthography. There are official, constructed and used orthographies. Identifying a text correctly helps us in making them part of a corpus for such a resource. What motivates us to go this route of connecting to the standards may be found in the definition we have of success for our project: "Success is when people find a use for our data that we did not think of ourselves". By ensuring that we link to what is considered to be the/a standard we make it easier for WiktionaryZ to be successful. There are a few practical questions, let me quote from a request for the addition of languages that can be edited in: * mrc - Maricopa language. It has two main dialects, one in Salt River and one in Gila River. Both use the same alphabet. * ood - O'Odham language. It has three main dialects, Tohono (Desert), Akimel (River), and Hia C-ed (Sand). Language has two different alphabets in use -- one orthography, Saxton, is used nowadays just for Akimel in Gila River (and in older literature from other dialects). Alvarez-Hale orthography is used everywhere else for every dialect (including Akimel in Salt River), also by the most people. * apw - Western Apache language. It has 3 dialects, White Mountain, San Carlos, and Tonto. All use the same alphabet. * nav - Navajo language. Very little dialect variation. Just one alphabet. At this moment we have only accepted the Navajo language as a language to edit in. For the others (including dialects) we would like to know if they have been recognised. And if not, what it takes to get what you would consider appropriate codes. I am not sure what ISO ? standard would deal with dialects. Many languages like the Dutch language, have regular changes to the official orthography. For the Dutch language this happens every ten years. It is imho important to be able to tag text and words correctly to the orthography used. Only indicating something as Dutch is minimalistic and prevents the use of content for other purposes. It is not clear to me how you deal with this. It would not be surprised when this needs to be part of a standard too. Thanks, GerardM Sources: http://wiktionaryz.org http://wiktionary.org http://wiktionaryz.org/Category:Language_portals http://www.eionet.europa.eu/gemet http://www.iana.org/assignments/language-subtag-registry http://wiktionaryz.org/DefinedMeaning _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages --azLHFNyN32YCQGCU 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 --azLHFNyN32YCQGCU-- From ltru-bounces@ietf.org Mon Nov 13 15:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjibz-0003mo-71; Mon, 13 Nov 2006 15:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjibx-0003mj-VZ for ltru@ietf.org; Mon, 13 Nov 2006 15:40:57 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjibw-000574-MJ for ltru@ietf.org; Mon, 13 Nov 2006 15:40:57 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Z2iuCE6hElN88l7q0bMIKEDuF56Lgbpk2WRVapMFIfCZqX1/ONkxTdrnwKU3hE2o; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.84] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gjibq-00031w-Uo for ltru@ietf.org; Mon, 13 Nov 2006 15:40:51 -0500 Message-ID: <001f01c70763$e5605180$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20061113143335.GA4330@nic.fr> Subject: Re: [Ltru] [gerardm@wiktionaryz.org: WiktionaryZ language codes] Date: Mon, 13 Nov 2006 11:36:21 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee65aae60d7c03c763997d4a7922531965f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Stephane Bortzmeyer" > To: > Sent: Monday, November 13, 2006 6:33 AM > Subject: [Ltru] [gerardm@wiktionaryz.org: WiktionaryZ language codes] > > The criticisms of RFC 4646 and of the LSR are, I believe, relevant to > this working group. ... Are there any conclusions you would draw from his posting other than: (1) that we need to finish our current work items quickly to stave off gratuitously incompatible approaches like their suggested "eng-US" (2) that we need to remind those who complain about the registry's incompleteness that there are fairly simple procedures to request the addition of new subtags? (Or are these procedures not clear / prominent enough in RFC 4646?) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 16:32:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjPb-0008SJ-5Y; Mon, 13 Nov 2006 16:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjPZ-0008Mp-V6 for ltru@ietf.org; Mon, 13 Nov 2006 16:32:13 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjjPX-0003rO-9s for ltru@ietf.org; Mon, 13 Nov 2006 16:32:13 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 42A3A240817; Mon, 13 Nov 2006 22:32:08 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 3B09611C34; Mon, 13 Nov 2006 22:27:38 +0100 (CET) Date: Mon, 13 Nov 2006 22:27:38 +0100 From: Stephane Bortzmeyer To: Randy Presuhn Message-ID: <20061113212738.GC6389@sources.org> References: <20061113143335.GA4330@nic.fr> <001f01c70763$e5605180$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01c70763$e5605180$6601a8c0@oemcomputer> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group Subject: [Ltru] Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Nov 13, 2006 at 11:36:21AM -0800, Randy Presuhn wrote a message of 26 lines which said: > (2) that we need to remind those who complain about the registry's > incompleteness that there are fairly simple procedures to request > the addition of new subtags? (Or are these procedures not clear / > prominent enough in RFC 4646?) You mean to register variant subtags? Because, to register language subtags, it would not work, codes not in ISO 639-something would not be accepted, no? And I'm afraid some people would say that they do not want variants, "their" language "is a real language", and so on... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 16:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjpJ-0006Zx-4k; Mon, 13 Nov 2006 16:58:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjpI-0006ZB-9I for ltru@ietf.org; Mon, 13 Nov 2006 16:58:48 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjjpF-0007Ld-Ua for ltru@ietf.org; Mon, 13 Nov 2006 16:58:48 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kADLwX6q091745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 13:58:37 -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=nmIYScUgY5DBo5Tzk4jyQJYjzFM2lI0cQAJFTg3i4cEyeo5KBHklz7OKOVTWuxba Message-ID: <4558EA89.7030008@yahoo-inc.com> Date: Mon, 13 Nov 2006 13:58:33 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] References: <20061113143335.GA4330@nic.fr> <001f01c70763$e5605180$6601a8c0@oemcomputer> <20061113212738.GC6389@sources.org> In-Reply-To: <20061113212738.GC6389@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > On Mon, Nov 13, 2006 at 11:36:21AM -0800, > Randy Presuhn wrote > a message of 26 lines which said: > >> (2) that we need to remind those who complain about the registry's >> incompleteness that there are fairly simple procedures to request >> the addition of new subtags? (Or are these procedures not clear / >> prominent enough in RFC 4646?) > > You mean to register variant subtags? Because, to register language > subtags, it would not work, codes not in ISO 639-something would not > be accepted, no? > > And I'm afraid some people would say that they do not want variants, > "their" language "is a real language", and so on... > There *is* a registration process for language subtags, but it does require going to ISO 639 first. If the language is a "real language", presumably ISO 639 would register it. If they collect a rejection slip, they can proceed to (try to) register it via ietf-languages. If we finish our work on 4646bis, presumably very very very few languages would be able to collect the necessary rejection slip and still be registration-worthy. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 17:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjkAm-0002rG-8u; Mon, 13 Nov 2006 17:21:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjkAl-0002rA-5c for ltru@ietf.org; Mon, 13 Nov 2006 17:20:59 -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 1GjkAj-0001qy-Pb for ltru@ietf.org; Mon, 13 Nov 2006 17:20:59 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005672233.msg for ; Mon, 13 Nov 2006 22:23:46 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Mon, 13 Nov 2006 22:21:10 +0000 From: "Debbie Garside" To: , Date: Mon, 13 Nov 2006 22:20:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20061113212503.GB6389@sources.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccHbWRdwixPs9FcTwCjxim+W1serAAAOYkQ Message-ID: <2DCE13C0156D4FAEB202C4B6BD4CD840.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Mon, 13 Nov 2006 22:23:46 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Mon, 13 Nov 2006 22:23:47 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ietf-languages@alvestrand.no Subject: [Ltru] LTRU progress and ISO 639-6 (was WiktionaryZ language codes) 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 Stephane wrote: > > Can you send me details of the project? > > Attached. Ah! So you really mean LTRU! What exactly is going on with LTRU. There seems to be no progress being made at all. What has happened to issue tracker. How do we find out what the issues are and in what state of discussion they are in? Randy, Martin, I would really appreciate it if we could have a list of the issues and possible solutions. Or have I missed something? Are RFC4645/6bis on track without me realising? What are the timescales that we are now working to? When can we expect the next draft? Questions, questions! And why, when it is so relevant to all the variants currently under discussion (written/spoken/signed/orthographies/writing systems etc) is ISO 639-6 not being discussed? As I have mentioned, both on list and privately, ISO 639-6 is at a stage where this WG can have significant input. If members of this WG feel that there are elements of the 639-6 system that will be difficult to incorporate within RFC4646bis+ then I need to know NOW! If I do not hear to the contrary, I will assume that this WG has no problem with the current development of ISO 639-6 and will continue along the same vein. Having asked so many times for your input, I will be pretty mad if you come back in a years time and tell me it is not what you want. Debbie Garside Editor > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of > Stephane Bortzmeyer > Sent: 13 November 2006 21:25 > To: Debbie Garside > Cc: ietf-languages@alvestrand.no > Subject: Re: WiktionaryZ language codes > > On Mon, Nov 13, 2006 at 06:27:54PM -0000, Debbie Garside > wrote a message of 36 lines which said: > > > Can you send me details of the project? > > Attached. > > [It seems currently stalled.] > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 18:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjkp2-0008GP-PO; Mon, 13 Nov 2006 18:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjkp1-0008GI-0K for ltru@ietf.org; Mon, 13 Nov 2006 18:02:35 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjkoz-00074Q-MY for ltru@ietf.org; Mon, 13 Nov 2006 18:02:34 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Rc/XurUfbGskEZDdMwH+Tkvm1FpihT63NVlgqRf5aXdECPRjMLhFJtRuNr0pbO4i; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.149] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gjkoa-0007lD-P6 for ltru@ietf.org; Mon, 13 Nov 2006 18:02:09 -0500 Message-ID: <002901c70777$d4fcfa00$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20061113143335.GA4330@nic.fr> <001f01c70763$e5605180$6601a8c0@oemcomputer> <20061113212738.GC6389@sources.org> Date: Mon, 13 Nov 2006 14:31:41 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6cb8db6edeb77b00559cd9f61a9487fda350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.149 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Stephane Bortzmeyer" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Monday, November 13, 2006 1:27 PM > Subject: Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] > > On Mon, Nov 13, 2006 at 11:36:21AM -0800, > Randy Presuhn wrote > a message of 26 lines which said: > > > (2) that we need to remind those who complain about the registry's > > incompleteness that there are fairly simple procedures to request > > the addition of new subtags? (Or are these procedures not clear / > > prominent enough in RFC 4646?) > > You mean to register variant subtags? No. I'm referring specifically to RFC 4646 section 3.6 (first bullet). > Because, to register language > subtags, it would not work, codes not in ISO 639-something would not > be accepted, no? That's precisely why I'm referring to RFC 4646 section 3.6 (first bullet). > And I'm afraid some people would say that they do not want variants, > "their" language "is a real language", and so on... That's why I'm not talking about variants, even though in some cases they are clearly a better solution. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 18:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlMb-0000yU-VI; Mon, 13 Nov 2006 18:37:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlMa-0000xg-Fe for ltru@ietf.org; Mon, 13 Nov 2006 18:37:16 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjlMV-0003RH-U9 for ltru@ietf.org; Mon, 13 Nov 2006 18:37:16 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GjlMV-0005Gj-8O; Mon, 13 Nov 2006 18:37:11 -0500 Date: Mon, 13 Nov 2006 18:37:11 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] Message-ID: <20061113233711.GD3781@ccil.org> References: <20061113143335.GA4330@nic.fr> <001f01c70763$e5605180$6601a8c0@oemcomputer> <20061113212738.GC6389@sources.org> <002901c70777$d4fcfa00$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002901c70777$d4fcfa00$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i 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 Randy Presuhn scripsit: > No. I'm referring specifically to RFC 4646 section 3.6 (first bullet). That's a measure of last resort, and I would strenuously oppose any use of it whatsoever until RFC 4646bis is in effect. -- A few times, I did some exuberant stomping about, John Cowan like a hippo auditioning for Riverdance, though cowan@ccil.org I stopped when I thought I heard something at http://ccil.org/~cowan the far side of the room falling over in rhythm with my feet. -- Joseph Zitt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 21:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhI-0005zr-3C; Mon, 13 Nov 2006 21:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhH-0005yl-AE for ltru@ietf.org; Mon, 13 Nov 2006 21:06:47 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjnae-00084X-NW for ltru@ietf.org; Mon, 13 Nov 2006 20:59:59 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAE1xev2024683 for ; Tue, 14 Nov 2006 10:59:43 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 50ad_ca4b08a4_7383_11db_9de5_0014221fa3c9; Tue, 14 Nov 2006 10:59:40 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55567) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 14 Nov 2006 10:59:07 +0900 Message-Id: <6.0.0.20.2.20061114104923.07748220@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 14 Nov 2006 10:54:33 +0900 To: debbie@ictmarketing.co.uk, , From: Martin Duerst Subject: Re: [Ltru] LTRU progress and ISO 639-6 (was WiktionaryZ language codes) In-Reply-To: <2DCE13C0156D4FAEB202C4B6BD4CD840.MAI@home> References: <20061113212503.GB6389@sources.org> <2DCE13C0156D4FAEB202C4B6BD4CD840.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ietf-languages@alvestrand.no X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 07:20 06/11/14, Debbie Garside wrote: >Stephane wrote: > >> > Can you send me details of the project? >> >> Attached. > >Ah! So you really mean LTRU! > >What exactly is going on with LTRU. There seems to be no progress being >made at all. For several weeks before an IETF meeting, draft submission is closed. >What has happened to issue tracker. How do we find out what >the issues are and in what state of discussion they are in? I haven't officially tracked any issues, because they are still too much in flux. >Randy, Martin, I would really appreciate it if we could have a list of the >issues and possible solutions. Or have I missed something? Are RFC4645/6bis >on track without me realising? I think there are several areas of issues. Doug has sent a list that he need resolved for his next draft a few days ago. >What are the timescales that we are now working to? When can we expect the >next draft? Questions, questions! And why, when it is so relevant to all >the variants currently under discussion >(written/spoken/signed/orthographies/writing systems etc) is ISO 639-6 not >being discussed? I think one reason is that most people do not know very much about 639-6. If you don't mind, could you send a short summary of how 639-6 addresses things such as written/spoken/signed/orthographies/writing systems etc? With concrete examples, indicating whether these are currently in the draft or are hypothetical. I think that would help the WG to have a good disucussion. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 13 21:09:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhI-0005zs-5L; Mon, 13 Nov 2006 21:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhH-0005z5-BF for ltru@ietf.org; Mon, 13 Nov 2006 21:06:47 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjnae-00084Y-NX for ltru@ietf.org; Mon, 13 Nov 2006 20:59:59 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAE1xgqg024687 for ; Tue, 14 Nov 2006 10:59:43 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 513f_cb69b8e8_7383_11db_8f58_0014221fa3c9; Tue, 14 Nov 2006 10:59:42 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55567) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 14 Nov 2006 10:59:11 +0900 Message-Id: <6.0.0.20.2.20061114105518.07749110@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 14 Nov 2006 10:56:05 +0900 To: John Cowan , Randy Presuhn From: Martin Duerst Subject: Re: [Ltru] Re: [gerardm@wiktionaryz.org: WiktionaryZ language codes] In-Reply-To: <20061113233711.GD3781@ccil.org> References: <20061113143335.GA4330@nic.fr> <001f01c70763$e5605180$6601a8c0@oemcomputer> <20061113212738.GC6389@sources.org> <002901c70777$d4fcfa00$6601a8c0@oemcomputer> <20061113233711.GD3781@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 08:37 06/11/14, John Cowan wrote: >Randy Presuhn scripsit: > >> No. I'm referring specifically to RFC 4646 section 3.6 (first bullet). > >That's a measure of last resort, and I would strenuously oppose any use >of it whatsoever until RFC 4646bis is in effect. I agree that I would refuse separate registration of a language that's already included in 639-3 or has a good chance to get included there soon. 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 Nov 14 09:07:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjywe-00007L-J7; Tue, 14 Nov 2006 09:07:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjywd-00007G-Tl for ltru@ietf.org; Tue, 14 Nov 2006 09:07:23 -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 1GjywY-0007Y2-LH for ltru@ietf.org; Tue, 14 Nov 2006 09:07:23 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005688549.msg for ; Tue, 14 Nov 2006 14:10:17 +0000 Received: from debbie ([213.208.115.6]) by home with MailEnable ESMTP; Tue, 14 Nov 2006 14:07:42 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] LTRU progress and ISO 639-6 (was WiktionaryZ language codes) Date: Tue, 14 Nov 2006 14:05:09 -0000 Message-ID: <027a01c707f5$e540a730$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AccHkMSxzYqoceBWSFiKc0noHjYtGgAY5O2A In-Reply-To: <6.0.0.20.2.20061114104923.07748220@localhost> X-Spam-Processed: mx1.nexbyte.net, Tue, 14 Nov 2006 14:10:17 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: 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, 14 Nov 2006 14:10:18 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Martin wrote: >For several weeks before an IETF meeting, draft submission is closed. But that doesn't stop us discussing issues and updating the draft ready for submission. >I haven't officially tracked any issues, because they are still too much in flux. Maybe they are still too much in flux because nobody can readily identify the issues and the possible solutions that have been presented! >[re ISO 639-6 ]I think one reason is that most people do not know very much about 639-6. If you don't mind, could you send a short summary of how 639-6 addresses things such as written/spoken/signed/orthographies/writing systems etc? With concrete examples, indicating whether these are currently in the draft or are hypothetical. I think that would help the WG to have a good disucussion. Thanks for that. I will prepare a short summary with examples and will forward it to the WG for discussion asap. Regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 14 16:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5eo-0005CF-1K; Tue, 14 Nov 2006 16:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5em-0005C4-N7 for ltru@ietf.org; Tue, 14 Nov 2006 16:17:24 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5el-0006tO-CP for ltru@ietf.org; Tue, 14 Nov 2006 16:17:24 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VVbOEfpgqQeyB/oXIcH1tzvhUT3tI4yahtNIqv4FQ3ba6GhqEh+oV9rw307LALOC; 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.166.38.121] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gk5eg-0002mp-Tm for ltru@ietf.org; Tue, 14 Nov 2006 16:17:19 -0500 Message-ID: <002601c70832$541ca960$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 14 Nov 2006 13:17:38 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6b211b6594ba7c5161bc33693fea923a2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Fw: I-D ACTION:draft-mcwalter-langtag-mib-00.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: > To: > Sent: Tuesday, November 14, 2006 12:50 PM > Subject: I-D ACTION:draft-mcwalter-langtag-mib-00.txt ... > Title : Language Tag MIB > Author(s) : D. McWalter > Filename : draft-mcwalter-langtag-mib-00.txt > Pages : 8 > Date : 2006-11-14 > > This MIB module defines a textual convention to represent BCP 47 > [RFC4646] language tags. The intent is that this textual convention > will be imported and used in MIB modules that would otherwise define > their own representation. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mcwalter-langtag-mib-00.txt ... Forwarded for your information, since this document describes a use of language tags, and is intended for re-use by other MIB modules. If you have comments on this internet-draft, please send them to its author. Randy (as a MIB doctor) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 15 18:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUb5-00075b-M9; Wed, 15 Nov 2006 18:55:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUb4-00074g-FS for ltru@ietf.org; Wed, 15 Nov 2006 18:55:14 -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 1GkUay-0006IC-7l for ltru@ietf.org; Wed, 15 Nov 2006 18:55:14 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005720418.msg for ; Wed, 15 Nov 2006 23:57:58 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 15 Nov 2006 23:55:15 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Wed, 15 Nov 2006 23:54:39 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccHkMSxJJW8QEJYQoGivnD7VZJEEgBcsdzw In-Reply-To: <6.0.0.20.2.20061114104923.07748220@localhost> Message-ID: <188454ABD3E0439C94CF3C750DD12A20.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Wed, 15 Nov 2006 23:57:58 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: 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, 15 Nov 2006 23:57:59 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 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 In response to Martin's request for an overview of ISO 639-6. Apologies for the length of this post. I have tried to condense it but feel that I must also give enough information to facilitate informed discussion. For those that are not familiar with ISO 639-6, a brief description. It is a hierarchical system of alpha4 identifiers for language variants based on genetic and/or geographic affinities. The system provides for the highest level of linguistic classification, e.g. phyla, down to the lowest level of granularity (not definitive but could be as low as linguistic "register" and orthographies). Although, the system itself does not classify. There are no boundaries for languages/dialects/complexes etc. within ISO 639-6 and this is intentional. The system also offers codes for different language/variant modes - written/spoken/signed/sung - and is extensible. I am currently looking at the inclusion of linguistic "registers". See http://en.wikipedia.org/wiki/Register_(linguistics) In devising a system that will work in synergy with other ISO 639 standards, no alpha4 identifier is assigned to a linguistic entity that already has an alpha3 in either ISO 639-3 or -5. Thus, the hierarchical system, necessarily, includes ISO 639-3 and -5 identifiers and their associated reference names; ISO 639-3 is already mapped to ISO 639-1 and ISO 639-2T/B. This means that the whole of the ISO 639 family is related through ISO 639-6. The proposed data tables for ISO 639-6 will include the following fields: Alpha4 Identifier Alpha4 Parent Identifier Reference Name Here are some examples of the draft/unverified data (this means that more information - especially temporal - is currently being compiled and verification procedures are in process): NB: Please note ISO 639-5 codes have not yet been included so the code list displayed is for demonstration purposes only. Neapolitan (showing upper levels) inht Indo-Hittite indo inht Indo-European itlc indo Italic lnof itlc Latino-Faliscan rmce lnof Romance cont rmce Romance Continental wctl cont Romance Western Continental itor wctl Italo-Romance itnc itor Italian Cluster nap itnc Neapolitan napw nap Neapolitan Written napl napw Neapolitan Written Latin Script naps nap Neapolitan Spoken mags naps Marchigiano-S reno naps Reatino- Aquilano abze naps Abruzzese mols naps Molisano cpno naps Campano npou naps Napoletano-U Khanty (showing lower levels of written only) kca obgc Khanty kcaw kca Khanty Written kcal kcaw Khanty Written Latin Script kcac kcaw Khanty Written Cyrillic Script kcao kcaw Khanty Written Cyrillic Script Obdorsk Model kccc kcaw Khanty Written Cyrillic Script Central Ob Model kcav kcaw Khanty Written Cyrillic Script Vakh-Vasyugan Model kcak kcaw Khanty Written Cyrillic Script Kazym Model kcam kcaw Khanty Written Cyrillic Script Vakh-Surgut-Shuryshkar Model There has already been some off-list discussion on whether ISO 639-6 should be incorporated within RFC4646bis/ter and if so, how. Comments so far have highlighted that there is an overlap with entities currently available in RFC4646bis. For instance, the entity with the proposed alpha4 "kcal" representing "Khanty Written Latin Script" could be deemed the same as "kca-Latn-RU". These sort of problems would need to be addressed if ISO 639-6 is to be incorporated within a future RFC. Needless to say, I think there is a need for ISO 639-6 within this RFC. There is a need for variants. There is a need for a hierarchical system that will facilitate the creation of pick lists; 7,200 entities are more than a little unwieldy for the end user when setting language preferences! Currently, RFC4646 has reserved the alpha4 primary language sub tag position for ISO 639-6. This does not mean that ISO 639-6 is definitely going to be incorporated within a future RFC but rather that the space was reserved to give an option for inclusion. Given the problem with the overlap between RFC4646 conformant tags and the meaning of some of the alpha4 identifiers of ISO 639-6, one of the possible solutions is to include ISO 639-6 alpha4s as variant sub tags. For example (and I don't know what singleton would/could be used so I am using the number "6" to indicate that the variant is an ISO 639-6 identifier): "kcao Khanty Written Cyrillic Script Obdorsk Model" could be tagged as: ---- kca-Latn-RU-6-kcao ---- This would give the level of precision and granularity required by some, whilst retaining the "top level" information required for backward compatibility purposes and some applications. The ISO 639-6 hierarchical system would, as an estimate, increase the size of the Registry by approximately 25,000 sub tags. This could also be seen as a barrier to inclusion. However, there is no reason why these subtags should be included within the registry. The ISO 639-6 code tables will be made available on-line hosted by the RA on a number of servers. The important aspect, IMHO, is to design a mechanism for the inclusion of ISO 639-6 alpha4 identifiers within RFC4646 (bis or ter). ISO DIS 639-6 is scheduled for publication in January 2008. Debbie Garside Editor ISO DIS 639-6 Managing Director GeoLang Ltd www.geolang.com > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of > Martin Duerst > Sent: 14 November 2006 01:55 > To: debbie@ictmarketing.co.uk; ltru@ietf.org; bortzmeyer@nic.fr > Cc: ietf-languages@alvestrand.no > Subject: Re: [Ltru] LTRU progress and ISO 639-6 (was > WiktionaryZ language codes) > > At 07:20 06/11/14, Debbie Garside wrote: > >Stephane wrote: > > > >> > Can you send me details of the project? > >> > >> Attached. > > > >Ah! So you really mean LTRU! > > > >What exactly is going on with LTRU. There seems to be no progress > >being made at all. > > For several weeks before an IETF meeting, draft submission is closed. > > >What has happened to issue tracker. How do we find out what > the issues > >are and in what state of discussion they are in? > > I haven't officially tracked any issues, because they are > still too much in flux. > > >Randy, Martin, I would really appreciate it if we could have > a list of > >the issues and possible solutions. Or have I missed something? Are > >RFC4645/6bis on track without me realising? > > I think there are several areas of issues. Doug has sent a > list that he need resolved for his next draft a few days ago. > > >What are the timescales that we are now working to? When > can we expect > >the next draft? Questions, questions! And why, when it is > so relevant > >to all the variants currently under discussion > >(written/spoken/signed/orthographies/writing systems etc) is > ISO 639-6 > >not being discussed? > > I think one reason is that most people do not know very much > about 639-6. If you don't mind, could you send a short summary of how > 639-6 addresses things such as > written/spoken/signed/orthographies/writing > systems etc? With concrete examples, indicating whether these > are currently in the draft or are hypothetical. I think that > would help the WG to have a good disucussion. > > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 15 20:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVmR-00027E-Dm; Wed, 15 Nov 2006 20:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVmP-000271-MS for ltru@ietf.org; Wed, 15 Nov 2006 20:11: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 1GkVmO-0000Hd-Dx for ltru@ietf.org; Wed, 15 Nov 2006 20:11:01 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005721337.msg for ; Thu, 16 Nov 2006 01:14:00 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 01:11:18 +0000 From: "Debbie Garside" To: Date: Thu, 16 Nov 2006 01:10:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJHAkH00J4ESxxSEyu7SRTqkYa2w== Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 01:14:00 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 01:14:02 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Just checking... 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 To see if you are awake... I wrote: "kcao Khanty Written Cyrillic Script Obdorsk Model" could be tagged as: ---- kca-Latn-RU-6-kcao ---- This should, of course, be: ---- kca-Cyrl-RU-6-kcao ---- :-) Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 Fax: 0044 1437 766173 Web: http://www.ictmarketing.co.uk _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 01:22:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkadX-0004iT-KE; Thu, 16 Nov 2006 01:22:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkadW-0004iI-8b for ltru@ietf.org; Thu, 16 Nov 2006 01:22:10 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkadU-0000dT-Vo for ltru@ietf.org; Thu, 16 Nov 2006 01:22:10 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GkadU-0006TK-8c; Thu, 16 Nov 2006 01:22:08 -0500 Date: Thu, 16 Nov 2006 01:22:08 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061116062208.GI5359@ccil.org> References: <6.0.0.20.2.20061114104923.07748220@localhost> <188454ABD3E0439C94CF3C750DD12A20.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <188454ABD3E0439C94CF3C750DD12A20.MAI@home> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Debbie Garside scripsit: > Given the problem with the overlap between RFC4646 conformant tags > and the meaning of some of the alpha4 identifiers of ISO 639-6, one > of the possible solutions is to include ISO 639-6 alpha4s as variant > sub tags. For example (and I don't know what singleton would/could > be used so I am using the number "6" to indicate that the variant is > an ISO 639-6 identifier): > > "kcao Khanty Written Cyrillic Script Obdorsk Model" could be tagged as: > > ---- > > kca-Cyrl-RU-6-kcao I think this is basically the right idea, but I'd add the following qualifiers (this is very preliminary): 0) Before publication, 639-6 should be harmonized with ISO 15924 and ISO 3166-1 where possible; that is, new optional fields should be added to map kcal to Latn and kcac/kcao/kccc/kcav/kcak/kcam to Cyrl, and likewise to map any country-specific code elements to the 3166-1 code for the country. Until this is done, I don't think 639-6 is ready for use in BCP 47. 1) In the case of a code element identical to a 639-3 code element, the 639-6 addendum should be disallowed: kca, not kca-6-kca, obviously. 2) Supralanguage code elements (those which have no 639-3-equivalent ancestor) should be IMHO excluded from BCP 47; they are unsuitable for language tagging. I'd like to see the 639-2 language collections deprecated as well (though not removed, of course). There is simply no point in tagging a document as being in some Indo-European language -- the tag is too vague to be useful. This is not to say, of course, that these code elements are not useful for other purposes. 3) Infralanguage code elements (roughly, those that are not equivalent to any code element, but have at least one of them as an ancestor) should be represented using a variant rather than an extension. We could for example use 6kcao, which is a variant, rather than jumping through hoops to declare a 6 extension. The script and country values should also be used, and the variant should be omitted if it contains no further data: kca-Latn, not kca-Latn-6kcal. -- The first thing you learn in a lawin' family John Cowan is that there ain't no definite answers cowan@ccil.org to anything. --Calpurnia in To Kill A Mockingbird _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 01:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkauh-0001lZ-9h; Thu, 16 Nov 2006 01:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkauE-0000oQ-RV for ltru@ietf.org; Thu, 16 Nov 2006 01:39:26 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkaef-0000mC-15 for ltru@ietf.org; Thu, 16 Nov 2006 01:23:25 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gkaee-0006mz-OU; Thu, 16 Nov 2006 01:23:20 -0500 Date: Thu, 16 Nov 2006 01:23:20 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061116062320.GJ5359@ccil.org> References: <6.0.0.20.2.20061114104923.07748220@localhost> <188454ABD3E0439C94CF3C750DD12A20.MAI@home> <20061116062208.GI5359@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061116062208.GI5359@ccil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Scripsi: > 3) Infralanguage code elements (roughly, those that are not equivalent to > any code element, but have at least one of them as an ancestor) should That is, not equivalent to any 639-3 code element. -- Your worships will perhaps be thinking John Cowan that it is an easy thing to blow up a dog? http://www.ccil.org/~cowan [Or] to write a book? --Don Quixote, Introduction cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 04:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdLl-0002xt-8B; Thu, 16 Nov 2006 04:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdLh-0002tS-VY for ltru@ietf.org; Thu, 16 Nov 2006 04:15:57 -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 1GkdLg-0001LH-5Y for ltru@ietf.org; Thu, 16 Nov 2006 04:15:57 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005726415.msg for ; Thu, 16 Nov 2006 09:18:58 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 09:16:17 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 09:15:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJR7NekZbU9plURQqQzTTAMkGT1AAFyb2g In-Reply-To: <20061116062208.GI5359@ccil.org> Message-ID: <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:18:58 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:18:58 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 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: , Errors-To: ltru-bounces@ietf.org John wrote: > I think this is basically the right idea, but I'd add the > following qualifiers (this is very preliminary): > > 0) Before publication, 639-6 should be harmonized with ISO > 15924 and ISO > 3166-1 where possible; that is, new optional fields should be > added to map kcal to Latn and kcac/kcao/kccc/kcav/kcak/kcam > to Cyrl, and likewise to map any country-specific code > elements to the 3166-1 code for the country. > Until this is done, I don't think 639-6 is ready for use in BCP 47. Can you elaborate as to your reasons for requiring this please? It is not a problem as this information is currently being compiled anyway. > 1) In the case of a code element identical to a 639-3 code > element, the 639-6 addendum should be disallowed: kca, not > kca-6-kca, obviously. This is absolutely correct. kca represents an ISO 639-3 code element > 2) Supralanguage code elements (those which have no 639-3-equivalent > ancestor) should be IMHO excluded from BCP 47; they are > unsuitable for language tagging. I'd like to see the 639-2 > language collections deprecated as well (though not removed, > of course). There is simply no point in tagging a document > as being in some Indo-European language -- the tag is too > vague to be useful. This is not to say, of course, that > these code elements are not useful for other purposes. The hierarchical system facilitatates the exclusion of code elements "above" ISO 639-3. > 3) Infralanguage code elements (roughly, those that are not > equivalent to any code element, but have at least one of them > as an ancestor) should be represented using a variant rather > than an extension. I am not sure I understand this. Please elaborate. >We could for example use 6kcao, which is > a variant, rather than jumping through hoops to declare a 6 > extension. OK, sounds reasonable. >The script and country values should also be > used, and the variant should be omitted if it contains no > further data: kca-Latn, not kca-Latn-6kcal. Agreed, other than when suppress script comes into play. Debbie > > -- > The first thing you learn in a lawin' family John Cowan > is that there ain't no definite answers cowan@ccil.org > to anything. --Calpurnia in To Kill A Mockingbird > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 04:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdNu-0003ju-Jv; Thu, 16 Nov 2006 04:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdNt-0003jl-Ek for ltru@ietf.org; Thu, 16 Nov 2006 04:18:13 -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 1GkdNr-0001bJ-5I for ltru@ietf.org; Thu, 16 Nov 2006 04:18:13 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005726459.msg for ; Thu, 16 Nov 2006 09:21:11 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 09:18:32 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 09:17:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJR9ocW1wu+4FORYyWVux6oYZ0VQAF/3Zw In-Reply-To: <20061116062320.GJ5359@ccil.org> Message-ID: <763B7C66BACE4F108A6ECF8A9DA1FA6E.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:21:11 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:21:13 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 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: , Errors-To: ltru-bounces@ietf.org John wrote: > Scripsi: > > > 3) Infralanguage code elements (roughly, those that are not > equivalent > > to any code element, but have at least one of them as an ancestor) > > should > > That is, not equivalent to any 639-3 code element. Now I'm with you. Debbie > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 16 November 2006 06:23 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] LTRU progress and ISO 639-6 > > Scripsi: > > > 3) Infralanguage code elements (roughly, those that are not > equivalent > > to any code element, but have at least one of them as an ancestor) > > should > > That is, not equivalent to any 639-3 code element. > > -- > Your worships will perhaps be thinking John Cowan > that it is an easy thing to blow up a dog? > http://www.ccil.org/~cowan > [Or] to write a book? > --Don Quixote, Introduction cowan@ccil.org > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 10:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjBB-0003L2-Jn; Thu, 16 Nov 2006 10:29:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjBA-0003Kh-D2 for ltru@ietf.org; Thu, 16 Nov 2006 10:29:28 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkj7t-00024w-J5 for ltru@ietf.org; Thu, 16 Nov 2006 10:26:06 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gkj7t-00050x-5m; Thu, 16 Nov 2006 10:26:05 -0500 Date: Thu, 16 Nov 2006 10:26:05 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061116152605.GL5359@ccil.org> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Debbie Garside scripsit: > > 0) Before publication, 639-6 should be harmonized with ISO 15924 and > > ISO 3166-1 where possible; that is, new optional fields should be > > added to map kcal to Latn and kcac/kcao/kccc/kcav/kcak/kcam to Cyrl, > > and likewise to map any country-specific code elements to the 3166-1 > > code for the country. Until this is done, I don't think 639-6 is > > ready for use in BCP 47. > > Can you elaborate as to your reasons for requiring this please? It's required to make mechanical translatability possible. To translate 'kcal' into BCP 47 style, I need to know these things: 1) By chasing the parent links, I know that the appropriate language subtag is 'kca'. 2) By looking at the ISO 15942 mapping, I know that 'Latn' is the appropriate script subtag. (I then need to check the LSR to see if it should be suppressed.) 3) By seeing that there is no ISO 3166-1 mapping, I know that adding a region subtag is a bad idea. 4) There also needs to be a flag field in the 639-6 database which says that this mapping is complete, that I do *not* need to add a variant subtag of '6kcal'. This flag would be false for 'kcao', telling me that I *do* need a variant subtag '6kcao' in that case. I didn't realize the need for this field until now. -- Here lies the Christian, John Cowan judge, and poet Peter, http://www.ccil.org/~cowan Who broke the laws of God cowan@ccil.org and man and metre. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 11:46:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkO5-00060H-5x; Thu, 16 Nov 2006 11:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkO1-0005rt-CU for ltru@ietf.org; Thu, 16 Nov 2006 11:46:49 -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 1GkkGu-0003Tx-2C for ltru@ietf.org; Thu, 16 Nov 2006 11:39:34 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005735699.msg for ; Thu, 16 Nov 2006 16:42:28 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 16:39:47 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 16:39:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20061116152605.GL5359@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJk7QdIg+nb3YCTdCmTsRF1Mj07AABrHRQ Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 16:42:28 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 16:42:29 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 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: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > It's required to make mechanical translatability possible. > To translate 'kcal' into BCP 47 style, I need to know these things: > > 1) By chasing the parent links, I know that the appropriate > language subtag is 'kca'. Yes, that's the idea. > > 2) By looking at the ISO 15942 mapping, I know that 'Latn' is > the appropriate script subtag. (I then need to check the LSR > to see if it should be suppressed.) I can see the enormous value of this to RFC4646bis. However, if we are always translating the alpha4 back to the Alpha3 and/or script/country codes would it not be better to make this a requirement of ISO 639-3? I have to query whether this is the job of ISO 639 in general. One problem with this is when you have more than one script code. Representing this in a flat data format is messy. I think XML would do it nicely. > 3) By seeing that there is no ISO 3166-1 mapping, I know that > adding a region subtag is a bad idea. Can you give me some examples of when ISO 3166-1 code is not required? i.e. when it is a bad idea (I need to be sure I have the correct picture). Also, the same comment applies. I can see the value but why is this mapping not required for ISO 639-3? Please don't misunderstand, I am not saying ISO 639-6 will not facilitate this. > 4) There also needs to be a flag field in the 639-6 database > which says that this mapping is complete, that I do *not* > need to add a variant subtag of '6kcal'. This flag would be > false for 'kcao', telling me that I *do* need a variant > subtag '6kcao' in that case. I didn't realize the need for > this field until now. Hmmm... Yes, I can see the value of this as well. I think I can also see how this could be done. Basically you are not really suggesting general mapping to ISO 3166-1/ISO 15924, what you are suggesting is a bespoke mapping to facilitate RFC4646bis/ter tag generation. I am happy to look at this but I want to start with the absolute basics that are required to facilitate ISO 639-6 tags within a future RFC. To me, those basics are items 1) and 4). What do you think? Thanks Debbie > > -- > Here lies the Christian, John Cowan > judge, and poet Peter, > http://www.ccil.org/~cowan > Who broke the laws of God cowan@ccil.org > and man and metre. > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 13:37:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkm6c-00010N-VD; Thu, 16 Nov 2006 13:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkm6c-0000xc-4g for ltru@ietf.org; Thu, 16 Nov 2006 13:36:58 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkm6Z-0002XU-Fw for ltru@ietf.org; Thu, 16 Nov 2006 13:36:58 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gkm6Y-0003yw-TL; Thu, 16 Nov 2006 13:36:54 -0500 Date: Thu, 16 Nov 2006 13:36:54 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061116183654.GT5359@ccil.org> References: <20061116152605.GL5359@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Debbie Garside scripsit: > I can see the enormous value of this to RFC4646bis. However, if we are > always translating the alpha4 back to the Alpha3 and/or script/country > codes would it not be better to make this a requirement of ISO 639-3? No, because 639-3 identifiers don't have *specific* mappings to 15942 or 3166-1, but 639-6 identifiers do, at least some of them. 'kcal' refers to the variety of Khanty written in the Latin script, so it's appropriate to map it to 'Latn' in the 15942 field. It's not a requirement to map 'kca' itself, either in 639-3 or 639-6, to "Latn; Cyrl". If you want to know what scripts 'kca' can be written in, you examine its immediate children. > One problem with this is when you have more than one script code. > Representing this in a flat data format is messy. As I understand it, each 639-6 code for a written variety refers to at most one script: there is one for Khanty written in Latin, one for Khanty written in Cyrillic, one for Khanty written in each of the various Cyrillic orthography variants. It would not make sense for 639-3 to carry this information. It does make sense for 639-6 to do so -- in fact, it's right there in the names of the code elements. > Can you give me some examples of when ISO 3166-1 code is not > required? i.e. when it is a bad idea (I need to be sure I have the > correct picture). Well, when the language does not come in region-specific varieties: if your Khanty subtree is complete, there is no need for a mapping to 3166-1, since Khanty does not vary according to the nations in which it is spoken. > I can see the value but why is this mapping not required for ISO 639-3? Simply because 639-3 codes do not reflect regional variations. > Basically you are not really suggesting general mapping to ISO > 3166-1/ISO 15924, what you are suggesting is a bespoke mapping to > facilitate RFC4646bis/ter tag generation. I don't think it is bespoke. It just encodes the information that is already in the code element names in a machine-processable form. I presume there is a code for "American English", so that would have a mapping of "US" in the 3166-1 field, as would its descendants. > I want to start with the absolute basics that are required to facilitate > ISO 639-6 tags within a future RFC. To me, those basics are items 1) > and 4). What do you think? I think that all the fields mentioned are required to get a good crosswalk: code element, name, parent, script, country, complete-flag. The result would be that BCP 47 variant subtags would be required for those, and only those, 639-6 code elements where the complete-flag is false (and a variant subtag is needed to specify a subnational region, an orthography variant, or whatever). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Please leave your values Check your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:19:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmlr-0008Hc-5D; Thu, 16 Nov 2006 14:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmlp-0008HH-ND for ltru@ietf.org; Thu, 16 Nov 2006 14:19:33 -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 1Gkmlm-0001FN-35 for ltru@ietf.org; Thu, 16 Nov 2006 14:19:33 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005738008.msg for ; Thu, 16 Nov 2006 19:22:32 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 19:19:50 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 19:19:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20061116183654.GT5359@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJrm/rthDvwnnOShSkezwMWgSTqgAA4ghw Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:22:32 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:22:33 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 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: , Errors-To: ltru-bounces@ietf.org John wrote: > Debbie Garside scripsit: > > > I can see the enormous value of this to RFC4646bis. However, if we > > are always translating the alpha4 back to the Alpha3 and/or > > script/country codes would it not be better to make this a > requirement of ISO 639-3? > > No, because 639-3 identifiers don't have *specific* mappings > to 15942 or 3166-1, but 639-6 identifiers do, at least some > of them. 'kcal' > refers to the variety of Khanty written in the Latin script, > so it's appropriate to map it to 'Latn' in the 15942 field. Yes, I see your point. > It's not a requirement to map 'kca' itself, either in 639-3 > or 639-6, to "Latn; Cyrl". If you want to know what scripts > 'kca' can be written in, you examine its immediate children. Yes. > > One problem with this is when you have more than one script code. > > Representing this in a flat data format is messy. > > As I understand it, each 639-6 code for a written variety > refers to at most one script: there is one for Khanty written > in Latin, one for Khanty written in Cyrillic, one for Khanty > written in each of the various Cyrillic orthography variants. Yes, I misconstrued and was looking at providing the mapping attached to the alpha3, thus several scripts, giving a one to many relationship - my mistake. > > It would not make sense for 639-3 to carry this information. > It does make sense for 639-6 to do so -- in fact, it's right > there in the names of the code elements. Yes it is. But there are some (mainly older) scripts that do not have ISO 15924 codes. How would we deal with these? > > Can you give me some examples of when ISO 3166-1 code is > not required? > > i.e. when it is a bad idea (I need to be sure I have the correct > > picture). > > Well, when the language does not come in region-specific varieties: > if your Khanty subtree is complete, there is no need for a > mapping to 3166-1, since Khanty does not vary according to > the nations in which it is spoken. Here lies my biggest problem. This would effectively have to be done by hand looking at each code element with an ISO 639-3 identifier and coding the children as necessary. > > I can see the value but why is this mapping not required > for ISO 639-3? > > Simply because 639-3 codes do not reflect regional variations. > > > Basically you are not really suggesting general mapping to ISO > > 3166-1/ISO 15924, what you are suggesting is a bespoke mapping to > > facilitate RFC4646bis/ter tag generation. > > I don't think it is bespoke. It just encodes the information > that is already in the code element names in a > machine-processable form. > I presume there is a code for "American English", so that > would have a mapping of "US" in the 3166-1 field, as would > its descendants. Ah right, now I get it, so everywhere I have an alpha3 that has more than one ISO 3166-1 code attached I need to allocate the correct country code to the children. > > I want to start with the absolute basics that are required to > > facilitate ISO 639-6 tags within a future RFC. To me, those basics > > are items 1) and 4). What do you think? > > I think that all the fields mentioned are required to get a good > crosswalk: code element, name, parent, script, country, complete-flag. > The result would be that BCP 47 variant subtags would be > required for those, and only those, 639-6 code elements where > the complete-flag is false (and a variant subtag is needed to > specify a subnational region, an orthography variant, or whatever). OK. Seems reasonable to me. Debbie > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Please leave your values Check your > assumptions. In fact, > at the front desk. check your > assumptions at the door. > --sign in Paris hotel --Cordelia Vorkosigan > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmob-0000g8-2l; Thu, 16 Nov 2006 14:22:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmoZ-0000g2-Q9 for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:22:23 -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 1GkmoU-00020P-Go for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:22:23 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GkmoE-0002AU-S5 for ltru@lists.ietf.org; Thu, 16 Nov 2006 20:22:02 +0100 Received: from 212.82.251.231 ([212.82.251.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 20:22:02 +0100 Received: from nobody by 212.82.251.231 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 20:22:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 16 Nov 2006 20:20:55 +0100 Organization: Lines: 16 Message-ID: <455CBA17.4A1F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.231 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: Just checking... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > "kcao Khanty Written Cyrillic Script Obdorsk Model" could be tagged as: [...] > kca-Cyrl-RU-6-kcao Okay. And what about kcac, would we / you / someone offer an equivalence table "for kcac use kca-Cyrl-RU if in 4646ter territory, and try to avoid kcy-Cyrl-RU-6-kcac, because it's redundant" ? The RFC for the 6-extension registry could probably manage that. Thanks for the examples, it's much clearer now what you're talking about. And hopefully better than the current variant registration business. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmts-0003MR-Jd; Thu, 16 Nov 2006 14:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmtr-0003MB-9m for ltru@ietf.org; Thu, 16 Nov 2006 14:27:51 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkmtn-0003e7-JT for ltru@ietf.org; Thu, 16 Nov 2006 14:27:51 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gkmtn-0005uN-5M; Thu, 16 Nov 2006 14:27:47 -0500 Date: Thu, 16 Nov 2006 14:27:47 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061116192747.GW5359@ccil.org> References: <20061116183654.GT5359@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Debbie Garside scripsit: > Yes it is. But there are some (mainly older) scripts that do not have ISO > 15924 codes. How would we deal with these? Fill out the form at http://www.unicode.org/iso15924/iso15924form.html . > OK. Seems reasonable to me. Great. How about everyone else? To summarize: 1) No language tags for language collections except for the grandfathered 639-2 ones. 2) All existing language tags unchanged. 3) 639-3 tags which represent a finer granularity than we have today are registered as variant subtags of the form '6xxxx' with an appropriate prefix. Comments? -- John Cowan http://ccil.org/~cowan cowan@ccil.org Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue did rudely yerk me on the knob, wherefrom my wits still wander." An Englishman: "Ay, a filchman to the nab betimes 'll leave a man crank for a spell." --Harry Turtledove, Ruled Britannia _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmwe-0004wv-B4; Thu, 16 Nov 2006 14:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmwd-0004vq-B0 for ltru@ietf.org; Thu, 16 Nov 2006 14:30:43 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkmwb-0004NP-HZ for ltru@ietf.org; Thu, 16 Nov 2006 14:30:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gkmwa-00061A-P8; Thu, 16 Nov 2006 14:30:40 -0500 Date: Thu, 16 Nov 2006 14:30:40 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Just checking... Message-ID: <20061116193040.GX5359@ccil.org> References: <455CBA17.4A1F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455CBA17.4A1F@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Frank Ellermann scripsit: > Okay. And what about kcac, would we / you / someone offer an equivalence > table "for kcac use kca-Cyrl-RU if in 4646ter territory, and try to avoid > kcy-Cyrl-RU-6-kcac, because it's redundant" ? That is the "complete-flag" field that I have been talking about: it is true for 'kcac' and false for 'kcao'. I do, however, prefer '6kcao' (a variant) to '6-kcao' (an extension). -- "Well, I'm back." --Sam John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknEV-000587-1D; Thu, 16 Nov 2006 14:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknET-00057t-P1 for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:49:09 -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 1GknES-000057-F0 for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:49:09 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005738434.msg for ; Thu, 16 Nov 2006 19:52:10 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 19:49:32 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: Just checking... Date: Thu, 16 Nov 2006 19:48:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <455CBA17.4A1F@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJtM/kX/ysDq5iSSCJ4tanPcrpvwAAtL7w Message-ID: X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:52:10 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:52:11 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Frank wrote: > Okay. And what about kcac, would we / you / someone offer an > equivalence table "for kcac use kca-Cyrl-RU if in 4646ter > territory, and try to avoid kcy-Cyrl-RU-6-kcac, because it's > redundant" ? A flag would be provided in the data tables to indictate where a 639-6 identifier is redundant when it is equal to the combined language subtag containing ISO 639-3/3166-1/15924. > The RFC for the 6-extension registry could probably manage > that. Thanks for the examples, it's much clearer now what > you're talking about. And hopefully better than the current > variant registration business. Hopefully :-) Debbie > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:50:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknFP-0005en-3z; Thu, 16 Nov 2006 14:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknFN-0005eh-Ta for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:50:05 -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 1GknFL-0000Ef-Js for ltru@lists.ietf.org; Thu, 16 Nov 2006 14:50:05 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GknFK-0007eT-6Y for ltru@lists.ietf.org; Thu, 16 Nov 2006 20:50:02 +0100 Received: from 212.82.251.231 ([212.82.251.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 20:50:02 +0100 Received: from nobody by 212.82.251.231 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 20:50:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 16 Nov 2006 20:45:14 +0100 Organization: Lines: 29 Message-ID: <455CBFCA.4872@xyzzy.claranet.de> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.231 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> The script and country values should also be used, >> and the variant should be omitted if it contains >> no further data: kca-Latn, not kca-Latn-6kcal. > Agreed, other than when suppress script comes into play. Yes, if nap has an Suppress-Script Latn (as it should), then nap-6-napl isn't the same as nap-Latn, because nap-Latn is reduced to nap for most practical purposes. In other words nap-6-napl is okay in 4646ter territory. That's a bit tricky for a future equivalence table. If nap has no Suppress-Script Latn, because nobody bothered to register it, you have "use nap-Latn, not nap-6-napl, let alone nap-Latn-6-napl". If that's later fixed by adding a proper Suppress-Script nap-6-napl suddenly makes sense. And any old nap-Latn tags are dubious. One point with the Suppress-Scripts is that we must get it right a.s.a.p. 4646bis should be put on hold until the 4646 registry without 639-3 is complete. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 14:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknGW-0008Dr-Ga; Thu, 16 Nov 2006 14:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknGV-0008Dc-Us for ltru@ietf.org; Thu, 16 Nov 2006 14:51:15 -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 1GknGT-0000WM-Jp for ltru@ietf.org; Thu, 16 Nov 2006 14:51:15 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005738460.msg for ; Thu, 16 Nov 2006 19:54:14 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 19:51:33 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 19:50:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20061116192747.GW5359@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJtZI0CMcBFMUDQCKXTH3yE1O/7AAAsmqQ Message-ID: <2C7015BCC3984108BB1B736A7B4FD79E.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:54:14 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 19:54:16 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 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: , Errors-To: ltru-bounces@ietf.org John wrote: > 3) 639-3 tags which represent a finer granularity than we have today > are registered as variant subtags of the form '6xxxx' > with an appropriate prefix. That should read: 3) 639-6 tags which represent a finer granularity than we have today are registered as variant subtags of the form '6xxxx' with an appropriate prefix. Debbie > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 16 November 2006 19:28 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] LTRU progress and ISO 639-6 > > Debbie Garside scripsit: > > > Yes it is. But there are some (mainly older) scripts that > do not have ISO > > 15924 codes. How would we deal with these? > > Fill out the form at > http://www.unicode.org/iso15924/iso15924form.html . > > > OK. Seems reasonable to me. > > Great. How about everyone else? To summarize: > > 1) No language tags for language collections except for the > grandfathered > 639-2 ones. > > 2) All existing language tags unchanged. > > 3) 639-3 tags which represent a finer granularity than we have today > are registered as variant subtags of the form '6xxxx' > with an appropriate prefix. > > Comments? > > -- > John Cowan http://ccil.org/~cowan cowan@ccil.org > Lope de Vega: "It wonders me I can speak at all. Some > caitiff rogue did rudely yerk me on the knob, wherefrom my > wits still wander." > An Englishman: "Ay, a filchman to the nab betimes 'll leave a > man crank for a spell." --Harry Turtledove, Ruled Britannia > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 15:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gknc0-0003Kc-8N; Thu, 16 Nov 2006 15:13:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gknby-0003KO-Nb for ltru@lists.ietf.org; Thu, 16 Nov 2006 15:13:26 -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 1Gknbx-0005Ml-E7 for ltru@lists.ietf.org; Thu, 16 Nov 2006 15:13:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gknbp-0003LK-S1 for ltru@lists.ietf.org; Thu, 16 Nov 2006 21:13:17 +0100 Received: from 212.82.251.231 ([212.82.251.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 21:13:17 +0100 Received: from nobody by 212.82.251.231 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 21:13:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 16 Nov 2006 21:12:18 +0100 Organization: Lines: 22 Message-ID: <455CC622.46AB@xyzzy.claranet.de> References: <455CBA17.4A1F@xyzzy.claranet.de> <20061116193040.GX5359@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.231 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Just checking... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > That is the "complete-flag" field that I have been talking about Yes, I read and replied in reverse chronological order by thread, Debbie's "just checking" was the newest thread from my POV. Later I found your explanation. > I do, however, prefer '6kcao' (a variant) to '6-kcao' (an > extension). As usual I prefer extensions, when there's a clear topic or issue, and the variant approach would result in an "emulated" singleton, fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. Why use an informal convention if you can also get an RFC with all details, here your "flag" algorithm to determine equivalences ? For variants it's so far not possible to specify "conventional" rules in separate documents. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 16:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoRW-000192-BK; Thu, 16 Nov 2006 16:06:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoRU-00018Y-OB for ltru@lists.ietf.org; Thu, 16 Nov 2006 16:06:40 -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 1GkoRC-0006U9-6B for ltru@lists.ietf.org; Thu, 16 Nov 2006 16:06:40 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005739241.msg for ; Thu, 16 Nov 2006 21:09:24 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 21:06:43 +0000 From: "Debbie Garside" To: , , Subject: RE: [Ltru] Re: Just checking... Date: Thu, 16 Nov 2006 21:06:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <455CC622.46AB@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJvBTA7baKrZLOQnuSZUE9fZXjHQABnYQg Message-ID: <5D09A24184EF4AB6A046C4E0875FAFDD.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 21:09:24 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 21:09:24 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Frank wrote: > John wrote > > I do, however, prefer '6kcao' (a variant) to '6-kcao' (an > extension). > > As usual I prefer extensions, when there's a clear topic or > issue, and the variant approach would result in an "emulated" > singleton, fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. If I had to state a preference it would be for an extension because it presents the alpha4 as is. But maybe I don't fully understand the issues involved. Would someone like to enlighten me? Debbie > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: 16 November 2006 20:12 > To: ltru@lists.ietf.org > Subject: [Ltru] Re: Just checking... > > John Cowan wrote: > > > That is the "complete-flag" field that I have been talking about > > Yes, I read and replied in reverse chronological order by > thread, Debbie's "just checking" was the newest thread from > my POV. Later I found your explanation. > > > I do, however, prefer '6kcao' (a variant) to '6-kcao' (an > extension). > > As usual I prefer extensions, when there's a clear topic or > issue, and the variant approach would result in an "emulated" > singleton, fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. > > Why use an informal convention if you can also get an RFC > with all details, here your "flag" algorithm to determine > equivalences ? > For variants it's so far not possible to specify "conventional" > rules in separate documents. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 16 20:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksEa-0002ws-RT; Thu, 16 Nov 2006 20:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksEZ-0002wb-Na for ltru@ietf.org; Thu, 16 Nov 2006 20:09:35 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GksEY-0002pY-Ck for ltru@ietf.org; Thu, 16 Nov 2006 20:09:35 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bDGv2pdF6QwsqIjJZ46KVT1Fd0zQ6k8+e4PStqIB0ENgLzj2zZ5fN9qvX6pj2HQj; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.15] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GksEX-0005G0-N0 for ltru@ietf.org; Thu, 16 Nov 2006 20:09:34 -0500 Message-ID: <000201c709e5$1c451a40$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20061116183654.GT5359@ccil.org> <20061116192747.GW5359@ccil.org> Subject: Re: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 17:08:58 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6f647f2aeefa4e98489ccdf63bf764ae8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.15 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: "John Cowan" > To: "Debbie Garside" > Cc: > Sent: Thursday, November 16, 2006 11:27 AM > Subject: Re: [Ltru] LTRU progress and ISO 639-6 ... > 1) No language tags for language collections except for the grandfathered > 639-2 ones. ... I disagree. I think it is simpler to *not* prohibit language collections. Yes, some of them may have limited utility, but that is not a good reason for prohibiting them, in my opinion. If it results in a simpler specification, while permitting meaningful tags that would otherwise be prohibited, I think the choice is simple. (Considering the cataloguer's plight, I think that tags for language collections could be very useful for material whose language can be roughly categorized, pending a closer look by a specialist. "zh" is already used in this way.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 00:01:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvrN-0000Ua-FQ; Fri, 17 Nov 2006 00:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvrN-0000UU-1a for ltru@ietf.org; Fri, 17 Nov 2006 00:01:53 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkvrL-0006a3-Qx for ltru@ietf.org; Fri, 17 Nov 2006 00:01:53 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GkvrL-0005bM-0j; Fri, 17 Nov 2006 00:01:51 -0500 Date: Fri, 17 Nov 2006 00:01:50 -0500 To: Randy Presuhn Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061117050150.GB13257@ccil.org> References: <20061116192747.GW5359@ccil.org> <000201c709e5$1c451a40$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201c709e5$1c451a40$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > I disagree. I think it is simpler to *not* prohibit language collections. It's *simpler* not to prohibit anything, but the trend of RFC 4646 is to set more limits so that people can rely on things. > Yes, some of them may have limited utility, but that is not a good > reason for prohibiting them, in my opinion. If it results in a simpler > specification, while permitting meaningful tags that would otherwise > be prohibited, I think the choice is simple. Of course, but meaningful for what? What good does it do to be able to tag a document "ger" (Germanic languages)? It doesn't tell you anything useful about it. > (Considering the cataloguer's plight, I think that tags for language > collections could be very useful for material whose language can be > roughly categorized, pending a closer look by a specialist. "zh" is > already used in this way.) "zh" is a macrolanguage, not a collection. The only way to know if something is North Germanic is to recognize it as Swedish, Danish, Norwegian, Icelandic, Faroese, ... and consult the current definition of the term. (Okay, *that* term is stable, but plenty of other language-collection terms aren't; languages move in and out all the time.) -- Winter: MIT, John Cowan Keio, INRIA, cowan@ccil.org Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! Might simplicity return? (A "tanka", or extended haiku) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 01:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhG-0003g0-TY; Fri, 17 Nov 2006 01:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhF-0003c2-CW for ltru@ietf.org; Fri, 17 Nov 2006 01:59:33 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkxW9-0002fr-Gs for ltru@ietf.org; Fri, 17 Nov 2006 01:48:07 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GkxW8-0005bg-GN; Fri, 17 Nov 2006 01:48:04 -0500 Date: Fri, 17 Nov 2006 01:48:04 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061117064804.GC13257@ccil.org> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> <455CBFCA.4872@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455CBFCA.4872@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Yes, if nap has an Suppress-Script Latn (as it should), > then nap-6-napl isn't the same as nap-Latn, because > nap-Latn is reduced to nap for most practical purposes. I don't understand this. The meaning of saying that napl has a Suppress-Script of Latn is that nap and nap-Latn are synonymous. > In other words nap-6-napl is okay in 4646ter territory. What for? -- On the Semantic Web, it's too hard to prove John Cowan cowan@ccil.org you're not a dog. --Bill de hOra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 01:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhE-0003fN-FV; Fri, 17 Nov 2006 01:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhC-0003dP-KE for ltru@ietf.org; Fri, 17 Nov 2006 01:59:30 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkxX0-0002jK-5l for ltru@ietf.org; Fri, 17 Nov 2006 01:49:02 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GkxWz-0005cq-VD; Fri, 17 Nov 2006 01:48:57 -0500 Date: Fri, 17 Nov 2006 01:48:57 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Just checking... Message-ID: <20061117064857.GD13257@ccil.org> References: <455CBA17.4A1F@xyzzy.claranet.de> <20061116193040.GX5359@ccil.org> <455CC622.46AB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455CC622.46AB@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > As usual I prefer extensions, when there's a clear topic or issue, > and the variant approach would result in an "emulated" singleton, > fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. This is what variants are *for*. Read the section on them in 4646 again. > Why use an informal convention if you can also get an RFC with all > details, here your "flag" algorithm to determine equivalences ? > For variants it's so far not possible to specify "conventional" > rules in separate documents. Why not? When we do RFC 4646ter we can explain all of this. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 01:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhU-0003m6-BL; Fri, 17 Nov 2006 01:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxhT-0003kh-B4 for ltru@ietf.org; Fri, 17 Nov 2006 01:59:47 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkxSH-0002TW-JK for ltru@ietf.org; Fri, 17 Nov 2006 01:44:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HIJAwkLQJm2/sCW57or4PU7tVfrofVMrkkE3eblKrB7Orfcm7GOWEtCzD1aet4SR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.183] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GkxSF-0001h5-Sx for ltru@ietf.org; Fri, 17 Nov 2006 01:44:04 -0500 Message-ID: <000001c70a13$dd884460$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061116192747.GW5359@ccil.org> <000201c709e5$1c451a40$6601a8c0@oemcomputer> <20061117050150.GB13257@ccil.org> Subject: Re: [Ltru] LTRU progress and ISO 639-6 Date: Thu, 16 Nov 2006 22:41:34 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee61b945bdaea6d467095bb6f46bdb8bc26350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.183 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Thursday, November 16, 2006 9:01 PM > Subject: Re: [Ltru] LTRU progress and ISO 639-6 ... > "zh" is a macrolanguage, not a collection. The only way to know if > something is North Germanic is to recognize it as Swedish, Danish, > Norwegian, Icelandic, Faroese, ... and consult the current definition > of the term. (Okay, *that* term is stable, but plenty of other > language-collection terms aren't; languages move in and out all the time.) ... Actually, this is a good example. If I were helping to catalog material in a library, I know the major East and West Germanic languages well enough to tag material in those languages. I also know enough to recognize something as being in a North Germanic language, but for a more precise tagging I'd just to hand it off to a "specialist". If the specialist wasn't handy, being able to tag it as "North Germanic", even as a temporary measure, would be quite useful, even if the category is fuzzy or unstable. There are times when fuzziness can be a feature, rather than a bug. Folks that don't need these don't need to use them. I'd just hate to prohibit something that could potentially be useful, especially when I don't yet see any clear benefit arising from the prohibition. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 03:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkzVF-0005BW-S6; Fri, 17 Nov 2006 03:55:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkzVE-0005BR-U4 for ltru@ietf.org; Fri, 17 Nov 2006 03:55:16 -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 1GkzVD-0000Au-Go for ltru@ietf.org; Fri, 17 Nov 2006 03:55:16 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005747802.msg for ; Fri, 17 Nov 2006 08:58:07 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 17 Nov 2006 08:55:26 +0000 From: "Debbie Garside" To: , "'Randy Presuhn'" Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Fri, 17 Nov 2006 08:54:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <000001c70a13$dd884460$6601a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccKFiPTUVQ86aaYTlCqUGoq3AzESAADiJoA Message-ID: <820B02FCBFD0451AAB2A30BDA5BA7C16.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 08:58:07 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 08:58:08 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Randy wrote: > Actually, this is a good example. If I were helping to > catalog material in a library, I know the major East and West > Germanic languages well enough to tag material in those languages. > I also know enough to recognize something as being in a North > Germanic language, but for a more precise tagging I'd just to > hand it off to a "specialist". If the specialist wasn't > handy, being able to tag it as "North Germanic", even as a > temporary measure, would be quite useful, even if the > category is fuzzy or unstable. > > There are times when fuzziness can be a feature, rather than a bug. > > Folks that don't need these don't need to use them. I'd just > hate to prohibit something that could potentially be useful, > especially when I don't yet see any clear benefit arising > from the prohibition. I agree with your sentiments. However, as far as I know the library community do not use RFC4646 (or do they?). John is not proposing that these tags be taken out of ISO 639-6 altogether but rather that they be flagged as not to be used in RFC4646. If there is a possibility of a legitimate use case then they should, perhaps, stay in. There is a (slightly messy) way around this and that is to create a rule that says "-6kcal" can be used as a variant but the upper levels can be used in the primary language sub tag position; as the alpha4 space is already reserved. In other words create a rule that states, if the 639-6 tag is flagged for use and has a 639-3 tag as a parent then use as variant otherwise use as primary language subtag. The rule could also state that alpha4s used in the Primary Language subtag position should include no other subtags (other than, possibly, extensions). Debbie > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 04:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzow-0008D0-3m; Fri, 17 Nov 2006 04:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzov-0008Cs-Du for ltru@lists.ietf.org; Fri, 17 Nov 2006 04:15:37 -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 1Gkzou-0002oc-2v for ltru@lists.ietf.org; Fri, 17 Nov 2006 04:15:37 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005748314.msg for ; Fri, 17 Nov 2006 09:18:37 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 17 Nov 2006 09:15:54 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: LTRU progress and ISO 639-6 Date: Fri, 17 Nov 2006 09:15:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <455CBFCA.4872@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccJuKIB64fnL2yjSNCkShGt8L/fmgAbXswg Message-ID: <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 09:18:37 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 09:18:39 +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 Frank wrote: > Yes, if nap has an Suppress-Script Latn (as it should), then > nap-6-napl isn't the same as nap-Latn, because nap-Latn is > reduced to nap for most practical purposes. > In other words nap-6-napl is okay in 4646ter territory. I don't think it is. If "nap" is equal to "nap-Latn" (as it is with suppress script) and "napl" is also equal to "nap-Latn" there lieth an overlap. But I do sort of see where you are coming from because essentially "nap" represents just the language and not the language plus script. Is there a liklihood that "nap-6napl" would be useful? I suppose if we suddenly had a need for "nap-Grek" it would be. Hmmm... I can see a glimmer of a need. The rules for suppress script, once invoked are they set in stone? Could you suppress "nap" now and unsuppress in the future? Debbie > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: 16 November 2006 19:45 > To: ltru@lists.ietf.org > Subject: [Ltru] Re: LTRU progress and ISO 639-6 > > Debbie Garside wrote: > > >> The script and country values should also be used, and the variant > >> should be omitted if it contains no further data: kca-Latn, not > >> kca-Latn-6kcal. > > > Agreed, other than when suppress script comes into play. > > Yes, if nap has an Suppress-Script Latn (as it should), then > nap-6-napl isn't the same as nap-Latn, because nap-Latn is > reduced to nap for most practical purposes. > > In other words nap-6-napl is okay in 4646ter territory. > > That's a bit tricky for a future equivalence table. If nap > has no Suppress-Script Latn, because nobody bothered to > register it, you have "use nap-Latn, not nap-6-napl, let > alone nap-Latn-6-napl". > > If that's later fixed by adding a proper Suppress-Script > nap-6-napl suddenly makes sense. And any old nap-Latn tags > are dubious. > > One point with the Suppress-Scripts is that we must get it > right a.s.a.p. 4646bis should be put on hold until the 4646 > registry without 639-3 is complete. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 05:56:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1OQ-0006t4-H6; Fri, 17 Nov 2006 05:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1OP-0006r8-EV for ltru@ietf.org; Fri, 17 Nov 2006 05:56:21 -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 1Gl1OO-0004Vg-4s for ltru@ietf.org; Fri, 17 Nov 2006 05:56:21 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005750773.msg for ; Fri, 17 Nov 2006 10:59:23 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 17 Nov 2006 10:56:35 +0000 From: "Debbie Garside" To: Date: Fri, 17 Nov 2006 10:55:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccKNvZtDKX0Is19Rx+vlU7QTjdp+w== Message-ID: <57106CBB55964BB394D6F95DCF91DDCB.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 10:59:23 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 17 Nov 2006 10:59:23 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ltru] Error Correction 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 In putting together the data for demonstration purposes, I introduced an error in the hierarchical system. Khanty (showing lower levels of written only) kca obgc Khanty kcaw kca Khanty Written kcal kcaw Khanty Written Latin Script kcac kcaw Khanty Written Cyrillic Script kcao kcaw Khanty Written Cyrillic Script Obdorsk Model kccc kcaw Khanty Written Cyrillic Script Central Ob Model kcav kcaw Khanty Written Cyrillic Script Vakh-Vasyugan Model kcak kcaw Khanty Written Cyrillic Script Kazym Model kcam kcaw Khanty Written Cyrillic Script Vakh-Surgut-Shuryshkar Model The written variants of Khanty in Cyrillic script should be related to the Cyrillic parent. Thus, it should read: kca obgc Khanty kcaw kca Khanty Written kcal kcaw Khanty Written Latin Script kcac kcaw Khanty Written Cyrillic Script kcao kcac Khanty Written Cyrillic Script Obdorsk Model kccc kcac Khanty Written Cyrillic Script Central Ob Model kcav kcac Khanty Written Cyrillic Script Vakh-Vasyugan Model kcak kcac Khanty Written Cyrillic Script Kazym Model kcam kcac Khanty Written Cyrillic Script Vakh-Surgut-Shuryshkar Model This way a match can be returned for all Khanty written in Cyrillic script regardless of Model. Best regards Debbie Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 Fax: 0044 1437 766173 Web: http://www.ictmarketing.co.uk _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 07:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2ke-0002Ks-TQ; Fri, 17 Nov 2006 07:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2kd-0002Km-Fj for ltru@lists.ietf.org; Fri, 17 Nov 2006 07:23:23 -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 1Gl2ka-0002ES-29 for ltru@lists.ietf.org; Fri, 17 Nov 2006 07:23:23 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl2kB-0004Pa-An for ltru@lists.ietf.org; Fri, 17 Nov 2006 13:22:55 +0100 Received: from pd9fbad50.dip0.t-ipconnect.de ([217.251.173.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 13:22:55 +0100 Received: from nobody by pd9fbad50.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 13:22:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 17 Nov 2006 13:17:06 +0100 Organization: Lines: 39 Message-ID: <455DA842.C75@xyzzy.claranet.de> References: <20061116062208.GI5359@ccil.org><2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> <455CBFCA.4872@xyzzy.claranet.de> <000101c709e5$1c0b1e80$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad50.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Our charter says nothing about waiting for the state of the > registry to reach any particular state before we complete > our work in the ltru WG, and, given the very nature of a > registry, there is no technical reason to impose such a > requirement. As far as I'm concerned 4646bis goes nowhere without completing the Suppress-Scripts or revising the procedure to add them. The 4646 idea was to let the review list complete this in any way they like, and so far they completed no Suppress-Scripts in about a year. We have that all documented in 4646-tickets, in the LTRU list archive, and about four attempts to add Suppress-Scripts on the review list (two individual, and John's two proposals for bulk updates). A plausible plan was to get it right for languages adopted from 639-1 / 639-2, and ignore the future 639-3 languages as less interesting wrt this compatibility kludge. So far the 4645bis registry won't tell us the source of a language subtag, this plan works reliably only _before_ 4645bis is last called. We could also decide it here directly in 4645bis, as proposed by the current subtag reviewer. I don't care how it's solved before a 4645bis "last call", but we've now seen what happens if we delegate this taks: Twice as nothing. The charter says "evaluate the 4646 procedure, adjust it as needed" or similar. I'm no big fan of the "review committee" idea proposed here some weeks ago, but if that's what it takes to get many missing Suppress-Scripts right, why not... Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 07:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2mH-0003PE-Nt; Fri, 17 Nov 2006 07:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2mG-0003P6-JC for ltru@lists.ietf.org; Fri, 17 Nov 2006 07:25: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 1Gl2mF-0002Y8-5F for ltru@lists.ietf.org; Fri, 17 Nov 2006 07:25:04 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gl2mD-0004pw-Sy for ltru@lists.ietf.org; Fri, 17 Nov 2006 13:25:01 +0100 Received: from pd9fbad50.dip0.t-ipconnect.de ([217.251.173.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 13:25:01 +0100 Received: from nobody by pd9fbad50.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 13:25:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 17 Nov 2006 13:22:10 +0100 Organization: Lines: 56 Message-ID: <455DA972.C36@xyzzy.claranet.de> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> <455CBFCA.4872@xyzzy.claranet.de> <20061117064804.GC13257@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad50.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> if nap has an Suppress-Script Latn (as it should), >> then nap-6-napl isn't the same as nap-Latn, because >> nap-Latn is reduced to nap for most practical purposes. > I don't understand this. The meaning of saying that napl > has a Suppress-Script of Latn is that nap and nap-Latn > are synonymous. nap has (or rather should or could have) a Suppress-Script Latn. For the purposes of 4646 and backwards compatibility a tag nap is then better (SHOULD) than nap-Latn. For the purposes of 639-6 napl is a proper subset of nap, napl implies "written using Latn". For a 639-6 nap that's not the case, it can be spoken, or written using another script, etc., including but not limited to all 639-6 code elements with nap as their parent. In other words nap and napl are not synonymous wrt 639-6. But nap and nap-Latn are (or could be) to some degree wrt 4646 ff. Taggers going to the trouble of using 639-6 as extension or variant could try to preserve that relation using nap-6-napl or nap-6napl, intuitively. I'm not sure about your variant idea, maybe it's important for the outcome. For an extension it's clearer, a tag like nap-6-napl is okay, taggers using extensions aren't really interested in backwards compatible Suppress-Script kludges. ...BUT... At the moment nap doesn't have a Suppress-Script Latn. With that a tag nap-Latn is perfectly okay, it doesn't violate the SHOULD about avoiding Suppress-Script subtags, at worst it violates a general SHOULD about tagging wisely. Based on that nap-6-napl or nap-6napl are "verboten", because there's a short and simple nap-Latn for this purpose. The outcome depends on accurate Suppress-Scripts, as far as that's possible. Switching them later without compelling reasons is messy. We know this, it was clearly understood for the introduction of 4646, and "let the review list complete the stuff found in an earlier CLDR database" was only to make sure that no nonsense (Tatar and similar cases) goes into the registry. But the precise number of Suppress-Scripts completed by the review list in about a year is ZERO, not counting one case of Nkoo, where it was done simultaneously with the addition of ngo. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 17 11:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6iA-00057e-J0; Fri, 17 Nov 2006 11:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6f5-0004E6-H3 for ltru@ietf.org; Fri, 17 Nov 2006 11:33:55 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6c9-0001Cn-0m for ltru@ietf.org; Fri, 17 Nov 2006 11:30:57 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gl6c8-0000go-DT; Fri, 17 Nov 2006 11:30:52 -0500 Date: Fri, 17 Nov 2006 11:30:52 -0500 To: Debbie Garside Subject: Re: [Ltru] LTRU progress and ISO 639-6 Message-ID: <20061117163052.GC24547@ccil.org> References: <000001c70a13$dd884460$6601a8c0@oemcomputer> <820B02FCBFD0451AAB2A30BDA5BA7C16.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <820B02FCBFD0451AAB2A30BDA5BA7C16.MAI@home> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Debbie Garside scripsit: > Randy wrote: > > > I also know enough to recognize something as being in a North > > Germanic language, but for a more precise tagging I'd just to > > hand it off to a "specialist". If the specialist wasn't > > handy, being able to tag it as "North Germanic", even as a > > temporary measure, would be quite useful, even if the > > category is fuzzy or unstable. Okay, you've convinced me. > There is a (slightly messy) way around this and that is to create a > rule that says "-6kcal" can be used as a variant but the upper levels > can be used in the primary language sub tag position; as the alpha4 > space is already reserved. In other words create a rule that states, > if the 639-6 tag is flagged for use and has a 639-3 tag as a parent then > use as variant otherwise use as primary language subtag. The rule could > also state that alpha4s used in the Primary Language subtag position > should include no other subtags (other than, possibly, extensions). That sounds like the Right Thing to me. It does add complications to the method of treating 639-6 tags, but I think there is no getting away from it: the tag for "Indo-European languages" simply can't be made subordinate to anything language subtag. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 01:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glg0m-0007Lv-Vp; Sun, 19 Nov 2006 01:18:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glg0m-0007Ln-HJ for ltru@ietf.org; Sun, 19 Nov 2006 01:18:40 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glg0l-0002Uh-8J for ltru@ietf.org; Sun, 19 Nov 2006 01:18:40 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061119061834.CBAB26810.mta9.adelphia.net@DGBP7M81> for ; Sun, 19 Nov 2006 01:18:34 -0500 Message-ID: <000501c70ba2$8bcf13c0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 18 Nov 2006 22:18:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 1) No language tags for language collections except for the > grandfathered 639-2 ones. No, I agree with Randy: we cannot guarantee that no RFC 4646bis/ter application will ever have a use for collection subtags. It's not all Web pages and browser preferences. When we forbid "nv-DK" and "nv-Yiii" we can talk about forbidding the collections. > 2) All existing language tags unchanged. No problem there. > 3) 639-3 tags which represent a finer granularity than we have > today are registered as variant subtags of the form '6xxxx' > with an appropriate prefix. > > Comments? 1) Are we planning to un-reserve the 4-letter primary language subtags, since it's obvious we aren't going to use them for the intended purpose? (Not that there will ever be any non-639-based langauge subtags anyway.) 2) Is the extension mechanism really so distasteful that we would rather register thousands of "6xxxx" variants instead? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 01:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgG8-0004Mg-FX; Sun, 19 Nov 2006 01:34:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgG7-0004J7-QZ for ltru@ietf.org; Sun, 19 Nov 2006 01:34:31 -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 1GlgG4-0003sb-79 for ltru@ietf.org; Sun, 19 Nov 2006 01:34:31 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061119063427.SWV21407.mta13.adelphia.net@DGBP7M81> for ; Sun, 19 Nov 2006 01:34:27 -0500 Message-ID: <000901c70ba4$c3d29b50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 18 Nov 2006 22:34:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > One point with the Suppress-Scripts is that we must get > it right a.s.a.p. 4646bis should be put on hold until > the 4646 registry without 639-3 is complete. Once again I must disagree in the strongest terms with Frank on this topic. Suppress-Script is NOT normative and the Registry is NOT expected to ever contain a complete and uncontroversial set of Suppress-Script entries -- not even for the 489 current language subtags. No tag is made invalid by the addition of a script subtag, even one that is supposed to be Suppressed. Suppress-Script is only a suggestion, meant to simplify life for matching engines that have not been upgraded to use RFC 4647 techniques. No mechanism should be put in place in 4646bis or beyond that makes S-S anything more than a suggestion. One of the main reasons I opposed Suppress-Script (or anything like it) in the first place was that somebody might expect this group, or ietf-languages, to research script usage for hundreds or thousands of languages. The benefit simply does not justify the effort and inevitable controversy. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 01:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgQ7-00009z-8n; Sun, 19 Nov 2006 01:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgQ6-00008S-1N for ltru@ietf.org; Sun, 19 Nov 2006 01:44:50 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlgQ1-0004fn-Pd for ltru@ietf.org; Sun, 19 Nov 2006 01:44:50 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GlgQ1-0003an-90; Sun, 19 Nov 2006 01:44:45 -0500 Date: Sun, 19 Nov 2006 01:44:45 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061119064445.GB27676@ccil.org> References: <000501c70ba2$8bcf13c0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501c70ba2$8bcf13c0$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: > No, I agree with Randy: we cannot guarantee that no RFC > 4646bis/ter application will ever have a use for collection > subtags. It's not all Web pages and browser preferences. When we > forbid "nv-DK" and "nv-Yiii" we can talk about forbidding the > collections. I now accept this. > >3) 639-3 tags which represent a finer granularity than we have > > today are registered as variant subtags of the form '6xxxx' > > with an appropriate prefix. > > 1) Are we planning to un-reserve the 4-letter primary language > subtags, since it's obvious we aren't going to use them for the > intended purpose? No, we'll need them for the supralanguage tags like "inde" (Indo- European languages). > 2) Is the extension mechanism really so distasteful that we would > rather register thousands of "6xxxx" variants instead? This is what variants are for: language varieties that don't amount to separate languages. Rather than waiting for people to register them as needed, we are being handed a whole bunch on a platter. I say, let's grab 'em. -- A few times, I did some exuberant stomping about, John Cowan like a hippo auditioning for Riverdance, though cowan@ccil.org I stopped when I thought I heard something at http://ccil.org/~cowan the far side of the room falling over in rhythm with my feet. -- Joseph Zitt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 03:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOW-0000i2-Qn; Sun, 19 Nov 2006 03:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOV-0000hr-H1 for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GliOR-00053a-L9 for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAJ8ovfE007617 for ; Sun, 19 Nov 2006 17:51:00 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 53d4_12d8db20_77ab_11db_9677_0014221fa3c9; Sun, 19 Nov 2006 17:50:57 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39818) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 19 Nov 2006 17:50:24 +0900 Message-Id: <6.0.0.20.2.20061118113349.0830eec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 18 Nov 2006 11:36:56 +0900 To: John Cowan , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: Just checking... In-Reply-To: <20061117064857.GD13257@ccil.org> References: <455CBA17.4A1F@xyzzy.claranet.de> <20061116193040.GX5359@ccil.org> <455CC622.46AB@xyzzy.claranet.de> <20061117064857.GD13257@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:48 06/11/17, John Cowan wrote: >Frank Ellermann scripsit: > >> As usual I prefer extensions, when there's a clear topic or issue, >> and the variant approach would result in an "emulated" singleton, >> fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. > >This is what variants are *for*. Read the section on them in >4646 again. Two points: 1) This is indeed what variants are for, but there is no restriction on what extensions are for, in partucular there is nothing saying that you can't use extensions for variants. 2) One reason where an extension would be better is that the necessary data (flags and such) could easily go on a separate place (IANA or elsewhere), whereas extensions all have to go on the same page (unless we would decide to change that). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 03:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOW-0000hy-NO; Sun, 19 Nov 2006 03:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOV-0000hm-Eh for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GliOR-00053Z-LA for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAJ8owCg007618 for ; Sun, 19 Nov 2006 17:51:00 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2d45_135d7e02_77ab_11db_9c9d_0014221f2a2d; Sun, 19 Nov 2006 17:50:57 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39818) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 19 Nov 2006 17:50:25 +0900 Message-Id: <6.0.0.20.2.20061118114301.0963a340@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 18 Nov 2006 11:45:46 +0900 To: debbie@ictmarketing.co.uk, From: Martin Duerst Subject: RE: [Ltru] LTRU progress and ISO 639-6 In-Reply-To: <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 18:15 06/11/16, Debbie Garside wrote: >John wrote: >>The script and country values should also be >> used, and the variant should be omitted if it contains no >> further data: kca-Latn, not kca-Latn-6kcal. > >Agreed, other than when suppress script comes into play. Just an idea that came up: It looks like some of the 639-6 data could help figuring out some more suppress-scripts (or otherwise decide on how to solve that issues). What I'm assuming is that the 639-6 data might be a good source for what language is written with what scripts. Just an idea. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 03:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOW-0000i2-Qn; Sun, 19 Nov 2006 03:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOV-0000hr-H1 for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GliOR-00053a-L9 for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAJ8ovfE007617 for ; Sun, 19 Nov 2006 17:51:00 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 53d4_12d8db20_77ab_11db_9677_0014221fa3c9; Sun, 19 Nov 2006 17:50:57 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39818) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 19 Nov 2006 17:50:24 +0900 Message-Id: <6.0.0.20.2.20061118113349.0830eec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 18 Nov 2006 11:36:56 +0900 To: John Cowan , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: Just checking... In-Reply-To: <20061117064857.GD13257@ccil.org> References: <455CBA17.4A1F@xyzzy.claranet.de> <20061116193040.GX5359@ccil.org> <455CC622.46AB@xyzzy.claranet.de> <20061117064857.GD13257@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:48 06/11/17, John Cowan wrote: >Frank Ellermann scripsit: > >> As usual I prefer extensions, when there's a clear topic or issue, >> and the variant approach would result in an "emulated" singleton, >> fonxyz instead of f-xyz, or here 6xyz instead of 6-xyz. > >This is what variants are *for*. Read the section on them in >4646 again. Two points: 1) This is indeed what variants are for, but there is no restriction on what extensions are for, in partucular there is nothing saying that you can't use extensions for variants. 2) One reason where an extension would be better is that the necessary data (flags and such) could easily go on a separate place (IANA or elsewhere), whereas extensions all have to go on the same page (unless we would decide to change that). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 03:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOW-0000hy-NO; Sun, 19 Nov 2006 03:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GliOV-0000hm-Eh for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GliOR-00053Z-LA for ltru@ietf.org; Sun, 19 Nov 2006 03:51:19 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAJ8owCg007618 for ; Sun, 19 Nov 2006 17:51:00 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2d45_135d7e02_77ab_11db_9c9d_0014221f2a2d; Sun, 19 Nov 2006 17:50:57 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39818) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 19 Nov 2006 17:50:25 +0900 Message-Id: <6.0.0.20.2.20061118114301.0963a340@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 18 Nov 2006 11:45:46 +0900 To: debbie@ictmarketing.co.uk, From: Martin Duerst Subject: RE: [Ltru] LTRU progress and ISO 639-6 In-Reply-To: <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> References: <20061116062208.GI5359@ccil.org> <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 18:15 06/11/16, Debbie Garside wrote: >John wrote: >>The script and country values should also be >> used, and the variant should be omitted if it contains no >> further data: kca-Latn, not kca-Latn-6kcal. > >Agreed, other than when suppress script comes into play. Just an idea that came up: It looks like some of the 639-6 data could help figuring out some more suppress-scripts (or otherwise decide on how to solve that issues). What I'm assuming is that the 639-6 data might be a good source for what language is written with what scripts. Just an idea. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 04:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glia9-0004fg-Ni; Sun, 19 Nov 2006 04:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glia8-0004fa-Gg for ltru@ietf.org; Sun, 19 Nov 2006 04:03:20 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glia7-00064h-6C for ltru@ietf.org; Sun, 19 Nov 2006 04:03:20 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061119090316.VBHK2497.mta11.adelphia.net@DGBP7M81> for ; Sun, 19 Nov 2006 04:03:16 -0500 Message-ID: <001901c70bb9$8dfc83a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 19 Nov 2006 01:03:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ltru] "IETF language code" in Wikipedia X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 just found the article "IETF language code" in Wikipedia, which purports to describe RFC 4646 language tagging but contains some rather serious factual errors and misleading statements. A few examples: "It is written that subtags are separated from each other by a hyphen. This is not true for the given examples in cases where the subtags are empty. The example is en not en-----." This statement presupposes that tags can contain "empty subtags," which do not in fact exist. There is only one subtag in the tag "en". "The IETF only derives their subtags from ISO standards, they are therefore not ISO conform." The RFC 4646 system does not claim to be "ISO-conformant," and explicitly seeks to mitigate some of the instability of the ISO standards, so this statement is a red herring. Country-code TLDs are also not ISO-conformant since they use ".uk" instead of ".gb", and use other extensions to ISO 3166 such as ".ac". "It also reserves some tag parts that currently do not exist. Section 2.2.1, point 4 reads: "4. All four-character language subtags are reserved for possible future standardization. "At the same time ISO 15924 is a four-character subtag, all ready." This is a non sequitur. There is no syntactical or namespace collision between language subtags and script subtags, just as there is none between 2-letter language subtags and region subtags. "Since the ISO 3166-1 alpha-2 can change from time to time there is ambiguity in the use. E.g. CS could refer to Serbia and Montenegro or to Czechoslovakia. Section 2.2.4. point 3 C&D solve this. For ambiguous ISO 3166-1 codes the UN M.49 code shall be used." This is oversimplified to the point of inaccuracy. While ISO code elements may be ambiguous for the reason given, RFC 4646 does not assign a UN M.49-based subtag in place of *each* of the "ambiguous codes," only the more recently assigned. Going forward, if ISO 3166/MA reassigned "CS" to yet another country, that country would get a UN-based subtag but the existing "CS" subtag would not be changed. I'll be making the necessary factual corrections to the article, but others are of course free to jump in and do it first. I thought it would be good to let the list know that these misconceptions exist and may be widespread, because of the wide use of Wikipedia, -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 07:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GllwT-0003M0-O8; Sun, 19 Nov 2006 07:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GllwS-0003KU-GK for ltru@lists.ietf.org; Sun, 19 Nov 2006 07:38:36 -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 1GlluT-00010T-Ah for ltru@lists.ietf.org; Sun, 19 Nov 2006 07:36:36 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GlluE-0003ft-VW for ltru@lists.ietf.org; Sun, 19 Nov 2006 13:36:18 +0100 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 13:36:18 +0100 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 13:36:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 19 Nov 2006 13:29:06 +0100 Organization: Lines: 20 Message-ID: <45604E12.3127@xyzzy.claranet.de> References: <001901c70bb9$8dfc83a0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: "IETF language code" in Wikipedia X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'll be making the necessary factual corrections to the article The title is already dubious, "Internet language tags" or similar would be clearer. But better start with small corrections before. > let the list know that these misconceptions exist and may be > widespread It has only three links ("what links here", not counting the "IANA language code" redirect), and in essence one author ("history") => likely a genuine error and no intentional disinformation, unless it's about the "IETF" bit on the same level as "linguasphere". Get some good asbestos for this endeavour, Wikipedia is worse than the IETF in all respects. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 08:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmS4-0005pW-Rr; Sun, 19 Nov 2006 08:11:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmS3-0005p4-0q for ltru@lists.ietf.org; Sun, 19 Nov 2006 08:11:15 -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 1GlmRz-0003Wh-PN for ltru@lists.ietf.org; Sun, 19 Nov 2006 08:11:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GlmRq-0000T2-QN for ltru@lists.ietf.org; Sun, 19 Nov 2006 14:11:02 +0100 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 14:11:02 +0100 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 14:11:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 19 Nov 2006 14:08:02 +0100 Organization: Lines: 24 Message-ID: <45605732.7C77@xyzzy.claranet.de> References: <000501c70ba2$8bcf13c0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 1) Are we planning to un-reserve the 4-letter primary language subtags, > since it's obvious we aren't going to use them for the intended purpose? No, the 4646ter folks should at least in theory be free to replace the current structured tags by simple 639-6 alpha4 codes *IFF* that's better. Very unlikely, but I want them to be free to consider it. We have no compelling reasons to use these codes for something else. Actually we've no reason at all to use them for something else before 639-6 is published. > 2) Is the extension mechanism really so distasteful that we would > rather register thousands of "6xxxx" variants instead? No, 6xxxx variants are a dubious idea. Variants are a fallback mechanism for various special cases bound to specific prefixes, discussed and then registered by the review list individually. Extensions are for generally interesting properties, with their own RFCs and maintenance procedures. We might need a rule that variants can be deprecated in favour of a later established extension. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 09:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlnDf-0005kb-Tq; Sun, 19 Nov 2006 09:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlnDb-0005gj-G0 for ltru@lists.ietf.org; Sun, 19 Nov 2006 09:00:23 -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 1GlnCv-0007TX-6z for ltru@lists.ietf.org; Sun, 19 Nov 2006 08:59:42 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GlnCn-0000yR-M4 for ltru@lists.ietf.org; Sun, 19 Nov 2006 14:59:33 +0100 Received: from pd9fba931.dip0.t-ipconnect.de ([217.251.169.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 14:59:33 +0100 Received: from nobody by pd9fba931.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 14:59:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 19 Nov 2006 14:56:52 +0100 Organization: Lines: 51 Message-ID: <456062A4.7B63@xyzzy.claranet.de> References: <455CBFCA.4872@xyzzy.claranet.de> <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba931.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > Is there a liklihood that "nap-6napl" would be useful? I suppose if we > suddenly had a need for "nap-Grek" it would be. Hmmm... I can see a > glimmer of a need. If "napl" would be never interesting you probably wouldn't list it (?) You're not forced to consider backwards compatibility with 3066 tags and applications. From your POV the complete "Suppress-Script" business in 4646 is plain nonsense, you want as much info as you can possibly cram into alpha4 code elements. I think, please correct me... :-) > The rules for suppress script, once invoked are they set in stone? No. A Suppress-Script won't jump from Aaaa to Bbbb - unless Aaaa was an unlikely error, confusing Latg and Goth, or something in that direction. But adding or removing a Suppress-Sript is possible. > Could you suppress "nap" now and unsuppress in the future? Unsuppress is unlikely in that case, why would they start to use a new script in addition to Latn, justifying to explicitly distinguish Latn and this new script in language tags ? The problem we have now is the missing Suppress-Script Latn, which could be introduced later. At the moment a tag nap-Latn is perfectly okay, and therefore nap-6-napl or nap-Latn-6-napl would be wrong / redundant. As soon as nap gets a Suppress-Script Latn the nap-Latn-6-napl is still wrong / redundant. But suddenly nap-6-napl would be allowed instead of the then suppressed nap-Latn. Kind of messy. IMO we must finish this kludge for the 4646 languages, hoping that it will be almost never used for the 639-3 languages, and almost never changed where it's used. The "hope" could go as far as a NOT RECOMMENDED. It was a huge mistake to delegate this task to the review list, and of course it's impossible to deal with it as soon as thousands of 639-3 languages are in. It's mainly relevant for existing 3066 tags, and for existing 3066 applications. For the new 639-3 languages we can demand that taggers get this right, adding script subtags where they feel that it's necessary. For existing 3066 tags it's different, the taggers couldn't add scripts even where it's necessary before it was allowed by 4646. The about ten languages added after 4646 was introduced are a border case, for "ngo" a Suppress-Script was added, for "frr" and "frs" it wasn't. That's no consistent solution, IMO we've to fix it for all language subtags added before the 4645bis bulk update. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 12:27:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqSI-0002in-R4; Sun, 19 Nov 2006 12:27:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqSH-0002iS-G2 for ltru@ietf.org; Sun, 19 Nov 2006 12:27:45 -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 1GlqS8-0000fK-6C for ltru@ietf.org; Sun, 19 Nov 2006 12:27:44 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005797970.msg for ; Sun, 19 Nov 2006 17:30:31 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sun, 19 Nov 2006 17:27:47 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] LTRU progress and ISO 639-6 Date: Sun, 19 Nov 2006 17:27:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.0.0.20.2.20061118114301.0963a340@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccLt/8XOC7nMkrzSn+fSJBooKog+gAR5zGw Message-ID: X-Spam-Processed: mx1.nexbyte.net, Sun, 19 Nov 2006 17:30:31 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sun, 19 Nov 2006 17:30:32 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Martin wrote: > Just an idea that came up: It looks like some of the 639-6 > data could help figuring out some more suppress-scripts (or > otherwise decide on how to solve that issues). > > What I'm assuming is that the 639-6 data might be a good > source for what language is written with what scripts. Just an idea. This is true. However, I would only be happy to recommend suppress-script options once the data has been verified. Best Debbie Debbie Garside www.geolang.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 12:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqtA-0003ix-MN; Sun, 19 Nov 2006 12:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glqt9-0003ir-Dj for ltru@lists.ietf.org; Sun, 19 Nov 2006 12:55:31 -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 1Glqt4-0003aQ-02 for ltru@lists.ietf.org; Sun, 19 Nov 2006 12:55:31 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005798494.msg for ; Sun, 19 Nov 2006 17:58:31 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sun, 19 Nov 2006 17:55:46 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: LTRU progress and ISO 639-6 Date: Sun, 19 Nov 2006 17:55:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <456062A4.7B63@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccL4z9A2dIcVfBMR+67NNfhou3+pwAHMdrQ Message-ID: <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Sun, 19 Nov 2006 17:58:31 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sun, 19 Nov 2006 17:58:32 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Frank wrote: > If "napl" would be never interesting you probably wouldn't > list it (?) You're not forced to consider backwards > compatibility with 3066 tags and applications. From your POV > the complete "Suppress-Script" business in > 4646 is plain nonsense, you want as much info as you can > possibly cram into alpha4 code elements. I think, please > correct me... :-) Yes, from the POV of ISO 639-6 suppress-script is not relevant; napl is relevant to other users of ISO 639-6 as the system, necessarily, needs to offer "stand-alone" tags. However, from the POV of extension coding and my participation in this WG it is and if ISO 639-6 data can help RFC4646bis and the compilation of data for the Registry, all well and good. > > > The rules for suppress script, once invoked are they set in stone? > > No. A Suppress-Script won't jump from Aaaa to Bbbb - unless > Aaaa was an unlikely error, confusing Latg and Goth, or > something in that direction. > But adding or removing a Suppress-Sript is possible. > > > Could you suppress "nap" now and unsuppress in the future? > > Unsuppress is unlikely in that case, why would they start to > use a new script in addition to Latn, justifying to > explicitly distinguish Latn and this new script in language tags ? As a hypothetical case: Say, for instance, that an archaeological dig unearthed materials written in nap-Grek; the academic community would then be interested in searching/archiving/matching nap-Grek. > The problem we have now is the missing Suppress-Script Latn, > which could be introduced later. At the moment a tag > nap-Latn is perfectly okay, and therefore nap-6-napl or > nap-Latn-6-napl would be wrong / redundant. Why would it be wrong? nap-Latn-6-napl means the same as nap-Latn. The only thing wrong would be that it is not tagging content wisely. I seem to remember a paragraph in RFC4646 that states to (SHOULD) use only the tags that are necessary to accurately identify the object. > As soon as nap gets a Suppress-Script Latn the > nap-Latn-6-napl is still wrong / redundant. But suddenly > nap-6-napl would be allowed instead of the then suppressed > nap-Latn. I am not sure I really understand this. Surely if nap was allocated the suppress-script Latn, then nap becomes equal to nap-Latn. Therefore, if nap-Latn-6-napl is disallowed prior to the suppress-script then nap-6-napl is also disallowed subsequently as in effect its meaning is the same as nap-Latn-6-napl. Or maybe I am just completely suppress-script illiterate :-) > Kind of messy. IMO we must finish this kludge for > the 4646 languages, hoping that it will be almost never used > for the 639-3 languages, and almost never changed where it's > used. The "hope" could go as far as a NOT RECOMMENDED. By "NOT RECOMMENDED" I assume you mean not recommended to suppress scripts? > > It was a huge mistake to delegate this task to the review > list, and of course it's impossible to deal with it as soon > as thousands of 639-3 languages are in. Can you remind me of the reasoning behind suppress-script being included? (perhaps off-list as everyone has heard it before). All I can remember is that there are applications and protocols that cannot deal with script tags. Best Debbie Debbie Garside www.qeolang.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 14:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gls4o-0005ES-ID; Sun, 19 Nov 2006 14:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gls4n-0005EM-BC for ltru@lists.ietf.org; Sun, 19 Nov 2006 14:11:37 -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 1Gls4k-00087k-Ra for ltru@lists.ietf.org; Sun, 19 Nov 2006 14:11:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gls4j-0000VK-Mg for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:11:33 +0100 Received: from du-001-004.access.de.clara.net ([212.82.227.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 20:11:33 +0100 Received: from nobody by du-001-004.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Nov 2006 20:11:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 19 Nov 2006 20:09:26 +0100 Organization: Lines: 92 Message-ID: <4560ABE6.5685@xyzzy.claranet.de> References: <456062A4.7B63@xyzzy.claranet.de> <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-004.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > if ISO 639-6 data can help RFC4646bis and the compilation of data for > the Registry, all well and good. ...and maybe avoid some discussions about the best variant subtag, what would 639-6 offer for say the arevela / arevmda subtags ? > As a hypothetical case: Say, for instance, that an archaeological dig > unearthed materials written in nap-Grek; the academic community would > then be interested in searching/archiving/matching nap-Grek. That's no problem, if Latn is suppressed anything else is still okay. They could also unearth tons of de-Latf books, it wouldn't affect the Suppress-Script Latn for de. >> At the moment a tag nap-Latn is perfectly okay, and therefore >> nap-6-napl or nap-Latn-6-napl would be wrong / redundant. > Why would it be wrong? nap-Latn-6-napl means the same as nap-Latn. Because John's algorithm to eliminate dupes / redundancies would say that nap-Latn is good enough, no 6napl or 6-napl needed or allowed. Maybe I'm wrong, but apparently that algorithm determines all 639-6 code elements already covered by other means (script, region, variant), and only the rest of 639-6 (not already covered) is used to form tags. So if 639-6 offers "enlu" with the same meaning as en-Latn-US, then en-Latn-US wins, and "enlu" is never used in 4646ter tags, and also no candidate for a 4646bis variant "6enlu". But if 639-6 offers "enny" for en as in New York it's finer than any RFC 4646 tag (at the moment), and en-6enny or en-6-enny can be used - maybe directly with 4646ter. Or registered as variant 6enny on demand, and then used. Or as the extension 6-enny as soon as the 6-extension registry is specified and populated. > I seem to remember a paragraph in RFC4646 that states to (SHOULD) > use only the tags that are necessary to accurately identify the > object. John's algorithm as an application of this SHOULD ? I thought it's a MUST. I wouldn't like a situation where nap-Latn and nap-6-napl are in theory both possible. > Surely if nap was allocated the suppress-script Latn, then nap > becomes equal to nap-Latn. Therefore, if nap-Latn-6-napl is > disallowed prior to the suppress-script then nap-6-napl is also > disallowed subsequently as in effect its meaning is the same as > nap-Latn-6-napl. Why should nap-6-napl be disallowed ? It's Suppress-Script: Latn, not Suppress-Extension: 6-napl. It's less fuzzy than nap after the Suppress-Script suppressed nap-Latn. > Or maybe I am just completely suppress-script illiterate :-) Could be also me, but nap-6-napl is written, for nap we're not sure. The Suppress-Script intentionally removes some info for the higher goal of backwards compatibility and better matching. If somebody uses nap-6-napl they intentionally don't care about that. Maybe we could decree that a Suppress-Script also affects 639-6 code elements identifying the supressed script if used in language tags, then it's as you say, all would be disallowed. So far I assumed that the Suppress-Script only affects script subtags, not 639-6 (?) >> messy. IMO we must finish this kludge for the 4646 languages, >> hoping that it will be almost never used for the 639-3 languages, >> and almost never changed where it's used. The "hope" could go >> as far as a NOT RECOMMENDED. > By "NOT RECOMMENDED" I assume you mean not recommended to suppress > scripts? Yes, for anything added by 4645bis and afterwards. Doug said that there's no chance to figure this out for thousands of languages, or to deal with it piecemeal on the review list. For the about 500 languages registered now, almost all old 3066-languages, including "nap", it's still possible. > All I can remember is that there are applications and protocols > that cannot deal with script tags. That's all, they can handle en or en-US, but not en-Latn-US. And of course most existing documents using these tags won't have scripts, it's a new 4646-invention. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 20:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlxuG-0000yi-Nt; Sun, 19 Nov 2006 20:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlxuE-0000yc-S3 for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:25:06 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlxuD-0005pn-IH for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:25:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TX68s1YnnmfjcdymA6FoudF9GeMkInqurXwB6ZwT7wuJ/81cOaN31vZT6BeeH/qk; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.67] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GlxuB-0003tg-3X for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:25:03 -0500 Message-ID: <004c01c70c42$d24599a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Date: Sun, 19 Nov 2006 17:25:50 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6e07502f91b6c7e076f56d18f4c87e233350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.67 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Debbie Garside" > To: ; > Sent: Sunday, November 19, 2006 9:55 AM > Subject: RE: [Ltru] Re: LTRU progress and ISO 639-6 ... > Can you remind me of the reasoning behind suppress-script being included? > (perhaps off-list as everyone has heard it before). All I can remember is > that there are applications and protocols that cannot deal with script tags. ... As I see it... Supress-script exists to encourage consistent tagging. It is only needed for those languages which meet BOTH of these criteria: - there is already a significant amount of material tagged for the language, but without any script subtag - virtually all material in that language is written in the same script If the language is written in multiple scripts, Suppress-script clearly doesn't apply. If there is not a significant amount of material already tagged (yes, this is a judgment call, and I hope ietf-languages@iana.org would be cautious) there is also no reason to use Suppress-script for that language, since there is not an existing "base" with which compatibility is needed. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 20:58:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlyQn-0004V0-3c; Sun, 19 Nov 2006 20:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlyQm-0004Tq-2E for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:58:44 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlyQk-00008C-RS for ltru@lists.ietf.org; Sun, 19 Nov 2006 20:58:44 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GlyQj-0008CT-Pw; Sun, 19 Nov 2006 20:58:41 -0500 Date: Sun, 19 Nov 2006 20:58:41 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061120015841.GA24285@ccil.org> References: <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> <004c01c70c42$d24599a0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01c70c42$d24599a0$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > - there is already a significant amount of material tagged > for the language, but without any script subtag > - virtually all material in that language is written in the > same script I would even add a third criterion: that the language is likely to be used with a region-tag. The problem being solved is that "en-US" will not match "en-Latn-US" properly; there really isn't a problem with "ka" vs. "ka-Geor", say, though we do have it suppressed. > If the language is written in multiple scripts, Suppress-script > clearly doesn't apply. If there is not a significant amount > of material already tagged (yes, this is a judgment call, and > I hope ietf-languages@iana.org would be cautious) there > is also no reason to use Suppress-script for that language, > since there is not an existing "base" with which compatibility > is needed. +1 -- John Cowan cowan@ccil.org At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, With loud and high-pitched ululation. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 21:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glyux-0005yE-Al; Sun, 19 Nov 2006 21:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glyuw-0005y4-CX for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:29:54 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glyuv-0002N8-4q for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:29:54 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Glyuu-0002To-Cz; Sun, 19 Nov 2006 21:29:52 -0500 Date: Sun, 19 Nov 2006 21:29:52 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061120022952.GB24285@ccil.org> References: <456062A4.7B63@xyzzy.claranet.de> <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> <4560ABE6.5685@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4560ABE6.5685@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: > Because John's algorithm to eliminate dupes / redundancies would say > that nap-Latn is good enough, no 6napl or 6-napl needed or allowed. Just so. > Maybe I'm wrong, but apparently that algorithm determines all 639-6 > code elements already covered by other means (script, region, variant), > and only the rest of 639-6 (not already covered) is used to form tags. Exactly, with the addendum that a 639-6 tag that covers multiple languages would be used directly as an unqualified 4-alpha tag. > So if 639-6 offers "enlu" with the same meaning as en-Latn-US, then > en-Latn-US wins, and "enlu" is never used in 4646ter tags, and also > no candidate for a 4646bis variant "6enlu". Yes. > But if 639-6 offers "enny" for en as in New York it's finer than any > RFC 4646 tag (at the moment), and en-6enny or en-6-enny can be used - > maybe directly with 4646ter. Or registered as variant 6enny on demand, > and then used. Or as the extension 6-enny as soon as the 6-extension > registry is specified and populated. Yes, though I think the first of these is the best, as it involves the smallest amount of process for users. > Could be also me, but nap-6-napl is written, for nap we're not sure. > The Suppress-Script intentionally removes some info for the higher > goal of backwards compatibility and better matching. If somebody > uses nap-6-napl they intentionally don't care about that. Saying that 'nap' has a Suppress-Script of 'Latn' means that we've decided as a matter of public policy that the distinctions between Neapolitan unspecified, Neapolitan spoken, and Neapolitan written in Latin are insignificant. Reintroducing a way of making those distinctions through the back door is a Bad Thing. -- John Cowan cowan@ccil.org http://ccil.org/~cowan I come from under the hill, and under the hills and over the hills my paths led. And through the air. I am he that walks unseen. I am the clue-finder, the web-cutter, the stinging fly. I was chosen for the lucky number. --Bilbo _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 21:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glz0q-0007dy-N0; Sun, 19 Nov 2006 21:36:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glz0p-0007ds-Tu for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:35:59 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glz0o-0002m8-Mg for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:35:59 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Glz0n-0002df-Aa; Sun, 19 Nov 2006 21:35:57 -0500 Date: Sun, 19 Nov 2006 21:35:57 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061120023556.GC24285@ccil.org> References: <455CBFCA.4872@xyzzy.claranet.de> <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> <456062A4.7B63@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456062A4.7B63@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Unsuppress is unlikely in that case, why would they start to use a new > script in addition to Latn, justifying to explicitly distinguish Latn > and this new script in language tags ? Politics. If Greece reconquered Neapolis (or bought it back from Italy, more likely), nap-Grek might well become an important language. > The problem we have now is the missing Suppress-Script Latn, which could > be introduced later. At the moment a tag nap-Latn is perfectly okay, > and therefore nap-6-napl or nap-Latn-6-napl would be wrong / redundant. > > As soon as nap gets a Suppress-Script Latn the nap-Latn-6-napl is still > wrong / redundant. But suddenly nap-6-napl would be allowed instead of > the then suppressed nap-Latn. No, I disagree. Quite independent of Suppress-Script, 'napl' does not contain any extra information above "nap" or "nap-Latn" as the case may be. So it remains forbidden to use either "nap-6napl" or "nap-Latn-6napl". See my previous post for the rationale. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 19 21:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glz4u-0001ZM-0r; Sun, 19 Nov 2006 21:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glz4s-0001ZB-BF for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:40:10 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glz4r-00032A-4S for ltru@lists.ietf.org; Sun, 19 Nov 2006 21:40:10 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Glz4q-0003kS-O7; Sun, 19 Nov 2006 21:40:08 -0500 Date: Sun, 19 Nov 2006 21:40:08 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061120024008.GD24285@ccil.org> References: <000501c70ba2$8bcf13c0$6501a8c0@DGBP7M81> <45605732.7C77@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45605732.7C77@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: > No, 6xxxx variants are a dubious idea. Variants are a fallback mechanism > for various special cases bound to specific prefixes, discussed and then > registered by the review list individually. Section 2.2.5 says: Variant subtags are used to indicate additional, well-recognized variations that define a language or its dialects that are not covered by other available subtags. I take "dialects" to include sociolects and orthographic variants. > Extensions are for generally > interesting properties, with their own RFCs and maintenance procedures. Yes; they are for extensions *to* language tags, providing non-language-tag-like information, which variant subtags are not. -- Mos Eisley spaceport. You will never John Cowan see a more wretched hive of scum and cowan@ccil.org villainy -- unless you watch the http://www.ccil.org/~cowan Jerry Springer Show. --georgettesworld.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 01:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2Ps-0003nI-00; Mon, 20 Nov 2006 01:14:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm2Pq-0003nD-Ke for ltru@ietf.org; Mon, 20 Nov 2006 01:14:02 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm2Pp-000228-AL for ltru@ietf.org; Mon, 20 Nov 2006 01:14:02 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061120061400.AWS23051.mta10.adelphia.net@DGBP7M81> for ; Mon, 20 Nov 2006 01:14:00 -0500 Message-ID: <005301c70c6b$13102e50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Just checking... Date: Sun, 19 Nov 2006 22:14:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > 2) One reason where an extension would be better is that the necessary > data (flags and such) could easily go on a separate place (IANA > or elsewhere), whereas extensions all have to go on the same page > (unless we would decide to change that). I assume this was supposed to read: "whereas variants all have to go on the same page..." Martin already understands the following, but I include it for those who may still be fuzzy about extensions: A basic feature of extension subtags is that they are not defined by LTRU or ietf-languages, and are not listed in the Language Subtag Registry or any other resource hosted by IANA. They are defined by an external "maintaining authority" and listed in a separate, non-IANA, non-IETF registry. There is a Language Tag Extensions Registry maintained by IANA, but it lists only the singleton and other basic information associated with each extension. All of this is described plainly in Section 3.7. If ISO 639-6 were used as the basis for an extension RFC, then all of the complicated rules we have been discussing -- which code elements could be used in language tags and which could not, which one would allow additional subtags (like script) and which would forbid them, which combinations would be impossible, etc. -- would be specified in that RFC, and the registry of subtags defined therein would be maintained by a third party. Neither LTRU nor ietf-languages would have to make any of those decisions, or vet thousands of subtags. The responsibility could fall on Debbie's Geolang organization, assisted by whoever volunteers (or is drafted) to assist. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 03:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Lg-0007bT-Sm; Mon, 20 Nov 2006 03:17:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm4Lf-0007Z5-Ld for ltru@ietf.org; Mon, 20 Nov 2006 03:17:51 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm4Lb-000121-As for ltru@ietf.org; Mon, 20 Nov 2006 03:17:51 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061120081746.FWJJ23051.mta10.adelphia.net@DGBP7M81> for ; Mon, 20 Nov 2006 03:17:46 -0500 Message-ID: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 20 Nov 2006 00:17:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ltru] ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 downloadable ISO/FDIS 639-3 tables have been substantially modified as of November 14, and they now contain additional information that will allow us to make critical decisions related to alternative and inverted language names. http://www.sil.org/iso639-3/download.asp The basic "code set" file has the same general format as before, but the "Name" or "Inverted_Name" field has been redefined as "Reference_Name". This appears to be the non-inverted form of one of the names associated with the language, often the most common (e.g. Spanish is listed instead of Castillian, Dutch instead of Flemish). No commas or semicolons are present in this file. An example is: crh crh crh I L Crimean Tatar A new 'language names index" file has been added, which lists all of the names associated with the language, in both non-inverted and inverted forms when present (two identical forms are given when there is no inversion). The file has one record for each distinct name, and does not use semicolons to separate multiple names. Commas are present only at the inversion points. An example is: crh Crimean Tatar Tatar, Crimean crh Crimean Turkish Turkish, Crimean The macrolanguage file is essentially the same as before; only the field names have been changed. A "retirements" file has been added to track changes made in the FDIS. This include one entry, the change from "fri" to "fry" that reflects the ISO 639-2 mapping. We in LTRU now have all the information related to ISO 639-3 language names that we need, and we need to make a decision about which names should appear in the RFC 4645bis Registry. Should we use: 1a. only the reference names shown in the main file? 1b. the reference and alternative names, but only in non-inverted form (when both exist)? 1c. the reference and alternative names, but only in inverted form (when both exist)? 1d. the reference and alternative names, in both inverted and non-inverted form? My preference is for option 1d, including all the names. We also need to decide whether to apply the decision in question 1 above to: 2a. all primary and extended language subtags in the Registry, possibly adding more names to existing subtags, or 2b. only the new subtags added with ISO 639-3. My preference is for option 2a, retrofitting new names onto existing subtags where ISO 639-3 lists them. Let's discuss our options here, make a decision, and incorporate it into the next draft of RFC 4646bis so I can reflect it in a new draft of RFC 4645bis. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 06:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6sx-0006BL-45; Mon, 20 Nov 2006 06:00:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6sw-0006BF-6c for ltru@ietf.org; Mon, 20 Nov 2006 06:00:22 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gm6st-0008VE-UF for ltru@ietf.org; Mon, 20 Nov 2006 06:00:22 -0500 Received: (qmail 8193 messnum 2898577 invoked from network[194.125.174.28/ts09-028.dublin.indigo.ie]); 20 Nov 2006 11:00:11 -0000 Received: from ts09-028.dublin.indigo.ie (HELO ?194.125.174.28?) (194.125.174.28) by mail07.svc.cra.dublin.eircom.net (qp 8193) with SMTP; 20 Nov 2006 11:00:11 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <200608041841.k74IfIt8005737@mta6.iomartmail.com> References: <200608041841.k74IfIt8005737@mta6.iomartmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3747AAE5-2F96-43E7-95B9-29E255F42A63@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Charter update proposal (updated) Date: Mon, 20 Nov 2006 11:03:44 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Maybe I missed something (traffic being so heavy on this list), but =20 I'd still be inclined to put a full stop after "languages" below =20 (losing the final 3 words). Reason: with languages disappearing from =20 use at such an alarming rate, leaving in those 3 words could cause =20 problems for marginal linguistic groups sans research facilities. mg On 4 Aug 2006, at 18:41, scr=EDobh Debbie Garside: > Addison wrote: > > >> "These additional code elements are intended to provide >> coverage for all known human languages in use today." - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 06:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7Uc-0005fv-Re; Mon, 20 Nov 2006 06:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7Ub-0005fj-Qf for ltru@ietf.org; Mon, 20 Nov 2006 06:39:17 -0500 Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gm7UQ-0004do-Av for ltru@ietf.org; Mon, 20 Nov 2006 06:39:17 -0500 Received: (qmail 4681 messnum 5396608 invoked from network[194.125.174.28/ts09-028.dublin.indigo.ie]); 20 Nov 2006 11:12:23 -0000 Received: from ts09-028.dublin.indigo.ie (HELO ?194.125.174.28?) (194.125.174.28) by mail08.svc.cra.dublin.eircom.net (qp 4681) with SMTP; 20 Nov 2006 11:12:23 -0000 Mime-Version: 1.0 (Apple Message framework v728) To: LTRU Working Group Message-Id: <531DC406-7448-4E06-AB2E-6DCC51EBD6A9@egt.ie> From: Marion Gunn Subject: Re: [Ltru] Charter update proposal (updated) Date: Mon, 20 Nov 2006 11:15:55 +0000 X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1992914999==" Errors-To: ltru-bounces@ietf.org --===============1992914999== Content-Type: multipart/alternative; boundary=Apple-Mail-2-1030562130 --Apple-Mail-2-1030562130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed For example - and please bear with me on this - see article below, =20 where a language is being regenerated from one living speaker, which =20 is a better chance than anyone would have given Hebrew as a living =20 language just over half a century ago. mg From: andrekar@NCIDC.ORG Subject: Stubborn Elder Date: 19 November 2006 09:19:13 GMT+00:00 To: ENDANGERED-LANGUAGES-L@LISTSERV.LINGUISTLIST.ORG Reply-To: andrekar@NCIDC.ORG Native language lives in woman Vi Hilbert of the Upper Skagit tribe stubbornly aims to keep the old =20 words of Lushootseed alive. By Krista J. Kapralos Herald Writer EVERETT - By her own admission, Vi Hilbert, 88, is stubborn. She was an only child raised in the Upper Skagit tribe. Her mother =20 loved to perform and her father was a medicine man. When they passed =20 the stories on to Hilbert, he spoke in Lushootseed, the language of =20 Western Washington's Coast Salish tribes. Hilbert was a child in a desperate era for American Indian tribes. =20 Tribal children went to boarding schools where they weren't allowed =20 to speak their native languages. Many children forgot Lushootseed, =20 but not Hilbert. She stubbornly tucked it away in her mind and in her heart. Years later, the language emerged from an age of darkness and was =20 brought into the light once again. Hilbert was one of the few people =20 who remembered enough of it to speak it again. At an event sponsored by Everett Community College's Diversity and =20 Equity Center Thursday, Hilbert shared her language with about 70 =20 students. The students leaned forward in their seats in an effort to =20 catch every word, and afterward they knelt on the floor in front of =20 Hilbert to thank her. "She's living history," said Earl Martin, director of the college's =20 counseling center and a member of the Cree tribe. "The knowledge she =20 passes down orally is just as valuable as anything that's in our =20 library." Hilbert has dedicated her life to the rebirth of Lushootseed. She =20 worked in the linguistics department at the University of Washington =20 for 15 years. In 1989, she received an honorary doctorate from =20 Seattle University and was named a Washington State Living Treasure. Hilbert has worked closely with linguists to develop a written form =20 of Lushootseed and publish dictionaries for the language. "Given her age, I've wanted to get her here while she's still able to =20= speak," said Christina Castorena, associate dean for diversity for =20 EvCC. "She's a local jewel, and it's an honor to have her here." Hilbert clutched a dark blanket around her thin shoulders as she sat =20 in a chair on the stage in Baker Hall on the EvCC campus. She =20 demanded that the students speak up if they wanted to ask her a =20 question. "I'm bossy," she said, smiling slyly. Hilbert said she's been criticized by some tribal members for sharing =20= Upper Skagit culture. She argues that every culture is important and =20 should be shared with as many people as possible. Sharing Lushootseed =20= and ancient Coast Salish stories won't dilute the value of the culture. "The language will live because it's important," she said. "The =20 culture will live because it's important." Reporter Krista J. Kapralos: 425-339-3422 or kkapralos@heraldnet.com. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-2-1030562130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
For example - and please bear with me on = this - see article below, where a language is being regenerated from one = living speaker, which is a better chance than anyone would have given = Hebrew as a living language just over half a century = ago.
mg

=A0 =A0From: =A0 =A0 =A0 andrekar@NCIDC.ORG
=A0 =A0 = Subject: =A0 =A0 = Stubborn Elder
=A0 =A0 Date: =A0 =A0 19 November 2006 09:19:13 = GMT+00:00
=A0 =A0 Reply-To: =A0 =A0 =A0 andrekar@NCIDC.ORG

Native language = lives in woman
Vi Hilbert of the = Upper Skagit tribe stubbornly aims to keep the old words of Lushootseed = alive.

By Krista J. Kapralos
Herald = Writer


EVERETT - By her = own admission, Vi Hilbert, 88, is stubborn.

She was an only = child raised in the Upper Skagit tribe. Her mother loved to perform and = her father was a medicine man. When they passed the stories on to = Hilbert, he spoke in Lushootseed, the language of Western Washington's = Coast Salish tribes.

Hilbert was a child in a desperate era for American Indian = tribes. Tribal children went to boarding schools where they weren't = allowed to speak their native languages. Many children forgot = Lushootseed, but not Hilbert.
She stubbornly tucked it away in her mind and = in her heart.

Years later, the language emerged from an age of darkness and was = brought into the light once again. Hilbert was one of the few people who = remembered enough of it to speak it again.

At an event = sponsored by Everett Community College's Diversity and Equity Center = Thursday, Hilbert shared her language with about 70 students. The = students leaned forward in their seats in an effort to catch every word, = and afterward they knelt on the floor in front of Hilbert to thank = her.

"She's living history," said Earl Martin, director of the = college's counseling center and a member of the Cree tribe. "The = knowledge she passes down orally is just as valuable as anything that's = in our library."

Hilbert has dedicated her life to the rebirth of Lushootseed. She = worked in the linguistics department at the University of Washington for = 15 years. In 1989, she received an honorary doctorate from Seattle = University and was named a Washington State Living = Treasure.

Hilbert has worked closely with linguists to develop a written = form of Lushootseed and publish dictionaries for the = language.

"Given her age, I've wanted to get her here while she's still = able to speak," said Christina Castorena, associate dean for diversity = for EvCC. "She's a local jewel, and it's an honor to have her = here."

Hilbert clutched a dark blanket around her thin shoulders as she = sat in a chair on the stage in Baker Hall on the EvCC campus. She = demanded that the students speak up if they wanted to ask her a = question.

"I'm bossy," she said, smiling slyly.

Hilbert said she's = been criticized by some tribal members for sharing Upper Skagit culture. = She argues that every culture is important and should be shared with as = many people as possible. Sharing Lushootseed and ancient Coast Salish = stories won't dilute the value of the culture.

"The language will = live because it's important," she said. "The culture will live because = it's important."

Reporter Krista J. Kapralos: 425-339-3422 or kkapralos@heraldnet.com.
- -=A0
Marion Gunn * EGTeo = (Estab.1991)
27 P=E1irc an Fh=E9ithlinn, Baile an =
Bh=F3thair, Co. =C1tha Cliath, =C9ire.
=

= --Apple-Mail-2-1030562130-- --===============1992914999== 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 --===============1992914999==-- From ltru-bounces@ietf.org Mon Nov 20 08:07:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm8sL-0002ZJ-EH; Mon, 20 Nov 2006 08:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm8sK-0002ZE-4x for ltru@ietf.org; Mon, 20 Nov 2006 08:07:52 -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 1Gm8sE-00076i-RK for ltru@ietf.org; Mon, 20 Nov 2006 08:07:52 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005818421.msg for ; Mon, 20 Nov 2006 13:10:53 +0000 Received: from debbie ([213.208.115.6]) by home with MailEnable ESMTP; Mon, 20 Nov 2006 13:08:09 +0000 From: "Debbie Garside" To: "'LTRU Working Group'" , "'Marion Gunn'" Subject: RE: [Ltru] Charter update proposal (updated) Date: Mon, 20 Nov 2006 13:07:30 -0000 Message-ID: <01a901c70ca4$d5ec46f0$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <3747AAE5-2F96-43E7-95B9-29E255F42A63@egt.ie> Thread-Index: AccMk0uD2yXUfNsEQtm0i0Qs7loqMQAELoIg X-Spam-Processed: mx1.nexbyte.net, Mon, 20 Nov 2006 13:10:53 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Mon, 20 Nov 2006 13:10:54 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Marion wrote: > Maybe I missed something (traffic being so heavy on this list), but = I'd still be inclined to put a full stop after "languages" below (losing the final 3 words). Reason: with languages disappearing from use at such an alarming rate, leaving in those 3 words could cause problems for = marginal linguistic groups sans research facilities. I think "in use today" can be interpreted quite broadly as spoken/written/studied/revived/documented, so I am not sure that I can = see a problem.=20 Best regards Debbie -----Original Message----- From: Marion Gunn [mailto:mgunn@egt.ie]=20 Sent: 20 November 2006 11:04 To: LTRU Working Group Subject: Re: [Ltru] Charter update proposal (updated) Maybe I missed something (traffic being so heavy on this list), but I'd still be inclined to put a full stop after "languages" below (losing the final 3 words). Reason: with languages disappearing from use at such an alarming rate, leaving in those 3 words could cause problems for = marginal linguistic groups sans research facilities. mg On 4 Aug 2006, at 18:41, scr=EDobh Debbie Garside: > Addison wrote: > > >> "These additional code elements are intended to provide coverage for=20 >> all known human languages in use today." - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 11:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC4t-000757-7F; Mon, 20 Nov 2006 11:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC4r-000746-Ln for ltru@ietf.org; Mon, 20 Nov 2006 11:33:01 -0500 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmC4p-0004vw-3K for ltru@ietf.org; Mon, 20 Nov 2006 11:33:01 -0500 Received: by nz-out-0102.google.com with SMTP id k1so954348nzf for ; Mon, 20 Nov 2006 08:32:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ebW7YBHQNWYKps3Kvg3khI69v5DPbhuYIBAsDev80cZIQk04fURqbdZn8UWFG2eE3Jgxg6K2PDjBETC/GVWPxKvleDJPLHyG2S+43TE6xyBPMOI3m2Rm2lG6QCF8py/ca1P9i+39pgZ2MU2J2EWDKl+50RI7GnvziP2JAtnL8l0= Received: by 10.65.216.19 with SMTP id t19mr8241607qbq.1164040364986; Mon, 20 Nov 2006 08:32:44 -0800 (PST) Received: by 10.65.252.11 with HTTP; Mon, 20 Nov 2006 08:32:44 -0800 (PST) Message-ID: <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> Date: Mon, 20 Nov 2006 08:32:44 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised In-Reply-To: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> X-Google-Sender-Auth: 3af9b32f506ed2e1 X-Spam-Score: 0.5 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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="===============0342597526==" Errors-To: ltru-bounces@ietf.org --===============0342597526== Content-Type: multipart/alternative; boundary="----=_Part_62114_24890210.1164040364931" ------=_Part_62114_24890210.1164040364931 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I looked over these table this morning, and all I can say is: *fabulous*! The 639-3 people have done a wonderful job with these tables, and very thorough work on the names. They have done such a good job that I don't see any barrier to using the information as is. The only real question is how best to leverage it. Here is my take: Fields to add: 1. Three Letter Code: it would indeed be handy to have the 3 letter code around, for those cases where our canonical subtag is 2 letter. While that is somewhat peripheral to our main function, it would be useful to have this for both the language subtag and the region subtag to help in identification, perhaps as "Type-Equivalent"? 2. Inverted Names: I suggest we add an additional field for these, allowing more than one. Maybe "Inverted-Description"? We could change any of the current descriptions that are inverted to Inverted-Description, and add add the 639-3 ones (1403 of them). 3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), S(pecial). This would be very useful information for identification, and I suggest we add it as a Language-Type field Fields that our current structure can accommodate: 1. Scope: we don't need to add this, since it can be derived: something is a macro language iff there is an extlang that points to it. 2. Reference Name: If we have the convention that the first Description is the reference name, then we could incorporate all of this information without changing our structure. Note: 636-3 only has 85 cases of multiple names. 3. Other Names: we can add any alternate names as additional descriptions. Mark On 11/20/06, Doug Ewell wrote: > > The downloadable ISO/FDIS 639-3 tables have been substantially modified > as of November 14, and they now contain additional information that will > allow us to make critical decisions related to alternative and inverted > language names. > > http://www.sil.org/iso639-3/download.asp > > The basic "code set" file has the same general format as before, but the > "Name" or "Inverted_Name" field has been redefined as "Reference_Name". > This appears to be the non-inverted form of one of the names associated > with the language, often the most common (e.g. Spanish is listed instead > of Castillian, Dutch instead of Flemish). No commas or semicolons are > present in this file. An example is: > > crh crh crh I L Crimean Tatar > > A new 'language names index" file has been added, which lists all of the > names associated with the language, in both non-inverted and inverted > forms when present (two identical forms are given when there is no > inversion). The file has one record for each distinct name, and does > not use semicolons to separate multiple names. Commas are present only > at the inversion points. An example is: > > crh Crimean Tatar Tatar, Crimean > crh Crimean Turkish Turkish, Crimean > > The macrolanguage file is essentially the same as before; only the field > names have been changed. > > A "retirements" file has been added to track changes made in the FDIS. > This include one entry, the change from "fri" to "fry" that reflects the > ISO 639-2 mapping. > > We in LTRU now have all the information related to ISO 639-3 language > names that we need, and we need to make a decision about which names > should appear in the RFC 4645bis Registry. Should we use: > > 1a. only the reference names shown in the main file? > 1b. the reference and alternative names, but only in non-inverted form > (when both exist)? > 1c. the reference and alternative names, but only in inverted form > (when both exist)? > 1d. the reference and alternative names, in both inverted and > non-inverted form? > > My preference is for option 1d, including all the names. > > We also need to decide whether to apply the decision in question 1 above > to: > > 2a. all primary and extended language subtags in the Registry, possibly > adding more names to existing subtags, or > 2b. only the new subtags added with ISO 639-3. > > My preference is for option 2a, retrofitting new names onto existing > subtags where ISO 639-3 lists them. > > Let's discuss our options here, make a decision, and incorporate it into > the next draft of RFC 4646bis so I can reflect it in a new draft of RFC > 4645bis. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_62114_24890210.1164040364931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I looked over these table this morning, and all I can say is: *fabulous*! The 639-3 people have done a wonderful job with these tables, and very thorough work on the names. They have done such a good job that I don't see any barrier to using the information as is. The only real question is how best to leverage it. Here is my take:

Fields to add:
  1. Three Letter Code: it would indeed be handy to have the 3 letter code around, for those cases where our canonical subtag is 2 letter. While that is somewhat peripheral to our main function, it would be useful to have this for both the language subtag and the region subtag to help in identification, perhaps as "Type-Equivalent"?
  2. Inverted Names: I suggest we add an additional field for these, allowing more than one. Maybe "Inverted-Description"? We could change any of the current descriptions that are inverted to Inverted-Description, and add add the 639-3 ones (1403 of them).
  3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), S(pecial). This would be very useful information for identification, and I suggest we add it as a Language-Type field
Fields that our current structure can accommodate:
  1. Scope: we don't need to add this, since it can be derived: something is a macro language iff there is an extlang that points to it.
  2. Reference Name: If we have the convention that the first Description is the reference name, then we could incorporate all of this information without changing our structure. Note: 636-3 only has 85 cases of multiple names.
  3. Other Names: we can add any alternate names as additional descriptions.
Mark

On 11/20/06, Doug Ewell < dewell@adelphia.net> wrote:
The downloadable ISO/FDIS 639-3 tables have been substantially modified
as of November 14, and they now contain additional information that will
allow us to make critical decisions related to alternative and inverted
language names.

http://www.sil.org/iso639-3/download.asp

The basic "code set" file has the same general format as before, but the
"Name" or "Inverted_Name" field has been redefined as "Reference_Name".
This appears to be the non-inverted form of one of the names associated
with the language, often the most common (e.g. Spanish is listed instead
of Castillian, Dutch instead of Flemish).  No commas or semicolons are
present in this file.  An example is:

    crh     crh     crh             I       L       Crimean Tatar

A new 'language names index" file has been added, which lists all of the
names associated with the language, in both non-inverted and inverted
forms when present (two identical forms are given when there is no
inversion).  The file has one record for each distinct name, and does
not use semicolons to separate multiple names.  Commas are present only
at the inversion points.  An example is:

    crh     Crimean Tatar   Tatar, Crimean
    crh     Crimean Turkish Turkish, Crimean

The macrolanguage file is essentially the same as before; only the field
names have been changed.

A "retirements" file has been added to track changes made in the FDIS.
This include one entry, the change from "fri" to "fry" that reflects the
ISO 639-2 mapping.

We in LTRU now have all the information related to ISO 639-3 language
names that we need, and we need to make a decision about which names
should appear in the RFC 4645bis Registry.  Should we use:

1a.  only the reference names shown in the main file?
1b.  the reference and alternative names, but only in non-inverted form
(when both exist)?
1c.  the reference and alternative names, but only in inverted form
(when both exist)?
1d.  the reference and alternative names, in both inverted and
non-inverted form?

My preference is for option 1d, including all the names.

We also need to decide whether to apply the decision in question 1 above
to:

2a.  all primary and extended language subtags in the Registry, possibly
adding more names to existing subtags, or
2b.  only the new subtags added with ISO 639-3.

My preference is for option 2a, retrofitting new names onto existing
subtags where ISO 639-3 lists them.

Let's discuss our options here, make a decision, and incorporate it into
the next draft of RFC 4646bis so I can reflect it in a new draft of RFC
4645bis.

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


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

------=_Part_62114_24890210.1164040364931-- --===============0342597526== 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 --===============0342597526==-- From ltru-bounces@ietf.org Mon Nov 20 12:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCii-0005rZ-0L; Mon, 20 Nov 2006 12:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCih-0005rU-LK for ltru@ietf.org; Mon, 20 Nov 2006 12:14:11 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCif-000898-CG for ltru@ietf.org; Mon, 20 Nov 2006 12:14:11 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GmCic-0002y8-Fq; Mon, 20 Nov 2006 12:14:06 -0500 Date: Mon, 20 Nov 2006 12:14:06 -0500 To: Mark Davis Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised Message-ID: <20061120171406.GC19903@ccil.org> References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > 1. Three Letter Code: it would indeed be handy to have the 3 letter > code around, for those cases where our canonical subtag is 2 letter. > While that is somewhat peripheral to our main function, it would > be useful to have this for both the language subtag and the region > subtag to help in identification, perhaps as "Type-Equivalent"? I would be opposed to this: it might easily give the impression that the use of these forms is licit. ISO 3166 and ISO 639-3 already provide such mappings. > 2. Inverted Names: [... and] 3. Type: A(ncient), C(onstructed), > E(xtinct), H(istorical), L(iving), S(pecial). I'm fairly neutral about these. > 1. Scope: we don't need to add this, since it can be derived: > something is a macro language iff there is an extlang that points > to it. That's true now, but won't always be true. If languages 'xxx' and 'yyy' are encompassed in a newly created macrolanguage 'zzz', then we will not start using 'zzz-xxx' and 'zzz-yyy', at least according to current plans. That said, I'm not sure how much having this information machine-processable adds. In cases where the names are confusing, 639-3 is adding "(macrolanguage)" anyhow. > 2. Reference Name: If we have the convention that the first > Description is the reference name, I am very much opposed to any convention that assigns special semantics to the first (or any other) instance of a field. If you want distinct semantics, use a distinct field name. -- I marvel at the creature: so secret and John Cowan so sly as he is, to come sporting in the pool cowan@ccil.org before our very window. Does he think that http://www.ccil.org/~cowan Men sleep without watch all night? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 13:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmDcY-0000mL-75; Mon, 20 Nov 2006 13:11:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmDcW-0000kv-W8 for ltru@lists.ietf.org; Mon, 20 Nov 2006 13:11:53 -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 1GmDcT-0005lO-LR for ltru@lists.ietf.org; Mon, 20 Nov 2006 13:11:52 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GmDbz-0008PC-Fp for ltru@lists.ietf.org; Mon, 20 Nov 2006 19:11:19 +0100 Received: from d254017.dialin.hansenet.de ([80.171.254.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Nov 2006 19:11:19 +0100 Received: from nobody by d254017.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Nov 2006 19:11:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 20 Nov 2006 19:10:02 +0100 Organization: Lines: 37 Message-ID: <4561EF7A.4AC1@xyzzy.claranet.de> References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> <20061120171406.GC19903@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254017.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] Re: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Mark Davis scripsit: >> 1. Three Letter Code: it would indeed be handy to have the 3 letter >> code around, for those cases where our canonical subtag is 2 letter. >> While that is somewhat peripheral to our main function, it would >> be useful to have this for both the language subtag and the region >> subtag to help in identification, perhaps as "Type-Equivalent"? > I would be opposed to this: it might easily give the impression that > the use of these forms is licit. ISO 3166 and ISO 639-3 already > provide such mappings. +1 My intuitive reaction was "maybe as Comment: Do not use 'abc'". >> 2. Inverted Names: [... and] 3. Type: A(ncient), C(onstructed), >> E(xtinct), H(istorical), L(iving), S(pecial). > I'm fairly neutral about these. I like the "inverted names". If the types are listed let's at least get rid of "living", declaring this as default. >> 2. Reference Name: If we have the convention that the first >> Description is the reference name, > I am very much opposed to any convention that assigns special > semantics to the first (or any other) instance of a field. If > you want distinct semantics, use a distinct field name. IMO Doug can list the descriptions in "source order", and it will automagically do what Mark wants. Inventing more field names isn't attractive, maybe the type deserves it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 13:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmE6P-00062r-My; Mon, 20 Nov 2006 13:42:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmE6O-00062l-B0 for ltru@lists.ietf.org; Mon, 20 Nov 2006 13:42:44 -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 1GmE6N-0000bj-1L for ltru@lists.ietf.org; Mon, 20 Nov 2006 13:42:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GmE6C-0000Fd-Ga for ltru@lists.ietf.org; Mon, 20 Nov 2006 19:42:35 +0100 Received: from d254017.dialin.hansenet.de ([80.171.254.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Nov 2006 19:42:32 +0100 Received: from nobody by d254017.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Nov 2006 19:42:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 20 Nov 2006 19:40:32 +0100 Organization: Lines: 27 Message-ID: <4561F6A0.29B5@xyzzy.claranet.de> References: <456062A4.7B63@xyzzy.claranet.de> <696E44EA4E1646AAA9B9ED85C9996887.MAI@home> <4560ABE6.5685@xyzzy.claranet.de> <20061120022952.GB24285@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254017.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> apparently that algorithm determines all 639-6 code elements already >> covered by other means (script, region, variant),> and only the rest >> of 639-6 (not already covered) is used to form tags. > Exactly, with the addendum that a 639-6 tag that covers multiple > languages would be used directly as an unqualified 4-alpha tag. Interesting, stuff for a 4646ter when 639-6 is published. > Saying that 'nap' has a Suppress-Script of 'Latn' means that > we've decided as a matter of public policy that the distinctions > between Neapolitan unspecified, Neapolitan spoken, and Neapolitan > written in Latin are insignificant. Reintroducing a way of > making those distinctions through the back door is a Bad Thing. Why's that bad ? In another article you or Randy pointed out that the worst thing about e.g. fy-Latn-DE is the _position_ of Latn between fy and DE confusing old applications looking for fy-DE. Variants or extensions are noted after the region, unlike script subtags. Some nap-FR-6napl could still match nap-FR (constructed example, it's not about Corsica), unlike nap-Latn-FR. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 14:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFI9-0003hs-I1; Mon, 20 Nov 2006 14:58:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFI8-0003hR-Ae for ltru@ietf.org; Mon, 20 Nov 2006 14:58:56 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFI7-0002X2-0M for ltru@ietf.org; Mon, 20 Nov 2006 14:58:56 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kY7juooZIv1MUPm/RmaetYcgsAa1HzDvUq7CjIDxw4dHtD0iT1U2gpL7uQxitsze; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.53] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GmFI6-0002jo-A2 for ltru@ietf.org; Mon, 20 Nov 2006 14:58:54 -0500 Message-ID: <004b01c70cde$6e9b6820$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <200608041841.k74IfIt8005737@mta6.iomartmail.com> <3747AAE5-2F96-43E7-95B9-29E255F42A63@egt.ie> Subject: Re: [Ltru] Charter update proposal (updated) Date: Mon, 20 Nov 2006 11:59:47 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6c7199f944ec1c1d3fd3caa3cf56d859c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.53 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Marion Gunn" > To: "LTRU Working Group" > Sent: Monday, November 20, 2006 3:03 AM > Subject: Re: [Ltru] Charter update proposal (updated) > > Maybe I missed something (traffic being so heavy on this list), but The approval of the updated charter in early September, perhaps? > I'd still be inclined to put a full stop after "languages" below > (losing the final 3 words). Reason: with languages disappearing from > use at such an alarming rate, leaving in those 3 words could cause > problems for marginal linguistic groups sans research facilities. ... Since http://www.ietf.org/html.charters/ltru-charter.html does not have the text to which you objected, I think this thread can safely come to an end. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 15:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFMg-000692-EF; Mon, 20 Nov 2006 15:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFMf-00068r-F6 for ltru@ietf.org; Mon, 20 Nov 2006 15:03:37 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFMe-000306-6u for ltru@ietf.org; Mon, 20 Nov 2006 15:03:37 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ocOfcupQ88ThJDxLKFibBkX9bzHht6Xxtj3tKvmQ6H+86eQHd1JyXA2xYGD3+6g7; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.53] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GmFMb-0005id-Cn for ltru@ietf.org; Mon, 20 Nov 2006 15:03:33 -0500 Message-ID: <004e01c70cdf$1536c620$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised Date: Mon, 20 Nov 2006 12:04: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6bcecd2f63df8b8924ca89f08f36c102b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.53 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, November 20, 2006 12:17 AM > Subject: [Ltru] ISO/FDIS 639-3 tables revised ... > We in LTRU now have all the information related to ISO 639-3 language > names that we need, and we need to make a decision about which names > should appear in the RFC 4645bis Registry. Should we use: > > 1a. only the reference names shown in the main file? > 1b. the reference and alternative names, but only in non-inverted form > (when both exist)? > 1c. the reference and alternative names, but only in inverted form > (when both exist)? > 1d. the reference and alternative names, in both inverted and > non-inverted form? > > My preference is for option 1d, including all the names. I prefer option 1d, too. > We also need to decide whether to apply the decision in question 1 above > to: > > 2a. all primary and extended language subtags in the Registry, possibly > adding more names to existing subtags, or > 2b. only the new subtags added with ISO 639-3. > > My preference is for option 2a, retrofitting new names onto existing > subtags where ISO 639-3 lists them. ... Although 2b might be less work, I don't object to 2a. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 15:16:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFYW-0003jC-DY; Mon, 20 Nov 2006 15:15:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFYV-0003ig-2o for ltru@ietf.org; Mon, 20 Nov 2006 15:15:51 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFYT-0004OC-6l for ltru@ietf.org; Mon, 20 Nov 2006 15:15:51 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oKwD6IqI6S+ivrUBIZqDZP9IkHTYC0TjgqZO41+lTqEqoWsgMC7LRoGP6q3jJjQF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.53] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GmFYR-0001U8-5f for ltru@ietf.org; Mon, 20 Nov 2006 15:15:47 -0500 Message-ID: <006401c70ce0$ca7632e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised Date: Mon, 20 Nov 2006 12:16:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee66b8a0440951bf7ba57cffc42be009f8d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.53 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Monday, November 20, 2006 8:32 AM > Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised ... > Fields to add: > > 1. Three Letter Code: it would indeed be handy to have the 3 letter > code around, for those cases where our canonical subtag is 2 letter. While > that is somewhat peripheral to our main function, it would be useful to have > this for both the language subtag and the region subtag to help in > identification, perhaps as "Type-Equivalent"? > 2. Inverted Names: I suggest we add an additional field for these, > allowing more than one. Maybe "Inverted-Description"? We could change any of > the current descriptions that are inverted to Inverted-Description, and add > add the 639-3 ones (1403 of them). > 3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), > S(pecial). This would be very useful information for identification, and I > suggest we add it as a Language-Type field As a co-chair, one of the things I'm supposed to watch out for is feature-creep. Consequently, before going any further in discussing these three proposed fields, I'd like to see a clear statement of why these are necessary to meeting the requirements established in the ltru WG charter. If they're not necessary, then the cost/benefit ratio needs to be *extremely* persuasive, and the benefits still need to be in terms of supporting language tagging. > Fields that our current structure can accommodate: > > 1. Scope: we don't need to add this, since it can be derived: > something is a macro language iff there is an extlang that points to it. > 2. Reference Name: If we have the convention that the first > Description is the reference name, then we could incorporate all of this > information without changing our structure. Note: 636-3 only has 85 cases of > multiple names. As a technical contributor, I think that giving semantics to field order would be unwise. If we need special semantics for this (I'm not convinced that we do) then we should introduce an additional field for the other names. > 3. Other Names: we can add any alternate names as additional > descriptions. This seems adequate. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 20 16:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmHB0-0002fx-6j; Mon, 20 Nov 2006 16:59:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmHAy-0002fq-P4 for ltru@ietf.org; Mon, 20 Nov 2006 16:59:40 -0500 Received: from nz-out-0102.google.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmHAw-0001n3-9W for ltru@ietf.org; Mon, 20 Nov 2006 16:59:40 -0500 Received: by nz-out-0102.google.com with SMTP id k1so1014850nzf for ; Mon, 20 Nov 2006 13:59:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Qv2KJupJ7sapU/uackNTEG/EJgb7OPTHdySp7ybxQV8ofcfhqHvP5YVNPf5DYXcl068+OQev82vV7uRL0FFq2cIV+4umQKVL+a1i3mjTQqJfaXOI5GE29s0ZaDeswdvdQYtX1mbMui/sk3XT3zHqKZZpsyaEn0BI4JNvmfiE8Qo= Received: by 10.65.176.7 with SMTP id d7mr8772395qbp.1164059958549; Mon, 20 Nov 2006 13:59:18 -0800 (PST) Received: by 10.65.252.11 with HTTP; Mon, 20 Nov 2006 13:59:18 -0800 (PST) Message-ID: <30b660a20611201359h688f11c2hbbe3577125845aca@mail.gmail.com> Date: Mon, 20 Nov 2006 13:59:18 -0800 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised In-Reply-To: <006401c70ce0$ca7632e0$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> <006401c70ce0$ca7632e0$6601a8c0@oemcomputer> X-Google-Sender-Auth: 81f611a8ba7bda5b X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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="===============1426472005==" Errors-To: ltru-bounces@ietf.org --===============1426472005== Content-Type: multipart/alternative; boundary="----=_Part_67299_7563813.1164059958484" ------=_Part_67299_7563813.1164059958484 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/20/06, Randy Presuhn wrote: > > Hi - > > > From: "Mark Davis" > > To: "Doug Ewell" > > Cc: "LTRU Working Group" > > Sent: Monday, November 20, 2006 8:32 AM > > Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised > ... > > Fields to add: > > > > 1. Three Letter Code: it would indeed be handy to have the 3 letter > > code around, for those cases where our canonical subtag is 2 letter. > While > > that is somewhat peripheral to our main function, it would be useful > to have > > this for both the language subtag and the region subtag to help in > > identification, perhaps as "Type-Equivalent"? > > 2. Inverted Names: I suggest we add an additional field for these, > > allowing more than one. Maybe "Inverted-Description"? We could change > any of > > the current descriptions that are inverted to Inverted-Description, > and add > > add the 639-3 ones (1403 of them). > > 3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), > > S(pecial). This would be very useful information for identification, > and I > > suggest we add it as a Language-Type field > > As a co-chair, one of the things I'm supposed to watch out for is > feature-creep. > > Consequently, before going any further in discussing these three proposed > fields, > I'd like to see a clear statement of why these are necessary to meeting > the > requirements established in the ltru WG charter. If they're not > necessary, then > the cost/benefit ratio needs to be *extremely* persuasive, and the > benefits still > need to be in terms of supporting language tagging. These are directly related to our charter, which is the addition of the 639-3 codes, since this is relevant data coming directly from 636-3. The scope of the change, adding 7000 new codes -- means that we need to consider any information that is useful for people to distinguish them. Now, as pointed out, we could encode this as specialized-format comments: Comment: Do not use three-letter code: abc Comment: 639-3 Type = Ancient While these are possible, this is kinda hacky, since we are overloading the comment mechanism. It just makes a bit gummier for anyone needing to machine parse the data, so I think it would be better to have explicit field types for these. > Fields that our current structure can accommodate: > > > > 1. Scope: we don't need to add this, since it can be derived: > > something is a macro language iff there is an extlang that points to > it. > > 2. Reference Name: If we have the convention that the first > > Description is the reference name, then we could incorporate all of > this > > information without changing our structure. Note: 636-3 only has 85 > cases of > > multiple names. > > As a technical contributor, I think that giving semantics to field order > would be unwise. If we need special semantics for this (I'm not convinced > that we do) then we should introduce an additional field for the other > names. I think that 639-3 has made a significant advance in distinguishing a reference name, and it would be a great advantage for us to be able to distinguish it in some way. By far the simplest way to do this is to use the first Description. > 3. Other Names: we can add any alternate names as additional > > descriptions. > > This seems adequate. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_67299_7563813.1164059958484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/20/06, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "Doug Ewell" <dewell@adelphia.net >
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Monday, November 20, 2006 8:32 AM
> Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised
...
> Fields to add:
>
>    1. Three Letter Code: it would indeed be handy to have the 3 letter
>    code around, for those cases where our canonical subtag is 2 letter. While
>    that is somewhat peripheral to our main function, it would be useful to have
>    this for both the language subtag and the region subtag to help in
>    identification, perhaps as "Type-Equivalent"?
>    2. Inverted Names: I suggest we add an additional field for these,
>    allowing more than one. Maybe "Inverted-Description"? We could change any of
>    the current descriptions that are inverted to Inverted-Description, and add
>    add the 639-3 ones (1403 of them).
>    3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving),
>    S(pecial). This would be very useful information for identification, and I
>    suggest we add it as a Language-Type field

As a co-chair, one of the things I'm supposed to watch out for is feature-creep.

Consequently, before going any further in discussing these three proposed fields,
I'd like to see a clear statement of why these are necessary to meeting the
requirements established in the ltru WG charter.  If they're not necessary, then
the cost/benefit ratio needs to be *extremely* persuasive, and the benefits still
need to be in terms of supporting language tagging.

These are directly related to our charter, which is the addition of the 639-3 codes, since this is relevant data coming directly from 636-3. The scope of the change, adding 7000 new codes -- means that we need to consider any information that is useful for people to distinguish them.

Now, as pointed out, we could encode this as specialized-format comments:

Comment: Do not use three-letter code: abc
Comment: 639-3 Type = Ancient

While these are possible, this is kinda hacky, since we are overloading the comment mechanism. It just makes a bit gummier for anyone needing to machine parse the data, so I think it would be better to have explicit field types for these.

> Fields that our current structure can accommodate:
>
>    1. Scope: we don't need to add this, since it can be derived:
>    something is a macro language iff there is an extlang that points to it.
>    2. Reference Name: If we have the convention that the first
>    Description is the reference name, then we could incorporate all of this
>    information without changing our structure. Note: 636-3 only has 85 cases of
>    multiple names.

As a technical contributor, I think that giving semantics to field order
would be unwise.  If we need special semantics for this (I'm not convinced
that we do) then we should introduce an additional field for the other
names.

I think that 639-3 has made a significant advance in distinguishing a reference name, and it would be a great advantage for us to be able to distinguish it in some way. By far the simplest way to do this is to use the first Description. 

>    3. Other Names: we can add any alternate names as additional
>    descriptions.

This seems adequate.

Randy


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

------=_Part_67299_7563813.1164059958484-- --===============1426472005== 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 --===============1426472005==-- From ltru-bounces@ietf.org Mon Nov 20 18:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIew-0006YA-Uk; Mon, 20 Nov 2006 18:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIev-0006Y4-CH for ltru@ietf.org; Mon, 20 Nov 2006 18:34:41 -0500 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound2-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmIes-0006jq-9g for ltru@ietf.org; Mon, 20 Nov 2006 18:34:41 -0500 Received: from outbound2-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-red-R.bigfish.com (Postfix) with ESMTP id D253F185CA8B; Mon, 20 Nov 2006 23:34:37 +0000 (UTC) Received: from mail47-red-R.bigfish.com (unknown [172.18.12.3]) by outbound2-red.bigfish.com (Postfix) with ESMTP id C752818590C4; Mon, 20 Nov 2006 23:34:37 +0000 (UTC) Received: from mail47-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail47-red-R.bigfish.com (Postfix) with ESMTP id 89DA290EEBF; Mon, 20 Nov 2006 23:34:37 +0000 (UTC) X-BigFish: VP Received: by mail47-red (MessageSwitch) id 1164065677471116_18808; Mon, 20 Nov 2006 23:34:37 +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 mail47-red.bigfish.com (Postfix) with ESMTP id 6796190DAE5; Mon, 20 Nov 2006 23:34:37 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006112015380354-675541 ; Mon, 20 Nov 2006 15:38:03 -0800 In-Reply-To: <30b660a20611201359h688f11c2hbbe3577125845aca@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Mon, 20 Nov 2006 15:33:15 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/20/2006 15:33:14, Serialize complete at 11/20/2006 15:33:14, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/20/2006 03:38:03 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/20/2006 03:38:06 PM, Serialize complete at 11/20/2006 03:38:06 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d 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="===============0587324241==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0587324241== Content-Type: multipart/alternative; boundary="=_alternative 008181E88825722C_=" This is a multipart message in MIME format. --=_alternative 008181E88825722C_= Content-Type: text/plain; charset="US-ASCII" I find the inverted names very useful in addition to the reference names and alternate names (synonyms). When inverted names are used in classification interfaces, it helps promote data quality -- the user sees all available variants together before making a choice. I don't think LTRU should be in the business of deciding exactly how a UI should be implemented as was previously being discussed, but the inverted names are common and if already found in 639-3, I would certainly include them. However, they are most useful when specifically identified as inverted names. It seems the label "description" is less than descriptive given the expanding requirements (it wouldn't meet ISO 11179 element-naming best practices). I'd throw out that terminology altogether in favor of something like: referencelangname alternatelangname invertedlangname So I agree with those who feel that different semantics require different fields and don't think that ordering should add to the semantics of a field. You might want more specific terminology for "language type" as well. If you look beyond RFC 4646, "language type" is also ambiguous. I might have "language usage type" = subtitles, dubbed, EAD, closed captions ... as well as "language mode type" = spoken, written, signed, embossed; etc. Will future versions of RFC 4646 have similar expanded needs? I'm failing to come up with a better name, however, as the language types listed seem a little bit like apples and oranges. Most of the "language type" categories below deal with the current demographics of the language, but then "constructed" and "special" don't quite fit that definition. Hmm... Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Mark Davis" wrote on 11/20/2006 01:59:18 PM: > > On 11/20/06, Randy Presuhn wrote: > Hi - > > > From: "Mark Davis" > > To: "Doug Ewell" > > Cc: "LTRU Working Group" > > Sent: Monday, November 20, 2006 8:32 AM > > Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised > ... > > Fields to add: > > > > 1. Three Letter Code: it would indeed be handy to have the 3 letter > > code around, for those cases where our canonical subtag is 2 > letter. While > > that is somewhat peripheral to our main function, it would be > useful to have > > this for both the language subtag and the region subtag to help in > > identification, perhaps as "Type-Equivalent"? > > 2. Inverted Names: I suggest we add an additional field for these, > > allowing more than one. Maybe "Inverted-Description"? We could > change any of > > the current descriptions that are inverted to Inverted- > Description, and add > > add the 639-3 ones (1403 of them). > > 3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), > > S(pecial). This would be very useful information for > identification, and I > > suggest we add it as a Language-Type field > > As a co-chair, one of the things I'm supposed to watch out for is > feature-creep. > > Consequently, before going any further in discussing these three > proposed fields, > I'd like to see a clear statement of why these are necessary to meeting the > requirements established in the ltru WG charter. If they're not > necessary, then > the cost/benefit ratio needs to be *extremely* persuasive, and the > benefits still > need to be in terms of supporting language tagging. > > These are directly related to our charter, which is the addition of > the 639-3 codes, since this is relevant data coming directly from > 636-3. The scope of the change, adding 7000 new codes -- means that > we need to consider any information that is useful for people to > distinguish them. > > Now, as pointed out, we could encode this as specialized-format comments: > > Comment: Do not use three-letter code: abc > Comment: 639-3 Type = Ancient > > While these are possible, this is kinda hacky, since we are > overloading the comment mechanism. It just makes a bit gummier for > anyone needing to machine parse the data, so I think it would be > better to have explicit field types for these. > > > Fields that our current structure can accommodate: > > > > 1. Scope: we don't need to add this, since it can be derived: > > something is a macro language iff there is an extlang that points to it. > > 2. Reference Name: If we have the convention that the first > > Description is the reference name, then we could incorporate all of this > > information without changing our structure. Note: 636-3 only > has 85 cases of > > multiple names. > > As a technical contributor, I think that giving semantics to field order > would be unwise. If we need special semantics for this (I'm not convinced > that we do) then we should introduce an additional field for the other > names. > > I think that 639-3 has made a significant advance in distinguishing > a reference name, and it would be a great advantage for us to be > able to distinguish it in some way. By far the simplest way to do > this is to use the first Description. > > > 3. Other Names: we can add any alternate names as additional > > descriptions. > > This seems adequate. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 008181E88825722C_= Content-Type: text/html; charset="US-ASCII"
I find the inverted names very useful in addition to the reference names and alternate names (synonyms). When inverted names are used in classification interfaces, it helps promote data quality -- the user sees all available variants together before making a choice. I don't think LTRU should be in the business of deciding exactly how a UI should be implemented as was previously being discussed, but the inverted names are common and if already found in 639-3, I would certainly include them. However, they are most useful when specifically identified as inverted names.

It seems the label "description" is less than descriptive given the expanding requirements (it wouldn't meet ISO 11179 element-naming best practices).  I'd throw out that terminology altogether in favor of something like:

referencelangname
alternatelangname
invertedlangname

So I agree with those who feel that different semantics require different fields and don't think that ordering should add to the semantics of a field.

You might want more specific terminology for "language type" as well. If you look beyond RFC 4646, "language type" is also ambiguous. I might have "language usage type" = subtitles, dubbed, EAD, closed captions ... as well as "language mode type" = spoken, written, signed, embossed; etc.  Will future versions of RFC 4646 have similar expanded needs?

I'm failing to come up with a better name, however, as the language types listed seem a little bit like apples and oranges. Most of the "language type" categories below deal with the current demographics of the language, but then "constructed" and "special" don't quite fit that definition.  Hmm...

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

"Mark Davis" <mark.davis@icu-project.org> wrote on 11/20/2006 01:59:18 PM:

>

> On 11/20/06, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> Hi -
>
> > From: "Mark Davis" <mark.davis@icu-project.org>
> > To: "Doug Ewell" <dewell@adelphia.net >
> > Cc: "LTRU Working Group" <ltru@ietf.org>
> > Sent: Monday, November 20, 2006 8:32 AM
> > Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised
> ...
> > Fields to add:
> >
> >    1. Three Letter Code: it would indeed be handy to have the 3 letter
> >    code around, for those cases where our canonical subtag is 2
> letter. While
> >    that is somewhat peripheral to our main function, it would be
> useful to have
> >    this for both the language subtag and the region subtag to help in
> >    identification, perhaps as "Type-Equivalent"?
> >    2. Inverted Names: I suggest we add an additional field for these,
> >    allowing more than one. Maybe "Inverted-Description"? We could
> change any of
> >    the current descriptions that are inverted to Inverted-
> Description, and add
> >    add the 639-3 ones (1403 of them).
> >    3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving),
> >    S(pecial). This would be very useful information for
> identification, and I
> >    suggest we add it as a Language-Type field
>
> As a co-chair, one of the things I'm supposed to watch out for is
> feature-creep.
>
> Consequently, before going any further in discussing these three
> proposed fields,
> I'd like to see a clear statement of why these are necessary to meeting the
> requirements established in the ltru WG charter.  If they're not
> necessary, then
> the cost/benefit ratio needs to be *extremely* persuasive, and the
> benefits still
> need to be in terms of supporting language tagging.
>
> These are directly related to our charter, which is the addition of
> the 639-3 codes, since this is relevant data coming directly from
> 636-3. The scope of the change, adding 7000 new codes -- means that
> we need to consider any information that is useful for people to
> distinguish them.
>
> Now, as pointed out, we could encode this as specialized-format comments:
>
> Comment: Do not use three-letter code: abc
> Comment: 639-3 Type = Ancient
>
> While these are possible, this is kinda hacky, since we are
> overloading the comment mechanism. It just makes a bit gummier for
> anyone needing to machine parse the data, so I think it would be
> better to have explicit field types for these.
>
> > Fields that our current structure can accommodate:
> >
> >    1. Scope: we don't need to add this, since it can be derived:
> >    something is a macro language iff there is an extlang that points to it.
> >    2. Reference Name: If we have the convention that the first
> >    Description is the reference name, then we could incorporate all of this
> >    information without changing our structure. Note: 636-3 only
> has 85 cases of
> >    multiple names.
>
> As a technical contributor, I think that giving semantics to field order
> would be unwise.  If we need special semantics for this (I'm not convinced
> that we do) then we should introduce an additional field for the other
> names.
>
> I think that 639-3 has made a significant advance in distinguishing
> a reference name, and it would be a great advantage for us to be
> able to distinguish it in some way. By far the simplest way to do
> this is to use the first Description.  
>
> >    3. Other Names: we can add any alternate names as additional
> >    descriptions.
>
> This seems adequate.
>
> Randy
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
 --=_alternative 008181E88825722C_=-- --===============0587324241== 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 --===============0587324241==-- From ltru-bounces@ietf.org Tue Nov 21 02:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmPqa-0003nr-Qm; Tue, 21 Nov 2006 02:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmPqZ-0003nl-Qp for ltru@ietf.org; Tue, 21 Nov 2006 02:15:11 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmPqV-0001W4-VZ for ltru@ietf.org; Tue, 21 Nov 2006 02:15:11 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kAL7F6kL025078 for ; Tue, 21 Nov 2006 16:15:06 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 465d_038909de_7930_11db_8cdd_0014221fa3c9; Tue, 21 Nov 2006 16:15:06 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58609) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 21 Nov 2006 16:14:29 +0900 Message-Id: <6.0.0.20.2.20061121132959.09b33c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 21 Nov 2006 13:33:07 +0900 To: John Cowan , Mark Davis From: Martin Duerst Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised In-Reply-To: <20061120171406.GC19903@ccil.org> References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> <20061120171406.GC19903@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 [co-chair hat off] At 02:14 06/11/21, John Cowan wrote: >Mark Davis scripsit: > >> 1. Three Letter Code: it would indeed be handy to have the 3 letter >> code around, for those cases where our canonical subtag is 2 letter. >> While that is somewhat peripheral to our main function, it would >> be useful to have this for both the language subtag and the region >> subtag to help in identification, perhaps as "Type-Equivalent"? > >I would be opposed to this: it might easily give the impression that >the use of these forms is licit. ISO 3166 and ISO 639-3 already >provide such mappings. I agree with John here. Mark says that this can be put into a comment, and that it's helpful for identifying a language. As I understand, the three-letter codes would be added to two-letter code entries. I don't think there is too much of a problem identifying two-letter code entries anyway, so I don't think this is necessary. >> 2. Reference Name: If we have the convention that the first >> Description is the reference name, > >I am very much opposed to any convention that assigns special semantics >to the first (or any other) instance of a field. If you want >distinct semantics, use a distinct field name. I agree with John here, too. 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 Nov 21 04:44:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSAl-000602-G9; Tue, 21 Nov 2006 04:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSAj-0005zx-VT for ltru@ietf.org; Tue, 21 Nov 2006 04:44:10 -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 1GmSAg-0001E8-Vv for ltru@ietf.org; Tue, 21 Nov 2006 04:44:09 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005836635.msg for ; Tue, 21 Nov 2006 09:47:02 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Tue, 21 Nov 2006 09:44:15 +0000 From: "Debbie Garside" To: "'Mark Davis'" , Subject: RE: [Ltru] ISO/FDIS 639-3 tables revised Date: Tue, 21 Nov 2006 09:43:36 -0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccM/M1c7jvugIB2TrqdLydNS4rkPQAUxD3Q Message-ID: <4E8BBA6011E84F659EFC04659B86F1BF.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Tue, 21 Nov 2006 09:47:02 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 21 Nov 2006 09:47:04 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0733045845==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0733045845== Content-Type: multipart/alternative; boundary="----=_NextPart_000_037B_01C70D51.8457FF20" This is a multi-part message in MIME format. ------=_NextPart_000_037B_01C70D51.8457FF20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I like your thoughts, Karen. I think there should be a discussion wrt splitting "Description" into a number of more descriptive fields. I also think it would be a good idea if, in doing so, this WG considered at least the basic requirements for conformity to ISO 11179 that the Registry structure could reflect very easily without necessarily adopting ISO 11179 at this point in time. Best Regards Debbie _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 20 November 2006 23:33 To: Mark Davis Cc: LTRU Working Group Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised I find the inverted names very useful in addition to the reference names and alternate names (synonyms). When inverted names are used in classification interfaces, it helps promote data quality -- the user sees all available variants together before making a choice. I don't think LTRU should be in the business of deciding exactly how a UI should be implemented as was previously being discussed, but the inverted names are common and if already found in 639-3, I would certainly include them. However, they are most useful when specifically identified as inverted names. It seems the label "description" is less than descriptive given the expanding requirements (it wouldn't meet ISO 11179 element-naming best practices). I'd throw out that terminology altogether in favor of something like: referencelangname alternatelangname invertedlangname So I agree with those who feel that different semantics require different fields and don't think that ordering should add to the semantics of a field. You might want more specific terminology for "language type" as well. If you look beyond RFC 4646, "language type" is also ambiguous. I might have "language usage type" = subtitles, dubbed, EAD, closed captions ... as well as "language mode type" = spoken, written, signed, embossed; etc. Will future versions of RFC 4646 have similar expanded needs? I'm failing to come up with a better name, however, as the language types listed seem a little bit like apples and oranges. Most of the "language type" categories below deal with the current demographics of the language, but then "constructed" and "special" don't quite fit that definition. Hmm... Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Mark Davis" wrote on 11/20/2006 01:59:18 PM: > > On 11/20/06, Randy Presuhn wrote: > Hi - > > > From: "Mark Davis" > > To: "Doug Ewell" > > Cc: "LTRU Working Group" > > Sent: Monday, November 20, 2006 8:32 AM > > Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised > ... > > Fields to add: > > > > 1. Three Letter Code: it would indeed be handy to have the 3 letter > > code around, for those cases where our canonical subtag is 2 > letter. While > > that is somewhat peripheral to our main function, it would be > useful to have > > this for both the language subtag and the region subtag to help in > > identification, perhaps as "Type-Equivalent"? > > 2. Inverted Names: I suggest we add an additional field for these, > > allowing more than one. Maybe "Inverted-Description"? We could > change any of > > the current descriptions that are inverted to Inverted- > Description, and add > > add the 639-3 ones (1403 of them). > > 3. Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), > > S(pecial). This would be very useful information for > identification, and I > > suggest we add it as a Language-Type field > > As a co-chair, one of the things I'm supposed to watch out for is > feature-creep. > > Consequently, before going any further in discussing these three > proposed fields, > I'd like to see a clear statement of why these are necessary to meeting the > requirements established in the ltru WG charter. If they're not > necessary, then > the cost/benefit ratio needs to be *extremely* persuasive, and the > benefits still > need to be in terms of supporting language tagging. > > These are directly related to our charter, which is the addition of > the 639-3 codes, since this is relevant data coming directly from > 636-3. The scope of the change, adding 7000 new codes -- means that > we need to consider any information that is useful for people to > distinguish them. > > Now, as pointed out, we could encode this as specialized-format comments: > > Comment: Do not use three-letter code: abc > Comment: 639-3 Type = Ancient > > While these are possible, this is kinda hacky, since we are > overloading the comment mechanism. It just makes a bit gummier for > anyone needing to machine parse the data, so I think it would be > better to have explicit field types for these. > > > Fields that our current structure can accommodate: > > > > 1. Scope: we don't need to add this, since it can be derived: > > something is a macro language iff there is an extlang that points to it. > > 2. Reference Name: If we have the convention that the first > > Description is the reference name, then we could incorporate all of this > > information without changing our structure. Note: 636-3 only > has 85 cases of > > multiple names. > > As a technical contributor, I think that giving semantics to field order > would be unwise. If we need special semantics for this (I'm not convinced > that we do) then we should introduce an additional field for the other > names. > > I think that 639-3 has made a significant advance in distinguishing > a reference name, and it would be a great advantage for us to be > able to distinguish it in some way. By far the simplest way to do > this is to use the first Description. > > > 3. Other Names: we can add any alternate names as additional > > descriptions. > > This seems adequate. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_037B_01C70D51.8457FF20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I like=20 your thoughts, Karen.  I think there should be a discussion=20 wrt splitting "Description" into a number of more descriptive = fields. =20 I also think it would be a good idea if, in doing so, this WG=20 considered at least the basic requirements for conformity to ISO = 11179 =20 that the Registry structure could reflect very easily without = necessarily=20 adopting ISO 11179 at this point in time. 
 
Best=20 Regards
 
Debbie

From: Karen_Broome@spe.sony.com=20 [mailto:Karen_Broome@spe.sony.com]
Sent: 20 November 2006=20 23:33
To: Mark Davis
Cc: LTRU Working=20 Group
Subject: Re: [Ltru] ISO/FDIS 639-3 tables=20 revised


I find the inverted = names very=20 useful in addition to the reference names and alternate names = (synonyms). When=20 inverted names are used in classification interfaces, it helps promote = data=20 quality -- the user sees all available variants together before making = a=20 choice. I don't think LTRU should be in the business of deciding = exactly how a=20 UI should be implemented as was previously being discussed, but the = inverted=20 names are common and if already found in 639-3, I would certainly = include=20 them. However, they are most useful when specifically identified as = inverted=20 names.

It seems the = label=20 "description" is less than descriptive given the expanding = requirements (it=20 wouldn't meet ISO 11179 element-naming best practices).  I'd = throw out=20 that terminology altogether in favor of something like: =

referencelangname
alternatelangname
invertedlangname

So I agree=20 with those who feel that different semantics require different fields = and=20 don't think that ordering should add to the semantics of a = field.=20

You might want more specific = terminology=20 for "language type" as well. If you look beyond RFC 4646, "language = type" is=20 also ambiguous. I might have "language usage type" =3D subtitles, = dubbed, EAD,=20 closed captions ... as well as "language mode type" =3D spoken, = written, signed,=20 embossed; etc.  Will future versions of RFC 4646 have similar = expanded=20 needs?

I'm failing to = come up with=20 a better name, however, as the language types listed seem a little bit = like=20 apples and oranges. Most of the "language type" categories below deal = with the=20 current demographics of the language, but then "constructed" and = "special"=20 don't quite fit that definition.  Hmm...

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures=20 Entertainment
310.244.4384

"Mark = Davis"=20 <mark.davis@icu-project.org> wrote on 11/20/2006 01:59:18=20 PM:

>

> On = 11/20/06, Randy=20 Presuhn <randy_presuhn@mindspring.com> wrote: =
> Hi -
>
> > From: "Mark Davis"=20 <mark.davis@icu-project.org>
> > To: "Doug Ewell"=20 <dewell@adelphia.net >
> > Cc: "LTRU Working Group"=20 <ltru@ietf.org>
> > Sent: Monday, November 20, 2006 = 8:32=20 AM
> > Subject: Re: [Ltru] ISO/FDIS 639-3 tables = revised
> ...=20
> > Fields to add:
> >
> >    1. = Three=20 Letter Code: it would indeed be handy to have the 3 letter
> = >  =20  code around, for those cases where our canonical subtag is 2 =
>=20 letter. While
> >    that is somewhat peripheral to = our=20 main function, it would be
> useful to have
> > =  =20  this for both the language subtag and the region subtag to help=20 in
> >    identification, perhaps as=20 "Type-Equivalent"?
> >    2. Inverted Names: I = suggest we=20 add an additional field for these,
> >    allowing = more=20 than one. Maybe "Inverted-Description"? We could
> change any=20 of
> >    the current descriptions that are = inverted to=20 Inverted-
> Description, and add
> >    add = the 639-3=20 ones (1403 of them).
> >    3. Type: A(ncient),=20 C(onstructed), E(xtinct), H(istorical), L(iving),
> >  =20  S(pecial). This would be very useful information for
>=20 identification, and I
> >    suggest we add it as a = Language-Type field
>
> As a co-chair, one of the things = I'm=20 supposed to watch out for is
> feature-creep.
>
>=20 Consequently, before going any further in discussing these three =
>=20 proposed fields,
> I'd like to see a clear statement of why = these are=20 necessary to meeting the
> requirements established in the ltru = WG=20 charter.  If they're not
> necessary, then
> the=20 cost/benefit ratio needs to be *extremely* persuasive, and the =
>=20 benefits still
> need to be in terms of supporting language = tagging.=20
>
> These are directly = related to=20 our charter, which is the addition of
> the 639-3 codes, since = this is=20 relevant data coming directly from
> 636-3. The scope of the = change,=20 adding 7000 new codes -- means that
> we need to consider any=20 information that is useful for people to
> distinguish them. =
>=20
> Now, as pointed out, we could encode this as = specialized-format=20 comments:
>
> Comment: Do not use three-letter code: = abc
>=20 Comment: 639-3 Type =3D Ancient
>
> While these are = possible, this=20 is kinda hacky, since we are
> overloading the comment = mechanism. It=20 just makes a bit gummier for
> anyone needing to machine parse = the=20 data, so I think it would be
> better to have explicit field = types for=20 these.
>
> > Fields = that our=20 current structure can accommodate:
> >
> >   =  1.=20 Scope: we don't need to add this, since it can be derived:
> = >=20    something is a macro language iff there is an extlang = that points=20 to it.
> >    2. Reference Name: If we have the = convention=20 that the first
> >    Description is the reference = name,=20 then we could incorporate all of this
> >   =  information=20 without changing our structure. Note: 636-3 only
> has 85 cases = of
> >    multiple names.
>
> As a = technical=20 contributor, I think that giving semantics to field order
> = would be=20 unwise.  If we need special semantics for this (I'm not convinced =
> that we do) then we should introduce an additional field for = the=20 other
> names.
>
> = I think=20 that 639-3 has made a significant advance in distinguishing
> a = reference name, and it would be a great advantage for us to be =
> able=20 to distinguish it in some way. By far the simplest way to do
> = this is=20 to use the first Description.  
>=20
> >    3. Other Names: we can add any alternate = names as=20 additional
> >    descriptions.
>
> = This=20 seems adequate.
>
> Randy
>
>
>=20 _______________________________________________
> Ltru mailing=20 list
> Ltru@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ltru
> _______________________________________________
> = Ltru=20 mailing list
> Ltru@ietf.org
>=20 = https://www1.ietf.org/mailman/listinfo/ltru
<= /BODY> ------=_NextPart_000_037B_01C70D51.8457FF20-- --===============0733045845== 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 --===============0733045845==-- From ltru-bounces@ietf.org Tue Nov 21 05:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSss-0003vA-1c; Tue, 21 Nov 2006 05:29:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSsq-0003v1-A5 for ltru@ietf.org; Tue, 21 Nov 2006 05:29:44 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSsm-0005Jh-Cy for ltru@ietf.org; Tue, 21 Nov 2006 05:29:44 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kALATaCN014102 for ; Tue, 21 Nov 2006 19:29:36 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2bb7_2fa70988_794b_11db_8103_0014221f2a2d; Tue, 21 Nov 2006 19:29:35 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39442) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 21 Nov 2006 19:29:02 +0900 Message-Id: <6.0.0.20.2.20061121162130.09b4bec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 21 Nov 2006 16:27:38 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Just checking... In-Reply-To: <005301c70c6b$13102e50$6501a8c0@DGBP7M81> References: <005301c70c6b$13102e50$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:14 06/11/20, Doug Ewell wrote: >Martin Duerst wrote: > >> 2) One reason where an extension would be better is that the necessary >> data (flags and such) could easily go on a separate place (IANA >> or elsewhere), whereas extensions all have to go on the same page >> (unless we would decide to change that). > >I assume this was supposed to read: "whereas variants all have to go on the same page..." [chair hat off] Yes indeed. I agree with the following, except that the "maintaining authority" is not restricted to be non-IANA, non-IETF, and the body that defines an extension is not restricted to non-IETF-language, non-LTRU. As far as I understand, it would in theory be possible that a next version of the LTRU WG would take on the job of creating an extension for 639-6 (and/or anything else that the IETF would deem necessary), and that the necessary registry may or may not be hosted at IANA. I don't know at this moment whether this would be a good idea or not; I don't even want to start a discussion on such things before we have reasonably completed the current charter. I just want to make clear that this is also possible. Regards, Martin. >Martin already understands the following, but I include it for those who may still be fuzzy about extensions: > >A basic feature of extension subtags is that they are not defined by LTRU or ietf-languages, and are not listed in the Language Subtag Registry or any other resource hosted by IANA. They are defined by an external "maintaining authority" and listed in a separate, non-IANA, non-IETF registry. There is a Language Tag Extensions Registry maintained by IANA, but it lists only the singleton and other basic information associated with each extension. All of this is described plainly in Section 3.7. > >If ISO 639-6 were used as the basis for an extension RFC, then all of the complicated rules we have been discussing -- which code elements could be used in language tags and which could not, which one would allow additional subtags (like script) and which would forbid them, which combinations would be impossible, etc. -- would be specified in that RFC, and the registry of subtags defined therein would be maintained by a third party. Neither LTRU nor ietf-languages would have to make any of those decisions, or vet thousands of subtags. The responsibility could fall on Debbie's Geolang organization, assisted by whoever volunteers (or is drafted) to assist. > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# 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 Nov 21 06:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTvA-00030Q-PE; Tue, 21 Nov 2006 06:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTv9-00030J-AV for ltru@ietf.org; Tue, 21 Nov 2006 06:36:11 -0500 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmTv8-0002ww-2O for ltru@ietf.org; Tue, 21 Nov 2006 06:36:11 -0500 Received: (qmail 61800 messnum 11065705 invoked from network[194.125.174.109/ts09-109.dublin.indigo.ie]); 21 Nov 2006 11:36:03 -0000 Received: from ts09-109.dublin.indigo.ie (HELO ?194.125.174.109?) (194.125.174.109) by mail11.svc.cra.dublin.eircom.net (qp 61800) with SMTP; 21 Nov 2006 11:36:03 -0000 In-Reply-To: <200611210150.kAL1oWT14470@birdie.sybase.com> References: <200611210150.kAL1oWT14470@birdie.sybase.com> 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, 21 Nov 2006 11:39:35 +0000 To: Kenneth Whistler , LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 21 Nov 2006, at 01:50, scr=EDobh Kenneth Whistler: > ... in my opinion > the right way to handle this is to first *formally* extend the > scope of 15924... I hardly think that necessary, but if that's that what it takes, fine. > And IPA is not a variant script. It is not comparable to Latf and =20 > Latg. I believe that it is. We need both Latg and IPA, for example. > It is a circumscribed, technical use of Latn. "cat" is English. > "[cat]" is IPA. Tell me the script difference, except in function... You choose an example lacking non-Latin (Greek) letters. Why? 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 Nov 21 09:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWqi-0001H5-50; Tue, 21 Nov 2006 09:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWqg-0001Gt-Oi for ltru@ietf.org; Tue, 21 Nov 2006 09:43:46 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWqf-0001LQ-DM for ltru@ietf.org; Tue, 21 Nov 2006 09:43:46 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061121144338.BBAC23051.mta10.adelphia.net@DGBP7M81>; Tue, 21 Nov 2006 09:43:38 -0500 Message-ID: <003201c70d7b$6fcb6e50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007a01c70c7c$5d6a8b10$6501a8c0@DGBP7M81> <30b660a20611200832w257029bdy6e20fb4a8d53890c@mail.gmail.com> Subject: Re: [Ltru] ISO/FDIS 639-3 tables revised Date: Tue, 21 Nov 2006 06:43:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Fields to add: > > Three Letter Code: it would indeed be handy to have the 3 letter code > around, for those cases where our canonical subtag is 2 letter. While > that is somewhat peripheral to our main function, it would be useful > to have this for both the language subtag and the region subtag to > help in identification, perhaps as "Type-Equivalent"? I *strongly* disagree, for the reason John stated: it would send users a clear message that "fra" is an acceptable alternative for "fr" in RFC 4646-family language tags. This is much worse than simply being "not relevant" to language tagging. No, no, a thousand times no. > Inverted Names: I suggest we add an additional field for these, > allowing more than one. Maybe "Inverted-Description"? We could change > any of the current descriptions that are inverted to > Inverted-Description, and add add the 639-3 ones (1403 of them). Inverted names in language subtags are easy to identify already; they are the only ones that contain a comma. (ISO 639 and 3166 don't use the comma to separate alternative names, as ISO 15924 and some of our grandfathered tags do.) So I don't see a need to label them specially; we could just include them, or we could include *only* the inverted forms and it would be trivial for users to uninvert them (but I prefer the former). > Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), > S(pecial). This would be very useful information for identification, > and I suggest we add it as a Language-Type field I do support this, and supported it back when John proposed it in early October. Unlike some other ideas for new fields, this one directly assists users in determining the appropriateness of a subtag. I agree with Frank that "Living" should be the default, and should not be explicitly indicated. This field should also be able to hold the value "Collection" for those collection codes included in 639-2 but not 639-3. Draft-4646bis-01 recommends against using these (Section 4.1) but they cannot always be identified without this field. > Fields that our current structure can accommodate: > > Scope: we don't need to add this, since it can be derived: something > is a macro language iff there is an extlang that points to it. I agree. John is right that the concept of "ISO 639-3 macrolanguage" and "RFC 4646bis primary language subtag that has extended language subtags under it" may diverge in the future, but I'm not sure that's relevant for our purposes. > Reference Name: If we have the convention that the first Description > is the reference name, then we could incorporate all of this > information without changing our structure. Note: 636-3 only has 85 > cases of multiple names. I don't think we need to incorporate it. As long as one of the Descriptions matches an ISO 639-3 reference name, that is enough. I've already fought and lost this particular battle. Let's put it this way: Since the order of Description fields doesn't matter, I do plan to put them (in RFC 4645bis) in roughly the order in which they appear in ISO 639-3: reference name first, then other names, then inverted forms. But we cannot count on that being relevant, or on tag consumeres treating the first Description as special in any way. > Other Names: we can add any alternate names as additional > descriptions. Yes, including any names proposed by individuals that ISO 639 left off for whatever reason. The inclusion of the full list of names, inverted and non-inverted, in a downloadable ISO 639-3 text file is a major step forward. By including all of these names in the Registry, we can be assured of fulfilling the oft-stated requirement to match the Description field with the "official" ISO name. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 09:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWui-00021y-77; Tue, 21 Nov 2006 09:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWuh-00021t-Ci for ltru@ietf.org; Tue, 21 Nov 2006 09:47:55 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWuf-0001gp-2r for ltru@ietf.org; Tue, 21 Nov 2006 09:47:55 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061121144752.BMVH27259.mta9.adelphia.net@DGBP7M81>; Tue, 21 Nov 2006 09:47:52 -0500 Message-ID: <004001c70d7c$06f9f9e0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005301c70c6b$13102e50$6501a8c0@DGBP7M81> <6.0.0.20.2.20061121162130.09b4bec0@localhost> Subject: Re: [Ltru] Re: Just checking... Date: Tue, 21 Nov 2006 06:47:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Martin is absolutely correct. The proponent of an extension RFC and the maintaining authority for the extension are not *required* to be related to IETF or IANA, but they may be. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 09:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX1j-0004ZV-O8; Tue, 21 Nov 2006 09:55:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX1h-0004ZL-Ak for ltru@ietf.org; Tue, 21 Nov 2006 09:55:10 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmX1g-0002HP-01 for ltru@ietf.org; Tue, 21 Nov 2006 09:55:09 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061121145508.FCSM21407.mta13.adelphia.net@DGBP7M81> for ; Tue, 21 Nov 2006 09:55:08 -0500 Message-ID: <005201c70d7d$0a3cd360$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 21 Nov 2006 06:55:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Now, as pointed out, we could encode this as specialized-format > comments: > > Comment: Do not use three-letter code: abc > Comment: 639-3 Type = Ancient > > While these are possible, this is kinda hacky, since we are > overloading the comment mechanism. It just makes a bit gummier for > anyone needing to machine parse the data, so I think it would be > better to have explicit field types for these. I agree that these should not be comments. In particular, the three-letter ISO code elements equivalent to two-letter language subtags should not appear ANYWHERE in the Registry, or it will give the impression they are acceptable alternatives. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 10:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXFB-0006La-PB; Tue, 21 Nov 2006 10:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXFB-0006LU-IP for ltru@ietf.org; Tue, 21 Nov 2006 10:09:05 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXF9-00044U-9W for ltru@ietf.org; Tue, 21 Nov 2006 10:09:05 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061121150902.LDVD2497.mta11.adelphia.net@DGBP7M81>; Tue, 21 Nov 2006 10:09:02 -0500 Message-ID: <005601c70d7e$fc184d80$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 21 Nov 2006 07:09:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 also think it would be a good idea if, in doing so, this WG > considered at least the basic requirements for conformity to ISO 11179 > that the Registry structure could reflect very easily without > necessarily adopting ISO 11179 at this point in time. I've never been clear on what the basic requirements would be, since ISO 11179 is a long, six-part document that I've never been able to take the time to fully understand. I know people keep asking you to "prepare a short summary" of things, and doing the thinking for other people gets old after a while, but... Could you prepare a short summary of what it would take to make the Registry "conformant" to ISO 11179 (however that is defined)? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 10:42:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXln-0007l2-Cs; Tue, 21 Nov 2006 10:42:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXlm-0007jB-3A for ltru@ietf.org; Tue, 21 Nov 2006 10:42:46 -0500 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmXlj-0007y6-QD for ltru@ietf.org; Tue, 21 Nov 2006 10:42:46 -0500 Received: (qmail 39543 messnum 3624257 invoked from network[194.125.174.88/ts09-088.dublin.indigo.ie]); 21 Nov 2006 15:42:42 -0000 Received: from ts09-088.dublin.indigo.ie (HELO ?194.125.174.88?) (194.125.174.88) by mail16.svc.cra.dublin.eircom.net (qp 39543) with SMTP; 21 Nov 2006 15:42:42 -0000 In-Reply-To: <004b01c70cde$6e9b6820$6601a8c0@oemcomputer> References: <200608041841.k74IfIt8005737@mta6.iomartmail.com> <3747AAE5-2F96-43E7-95B9-29E255F42A63@egt.ie> <004b01c70cde$6e9b6820$6601a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Charter update proposal (updated) Date: Tue, 21 Nov 2006 15:46:14 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ltru@ietf.org, ietf On 20 Nov 2006, at 19:59, Randy Presuhn: > ... > Since http://www.ietf.org/html.charters/ltru-charter.html does > not have the text to which you objected, I think this thread can > safely come to an end. Good. That's real progress. Thanks. 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 Nov 21 10:43:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXmg-00017U-Dg; Tue, 21 Nov 2006 10:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXme-000164-Uu for ltru@ietf.org; Tue, 21 Nov 2006 10:43:40 -0500 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmXmd-000854-CT for ltru@ietf.org; Tue, 21 Nov 2006 10:43:40 -0500 Received: (qmail 44746 messnum 3621994 invoked from network[194.125.174.88/ts09-088.dublin.indigo.ie]); 21 Nov 2006 15:43:38 -0000 Received: from ts09-088.dublin.indigo.ie (HELO ?194.125.174.88?) (194.125.174.88) by mail16.svc.cra.dublin.eircom.net (qp 44746) with SMTP; 21 Nov 2006 15:43:38 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: <200611210150.kAL1oWT14470@birdie.sybase.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Tue, 21 Nov 2006 15:47:10 +0000 To: IETF Languages Discussion , Kenneth Whistler , LTRU Working Group , iso15924-jac@unicode.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 21 Nov 2006, at 01:50, scr=EDobh Kenneth Whistler: > ... > Yeah, yeah, cute, Mark. Note also that Michael and I, at least, > were trained in IPA (and other phonetic orthographies) and > made significant professional use of them. So it isn't as > if we are babes in the woods here presented with something > we've never heard of before, and are making off-the-cuff, uninformed > remarks about... Fine - suppose we all believe the above claim (which I, personally, =20 happen to do), then let's suppose we drop Ken and any compatriot of =20 his choice, who happen to be both equally _literate_ in IPA and =20 equally _illiterate_ in some endangered language (to make things even =20= easier, let's make it any indigenous language of the Americas in =20 which they both happen to be illiterate!) into an indigenous =20 community, their mission being to write down all possible of that =20 community's stories and traditional cures in a single week, with all =20 travel expenses paid? How would you like us to tag the results of your week's work, Ken? 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 Nov 21 10:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXtG-0005DL-F8; Tue, 21 Nov 2006 10:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXtF-0005DF-TM for ltru@ietf.org; Tue, 21 Nov 2006 10:50:29 -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 1GmXtE-0000la-Gw for ltru@ietf.org; Tue, 21 Nov 2006 10:50:29 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005844721.msg for ; Tue, 21 Nov 2006 15:53:29 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Tue, 21 Nov 2006 15:50:45 +0000 From: "Debbie Garside" To: , "'LTRU Working Group'" , Date: Tue, 21 Nov 2006 15:50:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <005601c70d7e$fc184d80$6501a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccNgZLok/mSP3apT6y2TbooisngfQAAm30w Message-ID: <3C398E83D8F84788A11CBDF01D840375.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Tue, 21 Nov 2006 15:53:29 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 21 Nov 2006 15:53:31 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Ltru] ISO 11179 Summary was RE: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > I know people keep asking you to "prepare a short summary" of > things, and doing the thinking for other people gets old > after a while, but... > Could you prepare a short summary of what it would take to > make the Registry "conformant" to ISO 11179 (however that is defined)? :-) Generally I am happy to do so but at this point in time I am snowed under with other work so it would most likely be after Christmas before I could get to it. I am not sure that I would be the right person to do this anyway. Karen is far more knowledgeable wrt ISO 11179 than I am. Karen, could you put a brief summary together? Sorry for passing the buck this time. I will happily contribute to any discussion. Best Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 21 November 2006 15:09 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: ISO/FDIS 639-3 tables revised > > Debbie Garside wrote: > > > I also think it would be a good idea if, in doing so, this WG > > considered at least the basic requirements for conformity > to ISO 11179 > > that the Registry structure could reflect very easily without > > necessarily adopting ISO 11179 at this point in time. > > I've never been clear on what the basic requirements would > be, since ISO > 11179 is a long, six-part document that I've never been able > to take the time to fully understand. > > I know people keep asking you to "prepare a short summary" of > things, and doing the thinking for other people gets old > after a while, but... > Could you prepare a short summary of what it would take to > make the Registry "conformant" to ISO 11179 (however that is defined)? > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 10:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY0s-0002uY-Hm; Tue, 21 Nov 2006 10:58:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmY0r-0002uS-QW for ltru@ietf.org; Tue, 21 Nov 2006 10:58:21 -0500 Received: from mail16.svc.cra.dublin.eircom.net ([159.134.118.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmY0q-0002A1-IU for ltru@ietf.org; Tue, 21 Nov 2006 10:58:21 -0500 Received: (qmail 25237 messnum 3624238 invoked from network[194.125.174.88/ts09-088.dublin.indigo.ie]); 21 Nov 2006 15:58:19 -0000 Received: from ts09-088.dublin.indigo.ie (HELO ?194.125.174.88?) (194.125.174.88) by mail16.svc.cra.dublin.eircom.net (qp 25237) with SMTP; 21 Nov 2006 15:58:19 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <3C398E83D8F84788A11CBDF01D840375.MAI@home> References: <3C398E83D8F84788A11CBDF01D840375.MAI@home> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8911BE3F-38D3-4D26-BD68-7BC8FABE248F@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] ISO 11179 Summary was RE: ISO/FDIS 639-3 tables revised Date: Tue, 21 Nov 2006 16:01:51 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 21 Nov 2006, at 15:50, scr=EDobh Debbie Garside: > ... > :-) Generally I am happy to do so but at this point in time I am =20 > snowed > under with other work... Relieved to hear someone else on LTRU is snowed under with earning =20 her keep!:-) > Sorry for passing the buck this time. I will happily contribute to =20= > any > discussion. No need for apol's, D. We all know you will. 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 Nov 21 13:12:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma6i-0006tD-Lt; Tue, 21 Nov 2006 13:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma6h-0006t3-G7 for ltru@ietf.org; Tue, 21 Nov 2006 13:12:31 -0500 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gma6g-0007VH-55 for ltru@ietf.org; Tue, 21 Nov 2006 13:12:31 -0500 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Tue, 21 Nov 2006 18:12:24 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J93000SBEKOW2@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Tue, 21 Nov 2006 18:12:24 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Tue, 21 Nov 2006 18:12:24 +0000 Date: Tue, 21 Nov 2006 18:11:04 +0000 From: Misha Wolf To: ltru@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: ISO 11179 conformance [was: something else] Thread-Index: AccNgZLok/mSP3apT6y2TbooisngfQAAm30wAATtkyA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Nov 2006 18:12:24.0621 (UTC) FILETIME=[9863B5D0:01C70D98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] ISO 11179 conformance [was: something else] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org While we're making the registry ISO 11179 conformant,=20 can we also make it conformant with the tenets of the=20 World's major religions? Maybe we should propose to Sacha Baron Cohen that ISO=20 11179 should star in his next movie ... Misha This email was sent to you by Reuters, the global news and information comp= any.=20 To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 13:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmapQ-0003nZ-Ge; Tue, 21 Nov 2006 13:58:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmapP-0003nR-Lx for ltru@ietf.org; Tue, 21 Nov 2006 13:58:43 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmapM-0008Aa-Dq for ltru@ietf.org; Tue, 21 Nov 2006 13:58:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GmapL-0004SO-Ie; Tue, 21 Nov 2006 13:58:39 -0500 Date: Tue, 21 Nov 2006 13:58:39 -0500 To: Marion Gunn Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Message-ID: <20061121185839.GB12648@ccil.org> References: <200611210150.kAL1oWT14470@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Marion Gunn scripsit: > Fine - suppose we all believe the above claim (which I, personally, > happen to do), then let's suppose we drop Ken and any compatriot of > his choice, who happen to be both equally _literate_ in IPA and equally > _illiterate_ in some endangered language (to make things even easier, > let's make it any indigenous language of the Americas in which they > both happen to be illiterate!) We generally use the term "illiterate" for someone who does not know the usual orthography for a language. Thus, one can be illiterate in English or Irish or Cherokee, but not Kickapoo -- there simply is no usual orthography. > into an indigenous community, their mission being to write down all > possible of that community's stories and traditional cures in a single > week, with all travel expenses paid? > > How would you like us to tag the results of your week's work, Ken? If it's Kickapoo, one can simply use the tag "kic", as there is nothing more to say. If the language has an orthography but Ken & Co. do not know it, perhaps Creek, then "mus-x-adhoc" would seem sufficient. A week is not really enough to do a proper phonemic analysis from scratch. Tag wisely. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 14:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbCZ-0000nt-Mh; Tue, 21 Nov 2006 14:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbCX-0000kz-5F for ltru@lists.ietf.org; Tue, 21 Nov 2006 14:22:37 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbCV-0003IT-Pm for ltru@lists.ietf.org; Tue, 21 Nov 2006 14:22:37 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kALJMEth000315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2006 11:22:14 -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=C7u2inForDH4HuoPnZyCN8ELAmlXs4Mc+UBdqQ80SxD948FrVbjfXWskt2Twamo1 Message-ID: <456351E5.5060102@yahoo-inc.com> Date: Tue, 21 Nov 2006 11:22:13 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 References: <455CBFCA.4872@xyzzy.claranet.de> <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> <456062A4.7B63@xyzzy.claranet.de> <20061120023556.GC24285@ccil.org> In-Reply-To: <20061120023556.GC24285@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 The more I think about this thread, the more I'm of the opinion that ISO 639-6 either defines an extension or defines a parallel standard. As near as I can tell, most of the codes in ISO 639-6 have a 1:1 relationship with some language tag. That is, they either map to currently defined language tags using one or more subtags (napl => nap-Latn) or they define a variant which is eligible for registration. I oppose including redundant subtags in the registry. It will confuse people to no good purpose. Language tags, for various historical and practical reasons, consist of subtags. ISO 639-6 codes might serve as a useful reference when registering variants (perhaps a restriction should exist requiring variant registrations collect a rejection slip form ISO 639-6 RA before independently being registered, a la language subtags??) and might even serve as the source for specific variants not currently registered in some 4646ter timeframe. That is, any ISO 639-6 codes that don't have an associated language tag would be registered using some format such as the below to identify the variation. Just my current thoughts on the matter. Addison John Cowan wrote: > Frank Ellermann scripsit: > >> Unsuppress is unlikely in that case, why would they start to use a new >> script in addition to Latn, justifying to explicitly distinguish Latn >> and this new script in language tags ? > > Politics. If Greece reconquered Neapolis (or bought it back from > Italy, more likely), nap-Grek might well become an important language. > >> The problem we have now is the missing Suppress-Script Latn, which could >> be introduced later. At the moment a tag nap-Latn is perfectly okay, >> and therefore nap-6-napl or nap-Latn-6-napl would be wrong / redundant. >> >> As soon as nap gets a Suppress-Script Latn the nap-Latn-6-napl is still >> wrong / redundant. But suddenly nap-6-napl would be allowed instead of >> the then suppressed nap-Latn. > > No, I disagree. Quite independent of Suppress-Script, 'napl' does not > contain any extra information above "nap" or "nap-Latn" as the case > may be. So it remains forbidden to use either "nap-6napl" or > "nap-Latn-6napl". See my previous post for the rationale. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 14:31:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbLb-0002RU-AT; Tue, 21 Nov 2006 14:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbLZ-0002RD-Ew for ltru@ietf.org; Tue, 21 Nov 2006 14:31:57 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbLY-0005u4-31 for ltru@ietf.org; Tue, 21 Nov 2006 14:31:57 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id kALJVldf000972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2006 11:31:47 -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=OKybjzyhRPEmja3l9Qlwyx8IkMhe3FUG26oAKi7jCQuGpQd+rG8LHvWcL3z3VY/t Message-ID: <45635423.2030902@yahoo-inc.com> Date: Tue, 21 Nov 2006 11:31:47 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Misha Wolf Subject: Re: [Ltru] ISO 11179 conformance and a new draft 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 By the way, I'm preparing a new draft of 4646bis for submission. I haven't changed anything in the text for several weeks. If there is some specific text that we've decided to incorporate that I missed (and I haven't seen anything), it would be useful to know about it. Addison Misha Wolf wrote: > While we're making the registry ISO 11179 conformant, > can we also make it conformant with the tenets of the > World's major religions? > > Maybe we should propose to Sacha Baron Cohen that ISO > 11179 should star in his next movie ... > > Misha > > > This email was sent to you by Reuters, the global news and information company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 15:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbpK-0005gl-Un; Tue, 21 Nov 2006 15:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbpJ-0005gb-BE for ltru@ietf.org; Tue, 21 Nov 2006 15:02:41 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbpE-00030r-DO for ltru@ietf.org; Tue, 21 Nov 2006 15:02:41 -0500 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 27F5C1D50CF8; Tue, 21 Nov 2006 20:01:11 +0000 (UTC) Received: from mail3-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 1F3481D51115; Tue, 21 Nov 2006 20:01:11 +0000 (UTC) Received: from mail3-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail3-ash-R.bigfish.com (Postfix) with ESMTP id 03E34862061; Tue, 21 Nov 2006 20:01:11 +0000 (UTC) X-BigFish: VP Received: by mail3-ash (MessageSwitch) id 1164139104221920_1131; Tue, 21 Nov 2006 19:58:24 +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 mail3-ash.bigfish.com (Postfix) with ESMTP id EFE60862E4E; Tue, 21 Nov 2006 19:58:23 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006112111480310-716462 ; Tue, 21 Nov 2006 11:48:03 -0800 In-Reply-To: <45635423.2030902@yahoo-inc.com> To: Addison Phillips Subject: Re: [Ltru] ISO 11179 conformance and a new draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 21 Nov 2006 11:43:12 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/21/2006 11:43:13, Serialize complete at 11/21/2006 11:43:13, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/21/2006 11:48:03 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/21/2006 12:01:53 PM, Serialize complete at 11/21/2006 12:01:53 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Misha Wolf , 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="===============1115149785==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1115149785== Content-Type: multipart/alternative; boundary="=_alternative 006C72708825722D_=" This is a multipart message in MIME format. --=_alternative 006C72708825722D_= Content-Type: text/plain; charset="US-ASCII" Did we ever come to any final decisions on the "great script debate" thread with respect to indicating that scripts aren't relevant for audio language tagging? Regards, Karen Broome Addison Phillips 11/21/2006 11:31 AM To Misha Wolf cc ltru@ietf.org Subject Re: [Ltru] ISO 11179 conformance and a new draft +1 By the way, I'm preparing a new draft of 4646bis for submission. I haven't changed anything in the text for several weeks. If there is some specific text that we've decided to incorporate that I missed (and I haven't seen anything), it would be useful to know about it. Addison Misha Wolf wrote: > While we're making the registry ISO 11179 conformant, > can we also make it conformant with the tenets of the > World's major religions? > > Maybe we should propose to Sacha Baron Cohen that ISO > 11179 should star in his next movie ... > > Misha > > > This email was sent to you by Reuters, the global news and information company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006C72708825722D_= Content-Type: text/html; charset="US-ASCII"
Did we ever come to any final decisions on the "great script debate" thread with respect to indicating that scripts aren't relevant for audio language tagging?

Regards,

Karen Broome



Addison Phillips <addison@yahoo-inc.com>

11/21/2006 11:31 AM

To
Misha Wolf <Misha.Wolf@reuters.com>
cc
ltru@ietf.org
Subject
Re: [Ltru] ISO 11179 conformance and a new draft





+1

By the way, I'm preparing a new draft of 4646bis for submission. I
haven't changed anything in the text for several weeks. If there is some
specific text that we've decided to incorporate that I missed (and I
haven't seen anything), it would be useful to know about it.

Addison

Misha Wolf wrote:
> While we're making the registry ISO 11179 conformant,
> can we also make it conformant with the tenets of the
> World's major religions?
>
> Maybe we should propose to Sacha Baron Cohen that ISO
> 11179 should star in his next movie ...
>
> Misha
>
>
> This email was sent to you by Reuters, the global news and information company.
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

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

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 006C72708825722D_=-- --===============1115149785== 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 --===============1115149785==-- From ltru-bounces@ietf.org Tue Nov 21 15:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmc1C-0008Fy-8H; Tue, 21 Nov 2006 15:14:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmc1B-0008Ft-6F for ltru@ietf.org; Tue, 21 Nov 2006 15:14:57 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmc19-00055t-OM for ltru@ietf.org; Tue, 21 Nov 2006 15:14:57 -0500 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id 725611A9D7F1; Tue, 21 Nov 2006 20:14:55 +0000 (UTC) Received: from mail59-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id 674A81A9E282; Tue, 21 Nov 2006 20:14:55 +0000 (UTC) Received: from mail59-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail59-ash-R.bigfish.com (Postfix) with ESMTP id 4D7D8A19185; Tue, 21 Nov 2006 20:14:55 +0000 (UTC) X-BigFish: VP Received: by mail59-ash (MessageSwitch) id 1164139985222814_12852; Tue, 21 Nov 2006 20:13:05 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail59-ash.bigfish.com (Postfix) with ESMTP id 14FA3A14961; Tue, 21 Nov 2006 20:13:05 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006112112163202-718309 ; Tue, 21 Nov 2006 12:16:32 -0800 In-Reply-To: <3C398E83D8F84788A11CBDF01D840375.MAI@home> To: debbie@ictmarketing.co.uk MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 21 Nov 2006 12:11:42 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/21/2006 12:11:42, Serialize complete at 11/21/2006 12:11:42, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/21/2006 12:16:32 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/21/2006 12:16:34 PM, Serialize complete at 11/21/2006 12:16:34 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: dewell@adelphia.net, 'LTRU Working Group' Subject: [Ltru] Re: ISO 11179 Summary was RE: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0587956195==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0587956195== Content-Type: multipart/alternative; boundary="=_alternative 006F0E368825722D_=" This is a multipart message in MIME format. --=_alternative 006F0E368825722D_= Content-Type: text/plain; charset="US-ASCII" I will see what I can do. I must warn you, I'm a bit slammed too. Tis' the season and I will be out of town for a standards meeting the first week in December. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Debbie Garside" 11/21/2006 07:50 AM Please respond to debbie@ictmarketing.co.uk To , "'LTRU Working Group'" , cc Subject ISO 11179 Summary was RE: ISO/FDIS 639-3 tables revised Doug wrote: > I know people keep asking you to "prepare a short summary" of > things, and doing the thinking for other people gets old > after a while, but... > Could you prepare a short summary of what it would take to > make the Registry "conformant" to ISO 11179 (however that is defined)? :-) Generally I am happy to do so but at this point in time I am snowed under with other work so it would most likely be after Christmas before I could get to it. I am not sure that I would be the right person to do this anyway. Karen is far more knowledgeable wrt ISO 11179 than I am. Karen, could you put a brief summary together? Sorry for passing the buck this time. I will happily contribute to any discussion. Best Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 21 November 2006 15:09 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: ISO/FDIS 639-3 tables revised > > Debbie Garside wrote: > > > I also think it would be a good idea if, in doing so, this WG > > considered at least the basic requirements for conformity > to ISO 11179 > > that the Registry structure could reflect very easily without > > necessarily adopting ISO 11179 at this point in time. > > I've never been clear on what the basic requirements would > be, since ISO > 11179 is a long, six-part document that I've never been able > to take the time to fully understand. > > I know people keep asking you to "prepare a short summary" of > things, and doing the thinking for other people gets old > after a while, but... > Could you prepare a short summary of what it would take to > make the Registry "conformant" to ISO 11179 (however that is defined)? > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > > > --=_alternative 006F0E368825722D_= Content-Type: text/html; charset="US-ASCII"
I will see what I can do. I must warn you, I'm a bit slammed too. Tis' the season and I will be out of town for a standards meeting the first week in December.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


"Debbie Garside" <debbie@ictmarketing.co.uk>

11/21/2006 07:50 AM
Please respond to
debbie@ictmarketing.co.uk
To
<dewell@adelphia.net>, "'LTRU Working Group'" <ltru@ietf.org>, <Karen_Broome@spe.sony.com>
cc
Subject
ISO 11179 Summary was RE: ISO/FDIS 639-3 tables revised





Doug wrote:

> I know people keep asking you to "prepare a short summary" of
> things, and doing the thinking for other people gets old
> after a while, but...
> Could you prepare a short summary of what it would take to
> make the Registry "conformant" to ISO 11179 (however that is defined)?

:-) Generally I am happy to do so but at this point in time I am snowed
under with other work so it would most likely be after Christmas before I
could get to it.

I am not sure that I would be the right person to do this anyway.  Karen is
far more knowledgeable wrt ISO 11179 than I am.  Karen, could you put a
brief summary together?

Sorry for passing the buck this time.  I will happily contribute to any
discussion.

Best

Debbie

> -----Original Message-----
> From: Doug Ewell [mailto:dewell@adelphia.net]
> Sent: 21 November 2006 15:09
> To: LTRU Working Group
> Cc: Debbie Garside
> Subject: Re: ISO/FDIS 639-3 tables revised
>
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
>
> > I also think it would be a good idea if, in doing so, this WG
> > considered at least the basic requirements for conformity
> to ISO 11179
> > that the Registry structure could reflect very easily without
> > necessarily adopting ISO 11179 at this point in time.
>
> I've never been clear on what the basic requirements would
> be, since ISO
> 11179 is a long, six-part document that I've never been able
> to take the time to fully understand.
>
> I know people keep asking you to "prepare a short summary" of
> things, and doing the thinking for other people gets old
> after a while, but...
> Could you prepare a short summary of what it would take to
> make the Registry "conformant" to ISO 11179 (however that is defined)?
>
> --
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  
> UTN #14 http://users.adelphia.net/~dewell/
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>
>
>
>
>






--=_alternative 006F0E368825722D_=-- --===============0587956195== 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 --===============0587956195==-- From ltru-bounces@ietf.org Tue Nov 21 15:22:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmc8M-00042F-RC; Tue, 21 Nov 2006 15:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmc8L-000428-LF for ltru@lists.ietf.org; Tue, 21 Nov 2006 15:22:21 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmc8G-0006sR-52 for ltru@lists.ietf.org; Tue, 21 Nov 2006 15:22:21 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gmc8D-0007z5-2U; Tue, 21 Nov 2006 15:22:13 -0500 Date: Tue, 21 Nov 2006 15:22:13 -0500 To: Addison Phillips Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061121202212.GC12648@ccil.org> References: <455CBFCA.4872@xyzzy.claranet.de> <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> <456062A4.7B63@xyzzy.claranet.de> <20061120023556.GC24285@ccil.org> <456351E5.5060102@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456351E5.5060102@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > The more I think about this thread, the more I'm of the opinion that > ISO 639-6 either defines an extension or defines a parallel standard. I disagree with this conclusion, while agreeing with most of your specific points. > As near as I can tell, most of the codes in ISO 639-6 have a 1:1 > relationship with some language tag. That is, they either map to > currently defined language tags using one or more subtags (napl => > nap-Latn) or they define a variant which is eligible for registration. I agree with this, although I would put it more precisely thus: most of the codes in 639-6 have a 1:1 relationship with some *potential* language tag. Randy has expressed a desire to allow the 639-6 language-collection tags to be made available also, and the reserved syntax for 4-alphas in the language subtag position makes this possible. In 639-6, a language collection is any code element that does not have a 639-3-defined language ancestral to it. Some of these are already included by virtue of their presence in 639-2. > I oppose including redundant subtags in the registry. It will confuse > people to no good purpose. Agreed. > Language tags, for various historical and practical reasons, consist > of subtags. Indeed. > ISO 639-6 codes might serve as a useful reference when registering > variants (perhaps a restriction should exist requiring variant > registrations collect a rejection slip form ISO 639-6 RA before > independently being registered, a la language subtags??) I agree that this is a good idea for the 4646ter process. > and might even serve as the source for specific variants not currently > registered in some 4646ter timeframe. That is, any ISO 639-6 codes > that don't have an associated language tag would be registered using > some format such as the below to identify the variation. That is precisely what I propose be done, en masse, in 4645ter: 639-6 language-collection code elements to be registered as language subtags; 639-6 code elements that are exactly equivalent to some valid 4646bis language tag to be excluded from 4646ter; all other 639-6 code elements to be accepted as variants in 4646ter, prefixed with '6' to make them long enough and unique, and with a Prefix: value corresponding to the appropriate language, script (if any), and region (if any) subtags associated with that code element. This leaves open the fate of existing variants that match 639-6 code elements: should they be deprecated in favor of their 639-6 equivalents, or left alone and the 639-6 equivalent excluded? -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; cowan@ccil.org Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 19:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmg2l-0001z5-Dn; Tue, 21 Nov 2006 19:32:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbem-0000Nd-Aj for ltru@ietf.org; Tue, 21 Nov 2006 14:51:48 -0500 Received: from inergen.sybase.com ([192.138.151.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmbek-0001fx-Rf for ltru@ietf.org; Tue, 21 Nov 2006 14:51:48 -0500 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id kALJpb928742; Tue, 21 Nov 2006 11:51:37 -0800 (PST) Received: from olympus-dublin.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com with ESMTP id kALJpau11712; Tue, 21 Nov 2006 11:51:36 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.7p1+Sun/8.10.2) with ESMTP id kALJpaM11230; Tue, 21 Nov 2006 11:51:36 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id kALJpZT15348; Tue, 21 Nov 2006 11:51:35 -0800 (PST) Message-Id: <200611211951.kALJpZT15348@birdie.sybase.com> Date: Tue, 21 Nov 2006 11:51:35 -0800 (PST) From: Kenneth Whistler To: mgunn@egt.ie MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wtkTiGd8hNKijCGotF4jVQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Tue, 21 Nov 2006 19:32:50 -0500 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, ltru@ietf.org, kenw@sybase.com Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Whistler List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > Fine - suppose we all believe the above claim (which I, personally, > happen to do), then let's suppose we drop Ken and any compatriot of > his choice, who happen to be both equally _literate_ in IPA and > equally _illiterate_ in some endangered language (to make things even > easier, let's make it any indigenous language of the Americas in > which they both happen to be illiterate!) Well, I think that is a misconstrual to begin with. I assume you are talking about a community without an indigenous writing system. In which case, it doesn't make much sense to talk about me (or my hypothetical compatriot) being "illiterate" in a non-existent writing system. And I guess you mean to posit that there isn't any other written material gathered by prior visits by any trained linguist or anthropologist or even just some 19th century BAE employee gathering word lists. At this point such a postulation is becoming counterfactual for almost any language community that you could meaningfully hope to gather data from, but whatever... > into an indigenous > community, their mission being to write down all possible of that > community's stories and traditional cures in a single week, with all > travel expenses paid? Well, first of all, such an approach isn't very likely to be the most effective in gathering good data. If I were the one making funding decisions about salvage linguistics, if that is what you have in mind, I wouldn't be favoring the funding of helicopter in for a week and helicopter out approaches, but taking the scenario and running with it... Assuming I and my hypothetical compatriot were constrained to these parameters and that week, I would organize the work as follows: Track down the best traditional raconteur(s) in the town/village and set my compatriot to gathering high-quality digital recordings of whatever s/he could elicit, interspersed on an item by item basis with a retelling, if possible, of the tales in the contact language (Spanish, English, Portuguese) and any explanatory commentary about it. That would give the best chance of being able to gather good data (and lots of it) with an ability to unravel any of it later on. Meanwhile, track down the best bilingual speaker with a willingness to work long hours nonstop and a sense of language structure. Spend the first two days or so unravelling the phonology as best as possible, and devising a practical scheme to write down the *significant* distinctions phonemically, making sure that by the end of that time, I had an easy-to-write way to transcribe (and enter into a computer) quickly, without bothering about irrelevant phonetic details. Then spend the rest of the week pounding through the gathering of as much vocabulary (with glosses in the contact language) as possible, and unravelling the basics of morphological structure and syntax, so that there would some chance to make sense of the extended digital corpus being collected. > > How would you like us to tag the results of your week's work, Ken? Latn. I definitely would *not* do this in IPA. IPA is actually singularly ill-equipped to handle this kind of a task. If the task is to gather lots of *content* quickly and accurately in a short amount of time, I don't consider IPA to be a good tool. It is harder to write and can bog you down in irrelevant detail. Where it makes sense is when you are focussing on recording precise detail for phonological analysis per se. For example, if I discovered early on in the phonological analysis that I was dealing with a 5 vowel system (fairly common in the Americas), I would very, very quickly abandon all the details of iotas and epsilons and open o's and turned a's and turned m's and whatnot, for an "aeiou" system that worked for rapid transcription. I would end up with a rough-and-ready practical phonemic, Latin-based orthography, probably based primarily on Americanist standards, but possibly borrowing some IPA usage for particular phonemes if useful. And whatever happened during the week, it would have to be refined later into a consistent orthography that could be used to attempt to then transcribe the larger corpus of recorded textual material. --Ken P.S. I *have* done salvage linguistic fieldwork in California, although not on Chumash -- all varieties of which were extinct before I was trained as a field linguist. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 20:04:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmgWt-00021C-Iy; Tue, 21 Nov 2006 20:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmgWr-00020j-Te for ltru@lists.ietf.org; Tue, 21 Nov 2006 20:03:57 -0500 Received: from mailc.microsoft.com ([205.248.106.32] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmgUN-0000Yh-MS for ltru@lists.ietf.org; Tue, 21 Nov 2006 20:01:27 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.15; Tue, 21 Nov 2006 17:01:23 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:01:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: LTRU progress and ISO 639-6 Date: Tue, 21 Nov 2006 17:01:14 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A13422@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <20061120023556.GC24285@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: LTRU progress and ISO 639-6 Thread-Index: AccMTJ/ZiNaI/oi0Rs2KqZRWOyKkNgBhI3EA From: Peter Constable To: X-OriginalArrivalTime: 22 Nov 2006 01:01:22.0939 (UTC) FILETIME=[BA5DE4B0:01C70DD1] 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 In my mind, this raises the question of what use having "napl" in 639-6 = is anyway? It has the same semantics as "nap-Latn" and I don't see a = point in having a metadata element to denote a semantic for which we = already have an existing metadata element unless someone has a syntactic = requirement -- their metadata elements must all be alpha4 -- but I see = no indication of anyone having such a requirement. Peter > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > No, I disagree. Quite independent of Suppress-Script, 'napl' does not > contain any extra information above "nap" or "nap-Latn" as the case > may be. So it remains forbidden to use either "nap-6napl" or > "nap-Latn-6napl". See my previous post for the rationale. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 20:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmgvy-0001BJ-CA; Tue, 21 Nov 2006 20:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmgvx-0001BD-K7 for ltru@ietf.org; Tue, 21 Nov 2006 20:29:53 -0500 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmgvu-0005LC-Ni for ltru@ietf.org; Tue, 21 Nov 2006 20:29:53 -0500 Received: by nz-out-0102.google.com with SMTP id z6so27710nzd for ; Tue, 21 Nov 2006 17:29:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ogY1JZMYTyibcvkihxjLEUZ8OKyWff5Of0LMVP/QKkWThcPGgLTWhEEiRjXf+++/CHJBmOel6UimHjPqEgMsONhMuB5NmO4Mujn1DGy3ovU1yMu+x1DjD3IKHVBbmjBbm6tZEJgecpvHsX1WvOeCgJRQuYzdUNsSfI1u/LIOSck= Received: by 10.65.239.14 with SMTP id q14mr11461956qbr.1164158990270; Tue, 21 Nov 2006 17:29:50 -0800 (PST) Received: by 10.65.252.11 with HTTP; Tue, 21 Nov 2006 17:29:50 -0800 (PST) Message-ID: <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> Date: Tue, 21 Nov 2006 17:29:50 -0800 From: "Mark Davis" To: "Kenneth Whistler" In-Reply-To: <200611210150.kAL1oWT14470@birdie.sybase.com> MIME-Version: 1.0 References: <200611210150.kAL1oWT14470@birdie.sybase.com> X-Google-Sender-Auth: bf9895c4ac150682 X-Spam-Score: 0.5 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: ietf-languages@iana.org, LTRU Working Group , iso15924-jac@unicode.org Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1540444106==" Errors-To: ltru-bounces@ietf.org --===============1540444106== Content-Type: multipart/alternative; boundary="----=_Part_87792_24637650.1164158990199" ------=_Part_87792_24637650.1164158990199 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTEvMjAvMDYsIEtlbm5ldGggV2hpc3RsZXIgPGtlbndAc3liYXNlLmNvbT4gd3JvdGU6Cj4K PiBNYXJrLAo+Cj4gPgo+ID4gMTU5MjQgZG9lcyBub3QgZW5jb2RlIGp1c3Qgc2NyaXB0cywgaXQg YWxzbyBoYXMgdmFyaWFudHMgYW5kIGFsaWFzZXMsCj4gc3VjaAo+ID4gYXM6Cj4gPgo+ID4gICAg LSBDeXJzLCBMYXRmLCBMYXRnLCBIYW5zLCBIYW50LCBTeXJlLCBTeXJqLCBTeXJuCj4gPiAgICAt IEhya3QsIEpwYW4KPiA+Cj4gPiBUaGUgaW5jbHVzaW9uIG9mIElQQSBhcyBhIHZhcmlhbnQgc2Ny aXB0IG9mIExhdGluIGlzIGxpdHRsZSBkaWZmZXJlbnQKPiBmcm9tCj4gPiB0aGUgZGlzdGluY3Rp b24gYmV0d2VlbiBIYW5zIGFuZCBIYW50OyBib3RoIGFyZSBwcmltYXJpbHkgZGlmZmVyZW5jZXMg aW4KPiA+IHNlbGVjdGlvbiBvZiBjaGFyYWN0ZXJzIGZyb20gVUNTLiBUaGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIEVuZ2xpc2ggd3JpdHRlbgo+IGluCj4gPiBJUEEgdnMgcmVndWxhciBMYXRpbiBjaGFy YWN0ZXJzIGlzIGNlcnRhaW5seSBvbiB0aGUgb3JkZXIgb2YgdGhlCj4gZGlmZmVyZW5jZQo+ID4g YmV0d2VlbiBDaGluZXNlIHdyaXR0ZW4gaW4gSGFucyB2cyBIYW50LCBpZiBub3QgbW9yZSBzby4K Pgo+IFRydWUsIGJ1dCBhIHNwZWNpb3VzIGFuYWxvZ3kgbm9uZXRoZWxlc3MuCj4KPiBCYXNpY2Fs bHkgd2hhdCBpcyBnb2luZyBvbiBoZXJlIGlzIHRoYXQgc2NyaXB0IGNvZGVzLCBiZWNhdXNlCj4g dGhleSBhcmUgYXZhaWxhYmxlIGFuZCB0aWVkIHRvIHRoZSBsYW5ndWFnZSBjb2RlIGFwcGFyYXR1 cywgYXJlCj4gYmVpbmcgZXh0ZW5kZWQgdG8gYXBwbHkgdG8gYW55ICJzaWduaWZpY2FudCB2YXJp YXRpb24gaW4gd3JpdGluZyBzeXN0ZW0iCj4gdGhhdCBwb3BzIHVwIHRvIHRoZSBsZXZlbCBvZiAi d2UgY2FyZSBhYm91dCB0aGUgZGlmZmVyZW5jZSBmb3IKPiBvdXIgaW1wbGVtZW50YXRpb25zLiIK Pgo+IE5vdyBtYXliZSB0aGF0IGlzIGV4YWN0bHkgd2hhdCBuZWVkcyB0byBiZSBkb25lLCBidXQg aW4gbXkgb3Bpbmlvbgo+IHRoZSByaWdodCB3YXkgdG8gaGFuZGxlIHRoaXMgaXMgdG8gZmlyc3Qg KmZvcm1hbGx5KiBleHRlbmQgdGhlCj4gc2NvcGUgb2YgMTU5MjQsIHNvIHRoYXQgaXQgbm8gbG9u Z2VyIGlzIGEgc3RhbmRhcmQgZm9yIHRoZQo+IHJlZ2lzdHJhdGlvbiBvZiBzY3JpcHQgY29kZXMs IGJ1dCBmb3Igc2NyaXB0IGNvZGVzICphbmQqCj4gc2VsZWN0ZWQgb3J0aG9ncmFwaHkgY29kZXMg b2YgaW50ZXJlc3QgKmFuZCogc2VsZWN0ZWQgdmFyaWFudHMKPiBvZiB3cml0aW5nIHN5c3RlbXMg b2YgaW50ZXJlc3QuIEF0IHRoYXQgcG9pbnQgdGhlIEpBQyB3b3VsZG4ndAo+IGhhdmUgdG8gc2l0 IGFuZCBhcmd1ZSBvbiBwcmluY2lwbGUgd2hldGhlciBzb21lIHBhcnRpY3VsYXIKPiBvZGRiYWxs IHJlcXVlc3QgZml0cyBvciBub3QsIGFuZCBpbXBsZW1lbnRlcnMgd291bGQgYmUgZnJlZXIKPiB0 byBhc2sgZm9yIHN0dWZmIHRoYXQgbWF0Y2hlcyBkaXN0aW5jdGlvbnMgdGhleSB3b3VsZCBsaWtl IHRvCj4gbWFrZS4KPgo+IEFzIGl0IGlzLCBpdCBpcyBiYWQgZW5vdWdoIHRoYXQgd2UgaGF2ZSBh ICJzY3JpcHQiIHJlZ2lzdHJhdGlvbgo+IHN0YW5kYXJkIHRoYXQgdHJpZXMgdG8gbWF0Y2ggdXAg YWdhaW5zdCB0aGUgInNjcmlwdHMiIGVuY29kZWQKPiBpbiBVbmljb2RlLCBhbmQgaGFzIGEgbW9z dGx5IHVuZXhwbGFpbmVkIGhhaXJiYWxsIG9mIHN0dWZmCj4gd2hpY2ggY2FuJ3QgYmUgbWF0Y2hl ZCB1cCwgYnV0IG5vdyByZXF1ZXN0cyB0byByZWdpc3RlciBzdHVmZiBsaWtlCj4gSVBBIGZvciBh IHNjcmlwdCBjb2RlIGtlZXAgcHVzaGluZyB0aGluZ3MgZnVydGhlciB0aGF0IHdheS4KCgpJIGRv bid0IHJlYWxseSBzZWUgdGhlIG5lY2Vzc2l0eSBmb3IgYSBjaGFydGVyIGNoYW5nZTsgaW4gcGFy dGljdWxhciwgSQpkb24ndCBzZWUgYW55dGhpbmcgaW4KaHR0cDovL3d3dy51bmljb2RlLm9yZy9p c28xNTkyNC9zdGFuZGFyZC9pbmRleC5odG1sdGhhdCB3b3VsZCBzYXkgdGhhdApIYW50IGlzIGEg dmFsaWQgc2NyaXB0IHZhcmlhbnQsIGFuZCBJUEEgaXMgbm90LiBNYXliZQpJJ20gbm90IGxvb2tp bmcgaW4gdGhlIHJpZ2h0IGFyZWEsIHNvIGFueSBoZWxwIHdvdWxkIGJlIGFwcHJlY2lhdGVkLgoK PiBJdCB3b3VsZCBiZSBvZgo+ID4gZ3JlYXQgYmVuZWZpdCB0byB1c2VycyBvZiBJUEEgdG8gYmUg YWJsZSB0byB0YWcgZGF0YSB3aXRoIGEgdmFyaWFudAo+IHNjcmlwdAo+ID4gY29kZSwgYW5kIGxp dHRsZSBwcmFnbWF0aWMgcmVhc29uIG5vdCB0byBhbGxvdyB0aGF0LCBlc3BlY2lhbGx5IGluIHZp ZXcKPiBvZgo+ID4gdGhlIGZhY3QgdGhhdCB0aGUgc3RhbmRhcmQgaGFzIGFscmVhZHkgYmVlbiBz dHJldGNoZWQgdG8gaW5jbHVkZQo+IHZhcmlhbnRzCj4gPiBhbmQgYWxpYXNlcy4KPgo+IER1bm5v IHdoYXQgYWxpYXNlcyBoYXZlIHRvIGRvIHdpdGggaXQsIG90aGVyIHRoYW4gdG8gcHVmZiB1cCB0 aGUKPiBhcmd1bWVudC4KCgpXaGF0IHRoZXkgaGF2ZSB0byBkbyB3aXRoIGl0IGlzIHRoYXQgMTU5 MjQgaXMgYWxyZWFkeSBub3QgInB1cmUiOiBKcGFuIGlzCm5vdCB0aGUgbmFtZSBvZiAiYSIgc2Ny aXB0LgoKQW5kIElQQSBpcyBub3QgYSB2YXJpYW50IHNjcmlwdC4gSXQgaXMgbm90IGNvbXBhcmFi bGUgdG8gTGF0ZiBhbmQgTGF0Zy4KPiBJdCBpcyBhIGNpcmN1bXNjcmliZWQsIHRlY2huaWNhbCB1 c2Ugb2YgTGF0bi4KCgoKImNhdCIgaXMgRW5nbGlzaC4KPiAiW2NhdF0iIGlzIElQQS4gVGVsbCBt ZSB0aGUgc2NyaXB0IGRpZmZlcmVuY2UsIGV4Y2VwdCBpbiBmdW5jdGlvbi4KCgptdXRhdGlzIG11 dGFuZGlzOiAi5LiA5LqM5LiJIiBpcyBIYW50LCBhbmQgIuS4gOS6jOS4iSIgaXMgSGFucy4gVGVs bCBtZSB0aGUgc2NyaXB0CmRpZmZlcmVuY2UsIGV4Y2VwdCBpbiBmdW5jdGlvbi4KClNvIGFzIGlu IHRoZSBjYXNlIG9mIEhhbnQgdmVyc3VzIEhhbnMsIHJlZ2lzdGVyaW5nIElQQSB3aXRoIGEKPiBz Y3JpcHQgY29kZSB3b3VsZCBiZSBhbm90aGVyIGFkIGhvYyBleHRlbnNpb24gb2YgMTU5MjQgaW4g YW4KPiBvcnRob2dvbmFsIGJ1dCBiYXNpY2FsbHkgdW5leHBsYWluZWQgZGlyZWN0aW9uLgoKCllv dSBzZWVtIHRvIHNlZSB0aGlzIGFzIGEgc2xpcHBlcnkgc2xvcGU7IHRha2UgdGhhdCBvbmUgZHJp bmssIGFuZCB0aGVyZSBpcwphbiBpbmV2aXRhYmxlIHBhdGggdG8gbHlpbmcgaW4gdGhlIGd1dHRl ciB3aXRoIGEgYm90dGxlIG9mIFJpcHBsZSBpbiBhIGJyb3duCnBhcGVyIGJhZy4gSSBzZWUgaXQg YXMgZm9sbG93aW5nIHRoZSBwcmVjZWRlbnQgYWxyZWFkeSBzZXQgd2l0aCBIYW5zL0hhbnQsCmFu ZCBwcm92aWRpbmcgYSByZWFzb25hYmxlLCBwcmFnbWF0aWMgc29sdXRpb24gZm9yIGxhbmd1YWdl IHRhZ3MuIEkgZG9uJ3QKc2VlIGFueW9uZSB3YW50aW5nIHRvIHVzZSBzY3JpcHQgY29kZXMgZm9y IHNtYWxsZXIgb3J0aG9ncmFwaGljCmRpc3RpbmN0aW9ucywgc3VjaCBhcyBiZXR3ZWVuICJ0aGVh dHJlIiBhbmQgInRoZWF0ZXIiOyBsYW5ndWFnZSB0YWdzIGNhbgphbHJlYWR5IGVuY29tcGFzcyBz dWNoIGRpZmZlcmVuY2VzLgoKVGhlIHByYWdtYXRpYyByZWFzb24gbm90IHRvIGFsbG93IHRoYXQg aXMgdG8gcHJldmVudCAxNTkyNCBiZWluZwo+IHVzZWQgdG8gZnVydGhlciBtdWRkeSBhbGwgdGhl IGRpbWVuc2lvbnMgb2YgZGlzdGluY3Rpb25zIGluCj4gd3JpdGluZyBzeXN0ZW1zLgo+Cj4gQnV0 IHRoZSBwcmFnbWF0aWMgcmVhc29uIHRvICphbGxvdyogaXQgd291bGQgYmUgdG8gbGV0IEdvb2ds ZQo+IGFuZCBNaWNyb3NvZnQgZG8gd2hhdCB0aGV5IHdhbnQgdG8gZG8gZm9yIHNlYXJjaGVzIGFu eXdheSwgYW5kCj4gdG8gaGVsbCB3aXRoIGV4cGVjdGluZyAxNTkyNCB0byBtYWtlIGFueSBzZW5z ZSBvdXRzaWRlIGl0cwo+IHVzZSBhcyBhIHN0YW5kYXJkIGZvciBsYWJlbGluZyAid3JpdHRlbiBz dHVmZiB3ZSB3YW50IHRvIGRpc3Rpbmd1aXNoIi4KCgpUaGUgcG9saXRpY2FsIHNlYXNvbiBpcyBv dmVyLCBhbmQgSSBzZWUgbm8gbmVlZCB0byBnZXQgaW50byBhZCBob21pbmVtCmF0dGFja3MuIEdv b2dsZSBoYXMsIHRvIG15IGtub3dsZWRnZSwgbm8gcGFydGljdWxhciBzdGFrZSBpbiB0aGlzIGlz c3VlIC0tIEkKZG9uJ3Qga25vdyB0aGF0IE1TIGRvZXMgZWl0aGVyLiBUaGlzIGlzIHJlYWxseSBq dXN0IGEgdGVjaG5pY2FsIGlzc3VlIG9mIGhvdwp0byBiZXN0IHVzZSBzY3JpcHQgdmFsdWVzIGlu IHRoZSBsYW5ndWFnZSB0YWcgbWVjaGFuaXNtIG1vc3QgZWZmZWN0aXZlbHkuCkxhbmd1YWdlIHRh Z3MgYXJlIGEgYmlnIGN1c3RvbWVyIGZvciBJU08gMTU5MjQsIGFuZCBpdCB3b3VsZCBzZWVtIHJl YXNvbmFibGUKdG8gYXQgbGVhc3QgY29uc2lkZXIgdGhlIGlzc3VlIGZyb20gYWxsIHNpZGVzLgoK PiA+PiBUaGlzIGlzIG5vdCBteSB2aWV3IG9ubHkuIEl0IHdhcyB0aGUgdmlldyBvZiB0aGUgUkEu Cj4gPgo+ID4gUmVnYXJkaW5nIHRoZSBhYm92ZSBzdGF0ZW1lbnQsIEkgYWxzbyB3YW50IHRvIGFk ZCB0aGF0IGFzIGZhciBhcyBJIGNhbgo+IHRlbGwsCj4gPiB0aGUgMTU5MjQgSkFDIGRpZCBub3Qg Y29uc2lkZXIgdGhpcyB0b3BpYyBpbiBhbnkgZGVwdGgsIG5vciBkb2VzIGFueSBvZgo+IHRoZQo+ ID4gZGlzY3Vzc2lvbiBoZXJlIHNlZW0gdG8gYmUgZm9yd2FyZGVkIHRvIHRoZSBKQUMgZm9yIHRo ZWlyIGNvbnNpZGVyYXRpb247Cj4gSQo+ID4gYmVsaWV2ZSB0aGF0IHRoZSBtZW1iZXJzIGFyZSB1 bmF3YXJlIG9mIHRoZSBpc3N1ZXMgcmFpc2VkIHJlZ2FyZGluZwo+IGxhbmd1YWdlCj4gPiB0YWdz LiBBcyBmYXIgYXMgSSBjb3VsZCBzZWUgZnJvbSBlbWFpbCwgdGhlIHN1bSB0b3RhbCBvZiB0aGUg ZGlzY3Vzc2lvbgo+IHdhcwo+ID4gdGhyZWUgc3RhdGVtZW50cywgdHdvIGJ5IHRoZSBzYW1lIHBl cnNvbjoKPiA+Cj4gPiBBOiAiQXMgZmFyIGFzIEkgY2FuIHNlZSwgSVBBIGlzIGp1c3QgYSBzZXQg b2YgTGF0aW4gY2hhcmFjdGVycy4iCj4gPiBBOiAiVGhlIElQQSBpcyBhIHNldCBvZiBMYXRpbiBs ZXR0ZXJzLCBhbmQgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IExhdG4uCj4gSXQgaXMKPiA+IGFuIG9y dGhvZ3JhcGh5IG9mIExhdGluLCBub3QgYSBzY3JpcHQgb2YgaXRzIG93bi4iCj4gPiBDOiAiSSBj b25jdXIgd2l0aCB0aGlzIGNvbmNsdXNpb24uIgo+ID4gW25hbWVzIHJlbW92ZWQgdG8gcHJvdGVj dCB0aGUgaW5ub2NlbnRdCj4KPiBZZWFoLCB5ZWFoLCBjdXRlLCBNYXJrLiBOb3RlIGFsc28gdGhh dCBNaWNoYWVsIGFuZCBJLCBhdCBsZWFzdCwKPiB3ZXJlIHRyYWluZWQgaW4gSVBBIChhbmQgb3Ro ZXIgcGhvbmV0aWMgb3J0aG9ncmFwaGllcykgYW5kCj4gbWFkZSBzaWduaWZpY2FudCBwcm9mZXNz aW9uYWwgdXNlIG9mIHRoZW0uIFNvIGl0IGlzbid0IGFzCj4gaWYgd2UgYXJlIGJhYmVzIGluIHRo ZSB3b29kcyBoZXJlIHByZXNlbnRlZCB3aXRoIHNvbWV0aGluZwo+IHdlJ3ZlIG5ldmVyIGhlYXJk IG9mIGJlZm9yZSwgYW5kIGFyZSBtYWtpbmcgb2ZmLXRoZS1jdWZmLCB1bmluZm9ybWVkCj4gcmVt YXJrcyBhYm91dC4KPgo+IElmIHlvdSBmZWVsIHRoYXQgYSByZWdpc3RyYXRpb24gZm9yIElQQSBi ZWxvbmdzIGluIDE1OTI0LCB0aGVuCj4gbWFrZSB0aGUgY2FzZSB3aHkgMTU5MjQgc2hvdWxkIHN0 YXJ0IHJlZ2lzdGVyaW5nIG9ydGhvZ3JhcGhpYwo+IGNvbnZlbnRpb25zIGZvciB0aGUgdXNlIG9m IGEgc2NyaXB0LCBpbnN0ZWFkIG9mIGp1c3Qga25vY2tpbmcKPiB0aGUgSkFDIGZvciAibm90IGNv bnNpZGVyW2luZ10gdGhpcyB0b3BpYyBpbiBhbnkgZGVwdGgsIiBwbGVhc2UuCgoKSSB0aGluayBJ IG1pZ2h0IG5vdCBoYXZlIGJlZW4gY2xlYXIuIFdoaWxlIHRoZXJlIG1heSBiZSBnb29kIHJlYXNv bnMgZm9yIHdoeQpJUEEgZG9lc24ndCBxdWFsaWZ5LCBhbmQgeWV0IEhhbnMgJiBIYW50IHF1YWxp ZnksIGJ1dCB0aGUgSkFDIGRpZCBub3QgbWFrZQp0aGUgcmF0aW9uYWxlIGNsZWFyLiBXaGlsZSB0 aGUgZGlmZmVyZW5jZSBtYXkgYmUgYmxpbmRpbmdseSBvYnZpb3VzIHRvIHlvdSwKaXQgd291bGQg YmUgaGVscGZ1bCB0byBoZWFyIHdoYXQgaXQgYWN0dWFsbHkgaXMsIG1vcmUgdGhhbiBhbiAiSSBj b25jdXIiLgoKQWxzbywgSSBzdWdnZXN0IHlvdSBjb25zaWRlciB0aGUgZGlzdGluY3Rpb24gYmV0 d2VlbiB0aGUgZnVuY3Rpb24KPiBvZiBJUEEgYXMgYSBiaWJsaW9ncmFwaGljIGNvZGUgYW5kIGFz IGEgImxhbmd1YWdlIiBjb2RlLiBUaGVyZQo+IGFyZSB2ZXJ5LCB2ZXJ5IGZldyBib29rcywgYXJ0 aWNsZXMsIG9yIGFueXRoaW5nIGVsc2UgdGhhdCBjb25zaXN0Cj4gZXhjbHVzaXZlbHkgb3IgcHJp bWFyaWx5IG9mIElQQSB1c2VkIGp1c3QgdG8gcmVwcmVzZW50IHRleHQuIE1vc3QKPiBvZiB0aGUg b25lcyB0aGF0IGRvIGV4aXN0IGFyZSBleHBlcmltZW50YWwgZmFpbHVyZXMsIGJhc2ljYWxseS4K PiBJdCB3b3VsZCBiZSB2ZXJ5IHJhcmUgdGhhdCB5b3Ugd291bGQgbmVlZCBhIGJpYmxpb2dyYXBo aWMgY29kZQo+IGZvciBhIGJvb2sgKmluKiBJUEEsIGFzIG9wcG9zZWQgdG8gYSBib29rICphYm91 dCogSVBBIG9yIGluY2x1ZGluZwo+IHVzZSAqb2YqIElQQS4gT24gdGhlIG90aGVyIGhhbmQsIGl0 IGlzIHV0dGVybHkgbm9ybWFsIGZvcgo+IElQQSB0byBiZSB1c2VkIGV4dGVuc2l2ZWx5IGVtYmVk ZGVkIGluIHRoZSBtaWRkbGUgb2Ygb3RoZXJ3aXNlCj4gbm9ybWFsIExhdGluIHRleHQgKG9yLCB0 byBiZSBzdXJlLCBhcyBjaXRhdGlvbnMgdXNlZCBpbiB0aGUKPiBtaWRkbGUgb2YgQ3lyaWxsaWMg b3IgSmFwYW5lc2Ugb3IgQ2hpbmVzZSBvciB3aGF0ZXZlciBvdGhlcgo+IHRleHQpLiBJZiB5b3Ug ZW1iZWQgYSBidW5jaCBvZiBJUEEgaW4gdGhlIG1pZGRsZSBvZiBvdGhlcndpc2UKPiB1bnJlbWFy a2FibGUgTGF0aW4gdGV4dCwgeW91IHJlYWxseSBhcmVuJ3QgdGFsa2luZyBhYm91dCBhCj4gYmli bGlvZ3JhcGhpYyBjb2RlIGF0IGFsbCwgYnV0IHRhZ2dpbmcgcnVucyBvZiB0ZXh0IGFzIGJlaW5n Cj4gaW4gYSBzcGVjaWFsIGZ1bmN0aW9uIG9ydGhvZ3JhcGh5LiBJZiB0aGF0J3Mgd2hhdCB5b3Ug bmVlZCB0bwo+IG1ha2UgdGV4dCBzZWFyY2hlcyB3b3JrIHJpZ2h0IGZvciBpbnRlcnByZXRpbmcg c3VjaCBydW5zIG9mCj4gc3BlY2lhbGl6ZWQgdGV4dCwgdGhlbiBtYWtlIHRoZSBjYXNlIGZvciBp dC4KCgpJIGRvbid0IHRoaW5rIGFueW9uZSBpcyBleHBlY3RpbmcgYm9va3MgaW4gSVBBIC0tIGl0 IHdvdWxkIGJlLCBhcyB5b3Ugc2F5LAp0YWdnZWQgZnJhZ21lbnRzLgoKQnV0IHRoZSBmYWN0IGlz IHRoYXQgb25jZSB5b3UgZ2V0IGJleW9uZCBzdGFuZGFyZCB3cml0aW5nIHN5c3RlbXMKPiB3aXRo IHN0YW5kYXJkaXplZCBzcGVsbGluZ3MgYW5kIHN0YXJ0IGhpdHRpbmcgdGhlIHRleHQgY29ycHVz ZXMKPiBvZiBzcGVjaWFsaXplZCBsYW5ndWFnZXMgaW4gc3BlY2lhbGl6ZWQgb3J0aG9ncmFwaGll cyB3aGljaCBhcmUKPiBpbmNyZWFzaW5nbHkgbGlrZWx5IHRvIGdldCBvcGVubHkgcG9zdGVkIG9u IHRoZSB3ZWIsIHlvdQo+IGFyZSBnb2luZyB0byBuZWVkIGEgY29kZSBmb3IgKmVhY2gqIG9ydGhv Z3JhcGh5IGluIHVzZSwgcGVyIGxhbmd1YWdlLAo+IHRvIG1ha2UgYW55IHNlbnNlIG9mIHRoZSBj b250ZW50IG9mIHRob3NlIGNvcnB1c2VzLgo+Cj4gU2F5IEkgd2VyZSB0byBzdGFydCBwb3N0aW5n IENodW1hc2ggbGFuZ3VhZ2UgbWF0ZXJpYWxzIG9uIHRoZQo+IHdlYiBpbiBVbmljb2RlLiAoVGhl cmUgYXJlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGxpbmd1aXN0cywKPiBDaHVtYXNoIGRlc2Nl bmRhbnRzLCBhbnRocm9wb2xvZ2lzdHMsIGFuZCBqdXN0IHBsYWluIENodW1hc2gKPiBhZmZpY2lv bmFkb3MgYW1vbmcgdGhlIGdlbmVyYWwgd2hpdGUgcG9wdWxhdGlvbiBpbiBTYW50YSBCYXJiYXJh Cj4gYW5kIFZlbnR1cmEgY291bnRpZXMgd2hvIHdvdWxkIGxpa2UgdGhhdCwgYnkgdGhlIHdheS4p IFRvCj4gc2VhcmNoIHRoYXQgbWF0ZXJpYWwsIGFuZCBqdXN0IHN0aWNraW5nIHRvIHRoZSBCYXJi YXJlbm8KPiB2ZXJzaW9uIG9mIENodW1hc2gsIHlvdSB3b3VsZCBuZWVkIGF0IGxlYXN0Ogo+Cj4g Q2h1bWFzaC1CYXJiYXJlbm8gaW4gSVBBCj4gQ2h1bWFzaC1CYXJiYXJlbm8gaW4gSlBIYXJyaW5n dG9uIG9ydGhvZ3JhcGh5IChhIG1hc3NpdmUgY29ycHVzKQo+IENodW1hc2gtQmFyYmFyZW5vIGlu IEFtZXJpY2FuaXN0IG9ydGhvZ3JhcGh5Cj4gQ2h1bWFzaC1CYXJiYXJlbm8gaW4gQXBwbGVnYXRl IHByYWN0aWNhbCBvcnRob2dyYXBoeSAodXNlZCBieSBzb21lCj4gICAgICAgICAgICAgICAgICAg ICAgICBhbnRocm9wb2xvZ2lzdHMgYW5kIGEgbG90IG9mIG1hdGVyaWFsKQo+IENodW1hc2gtQmFy YmFyZW5vIGluIFdoaXN0bGVyIHByYWN0aWNhbCBvcnRob2dyYXBoeQo+IENodW1hc2gtQmFyYmFy ZW5vIGluIENodW1hc2ggbmF0aW9uIG9ydGhvZ3JhcGh5Cj4KPiBCZWNhdXNlIHRleHRzIGFyZSBz cGVsbGVkIHN5c3RlbWF0aWNhbGx5IGRpZmZlcmVudGx5IGluIGVhY2ggb2YKPiB0aG9zZSBzeXN0 ZW1zIGFuZCB1c2Ugc29tZXdoYXQgZGlmZmVyZW50IHJlcGVydG9pcmVzIG9mIGNoYXJhY3RlcnMu Cj4KPiBTbyBtYWtlIHlvdXIgY2FzZSB3aHkgSVBBIGlzIHNwZWNpYWwuIChGb3IgQ2h1bWFzaCwg aXQgd291bGQsCj4gZm9yIGV4YW1wbGUsIGJlIG9mIHZlcnkgbGl0dGxlIHJlYWwgdmFsdWUsIGJl Y2F1c2UgdmVyeSBsaXR0bGUKPiBvZiB0aGUgQ2h1bWFzaCBkYXRhIGlzIHJlcHJlc2VudGVkIGRp cmVjdGx5IGluIElQQS4pIFdoZXJlIGRvCj4geW91IGRyYXcgdGhlIGxpbmUgaW4gcmVnaXN0ZXJp bmcgdGhlc2UgdGhpbmc/Cj4KPiBPciBkbyB5b3UgdGhpbmsgcmVnaXN0ZXJpbmcgSVBBIGp1c3Qg c29sdmVzIHNvbWUgcHJvYmxlbSB0aGF0Cj4gd29uJ3QgY29tZSBhcm91bmQgYWdhaW4gZm9yIHRo ZSBuZXh0IHRlY2huaWNhbCBvcnRob2dyYXBoeQo+IHRoYXQgY29tZXMgZG93biB0aGUgcGlrZT8K CgpObywgSSB0aGluayBldmVyeW9uZSBpcyBhd2FyZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBz eXN0ZW1zIG9mIHBob25ldGljCnJlcHJlc2VudGF0aW9ucy4gU28gSVBBIHdvdWxkIGxpa2VseSBi ZSB0aGUgZmlyc3Qgb2Ygc2V2ZXJhbC4gQnV0IGl0IGlzCmNsZWFybHkgYSByZWxhdGl2ZWx5IGlt cG9ydGFudCBvbmUsIGJlaW5nIGluIHByZXR0eSB3aWRlc3ByZWFkIHVzZSBpbgpkaWN0aW9uYXJp ZXMgYW5kIG90aGVyIHNvdXJjZXMuIEFzIHdpdGggZW5jb2RpbmcgY2hhcmFjdGVycywgb3Igc2Ny aXB0CnZhcmlhbnRzLCBhdCBzb21lIHBvaW50IHlvdSBoYXZlIHRvIG1ha2UganVkZ21lbnRzIGFz IHRvIHdoZXRoZXIgYSBzeXN0ZW0gaXMKaW4gd2lkZSBlbm91Z2ggdXNhZ2UgdG8gYmUgd29ydGgg ZW5jb2Rpbmc7IHN5c3RlbXMgdGhhdCBhcmUgaW4gYWQgaG9jLApsaW1pdGVkIHVzZSB3b3VsZG4n dCBxdWFsaWZ5LgoKQnV0IGEgc2lkZSBub3RlOiBhIGxpc3Qgb2YgOCBkaWZmZXJlbnQgcG90ZW50 aWFsIHN5c3RlbXMgaXMgbm90IGV4YWN0bHkKc2NhcnksIGdpdmVuIHdlIHRoYXQgd2UgYXJlIGF0 IHRoZSBwb2ludCBvZiBhZGRpbmcgc29tZSA3LDAwMCBuZXcgbGFuZ3VhZ2UKdGFncy4KCj4KPiA+ IE1vcmV2ZXIsIEkgd2FudCB0byBwb2ludCBvdXQgdGhhdCB0aGUgUkEgYW5kIHRoZSBKQUMgYXJl IHR3byBkaWZmZXJlbnQKPiA+IGVudGl0aWVzLCBhbmQgdGhhdCB0aGlzIHZpZXcgZG9lcyBub3Qg cmVwcmVzZW50IHRoZSB2aWV3IG9mIHRoZSBSQQo+ICh3aGljaAo+ID4gaGFzIG5vdCB0YWtlbiBh IHBvc2l0aW9uIG9uIHRoZSBpc3N1ZSkuCj4KPiBZZXAuIEkgYWdyZWUgd2l0aCB0aGF0Lgo+Cj4g LS1LZW4KPgo+ID4KPiA+IE1hcmsKPgo+Cj4K ------=_Part_87792_24637650.1164158990199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTEvMjAvMDYsIDxiIGNs YXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5LZW5uZXRoIFdoaXN0bGVyPC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtlbndAc3liYXNlLmNvbSI+a2Vud0BzeWJhc2UuY29tPC9hPiZndDsgd3JvdGU6PC9z cGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAx cHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBw YWRkaW5nLWxlZnQ6IDFleDsiPgpNYXJrLDxicj48YnI+Jmd0Ozxicj4mZ3Q7IDE1OTI0IGRvZXMg bm90IGVuY29kZSBqdXN0IHNjcmlwdHMsIGl0IGFsc28gaGFzIHZhcmlhbnRzIGFuZCBhbGlhc2Vz LCBzdWNoPGJyPiZndDsgYXM6PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy0gQ3lycywgTGF0ZiwgTGF0ZywgSGFucywgSGFudCwgU3lyZSwgU3lyaiwgU3lybjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSBIcmt0LCBKcGFuPGJyPiZndDs8YnI+Jmd0OyBUaGUg aW5jbHVzaW9uIG9mIElQQSBhcyBhIHZhcmlhbnQgc2NyaXB0IG9mIExhdGluIGlzIGxpdHRsZSBk aWZmZXJlbnQgZnJvbQo8YnI+Jmd0OyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBIYW5zIGFuZCBI YW50OyBib3RoIGFyZSBwcmltYXJpbHkgZGlmZmVyZW5jZXMgaW48YnI+Jmd0OyBzZWxlY3Rpb24g b2YgY2hhcmFjdGVycyBmcm9tIFVDUy4gVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBFbmdsaXNoIHdy aXR0ZW4gaW48YnI+Jmd0OyBJUEEgdnMgcmVndWxhciBMYXRpbiBjaGFyYWN0ZXJzIGlzIGNlcnRh aW5seSBvbiB0aGUgb3JkZXIgb2YgdGhlIGRpZmZlcmVuY2UKPGJyPiZndDsgYmV0d2VlbiBDaGlu ZXNlIHdyaXR0ZW4gaW4gSGFucyB2cyBIYW50LCBpZiBub3QgbW9yZSBzby48YnI+PGJyPlRydWUs IGJ1dCBhIHNwZWNpb3VzIGFuYWxvZ3kgbm9uZXRoZWxlc3MuPGJyPjxicj5CYXNpY2FsbHkgd2hh dCBpcyBnb2luZyBvbiBoZXJlIGlzIHRoYXQgc2NyaXB0IGNvZGVzLCBiZWNhdXNlPGJyPnRoZXkg YXJlIGF2YWlsYWJsZSBhbmQgdGllZCB0byB0aGUgbGFuZ3VhZ2UgY29kZSBhcHBhcmF0dXMsIGFy ZQo8YnI+YmVpbmcgZXh0ZW5kZWQgdG8gYXBwbHkgdG8gYW55ICZxdW90O3NpZ25pZmljYW50IHZh cmlhdGlvbiBpbiB3cml0aW5nIHN5c3RlbSZxdW90Ozxicj50aGF0IHBvcHMgdXAgdG8gdGhlIGxl dmVsIG9mICZxdW90O3dlIGNhcmUgYWJvdXQgdGhlIGRpZmZlcmVuY2UgZm9yPGJyPm91ciBpbXBs ZW1lbnRhdGlvbnMuJnF1b3Q7PGJyPjxicj5Ob3cgbWF5YmUgdGhhdCBpcyBleGFjdGx5IHdoYXQg bmVlZHMgdG8gYmUgZG9uZSwgYnV0IGluIG15IG9waW5pb24KPGJyPnRoZSByaWdodCB3YXkgdG8g aGFuZGxlIHRoaXMgaXMgdG8gZmlyc3QgKmZvcm1hbGx5KiBleHRlbmQgdGhlPGJyPnNjb3BlIG9m IDE1OTI0LCBzbyB0aGF0IGl0IG5vIGxvbmdlciBpcyBhIHN0YW5kYXJkIGZvciB0aGU8YnI+cmVn aXN0cmF0aW9uIG9mIHNjcmlwdCBjb2RlcywgYnV0IGZvciBzY3JpcHQgY29kZXMgKmFuZCo8YnI+ c2VsZWN0ZWQgb3J0aG9ncmFwaHkgY29kZXMgb2YgaW50ZXJlc3QgKmFuZCogc2VsZWN0ZWQgdmFy aWFudHMKPGJyPm9mIHdyaXRpbmcgc3lzdGVtcyBvZiBpbnRlcmVzdC4gQXQgdGhhdCBwb2ludCB0 aGUgSkFDIHdvdWxkbid0PGJyPmhhdmUgdG8gc2l0IGFuZCBhcmd1ZSBvbiBwcmluY2lwbGUgd2hl dGhlciBzb21lIHBhcnRpY3VsYXI8YnI+b2RkYmFsbCByZXF1ZXN0IGZpdHMgb3Igbm90LCBhbmQg aW1wbGVtZW50ZXJzIHdvdWxkIGJlIGZyZWVyPGJyPnRvIGFzayBmb3Igc3R1ZmYgdGhhdCBtYXRj aGVzIGRpc3RpbmN0aW9ucyB0aGV5IHdvdWxkIGxpa2UgdG8KPGJyPm1ha2UuPGJyPjxicj5BcyBp dCBpcywgaXQgaXMgYmFkIGVub3VnaCB0aGF0IHdlIGhhdmUgYSAmcXVvdDtzY3JpcHQmcXVvdDsg cmVnaXN0cmF0aW9uPGJyPnN0YW5kYXJkIHRoYXQgdHJpZXMgdG8gbWF0Y2ggdXAgYWdhaW5zdCB0 aGUgJnF1b3Q7c2NyaXB0cyZxdW90OyBlbmNvZGVkPGJyPmluIFVuaWNvZGUsIGFuZCBoYXMgYSBt b3N0bHkgdW5leHBsYWluZWQgaGFpcmJhbGwgb2Ygc3R1ZmYKPGJyPndoaWNoIGNhbid0IGJlIG1h dGNoZWQgdXAsIGJ1dCBub3cgcmVxdWVzdHMgdG8gcmVnaXN0ZXIgc3R1ZmYgbGlrZTxicj5JUEEg Zm9yIGEgc2NyaXB0IGNvZGUga2VlcCBwdXNoaW5nIHRoaW5ncyBmdXJ0aGVyIHRoYXQgd2F5Ljwv YmxvY2txdW90ZT48ZGl2Pjxicj5JIGRvbid0IHJlYWxseSBzZWUgdGhlIG5lY2Vzc2l0eSBmb3Ig YSBjaGFydGVyIGNoYW5nZTsgaW4gcGFydGljdWxhciwgSSBkb24ndCBzZWUgYW55dGhpbmcgaW4g CjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pY29kZS5vcmcvaXNvMTU5MjQvc3RhbmRhcmQvaW5kZXgu aHRtbCI+aHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNC9zdGFuZGFyZC9pbmRleC5odG1s PC9hPiB0aGF0IHdvdWxkIHNheSB0aGF0IEhhbnQgaXMgYSB2YWxpZCBzY3JpcHQgdmFyaWFudCwg YW5kIElQQSBpcyBub3QuIE1heWJlIEknbSBub3QgbG9va2luZyBpbiB0aGUgcmlnaHQgYXJlYSwg c28gYW55IGhlbHAgd291bGQgYmUgYXBwcmVjaWF0ZWQuCjxicj48L2Rpdj48YnI+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2Io MjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDog MWV4OyI+Jmd0OyBJdCB3b3VsZCBiZSBvZjxicj4mZ3Q7IGdyZWF0IGJlbmVmaXQgdG8gdXNlcnMg b2YgSVBBIHRvIGJlIGFibGUgdG8gdGFnIGRhdGEgd2l0aCBhIHZhcmlhbnQgc2NyaXB0Cjxicj4m Z3Q7IGNvZGUsIGFuZCBsaXR0bGUgcHJhZ21hdGljIHJlYXNvbiBub3QgdG8gYWxsb3cgdGhhdCwg ZXNwZWNpYWxseSBpbiB2aWV3IG9mPGJyPiZndDsgdGhlIGZhY3QgdGhhdCB0aGUgc3RhbmRhcmQg aGFzIGFscmVhZHkgYmVlbiBzdHJldGNoZWQgdG8gaW5jbHVkZSB2YXJpYW50czxicj4mZ3Q7IGFu ZCBhbGlhc2VzLjxicj48YnI+RHVubm8gd2hhdCBhbGlhc2VzIGhhdmUgdG8gZG8gd2l0aCBpdCwg b3RoZXIgdGhhbiB0byBwdWZmIHVwIHRoZQo8YnI+YXJndW1lbnQuPC9ibG9ja3F1b3RlPjxkaXY+ PGJyPldoYXQgdGhleSBoYXZlIHRvIGRvIHdpdGggaXQgaXMgdGhhdCAxNTkyNCBpcyBhbHJlYWR5 IG5vdCAmcXVvdDtwdXJlJnF1b3Q7OiBKcGFuIGlzIG5vdCB0aGUgbmFtZSBvZiAmcXVvdDthJnF1 b3Q7IHNjcmlwdC48YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpBbmQgSVBBIGlzIG5vdCBh IHZhcmlhbnQgc2NyaXB0LiBJdCBpcyBub3QgY29tcGFyYWJsZSB0byBMYXRmIGFuZCBMYXRnLjxi cj5JdCBpcyBhIGNpcmN1bXNjcmliZWQsIHRlY2huaWNhbCB1c2Ugb2YgTGF0bi4gPC9ibG9ja3F1 b3RlPjxkaXY+Jm5ic3A7PGJyPjwvZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KJnF1b3Q7Y2F0JnF1 b3Q7IGlzIEVuZ2xpc2guPGJyPiZxdW90O1tjYXRdJnF1b3Q7IGlzIElQQS4gVGVsbCBtZSB0aGUg c2NyaXB0IGRpZmZlcmVuY2UsIGV4Y2VwdCBpbiBmdW5jdGlvbi48L2Jsb2NrcXVvdGU+PGRpdj48 YnI+PHNwYW4+bXV0YXRpcyBtdXRhbmRpczogJnF1b3Q75LiA5LqM5LiJJnF1b3Q7IGlzIEhhbnQs IGFuZCA8L3NwYW4+PHNwYW4+JnF1b3Q75LiA5LqM5LiJJnF1b3Q7IGlzIEhhbnMuIDwvc3Bhbj4K VGVsbCBtZSB0aGUgc2NyaXB0IGRpZmZlcmVuY2UsIGV4Y2VwdCBpbiBmdW5jdGlvbi48L2Rpdj48 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFw eCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBh ZGRpbmctbGVmdDogMWV4OyI+U28gYXMgaW4gdGhlIGNhc2Ugb2YgSGFudCB2ZXJzdXMgSGFucywg cmVnaXN0ZXJpbmcgSVBBIHdpdGggYQo8YnI+c2NyaXB0IGNvZGUgd291bGQgYmUgYW5vdGhlciBh ZCBob2MgZXh0ZW5zaW9uIG9mIDE1OTI0IGluIGFuPGJyPm9ydGhvZ29uYWwgYnV0IGJhc2ljYWxs eSB1bmV4cGxhaW5lZCBkaXJlY3Rpb24uPC9ibG9ja3F1b3RlPjxkaXY+PGJyPllvdSBzZWVtIHRv IHNlZSB0aGlzIGFzIGEgc2xpcHBlcnkgc2xvcGU7IHRha2UgdGhhdCBvbmUgZHJpbmssIGFuZCB0 aGVyZSBpcyBhbiBpbmV2aXRhYmxlIHBhdGggdG8gbHlpbmcgaW4gdGhlIGd1dHRlciB3aXRoIGEg Ym90dGxlIG9mIFJpcHBsZSBpbiBhIGJyb3duIHBhcGVyIGJhZy4gSSBzZWUgaXQgYXMgZm9sbG93 aW5nIHRoZSBwcmVjZWRlbnQgYWxyZWFkeSBzZXQgd2l0aCBIYW5zL0hhbnQsIGFuZCBwcm92aWRp bmcgYSByZWFzb25hYmxlLCBwcmFnbWF0aWMgc29sdXRpb24gZm9yIGxhbmd1YWdlIHRhZ3MuIEkg ZG9uJ3Qgc2VlIGFueW9uZSB3YW50aW5nIHRvIHVzZSBzY3JpcHQgY29kZXMgZm9yIHNtYWxsZXIg b3J0aG9ncmFwaGljIGRpc3RpbmN0aW9ucywgc3VjaCBhcyBiZXR3ZWVuICZxdW90O3RoZWF0cmUm cXVvdDsgYW5kICZxdW90O3RoZWF0ZXImcXVvdDs7IGxhbmd1YWdlIHRhZ3MgY2FuIGFscmVhZHkg ZW5jb21wYXNzIHN1Y2ggZGlmZmVyZW5jZXMuCjxzcGFuIHRpdGxlPSJJUEEiIGxhbmc9ImVuIj48 L3NwYW4+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJv cmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQg MHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPlRoZSBwcmFnbWF0aWMgcmVhc29uIG5vdCB0 byBhbGxvdyB0aGF0IGlzIHRvIHByZXZlbnQgMTU5MjQgYmVpbmcKPGJyPnVzZWQgdG8gZnVydGhl ciBtdWRkeSBhbGwgdGhlIGRpbWVuc2lvbnMgb2YgZGlzdGluY3Rpb25zIGluPGJyPndyaXRpbmcg c3lzdGVtcy48YnI+PGJyPkJ1dCB0aGUgcHJhZ21hdGljIHJlYXNvbiB0byAqYWxsb3cqIGl0IHdv dWxkIGJlIHRvIGxldCBHb29nbGU8YnI+YW5kIE1pY3Jvc29mdCBkbyB3aGF0IHRoZXkgd2FudCB0 byBkbyBmb3Igc2VhcmNoZXMgYW55d2F5LCBhbmQ8YnI+CnRvIGhlbGwgd2l0aCBleHBlY3Rpbmcg MTU5MjQgdG8gbWFrZSBhbnkgc2Vuc2Ugb3V0c2lkZSBpdHM8YnI+dXNlIGFzIGEgc3RhbmRhcmQg Zm9yIGxhYmVsaW5nICZxdW90O3dyaXR0ZW4gc3R1ZmYgd2Ugd2FudCB0byBkaXN0aW5ndWlzaCZx dW90Oy48L2Jsb2NrcXVvdGU+PGRpdj48YnI+VGhlIHBvbGl0aWNhbCBzZWFzb24gaXMgb3Zlciwg YW5kIEkgc2VlIG5vIG5lZWQgdG8gZ2V0IGludG8gYWQgaG9taW5lbSBhdHRhY2tzLiBHb29nbGUg aGFzLCB0byBteSBrbm93bGVkZ2UsIG5vIHBhcnRpY3VsYXIgc3Rha2UgaW4gdGhpcyBpc3N1ZSAt LSBJIGRvbid0IGtub3cgdGhhdCBNUyBkb2VzIGVpdGhlci4gVGhpcyBpcyByZWFsbHkganVzdCBh IHRlY2huaWNhbCBpc3N1ZSBvZiBob3cgdG8gYmVzdCB1c2Ugc2NyaXB0IHZhbHVlcyBpbiB0aGUg bGFuZ3VhZ2UgdGFnIG1lY2hhbmlzbSBtb3N0IGVmZmVjdGl2ZWx5LiBMYW5ndWFnZSB0YWdzIGFy ZSBhIGJpZyBjdXN0b21lciBmb3IgSVNPIDE1OTI0LCBhbmQgaXQgd291bGQgc2VlbSByZWFzb25h YmxlIHRvIGF0IGxlYXN0IGNvbnNpZGVyIHRoZSBpc3N1ZSBmcm9tIGFsbCBzaWRlcy4KPGJyPjwv ZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVm dDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhl eDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4mZ3Q7ICZndDsmZ3Q7IFRoaXMgaXMgbm90IG15IHZpZXcg b25seS4gSXQgd2FzIHRoZSB2aWV3IG9mIHRoZSBSQS48YnI+Jmd0Ozxicj4KJmd0OyBSZWdhcmRp bmcgdGhlIGFib3ZlIHN0YXRlbWVudCwgSSBhbHNvIHdhbnQgdG8gYWRkIHRoYXQgYXMgZmFyIGFz IEkgY2FuIHRlbGwsPGJyPiZndDsgdGhlIDE1OTI0IEpBQyBkaWQgbm90IGNvbnNpZGVyIHRoaXMg dG9waWMgaW4gYW55IGRlcHRoLCBub3IgZG9lcyBhbnkgb2YgdGhlPGJyPiZndDsgZGlzY3Vzc2lv biBoZXJlIHNlZW0gdG8gYmUgZm9yd2FyZGVkIHRvIHRoZSBKQUMgZm9yIHRoZWlyIGNvbnNpZGVy YXRpb247IEkKPGJyPiZndDsgYmVsaWV2ZSB0aGF0IHRoZSBtZW1iZXJzIGFyZSB1bmF3YXJlIG9m IHRoZSBpc3N1ZXMgcmFpc2VkIHJlZ2FyZGluZyBsYW5ndWFnZTxicj4mZ3Q7IHRhZ3MuIEFzIGZh ciBhcyBJIGNvdWxkIHNlZSBmcm9tIGVtYWlsLCB0aGUgc3VtIHRvdGFsIG9mIHRoZSBkaXNjdXNz aW9uIHdhczxicj4mZ3Q7IHRocmVlIHN0YXRlbWVudHMsIHR3byBieSB0aGUgc2FtZSBwZXJzb246 PGJyPgomZ3Q7PGJyPiZndDsgQTogJnF1b3Q7QXMgZmFyIGFzIEkgY2FuIHNlZSwgSVBBIGlzIGp1 c3QgYSBzZXQgb2YgTGF0aW4gY2hhcmFjdGVycy4mcXVvdDs8YnI+Jmd0OyBBOiAmcXVvdDtUaGUg SVBBIGlzIGEgc2V0IG9mIExhdGluIGxldHRlcnMsIGFuZCBjYW4gYmUgcmVwcmVzZW50ZWQgYnkg TGF0bi4gSXQgaXM8YnI+Jmd0OyBhbiBvcnRob2dyYXBoeSBvZiBMYXRpbiwgbm90IGEgc2NyaXB0 IG9mIGl0cyBvd24uJnF1b3Q7Cjxicj4mZ3Q7IEM6ICZxdW90O0kgY29uY3VyIHdpdGggdGhpcyBj b25jbHVzaW9uLiZxdW90Ozxicj4mZ3Q7IFtuYW1lcyByZW1vdmVkIHRvIHByb3RlY3QgdGhlIGlu bm9jZW50XTxicj48YnI+WWVhaCwgeWVhaCwgY3V0ZSwgTWFyay4gTm90ZSBhbHNvIHRoYXQgTWlj aGFlbCBhbmQgSSwgYXQgbGVhc3QsPGJyPndlcmUgdHJhaW5lZCBpbiBJUEEgKGFuZCBvdGhlciBw aG9uZXRpYyBvcnRob2dyYXBoaWVzKSBhbmQKPGJyPm1hZGUgc2lnbmlmaWNhbnQgcHJvZmVzc2lv bmFsIHVzZSBvZiB0aGVtLiBTbyBpdCBpc24ndCBhczxicj5pZiB3ZSBhcmUgYmFiZXMgaW4gdGhl IHdvb2RzIGhlcmUgcHJlc2VudGVkIHdpdGggc29tZXRoaW5nPGJyPndlJ3ZlIG5ldmVyIGhlYXJk IG9mIGJlZm9yZSwgYW5kIGFyZSBtYWtpbmcgb2ZmLXRoZS1jdWZmLCB1bmluZm9ybWVkPGJyPnJl bWFya3MgYWJvdXQuPGJyPjxicj4KSWYgeW91IGZlZWwgdGhhdCBhIHJlZ2lzdHJhdGlvbiBmb3Ig SVBBIGJlbG9uZ3MgaW4gMTU5MjQsIHRoZW48YnI+bWFrZSB0aGUgY2FzZSB3aHkgMTU5MjQgc2hv dWxkIHN0YXJ0IHJlZ2lzdGVyaW5nIG9ydGhvZ3JhcGhpYzxicj5jb252ZW50aW9ucyBmb3IgdGhl IHVzZSBvZiBhIHNjcmlwdCwgaW5zdGVhZCBvZiBqdXN0IGtub2NraW5nPGJyPnRoZSBKQUMgZm9y ICZxdW90O25vdCBjb25zaWRlcltpbmddIHRoaXMgdG9waWMgaW4gYW55IGRlcHRoLCZxdW90OyBw bGVhc2UuCjwvYmxvY2txdW90ZT48ZGl2Pjxicj5JIHRoaW5rIEkgbWlnaHQgbm90IGhhdmUgYmVl biBjbGVhci4gV2hpbGUgdGhlcmUgbWF5IGJlIGdvb2QgcmVhc29ucyBmb3Igd2h5IElQQSBkb2Vz bid0IHF1YWxpZnksIGFuZCB5ZXQgSGFucyAmYW1wOyBIYW50IHF1YWxpZnksIGJ1dCB0aGUgSkFD IGRpZCBub3QgbWFrZSB0aGUgcmF0aW9uYWxlIGNsZWFyLiBXaGlsZSB0aGUgZGlmZmVyZW5jZSBt YXkgYmUgYmxpbmRpbmdseSBvYnZpb3VzIHRvIHlvdSwgaXQgd291bGQgYmUgaGVscGZ1bCB0byBo ZWFyIHdoYXQgaXQgYWN0dWFsbHkgaXMsIG1vcmUgdGhhbiBhbiAmcXVvdDtJIGNvbmN1ciZxdW90 Oy4KPGJyPjwvZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5BbHNvLCBJIHN1Z2dlc3QgeW91IGNvbnNp ZGVyIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSBmdW5jdGlvbjxicj5vZiBJUEEgYXMgYSBi aWJsaW9ncmFwaGljIGNvZGUgYW5kIGFzIGEgJnF1b3Q7bGFuZ3VhZ2UmcXVvdDsgY29kZS4gVGhl cmUKPGJyPmFyZSB2ZXJ5LCB2ZXJ5IGZldyBib29rcywgYXJ0aWNsZXMsIG9yIGFueXRoaW5nIGVs c2UgdGhhdCBjb25zaXN0PGJyPmV4Y2x1c2l2ZWx5IG9yIHByaW1hcmlseSBvZiBJUEEgdXNlZCBq dXN0IHRvIHJlcHJlc2VudCB0ZXh0LiBNb3N0PGJyPm9mIHRoZSBvbmVzIHRoYXQgZG8gZXhpc3Qg YXJlIGV4cGVyaW1lbnRhbCBmYWlsdXJlcywgYmFzaWNhbGx5Ljxicj5JdCB3b3VsZCBiZSB2ZXJ5 IHJhcmUgdGhhdCB5b3Ugd291bGQgbmVlZCBhIGJpYmxpb2dyYXBoaWMgY29kZQo8YnI+Zm9yIGEg Ym9vayAqaW4qIElQQSwgYXMgb3Bwb3NlZCB0byBhIGJvb2sgKmFib3V0KiBJUEEgb3IgaW5jbHVk aW5nPGJyPnVzZSAqb2YqIElQQS4gT24gdGhlIG90aGVyIGhhbmQsIGl0IGlzIHV0dGVybHkgbm9y bWFsIGZvcjxicj5JUEEgdG8gYmUgdXNlZCBleHRlbnNpdmVseSBlbWJlZGRlZCBpbiB0aGUgbWlk ZGxlIG9mIG90aGVyd2lzZTxicj5ub3JtYWwgTGF0aW4gdGV4dCAob3IsIHRvIGJlIHN1cmUsIGFz IGNpdGF0aW9ucyB1c2VkIGluIHRoZQo8YnI+bWlkZGxlIG9mIEN5cmlsbGljIG9yIEphcGFuZXNl IG9yIENoaW5lc2Ugb3Igd2hhdGV2ZXIgb3RoZXI8YnI+dGV4dCkuIElmIHlvdSBlbWJlZCBhIGJ1 bmNoIG9mIElQQSBpbiB0aGUgbWlkZGxlIG9mIG90aGVyd2lzZTxicj51bnJlbWFya2FibGUgTGF0 aW4gdGV4dCwgeW91IHJlYWxseSBhcmVuJ3QgdGFsa2luZyBhYm91dCBhPGJyPmJpYmxpb2dyYXBo aWMgY29kZSBhdCBhbGwsIGJ1dCB0YWdnaW5nIHJ1bnMgb2YgdGV4dCBhcyBiZWluZwo8YnI+aW4g YSBzcGVjaWFsIGZ1bmN0aW9uIG9ydGhvZ3JhcGh5LiBJZiB0aGF0J3Mgd2hhdCB5b3UgbmVlZCB0 bzxicj5tYWtlIHRleHQgc2VhcmNoZXMgd29yayByaWdodCBmb3IgaW50ZXJwcmV0aW5nIHN1Y2gg cnVucyBvZjxicj5zcGVjaWFsaXplZCB0ZXh0LCB0aGVuIG1ha2UgdGhlIGNhc2UgZm9yIGl0Ljwv YmxvY2txdW90ZT48ZGl2Pjxicj5JIGRvbid0IHRoaW5rIGFueW9uZSBpcyBleHBlY3RpbmcgYm9v a3MgaW4gSVBBIC0tIGl0IHdvdWxkIGJlLCBhcyB5b3Ugc2F5LCB0YWdnZWQgZnJhZ21lbnRzLgo8 YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPkJ1dCB0aGUgZmFjdCBpcyB0aGF0IG9uY2UgeW91 IGdldCBiZXlvbmQgc3RhbmRhcmQgd3JpdGluZyBzeXN0ZW1zPGJyPndpdGggc3RhbmRhcmRpemVk IHNwZWxsaW5ncyBhbmQgc3RhcnQgaGl0dGluZyB0aGUgdGV4dCBjb3JwdXNlcwo8YnI+b2Ygc3Bl Y2lhbGl6ZWQgbGFuZ3VhZ2VzIGluIHNwZWNpYWxpemVkIG9ydGhvZ3JhcGhpZXMgd2hpY2ggYXJl PGJyPmluY3JlYXNpbmdseSBsaWtlbHkgdG8gZ2V0IG9wZW5seSBwb3N0ZWQgb24gdGhlIHdlYiwg eW91PGJyPmFyZSBnb2luZyB0byBuZWVkIGEgY29kZSBmb3IgKmVhY2gqIG9ydGhvZ3JhcGh5IGlu IHVzZSwgcGVyIGxhbmd1YWdlLDxicj50byBtYWtlIGFueSBzZW5zZSBvZiB0aGUgY29udGVudCBv ZiB0aG9zZSBjb3JwdXNlcy4KPGJyPjxicj5TYXkgSSB3ZXJlIHRvIHN0YXJ0IHBvc3RpbmcgQ2h1 bWFzaCBsYW5ndWFnZSBtYXRlcmlhbHMgb24gdGhlPGJyPndlYiBpbiBVbmljb2RlLiAoVGhlcmUg YXJlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGxpbmd1aXN0cyw8YnI+Q2h1bWFzaCBkZXNjZW5k YW50cywgYW50aHJvcG9sb2dpc3RzLCBhbmQganVzdCBwbGFpbiBDaHVtYXNoPGJyPmFmZmljaW9u YWRvcyBhbW9uZyB0aGUgZ2VuZXJhbCB3aGl0ZSBwb3B1bGF0aW9uIGluIFNhbnRhIEJhcmJhcmEK PGJyPmFuZCBWZW50dXJhIGNvdW50aWVzIHdobyB3b3VsZCBsaWtlIHRoYXQsIGJ5IHRoZSB3YXku KSBUbzxicj5zZWFyY2ggdGhhdCBtYXRlcmlhbCwgYW5kIGp1c3Qgc3RpY2tpbmcgdG8gdGhlIEJh cmJhcmVubzxicj52ZXJzaW9uIG9mIENodW1hc2gsIHlvdSB3b3VsZCBuZWVkIGF0IGxlYXN0Ojxi cj48YnI+Q2h1bWFzaC1CYXJiYXJlbm8gaW4gSVBBPGJyPkNodW1hc2gtQmFyYmFyZW5vIGluIEpQ SGFycmluZ3RvbiBvcnRob2dyYXBoeSAoYSBtYXNzaXZlIGNvcnB1cykKPGJyPkNodW1hc2gtQmFy YmFyZW5vIGluIEFtZXJpY2FuaXN0IG9ydGhvZ3JhcGh5PGJyPkNodW1hc2gtQmFyYmFyZW5vIGlu IEFwcGxlZ2F0ZSBwcmFjdGljYWwgb3J0aG9ncmFwaHkgKHVzZWQgYnkgc29tZTxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYW50aHJvcG9sb2dpc3RzIGFuZCBhIGxvdCBvZiBtYXRlcmlhbCk8YnI+Q2h1 bWFzaC1CYXJiYXJlbm8gaW4gV2hpc3RsZXIgcHJhY3RpY2FsIG9ydGhvZ3JhcGh5Cjxicj5DaHVt YXNoLUJhcmJhcmVubyBpbiBDaHVtYXNoIG5hdGlvbiBvcnRob2dyYXBoeTxicj48YnI+QmVjYXVz ZSB0ZXh0cyBhcmUgc3BlbGxlZCBzeXN0ZW1hdGljYWxseSBkaWZmZXJlbnRseSBpbiBlYWNoIG9m PGJyPnRob3NlIHN5c3RlbXMgYW5kIHVzZSBzb21ld2hhdCBkaWZmZXJlbnQgcmVwZXJ0b2lyZXMg b2YgY2hhcmFjdGVycy48YnI+PGJyPlNvIG1ha2UgeW91ciBjYXNlIHdoeSBJUEEgaXMgc3BlY2lh bC4gKEZvciBDaHVtYXNoLCBpdCB3b3VsZCwKPGJyPmZvciBleGFtcGxlLCBiZSBvZiB2ZXJ5IGxp dHRsZSByZWFsIHZhbHVlLCBiZWNhdXNlIHZlcnkgbGl0dGxlPGJyPm9mIHRoZSBDaHVtYXNoIGRh dGEgaXMgcmVwcmVzZW50ZWQgZGlyZWN0bHkgaW4gSVBBLikgV2hlcmUgZG88YnI+eW91IGRyYXcg dGhlIGxpbmUgaW4gcmVnaXN0ZXJpbmcgdGhlc2UgdGhpbmc/PGJyPjxicj5PciBkbyB5b3UgdGhp bmsgcmVnaXN0ZXJpbmcgSVBBIGp1c3Qgc29sdmVzIHNvbWUgcHJvYmxlbSB0aGF0Cjxicj53b24n dCBjb21lIGFyb3VuZCBhZ2FpbiBmb3IgdGhlIG5leHQgdGVjaG5pY2FsIG9ydGhvZ3JhcGh5PGJy PnRoYXQgY29tZXMgZG93biB0aGUgcGlrZT88L2Jsb2NrcXVvdGU+PGRpdj48YnI+Tm8sIEkgdGhp bmsgZXZlcnlvbmUgaXMgYXdhcmUgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgc3lzdGVtcyBvZiBw aG9uZXRpYyByZXByZXNlbnRhdGlvbnMuIFNvIElQQSB3b3VsZCBsaWtlbHkgYmUgdGhlIGZpcnN0 IG9mIHNldmVyYWwuIEJ1dCBpdCBpcyBjbGVhcmx5IGEgcmVsYXRpdmVseSBpbXBvcnRhbnQgb25l LCBiZWluZyBpbiBwcmV0dHkgd2lkZXNwcmVhZCB1c2UgaW4gZGljdGlvbmFyaWVzIGFuZCBvdGhl ciBzb3VyY2VzLiBBcyB3aXRoIGVuY29kaW5nIGNoYXJhY3RlcnMsIG9yIHNjcmlwdCB2YXJpYW50 cywgYXQgc29tZSBwb2ludCB5b3UgaGF2ZSB0byBtYWtlIGp1ZGdtZW50cyBhcyB0byB3aGV0aGVy IGEgc3lzdGVtIGlzIGluIHdpZGUgZW5vdWdoIHVzYWdlIHRvIGJlIHdvcnRoIGVuY29kaW5nOyBz eXN0ZW1zIHRoYXQgYXJlIGluIGFkIGhvYywgbGltaXRlZCB1c2Ugd291bGRuJ3QgcXVhbGlmeS4K PGJyPjxicj5CdXQgYSBzaWRlIG5vdGU6IGEgbGlzdCBvZiA4IGRpZmZlcmVudCBwb3RlbnRpYWwg c3lzdGVtcyBpcyBub3QgZXhhY3RseSBzY2FyeSwgZ2l2ZW4gd2UgdGhhdCB3ZSBhcmUgYXQgdGhl IHBvaW50IG9mIGFkZGluZyBzb21lIDcsMDAwIG5ldyBsYW5ndWFnZSB0YWdzLiA8YnI+PC9kaXY+ PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAx cHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBw YWRkaW5nLWxlZnQ6IDFleDsiPgomZ3Q7PGJyPiZndDsgTW9yZXZlciwgSSB3YW50IHRvIHBvaW50 IG91dCB0aGF0IHRoZSBSQSBhbmQgdGhlIEpBQyBhcmUgdHdvIGRpZmZlcmVudDxicj4mZ3Q7IGVu dGl0aWVzLCBhbmQgdGhhdCB0aGlzIHZpZXcgZG9lcyBub3QgcmVwcmVzZW50IHRoZSB2aWV3IG9m IHRoZSBSQSAod2hpY2g8YnI+Jmd0OyBoYXMgbm90IHRha2VuIGEgcG9zaXRpb24gb24gdGhlIGlz c3VlKS48YnI+PGJyPgpZZXAuIEkgYWdyZWUgd2l0aCB0aGF0Ljxicj48YnI+LS1LZW48YnI+PGJy PiZndDs8YnI+Jmd0OyBNYXJrPGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_87792_24637650.1164158990199-- --===============1540444106== 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 --===============1540444106==-- From ltru-bounces@ietf.org Tue Nov 21 20:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmgzK-0002Zy-IP; Tue, 21 Nov 2006 20:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmgzJ-0002Z1-De for ltru@lists.ietf.org; Tue, 21 Nov 2006 20:33:21 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmgzI-00060x-6S for ltru@lists.ietf.org; Tue, 21 Nov 2006 20:33:21 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GmgzH-0006aN-SF; Tue, 21 Nov 2006 20:33:19 -0500 Date: Tue, 21 Nov 2006 20:33:19 -0500 To: Peter Constable Subject: Re: [Ltru] Re: LTRU progress and ISO 639-6 Message-ID: <20061122013319.GB8141@ccil.org> References: <20061120023556.GC24285@ccil.org> <19A328037921AA42847A717566D1D6A109A13422@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19A328037921AA42847A717566D1D6A109A13422@RED-MSG-42.redmond.corp.microsoft.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > In my mind, this raises the question of what use having "napl" in 639-6 > is anyway? It has the same semantics as "nap-Latn" and I don't see > a point in having a metadata element to denote a semantic for which > we already have an existing metadata element unless someone has a > syntactic requirement -- their metadata elements must all be alpha4 -- > but I see no indication of anyone having such a requirement. This is off-topic, but the theory of 639-6 is that there is a single flat code space (mostly 4-alpha, but 3-alpha where a code element has the same semantics as one from the 639-2/3/5 code space) for everything from phyla to varieties, with a straightforward tree structure superimposed. The identifiers are invariant, but the tree structure is subject to change. The closest analogue is the Linnaean tree, if we treat binomial species and trinomial subspecies names as single identifiers; however, Linnaean identifiers are not even close to fixed-length. I agree that there is no point in allowing 'napl' into BCP 47 codespace, since it does indeed mean the same as 'nap-Latn'. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 22:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmiiM-0002o2-PD; Tue, 21 Nov 2006 22:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmiiK-0002mP-V6 for ltru@ietf.org; Tue, 21 Nov 2006 22:23:56 -0500 Received: from smtp2.wsfo.org ([208.145.81.51] helo=smtp1.wsfo.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmiiH-0000Wi-CB for ltru@ietf.org; Tue, 21 Nov 2006 22:23:56 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id kAM3NaTW015006 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Nov 2006 22:23:36 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.134.201] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 129059621; Tue, 21 Nov 2006 22:23:35 -0500 Message-ID: <4563C2B2.9010209@sil.org> Date: Wed, 22 Nov 2006 10:23:30 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies References: <200611210150.kAL1oWT14470@birdie.sybase.com> <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> In-Reply-To: <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, LTRU Working Group , Kenneth Whistler X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, > Say I were to start posting Chumash language materials on the > web in Unicode. (There are a significant number of linguists, > Chumash descendants, anthropologists, and just plain Chumash > afficionados among the general white population in Santa Barbara > and Ventura counties who would like that, by the way.) To > search that material, and just sticking to the Barbareno > version of Chumash, you would need at least: > > Chumash-Barbareno in IPA > IPA is a script/transcription system that is used for multiple languages even more than Roman script. I.e. a reader of IPA can do a pretty good job of sounding out text in a language written using it, that they do not know. > Chumash-Barbareno in JPHarrington orthography (a massive corpus) > I know nothing about this orthography. But whether it is phonetic or phonemic, I would suggest that it is limited to this and perhaps a few other languages. Therefore allocating a per language extension for this orthography seems sensible. > Chumash-Barbareno in Americanist orthography > Americanist is like the IPA to a limited extent, in that it is used to write multiple languages and can be read by users who have no knowledge of the language. > Chumash-Barbareno in Applegate practical orthography (used by some > anthropologists and a lot of material) > This is a language specific orthography and should be registered as an script extension of that one language > > Chumash-Barbareno in Whistler practical orthography > Chumash-Barbareno in Chumash nation orthography > Likewise for these two. I posit, therefore that there are two kinds of transcription system that have to be dealt with. Those that are designed to handle a single language or small group of languages and those that are designed to represent the sounds of any language. Those transcription systems designed for a single language can be tagged adequately within the existing system by allocating a language extension. Those that are designed to be universal (or near universal) transcription systems (of which I only know of IPA and Americanist, are there others?) are not best served by a model that only allows for per language extensions. These universal systems are scripts/script variants, call them what you will. I don't really mind where one draws the line, but I do want to know how to tag stuff that has been written using them. Please help. As SIL starts to get its act together in this area, we would really value your input on how you want us to tag our data. The danger I fear is that the need to tag will precede the knowledge of how to tag and people will just make things up and we'll have a retagging nightmare on our hands. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 22:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmj6o-0001kR-3u; Tue, 21 Nov 2006 22:49:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmj6m-0001kI-M7 for ltru@ietf.org; Tue, 21 Nov 2006 22:49:12 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmj6l-0007x1-AQ for ltru@ietf.org; Tue, 21 Nov 2006 22:49:12 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AR1LY8YbHUHdxbDSsYUuZEtPE/Tv+046eICzJC0XMNtmxsEDEE7M/aznp9LrB/js; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.12] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gmj6k-00006R-Ji for ltru@ietf.org; Tue, 21 Nov 2006 22:49:10 -0500 Message-ID: <000401c70de9$4bfa89c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <200611210150.kAL1oWT14470@birdie.sybase.com><30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> <4563C2B2.9010209@sil.org> Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Date: Tue, 21 Nov 2006 19:50:04 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6bcd741a2f58259a053328867e5f729d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.12 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Martin Hosken" > To: "Mark Davis" > Cc: ; ; "LTRU Working Group" ; "Kenneth Whistler" > Sent: Tuesday, November 21, 2006 7:23 PM > Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies ... > I posit, therefore that there are two kinds of transcription system that > have to be dealt with. Those that are designed to handle a single > language or small group of languages and those that are designed to > represent the sounds of any language. Those transcription systems > designed for a single language can be tagged adequately within the > existing system by allocating a language extension. Those that are > designed to be universal (or near universal) transcription systems (of > which I only know of IPA and Americanist, are there others?) are not > best served by a model that only allows for per language extensions. Agreed, but I think the argument can be taken a bit further. As discussed earlier on this list, within, for example, the Americanist tradition(s), there may be a number of specific ways in which that set of symbols is used to transcribe data. If one is not conversant in the specific language being transcribed, one might recognize that material is a transcription from the symbols used, but not recognize, for example, that specifically the Trager-Smith conventions were employed in the use of those symbols. > These universal systems are scripts/script variants, call them what you > will. I don't really mind where one draws the line, but I do want to > know how to tag stuff that has been written using them. Please help. As > SIL starts to get its act together in this area, we would really value > your input on how you want us to tag our data. The danger I fear is that > the need to tag will precede the knowledge of how to tag and people will > just make things up and we'll have a retagging nightmare on our hands. ... One possibility would be to have something that would roughly look like -- We can observe that a "TranscriptionOrthography" is always specific to a particular combination of Language and TranscriptionScript, with one exception. This makes possible a less optimal structure of - This would work, but its behaviour for searching / matching would be a bit awkward due to that exception: we'd need a generic subtag to represent "we know it's a (IPA) transcription but don't know specifically which conventions are in use" for cataloging purposes. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 21 23:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmk3s-0003UK-5J; Tue, 21 Nov 2006 23:50:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmk3q-0003R9-GI for ltru@ietf.org; Tue, 21 Nov 2006 23:50:14 -0500 Received: from maila.microsoft.com ([205.248.106.64] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmk3n-00013W-6z for ltru@ietf.org; Tue, 21 Nov 2006 23:50:14 -0500 Received: from mailout4.microsoft.com (157.57.217.12) by SVC-EXGWY-E801.partners.extranet.microsoft.com (10.251.24.242) with Microsoft SMTP Server id 8.0.685.15; Tue, 21 Nov 2006 20:50:10 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 20:50:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] ISO/FDIS 639-3 tables revised Date: Tue, 21 Nov 2006 20:41:04 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A13582@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <003201c70d7b$6fcb6e50$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] ISO/FDIS 639-3 tables revised Thread-Index: AccNe4GM2vLy1NYFTHiaCy7uY4r3ZQAc/+1Q From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 22 Nov 2006 04:50:07.0975 (UTC) FILETIME=[AF202F70:01C70DF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Doug Ewell [mailto:dewell@adelphia.net]=20 >> Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving),=20 >> S(pecial). This would be very useful information for identification,=20 >> and I suggest we add it as a Language-Type field > > This field should also be able to hold the value=20 > "Collection"=20 In terms of the attributes on entries defined in ISO 639-3, this would be mixing values for two distinct attributes: type (living, etc.) and scope (individual language, macrolanguage, collection). The type attribute applied to collections would more-appropriately have values such as "genetic" or "geographic" according to how the collection is defined. >> Scope: we don't need to add this, since it can be derived: something=20 >> is a macro language iff there is an extlang that points to it. > > I agree.=20 Well, note that right now you don't have a certain way to tell which entities have a collection scope. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 01:31:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmldl-0002ZP-1h; Wed, 22 Nov 2006 01:31:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmldj-0002WA-JG for ltru@ietf.org; Wed, 22 Nov 2006 01:31:23 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmldh-0000uo-AA for ltru@ietf.org; Wed, 22 Nov 2006 01:31:23 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061122063116.QSVR23051.mta10.adelphia.net@DGBP7M81> for ; Wed, 22 Nov 2006 01:31:16 -0500 Message-ID: <005b01c70dff$d1920de0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 21 Nov 2006 22:31:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: ISO 11179 conformance and a new draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen underscore Broome at spe dot sony dot com wrote: > Did we ever come to any final decisions on the "great script debate" > thread with respect to indicating that scripts aren't relevant for > audio language tagging? I don't remember what the goal was. Did you want a statement added to 4646bis stating that non-written content shouldn't be tagged with a script subtag? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 03:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnkE-0005w7-24; Wed, 22 Nov 2006 03:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnkC-0005vf-9x for ltru@lists.ietf.org; Wed, 22 Nov 2006 03:46:12 -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 1Gmnk9-0005GT-Vu for ltru@lists.ietf.org; Wed, 22 Nov 2006 03:46:12 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005855038.msg for ; Wed, 22 Nov 2006 08:48:43 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 22 Nov 2006 08:45:58 +0000 From: "Debbie Garside" To: , Subject: RE: [Ltru] Re: LTRU progress and ISO 639-6 Date: Wed, 22 Nov 2006 08:45:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <19A328037921AA42847A717566D1D6A109A13422@RED-MSG-42.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccMTJ/ZiNaI/oi0Rs2KqZRWOyKkNgBhI3EAABA5gjA= Message-ID: X-Spam-Processed: mx1.nexbyte.net, Wed, 22 Nov 2006 08:48:43 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Wed, 22 Nov 2006 08:48:45 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: > In my mind, this raises the question of what use having > "napl" in 639-6 is anyway? It has the same semantics as > "nap-Latn" and I don't see a point in having a metadata > element to denote a semantic for which we already have an > existing metadata element unless someone has a syntactic > requirement -- their metadata elements must all be alpha4 -- > but I see no indication of anyone having such a requirement. Not everyone wants to use extension coding. There is a need for an alpha4 "stand alone" tag. By mapping the stand alone alpha4s to the extension mechanism, they can translated either way. Debbie > Peter > > > > > -----Original Message----- > > From: John Cowan [mailto:cowan@ccil.org] > > > No, I disagree. Quite independent of Suppress-Script, > 'napl' does not > > contain any extra information above "nap" or "nap-Latn" as the case > > may be. So it remains forbidden to use either "nap-6napl" or > > "nap-Latn-6napl". See my previous post for the rationale. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 05:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpec-0000VL-2H; Wed, 22 Nov 2006 05:48:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpea-0000VG-TK for ltru@ietf.org; Wed, 22 Nov 2006 05:48:32 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmpeW-0002UD-Kc for ltru@ietf.org; Wed, 22 Nov 2006 05:48:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E14D526C32E for ; Wed, 22 Nov 2006 11:47:31 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4137B26C342 for ; Wed, 22 Nov 2006 11:47:23 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 354BF58ED2D for ; Wed, 22 Nov 2006 11:47:03 +0100 (CET) Date: Wed, 22 Nov 2006 11:47:03 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20061122104703.GA12899@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.17-2-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: 6d62ab47271805379d7172ee693a45db Subject: [Ltru] Google and marking the 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 Very good talk but it seems noone uses language tagging properly (not even Google internally, see the slide on "Stable identifiers"). http://www.macchiato.com/slides/unicode_at_google.ppt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 07:33:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrID-0005DT-2j; Wed, 22 Nov 2006 07:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrIC-0005DC-Ad for ltru@ietf.org; Wed, 22 Nov 2006 07:33:32 -0500 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmrI7-0003g7-Vo for ltru@ietf.org; Wed, 22 Nov 2006 07:33:32 -0500 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id E303EF35 for ; Wed, 22 Nov 2006 14:33:22 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 21614-02-4 for ; Wed, 22 Nov 2006 14:33:22 +0200 (EET) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 8E07CA3F2 for ; Wed, 22 Nov 2006 14:33:18 +0200 (EET) Date: Wed, 22 Nov 2006 14:33:18 +0200 (EET) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] Google and marking the languages In-Reply-To: <20061122104703.GA12899@nic.fr> Message-ID: References: <20061122104703.GA12899@nic.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) 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 On Wed, 22 Nov 2006, Stephane Bortzmeyer wrote: > Very good talk but it seems noone uses language tagging properly (not > even Google internally, see the slide on "Stable identifiers"). And why would people bother using even simple language markup on web pages where it's almost trivial (), when even the most obvious candidates for utilizing such information, namely search engines, ignore it? This looks very much like a vicious circle. It's natural that Google uses heuristic language guessing instead of using language information in markup (or HTTP headers), since most pages lack such information - or have it plain wrong. What Google could sensibly do is to use such information, when available, to decide between similar alternatives in borderline cases, like distinguishing Danish from Norwegian. But this would be of rather limited usefulness. For any substantial amount of text, heuristic language guessing works sufficiently well. For small fragments of text, like quotations or foreign words, guessing is not very successful (as we know from experience with MS Word if we let it guess the language), but who wants to tag his quotations and foreign words, and do it properly? So we have the paradox of language tagging: it's easy when it's not needed, but not otherwise. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 07:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrZQ-0003jj-FZ; Wed, 22 Nov 2006 07:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrZP-0003jb-Dj for ltru@ietf.org; Wed, 22 Nov 2006 07:51:19 -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 1GmrZN-0005Uy-Vs for ltru@ietf.org; Wed, 22 Nov 2006 07:51:19 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005859521.msg for ; Wed, 22 Nov 2006 12:53:54 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 22 Nov 2006 12:51:06 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] Google and marking the languages Date: Wed, 22 Nov 2006 12:50:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20061122104703.GA12899@nic.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccOJSpS7VBGZ/8EQieFGvBblq17AQADL8LA Message-ID: X-Spam-Processed: mx1.nexbyte.net, Wed, 22 Nov 2006 12:53:54 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: 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, 22 Nov 2006 12:53:55 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Stephane wrote: > Very good talk but it seems noone uses language tagging > properly (not even Google internally, see the slide on > "Stable identifiers"). > > http://www.macchiato.com/slides/unicode_at_google.ppt > This is something that I have tried to bring up (privately) on a number of occasions. We can sit here and standardize until the cows come home but unless we give the end user motivation to adopt the standards that we create, there will be no real standardization. Standardization occurs when the end user adopts the standard and we have to devise ways to encourage our target market to do that and then market those ways effectively. If search engines (such as Google) make part of their search engine rating whether a document has been "tagged wisely", this will spur on the end user to follow the standard. As a business owner with several web sites, I know that I would definitely tag my sites wisely if I thought it would increase my ranking on a search engine. (Please don't check out my web sites :-)) It is simple. If search engines adopt this strategy and make it known that this is the case wrt ranking, the end user will also adopt. The pay off...Better information for search engines and standardization in the very meaning of the word, with the end user happy that he has done that little bit extra to ensure his business is up there with the rest. How many books/articles are published each year telling end users how to increase their rankings on search engines? Sounds like standardization marketing made easy! Best regards Debbie Debbie Garside > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 08:50:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsUq-00052X-LM; Wed, 22 Nov 2006 08:50:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsUp-00052S-J8 for ltru@ietf.org; Wed, 22 Nov 2006 08:50:39 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmsUl-0003jD-92 for ltru@ietf.org; Wed, 22 Nov 2006 08:50:39 -0500 Received: by ug-out-1314.google.com with SMTP id 72so145202ugd for ; Wed, 22 Nov 2006 05:50:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EkQIHGXIPt7vOAPAM25A48CLvjABPG1XrzkflSspAHqrw4+faZxff5937g1nvK8O3cR7iUUPaiigEUqfK3X/aBMKdcnFaIwLW1RBcTwR6fKUqd3BLADW1st+PYJws/kVXw+LdmfrERStCkLH/iqylQdZjkpEUxpGtpX4UzE5YUU= Received: by 10.78.201.10 with SMTP id y10mr7825157huf.1164203433896; Wed, 22 Nov 2006 05:50:33 -0800 (PST) Received: by 10.78.199.19 with HTTP; Wed, 22 Nov 2006 05:50:33 -0800 (PST) Message-ID: <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> Date: Wed, 22 Nov 2006 13:50:33 +0000 From: "Dave Pawson" To: ltru@ietf.org Subject: Re: [Ltru] Google and marking the languages In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061122104703.GA12899@nic.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org View from the outside. On 22/11/06, Debbie Garside wrote: > This is something that I have tried to bring up (privately) on a number of > occasions. We can sit here and standardize until the cows come home but > unless we give the end user motivation to adopt the standards that we > create, there will be no real standardization. Standardization occurs when > the end user adopts the standard and we have to devise ways to encourage our > target market to do that and then market those ways effectively. I'd make it even plainer. How many users (commercial or individual) who are unaware of I18N or have never had reason to consider it? Does this group (or the others with similar interests) ever make a marketing effort? Where is the list of ten good reasons to id the language? Where should those who see the benefit point others to, the 'sales pitch'? > It is simple. If search engines adopt this strategy and make it known that > this is the case wrt ranking, the end user will also adopt. The pay > off...Better information for search engines and standardization in the very > meaning of the word, with the end user happy that he has done that little > bit extra to ensure his business is up there with the rest. Great piece of marketing; that would hit home with business users. > > How many books/articles are published each year telling end users how to > increase their rankings on search engines? Sounds like standardization > marketing made easy! Yes! regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 10:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmttO-00072n-EB; Wed, 22 Nov 2006 10:20:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmttN-00072c-DG for ltru@ietf.org; Wed, 22 Nov 2006 10:20:05 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmttM-0005IE-28 for ltru@ietf.org; Wed, 22 Nov 2006 10:20:05 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20061122150844.FRAZ25578.mta15.adelphia.net@DGBP7M81> for ; Wed, 22 Nov 2006 10:08:44 -0500 Message-ID: <008301c70e49$a90420d0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 22 Nov 2006 07:19:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ltru] Re: ISO/FDIS 639-3 tables revised X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >>> Type: A(ncient), C(onstructed), E(xtinct), H(istorical), L(iving), >>> S(pecial). This would be very useful information for identification, >>> and I suggest we add it as a Language-Type field >> >> This field should also be able to hold the value "Collection" > > In terms of the attributes on entries defined in ISO 639-3, this would > be mixing values for two distinct attributes: type (living, etc.) and > scope (individual language, macrolanguage, collection). The type > attribute applied to collections would more-appropriately have values > such as "genetic" or "geographic" according to how the collection is > defined. I understand this, and I'm prepared to live with it. The ISO 639-3 distinction between individual languages and macrolanguages is important to us from the standpoints of understanding the concepts and reloading the Registry for RFC 4646bis. However, as some have pointed out, there will not necessarily always be a 1-to-1 relationship in the future between macrolanguages and languages subtags that have extlangs. ISO 639-3 may need to change a language from one category to the other, but the type of 4646bis subtag would not change. Collections, on the other hand, are operationally important: we have a passage in 4646bis that subtags based on collection codes are to be avoided. The proposed "Language-Type" field would be populated primarily from the "Type" field in ISO 639-3, with abbreviations expanded ("Constructed" instead of "C") and with "L" suppressed as a default. Code elements in 639-2 but not 639-3 have no "Type" field, of course, but those code elements -- by definition -- are exactly the collection codes. There needs to be a place to specify that information. I don't think it would make sense to have a separate "Language-Scope" field that would only exist for collections, and then have the absence of a "Language-Type" field mean "either a living language OR a collection." I note that the "Scope" field in 639-3 mirrors the "Type" field for the "special" ("S") codes mul, und, and zxx. >>> Scope: we don't need to add this, since it can be derived: something >>> is a macro language iff there is an extlang that points to it. >> >> I agree. > > Well, note that right now you don't have a certain way to tell which > entities have a collection scope. I consider that to be a problem. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 12:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvgp-0004vp-Al; Wed, 22 Nov 2006 12:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvgo-0004vT-4K for ltru@lists.ietf.org; Wed, 22 Nov 2006 12:15: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 1Gmvgm-0006a6-Rn for ltru@lists.ietf.org; Wed, 22 Nov 2006 12:15:14 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GmvgC-00010V-8y for ltru@lists.ietf.org; Wed, 22 Nov 2006 18:14:36 +0100 Received: from d247167.dialin.hansenet.de ([80.171.247.167]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 18:14:36 +0100 Received: from nobody by d247167.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 18:14:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 22 Nov 2006 18:13:25 +0100 Organization: Lines: 10 Message-ID: <45648535.41A4@xyzzy.claranet.de> References: <455CBFCA.4872@xyzzy.claranet.de> <80E9D6AB5A5347F986A103AFCD7D2C60.MAI@home> <456062A4.7B63@xyzzy.claranet.de> <20061120023556.GC24285@ccil.org> <456351E5.5060102@yahoo-inc.com> <20061121202212.GC12648@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d247167.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: LTRU progress and ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > This leaves open the fate of existing variants that match 639-6 code elements: > should they be deprecated in favor of their 639-6 equivalents, or left alone > and the 639-6 equivalent excluded? Deprecate the ad-hoc-variants. Same idea as with i-whatever in 4646. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 12:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvm3-00089u-8D; Wed, 22 Nov 2006 12:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvm2-00089f-Bv for ltru@lists.ietf.org; Wed, 22 Nov 2006 12:20:38 -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 1Gmvm0-0007ns-8R for ltru@lists.ietf.org; Wed, 22 Nov 2006 12:20:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GmvlZ-0002GZ-63 for ltru@lists.ietf.org; Wed, 22 Nov 2006 18:20:09 +0100 Received: from d247167.dialin.hansenet.de ([80.171.247.167]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 18:20:09 +0100 Received: from nobody by d247167.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 18:20:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 22 Nov 2006 18:19:32 +0100 Organization: Lines: 13 Message-ID: <456486A4.72BD@xyzzy.claranet.de> References: <45635423.2030902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d247167.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: ISO 11179 conformance and a new draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > If there is some specific text that we've decided to incorporate > that I missed (and I haven't seen anything), it would be useful > to know about it. I've two articles on hold with modifications for the next I-D: Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 12:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwIz-0002Xg-6Y; Wed, 22 Nov 2006 12:54:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwIy-0002Vb-IT for ltru@ietf.org; Wed, 22 Nov 2006 12:54:40 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmwIx-0004et-AA for ltru@ietf.org; Wed, 22 Nov 2006 12:54:40 -0500 Received: (qmail 99639 messnum 2902055 invoked from network[194.125.174.119/ts09-119.dublin.indigo.ie]); 22 Nov 2006 17:54:37 -0000 Received: from ts09-119.dublin.indigo.ie (HELO ?194.125.174.119?) (194.125.174.119) by mail07.svc.cra.dublin.eircom.net (qp 99639) with SMTP; 22 Nov 2006 17:54:37 -0000 In-Reply-To: <000401c70de9$4bfa89c0$6601a8c0@oemcomputer> References: <200611210150.kAL1oWT14470@birdie.sybase.com><30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> <4563C2B2.9010209@sil.org> <000401c70de9$4bfa89c0$6601a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Date: Wed, 22 Nov 2006 17:58:07 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org If that's the best Randy can offer, I'll accept it. So which ISO =20 standard is capable of tagging IPA so? mg On 22 Nov 2006, at 03:50, scr=EDobh Randy Presuhn: > ...we'd need a generic subtag to > represent "we know it's a (IPA) transcription but don't know =20 > specifically > which conventions are in use" for cataloging purposes. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 12:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwNT-0004uC-Ah; Wed, 22 Nov 2006 12:59:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwNR-0004tH-Mh for ltru@ietf.org; Wed, 22 Nov 2006 12:59:17 -0500 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmwNQ-0005gP-BL for ltru@ietf.org; Wed, 22 Nov 2006 12:59:17 -0500 Received: (qmail 31388 messnum 6387246 invoked from network[194.125.174.119/ts09-119.dublin.indigo.ie]); 22 Nov 2006 17:59:14 -0000 Received: from ts09-119.dublin.indigo.ie (HELO ?194.125.174.119?) (194.125.174.119) by mail00.svc.cra.dublin.eircom.net (qp 31388) with SMTP; 22 Nov 2006 17:59:14 -0000 In-Reply-To: <200611211951.kALJpZT15348@birdie.sybase.com> References: <200611211951.kALJpZT15348@birdie.sybase.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5C4E9B1E-ADE3-4533-AD5F-3FD6C6091F5C@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Wed, 22 Nov 2006 18:02:44 +0000 To: Kenneth Whistler X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, ltru@ietf.org Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 21 Nov 2006, at 19:51, scr=EDobh Kenneth Whistler:... > > Well, I think that is a misconstrual to begin with. I assume you > are talking about a community without an indigenous writing > system. In which case, it doesn't make much sense to talk about > me (or my hypothetical compatriot) being "illiterate" in a > non-existent writing system... Wrong. I think I made it clear that such may or may not exist, but =20 either it would take too long to re-educate you to write it and/or =20 the elders do not feel like spending time on educating you, so we go =20 with all you have (IPA). > > And I guess you mean to posit that there isn't any other written > material... Wrong again. (Please see above.) > Well, first of all, such an approach isn't very likely to > be the most effective in gathering good data... Probably right. But all we have is you plus one, literate only in IPA =20= (which is an internationally acceptable mode of committing speech to =20 a form of writing in which natively-trained experts may well be as =20 adept as you). > Assuming I and my hypothetical compatriot were constrained to > these parameters and that week, I would organize the work > as follows: > > Track down the best traditional raconteur(s) in the town/village > and set my compatriot to gathering high-quality digital > recordings of whatever s/he could elicit, interspersed on > an item by item basis with a retelling, if possible, of > the tales in the contact language (Spanish, English, Portuguese) Pointless. Digital recordings ar not amenable to text searches (IPA =20 texts are). > and any explanatory commentary about it. That would give the > best chance of being able to gather good data (and lots of > it) with an ability to unravel any of it later on... > ... > Then spend the rest of the week pounding through the > gathering of as much vocabulary (with glosses in the > contact language) as possible, No. Better leave that to professional lexicographers, such as myself. =20= All you are being paid to do is gather texts we can process =20 (remember, all you know is IPA, and I already have experience of =20 processing texts written in IPA by people, mostly Germans, unfamiliar =20= with such native orthography as may exist). > and unravelling the basics > of morphological structure and syntax, so that there would > some chance to make sense of the extended digital corpus > being collected... Again not your concern (way outside your ken). Your job is only to =20 produce searchable, written text. > I definitely would *not* do this in IPA... if I discovered early on =20= > in the phonological > analysis that I was dealing with a 5 vowel system (fairly > common in the Americas), I would very, very quickly > abandon all the details of iotas and epsilons and open > o's and turned a's and turned m's and whatnot, for > an "aeiou" system that worked for rapid transcription. You mean, invent your own? Sorry, we wouldn't hire you. > > I would end up with a rough-and-ready practical > phonemic, Latin-based orthography, probably based primarily > on Americanist standards, but possibly borrowing some IPA > usage for particular phonemes if useful. And whatever > happened during the week, it would have to be refined > later into a consistent orthography Again, not your job. If you cannot produce text in a well-established =20= script/orthography (viz. IPA), anything else you produce will be of =20 absolutely no use to trained IPA researchers working in the same =20 region with other communities, whose languages may or may not be =20 related to the community in which we permitted you to work. > that could be used > to attempt to then transcribe the larger corpus of > recorded textual material. > > --Ken > > P.S. I *have* done salvage linguistic fieldwork in > California, although not on Chumash -- all varieties of > which were extinct before I was trained as a field linguist. So? We are not here positing extinct languages, Ken (but languages =20 about to become extinct without such help as minimally trained IPA =20 workers can give us). Have you never done salvage linguistic =20 fieldwork on a living language, Ken?! mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 13:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwTb-000765-6E; Wed, 22 Nov 2006 13:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwTa-00075t-4q for ltru@ietf.org; Wed, 22 Nov 2006 13:05:38 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmwTV-0006ih-Rp for ltru@ietf.org; Wed, 22 Nov 2006 13:05:38 -0500 Received: (qmail 55372 messnum 2891883 invoked from network[194.125.174.119/ts09-119.dublin.indigo.ie]); 22 Nov 2006 18:05:32 -0000 Received: from ts09-119.dublin.indigo.ie (HELO ?194.125.174.119?) (194.125.174.119) by mail07.svc.cra.dublin.eircom.net (qp 55372) with SMTP; 22 Nov 2006 18:05:32 -0000 In-Reply-To: References: <200611210150.kAL1oWT14470@birdie.sybase.com> 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: Wed, 22 Nov 2006 18:09:02 +0000 To: IETF Languages Discussion , Kenneth Whistler , LTRU Working Group , iso15924-jac@unicode.org, TC46-L Information and Documentation Technology List , Mozilla Project translation into Irish Applied Translation Studies X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] Re: [iso15924-jac]... [was: IPA...] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks for putting that so succinctly, C. E. So we add it to the =20 existing group of Latf, Latg, etc., already registered in ISO 15924 =20 (with no alteration to its scope)? mg On 21 Nov 2006, at 22:54, scr=EDobh CE Whitehead: > > Yes, IPA is based on the Latin script (the Western bias in =20 > linguistics), but it has a few variant characters, particularly for =20= > the gutterals; also there are places where you put dots and such =20 > that are not standard in Latin; there are a few characters from =20 > Greek, but the characters as a whole have nothing to do with =20 > Greek; I'd tag it as a variant of Latin, I think. (See it at: =20 > http://www.omniglot.com/writing/ipa.htm) > Does that make sense? > >> From: Marion Gunn >> >> On 21 Nov 2006, at 01:50, scr=EDobh Kenneth Whistler: >> >> >>> ... in my opinion >>> the right way to handle this is to first *formally* extend the >>> scope of 15924... >>> >> >> I hardly think that necessary, but if that's that what it takes, =20 >> fine. >> >> >>> And IPA is not a variant script. It is not comparable to Latf =20 >>> and Latg. >>> >> >> I believe that it is. We need both Latg and IPA, for example. >> >> >>> It is a circumscribed, technical use of Latn. "cat" is English. >>> "[cat]" is IPA. Tell me the script difference, except in function... >>> >> >> You choose an example lacking non-Latin (Greek) letters. Why? >> >> mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 13:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwWI-0002Ru-1J; Wed, 22 Nov 2006 13:08:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwWG-0002Pz-47 for ltru@ietf.org; Wed, 22 Nov 2006 13:08:24 -0500 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmwWE-0006xp-RE for ltru@ietf.org; Wed, 22 Nov 2006 13:08:24 -0500 Received: (qmail 92811 messnum 11062130 invoked from network[194.125.174.119/ts09-119.dublin.indigo.ie]); 22 Nov 2006 18:08:19 -0000 Received: from ts09-119.dublin.indigo.ie (HELO ?194.125.174.119?) (194.125.174.119) by mail11.svc.cra.dublin.eircom.net (qp 92811) with SMTP; 22 Nov 2006 18:08:19 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> References: <200611210150.kAL1oWT14470@birdie.sybase.com> <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7C4FF3DB-EA44-41A0-AA4F-52CF8E541E00@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Date: Wed, 22 Nov 2006 18:11:49 +0000 To: IETF Languages Discussion , LTRU Working Group , iso15924-jac@unicode.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 22 Nov 2006, at 01:29, scr=EDobh Mark Davis: > ... > The political season is over... > Language tags are a big customer for ISO 15924, and it would seem =20 > reasonable to at least consider the issue from all sides... I concur. > > I think I might not have been clear. While there may be good =20 > reasons for why IPA doesn't qualify, and yet Hans & Hant qualify, =20 > but the JAC did not make the rationale clear. While the difference =20 > may be blindingly obvious to you, it would be helpful to hear what =20 > it actually is, more than an "I concur". I concur.:-) > I don't think anyone is expecting books in IPA -- it would be, as =20 > you say, tagged fragments. Actually, I would - mostly what I see are bks with parallel texts - =20 but tagged fragments will suffice, for now. > No, I think everyone is aware that there are multiple systems of =20 > phonetic representations. So IPA would likely be the first of =20 > several. But it is clearly a relatively important one, being in =20 > pretty widespread use in dictionaries and other sources. As with =20 > encoding characters, or script variants, at some point you have to =20 > make judgments as to whether a system is in wide enough usage to be =20= > worth encoding; systems that are in ad hoc, limited use wouldn't =20 > qualify. I concur. > > But a side note: a list of 8 different potential systems is not =20 > exactly scary, given we that we are at the point of adding some =20 > 7,000 new language tags. Exactly what I was thinking, and not really such a big "ask" (given =20 the potential benefits accruing to all). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 16:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzls-00011e-9x; Wed, 22 Nov 2006 16:36:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzlr-00011W-Cs for ltru@ietf.org; Wed, 22 Nov 2006 16:36:43 -0500 Received: from smtp.microsoft.com ([205.248.106.30] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmzlm-00081T-3v for ltru@ietf.org; Wed, 22 Nov 2006 16:36:43 -0500 Received: from mailout4.microsoft.com (157.57.217.12) by SVC-EXGWY-E802.partners.extranet.microsoft.com (10.251.24.243) with Microsoft SMTP Server id 8.0.685.15; Wed, 22 Nov 2006 13:36:37 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 13:36:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: ISO/FDIS 639-3 tables revised Date: Wed, 22 Nov 2006 13:36:22 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A139B4@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <008301c70e49$a90420d0$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: ISO/FDIS 639-3 tables revised Thread-Index: AccOSbkjmV8Yxu5SRbKGo2PBzRxrXAANEhGQ From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 22 Nov 2006 21:36:37.0387 (UTC) FILETIME=[4A052DB0:01C70E7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1524950259==" Errors-To: ltru-bounces@ietf.org --===============1524950259== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldF0NCg0KPiBJIG5v dGUgdGhhdCB0aGUgIlNjb3BlIiBmaWVsZCBpbiA2MzktMyBtaXJyb3JzIHRoZSAiVHlwZSIgZmll bGQgZm9yIHRoZQ0KPiAic3BlY2lhbCIgKCJTIikgY29kZXMgbXVsLCB1bmQsIGFuZCB6eHguDQoN Clllcy4gVGhhdCdzIG5vdCBzdXJwcmlzaW5nIHNpbmNlIHRoZXNlIGFyZSByZWFsbHkgZXhjZXB0 aW9uYWwsIHNpbmd1bGFyaXRpZXMgLS0gc3BlY2lhbCBjYXNlcyB0byB3aGljaCBub3JtYWwgYmVo YXZpb3VycyBkbyBub3QgYXBwbHkuIA0KDQoNCg0KUGV0ZXIgQ29uc3RhYmxlDQo= --===============1524950259== 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 --===============1524950259==-- From ltru-bounces@ietf.org Wed Nov 22 16:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzvv-0003nZ-Oj; Wed, 22 Nov 2006 16:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmzvu-0003lT-Ls for ltru@ietf.org; Wed, 22 Nov 2006 16:47:06 -0500 Received: from smtp.microsoft.com ([205.248.106.64] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmzvt-0001Vx-DX for ltru@ietf.org; Wed, 22 Nov 2006 16:47:06 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E801.partners.extranet.microsoft.com (10.251.24.242) with Microsoft SMTP Server id 8.0.685.15; Wed, 22 Nov 2006 13:47:05 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 13:47:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Google and marking the languages Date: Wed, 22 Nov 2006 13:46:56 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A139C9@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Google and marking the languages Thread-Index: AccOJSpS7VBGZ/8EQieFGvBblq17AQADL8LAABMqd6A= From: Peter Constable To: X-OriginalArrivalTime: 22 Nov 2006 21:47:04.0661 (UTC) FILETIME=[BFE79850:01C70E7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > This is something that I have tried to bring up (privately) on a = number of > occasions. We can sit here and standardize until the cows come home = but > unless we give the end user motivation to adopt the standards that we > create, there will be no real standardization. In relation to our recent discussion regarding phonetic transcriptions, = it would be a serious mistake to be misled by statistics about Web = documents.=20 IMO, the primary need for tags for phonetic transcription is not in Web = pages but rather in documentation of some 7000 languages recorded by = linguists all over the world, held in various language data archives, = and contained primarily in xml files using various schemas.=20 Linguists around the world are very much engaged in such documentation = projects, and they are depending on standards for various purposes to = make the data that is compiled interoperable and enduring. Language = tagging is an important aspect of standardization for language = documentation, and tagging of content in various phonetic transcriptions = is an important aspect of their language tagging needs. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 17:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0eL-0003gd-NC; Wed, 22 Nov 2006 17:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmy1y-0004Tt-BZ for ltru@ietf.org; Wed, 22 Nov 2006 14:45:14 -0500 Received: from inergen.sybase.com ([192.138.151.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmy1w-0003yA-UF for ltru@ietf.org; Wed, 22 Nov 2006 14:45:14 -0500 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id kAMJitV11914; Wed, 22 Nov 2006 11:44:55 -0800 (PST) Received: from olympus-dublin.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com with ESMTP id kAMJitu11491; Wed, 22 Nov 2006 11:44:55 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.7p1+Sun/8.10.2) with ESMTP id kAMJisM14836; Wed, 22 Nov 2006 11:44:54 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id kAMJisT16288; Wed, 22 Nov 2006 11:44:54 -0800 (PST) Message-Id: <200611221944.kAMJisT16288@birdie.sybase.com> Date: Wed, 22 Nov 2006 11:44:54 -0800 (PST) From: Kenneth Whistler To: mgunn@egt.ie MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: r9E5t5rKg6h9ss8AgFAtjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Wed, 22 Nov 2006 17:33:01 -0500 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, ltru@ietf.org, kenw@sybase.com Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Whistler List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Pointless. Digital recordings ar not amenable to text searches (IPA > texts are). Hmmm. You posited that you wanted: "to write down all possible of that community's stories and traditional cures in a single week" and I gave you a strategy to accomplish that. > No. Better leave that to professional lexicographers, such as myself. And if you think a field linguist can reliably gather text without focussing on such issues, I think you are sadly mistaken. > All you are being paid to do is gather texts we can process > (remember, all you know is IPA, Actually, not, of course... but this is your dime, I guess. > and I already have experience of > processing texts written in IPA by people, mostly Germans, unfamiliar > with such native orthography as may exist). O.k., if they want to do it that way, but if they do so without understanding the phonological and morphological structure of the language in question, the data will be misleading unless interpreted by *another* native speaker or one otherwise familiar with the language structure, back into meaningful distinctions. > > and unravelling the basics > > of morphological structure and syntax, so that there would > > some chance to make sense of the extended digital corpus > > being collected... > > Again not your concern (way outside your ken). Your job is only to > produce searchable, written text. Garbage in, garbage out. I've seen -- many times -- the results of field linguists attempting to simply transcribe connected text phonetically. Most of the time it is a horrid mess. > You mean, invent your own? Sorry, we wouldn't hire you. Sorry, I wouldn't take your job. ;-) > Again, not your job. If you cannot produce text in a well-established > script/orthography (viz. IPA), anything else you produce will be of > absolutely no use to trained IPA researchers working in the same > region with other communities, whose languages may or may not be > related to the community in which we permitted you to work. Well, if you say so. > > P.S. I *have* done salvage linguistic fieldwork in > > California, although not on Chumash -- all varieties of > > which were extinct before I was trained as a field linguist. > > So? We are not here positing extinct languages, Ken (but languages > about to become extinct without such help as minimally trained IPA > workers can give us). Have you never done salvage linguistic > fieldwork on a living language, Ken?! Yes, Marion!! If you will read, please. I don't consider philological work on recordings of now-extinct languages to be "salvage linguistic fieldwork." I worked in California in the mid-70's with speakers of a profoundly moribund language. The language community was already extinct, but I located 3 very elderly speakers, all in their 80's, all isolated from each other, and each with handicaps of various sorts that interfered with elicitation -- including in one case very advanced deafness. The irony is that working with them, I managed to write down more of the language, far better analyzed, than at least 8 linguists and/or anthropologists who had worked in that language community before me -- including Alfred Kroeber himself, who published the definitive ethnography in 1932. And no, I didn't use IPA to do it, and yes, I worked up a phonemic orthography as I went. And to the extent that *any* of the previously written down textual material is usable at all, it is because I was able to reinterpret execrable written recordings to figure out what the original recorders had to have been hearing, based on what I had sorted out about the structure of the phonology, morphology, syntax, and discourse patterns of the language. See: Kenneth W. Whistler, "Deer and Bear Children (Patwin),", published in IJAL-Native American Text Series No. 2 (1977): 158-78, for an example. --Ken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 17:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0eL-0003gh-PY; Wed, 22 Nov 2006 17:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn06G-0003O3-GE for ltru@ietf.org; Wed, 22 Nov 2006 16:57:48 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn06F-0003O8-3P for ltru@ietf.org; Wed, 22 Nov 2006 16:57:48 -0500 Received: by ug-out-1314.google.com with SMTP id 72so268997ugd for ; Wed, 22 Nov 2006 13:57:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hp4aE+AsFodRv4DTQ+AS9mRVkcYNYdG3wkr0gOJQvPYS9tG/Wvil1R9ZKVTxPFhZgbuZuVK1T4GaVZKkZMChtNwGuJxq+9MNJ6Hh+cf3AVMYk6aDdpkDTiurrByurw1q+TgHN2dsQh9Gm2KTCAaXiyI4i+EqstddJQISH9UCcXw= Received: by 10.78.138.6 with SMTP id l6mr8279630hud.1164232665705; Wed, 22 Nov 2006 13:57:45 -0800 (PST) Received: by 10.78.151.14 with HTTP; Wed, 22 Nov 2006 13:57:45 -0800 (PST) Message-ID: <6d99d1fd0611221357w731ac8bau7c604fd3b1b2f5b0@mail.gmail.com> Date: Wed, 22 Nov 2006 15:57:45 -0600 From: "David Starner" To: "Martin Hosken" Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies In-Reply-To: <4563C2B2.9010209@sil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200611210150.kAL1oWT14470@birdie.sybase.com> <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> <4563C2B2.9010209@sil.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Wed, 22 Nov 2006 17:33:01 -0500 Cc: ietf-languages@iana.org, LTRU Working Group , iso15924-jac@unicode.org, Kenneth Whistler X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 11/21/06, Martin Hosken wrote: > IPA is a script/transcription system that is used for multiple languages > even more than Roman script. I.e. a reader of IPA can do a pretty good > job of sounding out text in a language written using it, that they do > not know. IPA is Roman script, and I doubt that it's been used for more languages than Roman script, given that most languages sooner or later show up somewhere in Latin transliteration. > > Chumash-Barbareno in JPHarrington orthography (a massive corpus) > > > > I know nothing about this orthography. But whether it is phonetic or > phonemic, I would suggest that it is limited to this and perhaps a few > other languages. Therefore allocating a per language extension for this > orthography seems sensible. But that's not a job that ISO 15924 has chosen for itself or is designed to handle. There is no concept in that standard of a per language extension. > Those that are > designed to be universal (or near universal) transcription systems (of > which I only know of IPA and Americanist, are there others?) The UPA, for one, and I'm sure there are others. > are not > best served by a model that only allows for per language extensions. I know of no such model, so you're in luck. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 17:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0eL-0003gd-NC; Wed, 22 Nov 2006 17:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmy1y-0004Tt-BZ for ltru@ietf.org; Wed, 22 Nov 2006 14:45:14 -0500 Received: from inergen.sybase.com ([192.138.151.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmy1w-0003yA-UF for ltru@ietf.org; Wed, 22 Nov 2006 14:45:14 -0500 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id kAMJitV11914; Wed, 22 Nov 2006 11:44:55 -0800 (PST) Received: from olympus-dublin.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com with ESMTP id kAMJitu11491; Wed, 22 Nov 2006 11:44:55 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.7p1+Sun/8.10.2) with ESMTP id kAMJisM14836; Wed, 22 Nov 2006 11:44:54 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id kAMJisT16288; Wed, 22 Nov 2006 11:44:54 -0800 (PST) Message-Id: <200611221944.kAMJisT16288@birdie.sybase.com> Date: Wed, 22 Nov 2006 11:44:54 -0800 (PST) From: Kenneth Whistler To: mgunn@egt.ie MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: r9E5t5rKg6h9ss8AgFAtjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Wed, 22 Nov 2006 17:33:01 -0500 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, ltru@ietf.org, kenw@sybase.com Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Whistler List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Pointless. Digital recordings ar not amenable to text searches (IPA > texts are). Hmmm. You posited that you wanted: "to write down all possible of that community's stories and traditional cures in a single week" and I gave you a strategy to accomplish that. > No. Better leave that to professional lexicographers, such as myself. And if you think a field linguist can reliably gather text without focussing on such issues, I think you are sadly mistaken. > All you are being paid to do is gather texts we can process > (remember, all you know is IPA, Actually, not, of course... but this is your dime, I guess. > and I already have experience of > processing texts written in IPA by people, mostly Germans, unfamiliar > with such native orthography as may exist). O.k., if they want to do it that way, but if they do so without understanding the phonological and morphological structure of the language in question, the data will be misleading unless interpreted by *another* native speaker or one otherwise familiar with the language structure, back into meaningful distinctions. > > and unravelling the basics > > of morphological structure and syntax, so that there would > > some chance to make sense of the extended digital corpus > > being collected... > > Again not your concern (way outside your ken). Your job is only to > produce searchable, written text. Garbage in, garbage out. I've seen -- many times -- the results of field linguists attempting to simply transcribe connected text phonetically. Most of the time it is a horrid mess. > You mean, invent your own? Sorry, we wouldn't hire you. Sorry, I wouldn't take your job. ;-) > Again, not your job. If you cannot produce text in a well-established > script/orthography (viz. IPA), anything else you produce will be of > absolutely no use to trained IPA researchers working in the same > region with other communities, whose languages may or may not be > related to the community in which we permitted you to work. Well, if you say so. > > P.S. I *have* done salvage linguistic fieldwork in > > California, although not on Chumash -- all varieties of > > which were extinct before I was trained as a field linguist. > > So? We are not here positing extinct languages, Ken (but languages > about to become extinct without such help as minimally trained IPA > workers can give us). Have you never done salvage linguistic > fieldwork on a living language, Ken?! Yes, Marion!! If you will read, please. I don't consider philological work on recordings of now-extinct languages to be "salvage linguistic fieldwork." I worked in California in the mid-70's with speakers of a profoundly moribund language. The language community was already extinct, but I located 3 very elderly speakers, all in their 80's, all isolated from each other, and each with handicaps of various sorts that interfered with elicitation -- including in one case very advanced deafness. The irony is that working with them, I managed to write down more of the language, far better analyzed, than at least 8 linguists and/or anthropologists who had worked in that language community before me -- including Alfred Kroeber himself, who published the definitive ethnography in 1932. And no, I didn't use IPA to do it, and yes, I worked up a phonemic orthography as I went. And to the extent that *any* of the previously written down textual material is usable at all, it is because I was able to reinterpret execrable written recordings to figure out what the original recorders had to have been hearing, based on what I had sorted out about the structure of the phonology, morphology, syntax, and discourse patterns of the language. See: Kenneth W. Whistler, "Deer and Bear Children (Patwin),", published in IJAL-Native American Text Series No. 2 (1977): 158-78, for an example. --Ken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 17:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0eL-0003gh-PY; Wed, 22 Nov 2006 17:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn06G-0003O3-GE for ltru@ietf.org; Wed, 22 Nov 2006 16:57:48 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn06F-0003O8-3P for ltru@ietf.org; Wed, 22 Nov 2006 16:57:48 -0500 Received: by ug-out-1314.google.com with SMTP id 72so268997ugd for ; Wed, 22 Nov 2006 13:57:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hp4aE+AsFodRv4DTQ+AS9mRVkcYNYdG3wkr0gOJQvPYS9tG/Wvil1R9ZKVTxPFhZgbuZuVK1T4GaVZKkZMChtNwGuJxq+9MNJ6Hh+cf3AVMYk6aDdpkDTiurrByurw1q+TgHN2dsQh9Gm2KTCAaXiyI4i+EqstddJQISH9UCcXw= Received: by 10.78.138.6 with SMTP id l6mr8279630hud.1164232665705; Wed, 22 Nov 2006 13:57:45 -0800 (PST) Received: by 10.78.151.14 with HTTP; Wed, 22 Nov 2006 13:57:45 -0800 (PST) Message-ID: <6d99d1fd0611221357w731ac8bau7c604fd3b1b2f5b0@mail.gmail.com> Date: Wed, 22 Nov 2006 15:57:45 -0600 From: "David Starner" To: "Martin Hosken" Subject: Re: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies In-Reply-To: <4563C2B2.9010209@sil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200611210150.kAL1oWT14470@birdie.sybase.com> <30b660a20611211729x6e7e6cdfj96786cd005785bf3@mail.gmail.com> <4563C2B2.9010209@sil.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Wed, 22 Nov 2006 17:33:01 -0500 Cc: ietf-languages@iana.org, LTRU Working Group , iso15924-jac@unicode.org, Kenneth Whistler X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 11/21/06, Martin Hosken wrote: > IPA is a script/transcription system that is used for multiple languages > even more than Roman script. I.e. a reader of IPA can do a pretty good > job of sounding out text in a language written using it, that they do > not know. IPA is Roman script, and I doubt that it's been used for more languages than Roman script, given that most languages sooner or later show up somewhere in Latin transliteration. > > Chumash-Barbareno in JPHarrington orthography (a massive corpus) > > > > I know nothing about this orthography. But whether it is phonetic or > phonemic, I would suggest that it is limited to this and perhaps a few > other languages. Therefore allocating a per language extension for this > orthography seems sensible. But that's not a job that ISO 15924 has chosen for itself or is designed to handle. There is no concept in that standard of a per language extension. > Those that are > designed to be universal (or near universal) transcription systems (of > which I only know of IPA and Americanist, are there others?) The UPA, for one, and I'm sure there are others. > are not > best served by a model that only allows for per language extensions. I know of no such model, so you're in luck. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 17:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0je-0000Bw-0H; Wed, 22 Nov 2006 17:38:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0jd-0000B5-FU for ltru@ietf.org; Wed, 22 Nov 2006 17:38:29 -0500 Received: from mailc.microsoft.com ([205.248.106.32] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn0Vv-0000yh-Hh for ltru@ietf.org; Wed, 22 Nov 2006 17:24:20 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.15; Wed, 22 Nov 2006 14:24:18 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:24:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Date: Wed, 22 Nov 2006 14:23:52 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A13A19@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <6d99d1fd0611221357w731ac8bau7c604fd3b1b2f5b0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies Thread-Index: AccOgVYFO8H6Tft1SyCe33axbaIw8QAAxkZw From: Peter Constable To: David Starner , Martin Hosken X-OriginalArrivalTime: 22 Nov 2006 22:24:18.0589 (UTC) FILETIME=[F36DF4D0:01C70E84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, LTRU Working Group , Kenneth Whistler X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0703466778==" Errors-To: ltru-bounces@ietf.org --===============0703466778== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBpZXRmLWxhbmd1YWdlcy1ib3VuY2VzQGFsdmVzdHJhbmQubm8gW21haWx0bzppZXRm LWxhbmd1YWdlcy0NCj4gYm91bmNlc0BhbHZlc3RyYW5kLm5vXSBPbiBCZWhhbGYgT2YgRGF2aWQg U3Rhcm5lcg0KDQoNCj4gPiBJIGtub3cgbm90aGluZyBhYm91dCB0aGlzIG9ydGhvZ3JhcGh5LiBC dXQgd2hldGhlciBpdCBpcyBwaG9uZXRpYyBvcg0KPiA+IHBob25lbWljLCBJIHdvdWxkIHN1Z2dl c3QgdGhhdCBpdCBpcyBsaW1pdGVkIHRvIHRoaXMgYW5kIHBlcmhhcHMgYSBmZXcNCj4gPiBvdGhl ciBsYW5ndWFnZXMuIFRoZXJlZm9yZSBhbGxvY2F0aW5nIGEgcGVyIGxhbmd1YWdlIGV4dGVuc2lv biBmb3IgdGhpcw0KPiA+IG9ydGhvZ3JhcGh5IHNlZW1zIHNlbnNpYmxlLg0KPiANCj4gQnV0IHRo YXQncyBub3QgYSBqb2IgdGhhdCBJU08gMTU5MjQgaGFzIGNob3NlbiBmb3IgaXRzZWxmIG9yIGlz DQo+IGRlc2lnbmVkIHRvIGhhbmRsZS4gVGhlcmUgaXMgbm8gY29uY2VwdCBpbiB0aGF0IHN0YW5k YXJkIG9mIGEgcGVyDQo+IGxhbmd1YWdlIGV4dGVuc2lvbi4NCg0KSSB0aGluayB0aGF0IHdhcyBo aXMgcG9pbnQ6IGluIHRoaXMgY2FzZSBpdCBkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8gY29kaWZ5IHRo YXQgaW4gSVNPIDE1OTI0IGJlY2F1c2UgaXQgaXMgc3BlY2lmaWMgdG8gYSBzaW5nbGUgbGFuZ3Vh Z2UgKG9yIHNtYWxsIG51bWJlciBvZiBsYW5ndWFnZXMpLCBhbmQgYSB2YXJpYW50IHN1YnRhZyBt YWtlcyBtdWNoIGJldHRlciBzZW5zZS4gSW4gY29udHJhc3QsIHNvbWV0aGluZyBsaWtlICJJUEEg dHJhbnNjcmlwdGlvbiIgb3IgIkxhdGluLWJhc2VkIHBob25ldGljIHRyYW5zY3JpcHRpb25zIiBh cmUgYXBwbGljYWJsZSBhY3Jvc3MgYWxsIGxhbmd1YWdlcywgYW5kIHNvIGNhbiBtb3JlLWFwcHJv cHJpYXRlbHkgYmUgY29uc2lkZXJlZCBmb3IgY29kaW5nIGluIElTTyAxNTkyNC4NCg0KDQoNClBl dGVyIENvbnN0YWJsZQ0K --===============0703466778== 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 --===============0703466778==-- From ltru-bounces@ietf.org Wed Nov 22 18:10:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1EO-0006T7-7l; Wed, 22 Nov 2006 18:10:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1EN-0006T2-L6 for ltru@ietf.org; Wed, 22 Nov 2006 18:10:15 -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 1Gn1EM-0007wO-7I for ltru@ietf.org; Wed, 22 Nov 2006 18:10:15 -0500 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005868671.msg for ; Wed, 22 Nov 2006 23:12:23 +0000 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 22 Nov 2006 23:09:37 +0000 From: "Debbie Garside" To: , , Subject: IPA AGAIN was RE: [Ltru] Google and marking the languages Date: Wed, 22 Nov 2006 23:08:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <19A328037921AA42847A717566D1D6A109A139C9@RED-MSG-42.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AccOJSpS7VBGZ/8EQieFGvBblq17AQADL8LAABMqd6AAAp8IYA== Message-ID: <25867F643C9F48AA8FC1139E5F120BE5.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Wed, 22 Nov 2006 23:12:23 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: 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, 22 Nov 2006 23:12:24 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: everson@evertype.com, 'Kenneth Whistler' 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: > In relation to our recent discussion regarding phonetic > transcriptions, it would be a serious mistake to be misled by > statistics about Web documents. My comments were aimed at the statistics for web documents of which there are one or two :-) However... > > IMO, the primary need for tags for phonetic transcription is > not in Web pages but rather in documentation of some 7000 > languages recorded by linguists all over the world, held in > various language data archives, and contained primarily in > xml files using various schemas. Yes, the archive industry is huge, without a doubt. And, I can see their needs quite clearly. I assume they are using RFC4646 and thus would be amenable to a variant subtag as proposed by Michael? > Linguists around the world are very much engaged in such > documentation projects, and they are depending on standards > for various purposes to make the data that is compiled > interoperable and enduring. Language tagging is an important > aspect of standardization for language documentation, and > tagging of content in various phonetic transcriptions is an > important aspect of their language tagging needs. Indeed. But, given that IPA is considered by some to be out of scope for ISO 15924, can we discuss any reasons why Michael's proposals will not meet this need? If any valid reasons are accepted by the majority of IETF-languages (or LTRU for that matter) then we can go to proposal number two (Ken) and petition the JAC of ISO 15924 to change the scope or just allow the tag. If that fails, you can always register a variant of any written language in IPA with ISO 639-6 (as a last resort, of course). Of course, this does not, in any way, prevent any one person from petitioning the ISO 15924 JAC of their own accord. Best regards Debbie > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 18:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1NE-0005ez-0U; Wed, 22 Nov 2006 18:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1NC-0005ec-GW for ltru@ietf.org; Wed, 22 Nov 2006 18:19:22 -0500 Received: from inergen.sybase.com ([192.138.151.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn1N8-0008TX-2D for ltru@ietf.org; Wed, 22 Nov 2006 18:19:22 -0500 Received: from smtp2.sybase.com (sybgate2 [10.22.97.85]) by inergen.sybase.com with ESMTP id kAMNJ4V24940; Wed, 22 Nov 2006 15:19:04 -0800 (PST) Received: from olympus-dublin.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id kAMNJ3m25315; Wed, 22 Nov 2006 15:19:03 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.7p1+Sun/8.10.2) with ESMTP id kAMNJ3M21158; Wed, 22 Nov 2006 15:19:03 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id kAMNJ3T16369; Wed, 22 Nov 2006 15:19:03 -0800 (PST) Message-Id: <200611222319.kAMNJ3T16369@birdie.sybase.com> Date: Wed, 22 Nov 2006 15:19:03 -0800 (PST) From: Kenneth Whistler To: petercon@microsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XIpS4Dg2rN/XsA0KntBD+Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ietf-languages@iana.org, prosfilaes@gmail.com, ltru@ietf.org, iso15924-jac@unicode.org, kenw@sybase.com Subject: [Ltru] RE: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Whistler List-Id: 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 Hosken said, in reference to J.P. Harrington's orthography: > > > I know nothing about this orthography. But whether it is phonetic or > > > phonemic, I would suggest that it is limited to this and perhaps a few > > > other languages. Therefore allocating a per language extension for this > > > orthography seems sensible. > > David Starner responded: > > But that's not a job that ISO 15924 has chosen for itself or is > > designed to handle. There is no concept in that standard of a per > > language extension. > And Peter Constable replied: > I think that was his point: in this case it doesn't make sense to > codify that in ISO 15924 because it is specific to a single > language (or small number of languages), and a variant subtag > makes much better sense. Bzzzt. John Peabody Harrington was the most prolific field recorder of indigenous languages in the history of American linguists, for sure. He started recording them in 1907 and continued, more or less obsessively until his death in 1961. He recorded massively -- there are shelves and shelves and shelves of this stuff in the Smithsonian. Huge corpuses in some particular languages and smaller corpuses, down to miscellaneous recordings, probably in toto as many as 100 distinct languages altogether. Over his lifetime, Harrington probably *lost* more suitcases full of field notes than some linguists recorded in their entire careers. He developed his transcriptional system, which he used very systematically (although it changed somewhat over time from the 1910's into the 1950's), an adaptation of both Americanist principles and IPA, with a number of specific symbol uses directly from IPA. He was known as a highly gifted linguist, and probably had the best ear of any field linguist of that era bar Edward Sapir himself (who was undoubtedly a savant in this regard). But he was also a very difficult and rather secretive person. Much of his corpus didn't surface until after his death, despite the fact that he worked for the BAE (Bureau of American Ethnology) for years. Note from a chronology of J.P. Harrington's work at http://www.rock-art.com/jph/crono.htm 1913 "Jan: JPH appointed to the AAA [American Anthropological Association] committee on phonetic orthography, on [Edward] Sapir's recommendation. [Alfred] Kroeber comments: 'I should not be surprised...if you would have a great deal of trouble from Harrington. He is as keen and well informed on the subject as anyone in the country, but perhaps because he is a young man has shown a riotous inclination to indulge in the expressions of fine shades of sounds in the symbols used for them...'" And what flows through from acquaintance of Harrington's work is that he basically held most of his contemporaries in contempt for their inattention to detail and the general low quality of their linguistic recordings. > In contrast, something like "IPA transcription" or "Latin-based > phonetic transcriptions" are applicable across all languages, > and so can more-appropriately be considered for coding in ISO 15924. There's no "in contrast" about it. JPH's orthographic conventions were applicable and *applied* to dozens and dozens of languages of all types, from Canada to Mesoamerica, Navajo to Mayan, Yuma to Carrier, Tewa to Sarcee, and to languages from practically every language family in California, an area as linguistically diverse as New Guinea. The fact that only one person used it (and occasionally a few assistants) is irrelevant, compared to the fact that there exist perhaps a million pages of raw material using it in a massively multilingual corpus. And it is a damn sight more important and significant than a lot of other proposed or used orthographies. And it isn't a language or script variant subtag. *hehe* --Ken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 18:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1fM-0007tM-SJ; Wed, 22 Nov 2006 18:38:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1fM-0007tF-1G for ltru@ietf.org; Wed, 22 Nov 2006 18:38:08 -0500 Received: from smtp.microsoft.com ([205.248.106.32] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn1fJ-00022G-KY for ltru@ietf.org; Wed, 22 Nov 2006 18:38:08 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.15; Wed, 22 Nov 2006 15:38:05 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 15:38:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Nov 2006 15:37:53 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109A13AB7@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <200611222319.kAMNJ3T16369@birdie.sybase.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phonetic orthographies Thread-Index: AccOjKkzExe/Kk8SRuSqeEpjjvb70AAAF9YA From: Peter Constable To: Kenneth Whistler X-OriginalArrivalTime: 22 Nov 2006 23:38:04.0835 (UTC) FILETIME=[41AD7F30:01C70E8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ietf-languages@iana.org, prosfilaes@gmail.com, ltru@ietf.org, iso15924-jac@unicode.org Subject: [Ltru] RE: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: Kenneth Whistler [mailto:kenw@sybase.com] > Martin Hosken said, in reference to J.P. Harrington's orthography: [snip] > John Peabody Harrington was ... [snip -- lots of interesting info] > > In contrast, something like "IPA transcription" or "Latin-based > > phonetic transcriptions" are applicable across all languages, > > and so can more-appropriately be considered for coding in ISO 15924. >=20 > There's no "in contrast" about it. JPH's orthographic conventions > were applicable and *applied* to dozens and dozens of languages > of all types... In which case, Martin's comments about a language-specific orthography = -- or, at least, my interpretation of Martin's comments in that regard = -- are not applicable. I think my main points are still valid:=20 - There may well be a need to tag orthography distinctions that are = particular to specific languages, but IMO the fact that they are = language-specific automatically disqualifies them from any possible = coding in ISO 15924 (with or without some re-statement of its scope and = purpose). - A system for written notation of language that is not specific to one = particular language is, IMO, a potential candidate for coding in ISO = 15924 (with or without some re-statement of its scope and purpose).=20 - And, more specifically (this is a bit of an amplification of what I = had said in the earlier message), I don't think it is an unreasonable = stretch of the scope and purpose of ISO 15924 to codify as a script = variant "Latin-based phonetic transcriptions".=20 I think you'd probably agree with the first point.=20 The second point is vague enough that it's probably not worth debating, = though I think you probably wouldn't object to that statement given its = vagueness.=20 The third is my particular variant of a proposal to code something in = ISO 15924 -- I am not inclined in favour of coding specifically IPA (or = Harrington's system) in ISO 15924. And clearly this is subject to = debate.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 22 19:06:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn26h-0005DN-5N; Wed, 22 Nov 2006 19:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn26f-00058c-JE for ltru@ietf.org; Wed, 22 Nov 2006 19:06:21 -0500 Received: from inergen.sybase.com ([192.138.151.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn26e-0004SV-6G for ltru@ietf.org; Wed, 22 Nov 2006 19:06:21 -0500 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id kAN065V01990; Wed, 22 Nov 2006 16:06:05 -0800 (PST) Received: from olympus-dublin.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com with ESMTP id kAN064u05509; Wed, 22 Nov 2006 16:06:04 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.7p1+Sun/8.10.2) with ESMTP id kAN063M05456; Wed, 22 Nov 2006 16:06:03 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.11.6+Sun/8.11.6) with SMTP id kAN05wT16381; Wed, 22 Nov 2006 16:05:58 -0800 (PST) Message-Id: <200611230005.kAN05wT16381@birdie.sybase.com> Date: Wed, 22 Nov 2006 16:05:58 -0800 (PST) From: Kenneth Whistler To: petercon@microsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Je68iup0hjcjk54SwhNnBA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ietf-languages@iana.org, iso15924-jac@unicode.org, ltru@ietf.org, kenw@sybase.com, prosfilaes@gmail.com Subject: [Ltru] RE: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Whistler List-Id: 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, > I think my main points are still valid: > > - There may well be a need to tag orthography distinctions that are > particular to specific languages, but IMO the fact that they are > language-specific automatically disqualifies them from any possible > coding in ISO 15924 (with or without some re-statement of its scope > and purpose). > > I think you'd probably agree with the first point. Well, even this first point is problematical, because it immediately runs afoul of Hans and Hant, which is an orthographic distinction in Han, encoded as a "script variant" in 15924, despite the fact that it applies only to one language. (You could quibble that "Chinese" is actually an entire family of languages, which is genetically true, but nearly everybody in IT, as well as the Chinese government, behaves as if written Chinese were a single language, and "Hans" and "Hant" are just two ways to write it.) This point is probably on thin ice for the Syriac script variants, as well. And what about systems which *aren't* encoded at this point -- perhaps Traditional Malayalam versus Reformed Malayalam. That is basically an orthographic distinction within a single script for a single language, rather than a script variant on the order of Latf, but it has about as much justification for script codes as Hans versus Hant, and if the political stinkus about it got hot enough, people would show up at the door of the ISO 15924 JAC demanding that script variant codes be registered, so they could appropriately tag text represented in one form versus the other. > > - A system for written notation of language that is not specific to > one particular language is, IMO, a potential candidate for coding > in ISO 15924 (with or without some re-statement of its scope and purpose). > The second point is vague enough that it's probably not worth debating, > though I think you probably wouldn't object to that statement given its > vagueness. Yep. Effectively that is what is happening now, anyway. As I said in the first response on this topic, people are coming in with "distinctions in writing systems" that they want to tag, and they want script codes to do so. > > - And, more specifically (this is a bit of an amplification of what I had > said in the earlier message), I don't think it is an unreasonable stretch > of the scope and purpose of ISO 15924 to codify as a script variant > "Latin-based phonetic transcriptions". > > The third is my particular variant of a proposal to code something in > ISO 15924 -- I am not inclined in favour of coding specifically IPA > (or Harrington's system) in ISO 15924. And clearly this is subject to > debate. It is not an unreasonable stretch. Reasonable people are clearly making that stretch. But it lets the orthography camel stick his nose further in the tent, and I think it is more or less inevitable that, to paraphrase Mark, that camel is going to come all the way into the tent, drink all the date wine, and then end up lying in the gutter. --Ken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 23 08:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnF4r-00016O-Sa; Thu, 23 Nov 2006 08:57:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnF4q-0000yF-0z for ltru@ietf.org; Thu, 23 Nov 2006 08:57:20 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnF4n-0007pX-NM for ltru@ietf.org; Thu, 23 Nov 2006 08:57:20 -0500 Received: (qmail 84173 messnum 2902299 invoked from network[194.125.174.53/ts09-053.dublin.indigo.ie]); 23 Nov 2006 13:57:03 -0000 Received: from ts09-053.dublin.indigo.ie (HELO ?194.125.174.53?) (194.125.174.53) by mail07.svc.cra.dublin.eircom.net (qp 84173) with SMTP; 23 Nov 2006 13:57:03 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <200611221944.kAMJisT16288@birdie.sybase.com> References: <200611221944.kAMJisT16288@birdie.sybase.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <12C3392B-A208-4748-8636-7DA241D2FFBE@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Thu, 23 Nov 2006 14:00:33 +0000 To: IETF Languages Discussion , LTRU Working Group , iso15924-jac@unicode.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Ltru] Re: [iso15924-jac] Re: Phonetic orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 23 Nov 2006, at 00:05, scr=EDobh Kenneth Whistler: > Peter, > Well, even this first point is problematical, because it immediately > runs afoul of Hans and Hant, which is an orthographic distinction > in Han, encoded as a "script variant" in 15924, despite the fact > that it applies only to one language... I agree. (That is self-evident.) Anyway, IPA is applicable to =20 languages in general. On 22 Nov 2006, at 19:44, scr=EDobh Kenneth Whistler: > ... Sorry, I wouldn't take your job. ;-) Nor I yours, but I thank you for your kindness in giving it real =20 consideration.:-) > Yes, Marion!! If you will read, please. I don't consider > philological work on recordings of now-extinct languages to > be "salvage linguistic fieldwork." Nor do I - I'd rather hear more of your current work with cultural =20 elements which can still be salvaged (even if only by transcribing =20 from scratchy tapes - which I have done it myself, just like you). =20 For the record, having seen and used excellent IPA transcriptions of =20 Irish speech done by Germans unskilled in our grammar or orthography, =20= whom we bless because we, as native dialectologists, have found their =20= work invaluable for analyzing things independent of orthographies, =20 such as realtime syntax, pronunciation, etc. and we can easily =20 transcribe from IPA into something the young generation can =20 assimilate without knowing anything of the trouble we went to to =20 secure it. > I worked in California > in the mid-70's with speakers of a profoundly moribund > language... I congratulate you on that, and hope any similar work you and your =20 compatriots are currently doing for endangered native American =20 language communities may succeed, as work deserving of every blessing. On 22 Nov 2006, at 03:23, scr=EDobh Martin Hosken: > IPA is a script/transcription system that is used for multiple =20 > languages > even more than Roman script. I.e. a reader of IPA can do a pretty good > job of sounding out text in a language written using it, that they do > not know... Amen. 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 Mon Nov 27 11:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goj2d-0000Yi-7y; Mon, 27 Nov 2006 11:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goj2b-0000YS-V3 for ltru@lists.ietf.org; Mon, 27 Nov 2006 11:09: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 1Goj2Q-0007eB-3O for ltru@lists.ietf.org; Mon, 27 Nov 2006 11:09:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Goj2A-00014h-8p for ltru@lists.ietf.org; Mon, 27 Nov 2006 17:08:42 +0100 Received: from d255034.dialin.hansenet.de ([80.171.255.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 17:08:42 +0100 Received: from nobody by d255034.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Nov 2006 17:08:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 27 Nov 2006 17:06:59 +0100 Organization: Lines: 20 Message-ID: <456B0D23.8B1@xyzzy.claranet.de> References: <20061126110003.3CD9E2596D2@eikenes.alvestrand.no> <000f01c711e5$9f6d6c80$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255034.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Tag wisely (was: Phonetic orthographies) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 on > John Cowan wrote: >> RFC 4646 says "tag wisely", *not* "tag exhaustively". > I wish it did say "tag wisely" a bit more explicitly, > maybe even using those exact words. IMO chapter 4.1 is good as is, but we could add that as motto at its beginning. Testing: Tag wisely +-----------------------------------+ | Tag wisely | +-----------------------------------+ Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 28 07:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yU-0002u0-W5; Tue, 28 Nov 2006 07:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yU-0002tP-8F for ltru@ietf.org; Tue, 28 Nov 2006 07:22:10 -0500 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp1uV-0003lo-6d for ltru@ietf.org; Tue, 28 Nov 2006 07:18:05 -0500 Received: (qmail 67603 messnum 2904079 invoked from network[194.125.174.104/ts09-104.dublin.indigo.ie]); 28 Nov 2006 12:17:44 -0000 Received: from ts09-104.dublin.indigo.ie (HELO ?194.125.174.104?) (194.125.174.104) by mail06.svc.cra.dublin.eircom.net (qp 67603) with SMTP; 28 Nov 2006 12:17:44 -0000 In-Reply-To: <009201c712c3$455109d0$6501a8c0@DGBP7M81> References: <20061128072611.D98702580EE@eikenes.alvestrand.no> <009201c712c3$455109d0$6501a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Tue, 28 Nov 2006 12:21:10 +0000 To: IETF Languages Discussion , TC46-L Information and Documentation Technology List , LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Mozilla Project translation into Irish Applied Translation Studies Subject: [Ltru] Re: LANGUAGE SUBTAG REGISTRATION FORM: Uralic Phonetic Alphabet X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 can support the proposal below, as a quick fix. Many thanks, mg On 28 Nov 2006, at 08:00, scr=EDobh Doug Ewell: > Michael Everson wrote: > ... >> Type: variant >> Subtag: fonipa >> Description: International Phonetic Alphabet >> ... > trying to find a way to tag phonetic content (primarily IPA) and =20 > most solutions involve an ISO 15924 registration... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 29 02:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJpk-00023a-Id; Wed, 29 Nov 2006 02:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpJpi-00021b-SW for ltru@lists.ietf.org; Wed, 29 Nov 2006 02:26:18 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpJpd-0005Wb-OB for ltru@lists.ietf.org; Wed, 29 Nov 2006 02:26:18 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kAT7Q2Tg001247 for ; Wed, 29 Nov 2006 16:26:02 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 585d_ddd77fbc_7f7a_11db_9ee0_0014221f2a2d; Wed, 29 Nov 2006 16:26:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52329) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 29 Nov 2006 16:25:24 +0900 Message-Id: <6.0.0.20.2.20061129150346.056b2120@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 29 Nov 2006 15:05:47 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Tag wisely (was: Phonetic orthographies) In-Reply-To: <456B0D23.8B1@xyzzy.claranet.de> References: <20061126110003.3CD9E2596D2@eikenes.alvestrand.no> <000f01c711e5$9f6d6c80$6501a8c0@DGBP7M81> <456B0D23.8B1@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Please don't use in xml2rfc. It is a particularly clear example of bad markup (there are others), and this use in this case would be visual only.] At 01:06 06/11/28, Frank Ellermann wrote: >Doug Ewell wrote on > >> John Cowan wrote: > >>> RFC 4646 says "tag wisely", *not* "tag exhaustively". > >> I wish it did say "tag wisely" a bit more explicitly, >> maybe even using those exact words. > >IMO chapter 4.1 is good as is, but we could add that as >motto at its beginning. Testing: > > >Tag wisely > > +-----------------------------------+ > | Tag wisely | > +-----------------------------------+ >Frank > > > >_______________________________________________ >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 Nov 29 12:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTHV-00014Z-Ot; Wed, 29 Nov 2006 12:31:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTHU-00014T-SG for ltru@ietf.org; Wed, 29 Nov 2006 12:31:36 -0500 Received: from qb-out-0506.google.com ([72.14.204.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpTHP-0004hZ-GS for ltru@ietf.org; Wed, 29 Nov 2006 12:31:36 -0500 Received: by qb-out-0506.google.com with SMTP id q12so1569190qba for ; Wed, 29 Nov 2006 09:31:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=GOkv3UjyTxf7dNn4UjIsIH/q7Yfvaa1cuveKs3R8+nUyTyICB9eRSXqs3VDeP81BbEqCbgeIzD21eQjRLiJwBpKOFjZoajkAnwRUFtaZ4lLm8aRP15Nd+lFf6HtwJ4yNArQ27LoRp2Jf1jNcL/YUPTDwZ0HkUN+AKlZofNdldOs= Received: by 10.100.132.16 with SMTP id f16mr320048and.1164821490605; Wed, 29 Nov 2006 09:31:30 -0800 (PST) Received: by 10.100.8.6 with HTTP; Wed, 29 Nov 2006 09:31:30 -0800 (PST) Message-ID: <30b660a20611290931v50a7f0d9s7c5d798d316996c@mail.gmail.com> Date: Wed, 29 Nov 2006 09:31:30 -0800 From: "Mark Davis" To: "Peter Constable" MIME-Version: 1.0 X-Google-Sender-Auth: 4297887f8713f213 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Markus Scherer , LTRU Working Group Subject: [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0000019289==" Errors-To: ltru-bounces@ietf.org --===============0000019289== Content-Type: multipart/alternative; boundary="----=_Part_3620_3837899.1164821490584" ------=_Part_3620_3837899.1164821490584 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline UGV0ZXIsIEkgc2VlIGFuIG9kZGl0eSBpbiB0aGUgdGFibGVzLgoKZ3N3ICAgZ3N3ICAgZ3N3ICAg ICAgSSAgIEwgICBBbGVtYW5pYwoKQXQgbGVhc3QgaW4gdGhlIEV0aG5vbG9ndWUsIGdzdyBpcyBT d2lzcyBHZXJtYW4gKApodHRwOi8vd3d3LmV0aG5vbG9ndWUuY29tL3Nob3dfbGFuZ3VhZ2UuYXNw P2NvZGU9Z3N3KSwgd2hpY2ggaXMgbm90IHRoZSBzYW1lCmFzIEFsZW1hbmljIC0tIGl0J3MgYSAi c3VidHlwZSIgb2YgQWxlbWFuaWMuCgpJcyBpdCB0aGUgaW50ZW50aW9uIHRoYXQgZ3N3IGJlIGFu eSBBbGVtYW5pYywgYW5kIHRoYXQgdGhlbiBnc3ctQ0ggYmUgU3dpc3MKR2VybWFuLCBhbmQgZGUt Q0ggYmUgdGhlIFN3aXNzIGZvcm0gb2YgSGlnaCBHZXJtYW4gKGVnIHdyaXR0ZW4gd2l0aCDDnwpp bnN0ZWFkIG9mIHNzKT8KCklTTyA2MzktMiBpcyBhIGJpdCB1bmNsZWFyLCBsaXN0aW5nIGJvdGgu Cgpnc3cgICAgICAgICAgICAgQWxlbWFuaTsgU3dpc3MgR2VybWFuICAgICAgYWzDqW1hbmlxdWUK CihCeSB0aGUgd2F5LCBpbiB0ZXJtcyBvZiBtdXR1YWwgaW50ZWxsaWdpYmlsaXR5LCBJIGZvdW5k IHRoYXQgZGVzcGl0ZSBiZWluZwphYmxlIHRvIHVuZGVyc3RhbmQgIlJoaW5lIFZhbGxleSIgU3dp c3MgR2VybWFuLCBJIHdhcyBub3QgcmVhbGx5IGFibGUgdG8KdW5kZXJzdGFuZCAiV2FsbGlzIiBT d2lzcyBHZXJtYW4uIEkgYWxzbyBub3RpY2VkIHRoYXQgd2lraXBlZGlhIHdhcyB1c2luZwoiYWxz IiBmb3IgQWxlbWFuaWMgKGVnIGh0dHA6Ly9hbHMud2lraXBlZGlhLm9yZykgd2hlbiAiZ3N3IiBp cyBhbHJlYWR5IGluCklTTyA2MzktMiwgYW5kICJhbHMiIHdpbGwgYmUgVG9zayBBbGJhbmlhbiBp biA2MzktMy4pCgpNYXJrCgpPbiAxMS8yMi8wNiwgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBt aWNyb3NvZnQuY29tPiB3cm90ZToKPgo+ID4gRnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRld2Vs bEBhZGVscGhpYS5uZXRdCj4KPiA+IEkgbm90ZSB0aGF0IHRoZSAiU2NvcGUiIGZpZWxkIGluIDYz OS0zIG1pcnJvcnMgdGhlICJUeXBlIiBmaWVsZCBmb3IgdGhlCj4gPiAic3BlY2lhbCIgKCJTIikg Y29kZXMgbXVsLCB1bmQsIGFuZCB6eHguCj4KPiBZZXMuIFRoYXQncyBub3Qgc3VycHJpc2luZyBz aW5jZSB0aGVzZSBhcmUgcmVhbGx5IGV4Y2VwdGlvbmFsLAo+IHNpbmd1bGFyaXRpZXMgLS0gc3Bl Y2lhbCBjYXNlcyB0byB3aGljaCBub3JtYWwgYmVoYXZpb3VycyBkbyBub3QgYXBwbHkuCj4KPgo+ Cj4gUGV0ZXIgQ29uc3RhYmxlCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+Cj4K ------=_Part_3620_3837899.1164821490584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UGV0ZXIsIEkgc2VlIGFuIG9kZGl0eSBpbiB0aGUgdGFibGVzLjxzcGFuPjxicj4mbmJzcDsmbmJz cDsgPGJyPmdzdyZuYnNwOyZuYnNwOyBnc3cmbmJzcDsmbmJzcDsgZ3N3Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyBJJm5ic3A7Jm5ic3A7IEwmbmJzcDsmbmJzcDsgQWxlbWFuaWM8YnI+IDxicj5B dCBsZWFzdCBpbiB0aGUgRXRobm9sb2d1ZSwgZ3N3IGlzIFN3aXNzIEdlcm1hbiAoPC9zcGFuPjxm b250IGZhY2U9IkhlbHZldGljYSxBcmlhbCIgc2l6ZT0iLTEiPjxhIGhyZWY9Imh0dHA6Ly93d3cu ZXRobm9sb2d1ZS5jb20vc2hvd19sYW5ndWFnZS5hc3A/Y29kZT1nc3ciPgpodHRwOi8vd3d3LmV0 aG5vbG9ndWUuY29tL3Nob3dfbGFuZ3VhZ2UuYXNwP2NvZGU9Z3N3PC9hPiksIHdoaWNoIGlzIG5v dCB0aGUgc2FtZSBhcyBBbGVtYW5pYyAtLSBpdCdzIGEgJnF1b3Q7c3VidHlwZSZxdW90OyBvZiBB bGVtYW5pYy48YnI+PGJyPklzIGl0IHRoZSBpbnRlbnRpb24gdGhhdCBnc3cgYmUgYW55IEFsZW1h bmljLCBhbmQgdGhhdCB0aGVuIGdzdy1DSCBiZSBTd2lzcyBHZXJtYW4sIGFuZCBkZS1DSCBiZSB0 aGUgU3dpc3MgZm9ybSBvZiBIaWdoIEdlcm1hbiAoCjwvZm9udD48Zm9udCBmYWNlPSJIZWx2ZXRp Y2EsQXJpYWwiIHNpemU9Ii0xIj5lZyB3cml0dGVuIHdpdGggw58gaW5zdGVhZCBvZiBzcyk/PGJy Pjxicj5JU08gNjM5LTIgaXMgYSBiaXQgdW5jbGVhciwgbGlzdGluZyBib3RoLjxicj48YnI+Z3N3 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 IEFsZW1hbmk7IFN3aXNzIEdlcm1hbiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgYWzDqW1hbmlx dWU8YnI+PC9mb250Pjxmb250IGZhY2U9IkhlbHZldGljYSxBcmlhbCIgc2l6ZT0iLTEiPgo8YnI+ PC9mb250PjxzcGFuPihCeSB0aGUgd2F5LCBpbiB0ZXJtcyBvZiBtdXR1YWwgaW50ZWxsaWdpYmls aXR5LCBJIGZvdW5kIHRoYXQgZGVzcGl0ZSBiZWluZyBhYmxlIHRvIHVuZGVyc3RhbmQgJnF1b3Q7 UmhpbmUgVmFsbGV5JnF1b3Q7IFN3aXNzIEdlcm1hbiwgSSB3YXMgbm90IHJlYWxseSBhYmxlIHRv IHVuZGVyc3RhbmQgJnF1b3Q7V2FsbGlzJnF1b3Q7IFN3aXNzIEdlcm1hbi4gPC9zcGFuPgo8Zm9u dCBmYWNlPSJIZWx2ZXRpY2EsQXJpYWwiIHNpemU9Ii0xIj5JIGFsc28gbm90aWNlZCB0aGF0IHdp a2lwZWRpYSB3YXMgdXNpbmcgJnF1b3Q7YWxzJnF1b3Q7IGZvciBBbGVtYW5pYyAoZWcgPGEgaHJl Zj0iaHR0cDovL2Fscy53aWtpcGVkaWEub3JnIj5odHRwOi8vYWxzLndpa2lwZWRpYS5vcmc8L2E+ KSB3aGVuICZxdW90O2dzdyZxdW90OyBpcyBhbHJlYWR5IGluIElTTyA2MzktMiwgYW5kICZxdW90 O2FscyZxdW90OyB3aWxsIGJlIAo8L2ZvbnQ+PHNwYW4+VG9zayBBbGJhbmlhbiBpbiA2MzktMy4p PGJyPjwvc3Bhbj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsQXJpYWwiIHNpemU9Ii0xIj48YnI+TWFy azxicj48L2ZvbnQ+PHNwYW4+PGJyPk9uIDExLzIyLzwvc3Bhbj48ZGl2PjxzcGFuIGNsYXNzPSJn bWFpbF9xdW90ZSI+MDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5QZXRlciBDb25zdGFi bGU8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+CnBldGVy Y29uQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Jmd0 OyBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRld2VsbEBhZGVscGhp YS5uZXQiPgpkZXdlbGxAYWRlbHBoaWEubmV0PC9hPl08YnI+PGJyPiZndDsgSSBub3RlIHRoYXQg dGhlICZxdW90O1Njb3BlJnF1b3Q7IGZpZWxkIGluIDYzOS0zIG1pcnJvcnMgdGhlICZxdW90O1R5 cGUmcXVvdDsgZmllbGQgZm9yIHRoZTxicj4mZ3Q7ICZxdW90O3NwZWNpYWwmcXVvdDsgKCZxdW90 O1MmcXVvdDspIGNvZGVzIG11bCwgdW5kLCBhbmQgenh4Ljxicj48YnI+WWVzLiBUaGF0J3Mgbm90 IHN1cnByaXNpbmcgc2luY2UgdGhlc2UgYXJlIHJlYWxseSBleGNlcHRpb25hbCwgc2luZ3VsYXJp dGllcyAtLSBzcGVjaWFsIGNhc2VzIHRvIHdoaWNoIG5vcm1hbCBiZWhhdmlvdXJzIGRvIG5vdCBh cHBseS4KPGJyPjxicj48YnI+PGJyPlBldGVyIENvbnN0YWJsZTxicj48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiPmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPC9hPjxicj48YnI+PGJyPjwv YmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_3620_3837899.1164821490584-- --===============0000019289== 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 --===============0000019289==-- From ltru-bounces@ietf.org Wed Nov 29 16:19:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWq6-0005ec-Vg; Wed, 29 Nov 2006 16:19:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWq4-0005eQ-Pt for ltru@ietf.org; Wed, 29 Nov 2006 16:19:32 -0500 Received: from mail5.microsoft.com ([205.248.106.30] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWq0-0006zq-2U for ltru@ietf.org; Wed, 29 Nov 2006 16:19:32 -0500 Received: from mailout4.microsoft.com (157.57.217.12) by SVC-EXGWY-E802.partners.extranet.microsoft.com (10.251.24.243) with Microsoft SMTP Server id 8.0.685.15; Wed, 29 Nov 2006 13:19:27 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 13:19:27 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Nov 2006 13:18:57 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109B52EAA@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <30b660a20611290931v50a7f0d9s7c5d798d316996c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Swiss German (was ISO/FDIS 639-3 tables revised) Thread-Index: AccT3Fz5ioaxpFjERF68DKtF2ROlbgAHbW2w From: Peter Constable To: Mark Davis , X-OriginalArrivalTime: 29 Nov 2006 21:19:27.0003 (UTC) FILETIME=[0CC14EB0:01C713FC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: Markus Scherer , LTRU Working Group Subject: [Ltru] RE: Swiss German (was ISO/FDIS 639-3 tables revised) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0903463844==" Errors-To: ltru-bounces@ietf.org --===============0903463844== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C713FB.F4455A68" ------_=_NextPart_001_01C713FB.F4455A68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The intent is the same semantic as the corresponding Ethnologue entry. I = believe "Alemanic" and "Swiss German" are listed as alternate names, = probably along with "Schwyzerd=FCtsch" and "Allemanisch". (I haven't = checked the updated data files Joan has posted.)=20 =20 (Re what 639-2 lists -- "Alemani[c]; Swiss German" -- there's a typo - = the "c" is missing, but it's clearly intended). =20 I know that "Alemanic" is also used to refer to a grouping of Germanic = languages; this is clear from Ethnologue, which lists Swabian, Walser = (apparently =3D "Wallis") and also "Colonia Tovar German" (spoken in = Venezuela). =20 As for what Wikipedia does, it's not the first time I've seen them using = their own alpha-3 IDs. Naturally, I consider that bad. =20 =20 Peter =20 ________________________________ From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis Sent: Wednesday, November 29, 2006 9:32 AM To: Peter Constable Cc: LTRU Working Group; Martin Duerst; Markus Scherer Subject: Swiss German (was ISO/FDIS 639-3 tables revised) =20 Peter, I see an oddity in the tables. =20 gsw gsw gsw I L Alemanic At least in the Ethnologue, gsw is Swiss German ( = http://www.ethnologue.com/show_language.asp?code=3Dgsw = ), which is not = the same as Alemanic -- it's a "subtype" of Alemanic. Is it the intention that gsw be any Alemanic, and that then gsw-CH be = Swiss German, and de-CH be the Swiss form of High German ( eg written = with =DF instead of ss)? ISO 639-2 is a bit unclear, listing both. gsw Alemani; Swiss German al=E9manique (By the way, in terms of mutual intelligibility, I found that despite = being able to understand "Rhine Valley" Swiss German, I was not really = able to understand "Wallis" Swiss German. I also noticed that wikipedia = was using "als" for Alemanic (eg http://als.wikipedia.org) when "gsw" is = already in ISO 639-2, and "als" will be Tosk Albanian in 639-3.) Mark On 11/22/ 06, Peter Constable < petercon@microsoft.com = > wrote: > From: Doug Ewell [mailto: dewell@adelphia.net = ] > I note that the "Scope" field in 639-3 mirrors the "Type" field for = the > "special" ("S") codes mul, und, and zxx. Yes. That's not surprising since these are really exceptional, = singularities -- special cases to which normal behaviours do not apply.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru=20 =20 ------_=_NextPart_001_01C713FB.F4455A68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The intent is the same semantic as = the corresponding Ethnologue entry. I believe “Alemanic” and = “Swiss German” are listed as alternate names, probably along with = “Schwyzerd=FCtsch” and “Allemanisch”. (I haven’t checked the updated data = files Joan has posted.)

 

(Re what 639-2 lists -- = “Alemani[c]; Swiss German” -- there’s a typo – the “c” = is missing, but it’s clearly intended).

 

I know that “Alemanic” = is also used to refer to a grouping of Germanic languages; this is clear from Ethnologue, which lists Swabian, Walser (apparently =3D = “Wallis”) and also “Colonia Tovar German” (spoken in Venezuela).

 

As for what Wikipedia does, = it’s not the first time I’ve seen them using their own alpha-3 IDs. = Naturally, I consider that bad.

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] = On Behalf Of Mark Davis
Sent: Wednesday, November = 29, 2006 9:32 AM
To: Peter Constable
Cc: LTRU Working Group; = Martin Duerst; Markus Scherer
Subject: Swiss German = (was ISO/FDIS 639-3 tables revised)

 

Peter, I see an oddity in the tables.
  
gsw   gsw   gsw      = I   L   Alemanic

At least in the Ethnologue, gsw is Swiss German ( = http://www.ethnologue.com/show_language.asp?code=3Dgsw), which is not the same as Alemanic -- it's a "subtype" of = Alemanic.

Is it the intention that gsw be any Alemanic, and that then gsw-CH be = Swiss German, and de-CH be the Swiss form of High German ( eg written with =DF = instead of ss)?

ISO 639-2 is a bit unclear, listing both.

gsw             Alemani; = Swiss German      al=E9manique

(By the way, in terms of mutual intelligibility, I found = that despite being able to understand "Rhine Valley" Swiss German, I was not really able to understand "Wallis" = Swiss German. I also noticed that wikipedia was using "als" for = Alemanic (eg http://als.wikipedia.org) = when "gsw" is already in ISO 639-2, and "als" will be = Tosk Albanian in 639-3.)

Mark

On 11/22/

06, Peter Constable = < petercon@microsoft.com> = wrote:

> From: = Doug Ewell [mailto: = dewell@adelphia.net]

> I note that the "Scope" field in 639-3 mirrors the "Type" field for the
> "special" ("S") codes mul, und, and zxx.

Yes. That's not surprising since these are really exceptional, = singularities -- special cases to which normal behaviours do not apply.



Peter Constable

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

 

------_=_NextPart_001_01C713FB.F4455A68-- --===============0903463844== 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 --===============0903463844==-- From ltru-bounces@ietf.org Wed Nov 29 16:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX1F-0007LG-Fl; Wed, 29 Nov 2006 16:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX1E-0007Il-7W for ltru@ietf.org; Wed, 29 Nov 2006 16:31:04 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpX1D-0008PX-1w for ltru@ietf.org; Wed, 29 Nov 2006 16:31:04 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GpX17-0004c0-Dy; Wed, 29 Nov 2006 16:30:57 -0500 Date: Wed, 29 Nov 2006 16:30:57 -0500 To: Peter Constable Subject: Re: [Ltru] RE: Swiss German (was ISO/FDIS 639-3 tables revised) Message-ID: <20061129213057.GH10966@ccil.org> References: <30b660a20611290931v50a7f0d9s7c5d798d316996c@mail.gmail.com> <19A328037921AA42847A717566D1D6A109B52EAA@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19A328037921AA42847A717566D1D6A109B52EAA@RED-MSG-42.redmond.corp.microsoft.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group , ISO639-3@sil.org, Markus Scherer X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > I know that "Alemanic" is also used to refer to a grouping of Germanic > languages; this is clear from Ethnologue, which lists Swabian, Walser > (apparently = "Wallis") and also "Colonia Tovar German" (spoken in > Venezuela). This often happens. Ethnologue uses "Japanese" as both the name for Japanese proper and for the (top-level) tree node that includes both Japanese proper and the Ryukyuan languages. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 29 21:16:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbTM-0004ux-KO; Wed, 29 Nov 2006 21:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbTL-0004ur-9o for ltru@ietf.org; Wed, 29 Nov 2006 21:16:23 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpbTH-0004iJ-EE for ltru@ietf.org; Wed, 29 Nov 2006 21:16:23 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id kAU2GHqK004394 for ; Thu, 30 Nov 2006 11:16:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0460_c3142bb4_8018_11db_9ebc_0014221fa3c9; Thu, 30 Nov 2006 11:16:17 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:38378) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 30 Nov 2006 11:15:39 +0900 Message-Id: <6.0.0.20.2.20061130094404.05650dc0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 30 Nov 2006 10:00:35 +0900 To: Peter Constable , Mark Davis , From: Martin Duerst In-Reply-To: <19A328037921AA42847A717566D1D6A109B52EAA@RED-MSG-42.redmon d.corp.microsoft.com> References: <30b660a20611290931v50a7f0d9s7c5d798d316996c@mail.gmail.com> <19A328037921AA42847A717566D1D6A109B52EAA@RED-MSG-42.redmond.corp.microsoft.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 kAU2GHqK004394 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Markus Scherer , LTRU Working Group Subject: [Ltru] RE: Swiss German (was ISO/FDIS 639-3 tables revised) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 06:18 06/11/30, Peter Constable wrote: >The intent is the same semantic as the corresponding Ethnologue entry. I= believe =1B$BE"=1B(Blemanic=1B$BG=01=1B(Band =1B$BE4=1B(Bwiss German=1B$= BG=01=1B(Bare listed as alternate names, probably along with =1B$BE4=1B(B= chwyzerd=1B$B=97U=1B(Bsch=1B$BG=01=1B(Band =1B$BE"=1B(Bllemanisch=1B$BG=0F= =1B(B (I haven=1B$BCU=1B(B checked the updated data files Joan has posted= .)=20 >=20 >(Re what 639-2 lists -- =1B$BE"=1B(Blemani[c]; Swiss German=1B$BG=01=1B(= B-- there=1B$BCT=1B(B a typo =1B$BK=01=1B(Bthe =1B$BEDG=01=1B(Bis missing= , but it=1B$BCT=1B(B clearly intended). >=20 >I know that =1B$BE"=1B(Blemanic=1B$BG=01=1B(Bis also used to refer to a = grouping of Germanic languages; this is clear from Ethnologue, which list= s Swabian, Yes, Swabian is clearly Alemanic. Alemanic and Swiss German are not the same. There are very close similarities between some dialects in the north of Switzerland and across the border in Germany, but as soon as you cross the border, it's very clearly no longer Swiss German. A label such as "Alemanic; Swiss German", assuming that both are the same, is clearly wrong. If it's something like "Alemanic; includes Swiss German", that would be okay. >Walser (apparently =3D =1B$BE8=1B(Ballis=1B$BG =1B(B Walser is the name of people who *emigrated* south and west *from* the Wallis, in the 12th and 13th century. See e.g. http://en.wikipedia.org/wiki/Walser. So it's not the same, although there are a lot of similarities. >and also =1B$BE$=1B(Bolonia Tovar German=1B$BG=01=1B(B(spoken in Venezue= la). There may be all kinds of Germans that go into the same group if they emigrated from areas where Alemanic was/is spoken. > >---------- >From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] O= n Behalf Of Mark Davis >Sent: Wednesday, November 29, 2006 9:32 AM >Peter, I see an oddity in the tables. > =20 >gsw gsw gsw I L Alemanic > >At least in the Ethnologue, gsw is Swiss German ( http://www.ethnologue.= com/show_language.asp?code=3Dgsw), which is not the same as Alemanic -- i= t's a "subtype" of Alemanic. > >Is it the intention that gsw be any Alemanic, and that then gsw-CH be Sw= iss German, and de-CH be the Swiss form of High German ( eg written with = =1B$B!,=1B(B instead of ss)? This would be one way to make things work. But first, it should be made clear exactly what is intended. >ISO 639-2 is a bit unclear, listing both. > >gsw Alemani; Swiss German al=1B$BqN=1B(Banique > >(By the way, in terms of mutual intelligibility, I found that despite be= ing able to understand "Rhine Valley" Swiss German, I was not really able= to understand "Wallis" Swiss German. That's easily possible. Regards, Martin. #-#-# 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 Nov 30 12:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppGb-0008Pq-Vu; Thu, 30 Nov 2006 12:00:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppGY-000837-9v for ltru@ietf.org; Thu, 30 Nov 2006 12:00:06 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppGV-0007gi-Op for ltru@ietf.org; Thu, 30 Nov 2006 12:00:06 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1038868wra for ; Thu, 30 Nov 2006 08:59:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=i4HRH6YkvFKmamZUG/6Cn03f+iICaXZ3KeINfY3QIgwA2qubvR9xD6C/1AfrgJPdtRB7P8mj2dYz8hL+XS3CLS2dYmqasoZz3PpFeiZN0nIKrPrl2kyFnwMkmZKbUMurQ1AGu1WKIrOW0BSxdgheaTyJQEjnsQP62Vc6V2OCTLw= Received: by 10.100.37.4 with SMTP id k4mr1021383ank.1164905997239; Thu, 30 Nov 2006 08:59:57 -0800 (PST) Received: by 10.100.8.6 with HTTP; Thu, 30 Nov 2006 08:59:57 -0800 (PST) Message-ID: <30b660a20611300859s7e39fbedn7365debb6184df7c@mail.gmail.com> Date: Thu, 30 Nov 2006 08:59:57 -0800 From: "Mark Davis" To: "=?UTF-8?Q?H=C3=A5vard_Hjulstad?=" , iso639-2@loc.gov MIME-Version: 1.0 X-Google-Sender-Auth: 6fe1e7093143eaae X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: LTRU Working Group , zaiitov@gmail.com, ISO 639 Joint Advisory Committee , ietf-languages@iana.org, iso639@dkuug.dk Subject: [Ltru] Alemanic & Swiss German X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1688967986==" Errors-To: ltru-bounces@ietf.org --===============1688967986== Content-Type: multipart/alternative; boundary="----=_Part_5534_18893602.1164905997216" ------=_Part_5534_18893602.1164905997216 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SVNPIDYzOS0yIChvbiBodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9j b2RlX2xpc3QucGhwKSBsaXN0cwp0aGUgZm9sbG93aW5nOgoKZ3N3ICAgICAgICAgICAgIEFsZW1h bmk7IFN3aXNzIEdlcm1hbiAgICAgIGFsw6ltYW5pcXVlCgpIb3dldmVyLCB0aGVyZSBpcyBhICJj IiBtaXNzaW5nIGZyb20gQWxlbWFuaWMsIGFuZCBTd2lzcyBHZXJtYW4gaXMgbm90IHRoZQpzYW1l IGFzIEFsZW1hbmljOiBTd2lzcyBHZXJtYW4gaXMgYSB0eXBlIG9mIEFsZW1hbmljLCBidXQgdGhl cmUgYXJlIG90aGVyCnR5cGVzIHRoYXQgYXJlIG5vdCB0aGUgc2FtZSBhcyBTd2lzcyBHZXJtYW4u CgpRdW90aW5nIE1hcnRpbiBEdWVyc3Q6CgoiWWVzLCBTd2FiaWFuIGlzIGNsZWFybHkgQWxlbWFu aWMuIEFsZW1hbmljIGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5vdAp0aGUgc2FtZS4gVGhlcmUgYXJl IHZlcnkgY2xvc2Ugc2ltaWxhcml0aWVzIGJldHdlZW4gc29tZSBkaWFsZWN0cyBpbgp0aGUgbm9y dGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9zcyB0aGUgYm9yZGVyIGluIEdlcm1hbnksIGJ1dCBh cwpzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyLCBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25n ZXIgU3dpc3MKR2VybWFuLiBBIGxhYmVsIHN1Y2ggYXMgIkFsZW1hbmljOyBTd2lzcyBHZXJtYW4i LCBhc3N1bWluZyB0aGF0CmJvdGggYXJlIHRoZSBzYW1lLCBpcyBjbGVhcmx5IHdyb25nLiBJZiBp dCdzIHNvbWV0aGluZyBsaWtlCiJBbGVtYW5pYzsgaW5jbHVkZXMgU3dpc3MgR2VybWFuIiwgdGhh dCB3b3VsZCBiZSBva2F5LiIKCkNhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMg bm90IGNvbnRpbnVlIHRvIG1pc2xlYWQgcGVvcGxlPwoKTWFyayBEYXZpcwo= ------=_Part_5534_18893602.1164905997216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGZvbnQgZmFjZT0iSGVsdmV0aWNhLEFyaWFsIiBzaXplPSItMSI+SVNPIDYzOS0yIChvbiA8YSBo cmVmPSJodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3Qu cGhwIj5odHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3Qu cGhwPC9hPikgbGlzdHMgdGhlIGZvbGxvd2luZzo8YnI+PGJyPmdzdyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBBbGVtYW5pOyBTd2lzcyBH ZXJtYW4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGFsw6ltYW5pcXVlCjxicj48YnI+SG93ZXZl ciwgdGhlcmUgaXMgYSAmcXVvdDtjJnF1b3Q7IG1pc3NpbmcgZnJvbSBBbGVtYW5pYywgYW5kIFN3 aXNzIEdlcm1hbiBpcyBub3QgdGhlIHNhbWUgYXMgQWxlbWFuaWM6IFN3aXNzIEdlcm1hbiBpcyBh IHR5cGUgb2YgQWxlbWFuaWMsIGJ1dCB0aGVyZSBhcmUgb3RoZXIgdHlwZXMgdGhhdCBhcmUgbm90 IHRoZSBzYW1lIGFzIFN3aXNzIEdlcm1hbi48YnI+PGJyPlF1b3RpbmcgTWFydGluIER1ZXJzdDoK PGJyPjxicj48L2ZvbnQ+JnF1b3Q7WWVzLCBTd2FiaWFuIGlzIGNsZWFybHkgPHNwYW4gaWQ9InN0 IiBuYW1lPSJzdCIgY2xhc3M9InN0Ij5BbGVtYW5pYzwvc3Bhbj4uIDxzcGFuIGlkPSJzdCIgbmFt ZT0ic3QiIGNsYXNzPSJzdCI+QWxlbWFuaWM8L3NwYW4+IGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5v dDxicj50aGUgc2FtZS4gVGhlcmUgYXJlIHZlcnkgY2xvc2Ugc2ltaWxhcml0aWVzIGJldHdlZW4g c29tZSBkaWFsZWN0cyBpbgo8YnI+dGhlIG5vcnRoIG9mIFN3aXR6ZXJsYW5kIGFuZCBhY3Jvc3Mg dGhlIGJvcmRlciBpbiBHZXJtYW55LCBidXQgYXM8YnI+c29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJv cmRlciwgaXQncyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzPGJyPkdlcm1hbi4gQSBsYWJl bCBzdWNoIGFzICZxdW90OzxzcGFuIGlkPSJzdCIgbmFtZT0ic3QiIGNsYXNzPSJzdCI+QWxlbWFu aWM8L3NwYW4+OyBTd2lzcyBHZXJtYW4mcXVvdDssIGFzc3VtaW5nIHRoYXQKPGJyPmJvdGggYXJl IHRoZSBzYW1lLCBpcyBjbGVhcmx5IHdyb25nLiBJZiBpdCdzIHNvbWV0aGluZyBsaWtlPGJyPiZx dW90OzxzcGFuIGlkPSJzdCIgbmFtZT0ic3QiIGNsYXNzPSJzdCI+QWxlbWFuaWM8L3NwYW4+OyBp bmNsdWRlcyBTd2lzcyBHZXJtYW4mcXVvdDssIHRoYXQgd291bGQgYmUgb2theS4mcXVvdDs8YnI+ PGJyPkNhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRpbnVlIHRv IG1pc2xlYWQgcGVvcGxlPwo8YnI+PGJyPk1hcmsgRGF2aXM8YnI+PHNwYW4+PC9zcGFuPgo= ------=_Part_5534_18893602.1164905997216-- --===============1688967986== 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 --===============1688967986==-- From ltru-bounces@ietf.org Thu Nov 30 12:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppgu-0006ot-Kj; Thu, 30 Nov 2006 12:27:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppgt-0006og-L8 for ltru@ietf.org; Thu, 30 Nov 2006 12:27:19 -0500 Received: from mailb.microsoft.com ([205.248.106.30] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gppgp-0002Mw-0Z for ltru@ietf.org; Thu, 30 Nov 2006 12:27:19 -0500 Received: from mailout4.microsoft.com (157.57.217.12) by SVC-EXGWY-E802.partners.extranet.microsoft.com (10.251.24.243) with Microsoft SMTP Server id 8.0.685.23; Thu, 30 Nov 2006 09:27:14 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 09:27:14 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Alemanic & Swiss German Date: Thu, 30 Nov 2006 09:26:31 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109BC387F@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <30b660a20611300859s7e39fbedn7365debb6184df7c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Alemanic & Swiss German Thread-Index: AccUoRHHYRsnoQUdTxmYFqRzP9stKQAA0J2Q From: Peter Constable To: Mark Davis , =?utf-8?B?SMOldmFyZCBIanVsc3RhZA==?= , X-OriginalArrivalTime: 30 Nov 2006 17:27:14.0022 (UTC) FILETIME=[C676E060:01C714A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: LTRU Working Group , zaiitov@gmail.com, ISO, Advisory Committee , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1577346390==" Errors-To: ltru-bounces@ietf.org --===============1577346390== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C714A4.AD441DAB" ------_=_NextPart_001_01C714A4.AD441DAB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFydGlu4oCZcyBjb21tZW50IGlzIHNvbWV3aGF0IHZhZ3VlOiB2YXJpZXRpZXMgc3Bva2VuIG9u IGVpdGhlciBzaWRlIG9mIHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwgZXQg4oCcYXMgc29v biBhcyB5b3UgY3Jvc3MgdGhlIGJvcmRlciBpdOKAmXMgdmVyeSBjbGVhcmx5IG5vIGxvbmdlciBT d2lzcyBHZXJtYW7igJ0uIERvZXMgdGhhdCBtZWFuIHRoYXQgd2hhdCBpcyBzcG9rZW4gYWNyb3Nz IHRoZSBib3JkZXIgaXMgY2xlYXJseSBhIGRpZmZlcmVudCBsYW5ndWFnZSwgb3IgdGhhdCB0aGUg bGFiZWwg4oCcU3dpc3MgR2VybWFu4oCdIGlzIGNsZWFybHkgbm90IHVzZWQ/DQogDQogDQpQZXRl cg0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogTWFyayBEYXZp cyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXSANClNlbnQ6IFRodXJzZGF5LCBO b3ZlbWJlciAzMCwgMjAwNiA5OjAwIEFNDQpUbzogSMOldmFyZCBIanVsc3RhZDsgaXNvNjM5LTJA bG9jLmdvdg0KQ2M6IExUUlUgV29ya2luZyBHcm91cDsgemFpaXRvdkBnbWFpbC5jb207IElTTyA2 MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlOyBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsgaXNv NjM5QGRrdXVnLmRrDQpTdWJqZWN0OiBbTHRydV0gQWxlbWFuaWMgJiBTd2lzcyBHZXJtYW4NCiAN CklTTyA2MzktMiAob24gaHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi9waHAv Y29kZV9saXN0LnBocCkgbGlzdHMgdGhlIGZvbGxvd2luZzoNCg0KZ3N3ICAgICAgICAgICAgIEFs ZW1hbmk7IFN3aXNzIEdlcm1hbiAgICAgIGFsw6ltYW5pcXVlIA0KDQpIb3dldmVyLCB0aGVyZSBp cyBhICJjIiBtaXNzaW5nIGZyb20gQWxlbWFuaWMsIGFuZCBTd2lzcyBHZXJtYW4gaXMgbm90IHRo ZSBzYW1lIGFzIEFsZW1hbmljOiBTd2lzcyBHZXJtYW4gaXMgYSB0eXBlIG9mIEFsZW1hbmljLCBi dXQgdGhlcmUgYXJlIG90aGVyIHR5cGVzIHRoYXQgYXJlIG5vdCB0aGUgc2FtZSBhcyBTd2lzcyBH ZXJtYW4uDQoNClF1b3RpbmcgTWFydGluIER1ZXJzdDogDQoNCiJZZXMsIFN3YWJpYW4gaXMgY2xl YXJseSBBbGVtYW5pYy4gQWxlbWFuaWMgYW5kIFN3aXNzIEdlcm1hbiBhcmUgbm90DQp0aGUgc2Ft ZS4gVGhlcmUgYXJlIHZlcnkgY2xvc2Ugc2ltaWxhcml0aWVzIGJldHdlZW4gc29tZSBkaWFsZWN0 cyBpbiANCnRoZSBub3J0aCBvZiBTd2l0emVybGFuZCBhbmQgYWNyb3NzIHRoZSBib3JkZXIgaW4g R2VybWFueSwgYnV0IGFzDQpzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyLCBpdCdzIHZlcnkg Y2xlYXJseSBubyBsb25nZXIgU3dpc3MNCkdlcm1hbi4gQSBsYWJlbCBzdWNoIGFzICJBbGVtYW5p YzsgU3dpc3MgR2VybWFuIiwgYXNzdW1pbmcgdGhhdCANCmJvdGggYXJlIHRoZSBzYW1lLCBpcyBj bGVhcmx5IHdyb25nLiBJZiBpdCdzIHNvbWV0aGluZyBsaWtlDQoiQWxlbWFuaWM7IGluY2x1ZGVz IFN3aXNzIEdlcm1hbiIsIHRoYXQgd291bGQgYmUgb2theS4iDQoNCkNhbiB0aGlzIGJlIGNvcnJl Y3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRpbnVlIHRvIG1pc2xlYWQgcGVvcGxlPyANCg0K TWFyayBEYXZpcw0K ------_=_NextPart_001_01C714A4.AD441DAB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPVByb2dJZCBjb250 ZW50PVdvcmQuRG9jdW1lbnQ+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3Nv ZnQgV29yZCAxMSI+DQo8bWV0YSBuYW1lPU9yaWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdv cmQgMTEiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQzcx NDYxLjlFRDQxMUIwIj4NCjxsaW5rIHJlbD1FZGl0LVRpbWUtRGF0YSBocmVmPSJjaWQ6ZWRpdGRh dGEubXNvIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KICA8bzpEb05vdFJlbHlPbkNTUy8+DQogPC9v Ok9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OkRvbnREaXNwbGF5UGFnZUJvdW5k YXJpZXMvPg0KICA8dzpHcmFtbWFyU3RhdGU+Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpE b2N1bWVudEtpbmQ+RG9jdW1lbnRFbWFpbDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3Bl VmlzLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFs aWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZh bHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KIDwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpMYXRlbnRT dHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBMYXRlbnRTdHlsZUNvdW50PSIxNTYiPg0KIDwv dzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBG b250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0K CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxl Ow0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU1ODA5IC0xMDczNzExMDM3IDkgMCA1MTEgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJl Oi01MjAwNzg1OTMgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xNTkzODMzNzI5IDEwNzM3 NTAxMDcgMTYgMCA0MTUgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uc3QNCgl7bXNvLXN0eWxlLW5hbWU6 c3Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglt c28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OlZlcmRhbmE7 DQoJY29sb3I6Ymx1ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRl Y29yYXRpb246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lO30NCnNwYW4uR3JhbUUNCgl7 bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47DQoJ bXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1w YXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwv c3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gMTBdPg0KPHN0eWxlPg0KIC8qIFN0eWxlIERlZmluaXRp b25zICovIA0KIHRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBO b3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5k LXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0K CW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjow aW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndp ZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iOw0KCW1zby1hbnNpLWxhbmd1YWdlOiMwNDAwOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OiMwNDAwOw0KCW1zby1iaWRpLWxhbmd1YWdlOiMwNDAwO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0t LT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9Ymx1ZSBzdHls ZT0ndGFiLWludGVydmFsOi41aW4nPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1WZXJkYW5hPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibHVlJz5N YXJ0aW7igJlzIGNvbW1lbnQgaXMgc29tZXdoYXQgdmFndWU6IHZhcmlldGllcw0Kc3Bva2VuIG9u IGVpdGhlciBzaWRlIG9mIHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwgPHNwYW4gY2xhc3M9 R3JhbUU+ZXQ8L3NwYW4+DQrigJxhcyBzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyIGl04oCZ cyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzIEdlcm1hbuKAnS4gRG9lcw0KdGhhdCBtZWFu IHRoYXQgd2hhdCBpcyBzcG9rZW4gYWNyb3NzIHRoZSBib3JkZXIgaXMgY2xlYXJseSBhIGRpZmZl cmVudA0KbGFuZ3VhZ2UsIG9yIHRoYXQgdGhlIGxhYmVsIOKAnFN3aXNzIEdlcm1hbuKAnSBpcyBj bGVhcmx5IG5vdCB1c2VkPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPlBldGVyPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9VmVyZGFuYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OlZl cmRhbmE7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhy IHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+ PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9 VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21h O2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpm YWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhv bWEnPiBNYXJrIERhdmlzDQpbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXSA8YnI+ DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBUaHVy c2RheSwgTm92ZW1iZXIgMzAsIDIwMDYNCjk6MDAgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gSMOldmFyZCBIanVsc3RhZDsNCmlzbzYzOS0y QGxvYy5nb3Y8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFu PjwvYj4gTFRSVSBXb3JraW5nIEdyb3VwOw0KemFpaXRvdkBnbWFpbC5jb207IElTTyA2MzkgSm9p bnQgQWR2aXNvcnkgQ29tbWl0dGVlOyBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsNCmlzbzYzOUBk a3V1Zy5kazxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwv c3Bhbj48L2I+IFtMdHJ1XSBBbGVtYW5pYyAmYW1wOw0KU3dpc3MgR2VybWFuPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9SGVsdmV0aWNhPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6SGVsdmV0aWNhJz5JU08gNjM5LTIgKG9uIDxhDQpocmVmPSJo dHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhwIj5o dHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhwPC9h PikNCmxpc3RzIHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KZ3N3Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IEFsZW1hbmk7IFN3aXNzDQpH ZXJtYW4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGFsw6ltYW5pcXVlIDxicj4NCjxicj4NCkhv d2V2ZXIsIHRoZXJlIGlzIGEgJnF1b3Q7YyZxdW90OyBtaXNzaW5nIGZyb20gQWxlbWFuaWMsIGFu ZCBTd2lzcyBHZXJtYW4gaXMNCm5vdCB0aGUgc2FtZSBhcyBBbGVtYW5pYzogU3dpc3MgR2VybWFu IGlzIGEgdHlwZSBvZiBBbGVtYW5pYywgYnV0IHRoZXJlIGFyZQ0Kb3RoZXIgdHlwZXMgdGhhdCBh cmUgbm90IHRoZSBzYW1lIGFzIFN3aXNzIEdlcm1hbi48YnI+DQo8YnI+DQpRdW90aW5nIE1hcnRp biBEdWVyc3Q6IDxicj4NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+JnF1b3Q7WWVzLCBTd2FiaWFuIGlz IGNsZWFybHkgPHNwYW4gY2xhc3M9c3Q+PHNwYW4gbmFtZT1zdCBpZD1zdD5BbGVtYW5pYzwvc3Bh bj48L3NwYW4+Lg0KPHNwYW4gY2xhc3M9c3Q+PHNwYW4gbmFtZT1zdCBpZD1zdD5BbGVtYW5pYzwv c3Bhbj48L3NwYW4+IGFuZCBTd2lzcyBHZXJtYW4gYXJlDQpub3Q8YnI+DQp0aGUgc2FtZS4gVGhl cmUgYXJlIHZlcnkgY2xvc2Ugc2ltaWxhcml0aWVzIGJldHdlZW4gc29tZSBkaWFsZWN0cyBpbiA8 YnI+DQp0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9zcyB0aGUgYm9yZGVyIGluIEdl cm1hbnksIGJ1dCBhczxicj4NCnNvb24gYXMgeW91IGNyb3NzIHRoZSBib3JkZXIsIGl0J3MgdmVy eSBjbGVhcmx5IG5vIGxvbmdlciBTd2lzczxicj4NCkdlcm1hbi4gQSBsYWJlbCBzdWNoIGFzICZx dW90OzxzcGFuIGNsYXNzPXN0PjxzcGFuIG5hbWU9c3QgaWQ9c3Q+QWxlbWFuaWM8L3NwYW4+PC9z cGFuPjsNClN3aXNzIEdlcm1hbiZxdW90OywgYXNzdW1pbmcgdGhhdCA8YnI+DQpib3RoIGFyZSB0 aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZTxicj4NCiZx dW90OzxzcGFuIGNsYXNzPXN0PjxzcGFuIG5hbWU9c3QgaWQ9c3Q+QWxlbWFuaWM8L3NwYW4+PC9z cGFuPjsgaW5jbHVkZXMgU3dpc3MNCkdlcm1hbiZxdW90OywgdGhhdCB3b3VsZCBiZSBva2F5LiZx dW90Ozxicj4NCjxicj4NCkNhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90 IGNvbnRpbnVlIHRvIG1pc2xlYWQgcGVvcGxlPyA8YnI+DQo8YnI+DQpNYXJrIERhdmlzPG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C714A4.AD441DAB-- --===============1577346390== 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 --===============1577346390==-- From ltru-bounces@ietf.org Thu Nov 30 14:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprF6-0003D6-8F; Thu, 30 Nov 2006 14:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprF5-0003D1-KN for ltru@ietf.org; Thu, 30 Nov 2006 14:06:43 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprF4-0006fB-83 for ltru@ietf.org; Thu, 30 Nov 2006 14:06:43 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1073139wra for ; Thu, 30 Nov 2006 11:06:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=A55WtxxWLAdW5pe8OVUxawwdUE6B3oPX3fCI6dlm4iwU7r0pb/IH7koEbYSvC3QKIRaqOjpF4ERicu2dUAXADMVXTkTxDkBpyAO46Er1NpyQ71THsNU/PJejI0rHzfTwpIyizYkhaJ5v1hRQdb3azCtqBasjAv3hHIKA6KYtP+c= Received: by 10.100.124.5 with SMTP id w5mr1127500anc.1164913601816; Thu, 30 Nov 2006 11:06:41 -0800 (PST) Received: by 10.100.8.6 with HTTP; Thu, 30 Nov 2006 11:06:41 -0800 (PST) Message-ID: <30b660a20611301106q39e9f498lde14ebba3e97a996@mail.gmail.com> Date: Thu, 30 Nov 2006 11:06:41 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Alemanic & Swiss German In-Reply-To: <19A328037921AA42847A717566D1D6A109BC387F@RED-MSG-42.redmond.corp.microsoft.com> MIME-Version: 1.0 References: <30b660a20611300859s7e39fbedn7365debb6184df7c@mail.gmail.com> <19A328037921AA42847A717566D1D6A109BC387F@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: a54814c5d005f4bf X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: LTRU Working Group , zaiitov@gmail.com, iso639-2@loc.gov, =?UTF-8?Q?H=C3=A5vard_Hjulstad?= , ISO 639 Joint Advisory Committee , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0940306928==" Errors-To: ltru-bounces@ietf.org --===============0940306928== Content-Type: multipart/alternative; boundary="----=_Part_5879_21963159.1164913601784" ------=_Part_5879_21963159.1164913601784 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline QWxlbWFuaWMgcmVmZXJzIHRvIGEgYnJvYWRlciBncm91cCBvZiBkaWFsZWN0cyB0aGFuICJTd2lz cyBHZXJtYW4iIChha2EKU2Nod3l6ZXJ0dWVzY2gpIGRvZXMuIFNvIGxpc3RpbmcgdGhlbSBhcyBp dCBkb2VzIGlzIHByb2JsZW1hdGljOyBpdCdzIGxpa2UKbGlzdGluZwoKYXIgQXJhYmljOyBFZ3lw dGlhbiBBcmFiaWMKClBlcnNvbmFsbHksIEkgZG9uJ3QgY2FyZSB3aGV0aGVyIGl0IGlzIHJlc29s dmVkIHRvIGJlCgpBbGVtYW5pYyAoaW5jbHVkaW5nIFN3aXNzIEdlcm1hbikKLy8gd2hpY2ggaXMg d2hhdCA2MzktMyBzZWVtcyB0byBiZSBwb2ludGluZyB0bwoKb3IKClN3aXNzIEdlcm1hbiAoYSBw YXJ0aWN1bGFyIHZhcmlhbnQgb2YgQWxlbWFuaWMpCi8vIHdoaWNoIGlzIHdoYXQgdGhlIGNvZGUg KGdzdykgc2VlbXMgdG8gYmUgcG9pbnRpbmcgdG8KCkJ1dCB3ZSBuZWVkIHNvbWUgY2xhcml0eSBh cyB0byB3aGF0IGlzIG1lYW50IGJ5IHRoZSBjb2RlLgoKTWFyawoKT24gMTEvMzAvMDYsIFBldGVy IENvbnN0YWJsZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiAgTWFydGluJ3Mg Y29tbWVudCBpcyBzb21ld2hhdCB2YWd1ZTogdmFyaWV0aWVzIHNwb2tlbiBvbiBlaXRoZXIgc2lk ZSBvZgo+IHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwgZXQgImFzIHNvb24gYXMgeW91IGNy b3NzIHRoZSBib3JkZXIgaXQncyB2ZXJ5Cj4gY2xlYXJseSBubyBsb25nZXIgU3dpc3MgR2VybWFu Ii4gRG9lcyB0aGF0IG1lYW4gdGhhdCB3aGF0IGlzIHNwb2tlbiBhY3Jvc3MKPiB0aGUgYm9yZGVy IGlzIGNsZWFybHkgYSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9yIHRoYXQgdGhlIGxhYmVsICJTd2lz cyBHZXJtYW4iCj4gaXMgY2xlYXJseSBub3QgdXNlZD8KPgo+Cj4KPgo+Cj4gUGV0ZXIKPgo+Cj4g ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+ICpGcm9tOiogTWFyayBEYXZpcyBb bWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQo+ICpTZW50OiogVGh1cnNkYXksIE5v dmVtYmVyIDMwLCAyMDA2IDk6MDAgQU0KPiAqVG86KiBIw6V2YXJkIEhqdWxzdGFkOyBpc282Mzkt MkBsb2MuZ292Cj4gKkNjOiogTFRSVSBXb3JraW5nIEdyb3VwOyB6YWlpdG92QGdtYWlsLmNvbTsg SVNPIDYzOSBKb2ludCBBZHZpc29yeQo+IENvbW1pdHRlZTsgaWV0Zi1sYW5ndWFnZXNAaWFuYS5v cmc7IGlzbzYzOUBka3V1Zy5kawo+ICpTdWJqZWN0OiogW0x0cnVdIEFsZW1hbmljICYgU3dpc3Mg R2VybWFuCj4KPgo+Cj4gSVNPIDYzOS0yIChvbiBodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRz L2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhwKQo+IGxpc3RzIHRoZSBmb2xsb3dpbmc6Cj4KPiBn c3cgICAgICAgICAgICAgQWxlbWFuaTsgU3dpc3MgR2VybWFuICAgICAgYWzDqW1hbmlxdWUKPgo+ IEhvd2V2ZXIsIHRoZXJlIGlzIGEgImMiIG1pc3NpbmcgZnJvbSBBbGVtYW5pYywgYW5kIFN3aXNz IEdlcm1hbiBpcyBub3QgdGhlCj4gc2FtZSBhcyBBbGVtYW5pYzogU3dpc3MgR2VybWFuIGlzIGEg dHlwZSBvZiBBbGVtYW5pYywgYnV0IHRoZXJlIGFyZSBvdGhlcgo+IHR5cGVzIHRoYXQgYXJlIG5v dCB0aGUgc2FtZSBhcyBTd2lzcyBHZXJtYW4uCj4KPiBRdW90aW5nIE1hcnRpbiBEdWVyc3Q6Cj4K PiAiWWVzLCBTd2FiaWFuIGlzIGNsZWFybHkgQWxlbWFuaWMuIEFsZW1hbmljIGFuZCBTd2lzcyBH ZXJtYW4gYXJlIG5vdAo+IHRoZSBzYW1lLiBUaGVyZSBhcmUgdmVyeSBjbG9zZSBzaW1pbGFyaXRp ZXMgYmV0d2VlbiBzb21lIGRpYWxlY3RzIGluCj4gdGhlIG5vcnRoIG9mIFN3aXR6ZXJsYW5kIGFu ZCBhY3Jvc3MgdGhlIGJvcmRlciBpbiBHZXJtYW55LCBidXQgYXMKPiBzb29uIGFzIHlvdSBjcm9z cyB0aGUgYm9yZGVyLCBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3MKPiBHZXJtYW4u IEEgbGFiZWwgc3VjaCBhcyAiQWxlbWFuaWM7IFN3aXNzIEdlcm1hbiIsIGFzc3VtaW5nIHRoYXQK PiBib3RoIGFyZSB0aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBzb21ldGhpbmcg bGlrZQo+ICJBbGVtYW5pYzsgaW5jbHVkZXMgU3dpc3MgR2VybWFuIiwgdGhhdCB3b3VsZCBiZSBv a2F5LiIKPgo+IENhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRp bnVlIHRvIG1pc2xlYWQgcGVvcGxlPwo+Cj4gTWFyayBEYXZpcwo+Cg== ------=_Part_5879_21963159.1164913601784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QWxlbWFuaWMgcmVmZXJzIHRvIGEgYnJvYWRlciBncm91cCBvZiBkaWFsZWN0cyB0aGFuICZxdW90 O1N3aXNzIEdlcm1hbiZxdW90OyAoYWthIFNjaHd5emVydHVlc2NoKSBkb2VzLiBTbyBsaXN0aW5n IHRoZW0gYXMgaXQgZG9lcyBpcyBwcm9ibGVtYXRpYzsgaXQncyBsaWtlIGxpc3Rpbmc8YnI+PGJy PmFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljPGJyPjxicj5QZXJzb25hbGx5LCBJIGRvbid0IGNh cmUgd2hldGhlciBpdCBpcyByZXNvbHZlZCB0byBiZQo8YnI+PGJyPkFsZW1hbmljIChpbmNsdWRp bmcgU3dpc3MgR2VybWFuKSAKPGJyPi8vIHdoaWNoIGlzIHdoYXQgNjM5LTMgc2VlbXMgdG8gYmUg cG9pbnRpbmcgdG88YnI+PGJyPm9yPGJyPjxicj5Td2lzcyBHZXJtYW4gKGEgcGFydGljdWxhciB2 YXJpYW50IG9mIEFsZW1hbmljKTxicj4vLyB3aGljaCBpcyB3aGF0IHRoZSBjb2RlIChnc3cpIHNl ZW1zIHRvIGJlIHBvaW50aW5nIHRvPGJyPjxicj5CdXQgd2UgbmVlZCBzb21lIGNsYXJpdHkgYXMg dG8gd2hhdCBpcyBtZWFudCBieSB0aGUgY29kZS4KPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2Pjxz cGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTEvMzAvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5k ZXJuYW1lIj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25A bWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bh bj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4 IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFk ZGluZy1sZWZ0OiAxZXg7Ij4KCgoKCgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJi bHVlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZl cmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPk1hcnRpbidzIGNvbW1lbnQgaXMgc29tZXdoYXQgdmFn dWU6IHZhcmlldGllcwpzcG9rZW4gb24gZWl0aGVyIHNpZGUgb2YgdGhlIGJvcmRlciBhcmUgdmVy eSBzaW1pbGFyLCA8c3Bhbj5ldDwvc3Bhbj4KImFzIHNvb24gYXMgeW91IGNyb3NzIHRoZSBib3Jk ZXIgaXQncyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzIEdlcm1hbiIuIERvZXMKdGhhdCBt ZWFuIHRoYXQgd2hhdCBpcyBzcG9rZW4gYWNyb3NzIHRoZSBib3JkZXIgaXMgY2xlYXJseSBhIGRp ZmZlcmVudApsYW5ndWFnZSwgb3IgdGhhdCB0aGUgbGFiZWwgIlN3aXNzIEdlcm1hbiIgaXMgY2xl YXJseSBub3QgdXNlZD88L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBm YWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4K CjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij4m bmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJk YW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VmVyZGFuYTsgY29sb3I6IGJsdWU7Ij5QZXRlcjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQg Y29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9wPgoKPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBz b2xpZDsgYm9yZGVyLWNvbG9yOiAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29s b3IgLW1vei11c2UtdGV4dC1jb2xvciBibHVlOyBib3JkZXItd2lkdGg6IG1lZGl1bSBtZWRpdW0g bWVkaXVtIDEuNXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7Ij4KCjxkaXY+Cgo8ZGl2IHN0 eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7IiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4KCjxo ciBhbGlnbj0iY2VudGVyIiBzaXplPSIyIiB3aWR0aD0iMTAwJSI+Cgo8L3NwYW4+PC9mb250Pjwv ZGl2PgoKPHA+PGI+PGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hOyBmb250LXdlaWdodDogYm9sZDsiPkZy b206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hOyI+IE1hcmsgRGF2aXMK W21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+XSA8YnI+CjxiPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIE5vdmVt YmVyIDMwLCAyMDA2Cjk6MDAgQU08YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9s ZDsiPlRvOjwvc3Bhbj48L2I+IEjDpXZhcmQgSGp1bHN0YWQ7CjxhIGhyZWY9Im1haWx0bzppc282 MzktMkBsb2MuZ292IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlzbzYzOS0yQGxvYy5nb3Y8L2E+PGJyPgo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5DYzo8L3NwYW4+PC9iPiBMVFJVIFdvcmtp bmcgR3JvdXA7CjxhIGhyZWY9Im1haWx0bzp6YWlpdG92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij56YWlpdG92QGdtYWlsLmNvbTwvYT47IElTTyA2MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVl OyA8YSBocmVmPSJtYWlsdG86aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRhcmdldD0iX2JsYW5r IiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+ CmlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPC9hPjsKPGEgaHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1 Zy5kayIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIj5pc282MzlAZGt1dWcuZGs8L2E+PGJyPgo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+ICBbTHRydV0gPHNwYW4g aWQ9InN0IiBuYW1lPSJzdCIgY2xhc3M9InN0Ij5BbGVtYW5pYzwvc3Bhbj4gJmFtcDsKU3dpc3Mg R2VybWFuPC9zcGFuPjwvZm9udD48L3A+Cgo8L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJlIiBpZD0i cV8xMGYzOWU3ZmI5MDFlNThmXzEiPgoKPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+Cgo8cD48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7Ij5JU08gNjM5LTIgKG9uIDxh IGhyZWY9Imh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhwL2NvZGVfbGlz dC5waHAiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5r KHdpbmRvdyxldmVudCx0aGlzKSI+Cmh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5 LTIvcGhwL2NvZGVfbGlzdC5waHA8L2E+KQpsaXN0cyB0aGUgZm9sbG93aW5nOjxicj4KPGJyPgpn c3cmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgQWxlbWFuaTsgU3dpc3MKR2VybWFuJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBhbMOpbWFu aXF1ZSA8YnI+Cjxicj4KSG93ZXZlciwgdGhlcmUgaXMgYSAmcXVvdDtjJnF1b3Q7IG1pc3Npbmcg ZnJvbSBBbGVtYW5pYywgYW5kIFN3aXNzIEdlcm1hbiBpcwpub3QgdGhlIHNhbWUgYXMgQWxlbWFu aWM6IFN3aXNzIEdlcm1hbiBpcyBhIHR5cGUgb2YgQWxlbWFuaWMsIGJ1dCB0aGVyZSBhcmUKb3Ro ZXIgdHlwZXMgdGhhdCBhcmUgbm90IHRoZSBzYW1lIGFzIFN3aXNzIEdlcm1hbi48YnI+Cjxicj4K UXVvdGluZyBNYXJ0aW4gRHVlcnN0OiA8YnI+Cjxicj4KPC9zcGFuPjwvZm9udD4mcXVvdDtZZXMs IFN3YWJpYW4gaXMgY2xlYXJseSA8c3Bhbj48c3BhbiBuYW1lPSJzdCI+QWxlbWFuaWM8L3NwYW4+ PC9zcGFuPi4KPHNwYW4+PHNwYW4gbmFtZT0ic3QiPkFsZW1hbmljPC9zcGFuPjwvc3Bhbj4gYW5k IFN3aXNzIEdlcm1hbiBhcmUKbm90PGJyPgp0aGUgc2FtZS4gVGhlcmUgYXJlIHZlcnkgY2xvc2Ug c2ltaWxhcml0aWVzIGJldHdlZW4gc29tZSBkaWFsZWN0cyBpbiA8YnI+CnRoZSBub3J0aCBvZiBT d2l0emVybGFuZCBhbmQgYWNyb3NzIHRoZSBib3JkZXIgaW4gR2VybWFueSwgYnV0IGFzPGJyPgpz b29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyLCBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIg U3dpc3M8YnI+Ckdlcm1hbi4gQSBsYWJlbCBzdWNoIGFzICZxdW90OzxzcGFuPjxzcGFuIG5hbWU9 InN0Ij5BbGVtYW5pYzwvc3Bhbj48L3NwYW4+OwpTd2lzcyBHZXJtYW4mcXVvdDssIGFzc3VtaW5n IHRoYXQgPGJyPgpib3RoIGFyZSB0aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBz b21ldGhpbmcgbGlrZTxicj4KJnF1b3Q7PHNwYW4+PHNwYW4gbmFtZT0ic3QiPkFsZW1hbmljPC9z cGFuPjwvc3Bhbj47IGluY2x1ZGVzIFN3aXNzCkdlcm1hbiZxdW90OywgdGhhdCB3b3VsZCBiZSBv a2F5LiZxdW90Ozxicj4KPGJyPgpDYW4gdGhpcyBiZSBjb3JyZWN0ZWQgc28gdGhhdCBpdCBkb2Vz IG5vdCBjb250aW51ZSB0byBtaXNsZWFkIHBlb3BsZT8gPGJyPgo8YnI+Ck1hcmsgRGF2aXM8L3A+ Cgo8L3NwYW4+PC9kaXY+PC9kaXY+Cgo8L2Rpdj4KCjwvZGl2PgoKCjwvYmxvY2txdW90ZT48L2Rp dj48YnI+Cg== ------=_Part_5879_21963159.1164913601784-- --===============0940306928== 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 --===============0940306928==-- From ltru-bounces@ietf.org Thu Nov 30 16:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDy-0004uz-Ai; Thu, 30 Nov 2006 16:13:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDP-0003Ti-HD for ltru@ietf.org; Thu, 30 Nov 2006 16:13:07 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound1-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpsz2-0003uw-Vk for ltru@ietf.org; Thu, 30 Nov 2006 15:58:28 -0500 Received: from outbound1-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-dub-R.bigfish.com (Postfix) with ESMTP id 631E5871628; Thu, 30 Nov 2006 20:58:16 +0000 (UTC) Received: from mail8-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound1-dub.bigfish.com (Postfix) with ESMTP id 30EEFD1807A; Thu, 30 Nov 2006 20:58:16 +0000 (UTC) Received: from mail8-dub (localhost.localdomain [127.0.0.1]) by mail8-dub-R.bigfish.com (Postfix) with ESMTP id C4F7A1818285; Thu, 30 Nov 2006 20:58:15 +0000 (UTC) X-BigFish: VP Received: by mail8-dub (MessageSwitch) id 1164920295739257_6801; Thu, 30 Nov 2006 20:58:15 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail8-dub.bigfish.com (Postfix) with ESMTP id 3BA8C12A8054; Thu, 30 Nov 2006 20:58:15 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006113013014668-1026392 ; Thu, 30 Nov 2006 13:01:46 -0800 In-Reply-To: <30b660a20611290931v50a7f0d9s7c5d798d316996c@mail.gmail.com> To: "Mark Davis" Subject: Re: [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Thu, 30 Nov 2006 12:56:49 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/30/2006 12:56:49, Serialize complete at 11/30/2006 12:56:49, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 01:01:46 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 01:01:50 PM, Serialize complete at 11/30/2006 01:01:50 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Markus Scherer , 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="===============1412890762==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1412890762== Content-Type: multipart/alternative; boundary="=_alternative 0073304E88257236_=" This is a multipart message in MIME format. --=_alternative 0073304E88257236_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" All, As the registrant of the "gsw" tag, I can tell you my intentions.=20 Initially I presented a need for a tag to classify spoken Swiss German=20 audio tracks. I don't have a use for a code for textual forms of this=20 language, but there was considerable debate when I initially presented=20 this language as "spoken Swiss German" -- it was pointed out that Swiss=20 German *can* be written, even though it rarely is.=20 As I was registering this tag, the IANA registry was on the cusp of the=20 RFC 3066 conversion. The recommendation at that time was that I submit an=20 ISO application for a tag that was in synch with ISO 639-3 and add=20 Alemanic as an alternate name. I checked my internal requirements and=20 found that we also had films that contained spoken Alemanic. As previously = mentioned on this list, there is a strong distinction between spoken and=20 written languages in broadcast and film metadata as we have a need to=20 describe original languages, dubbed languages, and subtitle languages.=20 Many films will obviously have more than one classification, and we would=20 want to prevent a user from assigning a gsw-CH tag to de-CH subtitles. After the tag was approved, I recommended the codes gsw-AT and gsw-CH for=20 the regional dialects. If we had subtitles in written de-CH, I would=20 recommend that as well, but today this is not a business need. Take this as you will -- I just thought I'd add my intentions to this=20 argument as the originator of the tag in 639-2. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Mark Davis" =20 11/29/2006 09:31 AM To "Peter Constable" cc Markus Scherer , LTRU Working Group=20 Subject [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) Peter, I see an oddity in the tables. =20 gsw gsw gsw I L Alemanic At least in the Ethnologue, gsw is Swiss German (=20 http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw), which is not the= =20 same as Alemanic -- it's a "subtype" of Alemanic. Is it the intention that gsw be any Alemanic, and that then gsw-CH be=20 Swiss German, and de-CH be the Swiss form of High German ( eg written with = =DF instead of ss)? ISO 639-2 is a bit unclear, listing both. gsw Alemani; Swiss German al=E9manique (By the way, in terms of mutual intelligibility, I found that despite=20 being able to understand "Rhine Valley" Swiss German, I was not really=20 able to understand "Wallis" Swiss German. I also noticed that wikipedia=20 was using "als" for Alemanic (eg http://als.wikipedia.org) when "gsw" is=20 already in ISO 639-2, and "als" will be Tosk Albanian in 639-3.) Mark On 11/22/ 06, Peter Constable < petercon@microsoft.com> wrote: > From: Doug Ewell [mailto: dewell@adelphia.net] > I note that the "Scope" field in 639-3 mirrors the "Type" field for the > "special" ("S") codes mul, und, and zxx. Yes. That's not surprising since these are really exceptional,=20 singularities -- special cases to which normal behaviours do not apply.=20 Peter Constable =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 0073304E88257236_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
All,

As the registrant of the "gsw&q= uot; tag, I can tell you my intentions. Initially I presented a need for a tag to classify spoken Swiss German audio tracks. I don't have a use for a code for textual forms of this language, but there was considerable debate when I initially presented this language as "spoken Swiss German" --  it was pointed out that Swiss German *can* be written, even though it rarely is.

As I was registering this tag, the I= ANA registry was on the cusp of the RFC 3066 conversion. The recommendation at that time was that I submit an ISO application for a tag that was in synch with ISO 639-3 and add Alemanic as an alternate name. I checked my internal requirements and found that we also had films that contained spoken Alemanic. As previously mentioned on this list, there is a strong distincti= on between spoken and written languages in broadcast and film metadata as we have a need to describe original languages, dubbed languages, and subtit= le languages. Many films will obviously have more than one classification, and we would want to prevent a user from assigning a gsw-CH tag to de-CH subtitles.

After the tag was approved, I recomm= ended the codes gsw-AT and gsw-CH for the regional dialects. If we had subtitles in written de-CH, I would recommend that as well, but today this is not a business need.

Take this as you will -- I just thou= ght I'd add my intentions to this argument as the originator of the tag in 639-2.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384




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

11/29/2006 09:31 AM

To
"Peter Constable" <pete= rcon@microsoft.com>
cc
Markus Scherer <markus.scherer@go= ogle.com>, LTRU Working Group <ltru@ietf.org>
Subject
[Ltru] Swiss German (was ISO/FDIS 63= 9-3 tables revised)





Peter, I see an oddity in the tables.
 
gsw   gsw   gsw      I   L   Alemanic

At least in the Ethnologue, gsw is Swiss German ( http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw), which is not the same as Alemanic -- it's a "subtype" of Alemanic= .

Is it the intention that gsw be any Alemanic, and that then gsw-CH be Swiss German, and de-CH be the Swiss form of High German ( eg written with =DF instead of ss)?

ISO 639-2 is a bit unclear, listing both.

gsw             Alemani; Swiss German      al=E9manique

(By the way, in terms of mutual intelligibility, I found that despite being able to understand "Rhine Valley" Swiss German, I was not really able to understand "Wallis" Swiss German. I also noticed that wikipedia was using "als" for Alemanic (eg http://als.wikipedia.org) when "gsw" is already in ISO 639-2, and "als" will be Tosk Albanian in 639-3.)

Mark

On 11/22/
06, Peter Constable < petercon@microsoft.com> wrote:
> From: Doug Ewell [mailto: dewell@adelphia.net]

> I note that the "Scope" field in 639-3 mirrors the "Typ= e" field for the
> "special" ("S") codes mul, und, and zxx.

Yes. That's not surprising since these are really exceptional, singularities -- special cases to which normal behaviours do not apply.



Peter Constable

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


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 0073304E88257236_=-- --===============1412890762== 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 --===============1412890762==-- From ltru-bounces@ietf.org Thu Nov 30 16:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptXb-0002XG-P2; Thu, 30 Nov 2006 16:33:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptXZ-0002Wu-Ua for ltru@ietf.org; Thu, 30 Nov 2006 16:33:58 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound3-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GptXT-00031T-RP for ltru@ietf.org; Thu, 30 Nov 2006 16:33:57 -0500 Received: from outbound3-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-dub-R.bigfish.com (Postfix) with ESMTP id D111B10D062D; Thu, 30 Nov 2006 21:33:50 +0000 (UTC) Received: from mail1-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound3-dub.bigfish.com (Postfix) with ESMTP id BC8B31F8072; Thu, 30 Nov 2006 21:33:50 +0000 (UTC) Received: from mail1-dub (localhost.localdomain [127.0.0.1]) by mail1-dub-R.bigfish.com (Postfix) with ESMTP id 84F541AC838A; Thu, 30 Nov 2006 21:33:50 +0000 (UTC) X-BigFish: VP Received: by mail1-dub (MessageSwitch) id 1164922430160837_13144; Thu, 30 Nov 2006 21:33:50 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail1-dub.bigfish.com (Postfix) with ESMTP id A509C161007F; Thu, 30 Nov 2006 21:33:49 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006113013372423-1027632 ; Thu, 30 Nov 2006 13:37:24 -0800 In-Reply-To: To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Thu, 30 Nov 2006 13:32:26 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/30/2006 13:32:27, Serialize complete at 11/30/2006 13:32:27, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 01:37:24 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 01:37:24 PM, Serialize complete at 11/30/2006 01:37:24 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: Markus Scherer , 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="===============0154245518==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0154245518== Content-Type: multipart/alternative; boundary="=_alternative 0076734C88257236_=" This is a multipart message in MIME format. --=_alternative 0076734C88257236_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Correction: "cusp of RFC 4646 conversion...." Karen=5FBroome@spe.sony.com=20 11/30/2006 12:56 PM To "Mark Davis" cc Markus Scherer , LTRU Working Group=20 Subject Re: [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) All,=20 As the registrant of the "gsw" tag, I can tell you my intentions.=20 Initially I presented a need for a tag to classify spoken Swiss German=20 audio tracks. I don't have a use for a code for textual forms of this=20 language, but there was considerable debate when I initially presented=20 this language as "spoken Swiss German" -- it was pointed out that Swiss=20 German *can* be written, even though it rarely is.=20 As I was registering this tag, the IANA registry was on the cusp of the=20 RFC 3066 conversion. The recommendation at that time was that I submit an=20 ISO application for a tag that was in synch with ISO 639-3 and add=20 Alemanic as an alternate name. I checked my internal requirements and=20 found that we also had films that contained spoken Alemanic. As previously = mentioned on this list, there is a strong distinction between spoken and=20 written languages in broadcast and film metadata as we have a need to=20 describe original languages, dubbed languages, and subtitle languages.=20 Many films will obviously have more than one classification, and we would=20 want to prevent a user from assigning a gsw-CH tag to de-CH subtitles.=20 After the tag was approved, I recommended the codes gsw-AT and gsw-CH for=20 the regional dialects. If we had subtitles in written de-CH, I would=20 recommend that as well, but today this is not a business need.=20 Take this as you will -- I just thought I'd add my intentions to this=20 argument as the originator of the tag in 639-2.=20 Regards,=20 Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384=20 "Mark Davis" =20 11/29/2006 09:31 AM=20 To "Peter Constable" =20 cc Markus Scherer , LTRU Working Group=20 =20 Subject [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised) Peter, I see an oddity in the tables. =20 gsw gsw gsw I L Alemanic At least in the Ethnologue, gsw is Swiss German (=20 http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw), which is not the= =20 same as Alemanic -- it's a "subtype" of Alemanic. Is it the intention that gsw be any Alemanic, and that then gsw-CH be=20 Swiss German, and de-CH be the Swiss form of High German ( eg written with = =DF instead of ss)? ISO 639-2 is a bit unclear, listing both. gsw Alemani; Swiss German al=E9manique (By the way, in terms of mutual intelligibility, I found that despite=20 being able to understand "Rhine Valley" Swiss German, I was not really=20 able to understand "Wallis" Swiss German. I also noticed that wikipedia=20 was using "als" for Alemanic (eg http://als.wikipedia.org) when "gsw" is=20 already in ISO 639-2, and "als" will be Tosk Albanian in 639-3.) Mark On 11/22/=20 06, Peter Constable < petercon@microsoft.com> wrote:=20 > From: Doug Ewell [mailto: dewell@adelphia.net] > I note that the "Scope" field in 639-3 mirrors the "Type" field for the > "special" ("S") codes mul, und, and zxx. Yes. That's not surprising since these are really exceptional,=20 singularities -- special cases to which normal behaviours do not apply.=20 Peter Constable =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 0076734C88257236_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Correction: "cusp of RFC 4646 c= onversion...."




Karen=5FBroome@spe.so= ny.com

11/30/2006 12:56 PM

To
"Mark Davis" <mark.davi= s@icu-project.org>
cc
Markus Scherer <markus.scherer@go= ogle.com>, LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Swiss German (was ISO/FDIS 639-3 tables revised)






All,

As the registrant of the "gsw" tag, I can tell you my intentions. Initially I presented a need for a tag to classify spoken Swiss German audio tracks. I don't have a use for a code for textual forms of this langu= age, but there was considerable debate when I initially presented this language as "spoken Swiss German" --  it was pointed out that Swiss German *can* be written, even though it rarely is.
As I was registering this tag, the IANA registry was on the cusp of the RFC 3066 conversion. The recommendation at that time was that I submit an ISO application for a tag that was in synch with ISO 639-3 and add Alema= nic as an alternate name. I checked my internal requirements and found that we also had films that contained spoken Alemanic. As previously mentioned on this list, there is a strong distinction between spoken and written languages in broadcast and film metadata as we have a need to describe original languages, dubbed languages, and subtitle languages. Many films will obviously have more than one classification, and we would want to prevent a user from assigning a gsw-CH tag to de-CH subtitles.

After the tag was approved, I recommended the codes gsw-AT and gsw-CH for the regional dialects. If we had subtitles in written de-CH, I would recomm= end that as well, but today this is not a business need.

Take this as you will -- I just thought I'd add my intentions to this argum= ent as the originator of the tag in 639-2.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384



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

11/29/2006 09:31 AM


To
"Peter Constable&qu= ot; <petercon@microsoft.com>
cc
Markus Scherer <markus.scherer@go= ogle.com>, LTRU Working Group <ltru@ietf.org>
Subject
[Ltru] Swiss German (was ISO/FDIS 63= 9-3 tables revised)







Peter, I see an oddity in the tables.
 
gsw   gsw   gsw      I   L   Alemanic

At least in the Ethnologue, gsw is Swiss German ( http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw), which is not the same as Alemanic -- it's a "subtype" of Alemanic= .

Is it the intention that gsw be any Alemanic, and that then gsw-CH be Swiss German, and de-CH be the Swiss form of High German ( eg written with =DF instead of ss)?

ISO 639-2 is a bit unclear, listing both.

gsw             Alemani; Swiss German      al=E9manique

(By the way, in terms of mutual intelligibility, I found that despite being able to understand "Rhine Valley" Swiss German, I was not really able to understand "Wallis" Swiss German. I also noticed that wikipedia was using "als" for Alemanic (eg http://als.wikipedia.org) when "gsw" is already in ISO 639-2, and "als" will be Tosk Albanian in 639-3.)

Mark

On 11/22/
06, Peter Constable < petercon@microsoft.com> wrote:
> From: Doug Ewell [mailto:<= font size=3D3 color=3Dblue> dewell@adelphia.net]

> I note that the "Scope" field in 639-3 mirrors the "Typ= e" field for the
> "special" ("S") codes mul, und, and zxx.

Yes. That's not surprising since these are really exceptional, singularities -- special cases to which normal behaviours do not apply.



Peter Constable

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


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 0076734C88257236_=-- --===============0154245518== 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 --===============0154245518==-- From ltru-bounces@ietf.org Thu Nov 30 18:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gputf-0004zx-Tg; Thu, 30 Nov 2006 18:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpute-0004zh-Ms for ltru@ietf.org; Thu, 30 Nov 2006 18:00:50 -0500 Received: from mail4.microsoft.com ([205.248.106.64] helo=smtpmail.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gputb-0008OL-1E for ltru@ietf.org; Thu, 30 Nov 2006 18:00:50 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E801.partners.extranet.microsoft.com (10.251.24.242) with Microsoft SMTP Server id 8.0.685.23; Thu, 30 Nov 2006 15:00:46 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.140]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 15:00:46 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Alemanic & Swiss German Date: Thu, 30 Nov 2006 14:59:47 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109BC3E4B@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <30b660a20611301106q39e9f498lde14ebba3e97a996@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Alemanic & Swiss German Thread-Index: AccUsrpAWxwM2rSITX2Oh8komWqs+AAH8/Xw From: Peter Constable To: Mark Davis X-OriginalArrivalTime: 30 Nov 2006 23:00:46.0089 (UTC) FILETIME=[5E95F790:01C714D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: LTRU Working Group , zaiitov@gmail.com, iso639-2@loc.gov, =?utf-8?B?SMOldmFyZCBIanVsc3RhZA==?= , ISO 639 Joint Advisory Committee , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0912543683==" Errors-To: ltru-bounces@ietf.org --===============0912543683== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C714D3.3B920A95" ------_=_NextPart_001_01C714D3.3B920A95 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gdGVsbCB5b3UgdGhhdCB0aGUgaW50ZW50IG9mIOKAnGdzd+KAnSBpcyBzcGVjaWZpY2Fs bHkgU3dpc3MgR2VybWFuLCBhbmQgdGhhdCB0aGUgYXNzdW1wdGlvbiBvZiBoYXZpbmcg4oCcQWxl bWFuaWPigJ0gbGlzdGVkIGFzIGEgbmFtZSBpcyB0aGF0IHNvbWUgcGVvcGxlIHVzZSB0aGF0IGxh YmVsIHRvIHJlZmVyIHRvIHNwZWNpZmljYWxseSB0byBTd2lzcyBHZXJtYW4uIElmIHRoZSBsYXR0 ZXIgYXNzdW1wdGlvbiBpcyBpbmNvcnJlY3QgKHdoaWNoIGFwcGVhcnMgdG8gYmUgd2hhdCBNYXJr IGlzIHNheWluZywgdGhlbiB0aGF0IGlzIGEgY2hhbmdlIHRoYXQgdGhlIEpBQyBzaG91bGQgY29u c2lkZXIuDQogDQpCdXQgaWYgTWFydGlu4oCZcyBjb21tZW50IGlzIHRoZSBzdXBwb3J0aW5nIGV2 aWRlbmNlLCB0aGVuIEkgc3RpbGwgZmluZCBNYXJ0aW7igJlzIGNvbW1lbnQgdG8gYmUgdW5jbGVh ci4gSXTigJlzIGNsZWFyIHRvIG1lIHdoYXQgTWFyayBpcyBzYXlpbmc7IGl04oCZcyBub3QgY2xl YXIgdG8gbWUgaWYgTWFydGluIGlzIHNheWluZyB0aGUgc2FtZSB0aGluZy4NCiANCiANClBldGVy IENvbnN0YWJsZQ0KIA0KIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RnJvbTogbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tIFttYWlsdG86bWFyay5lZHdhcmQuZGF2 aXNAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDMwLCAyMDA2IDExOjA3IEFNDQpUbzogUGV0ZXIgQ29uc3RhYmxlDQpDYzogSMOldmFy ZCBIanVsc3RhZDsgaXNvNjM5LTJAbG9jLmdvdjsgTFRSVSBXb3JraW5nIEdyb3VwOyB6YWlpdG92 QGdtYWlsLmNvbTsgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWU7IGlldGYtbGFuZ3Vh Z2VzQGlhbmEub3JnOyBpc282MzlAZGt1dWcuZGsNClN1YmplY3Q6IFJlOiBbTHRydV0gQWxlbWFu aWMgJiBTd2lzcyBHZXJtYW4NCiANCkFsZW1hbmljIHJlZmVycyB0byBhIGJyb2FkZXIgZ3JvdXAg b2YgZGlhbGVjdHMgdGhhbiAiU3dpc3MgR2VybWFuIiAoYWthIFNjaHd5emVydHVlc2NoKSBkb2Vz LiBTbyBsaXN0aW5nIHRoZW0gYXMgaXQgZG9lcyBpcyBwcm9ibGVtYXRpYzsgaXQncyBsaWtlIGxp c3RpbmcNCg0KYXIgQXJhYmljOyBFZ3lwdGlhbiBBcmFiaWMNCg0KUGVyc29uYWxseSwgSSBkb24n dCBjYXJlIHdoZXRoZXIgaXQgaXMgcmVzb2x2ZWQgdG8gYmUgDQoNCkFsZW1hbmljIChpbmNsdWRp bmcgU3dpc3MgR2VybWFuKSANCi8vIHdoaWNoIGlzIHdoYXQgNjM5LTMgc2VlbXMgdG8gYmUgcG9p bnRpbmcgdG8NCg0Kb3INCg0KU3dpc3MgR2VybWFuIChhIHBhcnRpY3VsYXIgdmFyaWFudCBvZiBB bGVtYW5pYykNCi8vIHdoaWNoIGlzIHdoYXQgdGhlIGNvZGUgKGdzdykgc2VlbXMgdG8gYmUgcG9p bnRpbmcgdG8NCg0KQnV0IHdlIG5lZWQgc29tZSBjbGFyaXR5IGFzIHRvIHdoYXQgaXMgbWVhbnQg YnkgdGhlIGNvZGUuIA0KDQpNYXJrDQpPbiAxMS8zMC8wNiwgUGV0ZXIgQ29uc3RhYmxlIDxwZXRl cmNvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCk1hcnRpbidzIGNvbW1lbnQgaXMgc29tZXdoYXQg dmFndWU6IHZhcmlldGllcyBzcG9rZW4gb24gZWl0aGVyIHNpZGUgb2YgdGhlIGJvcmRlciBhcmUg dmVyeSBzaW1pbGFyLCBldCAiYXMgc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJvcmRlciBpdCdzIHZl cnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3MgR2VybWFuIi4gRG9lcyB0aGF0IG1lYW4gdGhhdCB3 aGF0IGlzIHNwb2tlbiBhY3Jvc3MgdGhlIGJvcmRlciBpcyBjbGVhcmx5IGEgZGlmZmVyZW50IGxh bmd1YWdlLCBvciB0aGF0IHRoZSBsYWJlbCAiU3dpc3MgR2VybWFuIiBpcyBjbGVhcmx5IG5vdCB1 c2VkPw0KIA0KIA0KUGV0ZXINCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gDQpT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIwMDYgOTowMCBBTQ0KVG86IEjDpXZhcmQgSGp1 bHN0YWQ7IGlzbzYzOS0yQGxvYy5nb3YNCkNjOiBMVFJVIFdvcmtpbmcgR3JvdXA7IHphaWl0b3ZA Z21haWwuY29tOyBJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZTsgaWV0Zi1sYW5ndWFn ZXNAaWFuYS5vcmc7IGlzbzYzOUBka3V1Zy5kaw0KU3ViamVjdDogW0x0cnVdIEFsZW1hbmljICYg U3dpc3MgR2VybWFuDQogDQpJU08gNjM5LTIgKG9uIGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFy ZHMvaXNvNjM5LTIvcGhwL2NvZGVfbGlzdC5waHApIGxpc3RzIHRoZSBmb2xsb3dpbmc6DQoNCmdz dyAgICAgICAgICAgICBBbGVtYW5pOyBTd2lzcyBHZXJtYW4gICAgICBhbMOpbWFuaXF1ZSANCg0K SG93ZXZlciwgdGhlcmUgaXMgYSAiYyIgbWlzc2luZyBmcm9tIEFsZW1hbmljLCBhbmQgU3dpc3Mg R2VybWFuIGlzIG5vdCB0aGUgc2FtZSBhcyBBbGVtYW5pYzogU3dpc3MgR2VybWFuIGlzIGEgdHlw ZSBvZiBBbGVtYW5pYywgYnV0IHRoZXJlIGFyZSBvdGhlciB0eXBlcyB0aGF0IGFyZSBub3QgdGhl IHNhbWUgYXMgU3dpc3MgR2VybWFuLg0KDQpRdW90aW5nIE1hcnRpbiBEdWVyc3Q6IA0KDQoiWWVz LCBTd2FiaWFuIGlzIGNsZWFybHkgQWxlbWFuaWMuIEFsZW1hbmljIGFuZCBTd2lzcyBHZXJtYW4g YXJlIG5vdA0KdGhlIHNhbWUuIFRoZXJlIGFyZSB2ZXJ5IGNsb3NlIHNpbWlsYXJpdGllcyBiZXR3 ZWVuIHNvbWUgZGlhbGVjdHMgaW4gDQp0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9z cyB0aGUgYm9yZGVyIGluIEdlcm1hbnksIGJ1dCBhcw0Kc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJv cmRlciwgaXQncyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzDQpHZXJtYW4uIEEgbGFiZWwg c3VjaCBhcyAiQWxlbWFuaWM7IFN3aXNzIEdlcm1hbiIsIGFzc3VtaW5nIHRoYXQgDQpib3RoIGFy ZSB0aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZQ0KIkFs ZW1hbmljOyBpbmNsdWRlcyBTd2lzcyBHZXJtYW4iLCB0aGF0IHdvdWxkIGJlIG9rYXkuIg0KDQpD YW4gdGhpcyBiZSBjb3JyZWN0ZWQgc28gdGhhdCBpdCBkb2VzIG5vdCBjb250aW51ZSB0byBtaXNs ZWFkIHBlb3BsZT8gDQoNCk1hcmsgRGF2aXMNCiANCg== ------_=_NextPart_001_01C714D3.3B920A95 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPVByb2dJZCBjb250 ZW50PVdvcmQuRG9jdW1lbnQ+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3Nv ZnQgV29yZCAxMSI+DQo8bWV0YSBuYW1lPU9yaWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdv cmQgMTEiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQzcx NDkwLjJEMzE0QkMwIj4NCjxsaW5rIHJlbD1FZGl0LVRpbWUtRGF0YSBocmVmPSJjaWQ6ZWRpdGRh dGEubXNvIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KICA8bzpEb05vdFJlbHlPbkNTUy8+DQogPC9v Ok9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OkRvbnREaXNwbGF5UGFnZUJvdW5k YXJpZXMvPg0KICA8dzpHcmFtbWFyU3RhdGU+Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpE b2N1bWVudEtpbmQ+RG9jdW1lbnRFbWFpbDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3Bl VmlzLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFs aWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZh bHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KIDwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpMYXRlbnRT dHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBMYXRlbnRTdHlsZUNvdW50PSIxNTYiPg0KIDwv dzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBG b250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0K CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxl Ow0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU1ODA5IC0xMDczNzExMDM3IDkgMCA1MTEgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJl Oi01MjAwNzg1OTMgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xNTkzODMzNzI5IDEwNzM3 NTAxMDcgMTYgMCA0MTUgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5nbWFpbHF1b3RlDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsX3F1b3RlO30NCnNwYW4uc3QNCgl7bXNvLXN0eWxlLW5hbWU6c3Q7fQ0K c3Bhbi5lDQoJe21zby1zdHlsZS1uYW1lOmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlZlcmRhbmE7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJbXNvLWhh bnNpLWZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJY29sb3I6Ymx1ZTsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11 bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3Vn aDpub25lO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNv LWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24x DQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4N CjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJs ZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQt c2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5 ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBp biA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYW5zaS1sYW5ndWFnZToj MDQwMDsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTojMDQwMDsNCgltc28tYmlkaS1sYW5ndWFnZToj MDQwMDt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4t VVMgbGluaz1ibHVlIHZsaW5rPWJsdWUgc3R5bGU9J3RhYi1pbnRlcnZhbDouNWluJz4NCg0KPGRp diBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+SSBjYW4gdGVsbCB5b3UgdGhhdCB0aGUgaW50ZW50 IG9mIOKAnGdzd+KAnQ0KaXMgc3BlY2lmaWNhbGx5IFN3aXNzIEdlcm1hbiwgYW5kIHRoYXQgdGhl IGFzc3VtcHRpb24gb2YgaGF2aW5nIOKAnEFsZW1hbmlj4oCdDQpsaXN0ZWQgYXMgYSBuYW1lIGlz IHRoYXQgc29tZSBwZW9wbGUgdXNlIHRoYXQgbGFiZWwgdG8gcmVmZXIgdG8gc3BlY2lmaWNhbGx5 IHRvDQpTd2lzcyBHZXJtYW4uIElmIHRoZSBsYXR0ZXIgYXNzdW1wdGlvbiBpcyBpbmNvcnJlY3Qg KHdoaWNoIGFwcGVhcnMgdG8gYmUgd2hhdCBNYXJrDQppcyBzYXlpbmcsIHRoZW4gdGhhdCBpcyBh IGNoYW5nZSB0aGF0IHRoZSBKQUMgc2hvdWxkIGNvbnNpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpW ZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9y OmJsdWUnPkJ1dCBpZiBNYXJ0aW7igJlzIGNvbW1lbnQgaXMgdGhlDQpzdXBwb3J0aW5nIGV2aWRl bmNlLCB0aGVuIEkgc3RpbGwgZmluZCBNYXJ0aW7igJlzIGNvbW1lbnQgdG8gYmUgdW5jbGVhci4g SXTigJlzDQpjbGVhciB0byBtZSB3aGF0IE1hcmsgaXMgc2F5aW5nOyBpdOKAmXMgbm90IGNsZWFy IHRvIG1lIGlmIE1hcnRpbiBpcyBzYXlpbmcgdGhlDQpzYW1lIHRoaW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh bWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZl cmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5h O2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUn PlBldGVyIENvbnN0YWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgY2xh c3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250 IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0t MT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250 IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGFob21hJz4NCm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbSBbbWFpbHRvOm1h cmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbV0gPGI+PHNwYW4NCnN0eWxlPSdmb250LXdlaWdodDpi b2xkJz5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5NYXJrIERhdmlzPGJyPg0KPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIE5vdmVtYmVy IDMwLCAyMDA2DQoxMTowNyBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xk Jz5Ubzo8L3NwYW4+PC9iPiBQZXRlciBDb25zdGFibGU8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gSMOldmFyZCBIanVsc3RhZDsNCmlzbzYzOS0y QGxvYy5nb3Y7IExUUlUgV29ya2luZyBHcm91cDsgemFpaXRvdkBnbWFpbC5jb207IElTTyA2Mzkg Sm9pbnQgQWR2aXNvcnkNCkNvbW1pdHRlZTsgaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc7IGlzbzYz OUBka3V1Zy5kazxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0 Ojwvc3Bhbj48L2I+IFJlOiBbTHRydV0gQWxlbWFuaWMgJmFtcDsNClN3aXNzIEdlcm1hbjwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGZvbnQgc2l6ZT0zDQpm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5BbGVt YW5pYyByZWZlcnMgdG8gYQ0KYnJvYWRlciBncm91cCBvZiBkaWFsZWN0cyB0aGFuICZxdW90O1N3 aXNzIEdlcm1hbiZxdW90OyAoYWthIFNjaHd5emVydHVlc2NoKQ0KZG9lcy4gU28gbGlzdGluZyB0 aGVtIGFzIGl0IGRvZXMgaXMgcHJvYmxlbWF0aWM7IGl0J3MgbGlrZSBsaXN0aW5nPGJyPg0KPGJy Pg0KYXIgQXJhYmljOyBFZ3lwdGlhbiBBcmFiaWM8YnI+DQo8YnI+DQpQZXJzb25hbGx5LCBJIGRv bid0IGNhcmUgd2hldGhlciBpdCBpcyByZXNvbHZlZCB0byBiZSA8YnI+DQo8YnI+DQpBbGVtYW5p YyAoaW5jbHVkaW5nIFN3aXNzIEdlcm1hbikgPGJyPg0KLy8gd2hpY2ggaXMgd2hhdCA2MzktMyBz ZWVtcyB0byBiZSBwb2ludGluZyB0bzxicj4NCjxicj4NCm9yPGJyPg0KPGJyPg0KU3dpc3MgR2Vy bWFuIChhIHBhcnRpY3VsYXIgdmFyaWFudCBvZiBBbGVtYW5pYyk8YnI+DQovLyB3aGljaCBpcyB3 aGF0IHRoZSBjb2RlIChnc3cpIHNlZW1zIHRvIGJlIHBvaW50aW5nIHRvPGJyPg0KPGJyPg0KQnV0 IHdlIG5lZWQgc29tZSBjbGFyaXR5IGFzIHRvIHdoYXQgaXMgbWVhbnQgYnkgdGhlIGNvZGUuIDxi cj4NCjxicj4NCk1hcms8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9Z21haWxxdW90ZT48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPk9uIDEx LzMwLzA2LCA8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+UGV0ZXINCkNvbnN0YWJs ZTwvc3Bhbj48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+ cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7DQp3cm90ZTo8L3NwYW4+PC9mb250Pjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdiBsaW5rPWJsdWUgdmxpbms9Ymx1ZT4NCg0KPGRpdj4N Cg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1WZXJkYW5hPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibHVlJz5NYXJ0aW4n cyBjb21tZW50IGlzIHNvbWV3aGF0IHZhZ3VlOiB2YXJpZXRpZXMNCnNwb2tlbiBvbiBlaXRoZXIg c2lkZSBvZiB0aGUgYm9yZGVyIGFyZSB2ZXJ5IHNpbWlsYXIsIGV0ICZxdW90O2FzIHNvb24gYXMg eW91DQpjcm9zcyB0aGUgYm9yZGVyIGl0J3MgdmVyeSBjbGVhcmx5IG5vIGxvbmdlciBTd2lzcyBH ZXJtYW4mcXVvdDsuIERvZXMgdGhhdCBtZWFuDQp0aGF0IHdoYXQgaXMgc3Bva2VuIGFjcm9zcyB0 aGUgYm9yZGVyIGlzIGNsZWFybHkgYSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9yIHRoYXQNCnRoZSBs YWJlbCAmcXVvdDtTd2lzcyBHZXJtYW4mcXVvdDsgaXMgY2xlYXJseSBub3QgdXNlZD88L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpWZXJk YW5hO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxw Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT1WZXJkYW5hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VmVy ZGFuYTtjb2xvcjpibHVlJz5QZXRlcjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxw Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ow0K Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciAtbW96 LXVzZS10ZXh0LWNvbG9yIGJsdWUnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBh bGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIg c2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQoNCjxwPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7DQpmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bh bj48L2ZvbnQ+PC9iPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gTWFyayBEYXZpcyBbbWFpbHRvOjxhDQpo cmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2JsYW5rIj5t YXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZzwvYT5dDQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIw MDYNCjk6MDAgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9z cGFuPjwvYj4gSMOldmFyZCBIanVsc3RhZDsgPGENCmhyZWY9Im1haWx0bzppc282MzktMkBsb2Mu Z292IiB0YXJnZXQ9Il9ibGFuayI+aXNvNjM5LTJAbG9jLmdvdjwvYT48YnI+DQo8Yj48c3BhbiBz dHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gTFRSVSBXb3JraW5nIEdyb3Vw OyA8YQ0KaHJlZj0ibWFpbHRvOnphaWl0b3ZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+emFp aXRvdkBnbWFpbC5jb208L2E+OyBJU08gNjM5DQpKb2ludCBBZHZpc29yeSBDb21taXR0ZWU7IDxh IGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlc0BpYW5hLm9yZyINCnRhcmdldD0iX2JsYW5rIj5p ZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppc282MzlAZGt1dWcu ZGsiDQp0YXJnZXQ9Il9ibGFuayI+aXNvNjM5QGRrdXVnLmRrPC9hPjxicj4NCjxiPjxzcGFuIHN0 eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtMdHJ1XSA8c3BhbiBu YW1lPXN0DQppZD1zdD48c3BhbiBjbGFzcz1zdD5BbGVtYW5pYzwvc3Bhbj48L3NwYW4+ICZhbXA7 IFN3aXNzIEdlcm1hbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2PjxzcGFuIGlkPSJxXzEwZjM5ZTdmYjkwMWU1OGZfMSI+DQoNCjxwPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT1I ZWx2ZXRpY2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhJz5JU08NCjYzOS0yIChvbiA8YSBocmVmPSJodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRz L2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhwIg0KdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cu bG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhwL2NvZGVfbGlzdC5waHA8L2E+KQ0KbGlzdHMg dGhlIGZvbGxvd2luZzo8YnI+DQo8YnI+DQpnc3cmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgQWxlbWFuaTsgU3dpc3MNCkdlcm1hbiZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgYWzDqW1hbmlxdWUgPGJyPg0KPGJyPg0KSG93ZXZlciwgdGhl cmUgaXMgYSAmcXVvdDtjJnF1b3Q7IG1pc3NpbmcgZnJvbSBBbGVtYW5pYywgYW5kIFN3aXNzIEdl cm1hbiBpcw0Kbm90IHRoZSBzYW1lIGFzIEFsZW1hbmljOiBTd2lzcyBHZXJtYW4gaXMgYSB0eXBl IG9mIEFsZW1hbmljLCBidXQgdGhlcmUgYXJlDQpvdGhlciB0eXBlcyB0aGF0IGFyZSBub3QgdGhl IHNhbWUgYXMgU3dpc3MgR2VybWFuLjxicj4NCjxicj4NClF1b3RpbmcgTWFydGluIER1ZXJzdDog PGJyPg0KPGJyPg0KPC9zcGFuPjwvZm9udD4mcXVvdDtZZXMsIFN3YWJpYW4gaXMgY2xlYXJseSA8 c3BhbiBuYW1lPXN0PkFsZW1hbmljPC9zcGFuPi4gPHNwYW4NCm5hbWU9c3Q+QWxlbWFuaWM8L3Nw YW4+IGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5vdDxicj4NCnRoZSBzYW1lLiBUaGVyZSBhcmUgdmVy eSBjbG9zZSBzaW1pbGFyaXRpZXMgYmV0d2VlbiBzb21lIGRpYWxlY3RzIGluIDxicj4NCnRoZSBu b3J0aCBvZiBTd2l0emVybGFuZCBhbmQgYWNyb3NzIHRoZSBib3JkZXIgaW4gR2VybWFueSwgYnV0 IGFzPGJyPg0Kc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJvcmRlciwgaXQncyB2ZXJ5IGNsZWFybHkg bm8gbG9uZ2VyIFN3aXNzPGJyPg0KR2VybWFuLiBBIGxhYmVsIHN1Y2ggYXMgJnF1b3Q7PHNwYW4g bmFtZT1zdD5BbGVtYW5pYzwvc3Bhbj47IFN3aXNzIEdlcm1hbiZxdW90OywNCmFzc3VtaW5nIHRo YXQgPGJyPg0KYm90aCBhcmUgdGhlIHNhbWUsIGlzIGNsZWFybHkgd3JvbmcuIElmIGl0J3Mgc29t ZXRoaW5nIGxpa2U8YnI+DQomcXVvdDs8c3BhbiBuYW1lPXN0PkFsZW1hbmljPC9zcGFuPjsgaW5j bHVkZXMgU3dpc3MgR2VybWFuJnF1b3Q7LCB0aGF0IHdvdWxkIGJlDQpva2F5LiZxdW90Ozxicj4N Cjxicj4NCkNhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRpbnVl IHRvIG1pc2xlYWQgcGVvcGxlPyA8YnI+DQo8YnI+DQpNYXJrIERhdmlzPG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9z cGFuPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRt bD4NCg== ------_=_NextPart_001_01C714D3.3B920A95-- --===============0912543683== 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 --===============0912543683==-- From ltru-bounces@ietf.org Thu Nov 30 19:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwZt-0004mK-48; Thu, 30 Nov 2006 19:48:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwZs-0004m2-6s for ltru@ietf.org; Thu, 30 Nov 2006 19:48:32 -0500 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpwZq-0006nH-N1 for ltru@ietf.org; Thu, 30 Nov 2006 19:48:32 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1138217wra for ; Thu, 30 Nov 2006 16:48:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KTZHKblKjdAS24d0SMoe2iRDz9RtNbU4In8jHgEWFMAW+VxwFqvyG0fZwavSQfYtaQ11CeCjsg42AJ8XoB3VKyXb4zjdbFwB/zrn4JP2m2Ir2R6iE7/SH0HgsXq0LE0TsprsERnMry11m0CTlVWB6jRELHmm/gLn3G4Oj/dzSDg= Received: by 10.100.33.14 with SMTP id g14mr1247139ang.1164934109508; Thu, 30 Nov 2006 16:48:29 -0800 (PST) Received: by 10.100.8.6 with HTTP; Thu, 30 Nov 2006 16:48:29 -0800 (PST) Message-ID: <30b660a20611301648p4cedc882p9e367f22ff37efc5@mail.gmail.com> Date: Thu, 30 Nov 2006 16:48:29 -0800 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Alemanic & Swiss German In-Reply-To: <19A328037921AA42847A717566D1D6A109BC3E4B@RED-MSG-42.redmond.corp.microsoft.com> MIME-Version: 1.0 References: <30b660a20611301106q39e9f498lde14ebba3e97a996@mail.gmail.com> <19A328037921AA42847A717566D1D6A109BC3E4B@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: 7cfc36a2d80e1eea X-Spam-Score: 0.1 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: LTRU Working Group , zaiitov@gmail.com, iso639-2@loc.gov, =?UTF-8?Q?H=C3=A5vard_Hjulstad?= , ISO 639 Joint Advisory Committee , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641041170==" Errors-To: ltru-bounces@ietf.org --===============1641041170== Content-Type: multipart/alternative; boundary="----=_Part_6475_11547951.1164934109461" ------=_Part_6475_11547951.1164934109461 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline TWFydGluLCBJJ20gYXNzdW1pbmcgeW91IGFyZSBvbiB0aGlzIGxpc3QgdmlhIExUUlUuCgpNYXJr CgpPbiAxMS8zMC8wNiwgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPiB3 cm90ZToKPgo+ICBJIGNhbiB0ZWxsIHlvdSB0aGF0IHRoZSBpbnRlbnQgb2YgImdzdyIgaXMgc3Bl Y2lmaWNhbGx5IFN3aXNzIEdlcm1hbiwgYW5kCj4gdGhhdCB0aGUgYXNzdW1wdGlvbiBvZiBoYXZp bmcgIkFsZW1hbmljIiBsaXN0ZWQgYXMgYSBuYW1lIGlzIHRoYXQgc29tZQo+IHBlb3BsZSB1c2Ug dGhhdCBsYWJlbCB0byByZWZlciB0byBzcGVjaWZpY2FsbHkgdG8gU3dpc3MgR2VybWFuLiBJZiB0 aGUKPiBsYXR0ZXIgYXNzdW1wdGlvbiBpcyBpbmNvcnJlY3QgKHdoaWNoIGFwcGVhcnMgdG8gYmUg d2hhdCBNYXJrIGlzIHNheWluZywKPiB0aGVuIHRoYXQgaXMgYSBjaGFuZ2UgdGhhdCB0aGUgSkFD IHNob3VsZCBjb25zaWRlci4KPgo+Cj4KPiBCdXQgaWYgTWFydGluJ3MgY29tbWVudCBpcyB0aGUg c3VwcG9ydGluZyBldmlkZW5jZSwgdGhlbiBJIHN0aWxsIGZpbmQKPiBNYXJ0aW4ncyBjb21tZW50 IHRvIGJlIHVuY2xlYXIuIEl0J3MgY2xlYXIgdG8gbWUgd2hhdCBNYXJrIGlzIHNheWluZzsgaXQn cwo+IG5vdCBjbGVhciB0byBtZSBpZiBNYXJ0aW4gaXMgc2F5aW5nIHRoZSBzYW1lIHRoaW5nLgo+ Cj4KPgo+Cj4KPiBQZXRlciBDb25zdGFibGUKPgo+Cj4KPgo+Cj4KPiAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQo+Cj4gKkZyb206KiBtYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb20g W21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dICpPbgo+IEJlaGFsZiBPZiAqTWFy ayBEYXZpcwo+ICpTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDA2IDExOjA3IEFNCj4g KlRvOiogUGV0ZXIgQ29uc3RhYmxlCj4gKkNjOiogSMOldmFyZCBIanVsc3RhZDsgaXNvNjM5LTJA bG9jLmdvdjsgTFRSVSBXb3JraW5nIEdyb3VwOwo+IHphaWl0b3ZAZ21haWwuY29tOyBJU08gNjM5 IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZTsKPiBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsgaXNv NjM5QGRrdXVnLmRrCj4gKlN1YmplY3Q6KiBSZTogW0x0cnVdIEFsZW1hbmljICYgU3dpc3MgR2Vy bWFuCj4KPgo+Cj4gQWxlbWFuaWMgcmVmZXJzIHRvIGEgYnJvYWRlciBncm91cCBvZiBkaWFsZWN0 cyB0aGFuICJTd2lzcyBHZXJtYW4iIChha2EKPiBTY2h3eXplcnR1ZXNjaCkgZG9lcy4gU28gbGlz dGluZyB0aGVtIGFzIGl0IGRvZXMgaXMgcHJvYmxlbWF0aWM7IGl0J3MgbGlrZQo+IGxpc3RpbmcK Pgo+IGFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljCj4KPiBQZXJzb25hbGx5LCBJIGRvbid0IGNh cmUgd2hldGhlciBpdCBpcyByZXNvbHZlZCB0byBiZQo+Cj4gQWxlbWFuaWMgKGluY2x1ZGluZyBT d2lzcyBHZXJtYW4pCj4gLy8gd2hpY2ggaXMgd2hhdCA2MzktMyBzZWVtcyB0byBiZSBwb2ludGlu ZyB0bwo+Cj4gb3IKPgo+IFN3aXNzIEdlcm1hbiAoYSBwYXJ0aWN1bGFyIHZhcmlhbnQgb2YgQWxl bWFuaWMpCj4gLy8gd2hpY2ggaXMgd2hhdCB0aGUgY29kZSAoZ3N3KSBzZWVtcyB0byBiZSBwb2lu dGluZyB0bwo+Cj4gQnV0IHdlIG5lZWQgc29tZSBjbGFyaXR5IGFzIHRvIHdoYXQgaXMgbWVhbnQg YnkgdGhlIGNvZGUuCj4KPiBNYXJrCj4KPiBPbiAxMS8zMC8wNiwgKlBldGVyIENvbnN0YWJsZSog PHBldGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gTWFydGluJ3MgY29tbWVudCBpcyBz b21ld2hhdCB2YWd1ZTogdmFyaWV0aWVzIHNwb2tlbiBvbiBlaXRoZXIgc2lkZSBvZiB0aGUKPiBi b3JkZXIgYXJlIHZlcnkgc2ltaWxhciwgZXQgImFzIHNvb24gYXMgeW91IGNyb3NzIHRoZSBib3Jk ZXIgaXQncyB2ZXJ5Cj4gY2xlYXJseSBubyBsb25nZXIgU3dpc3MgR2VybWFuIi4gRG9lcyB0aGF0 IG1lYW4gdGhhdCB3aGF0IGlzIHNwb2tlbiBhY3Jvc3MKPiB0aGUgYm9yZGVyIGlzIGNsZWFybHkg YSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9yIHRoYXQgdGhlIGxhYmVsICJTd2lzcyBHZXJtYW4iCj4g aXMgY2xlYXJseSBub3QgdXNlZD8KPgo+Cj4KPgo+Cj4gUGV0ZXIKPgo+Cj4gICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+ICpGcm9tOiogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsu ZGF2aXNAaWN1LXByb2plY3Qub3JnXQo+ICpTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAy MDA2IDk6MDAgQU0KPiAqVG86KiBIw6V2YXJkIEhqdWxzdGFkOyBpc282MzktMkBsb2MuZ292Cj4g KkNjOiogTFRSVSBXb3JraW5nIEdyb3VwOyB6YWlpdG92QGdtYWlsLmNvbTsgSVNPIDYzOSBKb2lu dCBBZHZpc29yeQo+IENvbW1pdHRlZTsgaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc7IGlzbzYzOUBk a3V1Zy5kawo+ICpTdWJqZWN0OiogW0x0cnVdIEFsZW1hbmljICYgU3dpc3MgR2VybWFuCj4KPgo+ Cj4gSVNPIDYzOS0yIChvbiBodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3Bo cC9jb2RlX2xpc3QucGhwKQo+IGxpc3RzIHRoZSBmb2xsb3dpbmc6Cj4KPiBnc3cgICAgICAgICAg ICAgQWxlbWFuaTsgU3dpc3MgR2VybWFuICAgICAgYWzDqW1hbmlxdWUKPgo+IEhvd2V2ZXIsIHRo ZXJlIGlzIGEgImMiIG1pc3NpbmcgZnJvbSBBbGVtYW5pYywgYW5kIFN3aXNzIEdlcm1hbiBpcyBu b3QgdGhlCj4gc2FtZSBhcyBBbGVtYW5pYzogU3dpc3MgR2VybWFuIGlzIGEgdHlwZSBvZiBBbGVt YW5pYywgYnV0IHRoZXJlIGFyZSBvdGhlcgo+IHR5cGVzIHRoYXQgYXJlIG5vdCB0aGUgc2FtZSBh cyBTd2lzcyBHZXJtYW4uCj4KPiBRdW90aW5nIE1hcnRpbiBEdWVyc3Q6Cj4KPiAiWWVzLCBTd2Fi aWFuIGlzIGNsZWFybHkgQWxlbWFuaWMuIEFsZW1hbmljIGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5v dAo+IHRoZSBzYW1lLiBUaGVyZSBhcmUgdmVyeSBjbG9zZSBzaW1pbGFyaXRpZXMgYmV0d2VlbiBz b21lIGRpYWxlY3RzIGluCj4gdGhlIG5vcnRoIG9mIFN3aXR6ZXJsYW5kIGFuZCBhY3Jvc3MgdGhl IGJvcmRlciBpbiBHZXJtYW55LCBidXQgYXMKPiBzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVy LCBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3MKPiBHZXJtYW4uIEEgbGFiZWwgc3Vj aCBhcyAiQWxlbWFuaWM7IFN3aXNzIEdlcm1hbiIsIGFzc3VtaW5nIHRoYXQKPiBib3RoIGFyZSB0 aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZQo+ICJBbGVt YW5pYzsgaW5jbHVkZXMgU3dpc3MgR2VybWFuIiwgdGhhdCB3b3VsZCBiZSBva2F5LiIKPgo+IENh biB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRpbnVlIHRvIG1pc2xl YWQgcGVvcGxlPwo+Cj4gTWFyayBEYXZpcwo+Cj4KPgo= ------=_Part_6475_11547951.1164934109461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline TWFydGluLCBJJ20gYXNzdW1pbmcgeW91IGFyZSBvbiB0aGlzIGxpc3QgdmlhIExUUlUuPGJyPjxi cj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTEvMzAvMDYs IDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5QZXRlciBDb25zdGFibGU8L2I+ICZsdDs8YSBo cmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNv bQo8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjog MHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoKCgoKCgoKCgoKCgo8ZGl2 IGxpbms9ImJsdWUiIHZsaW5rPSJibHVlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+PGZvbnQg Y29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPkkgY2FuIHRlbGwg eW91IHRoYXQgdGhlIGludGVudCBvZiAiZ3N3IgppcyBzcGVjaWZpY2FsbHkgU3dpc3MgR2VybWFu LCBhbmQgdGhhdCB0aGUgYXNzdW1wdGlvbiBvZiBoYXZpbmcgIkFsZW1hbmljIgpsaXN0ZWQgYXMg YSBuYW1lIGlzIHRoYXQgc29tZSBwZW9wbGUgdXNlIHRoYXQgbGFiZWwgdG8gcmVmZXIgdG8gc3Bl Y2lmaWNhbGx5IHRvClN3aXNzIEdlcm1hbi4gSWYgdGhlIGxhdHRlciBhc3N1bXB0aW9uIGlzIGlu Y29ycmVjdCAod2hpY2ggYXBwZWFycyB0byBiZSB3aGF0IE1hcmsKaXMgc2F5aW5nLCB0aGVuIHRo YXQgaXMgYSBjaGFuZ2UgdGhhdCB0aGUgSkFDIHNob3VsZCBjb25zaWRlci48L3NwYW4+PC9mb250 PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJs dWU7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNl PSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij5CdXQgaWYgTWFydGluJ3MgY29tbWVudCBpcyB0 aGUKc3VwcG9ydGluZyBldmlkZW5jZSwgdGhlbiBJIHN0aWxsIGZpbmQgTWFydGluJ3MgY29tbWVu dCB0byBiZSB1bmNsZWFyLiBJdCdzCmNsZWFyIHRvIG1lIHdoYXQgTWFyayBpcyBzYXlpbmc7IGl0 J3Mgbm90IGNsZWFyIHRvIG1lIGlmIE1hcnRpbiBpcyBzYXlpbmcgdGhlCnNhbWUgdGhpbmcuPC9z cGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7 IGNvbG9yOiBibHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0i Ymx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBibHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+Cgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBi bHVlOyI+UGV0ZXIgQ29uc3RhYmxlPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0i Ymx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBibHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+Cgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBi bHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFj ZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBibHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8 ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItY29s b3I6IC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0 LWNvbG9yIGJsdWU7IGJvcmRlci13aWR0aDogbWVkaXVtIG1lZGl1bSBtZWRpdW0gMS41cHQ7IHBh ZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiPgoKPGRpdj4KCjxkaXYgc3R5bGU9InRleHQtYWxpZ246 IGNlbnRlcjsiIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPgoKPGhyIGFsaWduPSJjZW50ZXIi IHNpemU9IjIiIHdpZHRoPSIxMDAlIj4KCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+Cgo8cD48Yj48Zm9u dCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBUYWhvbWE7IGZvbnQtd2VpZ2h0OiBib2xkOyI+RnJvbTo8L3NwYW4+PC9mb250 PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij4KPGEgaHJlZj0ibWFpbHRvOm1hcmsuZWR3YXJk LmRhdmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5tYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5j b208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj4KbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tPC9hPl0gPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+TWFy ayBEYXZpczxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2VudDo8L3Nw YW4+PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIwMDYKMTE6MDcgQU08YnI+CjxiPjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+IFBldGVyIENvbnN0YWJs ZTxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+Q2M6PC9zcGFuPjwvYj4g SMOldmFyZCBIanVsc3RhZDsKPGEgaHJlZj0ibWFpbHRvOmlzbzYzOS0yQGxvYy5nb3YiIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+aXNvNjM5LTJAbG9jLmdvdjwvYT47IExUUlUgV29ya2luZyBHcm91cDsgPGEgaHJl Zj0ibWFpbHRvOnphaWl0b3ZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0 dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgp6YWlpdG92QGdtYWls LmNvbTwvYT47IElTTyA2MzkgSm9pbnQgQWR2aXNvcnkKQ29tbWl0dGVlOyA8YSBocmVmPSJtYWls dG86aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1 cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWV0Zi1sYW5ndWFnZXNA aWFuYS5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aXNvNjM5QGRrdXVnLmRrIiB0YXJnZXQ9Il9i bGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiPgppc282MzlAZGt1dWcuZGs8L2E+PGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 IGJvbGQ7Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbTHRydV0gQWxlbWFuaWMgJmFtcDsKU3dp c3MgR2VybWFuPC9zcGFuPjwvZm9udD48L3A+Cgo8L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJlIiBp ZD0icV8xMGYzYjE5NTIwOWY4OTJlXzEiPgoKPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Jm5ic3A7PC9zcGFuPjwv Zm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPkFs ZW1hbmljIHJlZmVycyB0byBhCmJyb2FkZXIgZ3JvdXAgb2YgZGlhbGVjdHMgdGhhbiAmcXVvdDtT d2lzcyBHZXJtYW4mcXVvdDsgKGFrYSBTY2h3eXplcnR1ZXNjaCkKZG9lcy4gU28gbGlzdGluZyB0 aGVtIGFzIGl0IGRvZXMgaXMgcHJvYmxlbWF0aWM7IGl0J3MgbGlrZSBsaXN0aW5nPGJyPgo8YnI+ CmFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljPGJyPgo8YnI+ClBlcnNvbmFsbHksIEkgZG9uJ3Qg Y2FyZSB3aGV0aGVyIGl0IGlzIHJlc29sdmVkIHRvIGJlIDxicj4KPGJyPgpBbGVtYW5pYyAoaW5j bHVkaW5nIFN3aXNzIEdlcm1hbikgPGJyPgovLyB3aGljaCBpcyB3aGF0IDYzOS0zIHNlZW1zIHRv IGJlIHBvaW50aW5nIHRvPGJyPgo8YnI+Cm9yPGJyPgo8YnI+ClN3aXNzIEdlcm1hbiAoYSBwYXJ0 aWN1bGFyIHZhcmlhbnQgb2YgQWxlbWFuaWMpPGJyPgovLyB3aGljaCBpcyB3aGF0IHRoZSBjb2Rl IChnc3cpIHNlZW1zIHRvIGJlIHBvaW50aW5nIHRvPGJyPgo8YnI+CkJ1dCB3ZSBuZWVkIHNvbWUg Y2xhcml0eSBhcyB0byB3aGF0IGlzIG1lYW50IGJ5IHRoZSBjb2RlLiA8YnI+Cjxicj4KTWFyazwv c3Bhbj48L2ZvbnQ+PC9wPgoKPGRpdj4KCjxwPjxzcGFuPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPk9uIDExLzMwLzA2 LCA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5QZXRlcgpDb25zdGFibGU8L3Nw YW4+PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Cndyb3RlOjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvcD4KCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9ImJsdWUiPgoKPGRpdj4KCjxw Pjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij5NYXJ0 aW4ncyBjb21tZW50IGlzIHNvbWV3aGF0IHZhZ3VlOiB2YXJpZXRpZXMKc3Bva2VuIG9uIGVpdGhl ciBzaWRlIG9mIHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwgZXQgJnF1b3Q7YXMgc29vbiBh cyB5b3UKY3Jvc3MgdGhlIGJvcmRlciBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3Mg R2VybWFuJnF1b3Q7LiBEb2VzIHRoYXQgbWVhbgp0aGF0IHdoYXQgaXMgc3Bva2VuIGFjcm9zcyB0 aGUgYm9yZGVyIGlzIGNsZWFybHkgYSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9yIHRoYXQKdGhlIGxh YmVsICZxdW90O1N3aXNzIEdlcm1hbiZxdW90OyBpcyBjbGVhcmx5IG5vdCB1c2VkPzwvc3Bhbj48 L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xv cjogYmx1ZTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9ImJsdWUi IGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9w PgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsi PlBldGVyPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVy ZGFuYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFZlcmRhbmE7IGNvbG9yOiBibHVlOyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8ZGl2IHN0 eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItY29sb3I6IC1t b3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9y IGJsdWU7IGJvcmRlci13aWR0aDogbWVkaXVtIG1lZGl1bSBtZWRpdW0gMS41cHQ7IHBhZGRpbmc6 IDBpbiAwaW4gMGluIDRwdDsiPgoKPGRpdj4KCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IGNlbnRl cjsiIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPgoKPGhyIGFsaWduPSJjZW50ZXIiIHNpemU9 IjIiIHdpZHRoPSIxMDAlIj4KCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+Cgo8cD48Yj48Zm9udCBmYWNl PSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWE7IGZvbnQtd2VpZ2h0OiBib2xkOyI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48 Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij4gTWFyayBEYXZpcyBbbWFpbHRvOgo8YSBocmVmPSJtYWls dG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5kYXZpc0Bp Y3UtcHJvamVjdC5vcmc8L2E+XQo8YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9s ZDsiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDA2Cjk6MDAgQU08 YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+IEjD pXZhcmQgSGp1bHN0YWQ7IDxhIGhyZWY9Im1haWx0bzppc282MzktMkBsb2MuZ292IiB0YXJnZXQ9 Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiPmlzbzYzOS0yQGxvYy5nb3Y8L2E+PGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6IGJvbGQ7Ij5DYzo8L3NwYW4+PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA7IDxhIGhyZWY9Im1h aWx0bzp6YWlpdG92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj56YWlpdG92QGdtYWlsLmNvbTwv YT47IElTTyA2MzkKSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlOyA8YSBocmVmPSJtYWlsdG86aWV0 Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWV0Zi1sYW5ndWFnZXNAaWFuYS5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aXNvNjM5QGRrdXVnLmRrIiB0YXJnZXQ9Il9ibGFuayIg b25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgpp c282MzlAZGt1dWcuZGs8L2E+PGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7 Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtMdHJ1XSA8c3BhbiBuYW1lPSJzdCI+PHNwYW4+QWxlbWFu aWM8L3NwYW4+PC9zcGFuPiAmYW1wOyBTd2lzcyBHZXJtYW48L3NwYW4+PC9mb250PjwvcD4KCjwv ZGl2PgoKPGRpdj48c3Bhbj4KCjxwPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9w PgoKPHA+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyI+SVNPCjYzOS0yIChvbiA8YSBocmVm PSJodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhw IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiPmh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhw L2NvZGVfbGlzdC5waHA8L2E+KQpsaXN0cyB0aGUgZm9sbG93aW5nOjxicj4KPGJyPgpnc3cmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgQWxl bWFuaTsgU3dpc3MKR2VybWFuJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBhbMOpbWFuaXF1ZSA8 YnI+Cjxicj4KSG93ZXZlciwgdGhlcmUgaXMgYSAmcXVvdDtjJnF1b3Q7IG1pc3NpbmcgZnJvbSBB bGVtYW5pYywgYW5kIFN3aXNzIEdlcm1hbiBpcwpub3QgdGhlIHNhbWUgYXMgQWxlbWFuaWM6IFN3 aXNzIEdlcm1hbiBpcyBhIHR5cGUgb2YgQWxlbWFuaWMsIGJ1dCB0aGVyZSBhcmUKb3RoZXIgdHlw ZXMgdGhhdCBhcmUgbm90IHRoZSBzYW1lIGFzIFN3aXNzIEdlcm1hbi48YnI+Cjxicj4KUXVvdGlu ZyBNYXJ0aW4gRHVlcnN0OiA8YnI+Cjxicj4KPC9zcGFuPjwvZm9udD4mcXVvdDtZZXMsIFN3YWJp YW4gaXMgY2xlYXJseSA8c3BhbiBuYW1lPSJzdCI+QWxlbWFuaWM8L3NwYW4+LiA8c3BhbiBuYW1l PSJzdCI+QWxlbWFuaWM8L3NwYW4+IGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5vdDxicj4KdGhlIHNh bWUuIFRoZXJlIGFyZSB2ZXJ5IGNsb3NlIHNpbWlsYXJpdGllcyBiZXR3ZWVuIHNvbWUgZGlhbGVj dHMgaW4gPGJyPgp0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9zcyB0aGUgYm9yZGVy IGluIEdlcm1hbnksIGJ1dCBhczxicj4Kc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJvcmRlciwgaXQn cyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzPGJyPgpHZXJtYW4uIEEgbGFiZWwgc3VjaCBh cyAmcXVvdDs8c3BhbiBuYW1lPSJzdCI+QWxlbWFuaWM8L3NwYW4+OyBTd2lzcyBHZXJtYW4mcXVv dDssCmFzc3VtaW5nIHRoYXQgPGJyPgpib3RoIGFyZSB0aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9u Zy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZTxicj4KJnF1b3Q7PHNwYW4gbmFtZT0ic3QiPkFsZW1h bmljPC9zcGFuPjsgaW5jbHVkZXMgU3dpc3MgR2VybWFuJnF1b3Q7LCB0aGF0IHdvdWxkIGJlCm9r YXkuJnF1b3Q7PGJyPgo8YnI+CkNhbiB0aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMg bm90IGNvbnRpbnVlIHRvIG1pc2xlYWQgcGVvcGxlPyA8YnI+Cjxicj4KTWFyayBEYXZpczwvcD4K Cjwvc3Bhbj48L2Rpdj4KCjwvZGl2PgoKPC9kaXY+Cgo8L2Rpdj4KCjwvZGl2PgoKCgo8cD48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjwvc3Bhbj48L2Rpdj48L2Rpdj4KCjwv ZGl2PgoKPC9kaXY+CgoKPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_6475_11547951.1164934109461-- --===============1641041170== 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 --===============1641041170==-- From ltru-bounces@ietf.org Thu Nov 30 20:56:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxdr-0006L6-Kl; Thu, 30 Nov 2006 20:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxdq-0006Kj-3d for ltru@ietf.org; Thu, 30 Nov 2006 20:56:42 -0500 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound6-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpxdk-0008JZ-4T for ltru@ietf.org; Thu, 30 Nov 2006 20:56:42 -0500 Received: from outbound6-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-blu-R.bigfish.com (Postfix) with ESMTP id B684B162010C; Fri, 1 Dec 2006 01:56:31 +0000 (UTC) Received: from mail112-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound6-blu.bigfish.com (Postfix) with ESMTP id A982DBE8048; Fri, 1 Dec 2006 01:56:31 +0000 (UTC) Received: from mail112-blu (localhost.localdomain [127.0.0.1]) by mail112-blu-R.bigfish.com (Postfix) with ESMTP id 18014578413; Fri, 1 Dec 2006 01:56:31 +0000 (UTC) X-BigFish: VP Received: by mail112-blu (MessageSwitch) id 116493819157775_5360; Fri, 1 Dec 2006 01:56:31 +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 mail112-blu.bigfish.com (Postfix) with ESMTP id 6EABF38005D; Fri, 1 Dec 2006 01:56:30 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006113018000310-1041418 ; Thu, 30 Nov 2006 18:00:03 -0800 In-Reply-To: <19A328037921AA42847A717566D1D6A109BC40AD@RED-MSG-42.redmond.corp.microsoft.com> To: Peter Constable Subject: RE: [Ltru] Alemanic & Swiss German MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Thu, 30 Nov 2006 17:55:04 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/30/2006 17:55:06, Serialize complete at 11/30/2006 17:55:06, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 06:00:03 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2006 06:00:05 PM, Serialize complete at 11/30/2006 06:00:05 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: LTRU Working Group , zaiitov@gmail.com, iso639-2@loc.gov, =?ISO-8859-1?Q?H=E5vard_Hjulstad?= , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1542771147==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1542771147== Content-Type: multipart/alternative; boundary="=_alternative 000AA8EE88257237_=" This is a multipart message in MIME format. --=_alternative 000AA8EE88257237_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" QXJlIHdlIHJlYWRpbmcgdGhlIHNhbWUgRXRobm9sb2d1ZSBwYWdlPyBFdGhub2xvZ3VlIHNlZW1z IHRvIGluY2x1ZGUgdGhlIA0KQXVzdHJpYW4gZm9ybXMgYW5kIG1lbnRpb25zIHRoYXQgY2VydGFp biBkaWFsZWN0cyB3aXRoaW4gdGhpcyBsYW5ndWFnZSANCmZhbWlseSBtYXkgbm90IGJlIGludGVs bGlnaWJsZSB0byBzcGVha2VycyBvZiBvdGhlciBkaWFsZWN0cy4NCg0KSSdtIG5vdCB0cnlpbmcg dG8gYmUgZGlmZmljdWx0ICAtLSB0b2RheSA6KSAtLSBhbmQgY2VydGFpbmx5IGFwcHJlY2lhdGUg DQp5b3VyIHByZXZpb3VzIGhlbHAgaW4gc29ydGluZyBvdXQgdGhlc2UgaXNzdWVzLCBidXQgSSBo YXZlIGNpcmN1bGF0ZWQgdGhlIA0KY29kZXMgZ3N3LUNIIGFuZCBnc3ctQVQgdG8gYSBmYWlybHkg d2lkZSBhdWRpZW5jZSBiYXNlZCBvbiBhc3N1bXB0aW9ucyANCnRoYXQgc2VlbSB0byBiZSBmYWly bHkgd2VsbC1kb2N1bWVudGVkIG9uIEV0aG5vbG9ndWUsIG15IGFwcGxpY2F0aW9uLCANCklTTydz IGFwcHJvdmFsLCBhbmQgdmFyaW91cyBvdGhlciByZXNvdXJjZXMgdGhhdCBsdW1wIHRoZXNlIHJl Z2lvbmFsIA0KZGlhbGVjdHMgdG9nZXRoZXIuIERvZXMgNjM5LTMgc2hvdWxkIGhhdmUgYSBtYWNy b2xhbmd1YWdlIGZvciB0aGlzPyBJZiANCm5vdCwgc2hvdWxkIGl0PyANCg0KSSdkIGFwcHJlY2lh dGUgaXQgaWYgeW91IGNvdWxkIHJldmlldyB5b3VyIG5vdGVzIGJlZm9yZSBhY3Rpbmcgb24gdGhp cyANCnN1Z2dlc3RlZCBjaGFuZ2UuIA0KDQpCZXN0IHJlZ2FyZHMsDQoNCkthcmVuIA0KDQoNCg0K DQpQZXRlciBDb25zdGFibGUgPHBldGVyY29uQG1pY3Jvc29mdC5jb20+IA0KMTEvMzAvMjAwNiAw NTozNCBQTQ0KDQpUbw0KPEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20+DQpjYw0KSMOldmFyZCBI anVsc3RhZCA8SEhqQHN0YW5kYXJkLm5vPiwgPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiwgDQo8 aWV0Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vPiwgPGlzbzYzOUBka3V1Zy5kaz4s IA0KPGlzbzYzOS0yQGxvYy5nb3Y+LCBJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZSA8 SVNPSkFDQGxvYy5nb3Y+LCANCkxUUlUgV29ya2luZyBHcm91cCA8bHRydUBpZXRmLm9yZz4sIE1h cmsgRGF2aXMgDQo8bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc+LCA8emFpaXRvdkBnbWFpbC5j b20+DQpTdWJqZWN0DQpSRTogW0x0cnVdIEFsZW1hbmljICYgU3dpc3MgR2VybWFuDQoNCg0KDQoN Cg0KDQpJ4oCZbGwgaGF2ZSB0byBjaGVjayBlbWFpbCB0byBiZSBzdXJlLCBidXQgbXkgcmVjb2xs ZWN0aW9uIHdhcyB0aGF0IEkgaGFkIA0Kc3VnZ2VzdGVkIHRvIHlvdSB0aGF0IHRoZSBjYXRlZ29y eSB0aGF0IHdhcyBhbHJlYWR5IGluIHRoZSBkcmFmdCB0YWJsZSBmb3IgDQo2MzktMyBtaWdodCBt ZWV0IHlvdXIgbmVlZCwgYW5kIHRoYXQgY2F0ZWdvcnkgd2FzIHRoZSBvbmUgY29kZWQg4oCcZ3N3 4oCdIHdpdGggDQpzZW1hbnRpY3MgZGVmaW5lZCBpbiBFdGhub2xvZ3VlLiBEZWZpbml0ZWx5IHRo ZSBKQUMgd2FzIGluY29ycG9yYXRpbmcgaW50byANCnBhcnQgMiB0aGUgaXRlbSBpbiB0aGUgZHJh ZnQgY29kZSB0YWJsZSBmb3IgcGFydCAzOyBJIGJlbGlldmUgdGhhdCBhbGwgDQphbG9uZyB0aGUg SkFDIHVuZGVyc3Rvb2QgdGhhdCB0byBoYXZlIHRoZSBzZW1hbnRpY3Mgb2Yg4oCcU3dpc3MgR2Vy bWFu4oCdIChvciANCuKAnFNjaHd5emVyZMO8dHNjaOKAnSkg4oCTIGNlcnRhaW5seSBJIGRpZCwg YnV0IGFnYWluIEnigJlkIG5lZWQgdG8gcmV2aWV3IA0KZGlzY3Vzc2lvbnMgdG8gYmUgbW9yZSBj ZXJ0YWluLg0KIA0KIA0KUGV0ZXINCiANCg0KRnJvbTogS2FyZW5fQnJvb21lQHNwZS5zb255LmNv bSBbbWFpbHRvOkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb21dIA0KU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDMwLCAyMDA2IDQ6NTEgUE0NClRvOiBQZXRlciBDb25zdGFibGUNCkNjOiBIw6V2YXJk IEhqdWxzdGFkOyBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsgDQppZXRmLWxhbmd1YWdlcy1ib3Vu Y2VzQGFsdmVzdHJhbmQubm87IGlzbzYzOUBka3V1Zy5kazsgaXNvNjM5LTJAbG9jLmdvdjsgDQpJ U08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZTsgTFRSVSBXb3JraW5nIEdyb3VwOyBNYXJr IERhdmlzOyANCnphaWl0b3ZAZ21haWwuY29tDQpTdWJqZWN0OiBSRTogW0x0cnVdIEFsZW1hbmlj ICYgU3dpc3MgR2VybWFuDQogDQoNClBldGVyLCANCg0KSSdtIG5vdCBxdWl0ZSBzdXJlIHlvdXIg dGFrZSBvbiB0aGlzIHJlcHJlc2VudHMgd2hhdCB3YXMgb24gbXkgSVNPIA0KYXBwbGljYXRpb24u IFRoZSBhcHBsaWNhdGlvbiBkcmF3cyBhdHRlbnRpb24gdG8gb3RoZXIgcmVnaW9ucyB3aGVyZSAN CkFsZW1hbmljIGRpYWxlY3RzIGNhbiBiZSBmb3VuZCAoc2VlOiAiYWRkaW5mbyIgc2VjdGlvbiku IEkgYmVsaWV2ZSB0aGUgDQpGcmVuY2ggbmFtZSB0eXBpY2FsbHkgaW5kaWNhdGVzIGEgYnJvYWRl ciByYW5nZSBvZiBkaWFsZWN0cyBhcyB3ZWxsOiANCg0KPiA+IFRoaXMgZGF0YSB3YXMgc3VibWl0 dGVkIG9uOiBXZWRuZXNkYXksIEp1bmUgMTUsIDIwMDUgYXQgMTk6MDg6MDANCj4gPiANCj4gPiBs YW5nX2luX2VuZyA9IFN3aXNzIEdlcm1hbiwgQWxlbWFuaWMNCj4gPiBsYW5nX2luX2ZyZSA9IGFs w6ltYW5pcXVlDQo+ID4gcmVmX3doZXJlX2ZvdW5kXzEgPSBodHRwOi8vd3d3LmV0aG5vbG9ndWUu Y29tDQo+ID4gbGFuZ19pbl92ZXJuID0gU2Nod3l6ZXJkw7x0c2NoLCBTY2h3ZWl6ZXJkZXV0c2No LCBTY2h3aWl6ZXJkw7x0c2NoLCANCj4gU2Nod3l6ZXJ0w7x0c2NoLCBTY2h3aXplcnRpdHNjaA0K PiA+IHJlZl93aGVyZV9mb3VuZF8yID0gSVNPIDYzOS0zIERJUywgaHR0cDovL3d3dy5ldGhub2xv Z3VlLmNvbSwgDQpodHRwOi8vd3d3Lndpa2lwZWRpYS5jb20NCj4gPiB0cmFuc19saXQgPSANCj4g PiBldmlkZW5jZSA9IEFHSUNPQSwgdGhlIEFzc29jaWF0aW9uIG9mIEludGVybmF0aW9uYWwgQ29s bGVjdGl2ZSANCj4gTWFuYWdlbWVudCBvZiBBdWRpb3Zpc3VhbCBXb3JrcyAoQXNzb2NpYXRpb24g ZGUgR2VzdGlvbiBJbnRlcm5hdGlvbmFsZSANCj4gQ29sbGVjdGl2ZSBkZXMgT2V1dnJlcyBBdWRp b3Zpc3VlbGxlcyk7IDQyOCBkb2N1bWVudHMgKGF1ZGlvdmlzdWFsKQ0KPiA+IA0KPiA+IGh0dHA6 Ly93d3cuYWdpY29hLm9yZw0KPiA+IGFkZGluZm8gPSA0LDIxNSwwMDAgaW4gU3dpdHplcmxhbmQg KDE5OTAgY2Vuc3VzKS4gUG9wdWxhdGlvbiB0b3RhbCBhbGwgDQoNCj4gY291bnRyaWVzOiA2LDA0 NCwwMDAuIENlbnRyYWwsIHNvdXRoIGNlbnRyYWwsIG5vcnRoIGNlbnRyYWwsIG5vcnRoZWFzdCwg DQo+IGFuZCBlYXN0ZXJuIGNhbnRvbnMuIEFsc28gc3Bva2VuIGluIEF1c3RyaWEsIEZyYW5jZSwg R2VybWFueSwgDQo+IExpZWNodGVuc3RlaW4uDQoNClJlZ2FyZHMsIA0KDQpLYXJlbiBCcm9vbWUN Ck1ldGFkYXRhIFN5c3RlbXMgRGVzaWduZXINClNvbnkgUGljdHVyZXMgRW50ZXJ0YWlubWVudA0K MzEwLjI0NC40Mzg0IA0KDQoNClBldGVyIENvbnN0YWJsZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNv bT4gDQpTZW50IGJ5OiBpZXRmLWxhbmd1YWdlcy1ib3VuY2VzQGFsdmVzdHJhbmQubm8gDQoxMS8z MC8yMDA2IDAyOjU5IFBNIA0KDQoNClRvDQpNYXJrIERhdmlzIDxtYXJrLmRhdmlzQGljdS1wcm9q ZWN0Lm9yZz4gDQpjYw0KTFRSVSBXb3JraW5nIEdyb3VwIDxsdHJ1QGlldGYub3JnPiwgemFpaXRv dkBnbWFpbC5jb20sIGlzbzYzOS0yQGxvYy5nb3YsIA0KSMOldmFyZCBIanVsc3RhZCA8SEhqQHN0 YW5kYXJkLm5vPiwgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUgDQo8SVNPSkFDQGxv Yy5nb3Y+LCBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZywgaXNvNjM5QGRrdXVnLmRrIA0KU3ViamVj dA0KUkU6IFtMdHJ1XSBBbGVtYW5pYyAmIFN3aXNzIEdlcm1hbg0KIA0KDQoNCiANCiANCg0KDQoN Cg0KSSBjYW4gdGVsbCB5b3UgdGhhdCB0aGUgaW50ZW50IG9mIOKAnGdzd+KAnSBpcyBzcGVjaWZp Y2FsbHkgU3dpc3MgR2VybWFuLCBhbmQgDQp0aGF0IHRoZSBhc3N1bXB0aW9uIG9mIGhhdmluZyDi gJxBbGVtYW5pY+KAnSBsaXN0ZWQgYXMgYSBuYW1lIGlzIHRoYXQgc29tZSANCnBlb3BsZSB1c2Ug dGhhdCBsYWJlbCB0byByZWZlciB0byBzcGVjaWZpY2FsbHkgdG8gU3dpc3MgR2VybWFuLiBJZiB0 aGUgDQpsYXR0ZXIgYXNzdW1wdGlvbiBpcyBpbmNvcnJlY3QgKHdoaWNoIGFwcGVhcnMgdG8gYmUg d2hhdCBNYXJrIGlzIHNheWluZywgDQp0aGVuIHRoYXQgaXMgYSBjaGFuZ2UgdGhhdCB0aGUgSkFD IHNob3VsZCBjb25zaWRlci4gDQogIA0KQnV0IGlmIE1hcnRpbuKAmXMgY29tbWVudCBpcyB0aGUg c3VwcG9ydGluZyBldmlkZW5jZSwgdGhlbiBJIHN0aWxsIGZpbmQgDQpNYXJ0aW7igJlzIGNvbW1l bnQgdG8gYmUgdW5jbGVhci4gSXTigJlzIGNsZWFyIHRvIG1lIHdoYXQgTWFyayBpcyBzYXlpbmc7 IGl04oCZcyANCm5vdCBjbGVhciB0byBtZSBpZiBNYXJ0aW4gaXMgc2F5aW5nIHRoZSBzYW1lIHRo aW5nLiANCiAgDQogIA0KUGV0ZXIgQ29uc3RhYmxlIA0KICANCiAgDQogIA0KDQpGcm9tOiBtYXJr LmVkd2FyZC5kYXZpc0BnbWFpbC5jb20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5j b21dIE9uIA0KQmVoYWxmIE9mIE1hcmsgRGF2aXMNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAz MCwgMjAwNiAxMTowNyBBTQ0KVG86IFBldGVyIENvbnN0YWJsZQ0KQ2M6IEjDpXZhcmQgSGp1bHN0 YWQ7IGlzbzYzOS0yQGxvYy5nb3Y7IExUUlUgV29ya2luZyBHcm91cDsgDQp6YWlpdG92QGdtYWls LmNvbTsgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWU7IA0KaWV0Zi1sYW5ndWFnZXNA aWFuYS5vcmc7IGlzbzYzOUBka3V1Zy5kaw0KU3ViamVjdDogUmU6IFtMdHJ1XSBBbGVtYW5pYyAm IFN3aXNzIEdlcm1hbiANCiANCkFsZW1hbmljIHJlZmVycyB0byBhIGJyb2FkZXIgZ3JvdXAgb2Yg ZGlhbGVjdHMgdGhhbiAiU3dpc3MgR2VybWFuIiAoYWthIA0KU2Nod3l6ZXJ0dWVzY2gpIGRvZXMu IFNvIGxpc3RpbmcgdGhlbSBhcyBpdCBkb2VzIGlzIHByb2JsZW1hdGljOyBpdCdzIGxpa2UgDQps aXN0aW5nDQoNCmFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljDQoNClBlcnNvbmFsbHksIEkgZG9u J3QgY2FyZSB3aGV0aGVyIGl0IGlzIHJlc29sdmVkIHRvIGJlIA0KDQpBbGVtYW5pYyAoaW5jbHVk aW5nIFN3aXNzIEdlcm1hbikgDQovLyB3aGljaCBpcyB3aGF0IDYzOS0zIHNlZW1zIHRvIGJlIHBv aW50aW5nIHRvDQoNCm9yDQoNClN3aXNzIEdlcm1hbiAoYSBwYXJ0aWN1bGFyIHZhcmlhbnQgb2Yg QWxlbWFuaWMpDQovLyB3aGljaCBpcyB3aGF0IHRoZSBjb2RlIChnc3cpIHNlZW1zIHRvIGJlIHBv aW50aW5nIHRvDQoNCkJ1dCB3ZSBuZWVkIHNvbWUgY2xhcml0eSBhcyB0byB3aGF0IGlzIG1lYW50 IGJ5IHRoZSBjb2RlLiANCg0KTWFyayANCk9uIDExLzMwLzA2LCBQZXRlciBDb25zdGFibGUgPHBl dGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOiANCk1hcnRpbidzIGNvbW1lbnQgaXMgc29tZXdo YXQgdmFndWU6IHZhcmlldGllcyBzcG9rZW4gb24gZWl0aGVyIHNpZGUgb2YgdGhlIA0KYm9yZGVy IGFyZSB2ZXJ5IHNpbWlsYXIsIGV0ICJhcyBzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyIGl0 J3MgdmVyeSANCmNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzIEdlcm1hbiIuIERvZXMgdGhhdCBtZWFu IHRoYXQgd2hhdCBpcyBzcG9rZW4gYWNyb3NzIA0KdGhlIGJvcmRlciBpcyBjbGVhcmx5IGEgZGlm ZmVyZW50IGxhbmd1YWdlLCBvciB0aGF0IHRoZSBsYWJlbCAiU3dpc3MgDQpHZXJtYW4iIGlzIGNs ZWFybHkgbm90IHVzZWQ/IA0KICANCiAgDQpQZXRlciANCiAgDQoNCkZyb206IE1hcmsgRGF2aXMg W21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gDQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMzAsIDIwMDYgOTowMCBBTQ0KVG86IEjDpXZhcmQgSGp1bHN0YWQ7IGlzbzYzOS0yQGxv Yy5nb3YNCkNjOiBMVFJVIFdvcmtpbmcgR3JvdXA7IHphaWl0b3ZAZ21haWwuY29tOyBJU08gNjM5 IEpvaW50IEFkdmlzb3J5IA0KQ29tbWl0dGVlOyBpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzsgaXNv NjM5QGRrdXVnLmRrDQpTdWJqZWN0OiBbTHRydV0gQWxlbWFuaWMgJiBTd2lzcyBHZXJtYW4gDQog DQpJU08gNjM5LTIgKG9uIGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhw L2NvZGVfbGlzdC5waHApIA0KbGlzdHMgdGhlIGZvbGxvd2luZzoNCg0KZ3N3ICAgICAgICAgICAg IEFsZW1hbmk7IFN3aXNzIEdlcm1hbiAgICAgIGFsw6ltYW5pcXVlIA0KDQpIb3dldmVyLCB0aGVy ZSBpcyBhICJjIiBtaXNzaW5nIGZyb20gQWxlbWFuaWMsIGFuZCBTd2lzcyBHZXJtYW4gaXMgbm90 IHRoZSANCnNhbWUgYXMgQWxlbWFuaWM6IFN3aXNzIEdlcm1hbiBpcyBhIHR5cGUgb2YgQWxlbWFu aWMsIGJ1dCB0aGVyZSBhcmUgb3RoZXIgDQp0eXBlcyB0aGF0IGFyZSBub3QgdGhlIHNhbWUgYXMg U3dpc3MgR2VybWFuLg0KDQpRdW90aW5nIE1hcnRpbiBEdWVyc3Q6IA0KDQoiWWVzLCBTd2FiaWFu IGlzIGNsZWFybHkgQWxlbWFuaWMuIEFsZW1hbmljIGFuZCBTd2lzcyBHZXJtYW4gYXJlIG5vdA0K dGhlIHNhbWUuIFRoZXJlIGFyZSB2ZXJ5IGNsb3NlIHNpbWlsYXJpdGllcyBiZXR3ZWVuIHNvbWUg ZGlhbGVjdHMgaW4gDQp0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9zcyB0aGUgYm9y ZGVyIGluIEdlcm1hbnksIGJ1dCBhcw0Kc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGJvcmRlciwgaXQn cyB2ZXJ5IGNsZWFybHkgbm8gbG9uZ2VyIFN3aXNzDQpHZXJtYW4uIEEgbGFiZWwgc3VjaCBhcyAi QWxlbWFuaWM7IFN3aXNzIEdlcm1hbiIsIGFzc3VtaW5nIHRoYXQgDQpib3RoIGFyZSB0aGUgc2Ft ZSwgaXMgY2xlYXJseSB3cm9uZy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZQ0KIkFsZW1hbmljOyBp bmNsdWRlcyBTd2lzcyBHZXJtYW4iLCB0aGF0IHdvdWxkIGJlIG9rYXkuIg0KDQpDYW4gdGhpcyBi ZSBjb3JyZWN0ZWQgc28gdGhhdCBpdCBkb2VzIG5vdCBjb250aW51ZSB0byBtaXNsZWFkIHBlb3Bs ZT8gDQoNCk1hcmsgRGF2aXMgDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklldGYtbGFuZ3VhZ2VzIG1haWxpbmcgbGlzdA0KSWV0Zi1sYW5ndWFnZXNA YWx2ZXN0cmFuZC5ubw0KaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8v aWV0Zi1sYW5ndWFnZXMNCg0K --=_alternative 000AA8EE88257237_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="UTF-8" DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFyZSB3ZSByZWFkaW5nIHRoZSBz YW1lIEV0aG5vbG9ndWUgcGFnZT8NCkV0aG5vbG9ndWUgc2VlbXMgdG8gaW5jbHVkZSB0aGUgQXVz dHJpYW4gZm9ybXMgYW5kIG1lbnRpb25zIHRoYXQgY2VydGFpbg0KZGlhbGVjdHMgd2l0aGluIHRo aXMgbGFuZ3VhZ2UgZmFtaWx5IG1heSBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIHNwZWFrZXJzDQpv ZiBvdGhlciBkaWFsZWN0cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkknbSBub3QgdHJ5aW5nIHRvIGJlIGRpZmZpY3VsdCAmbmJzcDstLQ0KdG9kYXkg OikgLS0gYW5kIGNlcnRhaW5seSBhcHByZWNpYXRlIHlvdXIgcHJldmlvdXMgaGVscCBpbiBzb3J0 aW5nIG91dA0KdGhlc2UgaXNzdWVzLCBidXQgSSBoYXZlIGNpcmN1bGF0ZWQgdGhlIGNvZGVzIGdz dy1DSCBhbmQgZ3N3LUFUIHRvIGEgZmFpcmx5DQp3aWRlIGF1ZGllbmNlIGJhc2VkIG9uIGFzc3Vt cHRpb25zIHRoYXQgc2VlbSB0byBiZSBmYWlybHkgd2VsbC1kb2N1bWVudGVkDQpvbiBFdGhub2xv Z3VlLCBteSBhcHBsaWNhdGlvbiwgSVNPJ3MgYXBwcm92YWwsIGFuZCB2YXJpb3VzIG90aGVyIHJl c291cmNlcw0KdGhhdCBsdW1wIHRoZXNlIHJlZ2lvbmFsIGRpYWxlY3RzIHRvZ2V0aGVyLiBEb2Vz IDYzOS0zIHNob3VsZCBoYXZlIGEgbWFjcm9sYW5ndWFnZQ0KZm9yIHRoaXM/IElmIG5vdCwgc2hv dWxkIGl0PyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkknZCBhcHByZWNpYXRlIGl0IGlmIHlvdSBjb3VsZCByZXZpZXcNCnlvdXIgbm90ZXMgYmVmb3Jl IGFjdGluZyBvbiB0aGlzIHN1Z2dlc3RlZCBjaGFuZ2UuIDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+S2FyZW4gPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBldGVyIENvbnN0YWJs ZSAmbHQ7cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTEvMzAvMjAwNiAwNTozNCBQTTwvZm9udD4NCjx0ZCB3 aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtLYXJlbl9Ccm9vbWVA c3BlLnNvbnkuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkjDpXZhcmQgSGp1bHN0YWQgJmx0O0hI akBzdGFuZGFyZC5ubyZndDssDQombHQ7aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmcmZ3Q7LCAmbHQ7 aWV0Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vJmd0OywNCiZsdDtpc282MzlAZGt1 dWcuZGsmZ3Q7LCAmbHQ7aXNvNjM5LTJAbG9jLmdvdiZndDssIElTTyA2MzkgSm9pbnQgQWR2aXNv cnkNCkNvbW1pdHRlZSAmbHQ7SVNPSkFDQGxvYy5nb3YmZ3Q7LCBMVFJVIFdvcmtpbmcgR3JvdXAg Jmx0O2x0cnVAaWV0Zi5vcmcmZ3Q7LA0KTWFyayBEYXZpcyAmbHQ7bWFyay5kYXZpc0BpY3UtcHJv amVjdC5vcmcmZ3Q7LCAmbHQ7emFpaXRvdkBnbWFpbC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SRTogW0x0cnVdIEFsZW1hbmljICZhbXA7IFN3aXNzIEdlcm1hbjwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlZlcmRhbmEiPknigJlsbCBoYXZlIHRvIGNoZWNrIGVtYWlsIHRvDQpiZSBzdXJlLCBidXQgbXkg cmVjb2xsZWN0aW9uIHdhcyB0aGF0IEkgaGFkIHN1Z2dlc3RlZCB0byB5b3UgdGhhdCB0aGUgY2F0 ZWdvcnkNCnRoYXQgd2FzIGFscmVhZHkgaW4gdGhlIGRyYWZ0IHRhYmxlIGZvciA2MzktMyBtaWdo dCBtZWV0IHlvdXIgbmVlZCwgYW5kDQp0aGF0IGNhdGVnb3J5IHdhcyB0aGUgb25lIGNvZGVkIOKA nGdzd+KAnSB3aXRoIHNlbWFudGljcyBkZWZpbmVkIGluIEV0aG5vbG9ndWUuDQpEZWZpbml0ZWx5 IHRoZSBKQUMgd2FzIGluY29ycG9yYXRpbmcgaW50byBwYXJ0IDIgdGhlIGl0ZW0gaW4gdGhlIGRy YWZ0DQpjb2RlIHRhYmxlIGZvciBwYXJ0IDM7IEkgYmVsaWV2ZSB0aGF0IGFsbCBhbG9uZyB0aGUg SkFDIHVuZGVyc3Rvb2QgdGhhdA0KdG8gaGF2ZSB0aGUgc2VtYW50aWNzIG9mIOKAnFN3aXNzIEdl cm1hbuKAnSAob3Ig4oCcU2Nod3l6ZXJkw7x0c2No4oCdKSDigJMgY2VydGFpbmx5DQpJIGRpZCwg YnV0IGFnYWluIEnigJlkIG5lZWQgdG8gcmV2aWV3IGRpc2N1c3Npb25zIHRvIGJlIG1vcmUgY2Vy dGFpbi48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj4m bmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj4m bmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj5Q ZXRlcjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZu YnNwOzwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0KPHA+DQo8aHI+PC9kaXY+DQo8cD48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gS2FyZW5fQnJvb21lQHNwZS5zb255 LmNvbSBbbWFpbHRvOkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb21dDQo8Yj48YnI+DQpTZW50Ojwv Yj4gVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDA2IDQ6NTEgUE08Yj48YnI+DQpUbzo8L2I+IFBl dGVyIENvbnN0YWJsZTxiPjxicj4NCkNjOjwvYj4gSMOldmFyZCBIanVsc3RhZDsgaWV0Zi1sYW5n dWFnZXNAaWFuYS5vcmc7IGlldGYtbGFuZ3VhZ2VzLWJvdW5jZXNAYWx2ZXN0cmFuZC5ubzsNCmlz bzYzOUBka3V1Zy5kazsgaXNvNjM5LTJAbG9jLmdvdjsgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBD b21taXR0ZWU7IExUUlUNCldvcmtpbmcgR3JvdXA7IE1hcmsgRGF2aXM7IHphaWl0b3ZAZ21haWwu Y29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJFOiBbTHRydV0gQWxlbWFuaWMgJmFtcDsgU3dpc3Mg R2VybWFuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClBldGVy LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJJ20gbm90IHF1aXRlIHN1cmUg eW91ciB0YWtlIG9uIHRoaXMgcmVwcmVzZW50cyB3aGF0IHdhcyBvbiBteSBJU08gYXBwbGljYXRp b24uDQpUaGUgYXBwbGljYXRpb24gZHJhd3MgYXR0ZW50aW9uIHRvIG90aGVyIHJlZ2lvbnMgd2hl cmUgQWxlbWFuaWMgZGlhbGVjdHMNCmNhbiBiZSBmb3VuZCAoc2VlOiAmcXVvdDthZGRpbmZvJnF1 b3Q7IHNlY3Rpb24pLiBJIGJlbGlldmUgdGhlIEZyZW5jaCBuYW1lDQp0eXBpY2FsbHkgaW5kaWNh dGVzIGEgYnJvYWRlciByYW5nZSBvZiBkaWFsZWN0cyBhcyB3ZWxsOjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJmd0OyBUaGlzIGRhdGEgd2FzIHN1Ym1pdHRlZCBv bjogV2VkbmVzZGF5LCBKdW5lIDE1LCAyMDA1IGF0IDE5OjA4OjAwPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBsYW5nX2luX2VuZyA9IFN3aXNzIEdlcm1hbiwgQWxlbWFuaWM8YnI+DQom Z3Q7ICZndDsgbGFuZ19pbl9mcmUgPSBhbMOpbWFuaXF1ZTxicj4NCiZndDsgJmd0OyByZWZfd2hl cmVfZm91bmRfMSA9IGh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb208YnI+DQomZ3Q7ICZndDsgbGFu Z19pbl92ZXJuID0gU2Nod3l6ZXJkw7x0c2NoLCBTY2h3ZWl6ZXJkZXV0c2NoLCBTY2h3aWl6ZXJk w7x0c2NoLA0KPGJyPg0KJmd0OyBTY2h3eXplcnTDvHRzY2gsIFNjaHdpemVydGl0c2NoPGJyPg0K Jmd0OyAmZ3Q7IHJlZl93aGVyZV9mb3VuZF8yID0gSVNPIDYzOS0zIERJUywgaHR0cDovL3d3dy5l dGhub2xvZ3VlLmNvbSwNCmh0dHA6Ly93d3cud2lraXBlZGlhLmNvbTxicj4NCiZndDsgJmd0OyB0 cmFuc19saXQgPSA8YnI+DQomZ3Q7ICZndDsgZXZpZGVuY2UgPSBBR0lDT0EsIHRoZSBBc3NvY2lh dGlvbiBvZiBJbnRlcm5hdGlvbmFsIENvbGxlY3RpdmUNCjxicj4NCiZndDsgTWFuYWdlbWVudCBv ZiBBdWRpb3Zpc3VhbCBXb3JrcyAoQXNzb2NpYXRpb24gZGUgR2VzdGlvbiBJbnRlcm5hdGlvbmFs ZQ0KPGJyPg0KJmd0OyBDb2xsZWN0aXZlIGRlcyBPZXV2cmVzIEF1ZGlvdmlzdWVsbGVzKTsgNDI4 IGRvY3VtZW50cyAoYXVkaW92aXN1YWwpPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBo dHRwOi8vd3d3LmFnaWNvYS5vcmc8YnI+DQomZ3Q7ICZndDsgYWRkaW5mbyA9IDQsMjE1LDAwMCBp biBTd2l0emVybGFuZCAoMTk5MCBjZW5zdXMpLiBQb3B1bGF0aW9uDQp0b3RhbCBhbGwgPGJyPg0K Jmd0OyBjb3VudHJpZXM6IDYsMDQ0LDAwMC4gQ2VudHJhbCwgc291dGggY2VudHJhbCwgbm9ydGgg Y2VudHJhbCwgbm9ydGhlYXN0LA0KPGJyPg0KJmd0OyBhbmQgZWFzdGVybiBjYW50b25zLiBBbHNv IHNwb2tlbiBpbiBBdXN0cmlhLCBGcmFuY2UsIEdlcm1hbnksIDxicj4NCiZndDsgTGllY2h0ZW5z dGVpbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSZWdhcmRzLDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpLYXJlbiBCcm9vbWU8YnI+DQpNZXRhZGF0YSBT eXN0ZW1zIERlc2lnbmVyPGJyPg0KU29ueSBQaWN0dXJlcyBFbnRlcnRhaW5tZW50PGJyPg0KMzEw LjI0NC40Mzg0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+ DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MTklPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QZXRlciBDb25zdGFi bGUgJmx0O3BldGVyY29uQG1pY3Jvc29mdC5jb20mZ3Q7PC9iPg0KPGJyPg0KU2VudCBieTogaWV0 Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjExLzMwLzIwMDYgMDI6NTkgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9ODAlPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00JT4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRo PTk1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TWFyayBEYXZpcyAmbHQ7bWFyay5k YXZpc0BpY3UtcHJvamVjdC5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TFRSVSBXb3JraW5nIEdyb3VwICZsdDtsdHJ1 QGlldGYub3JnJmd0OywNCnphaWl0b3ZAZ21haWwuY29tLCBpc282MzktMkBsb2MuZ292LCBIw6V2 YXJkIEhqdWxzdGFkICZsdDtISGpAc3RhbmRhcmQubm8mZ3Q7LA0KSVNPIDYzOSBKb2ludCBBZHZp c29yeSBDb21taXR0ZWUgJmx0O0lTT0pBQ0Bsb2MuZ292Jmd0OywgaWV0Zi1sYW5ndWFnZXNAaWFu YS5vcmcsDQppc282MzlAZGt1dWcuZGs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+IDwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtMdHJ1XSBBbGVtYW5pYyAmYW1w OyBTd2lzcyBHZXJtYW48L2ZvbnQ+PC90YWJsZT4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHRkIHdpZHRoPTUwJT48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPjxicj4NCkkgY2FuIHRlbGwg eW91IHRoYXQgdGhlIGludGVudCBvZiDigJxnc3figJ0gaXMgc3BlY2lmaWNhbGx5IFN3aXNzIEdl cm1hbiwNCmFuZCB0aGF0IHRoZSBhc3N1bXB0aW9uIG9mIGhhdmluZyDigJxBbGVtYW5pY+KAnSBs aXN0ZWQgYXMgYSBuYW1lIGlzIHRoYXQNCnNvbWUgcGVvcGxlIHVzZSB0aGF0IGxhYmVsIHRvIHJl ZmVyIHRvIHNwZWNpZmljYWxseSB0byBTd2lzcyBHZXJtYW4uIElmDQp0aGUgbGF0dGVyIGFzc3Vt cHRpb24gaXMgaW5jb3JyZWN0ICh3aGljaCBhcHBlYXJzIHRvIGJlIHdoYXQgTWFyayBpcyBzYXlp bmcsDQp0aGVuIHRoYXQgaXMgYSBjaGFuZ2UgdGhhdCB0aGUgSkFDIHNob3VsZCBjb25zaWRlci48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj5CdXQgaWYgTWFydGlu4oCZcyBjb21tZW50IGlzIHRo ZQ0Kc3VwcG9ydGluZyBldmlkZW5jZSwgdGhlbiBJIHN0aWxsIGZpbmQgTWFydGlu4oCZcyBjb21t ZW50IHRvIGJlIHVuY2xlYXIuDQpJdOKAmXMgY2xlYXIgdG8gbWUgd2hhdCBNYXJrIGlzIHNheWlu ZzsgaXTigJlzIG5vdCBjbGVhciB0byBtZSBpZiBNYXJ0aW4NCmlzIHNheWluZyB0aGUgc2FtZSB0 aGluZy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD4N CjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlZlcmRhbmEiPlBldGVyIENvbnN0YWJsZTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRh bmEiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxkaXYg YWxpZ249Y2VudGVyPg0KPHA+DQo8aHI+PC9kaXY+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj5Gcm9tOjwvYj4gbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tDQpbbWFpbHRvOm1h cmsuZWR3YXJkLmRhdmlzQGdtYWlsLmNvbV0gPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJrIERhdmlz PGI+PGJyPg0KU2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAzMCwgMjAwNiAxMTowNyBBTTxi Pjxicj4NClRvOjwvYj4gUGV0ZXIgQ29uc3RhYmxlPGI+PGJyPg0KQ2M6PC9iPiBIw6V2YXJkIEhq dWxzdGFkOyBpc282MzktMkBsb2MuZ292OyBMVFJVIFdvcmtpbmcgR3JvdXA7IHphaWl0b3ZAZ21h aWwuY29tOw0KSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWU7IGlldGYtbGFuZ3VhZ2Vz QGlhbmEub3JnOyBpc282MzlAZGt1dWcuZGs8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtMdHJ1 XSBBbGVtYW5pYyAmYW1wOyBTd2lzcyBHZXJtYW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDsgPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+QWxlbWFuaWMgcmVmZXJzIHRvIGEgYnJvYWRlciBncm91cA0Kb2YgZGlhbGVjdHMgdGhh biAmcXVvdDtTd2lzcyBHZXJtYW4mcXVvdDsgKGFrYSBTY2h3eXplcnR1ZXNjaCkgZG9lcy4gU28N Cmxpc3RpbmcgdGhlbSBhcyBpdCBkb2VzIGlzIHByb2JsZW1hdGljOyBpdCdzIGxpa2UgbGlzdGlu Zzxicj4NCjxicj4NCmFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljPGJyPg0KPGJyPg0KUGVyc29u YWxseSwgSSBkb24ndCBjYXJlIHdoZXRoZXIgaXQgaXMgcmVzb2x2ZWQgdG8gYmUgPGJyPg0KPGJy Pg0KQWxlbWFuaWMgKGluY2x1ZGluZyBTd2lzcyBHZXJtYW4pIDxicj4NCi8vIHdoaWNoIGlzIHdo YXQgNjM5LTMgc2VlbXMgdG8gYmUgcG9pbnRpbmcgdG88YnI+DQo8YnI+DQpvcjxicj4NCjxicj4N ClN3aXNzIEdlcm1hbiAoYSBwYXJ0aWN1bGFyIHZhcmlhbnQgb2YgQWxlbWFuaWMpPGJyPg0KLy8g d2hpY2ggaXMgd2hhdCB0aGUgY29kZSAoZ3N3KSBzZWVtcyB0byBiZSBwb2ludGluZyB0bzxicj4N Cjxicj4NCkJ1dCB3ZSBuZWVkIHNvbWUgY2xhcml0eSBhcyB0byB3aGF0IGlzIG1lYW50IGJ5IHRo ZSBjb2RlLiA8YnI+DQo8YnI+DQpNYXJrIDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPk9uIDExLzMwLzA2LCA8Yj5QZXRlciBDb25zdGFibGU8L2I+DQombHQ7 PC9mb250PjxhIGhyZWY9bWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5wZXRlcmNvbkBtaWNyb3NvZnQu Y29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jmd0 Ow0Kd3JvdGU6IDwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRh bmEiPk1hcnRpbidzIGNvbW1lbnQgaXMgc29tZXdoYXQNCnZhZ3VlOiB2YXJpZXRpZXMgc3Bva2Vu IG9uIGVpdGhlciBzaWRlIG9mIHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwNCmV0ICZxdW90 O2FzIHNvb24gYXMgeW91IGNyb3NzIHRoZSBib3JkZXIgaXQncyB2ZXJ5IGNsZWFybHkgbm8gbG9u Z2VyIFN3aXNzDQpHZXJtYW4mcXVvdDsuIERvZXMgdGhhdCBtZWFuIHRoYXQgd2hhdCBpcyBzcG9r ZW4gYWNyb3NzIHRoZSBib3JkZXIgaXMgY2xlYXJseQ0KYSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9y IHRoYXQgdGhlIGxhYmVsICZxdW90O1N3aXNzIEdlcm1hbiZxdW90OyBpcyBjbGVhcmx5DQpub3Qg dXNlZD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD4N CjxwPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlZlcmRhbmEiPlBldGVyPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVy ZGFuYSI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K PC9mb250Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8cD4NCjxocj48L2Rpdj4NCjxwPjxmb250IHNp emU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBNYXJrIERhdmlzIFttYWlsdG86PC9mb250 PjxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZyIgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1hcmsuZGF2aXNAaWN1 LXByb2plY3Qub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0K PGI+PGJyPg0KU2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAzMCwgMjAwNiA5OjAwIEFNPGI+ PGJyPg0KVG86PC9iPiBIw6V2YXJkIEhqdWxzdGFkOyA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmlz bzYzOS0yQGxvYy5nb3YiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iVGFob21hIj48dT5pc282MzktMkBsb2MuZ292PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KQ2M6PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA7IDwvZm9u dD48YSBocmVmPW1haWx0bzp6YWlpdG92QGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+emFpaXRvdkBnbWFpbC5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQpJU08gNjM5IEpvaW50IEFkdmlz b3J5IENvbW1pdHRlZTsgPC9mb250PjxhIGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlc0BpYW5h Lm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi Pjx1PmlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRhaG9tYSI+Ow0KPC9mb250PjxhIGhyZWY9bWFpbHRvOmlzbzYzOUBka3V1Zy5kayB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aXNvNjM5 QGRrdXVnLmRrPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJy Pg0KU3ViamVjdDo8L2I+IFtMdHJ1XSBBbGVtYW5pYyAmYW1wOyBTd2lzcyBHZXJtYW48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsgPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SVNPIDYzOS0yIChvbiA8L2ZvbnQ+PGEgaHJlZj0i aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi9waHAvY29kZV9saXN0LnBocCIg dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjx1Pmh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhwL2NvZGVfbGlz dC5waHA8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4p DQpsaXN0cyB0aGUgZm9sbG93aW5nOjxicj4NCjxicj4NCmdzdyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGVtYW5pOyBTd2lzcyBHZXJtYW4gJm5ic3A7DQombmJz cDsgJm5ic3A7YWzDqW1hbmlxdWUgPGJyPg0KPGJyPg0KSG93ZXZlciwgdGhlcmUgaXMgYSAmcXVv dDtjJnF1b3Q7IG1pc3NpbmcgZnJvbSBBbGVtYW5pYywgYW5kIFN3aXNzIEdlcm1hbg0KaXMgbm90 IHRoZSBzYW1lIGFzIEFsZW1hbmljOiBTd2lzcyBHZXJtYW4gaXMgYSB0eXBlIG9mIEFsZW1hbmlj LCBidXQgdGhlcmUNCmFyZSBvdGhlciB0eXBlcyB0aGF0IGFyZSBub3QgdGhlIHNhbWUgYXMgU3dp c3MgR2VybWFuLjxicj4NCjxicj4NClF1b3RpbmcgTWFydGluIER1ZXJzdDogPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCiZxdW90O1llcywgU3dh YmlhbiBpcyBjbGVhcmx5IEFsZW1hbmljLiBBbGVtYW5pYyBhbmQgU3dpc3MgR2VybWFuIGFyZSBu b3Q8YnI+DQp0aGUgc2FtZS4gVGhlcmUgYXJlIHZlcnkgY2xvc2Ugc2ltaWxhcml0aWVzIGJldHdl ZW4gc29tZSBkaWFsZWN0cyBpbiA8YnI+DQp0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFj cm9zcyB0aGUgYm9yZGVyIGluIEdlcm1hbnksIGJ1dCBhczxicj4NCnNvb24gYXMgeW91IGNyb3Nz IHRoZSBib3JkZXIsIGl0J3MgdmVyeSBjbGVhcmx5IG5vIGxvbmdlciBTd2lzczxicj4NCkdlcm1h bi4gQSBsYWJlbCBzdWNoIGFzICZxdW90O0FsZW1hbmljOyBTd2lzcyBHZXJtYW4mcXVvdDssIGFz c3VtaW5nIHRoYXQNCjxicj4NCmJvdGggYXJlIHRoZSBzYW1lLCBpcyBjbGVhcmx5IHdyb25nLiBJ ZiBpdCdzIHNvbWV0aGluZyBsaWtlPGJyPg0KJnF1b3Q7QWxlbWFuaWM7IGluY2x1ZGVzIFN3aXNz IEdlcm1hbiZxdW90OywgdGhhdCB3b3VsZCBiZSBva2F5LiZxdW90Ozxicj4NCjxicj4NCkNhbiB0 aGlzIGJlIGNvcnJlY3RlZCBzbyB0aGF0IGl0IGRvZXMgbm90IGNvbnRpbnVlIHRvIG1pc2xlYWQg cGVvcGxlPyA8YnI+DQo8YnI+DQpNYXJrIERhdmlzIDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KSWV0Zi1sYW5ndWFnZXMgbWFpbGluZyBsaXN0PGJyPg0KSWV0Zi1sYW5ndWFnZXNAYWx2 ZXN0cmFuZC5ubzxicj4NCmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZv L2lldGYtbGFuZ3VhZ2VzPC9mb250Pg0KPHA+DQo= --=_alternative 000AA8EE88257237_=-- --===============1542771147== 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 --===============1542771147==-- From ltru-bounces@ietf.org Thu Nov 30 21:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyLD-0005n7-9M; Thu, 30 Nov 2006 21:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyLB-0005mz-Ob for ltru@ietf.org; Thu, 30 Nov 2006 21:41:29 -0500 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpyL7-0001HU-SI for ltru@ietf.org; Thu, 30 Nov 2006 21:41:29 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1147901wra for ; Thu, 30 Nov 2006 18:41:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gfbV2gef+7zBNvTm2qf0rHlefPClog7XF1H/+oBL8fymCKFvNYfE00TBZdkQtgRxc81Gy+Xdzn8gRqOJU8nGeqh9sHWDzGd7tu2bHy3Wy0jEk5JzTopSp7F3zF3CMKc6tThzbmMHU0tsA4Io31dQYLcCzE/7onadhRVxf2NWfNk= Received: by 10.100.120.5 with SMTP id s5mr1231853anc.1164940884737; Thu, 30 Nov 2006 18:41:24 -0800 (PST) Received: by 10.100.8.6 with HTTP; Thu, 30 Nov 2006 18:41:24 -0800 (PST) Message-ID: <30b660a20611301841m51b310a6hc81942b23ccf0547@mail.gmail.com> Date: Thu, 30 Nov 2006 18:41:24 -0800 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Alemanic & Swiss German In-Reply-To: MIME-Version: 1.0 References: <19A328037921AA42847A717566D1D6A109BC40AD@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: 5874a56068bbecc6 X-Spam-Score: 0.8 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Cc: LTRU Working Group , zaiitov@gmail.com, iso639-2@loc.gov, =?UTF-8?Q?H=C3=A5vard_Hjulstad?= , ietf-languages@iana.org, iso639@dkuug.dk X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842542347==" Errors-To: ltru-bounces@ietf.org --===============0842542347== Content-Type: multipart/alternative; boundary="----=_Part_6539_29042332.1164940884653" ------=_Part_6539_29042332.1164940884653 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgc291bmRzIG1vcmUgYW5kIG1vcmUgdG8gbWUgdGhhdCAiQWxlbWFuaWMiIHdhcyBzaW1wbHkg YSBtaXN0YWtlOyB0aGUKZGVzY3JpcHRpb24gc2hvdWxkIGJlICJTd2lzcyBHZXJtYW4iIGFsb25l LCBib3RoIGluIDYzOS0yIGFuZCA2MzktMy4KCk1hcmsKCk9uIDExLzMwLzA2LCBLYXJlbl9Ccm9v bWVAc3BlLnNvbnkuY29tIDxLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tPiB3cm90ZToKPgo+Cj4g QXJlIHdlIHJlYWRpbmcgdGhlIHNhbWUgRXRobm9sb2d1ZSBwYWdlPyBFdGhub2xvZ3VlIHNlZW1z IHRvIGluY2x1ZGUgdGhlCj4gQXVzdHJpYW4gZm9ybXMgYW5kIG1lbnRpb25zIHRoYXQgY2VydGFp biBkaWFsZWN0cyB3aXRoaW4gdGhpcyBsYW5ndWFnZQo+IGZhbWlseSBtYXkgbm90IGJlIGludGVs bGlnaWJsZSB0byBzcGVha2VycyBvZiBvdGhlciBkaWFsZWN0cy4KPgo+IEknbSBub3QgdHJ5aW5n IHRvIGJlIGRpZmZpY3VsdCAgLS0gdG9kYXkgOikgLS0gYW5kIGNlcnRhaW5seSBhcHByZWNpYXRl Cj4geW91ciBwcmV2aW91cyBoZWxwIGluIHNvcnRpbmcgb3V0IHRoZXNlIGlzc3VlcywgYnV0IEkg aGF2ZSBjaXJjdWxhdGVkIHRoZQo+IGNvZGVzIGdzdy1DSCBhbmQgZ3N3LUFUIHRvIGEgZmFpcmx5 IHdpZGUgYXVkaWVuY2UgYmFzZWQgb24gYXNzdW1wdGlvbnMgdGhhdAo+IHNlZW0gdG8gYmUgZmFp cmx5IHdlbGwtZG9jdW1lbnRlZCBvbiBFdGhub2xvZ3VlLCBteSBhcHBsaWNhdGlvbiwgSVNPJ3MK PiBhcHByb3ZhbCwgYW5kIHZhcmlvdXMgb3RoZXIgcmVzb3VyY2VzIHRoYXQgbHVtcCB0aGVzZSBy ZWdpb25hbCBkaWFsZWN0cwo+IHRvZ2V0aGVyLiBEb2VzIDYzOS0zIHNob3VsZCBoYXZlIGEgbWFj cm9sYW5ndWFnZSBmb3IgdGhpcz8gSWYgbm90LCBzaG91bGQKPiBpdD8KPgo+IEknZCBhcHByZWNp YXRlIGl0IGlmIHlvdSBjb3VsZCByZXZpZXcgeW91ciBub3RlcyBiZWZvcmUgYWN0aW5nIG9uIHRo aXMKPiBzdWdnZXN0ZWQgY2hhbmdlLgo+Cj4gQmVzdCByZWdhcmRzLAo+Cj4gS2FyZW4KPgo+Cj4K PiAgKlBldGVyIENvbnN0YWJsZSA8cGV0ZXJjb25AbWljcm9zb2Z0LmNvbT4qCj4KPiAxMS8zMC8y MDA2IDA1OjM0IFBNCj4gICBUbwo+IDxLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tPiAgY2MKPiBI w6V2YXJkIEhqdWxzdGFkIDxISGpAc3RhbmRhcmQubm8+LCA8aWV0Zi1sYW5ndWFnZXNAaWFuYS5v cmc+LCA8Cj4gaWV0Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vPiwgPGlzbzYzOUBk a3V1Zy5kaz4sIDwKPiBpc282MzktMkBsb2MuZ292PiwgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBD b21taXR0ZWUgPElTT0pBQ0Bsb2MuZ292PiwgTFRSVQo+IFdvcmtpbmcgR3JvdXAgPGx0cnVAaWV0 Zi5vcmc+LCBNYXJrIERhdmlzIDxtYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4sIDwKPiB6YWlp dG92QGdtYWlsLmNvbT4KPiAgU3ViamVjdAo+IFJFOiBbTHRydV0gQWxlbWFuaWMgJiBTd2lzcyBH ZXJtYW4KPgo+Cj4KPgo+Cj4KPiBJJ2xsIGhhdmUgdG8gY2hlY2sgZW1haWwgdG8gYmUgc3VyZSwg YnV0IG15IHJlY29sbGVjdGlvbiB3YXMgdGhhdCBJIGhhZAo+IHN1Z2dlc3RlZCB0byB5b3UgdGhh dCB0aGUgY2F0ZWdvcnkgdGhhdCB3YXMgYWxyZWFkeSBpbiB0aGUgZHJhZnQgdGFibGUgZm9yCj4g NjM5LTMgbWlnaHQgbWVldCB5b3VyIG5lZWQsIGFuZCB0aGF0IGNhdGVnb3J5IHdhcyB0aGUgb25l IGNvZGVkICJnc3ciIHdpdGgKPiBzZW1hbnRpY3MgZGVmaW5lZCBpbiBFdGhub2xvZ3VlLiBEZWZp bml0ZWx5IHRoZSBKQUMgd2FzIGluY29ycG9yYXRpbmcgaW50bwo+IHBhcnQgMiB0aGUgaXRlbSBp biB0aGUgZHJhZnQgY29kZSB0YWJsZSBmb3IgcGFydCAzOyBJIGJlbGlldmUgdGhhdCBhbGwgYWxv bmcKPiB0aGUgSkFDIHVuZGVyc3Rvb2QgdGhhdCB0byBoYXZlIHRoZSBzZW1hbnRpY3Mgb2YgIlN3 aXNzIEdlcm1hbiIgKG9yCj4gIlNjaHd5emVyZMO8dHNjaCIpIOKAkyBjZXJ0YWlubHkgSSBkaWQs IGJ1dCBhZ2FpbiBJJ2QgbmVlZCB0byByZXZpZXcKPiBkaXNjdXNzaW9ucyB0byBiZSBtb3JlIGNl cnRhaW4uCj4KPgo+Cj4KPgo+IFBldGVyCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4KPiAqRnJvbToqIEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20gW21haWx0bzpLYXJl bl9Ccm9vbWVAc3BlLnNvbnkuY29tXSAqCj4gU2VudDoqIFRodXJzZGF5LCBOb3ZlbWJlciAzMCwg MjAwNiA0OjUxIFBNKgo+IFRvOiogUGV0ZXIgQ29uc3RhYmxlKgo+IENjOiogSMOldmFyZCBIanVs c3RhZDsgaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc7Cj4gaWV0Zi1sYW5ndWFnZXMtYm91bmNlc0Bh bHZlc3RyYW5kLm5vOyBpc282MzlAZGt1dWcuZGs7IGlzbzYzOS0yQGxvYy5nb3Y7Cj4gSVNPIDYz OSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWU7IExUUlUgV29ya2luZyBHcm91cDsgTWFyayBEYXZp czsKPiB6YWlpdG92QGdtYWlsLmNvbSoKPiBTdWJqZWN0OiogUkU6IFtMdHJ1XSBBbGVtYW5pYyAm IFN3aXNzIEdlcm1hbgo+Cj4KPgo+Cj4gUGV0ZXIsCj4KPiBJJ20gbm90IHF1aXRlIHN1cmUgeW91 ciB0YWtlIG9uIHRoaXMgcmVwcmVzZW50cyB3aGF0IHdhcyBvbiBteSBJU08KPiBhcHBsaWNhdGlv bi4gVGhlIGFwcGxpY2F0aW9uIGRyYXdzIGF0dGVudGlvbiB0byBvdGhlciByZWdpb25zIHdoZXJl IEFsZW1hbmljCj4gZGlhbGVjdHMgY2FuIGJlIGZvdW5kIChzZWU6ICJhZGRpbmZvIiBzZWN0aW9u KS4gSSBiZWxpZXZlIHRoZSBGcmVuY2ggbmFtZQo+IHR5cGljYWxseSBpbmRpY2F0ZXMgYSBicm9h ZGVyIHJhbmdlIG9mIGRpYWxlY3RzIGFzIHdlbGw6Cj4KPiA+ID4gVGhpcyBkYXRhIHdhcyBzdWJt aXR0ZWQgb246IFdlZG5lc2RheSwgSnVuZSAxNSwgMjAwNSBhdCAxOTowODowMAo+ID4gPgo+ID4g PiBsYW5nX2luX2VuZyA9IFN3aXNzIEdlcm1hbiwgQWxlbWFuaWMKPiA+ID4gbGFuZ19pbl9mcmUg PSBhbMOpbWFuaXF1ZQo+ID4gPiByZWZfd2hlcmVfZm91bmRfMSA9IGh0dHA6Ly93d3cuZXRobm9s b2d1ZS5jb20KPiA+ID4gbGFuZ19pbl92ZXJuID0gU2Nod3l6ZXJkw7x0c2NoLCBTY2h3ZWl6ZXJk ZXV0c2NoLCBTY2h3aWl6ZXJkw7x0c2NoLAo+ID4gU2Nod3l6ZXJ0w7x0c2NoLCBTY2h3aXplcnRp dHNjaAo+ID4gPiByZWZfd2hlcmVfZm91bmRfMiA9IElTTyA2MzktMyBESVMsIGh0dHA6Ly93d3cu ZXRobm9sb2d1ZS5jb20sCj4gaHR0cDovL3d3dy53aWtpcGVkaWEuY29tCj4gPiA+IHRyYW5zX2xp dCA9Cj4gPiA+IGV2aWRlbmNlID0gQUdJQ09BLCB0aGUgQXNzb2NpYXRpb24gb2YgSW50ZXJuYXRp b25hbCBDb2xsZWN0aXZlCj4gPiBNYW5hZ2VtZW50IG9mIEF1ZGlvdmlzdWFsIFdvcmtzIChBc3Nv Y2lhdGlvbiBkZSBHZXN0aW9uIEludGVybmF0aW9uYWxlCj4gPiBDb2xsZWN0aXZlIGRlcyBPZXV2 cmVzIEF1ZGlvdmlzdWVsbGVzKTsgNDI4IGRvY3VtZW50cyAoYXVkaW92aXN1YWwpCj4gPiA+Cj4g PiA+IGh0dHA6Ly93d3cuYWdpY29hLm9yZwo+ID4gPiBhZGRpbmZvID0gNCwyMTUsMDAwIGluIFN3 aXR6ZXJsYW5kICgxOTkwIGNlbnN1cykuIFBvcHVsYXRpb24gdG90YWwgYWxsCj4KPiA+IGNvdW50 cmllczogNiwwNDQsMDAwLiBDZW50cmFsLCBzb3V0aCBjZW50cmFsLCBub3J0aCBjZW50cmFsLCBu b3J0aGVhc3QsCj4gPiBhbmQgZWFzdGVybiBjYW50b25zLiBBbHNvIHNwb2tlbiBpbiBBdXN0cmlh LCBGcmFuY2UsIEdlcm1hbnksCj4gPiBMaWVjaHRlbnN0ZWluLgo+Cj4gUmVnYXJkcywKPgo+IEth cmVuIEJyb29tZQo+IE1ldGFkYXRhIFN5c3RlbXMgRGVzaWduZXIKPiBTb255IFBpY3R1cmVzIEVu dGVydGFpbm1lbnQKPiAzMTAuMjQ0LjQzODQKPgo+ICAqUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNv bkBtaWNyb3NvZnQuY29tPioKPiBTZW50IGJ5OiBpZXRmLWxhbmd1YWdlcy1ib3VuY2VzQGFsdmVz dHJhbmQubm8KPgo+IDExLzMwLzIwMDYgMDI6NTkgUE0KPgo+ICAgVG8KPiBNYXJrIERhdmlzIDxt YXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4gIGNjCj4gTFRSVSBXb3JraW5nIEdyb3VwIDxsdHJ1 QGlldGYub3JnPiwgemFpaXRvdkBnbWFpbC5jb20sIGlzbzYzOS0yQGxvYy5nb3YsCj4gSMOldmFy ZCBIanVsc3RhZCA8SEhqQHN0YW5kYXJkLm5vPiwgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21t aXR0ZWUgPAo+IElTT0pBQ0Bsb2MuZ292PiwgaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmcsIGlzbzYz OUBka3V1Zy5kayAgU3ViamVjdAo+IFJFOiBbTHRydV0gQWxlbWFuaWMgJiBTd2lzcyBHZXJtYW4K Pgo+Cj4KPgo+Cj4KPgo+Cj4KPiBJIGNhbiB0ZWxsIHlvdSB0aGF0IHRoZSBpbnRlbnQgb2YgImdz dyIgaXMgc3BlY2lmaWNhbGx5IFN3aXNzIEdlcm1hbiwgYW5kCj4gdGhhdCB0aGUgYXNzdW1wdGlv biBvZiBoYXZpbmcgIkFsZW1hbmljIiBsaXN0ZWQgYXMgYSBuYW1lIGlzIHRoYXQgc29tZQo+IHBl b3BsZSB1c2UgdGhhdCBsYWJlbCB0byByZWZlciB0byBzcGVjaWZpY2FsbHkgdG8gU3dpc3MgR2Vy bWFuLiBJZiB0aGUKPiBsYXR0ZXIgYXNzdW1wdGlvbiBpcyBpbmNvcnJlY3QgKHdoaWNoIGFwcGVh cnMgdG8gYmUgd2hhdCBNYXJrIGlzIHNheWluZywKPiB0aGVuIHRoYXQgaXMgYSBjaGFuZ2UgdGhh dCB0aGUgSkFDIHNob3VsZCBjb25zaWRlci4KPgo+Cj4KPiBCdXQgaWYgTWFydGluJ3MgY29tbWVu dCBpcyB0aGUgc3VwcG9ydGluZyBldmlkZW5jZSwgdGhlbiBJIHN0aWxsIGZpbmQKPiBNYXJ0aW4n cyBjb21tZW50IHRvIGJlIHVuY2xlYXIuIEl0J3MgY2xlYXIgdG8gbWUgd2hhdCBNYXJrIGlzIHNh eWluZzsgaXQncwo+IG5vdCBjbGVhciB0byBtZSBpZiBNYXJ0aW4gaXMgc2F5aW5nIHRoZSBzYW1l IHRoaW5nLgo+Cj4KPgo+Cj4KPiBQZXRlciBDb25zdGFibGUKPgo+Cj4KPgo+Cj4KPgo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gKkZyb206KiBtYXJrLmVkd2FyZC5kYXZpc0Bn bWFpbC5jb20gW21haWx0bzptYXJrLmVkd2FyZC5kYXZpc0BnbWFpbC5jb21dICpPbgo+IEJlaGFs ZiBPZiAqTWFyayBEYXZpcyoKPiBTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDA2IDEx OjA3IEFNKgo+IFRvOiogUGV0ZXIgQ29uc3RhYmxlKgo+IENjOiogSMOldmFyZCBIanVsc3RhZDsg aXNvNjM5LTJAbG9jLmdvdjsgTFRSVSBXb3JraW5nIEdyb3VwOwo+IHphaWl0b3ZAZ21haWwuY29t OyBJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZTsKPiBpZXRmLWxhbmd1YWdlc0BpYW5h Lm9yZzsgaXNvNjM5QGRrdXVnLmRrKgo+IFN1YmplY3Q6KiBSZTogW0x0cnVdIEFsZW1hbmljICYg U3dpc3MgR2VybWFuCj4KPgo+Cj4gQWxlbWFuaWMgcmVmZXJzIHRvIGEgYnJvYWRlciBncm91cCBv ZiBkaWFsZWN0cyB0aGFuICJTd2lzcyBHZXJtYW4iIChha2EKPiBTY2h3eXplcnR1ZXNjaCkgZG9l cy4gU28gbGlzdGluZyB0aGVtIGFzIGl0IGRvZXMgaXMgcHJvYmxlbWF0aWM7IGl0J3MgbGlrZQo+ IGxpc3RpbmcKPgo+IGFyIEFyYWJpYzsgRWd5cHRpYW4gQXJhYmljCj4KPiBQZXJzb25hbGx5LCBJ IGRvbid0IGNhcmUgd2hldGhlciBpdCBpcyByZXNvbHZlZCB0byBiZQo+Cj4gQWxlbWFuaWMgKGlu Y2x1ZGluZyBTd2lzcyBHZXJtYW4pCj4gLy8gd2hpY2ggaXMgd2hhdCA2MzktMyBzZWVtcyB0byBi ZSBwb2ludGluZyB0bwo+Cj4gb3IKPgo+IFN3aXNzIEdlcm1hbiAoYSBwYXJ0aWN1bGFyIHZhcmlh bnQgb2YgQWxlbWFuaWMpCj4gLy8gd2hpY2ggaXMgd2hhdCB0aGUgY29kZSAoZ3N3KSBzZWVtcyB0 byBiZSBwb2ludGluZyB0bwo+Cj4gQnV0IHdlIG5lZWQgc29tZSBjbGFyaXR5IGFzIHRvIHdoYXQg aXMgbWVhbnQgYnkgdGhlIGNvZGUuCj4KPiBNYXJrCj4KPiBPbiAxMS8zMC8wNiwgKlBldGVyIENv bnN0YWJsZSogPCpwZXRlcmNvbkBtaWNyb3NvZnQuY29tKjxwZXRlcmNvbkBtaWNyb3NvZnQuY29t Pj4KPiB3cm90ZToKPgo+IE1hcnRpbidzIGNvbW1lbnQgaXMgc29tZXdoYXQgdmFndWU6IHZhcmll dGllcyBzcG9rZW4gb24gZWl0aGVyIHNpZGUgb2YgdGhlCj4gYm9yZGVyIGFyZSB2ZXJ5IHNpbWls YXIsIGV0ICJhcyBzb29uIGFzIHlvdSBjcm9zcyB0aGUgYm9yZGVyIGl0J3MgdmVyeQo+IGNsZWFy bHkgbm8gbG9uZ2VyIFN3aXNzIEdlcm1hbiIuIERvZXMgdGhhdCBtZWFuIHRoYXQgd2hhdCBpcyBz cG9rZW4gYWNyb3NzCj4gdGhlIGJvcmRlciBpcyBjbGVhcmx5IGEgZGlmZmVyZW50IGxhbmd1YWdl LCBvciB0aGF0IHRoZSBsYWJlbCAiU3dpc3MgR2VybWFuIgo+IGlzIGNsZWFybHkgbm90IHVzZWQ/ Cj4KPgo+Cj4KPgo+IFBldGVyCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4KPiAqRnJvbToqIE1hcmsgRGF2aXMgW21haWx0bzoqbWFyay5kYXZpc0BpY3UtcHJvamVjdC5v cmcqPG1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPl0KPiAqCj4gU2VudDoqIFRodXJzZGF5LCBO b3ZlbWJlciAzMCwgMjAwNiA5OjAwIEFNKgo+IFRvOiogSMOldmFyZCBIanVsc3RhZDsgKmlzbzYz OS0yQGxvYy5nb3YqIDxpc282MzktMkBsb2MuZ292PioKPiBDYzoqIExUUlUgV29ya2luZyBHcm91 cDsgKnphaWl0b3ZAZ21haWwuY29tKiA8emFpaXRvdkBnbWFpbC5jb20+OyBJU08gNjM5Cj4gSm9p bnQgQWR2aXNvcnkgQ29tbWl0dGVlOyAqaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmcqPGlldGYtbGFu Z3VhZ2VzQGlhbmEub3JnPjsKPiAqaXNvNjM5QGRrdXVnLmRrKiA8aXNvNjM5QGRrdXVnLmRrPioK PiBTdWJqZWN0OiogW0x0cnVdIEFsZW1hbmljICYgU3dpc3MgR2VybWFuCj4KPgo+Cj4gSVNPIDYz OS0yIChvbiAqaHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi9waHAvY29kZV9s aXN0LnBocCo8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi9waHAvY29kZV9s aXN0LnBocD4pCj4gbGlzdHMgdGhlIGZvbGxvd2luZzoKPgo+IGdzdyAgICAgICAgICAgICBBbGVt YW5pOyBTd2lzcyBHZXJtYW4gICAgICBhbMOpbWFuaXF1ZQo+Cj4gSG93ZXZlciwgdGhlcmUgaXMg YSAiYyIgbWlzc2luZyBmcm9tIEFsZW1hbmljLCBhbmQgU3dpc3MgR2VybWFuIGlzIG5vdCB0aGUK PiBzYW1lIGFzIEFsZW1hbmljOiBTd2lzcyBHZXJtYW4gaXMgYSB0eXBlIG9mIEFsZW1hbmljLCBi dXQgdGhlcmUgYXJlIG90aGVyCj4gdHlwZXMgdGhhdCBhcmUgbm90IHRoZSBzYW1lIGFzIFN3aXNz IEdlcm1hbi4KPgo+IFF1b3RpbmcgTWFydGluIER1ZXJzdDoKPgo+ICJZZXMsIFN3YWJpYW4gaXMg Y2xlYXJseSBBbGVtYW5pYy4gQWxlbWFuaWMgYW5kIFN3aXNzIEdlcm1hbiBhcmUgbm90Cj4gdGhl IHNhbWUuIFRoZXJlIGFyZSB2ZXJ5IGNsb3NlIHNpbWlsYXJpdGllcyBiZXR3ZWVuIHNvbWUgZGlh bGVjdHMgaW4KPiB0aGUgbm9ydGggb2YgU3dpdHplcmxhbmQgYW5kIGFjcm9zcyB0aGUgYm9yZGVy IGluIEdlcm1hbnksIGJ1dCBhcwo+IHNvb24gYXMgeW91IGNyb3NzIHRoZSBib3JkZXIsIGl0J3Mg dmVyeSBjbGVhcmx5IG5vIGxvbmdlciBTd2lzcwo+IEdlcm1hbi4gQSBsYWJlbCBzdWNoIGFzICJB bGVtYW5pYzsgU3dpc3MgR2VybWFuIiwgYXNzdW1pbmcgdGhhdAo+IGJvdGggYXJlIHRoZSBzYW1l LCBpcyBjbGVhcmx5IHdyb25nLiBJZiBpdCdzIHNvbWV0aGluZyBsaWtlCj4gIkFsZW1hbmljOyBp bmNsdWRlcyBTd2lzcyBHZXJtYW4iLCB0aGF0IHdvdWxkIGJlIG9rYXkuIgo+Cj4gQ2FuIHRoaXMg YmUgY29ycmVjdGVkIHNvIHRoYXQgaXQgZG9lcyBub3QgY29udGludWUgdG8gbWlzbGVhZCBwZW9w bGU/Cj4KPiBNYXJrIERhdmlzCj4KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiBJZXRmLWxhbmd1YWdlcyBtYWlsaW5nIGxpc3QKPiBJZXRmLWxhbmd1 YWdlc0BhbHZlc3RyYW5kLm5vCj4gaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlz dGluZm8vaWV0Zi1sYW5ndWFnZXMKPgo+Cg== ------=_Part_6539_29042332.1164940884653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgc291bmRzIG1vcmUgYW5kIG1vcmUgdG8gbWUgdGhhdCAmcXVvdDtBbGVtYW5pYyZxdW90OyB3 YXMgc2ltcGx5IGEgbWlzdGFrZTsgdGhlIGRlc2NyaXB0aW9uIHNob3VsZCBiZSAmcXVvdDtTd2lz cyBHZXJtYW4mcXVvdDsgYWxvbmUsIGJvdGggaW4gNjM5LTIgYW5kIDYzOS0zLjxicj48YnI+TWFy azxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDExLzMwLzA2LCAKPGIg Y2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjxhIGhyZWY9Im1haWx0bzpLYXJlbl9Ccm9vbWVAc3Bl LnNvbnkuY29tIj5LYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tPC9hPjwvYj4gJmx0OzxhIGhyZWY9 Im1haWx0bzpLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tIj5LYXJlbl9Ccm9vbWVAc3BlLnNvbnku Y29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKPGJyPjxmb250IGZhY2U9 InNhbnMtc2VyaWYiIHNpemU9IjIiPkFyZSB3ZSByZWFkaW5nIHRoZSBzYW1lIEV0aG5vbG9ndWUg cGFnZT8KRXRobm9sb2d1ZSBzZWVtcyB0byBpbmNsdWRlIHRoZSBBdXN0cmlhbiBmb3JtcyBhbmQg bWVudGlvbnMgdGhhdCBjZXJ0YWluCmRpYWxlY3RzIHdpdGhpbiB0aGlzIGxhbmd1YWdlIGZhbWls eSBtYXkgbm90IGJlIGludGVsbGlnaWJsZSB0byBzcGVha2VycwpvZiBvdGhlciBkaWFsZWN0cy48 L2ZvbnQ+Cjxicj4KPGJyPjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjIiPkknbSBub3Qg dHJ5aW5nIHRvIGJlIGRpZmZpY3VsdCAmbmJzcDstLQp0b2RheSA6KSAtLSBhbmQgY2VydGFpbmx5 IGFwcHJlY2lhdGUgeW91ciBwcmV2aW91cyBoZWxwIGluIHNvcnRpbmcgb3V0CnRoZXNlIGlzc3Vl cywgYnV0IEkgaGF2ZSBjaXJjdWxhdGVkIHRoZSBjb2RlcyBnc3ctQ0ggYW5kIGdzdy1BVCB0byBh IGZhaXJseQp3aWRlIGF1ZGllbmNlIGJhc2VkIG9uIGFzc3VtcHRpb25zIHRoYXQgc2VlbSB0byBi ZSBmYWlybHkgd2VsbC1kb2N1bWVudGVkCm9uIEV0aG5vbG9ndWUsIG15IGFwcGxpY2F0aW9uLCBJ U08ncyBhcHByb3ZhbCwgYW5kIHZhcmlvdXMgb3RoZXIgcmVzb3VyY2VzCnRoYXQgbHVtcCB0aGVz ZSByZWdpb25hbCBkaWFsZWN0cyB0b2dldGhlci4gRG9lcyA2MzktMyBzaG91bGQgaGF2ZSBhIG1h Y3JvbGFuZ3VhZ2UKZm9yIHRoaXM/IElmIG5vdCwgc2hvdWxkIGl0PyA8L2ZvbnQ+Cjxicj4KPGJy Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjIiPkknZCBhcHByZWNpYXRlIGl0IGlmIHlv dSBjb3VsZCByZXZpZXcKeW91ciBub3RlcyBiZWZvcmUgYWN0aW5nIG9uIHRoaXMgc3VnZ2VzdGVk IGNoYW5nZS4gPC9mb250Pgo8YnI+Cjxicj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIy Ij5CZXN0IHJlZ2FyZHMsPC9mb250Pgo8YnI+Cjxicj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBz aXplPSIyIj5LYXJlbiA8L2ZvbnQ+Cjxicj4KPGJyPgo8YnI+Cjxicj4KPHRhYmxlIHdpZHRoPSIx MDAlIj4KPHRib2R5Pjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3aWR0aD0iNDAlIj48c3BhbiBjbGFz cz0icSI+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMSI+PGI+UGV0ZXIgQ29uc3RhYmxl ICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5wZXRlcmNvbkBtaWNyb3NvZnQuY29tCjwvYT4mZ3Q7PC9iPgo8L2ZvbnQ+Cjwvc3Bhbj48cD48 Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj4xMS8zMC8yMDA2IDA1OjM0IFBNPC9mb250 Pgo8L3A+PC90ZD48dGQgd2lkdGg9IjU5JSI+Cjx0YWJsZSB3aWR0aD0iMTAwJSI+Cjx0Ym9keT48 dHIgdmFsaWduPSJ0b3AiPgo8dGQ+CjxkaXYgYWxpZ249InJpZ2h0Ij48Zm9udCBmYWNlPSJzYW5z LXNlcmlmIiBzaXplPSIxIj5UbzwvZm9udD48L2Rpdj4KPC90ZD48dGQ+PHNwYW4gY2xhc3M9InEi Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPiZsdDs8YSBocmVmPSJtYWlsdG86S2Fy ZW5fQnJvb21lQHNwZS5zb255LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5LYXJlbl9Ccm9vbWVAc3BlLnNv bnkuY29tPC9hPiZndDs8L2ZvbnQ+Cjwvc3Bhbj48L3RkPjwvdHI+PHRyIHZhbGlnbj0idG9wIj4K PHRkPgo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMSI+ Y2M8L2ZvbnQ+PC9kaXY+CjwvdGQ+PHRkPjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEi PkjDpXZhcmQgSGp1bHN0YWQgJmx0OzxhIGhyZWY9Im1haWx0bzpISGpAc3RhbmRhcmQubm8iIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+SEhqQHN0YW5kYXJkLm5vPC9hPiZndDssCiZsdDs8YSBocmVmPSJtYWlsdG86 aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4g dG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWV0Zi1sYW5ndWFnZXNAaWFu YS5vcmc8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlcy1ib3VuY2Vz QGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CmlldGYtbGFuZ3VhZ2VzLWJvdW5jZXNAYWx2 ZXN0cmFuZC5ubzwvYT4mZ3Q7LAombHQ7PGEgaHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1Zy5kayIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj5pc282MzlAZGt1dWcuZGs8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0 bzppc282MzktMkBsb2MuZ292IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5q cy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgppc282MzktMkBsb2MuZ292PC9hPiZn dDssIElTTyA2MzkgSm9pbnQgQWR2aXNvcnkKQ29tbWl0dGVlICZsdDs8YSBocmVmPSJtYWlsdG86 SVNPSkFDQGxvYy5nb3YiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+SVNPSkFDQGxvYy5nb3Y8L2E+Jmd0OywgTFRS VSBXb3JraW5nIEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bHRydUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50 LHRoaXMpIj4KbHRydUBpZXRmLm9yZzwvYT4mZ3Q7LApNYXJrIERhdmlzICZsdDs8YSBocmVmPSJt YWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5kYXZp c0BpY3UtcHJvamVjdC5vcmc8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzp6YWlpdG92QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIj4KemFpaXRvdkBnbWFpbC5jb208L2E+Jmd0OzwvZm9udD4K PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9InFfMTBmM2JiYTNiNjE4MmMyOF81Ij48L3NwYW4+PC9k aXY+PC90ZD48L3RyPjx0ciB2YWxpZ249InRvcCI+Cjx0ZD4KPGRpdiBhbGlnbj0icmlnaHQiPjxm b250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+CjwvdGQ+ PHRkPjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPlJFOiBbTHRydV0gQWxlbWFuaWMg JmFtcDsgU3dpc3MgR2VybWFuPC9mb250PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+Cjxicj4K PHRhYmxlPgo8dGJvZHk+PHRyIHZhbGlnbj0idG9wIj4KPHRkPgo8YnI+PC90ZD48dGQ+PGJyPjwv dGQ+PC90cj48L3Rib2R5PjwvdGFibGU+Cjxicj48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjxk aXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwZjNiYmEzYjYxODJjMjhfNyI+Cjxicj4KPGJyPgo8 YnI+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPkknbGwgaGF2ZSB0 byBjaGVjayBlbWFpbCB0bwpiZSBzdXJlLCBidXQgbXkgcmVjb2xsZWN0aW9uIHdhcyB0aGF0IEkg aGFkIHN1Z2dlc3RlZCB0byB5b3UgdGhhdCB0aGUgY2F0ZWdvcnkKdGhhdCB3YXMgYWxyZWFkeSBp biB0aGUgZHJhZnQgdGFibGUgZm9yIDYzOS0zIG1pZ2h0IG1lZXQgeW91ciBuZWVkLCBhbmQKdGhh dCBjYXRlZ29yeSB3YXMgdGhlIG9uZSBjb2RlZCAiZ3N3IiB3aXRoIHNlbWFudGljcyBkZWZpbmVk IGluIEV0aG5vbG9ndWUuCkRlZmluaXRlbHkgdGhlIEpBQyB3YXMgaW5jb3Jwb3JhdGluZyBpbnRv IHBhcnQgMiB0aGUgaXRlbSBpbiB0aGUgZHJhZnQKY29kZSB0YWJsZSBmb3IgcGFydCAzOyBJIGJl bGlldmUgdGhhdCBhbGwgYWxvbmcgdGhlIEpBQyB1bmRlcnN0b29kIHRoYXQKdG8gaGF2ZSB0aGUg c2VtYW50aWNzIG9mICJTd2lzcyBHZXJtYW4iIChvciAiU2Nod3l6ZXJkw7x0c2NoIikg4oCTIGNl cnRhaW5seQpJIGRpZCwgYnV0IGFnYWluIEknZCBuZWVkIHRvIHJldmlldyBkaXNjdXNzaW9ucyB0 byBiZSBtb3JlIGNlcnRhaW4uPC9mb250Pgo8cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVy ZGFuYSIgc2l6ZT0iMiI+Jm5ic3A7PC9mb250Pgo8L3A+PHA+PGZvbnQgY29sb3I9ImJsdWUiIGZh Y2U9IlZlcmRhbmEiIHNpemU9IjIiPiZuYnNwOzwvZm9udD4KPC9wPjxwPjxmb250IGNvbG9yPSJi bHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj5QZXRlcjwvZm9udD4KPC9wPjxwPjxmb250IGNv bG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+CjwvcD48ZGl2 IGFsaWduPSJjZW50ZXIiPgo8cD4KPC9wPjxocj48cD48L3A+PC9kaXY+CjxwPjxmb250IGZhY2U9 IlRhaG9tYSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IDxhIGhyZWY9Im1haWx0bzpLYXJlbl9Ccm9v bWVAc3BlLnNvbnkuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5P cGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb208 L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20iIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+CkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb208L2E+XQo8Yj48YnI+ClNlbnQ6 PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIwMDYgNDo1MSBQTTxiPjxicj4KVG86PC9iPiBQ ZXRlciBDb25zdGFibGU8Yj48YnI+CkNjOjwvYj4gSMOldmFyZCBIanVsc3RhZDsgPGEgaHJlZj0i bWFpbHRvOmlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlldGYtbGFuZ3Vh Z2VzQGlhbmEub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGYtbGFuZ3VhZ2VzLWJvdW5jZXNA YWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj4KaWV0Zi1sYW5ndWFnZXMtYm91bmNlc0BhbHZl c3RyYW5kLm5vPC9hPjsKPGEgaHJlZj0ibWFpbHRvOmlzbzYzOUBka3V1Zy5kayIgdGFyZ2V0PSJf YmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRo aXMpIj5pc282MzlAZGt1dWcuZGs8L2E+OyA8YSBocmVmPSJtYWlsdG86aXNvNjM5LTJAbG9jLmdv diIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj4KaXNvNjM5LTJAbG9jLmdvdjwvYT47IElTTyA2MzkgSm9pbnQgQWR2 aXNvcnkgQ29tbWl0dGVlOyBMVFJVCldvcmtpbmcgR3JvdXA7IE1hcmsgRGF2aXM7IDxhIGhyZWY9 Im1haWx0bzp6YWlpdG92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj56YWlpdG92QGdtYWlsLmNv bTwvYT48Yj48YnI+ClN1YmplY3Q6PC9iPiBSRTogW0x0cnVdIEFsZW1hbmljICZhbXA7IFN3aXNz IEdlcm1hbjwvZm9udD4KPC9wPjxwPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MyI+Jm5ic3A7PC9mb250Pgo8L3A+PHA+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMiI+ PGJyPgpQZXRlciw8L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4g PGJyPgo8L2ZvbnQ+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGJyPgpJJ20gbm90 IHF1aXRlIHN1cmUgeW91ciB0YWtlIG9uIHRoaXMgcmVwcmVzZW50cyB3aGF0IHdhcyBvbiBteSBJ U08gYXBwbGljYXRpb24uClRoZSBhcHBsaWNhdGlvbiBkcmF3cyBhdHRlbnRpb24gdG8gb3RoZXIg cmVnaW9ucyB3aGVyZSBBbGVtYW5pYyBkaWFsZWN0cwpjYW4gYmUgZm91bmQgKHNlZTogJnF1b3Q7 YWRkaW5mbyZxdW90OyBzZWN0aW9uKS4gSSBiZWxpZXZlIHRoZSBGcmVuY2ggbmFtZQp0eXBpY2Fs bHkgaW5kaWNhdGVzIGEgYnJvYWRlciByYW5nZSBvZiBkaWFsZWN0cyBhcyB3ZWxsOjwvZm9udD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8YnI+CjwvZm9udD48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PGJyPgomZ3Q7ICZndDsgVGhpcyBkYXRhIHdhcyBz dWJtaXR0ZWQgb246IFdlZG5lc2RheSwgSnVuZSAxNSwgMjAwNSBhdCAxOTowODowMDxicj4KJmd0 OyAmZ3Q7IDxicj4KJmd0OyAmZ3Q7IGxhbmdfaW5fZW5nID0gU3dpc3MgR2VybWFuLCBBbGVtYW5p Yzxicj4KJmd0OyAmZ3Q7IGxhbmdfaW5fZnJlID0gYWzDqW1hbmlxdWU8YnI+CiZndDsgJmd0OyBy ZWZfd2hlcmVfZm91bmRfMSA9IDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20iIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+aHR0cDovL3d3dy5ldGhub2xvZ3VlLmNvbTwvYT48YnI+CiZndDsgJmd0OyBs YW5nX2luX3Zlcm4gPSBTY2h3eXplcmTDvHRzY2gsIFNjaHdlaXplcmRldXRzY2gsIFNjaHdpaXpl cmTDvHRzY2gsCjxicj4KJmd0OyBTY2h3eXplcnTDvHRzY2gsIFNjaHdpemVydGl0c2NoPGJyPgom Z3Q7ICZndDsgcmVmX3doZXJlX2ZvdW5kXzIgPSBJU08gNjM5LTMgRElTLCA8YSBocmVmPSJodHRw Oi8vd3d3LmV0aG5vbG9ndWUuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmh0dHA6Ly93d3cuZXRobm9sb2d1 ZS5jb208L2E+LAo8YSBocmVmPSJodHRwOi8vd3d3Lndpa2lwZWRpYS5jb20iIHRhcmdldD0iX2Js YW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSI+aHR0cDovL3d3dy53aWtpcGVkaWEuY29tPC9hPjxicj4KJmd0OyAmZ3Q7IHRyYW5zX2xpdCA9 IDxicj4KJmd0OyAmZ3Q7IGV2aWRlbmNlID0gQUdJQ09BLCB0aGUgQXNzb2NpYXRpb24gb2YgSW50 ZXJuYXRpb25hbCBDb2xsZWN0aXZlCjxicj4KJmd0OyBNYW5hZ2VtZW50IG9mIEF1ZGlvdmlzdWFs IFdvcmtzIChBc3NvY2lhdGlvbiBkZSBHZXN0aW9uIEludGVybmF0aW9uYWxlCjxicj4KJmd0OyBD b2xsZWN0aXZlIGRlcyBPZXV2cmVzIEF1ZGlvdmlzdWVsbGVzKTsgNDI4IGRvY3VtZW50cyAoYXVk aW92aXN1YWwpPGJyPgomZ3Q7ICZndDsgPGJyPgomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3 dy5hZ2ljb2Eub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmh0dHA6Ly93d3cuYWdpY29hLm9yZzwvYT48YnI+ CiZndDsgJmd0OyBhZGRpbmZvID0gNCwyMTUsMDAwIGluIFN3aXR6ZXJsYW5kICgxOTkwIGNlbnN1 cykuIFBvcHVsYXRpb24KdG90YWwgYWxsIDxicj4KJmd0OyBjb3VudHJpZXM6IDYsMDQ0LDAwMC4g Q2VudHJhbCwgc291dGggY2VudHJhbCwgbm9ydGggY2VudHJhbCwgbm9ydGhlYXN0LAo8YnI+CiZn dDsgYW5kIGVhc3Rlcm4gY2FudG9ucy4gQWxzbyBzcG9rZW4gaW4gQXVzdHJpYSwgRnJhbmNlLCBH ZXJtYW55LCA8YnI+CiZndDsgTGllY2h0ZW5zdGVpbi48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPSIzIj48YnI+CjwvZm9udD48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBz aXplPSIyIj48YnI+ClJlZ2FyZHMsPC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0iMyI+IDxicj4KPC9mb250Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjIiPjxi cj4KS2FyZW4gQnJvb21lPGJyPgpNZXRhZGF0YSBTeXN0ZW1zIERlc2lnbmVyPGJyPgpTb255IFBp Y3R1cmVzIEVudGVydGFpbm1lbnQ8YnI+CjMxMC4yNDQuNDM4NDwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPiA8YnI+CjwvZm9udD4KPC9wPjxwPgo8dGFibGUgd2lk dGg9IjEwMCUiPgo8dGJvZHk+PHRyIHZhbGlnbj0idG9wIj4KPHRkIHdpZHRoPSIxOSUiPjxmb250 IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPjxiPlBldGVyIENvbnN0YWJsZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+cGV0ZXJjb25A bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PC9iPgo8YnI+ClNlbnQgYnk6IDxhIGhyZWY9Im1haWx0bzpp ZXRmLWxhbmd1YWdlcy1ib3VuY2VzQGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWV0Zi1s YW5ndWFnZXMtYm91bmNlc0BhbHZlc3RyYW5kLm5vPC9hPjwvZm9udD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2ZvbnQ+CjxwPjxmb250IGZhY2U9InNhbnMtc2VyaWYi IHNpemU9IjEiPjExLzMwLzIwMDYgMDI6NTkgUE08L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj4KPC9mb250Pgo8L3A+PC90ZD48dGQgd2lkdGg9IjgwJSI+Cjxicj4K PHRhYmxlIHdpZHRoPSIxMDAlIj4KPHRib2R5Pjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3aWR0aD0i NCUiPgo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMSI+ VG88L2ZvbnQ+PC9kaXY+CjwvdGQ+PHRkIHdpZHRoPSI5NSUiPjxmb250IGZhY2U9InNhbnMtc2Vy aWYiIHNpemU9IjEiPk1hcmsgRGF2aXMgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGlj dS1wcm9qZWN0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5tYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZzwv YT4mZ3Q7PC9mb250Pgo8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2Zv bnQ+CjwvdGQ+PC90cj48dHIgdmFsaWduPSJ0b3AiPgo8dGQ+CjxkaXYgYWxpZ249InJpZ2h0Ij48 Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj5jYzwvZm9udD48L2Rpdj4KPC90ZD48dGQ+ PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMSI+TFRSVSBXb3JraW5nIEdyb3VwICZsdDs8 YSBocmVmPSJtYWlsdG86bHRydUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5sdHJ1QGlldGYub3Jn PC9hPiZndDssCjxhIGhyZWY9Im1haWx0bzp6YWlpdG92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij56YWlpdG92QGdtYWlsLmNvbTwvYT4sIDxhIGhyZWY9Im1haWx0bzppc282MzktMkBsb2MuZ292 IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiPgppc282MzktMkBsb2MuZ292PC9hPiwgSMOldmFyZCBIanVsc3RhZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOkhIakBzdGFuZGFyZC5ubyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5ISGpAc3Rh bmRhcmQubm88L2E+Jmd0OywKSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUgJmx0Ozxh IGhyZWY9Im1haWx0bzpJU09KQUNAbG9jLmdvdiIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5JU09KQUNAbG9jLmdv djwvYT4mZ3Q7LCA8YSBocmVmPSJtYWlsdG86aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmciIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+CmlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPC9hPiwKPGEgaHJlZj0ibWFpbHRvOmlz bzYzOUBka3V1Zy5kayIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5pc282MzlAZGt1dWcuZGs8L2E+PC9mb250Pjxm b250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+IDwvZm9udD4KPC90ZD48L3RyPjx0 ciB2YWxpZ249InRvcCI+Cjx0ZD4KPGRpdiBhbGlnbj0icmlnaHQiPjxmb250IGZhY2U9InNhbnMt c2VyaWYiIHNpemU9IjEiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+CjwvdGQ+PHRkPjxmb250IGZhY2U9 InNhbnMtc2VyaWYiIHNpemU9IjEiPlJFOiBbTHRydV0gQWxlbWFuaWMgJmFtcDsgU3dpc3MgR2Vy bWFuPC9mb250PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+CjxwPjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0iMyI+Jm5ic3A7PC9mb250Pgo8L3A+PHA+Cjxicj4KPHRhYmxlIHdp ZHRoPSIxMDAlIj4KPHRib2R5Pjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3aWR0aD0iNTAlIj48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPiZuYnNwOzwvZm9udD4KPC90ZD48dGQg d2lkdGg9IjUwJSI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4mbmJzcDs8 L2ZvbnQ+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT4KPGJyPjwvcD48L3RkPjwvdHI+PC90Ym9k eT48L3RhYmxlPgo8L3A+PHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48 YnI+Cjxicj4KPC9mb250Pjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIy Ij48YnI+CkkgY2FuIHRlbGwgeW91IHRoYXQgdGhlIGludGVudCBvZiAiZ3N3IiBpcyBzcGVjaWZp Y2FsbHkgU3dpc3MgR2VybWFuLAphbmQgdGhhdCB0aGUgYXNzdW1wdGlvbiBvZiBoYXZpbmcgIkFs ZW1hbmljIiBsaXN0ZWQgYXMgYSBuYW1lIGlzIHRoYXQKc29tZSBwZW9wbGUgdXNlIHRoYXQgbGFi ZWwgdG8gcmVmZXIgdG8gc3BlY2lmaWNhbGx5IHRvIFN3aXNzIEdlcm1hbi4gSWYKdGhlIGxhdHRl ciBhc3N1bXB0aW9uIGlzIGluY29ycmVjdCAod2hpY2ggYXBwZWFycyB0byBiZSB3aGF0IE1hcmsg aXMgc2F5aW5nLAp0aGVuIHRoYXQgaXMgYSBjaGFuZ2UgdGhhdCB0aGUgSkFDIHNob3VsZCBjb25z aWRlci48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4KPC9mb250 Pgo8L3A+PHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPiZuYnNw OzwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2ZvbnQ+Cjwv cD48cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+QnV0IGlmIE1h cnRpbidzIGNvbW1lbnQgaXMgdGhlCnN1cHBvcnRpbmcgZXZpZGVuY2UsIHRoZW4gSSBzdGlsbCBm aW5kIE1hcnRpbidzIGNvbW1lbnQgdG8gYmUgdW5jbGVhci4KSXQncyBjbGVhciB0byBtZSB3aGF0 IE1hcmsgaXMgc2F5aW5nOyBpdCdzIG5vdCBjbGVhciB0byBtZSBpZiBNYXJ0aW4KaXMgc2F5aW5n IHRoZSBzYW1lIHRoaW5nLjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 IjMiPiA8L2ZvbnQ+CjwvcD48cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6 ZT0iMiI+Jm5ic3A7PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+ CjwvZm9udD4KPC9wPjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIy Ij4mbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4KPC9m b250Pgo8L3A+PHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPlBl dGVyIENvbnN0YWJsZTwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMi Pgo8L2ZvbnQ+CjwvcD48cD48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0i MiI+Jm5ic3A7PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+Cjwv Zm9udD4KPC9wPjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj4m bmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4KPC9mb250 Pgo8L3A+PHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPiZuYnNw OzwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2ZvbnQ+Cjwv cD48ZGl2IGFsaWduPSJjZW50ZXIiPgo8cD4KPC9wPjxocj48cD48L3A+PC9kaXY+CjxwPjxmb250 IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IDxhIGhyZWY9Im1haWx0bzptYXJr LmVkd2FyZC5kYXZpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4g dG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5lZHdhcmQuZGF2aXNA Z21haWwuY29tPC9hPgpbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJrLmVkd2FyZC5kYXZpc0Bn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRM aW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tPC9hPl0g PGI+T24gQmVoYWxmIE9mIDwvYj5NYXJrIERhdmlzPGI+PGJyPgpTZW50OjwvYj4gVGh1cnNkYXks IE5vdmVtYmVyIDMwLCAyMDA2IDExOjA3IEFNPGI+PGJyPgpUbzo8L2I+IFBldGVyIENvbnN0YWJs ZTxiPjxicj4KQ2M6PC9iPiBIw6V2YXJkIEhqdWxzdGFkOyA8YSBocmVmPSJtYWlsdG86aXNvNjM5 LTJAbG9jLmdvdiIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5pc282MzktMkBsb2MuZ292PC9hPjsgTFRSVSBXb3Jr aW5nIEdyb3VwOyA8YSBocmVmPSJtYWlsdG86emFpaXRvdkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSI+CnphaWl0b3ZAZ21haWwuY29tPC9hPjsKSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0 ZWU7IDxhIGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlc0BpYW5hLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5pZXRmLWxhbmd1YWdlc0BpYW5hLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppc282MzlAZGt1 dWcuZGsiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5r KHdpbmRvdyxldmVudCx0aGlzKSI+CmlzbzYzOUBka3V1Zy5kazwvYT48Yj48YnI+ClN1YmplY3Q6 PC9iPiBSZTogW0x0cnVdIEFsZW1hbmljICZhbXA7IFN3aXNzIEdlcm1hbjwvZm9udD48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2ZvbnQ+CjwvcD48cD48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPiZuYnNwOyA8L2ZvbnQ+CjwvcD48cD48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPkFsZW1hbmljIHJlZmVycyB0byBhIGJyb2Fk ZXIgZ3JvdXAKb2YgZGlhbGVjdHMgdGhhbiAmcXVvdDtTd2lzcyBHZXJtYW4mcXVvdDsgKGFrYSBT Y2h3eXplcnR1ZXNjaCkgZG9lcy4gU28KbGlzdGluZyB0aGVtIGFzIGl0IGRvZXMgaXMgcHJvYmxl bWF0aWM7IGl0J3MgbGlrZSBsaXN0aW5nPGJyPgo8YnI+CmFyIEFyYWJpYzsgRWd5cHRpYW4gQXJh YmljPGJyPgo8YnI+ClBlcnNvbmFsbHksIEkgZG9uJ3QgY2FyZSB3aGV0aGVyIGl0IGlzIHJlc29s dmVkIHRvIGJlIDxicj4KPGJyPgpBbGVtYW5pYyAoaW5jbHVkaW5nIFN3aXNzIEdlcm1hbikgPGJy PgovLyB3aGljaCBpcyB3aGF0IDYzOS0zIHNlZW1zIHRvIGJlIHBvaW50aW5nIHRvPGJyPgo8YnI+ Cm9yPGJyPgo8YnI+ClN3aXNzIEdlcm1hbiAoYSBwYXJ0aWN1bGFyIHZhcmlhbnQgb2YgQWxlbWFu aWMpPGJyPgovLyB3aGljaCBpcyB3aGF0IHRoZSBjb2RlIChnc3cpIHNlZW1zIHRvIGJlIHBvaW50 aW5nIHRvPGJyPgo8YnI+CkJ1dCB3ZSBuZWVkIHNvbWUgY2xhcml0eSBhcyB0byB3aGF0IGlzIG1l YW50IGJ5IHRoZSBjb2RlLiA8YnI+Cjxicj4KTWFyayA8L2ZvbnQ+CjwvcD48cD48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPk9uIDExLzMwLzA2LCA8Yj5QZXRlciBDb25zdGFi bGU8L2I+CiZsdDs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSI+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0iMyI+PHU+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+CiZndDsKd3JvdGU6IDwvZm9udD4KPC9wPjxw Pjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj5NYXJ0aW4ncyBjb21t ZW50IGlzIHNvbWV3aGF0CnZhZ3VlOiB2YXJpZXRpZXMgc3Bva2VuIG9uIGVpdGhlciBzaWRlIG9m IHRoZSBib3JkZXIgYXJlIHZlcnkgc2ltaWxhciwKZXQgJnF1b3Q7YXMgc29vbiBhcyB5b3UgY3Jv c3MgdGhlIGJvcmRlciBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3MKR2VybWFuJnF1 b3Q7LiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdoYXQgaXMgc3Bva2VuIGFjcm9zcyB0aGUgYm9yZGVy IGlzIGNsZWFybHkKYSBkaWZmZXJlbnQgbGFuZ3VhZ2UsIG9yIHRoYXQgdGhlIGxhYmVsICZxdW90 O1N3aXNzIEdlcm1hbiZxdW90OyBpcyBjbGVhcmx5Cm5vdCB1c2VkPzwvZm9udD48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPiA8L2ZvbnQ+CjwvcD48cD48Zm9udCBjb2xvcj0i Ymx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+Jm5ic3A7PC9mb250Pjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+CjwvZm9udD4KPC9wPjxwPjxmb250IGNvbG9yPSJibHVl IiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPSIzIj4KPC9mb250Pgo8L3A+PHA+PGZvbnQgY29sb3I9ImJsdWUiIGZh Y2U9IlZlcmRhbmEiIHNpemU9IjIiPlBldGVyPC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+CjwvZm9udD4KPC9wPjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJW ZXJkYW5hIiBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPSIzIj4KPC9mb250Pgo8L3A+PGRpdiBhbGlnbj0iY2VudGVyIj4KPHA+CjwvcD48aHI+ PHA+PC9wPjwvZGl2Pgo8cD48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZyb206PC9i PiBNYXJrIERhdmlzIFttYWlsdG86PC9mb250PjxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGlj dS1wcm9qZWN0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVGFo b21hIiBzaXplPSIyIj4KPHU+bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPl0KPGI+PGJyPgpTZW50OjwvYj4gVGh1cnNk YXksIE5vdmVtYmVyIDMwLCAyMDA2IDk6MDAgQU08Yj48YnI+ClRvOjwvYj4gSMOldmFyZCBIanVs c3RhZDsgPC9mb250PjxhIGhyZWY9Im1haWx0bzppc282MzktMkBsb2MuZ292IiB0YXJnZXQ9Il9i bGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjx1PmlzbzYzOS0y QGxvYy5nb3Y8L3U+PC9mb250PjwvYT48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPgo8Yj48 YnI+CkNjOjwvYj4gTFRSVSBXb3JraW5nIEdyb3VwOyA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnph aWl0b3ZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5P cGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJU YWhvbWEiIHNpemU9IjIiPjx1PnphaWl0b3ZAZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQg ZmFjZT0iVGFob21hIiBzaXplPSIyIj4KOwpJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRl ZTsgPC9mb250PjxhIGhyZWY9Im1haWx0bzppZXRmLWxhbmd1YWdlc0BpYW5hLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50 LHRoaXMpIj48Zm9udCBjb2xvcj0iYmx1ZSIgZmFjZT0iVGFob21hIiBzaXplPSIyIj48dT5pZXRm LWxhbmd1YWdlc0BpYW5hLm9yZwo8L3U+PC9mb250PjwvYT48Zm9udCBmYWNlPSJUYWhvbWEiIHNp emU9IjIiPjsKPC9mb250PjxhIGhyZWY9Im1haWx0bzppc282MzlAZGt1dWcuZGsiIHRhcmdldD0i X2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSI+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHU+aXNvNjM5 QGRrdXVnLmRrPC91PjwvZm9udD48L2E+PGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48Yj48 YnI+CgpTdWJqZWN0OjwvYj4gW0x0cnVdIEFsZW1hbmljICZhbXA7IFN3aXNzIEdlcm1hbjwvZm9u dD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPgo8L2ZvbnQ+CjwvcD48cD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPiZuYnNwOyA8L2ZvbnQ+CjwvcD48 cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIiPklTTyA2MzktMiAob24gPC9m b250PjxhIGhyZWY9Imh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvcGhwL2Nv ZGVfbGlzdC5waHAiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5F eHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0iMiI+Cjx1Pmh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNv NjM5LTIvcGhwL2NvZGVfbGlzdC5waHA8L3U+PC9mb250PjwvYT48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjIiPikKbGlzdHMgdGhlIGZvbGxvd2luZzo8YnI+Cjxicj4KZ3N3ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsZW1hbmk7IFN3aXNzIEdl cm1hbiAmbmJzcDsKJm5ic3A7ICZuYnNwO2Fsw6ltYW5pcXVlIDxicj4KPGJyPgpIb3dldmVyLCB0 aGVyZSBpcyBhICZxdW90O2MmcXVvdDsgbWlzc2luZyBmcm9tIEFsZW1hbmljLCBhbmQgU3dpc3Mg R2VybWFuCmlzIG5vdCB0aGUgc2FtZSBhcyBBbGVtYW5pYzogU3dpc3MgR2VybWFuIGlzIGEgdHlw ZSBvZiBBbGVtYW5pYywgYnV0IHRoZXJlCmFyZSBvdGhlciB0eXBlcyB0aGF0IGFyZSBub3QgdGhl IHNhbWUgYXMgU3dpc3MgR2VybWFuLjxicj4KPGJyPgpRdW90aW5nIE1hcnRpbiBEdWVyc3Q6IDwv Zm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxicj4KPGJyPgomcXVv dDtZZXMsIFN3YWJpYW4gaXMgY2xlYXJseSBBbGVtYW5pYy4gQWxlbWFuaWMgYW5kIFN3aXNzIEdl cm1hbiBhcmUgbm90PGJyPgp0aGUgc2FtZS4gVGhlcmUgYXJlIHZlcnkgY2xvc2Ugc2ltaWxhcml0 aWVzIGJldHdlZW4gc29tZSBkaWFsZWN0cyBpbiA8YnI+CnRoZSBub3J0aCBvZiBTd2l0emVybGFu ZCBhbmQgYWNyb3NzIHRoZSBib3JkZXIgaW4gR2VybWFueSwgYnV0IGFzPGJyPgpzb29uIGFzIHlv dSBjcm9zcyB0aGUgYm9yZGVyLCBpdCdzIHZlcnkgY2xlYXJseSBubyBsb25nZXIgU3dpc3M8YnI+ Ckdlcm1hbi4gQSBsYWJlbCBzdWNoIGFzICZxdW90O0FsZW1hbmljOyBTd2lzcyBHZXJtYW4mcXVv dDssIGFzc3VtaW5nIHRoYXQKPGJyPgpib3RoIGFyZSB0aGUgc2FtZSwgaXMgY2xlYXJseSB3cm9u Zy4gSWYgaXQncyBzb21ldGhpbmcgbGlrZTxicj4KJnF1b3Q7QWxlbWFuaWM7IGluY2x1ZGVzIFN3 aXNzIEdlcm1hbiZxdW90OywgdGhhdCB3b3VsZCBiZSBva2F5LiZxdW90Ozxicj4KPGJyPgpDYW4g dGhpcyBiZSBjb3JyZWN0ZWQgc28gdGhhdCBpdCBkb2VzIG5vdCBjb250aW51ZSB0byBtaXNsZWFk IHBlb3BsZT8gPGJyPgo8YnI+Ck1hcmsgRGF2aXMgPC9mb250Pgo8L3A+PHA+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciIHNpemU9IjIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPgpJZXRmLWxhbmd1YWdlcyBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0 bzpJZXRmLWxhbmd1YWdlc0BhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPklldGYtbGFuZ3Vh Z2VzQGFsdmVzdHJhbmQubm88L2E+PGJyPgo8YSBocmVmPSJodHRwOi8vd3d3LmFsdmVzdHJhbmQu bm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8v d3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlczwvYT48L2Zv bnQ+CjwvcD48cD4KPC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9w PjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+ PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48 cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjxwPjwvcD48cD48L3A+PHA+PC9wPjwv c3Bhbj4KPC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_6539_29042332.1164940884653-- --===============0842542347== 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 --===============0842542347==--