From petercon@microsoft.com Sun Mar 1 14:09:40 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F412828C1EC for ; Sun, 1 Mar 2009 14:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm90J6ofcoUI for ; Sun, 1 Mar 2009 14:09:33 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 73B4A3A6359 for ; Sun, 1 Mar 2009 14:08:14 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 1 Mar 2009 14:08:39 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Sun, 1 Mar 2009 14:08:39 -0800 From: Peter Constable To: CE Whitehead , "ltru@ietf.org" Date: Sun, 1 Mar 2009 14:08:35 -0800 Thread-Topic: [Ltru] Data update from ISO 639-5 to draft-4645bis Thread-Index: AcmUPLdpe3ZwqcauQmSbADwVsjL61gGfP0Pg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E623DE60NAEXMSGC117re_" MIME-Version: 1.0 Cc: "rgue@loc.gov" , "iso639-3@sil.org" Subject: Re: [Ltru] Data update from ISO 639-5 to draft-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 22:09:40 -0000 --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E623DE60NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is all resolved, and I'm not trying to re-open anything. I just though= t people might be interested in some background on the term "Dayak" and why= it's not sensible to try to infer genetic associations based on that term. "Dayak" is not a linguonym but rather an ethnonym or, even, a socionym. Wha= t was explained to me some years back is that its history is a pejorative t= erm used by the "civilized" Muslim majority on the island of Borneo to refe= r to the many uncivilized, non-Muslim "tribal" minorities. I ran into this when doing early prep work for ISO 639-3: trying to figure = out how the entry day in 639-2 should relate to entries in Ethnologue. The = MARC Language Code List, which was the source for 639-2, used day to encomp= ass languages that cut across major divisions of the Western Malayo-Polynes= ian language family. At the time, 639-2 treated it as an individual languag= e ("languages" was not part of the name). The options were (a) to specify t= he denotation to some particular language (in spite of MARC), (b) change th= e scope to be a genetic collection and find some node in the W M-P language= -family hierarchy to identify it with (breaking with past MARC usage, but l= ess severely), (c) define the scope to be some ad-hoc collection (perhaps f= ollowing MARC documentation), or (d) to deprecate it. The decision taken by= the JAC was to treat it as a collection. As ISO 639 does not document the = precise denotation of collections, the choice between options (b) and (c) w= as left undetermined. If someone wants to try to improve on nailing down this bit of jello, good = luck! :) Peter From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of CE = Whitehead Sent: Saturday, February 21, 2009 7:53 AM To: ltru@ietf.org Cc: iso639-3@sil.org; rgue@loc.gov Subject: Re: [Ltru] Data update from ISO 639-5 to draft-4645bis Hi, Kent, Doug: It seems to me that at ethnologue: Dayak, Land [dyk] is a subset of the Land Dayak group of languages: http://www.ethnologue.com/show_family.asp?subid=3D91242 (There is also a separate group of languages there, Malayic Dayak which is = under the group Malayik and not the group Land Dayak; both Malayik (in the = "Ibanic" group) and Land Dayak are classified as Malayo-Polynesian but they= are not the same--not in Wikipedia either; Wikipedia classifies both as Da= yak it seems. So it may be just the naming that is different. That's as near as I can make this classification out.) Thanks. --C. E. Whitehead cewcathar@hotmail.com From: Kent Karlsson > Date: Sat, 21 Feb 2009 13:30:39 +0100 >Side remark: I have seen translations of this one as just "Dayak". > But the Land Dayak languages appears to be a subset of the Dayak languages. At least according to Wikipedia: > http://en.wikipedia.org/wiki/Dayak_languages, > http://en.wikipedia.org/wiki/Bidayuh. > (In addition there is the retired code dyk for Land Dayak [languages]...) --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E623DE60NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is all resolved, and I'm not trying to re-open anything= . I just thought people might be interested in some background on the term "Dayak" and why it's not sensible to try to infer genetic associa= tions based on that term.

 

"Dayak" is not a linguonym but rather an ethnonym = or, even, a socionym. What was explained to me some years back is that its hist= ory is a pejorative term used by the "civilized" Muslim majority on t= he island of Borneo to refer to the many uncivilized, non-Muslim "tribal" minorities.

 

I ran into this when doing early prep work for ISO 639-3: tr= ying to figure out how the entry day in 639-2 should relate to entries in Ethnologue. The MARC Language Code List, which was the source for 639-2, us= ed day to encompass languages that cut across major divisions of the Western Malayo-Polynesian language family. At the time, 639-2 treated it as an individual language ("languages" was not part of the name). The options were (a) to specify the denotation to some particular language (in spite of MARC), (b) change the scope to be a genetic collection and find so= me node in the W M-P language-family hierarchy to identify it with (breaking w= ith past MARC usage, but less severely), (c) define the scope to be some ad-hoc collection (perhaps following MARC documentation), or (d) to deprecate it. = The decision taken by the JAC was to treat it as a collection. As ISO 639 does = not document the precise denotation of collections, the choice between options = (b) and (c) was left undetermined.

 

If someone wants to try to improve on nailing down this bit = of jello, good luck! J

 

 

Peter

 

From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of CE Whitehead
Sent: Saturday, February 21, 2009 7:53 AM
To: ltru@ietf.org
Cc: iso639-3@sil.org; rgue@loc.gov
Subject: Re: [Ltru] Data update from ISO 639-5 to draft-4645bis=

 

Hi, Kent, Doug:
 
It seems to me that
at ethnologue:
Dayak, Land [dyk] is a subset of the Land Dayak group of languages:
http://= www.ethnologue.com/show_family.asp?subid=3D91242
 
(There is also a separate group of languages there, Malayic Dayak which is under the group Malayik and not the group Land Dayak; both Malayik (in the "Ibanic" group) and Land Dayak are classified as Malayo-Polynesian but they are not the same--not in Wikipedia either; Wikip= edia classifies both as Dayak it seems.
 
So it may be just the naming that is different.
 
That's as near as I can make this classification out.)
 
Thanks.
 
--C. E. Whitehead
cewcathar@hotmail.com

 
From:= Kent Karlsson <kent.karlsson= 14 at comhem.se>
Date: Sa= t, 21 Feb 2009 13:30:39 +0100
 
>Side remark: I have seen translations of this one as just "Dayak".
> But the Land Dayak languages appears to be a subset of the Dayak
languages. At least according to Wikipedia:
> http://en.wik= ipedia.org/wiki/Dayak_languages,
> http://en.wikipedia.o= rg/wiki/Bidayuh.
> (In addition there is the retired code dyk for Land Dayak [languages].= ..)

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E623DE60NAEXMSGC117re_-- From cowan@ccil.org Sun Mar 1 21:23:05 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E4C3A6ADE for ; Sun, 1 Mar 2009 21:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al11tCU41xpD for ; Sun, 1 Mar 2009 21:23:04 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 7D4443A68AA for ; Sun, 1 Mar 2009 21:23:04 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Le0ci-0006AE-64; Mon, 02 Mar 2009 00:23:28 -0500 Date: Mon, 2 Mar 2009 00:23:28 -0500 To: Peter Constable Message-ID: <20090302052327.GA4721@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: CE Whitehead , "iso639-3@sil.org" , "ltru@ietf.org" , "rgue@loc.gov" Subject: Re: [Ltru] Data update from ISO 639-5 to draft-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 05:23:06 -0000 Peter Constable scripsit: > "Dayak" is not a linguonym but rather an ethnonym or, even, > a socionym. What was explained to me some years back is that its > history is a pejorative term used by the "civilized" Muslim majority > on the island of Borneo to refer to the many uncivilized, non-Muslim > "tribal" minorities. They are, in fact, the wild men from Borneo who have just (more or less) come to town. -- A poetical purist named Cowan [that's me: cowan@ccil.org] Once put the rest of us dowan. [on xml-dev] "Your verse would be sweeter http://www.ccil.org/~cowan If it only had metre And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay From textexin@xencraft.com Mon Mar 2 01:05:12 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A8E3A6A50 for ; Mon, 2 Mar 2009 01:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku9RdE0iwG6w for ; Mon, 2 Mar 2009 01:05:11 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 1A08B3A67A5 for ; Mon, 2 Mar 2009 01:05:10 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id N9461b0010QuhwU5395dvE; Mon, 02 Mar 2009 09:05:37 +0000 Received: from XENCRAFT ([12.34.88.194]) by OMTA02.westchester.pa.mail.comcast.net with comcast id N95L1b0044Bb9wU3N95PMP; Mon, 02 Mar 2009 09:05:35 +0000 From: "Tex Texin" To: , Date: Mon, 2 Mar 2009 01:05:18 -0800 Organization: XenCraft Message-ID: <005e01c99b16$0b00d700$21028500$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C99AD2.FCDD9700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmbFf0GX5bdl/TJT0uPOFvY5ZJ8+w== Content-Language: en-us x-cr-hashedpuzzle: AvNE BDj1 DH/9 EKwW INmC JA3t QMvF RRLC THW2 ThK4 VL7Z WGoe X3Mg fBPn fB7J hI95; 3; aQBlAHQAZgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdAByAHUAQABpAGUAdABmAC4AbwByAGcAOwB0AGUAeAB0AGUAeABpAG4AQAB4AGUAbgBjAHIAYQBmAHQALgBjAG8AbQA=; Sosha1_v1; 7; {B49BEED6-B5F1-4B1F-87C2-B616FE7E735E}; dABlAHgAdABlAHgAaQBuAEAAeABlAG4AYwByAGEAZgB0AC4AYwBvAG0A; Mon, 02 Mar 2009 09:05:09 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGwAdAByAHUALQA0ADYANAA1AGIAaQBzAC0AMQAwAC4AdAB4AHQAIABpAHMAcwB1AGUAIAB3AGkAdABoACAAcAByAGUAZgBlAHIAcgBlAGQAIAB2AGEAbAB1AGUAIABmAG8AcgAgAFkAVQA= x-cr-puzzleid: {B49BEED6-B5F1-4B1F-87C2-B616FE7E735E} Subject: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 09:05:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005F_01C99AD2.FCDD9700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With respect to the proposed update to the Language Subtag Registry = draft-ietf-ltru-4645bis-10: =20 I would like to lodge an objection to the deletion of the = Preferred-Value for language subtag YU. =20 This change breaks the equivalence class relation between YU and CS. It = detrimentally changes the behavior of existing implementations. The loss of the relationship between YU and CS makes documents that were = believed to be tagged equivalently, to no longer be equivalent. =20 There is also no benefit to this change. =20 To be concrete, assume a user attempts to find documents for languages = from Yugoslavia. Using the then current registry data, a query tool noting the preferred = value relationship, matches either xx-YU and xx-CS. =20 Another user searches for documents for Serbia. A query tool using the current registry data noting the preferred value = relationship, matches either xx-YU and xx-CS. =20 The results are in some sense accurate and complete, given the history = of the subtag. =20 After this change in the preferred value relationship, the query tool = does not know to search for both xx-YU and xx-CS, since the registry = does not indicate a relationship. Only one or the other subtag is used = for each query. However, the query results are now incomplete since some = documents for xx-YU have been tagged with the one-time preferred tag of = xx-CS. =20 Comments in the registry are not a solution. Comments are a good thing = for recording rationale and tangential history. However, implementers = are not going to go thru and read the comments on any or all tags in = order to make a correct implementation. They are going to implement = based on the schema and operate with the data values. =20 The registry should stay as it is with respect to YU and retain CS as = the preferred value. As CS is now being used as a preferred value, deprecated or not, there = isn't a compelling motivation to remove the preferred value for YU. =20 Please eliminate this needless change that breaks applications relying = on the relationship between YU and CS. =20 tex ------=_NextPart_000_005F_01C99AD2.FCDD9700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

With respect to the proposed update to the Language = Subtag Registry draft-ietf-ltru-4645bis-10:

 

I would like to lodge an objection to the deletion = of the Preferred-Value for language subtag YU.

 

This change breaks the equivalence class relation = between YU and CS. It detrimentally changes the behavior of existing = implementations.

The loss of the relationship between YU and CS = makes documents that were believed to be tagged equivalently, to no longer be equivalent.

 

There is also no benefit to this = change.

 

To be concrete, assume a user attempts to find = documents for languages from Yugoslavia.

Using the then current registry data, a query tool = noting the preferred value relationship, matches either xx-YU and = xx-CS.

 

Another user searches for documents for = Serbia.

A query tool using the current registry data noting = the preferred value relationship, matches either xx-YU and = xx-CS.

 

The results are in some sense accurate and = complete, given the history of the subtag.

 

After this change in the preferred value = relationship, the query tool does not know to search for both xx-YU and xx-CS, since the = registry does not indicate a relationship. Only one or the other subtag is used = for each query. However, the query results are now incomplete since some = documents for xx-YU have been tagged with the one-time preferred tag of = xx-CS.

 

Comments in the registry are not a solution. = Comments are a good thing for recording rationale and tangential history. However, implementers are not going to go thru and read the comments on any or = all tags in order to make a correct implementation. They are going to implement = based on the schema and operate with the data values.

 

The registry should stay as it is with respect to = YU and retain CS as the preferred value.

As CS is now being used as a preferred value, = deprecated or not, there isn't a compelling motivation to remove the preferred value = for YU.

 

Please eliminate this needless change that breaks applications relying on the relationship between YU and = CS.

 

tex

------=_NextPart_000_005F_01C99AD2.FCDD9700-- From prvs=13124ca2b8=debbie@ictmarketing.co.uk Mon Mar 2 01:42:09 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C66A3A69FA; Mon, 2 Mar 2009 01:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+b8ZNTgx1Pn; Mon, 2 Mar 2009 01:42:08 -0800 (PST) Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id 68F123A699C; Mon, 2 Mar 2009 01:42:07 -0800 (PST) Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50009029584.msg; Mon, 02 Mar 2009 09:59:02 +0000 X-Spam-Processed: mx1.nexbyte.net, Mon, 02 Mar 2009 09:59:02 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=13124ca2b8=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk Received: from Vickynew ([213.208.115.6]) by 145.nexbyte.net with MailEnable ESMTP; Mon, 02 Mar 2009 09:42:21 +0000 From: "Debbie Garside" To: "'Tex Texin'" , , References: <005e01c99b16$0b00d700$21028500$@com> Date: Mon, 2 Mar 2009 09:20:07 -0000 Message-ID: <07db01c99b18$1424db90$0300a8c0@Vickynew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07DC_01C99B18.1424DB90" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <005e01c99b16$0b00d700$21028500$@com> Thread-Index: AcmbFf0GX5bdl/TJT0uPOFvY5ZJ8+wAAgIvA X-MDAV-Processed: mx1.nexbyte.net, Mon, 02 Mar 2009 09:59:02 +0000 Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 02 Mar 2009 09:50:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07DC_01C99B18.1424DB90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit I fully support this objection. Best regards Debbie _____ From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Tex Texin Sent: 02 March 2009 09:05 To: ltru@ietf.org; ietf@ietf.org Subject: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU With respect to the proposed update to the Language Subtag Registry draft-ietf-ltru-4645bis-10: I would like to lodge an objection to the deletion of the Preferred-Value for language subtag YU. This change breaks the equivalence class relation between YU and CS. It detrimentally changes the behavior of existing implementations. The loss of the relationship between YU and CS makes documents that were believed to be tagged equivalently, to no longer be equivalent. There is also no benefit to this change. To be concrete, assume a user attempts to find documents for languages from Yugoslavia. Using the then current registry data, a query tool noting the preferred value relationship, matches either xx-YU and xx-CS. Another user searches for documents for Serbia. A query tool using the current registry data noting the preferred value relationship, matches either xx-YU and xx-CS. The results are in some sense accurate and complete, given the history of the subtag. After this change in the preferred value relationship, the query tool does not know to search for both xx-YU and xx-CS, since the registry does not indicate a relationship. Only one or the other subtag is used for each query. However, the query results are now incomplete since some documents for xx-YU have been tagged with the one-time preferred tag of xx-CS. Comments in the registry are not a solution. Comments are a good thing for recording rationale and tangential history. However, implementers are not going to go thru and read the comments on any or all tags in order to make a correct implementation. They are going to implement based on the schema and operate with the data values. The registry should stay as it is with respect to YU and retain CS as the preferred value. As CS is now being used as a preferred value, deprecated or not, there isn't a compelling motivation to remove the preferred value for YU. Please eliminate this needless change that breaks applications relying on the relationship between YU and CS. tex No virus found in this incoming message. Checked by AVG. Version: 7.5.557 / Virus Database: 270.11.5/1979 - Release Date: 01/03/2009 17:46 No virus found in this outgoing message. Checked by AVG. Version: 7.5.557 / Virus Database: 270.11.5/1979 - Release Date: 01/03/2009 17:46 ------=_NextPart_000_07DC_01C99B18.1424DB90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

I fully support this = objection.

 

Best = regards

 

Debbie

 

From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Tex Texin
Sent: 02 March 2009 = 09:05
To: ltru@ietf.org; = ietf@ietf.org
Subject: draft-ietf-ltru-4645bis-10.txt issue with preferred value for = YU

 

With respect to the proposed update to the Language Subtag Registry draft-ietf-ltru-4645bis-10:

 

I would like to lodge an objection to the deletion of the Preferred-Value = for language subtag YU.

 

This change breaks the equivalence class relation between YU and CS. It detrimentally changes the behavior of existing = implementations.

The loss of the relationship between YU and CS makes documents that were = believed to be tagged equivalently, to no longer be = equivalent.

 

There is also no benefit to this change.

 

To be concrete, assume a user attempts to find documents for languages from = Yugoslavia.

Using the then current registry data, a query tool noting the preferred value relationship, matches either xx-YU and = xx-CS.

 

Another user searches for documents for Serbia.

A query tool using the current registry data noting the preferred value relationship, matches either xx-YU and = xx-CS.

 

The results are in some sense accurate and complete, given the history of = the subtag.

 

After this change in the preferred value relationship, the query tool does not = know to search for both xx-YU and xx-CS, since the registry does not indicate = a relationship. Only one or the other subtag is used for each query. = However, the query results are now incomplete since some documents for xx-YU have = been tagged with the one-time preferred tag of = xx-CS.

 

Comments in the registry are not a solution. Comments are a good thing for = recording rationale and tangential history. However, implementers are not going to = go thru and read the comments on any or all tags in order to make a correct implementation. They are going to implement based on the schema and = operate with the data values.

 

The registry should stay as it is with respect to YU and retain CS as the = preferred value.

As CS is now being used as a preferred value, deprecated or not, there = isn't a compelling motivation to remove the preferred value for = YU.

 

Please eliminate this needless change that breaks applications relying on the relationship between YU and CS.

 

tex=


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.11.5/1979 - Release Date: = 01/03/2009 17:46


No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.11.5/1979 - Release Date: = 01/03/2009 17:46

------=_NextPart_000_07DC_01C99B18.1424DB90-- From duerst@it.aoyama.ac.jp Mon Mar 2 02:19:54 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A9E3A699C for ; Mon, 2 Mar 2009 02:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.422 X-Spam-Level: ** X-Spam-Status: No, score=2.422 tagged_above=-999 required=5 tests=[AWL=-2.579, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1ZJecd8X-7w for ; Mon, 2 Mar 2009 02:19:53 -0800 (PST) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 67D973A68C7 for ; Mon, 2 Mar 2009 02:19:51 -0800 (PST) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n22AKGWQ005689 for ; Mon, 2 Mar 2009 19:20:16 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 4659_b93c3378_0713_11de_9e59_0019b9e2b3d9; Mon, 02 Mar 2009 19:20:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35680) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Mar 2009 19:11:43 +0900 Message-Id: <6.0.0.20.2.20090301210247.09515b90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Mar 2009 19:19:23 +0900 To: Chris Newman From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Addison Phillips Subject: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:19:54 -0000 Hello Chris, [I'm assuming you are the acting AD currently. I'm cc'ing Alex so he knows what might be comming up for him.] I'm glad to finally request IETF LAST CALL for draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21), the two current WG documents of the LTRU WG. The intended status of 4645bis is informational, the intended status of 4646bis is BCP (BCP 47 together with RFC 4647, which stays as it is). I'm sending the shepherding documents in separate mails, but I'm using this mail as a trigger; that's what Ted Hardie told me to do when I did this thing last time. If I need to do anything else, please don't hesitate to tell me. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Mon Mar 2 02:19:56 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA3728C210 for ; Mon, 2 Mar 2009 02:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[AWL=1.311, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVNCrovLGAug for ; Mon, 2 Mar 2009 02:19:55 -0800 (PST) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 1E8A73A68C7 for ; Mon, 2 Mar 2009 02:19:55 -0800 (PST) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n22AKJlK005728 for ; Mon, 2 Mar 2009 19:20:19 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 01cf_bb1ef784_0713_11de_8be3_001d0969ab06; Mon, 02 Mar 2009 19:20:19 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35680) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Mar 2009 19:11:51 +0900 Message-Id: <6.0.0.20.2.20090302184738.082f7198@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Mar 2009 19:19:07 +0900 To: Chris Newman From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Addison Phillips Subject: [Ltru] Shepherding writeup for draft-ietf-ltru-4646bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:19:56 -0000 [template from http://www.ietf.org/IESG/content/Doc-Writeup.html] (1.a) Who is the Document Shepherd for this document? Martin Duerst (duerst@it.aoyama.ac.jp, LTRU WG co-chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, I have personally reviewed it, and concluded that this version is ready for forwarding to the IESG for (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns or issues that I would know of. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Overall, I think the whole WG understands it and agrees with it. There were a few points where there was long-lasting disagreement and discussion, but for which we found solutions acceptable in all scenarios. The main such point was the treatment of extlangs. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Yes. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes for ID nits. MIB, media type, URI considerations don't apply. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes for the split. No for unclear or downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document updates the procedures for the IANA Language Subtag Registry (and the Language Tag Extension registry, which is mostly dormant). The document contains the following language: The Language Subtag Reviewer is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications. Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that the reviewer can assess the claims and draw upon the contributions of language experts and subtag requesters. The IESG will therefore have to solicit nominees for this position again when this document is adopted. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF for language tags in Figure 1 in the previous draft (-20.txt) has passed http://www.fenron.com/~fenner/abnf.cgi without errors. There were no changes in the ABNF between -20 and -21, but www.fenron.com currently doesn't seem to be reachable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? [there is no need for a question mark here :-] Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document is an update of RFC4646. The main change is the addition of thousands of three-letter language subtags for languages for which tagging was not possible up to now. Also, the registry format and procedures were adjusted to deal with this change, and to reflect experience from current practice. The WG process for this document was mostly smooth and revolving around details. There were some highly contentious issues, but for all of them, a solution was found that was acceptable to the involved parties and works for all scenarios identified. The IANA Language Subtag Registry, and the language tags that can be formed according to this document and its predecessor, are widely used across the Internet to identify languages, both in implementations (code) and in a wide range of data. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Mon Mar 2 03:25:44 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B933A6AB1 for ; Mon, 2 Mar 2009 03:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYUhv2+-Lf-r for ; Mon, 2 Mar 2009 03:25:42 -0800 (PST) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 2A3323A6AC3 for ; Mon, 2 Mar 2009 03:25:38 -0800 (PST) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n22AKHBX005708 for ; Mon, 2 Mar 2009 19:20:17 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 019d_ba0af3d4_0713_11de_ac75_001d0969ab06; Mon, 02 Mar 2009 19:20:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35680) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Mar 2009 19:11:50 +0900 Message-Id: <6.0.0.20.2.20090302184242.082f7058@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Mar 2009 19:18:45 +0900 To: Chris Newman From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Addison Phillips Subject: [Ltru] Shepherding writeup for draft-ietf-ltru-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 11:25:44 -0000 [template from http://www.ietf.org/IESG/content/Doc-Writeup.html] (1.a) Who is the Document Shepherd for this document? Martin Duerst (duerst@it.aoyama.ac.jp, LTRU WG co-chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, I have personally reviewed it, and concluded that this version is ready for forwarding to the IESG for (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. Due to its nature, the bulk of the document has mostly been 'reviewed' by cross-checking programs. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The document mainly contains public data, which isn't security- relevant. The considerable increase in size of the IANA registry has been discussed directly with IANA. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns or issues that I would know of. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I don't have any doubt that the WG as a whole understands it and agrees it, because it makes available several thousand new language subtags for languages which up to now cannot be tagged. For some issues (e.g. the treatment of extlangs), there has been intense discussion with diametrally opposing positions, but we were able to find a solution that was acceptable to everybody. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Yes. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes for ID nits. MIB, media type, URI considerations don't apply. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes for the split. No for unclear or downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document provides content for an actual update of the IANA Language Subtag Registry. The details are clearly spelled out in the IANA section, and the most crucial aspects of this update have already been discussed with IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The bulk of the document is in a format defined in draft-ietf-ltru-4646bis. I haven't verified this myself, but several members of the WG have, with their own tools. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? [there is no need for a question mark here :-] Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of draft-ietf-ltru-4646bis [NOTE: replace with actual RFC number], for use in forming tags for identifying languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. This update adds several thousand language codes to the registry, which will allow these languages to be identified appropriately on the Internet. To prevent confusion, the actual registry contents was removed before publication as an RFC. The WG process for this document was mostly smooth and revolving around details. This document also reflects changes defined in draft-ietf-ltru-4646bis, which are disussed in a separate writeup. The data contained in the document when it was an Internet Draft has been read and processed by several tools the implement parsing of the registry format and additional operations on this data. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From randy_presuhn@mindspring.com Mon Mar 2 09:59:30 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A6A3A6990; Mon, 2 Mar 2009 09:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji29usteuHn1; Mon, 2 Mar 2009 09:59:29 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id BF60F3A63EB; Mon, 2 Mar 2009 09:59:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=D6x8OT5liLw4tyfiZs2wVqvonpq1KdPT6zCeGg0nCx1s1am5NduzWxrqL17mBU44; 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 [69.3.28.100] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LeCQk-0007AP-Hy; Mon, 02 Mar 2009 12:59:54 -0500 Message-ID: <012801c99b60$c940c280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <005e01c99b16$0b00d700$21028500$@com> Date: Mon, 2 Mar 2009 10:00:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17376b7d6386e78810199268969ca6797e1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.100 Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:59:30 -0000 Hi - > From: "Tex Texin" > To: ; > Sent: Monday, March 02, 2009 1:05 AM > Subject: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU > > With respect to the proposed update to the Language Subtag Registry draft-ietf-ltru-4645bis-10: > > I would like to lodge an objection to the deletion of the Preferred-Value for language subtag YU. As ltru co-chair: it's exceedingly late for such an objection - the issue was discussed at length in the working group over a year ago. A recent revisiting of the question arrived at the same conclusion. > This change breaks the equivalence class relation between YU and CS. > It detrimentally changes the behavior of existing implementations. As a technical contributor: The main reason that CS does not make sense as a preferred value for YU is that there is *not* an "equivalence class relation" between them. There are pieces of what was YU that are not covered by CS. To treat them as an "equivalence class" ignores linguistic, geographic, and political reality. > The loss of the relationship between YU and CS makes documents that were > believed to be tagged equivalently, to no longer be equivalent. In my opinion, regarding them as equivalent is an error, since CS and YU don't encompass the same regions. > There is also no benefit to this change. I disagree. The change removes an error. > To be concrete, assume a user attempts to find documents for languages from Yugoslavia. Language tags do *not* pretend to be able to answer this sort of query. Using a region subtag (e.g. 'CS') says that the data subtag uses a specific variety of the primary language, and that the party tagging the data believes that this distinction is useful. For example, I could tag this paragraph with 'en' or with 'en-US'. Is that extra distinction necessary or useful? In this case, no. Consequently, the "retrieving documents by region subtag" use case, although technically permitted by RFC 4647, is not realistic, and in many ways contrary to the basic "tag wisely" principle. > Using the then current registry data, a query tool noting the preferred > value relationship, matches either xx-YU and xx-CS. > > Another user searches for documents for Serbia. > > A query tool using the current registry data noting the preferred value > relationship, matches either xx-YU and xx-CS. > > The results are in some sense accurate and complete, given the history of the subtag. No, they are not. (1) there is no requirement, much less a guarantee, that the data will bear a region subtag at all (2) there are many bits and pieces of YU not covered by CS - even if data always bore a region subtag, the YU->CS mapping would miss all the other territory that once belonged to YU. (3) blindly replacing all YU subtags with CS subtags would in fact falsify some data, since the language could well be of a variety covered by YU but not by CS. > After this change in the preferred value relationship, the query > tool does not know to search for both xx-YU and xx-CS, since the > registry does not indicate a relationship. Only one or the other > subtag is used for each query. However, the query results are now > incomplete since some documents for xx-YU have been tagged with > the one-time preferred tag of xx-CS. The relationship cannot be adequately automated with a simple one-way pointer like "preferred-value". The former YU also encompassed BA, HR, ME, MK, RS, and SI. > Comments in the registry are not a solution. Comments are a good > thing for recording rationale and tangential history. However, > implementers are not going to go thru and read the comments on any > or all tags in order to make a correct implementation. They are going > to implement based on the schema and operate with the data values. If someone (or something) is applying region subtags, they'd better have sufficient knowledge of the language varieties to do so meaningfully. This effectively requires *understanding* those comments and much more. The Language Subtag Registry does *not* attempt to record all the information needed to recognize language varieties. Rather, once someone (or something) has made a distinction, the LSR provides the bits needed to encode a tag for that language variety. In the particular case of the languages of the former YU, the region subtags now available (such as BA, HR, ME, MK, RS, and SI) are arguably far more useful, if someone needs to distinguish regional variations in their Croatian-language data, than just YU. (It's unclear to me whether YU would ever have been terribly useful, since it would allow the distinction of Croatian as spoken there from Croatian spoken somewhere (where?) else.) > The registry should stay as it is with respect to YU and retain > CS as the preferred value. > > As CS is now being used as a preferred value, deprecated or not, > there isn't a compelling motivation to remove the preferred value for YU. Please, let's look at the actual tagged language data. What corpora out there have employed YU (correctly) as a subtag? To what extent would replacing that subtag with 'CS' (rather than with BA, HR, ME, MK, RS, or SI) be correct, for Serbian, Croatian, or any of the other languages of that region? > Please eliminate this needless change that breaks applications > relying on the relationship between YU and CS. I would argue rather than an application that relies on an equivalence relation between YU and CS is already in some sense broken, in the same way as one assuming that Russia and the Soviet Union are somehow equivalent. > tex Randy From textexin@xencraft.com Tue Mar 3 02:10:11 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED8A3A6C16 for ; Tue, 3 Mar 2009 02:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU9QE67E3WCl for ; Tue, 3 Mar 2009 02:10:09 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id D6F7A3A6A15 for ; Tue, 3 Mar 2009 02:10:08 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Na8T1b0030lTkoCA7aAcxL; Tue, 03 Mar 2009 10:10:36 +0000 Received: from XENCRAFT ([24.6.121.224]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id NaAa1b00B4qbJq08QaAbrb; Tue, 03 Mar 2009 10:10:36 +0000 From: "Tex Texin" To: "'Randy Presuhn'" , , "'Phillips, Addison'" References: <4D25F22093241741BC1D0EEBC2DBB1DA019E160DE7@EX-SEA5-D.ant.amazon.com> <000901c99ba0$6e91eea0$6801a8c0@oemcomputer> In-Reply-To: <000901c99ba0$6e91eea0$6801a8c0@oemcomputer> Date: Tue, 3 Mar 2009 02:10:33 -0800 Organization: XenCraft Message-ID: <002a01c99be8$4b3c97f0$e1b5c7d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmbrqh6+Lr+2nkCQJ+nA8U18KZoAQAN748w Content-Language: en-us Cc: ltru@ietf.org Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:10:11 -0000 Hi guys, I sent the message to this list (as well as LTRU) in the belief I was following the instructions given to me... (My mail actually preceded Martin's request to the AD.) I admit to confusion about the suggestion I can register the change after 4645bis is accepted. 4645bis changes a code that exists already. I shouldn't have to reregister it to restore it. If anything, have 4645bis go forward without the change, and the change can be discussed separately. I'll pursue the discussion on the ltru list as requested and respond to Randy's other comments there. tex -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, March 02, 2009 5:36 PM To: ietf@ietf.org Subject: Re: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU Hi - > From: "Phillips, Addison" > To: > Sent: Monday, March 02, 2009 9:49 AM > Subject: RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU > > Hi Tex, > > I don't think this is probably appropriate, at least for this list to consider. Tex's posting came after the document shepherd (co-chair Martin Duerst) had sent the information to our AD requesting that the IESG consider publishing it. So although the IESG has not yet (AFAIK) acted on the request, much less issued an IETF last call, I can understand why ietf@ietf.org might be included. I have already responded to it on both lists, even though I think the issue is probably of little interest to most on the ietf@ietf.org list. Unless instructed to do otherwise by our AD, I would suggest that all follow-on discussion be directed to ltru@ietf.org > 1. You haven't posted to LTRU's mailing list, only ietf-languages@, yet. Tex's message was posted to *both* lists. > 2. Even if draft-4645bis is approved, the process for language tags > (in either RFC 4646 or its proposed successor) allow you to register > the information you want, if you think it was inappropriately omitted. ... Correct. Randy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From cewcathar@hotmail.com Tue Mar 3 08:38:52 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EC83A69EC for ; Tue, 3 Mar 2009 08:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoZwpddp+QIA for ; Tue, 3 Mar 2009 08:38:51 -0800 (PST) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by core3.amsl.com (Postfix) with ESMTP id B93A83A6955 for ; Tue, 3 Mar 2009 08:38:51 -0800 (PST) Received: from BLU109-W57 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 08:39:19 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_02e53b64-bc12-4d99-9399-cf424bffbe82_" X-Originating-IP: [198.252.156.11] From: CE Whitehead To: Date: Tue, 3 Mar 2009 11:39:18 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2009 16:39:19.0117 (UTC) FILETIME=[99452FD0:01C99C1E] Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:38:52 -0000 --_02e53b64-bc12-4d99-9399-cf424bffbe82_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi!=20 =20 The 'YU' subtag listed in the registry (draft 10 of RFC 4645) with the comm= ents currently there looks fine to me! =20 "Type: region Subtag: YU Description: Yugoslavia Added: 2005-10-16 Deprecated: 2003-07-23 Comments: see BA=2C HR=2C ME=2C MK=2C RS=2C or SI" =20 When the draft is published=2C one might of course add to these comments on= e more: =20 'YU' was in certain period replaced with 'CS'=3B=20 to see 'CS' as well.=20 =20 (This would help avoid breaking the old and now deprecated 'CS'-'YU' relati= onship--which is not quite like the broken relationship between Russia and = the USSR because the name Russia has not been deprecated?? or is it now "Th= e Russian Federation?" I have to say that I can't agree with 'YU' 's point= ing exclusively to 'CS' because of the other subtags it might point to as w= ell.) =20 --C. E. Whitehead cewcathar@hotmail.com=20 --_02e53b64-bc12-4d99-9399-cf424bffbe82_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi!
 =3B
The 'YU' subtag listed in the registry =3B(draft 10 of RFC 4645) with t= he comments =3Bcurrently there looks fine =3Bto me!
 =3B
"Type: region
Subtag: YU
Description: Yugoslavia
Added: 2005-10-16=
Deprecated: 2003-07-23
Comments: see BA=2C HR=2C ME=2C MK=2C RS=2C o= r SI"
 =3B
When the draft is published=2C one =3Bmight =3Bof course =3Badd= to these comments one more: =3B
 =3B =3B'YU' =3Bwas in certain period replaced with 'CS'=3B  =3B to see 'CS' as well. =3B
 =3B
(This would =3Bhelp avoid breaking the old and now deprecated 'CS'-'YU'= relationship--which is =3Bnot quite like the broken relationship betwe= en Russia and the USSR because the name Russia has not been deprecated?? or= is it now =3B"The Russian Federation?" =3B I have to say that I&nb= sp=3Bcan't agree with 'YU' 's pointing exclusively to 'CS' because of the o= ther subtags it might point to as well.)
 =3B
--C. E. Whitehead
cewcathar@hotmail.com

=

= --_02e53b64-bc12-4d99-9399-cf424bffbe82_-- From textexin@xencraft.com Tue Mar 3 13:57:03 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8AA28C15F for ; Tue, 3 Mar 2009 13:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyH+h1USN+A2 for ; Tue, 3 Mar 2009 13:57:01 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id AE4743A6452 for ; Tue, 3 Mar 2009 13:57:01 -0800 (PST) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id NezY1b00A0QkzPwA8lxWGG; Tue, 03 Mar 2009 21:57:30 +0000 Received: from XENCRAFT ([76.126.218.47]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id NlxU1b00o11wtRY8NlxVmo; Tue, 03 Mar 2009 21:57:29 +0000 From: "Tex Texin" To: "'Randy Presuhn'" , References: <005e01c99b16$0b00d700$21028500$@com> <012801c99b60$c940c280$6801a8c0@oemcomputer> In-Reply-To: <012801c99b60$c940c280$6801a8c0@oemcomputer> Date: Tue, 3 Mar 2009 13:57:26 -0800 Organization: XenCraft Message-ID: <002101c99c4b$0ace1cd0$206a5670$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmbbwOM+/sMmnVtRLemn6v98drl/AA1qfow Content-Language: en-us Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:57:03 -0000 Randy, et al. 1) I agree the equivalence is faulty. However, it has been established and in existence for some time. Correcting the error in the manner proposed does a greater damage. 2) If comments were a suitable solution, then it could be argued that adding a comment to CS that despite it being a preferred value of YU it might not be the best choice. At least then the equivalence would not be lost. 3) I agree with you and retract the statement that "there is no benefit" to the proposed change. I instead claim the benefit does not outweigh the harm caused. 4) I am surprised by your remarks with respect to en vs en-US. Of course the distinction could be significant. If I want to find documents about a "jumper", en-US vs en-GB will be significant. Or if the count is a "billion". The fact that it might not be relevant to the one paragraph you wrote does not mean it is irrelevant in all other statements. Frankly it doesn't make sense to argue that the regional subtag is not significant, but it is different and important enough to warrant breaking the equivalence. 5) The search query was an example to demonstrate the significance of breaking the equivalence. The problem will show itself in other linguistic applications where the differences are significant. 6) I agree YU=> CS is an unfortunate occurrence in the registry. I disagree we should fix it in the manner proposed. It is one thing to optimize preferred values. It is another thing entirely to have them changing in a way that breaks or redefines existing tags. 7) The registry was created to ensure language tag stability. If we treat preferred values as proposed, we lose stability. We would be better off without preferred value relationships at all if we can't ensure stability. 8) I do not want to undermine the standard moving forward. I do think this particular issue is bad policy and precedent. I am not intimately familiar with the way that IETF treats these drafts and the last call process etc. What are the options here for addressing this without derailing the standard? tex -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, March 02, 2009 10:01 AM To: ltru@ietf.org; ietf@ietf.org Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU Hi - > From: "Tex Texin" > To: ; > Sent: Monday, March 02, 2009 1:05 AM > Subject: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU > > With respect to the proposed update to the Language Subtag Registry draft-ietf-ltru-4645bis-10: > > I would like to lodge an objection to the deletion of the Preferred-Value for language subtag YU. As ltru co-chair: it's exceedingly late for such an objection - the issue was discussed at length in the working group over a year ago. A recent revisiting of the question arrived at the same conclusion. > This change breaks the equivalence class relation between YU and CS. > It detrimentally changes the behavior of existing implementations. As a technical contributor: The main reason that CS does not make sense as a preferred value for YU is that there is *not* an "equivalence class relation" between them. There are pieces of what was YU that are not covered by CS. To treat them as an "equivalence class" ignores linguistic, geographic, and political reality. > The loss of the relationship between YU and CS makes documents that were > believed to be tagged equivalently, to no longer be equivalent. In my opinion, regarding them as equivalent is an error, since CS and YU don't encompass the same regions. > There is also no benefit to this change. I disagree. The change removes an error. > To be concrete, assume a user attempts to find documents for languages from Yugoslavia. Language tags do *not* pretend to be able to answer this sort of query. Using a region subtag (e.g. 'CS') says that the data subtag uses a specific variety of the primary language, and that the party tagging the data believes that this distinction is useful. For example, I could tag this paragraph with 'en' or with 'en-US'. Is that extra distinction necessary or useful? In this case, no. Consequently, the "retrieving documents by region subtag" use case, although technically permitted by RFC 4647, is not realistic, and in many ways contrary to the basic "tag wisely" principle. > Using the then current registry data, a query tool noting the preferred > value relationship, matches either xx-YU and xx-CS. > > Another user searches for documents for Serbia. > > A query tool using the current registry data noting the preferred value > relationship, matches either xx-YU and xx-CS. > > The results are in some sense accurate and complete, given the history of the subtag. No, they are not. (1) there is no requirement, much less a guarantee, that the data will bear a region subtag at all (2) there are many bits and pieces of YU not covered by CS - even if data always bore a region subtag, the YU->CS mapping would miss all the other territory that once belonged to YU. (3) blindly replacing all YU subtags with CS subtags would in fact falsify some data, since the language could well be of a variety covered by YU but not by CS. > After this change in the preferred value relationship, the query > tool does not know to search for both xx-YU and xx-CS, since the > registry does not indicate a relationship. Only one or the other > subtag is used for each query. However, the query results are now > incomplete since some documents for xx-YU have been tagged with > the one-time preferred tag of xx-CS. The relationship cannot be adequately automated with a simple one-way pointer like "preferred-value". The former YU also encompassed BA, HR, ME, MK, RS, and SI. > Comments in the registry are not a solution. Comments are a good > thing for recording rationale and tangential history. However, > implementers are not going to go thru and read the comments on any > or all tags in order to make a correct implementation. They are going > to implement based on the schema and operate with the data values. If someone (or something) is applying region subtags, they'd better have sufficient knowledge of the language varieties to do so meaningfully. This effectively requires *understanding* those comments and much more. The Language Subtag Registry does *not* attempt to record all the information needed to recognize language varieties. Rather, once someone (or something) has made a distinction, the LSR provides the bits needed to encode a tag for that language variety. In the particular case of the languages of the former YU, the region subtags now available (such as BA, HR, ME, MK, RS, and SI) are arguably far more useful, if someone needs to distinguish regional variations in their Croatian-language data, than just YU. (It's unclear to me whether YU would ever have been terribly useful, since it would allow the distinction of Croatian as spoken there from Croatian spoken somewhere (where?) else.) > The registry should stay as it is with respect to YU and retain > CS as the preferred value. > > As CS is now being used as a preferred value, deprecated or not, > there isn't a compelling motivation to remove the preferred value for YU. Please, let's look at the actual tagged language data. What corpora out there have employed YU (correctly) as a subtag? To what extent would replacing that subtag with 'CS' (rather than with BA, HR, ME, MK, RS, or SI) be correct, for Serbian, Croatian, or any of the other languages of that region? > Please eliminate this needless change that breaks applications > relying on the relationship between YU and CS. I would argue rather than an application that relies on an equivalence relation between YU and CS is already in some sense broken, in the same way as one assuming that Russia and the Soviet Union are somehow equivalent. > tex Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru From addison@amazon.com Tue Mar 3 14:28:11 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF553A6A96 for ; Tue, 3 Mar 2009 14:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpdSvIaKobWk for ; Tue, 3 Mar 2009 14:28:10 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by core3.amsl.com (Postfix) with ESMTP id 0179D3A6973 for ; Tue, 3 Mar 2009 14:28:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,297,1233532800"; d="scan'208";a="196481893" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2009 22:28:32 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n23MSVVm002620 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 3 Mar 2009 22:28:32 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Tue, 3 Mar 2009 14:28:31 -0800 From: "Phillips, Addison" To: Tex Texin , "'Randy Presuhn'" , "ltru@ietf.org" Date: Tue, 3 Mar 2009 14:28:30 -0800 Thread-Topic: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU Thread-Index: AcmbbwOM+/sMmnVtRLemn6v98drl/AA1qfowAAFg7hA= Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019E23A581@EX-SEA5-D.ant.amazon.com> References: <005e01c99b16$0b00d700$21028500$@com> <012801c99b60$c940c280$6801a8c0@oemcomputer> <002101c99c4b$0ace1cd0$206a5670$@com> In-Reply-To: <002101c99c4b$0ace1cd0$206a5670$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:28:11 -0000 PiANCj4gMSkgSSBhZ3JlZSB0aGUgZXF1aXZhbGVuY2UgaXMgZmF1bHR5LiBIb3dldmVyLCBpdCBo YXMgYmVlbg0KPiBlc3RhYmxpc2hlZCBhbmQNCj4gaW4gZXhpc3RlbmNlIGZvciBzb21lIHRpbWUu DQo+IENvcnJlY3RpbmcgdGhlIGVycm9yIGluIHRoZSBtYW5uZXIgcHJvcG9zZWQgZG9lcyBhIGdy ZWF0ZXIgZGFtYWdlLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IFByZWZlcnJlZC1WYWx1ZSBpcyBub3Qg ZXF1aXZhbGVuY2UuDQoNCg0KPiANCj4gNikgSSBhZ3JlZSBZVT0+IENTIGlzIGFuIHVuZm9ydHVu YXRlIG9jY3VycmVuY2UgaW4gdGhlIHJlZ2lzdHJ5LiBJDQo+IGRpc2FncmVlDQo+IHdlIHNob3Vs ZCBmaXggaXQgaW4gdGhlIG1hbm5lciBwcm9wb3NlZC4NCj4gSXQgaXMgb25lIHRoaW5nIHRvIG9w dGltaXplIHByZWZlcnJlZCB2YWx1ZXMuIEl0IGlzIGFub3RoZXIgdGhpbmcNCj4gZW50aXJlbHkN Cj4gdG8gaGF2ZSB0aGVtIGNoYW5naW5nIGluIGEgd2F5IHRoYXQgYnJlYWtzIG9yIHJlZGVmaW5l cyBleGlzdGluZw0KPiB0YWdzLg0KDQpZb3Uga25vdy4uLiB3ZSBoYXZlIHRoaXMgcHJvY2Vzcywg ZG9jdW1lbnRlZCBpbiB0aGUgUkZDLCBmb3IgcmVzb2x2aW5nIGRpZmZlcmVuY2VzIG9mIG9waW5p b24gbGlrZSB0aGlzLiBJdCdzIGNhbGxlZCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuIEkgYWN0 dWFsbHkgdGhpbmsgdGhhdCBoYXZpbmcgdGFncyBjYW5vbmljYWxpemUgdG8gcG9pbnQgdG8gJ0NT JyAoaGV5LCBkaWRuJ3QgdGhhdCBjb2RlIHVzZWQgdG8gYmUgQ3plY2hvc2xvdmFraWE/PykgaXMg bGVzcyBnb29kIHRoYW4gZml4aW5nIGl0LiBCdXQgdGhhdCdzIG15IG9waW5pb24uDQoNCj4gDQo+ IDcpIFRoZSByZWdpc3RyeSB3YXMgY3JlYXRlZCB0byBlbnN1cmUgbGFuZ3VhZ2UgdGFnIHN0YWJp bGl0eS4gSWYgd2UNCj4gdHJlYXQgcHJlZmVycmVkIHZhbHVlcyBhcyBwcm9wb3NlZCwgd2UgbG9z ZSBzdGFiaWxpdHkuDQoNCkFjdHVhbGx5LCB3ZSBkb24ndC4gVGhlIHRhZ3MgdGhlbXNlbHZlcyBy ZW1haW4gc3RhYmxlIGFuZCB2YWxpZC4gQ2Fub25pY2FsaXphdGlvbiBpcyBuZXZlciByZXF1aXJl ZC4gVGhlIG1vc3QgcHJldmFsZW50IGltcGxlbWVudGF0aW9ucyBkb24ndCBjYW5vbmljYWxpemUg dG9kYXkuDQoNCj4gV2Ugd291bGQgYmUgYmV0dGVyIG9mZiB3aXRob3V0IHByZWZlcnJlZCB2YWx1 ZSByZWxhdGlvbnNoaXBzIGF0IGFsbA0KPiBpZiB3ZSBjYW4ndCBlbnN1cmUgc3RhYmlsaXR5Lg0K DQpJIHRoaW5rIG91ciBkZWZpbml0aW9uIG9mICJzdGFiaWxpdHkiIGRpZmZlcnMuDQoNCj4gDQo+ IDgpIEkgZG8gbm90IHdhbnQgdG8gdW5kZXJtaW5lIHRoZSBzdGFuZGFyZCBtb3ZpbmcgZm9yd2Fy ZC4gSSBkbw0KPiB0aGluayB0aGlzDQo+IHBhcnRpY3VsYXIgaXNzdWUgaXMgYmFkIHBvbGljeSBh bmQgcHJlY2VkZW50LiBJIGFtIG5vdCBpbnRpbWF0ZWx5DQo+IGZhbWlsaWFyDQo+IHdpdGggdGhl IHdheSB0aGF0IElFVEYgdHJlYXRzIHRoZXNlIGRyYWZ0cyBhbmQgdGhlIGxhc3QgY2FsbA0KPiBw cm9jZXNzIGV0Yy4NCj4gV2hhdCBhcmUgdGhlIG9wdGlvbnMgaGVyZSBmb3IgYWRkcmVzc2luZyB0 aGlzIHdpdGhvdXQgZGVyYWlsaW5nIHRoZQ0KPiBzdGFuZGFyZD8NCg0KSXQgaXNuJ3QgYSBwcmVj ZWRlbnQsIHJlYWxseS4gSXQncyBvbmUgZW50cnkgKG91dCBvZiBsaXRlcmFsbHkgdGhvdXNhbmRz KSBpbiB0aGUgcmVnaXN0cnkuIFRoZXJlIGlzIGEgcHJvY2VzcyBmb3IgcmVnaXN0ZXJpbmcgaW5m b3JtYXRpb24gdGhhdCAqaXMqIHByZWNlZGVudCBzZXR0aW5nIGFuZCBydWxlcyBmb3Igd2hhdCBp cyBhbmQgaXMgbm90IHBlcm1pdHRlZC4gSSBoYXZlIGFscmVhZHkgcG9pbnRlZCBvdXQgdGhhdCB5 b3UgbWF5IHVzZSB0aGlzIHByb2Nlc3MgdG8gYWNoaWV2ZSB3aGF0IHlvdSB3YW50LiBXaGF0J3Mg aW4gNDY0NWJpcyBpcyBvbmx5IGEgdGVtcGxhdGUgZm9yIHRoZSBhY3R1YWwsIG9wZXJhdGluZyBy ZWdpc3RyeS4gT25jZSB0aGUgcmVnaXN0cnkgaXMgaW4gb3BlcmF0aW9uLCB5b3UgY2FuIGhhdmUg YSBQcmVmZXJyZWQtVmFsdWUgcmVxdWVzdCBmb3IgWVUgYW5kIHRoZXJlIHdpbGwgYmUgYSBjb25z ZW5zdXMgYW5kIGEgcmV2aWV3ZXIgZGVjaXNpb24gYW5kIGFsbCB0aGF0Lg0KDQpGcmFua2x5LCBJ IHRoaW5rIHRoYXQgdGhlIGRvb21zZGF5IHNjZW5hcmlvcyB5b3UgcGFpbnQgZm9yIHRoaXMgcmVj b3JkIGFyZSBhIGJpdCBhbGFybWlzdC4gQ291bnRyaWVzIGhhdmUgYW5kIHdpbGwgY29udGludWUg dG8gY2hhbmdlIGlkZW50aXR5LCBib3JkZXIsIGZvcm0sIGV0Yy4gYW5kIHRoaXMgd2lsbCBpbXBh Y3QgYW55IHRhZ2dpbmcgc2NoZW1lIHRoYXQgdXNlcyByZWdpb24gY29kZXMuIFRoZSBiZXN0IGxh bmd1YWdlIHRhZyBmb3IgU2VyYmlhbiBsYW5ndWFnZSBkb2N1bWVudHMgaXMgdmVyeSB1bmxpa2Vs eSB0byBiZSB0aGUgc2FtZSBhcyBpdCB3YXMgMTAgeWVhcnMgYWdvIGFuZCBpdCBtYXkgdmVyeSB3 ZWxsIGNoYW5nZSBhZ2FpbiBpbiB0aGUgZnV0dXJlLiBIb3dldmVyLCB0ZW4geWVhcnMgZnJvbSBu b3cgYWxsIG9mIHRoZSB0YWdzIHdpbGwgc3RpbGwgYmUgdmFsaWQgYW5kIGhhdmUgdGhlIHNhbWUg bWVhbmluZyB0aGF0IHRoZXkgaGFkLiBUaGF0IGlzIHN0YWJpbGl0eS4gV2hldGhlciB3ZSBjYW4g YXV0b21hdGljYWxseSBlcXVhdGUgdGFncyBzdWNoIGFzICJzaC1ZVSIgYW5kICJzci1SUyIgaXMg YSBzZXBhcmF0ZSBpc3N1ZSAoYW5kIHRoZXJlIGlzIGEgbG9uZyB0aHJlYWQgYWJvdXQgbGFuZ3Vh Z2UgZGVmYXVsdGluZyBhbmQgc3VjaCB0aGF0IGlzIHVzZWZ1bCByZWFkaW5nIG9uIHRoaXMgdmVy eSB0b3BpYykuDQoNCklmIHlvdSBoYXZlbid0IGFscmVhZHkgZG9uZSBzbywgSSdkIHVyZ2UgeW91 IHRvIHJlYWQgNDY0NmJpcyBhbmQgcGFydGljaXBhdGUgaW4gdGhlIExhc3QgQ2FsbCBhcyBuZWNl c3NhcnkuDQoNCkFkZGlzb24NCg0K From textexin@xencraft.com Tue Mar 3 15:03:37 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35BD3A68E4 for ; Tue, 3 Mar 2009 15:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCwQafd3Gdfy for ; Tue, 3 Mar 2009 15:03:36 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id A5B053A687A for ; Tue, 3 Mar 2009 15:03:36 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id NezU1b01B0x6nqcA5n45Rv; Tue, 03 Mar 2009 23:04:05 +0000 Received: from XENCRAFT ([76.126.218.47]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id Nn441b00811wtRY8Yn44Uz; Tue, 03 Mar 2009 23:04:04 +0000 From: "Tex Texin" To: "'Phillips, Addison'" , "'Randy Presuhn'" , References: <005e01c99b16$0b00d700$21028500$@com> <012801c99b60$c940c280$6801a8c0@oemcomputer> <002101c99c4b$0ace1cd0$206a5670$@com> <4D25F22093241741BC1D0EEBC2DBB1DA019E23A581@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019E23A581@EX-SEA5-D.ant.amazon.com> Date: Tue, 3 Mar 2009 15:04:02 -0800 Organization: XenCraft Message-ID: <003301c99c54$585aee70$0910cb50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmbbwOM+/sMmnVtRLemn6v98drl/AA1qfowAAFg7hAAAZa74A== Content-Language: en-us x-cr-hashedpuzzle: Dzo4 EJ6N GcEI IX0/ JVnF PSEZ QD0H RXwD TZ8/ UWMO VySx WN5E WO0O bf/Q bq74 ir3Q; 3; YQBkAGQAaQBzAG8AbgBAAGEAbQBhAHoAbwBuAC4AYwBvAG0AOwBsAHQAcgB1AEAAaQBlAHQAZgAuAG8AcgBnADsAcgBhAG4AZAB5AF8AcAByAGUAcwB1AGgAbgBAAG0AaQBuAGQAcwBwAHIAaQBuAGcALgBjAG8AbQA=; Sosha1_v1; 7; {6B158B8D-D9F3-48EA-A41A-B2DB30F4C8DF}; dABlAHgAdABlAHgAaQBuAEAAeABlAG4AYwByAGEAZgB0AC4AYwBvAG0A; Tue, 03 Mar 2009 23:03:53 GMT; UgBFADoAIABbAEwAdAByAHUAXQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBsAHQAcgB1AC0ANAA2ADQANQBiAGkAcwAtADEAMAAuAHQAeAB0ACAAaQBzAHMAdQBlACAAdwBpAHQAaAAJAHAAcgBlAGYAZQByAHIAZQBkAAkAdgBhAGwAdQBlAGYAbwByACAAWQBVAA== x-cr-puzzleid: {6B158B8D-D9F3-48EA-A41A-B2DB30F4C8DF} Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 23:03:37 -0000 Addison, 1) You say preferred-value is not equivalence. You then refer to it as = canonicalization. I am confused. How is it not an equivalence? If you mean that it is one directional (all dogs are mammals, all = mammals are not dogs) ok. For the purposes of things tagged -YU, -CS is = an equivalent. 2) Tags are not stable if one day CS is a valid substitute for YU and = the next day it is not. The meaning of CS has changed if there is an implied distinction between = the two. This is exactly what people are arguing. That YU and CS do not mean the = same things and therefore YU=3D> CS is incorrect. When the preferred value relationship is removed the meaning of CS is = changed. My point is that the meaning of the tags should be stable and this = change does not maintain the existing meaning. 3) I don't know how many implementations canonicalize. It is a bad idea = for standards to change based on "prevalent usage" unless it is known to = be close to 100%. Otherwise every change will be for the benefit of the = prevalent users, and over time every user gets damaged by one or another = change. Standards should protect the investment made in them. 4) I have read 4646bis and considered objecting to its current treatment = of preferred value. It does not offer a meaningful guideline for the = circumstances by which they can be changed, it just offers that they can = be modified. I was hoping that the discussion of YU would shed some = light on how these issues would be resolved in practice. I would prefer = not to go that route, but can do. -----Original Message----- From: Phillips, Addison [mailto:addison@amazon.com]=20 Sent: Tuesday, March 03, 2009 2:29 PM To: Tex Texin; 'Randy Presuhn'; ltru@ietf.org Subject: RE: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred = valuefor YU >=20 > 1) I agree the equivalence is faulty. However, it has been > established and > in existence for some time. > Correcting the error in the manner proposed does a greater damage. Please note that Preferred-Value is not equivalence. >=20 > 6) I agree YU=3D> CS is an unfortunate occurrence in the registry. I > disagree > we should fix it in the manner proposed. > It is one thing to optimize preferred values. It is another thing > entirely > to have them changing in a way that breaks or redefines existing > tags. You know... we have this process, documented in the RFC, for resolving = differences of opinion like this. It's called the registration process. = I actually think that having tags canonicalize to point to 'CS' (hey, = didn't that code used to be Czechoslovakia??) is less good than fixing = it. But that's my opinion. >=20 > 7) The registry was created to ensure language tag stability. If we > treat preferred values as proposed, we lose stability. Actually, we don't. The tags themselves remain stable and valid. = Canonicalization is never required. The most prevalent implementations = don't canonicalize today. > We would be better off without preferred value relationships at all > if we can't ensure stability. I think our definition of "stability" differs. >=20 > 8) I do not want to undermine the standard moving forward. I do > think this > particular issue is bad policy and precedent. I am not intimately > familiar > with the way that IETF treats these drafts and the last call > process etc. > What are the options here for addressing this without derailing the > standard? It isn't a precedent, really. It's one entry (out of literally = thousands) in the registry. There is a process for registering = information that *is* precedent setting and rules for what is and is not = permitted. I have already pointed out that you may use this process to = achieve what you want. What's in 4645bis is only a template for the = actual, operating registry. Once the registry is in operation, you can = have a Preferred-Value request for YU and there will be a consensus and = a reviewer decision and all that. Frankly, I think that the doomsday scenarios you paint for this record = are a bit alarmist. Countries have and will continue to change identity, = border, form, etc. and this will impact any tagging scheme that uses = region codes. The best language tag for Serbian language documents is = very unlikely to be the same as it was 10 years ago and it may very well = change again in the future. However, ten years from now all of the tags = will still be valid and have the same meaning that they had. That is = stability. Whether we can automatically equate tags such as "sh-YU" and = "sr-RS" is a separate issue (and there is a long thread about language = defaulting and such that is useful reading on this very topic). If you haven't already done so, I'd urge you to read 4646bis and = participate in the Last Call as necessary. Addison From randy_presuhn@mindspring.com Tue Mar 3 16:46:55 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3DB28C100 for ; Tue, 3 Mar 2009 16:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISBaWaFgP0yH for ; Tue, 3 Mar 2009 16:46:54 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 37D2F3A6A2A for ; Tue, 3 Mar 2009 16:46:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=M0CrKGkqmANFNGVnDgweIK4iUp8Fy2pcR/WrnObuY0hqPeV8tkRi9yugT2VDCdcN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.45] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LefGb-0005Kx-J1 for ltru@ietf.org; Tue, 03 Mar 2009 19:47:21 -0500 Message-ID: <00b501c99c62$e1e6d7e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <005e01c99b16$0b00d700$21028500$@com> <012801c99b60$c940c280$6801a8c0@oemcomputer> <002101c99c4b$0ace1cd0$206a5670$@com> Date: Tue, 3 Mar 2009 16:48:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173bcac27623ef17c54d5c8d8bb898807d3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.45 Subject: Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:46:55 -0000 Hi - > From: "Tex Texin" > To: "'Randy Presuhn'" ; > Sent: Tuesday, March 03, 2009 1:57 PM > Subject: RE: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU > > Randy, et al. > > 1) I agree the equivalence is faulty. However, it has been established and > in existence for some time. > Correcting the error in the manner proposed does a greater damage. As a technical contributor... To which corpora? Unless there is a substantial amount of data out there that has meaningful YU region subtags, this would seem to be mere arm-waving. > 2) If comments were a suitable solution, then it could be argued that adding > a comment to CS that despite it being a preferred value of YU it might not > be the best choice. At least then the equivalence would not be lost. As a technical contributor... An issue for ietf-languages@iana.org if someone files a registration update request. I would hope that such a discussion would be backed up by concrete data about the state of Serbian, Croatian, or other relevant languages. > 3) I agree with you and retract the statement that "there is no benefit" to > the proposed change. I instead claim the benefit does not outweigh the harm > caused. As a technical contributor... I would argue that there is no harm to eliminating the Preferred-Value, while retaining it causes incorrect results for data with tags including a YU region subtag where treating it as equivalent to a CS region subtag would be inappropriate. > 4) I am surprised by your remarks with respect to en vs en-US. Of course the > distinction could be significant. If I want to find documents about a > "jumper", en-US vs en-GB will be significant. Or if the count is a > "billion". The fact that it might not be relevant to the one paragraph you > wrote does not mean it is irrelevant in all other statements. As a technical contributor... The point is that there is abolutely no requirement whatsoever that all data should bear a region subtag. It's up to the party tagging the data to decide whether a region subtag would be useful for the purposes for which the data is being tagged. Consequently, once cannot use region subtags to find all data using the language variants associated with a particular region. Though that might be an interesting thing to do, language tags are not designed to support that application. > Frankly it doesn't make sense to argue that the regional subtag is not > significant, but it is different and important enough to warrant breaking > the equivalence. I'm not arguing that region subtags aren't meaningful or significant, I'm simply stating the fact that there is absolutely no guarantee that they will be present. > 5) The search query was an example to demonstrate the significance of > breaking the equivalence. The problem will show itself in other linguistic > applications where the differences are significant. Doesn't matter. If the tagger is applying coarser-grained "tag wisely" principles than the user, this kind of application will produce misleading results. > 6) I agree YU=> CS is an unfortunate occurrence in the registry. I disagree > we should fix it in the manner proposed. > It is one thing to optimize preferred values. It is another thing entirely > to have them changing in a way that breaks or redefines existing tags. What tags will be broken? What tags will be redefined? The only "redfinition" is if some hypothetical data bore a "YU" region subtag, removing the preferred-value prevents it from being incorrectly redefined in terms of "CS". > 7) The registry was created to ensure language tag stability. If we treat > preferred values as proposed, we lose stability. > We would be better off without preferred value relationships at all if we > can't ensure stability. As co-chair: this was debated at length in the WG. The current text reflects of the rough consensus of the WG. Keep in mind that the use of Preferred-Value is RECOMMENDED, not REQUIRED, so don't read too much into it. > 8) I do not want to undermine the standard moving forward. I do think this > particular issue is bad policy and precedent. I am not intimately familiar > with the way that IETF treats these drafts and the last call process etc. > What are the options here for addressing this without derailing the > standard? As co-chair: I see four possible paths: (1) Appeal the determination of WG consensus by the co-chairs on procedural grounds. I don't think this would get far, but if it succeeded, we'd end up re-opening the issues under (2). (2) Appeal the WG consensus on technical grounds. The underlying issues, if I understand your argument correctly, are that: (a) the Preferred-Value field mapping behaviour should be REQUIRED rather than merely recommended (b) the Preferred-Value field needs a replacement whose syntax and semantcs can cope with region splits and mergers (c) the results of applying a canoncalization algorithm must be stable over time Note that *all* of these questions have been discussed at length in the WG. A re-work, changing the WG consensus on all three of these points, would probably be lengthy. (3) Raise the issue during IETF last call. If the IETF consensus was that the WG got it wrong, we'd effectively travel the same path as (2). (4) Submit a subtag registration update request on ietf-languages@iana.org after IANA has updated the registry, and try to convince the language subtag reviewer that a preferred-value for YU should be added. Randy From mark.edward.davis@gmail.com Mon Mar 9 11:17:07 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54AA33A6835 for ; Mon, 9 Mar 2009 11:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXXmg9P+r4-T for ; Mon, 9 Mar 2009 11:17:06 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id BA1653A6B3A for ; Mon, 9 Mar 2009 11:17:04 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1256930ywh.49 for ; Mon, 09 Mar 2009 11:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=78ujXPHQNG3mgCfjwIeG09riRSrir3CDfwnXspddtZQ=; b=fbJT3UUnL3Gpi4lmedETrwPyD68G+npSSS04zS2mX3Ib80NK/+kKj0VBZpuOmI1qWv lGTlO8dD73eHbtuF/1fgYt5WfL06f37QSNFCyKw5fvLOc9/FjPo8y9WGHU9ANlOQ5Wbt fcYWbUcxhOPbWKGNg3cpk7WHmDxWZ/CxlMwQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=OTqQgFsvsNSy6p+g+FABH+F1SA5liH4Eas7S7TU6ikOEbr/sANwZT3EfjfkrsiXUY7 lcvYoBDPS7S5UlQum7nLCvOZuIiiCPgxLu3+XrRflBKe4SpzBpMLWRt7JZZdx6usKIW/ NHIwiEwrNTtLzm3SIbyBrtHZVcFkSdXBeIA+E= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.7.5 with SMTP id k5mr2651474wfi.176.1236622658082; Mon, 09 Mar 2009 11:17:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Mar 2009 11:17:38 -0700 X-Google-Sender-Auth: eb71b023cab5e806 Message-ID: <30b660a20903091117p1c06409doc2a62d1616b7aa76@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=001636e0a8844199980464b3a673 Cc: "ietf-languages@iana.org" , LTRU Working Group Subject: Re: [Ltru] Geocoordinates (was: Re: Proposal to remove Preferred-Value field for region YU in LTRU) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:17:07 -0000 --001636e0a8844199980464b3a673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See my message of April 12 2005 (was intended for April 1): "A Modest Proposal" http://www.ietf.org/mail-archive/web/ltru/current/msg01060.html Since it is obvious that all applications in the world will require extremely fine-grained approach to languages, here is an initial proposal for development of a separate RFC to deal with them. The goal is to be able to describe the variety of speech that each person on earth may be using at a given time. Identification is by means of the location of the speaker and the time at which the speech could have occurred. The language tag is given by the following format (formal ABNF to follow). XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time Latitude and longitude are specified by radians, and be measured from 0 to 360 starting at the Prime Meridian going east, and from 0 to 180 starting a= t the South Pole and going north. The numeric values below zero are avoided because the use of the terms "positive" and "negative" when applied to location can clearly be prejudicial to many of the peoples of the world. Should in the course of the development of this RFC, the use of the Prime Meridian be viewed as representative of an English-speaking hegemony, a random longitude will be chosen as the origin. Use of latitude and longitud= e does not, of course, imply in any way that those who believe in a flat eart= h or the "four-elephant+turtle system" are in any way discouraged in the observance of their faith, nor does the use of radians in any way denigrate the goal of the Kansas State Education Board to recognize the value of =CF= =80 as exactly 3.0. Altitude is in meters above the center of the earth. While some may feel th= e likelihood of two speakers being exactly overhead is low, we do -- of course -- want to plan for all eventualities. By avoiding measurement against sea level, we again celebrate the diversity of the world's population, and do not discriminate against the proud inhabitants of Death Valley and similar locations by in any way referring to them as "negative". For location, since people rarely overlap in physical space, it will usuall= y be sufficient to have accuracy to within 10 cm. But since fractions can be supplied, applications can have arbitrarily high degree of accuracy. The time is specified by seconds since 0000-01-00T00:00:00Z (using the proleptic Gregorian calendar as specified in XML Schema), plus an offset of 1,000,000,000,000,000,000. If finer granularity than seconds is desired, then fractions can be specified. The reason for the offset is to again avoi= d negative numbers, and their implied bias against historic inhabitants. The offset is chosen as to be well before all current estimates of the Big Bang= . Note, however, that this in no way implies any denigration of creationism, or that believers are in any way discouraged in the observance of their faith. Nor does it imply that any one system of creationism, such as Greek or Norse creation theory, is any way inferior to any other, such as that espoused by the Kansas State Education Board. Other parts of this proposal, such as security implications, will be forthcoming. =E2=80=8EMark --001636e0a8844199980464b3a673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See my message of April 12 2005 (was intended for April 1): "A Modest = Proposal"

http://www.ietf.org/mail-archive/web/ltru/current/ms= g01060.html

Since it is obvious that all applicat= ions in the world will require
extremely fine-grained approach to langua= ges, here is an initial proposal
for development of a separate RFC to de= al with them. The goal is to be able
to describe the variety of speech that each person on earth may be using at=
a given time. Identification is by means of the location of the speaker= and
the time at which the speech could have occurred. The language tag = is given
by the following format (formal ABNF to follow).

XLanguageTag ::=3D = latitude "-" longitude "-" altitude "-" time<= br>
Latitude and longitude are specified by radians, and be measured fro= m 0 to
360 starting at the Prime Meridian going east, and from 0 to 180 starting a= t
the South Pole and going north. The numeric values below zero are avoi= ded
because the use of the terms "positive" and "negative= " when applied to
location can clearly be prejudicial to many of the peoples of the world.Should in the course of the development of this RFC, the use of the Prime<= br>Meridian be viewed as representative of an English-speaking hegemony, a<= br> random longitude will be chosen as the origin. Use of latitude and longitud= e
does not, of course, imply in any way that those who believe in a flat= earth
or the "four-elephant+turtle system" are in any way dis= couraged in the
observance of their faith, nor does the use of radians in any way denigrate=
the goal of the Kansas State Education Board to recognize the value of = =CF=80 as
exactly 3.0.

Altitude is in meters above the center of = the earth. While some may feel the
likelihood of two speakers being exactly overhead is low, we do -- of
co= urse -- want to plan for all eventualities. By avoiding measurement
agai= nst sea level, we again celebrate the diversity of the world's
popul= ation, and do not discriminate against the proud inhabitants of Death
Valley and similar locations by in any way referring to them as "negat= ive".

For location, since people rarely overlap in physical spa= ce, it will usually
be sufficient to have accuracy to within 10 cm. But = since fractions can be
supplied, applications can have arbitrarily high degree of accuracy.
The time is specified by seconds since 0000-01-00T00:00:00Z (using the
= proleptic Gregorian calendar as specified in XML Schema), plus an offset of=
1,000,000,000,000,000,000. If finer granularity than seconds is desired,then fractions can be specified. The reason for the offset is to again avo= id
negative numbers, and their implied bias against historic inhabitants= . The
offset is chosen as to be well before all current estimates of the Big Bang= .
Note, however, that this in no way implies any denigration of creation= ism,
or that believers are in any way discouraged in the observance of t= heir
faith. Nor does it imply that any one system of creationism, such as Greek<= br>or Norse creation theory, is any way inferior to any other, such as that=
espoused by the Kansas State Education Board.

Other parts of thi= s proposal, such as security implications, will be
forthcoming.

=E2=80=8EMark

--001636e0a8844199980464b3a673-- From randy_presuhn@mindspring.com Mon Mar 9 13:22:27 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09633A69CF for ; Mon, 9 Mar 2009 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=-2.255, BAYES_50=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGnOZeLVPYXG for ; Mon, 9 Mar 2009 13:22:27 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 2525E3A67B2 for ; Mon, 9 Mar 2009 13:22:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pyqWzJabhfW6O1Ll3c1o/q0LtF5P6WMotxUXzdnt+52lS8aiWxXISB6DaVrNrgvJ; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.72] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lgm05-0001Pf-4h for ltru@ietf.org; Mon, 09 Mar 2009 16:23:01 -0400 Message-ID: <000701c9a0f4$f4d601a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 9 Mar 2009 13:23:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1739223ea85c2fb449772dc9751072f2401350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.72 Subject: [Ltru] document status X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:22:27 -0000 Hi - Links for following the status of our drafts as they procede toward publication: https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4645bis/ https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ Randy From mark.edward.davis@gmail.com Mon Mar 9 14:25:32 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1761E3A6CD6 for ; Mon, 9 Mar 2009 14:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJlu3gISoZ4o for ; Mon, 9 Mar 2009 14:25:22 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 06CC83A6970 for ; Mon, 9 Mar 2009 14:25:16 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id b2so1039611ana.4 for ; Mon, 09 Mar 2009 14:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=KvXKVCK0GbN/zdlySVDp1g4uO93r+iB16lYCi05COnk=; b=SiucKx8FwrJTAYZz1ZjIQ462ekeejePGwfsxy4Rx9hcMgSOMjwvGqFfDcsO9QlpmNW 0jOGfBsjPdhYrk8iCEBZ/ng43I/i6UMEo241WbCnpKLbBLHW96cysukyA8olvioKK4fJ Ihk+xGE1+F3JIE2OZFqInR5FQ/1/mS01bKzXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=eYwzgfpw9Hp12F313W6zcHBG8SacNFUe/V8rY7ZikFxatYp93yhKgnhrsesfY4pWsu Uz2t0FwVAOQ9BCOhpN9NQzxUugdSKG7wTDvz/f+14zO04FpYfqte127jTHk2Yn5NEqoB rFddKnr1WvgrvwMt2tWovwrCzeQCK+Rs9xW8I= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.28.8 with SMTP id f8mr2716085wfj.204.1236633950421; Mon, 09 Mar 2009 14:25:50 -0700 (PDT) In-Reply-To: <000701c9a0f4$f4d601a0$6801a8c0@oemcomputer> References: <000701c9a0f4$f4d601a0$6801a8c0@oemcomputer> Date: Mon, 9 Mar 2009 14:25:50 -0700 X-Google-Sender-Auth: b184b2d0212bca36 Message-ID: <30b660a20903091425y7a1007a8gcb3f845c43fd23a6@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=001636e90cdd5501ee0464b647bd Cc: LTRU Working Group Subject: Re: [Ltru] document status X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:25:32 -0000 --001636e90cdd5501ee0464b647bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks Mark On Mon, Mar 9, 2009 at 13:23, Randy Presuhn wrote: > Hi - > > Links for following the status of our drafts as they procede > toward publication: > https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4645bis/ > https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/ > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e90cdd5501ee0464b647bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks

Mark


On Mon, Mar 9, 2009 at 13:23, Randy Pres= uhn <r= andy_presuhn@mindspring.com> wrote:
Hi -

Links for following the status of our drafts as they procede
toward publication:
https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4= 645bis/
https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4= 646bis/

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636e90cdd5501ee0464b647bd-- From bortzmeyer@nic.fr Tue Mar 10 02:30:54 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769703A68F9 for ; Tue, 10 Mar 2009 02:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHq-tcBzgbjO for ; Tue, 10 Mar 2009 02:30:53 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id EF5303A672F for ; Tue, 10 Mar 2009 02:30:52 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 492781C00F4; Tue, 10 Mar 2009 10:31:27 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 4383D1C00F0; Tue, 10 Mar 2009 10:31:27 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 37563A1D97F; Tue, 10 Mar 2009 10:31:27 +0100 (CET) Date: Tue, 10 Mar 2009 10:31:27 +0100 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20090310093127.GB2850@nic.fr> References: <30b660a20903091117p1c06409doc2a62d1616b7aa76@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20903091117p1c06409doc2a62d1616b7aa76@mail.gmail.com> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates (was: Re: Proposal to remove Preferred-Value field for region YU in LTRU) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:30:54 -0000 On Mon, Mar 09, 2009 at 11:17:38AM -0700, Mark Davis wrote a message of 149 lines which said: > Since it is obvious that all applications in the world will require > extremely fine-grained approach to languages, here is an initial > proposal for development of a separate RFC to deal with them. I fully support this proposal. > Other parts of this proposal, such as security implications, will be > forthcoming. I'm too impatient to read them! From randy_presuhn@mindspring.com Tue Mar 10 11:09:06 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB0A3A6407 for ; Tue, 10 Mar 2009 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4gV+f52a5v0 for ; Tue, 10 Mar 2009 11:09:05 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 3CF483A6A34 for ; Tue, 10 Mar 2009 11:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ErBKN7N4YnFnEe21jFQvvko9gyx8YF9CNywA9SwgAz6uOYTDXxTdskqkvXXE1aAe; 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 [69.3.146.199] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lh6Oa-0006Hi-Ff for ltru@ietf.org; Tue, 10 Mar 2009 14:09:40 -0400 Message-ID: <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20903091117p1c06409doc2a62d1616b7aa76@mail.gmail.com> <20090310093127.GB2850@nic.fr> Date: Tue, 10 Mar 2009 11:10:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1735da861fb9c516633ec25d69dacac5751350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.199 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:09:06 -0000 Hi - As co-chair... If you wish, you may include this as part of a proposal to re-charter this working group. However, I currently plan to recommend closing the working group when its current deliverables are published. As a technical contributor... I've observed that accent can vary according to the number of beers consumed. Perhaps another subtag should be designed to indicate the speaker's level of intoxication. Or can we just use the altitude parameter to indicate how high they are? :-) Randy > From: "Stephane Bortzmeyer" > To: "Mark Davis" > Cc: "LTRU Working Group" > Sent: Tuesday, March 10, 2009 2:31 AM > Subject: Re: [Ltru] Geocoordinates (was: Re: Proposal to removePreferred-Value field for region YU in LTRU) > > On Mon, Mar 09, 2009 at 11:17:38AM -0700, > Mark Davis wrote > a message of 149 lines which said: > > > Since it is obvious that all applications in the world will require > > extremely fine-grained approach to languages, here is an initial > > proposal for development of a separate RFC to deal with them. > > I fully support this proposal. > > > Other parts of this proposal, such as security implications, will be > > forthcoming. > > I'm too impatient to read them! > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru From cowan@ccil.org Tue Mar 10 11:45:28 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75AD3A684C for ; Tue, 10 Mar 2009 11:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ickrdBMN0ZIJ for ; Tue, 10 Mar 2009 11:45:27 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id CF7093A6407 for ; Tue, 10 Mar 2009 11:45:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Lh6xm-00023u-8v; Tue, 10 Mar 2009 14:46:02 -0400 Date: Tue, 10 Mar 2009 14:46:02 -0400 To: Randy Presuhn Message-ID: <20090310184601.GD7167@mercury.ccil.org> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:45:28 -0000 Randy Presuhn scripsit: > If you wish, you may include this as part of a proposal to re-charter > this working group. However, I currently plan to recommend closing > the working group when its current deliverables are published. What about the variant and (genetic) collection codes from ISO 639-6? That standard is at FDIS stage, and while we certainly shouldn't hold 4646bis on it, it seems to contain material for a 4646ter. -- John Cowan http://ccil.org/~cowan cowan@ccil.org The Penguin shall hunt and devour all that is crufty, gnarly and bogacious; all code which wriggles like spaghetti, or is infested with blighting creatures, or is bound by grave and perilous Licences shall it capture. And in capturing shall it replicate, and in replicating shall it document, and in documentation shall it bring freedom, serenity and most cool froodiness to the earth and all who code therein. --Gospel of Tux From addison@amazon.com Tue Mar 10 11:52:39 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703C43A6A47 for ; Tue, 10 Mar 2009 11:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaqK6u093rGb for ; Tue, 10 Mar 2009 11:52:38 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 51FB03A6A34 for ; Tue, 10 Mar 2009 11:52:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="154066900" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 18:53:12 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id n2AIrBP7021328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 10 Mar 2009 18:53:11 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Tue, 10 Mar 2009 11:53:09 -0700 From: "Phillips, Addison" To: John Cowan , Randy Presuhn Date: Tue, 10 Mar 2009 11:53:08 -0700 Thread-Topic: [Ltru] Geocoordinates Thread-Index: AcmhsHmXMUVZ9P/9ToKsileBYuUzSwAAFjdw Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> In-Reply-To: <20090310184601.GD7167@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:52:39 -0000 SSBoYXZlbid0IGZvbGxvd2VkIElTTyA2MzktNiBzaW5jZSB0aGVyZSB3ZXJlIChwcmVtYXR1cmU/ KSBhbm5vdW5jZW1lbnRzIG9mIGl0cyBwb3NzaWJsZSBkZW1pc2UuIEl0IG1pZ2h0IG1ha2UgYSBz dWl0YWJsZSBleHRlbnNpb24gKGluIHdoaWNoIGNhc2Ugbm8gV0cgaXMgbmVlZGVkKS4gT3IsIHdo ZW4gaXQgaXMgbWF0dXJlLCBjb3VsZG4ndCB3ZSBqdXN0IGNyZWF0ZSBhIG5ldyBpbnN0YW5jZSBv ZiBMVFJVIHdpdGggYSBuZXcgY2hhcnRlciBhdCB0aGF0IHRpbWU/IA0KDQpBZGRpc29uDQoNCkFk ZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJbnRl cm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJl Lg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2Yg Sm9obiBDb3dhbg0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAxMCwgMjAwOSAxMTo0NiBBTQ0KPiBU bzogUmFuZHkgUHJlc3Vobg0KPiBDYzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJl OiBbTHRydV0gR2VvY29vcmRpbmF0ZXMNCj4gDQo+IFJhbmR5IFByZXN1aG4gc2NyaXBzaXQ6DQo+ IA0KPiA+IElmIHlvdSB3aXNoLCB5b3UgbWF5IGluY2x1ZGUgdGhpcyBhcyBwYXJ0IG9mIGEgcHJv cG9zYWwgdG8gcmUtDQo+IGNoYXJ0ZXINCj4gPiB0aGlzIHdvcmtpbmcgZ3JvdXAuICBIb3dldmVy LCBJIGN1cnJlbnRseSBwbGFuIHRvIHJlY29tbWVuZA0KPiBjbG9zaW5nDQo+ID4gdGhlIHdvcmtp bmcgZ3JvdXAgd2hlbiBpdHMgY3VycmVudCBkZWxpdmVyYWJsZXMgYXJlIHB1Ymxpc2hlZC4NCj4g DQo+IFdoYXQgYWJvdXQgdGhlIHZhcmlhbnQgYW5kIChnZW5ldGljKSBjb2xsZWN0aW9uIGNvZGVz IGZyb20gSVNPIDYzOS0NCj4gNj8NCj4gVGhhdCBzdGFuZGFyZCBpcyBhdCBGRElTIHN0YWdlLCBh bmQgd2hpbGUgd2UgY2VydGFpbmx5IHNob3VsZG4ndA0KPiBob2xkDQo+IDQ2NDZiaXMgb24gaXQs IGl0IHNlZW1zIHRvIGNvbnRhaW4gbWF0ZXJpYWwgZm9yIGEgNDY0NnRlci4NCj4gDQo+IC0tDQo+ IEpvaG4gQ293YW4gICAgaHR0cDovL2NjaWwub3JnL35jb3dhbiAgY293YW5AY2NpbC5vcmcNCj4g VGhlIFBlbmd1aW4gc2hhbGwgaHVudCBhbmQgZGV2b3VyIGFsbCB0aGF0IGlzIGNydWZ0eSwgZ25h cmx5IGFuZA0KPiBib2dhY2lvdXM7IGFsbCBjb2RlIHdoaWNoIHdyaWdnbGVzIGxpa2Ugc3BhZ2hl dHRpLCBvciBpcyBpbmZlc3RlZA0KPiB3aXRoDQo+IGJsaWdodGluZyBjcmVhdHVyZXMsIG9yIGlz IGJvdW5kIGJ5IGdyYXZlIGFuZCBwZXJpbG91cyBMaWNlbmNlcw0KPiBzaGFsbCBpdA0KPiBjYXB0 dXJlLiAgQW5kIGluIGNhcHR1cmluZyBzaGFsbCBpdCByZXBsaWNhdGUsIGFuZCBpbiByZXBsaWNh dGluZw0KPiBzaGFsbA0KPiBpdCBkb2N1bWVudCwgYW5kIGluIGRvY3VtZW50YXRpb24gc2hhbGwg aXQgYnJpbmcgZnJlZWRvbSwgc2VyZW5pdHkNCj4gYW5kDQo+IG1vc3QgY29vbCBmcm9vZGluZXNz IHRvIHRoZSBlYXJ0aCBhbmQgYWxsIHdobyBjb2RlIHRoZXJlaW4uICAtLQ0KPiBHb3NwZWwgb2Yg VHV4DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= From cowan@ccil.org Tue Mar 10 13:03:25 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5CF3A6B1D for ; Tue, 10 Mar 2009 13:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmw+WZmYhwS1 for ; Tue, 10 Mar 2009 13:03:24 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 24D583A67DD for ; Tue, 10 Mar 2009 13:03:24 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Lh8B8-00022W-HY; Tue, 10 Mar 2009 16:03:54 -0400 Date: Tue, 10 Mar 2009 16:03:54 -0400 To: "Phillips, Addison" Message-ID: <20090310200354.GE7167@mercury.ccil.org> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:03:25 -0000 Phillips, Addison scripsit: > I haven't followed ISO 639-6 since there were (premature?) announcements > of its possible demise. It might make a suitable extension (in which > case no WG is needed). Or, when it is mature, couldn't we just create > a new instance of LTRU with a new charter at that time? I don't know if that's more or less expensive (in people time, mostly) than letting LTRU go dormant and then revivifying it. FWIU, 639-6 codes form a Big Tree, from "all languages" at the top down through genetic groups, languages, and variants of all sorts (including script variants). The codes for languages are harmonized with 639-3's, so they're already in; the codes for groups are or will be harmonized with 639-5's. So what's left is: (a) codes for language collections that aren't in 639-5, which could be added to BCP 47 as 4-letter primary language subtags (that size is currently reserved); (b) codes for variants other than script and national variants, which could be added to BCP 47 as 5-character variant subtags by adding a 5th character (I propose prefixing '6'). Of course the Registry would become bigger than ever, and some of He Who Must Not Be Named's concerns would actually become realities, like whether authorized mirrors would be needed to hold down on the number of downloads. On the other hand, we could pretty well shut down ietf-languages@, since there would be little or nothing left to approve outside the 639 framework. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler From addison@amazon.com Tue Mar 10 13:30:33 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A8028C152 for ; Tue, 10 Mar 2009 13:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.576 X-Spam-Level: X-Spam-Status: No, score=-107.576 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIFogC+akhQa for ; Tue, 10 Mar 2009 13:30:27 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id C10AF3A680A for ; Tue, 10 Mar 2009 13:30:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="154119849" Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 20:31:01 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n2AKV0Gh006865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 10 Mar 2009 20:31:00 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Tue, 10 Mar 2009 13:31:00 -0700 From: "Phillips, Addison" To: John Cowan Date: Tue, 10 Mar 2009 13:30:58 -0700 Thread-Topic: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates] Thread-Index: Acmhu1o4KfBUKhbxQ9yT3dOd44BIYAAAI2zA Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.amazon.com> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> In-Reply-To: <20090310200354.GE7167@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:30:33 -0000 PiBPbiB0aGUgb3RoZXIgaGFuZCwgd2UgY291bGQgcHJldHR5IHdlbGwgc2h1dA0KPiBkb3duIGll dGYtbGFuZ3VhZ2VzQCwgc2luY2UgdGhlcmUgd291bGQgYmUgbGl0dGxlIG9yIG5vdGhpbmcgbGVm dCB0bw0KPiBhcHByb3ZlIG91dHNpZGUgdGhlIDYzOSBmcmFtZXdvcmsuDQoNCi4uLiBhc3N1bWlu ZyB0aGF0IHRoZXJlIGlzIG9ubHkgb25lIHdheSB0byBjbGFzc2lmeSBsYW5ndWFnZXMgbWVldGlu ZyB0aGUgbmVlZHMgb2YgYWxsIGF1ZGllbmNlcy4gOi0pDQoNCkknbSBzdXJlIHRoYXQgc29tZSBh dWRpZW5jZXMgd2lsbCBmaW5kIHZhbHVlIGluIDYzOS02IGFuZCB0aGF0IGluY29ycG9yYXRpbmcg dGhlIDYzOS02IGNvZGVzIGludG8gQkNQIDQ3IG1heSBoYXZlIHNvbWUgbWVyaXQtLWp1c3QgaGFz IHRoZSB2YXJpb3VzIGNoYW5nZXMgd2UndmUgd3JvdWdodCBoYXZlIHZhbHVlLiBJbiBmYWN0LCBz b21lIHBlb3BsZSBoYXZlIHNhaWQgaXQgaGFzIG1lcml0IG9uIHRoaXMgbGlzdCwgc28gdGhhdCdz IGhhcmRseSBzcGVjdWxhdGlvbi4NCg0KUGVyc29uYWxseSwgSSBkb24ndCBzZWUgaW5jb3Jwb3Jh dGluZyBvdGhlciBjb2xsZWN0aW9ucyBhcyBhIGhpZ2ggcHJpb3JpdHk6IHRoZSBvbmVzIHdlIGhh dmUgYXJlIG1vcmUgZm9yIGNvbXBsZXRlbmVzcyB0aGFuIGFjdHVhbCB1dGlsaXR5LiBUaGUgb3Ro ZXIgdmFyaWFudHMgbWlnaHQgYmUgYWRkcmVzc2VkIGJ5IHBlcm1pdHRpbmcgInJhbmRvbSIgcmVn aXN0cmF0aW9uIGFuZCByZXF1aXJpbmcgYSByZWZlcmVuY2UgZmllbGQgaW4gdGhlIHJlZ2lzdHJ5 IGZvciB0aGUgSVNPIDYzOS02IGNvZGUgdGhhdCBjb3JyZXNwb25kcyAoYWxsb3dpbmcgYSBjcmVl cGluZyBtbmVtb25pY2l0eSB0byBkZXZlbG9wKS4gRm9yIHRoYXQgbWF0dGVyLCBpZiB0aGV5J3Jl IGdvaW5nIHRvIGJlIHZhcmlhbnRzIGFueXdheSwgYW4gZXh0ZW5zaW9uICgtNi0gc2VlbXMgbGlr ZSBhbiBhcHByb3ByaWF0ZSBzaW5nbGV0b24pIHNlZW1zIGxpa2UgYSBwcmFjdGljYWwgc29sdXRp b24gd2l0aCBzb21lIGJlbmVmaXRzIHRvIHJlY29tbWVuZCBpdC4NCg0KQnV0IEkgc3BlY3VsYXRl IHJlY2tsZXNzbHkuIFNpbmNlIGl0IHNlZW1zIHByZXR0eSBlYXN5IHRvIGNyZWF0ZSBhbiBJRVRG IFdHLCBJIGd1ZXNzIHRoZSByZWFsIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNoYWlycywgQUQs IGFuZCBzdWNoIHdvdWxkIHdhbnQgdG8gbWFpbnRhaW4gYSBtb3JpYnVuZCBncm91cCBmb3IgYSB5 ZWFyIG9yIHNvIHdoaWxlIHRoaXMgc3RhbmRhcmQgYmFrZXMgaW5zdGVhZCBvZiBqdXN0IGNyZWF0 aW5nIGEgbmV3IG9uZSBhdCB0aGUgYXBwcm9wcmlhdGUganVuY3R1cmUuIE9yIGl0IDYzOS02IHRo YXQgY2xvc2U/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBB cmNoaXRlY3QgLS0gTGFiMTI2DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1 cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBKb2huIENvd2FuIFttYWlsdG86Y293YW5AY2NpbC5vcmddDQo+IFNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDA5IDE6MDQgUE0NCj4gVG86IFBoaWxsaXBzLCBBZGRpc29u DQo+IENjOiBKb2huIENvd2FuOyBSYW5keSBQcmVzdWhuOyBMVFJVIFdvcmtpbmcgR3JvdXANCj4g U3ViamVjdDogUmU6IFtMdHJ1XSBHZW9jb29yZGluYXRlcw0KPiANCj4gUGhpbGxpcHMsIEFkZGlz b24gc2NyaXBzaXQ6DQo+IA0KPiA+IEkgaGF2ZW4ndCBmb2xsb3dlZCBJU08gNjM5LTYgc2luY2Ug dGhlcmUgd2VyZSAocHJlbWF0dXJlPykNCj4gYW5ub3VuY2VtZW50cw0KPiA+IG9mIGl0cyBwb3Nz aWJsZSBkZW1pc2UuIEl0IG1pZ2h0IG1ha2UgYSBzdWl0YWJsZSBleHRlbnNpb24gKGluDQo+IHdo aWNoDQo+ID4gY2FzZSBubyBXRyBpcyBuZWVkZWQpLiBPciwgd2hlbiBpdCBpcyBtYXR1cmUsIGNv dWxkbid0IHdlIGp1c3QNCj4gY3JlYXRlDQo+ID4gYSBuZXcgaW5zdGFuY2Ugb2YgTFRSVSB3aXRo IGEgbmV3IGNoYXJ0ZXIgYXQgdGhhdCB0aW1lPw0KPiANCj4gSSBkb24ndCBrbm93IGlmIHRoYXQn cyBtb3JlIG9yIGxlc3MgZXhwZW5zaXZlIChpbiBwZW9wbGUgdGltZSwNCj4gbW9zdGx5KQ0KPiB0 aGFuIGxldHRpbmcgTFRSVSBnbyBkb3JtYW50IGFuZCB0aGVuIHJldml2aWZ5aW5nIGl0Lg0KPiAN Cj4gRldJVSwgNjM5LTYgY29kZXMgZm9ybSBhIEJpZyBUcmVlLCBmcm9tICJhbGwgbGFuZ3VhZ2Vz IiBhdCB0aGUgdG9wDQo+IGRvd24NCj4gdGhyb3VnaCBnZW5ldGljIGdyb3VwcywgbGFuZ3VhZ2Vz LCBhbmQgdmFyaWFudHMgb2YgYWxsIHNvcnRzDQo+IChpbmNsdWRpbmcNCj4gc2NyaXB0IHZhcmlh bnRzKS4gIFRoZSBjb2RlcyBmb3IgbGFuZ3VhZ2VzIGFyZSBoYXJtb25pemVkIHdpdGggNjM5LQ0K PiAzJ3MsDQo+IHNvIHRoZXkncmUgYWxyZWFkeSBpbjsgdGhlIGNvZGVzIGZvciBncm91cHMgYXJl IG9yIHdpbGwgYmUNCj4gaGFybW9uaXplZA0KPiB3aXRoIDYzOS01J3MuICBTbyB3aGF0J3MgbGVm dCBpczoNCj4gDQo+IChhKSBjb2RlcyBmb3IgbGFuZ3VhZ2UgY29sbGVjdGlvbnMgdGhhdCBhcmVu J3QgaW4gNjM5LTUsIHdoaWNoDQo+IGNvdWxkDQo+IGJlIGFkZGVkIHRvIEJDUCA0NyBhcyA0LWxl dHRlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgKHRoYXQgc2l6ZQ0KPiBpcw0KPiBjdXJyZW50 bHkgcmVzZXJ2ZWQpOw0KPiANCj4gKGIpIGNvZGVzIGZvciB2YXJpYW50cyBvdGhlciB0aGFuIHNj cmlwdCBhbmQgbmF0aW9uYWwgdmFyaWFudHMsDQo+IHdoaWNoDQo+IGNvdWxkIGJlIGFkZGVkIHRv IEJDUCA0NyBhcyA1LWNoYXJhY3RlciB2YXJpYW50IHN1YnRhZ3MgYnkgYWRkaW5nIGENCj4gNXRo DQo+IGNoYXJhY3RlciAoSSBwcm9wb3NlIHByZWZpeGluZyAnNicpLg0KPiANCj4gT2YgY291cnNl IHRoZSBSZWdpc3RyeSB3b3VsZCBiZWNvbWUgYmlnZ2VyIHRoYW4gZXZlciwgYW5kIHNvbWUgb2YN Cj4gSGUgV2hvIE11c3QgTm90IEJlIE5hbWVkJ3MgY29uY2VybnMgd291bGQgYWN0dWFsbHkgYmVj b21lIHJlYWxpdGllcywNCj4gbGlrZSB3aGV0aGVyIGF1dGhvcml6ZWQgbWlycm9ycyB3b3VsZCBi ZSBuZWVkZWQgdG8gaG9sZCBkb3duIG9uIHRoZQ0KPiBudW1iZXIgb2YgZG93bmxvYWRzLiAgT24g dGhlIG90aGVyIGhhbmQsIHdlIGNvdWxkIHByZXR0eSB3ZWxsIHNodXQNCj4gZG93bg0KPiBpZXRm LWxhbmd1YWdlc0AsIHNpbmNlIHRoZXJlIHdvdWxkIGJlIGxpdHRsZSBvciBub3RoaW5nIGxlZnQg dG8NCj4gYXBwcm92ZQ0KPiBvdXRzaWRlIHRoZSA2MzkgZnJhbWV3b3JrLg0KPiANCj4gLS0NCj4g RXZlbiBhIHJlZnJpZ2VyYXRvciBjYW4gY29uZm9ybSB0byB0aGUgWE1MICAgICAgSm9obiBDb3dh bg0KPiBJbmZvc2V0LCBhcyBsb25nIGFzIGl0IGhhcyBhIGRvb3Igc3RpY2tlciAgICAgICBjb3dh bkBjY2lsLm9yZw0KPiBzYXlpbmcgIk5vIGluZm9ybWF0aW9uIGl0ZW1zIGluc2lkZSIuDQo+IGh0 dHA6Ly93d3cuY2NpbC5vcmcvfmNvd2FuDQo+ICAgICAgICAgLS1FdmUgTWFsZXINCg== From cowan@ccil.org Tue Mar 10 13:36:50 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E7E3A6B53 for ; Tue, 10 Mar 2009 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8W1rqppxkYu for ; Tue, 10 Mar 2009 13:36:49 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 4BD273A6B31 for ; Tue, 10 Mar 2009 13:36:49 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Lh8hR-0005LM-Bs; Tue, 10 Mar 2009 16:37:17 -0400 Date: Tue, 10 Mar 2009 16:37:17 -0400 To: "Phillips, Addison" Message-ID: <20090310203717.GF7167@mercury.ccil.org> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.amazon.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:36:50 -0000 Phillips, Addison scripsit: > For that matter, if they're going to be variants anyway, an extension > (-6- seems like an appropriate singleton) seems like a practical > solution with some benefits to recommend it. I wasn't proposing a singleton, but a convention: variant code abcd would come into BCP 47 as variant subtag 6abcd, to avoid confusing it with script subtags. > But I speculate recklessly. Since it seems pretty easy to create an > IETF WG, I guess the real question is whether the chairs, AD, and such > would want to maintain a moribund group for a year or so while this > standard bakes instead of just creating a new one at the appropriate > juncture. Or it 639-6 that close? IIRC, it's in FDIS (Final Draft International Standard) state, so about as close as we are. -- Normally I can handle panic attacks on my own; John Cowan but panic is, at the moment, a way of life. http://www.ccil.org/~cowan From randy_presuhn@mindspring.com Tue Mar 10 15:45:12 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB743A698D for ; Tue, 10 Mar 2009 15:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fWMyjJ8Ey9W for ; Tue, 10 Mar 2009 15:45:11 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 5649F3A676A for ; Tue, 10 Mar 2009 15:45:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qpJpP36IpQ/0Kn1x4zmqDgEB0BrBKgXZszudBf4MtBGDhq5WMwSBD5dM0NNiTKuf; 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 [69.3.146.199] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LhAhj-0005xZ-9P for ltru@ietf.org; Tue, 10 Mar 2009 18:45:43 -0400 Message-ID: <001401c9a1d2$1076e040$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.amazon.com> <20090310203717.GF7167@mercury.ccil.org> Date: Tue, 10 Mar 2009 15:46:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1738883d2b4a9f7db707fdb8dc0e47a16bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.199 Subject: Re: [Ltru] ISO 639-6 and LTRU continuation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:45:12 -0000 Hi - > From: "John Cowan" > To: "Phillips, Addison" > Cc: "John Cowan" ; "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, March 10, 2009 1:37 PM > Subject: Re: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates] ... > > But I speculate recklessly. Since it seems pretty easy to create an > > IETF WG, I guess the real question is whether the chairs, AD, and such > > would want to maintain a moribund group for a year or so while this > > standard bakes instead of just creating a new one at the appropriate > > juncture. Or it 639-6 that close? > > IIRC, it's in FDIS (Final Draft International Standard) state, so about > as close as we are. ... As a technical contributor... Truly supporting the concept of collections would require some serious work on an update to RFC 4647, among other things. I think we'd want to see some serious use cases and requirements from the protocol community before rechartering / spinning up a new WG. How would these be employed in existing IETF protocols? Do any new protocol proposals require this facility? I would not support the idea of keeping a WG around until we figured out how we were going to use such things. As co-chair... Those interested in pursuring further work should prepare a charter update (with clearly identified deliverables and dates) for discussion. Expect to be asked whether we're past the point of diminishing returns. Iff there is (rough) consensus in support of that proposal, we can ask our AD to take it to the IESG. If not, we'll wrap up the WG after our current deliverables are published as RFCs, probably with a recommendation to leave the mailing list active. Randy From petercon@microsoft.com Tue Mar 10 20:36:15 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2FA3A69CE for ; Tue, 10 Mar 2009 20:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY7Fo2-+LXsJ for ; Tue, 10 Mar 2009 20:36:14 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D55C93A6833 for ; Tue, 10 Mar 2009 20:36:14 -0700 (PDT) Received: from tk5-exmlt-c101.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 10 Mar 2009 20:36:40 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exmlt-c101.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Tue, 10 Mar 2009 20:36:40 -0700 From: Peter Constable To: John Cowan , "Phillips, Addison" Date: Tue, 10 Mar 2009 20:36:38 -0700 Thread-Topic: [Ltru] Geocoordinates Thread-Index: Acmhu2larMjyRZikSKCoPGIIoKqG0wAPq4ow Message-ID: References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> In-Reply-To: <20090310200354.GE7167@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:36:15 -0000 From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Joh= n Cowan > So what's left is: > > (a) codes for language collections that aren't in 639-5, which could > be added to BCP 47 as 4-letter primary language subtags (that size is > currently reserved); I'd be resistant to 4-letter primary language subtags. I have made derivati= ve use of BCP 47 tag syntax with the modification that the only obligatory = subtag is the script subtag. Introducing different 4-letter subtags within = BCP 47 syntax would create conflicts with this or other similar derivative = uses of our language tag syntax. Peter From doug@ewellic.org Tue Mar 10 20:55:10 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3ECA3A6833 for ; Tue, 10 Mar 2009 20:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub3KKPJagvQo for ; Tue, 10 Mar 2009 20:55:09 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id C71A53A681D for ; Tue, 10 Mar 2009 20:55:09 -0700 (PDT) Received: (qmail 6398 invoked from network); 11 Mar 2009 03:55:45 -0000 Received: from unknown (67.166.27.148) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 11 Mar 2009 03:55:44 -0000 Message-ID: From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 10 Mar 2009 21:55:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:55:10 -0000 Randy Presuhn wrote: > I've observed that accent can vary according to the number of beers > consumed. Perhaps another subtag should be designed to indicate the > speaker's level of intoxication. Or can we just use the altitude > parameter to indicate how high they are? :-) Uh oh, I'm busted! "We're in the Mile High City and I sure am!" - Don Meredith, "Monday Night Football," 1973-10-29 I think it may not be apparent to all respondents that while Caoimhín's suggestion to tag language usage by latitude and longitude may have been serious, Mark's response most certainly was not. -- Doug Ewell * Thornton, Colorado, USA (elevation 5324 ft, 1623 m) http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From doug@ewellic.org Tue Mar 10 21:09:33 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA1B3A685D for ; Tue, 10 Mar 2009 21:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, FAKE_REPLY_C=2.012, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVio6AbWB2Mv for ; Tue, 10 Mar 2009 21:09:32 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 990443A672F for ; Tue, 10 Mar 2009 21:09:32 -0700 (PDT) Received: (qmail 22675 invoked from network); 11 Mar 2009 04:10:08 -0000 Received: from unknown (67.166.27.148) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 11 Mar 2009 04:10:08 -0000 Message-ID: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 10 Mar 2009 22:10:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 04:09:33 -0000 John Cowan wrote: > (a) codes for language collections that aren't in 639-5, which could > be added to BCP 47 as 4-letter primary language subtags (that size is > currently reserved); *If* we are to support these code elements, I think this is the right place to do so. The 4-letter language subtag was reserved in BCP 47 for exactly this purpose, and if anyone, such as (ahem) Peter, sees a conflict with this due to their "derivative use of the language tag syntax," I'm sorry to say it, but that is a problem of their own making. > (b) codes for variants other than script and national variants, which > could be added to BCP 47 as 5-character variant subtags by adding a > 5th character (I propose prefixing '6'). (and later) > I wasn't proposing a singleton, but a convention: variant code abcd > would come into BCP 47 as variant subtag 6abcd, to avoid confusing it > with script subtags. I continue to be strongly opposed to adding hundreds or even thousands of variant subtags, using the same mechanism we currently use to register variants one by one. The boonts and fonipas and njivas would be completely overwhelmed by the oceans of 6xxxx subtags. If these don't qualify as language subtags, for whatever reason, then they should be encoded using the extension mechanism described in Section 3.7 of RFC 4646, preferably with an appropriate singleton such as '6'. This would be orders of magnitude more appropriate than variants. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From duerst@it.aoyama.ac.jp Tue Mar 10 22:03:27 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA863A6784 for ; Tue, 10 Mar 2009 22:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPF93+npF3gf for ; Tue, 10 Mar 2009 22:03:26 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 2BCC43A694A for ; Tue, 10 Mar 2009 22:03:24 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n2B53xBA015240 for ; Wed, 11 Mar 2009 14:03:59 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 07c2_07dc2c08_0dfa_11de_ae57_0019b9e2b3d9; Wed, 11 Mar 2009 14:03:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:44291) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Mar 2009 13:55:28 +0900 Message-Id: <6.0.0.20.2.20090311132912.0948b0a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Mar 2009 13:34:18 +0900 To: "Phillips, Addison" , John Cowan From: Martin Duerst In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.a mazon.com> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E6227EF@EX-SEA5-D.ant.amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 and LTRU continuation [was: Geocoordinates] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 05:03:27 -0000 At 05:30 09/03/11, Phillips, Addison wrote: >But I speculate recklessly. Since it seems pretty easy to create an IETF >WG, It is pretty easy if the proposed WG meets the relevant criteria, such as relevance to the Internet, critical mass,... >I guess the real question is whether the chairs, AD, and such would >want to maintain a moribund group for a year or so while this standard >bakes instead of just creating a new one at the appropriate juncture. It is very clear that the IETF prefers groups to be shut down when there's nothing much to do, not excluding the potential to form a new group again when there is new work to be done. In the mean time, the custom at the IETF is to keep the mailing list open, but a mailing list and a WG aren't the same. >Or it 639-6 that close? My preference would be to wait for it to be a full ISO standard, and in the mean time to collect experience with the actual use of 4646bis. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From petercon@microsoft.com Wed Mar 11 08:06:42 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1EF3A6877 for ; Wed, 11 Mar 2009 08:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.099 X-Spam-Level: X-Spam-Status: No, score=-12.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o80GeVqj8IVA for ; Wed, 11 Mar 2009 08:06:42 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 271F13A6B23 for ; Wed, 11 Mar 2009 08:06:42 -0700 (PDT) Received: from tk5-expfs-c106.redmond.corp.microsoft.com (157.54.69.40) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 11 Mar 2009 08:07:18 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-expfs-c106.redmond.corp.microsoft.com ([157.54.69.40]) with mapi; Wed, 11 Mar 2009 08:07:18 -0700 From: Peter Constable To: Doug Ewell , LTRU Working Group Date: Wed, 11 Mar 2009 08:07:16 -0700 Thread-Topic: [Ltru] ISO 639-6 (was: Geocoordinates) Thread-Index: Acmh/0eU89V3xSoXTAeJ+iYXIZJ2iwAWnBzg Message-ID: References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> In-Reply-To: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:06:43 -0000 RnJvbTogbHRydS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KDQo+ICpJZiogd2UgYXJlIHRvIHN1cHBvcnQgdGhl c2UgY29kZSBlbGVtZW50cywgSSB0aGluayB0aGlzIGlzIHRoZSByaWdodCANCj4gcGxhY2UgdG8g ZG8gc28uICBUaGUgNC1sZXR0ZXIgbGFuZ3VhZ2Ugc3VidGFnIHdhcyByZXNlcnZlZCBpbiBCQ1Ag NDcgZm9yIA0KPiBleGFjdGx5IHRoaXMgcHVycG9zZSwgYW5kIGlmIGFueW9uZSwgc3VjaCBhcyAo YWhlbSkgUGV0ZXIsIHNlZXMgYSANCj4gY29uZmxpY3Qgd2l0aCB0aGlzIGR1ZSB0byB0aGVpciAi ZGVyaXZhdGl2ZSB1c2Ugb2YgdGhlIGxhbmd1YWdlIHRhZyANCj4gc3ludGF4LCIgSSdtIHNvcnJ5 IHRvIHNheSBpdCwgYnV0IHRoYXQgaXMgYSBwcm9ibGVtIG9mIHRoZWlyIG93biBtYWtpbmcuDQoN Ckp1c3QgYmVjYXVzZSB3ZSByZXNlcnZlZCBzb21ldGhpbmcgZm9yIHNvbWUgZnV0dXJlIHBvc3Np YmlsaXR5IC0tIGEgZGVjaXNpb24gdGFrZW4gd2l0aG91dCBhbnkgY29uc2lkZXJhdGlvbiB3aGF0 c29ldmVyIG9mIHRoZSBtZXJpdHMgb2YgdGhhdCBwb3NzaWJpbGl0eSAtLSB0aGF0IGRvZXNuJ3Qg bWVhbiB0aGF0IHRoYXQgcG9zc2liaWxpdHkgZG9lcyBoYXZlIG1lcml0cy4gRm9yIG15IHBhcnQs IEkgaGF2ZSBhbHdheXMgZG91YnRlZCB0aGUgbWVyaXRzLiBPbiB0aGF0IGJhc2lzLCBhbmQgYXNz dW1pbmcgdGhhdCBub3RoaW5nIHdhcyBsaWtlbHkgdG8gY29tZSBvZiB0aGF0IHBvc3NpYmlsaXR5 LCBJIGNob3NlIHRvIHB1cnN1ZSBhIGRlcml2YXRpdmUgdXNlIGluIGEgcGFydGljdWxhciBhcHBs aWNhdGlvbiBjb250ZXh0LiBJZiBpdCB0dXJucyBvdXQgdGhhdCBhIGZ1dHVyZSB2ZXJzaW9uIG9m IEJDUDQ3IGRvZXMgbWFrZSB1c2Ugb2YgdGhvc2UgY3VycmVudGx5LXJlc2VydmVkIGFscGhhLTQg c3VidGFncywgdGhlbiBpbmRlZWQgdGhlIHByb2JsZW0gd2lsbCBiZSBtaW5lIChhbmQgSSdtIHN1 cmUgSSdsbCBzdXJ2aXZlKS4gQnV0IEkgY2FuIHRlbGwgeW91IHVwIGZyb250IHRoYXQgSSB3aWxs IG1vc3QgbGlrZWx5IHB1c2ggYmFjayBvbiBhIHJldmlzaW9uIHRvIG1ha2UgdXNlIG9mIHRoZSBy ZXNlcnZlZCBhbHBoYS00IHN1YnRhZ3Mgbm90IG9ubHkgYmVjYXVzZSBpdCdzIGluY29udmVuaWVu dCBmb3IgbXkgZGVyaXZhdGl2ZSBhcHBsaWNhdGlvbiBidXQgYWxzbyBiZWNhdXNlIEkgcmVtYWlu IHZlcnkgc2tlcHRpY2FsIHRoYXQgdGhlcmUgd2lsbCBiZSBiZW5lZml0cyAobGV0IGFsb25lIFJP SSwgY29uc2lkZXJpbmcgdGhlIGNvc3RzKS4NCg0KDQoNCj4gSSBjb250aW51ZSB0byBiZSBzdHJv bmdseSBvcHBvc2VkIHRvIGFkZGluZyBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyANCj4gb2Yg dmFyaWFudCBzdWJ0YWdzLCB1c2luZyB0aGUgc2FtZSBtZWNoYW5pc20gd2UgY3VycmVudGx5IHVz ZSB0byANCj4gcmVnaXN0ZXIgdmFyaWFudHMgb25lIGJ5IG9uZS4NCg0KRG8geW91IG1lYW4sICJv cHBvc2VkIHRvIGFkZGluZyAuLi4gdGhvdXNhbmRzIG9mIHZhcmlhbnQgc3VidGFncyBfaW4gbWFz c18sIGFuZCBwcmVmZXIgdG8gY29udGludWUgLi4uIHJlZ2lzdGVyW2luZ10gdmFyaWFudHMgb25l IGJ5IG9uZSI/DQoNCklmIHNvLCBJIGFncmVlLg0KDQoNCg0KUGV0ZXINCg== From cowan@ccil.org Wed Mar 11 08:25:35 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454CF3A68E6 for ; Wed, 11 Mar 2009 08:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgRk7WnpdSbz for ; Wed, 11 Mar 2009 08:25:29 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 894123A69C4 for ; Wed, 11 Mar 2009 08:25:29 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LhQJp-0005fH-1L; Wed, 11 Mar 2009 11:26:05 -0400 Date: Wed, 11 Mar 2009 11:26:05 -0400 To: Doug Ewell Message-ID: <20090311152604.GA15999@mercury.ccil.org> References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:25:35 -0000 Doug Ewell scripsit: > I continue to be strongly opposed to adding hundreds or even thousands > of variant subtags, using the same mechanism we currently use to > register variants one by one. The boonts and fonipas and njivas would > be completely overwhelmed by the oceans of 6xxxx subtags. And a Good Thing Too. Boontling is a variety of English, and ought to have a 639-6 code element. Fonipa is a kludge to compensate for a limitation in ISO 15924. With 639-6 we don't need to register variants, we make people go to 639-6/RA instead. > If these don't qualify as language subtags, for whatever reason, then > they should be encoded using the extension mechanism described in > Section 3.7 of RFC 4646, preferably with an appropriate singleton such > as '6'. This would be orders of magnitude more appropriate than > variants. Most of the 639-6 codes correspond semantically to variant subtags. Consider 'yoli' (or '6yoli' under my proposal): it's the Yo-Li variety of the Xinan dialect of Mandarin. We know this because of the 639-6 parent data, which shows the following chain: yoli > xuuk (Xinan dialect, spoken) > xghu (Xinan dialect) > cmn (Mandarin proper) > micr (Mandarin cluster) > mycx (Mandarin-Yue complex) > zho (Chinese) > ssic (Sinitic) > snot (Sino-Tibetan). This is not, of course, the One True Tree; what's more, it's preliminary data and subject to change. But just the fact that 'yoli' is subordinate to 'cmn', a known individual language code (from the 639-3 data), and that it isn't cross-referenced with a 3166 or 15924 code, tells us this is a variant. The code 'biar' (Bai cluster) > ssic > snot, on the other hand, is not subordinate to any 639-3 individual language and therefore is a collection. -- "Well, I'm back." --Sam John Cowan From cowan@ccil.org Wed Mar 11 08:27:23 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E37C3A6ACC for ; Wed, 11 Mar 2009 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Ksa6tdjsXm for ; Wed, 11 Mar 2009 08:27:22 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 635EF3A69C4 for ; Wed, 11 Mar 2009 08:27:22 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LhQLZ-0005o3-Jd; Wed, 11 Mar 2009 11:27:53 -0400 Date: Wed, 11 Mar 2009 11:27:53 -0400 To: Peter Constable Message-ID: <20090311152753.GB15999@mercury.ccil.org> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:27:23 -0000 Peter Constable scripsit: > I'd be resistant to 4-letter primary language subtags. I have made > derivative use of BCP 47 tag syntax with the modification that the only > obligatory subtag is the script subtag. Introducing different 4-letter > subtags within BCP 47 syntax would create conflicts with this or other > similar derivative uses of our language tag syntax. You can easily return to compliance by changing all ill-formed wxyz tags to und-wxyz tags. -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. From randy_presuhn@mindspring.com Wed Mar 11 10:30:23 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9C43A69F1 for ; Wed, 11 Mar 2009 10:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2bPq318D9-p for ; Wed, 11 Mar 2009 10:30:22 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 848DE3A6980 for ; Wed, 11 Mar 2009 10:30:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gScSPB4B1EMEJdtFIKzwyaZr66aBhOLlCl9178ks2CMLypepNfhVqMP7xdPtDxMe; 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 [69.3.28.96] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LhSGg-0004lk-M3 for ltru@ietf.org; Wed, 11 Mar 2009 13:30:58 -0400 Message-ID: <006101c9a26f$42f21240$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20090310093127.GB2850@nic.fr><003b01c9a1ab$7eacc060$6801a8c0@oemcomputer><20090310184601.GD7167@mercury.ccil.org><4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com><20090310200354.GE7167@mercury.ccil.org> Date: Wed, 11 Mar 2009 10:31:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1735d927fd47b2aba28005fc63b2863ac6d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.96 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:30:24 -0000 Hi - > From: "Peter Constable" > To: "John Cowan" ; "Phillips, Addison" > Cc: "LTRU Working Group" > Sent: Tuesday, March 10, 2009 8:36 PM > Subject: Re: [Ltru] Geocoordinates > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of John Cowan > > > So what's left is: > > > > (a) codes for language collections that aren't in 639-5, which could > > be added to BCP 47 as 4-letter primary language subtags (that size is > > currently reserved); > > I'd be resistant to 4-letter primary language subtags. > I have made derivative use of BCP 47 tag syntax > with the modification that the only obligatory subtag > is the script subtag. > Introducing different 4-letter subtags within BCP 47 syntax > would create conflicts with this or other similar derivative > uses of our language tag syntax. As a technical contributor... I find this line of argument unpersuasive. We should only concern ourselves with compatibility with conformant implementations. If someone implements something "derived from" the spec which does not follow it to the letter, they're on their own. Randy From mark.edward.davis@gmail.com Wed Mar 11 10:41:28 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A27F3A6B32 for ; Wed, 11 Mar 2009 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC3j-1ipRQvl for ; Wed, 11 Mar 2009 10:41:22 -0700 (PDT) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by core3.amsl.com (Postfix) with ESMTP id 41D6C3A6B13 for ; Wed, 11 Mar 2009 10:41:22 -0700 (PDT) Received: by gxk11 with SMTP id 11so277603gxk.13 for ; Wed, 11 Mar 2009 10:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=v/wdMRy0obGA4hIaY1B0XTEXjXRDWtsONjnm2vAz4IM=; b=SZVdgG4DhJLMZpqBXyvl5YFHALjaJomdVGSpAr0zTDpCn+dw+EMTn8IDTU8Q0H1xbb Rc5DBA+Dxad15Wf/li0VjQpe1InhGZE9UeGVyo16C2zK4KFr/rA1qgG7cX6NdGPRVFcs QjkoSDr5Kad5eRQROUiXuF+L2x9rks7Pk29sM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=P/nU+KanPahbid+w9IxEbD5pdMLDo6Th32qEfGTL65Vi5Gfwf82j+eeEcMrP6V4pIV 2mkYqLMyM2p5t3J4FXnrai36y/y5KugMKBAIhtf58acN+QAxb+kdjglCL6fp8LvnBAQ8 rEGgGKwYb37JUIvc6tTf8hDhGw/4Pm0FKjPZg= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.143.31.4 with SMTP id i4mr3776195wfj.247.1236793299992; Wed, 11 Mar 2009 10:41:39 -0700 (PDT) In-Reply-To: <006101c9a26f$42f21240$6801a8c0@oemcomputer> References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> <006101c9a26f$42f21240$6801a8c0@oemcomputer> Date: Wed, 11 Mar 2009 10:41:39 -0700 X-Google-Sender-Auth: ae0283cd265190e4 Message-ID: <30b660a20903111041jd41859apd94d4b0a361f34f7@mail.gmail.com> From: Mark Davis To: Randy Presuhn Content-Type: multipart/alternative; boundary=001636e0b4f14e7fdc0464db615e Cc: LTRU Working Group Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:41:28 -0000 --001636e0b4f14e7fdc0464db615e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It is not necessarily non-conformant. I could define a field as follows: - if it has 4 characters and no hyphen, it means X - otherwise it is interpreted as a BCP 47 language tag. That is perfectly conformant usage of BCP 47, and would work with the current spec. The disadvantage is that if BCP47 ever uses 4-letter base language codes, then you can't represent the full range of BCP47 at that point. So you definitely take a risk in using such a definition in terms of future compatibility, but such a definition is not non-conformant. Mark On Wed, Mar 11, 2009 at 10:31, Randy Presuhn wrote: > Hi - > > > From: "Peter Constable" > > To: "John Cowan" ; "Phillips, Addison" < > addison@amazon.com> > > Cc: "LTRU Working Group" > > Sent: Tuesday, March 10, 2009 8:36 PM > > Subject: Re: [Ltru] Geocoordinates > > > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > John Cowan > > > > > So what's left is: > > > > > > (a) codes for language collections that aren't in 639-5, which could > > > be added to BCP 47 as 4-letter primary language subtags (that size is > > > currently reserved); > > > > I'd be resistant to 4-letter primary language subtags. > > I have made derivative use of BCP 47 tag syntax > > with the modification that the only obligatory subtag > > is the script subtag. > > Introducing different 4-letter subtags within BCP 47 syntax > > would create conflicts with this or other similar derivative > > uses of our language tag syntax. > > As a technical contributor... > > I find this line of argument unpersuasive. We should only > concern ourselves with compatibility with conformant > implementations. If someone implements something > "derived from" the spec which does not follow it to the > letter, they're on their own. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e0b4f14e7fdc0464db615e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is not necessarily non-conformant. I could define a field as follows:
  • if it has 4 characters and no hyphen, it means X
  • otherwise= it is interpreted as a BCP 47 language tag.
That is perfectly con= formant usage of BCP 47, and would work with the current spec. The disadvan= tage is that if BCP47 ever uses 4-letter base language codes, then you can&= #39;t represent the full range of BCP47 at that point. So you definitely ta= ke a risk in using such a definition in terms of future compatibility, but = such a definition is not non-conformant.

Mark


On Wed, Mar 11, 2009 at 10:31, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

> From: "Peter Constable" <petercon@microsoft.com>
> To: "John Cowan" <cowan= @ccil.org>; "Phillips, Addison" <addison@amazon.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Tuesday, March 10, 2009 8:36 PM
> Subject: Re: [Ltru] Geocoordinates
>
> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of John Cowan
>
> > So what's left is:
> >
> > (a) codes for language collections that aren't in 639-5, whic= h could
> > be added to BCP 47 as 4-letter primary language subtags (that siz= e is
> > currently reserved);
>
> I'd be resistant to 4-letter primary language subtags.
> I have made derivative use of BCP 47 tag syntax
> with the modification that the only obligatory subtag
> is the script subtag.
> Introducing different 4-letter subtags within BCP 47 syntax
> would create conflicts with this or other similar derivative
> uses of our language tag syntax.

As a technical contributor...

I find this line of argument unpersuasive. =C2=A0We should only
concern ourselves with compatibility with conformant
implementations. =C2=A0If someone implements something
"derived from" the spec which does not follow it to the
letter, they're on their own.

Randy

--001636e0b4f14e7fdc0464db615e-- From randy_presuhn@mindspring.com Wed Mar 11 10:53:11 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB743A684C for ; Wed, 11 Mar 2009 10:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvX1ZRnSDR2e for ; Wed, 11 Mar 2009 10:53:11 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C217A3A6AF6 for ; Wed, 11 Mar 2009 10:52:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JQRiXaIxomprqSgYrzC4jIzQylHvoi07gfj4/8+5DTcng6+bHTBtJOjGBXyV3qdH; 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 [69.3.28.96] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LhScR-0007mJ-2C for ltru@ietf.org; Wed, 11 Mar 2009 13:53:27 -0400 Message-ID: <009401c9a272$686fd220$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20090310093127.GB2850@nic.fr> <003b01c9a1ab$7eacc060$6801a8c0@oemcomputer> <20090310184601.GD7167@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA019E622691@EX-SEA5-D.ant.amazon.com> <20090310200354.GE7167@mercury.ccil.org> <006101c9a26f$42f21240$6801a8c0@oemcomputer> <30b660a20903111041jd41859apd94d4b0a361f34f7@mail.gmail.com> Date: Wed, 11 Mar 2009 10:54:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173ec0fd205f80350abbb1dab9860fa237f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.96 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:53:11 -0000 Hi - > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Wednesday, March 11, 2009 10:41 AM > Subject: Re: [Ltru] Geocoordinates > > It is not necessarily non-conformant. I could define a field as follows: > > - if it has 4 characters and no hyphen, it means X > - otherwise it is interpreted as a BCP 47 language tag. > > That is perfectly conformant usage of BCP 47, and would work with the > current spec. As a technical contributor... I disagree. The field's definition would result in well-formed tags being analyzed incorrectly. > The disadvantage is that if BCP47 ever uses 4-letter base > language codes, then you can't represent the full range of BCP47 at that > point. They are *already* in the grammar. That's the whole point of "reserved for future use". Randy From doug@ewellic.org Wed Mar 11 18:06:20 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6727F28C16F for ; Wed, 11 Mar 2009 18:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkqZ1Jgtuz7m for ; Wed, 11 Mar 2009 18:06:19 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 7339528C15C for ; Wed, 11 Mar 2009 18:06:19 -0700 (PDT) Received: (qmail 13447 invoked from network); 12 Mar 2009 01:06:56 -0000 Received: from unknown (67.166.27.148) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 12 Mar 2009 01:06:55 -0000 Message-ID: <447B672B6C7E40C98DDFE55D667D6044@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> Date: Wed, 11 Mar 2009 19:02:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:06:20 -0000 Peter Constable wrote: > Just because we reserved something for some future possibility -- a > decision taken without any consideration whatsoever of the merits of > that possibility -- that doesn't mean that that possibility does have > merits. For my part, I have always doubted the merits. On that basis, > and assuming that nothing was likely to come of that possibility, I > chose to pursue a derivative use in a particular application context. > If it turns out that a future version of BCP47 does make use of those > currently-reserved alpha-4 subtags, then indeed the problem will be > mine (and I'm sure I'll survive). But I can tell you up front that I > will most likely push back on a revision to make use of the reserved > alpha-4 subtags not only because it's inconvenient for my derivative > application but also because I remain very skeptical that there will > be benefits (let alone ROI, considering the costs). We're talking about two separate issues here: 1. Whether the RFC 4646 decision to reserve 4-letter language subtags "for future use," widely assumed to be ISO 639-6, was a good one, and specifically whether ISO 639-6-based subtags would add sufficient value to BCP 47. 2. Whether a future decision on creating 4-letter language subtags, for whatever reason, should be influenced by the existence of one or more derivative applications that are non-conformant to BCP 47. Regarding issue 1, I'm reserving judgment until all of the 639-6 data becomes publicly available, and until LTRU and/or ietf-languages have had a chance to look at it and start discussing it. I also agree with Martin that some working experience with the 7,500 language subtags available in the 4646bis era would be helpful. As you can tell, I do have opinions about how they should be added *if* they are to be added. Regarding issue 2, I'm very much against letting this be a contributing factor. >> I continue to be strongly opposed to adding hundreds or even >> thousands of variant subtags, using the same mechanism we currently >> use to register variants one by one. > > Do you mean, "opposed to adding ... thousands of variant subtags _in > mass_, and prefer to continue ... register[ing] variants one by one"? I mean I'm opposed to adding thousands of variant subtags, either in mass *or* one by one, using a formulaic process such as prepending '6' to thousands of ISO 639-6 code elements. Variants are supposed to be proposed, discussed, and approved (or rejected) on a case-by-case basis. They are not supposed to be a means of shoehorning in another external standard. That is what the other two solutions -- 4-letter language subtags and extensions -- are for. > If so, I agree. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From doug@ewellic.org Wed Mar 11 18:15:05 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F14B3A6856 for ; Wed, 11 Mar 2009 18:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Sp4NabMLVf for ; Wed, 11 Mar 2009 18:15:04 -0700 (PDT) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by core3.amsl.com (Postfix) with SMTP id 044753A6AC0 for ; Wed, 11 Mar 2009 18:15:03 -0700 (PDT) Received: (qmail 10743 invoked from network); 12 Mar 2009 01:15:40 -0000 Received: from unknown (67.166.27.148) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 12 Mar 2009 01:15:39 -0000 Message-ID: <294D681B191C4449800450499A759B20@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <20090311152604.GA15999@mercury.ccil.org> Date: Wed, 11 Mar 2009 19:15:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:15:05 -0000 John Cowan wrote: >> ... The boonts and fonipas and njivas would be completely overwhelmed >> by the oceans of 6xxxx subtags. > > And a Good Thing Too. Boontling is a variety of English, and ought to > have a 639-6 code element. Fonipa is a kludge to compensate for a > limitation in ISO 15924. With 639-6 we don't need to register > variants, we make people go to 639-6/RA instead. Then if you like, view the "legacy" variants as warts on the side of a collection of '6' variants. Doesn't matter; the warts are not going away. Despite its size and ambitious goals, and the expertise of those preparing it, I would be very surprised if 639-6 encompassed a proper superset of everything that has ever been (a) registered in the Registry or (b) taken seriously but not registered in the Registry, going back to the whole tags registered under RFC 1766/3066. That is one of the major problems with claiming that 639-6 will enable ietf-languages to be shut down. The other, of course, is that we have 14 years of history with a Reviewer and a discussion list that offers him advice, and RFC 4646 and draft-4646bis have expanded their role to include vetting of new and changed subtags stemming not only from user requests, but from changes to the core ISO and UN standards. We have six such requests pending right now. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From mark.edward.davis@gmail.com Wed Mar 11 18:17:03 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCCD3A6B48 for ; Wed, 11 Mar 2009 18:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5VzLSbGf7C5 for ; Wed, 11 Mar 2009 18:17:02 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 3B4CD3A6AF6 for ; Wed, 11 Mar 2009 18:17:02 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so314880wfd.31 for ; Wed, 11 Mar 2009 18:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=53te8dlyhm1nXHr9OQQ2LB0dBW9rrGun1NTMnR3XLo4=; b=rTdS5G0yQbyhdEDCRCjn5YXIO/m1G/BPr5Xos9eyJzWlBttFgi+wlRH1qb7D0FZVA4 aP/7m76qExNAwOM0HoDKJyurOts5cBpz6P7xGFg+/lnb4GpIaejXpNj9mjAphBWoEbXQ VNgvzUMe/tx1pnuUqim7C6kZGtm2S+eWJTyrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=B7taBMDT3Bs8ARN5gtLpZD76d+8ZYpo79gMfFDPak9YS27C7Kah2y7KMTrgAjRQsPG 2jVwQT/gb8LUiKuRE0TlDyW1icpdLjSRhdjIdsUhGlWz9rvbgZ+VQ4V2Tn0co/3zr+pB hLCD4PiHSezRpXhfVv24TUO8HRfd0y22HYXD4= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.70.16 with SMTP id s16mr4003305wfa.151.1236820659185; Wed, 11 Mar 2009 18:17:39 -0700 (PDT) In-Reply-To: <447B672B6C7E40C98DDFE55D667D6044@DGBP7M81> References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <447B672B6C7E40C98DDFE55D667D6044@DGBP7M81> Date: Wed, 11 Mar 2009 18:17:39 -0700 X-Google-Sender-Auth: dc1da764bcb1974f Message-ID: <30b660a20903111817h768bda3avcf63415e9bd355@mail.gmail.com> From: Mark Davis To: Doug Ewell Content-Type: multipart/alternative; boundary=001636e9093a0aa9a60464e1c03b Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:17:03 -0000 --001636e9093a0aa9a60464e1c03b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Doug that we'd want to tread very carefully with regards to adding ISO 639-6. The rollout over a couple of years of the changes that we are currently making will teach us a lot. Mark On Wed, Mar 11, 2009 at 18:02, Doug Ewell wrote: > Peter Constable wrote: > > Just because we reserved something for some future possibility -- a >> decision taken without any consideration whatsoever of the merits of tha= t >> possibility -- that doesn't mean that that possibility does have merits.= For >> my part, I have always doubted the merits. On that basis, and assuming t= hat >> nothing was likely to come of that possibility, I chose to pursue a >> derivative use in a particular application context. If it turns out that= a >> future version of BCP47 does make use of those currently-reserved alpha-= 4 >> subtags, then indeed the problem will be mine (and I'm sure I'll survive= ). >> But I can tell you up front that I will most likely push back on a revis= ion >> to make use of the reserved alpha-4 subtags not only because it's >> inconvenient for my derivative application but also because I remain ver= y >> skeptical that there will be benefits (let alone ROI, considering the >> costs). >> > > We're talking about two separate issues here: > > 1. Whether the RFC 4646 decision to reserve 4-letter language subtags "fo= r > future use," widely assumed to be ISO 639-6, was a good one, and > specifically whether ISO 639-6-based subtags would add sufficient value t= o > BCP 47. > > 2. Whether a future decision on creating 4-letter language subtags, for > whatever reason, should be influenced by the existence of one or more > derivative applications that are non-conformant to BCP 47. > > Regarding issue 1, I'm reserving judgment until all of the 639-6 data > becomes publicly available, and until LTRU and/or ietf-languages have had= a > chance to look at it and start discussing it. I also agree with Martin t= hat > some working experience with the 7,500 language subtags available in the > 4646bis era would be helpful. As you can tell, I do have opinions about = how > they should be added *if* they are to be added. > > Regarding issue 2, I'm very much against letting this be a contributing > factor. > > I continue to be strongly opposed to adding hundreds or even thousands o= f >>> variant subtags, using the same mechanism we currently use to register >>> variants one by one. >>> >> >> Do you mean, "opposed to adding ... thousands of variant subtags _in >> mass_, and prefer to continue ... register[ing] variants one by one"? >> > > I mean I'm opposed to adding thousands of variant subtags, either in mass > *or* one by one, using a formulaic process such as prepending '6' to > thousands of ISO 639-6 code elements. Variants are supposed to be propos= ed, > discussed, and approved (or rejected) on a case-by-case basis. They are n= ot > supposed to be a means of shoehorning in another external standard. That= is > what the other two solutions -- 4-letter language subtags and extensions = -- > are for. > > If so, I agree. >> > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636e9093a0aa9a60464e1c03b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Doug that we'd want to tread very carefully with regards t= o adding ISO 639-6. The rollout over a couple of years of the changes that = we are currently making will teach us a lot.

Mark


On Wed, Mar 11, 2009 at 18:02, Doug Ewel= l <doug@ewellic.or= g> wrote:
Peter Constable <petercon at microsoft dot com> wro= te:

Just because we reserved something for some future possibility -- a decisio= n taken without any consideration whatsoever of the merits of that possibil= ity -- that doesn't mean that that possibility does have merits. For my= part, I have always doubted the merits. On that basis, and assuming that n= othing was likely to come of that possibility, I chose to pursue a derivati= ve use in a particular application context. If it turns out that a future v= ersion of BCP47 does make use of those currently-reserved alpha-4 subtags, = then indeed the problem will be mine (and I'm sure I'll survive). B= ut I can tell you up front that I will most likely push back on a revision = to make use of the reserved alpha-4 subtags not only because it's incon= venient for my derivative application but also because I remain very skepti= cal that there will be benefits (let alone ROI, considering the costs).

We're talking about two separate issues here:

1. Whether the RFC 4646 decision to reserve 4-letter language subtags "= ;for future use," widely assumed to be ISO 639-6, was a good one, and = specifically whether ISO 639-6-based subtags would add sufficient value to = BCP 47.

2. Whether a future decision on creating 4-letter language subtags, for wha= tever reason, should be influenced by the existence of one or more derivati= ve applications that are non-conformant to BCP 47.

Regarding issue 1, I'm reserving judgment until all of the 639-6 data b= ecomes publicly available, and until LTRU and/or ietf-languages have had a = chance to look at it and start discussing it. =C2=A0I also agree with Marti= n that some working experience with the 7,500 language subtags available in= the 4646bis era would be helpful. =C2=A0As you can tell, I do have opinion= s about how they should be added *if* they are to be added.

Regarding issue 2, I'm very much against letting this be a contributing= factor.


I continue to be strongly opposed to adding hundreds or even thousands of v= ariant subtags, using the same mechanism we currently use to register varia= nts one by one.

Do you mean, "opposed to adding ... thousands of variant subtags _in m= ass_, and prefer to continue ... register[ing] variants one by one"?

I mean I'm opposed to adding thousands of variant subtags, either in ma= ss *or* one by one, using a formulaic process such as prepending '6'= ; to thousands of ISO 639-6 code elements. =C2=A0Variants are supposed to b= e proposed, discussed, and approved (or rejected) on a case-by-case basis. = They are not supposed to be a means of shoehorning in another external stan= dard. =C2=A0That is what the other two solutions -- 4-letter language subta= gs and extensions -- are for.

If so, I agree.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86

_______________________________________________

--001636e9093a0aa9a60464e1c03b-- From doug@ewellic.org Wed Mar 11 18:31:03 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD0D3A6862 for ; Wed, 11 Mar 2009 18:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQoPjzJOVkQk for ; Wed, 11 Mar 2009 18:31:02 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 10BCC3A6856 for ; Wed, 11 Mar 2009 18:31:01 -0700 (PDT) Received: (qmail 31315 invoked from network); 12 Mar 2009 01:31:38 -0000 Received: from unknown (67.166.27.148) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 12 Mar 2009 01:31:37 -0000 Message-ID: <9EA6D78C566E49D79C37CA3396384644@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 11 Mar 2009 19:31:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:31:03 -0000 Mark Davis wrote: > It is not necessarily non-conformant. I could define a field as > follows: > > - if it has 4 characters and no hyphen, it means X > - otherwise it is interpreted as a BCP 47 language tag. > > That is perfectly conformant usage of BCP 47, and would work with the > current spec. The disadvantage is that if BCP47 ever uses 4-letter > base language codes, then you can't represent the full range of BCP47 > at that point. So you definitely take a risk in using such a > definition in terms of future compatibility, but such a definition is > not non-conformant. That sounds to me somewhat like a field containing a 16-bit unsigned integer defined as follows: - if it is within the range 0x0880 through 0x08FF, it is a message ID - otherwise it is interpreted as a UTF-16 code unit on the basis that no Unicode characters between U+0880 and U+08FF are currently assigned. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From petercon@microsoft.com Wed Mar 11 21:54:53 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF203A689A for ; Wed, 11 Mar 2009 21:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.265 X-Spam-Level: X-Spam-Status: No, score=-11.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTaj9w8OyPAF for ; Wed, 11 Mar 2009 21:54:53 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 37FCD3A6858 for ; Wed, 11 Mar 2009 21:54:52 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 11 Mar 2009 21:55:23 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Wed, 11 Mar 2009 21:55:23 -0700 From: Peter Constable To: Doug Ewell , LTRU Working Group Date: Wed, 11 Mar 2009 21:55:16 -0700 Thread-Topic: [Ltru] ISO 639-6 (was: Geocoordinates) Thread-Index: AcmirvT/89QFNWNAQuCjP/e0nMUp0AAHtgfg Message-ID: References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <447B672B6C7E40C98DDFE55D667D6044@DGBP7M81> In-Reply-To: <447B672B6C7E40C98DDFE55D667D6044@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 04:54:54 -0000 RnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRvdWdAZXdlbGxpYy5vcmddIA0KDQoNCj4+IERvIHlv dSBtZWFuLCAib3Bwb3NlZCB0byBhZGRpbmcgLi4uIHRob3VzYW5kcyBvZiB2YXJpYW50IHN1YnRh Z3MgX2luIA0KPj4gbWFzc18sIGFuZCBwcmVmZXIgdG8gY29udGludWUgLi4uIHJlZ2lzdGVyW2lu Z10gdmFyaWFudHMgb25lIGJ5IG9uZSI/DQo+DQo+IEkgbWVhbiBJJ20gb3Bwb3NlZCB0byBhZGRp bmcgdGhvdXNhbmRzIG9mIHZhcmlhbnQgc3VidGFncywgZWl0aGVyIGluIA0KPiBtYXNzICpvciog b25lIGJ5IG9uZSwgdXNpbmcgYSBmb3JtdWxhaWMgcHJvY2VzcyBzdWNoIGFzIHByZXBlbmRpbmcg JzYnIA0KPiB0byB0aG91c2FuZHMgb2YgSVNPIDYzOS02IGNvZGUgZWxlbWVudHMuICBWYXJpYW50 cyBhcmUgc3VwcG9zZWQgdG8gYmUgDQo+IHByb3Bvc2VkLCBkaXNjdXNzZWQsIGFuZCBhcHByb3Zl ZCAob3IgcmVqZWN0ZWQpIG9uIGEgY2FzZS1ieS1jYXNlIGJhc2lzLiANCg0KSSBjYW4gY2VydGFp bmx5IGdvIGFsb25nIHdpdGggdGhhdCBsYXN0IHN0YXRlbWVudC4NCg0KDQoNClBldGVyDQo= From cewcathar@hotmail.com Thu Mar 12 10:27:42 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A613A680B for ; Thu, 12 Mar 2009 10:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH4M0tB8LOYd for ; Thu, 12 Mar 2009 10:27:37 -0700 (PDT) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by core3.amsl.com (Postfix) with ESMTP id D07783A69B5 for ; Thu, 12 Mar 2009 10:27:36 -0700 (PDT) Received: from BLU109-W49 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 10:28:14 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fbd96f50-6a33-4ed4-b234-a220f699b513_" X-Originating-IP: [198.252.156.11] From: CE Whitehead To: Date: Thu, 12 Mar 2009 13:28:13 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 17:28:14.0316 (UTC) FILETIME=[EC80C2C0:01C9A337] Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:27:42 -0000 --_fbd96f50-6a33-4ed4-b234-a220f699b513_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is going to happen to the suggestion we allow wild cards to be registe= red as prefixes & incorporate that into the next draft of RFC 4646? =20 =20 Is that tabled too? Or was that never an option?=3B I recall only Doug's s= aying that this addition was too late for the current edition of 4646 & not= that it would never be an option: =20 http://www.ietf.org/mail-archive/web/ltru/current/msg11947.html =20 (also where will ISO 639-6 data be looked at? at ietf?) Otherwise I haven't an informed opinion on the closing of this list or ISO = 639-6=3B=20 however I hope ietf will continue to let users apply for their own variant = subtags. =20 =20 (Back to the geocoordinates post=2C since you've not changed the subject li= ne=2C I think that geocoordinates might in a few cases help get variants su= btags in a way that is further removed from the political muddle around som= e . . . but think this can be handled at ietf on a case-by-case basis=3B so= it's not a wholly idiot suggestion=3B on a large scale it might be cumbers= ome . . . & all that's needed for now is to tag language use that's current= on the internet not the dialects and varieties used in every corner of the= globe=2C not till they get online=3B it's the need to look at variants tha= t might be overlooked with the overlooking perceived as a political slight = that makes it especially important to have a method for registering new var= iants . . . ) =20 Best=2C =20 C. E. Whitehead cewcathar@hotmail.com =20 From: John Cowan =20 Date: Tue=2C 10 Mar 2009 16:03:54 -0400=20 > Of course the Registry would become bigger than ever=2C > and some of > He Who Must Not Be Named's concerns would actually=20 > become realities=2C > like whether authorized mirrors would be needed to hold > down on the > number of downloads. On the other hand=2C we could=20 > pretty well shut down ietf-languages@=2C since there would be little or nothing left to approve outside the 639 framework --_fbd96f50-6a33-4ed4-b234-a220f699b513_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is going to happen to the suggestion we =3Ballow wild cards&nb= sp=3Bto be registered as prefixes &=3B incorporate that into the next dr= aft of RFC 4646? =3B =3B
 =3B
Is that tabled too? =3B= Or was that never an option?=3B I recall only Doug's saying that this addi= tion was too late for the current edition of 4646 &=3B not that it would= never be an option:
 =3B
http://www.ietf.org/mail-archive/web/ltru/current/msg11947.html
 =3B
(also where will ISO 639-6 data be looked at? =3B at ietf?)

Otherwise I haven't an informed opinion =3Bon the closing of this list = or =3BISO 639-6=3B
however I hope ietf will continue to let users apply for their own variant = subtags. =3B
 =3B
(Back to the geocoordinates =3Bpost=2C since you've not changed the sub= ject line=2C I think that geocoordinates might in a few cases help get = =3Bvariants subtags =3Bin a way that is further removed from the politi= cal muddle around some =3B. . . but think this can be handled at ietf o= n a case-by-case basis=3B so it's not a wholly idiot suggestion=3B on a lar= ge scale it might be cumbersome . . . &=3B all that's needed for now is = to tag language use that's =3Bcurrent on the internet not the dialects = and varieties used in every corner of the globe=2C not till they get online= =3B it's the need to look at =3Bvariants that might be overlooked = =3Bwith the overlooking perceived =3Bas a =3Bpolitical slight that&= nbsp=3Bmakes it especially important to have a method for registering new v= ariants . . . =3B )
 =3B
Best=2C
 =3B
C. E. Whitehead
cewcathar@hotmail.com

 =3B

From: John Cowan <=3Bcowa= n at ccil.org>=3B
Date: Tue=2C 10 Mar 2009 16:03:54 -0400
>=3B Of course the R= egistry would become bigger than ever=2C >=3B and some of
>=3B He Wh= o Must Not Be Named's concerns would actually
>=3B become realities=2C
>=3B like whether authorized mirrors would = be needed to hold >=3B down on the
>=3B number of downloads. =3B= On the other hand=2C we could
>=3B pretty well shut down
ietf-languages@=2C since there would be lit= tle or nothing left to approve
outside the 639 framework


= --_fbd96f50-6a33-4ed4-b234-a220f699b513_-- From randy_presuhn@mindspring.com Thu Mar 12 13:57:31 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1146128C1F7 for ; Thu, 12 Mar 2009 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz-EqSEZYkN9 for ; Thu, 12 Mar 2009 13:57:30 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 49E0F3A6805 for ; Thu, 12 Mar 2009 13:57:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=etNEc8gBsYYabt+gQOCf4r2SUDf81WYbMjLLlbMhaKeaOTz4S/G8YtmYhw6pUNB9; 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 [69.3.144.97] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lhryh-0001fe-9M for ltru@ietf.org; Thu, 12 Mar 2009 16:58:07 -0400 Message-ID: <00dd01c9a355$61153fe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 12 Mar 2009 13:59:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1739ec183e8a42ec65044face39c8088337350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.97 Subject: [Ltru] Wild card prefixes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 20:57:31 -0000 Hi - (Subject line changed to reflect the subject. PLEASE use a new subject line when you introduce a new issue!) > From: "CE Whitehead" > To: > Sent: Thursday, March 12, 2009 10:28 AM > Subject: Re: [Ltru] Geocoordinates ... > What is going to happen to the suggestion we allow wild cards > to be registered as prefixes & incorporate that into the next > draft of RFC 4646? > > Is that tabled too? Or was that never an option?; I recall only > Doug's saying that this addition was too late for the current > edition of 4646 & not that it would never be an option: ... As co-chair: There was no consensus to make such a change, and it was clear from the discussion that the text that at one time could be read as permitting them was not intended to do so. Your options, if you wish to pursue this: (1) you can appeal the decision on procedural grounds, claiming the co-chairs did not properly read WG consensus (2) you can appeal the decision on technical grounds, claiming that interoperability will be harmed by the failure to add this new feature (3) you can raise the issue in IETF last call, but you'd have to be able to convince the IETF at large that the working group got it wrong. I think pursuing this issue would be unproductive. Randy From randy_presuhn@mindspring.com Thu Mar 12 14:03:42 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D425428C24B for ; Thu, 12 Mar 2009 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnEtB0AJmeeK for ; Thu, 12 Mar 2009 14:03:42 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 09DFE3A6AA2 for ; Thu, 12 Mar 2009 14:03:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rKhX+0alfS1Ub7osMmT9JF+gEc8+Puc8GTm/H1TbRuC0OVaddTbAACJBOXtkik1e; 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 [69.3.144.97] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lhs4h-0006BX-9o for ltru@ietf.org; Thu, 12 Mar 2009 17:04:19 -0400 Message-ID: <00f201c9a356$3ed919a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 12 Mar 2009 14:05:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173177e724f678461824758c78b466f3bd4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.97 Subject: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 21:03:42 -0000 Hi - (changed subject line to reflect topic!) > From: "CE Whitehead" > To: > Sent: Thursday, March 12, 2009 10:28 AM > Subject: Re: [Ltru] Geocoordinates ... > (also where will ISO 639-6 data be looked at? at ietf?) As co-chair: Not here now. It's not currently in this WG charter, and I know of no other IETF working group that would be even remotely interested in it. Discussion whether it makes sense to request a charter update to include it *is* in order at this time, though the posts so far give little sense of urgency or enthusiasm. > Otherwise I haven't an informed opinion on the closing of this list or ISO 639-6; > > however I hope ietf will continue to let users apply for their own variant subtags. That's what 4646bis does, so I don't see how there's any issue. Randy From doug@ewellic.org Thu Mar 12 17:54:39 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244D83A67F2 for ; Thu, 12 Mar 2009 17:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-rknmmB5tQn for ; Thu, 12 Mar 2009 17:54:38 -0700 (PDT) Received: from smtpout04.prod.mesa1.secureserver.net (smtpout04-01.prod.mesa1.secureserver.net [64.202.165.196]) by core3.amsl.com (Postfix) with SMTP id 20F4B3A657C for ; Thu, 12 Mar 2009 17:54:37 -0700 (PDT) Received: (qmail 20810 invoked from network); 13 Mar 2009 00:55:15 -0000 Received: from unknown (67.166.27.148) by smtpout04.prod.mesa1.secureserver.net (64.202.165.196) with ESMTP; 13 Mar 2009 00:55:15 -0000 Message-ID: <784B8E0979414364BE42B0853194EBBB@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Mar 2009 18:55:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 00:54:39 -0000 CE Whitehead wrote: > . . . & all that's needed for now is to tag language use that's > current on the internet not the dialects and varieties used in every > corner of the globe, not till they get online; it's the need to look > at variants that might be overlooked with the overlooking perceived as > a political slight that makes it especially important to have a method > for registering new variants . . . ) I agree that ietf-languages and user-requested variants should be retained, but worrying about registering subtags to remove a perception of political bias is tantamount to confessing that our existing subtags are inherently filled with political bias. People need to understand that language tags and subtags are not about making political statements; they're about identifying content by language and language variety. We need to continue to drive that point home. And ietf-languages needs to continue to be vigilant in not accepting subtag applications or arguments that are primarily motivated by politics. There was too much of that already in the discussions about Belarusian variants. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From doug@ewellic.org Thu Mar 12 17:56:19 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3DC3A6C2C for ; Thu, 12 Mar 2009 17:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FAKE_REPLY_C=2.012, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAiSmZxhJ6d6 for ; Thu, 12 Mar 2009 17:56:18 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 9AD7C3A6ACB for ; Thu, 12 Mar 2009 17:56:18 -0700 (PDT) Received: (qmail 6112 invoked from network); 13 Mar 2009 00:56:56 -0000 Received: from unknown (67.166.27.148) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 13 Mar 2009 00:56:56 -0000 Message-ID: From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 12 Mar 2009 18:56:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 00:56:19 -0000 Randy Presuhn wrote: >> however I hope ietf will continue to let users apply for their own >> variant subtags. > > That's what 4646bis does, so I don't see how there's any issue. John had proposed doing away with this as unnecessary in an 4646ter era that included ISO 639-6. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From cewcathar@hotmail.com Fri Mar 13 10:45:48 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F293A6B19 for ; Fri, 13 Mar 2009 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpjZRP4FftWH for ; Fri, 13 Mar 2009 10:45:47 -0700 (PDT) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by core3.amsl.com (Postfix) with ESMTP id D40F63A6AD6 for ; Fri, 13 Mar 2009 10:45:46 -0700 (PDT) Received: from BLU109-W53 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 10:46:26 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_daede19b-63ff-4d80-8a11-3c0a03af1cbf_" X-Originating-IP: [198.252.156.11] From: CE Whitehead To: Date: Fri, 13 Mar 2009 13:46:25 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2009 17:46:26.0036 (UTC) FILETIME=[A1A1C340:01C9A403] Subject: Re: [Ltru] Geocoordinates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:45:48 -0000 --_daede19b-63ff-4d80-8a11-3c0a03af1cbf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. Hope user-requested variants continue=2C even if iso 639-6 is adopted = . . .=20 =20 From: "Doug Ewell" =20 Date: Thu=2C 12 Mar 2009 18:55:13 -0600 > CE Whitehead wrote: >> . . . & all that's needed for now is to tag language use that's current = on the internet not the dialects and varieties used in every corner of the = globe=2C not till they get online=3B it's the need to look at variants that= might be overlooked with the overlooking perceived as a political slight t= hat makes it especially important to have a method for registering new vari= ants . . . )=20 > I agree that ietf-languages and user-requested=20 > variants should be retained=2C but worrying about > registering subtags t= o remove a perception of political > bias is tantamount to confessing that = our existing > subtags are inherently filled with political bias.=20 Not necessarily intentionally filled with political bias=2C but when you ha= ve borders you have politics I suppose (that's what borders are: political= )--and not that political borders can be ignored in language description ei= ther. > People need to understand that language tags and > subtags are not about = making political statements=3B > they're about identifying content by langu= age and > language variety. We need to continue to drive that > point home.= And ietf-languages needs to continue to > be vigilant in not accepting sub= tag applications or > arguments that are primarily motivated by politics. > There was too much of that already in the discussions > about Belarusian = variants. But you did agree that if there were two varieties of Belarussian writing o= nline it was appropriate to have subtags for both. I do not object myself to people coming to the ietf-languages list with var= ious political agendas=2C and applying for a subtag=3B that's only natural and in many of those cases the need for a subtag is leg= itimate=2C whatever the motivation=3B=20 for example if you have a politically-motivated web site & in the political= ly-motivated articles you post there=20 you use a script that's recommended by a particular political group=2C=20 it's fine to come and ask for a subtag and let ietf screen the request to m= ake sure that they are not simply made to 'disenfranchise' other language v= arieties. (You want these people to feel warm and welcome here I guess.)=20 I suppose however that people can be asked to make comment about requests i= n a polite fashion??? (perhaps people can be=2C occasionally=2C even on the= internet) =20 --C. E. Whitehead cewcathar@hotmail.com=20 =20 > Doug Ewell * Thornton=2C Colorado=2C USA * RFC 4645 * UTN #14 =20 --_daede19b-63ff-4d80-8a11-3c0a03af1cbf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. =3B =3BHope user-requested variants continue=2C =3Beven if = iso 639-6 is adopted . . .

 =3B
From: "Doug Ewell" <=3Bdoug at ewellic.org>=3B =3B
Date: Thu=2C= 12 Mar 2009 18:55:13 -0600

>=3B CE Whitehead <=3Bcewcathar at hotmail dot com>=3B wrote:

>=3B>=3B . . . &=3B all that's needed for now is to tag language= use that's current on the internet not the dialects and varieties used in = every corner of the globe=2C not till they get online=3B it's the need to l= ook at variants that might be overlooked with the overlooking perceived as = a political slight that makes it especially important to have a method for = registering new variants . . . )

>=3B I agree that ietf-languages and user-requested
>=3B variants should be retained=2C but worrying about >=3B =3Bregi= stering subtags to remove a perception of political >=3B =3Bbias is t= antamount to confessing that our existing >=3B =3Bsubtags are inheren= tly filled with political bias.
Not necessarily intentionally filled with political bias=2C but when you ha= ve borders you have politics I suppose (that's what borders are: =3B po= litical)--and not that political borders can be ignored in language descrip= tion either.

>=3B People need to understand that language tags and >=3B =3Bs= ubtags are not about making political statements=3B >=3B =3Bthey're a= bout identifying content by language and >=3B =3Blanguage variety. We= need to continue to drive that >=3B =3Bpoint home. And ietf-language= s needs to continue to >=3B =3Bbe vigilant in not accepting subtag ap= plications or >=3B =3Barguments that are primarily motivated by polit= ics.
>=3B =3BThere was too much of that already in the discussions >=3B&= nbsp=3Babout Belarusian variants.
But you did agree that if there were two varieties of Belarussian writing o= nline it was appropriate to have subtags for both.
I do not object myself to people coming to the ietf-languages list with var= ious political agendas=2C and applying for a subtag=3B
that's only natur= al and in many of those cases the need for a subtag is legitimate=2C whatev= er the motivation=3B
for example if you have a politically-motivated we= b site &=3B in the politically-motivated articles you post there
you= use a script that's recommended by a particular political group=2C
it'= s fine to come and ask for a subtag and let ietf screen the request to make= sure that they are not simply =3Bmade to 'disenfranchise' other langua= ge varieties.
(You want these people to feel warm and welcome here I guess.) =3B
I= suppose however that people can be asked to make comment about requests in= a polite fashion??? (perhaps =3Bpeople can be=2C occasionally=2C even = on the internet)
 =3B
--C. E. Whitehead
cewcathar@hotmail.com
 =3B
>=3B Doug Ewell =3B * =3B Thornton=2C Colorado=2C USA =3B *&n= bsp=3B RFC 4645 =3B * =3B UTN #14
 =3B


= --_daede19b-63ff-4d80-8a11-3c0a03af1cbf_-- From cowan@ccil.org Fri Mar 13 14:52:45 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB40428C196 for ; Fri, 13 Mar 2009 14:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bkG51vwgw1B for ; Fri, 13 Mar 2009 14:52:45 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id E425E3A6830 for ; Fri, 13 Mar 2009 14:52:44 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1LiFJf-0004Xi-9U; Fri, 13 Mar 2009 17:53:19 -0400 Date: Fri, 13 Mar 2009 17:53:19 -0400 To: Doug Ewell Message-ID: <20090313215319.GF26454@mercury.ccil.org> References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <20090311152604.GA15999@mercury.ccil.org> <294D681B191C4449800450499A759B20@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <294D681B191C4449800450499A759B20@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:52:46 -0000 Doug Ewell scripsit: > Then if you like, view the "legacy" variants as warts on the side of a > collection of '6' variants. Doesn't matter; the warts are not going > away. True, but then the irregular tags aren't going away either: nonetheless, most of them can be easily deprecated. > Despite its size and ambitious goals, and the expertise of those > preparing it, I would be very surprised if 639-6 encompassed a proper > superset of everything that has ever been (a) registered in the Registry > or (b) taken seriously but not registered in the Registry, going back to > the whole tags registered under RFC 1766/3066. That is one of the major > problems with claiming that 639-6 will enable ietf-languages to be shut > down. Well, it may not contain them now, but if something is a language variant, it ought to have a 639-6 tag, because 639-6 is deliberately unselective. -- MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS John Cowan cowan@ccil.org http://www.ccil.org/~cowan From doug@ewellic.org Fri Mar 13 20:23:19 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8173A6B2D for ; Fri, 13 Mar 2009 20:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyaUwVT-1z6N for ; Fri, 13 Mar 2009 20:23:19 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 02D1B3A69EA for ; Fri, 13 Mar 2009 20:23:18 -0700 (PDT) Received: (qmail 22476 invoked from network); 14 Mar 2009 03:23:57 -0000 Received: from unknown (67.166.27.148) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 14 Mar 2009 03:23:57 -0000 Message-ID: <86E4BA031EEC47C28A1338227E2B9136@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 13 Mar 2009 21:23:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Ltru] Political motivation (was: Re: Geocoordinates) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 03:23:19 -0000 CE Whitehead wrote: >> There was too much of that already in the discussions about >> Belarusian variants. > > But you did agree that if there were two varieties of Belarussian > writing online it was appropriate to have subtags for both. Absolutely correct. But that does not mean the discussions needed to be characterized by each side accusing the other of political motives, or fighting over which variation was "better." Perhaps I should rephrase: ietf-languages needs to be vigilant in not accepting applications for subtags that don't represent legitimate differences, or arguments that imply that one variation is superior to another, due to such applications or arguments being primarily motivated by politics. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Fri Mar 13 23:37:34 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEAA728C0EC for ; Fri, 13 Mar 2009 23:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgN74x2N+eBE for ; Fri, 13 Mar 2009 23:37:34 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 3629928C0D8 for ; Fri, 13 Mar 2009 23:37:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rim59s4j6ouB+87GixeLYQZFTS0iilfbuXUCGdD2hS/tmeggenRsFFoVxllZ8Ir8; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.220] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LiNVd-0004KY-3W for ltru@ietf.org; Sat, 14 Mar 2009 02:38:13 -0400 Message-ID: <00da01c9a46f$95b8a140$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81><20090311152604.GA15999@mercury.ccil.org><294D681B191C4449800450499A759B20@DGBP7M81> <20090313215319.GF26454@mercury.ccil.org> Date: Fri, 13 Mar 2009 23:39:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17366fa7b972c0d2ff75034d87e87a38c76350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.220 Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 06:37:34 -0000 Hi - As co-chair... I don't see much progress in this discussion. I suggest that those wishing to see work in ltru on the use of ISO 639-6 as a source of subtags should submit a specific charter update proposal to this mailing list for discussion. Please refrain from further comment on this topic until someone provides a specific (i.e. containing dates and delivarables) charter update proposal. Randy From petercon@microsoft.com Mon Mar 16 22:10:12 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C903A684C for ; Mon, 16 Mar 2009 22:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1KEsnprhqez for ; Mon, 16 Mar 2009 22:10:10 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 037BA3A681A for ; Mon, 16 Mar 2009 22:10:09 -0700 (PDT) Received: from tk5-expfs-c106.redmond.corp.microsoft.com (157.54.69.40) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 16 Mar 2009 22:10:52 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-expfs-c106.redmond.corp.microsoft.com ([157.54.69.40]) with mapi; Mon, 16 Mar 2009 22:10:52 -0700 From: Peter Constable To: LTRU Working Group Date: Mon, 16 Mar 2009 22:10:51 -0700 Thread-Topic: [Ltru] ISO 639-6 Thread-Index: Acmkb62NQ6RhY5tBTWG6dmd+99buqQCTrcdw Message-ID: References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81><20090311152604.GA15999@mercury.ccil.org><294D681B191C4449800450499A759B20@DGBP7M81> <20090313215319.GF26454@mercury.ccil.org> <00da01c9a46f$95b8a140$6801a8c0@oemcomputer> In-Reply-To: <00da01c9a46f$95b8a140$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 05:10:12 -0000 Due to off-line mail I received in relation to some of my comments in this = thread, I feel I need to make one additional comment: The opinions I have expressed are my own and not those of my employer or an= y other party with whom I may be affiliated. Peter -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Ran= dy Presuhn Sent: Friday, March 13, 2009 11:39 PM To: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 Hi - As co-chair... I don't see much progress in this discussion. I suggest that those wishing to see work in ltru on the use of ISO 639-6 as a source of subtags should submit a specific charter update proposal to this mailing list for discussion. Please refrain from further comment on this topic until someone provides a specific (i.e. containing dates and delivarables) charter update proposal. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru From gerard.meijssen@gmail.com Tue Mar 17 01:16:08 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E1F28C125 for ; Tue, 17 Mar 2009 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+Vm1mV+a4VL for ; Tue, 17 Mar 2009 01:16:07 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id D48C13A6AD6 for ; Tue, 17 Mar 2009 01:16:06 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so53202fgb.41 for ; Tue, 17 Mar 2009 01:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0737Al5SDsMQPJ695nU63jeme2rLbnkELl0/GeM6zJ4=; b=TroGhCTw6wl6PUItJlzJkTSIthPE5Qvf7ONi0aRP80Z5I9kZDdiOgtIItvZ0OZG36Q N9W2rxJ2a1Ljn74kd1b9J/gH1otqtaPPZFT2D/9qGGxdKJxEnc3xyX+5SBDC3lw/TNrw A6kHnT48W0Mh7AwkfOT8D5u5rgpsb0xU7InhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G4LQ8bPKX/ixD2UPOmy3JtK8eVJc1MdTri5h8i7t+OIm06YV4vs7rvA4CBw1khjyGa lwrOaz6DKDBBMrUtlwj4/JNSX6RnHaiqom+b8b4IFW6kuI9QR25n+3X7BElT4FSwGh3W GOaIs7SsywjxkxF3OGKpcLGdkgVu/O2lgLWY8= MIME-Version: 1.0 Received: by 10.86.60.15 with SMTP id i15mr3165243fga.12.1237277808787; Tue, 17 Mar 2009 01:16:48 -0700 (PDT) In-Reply-To: References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <20090311152604.GA15999@mercury.ccil.org> <294D681B191C4449800450499A759B20@DGBP7M81> <20090313215319.GF26454@mercury.ccil.org> <00da01c9a46f$95b8a140$6801a8c0@oemcomputer> Date: Tue, 17 Mar 2009 09:16:48 +0100 Message-ID: <41a006820903170116y522fe14bnf6443efb7f0cfd66@mail.gmail.com> From: Gerard Meijssen To: Peter Constable Content-Type: multipart/alternative; boundary=000e0cd341004800ee04654c30b3 Cc: LTRU Working Group Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 08:16:08 -0000 --000e0cd341004800ee04654c30b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hoi, I found the reply that Peter made in his reply on the thread "Re: [Ltru] ISO 639-6 (was: Geocoordinates)" problematic. In it he said: "But I can tell you up front that I will most likely push back on a revision to make use of the reserved alpha-4 subtags not only because it's inconvenient for my derivative application but also because I remain very skeptical that there will be benefits (let alone ROI, considering the costs).". I find this problematic because it puts commercial interests clearly ahead of a structured approach that comes with the ISO-639-6. Now that Peter states that he is expressing his own opinions and not the opinion of Microsoft, I find the statement quoted above unacceptable. It is unacceptable because he is spouting FUD on a standard that intends to reconcile the different standards in one body, a standard that intends to finally give a place to the different orthographies. When Peter speaks for Microsoft about ROI and costs, I find it problematic because I wonder how he reconciles this with being a member of the community, when Peter "only" expresses his own opinion it becomes unacceptable to me because he clearly presents himself as a Microsoft employee. ROI and costs are business related considerations and making these "personal opinion" is disingenuous probably dishonest and in my opinion unacceptable. There are clear benefits to a standard that reconciles the current mess of ISO-639 standards that are problematic to reconcile and have made the current RFC process a waiting game. At this time there is no software that provides the "most basic" language support. The most basic language support is recognising that people want to write in their own language and enabling them to do so. Enabling this is nothing more then setting the appropriate meta data and allowing people to express themselves. The best argument against providing a "most basic" language support has been the standards do not support this and with "personal opinions" expressed in this way it is less likely when we will see the day that people can express themselves in their language. Thanks, Gerard 2009/3/17 Peter Constable > Due to off-line mail I received in relation to some of my comments in this > thread, I feel I need to make one additional comment: > > The opinions I have expressed are my own and not those of my employer or > any other party with whom I may be affiliated. > > > Peter > > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Randy Presuhn > Sent: Friday, March 13, 2009 11:39 PM > To: LTRU Working Group > Subject: Re: [Ltru] ISO 639-6 > > Hi - > > As co-chair... > > I don't see much progress in this discussion. I suggest that those > wishing to see work in ltru on the use of ISO 639-6 as a source of > subtags should submit a specific charter update proposal to this > mailing list for discussion. Please refrain from further comment > on this topic until someone provides a specific (i.e. containing dates > and delivarables) charter update proposal. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd341004800ee04654c30b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hoi,
I found the reply that Peter made in his reply on the thread "= Re: [Ltru] ISO 639-6 (was: Geocoordinates)" problematic. In it he said= : "But I can tell you up front that I will most likely push back on a revision to make use of the reserved alpha-4 subtags not only because it's inconvenient for my derivative application but also because I remain very skeptical that there will be benefits (let alone ROI, considering the costs).". I find this problematic because it puts comm= ercial interests clearly ahead of a structured approach that comes with the= ISO-639-6.

Now that Peter states that he is expressing his own opin= ions and not the opinion of Microsoft, I find the statement quoted above un= acceptable. It is unacceptable because he is spouting FUD on a standard tha= t intends to reconcile the different standards in one body, a standard that= intends to finally give a place to the different orthographies. When Peter= speaks for Microsoft about ROI and costs, I find it problematic because I = wonder how he reconciles this with being a member of the community, when Pe= ter "only" expresses his own opinion it becomes unacceptable to m= e because he clearly presents himself as a Microsoft employee. ROI and cost= s are business related=C2=A0 considerations and making these "personal= opinion" is disingenuous probably dishonest and in my opinion unaccep= table.

There are clear benefits to a standard that reconciles the current mess= of ISO-639 standards that are problematic to reconcile and have made the c= urrent RFC process a waiting game. At this time there is no software that p= rovides the "most basic" language support. The most basic languag= e support is recognising that people want to write in their own language an= d enabling them to do so. Enabling this is nothing more then setting the ap= propriate meta data and allowing people to express themselves. The best arg= ument against providing a "most basic" language support has been = the standards do not support this and with "personal opinions" ex= pressed in this way it is less likely when we will see the day that people = can express themselves in their language.
Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gerard

2009/3/17 Peter Constable <petercon@microsoft.com>
Due to off-line mail I received in relation to some of my comments in this = thread, I feel I need to make one additional comment:

The opinions I have expressed are my own and not those of my employer or an= y other party with whom I may be affiliated.


Peter

-----Original Message-----
From: ltru-bounces@ietf.org [m= ailto:ltru-bounces@ietf.org] O= n Behalf Of Randy Presuhn
Sent: Friday, March 13, 2009 11:39 PM
To: LTRU Working Group
Subject: Re: [Ltru] ISO 639-6

Hi -

As co-chair...

I don't see much progress in this discussion. =C2=A0I suggest that thos= e
wishing to see work in ltru on the use of ISO 639-6 as a source of
subtags should submit a specific charter update proposal to this
mailing list for discussion. =C2=A0Please refrain from further comment
on this topic until someone provides a specific (i.e. containing dates
and delivarables) charter update proposal.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd341004800ee04654c30b3-- From petercon@microsoft.com Tue Mar 17 05:18:25 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8013A6893 for ; Tue, 17 Mar 2009 05:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.998 X-Spam-Level: X-Spam-Status: No, score=-10.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCq3cfY8bOcz for ; Tue, 17 Mar 2009 05:18:22 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id ADF573A6841 for ; Tue, 17 Mar 2009 05:18:22 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 17 Mar 2009 05:19:02 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Tue, 17 Mar 2009 05:18:58 -0700 From: Peter Constable To: LTRU Working Group Date: Tue, 17 Mar 2009 05:18:56 -0700 Thread-Topic: [Ltru] ISO 639-6 Thread-Index: Acmm2QoMsxFOoKyLSv2EayRqz/CVyAAHXi+Q Message-ID: References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81> <20090311152604.GA15999@mercury.ccil.org> <294D681B191C4449800450499A759B20@DGBP7M81> <20090313215319.GF26454@mercury.ccil.org> <00da01c9a46f$95b8a140$6801a8c0@oemcomputer> <41a006820903170116y522fe14bnf6443efb7f0cfd66@mail.gmail.com> In-Reply-To: <41a006820903170116y522fe14bnf6443efb7f0cfd66@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E66AD75FNAEXMSGC117re_" MIME-Version: 1.0 Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 12:18:25 -0000 --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E66AD75FNAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIHByb3ZpZGUgdGhpcyByZXBseSBhbmQgdGhlbiBkcm9wIHRoZSBkaXNjdXNzaW9uLg0K DQpHZXJhcmQgYXBwZWFycyB0byBzdXBwb3NlIHRoYXQsIHNpbmNlIEkgcmVmZXIgdG8g4oCcUk9J 4oCdLCBJIG11c3QgYmUgc3BlYWtpbmcgb24gYmVoYWxmIG9mIE1pY3Jvc29mdC4gVGhhdCBpcyBz aW1wbHkgbm90IHRoZSBjYXNlLiBJIHdhcyBzcGVha2luZyBhcyBhIGxhbmd1YWdlIHRlY2hub2xv Z2lzdCBleHByZXNzaW5nIG15IHRob3VnaHRzIG9uIHdoYXQgYmVuZWZpdHMsIGluIHByYWN0aWNh bCB0ZXJtcywgSSB0aGluayB3b3VsZCBhY2NydWUgdG8gbGFuZ3VhZ2UgY29tbXVuaXRpZXMgYXJv dW5kIHRoZSB3b3JsZC4gQmVuZWZpdHMgYXJlIG5vdCByZWFsaXplZCBzaW1wbHkgYnkgaGF2aW5n IGEgdGFnZ2luZyBzeXN0ZW0gdGhhdCBjb21lcyB3aXRoIHRlbnMgb2YgdGhvdXNhbmRzIG9mIGFs cmVhZHktc2FuY3Rpb25lZCBlbGVtZW50cy4gUmF0aGVyLCBiZW5lZml0cyBhcmUgcmVhbGl6ZWQg YnkgaGF2aW5nIGEgdGFnZ2luZyBzeXN0ZW0gdGhhdCBhY2NvbW1vZGF0ZXMgdGhlaXIgbmVlZHMg KmFuZCogdGhhdCB3b3JrcyBpbiBwcmFjdGljZSBhbmQgaXMgd2lkZWx5IHN1cHBvcnRlZC4gSSBh bSBzdHJvbmdseSBpbmZsdWVuY2VkIGJ5IHRob3NlIHByYWN0aWNhbCBjb25zaWRlcmF0aW9ucyBm cm9tIHRpbWUgSSBzcGVudCBpbiBhIG5vdC1mb3ItcHJvZml0IG9yZ2FuaXphdGlvbiwgcHJpb3Ig dG8gd29ya2luZyBmb3IgTWljcm9zb2Z0LCB0cnlpbmcgdG8gZmluZCB0ZWNobm9sb2d5IHNvbHV0 aW9ucyBmb3IgdGhvdXNhbmRzIG9mIGxhbmd1YWdlIHdvcmtlcnMgd29ya2luZyBpbiBkaXZlcnMg bGFuZ3VhZ2UgY29tbXVuaXRpZXMgdGhyb3VnaG91dCB0aGUgd29ybGQsIHdpdGggc2l6ZWFibGUg aW52ZXN0bWVudHMgbWFkZSBpbiBzb2x1dGlvbnMgdGhhdCB3ZXJlICpub3QqIHdpZGVseSBhZG9w dGVkIGluIGluZHVzdHJ5LiBTdWNoIHNvbHV0aW9ucyBkaWQgbm90IHNjYWxlIGFuZCBmb3N0ZXJl ZCBkZXBlbmRlbmNlIG9uIGEgc21hbGwgc3VwcG9ydCBpbmZyYXN0cnVjdHVyZSByYXRoZXIgdGhh biBnaXZpbmcgbG9uZy10ZXJtIGVtcG93ZXJtZW50Lg0KDQpJbiBmYWN0LCB0aGUgb3BpbmlvbnMg SSB3YXMgZXhwcmVzc2luZyB3ZXJlIGluIGxpbmUgd2l0aCBhbiBvcGluaW9uIEkgZm9ybWVkIHNv bWUgeWVhcnMgYmVmb3JlIEkgc3RhcnRlZCB0byB3b3JrIGF0IE1pY3Jvc29mdDogdGhhdCBzdWIt bGFuZ3VhZ2UgdmFyaWF0aW9ucyBhcmUgbm90IGFwcHJvcHJpYXRlIG9iamVjdHMgZm9yIGEgY29t cHJlaGVuc2l2ZSBlbmNvZGluZyBiZWNhdXNlIHRoZXJl4oCZcyBubyBjbGVhciB3YXkgdG8gZGVm aW5lIGRpYWxlY3RzLiBJIGZpcnN0IGRpc2N1c3NlZCB0aGlzIGluIDIwMDAsIGJ1dCB0aGUgZmly c3QgdGltZSBJIHB1Ymxpc2hlZCBtYXkgaGF2ZSBiZWVuIGluIGEgcGFwZXIgSSBwcmVzZW50ZWQg dG8gYSBVbmljb2RlIGNvbmZlcmVuY2UgaW4gMjAwMi4gVGhlIGZ1bGwgcGFwZXIgaXMgYXZhaWxh YmxlIGhlcmU6DQoNCmh0dHA6Ly93d3cuc2lsLm9yZy9zaWxld3AvMjAwMi9TSUxFV1AyMDAyLTAw My5wZGYNCg0KU2VlIHNlY3Rpb24gNC42LCBwLiAyOWY6DQoNCuKAnEl0IHdhcw0KY2xhaW1lZCBl YXJsaWVyIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gZW51bWVyYXRlIGEgY29tcHJlaGVuc2l2ZSBs aXN0IG9mIGluZGl2aWR1YWwgbGFuZ3VhZ2VzIGJhc2VkDQpvbiBhIHBhcnRpY3VsYXIgb3BlcmF0 aW9uYWwgZGVmaW5pdGlvbuKAlHRvIOKAnHRpbGUgdGhlIHBsYW5l4oCdIG9mIGxhbmd1YWdlcy4g SW4gY29udHJhc3QsIHRoaXMgaXMsIGluDQpwcmluY2lwbGUsIGltcG9zc2libGUgZm9yIGRpYWxl Y3RzLiBUaGUgcmVhc29uIGhhcyB0byBkbyB3aXRoIG9wZXJhdGlvbmFsIGRlZmluaXRpb25z4oCm LuKAnQ0KDQpJIHNpbXBseSBob2xkIHRoZSBzYW1lIHZpZXdzIHRoYXQgSSBoYWQgdGhlbi4NCg0K SeKAmW0gY29tcGxldGVseSBpbiBmYXZvdXIgb2YgZG9pbmcgd2hhdCBpcyBnb29kIGZvciBnb29k bmVzcyBzYWtlLiBUaGF0IGlzIHdoYXQgaGFzIG1vdGl2YXRlZCBteSB3b3JrIG92ZXIgdGhlIHBh c3QgbWFueSB5ZWFycyBpbiBjaGFyYWN0ZXIgZW5jb2RpbmcgYW5kIHRvIGRldmVsb3AgSVNPIDYz OS0zIGFuZCBnZXQgaXQgaW5jb3Jwb3JhdGVkIGludG8gQkNQIDQ3IOKAkyBJIHRoaW5rIHRob3Nl IGhhdmUgYmVlbiBzdGVwcyB0b3dhcmQgZ29vZG5lc3MgZnJvbSB3aGVyZSB3ZSB3ZXJlIGJlZm9y ZS4gKEdlcmFyZCBtYXkgdGhpbmsgSVNPIDYzOSBpcyBhIG1lc3MsIGJ1dCBJTU8gaXTigJlzIGxl c3Mgb2YgYSBtZXNzIGFuZCBhIG1vcmUgd2VsbC1kZWZpbmVkIG9uZSB0aGFuIGl0IHVzZWQgdG8g YmUuKQ0KDQpJIHJlbWFpbiB1bmNvbnZpbmNlZCB0aGF0IElTTyA2MzktNiB3aWxsLCBvbiB0aGUg YmFsYW5jZSwgcHJvdmlkZSBvdmVyYWxsIGdvb2RuZXNzIHRvIEJDUCA0Ny4gRXZlbiBzbywgSSBo YXZlbuKAmXQgZG9uZSBhbnl0aGluZyB0byBzdGFuZCBpbiB0aGUgd2F5IG9mIElTTyA2MzktNiBh cyBhbiBJU08gc3RhbmRhcmQsIGFuZCBJIHdvdWxkbuKAmXQgbmVjZXNzYXJpbHkgb3Bwb3NlIGEg cmV2aXNpb24gdG8gQkNQIDQ3IHRvIGFsbG93IElTTyA2MzktNiBzdWJ0YWdzIOKAkyBkZXBlbmRp bmcgb24gaG93IGl0IGlzIGhhbmRsZWQuIEFsbCB0aGF0IEkgc2FpZCBpbiB0aGlzIHRocmVhZCBJ IHdvdWxkIG5vdCBzdXBwb3J0IGlzIHB1dHRpbmcgdGhlc2UgaW4gdGhlIHJlc2VydmVkIGFscGhh LTQgc3VidGFncy4gSSBoYXZlIHZhcmlvdXMgcmVhc29ucyBmb3IgdGhhdCwgYnV0IEnigJlsbCBy ZWZyYWluIGZyb20gZ29pbmcgZnVydGhlciBpbiByZXNwZWN0IG9mIFJhbmR54oCZcyByZXF1ZXN0 Lg0KDQoNClBldGVyDQoNCg0KRnJvbTogR2VyYXJkIE1laWpzc2VuIFttYWlsdG86Z2VyYXJkLm1l aWpzc2VuQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDA5IDE6MTcgQU0N ClRvOiBQZXRlciBDb25zdGFibGUNCkNjOiBMVFJVIFdvcmtpbmcgR3JvdXANClN1YmplY3Q6IFJl OiBbTHRydV0gSVNPIDYzOS02DQoNCkhvaSwNCkkgZm91bmQgdGhlIHJlcGx5IHRoYXQgUGV0ZXIg bWFkZSBpbiBoaXMgcmVwbHkgb24gdGhlIHRocmVhZCAiUmU6IFtMdHJ1XSBJU08gNjM5LTYgKHdh czogR2VvY29vcmRpbmF0ZXMpIiBwcm9ibGVtYXRpYy4gSW4gaXQgaGUgc2FpZDogIkJ1dCBJIGNh biB0ZWxsIHlvdSB1cCBmcm9udCB0aGF0IEkgd2lsbCBtb3N0IGxpa2VseSBwdXNoIGJhY2sgb24g YSByZXZpc2lvbiB0byBtYWtlIHVzZSBvZiB0aGUgcmVzZXJ2ZWQgYWxwaGEtNCBzdWJ0YWdzIG5v dCBvbmx5IGJlY2F1c2UgaXQncyBpbmNvbnZlbmllbnQgZm9yIG15IGRlcml2YXRpdmUgYXBwbGlj YXRpb24gYnV0IGFsc28gYmVjYXVzZSBJIHJlbWFpbiB2ZXJ5IHNrZXB0aWNhbCB0aGF0IHRoZXJl IHdpbGwgYmUgYmVuZWZpdHMgKGxldCBhbG9uZSBST0ksIGNvbnNpZGVyaW5nIHRoZSBjb3N0cyku Ii4gSSBmaW5kIHRoaXMgcHJvYmxlbWF0aWMgYmVjYXVzZSBpdCBwdXRzIGNvbW1lcmNpYWwgaW50 ZXJlc3RzIGNsZWFybHkgYWhlYWQgb2YgYSBzdHJ1Y3R1cmVkIGFwcHJvYWNoIHRoYXQgY29tZXMg d2l0aCB0aGUgSVNPLTYzOS02Lg0KDQpOb3cgdGhhdCBQZXRlciBzdGF0ZXMgdGhhdCBoZSBpcyBl eHByZXNzaW5nIGhpcyBvd24gb3BpbmlvbnMgYW5kIG5vdCB0aGUgb3BpbmlvbiBvZiBNaWNyb3Nv ZnQsIEkgZmluZCB0aGUgc3RhdGVtZW50IHF1b3RlZCBhYm92ZSB1bmFjY2VwdGFibGUuIEl0IGlz IHVuYWNjZXB0YWJsZSBiZWNhdXNlIGhlIGlzIHNwb3V0aW5nIEZVRCBvbiBhIHN0YW5kYXJkIHRo YXQgaW50ZW5kcyB0byByZWNvbmNpbGUgdGhlIGRpZmZlcmVudCBzdGFuZGFyZHMgaW4gb25lIGJv ZHksIGEgc3RhbmRhcmQgdGhhdCBpbnRlbmRzIHRvIGZpbmFsbHkgZ2l2ZSBhIHBsYWNlIHRvIHRo ZSBkaWZmZXJlbnQgb3J0aG9ncmFwaGllcy4gV2hlbiBQZXRlciBzcGVha3MgZm9yIE1pY3Jvc29m dCBhYm91dCBST0kgYW5kIGNvc3RzLCBJIGZpbmQgaXQgcHJvYmxlbWF0aWMgYmVjYXVzZSBJIHdv bmRlciBob3cgaGUgcmVjb25jaWxlcyB0aGlzIHdpdGggYmVpbmcgYSBtZW1iZXIgb2YgdGhlIGNv bW11bml0eSwgd2hlbiBQZXRlciAib25seSIgZXhwcmVzc2VzIGhpcyBvd24gb3BpbmlvbiBpdCBi ZWNvbWVzIHVuYWNjZXB0YWJsZSB0byBtZSBiZWNhdXNlIGhlIGNsZWFybHkgcHJlc2VudHMgaGlt c2VsZiBhcyBhIE1pY3Jvc29mdCBlbXBsb3llZS4gUk9JIGFuZCBjb3N0cyBhcmUgYnVzaW5lc3Mg cmVsYXRlZCAgY29uc2lkZXJhdGlvbnMgYW5kIG1ha2luZyB0aGVzZSAicGVyc29uYWwgb3Bpbmlv biIgaXMgZGlzaW5nZW51b3VzIHByb2JhYmx5IGRpc2hvbmVzdCBhbmQgaW4gbXkgb3BpbmlvbiB1 bmFjY2VwdGFibGUuDQoNClRoZXJlIGFyZSBjbGVhciBiZW5lZml0cyB0byBhIHN0YW5kYXJkIHRo YXQgcmVjb25jaWxlcyB0aGUgY3VycmVudCBtZXNzIG9mIElTTy02Mzkgc3RhbmRhcmRzIHRoYXQg YXJlIHByb2JsZW1hdGljIHRvIHJlY29uY2lsZSBhbmQgaGF2ZSBtYWRlIHRoZSBjdXJyZW50IFJG QyBwcm9jZXNzIGEgd2FpdGluZyBnYW1lLiBBdCB0aGlzIHRpbWUgdGhlcmUgaXMgbm8gc29mdHdh cmUgdGhhdCBwcm92aWRlcyB0aGUgIm1vc3QgYmFzaWMiIGxhbmd1YWdlIHN1cHBvcnQuIFRoZSBt b3N0IGJhc2ljIGxhbmd1YWdlIHN1cHBvcnQgaXMgcmVjb2duaXNpbmcgdGhhdCBwZW9wbGUgd2Fu dCB0byB3cml0ZSBpbiB0aGVpciBvd24gbGFuZ3VhZ2UgYW5kIGVuYWJsaW5nIHRoZW0gdG8gZG8g c28uIEVuYWJsaW5nIHRoaXMgaXMgbm90aGluZyBtb3JlIHRoZW4gc2V0dGluZyB0aGUgYXBwcm9w cmlhdGUgbWV0YSBkYXRhIGFuZCBhbGxvd2luZyBwZW9wbGUgdG8gZXhwcmVzcyB0aGVtc2VsdmVz LiBUaGUgYmVzdCBhcmd1bWVudCBhZ2FpbnN0IHByb3ZpZGluZyBhICJtb3N0IGJhc2ljIiBsYW5n dWFnZSBzdXBwb3J0IGhhcyBiZWVuIHRoZSBzdGFuZGFyZHMgZG8gbm90IHN1cHBvcnQgdGhpcyBh bmQgd2l0aCAicGVyc29uYWwgb3BpbmlvbnMiIGV4cHJlc3NlZCBpbiB0aGlzIHdheSBpdCBpcyBs ZXNzIGxpa2VseSB3aGVuIHdlIHdpbGwgc2VlIHRoZSBkYXkgdGhhdCBwZW9wbGUgY2FuIGV4cHJl c3MgdGhlbXNlbHZlcyBpbiB0aGVpciBsYW5ndWFnZS4NClRoYW5rcywNCiAgICAgICAgR2VyYXJk DQoyMDA5LzMvMTcgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPG1haWx0 bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tPj4NCkR1ZSB0byBvZmYtbGluZSBtYWlsIEkgcmVjZWl2 ZWQgaW4gcmVsYXRpb24gdG8gc29tZSBvZiBteSBjb21tZW50cyBpbiB0aGlzIHRocmVhZCwgSSBm ZWVsIEkgbmVlZCB0byBtYWtlIG9uZSBhZGRpdGlvbmFsIGNvbW1lbnQ6DQoNClRoZSBvcGluaW9u cyBJIGhhdmUgZXhwcmVzc2VkIGFyZSBteSBvd24gYW5kIG5vdCB0aG9zZSBvZiBteSBlbXBsb3ll ciBvciBhbnkgb3RoZXIgcGFydHkgd2l0aCB3aG9tIEkgbWF5IGJlIGFmZmlsaWF0ZWQuDQoNCg0K UGV0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGx0cnUtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmx0cnUtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bHRydS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJh bmR5IFByZXN1aG4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTMsIDIwMDkgMTE6MzkgUE0NClRvOiBM VFJVIFdvcmtpbmcgR3JvdXANClN1YmplY3Q6IFJlOiBbTHRydV0gSVNPIDYzOS02DQoNCkhpIC0N Cg0KQXMgY28tY2hhaXIuLi4NCg0KSSBkb24ndCBzZWUgbXVjaCBwcm9ncmVzcyBpbiB0aGlzIGRp c2N1c3Npb24uICBJIHN1Z2dlc3QgdGhhdCB0aG9zZQ0Kd2lzaGluZyB0byBzZWUgd29yayBpbiBs dHJ1IG9uIHRoZSB1c2Ugb2YgSVNPIDYzOS02IGFzIGEgc291cmNlIG9mDQpzdWJ0YWdzIHNob3Vs ZCBzdWJtaXQgYSBzcGVjaWZpYyBjaGFydGVyIHVwZGF0ZSBwcm9wb3NhbCB0byB0aGlzDQptYWls aW5nIGxpc3QgZm9yIGRpc2N1c3Npb24uICBQbGVhc2UgcmVmcmFpbiBmcm9tIGZ1cnRoZXIgY29t bWVudA0Kb24gdGhpcyB0b3BpYyB1bnRpbCBzb21lb25lIHByb3ZpZGVzIGEgc3BlY2lmaWMgKGku ZS4gY29udGFpbmluZyBkYXRlcw0KYW5kIGRlbGl2YXJhYmxlcykgY2hhcnRlciB1cGRhdGUgcHJv cG9zYWwuDQoNClJhbmR5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpMdHJ1IG1haWxpbmcgbGlzdA0KTHRydUBpZXRmLm9yZzxtYWlsdG86THRydUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBtYWls aW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmc8bWFpbHRvOkx0cnVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E66AD75FNAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczptdD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvbWVldGluZ3MvIiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvZXhjZWwvMjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53 My5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vZGF0YS91ZGMiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEiIHhtbG5zOnN1Yj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3Nv YXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5zOmVjPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3ht bGVuYyMiIHhtbG5zOnNwPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv IiB4bWxuczpzcHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2Fw LyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIg eG1sbnM6dWRjcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9zb2FwIiB4 bWxuczp1ZGN4Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMvcGFy dHRvcGFydCIgeG1sbnM6d2Y9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL3dvcmtmbG93LyIgeG1sbnM6ZHNzcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2k9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvZGlnc2lnIiB4bWxuczptZHNzaT0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9kaWdpdGFsLXNpZ25hdHVyZSIgeG1s bnM6bXZlcj0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRp YmlsaXR5LzIwMDYiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl LzIwMDQvMTIvb21tbCIgeG1sbnM6bXJlbHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRz Lm9yZy9wYWNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6c3B3cD0iaHR0cDovL21pY3Jv c29mdC5jb20vc2hhcmVwb2ludC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0PSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYvdHlwZXMiIHhtbG5zOmV4 MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv bWVzc2FnZXMiIHhtbG5zOnBwdHNsPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJl cG9pbnQvc29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsPSJodHRwOi8vbWljcm9zb2Z0LmNv bS93ZWJzZXJ2aWNlcy9TaGFyZVBvaW50UG9ydGFsU2VydmVyL1B1Ymxpc2hlZExpbmtzU2Vydmlj ZSIgeG1sbnM6Wj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbToiIHhtbG5zOnN0PSImIzE7IiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEg aHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04 Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0 ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5 IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUaW1lc05ld1Jv bWFuOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz5J4oCZbGwgcHJvdmlkZSB0aGlzIHJlcGx5IGFuZCB0aGVuIGRyb3Ag dGhlIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5HZXJhcmQgYXBw ZWFycyB0byBzdXBwb3NlIHRoYXQsIHNpbmNlIEkgcmVmZXIgdG8g4oCcUk9J4oCdLCBJIG11c3QN CmJlIHNwZWFraW5nIG9uIGJlaGFsZiBvZiBNaWNyb3NvZnQuIFRoYXQgaXMgc2ltcGx5IG5vdCB0 aGUgY2FzZS4gSSB3YXMgc3BlYWtpbmcNCmFzIGEgbGFuZ3VhZ2UgdGVjaG5vbG9naXN0IGV4cHJl c3NpbmcgbXkgdGhvdWdodHMgb24gd2hhdCBiZW5lZml0cywgaW4NCnByYWN0aWNhbCB0ZXJtcywg SSB0aGluayB3b3VsZCBhY2NydWUgdG8gbGFuZ3VhZ2UgY29tbXVuaXRpZXMgYXJvdW5kIHRoZSB3 b3JsZC4NCkJlbmVmaXRzIGFyZSBub3QgcmVhbGl6ZWQgc2ltcGx5IGJ5IGhhdmluZyBhIHRhZ2dp bmcgc3lzdGVtIHRoYXQgY29tZXMgd2l0aA0KdGVucyBvZiB0aG91c2FuZHMgb2YgYWxyZWFkeS1z YW5jdGlvbmVkIGVsZW1lbnRzLiBSYXRoZXIsIGJlbmVmaXRzIGFyZSByZWFsaXplZA0KYnkgaGF2 aW5nIGEgdGFnZ2luZyBzeXN0ZW0gdGhhdCBhY2NvbW1vZGF0ZXMgdGhlaXIgbmVlZHMgKjxiPmFu ZDwvYj4qIHRoYXQNCndvcmtzIGluIHByYWN0aWNlIGFuZCBpcyB3aWRlbHkgc3VwcG9ydGVkLiBJ IGFtIHN0cm9uZ2x5IGluZmx1ZW5jZWQgYnkgdGhvc2UNCnByYWN0aWNhbCBjb25zaWRlcmF0aW9u cyBmcm9tIHRpbWUgSSBzcGVudCBpbiBhIG5vdC1mb3ItcHJvZml0IG9yZ2FuaXphdGlvbiwgcHJp b3INCnRvIHdvcmtpbmcgZm9yIE1pY3Jvc29mdCwgdHJ5aW5nIHRvIGZpbmQgdGVjaG5vbG9neSBz b2x1dGlvbnMgZm9yIHRob3VzYW5kcyBvZiBsYW5ndWFnZQ0Kd29ya2VycyB3b3JraW5nIGluIGRp dmVycyBsYW5ndWFnZSBjb21tdW5pdGllcyB0aHJvdWdob3V0IHRoZSB3b3JsZCwgd2l0aA0Kc2l6 ZWFibGUgaW52ZXN0bWVudHMgbWFkZSBpbiBzb2x1dGlvbnMgdGhhdCB3ZXJlICo8Yj5ub3Q8L2I+ KiB3aWRlbHkgYWRvcHRlZCBpbg0KaW5kdXN0cnkuIFN1Y2ggc29sdXRpb25zIGRpZCBub3Qgc2Nh bGUgYW5kIGZvc3RlcmVkIGRlcGVuZGVuY2Ugb24gYSBzbWFsbA0Kc3VwcG9ydCBpbmZyYXN0cnVj dHVyZSByYXRoZXIgdGhhbiBnaXZpbmcgbG9uZy10ZXJtIGVtcG93ZXJtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+SW4gZmFjdCwgdGhlIG9waW5pb25zIEkgd2FzIGV4cHJlc3Np bmcgd2VyZSBpbiBsaW5lIHdpdGggYW4gb3Bpbmlvbg0KSSBmb3JtZWQgc29tZSB5ZWFycyBiZWZv cmUgSSBzdGFydGVkIHRvIHdvcmsgYXQgTWljcm9zb2Z0OiB0aGF0IHN1Yi1sYW5ndWFnZQ0KdmFy aWF0aW9ucyBhcmUgbm90IGFwcHJvcHJpYXRlIG9iamVjdHMgZm9yIGEgY29tcHJlaGVuc2l2ZSBl bmNvZGluZyBiZWNhdXNlDQp0aGVyZeKAmXMgbm8gY2xlYXIgd2F5IHRvIGRlZmluZSBkaWFsZWN0 cy4gSSBmaXJzdCBkaXNjdXNzZWQgdGhpcyBpbiAyMDAwLCBidXQgdGhlDQpmaXJzdCB0aW1lIEkg cHVibGlzaGVkIG1heSBoYXZlIGJlZW4gaW4gYSBwYXBlciBJIHByZXNlbnRlZCB0byBhIFVuaWNv ZGUNCmNvbmZlcmVuY2UgaW4gMjAwMi4gVGhlIGZ1bGwgcGFwZXIgaXMgYXZhaWxhYmxlIGhlcmU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vd3d3LnNpbC5v cmcvc2lsZXdwLzIwMDIvU0lMRVdQMjAwMi0wMDMucGRmIj5odHRwOi8vd3d3LnNpbC5vcmcvc2ls ZXdwLzIwMDIvU0lMRVdQMjAwMi0wMDMucGRmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+U2VlIHNlY3Rpb24gNC42LCBwLiAyOWY6PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFj ZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCcPC9zcGFuPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiVGltZXNOZXdSb21hbiIsInNlcmlmIic+SXQg d2FzPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1m YW1pbHk6IlRpbWVzTmV3Um9tYW4iLCJzZXJpZiInPmNsYWltZWQgZWFybGllciB0aGF0IGl0IGlz IHBvc3NpYmxlIHRvDQplbnVtZXJhdGUgYSBjb21wcmVoZW5zaXZlIGxpc3Qgb2YgaW5kaXZpZHVh bCBsYW5ndWFnZXMgYmFzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7DQpmb250LWZhbWlseToiVGltZXNOZXdSb21hbiIsInNlcmlmIic+b24gYSBwYXJ0aWN1 bGFyIG9wZXJhdGlvbmFsIGRlZmluaXRpb27igJR0bw0K4oCcdGlsZSB0aGUgcGxhbmXigJ0gb2Yg bGFuZ3VhZ2VzLiBJbiBjb250cmFzdCwgdGhpcyBpcywgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiVGltZXNOZXdSb21hbiIsInNlcmlmIic+cHJpbmNpcGxlLA0KaW1wb3NzaWJsZSBm b3IgZGlhbGVjdHMuIFRoZSByZWFzb24gaGFzIHRvIGRvIHdpdGggb3BlcmF0aW9uYWwgZGVmaW5p dGlvbnPigKYuPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+SSBzaW1wbHkgaG9sZCB0aGUgc2FtZSB2aWV3cyB0aGF0IEkgaGFk IHRoZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5J4oCZbSBjb21wbGV0ZWx5IGlu IGZhdm91ciBvZiBkb2luZyB3aGF0IGlzIGdvb2QgZm9yIGdvb2RuZXNzIHNha2UuDQpUaGF0IGlz IHdoYXQgaGFzIG1vdGl2YXRlZCBteSB3b3JrIG92ZXIgdGhlIHBhc3QgbWFueSB5ZWFycyBpbiBj aGFyYWN0ZXINCmVuY29kaW5nIGFuZCB0byBkZXZlbG9wIElTTyA2MzktMyBhbmQgZ2V0IGl0IGlu Y29ycG9yYXRlZCBpbnRvIEJDUCA0NyDigJMgSSB0aGluaw0KdGhvc2UgaGF2ZSBiZWVuIHN0ZXBz IHRvd2FyZCBnb29kbmVzcyBmcm9tIHdoZXJlIHdlIHdlcmUgYmVmb3JlLiAoR2VyYXJkIG1heQ0K dGhpbmsgSVNPIDYzOSBpcyBhIG1lc3MsIGJ1dCBJTU8gaXTigJlzIGxlc3Mgb2YgYSBtZXNzIGFu ZCBhIG1vcmUgd2VsbC1kZWZpbmVkDQpvbmUgdGhhbiBpdCB1c2VkIHRvIGJlLik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkkgcmVtYWluIHVuY29udmluY2VkIHRoYXQgSVNPIDYzOS02 IHdpbGwsIG9uIHRoZSBiYWxhbmNlLA0KcHJvdmlkZSBvdmVyYWxsIGdvb2RuZXNzIHRvIEJDUCA0 Ny4gRXZlbiBzbywgSSBoYXZlbuKAmXQgZG9uZSBhbnl0aGluZyB0byBzdGFuZA0KaW4gdGhlIHdh eSBvZiBJU08gNjM5LTYgYXMgYW4gSVNPIHN0YW5kYXJkLCBhbmQgSSB3b3VsZG7igJl0IG5lY2Vz c2FyaWx5IG9wcG9zZSBhDQpyZXZpc2lvbiB0byBCQ1AgNDcgdG8gYWxsb3cgSVNPIDYzOS02IHN1 YnRhZ3Mg4oCTIGRlcGVuZGluZyBvbiBob3cgaXQgaXMgaGFuZGxlZC4NCkFsbCB0aGF0IEkgc2Fp ZCBpbiB0aGlzIHRocmVhZCBJIHdvdWxkIG5vdCBzdXBwb3J0IGlzIHB1dHRpbmcgdGhlc2UgaW4g dGhlDQpyZXNlcnZlZCBhbHBoYS00IHN1YnRhZ3MuIEkgaGF2ZSB2YXJpb3VzIHJlYXNvbnMgZm9y IHRoYXQsIGJ1dCBJ4oCZbGwgcmVmcmFpbg0KZnJvbSBnb2luZyBmdXJ0aGVyIGluIHJlc3BlY3Qg b2YgUmFuZHnigJlzIHJlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+UGV0ZXI8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gR2VyYXJkIE1laWpzc2VuDQpbbWFpbHRvOmdl cmFyZC5tZWlqc3NlbkBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJj aCAxNywgMjAwOSAxOjE3IEFNPGJyPg0KPGI+VG86PC9iPiBQZXRlciBDb25zdGFibGU8YnI+DQo8 Yj5DYzo8L2I+IExUUlUgV29ya2luZyBHcm91cDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0x0 cnVdIElTTyA2MzktNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+SG9pLDxicj4NCkkgZm91bmQgdGhlIHJlcGx5IHRo YXQgUGV0ZXIgbWFkZSBpbiBoaXMgcmVwbHkgb24gdGhlIHRocmVhZCAmcXVvdDtSZTogW0x0cnVd DQpJU08gNjM5LTYgKHdhczogR2VvY29vcmRpbmF0ZXMpJnF1b3Q7IHByb2JsZW1hdGljLiBJbiBp dCBoZSBzYWlkOiAmcXVvdDtCdXQgSQ0KY2FuIHRlbGwgeW91IHVwIGZyb250IHRoYXQgSSB3aWxs IG1vc3QgbGlrZWx5IHB1c2ggYmFjayBvbiBhIHJldmlzaW9uIHRvIG1ha2UNCnVzZSBvZiB0aGUg cmVzZXJ2ZWQgYWxwaGEtNCBzdWJ0YWdzIG5vdCBvbmx5IGJlY2F1c2UgaXQncyBpbmNvbnZlbmll bnQgZm9yIG15DQpkZXJpdmF0aXZlIGFwcGxpY2F0aW9uIGJ1dCBhbHNvIGJlY2F1c2UgSSByZW1h aW4gdmVyeSBza2VwdGljYWwgdGhhdCB0aGVyZSB3aWxsDQpiZSBiZW5lZml0cyAobGV0IGFsb25l IFJPSSwgY29uc2lkZXJpbmcgdGhlIGNvc3RzKS4mcXVvdDsuIEkgZmluZCB0aGlzDQpwcm9ibGVt YXRpYyBiZWNhdXNlIGl0IHB1dHMgY29tbWVyY2lhbCBpbnRlcmVzdHMgY2xlYXJseSBhaGVhZCBv ZiBhIHN0cnVjdHVyZWQNCmFwcHJvYWNoIHRoYXQgY29tZXMgd2l0aCB0aGUgSVNPLTYzOS02Ljxi cj4NCjxicj4NCk5vdyB0aGF0IFBldGVyIHN0YXRlcyB0aGF0IGhlIGlzIGV4cHJlc3NpbmcgaGlz IG93biBvcGluaW9ucyBhbmQgbm90IHRoZQ0Kb3BpbmlvbiBvZiBNaWNyb3NvZnQsIEkgZmluZCB0 aGUgc3RhdGVtZW50IHF1b3RlZCBhYm92ZSB1bmFjY2VwdGFibGUuIEl0IGlzDQp1bmFjY2VwdGFi bGUgYmVjYXVzZSBoZSBpcyBzcG91dGluZyBGVUQgb24gYSBzdGFuZGFyZCB0aGF0IGludGVuZHMg dG8gcmVjb25jaWxlDQp0aGUgZGlmZmVyZW50IHN0YW5kYXJkcyBpbiBvbmUgYm9keSwgYSBzdGFu ZGFyZCB0aGF0IGludGVuZHMgdG8gZmluYWxseSBnaXZlIGENCnBsYWNlIHRvIHRoZSBkaWZmZXJl bnQgb3J0aG9ncmFwaGllcy4gV2hlbiBQZXRlciBzcGVha3MgZm9yIE1pY3Jvc29mdCBhYm91dCBS T0kNCmFuZCBjb3N0cywgSSBmaW5kIGl0IHByb2JsZW1hdGljIGJlY2F1c2UgSSB3b25kZXIgaG93 IGhlIHJlY29uY2lsZXMgdGhpcyB3aXRoDQpiZWluZyBhIG1lbWJlciBvZiB0aGUgY29tbXVuaXR5 LCB3aGVuIFBldGVyICZxdW90O29ubHkmcXVvdDsgZXhwcmVzc2VzIGhpcyBvd24NCm9waW5pb24g aXQgYmVjb21lcyB1bmFjY2VwdGFibGUgdG8gbWUgYmVjYXVzZSBoZSBjbGVhcmx5IHByZXNlbnRz IGhpbXNlbGYgYXMgYQ0KTWljcm9zb2Z0IGVtcGxveWVlLiBST0kgYW5kIGNvc3RzIGFyZSBidXNp bmVzcyByZWxhdGVkJm5ic3A7IGNvbnNpZGVyYXRpb25zIGFuZA0KbWFraW5nIHRoZXNlICZxdW90 O3BlcnNvbmFsIG9waW5pb24mcXVvdDsgaXMgZGlzaW5nZW51b3VzIHByb2JhYmx5IGRpc2hvbmVz dA0KYW5kIGluIG15IG9waW5pb24gdW5hY2NlcHRhYmxlLjxicj4NCjxicj4NClRoZXJlIGFyZSBj bGVhciBiZW5lZml0cyB0byBhIHN0YW5kYXJkIHRoYXQgcmVjb25jaWxlcyB0aGUgY3VycmVudCBt ZXNzIG9mDQpJU08tNjM5IHN0YW5kYXJkcyB0aGF0IGFyZSBwcm9ibGVtYXRpYyB0byByZWNvbmNp bGUgYW5kIGhhdmUgbWFkZSB0aGUgY3VycmVudA0KUkZDIHByb2Nlc3MgYSB3YWl0aW5nIGdhbWUu IEF0IHRoaXMgdGltZSB0aGVyZSBpcyBubyBzb2Z0d2FyZSB0aGF0IHByb3ZpZGVzIHRoZQ0KJnF1 b3Q7bW9zdCBiYXNpYyZxdW90OyBsYW5ndWFnZSBzdXBwb3J0LiBUaGUgbW9zdCBiYXNpYyBsYW5n dWFnZSBzdXBwb3J0IGlzDQpyZWNvZ25pc2luZyB0aGF0IHBlb3BsZSB3YW50IHRvIHdyaXRlIGlu IHRoZWlyIG93biBsYW5ndWFnZSBhbmQgZW5hYmxpbmcgdGhlbQ0KdG8gZG8gc28uIEVuYWJsaW5n IHRoaXMgaXMgbm90aGluZyBtb3JlIHRoZW4gc2V0dGluZyB0aGUgYXBwcm9wcmlhdGUgbWV0YSBk YXRhDQphbmQgYWxsb3dpbmcgcGVvcGxlIHRvIGV4cHJlc3MgdGhlbXNlbHZlcy4gVGhlIGJlc3Qg YXJndW1lbnQgYWdhaW5zdCBwcm92aWRpbmcNCmEgJnF1b3Q7bW9zdCBiYXNpYyZxdW90OyBsYW5n dWFnZSBzdXBwb3J0IGhhcyBiZWVuIHRoZSBzdGFuZGFyZHMgZG8gbm90IHN1cHBvcnQNCnRoaXMg YW5kIHdpdGggJnF1b3Q7cGVyc29uYWwgb3BpbmlvbnMmcXVvdDsgZXhwcmVzc2VkIGluIHRoaXMg d2F5IGl0IGlzIGxlc3MNCmxpa2VseSB3aGVuIHdlIHdpbGwgc2VlIHRoZSBkYXkgdGhhdCBwZW9w bGUgY2FuIGV4cHJlc3MgdGhlbXNlbHZlcyBpbiB0aGVpcg0KbGFuZ3VhZ2UuPGJyPg0KVGhhbmtz LDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHZXJhcmQ8 bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjIwMDkvMy8xNyBQ ZXRlciBDb25zdGFibGUgJmx0OzxhDQpocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNv bSI+cGV0ZXJjb25AbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD5EdWUgdG8gb2ZmLWxpbmUgbWFpbCBJIHJlY2VpdmVkIGluIHJlbGF0aW9u IHRvIHNvbWUgb2YgbXkNCmNvbW1lbnRzIGluIHRoaXMgdGhyZWFkLCBJIGZlZWwgSSBuZWVkIHRv IG1ha2Ugb25lIGFkZGl0aW9uYWwgY29tbWVudDo8YnI+DQo8YnI+DQpUaGUgb3BpbmlvbnMgSSBo YXZlIGV4cHJlc3NlZCBhcmUgbXkgb3duIGFuZCBub3QgdGhvc2Ugb2YgbXkgZW1wbG95ZXIgb3Ig YW55DQpvdGhlciBwYXJ0eSB3aXRoIHdob20gSSBtYXkgYmUgYWZmaWxpYXRlZC48YnI+DQo8c3Bh biBzdHlsZT0nY29sb3I6Izg4ODg4OCc+PGJyPg0KPGJyPg0KUGV0ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpsdHJ1LWJv dW5jZXNAaWV0Zi5vcmciPmx0cnUtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YQ0KaHJl Zj0ibWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZyI+bHRydS1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mDQpSYW5keSBQcmVzdWhuPGJyPg0KU2VudDogRnJpZGF5LCBNYXJjaCAx MywgMjAwOSAxMTozOSBQTTxicj4NClRvOiBMVFJVIFdvcmtpbmcgR3JvdXA8YnI+DQpTdWJqZWN0 OiBSZTogW0x0cnVdIElTTyA2MzktNjxicj4NCjxicj4NCkhpIC08YnI+DQo8YnI+DQpBcyBjby1j aGFpci4uLjxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIG11Y2ggcHJvZ3Jlc3MgaW4gdGhpcyBkaXNj dXNzaW9uLiAmbmJzcDtJIHN1Z2dlc3QgdGhhdCB0aG9zZTxicj4NCndpc2hpbmcgdG8gc2VlIHdv cmsgaW4gbHRydSBvbiB0aGUgdXNlIG9mIElTTyA2MzktNiBhcyBhIHNvdXJjZSBvZjxicj4NCnN1 YnRhZ3Mgc2hvdWxkIHN1Ym1pdCBhIHNwZWNpZmljIGNoYXJ0ZXIgdXBkYXRlIHByb3Bvc2FsIHRv IHRoaXM8YnI+DQptYWlsaW5nIGxpc3QgZm9yIGRpc2N1c3Npb24uICZuYnNwO1BsZWFzZSByZWZy YWluIGZyb20gZnVydGhlciBjb21tZW50PGJyPg0Kb24gdGhpcyB0b3BpYyB1bnRpbCBzb21lb25l IHByb3ZpZGVzIGEgc3BlY2lmaWMgKGkuZS4gY29udGFpbmluZyBkYXRlczxicj4NCmFuZCBkZWxp dmFyYWJsZXMpIGNoYXJ0ZXIgdXBkYXRlIHByb3Bvc2FsLjxicj4NCjxicj4NClJhbmR5PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpMdHJ1IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5M dHJ1QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkx0cnUgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRt bD4NCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579566E66AD75FNAEXMSGC117re_-- From randy_presuhn@mindspring.com Tue Mar 17 12:06:55 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA453A69A6 for ; Tue, 17 Mar 2009 12:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oNuL9rgKRwt for ; Tue, 17 Mar 2009 12:06:54 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 9CC733A68AB for ; Tue, 17 Mar 2009 12:06:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TGMr2DmQGAeuJ4SCsLOQYhs9EnI3xdnUz550usTRiTQiMJ8dJtOvekiJau5c1c2r; 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 [69.3.146.243] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LjedV-0006HZ-NJ for ltru@ietf.org; Tue, 17 Mar 2009 15:07:37 -0400 Message-ID: <005301c9a733$cc972d00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81><20090311152604.GA15999@mercury.ccil.org><294D681B191C4449800450499A759B20@DGBP7M81><20090313215319.GF26454@mercury.ccil.org><00da01c9a46f$95b8a140$6801a8c0@oemcomputer> <41a006820903170116y522fe14bnf6443efb7f0cfd66@mail.gmail.com> Date: Tue, 17 Mar 2009 12:08:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1731ef7b5696034f471277df4808e87bc43350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.243 Subject: Re: [Ltru] ISO 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 19:06:55 -0000 Hi Gerard - As Co-chair: > From: "Gerard Meijssen" > To: "Peter Constable" > Cc: "LTRU Working Group" > Sent: Tuesday, March 17, 2009 1:16 AM > Subject: Re: [Ltru] ISO 639-6 ... > It is unacceptable because he is spouting FUD ... > ROI and costs are business > related considerations and making these "personal opinion" is disingenuous > probably dishonest and in my opinion unacceptable. We *all* participate in these discussions as individuals. Accusations like these are highly inappropriate on an IETF mailing list. Stop it. NOW. Randy From randy_presuhn@mindspring.com Mon Mar 23 06:00:22 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7793A69D7 for ; Mon, 23 Mar 2009 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlvbaPFRZAWQ for ; Mon, 23 Mar 2009 06:00:21 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 6EC183A68B2 for ; Mon, 23 Mar 2009 06:00:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Lhlk0XZ8pRR5RXQRalyVwIJVcUCVlA7mj12l4dvhOGgILvvgoEhpT547FbV3TLmG; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.206.69] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LljmB-0006Yg-1p for ltru@ietf.org; Mon, 23 Mar 2009 09:01:11 -0400 Message-ID: <001101c9abb7$a118ed20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 23 Mar 2009 06:02:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173370d5c66cf75a381c9fc57d2e7964e68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.69 Subject: [Ltru] Fw: ANNOUNCEMENT: New FAQ on IETF Copyright Policy available (FYI) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:00:22 -0000 Hi - The document itself is at http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf and well worth the twenty minutes or so it takes to read it. Randy ----- Original Message ----- > From: "Ed Juskevicius" > To: ; > Cc: "Trustees" ; ; "Contreras,Jorge" ; > Sent: Sunday, March 22, 2009 8:58 PM > Subject: ANNOUNCEMENT: New FAQ on IETF Copyright Policy available (FYI) > > FYI, a well-written new FAQ has just been posted to the IETF Trust website. > The title of the FAQ is: > * > > IETF Trust *Copyright Policy and Trust Legal Provisions (TLP) > This FAQ was created in response to some uncertainty within the community > about the RFCs, BCPs, and Trust policies that govern copyrights in IETF (and > other) documents. > > The FAQ was prepared by Jorge Contreras (IETF Trust Legal Counsel), at the > request of Ray Pelletier (IAD) and the IETF Trustees. > > I believe the FAQ is informative, relevant and well worth the 10 minutes it > takes to read it. I encourage you to review it. The FAQ is available at: > http://trustee.ietf.org/faqs.html > > Regards, > > > Ed Juskevicius > IETF Trust Chair > edj.etc@gmail.com From mark.edward.davis@gmail.com Tue Mar 31 21:32:04 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2943A6804 for ; Tue, 31 Mar 2009 21:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLqb9z6MvfZx for ; Tue, 31 Mar 2009 21:32:02 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 37A2C3A67F5 for ; Tue, 31 Mar 2009 21:32:02 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3586687wfg.31 for ; Tue, 31 Mar 2009 21:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=ZI5ay6PF/CW2p4yaEii/NgPJtKniEbpxxKrGlOoN1XI=; b=aWs07Zu//b39UPS8IUZX2VQYKkS23hyURjxhhDSeyOErjP4alpO0p1jNJ1NC3yYv/W fT5K2uDJF2Nk5gXodfC4LYfOGsfLex7AaKpVi9WssSrSY0K54Nhw3nrr6Waq7Qs1M9hm HfsRTPjlkFkFCrIOQGttGC3c9+qm0/kn4zFCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=F8XOTkBCxNfyPBgngCPyIocuv+ubtASIFKPIQqXCRbg62Z2euLqFpiCjqNK5uXpuT4 qnwTkfJnYLmEFqTUVp715f0Mw+ffwNhxuItSL8NJNIvH/7IKA8znUL12Yt2+PgvTgadU uIMnqT+4hJ++xWwVSOfL0PNQZwDtD8Oy2F1gU= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.142.135.16 with SMTP id i16mr2946103wfd.250.1238560382135; Tue, 31 Mar 2009 21:33:02 -0700 (PDT) In-Reply-To: <6.0.0.20.2.20090301210247.09515b90@localhost> References: <6.0.0.20.2.20090301210247.09515b90@localhost> Date: Tue, 31 Mar 2009 21:33:02 -0700 X-Google-Sender-Auth: 7d9be756bd6e264b Message-ID: <30b660a20903312133g733a4bbei4765c9f2ad7c7aea@mail.gmail.com> From: Mark Davis To: Martin Duerst Content-Type: multipart/alternative; boundary=000e0cd328729c3081046676cf22 Cc: Lisa Dusseault , LTRU Working Group , Doug Ewell , Alexey Melnikov , Chris Newman , Addison Phillips Subject: Re: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 04:32:04 -0000 --000e0cd328729c3081046676cf22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit BTW, can someone point me to the tool for viewing the last call status? Mark On Mon, Mar 2, 2009 at 03:19, Martin Duerst wrote: > Hello Chris, > > [I'm assuming you are the acting AD currently. > I'm cc'ing Alex so he knows what might be comming up for him.] > > I'm glad to finally request IETF LAST CALL for > draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21), > the two current WG documents of the LTRU WG. > The intended status of 4645bis is informational, > the intended status of 4646bis is BCP (BCP 47 together > with RFC 4647, which stays as it is). > > I'm sending the shepherding documents in separate mails, > but I'm using this mail as a trigger; that's what Ted Hardie > told me to do when I did this thing last time. > > If I need to do anything else, please don't hesitate to tell me. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > --000e0cd328729c3081046676cf22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable BTW, can someone point me to the tool for viewing the last call status?
=
Mark


On Mon, Mar 2, 2009 at 03:19, Martin Due= rst <duerst@= it.aoyama.ac.jp> wrote:
Hello Chris,

[I'm assuming you are the acting AD currently.
I'm cc'ing Alex so he knows what might be comming up for him.]

I'm glad to finally request IETF LAST CALL for
draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21),
the two current WG documents of the LTRU WG.
The intended status of 4645bis is informational,
the intended status of 4646bis is BCP (BCP 47 together
with RFC 4647, which stays as it is).

I'm sending the shepherding documents in separate mails,
but I'm using this mail as a trigger; that's what Ted Hardie
told me to do when I did this thing last time.

If I need to do anything else, please don't hesitate to tell me.

Regards, =C2=A0 =C2=A0Martin.


#-#-# =C2=A0Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin Universi= ty
#-#-# =C2=A0htt= p://www.sw.it.aoyama.ac.jp =C2=A0 =C2=A0 =C2=A0 mailto:duerst@it.aoyama.ac.jp


--000e0cd328729c3081046676cf22--