From ltru-bounces@ietf.org Fri Jun 02 01:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2L7-0003vs-0W; Fri, 02 Jun 2006 01:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2L5-0003vh-QM; Fri, 02 Jun 2006 01:36:51 -0400 Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2L1-0007sY-DG; Fri, 02 Jun 2006 01:36:51 -0400 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fm2L0-00007S-00; Fri, 02 Jun 2006 01:36:46 -0400 Message-ID: <000701c68607$56c85360$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "Disman" , Date: Thu, 1 Jun 2006 22:42:29 -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-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - A reminder from the secretariat. Randy > From: > To: > Sent: Thursday, June 01, 2006 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 02 07:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Qp-0006oA-VL; Fri, 02 Jun 2006 07:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Qo-0006o5-Pn for ltru@ietf.org; Fri, 02 Jun 2006 07:03:06 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7Qm-0000vX-EJ for ltru@ietf.org; Fri, 02 Jun 2006 07:03:06 -0400 Received: from duringpersonlx (traveling-laptop-251.london.corp.yahoo.com [10.76.38.251]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k52B0mds085754 for ; Fri, 2 Jun 2006 04:00:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index; b=dEo4bHkI6CQ+BhpTibtOG9XUI/BC0j6XIDARZ+yYWEONEHFeqJ++cVXdZotscaC3 From: "Addison Phillips" To: "'LTRU Working Group'" Date: Fri, 2 Jun 2006 12:00:48 +0100 Message-ID: <000901c68633$ce971620$07ed4c0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaGM82QEGunGPA2Qg+f6Cx+H1ZD8A== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] draft-13 to draft-14 diff available... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ... at http://tinyurl.com/ofnwg Links to this are also on my homepage http://www.inter-locale.com This is a very tiny diff. Also, if you're interested in the draft's progress through the IETF = plumbing, you can watch the status on draft-tracker here: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D13140&rfc_flag=3D0 Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 02 20:19:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJrn-0003hH-PB; Fri, 02 Jun 2006 20:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJrm-0003hC-MH for ltru@ietf.org; Fri, 02 Jun 2006 20:19:46 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmJrk-0007dN-1v for ltru@ietf.org; Fri, 02 Jun 2006 20:19:46 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k530JaSO001097 for ; Sat, 3 Jun 2006 09:19:36 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 115e_a3b0cca6_f296_11da_9325_0014221fa3c9; Sat, 03 Jun 2006 09:19:35 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k530IgoF032319 for ; Sat, 3 Jun 2006 09:19:11 +0900 Message-Id: <6.0.0.20.2.20060603091556.05543450@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 03 Jun 2006 09:17:27 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ltru] Charter Discussion X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear LTRU WG Members, Quite some time ago, we agreed that after finishing our deliverables, we will have a discussion about the charter. Randy and I would like to start this discussion now, because we basically have finished our deliverables (we may need to come back to the matching draft once in a while based on comments in IETF Last Call and comments from the IESG). Discussions about (re)chartering are by nature rather open-ended, but to focus discussion a bit, here are some questions: 1) What do you think is most needed after our current drafts are approved (and published as RFCs). What are the next steps? In what order/priority? 2) Is further specification work needed? Are there preconditions? What are predicted/desirable timelines? 3) Where (which organizations) should further spec work be done? What work should be done in the IETF? 4) In case further work in the IETF is needed, should the current WG be closed and a new WG be started at a later time, or should the current WG be rechartered? (Hint: The IETF has a strong preference for short-duration WGs with very clearly defined deliverables.) 5) Anything else? Happy discussion! Regards, Martin. P.S.: Please remember that expressions of opinions in the IETF are taken as expressions by individuals, and that while we can advise the IESG and the responsible Area Directors about what the IETF should do next, it's not us (the WG) who decides on charter changes. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 02 22:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmLnx-0000Rx-AW; Fri, 02 Jun 2006 22:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmLnv-0000Pt-Az; Fri, 02 Jun 2006 22:23:55 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmLnu-0001pC-2h; Fri, 02 Jun 2006 22:23:55 -0400 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmLns-0000dt-00; Fri, 02 Jun 2006 22:23:52 -0400 Message-ID: <001001c686b5$88a735a0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , Date: Fri, 2 Jun 2006 19:29:25 -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-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Fw: Pre-IPV6 maintenance of one of the www.ietf.org servers -2006/06/03 - 12:00am EST X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - In case you're not on the ietf@ietf.org or ietf-announce@ietf.org distribution lists.... Randy > From: > To: ; > Sent: Friday, June 02, 2006 6:29 PM > Subject: Pre-IPV6 maintenance of one of the www.ietf.org servers -2006/06/03 - 12:00am EST > > > Hi All, > > Tomorrow Saturday June 3 at 12:00am EST, we will be taking down one of > the round robin www servers for the IETF (209.173.53.180) for > maintenance in preparation for supporting IPV6. The outage should be > less than 1 hour. This system also serves as the primary site for... > > noc.ietf.org > www.iab.org > www.iesg.org > > so those sites will also be down. > > Mail and the mailing lists (and their archives) should no be affected. > > If after 01:00AM EST you experience any difficulties, or notice > anything amiss with the sites, please send email to ietf-action at > ietf.org, the IAD at iad at ietf.org, and copy ietf-admin at > techsquare.com and rpelletier at isoc.org. In case of an emergency, > please call the emergency number: +1 301-858-6268. > > Thank you for your patience. > > IETF Secretariat. > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 03 02:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmPaE-0003vr-1r; Sat, 03 Jun 2006 02:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmPaD-0003vm-4O for ltru@ietf.org; Sat, 03 Jun 2006 02:26:01 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmPa9-0001DB-Lf for ltru@ietf.org; Sat, 03 Jun 2006 02:25:58 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c43.corp.yahoo.com [10.72.76.43]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k536Pjgk050682; Fri, 2 Jun 2006 23:25:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=VODu9tfKhFb7Spe0a6wCLfeRHybFsylvqU/U3IBgg/6y7PtOxQiTzwAcgQSwtKHQ From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Sat, 3 Jun 2006 07:25:45 +0100 Message-ID: <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaGo3D8Szod/msZRWO9l3diWx9LewAMMYJw In-Reply-To: <6.0.0.20.2.20060603091556.05543450@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Martin, Based on our past experience, we may have quite an adventure ahead on the matching draft: nothing surprises me any more. > 1) What do you think is most needed after our current drafts are > approved (and published as RFCs). What are the next steps? > In what order/priority? This group's next major task will be a minor revision of 3066bis when ISO 639-3 is approved later this year. After that we should go away. > 2) Is further specification work needed? Are there preconditions? > What are predicted/desirable timelines? See above. > 3) Where (which organizations) should further spec work be done? > What work should be done in the IETF? W3C I18N Core WG is already working on "LTLI" (Language Tags and Locale Identifiers). According to that group's charter, that spec will (among other things) interpret RFC 3066bis and draft-matching for use with W3C technologies. > 4) In case further work in the IETF is needed, should the current > WG be closed and a new WG be started at a later time, or should > the current WG be rechartered? We should keep the current WG until the update is completed. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 03 03:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmQdc-0004fk-V0; Sat, 03 Jun 2006 03:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmQdc-0004ff-94 for ltru@ietf.org; Sat, 03 Jun 2006 03:33:36 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmQdZ-0007qR-1g for ltru@ietf.org; Sat, 03 Jun 2006 03:33:36 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FmQdY-0002ln-AL; Sat, 03 Jun 2006 03:33:32 -0400 Date: Sat, 3 Jun 2006 03:33:32 -0400 To: Addison Phillips Subject: Re: [Ltru] Charter Discussion Message-ID: <20060603073332.GA25544@ccil.org> References: <6.0.0.20.2.20060603091556.05543450@localhost> <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > This group's next major task will be a minor revision of 3066bis when ISO > 639-3 is approved later this year. After that we should go away. Agreed. We will need to get the extlang machinery turned on and decide what to do about sign languages. We will also need to reload the registry from another I-D so that IANA does not need to process six thousand individual additions. That will constitute 3066ter. > > 4) In case further work in the IETF is needed, should the current > > WG be closed and a new WG be started at a later time, or should > > the current WG be rechartered? > > We should keep the current WG until the update is completed. Agreed again. The WG should go into dormancy until 639-3 is at the appropriate ISO stage, probably after approval as an International Standard but before actual publication -- analogous to IETF approval of an RFC as distinct from its publication. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 03 08:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmUsS-0005Ar-Ma; Sat, 03 Jun 2006 08:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmUsR-0005Ak-A4 for ltru@ietf.org; Sat, 03 Jun 2006 08:05:11 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmUsQ-0000tg-3l for ltru@ietf.org; Sat, 03 Jun 2006 08:05:11 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c29.corp.yahoo.com [10.72.76.29]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k53C4q4O087752; Sat, 3 Jun 2006 05:04:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=Rc+fHNYxv4tC2qqNZKLIFQ0kUrT1HMKFTVFoKytRVgoKma3VwPT0RwlL1BDqhTNZ From: "Addison Phillips" To: "'John Cowan'" Subject: RE: [Ltru] Charter Discussion Date: Sat, 3 Jun 2006 05:04:48 -0700 Message-ID: <000001c68705$ee8ad520$1333710a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060603073332.GA25544@ccil.org> Thread-Index: AcaG4BM5etbPfNVwTIuHqcAcG0IuHwAJLylg X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Agreed. We will need to get the extlang machinery turned on and Yep. > decide what to do about sign languages. Nothing much. Perhaps (informatively) deprecate the existing tags in favor of their 639 equivalents. > We will also need to reload > the registry from another I-D so that IANA does not need to > process six > thousand individual additions. Probably one with just the additions, rather than a wholesale replacement. This avoids complicated interregnum periods and such. > That will constitute 3066ter. Yes. Too bad we can't just do it as an erratum! Turning on extlang will take one, possibly two sentences. (Although I suspect we'll have to review the section on stability rules.) > > > > > We should keep the current WG until the update is completed. > > Agreed again. The WG should go into dormancy until 639-3 is at the > appropriate ISO stage, probably after approval as an International > Standard but before actual publication -- analogous to IETF > approval of > an RFC as distinct from its publication. > I'm told that the dormant period will not be long, given that our draft-matching IETF last call hasn't even started yet and 639-3 is advancing steadily. So that would be in keeping with the IETF's goals of short-lived WGs with fixed deliverables. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 03 10:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWzG-0002lT-5z; Sat, 03 Jun 2006 10:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWzE-0002lO-RR for ltru@ietf.org; Sat, 03 Jun 2006 10:20:20 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmWzD-0006hk-Kd for ltru@ietf.org; Sat, 03 Jun 2006 10:20:20 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FmWzC-00086T-Mp; Sat, 03 Jun 2006 10:20:18 -0400 Date: Sat, 3 Jun 2006 10:20:18 -0400 To: Addison Phillips Subject: Re: [Ltru] Charter Discussion Message-ID: <20060603142017.GA29941@ccil.org> References: <20060603073332.GA25544@ccil.org> <000001c68705$ee8ad520$1333710a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c68705$ee8ad520$1333710a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Nothing much. Perhaps (informatively) deprecate the existing tags in > favor of their 639 equivalents. The issue is whether we ought to treat "sgn" as a macrolanguage. It would be nice if 639-3 already did, but if it doesn't, we'll have to decide whether to do so (I'm in favor of it). > Probably one with just the additions, rather than a wholesale > replacement. This avoids complicated interregnum periods and such. Fair enough. There are a few modifications to do, changing some grandfathered tags to redundant and deprecating some. > > That will constitute 3066ter. > Yes. Too bad we can't just do it as an erratum! In principle we could issue an updating RFC, but I'd rather issue a superseding one. > I'm told that the dormant period will not be long, given that our > draft-matching IETF last call hasn't even started yet and 639-3 is > advancing steadily. So that would be in keeping with the IETF's goals > of short-lived WGs with fixed deliverables. Good. -- John Cowan cowan@ccil.org http://ccil.org/~cowan You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 03 17:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmdUz-0004uG-1S; Sat, 03 Jun 2006 17:17:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmdUy-0004uB-3l for ltru@ietf.org; Sat, 03 Jun 2006 17:17:32 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmdUw-0004Sv-QX for ltru@ietf.org; Sat, 03 Jun 2006 17:17:32 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060603211726.WHYJ10985.mta13.adelphia.net@DGBP7M81>; Sat, 3 Jun 2006 17:17:26 -0400 Message-ID: <004501c68753$1a9cb230$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Charter Discussion Date: Sat, 3 Jun 2006 14:17:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Debbie Garside X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> 1) What do you think is most needed after our current drafts are >> approved (and published as RFCs). What are the next steps? >> In what order/priority? > > This group's next major task will be a minor revision of 3066bis when > ISO 639-3 is approved later this year. After that we should go away. We also need to decide what to do about ISO 639-6. We've already reserved 4-letter primary language subtags for "possible future standardization" (Section 2.2.1), which really means 639-6. ISO 639-6 is scheduled for publication in 2007, and although publicly available information is still sparse and there are still questions about how it should interoperate with the rest of RFC 3066bis/ter, I think it would be a mistake for this group to "go away" before having a chance to discuss it. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 04 01:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmkoK-00009K-8c; Sun, 04 Jun 2006 01:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmkoI-000098-AY for ltru@ietf.org; Sun, 04 Jun 2006 01:05:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmkBx-0004ab-Jt for ltru@ietf.org; Sun, 04 Jun 2006 00:26:21 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmjwO-0004yn-I0 for ltru@ietf.org; Sun, 04 Jun 2006 00:10:19 -0400 Received: from h-68-165-6-62.snvacaid.dynamic.covad.net ([68.165.6.62] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmjwN-0007ey-00 for ltru@ietf.org; Sun, 04 Jun 2006 00:10:15 -0400 Message-ID: <001a01c6878d$8fedc260$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <004501c68753$1a9cb230$040aa8c0@DGBP7M81> Subject: Re: [Ltru] Charter Discussion Date: Sat, 3 Jun 2006 21:15: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-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Debbie Garside" > Sent: Saturday, June 03, 2006 2:17 PM > Subject: Re: [Ltru] Charter Discussion > > Addison Phillips wrote: > > >> 1) What do you think is most needed after our current drafts are > >> approved (and published as RFCs). What are the next steps? > >> In what order/priority? > > > > This group's next major task will be a minor revision of 3066bis when > > ISO 639-3 is approved later this year. After that we should go away. > > We also need to decide what to do about ISO 639-6. We've already > reserved 4-letter primary language subtags for "possible future > standardization" (Section 2.2.1), which really means 639-6. > > ISO 639-6 is scheduled for publication in 2007, and although publicly > available information is still sparse and there are still questions > about how it should interoperate with the rest of RFC 3066bis/ter, I > think it would be a mistake for this group to "go away" before having a > chance to discuss it. ... I think it's important to draw a distinction between keeping a working group active and keeping its mailing list going. There is no point in having an active working group unless there are chartered deliverables, but it would be perfectly reasonable to keep the WG's mailing list going in order to discuss things like 639-6, in anticipation of requesting a charter to produce so deliverable when the time comes. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 04 01:27:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fml9Q-0002yR-3k; Sun, 04 Jun 2006 01:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fml9O-0002sk-Sb for ltru@ietf.org; Sun, 04 Jun 2006 01:27:46 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fml9L-0001qo-DF for ltru@ietf.org; Sun, 04 Jun 2006 01:27:46 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060604052742.ISUO21801.mta9.adelphia.net@DGBP7M81> for ; Sun, 4 Jun 2006 01:27:42 -0400 Message-ID: <001101c68797$9838d270$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Charter Discussion Date: Sat, 3 Jun 2006 22:27:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> We will also need to reload the registry from another I-D so that >> IANA does not need to process six thousand individual additions. I think it's worthwhile to ask whether we would also want this new I-D to be an RFC, as we did with draft-initial. The number of new subtags will actually be over 7,000 and the I-D will probably be about 850 pages long. As it is, at least one person characterized the 118-page draft-initial as a vanity endeavor, even though the RFC Editor is supposed to remove the list before publication. > Probably one with just the additions, rather than a wholesale > replacement. This avoids complicated interregnum periods and such. As some folks know, I've already mocked up a prototype 3066ter Registry that incorporates the DIS 639-3 data as it exists now. Besides the newly added subtags, there are changes to the descriptions of existing subtags (639-1, -2, and -3 don't always agree perfectly on the names) and there are also the changes John mentioned. Given the clerical issues we've already experienced with IANA on the new Registry, I think we will have to watch over the reloading process very carefully, and doubly so if we expect IANA to merge deltas intelligently into the existing Registry. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 04 05:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmpOj-0008R8-U5; Sun, 04 Jun 2006 05:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmpOi-0008R2-Ry for ltru@ietf.org; Sun, 04 Jun 2006 05:59:53 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmpOe-0007sU-6t for ltru@ietf.org; Sun, 04 Jun 2006 05:59:52 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k549xQft012702; Sun, 4 Jun 2006 18:59:26 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 5b4a_ce3edd6c_f3b0_11da_8026_0014221f2a2d; Sun, 04 Jun 2006 18:59:25 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k549xJCX022023; Sun, 4 Jun 2006 18:59:25 +0900 Message-Id: <6.0.0.20.2.20060604153348.04f75b70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 04 Jun 2006 15:37:15 +0900 To: "Addison Phillips" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Charter Discussion In-Reply-To: <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> References: <6.0.0.20.2.20060603091556.05543450@localhost> <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:25 06/06/03, Addison Phillips wrote: >Based on our past experience, we may have quite an adventure ahead on the >matching draft: nothing surprises me any more. Let's just take that as it comes. We have a lot of experience and patience by now :-(. >This group's next major task will be a minor revision of 3066bis when ISO >639-3 is approved later this year. After that we should go away. Does anybody have any kinds of more concrete information about ISO 639-3? Current status? Maximum or minimum time it takes for the next stage? Deadlines (e.g. for voting,...) that are already know? Peter? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 11:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHKe-0005bm-Dx; Mon, 05 Jun 2006 11:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHKc-0005bh-P7 for ltru@ietf.org; Mon, 05 Jun 2006 11:49:30 -0400 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHKb-00053K-D9 for ltru@ietf.org; Mon, 05 Jun 2006 11:49:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 8CE5244FB; Tue, 6 Jun 2006 00:49:27 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07706-08; Tue, 6 Jun 2006 00:49:27 +0900 (JST) Received: from [127.0.0.1] (p3127-ipad73marunouchi.tokyo.ocn.ne.jp [220.104.153.127]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 3F6704399; Tue, 6 Jun 2006 00:49:27 +0900 (JST) Message-ID: <44845281.1080603@w3.org> Date: Tue, 06 Jun 2006 00:49:21 +0900 From: Felix Sasaki Organization: W3C User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Charter Discussion References: <6.0.0.20.2.20060603091556.05543450@localhost> <001c01c686d6$8d23e120$6be3690a@ds.corp.yahoo.com> <6.0.0.20.2.20060604153348.04f75b70@localhost> In-Reply-To: <6.0.0.20.2.20060604153348.04f75b70@localhost> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=0BE87F1E X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1679137420==" Errors-To: ltru-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1679137420== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2EDA5B34C62C5C96B75A0A23" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2EDA5B34C62C5C96B75A0A23 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Martin, all, [...] Martin Duerst wrote: >=20 > Does anybody have any kinds of more concrete information about ISO 639-= 3? > Current status? Maximum or minimum time it takes for the next stage? > Deadlines (e.g. for voting,...) that are already know? Peter? Maybe Peter has more / different information, but I talked at last weeks LREC conference to Gerhard Budin (University of Vienna), who is in the ISO committee which defines 639-3. He said 639-3 is now be in the FDIS stadium, and they don't expect major issues. There is a 6 months period to wait for comments, so the final standard will be published at the beginning of 2007. However, Gerhard said that it is possible to cite FDIS versions of ISO drafts "officially"= =2E I'm not familiar with ISO processes, so I don't know if this last statement is valid. Regards, Felix. --------------enig2EDA5B34C62C5C96B75A0A23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhFKBcU6f2Avofx4RAqISAJ9Z/89o/ZixJLnpveXFmZawWGHBvwCgujh8 VGTtxQESr2GsKc/gs+t4GbU= =IDVs -----END PGP SIGNATURE----- --------------enig2EDA5B34C62C5C96B75A0A23-- --===============1679137420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1679137420==-- From ltru-bounces@ietf.org Mon Jun 05 12:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHkU-0001lM-T8; Mon, 05 Jun 2006 12:16:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHkT-0001lC-L8 for ltru@ietf.org; Mon, 05 Jun 2006 12:16:13 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHkS-0008J2-92 for ltru@ietf.org; Mon, 05 Jun 2006 12:16:13 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k55GGBUk010994; Mon, 5 Jun 2006 17:16:11 +0100 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k55GG9sD010923; Mon, 5 Jun 2006 17:16:10 +0100 From: "Debbie Garside" To: "'Felix Sasaki'" , "'Martin Duerst'" Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 17:17:55 +0100 Message-ID: <1dea01c688bb$9b521eb0$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaIt6VIOwVPxK+bROalhcF4h98dnAAA7cQg In-Reply-To: <44845281.1080603@w3.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Felix wrote: > I'm not familiar with ISO processes, so I don't know if this last statement is valid. I would accept Gerhard's word - he is chair of ISO TC37/SC2 Best regards Debbie -----Original Message----- From: Felix Sasaki [mailto:fsasaki@w3.org] Sent: 05 June 2006 16:49 To: Martin Duerst Cc: 'LTRU Working Group' Subject: Re: [Ltru] Charter Discussion Hello Martin, all, [...] Martin Duerst wrote: > > Does anybody have any kinds of more concrete information about ISO 639-3? > Current status? Maximum or minimum time it takes for the next stage? > Deadlines (e.g. for voting,...) that are already know? Peter? Maybe Peter has more / different information, but I talked at last weeks LREC conference to Gerhard Budin (University of Vienna), who is in the ISO committee which defines 639-3. He said 639-3 is now be in the FDIS stadium, and they don't expect major issues. There is a 6 months period to wait for comments, so the final standard will be published at the beginning of 2007. However, Gerhard said that it is possible to cite FDIS versions of ISO drafts "officially". I'm not familiar with ISO processes, so I don't know if this last statement is valid. Regards, Felix. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 18:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN7P-00086t-4J; Mon, 05 Jun 2006 18:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN7O-00086l-4U; Mon, 05 Jun 2006 18:00:14 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnN7M-000735-TZ; Mon, 05 Jun 2006 18:00:14 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k55M0ARx016471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 22:00:12 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnN7K-0001Bi-MV; Mon, 05 Jun 2006 18:00:10 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 05 Jun 2006 18:00:10 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The IESG has received a request from the Language Tag Registry Update WG to consider the following document: - 'Matching of Language Tags ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 18:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNOe-0002AA-W7; Mon, 05 Jun 2006 18:18:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNOd-0002A4-ON for ltru@ietf.org; Mon, 05 Jun 2006 18:18:03 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNOc-0000qp-Dr for ltru@ietf.org; Mon, 05 Jun 2006 18:18:03 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 15:18:01 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 15:18:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 15:18:02 -0700 Message-ID: In-Reply-To: <001101c68797$9838d270$040aa8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaHl6gWCjwdxGYMSHiFYdpKX/zwwQBVgqCA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 05 Jun 2006 22:18:01.0374 (UTC) FILETIME=[E85E03E0:01C688ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0363981183==" Errors-To: ltru-bounces@ietf.org --===============0363981183== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldF0NCg0KDQo+IEFz IHNvbWUgZm9sa3Mga25vdywgSSd2ZSBhbHJlYWR5IG1vY2tlZCB1cCBhIHByb3RvdHlwZSAzMDY2 dGVyIFJlZ2lzdHJ5DQo+IHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBESVMgNjM5LTMgZGF0YSBhcyBp dCBleGlzdHMgbm93LiAgQmVzaWRlcyB0aGUNCj4gbmV3bHkgYWRkZWQgc3VidGFncywgdGhlcmUg YXJlIGNoYW5nZXMgdG8gdGhlIGRlc2NyaXB0aW9ucyBvZiBleGlzdGluZw0KPiBzdWJ0YWdzICg2 MzktMSwgLTIsIGFuZCAtMyBkb24ndCBhbHdheXMgYWdyZWUgcGVyZmVjdGx5IG9uIHRoZSBuYW1l cykNCj4gYW5kIHRoZXJlIGFyZSBhbHNvIHRoZSBjaGFuZ2VzIEpvaG4gbWVudGlvbmVkLg0KDQpJ J3ZlIGFza2VkIHRoZSBmb2xrIGF0IFNJTCB0byB3b3JrIG9uIGltcHJvdmluZyBjb25zaXN0ZW5j eSBiZXR3ZWVuIG5hbWVzIGxpc3RlZCBvbiB0aGUgNjM5LTIgYW5kIDYzOS0zIHNpdGVzLg0KDQoN Cg0KUGV0ZXIgQ29uc3RhYmxlDQo= --===============0363981183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0363981183==-- From ltru-bounces@ietf.org Mon Jun 05 18:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNZ2-00062R-FJ; Mon, 05 Jun 2006 18:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNZ1-00060s-Sn for ltru@ietf.org; Mon, 05 Jun 2006 18:28:47 -0400 Received: from mailb.microsoft.com ([131.107.1.8] helo=mail3.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNZ0-0001tH-KB for ltru@ietf.org; Mon, 05 Jun 2006 18:28:47 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 15:28:46 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 15:28:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 15:27:49 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060604153348.04f75b70@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaHvaSrmFysHuZiRkSQeAZ0pPXtigBMEscw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 05 Jun 2006 22:28:45.0849 (UTC) FILETIME=[68811890:01C688EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Does anybody have any kinds of more concrete information about ISO = 639-3? > Current status? Maximum or minimum time it takes for the next stage? > Deadlines (e.g. for voting,...) that are already know? Peter? The FDIS document has been submitted to ISO CS for circulation of the = FDIS ballot. As I do not receive the ballot (that gets sent to national = body agencies -- ANSI in the case of US), I can't tell for certain = whether it has actually been circulated yet. But I expect the FDIS = ballot should be complete by early August. Besides the matter of final approval of the text of 639-3, there have = been some open issues regarding the draft code table that the ISO = 639-RA/Joint Advisory Committee needs to wrap up. I'm hoping that will = also be complete by some time in August, though realistically it will = probably take a little longer than the ballot. But that should not = present an obstacle to the WG beginning to discuss what changes are = needed for 3066ter. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 18:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNc9-0006X5-B4; Mon, 05 Jun 2006 18:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNc8-0006X0-W8 for ltru@ietf.org; Mon, 05 Jun 2006 18:32:01 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNc7-0002Nk-OR for ltru@ietf.org; Mon, 05 Jun 2006 18:32:00 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 15:31:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 15:31:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 15:31:40 -0700 Message-ID: In-Reply-To: <44845281.1080603@w3.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaIt6ndyXC0cU+AR9qEn6m+Rhn2pQAN6fLg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 05 Jun 2006 22:31:57.0142 (UTC) FILETIME=[DA861760:01C688EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Felix Sasaki [mailto:fsasaki@w3.org] > He said 639-3 is now be in the FDIS stadium, and they don't expect = major > issues. There is a 6 months period to wait for comments, so the final > standard will be published at the beginning of 2007. That is incorrect. The FDIS ballot is two months in duration (ISO/IEC = Directives Part 1, 2.7.1). Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 20:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP5E-0007ie-BH; Mon, 05 Jun 2006 20:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP5D-0007hi-37 for ltru@ietf.org; Mon, 05 Jun 2006 20:06:07 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnP5A-0005RQ-A7 for ltru@ietf.org; Mon, 05 Jun 2006 20:06:07 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k56060NY023810 for ; Tue, 6 Jun 2006 09:06:00 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5e82_3c364f2c_f4f0_11da_883e_0014221fa3c9; Tue, 06 Jun 2006 09:05:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5605t7C024603 for ; Tue, 6 Jun 2006 09:05:58 +0900 Message-Id: <6.0.0.20.2.20060606090531.04f69840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 06 Jun 2006 09:05:44 +0900 To: "LTRU Working Group" From: "Debbie Garside" (by way of Martin Duerst ) Subject: RE: [Ltru] Charter Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi All FYI, herewith the ISO targets for 639-3 and 639-6 ISO 639-3 Bilingual FDIS in preparation -- Target date for circulation: Beginning September 2006, maybe before. Target date ISO Standard: 2007 ISO 639-6 DIS in preparation Target date for circulation : 2006-09-29 Target closing date on DIS circulation : 2006-12-29 Target date for circulation of FDIS : 2007-03-29 Target date for ISO Standard : 2007-06 I also have target dates for 639-4 and 639-5 if anyone is interested let me know. Best regards Debbie Garside Editor ISO CD 639-6 > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 05 June 2006 17:18 > To: 'Felix Sasaki'; 'Martin Duerst' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Charter Discussion > > Hi > > Felix wrote: > > I'm not familiar with ISO processes, so I don't know if this last > statement is valid. > > I would accept Gerhard's word - he is chair of ISO TC37/SC2 > > Best regards > > Debbie > > > -----Original Message----- > From: Felix Sasaki [mailto:fsasaki@w3.org] > Sent: 05 June 2006 16:49 > To: Martin Duerst > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] Charter Discussion > > Hello Martin, all, > > [...] > > Martin Duerst wrote: > > > > Does anybody have any kinds of more concrete information > about ISO 639-3? > > Current status? Maximum or minimum time it takes for the next stage? > > Deadlines (e.g. for voting,...) that are already know? Peter? > > Maybe Peter has more / different information, but I talked at > last weeks LREC conference to Gerhard Budin (University of > Vienna), who is in the ISO committee which defines 639-3. > > He said 639-3 is now be in the FDIS stadium, and they don't > expect major issues. There is a 6 months period to wait for > comments, so the final standard will be published at the > beginning of 2007. However, Gerhard said that it is possible > to cite FDIS versions of ISO drafts "officially". > > I'm not familiar with ISO processes, so I don't know if this > last statement is valid. > > Regards, Felix. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 22:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnR8M-0000XH-Lp; Mon, 05 Jun 2006 22:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnR8L-0000X9-41 for ltru@ietf.org; Mon, 05 Jun 2006 22:17:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnR8J-0002JV-Tj for ltru@ietf.org; Mon, 05 Jun 2006 22:17:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FnR8I-0007Vj-Bb; Mon, 05 Jun 2006 22:17:26 -0400 Date: Mon, 5 Jun 2006 22:17:26 -0400 To: Debbie Garside Subject: Re: [Ltru] Charter Discussion Message-ID: <20060606021726.GB14868@ccil.org> References: <6.0.0.20.2.20060606090531.04f69840@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060606090531.04f69840@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > ISO 639-6 > DIS in preparation > Target date for circulation : 2006-09-29 > Target closing date on DIS circulation : 2006-12-29 > > Target date for circulation of FDIS : 2007-03-29 > Target date for ISO Standard : 2007-06 Is there going to be a full mapping from 639-3 codes to 639-6 ones available? Because without that I don't think 3066quater efforts can even start. Also, will the hierarchical relationships be published with 639-6? > I also have target dates for 639-4 and 639-5 if anyone is interested let me > know. Sure. They're not directly relevant for 3066 revision, but they'd be interesting. -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous cowan@ccil.org internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 22:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRi3-0000yh-Ol; Mon, 05 Jun 2006 22:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRi3-0000yT-2r for ltru@ietf.org; Mon, 05 Jun 2006 22:54:23 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnRhz-000570-El for ltru@ietf.org; Mon, 05 Jun 2006 22:54:21 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k562s6P2008529; Tue, 6 Jun 2006 11:54:06 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 293d_b833324a_f507_11da_87f8_0014221f2a2d; Tue, 06 Jun 2006 11:54:06 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k562rk9C027035; Tue, 6 Jun 2006 11:53:58 +0900 Message-Id: <6.0.0.20.2.20060606114849.04e21360@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 06 Jun 2006 11:50:56 +0900 To: "Debbie Garside" (by way of Martin Duerst), "LTRU Working Group" From: Martin Duerst Subject: RE: [Ltru] Charter Discussion In-Reply-To: <6.0.0.20.2.20060606090531.04f69840@localhost> References: <6.0.0.20.2.20060606090531.04f69840@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 09:05 06/06/06, Debbie Garside wrote: >Hi All > >FYI, herewith the ISO targets for 639-3 and 639-6 > >ISO 639-3 >Bilingual FDIS in preparation -- Target date for circulation: Beginning >September 2006, maybe before. That estimate looks like it's a bit later than what Peter said (closing date in August). Anybody have any more precise information? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 22:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRi3-0000yd-MJ; Mon, 05 Jun 2006 22:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRi3-0000yU-2r for ltru@ietf.org; Mon, 05 Jun 2006 22:54:23 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnRhz-00056y-Em for ltru@ietf.org; Mon, 05 Jun 2006 22:54:21 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k562s6cX008530 for ; Tue, 6 Jun 2006 11:54:06 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5d78_b847d5f6_f507_11da_9e7b_0014221fa3c9; Tue, 06 Jun 2006 11:54:06 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k562rk9E027035 for ; Tue, 6 Jun 2006 11:54:06 +0900 Message-Id: <6.0.0.20.2.20060606115146.04e210e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 06 Jun 2006 11:53:36 +0900 To: "LTRU Working Group" From: Martin Duerst Subject: RE: [Ltru] Charter Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [sorry - this got cought by a spam filter] >From: "Debbie Garside" >To: "'Peter Constable'" ,"'LTRU Working Group'" > >Subject: RE: [Ltru] Charter Discussion >Date: Tue, 6 Jun 2006 00:56:06 +0100 >Thread-Index: AcaHvaSrmFysHuZiRkSQeAZ0pPXtigBMEscwAANNCDA= >In-Reply-To: > >Peter wrote: >> I can't tell for certain whether it has >> actually been circulated yet. > >I have not seen sight of it yet and I would normally expect to see it within >a day or so of circulation. Will make enquiries at BSI. > >Debbie > > > >> -----Original Message----- >> From: Peter Constable [mailto:petercon@microsoft.com] >> Sent: 05 June 2006 23:28 >> To: LTRU Working Group >> Subject: RE: [Ltru] Charter Discussion >> >> > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >> >> >> > Does anybody have any kinds of more concrete information >> about ISO 639-3? >> > Current status? Maximum or minimum time it takes for the next stage? >> > Deadlines (e.g. for voting,...) that are already know? Peter? >> >> The FDIS document has been submitted to ISO CS for >> circulation of the FDIS ballot. As I do not receive the >> ballot (that gets sent to national body agencies -- ANSI in >> the case of US), I can't tell for certain whether it has >> actually been circulated yet. But I expect the FDIS ballot >> should be complete by early August. >> >> Besides the matter of final approval of the text of 639-3, >> there have been some open issues regarding the draft code >> table that the ISO 639-RA/Joint Advisory Committee needs to >> wrap up. I'm hoping that will also be complete by some time >> in August, though realistically it will probably take a >> little longer than the ballot. But that should not present an >> obstacle to the WG beginning to discuss what changes are >> needed for 3066ter. >> >> >> >> Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 23:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnSJ7-0002uw-Ff; Mon, 05 Jun 2006 23:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnSJ5-0002ul-GY for ltru@ietf.org; Mon, 05 Jun 2006 23:32:39 -0400 Received: from mailb.microsoft.com ([131.107.1.8] helo=mail3.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnSJ4-0000ln-7E for ltru@ietf.org; Mon, 05 Jun 2006 23:32:39 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 20:32:37 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 20:32:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 20:32:32 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060606090531.04f69840@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaI/QhEm2IY39xXS32G8bGGksbkZgAHHXwA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 06 Jun 2006 03:32:37.0202 (UTC) FILETIME=[DB3CCB20:01C68919] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Debbie Garside [mailto:md@ictmarketing.co.uk] > ISO 639-3 > Bilingual FDIS in preparation -- Target date for circulation: Beginning > September 2006, maybe before. The target of September was assuming we needed to get AFNOR to handle preparation of the French document, but I got that done on my end and submitted both English and French. So, this is definitely before (three months before). Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jun 05 23:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnSM5-0004MQ-M9; Mon, 05 Jun 2006 23:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnSM5-0004MK-5j for ltru@ietf.org; Mon, 05 Jun 2006 23:35:45 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnSM2-0001oi-Pr for ltru@ietf.org; Mon, 05 Jun 2006 23:35:45 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Mon, 5 Jun 2006 20:35:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 20:35:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Mon, 5 Jun 2006 20:35:05 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060606114849.04e21360@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaJFImmGn3HueaqRsmpViOx6wwthAABWDhw From: "Peter Constable" To: "Martin Duerst" , "Debbie Garside" , "LTRU Working Group" X-OriginalArrivalTime: 06 Jun 2006 03:35:41.0622 (UTC) FILETIME=[49290D60:01C6891A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The info I gave you is more up to date than what Debbie had available. The only information more precise than what I offered would have to come either directly from ISO CS or from the first person to see the actual FDIS circulation. Peter Constable > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Monday, June 05, 2006 7:51 PM > To: Debbie Garside; LTRU Working Group > Subject: RE: [Ltru] Charter Discussion >=20 > At 09:05 06/06/06, Debbie Garside wrote: > >Hi All > > > >FYI, herewith the ISO targets for 639-3 and 639-6 > > > >ISO 639-3 > >Bilingual FDIS in preparation -- Target date for circulation: Beginning > >September 2006, maybe before. >=20 > That estimate looks like it's a bit later than what Peter said > (closing date in August). Anybody have any more precise information? >=20 > Regards, Martin. >=20 >=20 >=20 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 03:00:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnVY2-0005Gb-R3; Tue, 06 Jun 2006 03:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnVY2-0005GW-GD for ltru@ietf.org; Tue, 06 Jun 2006 03:00:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnVY2-0008Cs-Eg for ltru@ietf.org; Tue, 06 Jun 2006 03:00:18 -0400 Received: from suomi.kotus.fi ([193.166.18.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnVUS-0005Vk-Ub for ltru@ietf.org; Tue, 06 Jun 2006 02:56:39 -0400 Received: from kotus.fi (pc094.kotus.fi [193.166.18.94]) by suomi.kotus.fi (8.12.10+Sun/8.12.10) with ESMTP id k566uSiT021121; Tue, 6 Jun 2006 09:56:28 +0300 (EEST) Message-ID: <4485271B.70905@kotus.fi> Date: Tue, 06 Jun 2006 09:56:27 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] Charter Discussion References: <1dea01c688bb$9b521eb0$0400a8c0@debbie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The reason why FDIS documents can be cited is that no proposals for technical changes are allowed in the ISO FDIS ballot, which is a binary yes/no ballot. Thus, the content of the standard (editorial changes notwithstanding) remains intact from that point on (unless there is a truly exceptionally compelling reason). The only risk is that the standard may be rejected in its entirety, which is highly unlikely. Kind regards, Erkki I. Kolehmainen Debbie Garside wrote: > Hi > > Felix wrote: > >>I'm not familiar with ISO processes, so I don't know if this last >> > statement is valid. > > I would accept Gerhard's word - he is chair of ISO TC37/SC2 > > Best regards > > Debbie > > > -----Original Message----- > From: Felix Sasaki [mailto:fsasaki@w3.org] > Sent: 05 June 2006 16:49 > To: Martin Duerst > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] Charter Discussion > > Hello Martin, all, > > [...] > > Martin Duerst wrote: > >>Does anybody have any kinds of more concrete information about ISO 639-3? >>Current status? Maximum or minimum time it takes for the next stage? >>Deadlines (e.g. for voting,...) that are already know? Peter? >> > > Maybe Peter has more / different information, but I talked at last weeks > LREC conference to Gerhard Budin (University of Vienna), who is in the ISO > committee which defines 639-3. > > He said 639-3 is now be in the FDIS stadium, and they don't expect major > issues. There is a 6 months period to wait for comments, so the final > standard will be published at the beginning of 2007. However, Gerhard said > that it is possible to cite FDIS versions of ISO drafts "officially". > > I'm not familiar with ISO processes, so I don't know if this last statement > is valid. > > Regards, Felix. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 03:41:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnWBb-0001NU-4Q; Tue, 06 Jun 2006 03:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnWBa-0001NP-DR for ltru@ietf.org; Tue, 06 Jun 2006 03:41:10 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnWBY-0004N7-W3 for ltru@ietf.org; Tue, 06 Jun 2006 03:41:10 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k567etgX028757; Tue, 6 Jun 2006 08:40:55 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k567el9O028552; Tue, 6 Jun 2006 08:40:54 +0100 Message-Id: <200606060740.k567el9O028552@mta2.iomartmail.com> From: "Debbie Garside" To: "'John Cowan'" , "'Debbie Garside'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 6 Jun 2006 08:40:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaJD1y8l7mnneOuTjeDq7x7HsKrBgAK8oig In-Reply-To: <20060606021726.GB14868@ccil.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John wrote: > Is there going to be a full mapping from 639-3 codes to 639-6 > ones available? Because without that I don't think > 3066quater efforts can even start. Yes. This is currently being done as part of the standardization effort. You may be interested to know that no 639-6 alpha4 representation will be allocated to a linguistic entity that already has a 639-3 alpha3 code. > Also, will the hierarchical relationships be published with 639-6? Yes. The alpha4 parent representation will be published as part of the data supporting the standard; essentially alpha4 representation, alpha4 parent representation and Unique (Linguistic) Identifier (UI in 11179). > Sure. They're not directly relevant for 3066 revision, but > they'd be interesting. CD 639-4 : DIS in preparation Target date for DIS circulation : 2006-06-31 Target closing date for DIS circulation : 2006-09-29 Target date for circulation of FDIS : 2007-01-31 Target date for ISO Standard publication: 2007-04 CD 639-5 : DIS in preparation Target date for DIS circulation : 2006-05-19 Target closing date for DIS circulation : 2006-08-19 Target date for circulation of FDIS : 2006-12-30 Target date for ISO Standard publication: 2007-03 Best regards Debbie > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 06 June 2006 03:17 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] Charter Discussion > > Debbie Garside scripsit: > > > ISO 639-6 > > DIS in preparation > > Target date for circulation : 2006-09-29 > > Target closing date on DIS circulation : 2006-12-29 > > > > Target date for circulation of FDIS : 2007-03-29 > > Target date for ISO Standard : 2007-06 > > Is there going to be a full mapping from 639-3 codes to 639-6 > ones available? Because without that I don't think > 3066quater efforts can even start. > > Also, will the hierarchical relationships be published with 639-6? > > > I also have target dates for 639-4 and 639-5 if anyone is > interested > > let me know. > > Sure. They're not directly relevant for 3066 revision, but > they'd be interesting. > > -- > No, John. I want formats that are actually John Cowan > useful, rather than over-featured megaliths that > http://www.ccil.org/~cowan > address all questions by piling on ridiculous cowan@ccil.org > internal links in forms which are hideously over-complex. > --Simon St. Laurent on xml-dev > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 08:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnald-0005N3-9U; Tue, 06 Jun 2006 08:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnalc-0005My-64 for ltru@ietf.org; Tue, 06 Jun 2006 08:34:40 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnala-00034E-Mr for ltru@ietf.org; Tue, 06 Jun 2006 08:34:40 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k56CYCeU015320; Tue, 6 Jun 2006 13:34:13 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k56CY1KQ014883; Tue, 6 Jun 2006 13:34:07 +0100 Message-Id: <200606061234.k56CY1KQ014883@mta6.iomartmail.com> From: "Debbie Garside" To: "'Peter Constable'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 6 Jun 2006 13:33:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaJFImmGn3HueaqRsmpViOx6wwthAABWDhwABLYZzA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: ISO FDIS 639-3: No sight of it yet but the BSI sec will inform me as soon as it surfaces! Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 06 June 2006 04:35 > To: Martin Duerst; Debbie Garside; LTRU Working Group > Subject: RE: [Ltru] Charter Discussion > > The info I gave you is more up to date than what Debbie had available. > The only information more precise than what I offered would > have to come either directly from ISO CS or from the first > person to see the actual FDIS circulation. > > > Peter Constable > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: Monday, June 05, 2006 7:51 PM > > To: Debbie Garside; LTRU Working Group > > Subject: RE: [Ltru] Charter Discussion > > > > At 09:05 06/06/06, Debbie Garside wrote: > > >Hi All > > > > > >FYI, herewith the ISO targets for 639-3 and 639-6 > > > > > >ISO 639-3 > > >Bilingual FDIS in preparation -- Target date for circulation: > Beginning > > >September 2006, maybe before. > > > > That estimate looks like it's a bit later than what Peter said > > (closing date in August). Anybody have any more precise information? > > > > Regards, Martin. > > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 12:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneSw-0005fW-4L; Tue, 06 Jun 2006 12:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneSv-0005fD-4y; Tue, 06 Jun 2006 12:31:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd4H-0002Lm-T3; Tue, 06 Jun 2006 11:02:05 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fncvg-0005Xb-Hs; Tue, 06 Jun 2006 10:53:14 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k56EqCmU015498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2006 14:52:12 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fncui-0006vD-27; Tue, 06 Jun 2006 10:52:12 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 06 Jun 2006 10:52:12 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Note: there was a previous last call request sent for a status of Proposed Standard; this document is, however, intended for BCP. The IESG has received a request from the Language Tag Registry Update WG to consider the following document: - 'Matching of Language Tags ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 19:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlH6-0003vW-0l; Tue, 06 Jun 2006 19:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnfAR-0003nj-VT; Tue, 06 Jun 2006 13:16:35 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnfAQ-0002RX-JW; Tue, 06 Jun 2006 13:16:35 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 06 Jun 2006 10:16:33 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k56HF2Bl012957; Tue, 6 Jun 2006 10:15:08 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k56HG9ru023672; Tue, 6 Jun 2006 10:16:23 -0700 (PDT) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0J0G007R57YXOJ@mailsj-v1.corp.adobe.com>; Tue, 06 Jun 2006 10:16:10 -0700 (PDT) Received: from MasinterT43p ([10.7.240.156]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0J0G00MYU7YX4P@mailsj-v1.corp.adobe.com>; Tue, 06 Jun 2006 10:16:09 -0700 (PDT) Date: Tue, 06 Jun 2006 10:15:33 -0700 From: Larry Masinter In-reply-to: To: iesg@ietf.org Message-id: <001401c6898c$d1c34560$9cf0070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcaJhrC20GzBFV9OQPitvU15MHxGGwABG1IQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Tue, 06 Jun 2006 19:47:51 -0400 Cc: ltru@ietf.org Subject: [Ltru] RE: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This made more sense to me as "proposed standard" than it does as BCP. It seems to describe a syntax and method which can be implemented and referenced by standards track documents. Could you explain the reasoning for why it is being considered as BCP rather than Proposed Standard? It would seem better to make this a "Proposed Standard". Consider, rather than just making an informative reference to [RFC2616errata], normatively updating [RFC2616]. It would help confirm the update of 2616 without recycling at "Proposed". Larry > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Tuesday, June 06, 2006 7:52 AM > To: IETF-Announce > Cc: ltru@ietf.org > Subject: Last Call: 'Matching of Language Tags' to BCP > (draft-ietf-ltru-matching) > > Note: there was a previous last call request sent for a status of Proposed > Standard; this document is, however, intended for BCP. > > The IESG has received a request from the Language Tag Registry Update WG to > consider the following document: > > - 'Matching of Language Tags ' > as a BCP _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 06 22:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnnQX-000600-MG; Tue, 06 Jun 2006 22:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnnQW-0005zp-ED for ltru@ietf.org; Tue, 06 Jun 2006 22:05:44 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnnQV-0004BA-6z for ltru@ietf.org; Tue, 06 Jun 2006 22:05:44 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060607020538.KDMM21801.mta9.adelphia.net@DGBP7M81> for ; Tue, 6 Jun 2006 22:05:38 -0400 Message-ID: <000901c689d6$ddc6ae70$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Charter Discussion Date: Tue, 6 Jun 2006 19:05:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > You may be interested to know that no 639-6 alpha4 representation will > be allocated to a linguistic entity that already has a 639-3 alpha3 > code. That is a dramatic step toward eliminating my concerns -- and probably those of others as well -- that 639-6 couldn't be made to work with a successor to RFC 3066bis. I'll still be interested to see how we would go about defining equivalences between a language-script combination, or a language-region combination, and a unitary 639-6 code element that means the same thing. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 08:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwy4-0003kT-8x; Wed, 07 Jun 2006 08:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwy3-0003kL-KB; Wed, 07 Jun 2006 08:16:59 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnwxz-0001OJ-UT; Wed, 07 Jun 2006 08:16:59 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k57CGiXV001322; Wed, 7 Jun 2006 21:16:44 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 43a8_7bb006d6_f61f_11da_8f22_0014221f2a2d; Wed, 07 Jun 2006 21:16:43 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k57CGbv5025338; Wed, 7 Jun 2006 21:16:42 +0900 Message-Id: <6.0.0.20.2.20060607210054.06604a40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 07 Jun 2006 21:16:10 +0900 To: Larry Masinter , iesg@ietf.org From: Martin Duerst Subject: Re: [Ltru] RE: Last Call: 'Matching of Language Tags' to BCP(draft-ietf-ltru-matching) In-Reply-To: <001401c6898c$d1c34560$9cf0070a@corp.adobe.com> References: <001401c6898c$d1c34560$9cf0070a@corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Larry, I have entered your two issues at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. At 02:15 06/06/07, Larry Masinter wrote: >This made more sense to me as "proposed standard" than >it does as BCP. It seems to describe a syntax and method >which can be implemented and referenced by standards >track documents. > >Could you explain the reasoning for why it is being considered >as BCP rather than Proposed Standard? > >It would seem better to make this a "Proposed Standard". The overall reasoning I think is that draft-ietf-ltru-registry-14.txt (often called RFC 3066bis) and draft-ietf-ltru-matching-14.txt together replace RFC 3066, which is/was a BCP. Also, the matching methods described actually can't just be taken and used directly. At a minimum, the syntax for a language range (e.g. whether commas or semicolons or whatever is used as delimiters, and so on) has to be defined. The WG (as well as to some extent the IESG) has discussed this issue already quite a few times. There were good arguments on both sides, but we had ultimately to decide on something. >Consider, rather than just making an informative reference >to [RFC2616errata], normatively updating [RFC2616]. >It would help confirm the update of 2616 without >recycling at "Proposed". This is, as far as I know, a totally new idea. Would this depend on the document moving to Proposed Standard? Is this general practice? [Just thinking aloud: in the limit, any RFC might update any other RFC in this fashion, and we might get into a situation like in the US congress, where totally unrelated stuff may be added to a bill.] In our WG, I think we don't really have the expertise to judge whether this would be a good thing. I wouldn't want to suddenly get complaints from the HTTP community. But if this helps the HTTP folks, and doesn't cost us anything, it might work. But for the "doesn't cost us anything", we'd need more precise wording/editing instructions. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 11:24:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnztD-0002I7-EG; Wed, 07 Jun 2006 11:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnztC-0002Hi-V2; Wed, 07 Jun 2006 11:24:10 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnztB-00078v-Oc; Wed, 07 Jun 2006 11:24:10 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8442EE000E; Wed, 7 Jun 2006 11:24:02 -0400 (EDT) To: Martin Duerst Subject: Re: [Ltru] RE: Last Call: 'Matching of Language Tags' to BCP(draft-ietf-ltru-matching) References: <001401c6898c$d1c34560$9cf0070a@corp.adobe.com> <6.0.0.20.2.20060607210054.06604a40@localhost> From: Sam Hartman Date: Wed, 07 Jun 2006 11:24:02 -0400 In-Reply-To: <6.0.0.20.2.20060607210054.06604a40@localhost> (Martin Duerst's message of "Wed, 07 Jun 2006 21:16:10 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org, Larry Masinter , iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >>>>> "Martin" == Martin Duerst writes: Martin> The WG (as well as to some extent the IESG) has discussed Martin> this issue already quite a few times. There were good Martin> arguments on both sides, but we had ultimately to decide Martin> on something. I think the IESG has only discussed whether the registry draft should be a bcp. I don't think any discussion I was involved in applied to the matching draft. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 11:36:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo04u-0001H2-Ee; Wed, 07 Jun 2006 11:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo04t-0001Gu-Fx; Wed, 07 Jun 2006 11:36:15 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo04s-0007qZ-4A; Wed, 07 Jun 2006 11:36:15 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c250.corp.yahoo.com [10.72.72.250]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k57FZ9v6010295; Wed, 7 Jun 2006 08:35:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=Co7hX00NITDj+X+VRspDTCr2fsNuyUzZ9w96cCsg55ZwDY4FfUiiI0skT6yWxaEd From: "Addison Phillips" To: "'Sam Hartman'" , "'Martin Duerst'" Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags' toBCP(draft-ietf-ltru-matching) Date: Wed, 7 Jun 2006 08:35:09 -0700 Message-ID: <003301c68a47$f5bb1ef0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcaKRn5spYqlb1hVTueXVkWPFXf3QAAADSCQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'Larry Masinter' , ltru@ietf.org, iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Actually, it did. In particular, RFC 3066bis (draft-ietf-ltru-registry-14) is blocked from publication as BCP 47 because draft-matching makes up "the other portion" of it. I (among others) produced arguments to the IESG that draft-matching should be on the STD track, but were told that, for historical reasons (i.e. it obsoletes two paragraphs of RFC 3066), it should remain part of BCP 47. I believe (and co-chair Martin can confirm) that the LTRU WG actually had a consensus recommending STD track for matching. I'll have to rootle around in the archives to find the involved messages. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: 2006?6?7? 8:24 > To: Martin Duerst > Cc: ltru@ietf.org; Larry Masinter; iesg@ietf.org > Subject: Re: [Ltru] RE: Last Call: 'Matching of Language > Tags' toBCP(draft-ietf-ltru-matching) > > >>>>> "Martin" == Martin Duerst writes: > > > Martin> The WG (as well as to some extent the IESG) has discussed > Martin> this issue already quite a few times. There were good > Martin> arguments on both sides, but we had ultimately to decide > Martin> on something. > > I think the IESG has only discussed whether the registry draft should > be a bcp. I don't think any discussion I was involved in applied to > the matching draft. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 18:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo64q-0002qD-KI; Wed, 07 Jun 2006 18:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo64p-0002q8-H7 for ltru@ietf.org; Wed, 07 Jun 2006 18:00:35 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo64o-0003RM-4P for ltru@ietf.org; Wed, 07 Jun 2006 18:00:35 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k57M0GwH022582; Wed, 7 Jun 2006 23:00:16 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k57LxbmM021844; Wed, 7 Jun 2006 23:00:15 +0100 Message-Id: <200606072200.k57LxbmM021844@mta6.iomartmail.com> From: "Debbie Garside" To: "'LTRU Working Group'" Date: Wed, 7 Jun 2006 22:59:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaKfarUEw4N2RJZT2iWN2XLdUrbng== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Ltru] LTRU Charter - Revised ISO 639 Target Dates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Since my email of a day or so ago quoting ISO 639 target dates as at April 2006, I have received a further update from ISO wrt targets for ISO 639 parts 4, 5 and 6. The new targets published as at 5th June 2006 are as follows: ------- - ISO/CD 639-4: Registered target dates are now: DIS: 2006-06-30, FDIS: 2007-03-30, Publication: 2007-10-30 - ISO/CD 639-5: Registered target dates are now: DIS: 2006-06-30, FDIS: 2007-03-30, Publication: 2007-10-30 - ISO/CD 639-6: Registered target dates are now: DIS: 2006-09-30, FDIS: 2007-06-30, Publication: 2008-01-30 ------- No new dates have been published for ISO FDIS 639-3. I am currently making enquiries as to why these targets have been revised and will report back when more information is available. Best regards Debbie Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 Fax: 0044 1437 766173 Web: http://www.ictmarketing.co.uk _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 18:06:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6Ag-0000Nj-D7; Wed, 07 Jun 2006 18:06:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6Af-0000NK-M0; Wed, 07 Jun 2006 18:06:37 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo6Ac-0003ZX-HS; Wed, 07 Jun 2006 18:06:37 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Wed, 07 Jun 2006 15:06:33 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k57M5ABl005687; Wed, 7 Jun 2006 15:05:10 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k57M6WHX013248; Wed, 7 Jun 2006 15:06:33 -0700 (PDT) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0J0I00JRKG2WU7@mailsj-v1.corp.adobe.com>; Wed, 07 Jun 2006 15:06:32 -0700 (PDT) Received: from MasinterT43p ([153.32.47.39]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0J0I007X6G2VOH@mailsj-v1.corp.adobe.com>; Wed, 07 Jun 2006 15:06:32 -0700 (PDT) Date: Wed, 07 Jun 2006 15:06:30 -0700 From: Larry Masinter Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags' to BCP(draft-ietf-ltru-matching) In-reply-to: <6.0.0.20.2.20060607210054.06604a40@localhost> To: "'Martin Duerst'" , iesg@ietf.org Message-id: <001701c68a7e$a144f080$272f2099@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaKLED6K4ISTWM4QHu8ULLPuPaw+wAUUlXQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I now understand why the document is Last Called as BCP, and accept the explanation. I suggest you mark the "two issues" as being resolved. Formally linking with the HTTP spec would not be "at no cost". (What was I thinking?) Larry > > I have entered your two issues at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > At 02:15 06/06/07, Larry Masinter wrote: > >This made more sense to me as "proposed standard" than > >it does as BCP. It seems to describe a syntax and method > >which can be implemented and referenced by standards > >track documents. > > > >Could you explain the reasoning for why it is being considered > >as BCP rather than Proposed Standard? > > > >It would seem better to make this a "Proposed Standard". >Consider, rather than just making an informative reference >to [RFC2616errata], normatively updating [RFC2616]. >It would help confirm the update of 2616 without >recycling at "Proposed". _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 07 23:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBDp-00071T-O8; Wed, 07 Jun 2006 23:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBDo-00071C-Rb for ltru@ietf.org; Wed, 07 Jun 2006 23:30:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoBDm-00076Y-H4 for ltru@ietf.org; Wed, 07 Jun 2006 23:30:12 -0400 Received: by wr-out-0506.google.com with SMTP id i28so317333wra for ; Wed, 07 Jun 2006 20:30:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WepzKzq1gEcpo3lsBt84mEsMVeVUpTi34yr8WHi/iERuRWRnUpJWWSvSPi0ygEC514tE3k7pjLAYNc3X0No3FndV08IIa0f+XYaLhMSoUxnDeD1yd2b5RG8jBHvOg0ZtkXMQ7QwQqVhcjgAPHIK72kSl5MmRB1S7msAJcpfma9Y= Received: by 10.65.240.8 with SMTP id s8mr241646qbr; Wed, 07 Jun 2006 20:30:10 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Wed, 7 Jun 2006 20:30:10 -0700 (PDT) Message-ID: <30b660a20606072030u5ccac27cvaf7fa1a8cb60945f@mail.gmail.com> Date: Wed, 7 Jun 2006 21:30:10 -0600 From: "Mark Davis" To: "Larry Masinter" Subject: Re: [Ltru] RE: Last Call: 'Matching of Language Tags' to BCP(draft-ietf-ltru-matching) In-Reply-To: <001701c68a7e$a144f080$272f2099@corp.adobe.com> MIME-Version: 1.0 References: <6.0.0.20.2.20060607210054.06604a40@localhost> <001701c68a7e$a144f080$272f2099@corp.adobe.com> X-Google-Sender-Auth: 7c088cf896a4ac64 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ltru@ietf.org, iesg@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911428412==" Errors-To: ltru-bounces@ietf.org --===============1911428412== Content-Type: multipart/alternative; boundary="----=_Part_8677_29694309.1149737410135" ------=_Part_8677_29694309.1149737410135 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I got a private message about the document: ... Hi Mark, The document is in very good form. I only could catch one editorial nit: There is no legend "Figure 1", though there are figures 2, 3 and 4. ... Mark On 6/7/06, Larry Masinter wrote: > > I now understand why the document is Last Called as BCP, > and accept the explanation. I suggest you mark > the "two issues" as being resolved. Formally linking > with the HTTP spec would not be "at no cost". > (What was I thinking?) > > Larry > > > > > > I have entered your two issues at > > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > > > At 02:15 06/06/07, Larry Masinter wrote: > > >This made more sense to me as "proposed standard" than > > >it does as BCP. It seems to describe a syntax and method > > >which can be implemented and referenced by standards > > >track documents. > > > > > >Could you explain the reasoning for why it is being considered > > >as BCP rather than Proposed Standard? > > > > > >It would seem better to make this a "Proposed Standard". > > >Consider, rather than just making an informative reference > >to [RFC2616errata], normatively updating [RFC2616]. > >It would help confirm the update of 2616 without > >recycling at "Proposed". > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_8677_29694309.1149737410135 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I got a private message about the document:

... 
Hi Mark,

The document is in very good form. I only could catch one editorial nit:
There is no legend "Figure 1", though there are figures 2, 3 and 4.
...

Mark

On 6/7/06, Larry Masinter <LMM@acm.org> wrote:
I now understand why the document is Last Called as BCP,
and accept the explanation. I suggest you mark
the "two issues" as being resolved. Formally linking
with the HTTP spec would not be "at no cost".
(What was I thinking?)

Larry


>
> I have entered your two issues at
> http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/.
>
> At 02:15 06/06/07, Larry Masinter wrote:
> >This made more sense to me as "proposed standard" than
> >it does as BCP. It seems to describe a syntax and method
> >which can be implemented and referenced by standards
> >track documents.
> >
> >Could you explain the reasoning for why it is being considered
> >as BCP rather than Proposed Standard?
> >
> >It would seem better to make this a "Proposed Standard".

>Consider, rather than just making an informative reference
>to [RFC2616errata], normatively updating [RFC2616].
>It would help confirm the update of 2616 without
>recycling at "Proposed".


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

------=_Part_8677_29694309.1149737410135-- --===============1911428412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1911428412==-- From ltru-bounces@ietf.org Thu Jun 08 10:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLmO-0001sG-Ib; Thu, 08 Jun 2006 10:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLmM-0001nH-SX for ltru@ietf.org; Thu, 08 Jun 2006 10:46:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLM4-0008Qz-Hk for ltru@ietf.org; Thu, 08 Jun 2006 10:19:24 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoLJP-0008QT-RE for ltru@ietf.org; Thu, 08 Jun 2006 10:16:44 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c215.corp.yahoo.com [10.72.72.215]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k58EFDDu004293; Thu, 8 Jun 2006 07:15:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:x-mailer:x-mimeole:thread-index:in-reply-to; b=oalg1wbAHWHNTAYFNrKhrAVY0x0NTHcNGZv78IhZbRqlOaIZXN9ceqfe5sEFTK6n From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags' toBCP(draft-ietf-ltru-matching) Date: Thu, 8 Jun 2006 07:15:13 -0700 Message-ID: <003b01c68b05$f57264d0$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKq+Hco62T4hz5SOCnPVohS/xhXAAWcd/Q In-Reply-To: <30b660a20606072030u5ccac27cvaf7fa1a8cb60945f@mail.gmail.com> X-Spam-Score: -17.6 (-----------------) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711016003==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0711016003== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C68ACB.49138CD0" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C68ACB.49138CD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, Figure 1 is the Basic Language Range ABNF in Section 2.1. It is = not labelled with a title, hence the figure number doesn't appear. =20 Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 =20 _____ =20 From: Mark Davis [mailto:mark.davis@icu-project.org]=20 Sent: 2006=E5=B9=B46=E6=9C=887=E6=97=A5 20:30 To: Larry Masinter Cc: ltru@ietf.org; iesg@ietf.org Subject: Re: [Ltru] RE: Last Call: 'Matching of Language Tags' = toBCP(draft-ietf-ltru-matching) I got a private message about the document: ...=20 Hi Mark, The document is in very good form. I only could catch one editorial nit: There is no legend "Figure 1", though there are figures 2, 3 and 4. ... Mark On 6/7/06, Larry Masinter wrote:=20 I now understand why the document is Last Called as BCP, and accept the explanation. I suggest you mark the "two issues" as being resolved. Formally linking with the HTTP spec would not be "at no cost".=20 (What was I thinking?) Larry > > I have entered your two issues at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > At 02:15 06/06/07, Larry Masinter wrote: > >This made more sense to me as "proposed standard" than > >it does as BCP. It seems to describe a syntax and method > >which can be implemented and referenced by standards=20 > >track documents. > > > >Could you explain the reasoning for why it is being considered > >as BCP rather than Proposed Standard? > > > >It would seem better to make this a "Proposed Standard".=20 >Consider, rather than just making an informative reference >to [RFC2616errata], normatively updating [RFC2616]. >It would help confirm the update of 2616 without >recycling at "Proposed".=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru = =20 ------=_NextPart_000_003C_01C68ACB.49138CD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
FWIW,=20 Figure 1 is the Basic Language Range ABNF in Section 2.1. It is not = labelled=20 with a title, hence the figure number doesn't = appear.
 
Addison

Addison Phillips
Internationalization Architect - = Yahoo!=20 Inc.

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

 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: = 2006=E5=B9=B46=E6=9C=887=E6=97=A5=20 20:30
To: Larry Masinter
Cc: ltru@ietf.org;=20 iesg@ietf.org
Subject: Re: [Ltru] RE: Last Call: 'Matching = of=20 Language Tags' toBCP(draft-ietf-ltru-matching)

I got a private message about the document:

...=20 
Hi Mark,

The document is in very good form. =
I only could catch one editorial nit:
There is no legend "Figure 1", =
though there are figures 2, 3 and =
4.
...

Mark

On 6/7/06, Larry=20 Masinter <LMM@acm.org>=20 wrote:
I=20 now understand why the document is Last Called as BCP,
and accept = the=20 explanation. I suggest you mark
the "two issues" as being = resolved.=20 Formally linking
with the HTTP spec would not be "at no cost". =
(What=20 was I thinking?)

Larry


>
> I have entered = your=20 two issues at
> http://www.sw.it.a= oyama.ac.jp/2006/IETF/ltru/.
>
>=20 At 02:15 06/06/07, Larry Masinter wrote:
> >This made more = sense to=20 me as "proposed standard" than
> >it does as BCP. It seems = to=20 describe a syntax and method
> >which can be implemented = and=20 referenced by standards
> >track documents.
> = >
>=20 >Could you explain the reasoning for why it is being = considered
>=20 >as BCP rather than Proposed Standard?
> >
> = >It would=20 seem better to make this a "Proposed Standard". =

>Consider, rather=20 than just making an informative reference
>to [RFC2616errata], = normatively updating [RFC2616].
>It would help confirm the = update of=20 2616 without
>recycling at "Proposed".=20


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

------=_NextPart_000_003C_01C68ACB.49138CD0-- --===============0711016003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0711016003==-- From ltru-bounces@ietf.org Thu Jun 08 17:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSKk-0001hs-KG; Thu, 08 Jun 2006 17:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSKi-0001hn-UY for ltru@ietf.org; Thu, 08 Jun 2006 17:46:28 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSKg-0007gL-8K for ltru@ietf.org; Thu, 08 Jun 2006 17:46:28 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k58LkHR2026181; Fri, 9 Jun 2006 06:46:17 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7939_37012e2e_f738_11da_9dc7_0014221f2a2d; Fri, 09 Jun 2006 06:46:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k58Lk86M028438; Fri, 9 Jun 2006 06:46:14 +0900 Message-Id: <6.0.0.20.2.20060609063300.06723b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 09 Jun 2006 06:40:36 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags'toBCP(draft-ietf-ltru-matching) In-Reply-To: <003b01c68b05$f57264d0$650a0a0a@ds.corp.yahoo.com> References: <30b660a20606072030u5ccac27cvaf7fa1a8cb60945f@mail.gmail.com> <003b01c68b05$f57264d0$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Addison, As a co-chair: Are you proposing to leave things as they are, or just explaining why they are the way they are? As a technical participant: I propose to remove the titles and "Figure" labels for what is currently Figure 2-4. None of these really look like figures, one is a single ABNF rule, and two are numbered lists. If it says "Figure", I'd expect some ASCII-art diagram or some such. (We can still use the
element in the XML.) Regards, Martin. At 23:15 06/06/08, Addison Phillips wrote: >FWIW, Figure 1 is the Basic Language Range ABNF in Section 2.1. It is not labelled with a title, hence the figure number doesn't appear. > >Addison > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > > > >---------- >From: Mark Davis [mailto:mark.davis@icu-project.org] >Sent: 2006$Bj;%((B6$Bk|/kw!&(B 20:30 >To: Larry Masinter >Cc: ltru@ietf.org; iesg@ietf.org >Subject: Re: [Ltru] RE: Last Call: 'Matching of Language Tags' toBCP(draft-ietf-ltru-matching) > >I got a private message about the document: > >... >> >>Hi Mark, >> >> >>The document is in very good form. I only could catch one editorial nit: >> >>There is no legend "Figure 1", though there are figures 2, 3 and 4. >... > >Mark > >On 6/7/06, Larry Masinter <LMM@acm.org> wrote: >I now understand why the document is Last Called as BCP, >and accept the explanation. I suggest you mark >the "two issues" as being resolved. Formally linking >with the HTTP spec would not be "at no cost". >(What was I thinking?) > >Larry > > >> >> I have entered your two issues at >> http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. >> >> At 02:15 06/06/07, Larry Masinter wrote: >> >This made more sense to me as "proposed standard" than >> >it does as BCP. It seems to describe a syntax and method >> >which can be implemented and referenced by standards >> >track documents. >> > >> >Could you explain the reasoning for why it is being considered >> >as BCP rather than Proposed Standard? >> > >> >It would seem better to make this a "Proposed Standard". > >>Consider, rather than just making an informative reference >>to [RFC2616errata], normatively updating [RFC2616]. >>It would help confirm the update of 2616 without >>recycling at "Proposed". > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 08 18:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSXP-0001WZ-2Z; Thu, 08 Jun 2006 17:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSXN-0001WR-An for ltru@ietf.org; Thu, 08 Jun 2006 17:59:33 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSXM-0000o4-0U for ltru@ietf.org; Thu, 08 Jun 2006 17:59:33 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k58LufjC064775; Thu, 8 Jun 2006 14:56:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=qQ6TTg3EjDU1zsQS89jcwu11vOpVZofLvtk8+KTDrJeRu+ySpAfnha4d5WXj+O/2 From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags'toBCP(draft-ietf-ltru-matching) Date: Thu, 8 Jun 2006 14:56:38 -0700 Message-ID: <004301c68b46$6de084c0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060609063300.06723b00@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaLRTl6AjCiuMAvQg6tZwwR5dPYUwAAOn8Q X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Are you proposing to leave things as they are, or just > explaining why they are the way they are? Just explaining the 'why'. It's an editorial change to add or remove figure titles and I don't much think it matters which way we go. It's not like the titles are vital for anything. > I propose to remove the titles and "Figure" labels for what > is currently Figure 2-4. None of these really look like > figures, one is a single ABNF rule, and two are numbered > lists. If it says "Figure", I'd expect some ASCII-art > diagram or some such. (We can still use the
> element in the XML.) +1 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 13 01:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1PZ-00039v-0c; Tue, 13 Jun 2006 01:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1PY-00039o-4l for ltru@ietf.org; Tue, 13 Jun 2006 01:25:56 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1PN-00057S-Fi for ltru@ietf.org; Tue, 13 Jun 2006 01:25:48 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5D5PHJ0024268; Tue, 13 Jun 2006 14:25:17 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 621b_ffbc8572_fa9c_11da_8b80_0014221f2a2d; Tue, 13 Jun 2006 14:25:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5D5Orb4022953; Tue, 13 Jun 2006 14:25:01 +0900 Message-Id: <6.0.0.20.2.20060613134818.06674850@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Jun 2006 13:50:21 +0900 To: "Addison Phillips" , "'Mark Davis'" , Ted Hardie From: Martin Duerst Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags'toBCP(draft-ietf-ltru-matching) In-Reply-To: <004301c68b46$6de084c0$9fcd15ac@ds.corp.yahoo.com> References: <6.0.0.20.2.20060609063300.06723b00@localhost> <004301c68b46$6de084c0$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have seen Addison agreeing, and nobody else disagreeing, to my proposal to remove all three currently existing Figure titles to eliminate the numbering problem that was pointed out in IETF Last Call. Unless we hear otherwise from our AD (Ted), I'd like to instruct the editors to proceed with this change. Regards, Martin. At 06:56 06/06/09, Addison Phillips wrote: >> Are you proposing to leave things as they are, or just >> explaining why they are the way they are? > >Just explaining the 'why'. It's an editorial change to add or remove figure >titles and I don't much think it matters which way we go. It's not like the >titles are vital for anything. > >> I propose to remove the titles and "Figure" labels for what >> is currently Figure 2-4. None of these really look like >> figures, one is a single ABNF rule, and two are numbered >> lists. If it says "Figure", I'd expect some ASCII-art >> diagram or some such. (We can still use the
>> element in the XML.) > >+1 > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 13 01:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1ot-0005yH-9j; Tue, 13 Jun 2006 01:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1or-0005y8-T1; Tue, 13 Jun 2006 01:52:05 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1oo-0007Tw-UF; Tue, 13 Jun 2006 01:52:05 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5D5pxVK026254; Tue, 13 Jun 2006 14:51:59 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 62b0_bac36d38_faa0_11da_87c4_0014221f2a2d; Tue, 13 Jun 2006 14:51:58 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5D5puaO023362; Tue, 13 Jun 2006 14:51:56 +0900 Message-Id: <6.0.0.20.2.20060531180303.0a1aa400@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Jun 2006 14:40:21 +0900 To: iesg@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: LTRU Working Group Subject: [Ltru] Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org These are my comments on draft-ietf-ltru-matching-14.txt, currently in IETF Last Call: All of these comments are purely editorial, but should increase the quality of the document. First comment: Improve the reference to XML: draft-ietf-ltru-matching-14.txt currently has: [W3C.REC-xml-20040204] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004. This is in no way appropriate, because the order of the authors is jumbled due to the fact that RDF get involved, and whoever at W3C did that RDF application didn't take into account that RDF (out of the box) doesn't deal with order, whereas the order of authors is usually relevant. Also, as a former W3C Team member, I'd REALLY like to see the URI, because for W3C Recs, the URI is the real thing. Here is an examlpe of what I think things should look like (from RFC 3987): [XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation, February 2004, . And here is the relevant piece of XML source, for the editors: Extensible Markup Language (XML) 1.0 (Third Edition) Second comment: Appendix A says: The contributors to [RFC3066bis], [RFC3066] and [RFC1766], each of which is a precursor to this document, made enormous contributions directly or indirectly to this document and are generally responsible for the success of language tags. I think it's somewhat misleading to mention RFC3066bis (draft-ietf-ltru-registry) as a precursor of draft-ietf-ltru-matching in the same way as RFC 3066 and RFC 1766 (I understand that draft-ietf-ltru-registry and draft-ietf-ltru-matching were once a single document, and in this way, draft-ietf-ltru-registry can be called a 'precursor', but for somebody not understanding the document history, this will be confusing.) I would suggest to improve this as follows (approprately formatted): The contributors to [RFC3066] and [RFC1766], each of which is a precursor to this document, as well as the contributors to [RFC3066bis], made enormous contributions directly or indirectly to this document and are generally responsible for the success of language tags. Third comment: The Abstract says: This document describes a syntax, called a "language-range", for specifying items in a user's language preferences, called a "language priority list". It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. I'm not totally happy with the first sentence, in particular the second part: This document describes a syntax, called a "language-range", for specifying items in a user's language preferences, called a "language priority list". It's not really clear whether "language priority list" refers to "items" or "preferences"; in both cases, there is a singular/plural conflict. There are at least two ways to improve this: a) be more explicit, e.g.: This document describes a syntax, called a "language-range", for specifying items in the list of a user's language preferences, called a "language priority list". b) be less explicit, e.g.: This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. I have to say that I prefer b), because it is simpler, and while the spec does (define and use) the term "language preference list", it does not actually define a protocol element and syntax with that name, and therefore mentioning this term in the abstract is of minor importance (or actually gives the wrong impression). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 13 07:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7X1-0006v5-15; Tue, 13 Jun 2006 07:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7Wz-0006uu-Pi; Tue, 13 Jun 2006 07:58:01 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq7Wy-0003cw-E2; Tue, 13 Jun 2006 07:58:01 -0400 Received: from duringpersonlx (traveling-laptop-237.london.corp.yahoo.com [10.76.38.237]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5DBvJG1003424; Tue, 13 Jun 2006 04:57:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=lBYIRH9RZBiq8Mk3VqR68lMnyjBy+a3UqKCfuIu+2PSmWzH0u4jpRqkTr45Wm9dl From: "Addison Phillips" To: "'Martin Duerst'" , Subject: RE: [Ltru] Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching) Date: Tue, 13 Jun 2006 12:57:19 +0100 Message-ID: <004201c68ee0$86c936b0$bfed4c0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaOrYiqg2td9D5aTke45smlcoyCzwALxxug In-Reply-To: <6.0.0.20.2.20060531180303.0a1aa400@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Martin, > First comment: Improve the reference to XML: > draft-ietf-ltru-matching-14.txt currently has: I already have it on the to-do list. Thank you for producing the correct XML. Did you forward it to the maintainers of bibxml4? > I think it's somewhat misleading to mention RFC3066bis > (draft-ietf-ltru-registry) as a precursor of draft-ietf-ltru-matching in the same way as > RFC 3066 and RFC 1766 (I understand that draft-ietf-ltru-registry and > draft-ietf-ltru-matching were once a single document, and in this way, > draft-ietf-ltru-registry can be > called a 'precursor', but for somebody not understanding the > document history, this will be confusing.) I would suggest to improve this as follows In fact, most of the text in draft-matching was ripped bodily from draft-registry... but more than that, the work that went into draft-registry to a great degree made this document's content "obvious". And much of this document's text was developed while it was still a part of draft-registry. The problem here is that the acknowledgements list for this document could not be recreated from the mashup in draft-registry (I just didn't track the stuff separately through the 10 draft-phillips-davis drafts and 10 or so draft-registry drafts before the split). Perhaps we should make that particular fact more explicit by saying: -- The contributors to [RFC 1766] and [RFC 3066], each of which was a precursor to this document, contributed greatly to the development of language tag matching, and, in particular, the basic language range and the basic matching scheme. This document was originally part of [RFC 3066bis], but was split off before that document's completion. Thus, directly or indirectly, those acknowledged in [RFC 3066bis] also had a hand in the the development of this document, and work done prior to the split is acknowledged in that document. -- I have nothing in particular to say about the last comment. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?6?13? 6:40 > To: iesg@ietf.org > Cc: LTRU Working Group > Subject: [Ltru] Last Call: 'Matching of Language Tags' to > Proposed Standard (draft-ietf-ltru-matching) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 13 08:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7Zi-00085n-7C; Tue, 13 Jun 2006 08:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7Zh-00085d-30 for ltru@ietf.org; Tue, 13 Jun 2006 08:00:49 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq7Ze-0003hr-Mg for ltru@ietf.org; Tue, 13 Jun 2006 08:00:49 -0400 Received: from duringpersonlx (traveling-laptop-237.london.corp.yahoo.com [10.76.38.237]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5DBxf0h003756; Tue, 13 Jun 2006 04:59:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=2XomAtgVJBJJK3tgDufwrunHYLfq/0la2Wimc8bw7LbjbXjsCkKu6fPO2RUhEu82 From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" , "'Ted Hardie'" Subject: RE: [Ltru] RE: Last Call: 'Matching of Language Tags'toBCP(draft-ietf-ltru-matching) Date: Tue, 13 Jun 2006 12:59:41 +0100 Message-ID: <004301c68ee0$db6389f0$bfed4c0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaOqezLH3OqkxqzQcmDMtUv6M/2iwANq9HQ In-Reply-To: <6.0.0.20.2.20060613134818.06674850@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I can't proceed with the change until we are done with the Last Call, can I? When we produce draft-15 (incorporating all comments, which so far are editorial in nature), then I'll happily do this. Question: should we expect a GenART review? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?6?13? 5:50 > To: Addison Phillips; 'Mark Davis'; Ted Hardie > Cc: ltru@ietf.org > Subject: RE: [Ltru] RE: Last Call: 'Matching of Language > Tags'toBCP(draft-ietf-ltru-matching) > > I have seen Addison agreeing, and nobody else disagreeing, to my > proposal to remove all three currently existing Figure titles to > eliminate the numbering problem that was pointed out in IETF > Last Call. > > Unless we hear otherwise from our AD (Ted), I'd like to instruct > the editors to proceed with this change. > > Regards, Martin. > > At 06:56 06/06/09, Addison Phillips wrote: > >> Are you proposing to leave things as they are, or just > >> explaining why they are the way they are? > > > >Just explaining the 'why'. It's an editorial change to add > or remove figure > >titles and I don't much think it matters which way we go. > It's not like the > >titles are vital for anything. > > > >> I propose to remove the titles and "Figure" labels for what > >> is currently Figure 2-4. None of these really look like > >> figures, one is a single ABNF rule, and two are numbered > >> lists. If it says "Figure", I'd expect some ASCII-art > >> diagram or some such. (We can still use the
> >> element in the XML.) > > > >+1 > > > >Addison Phillips > >Internationalization Architect - Yahoo! Inc. > > > >Internationalization is an architecture. > >It is not a feature. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 13 12:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqC8Z-00045d-Av; Tue, 13 Jun 2006 12:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqC8X-00045G-P4; Tue, 13 Jun 2006 12:53:05 -0400 Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqC8W-0005Yg-HQ; Tue, 13 Jun 2006 12:53:05 -0400 Received: from h-68-165-7-130.snvacaid.dynamic.covad.net ([68.165.7.130] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FqC8R-0001FO-00; Tue, 13 Jun 2006 12:52:59 -0400 Message-ID: <003d01c68f0a$b11ab400$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <6.0.0.20.2.20060531180303.0a1aa400@localhost> Subject: Re: [Ltru] Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching) Date: Tue, 13 Jun 2006 09:59:06 -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-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Martin Duerst" > To: > Cc: "LTRU Working Group" > Sent: Monday, June 12, 2006 10:40 PM > Subject: [Ltru] Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching) ... > I'm not totally happy with the first sentence, in particular the second > part: > > This document describes a syntax, called a "language-range", for > specifying items in a user's language preferences, called a "language > priority list". > > It's not really clear whether "language priority list" refers to "items" > or "preferences"; in both cases, there is a singular/plural conflict. > a) be more explicit, e.g.: > > This document describes a syntax, called a "language-range", for > specifying items in the list of a user's language preferences, > called a "language priority list". > > b) be less explicit, e.g.: > > This document describes a syntax, called a "language-range", for > specifying items in a user's list of language preferences. > > I have to say that I prefer b), because it is simpler, and while > the spec does (define and use) the term "language preference list", > it does not actually define a protocol element and syntax with that name, > and therefore mentioning this term in the abstract is of minor importance > (or actually gives the wrong impression). ... Though I see nothing wrong with the sentence as is, I think the concerns might be addressed by something like: This document describes a syntax, called a "language-range". This syntax can function in protocol-specific constructs as part of a language priority list, indicating language preferences. But I don't feel strongly about this. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 14 23:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqili-0002yh-Mu; Wed, 14 Jun 2006 23:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqili-0002yb-2L for ltru@ietf.org; Wed, 14 Jun 2006 23:43:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqilZ-0003H2-EZ for ltru@ietf.org; Wed, 14 Jun 2006 23:43:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5F3hDI4015712 for ; Thu, 15 Jun 2006 12:43:13 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 4ff7_1266fede_fc21_11da_93b7_0014221fa3c9; Thu, 15 Jun 2006 12:43:12 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5F3gvL3024744 for ; Thu, 15 Jun 2006 12:43:13 +0900 Message-Id: <6.0.0.20.2.20060614154726.054a9140@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 14 Jun 2006 16:01:26 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Fwd: Re: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The following last call comments came in on the IETF mailing list. I'm forwarding it here with my comments interspersed. >Date: Wed, 07 Jun 2006 03:58:15 +0200 >To: ietf@ietf.org >From: "JFC (Jefsey) Morfin" >Subject: Re: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) >I noted the following typos: >- there is no Figure 1 We have already noted this as an issue, and currently the plan to remove the other Figure numbers/titles, because they don't contribute much to the overall understanding. >- Part 4.3 - typo in private agreement Anybody noticed anything? Can somebody please check? >- Appendix A - typo in Acknowledgments Anybody noticed anything? Can somebody please check? >- Appendix A - some names seem to be missing. I could quote a small score of them? If anybody who has contributed would like their name to be mentioned, or thinks that somebody else's name is missing, please don't hesitate to say so, or to contact the editors or chairs directly. Regards, Martin. >jfc #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 14 23:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqilv-00030N-Sk; Wed, 14 Jun 2006 23:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqilv-00030F-8h; Wed, 14 Jun 2006 23:43:55 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqils-0003fe-IP; Wed, 14 Jun 2006 23:43:55 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5F3hnqU010203; Thu, 15 Jun 2006 12:43:49 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 187e_27c2b6d8_fc21_11da_9a0f_0014221f2a2d; Thu, 15 Jun 2006 12:43:48 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5F3gvLF024744; Thu, 15 Jun 2006 12:43:48 +0900 Message-Id: <6.0.0.20.2.20060614180308.0721ce30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 14 Jun 2006 18:06:26 +0900 To: "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] Last Call: 'Matching of Language Tags' to ProposedStandard (draft-ietf-ltru-matching) In-Reply-To: <003d01c68f0a$b11ab400$6501a8c0@oemcomputer> References: <6.0.0.20.2.20060531180303.0a1aa400@localhost> <003d01c68f0a$b11ab400$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:59 06/06/14, Randy Presuhn wrote: >Hi - > >As a technical contributor... > >> From: "Martin Duerst" >> To: >> Cc: "LTRU Working Group" >> Sent: Monday, June 12, 2006 10:40 PM >> Subject: [Ltru] Last Call: 'Matching of Language Tags' to Proposed >Standard (draft-ietf-ltru-matching) >... >> I'm not totally happy with the first sentence, in particular the second >> part: >> >> This document describes a syntax, called a "language-range", for >> specifying items in a user's language preferences, called a "language >> priority list". >> >> It's not really clear whether "language priority list" refers to "items" >> or "preferences"; in both cases, there is a singular/plural conflict. >> a) be more explicit, e.g.: >> >> This document describes a syntax, called a "language-range", for >> specifying items in the list of a user's language preferences, >> called a "language priority list". >> >> b) be less explicit, e.g.: >> >> This document describes a syntax, called a "language-range", for >> specifying items in a user's list of language preferences. >> >> I have to say that I prefer b), because it is simpler, and while >> the spec does (define and use) the term "language preference list", >> it does not actually define a protocol element and syntax with that name, >> and therefore mentioning this term in the abstract is of minor importance >> (or actually gives the wrong impression). >... > >Though I see nothing wrong with the sentence as is, I think the >concerns might be addressed by something like: > > This document describes a syntax, called a "language-range". > This syntax can function in protocol-specific constructs as part > of a language priority list, indicating language preferences. > >But I don't feel strongly about this. Your text would be fine with me, too. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 15 02:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fql68-0006n8-4p; Thu, 15 Jun 2006 02:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fql66-0006k1-8I for ltru@ietf.org; Thu, 15 Jun 2006 02:12:54 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fql01-0007ry-UK for ltru@ietf.org; Thu, 15 Jun 2006 02:06:39 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060615060637.XUUJ17849.mta11.adelphia.net@DGBP7M81> for ; Thu, 15 Jun 2006 02:06:37 -0400 Message-ID: <008b01c69041$da2241f0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 14 Jun 2006 23:06:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> - Part 4.3 - typo in private agreement > > Anybody noticed anything? Can somebody please check? The word "agreement" is misspelled as "argeement" (G and R are reversed). >> - Appendix A - typo in Acknowledgments > > Anybody noticed anything? Can somebody please check? The word is spelled "Acknowledgements" instead of the preferred "Acknowledgments," without the E after the G. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 16 09:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEM6-0005ZV-GF; Fri, 16 Jun 2006 09:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEM6-0005ZN-7k for ltru@ietf.org; Fri, 16 Jun 2006 09:27:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrBfS-0002hq-Cb for ltru@ietf.org; Fri, 16 Jun 2006 06:35:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrBX6-0000hw-QM for ltru@ietf.org; Fri, 16 Jun 2006 06:26:38 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5GAQ099019142; Fri, 16 Jun 2006 19:26:00 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 3415_81cae180_fd22_11da_8afc_0014221f2a2d; Fri, 16 Jun 2006 19:26:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5GAPum9006450; Fri, 16 Jun 2006 19:26:00 +0900 Message-Id: <6.0.0.20.2.20060616191343.076930d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 16 Jun 2006 19:24:52 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -2.0 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Ltru] matching draft, issue 50 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I have asked for an improvement in the first sentence of the Abstract of the matching draft. I have proposed two new versions, and Randy has proposed a third, which would be fine by me, too. As a co-chair, I'm interested in getting this issue closed quickly, but I don't want to just pick one version. So please provide your preference. If you have yet another version, that's okay, too, but if possible, please try to select from one of those already on the table (including the current wording) so that we can close this issue quickly. So here are the four proposals, in chronological order: Proposal A (current text): This document describes a syntax, called a "language-range", for specifying items in a user's language preferences, called a "language priority list". Proposal B (from Martin): This document describes a syntax, called a "language-range", for specifying items in the list of a user's language preferences, called a "language priority list". Proposal C (from Martin): This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. Proposal D (from Randy): This document describes a syntax, called a "language-range". This syntax can function in protocol-specific constructs as part of a language priority list, indicating language preferences. Please express your preference. "anything is okay" is of course okay, but won't move us ahead. BTW, as a technical contributor, my preference is C before D before B before A. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 16 09:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEN7-0005l8-0G; Fri, 16 Jun 2006 09:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEN5-0005kx-WE for ltru@ietf.org; Fri, 16 Jun 2006 09:28:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrBfS-0002hq-Ec for ltru@ietf.org; Fri, 16 Jun 2006 06:35:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrBX6-0000hv-QM for ltru@ietf.org; Fri, 16 Jun 2006 06:26:37 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5GAQ0Ee002024; Fri, 16 Jun 2006 19:26:00 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 3375_81ba534c_fd22_11da_961c_0014221f2a2d; Fri, 16 Jun 2006 19:26:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5GAPum7006450; Fri, 16 Jun 2006 19:26:00 +0900 Message-Id: <6.0.0.20.2.20060616180806.07690dc0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 16 Jun 2006 19:19:31 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Intermediate disposition of IETF Last call comments X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear WG members, I have updated the list of comments resulting from the IETF Last Call of the matching draft at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. [I have received a report that this page cannot be accessed. While there has been a problem some months ago, I'm not aware of any problems now. If you happen to have problems accessing this page, please provide details (time, whether or not DNS resolution works, and so on). Thanks!] In the interest of moving forward, I'd like to assess consensus on those comments that I haven't seen any disagreement. If you think that any of these should be addressed differently, please say so. There is no need to mail in explicit agreements on these issues. Here are the issues and my proposed disposition: Issue 46: remove Figure numbers and titles from figures 2-4. Issue 47: adapt fixed reference for XML 1.0 Issue 48: adapt Acknowledgment text proposed by Addison Issue 50: fix typo as proposed by Doug (argeement -> agreement) Issue 51: fix typo as proposed by Doug (Acknowledgement -> Acknowledgment) Not listed here are issue 49, where we have various text proposals, which I'll address in a separate mail, and issue 52, where I haven't received any input from anybody yet (but none is needed if nobody feels they have been left out). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 16 09:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEl5-0005t8-Q7; Fri, 16 Jun 2006 09:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEl5-0005t3-4F for ltru@ietf.org; Fri, 16 Jun 2006 09:53:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEl3-0007Yu-U1 for ltru@ietf.org; Fri, 16 Jun 2006 09:53:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FrEl1-0002nD-Ox; Fri, 16 Jun 2006 09:53:07 -0400 Date: Fri, 16 Jun 2006 09:53:07 -0400 To: Martin Duerst Subject: Re: [Ltru] matching draft, issue 50 Message-ID: <20060616135307.GB32743@ccil.org> References: <6.0.0.20.2.20060616191343.076930d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060616191343.076930d0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > BTW, as a technical contributor, my preference is C before D before > B before A. +1 -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Is it not written, "That which is written, is written"? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 17 17:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frhv0-0002Zk-Vn; Sat, 17 Jun 2006 17:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frhv0-0002Zf-FR for ltru@ietf.org; Sat, 17 Jun 2006 17:01:22 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frhuy-00015Y-6g for ltru@ietf.org; Sat, 17 Jun 2006 17:01:22 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c41.corp.yahoo.com [10.72.76.41]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5HL0iWd011630; Sat, 17 Jun 2006 14:00:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=Ayna53/Pbd0kSnbsBxEemcFKLc6+g71di+JbM3R2Azwzu7y5+tqMgzAsUrZRqurV From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Issue 52 (list of acknowledgments) Date: Sat, 17 Jun 2006 14:00:43 -0700 Message-ID: <002f01c69251$1a021c30$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060616180806.07690dc0@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaRSM7P5REXXN8lSDW6JbURR2nCWwBB/fSA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This editor feel no one has been left out. Individuals are welcome to correct that perception, but, pace my adding someone to the list in draft-15 (for a new contribution or because someone has convinced an editory that they have unjustly been overlooked), the list is what the list is. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?6?16? 3:20 > To: LTRU Working Group > Subject: [Ltru] Intermediate disposition of IETF Last call comments > > Dear WG members, > > I have updated the list of comments resulting from the IETF Last Call > of the matching draft at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > [I have received a report that this page cannot be accessed. > While there has been a problem some months ago, I'm not aware > of any problems now. If you happen to have problems accessing > this page, please provide details (time, whether or not DNS > resolution works, and so on). Thanks!] > > In the interest of moving forward, I'd like to assess consensus on > those comments that I haven't seen any disagreement. If you think > that any of these should be addressed differently, please say so. > There is no need to mail in explicit agreements on these issues. > > Here are the issues and my proposed disposition: > > Issue 46: remove Figure numbers and titles from figures 2-4. > > Issue 47: adapt fixed reference for XML 1.0 > > Issue 48: adapt Acknowledgment text proposed by Addison > > Issue 50: fix typo as proposed by Doug (argeement -> agreement) > > Issue 51: fix typo as proposed by Doug (Acknowledgement -> > Acknowledgment) > > Not listed here are issue 49, where we have various text proposals, > which I'll address in a separate mail, and issue 52, where I haven't > received any input from anybody yet (but none is needed if nobody > feels they have been left out). > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 18 00:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrpGg-0002aC-T5; Sun, 18 Jun 2006 00:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrpGf-0002Zu-Gt for ltru@ietf.org; Sun, 18 Jun 2006 00:52:13 -0400 Received: from nz-out-0102.google.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FroWn-0000tJ-C8 for ltru@ietf.org; Sun, 18 Jun 2006 00:04:52 -0400 Received: by nz-out-0102.google.com with SMTP id q3so856941nzb for ; Sat, 17 Jun 2006 21:04:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=S87iKyaDi9EMiVOTiDE5JyCVcs+SHxfDdxQBEUn3h6PduhbHd/r5wkR3/PjXqrfSyFVMtCN6leOZKt4T6p3kPsVcQZMTa4Ma3Ck6+Z6B0o3gTIO1mTx7CJ7K66A4kNwF2veM1tqTM04i9+34FcrNnEBbB5H7GiX6zPAdAAzPi+A= Received: by 10.64.24.20 with SMTP id 20mr4371112qbx; Sat, 17 Jun 2006 21:04:49 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Sat, 17 Jun 2006 21:04:48 -0700 (PDT) Message-ID: <30b660a20606172104k11ef828fv9f7e8272b9718583@mail.gmail.com> Date: Sat, 17 Jun 2006 21:04:48 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Issue 52 (list of acknowledgments) In-Reply-To: <002f01c69251$1a021c30$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 References: <6.0.0.20.2.20060616180806.07690dc0@localhost> <002f01c69251$1a021c30$650a0a0a@ds.corp.yahoo.com> X-Google-Sender-Auth: 39a566a2a266f297 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1494755569==" Errors-To: ltru-bounces@ietf.org --===============1494755569== Content-Type: multipart/alternative; boundary="----=_Part_107772_28194357.1150603488933" ------=_Part_107772_28194357.1150603488933 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline this editor agrees -- md On 6/17/06, Addison Phillips wrote: > > This editor feel no one has been left out. Individuals are welcome to > correct that perception, but, pace my adding someone to the list in > draft-15 > (for a new contribution or because someone has convinced an editory that > they have unjustly been overlooked), the list is what the list is. > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: 2006?6?16? 3:20 > > To: LTRU Working Group > > Subject: [Ltru] Intermediate disposition of IETF Last call comments > > > > Dear WG members, > > > > I have updated the list of comments resulting from the IETF Last Call > > of the matching draft at > > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > > > [I have received a report that this page cannot be accessed. > > While there has been a problem some months ago, I'm not aware > > of any problems now. If you happen to have problems accessing > > this page, please provide details (time, whether or not DNS > > resolution works, and so on). Thanks!] > > > > In the interest of moving forward, I'd like to assess consensus on > > those comments that I haven't seen any disagreement. If you think > > that any of these should be addressed differently, please say so. > > There is no need to mail in explicit agreements on these issues. > > > > Here are the issues and my proposed disposition: > > > > Issue 46: remove Figure numbers and titles from figures 2-4. > > > > Issue 47: adapt fixed reference for XML 1.0 > > > > Issue 48: adapt Acknowledgment text proposed by Addison > > > > Issue 50: fix typo as proposed by Doug (argeement -> agreement) > > > > Issue 51: fix typo as proposed by Doug (Acknowledgement -> > > Acknowledgment) > > > > Not listed here are issue 49, where we have various text proposals, > > which I'll address in a separate mail, and issue 52, where I haven't > > received any input from anybody yet (but none is needed if nobody > > feels they have been left out). > > > > Regards, Martin. > > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp > > mailto:duerst@it.aoyama.ac.jp > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_107772_28194357.1150603488933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline this editor agrees -- md

On 6/17/06, Addison Phillips <addison@yahoo-inc.com> wrote:
This editor feel no one has been left out. Individuals are welcome to
correct that perception, but, pace my adding someone to the list in draft-15
(for a new contribution or because someone has convinced an editory that
they have unjustly been overlooked), the list is what the list is.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp]
> Sent: 2006?6?16? 3:20
> To: LTRU Working Group
> Subject: [Ltru] Intermediate disposition of IETF Last call comments
>
> Dear WG members,
>
> I have updated the list of comments resulting from the IETF Last Call
> of the matching draft at
> http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ .
>
> [I have received a report that this page cannot be accessed.
> While there has been a problem some months ago, I'm not aware
> of any problems now. If you happen to have problems accessing
> this page, please provide details (time, whether or not DNS
> resolution works, and so on). Thanks!]
>
> In the interest of moving forward, I'd like to assess consensus on
> those comments that I haven't seen any disagreement. If you think
> that any of these should be addressed differently, please say so.
> There is no need to mail in explicit agreements on these issues.
>
> Here are the issues and my proposed disposition:
>
> Issue 46: remove Figure numbers and titles from figures 2-4.
>
> Issue 47: adapt fixed reference for XML 1.0
>
> Issue 48: adapt Acknowledgment text proposed by Addison
>
> Issue 50: fix typo as proposed by Doug (argeement -> agreement)
>
> Issue 51: fix typo as proposed by Doug (Acknowledgement ->
> Acknowledgment)
>
> Not listed here are issue 49, where we have various text proposals,
> which I'll address in a separate mail, and issue 52, where I haven't
> received any input from anybody yet (but none is needed if nobody
> feels they have been left out).
>
> Regards,    Martin.
>
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp
> mailto:duerst@it.aoyama.ac.jp
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
>
>


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

------=_Part_107772_28194357.1150603488933-- --===============1494755569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1494755569==-- From ltru-bounces@ietf.org Mon Jun 19 21:21:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUvY-0008RS-33; Mon, 19 Jun 2006 21:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUvX-0008QD-EN for ltru@ietf.org; Mon, 19 Jun 2006 21:21:11 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUvV-0007SV-LD for ltru@ietf.org; Mon, 19 Jun 2006 21:21:11 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5K1KwqQ023299 for ; Tue, 20 Jun 2006 10:20:58 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 47cb_071c82dc_fffb_11da_9956_0014221f2a2d; Tue, 20 Jun 2006 10:20:57 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5K1KtwJ015611 for ; Tue, 20 Jun 2006 10:20:57 +0900 Message-Id: <6.0.0.20.2.20060619152554.076ad7d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 19 Jun 2006 15:28:17 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ltru] Fwd: Last call: BCP 47 second part. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear LTRU mailing list, This series of Last Call comments on the matching draft came through on the main IETF list. I'm forwarding it here for further discussion. Regards, Martin. >Date: Sun, 18 Jun 2006 16:56:00 +0200 >To: ietf@ietf.org >From: "JFC (Jefsey) Morfin" >Subject: Last call: BCP 47 second part. >List-Id: IETF-Discussion >List-Unsubscribe: , >List-Post: >List-Help: >List-Subscribe: , >Dear IESG Members, > >1. The proposed Draft is not about matching (it is absurd to say that my Italian can "match" your Japanese in order for us to understand each other better). It is about using pattern matching techniques in order to filter lists against a langtag with two results (max one answer, no max) and in two cases (well formed langtag or not). However, the wording is such that without examples it is difficult to understand the specifications of the pattern matching function that is being used - and therefore the possible applications and the purpose of the Draft. The algorithm of this function is undocumented and there is no obligation to document it, what may lead to blocking conflicts if two filters may have to interoperate. This proposition is NOT scalable and does not intent to be scalable. > >2. Either RFC 3066 Bis is well written (what I think we achieved if strictly limited to the Internationalized ASCII Internet) and well applied (what I can see that it is not the case: the review mechanism does not respect RFC 3066 Bis) and the filtering is already built-in, and the functional strategies are to be specific to applications and protocols. Or that Draft, which does not seek to first ensure that langtags respect RFC 3066 Bis (i.e. being well formed or corrected in order to become well formed), is a negation of RFC 3066 Bis. I think that authors had filtering in mind (it was the apex of the first unique document) and did not realise that the work achieved in cleaning the first part made its correction by the second part not necessary anymore. That is if the whole purpose was not a non documented use of the filtering (users mass profiling). If it was not the whole document can be written as "make sure langtags are well formed and feed them on the pattern matching function of your application/protocol to obtain the results it needs along your language management strategy". > >3. "*" restrictions in the pattern matching function can hardly be understood without several examples. They add usage limitations to the RFC 3066 Bis format, where they should be documented $B%e(B or the Draft cannot be part of BCP 47. This certainly belongs to the language constraining strategy of the WG-LTRU affinity group and to the interests a co-Chair recently documented. But this is unacceptable to most users, even if it is certainly favourable to a national strategy and to the members of a given consortium. I therefore submit that the IESG Members who are citizens of that nation, or members, or employees of the members of that commercial consortium have a COI. > >4. All the above means that the Draft is useful in at least two circumstances: > - if the langtags are not well formed or do not respect the principles of ISO 639-4 and/or RFC 3066 Bis. > - if the langtags are used for other purposes that are undocumented at the WG-LTRU Charter. >These circumstances should be documented. > >5. The security section should mention that this Daft encourages the disrespect of the RFC 3066 Bis format and further assists dangerous projects that the IETF has refused to mention in RFC 3066 Bis, such as lingual, cultural, racial, and religious profiling through retro-meta-spam ("I know who you are through which langtags you are not aware that you respond to"), two-tier Internet based upon the lingual characteristics of the users and their supposed market value, lack of conformance to ISO 11179, which may lead the IETF, stakeholders, and users to inadequate, costly, and delaying strategies or to conflicts with the Multilingual Internet - as in the sad DoS against the leading economic language ("en-EU") - or to legal access bans by democratic or privacy oriented countries. All of this lends itself to incentives for an Internet fragmentation. > >6. As far as I understand, two Draft compliant filters may result in different responses for the same filtering list and document. My concern is the interoperability of the proposed BCP 47 with Multilingual Internet registries, tags, etc. This interoperability is not ensured $B%e(B and there is no prospect to see it insured as it is purposely ignored by authors. This represents no incentive for developers. > >7. The acknowledgement section mostly quote those who contributed to the pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation of the WG which never studied and tried to conform to its Charter). This is the privilege of authors to quote who supported them best. However, in this case the document was considerably cleaned through the tough life of the WG. Also, most of the names being quoted are widely known as belonging to a non-IETF affinity group, what enforces the external understanding that BCP 47 documents are actually not IETF documents. This will most probably limit their consideration. After one year of tough debates I can testify these, good or not, three documents are IETF documents for the Internationalized ASCII Internet. I listed the names I consider missing in a Last C all mail. > >Authors either did not read it or are keeping harassing me, since they continue asking for an input. I quote my mail: "every contribution can be a key stone in the final construct. That people like Michael Everson, Ned Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce are real.". I do not ask my name to be listed there since I know "it is not [the] interest [of some in the list] to be associated with [my own] name". > >Or would that mean that the IETF does not really back this deliverable? The question here is: does the IETF wants to influence the world (RFC 3935), document the Internationalised ASCII Internet, or serve the Multilingual Internet development. Many would like to know. > >All the best. >jfc > >PS. Having transparency in mind I copy the IETF main list. This LC ends tomorrow. I do not intent to address the comments. But I will certainly consider them in the appeal I suspect to be unfortunately necessary (NB. Before their first day decision to keep with a twice IETF LC failed document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could finish the work in a few months. I obviously eventually get step by step all what I wanted - in the documents or in the real world: but what a waste of time and effort). Cheers. > > >jfc > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 18:04:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoKg-0007KP-W0; Tue, 20 Jun 2006 18:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoKf-0007KE-UL for ltru@ietf.org; Tue, 20 Jun 2006 18:04:25 -0400 Received: from mta5.iomartmail.com ([62.128.193.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsoKd-0007Hs-EW for ltru@ietf.org; Tue, 20 Jun 2006 18:04:25 -0400 Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5KM4MNn023001; Tue, 20 Jun 2006 23:04:22 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5KM4EQj022874; Tue, 20 Jun 2006 23:04:21 +0100 Message-Id: <200606202204.k5KM4EQj022874@mta5.iomartmail.com> From: "Debbie Garside" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 23:04:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <6.0.0.20.2.20060603091556.05543450@localhost> Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRA X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi There has been much discussion lately on IETF-languages with regard to updates/additions and structure/format of the Registry. If this WG is re-Chartered, I think it may be beneficial to include discussion on tighter rules and regulations for updates/additions to the Registry with some discussion on Registry format. To this end, it may also be beneficial to look in detail at ISO 11179. It could be suggested that further discussion in this regard take place when ISO FDIS 639-3 reaches full standard (approx. 6 months). It may therefore, with a mind to Martin's guidance, be more desirable to close this WG in the interim and to create a new WG and Charter at that time. However, given the length of time it has taken to get the various documents to Last Call this time round, I would not object to re-chartering with discussions commencing prior to publication of ISO 639-3. The key question here is how urgent is the need to facilitate ISO 639-3? Best regards Debbie Garside > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 03 June 2006 01:17 > To: LTRU Working Group > Subject: [Ltru] Charter Discussion > > Dear LTRU WG Members, > > Quite some time ago, we agreed that after finishing our > deliverables, we will have a discussion about the charter. > Randy and I would like to start this discussion now, because > we basically have finished our deliverables (we may need to > come back to the matching draft once in a while based on > comments in IETF Last Call and comments from the IESG). > > Discussions about (re)chartering are by nature rather > open-ended, but to focus discussion a bit, here are some questions: > > 1) What do you think is most needed after our current drafts are > approved (and published as RFCs). What are the next steps? > In what order/priority? > > 2) Is further specification work needed? Are there preconditions? > What are predicted/desirable timelines? > > 3) Where (which organizations) should further spec work be done? > What work should be done in the IETF? > > 4) In case further work in the IETF is needed, should the current > WG be closed and a new WG be started at a later time, or should > the current WG be rechartered? (Hint: The IETF has a strong > preference for short-duration WGs with very clearly defined > deliverables.) > > 5) Anything else? > > Happy discussion! Regards, Martin. > > P.S.: Please remember that expressions of opinions in the IETF are > taken as expressions by individuals, and that while we can > advise the IESG and the responsible Area Directors about > what the IETF should do next, it's not us (the WG) who > decides on charter changes. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 18:30:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsojQ-00017x-Qk; Tue, 20 Jun 2006 18:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsojP-00017f-Fw for ltru@ietf.org; Tue, 20 Jun 2006 18:29:59 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsojO-0000hu-7x for ltru@ietf.org; Tue, 20 Jun 2006 18:29:59 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5KMTRbw069539; Tue, 20 Jun 2006 15:29:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; b=0OFOleXrqOVAGRIwnx+qCm8uc3xiWPjeRXJ+I39Q6m0zn3qJZwAXtB6WAJ65j463 From: "Addison Phillips" To: "'Debbie Garside'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 15:29:27 -0700 Message-ID: <000201c694b8$fe372d00$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-reply-to: <200606202204.k5KM4EQj022874@mta5.iomartmail.com> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > There has been much discussion lately on IETF-languages with regard to > updates/additions and structure/format of the Registry. If this WG is > re-Chartered, I think it may be beneficial to include > discussion on tighter rules and regulations for updates/additions to the Registry with some > discussion on Registry format. To this end, it may also be > beneficial to look in detail at ISO 11179. It is possible that it would be beneficial to look at ISO 11179. What benefits do you think would accrue from doing this? I don't think that it would be beneficial to impose more rules on additions or updates to the registry. There is a perfectly good process in the existing document. The fact that people are not using this process (rather they are spending time shouting at one-another) does not mean that we should legislate an additional layer of requirements. Given my experience on ietf-languages and with LTRU, etc., my observation is: if one seeks quiet, thoughtful, dispassionate discourse, avoid language tags as a topic. I do think we should revisit encoding the registry in UTF-8. > > It could be suggested that further discussion in this regard > take place when > ISO FDIS 639-3 reaches full standard (approx. 6 months). It > may therefore, > with a mind to Martin's guidance, be more desirable to close > this WG in the > interim and to create a new WG and Charter at that time. It is not at all desirable, IMO, to re-create the group. Having a new "draft-registry" depend on ISO 639-3 being published is fine. What's important for our work here is knowing exactly what the structure of ISO 693-3 is in relation to 639-2 and 639-1 and how the various macro-languages, etc. will be handled. This will necessarily impact how extlang works. This information is increasingly unlikely to change. Note that (in my opinion), the only changes to 3066bis to incorporate 639-3 will be: 1. Referencing 639-3 as an additional source for language and extlang subtags (with attendent reference additions to stability rules, contact info, etc.) 2. Defining exactly the rules for inclusion of an extlang vs. a language subtag and the rules for Prefix in the extlang subtag. The only other change I foresee would be defining the encoding of the registry as UTF-8. It will also be necessary to prepare a rather large "bulk addition" to the registry. > > The key question here is how urgent is the need to facilitate > ISO 639-3? > It is "urgent" from the point of view that we want to incorporate ISO 639-3 as soon as it is reasonable to do so. Implementation rules for language tags are unaffected; all implementers will need is an updated copy of the registry (the syntax and so forth are already defined). Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 19:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspEA-0001sA-LV; Tue, 20 Jun 2006 19:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspE9-0001oy-50 for ltru@ietf.org; Tue, 20 Jun 2006 19:01:45 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FspE7-00078w-Ta for ltru@ietf.org; Tue, 20 Jun 2006 19:01:45 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FspE7-0000Tw-C0; Tue, 20 Jun 2006 19:01:43 -0400 Date: Tue, 20 Jun 2006 19:01:43 -0400 To: Debbie Garside Subject: Re: [Ltru] Charter Discussion Message-ID: <20060620230143.GA1076@ccil.org> References: <6.0.0.20.2.20060603091556.05543450@localhost> <200606202204.k5KM4EQj022874@mta5.iomartmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606202204.k5KM4EQj022874@mta5.iomartmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > It could be suggested that further discussion in this regard take place when > ISO FDIS 639-3 reaches full standard (approx. 6 months). It may therefore, > with a mind to Martin's guidance, be more desirable to close this WG in the > interim and to create a new WG and Charter at that time. It would effectively be the same WG with the same participants and the same basic purpose (applied to a new document), so I see no point to closing and reopening. > The key question here is how urgent is the need to facilitate ISO 639-3? I think that until 639-3 is in, we are living on borrowed time. In the 1766 and 3066 regimes, if anyone came along with a need for a language tag for a language that wasn't in ISO 639, we had a workaround: we could use the i- tag and create something like i-amis. 3066bis closes that loophole: anyone who needs a language tag now has to go to 639/MA and try to persuade them to add it, which may be difficult if the language doesn't meet the criteria (no less than fifty documents held by no more than five organizations). The fact that 3066bis isn't published is helping us, because few people are aware of the problem. But the most we can tell people now who want to tag text in a non-639 language is "Use this; it's not official but it will be some day." -- John Cowan cowan@ccil.org http://ccil.org/~cowan And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 19:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspI6-000584-Qd; Tue, 20 Jun 2006 19:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspI5-00057u-P8 for ltru@ietf.org; Tue, 20 Jun 2006 19:05:49 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FspI4-0007GC-B2 for ltru@ietf.org; Tue, 20 Jun 2006 19:05:49 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5KN5h2l009162; Wed, 21 Jun 2006 00:05:43 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5KN5cU6009088; Wed, 21 Jun 2006 00:05:42 +0100 Message-Id: <200606202305.k5KN5cU6009088@mta6.iomartmail.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 00:05:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <000201c694b8$fe372d00$9fcd15ac@ds.corp.yahoo.com> Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: > It is possible that it would be beneficial to look at ISO > 11179. What benefits do you think would accrue from doing this? I would have to do some work on this and I keep saying this, I haven't got time at the moment to take the discussion. Hence the reason why I said it MAY be beneficial. I will happily look at it in its entirety once the WG has been re-Chartered. Off the cuff, I would say that registration procedures would benefit greatly from some additional rules and structure. This would not only alleviate much of the discussion that has gone on in the past two weeks but make for a better quality and more consistent Registry. Whether this is done with or without ISO 11179 is neither here nor there. But it needs doing IMHO. > I don't think that it would be beneficial to impose more > rules on additions or updates to the registry. There is a > perfectly good process in the existing document. The fact > that people are not using this process (rather they are > spending time shouting at one-another) does not mean that we > should legislate an additional layer of requirements. It needs tightening! Then there will be no room for shouting! > Given > my experience on ietf-languages and with LTRU, etc., my > observation is: if one seeks quiet, thoughtful, dispassionate > discourse, avoid language tags as a topic. I have found the same, and not just within IETF-languages and LTRU! But then I never have been one for the quiet life! ;-) > I do think we should revisit encoding the registry in UTF-8. Absolutely agreed... And I have other suggestions and opinions on the format too ! But let us re-Charter (if that is what you want) BEFORE taking the actual discussions. > It is not at all desirable, IMO, to re-create the group. > Having a new "draft-registry" depend on ISO 639-3 being > published is fine. What's important for our work here is > knowing exactly what the structure of ISO > 693-3 is in relation to 639-2 and 639-1 and how the various > macro-languages, etc. will be handled. This will necessarily > impact how extlang works. This information is increasingly > unlikely to change. > > Note that (in my opinion), the only changes to 3066bis to > incorporate 639-3 will be: Now Addison, don't go creating a huge in-depth discussion when all I was doing was having a bit of quiet, thoughtful, dispassionate discourse re whether to dis-band or re-Charter. Re-charter and then get back into the affray! ;-) > > The key question here is how urgent is the need to facilitate ISO > > 639-3? > > > It is "urgent" from the point of view that we want to > incorporate ISO 639-3 as soon as it is reasonable to do so. > Implementation rules for language tags are unaffected; all > implementers will need is an updated copy of the registry > (the syntax and so forth are already defined). I'll take that as a vote for re-Charter then! Best regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 19:08:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspKw-0006CH-DA; Tue, 20 Jun 2006 19:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FspKv-0006BB-W2 for ltru@ietf.org; Tue, 20 Jun 2006 19:08:45 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FspKu-0007NI-I1 for ltru@ietf.org; Tue, 20 Jun 2006 19:08:45 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5KN8S4L028336; Wed, 21 Jun 2006 00:08:28 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5KN8MHE028115; Wed, 21 Jun 2006 00:08:28 +0100 Message-Id: <200606202308.k5KN8MHE028115@mta2.iomartmail.com> From: "Debbie Garside" To: "'John Cowan'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 00:08:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <20060620230143.GA1076@ccil.org> Thread-Index: AcaUvYBdPY4PaCu2RXCnorvR4IShmAAAKQUg X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So I'll take that as a +1 to re-Charter with ISO 639-3 on the menu prior to publication. Debbie > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 21 June 2006 00:02 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] Charter Discussion > > Debbie Garside scripsit: > > > It could be suggested that further discussion in this > regard take place when > > ISO FDIS 639-3 reaches full standard (approx. 6 months). > It may therefore, > > with a mind to Martin's guidance, be more desirable to > close this WG > > in the interim and to create a new WG and Charter at that time. > > It would effectively be the same WG with the same > participants and the same basic purpose (applied to a new > document), so I see no point to closing and reopening. > > > The key question here is how urgent is the need to > facilitate ISO 639-3? > > I think that until 639-3 is in, we are living on borrowed > time. In the > 1766 and 3066 regimes, if anyone came along with a need for a > language tag for a language that wasn't in ISO 639, we had a > workaround: we could use the i- tag and create something like > i-amis. 3066bis closes that loophole: anyone who needs a > language tag now has to go to 639/MA and try to persuade them > to add it, which may be difficult if the language doesn't > meet the criteria (no less than fifty documents held by no > more than five organizations). > > The fact that 3066bis isn't published is helping us, because > few people are aware of the problem. But the most we can > tell people now who want to tag text in a non-639 language is > "Use this; it's not official but it will be some day." > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan And now > here I was, in a country where a right to say how the country > should be governed was restricted to six persons in each > thousand of its population. > For the nine hundred and ninety-four to express > dissatisfaction with the regnant system and propose to change > it, would have made the whole six shudder as one man, it > would have been so disloyal, so dishonorable, such putrid > black treason. --Mark Twain's Connecticut Yankee > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 20:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqGR-00068Z-Ol; Tue, 20 Jun 2006 20:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqGQ-00068U-VG for ltru@ietf.org; Tue, 20 Jun 2006 20:08:10 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsqGP-0002PQ-Lk for ltru@ietf.org; Tue, 20 Jun 2006 20:08:10 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5L07DBi087290; Tue, 20 Jun 2006 17:07:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; b=ZZcwPK2/8ol5q+XHZxUIsPrMJ+27832vW8TO6ITbPO3KnQd7i6MrxAMZVsrHacpH From: "Addison Phillips" To: "'Debbie Garside'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 17:07:12 -0700 Message-ID: <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-reply-to: <200606202305.k5KN5cU6009088@mta6.iomartmail.com> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > It is possible that it would be beneficial to look at ISO > > 11179. What benefits do you think would accrue from doing this? > > I would have to do some work on this and I keep saying this, > I haven't got > time at the moment to take the discussion. Hence the reason > why I said it MAY be beneficial. I am sceptical of taking up a standard merely on the basis that it exists. If someone explains (coherently) what the benefits are, then I'm happy to consider them. But the nature of the langtags registry is such that we don't need a lot of additional stuff of this nature. There are well considered rules for which records go into the registry and how, with most of the decisions taken by external standards bodies. > I will happily look at it in its entirety > once the WG has > been re-Chartered. Off the cuff, I would say that > registration procedures > would benefit greatly from some additional rules and > structure. If there are problems with the registration procedures (I submit: there are not any that have been identified to date), then we should identify them and work to resolve them in any new document this WG or its successor might create. So far we haven't experienced any problems with the registration procedures themselves. Some people have taken exception to different registration proposals---objecting to proposed content of some non-stabilized, informative (i.e. in the non-normative sense) fields. In particular, the desire to include/not include ASCII-only descriptions and typesetter's quotes. But that discussion has nothing to do with the registration process. In that process, people are supporting or not supporting the inclusion of ’ vs ' in one of the description fields. I perceive that a consensus is emerging about what to do. Once that consensus hardens, I doubt we will revisit it in the future. It should be noted that 3066bis anticipated the need for more than one description, even. > This would > not only alleviate much of the discussion that has gone on in > the past two > weeks but make for a better quality and more consistent > Registry. Whether > this is done with or without ISO 11179 is neither here nor > there. But it > needs doing IMHO. No. The process would benefit from better discussion management and better list discipline. The recent discussions on the ietf-languages list have nothing to do with what RFC 3066bis says or doesn't say. We might not have had the discussions about the format for escape sequences if the registry were using UTF-8 (but the discussion about curly vs. non-curly quotes would still probably have taken place). None of these discussions, please note, means a thing in regard to what the rules of the road are. What exactly is the problem that would be solved by changing or reconsidering registration rules? Referencing standards is nice, but there should be a reason to do so. Given that the registry is (more or less) a compendium of other standards, it makes no sense to me to impose all sorts of additional cruft onto it unless absolutely necessary. > > I don't think that it would be beneficial to impose more > > rules on additions or updates to the registry. There is a > > perfectly good process in the existing document. The fact > > that people are not using this process (rather they are > > spending time shouting at one-another) does not mean that we > > should legislate an additional layer of requirements. > > It needs tightening! Then there will be no room for shouting! No, that's naive. Given an open email list there is always room for shouting. Shouting isn't even necessarily bad (and I must say that Harald does a good job of cutting off abusive behavior). Tighter rules for actual registrations would not prevent people from indulging in wild off-topic rambles (for example: questioning the rules). > > I do think we should revisit encoding the registry in UTF-8. > > Absolutely agreed... And I have other suggestions and > opinions on the format > too ! But let us re-Charter (if that is what you want) BEFORE > taking the actual discussions. I agree that we should not engage in the discussion here. But I don't think a re-charter is necessary unless the IESG does. > Now Addison, don't go creating a huge in-depth discussion > when all I was > doing was having a bit of quiet, thoughtful, dispassionate > discourse re > whether to dis-band or re-Charter. Re-charter and then get > back into the > affray! ;-) It is a question of scope. If the scope is small (I was attempting to demonstrate both small scope and the need for restraint in an edit), then we don't need a massive recharter, etc. We merely need an extension of our current mandate. > I'll take that as a vote for re-Charter then! That is a vote for doing 3066ter in this group, soon-ish, with quite limited scope for change---almost a RFC3066bis "second edition" or errata, rechartering if necessary. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: mardi 20 juin 2006 16:06 > To: 'Addison Phillips'; 'Martin Duerst'; 'LTRU Working Group' > Subject: RE: [Ltru] Charter Discussion > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 20:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsqxj-0007D5-8Z; Tue, 20 Jun 2006 20:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsqxi-0007D0-Fi for ltru@ietf.org; Tue, 20 Jun 2006 20:52:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsqxi-0004Zh-4j for ltru@ietf.org; Tue, 20 Jun 2006 20:52:54 -0400 Received: by wr-out-0506.google.com with SMTP id 71so42339wri for ; Tue, 20 Jun 2006 17:52:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LkFPOwkqe+FvWDij+vwHOWHsx8iI5G69QYVVOsJYqNacmgHgxjj0wMZ29OScqCJM1RR4Pdyt6jnLXaBVuur1SGg+1l60Y5jfMf2lZJZuW1KmQ2ai/++dYbtG46IlKreQuN2sSg1zd1MoBDAknbbGoSXRqye7TyWktuao9huCBQE= Received: by 10.64.193.13 with SMTP id q13mr79358qbf; Tue, 20 Jun 2006 17:52:53 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Tue, 20 Jun 2006 17:52:53 -0700 (PDT) Message-ID: <30b660a20606201752r724d33e8sc87564be16cf02f2@mail.gmail.com> Date: Tue, 20 Jun 2006 17:52:53 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Charter Discussion In-Reply-To: <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606202305.k5KN5cU6009088@mta6.iomartmail.com> <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> X-Google-Sender-Auth: 59cbc81fa9373684 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 On 6/20/06, Addison Phillips wrote: > > > It is possible that it would be beneficial to look at ISO > > > 11179. What benefits do you think would accrue from doing this? > > > > I would have to do some work on this and I keep saying this, > > I haven't got > > time at the moment to take the discussion. Hence the reason > > why I said it MAY be beneficial. > > I am sceptical of taking up a standard merely on the basis that it exists. > If someone explains (coherently) what the benefits are, then I'm happy to > consider them. But the nature of the langtags registry is such that we don't > need a lot of additional stuff of this nature. There are well considered > rules for which records go into the registry and how, with most of the > decisions taken by external standards bodies. > > > I will happily look at it in its entirety > > once the WG has > > been re-Chartered. Off the cuff, I would say that > > registration procedures > > would benefit greatly from some additional rules and > > structure. > > If there are problems with the registration procedures (I submit: there are > not any that have been identified to date), then we should identify them and > work to resolve them in any new document this WG or its successor might > create. So far we haven't experienced any problems with the registration > procedures themselves. Some people have taken exception to different > registration proposals---objecting to proposed content of some > non-stabilized, informative (i.e. in the non-normative sense) fields. In > particular, the desire to include/not include ASCII-only descriptions and > typesetter's quotes. But that discussion has nothing to do with the > registration process. In that process, people are supporting or not > supporting the inclusion of ’ vs ' in one of the description > fields. I perceive that a consensus is emerging about what to do. Once that > consensus hardens, I doubt we will revisit it in the future. It should be > noted that 3066bis anticipated the need for more than one description, even. > > > This would > > not only alleviate much of the discussion that has gone on in > > the past two > > weeks but make for a better quality and more consistent > > Registry. Whether > > this is done with or without ISO 11179 is neither here nor > > there. But it > > needs doing IMHO. > > No. The process would benefit from better discussion management and better > list discipline. The recent discussions on the ietf-languages list have > nothing to do with what RFC 3066bis says or doesn't say. We might not have > had the discussions about the format for escape sequences if the registry > were using UTF-8 (but the discussion about curly vs. non-curly quotes would > still probably have taken place). None of these discussions, please note, > means a thing in regard to what the rules of the road are. What exactly is > the problem that would be solved by changing or reconsidering registration > rules? > > Referencing standards is nice, but there should be a reason to do so. Given > that the registry is (more or less) a compendium of other standards, it > makes no sense to me to impose all sorts of additional cruft onto it unless > absolutely necessary. > > > > I don't think that it would be beneficial to impose more > > > rules on additions or updates to the registry. There is a > > > perfectly good process in the existing document. The fact > > > that people are not using this process (rather they are > > > spending time shouting at one-another) does not mean that we > > > should legislate an additional layer of requirements. > > > > It needs tightening! Then there will be no room for shouting! > > No, that's naive. Given an open email list there is always room for > shouting. Shouting isn't even necessarily bad (and I must say that Harald > does a good job of cutting off abusive behavior). Tighter rules for actual > registrations would not prevent people from indulging in wild off-topic > rambles (for example: questioning the rules). > > > > I do think we should revisit encoding the registry in UTF-8. > > > > Absolutely agreed... And I have other suggestions and > > opinions on the format > > too ! But let us re-Charter (if that is what you want) BEFORE > > taking the actual discussions. > > I agree that we should not engage in the discussion here. But I don't think > a re-charter is necessary unless the IESG does. > > > Now Addison, don't go creating a huge in-depth discussion > > when all I was > > doing was having a bit of quiet, thoughtful, dispassionate > > discourse re > > whether to dis-band or re-Charter. Re-charter and then get > > back into the > > affray! ;-) > > It is a question of scope. If the scope is small (I was attempting to > demonstrate both small scope and the need for restraint in an edit), then we > don't need a massive recharter, etc. We merely need an extension of our > current mandate. > > > I'll take that as a vote for re-Charter then! > > That is a vote for doing 3066ter in this group, soon-ish, with quite limited > scope for change---almost a RFC3066bis "second edition" or errata, > rechartering if necessary. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: mardi 20 juin 2006 16:06 > > To: 'Addison Phillips'; 'Martin Duerst'; 'LTRU Working Group' > > Subject: RE: [Ltru] Charter Discussion > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 21:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsryH-0006Yg-C8; Tue, 20 Jun 2006 21:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsryG-0006Yb-0T for ltru@ietf.org; Tue, 20 Jun 2006 21:57:32 -0400 Received: from mta1.iomartmail.com ([62.128.193.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsryF-0000Pv-DD for ltru@ietf.org; Tue, 20 Jun 2006 21:57:31 -0400 Received: from mta1.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5L1vTlJ013292; Wed, 21 Jun 2006 02:57:29 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5L1vOtU013216; Wed, 21 Jun 2006 02:57:28 +0100 Message-Id: <200606210157.k5L1vOtU013216@mta1.iomartmail.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 02:57:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeagAAV49XA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: > Referencing standards is nice, but there should be a reason > to do so. Given that the registry is (more or less) a > compendium of other standards, it makes no sense to me to > impose all sorts of additional cruft onto it unless > absolutely necessary. You have adopted ISO 639 You have adopted ISO 15924 You have adopted ISO 3166 You have created a meta-data registry I would say that it would be prudent to CONSIDER the ISO standard that covers meta-data registries - ISO 11179 IF there are good enough reasons for it being adopted, I believe it will protect you, the IETF, the IESG and all the excellent work that you have done. Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 21 June 2006 01:07 > To: 'Debbie Garside'; 'Martin Duerst'; 'LTRU Working Group' > Subject: RE: [Ltru] Charter Discussion > > > > It is possible that it would be beneficial to look at ISO 11179. > > > What benefits do you think would accrue from doing this? > > > > I would have to do some work on this and I keep saying > this, I haven't > > got time at the moment to take the discussion. Hence the > reason why I > > said it MAY be beneficial. > > I am sceptical of taking up a standard merely on the basis > that it exists. > If someone explains (coherently) what the benefits are, then > I'm happy to consider them. But the nature of the langtags > registry is such that we don't need a lot of additional stuff > of this nature. There are well considered rules for which > records go into the registry and how, with most of the > decisions taken by external standards bodies. > > > I will happily look at it in its entirety once the WG has been > > re-Chartered. Off the cuff, I would say that registration > procedures > > would benefit greatly from some additional rules and structure. > > If there are problems with the registration procedures (I > submit: there are not any that have been identified to date), > then we should identify them and work to resolve them in any > new document this WG or its successor might create. So far we > haven't experienced any problems with the registration > procedures themselves. Some people have taken exception to > different registration proposals---objecting to proposed > content of some non-stabilized, informative (i.e. in the > non-normative sense) fields. In particular, the desire to > include/not include ASCII-only descriptions and typesetter's > quotes. But that discussion has nothing to do with the > registration process. In that process, people are supporting > or not supporting the inclusion of ’ vs ' in one > of the description fields. I perceive that a consensus is > emerging about what to do. Once that consensus hardens, I > doubt we will revisit it in the future. It should be noted > that 3066bis anticipated the need for more than one description, even. > > > This would > > not only alleviate much of the discussion that has gone on > in the past > > two weeks but make for a better quality and more consistent > Registry. > > Whether this is done with or without ISO 11179 is neither here nor > > there. But it needs doing IMHO. > > No. The process would benefit from better discussion > management and better list discipline. The recent discussions > on the ietf-languages list have nothing to do with what RFC > 3066bis says or doesn't say. We might not have had the > discussions about the format for escape sequences if the > registry were using UTF-8 (but the discussion about curly vs. > non-curly quotes would still probably have taken place). None > of these discussions, please note, means a thing in regard to > what the rules of the road are. What exactly is the problem > that would be solved by changing or reconsidering registration rules? > > Referencing standards is nice, but there should be a reason > to do so. Given that the registry is (more or less) a > compendium of other standards, it makes no sense to me to > impose all sorts of additional cruft onto it unless > absolutely necessary. > > > > I don't think that it would be beneficial to impose more rules on > > > additions or updates to the registry. There is a perfectly good > > > process in the existing document. The fact that people > are not using > > > this process (rather they are spending time shouting at > one-another) > > > does not mean that we should legislate an additional layer of > > > requirements. > > > > It needs tightening! Then there will be no room for shouting! > > No, that's naive. Given an open email list there is always > room for shouting. Shouting isn't even necessarily bad (and I > must say that Harald does a good job of cutting off abusive > behavior). Tighter rules for actual registrations would not > prevent people from indulging in wild off-topic rambles (for > example: questioning the rules). > > > > I do think we should revisit encoding the registry in UTF-8. > > > > Absolutely agreed... And I have other suggestions and > opinions on the > > format too ! But let us re-Charter (if that is what you > want) BEFORE > > taking the actual discussions. > > I agree that we should not engage in the discussion here. But > I don't think a re-charter is necessary unless the IESG does. > > > Now Addison, don't go creating a huge in-depth discussion > when all I > > was doing was having a bit of quiet, thoughtful, dispassionate > > discourse re whether to dis-band or re-Charter. Re-charter > and then > > get back into the affray! ;-) > > It is a question of scope. If the scope is small (I was > attempting to demonstrate both small scope and the need for > restraint in an edit), then we don't need a massive > recharter, etc. We merely need an extension of our current mandate. > > > I'll take that as a vote for re-Charter then! > > That is a vote for doing 3066ter in this group, soon-ish, > with quite limited scope for change---almost a RFC3066bis > "second edition" or errata, rechartering if necessary. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: mardi 20 juin 2006 16:06 > > To: 'Addison Phillips'; 'Martin Duerst'; 'LTRU Working Group' > > Subject: RE: [Ltru] Charter Discussion > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 22:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FssQR-0002hf-4s; Tue, 20 Jun 2006 22:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FssQP-0002eM-Se for ltru@ietf.org; Tue, 20 Jun 2006 22:26:37 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FssQO-0004mw-Lv for ltru@ietf.org; Tue, 20 Jun 2006 22:26:37 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c15.corp.yahoo.com [10.72.76.15]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5L2QC0u059691; Tue, 20 Jun 2006 19:26:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=hXdaz1lUB37YwoN2EqetHb9bDXpfTtF8DaWfBX35zPq8cnD/XXsGQeOb+iVSr3ES From: "Addison Phillips" To: "'Debbie Garside'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 19:26:12 -0700 Message-ID: <001201c694da$10b31130$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeagAAV49XAAALATUA== In-Reply-To: <200606210157.k5L1vOtU013216@mta1.iomartmail.com> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > I would say that it would be prudent to CONSIDER the ISO standard that > covers meta-data registries - ISO 11179 I believe I said that it ought to be considered on its merits. But given your own description of same (six volumes, over 3 MB of material), my first reaction is: why? What problems does it address? Who is the audience for it? What utility is derived from it? What I object to is the *assumption* that we have to do something with ISO 11179. I'm more than willing to consider it, if there is some utility to be gained. But to declare a need for such standardization without any consideration for what the thing is? I don't think that prudent at all. > > IF there are good enough reasons for it being adopted, I > believe it will > protect you, the IETF, the IESG and all the excellent work > that you have done. Protect whom from what, exactly? If there are good reasons for adopting it, I'm sure this WG will consider doing so. That none have been presented to date does not mean that there are no arguments in favor. The least impressive argument in favor of any standard is its mere existance. Do the research and present a case for adopting it and I'll be the first to support it (if I think it warrants support). But not out of hand. I don't even know what would be required to support it and I begin to suspect that it would require significant work to do so... with possibly no reward? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 22:59:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fssvu-0000a2-CA; Tue, 20 Jun 2006 22:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fssvt-0000Zi-DC for ltru@ietf.org; Tue, 20 Jun 2006 22:59:09 -0400 Received: from mta1.iomartmail.com ([62.128.193.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fssvq-0007p4-UO for ltru@ietf.org; Tue, 20 Jun 2006 22:59:09 -0400 Received: from mta1.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5L2x3x6015470; Wed, 21 Jun 2006 03:59:04 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5L2ws3m015282; Wed, 21 Jun 2006 03:59:03 +0100 Message-Id: <200606210259.k5L2ws3m015282@mta1.iomartmail.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 03:58:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <001201c694da$10b31130$650a0a0a@ds.corp.yahoo.com> Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeagAAV49XAAALATUAABMDFA X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison I would draw your attention to my original email where I stated: "it may also be beneficial to look in detail at ISO 11179." That's all I said. Just stick it on the menu for re-Chartering. That is what this discussion (my discussion) is about. > Protect whom from what, exactly? I just threw that in for good measure and as a much needed distraction! In English law, as with any standard, if you have implemented its provisions in full this will provide you with what is called the 'due diligence' defence in any court action. If negligence or recklessness is required for you to be liable, conformity to a national or international standard is a complete defence. I don't expect you to need this but it is never a bad thing to be in conformity with an International Standard. There is no argument against it. Appeals etc. in relation to the structure and content of the Registry to the IESG are negated purely and simply by being in conformity with an International Standard. Dead easy really! I'm off now. If you need me you will find me in the flower arranging forum for people with frontal-lobe lobotomies...having a bit of QUIET, THOUGHTFUL, DISPASSIONATE DISCOURSE about anything but Language bloody tagging and ISO bloody 11179! GOODNIGHT! Debbie :-) > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 21 June 2006 03:26 > To: 'Debbie Garside'; 'Martin Duerst'; 'LTRU Working Group' > Subject: RE: [Ltru] Charter Discussion > > > > > I would say that it would be prudent to CONSIDER the ISO > standard that > > covers meta-data registries - ISO 11179 > > I believe I said that it ought to be considered on its > merits. But given your own description of same (six volumes, > over 3 MB of material), my first reaction is: why? What > problems does it address? Who is the audience for it? > What utility is derived from it? > > What I object to is the *assumption* that we have to do > something with ISO 11179. I'm more than willing to consider > it, if there is some utility to be gained. But to declare a > need for such standardization without any consideration for > what the thing is? I don't think that prudent at all. > > > > > IF there are good enough reasons for it being adopted, I believe it > > will protect you, the IETF, the IESG and all the excellent > work that > > you have done. > > Protect whom from what, exactly? > > If there are good reasons for adopting it, I'm sure this WG > will consider doing so. That none have been presented to date > does not mean that there are no arguments in favor. The least > impressive argument in favor of any standard is its mere > existance. Do the research and present a case for adopting it > and I'll be the first to support it (if I think it warrants > support). But not out of hand. I don't even know what would > be required to support it and I begin to suspect that it > would require significant work to do so... with possibly no reward? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 20 23:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstoE-0004UO-9A; Tue, 20 Jun 2006 23:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstoC-0004UI-S0 for ltru@ietf.org; Tue, 20 Jun 2006 23:55:17 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsto8-00033B-Jh for ltru@ietf.org; Tue, 20 Jun 2006 23:55:16 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c15.corp.yahoo.com [10.72.76.15]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5L3sxo8073118; Tue, 20 Jun 2006 20:54:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=G2PN83nR91bmeQNXtcL+hdeQP1l9aMhJ8OFNoiXqrzj37RCcY4IUg002ca9ICWJf From: "Addison Phillips" To: "'Debbie Garside'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 20:54:59 -0700 Message-ID: <001601c694e6$788f6450$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeagAAV49XAAALATUAABMDFAAAHKzwA= In-Reply-To: <200606210259.k5L2ws3m015282@mta1.iomartmail.com> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie, I apologize if I have misread your intentions. I will persist, if I may, with one point: if you wish to suggest that this WG consider something for a new charter, it is incumbent upon you to explain what it is and why the WG should consider it. I thought (was I wrong?) that "sticking it on the menu" meant putting it in a new charter. As I indicated, as an abstract notion, I'm happy to consider ISO 11179 along with other things the WG might do in RFC 3066ter. But, unless there is some reason to, I oppose actually mentioning it in the charter as a requirement (just as I would oppose mentioning any other random ideas--like using UTF-8 for the registry file). I misread your messages as a call for including it in the list of work to do. I'm opposed to that. I'm not opposed to considering if ISO 11179 might be appropriate within the context of 3066ter, but I think the charter scope and the changes to 3066bis should be as minor as possible (but no more so, to paraphrase Einstein). Let me know the address of the flower arranging forum. It would be a benison after a long day's language tagging. Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: mardi 20 juin 2006 19:59 > To: 'Addison Phillips'; 'Martin Duerst'; 'LTRU Working Group' > Subject: RE: [Ltru] Charter Discussion > > Addison > > I would draw your attention to my original email where I stated: > > "it may also be beneficial to look in detail at ISO 11179." > > That's all I said. Just stick it on the menu for > re-Chartering. That is > what this discussion (my discussion) is about. > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 01:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsuu7-0005dn-Vv; Wed, 21 Jun 2006 01:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsuu7-0005di-Hg for ltru@ietf.org; Wed, 21 Jun 2006 01:05:27 -0400 Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsuu6-00035Y-9S for ltru@ietf.org; Wed, 21 Jun 2006 01:05:27 -0400 Received: from h-68-165-4-99.snvacaid.dynamic.covad.net ([68.165.4.99] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fsuu3-00060h-00 for ltru@ietf.org; Wed, 21 Jun 2006 01:05:23 -0400 Message-ID: <001e01c694f0$560a1100$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001601c694e6$788f6450$650a0a0a@ds.corp.yahoo.com> Subject: Re: [Ltru] Charter Discussion Date: Tue, 20 Jun 2006 22:05:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ... > I will persist, if I may, with one point: if you wish to suggest that this > WG consider something for a new charter, it is incumbent upon you to explain > what it is and why the WG should consider it. I thought (was I wrong?) that > "sticking it on the menu" meant putting it in a new charter. As I indicated, > as an abstract notion, I'm happy to consider ISO 11179 along with other > things the WG might do in RFC 3066ter. But, unless there is some reason to, > I oppose actually mentioning it in the charter as a requirement (just as I > would oppose mentioning any other random ideas--like using UTF-8 for the > registry file). I misread your messages as a call for including it in the > list of work to do. I'm opposed to that. I'm not opposed to considering if > ISO 11179 might be appropriate within the context of 3066ter, but I think > the charter scope and the changes to 3066bis should be as minor as possible > (but no more so, to paraphrase Einstein). ... As an individual contributor who has some experience with charters and specification update efforts... I think there are three obvious options for a charter update with respect to the question of ISO 11179: a) say nothing about using ISO 11179 in producing 3066ter b) require use of ISO 11179 in producing 3066ter c) require WG to consider using ISO 11179, with the assumption that if the cost/benefit ration proves favorable, we'd use it Having some experience in how updates to complex specifications happen in the IETF... - choosing (a) practically guarantees that ISO 11179 would not be used. The default position in an update effort is normally to make changes only when absolutely necessary, and to keep the changes as small as practical. - I think choosing (b) would be premature now, and it doesn't look like arguments clinching the case for ISO 11179 are coming anytime soon. I think this would be a "non-starter." - choosing (c) means we'd have to (at least) get a design team to dig into ISO 11179 and make a recommendation to the WG. This is obviously more work than (a). What I think is needed at this stage is for folks who've looked into ISO 11179 at least a little to think whether it shows enough promise of benefit to make it worthwhile to commit to the effort the investigation option (c) would entail. If they're not convinced, then by default we'll end up with (a), which, as a practical matter, would make it much harder to steer the effort into using ISO 11179. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 10:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft41R-0002T8-UD; Wed, 21 Jun 2006 10:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft41Q-0002Sx-Sj for ltru@ietf.org; Wed, 21 Jun 2006 10:49:36 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft41P-0003m5-Jp for ltru@ietf.org; Wed, 21 Jun 2006 10:49:36 -0400 Received: by wr-out-0506.google.com with SMTP id 71so163379wri for ; Wed, 21 Jun 2006 07:49:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g2IAK5dpczdFtb5ZMqAwwMPRtL47x9v6DPEEUZBS/A7o2D+iG3mZi+Z2UWGmI+ZOf8BxJVEQ6cnOVAKB5FvazxjmJzlzQkflHFmTWvY/eEm5S6u8SL3nm7t+vw11gaqnwqEnNSWuypSs2N2Jh1k4la9A5q/HUlhqT6QMGvuXzWQ= Received: by 10.65.61.4 with SMTP id o4mr1073323qbk; Wed, 21 Jun 2006 07:49:35 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Wed, 21 Jun 2006 07:49:35 -0700 (PDT) Message-ID: <30b660a20606210749y2d6836c2gd9df6eab5428e7c0@mail.gmail.com> Date: Wed, 21 Jun 2006 07:49:35 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Charter Discussion In-Reply-To: <001e01c694f0$560a1100$6501a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001601c694e6$788f6450$650a0a0a@ds.corp.yahoo.com> <001e01c694f0$560a1100$6501a8c0@oemcomputer> X-Google-Sender-Auth: 554e696d402dc8e0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >What I think is needed at this stage is for folks who've looked into ISO 11179 at least a little to think whether it shows enough promise of benefit to make it worthwhile to commit to the effort the investigation option (c) would entail. +1 (We'd really have to see some examples of what the purported benefits would be.) On 6/20/06, Randy Presuhn wrote: > ... > > I will persist, if I may, with one point: if you wish to suggest that this > > WG consider something for a new charter, it is incumbent upon you to explain > > what it is and why the WG should consider it. I thought (was I wrong?) that > > "sticking it on the menu" meant putting it in a new charter. As I indicated, > > as an abstract notion, I'm happy to consider ISO 11179 along with other > > things the WG might do in RFC 3066ter. But, unless there is some reason to, > > I oppose actually mentioning it in the charter as a requirement (just as I > > would oppose mentioning any other random ideas--like using UTF-8 for the > > registry file). I misread your messages as a call for including it in the > > list of work to do. I'm opposed to that. I'm not opposed to considering if > > ISO 11179 might be appropriate within the context of 3066ter, but I think > > the charter scope and the changes to 3066bis should be as minor as possible > > (but no more so, to paraphrase Einstein). > ... > > As an individual contributor who has some experience with charters > and specification update efforts... > > I think there are three obvious options for a charter update with > respect to the question of ISO 11179: > a) say nothing about using ISO 11179 in producing 3066ter > b) require use of ISO 11179 in producing 3066ter > c) require WG to consider using ISO 11179, with the assumption > that if the cost/benefit ration proves favorable, we'd use it > > Having some experience in how updates to complex specifications > happen in the IETF... > - choosing (a) practically guarantees that ISO 11179 would not > be used. The default position in an update effort is normally > to make changes only when absolutely necessary, and to keep > the changes as small as practical. > - I think choosing (b) would be premature now, and it doesn't look > like arguments clinching the case for ISO 11179 are coming anytime > soon. I think this would be a "non-starter." > - choosing (c) means we'd have to (at least) get a design team to > dig into ISO 11179 and make a recommendation to the WG. This > is obviously more work than (a). > > What I think is needed at this stage is for folks who've looked into > ISO 11179 at least a little to think whether it shows enough promise > of benefit to make it worthwhile to commit to the effort the investigation > option (c) would entail. If they're not convinced, then by default we'll > end up with (a), which, as a practical matter, would make it much harder > to steer the effort into using ISO 11179. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 10:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft469-0007V6-7d; Wed, 21 Jun 2006 10:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft467-0007V1-Td for ltru@ietf.org; Wed, 21 Jun 2006 10:54:27 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft466-0005gp-IY for ltru@ietf.org; Wed, 21 Jun 2006 10:54:27 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 21 Jun 2006 14:54:16 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J1700GJBTEEAL@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 21 Jun 2006 14:54:14 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.23]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 21 Jun 2006 15:54:14 +0100 Date: Wed, 21 Jun 2006 15:54:01 +0100 From: Misha Wolf Subject: RE: [Ltru] Charter Discussion To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Charter Discussion thread-index: AcaVQe/0JEmaQr3+QhG51YUU1yi/agAAFr7A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jun 2006 14:54:14.0782 (UTC) FILETIME=[904A81E0:01C69542] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 (applies to Mark's text in brackets too) -----Original Message----- From: Mark Davis [mailto:mark.davis@icu-project.org]=20 Sent: 21 June 2006 15:50 To: Randy Presuhn Cc: LTRU Working Group Subject: Re: [Ltru] Charter Discussion >What I think is needed at this stage is for folks who've looked into ISO 11179 at least a little to think whether it shows enough promise of benefit to make it worthwhile to commit to the effort the investigation option (c) would entail. +1 (We'd really have to see some examples of what the purported benefits would be.) To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Gp-0004pv-Ok; Wed, 21 Jun 2006 11:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Go-0004pq-Bp for ltru@ietf.org; Wed, 21 Jun 2006 11:05:30 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Gn-0006os-3i for ltru@ietf.org; Wed, 21 Jun 2006 11:05:30 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060621150524.BWAZ17849.mta11.adelphia.net@DGBP7M81> for ; Wed, 21 Jun 2006 11:05:24 -0400 Message-ID: <00b001c69544$1f1eba20$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 08:05:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Having some experience in how updates to complex specifications > happen in the IETF... > - choosing (a) practically guarantees that ISO 11179 would not > be used. The default position in an update effort is normally > to make changes only when absolutely necessary, and to keep > the changes as small as practical. > - I think choosing (b) would be premature now, and it doesn't look > like arguments clinching the case for ISO 11179 are coming anytime > soon. I think this would be a "non-starter." > - choosing (c) means we'd have to (at least) get a design team to > dig into ISO 11179 and make a recommendation to the WG. This > is obviously more work than (a). > > What I think is needed at this stage is for folks who've looked into > ISO 11179 at least a little to think whether it shows enough promise > of benefit to make it worthwhile to commit to the effort the > investigation > option (c) would entail. If they're not convinced, then by default > we'll > end up with (a), which, as a practical matter, would make it much > harder > to steer the effort into using ISO 11179. I agree with everything Randy said above, and would reiterate that all Debbie said was that we should *consider* applying ISO 11179. We cannot know whether it is appropriate to our needs until we consider it. I suggest that we take Randy's option (c) > c) require WG to consider using ISO 11179, with the assumption > that if the cost/benefit ration proves favorable, we'd use it and suggest that Debbie lead the way in investigating the costs and benefits. I will try to help. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:24:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Z0-0001J4-7z; Wed, 21 Jun 2006 11:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Yz-0001It-9k for ltru@ietf.org; Wed, 21 Jun 2006 11:24:17 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Yx-0008Ju-Ue for ltru@ietf.org; Wed, 21 Jun 2006 11:24:17 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 21 Jun 2006 15:24:11 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J1700BE6USBU7@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 21 Jun 2006 15:24:11 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.23]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 21 Jun 2006 16:24:11 +0100 Date: Wed, 21 Jun 2006 16:23:58 +0100 From: Misha Wolf Subject: RE: [Ltru] Charter Discussion To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Charter Discussion thread-index: AcaVRCg8idWsG05nS8K5pSTorNIa2gAAWogQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jun 2006 15:24:11.0363 (UTC) FILETIME=[BF230330:01C69546] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org And I take the slightly different view, that anyone who wants=20 the WG to consider using ISO 11179 should come up with one or=20 more reasons why we should do so and should persuade the WG=20 that these reasons are good ones. Misha -----Original Message----- From: Doug Ewell [mailto:dewell@adelphia.net]=20 Sent: 21 June 2006 16:05 To: LTRU Working Group Subject: Re: [Ltru] Charter Discussion [...] I suggest that we take Randy's option (c) > c) require WG to consider using ISO 11179, with the assumption > that if the cost/benefit ration proves favorable, we'd use it [...] To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:26:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4bA-0001oM-9B; Wed, 21 Jun 2006 11:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4b9-0001oH-1A for ltru@ietf.org; Wed, 21 Jun 2006 11:26:31 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4b7-0008Np-P2 for ltru@ietf.org; Wed, 21 Jun 2006 11:26:31 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c15.corp.yahoo.com [10.72.76.15]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5LFQ163078569; Wed, 21 Jun 2006 08:26:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=jOw8brbNHZYTckvWGzu0knpdUs3COZeXLposLGJOteB+W4m/oZgv9zCp4tOIE+36 From: "Addison Phillips" To: "'Misha Wolf'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 08:26:01 -0700 Message-ID: <003901c69547$0165e730$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVRCg8idWsG05nS8K5pSTorNIa2gAAWogQAABa7qA= In-Reply-To: X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Misha Wolf [mailto:Misha.Wolf@reuters.com] > Sent: mercredi 21 juin 2006 08:24 > To: LTRU Working Group > Subject: RE: [Ltru] Charter Discussion > > And I take the slightly different view, that anyone who wants > the WG to consider using ISO 11179 should come up with one or > more reasons why we should do so and should persuade the WG > that these reasons are good ones. > > Misha > > > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 21 June 2006 16:05 > To: LTRU Working Group > Subject: Re: [Ltru] Charter Discussion > > [...] > > I suggest that we take Randy's option (c) > > > c) require WG to consider using ISO 11179, with the assumption > > that if the cost/benefit ration proves favorable, we'd use it > > [...] > > > > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the > individual sender, except where the sender specifically > states them to be the views of Reuters Ltd. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4jk-0008CK-AX; Wed, 21 Jun 2006 11:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4jj-0008CF-No for ltru@ietf.org; Wed, 21 Jun 2006 11:35:23 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4ji-0000H1-H4 for ltru@ietf.org; Wed, 21 Jun 2006 11:35:23 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Ft4ji-0005Gn-42; Wed, 21 Jun 2006 11:35:22 -0400 Date: Wed, 21 Jun 2006 11:35:22 -0400 To: Misha Wolf Subject: Re: [Ltru] Charter Discussion Message-ID: <20060621153522.GJ22961@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > And I take the slightly different view, that anyone who wants > the WG to consider using ISO 11179 should come up with one or > more reasons why we should do so and should persuade the WG > that these reasons are good ones. Those would rightly be reasons for *using* 11179, not merely for *considering* its use. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If a soldier is asked why he kills people who have done him no harm, or a terrorist why he kills innocent people with his bombs, they can always reply that war has been declared, and there are no innocent people in an enemy country in wartime. The answer is psychotic, but it is the answer that humanity has given to every act of aggression in history. --Northrop Frye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:41:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4pR-0004oN-Qk; Wed, 21 Jun 2006 11:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4pQ-0004oH-Mm for ltru@ietf.org; Wed, 21 Jun 2006 11:41:16 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4pP-0000Pl-D9 for ltru@ietf.org; Wed, 21 Jun 2006 11:41:16 -0400 Received: by wr-out-0506.google.com with SMTP id 71so175468wri for ; Wed, 21 Jun 2006 08:41:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=A7GXpWqlCfymphcIFSQVrd+6Qju/8i4E1fSMatukAU7Vg4oAzA9iuXjH1dZufJtcZrd6uS+46WiZCVq3WeXN3MXtkbnBbT/ZddeLu42xhEigvI6JspcHca1oJyq6/pH6GYNX0D3oKSGFLeQ1RTH72YkvqQ93SPrLJYbXVJ1XbKo= Received: by 10.65.252.5 with SMTP id e5mr1130289qbs; Wed, 21 Jun 2006 08:41:15 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Wed, 21 Jun 2006 08:41:14 -0700 (PDT) Message-ID: <30b660a20606210841t43d3375bxe546762e2472ddc7@mail.gmail.com> Date: Wed, 21 Jun 2006 08:41:14 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Charter Discussion In-Reply-To: <20060621153522.GJ22961@ccil.org> MIME-Version: 1.0 References: <20060621153522.GJ22961@ccil.org> X-Google-Sender-Auth: 7e4a7ce2ae2941f0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Misha Wolf , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1466764654==" Errors-To: ltru-bounces@ietf.org --===============1466764654== Content-Type: multipart/alternative; boundary="----=_Part_143944_4190700.1150904474845" ------=_Part_143944_4190700.1150904474845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd be stronger about it. Unless someone can present some good reasons beforehand for even wanting to consider it, we should definitely not put it in the charter. Mark On 6/21/06, John Cowan wrote: > > Misha Wolf scripsit: > > > And I take the slightly different view, that anyone who wants > > the WG to consider using ISO 11179 should come up with one or > > more reasons why we should do so and should persuade the WG > > that these reasons are good ones. > > Those would rightly be reasons for *using* 11179, not merely > for *considering* its use. > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > If a soldier is asked why he kills people who have done him no harm, or a > terrorist why he kills innocent people with his bombs, they can always > reply that war has been declared, and there are no innocent people in an > enemy country in wartime. The answer is psychotic, but it is the answer > that humanity has given to every act of aggression in history. --Northrop > Frye > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_143944_4190700.1150904474845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd be stronger about it. Unless someone can present some good reasons beforehand for even wanting to consider it, we should definitely not put it in the charter.

Mark

On 6/21/06, John Cowan <cowan@ccil.org> wrote:
Misha Wolf scripsit:

> And I take the slightly different view, that anyone who wants
> the WG to consider using ISO 11179 should come up with one or
> more reasons why we should do so and should persuade the WG
> that these reasons are good ones.

Those would rightly be reasons for *using* 11179, not merely
for *considering* its use.

--
John Cowan   cowan@ccil.org     http://ccil.org/~cowan
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye

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

------=_Part_143944_4190700.1150904474845-- --===============1466764654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1466764654==-- From ltru-bounces@ietf.org Wed Jun 21 11:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4vy-0001Hz-Ia; Wed, 21 Jun 2006 11:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4vw-0001FD-Pe for ltru@ietf.org; Wed, 21 Jun 2006 11:48:00 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4vv-0001gZ-J2 for ltru@ietf.org; Wed, 21 Jun 2006 11:48:00 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Ft4vv-0005fg-Bx; Wed, 21 Jun 2006 11:47:59 -0400 Date: Wed, 21 Jun 2006 11:47:59 -0400 To: Mark Davis Subject: Re: [Ltru] Charter Discussion Message-ID: <20060621154759.GL22961@ccil.org> References: <20060621153522.GJ22961@ccil.org> <30b660a20606210841t43d3375bxe546762e2472ddc7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20606210841t43d3375bxe546762e2472ddc7@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I'd be stronger about it. Unless someone can present some good > reasons beforehand for even wanting to consider [ISO 11179], we should > definitely not put it in the charter. The reason for *considering* it is that it's an international standard that is germane to what we are doing. If we put it in the charter and no one presents sufficiently compelling arguments for using it, we simply say that n default of such arguments we have not used 11179. But I see no merit to locking ourselves out in advance. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the cowan@ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 11:53:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft51i-0005vw-Gb; Wed, 21 Jun 2006 11:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft51h-0005vg-7e for ltru@ietf.org; Wed, 21 Jun 2006 11:53:57 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft51f-0002Wf-SA for ltru@ietf.org; Wed, 21 Jun 2006 11:53:57 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Wed, 21 Jun 2006 15:53:50 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J1700JNUW5QTD@eupig2.dtc.lon.ime.reuters.com>; Wed, 21 Jun 2006 15:53:50 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.23]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 21 Jun 2006 16:53:49 +0100 Date: Wed, 21 Jun 2006 16:53:36 +0100 From: Misha Wolf Subject: RE: [Ltru] Charter Discussion To: John Cowan Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Charter Discussion thread-index: AcaVSFLzQ4AHUEHPQXKuYxlD7Lgl3QAAereA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jun 2006 15:53:49.0928 (UTC) FILETIME=[E33E7E80:01C6954A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I suppose that the WG could perceive two levels of evidence: - persuasive evidence that it is worth spending time on=20 ISO 11179 (ie reasons for considering) - persuasive evidence that it is worth modifying BCP 47=20 in the light of ISO 11179 (ie reasons for using) The former could be put forward before resumption of work;=20 the latter after. Misha -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: 21 June 2006 16:35 To: Misha Wolf Cc: ltru@ietf.org Subject: Re: [Ltru] Charter Discussion Misha Wolf scripsit: > And I take the slightly different view, that anyone who wants=20 > the WG to consider using ISO 11179 should come up with one or=20 > more reasons why we should do so and should persuade the WG=20 > that these reasons are good ones. Those would rightly be reasons for *using* 11179, not merely for *considering* its use. [...] To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 12:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Iq-0000Fb-TR; Wed, 21 Jun 2006 12:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Im-0008EI-LD for ltru@ietf.org; Wed, 21 Jun 2006 12:11:36 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5Em-0004CQ-Bp for ltru@ietf.org; Wed, 21 Jun 2006 12:07:29 -0400 Received: by nz-out-0102.google.com with SMTP id i11so177984nzi for ; Wed, 21 Jun 2006 09:07:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=sitG8gkOo3hHUSEz3/8sXMBv9vVYo1aj8cGEqMagUoMBh17/jKiY/S/bcxMil/nfrqshrjk0bMxMFstT6yY5X+P66UysKmX9R5zqSoW631uVkk8oylBs2rX9ohkBnT/tdThQhgBxIvAh4hW5Q5uHX7ceduDqDwfrMTASXOU4q10= Received: by 10.64.24.20 with SMTP id 20mr2848259qbx; Wed, 21 Jun 2006 09:07:27 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Wed, 21 Jun 2006 09:07:23 -0700 (PDT) Message-ID: <30b660a20606210907g5716dcb2h28917fec3363005b@mail.gmail.com> Date: Wed, 21 Jun 2006 09:07:23 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Charter Discussion In-Reply-To: <20060621154759.GL22961@ccil.org> MIME-Version: 1.0 References: <20060621153522.GJ22961@ccil.org> <30b660a20606210841t43d3375bxe546762e2472ddc7@mail.gmail.com> <20060621154759.GL22961@ccil.org> X-Google-Sender-Auth: 31212e066cd47c57 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0886837951==" Errors-To: ltru-bounces@ietf.org --===============0886837951== Content-Type: multipart/alternative; boundary="----=_Part_144351_28736736.1150906043081" ------=_Part_144351_28736736.1150906043081 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline But is it germane? We need at least some reasons for considering it. I could come up with a *host* of standards that are to some degree relevant to what we are doing; it doesn't mean that we should spend time considering them, nor does it mean that we have to mention considering each one in the charter. Given how much time this group spends arguing about even trivia, there is no reason to provide more grist for the mill unless someone first presents at least an initial case for why it would be beneficial. Mark On 6/21/06, John Cowan wrote: > > Mark Davis scripsit: > > > I'd be stronger about it. Unless someone can present some good > > reasons beforehand for even wanting to consider [ISO 11179], we should > > definitely not put it in the charter. > > The reason for *considering* it is that it's an international standard > that is germane to what we are doing. If we put it in the charter > and no one presents sufficiently compelling arguments for using it, > we simply say that n default of such arguments we have not used 11179. > > But I see no merit to locking ourselves out in advance. > > -- > First known example of political correctness: John Cowan > After Nurhachi had united all the other http://www.ccil.org/~cowan > Jurchen tribes under the leadership of the cowan@ccil.org > Manchus, his successor Abahai (1592-1643) > issued an order that the name Jurchen should --S. Robert Ramsey, > be banned, and from then on, they were all The Languages of > China > to be called Manchus. > ------=_Part_144351_28736736.1150906043081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline But is it germane? We need at least some reasons for considering it. I could come up with a *host* of standards that are to some degree relevant to what we are doing; it doesn't mean that we should spend time considering them, nor does it mean that we have to mention considering each one in the charter.

Given how much time this group spends arguing about even trivia, there is no reason to provide more grist for the mill unless someone first presents at least an initial case for why it would be beneficial.

Mark

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

> I'd be stronger about it. Unless someone can present some good
> reasons beforehand for even wanting to consider [ISO 11179], we should
> definitely not put it in the charter.

The reason for *considering* it is that it's an international standard
that is germane to what we are doing.  If we put it in the charter
and no one presents sufficiently compelling arguments for using it,
we simply say that n default of such arguments we have not used 11179.

But I see no merit to locking ourselves out in advance.

--
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      cowan@ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.

------=_Part_144351_28736736.1150906043081-- --===============0886837951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0886837951==-- From ltru-bounces@ietf.org Wed Jun 21 12:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5J2-00016U-7Q; Wed, 21 Jun 2006 12:11:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Iz-00015Y-Vv for ltru@ietf.org; Wed, 21 Jun 2006 12:11:49 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft58g-0003az-E2 for ltru@ietf.org; Wed, 21 Jun 2006 12:01:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Ft58g-00065d-58; Wed, 21 Jun 2006 12:01:10 -0400 Date: Wed, 21 Jun 2006 12:01:10 -0400 To: Misha Wolf Subject: Re: [Ltru] Charter Discussion Message-ID: <20060621160110.GM22961@ccil.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > I suppose that the WG could perceive two levels of evidence: > > - persuasive evidence that it is worth spending time on > ISO 11179 (ie reasons for considering) > > - persuasive evidence that it is worth modifying BCP 47 > in the light of ISO 11179 (ie reasons for using) Just so. If no evidence of the second kind is given, no time need be spent. As for evidence of the first kind, since the barrier ought to be low (as the costs are low), the fact that we have created a metadata registry, which is the subject matter of 11179, should IMHO suffice. -- Principles. You can't say A is John Cowan made of B or vice versa. All mass http://www.ccil.org/~cowan is interaction. --Richard Feynman _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 12:19:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Q8-0004Jv-G2; Wed, 21 Jun 2006 12:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Q7-0004Jq-Ac for ltru@ietf.org; Wed, 21 Jun 2006 12:19:11 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5Q6-0004na-33 for ltru@ietf.org; Wed, 21 Jun 2006 12:19:11 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c15.corp.yahoo.com [10.72.76.15]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5LGIgbj086449; Wed, 21 Jun 2006 09:18:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=AVTXxzCttgQsUxNbas/weRJdJdn3TPUKW2LZmmrJjWY0Imx/n1UP+oOuBPoRF2/T From: "Addison Phillips" To: "'John Cowan'" , "'Mark Davis'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 09:18:42 -0700 Message-ID: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVSh6XLzg3h1s7TYy9bSw2tecMPwAAPjhg In-Reply-To: <20060621154759.GL22961@ccil.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > But I see no merit to locking ourselves out in advance. I see merit in limiting the scope of a revision to 3066bis. We have struggled long and mightily to produce 3066bis. There are very few changes necessary to incorporate ISO 639-3, which is the reason for producing a revision. Any additional things we might undertake would need to be really compelling in order for me to support them. Look, it isn't as if ISO 11179 was a secret. It was considered during the development of 3066bis. A few people familiar with the standard counseled the WG then that it was unnecessary to include it: I don't know if this advice was good or not. A few arguments were advanced in its favor, but mainly the argument was "because it is a standard". For us to reverse course and incorporate it now requires an understanding of the benefits and impact of trying to include it. I think we have a very real interest in seeing a revision to 3066bis be very small. Having undergone a major revision, I am of the opinion that we cannot afford another one. So I'm open to the argument, but wish someone would produce it. If it cannot be produced "now" (i.e. in some relatively short period, measured in weeks), I would oppose even mentioning it in our charter, as it is unlikely to have a limited scope or be produced later. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: mercredi 21 juin 2006 08:48 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Charter Discussion > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 12:19:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5QN-0004LB-Jp; Wed, 21 Jun 2006 12:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5QM-0004L6-HN for ltru@ietf.org; Wed, 21 Jun 2006 12:19:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5QL-0004oD-5z for ltru@ietf.org; Wed, 21 Jun 2006 12:19:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGJLm0018084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 09:19:21 -0700 Received: from [10.26.67.131] (dhcp129-46-172-2.qualcomm.com [129.46.172.158]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGJE8q023159; Wed, 21 Jun 2006 09:19:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200606210259.k5L2ws3m015282@mta1.iomartmail.com> References: <200606210259.k5L2ws3m015282@mta1.iomartmail.com> Date: Wed, 21 Jun 2006 09:19:14 -0700 To: "Debbie Garside" , "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" From: Ted Hardie Subject: RE: [Ltru] Charter Discussion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 3:58 AM +0100 6/21/06, Debbie Garside wrote: > >I don't expect you to need this but it is never a bad thing to be in >conformity with an International Standard. There is no argument against it. >Appeals etc. in relation to the structure and content of the Registry to the >IESG are negated purely and simply by being in conformity with an >International Standard. Dead easy really! It is my understanding of our appeals process that conformity with an external standard here would neither preclude an appeal nor be the basis for the IESG to reject the appeal. The appeal would have to stand on its merits in either case. At most, it might cause an appellant to assert that choice of this standard for the registry form was ill-made rather than the individual choices that went into the working group's document were ill-made. Since the appellant could also assert that the working group should not have chosen any other external standard (but should have rolled its own in a particular way), the work that goes into considering an appeal probably would not even go down. regards, Ted Hardie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 14:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7SK-0005kg-5E; Wed, 21 Jun 2006 14:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7SJ-0005ka-3T for ltru@ietf.org; Wed, 21 Jun 2006 14:29:35 -0400 Received: from mta1.iomartmail.com ([62.128.193.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7SI-0001pz-IW for ltru@ietf.org; Wed, 21 Jun 2006 14:29:35 -0400 Received: from mta1.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5LIT3Rn019001; Wed, 21 Jun 2006 19:29:03 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5LISvHf018863; Wed, 21 Jun 2006 19:29:02 +0100 Message-Id: <200606211829.k5LISvHf018863@mta1.iomartmail.com> From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 19:28:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <001e01c694f0$560a1100$6501a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaU8FN2wt24DQ5tS9WXe3u3v+rjZwAWxucw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'Doug Ewell' , 'Doug Ewell' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 to Randy's post. Given the lack of actual ISO 11179 information being discussed here it seems obvious that nobody here feels conversant enough with the standard to be able to say what the benefits could be. This includes me. I read the standard 18 months ago and would need to seriously re-fresh my memory before commenting. As many of you know already from other conversations, ISO 11179 is a six part standard and investigating the pros and cons is not going to be a 5 minute task. Let me make this absolutely clear. I am not flying the ISO 11179 flag. Investigation can be defined in several ways. To my mind in the context in which we speak it means un-biased enquiry. The product of such an investigation would be the presentation of possible benefits to this WG. The WG would then assess the value of those benefits in an un-biased manner. John wrote: "The reason for *considering* it is that it's an international standard that is germane to what we are doing. If we put it in the charter and no one presents sufficiently compelling arguments for using it, we simply say that n default of such arguments we have not used 11179. But I see no merit to locking ourselves out in advance." I agree 100% with what John has said. Doug has suggested that he would be happy to assist me in assessing any potential benefits. Thank you. I would be happy to conduct some PRELIMINARY investigations and report back to this WG. The main problem I have is time. I can maybe spare half a day to look at this at present (over the next couple of weeks). Other than that the nearest available time I have to conduct thorough investigations would be September. I have no great desire to do this. If there is anyone within this WG who would like to do this I will happily move aside. I have only suggested that it might be beneficial to consider ISO 11179. Best regards Debbie Garside > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 21 June 2006 06:06 > To: LTRU Working Group > Subject: Re: [Ltru] Charter Discussion > > ... > > I will persist, if I may, with one point: if you wish to > suggest that > > this WG consider something for a new charter, it is > incumbent upon you > > to explain what it is and why the WG should consider it. I thought > > (was I wrong?) that "sticking it on the menu" meant putting it in a > > new charter. As I indicated, as an abstract notion, I'm happy to > > consider ISO 11179 along with other things the WG might do in RFC > > 3066ter. But, unless there is some reason to, I oppose actually > > mentioning it in the charter as a requirement (just as I > would oppose > > mentioning any other random ideas--like using UTF-8 for the > registry > > file). I misread your messages as a call for including it > in the list > > of work to do. I'm opposed to that. I'm not opposed to > considering if > > ISO 11179 might be appropriate within the context of 3066ter, but I > > think the charter scope and the changes to 3066bis should > be as minor as possible (but no more so, to paraphrase Einstein). > ... > > As an individual contributor who has some experience with > charters and specification update efforts... > > I think there are three obvious options for a charter update > with respect to the question of ISO 11179: > a) say nothing about using ISO 11179 in producing 3066ter > b) require use of ISO 11179 in producing 3066ter > c) require WG to consider using ISO 11179, with the assumption > that if the cost/benefit ration proves favorable, we'd use it > > Having some experience in how updates to complex > specifications happen in the IETF... > - choosing (a) practically guarantees that ISO 11179 would not > be used. The default position in an update effort is normally > to make changes only when absolutely necessary, and to keep > the changes as small as practical. > - I think choosing (b) would be premature now, and it doesn't look > like arguments clinching the case for ISO 11179 are > coming anytime > soon. I think this would be a "non-starter." > - choosing (c) means we'd have to (at least) get a design team to > dig into ISO 11179 and make a recommendation to the WG. This > is obviously more work than (a). > > What I think is needed at this stage is for folks who've > looked into ISO 11179 at least a little to think whether it > shows enough promise of benefit to make it worthwhile to > commit to the effort the investigation option (c) would > entail. If they're not convinced, then by default we'll end > up with (a), which, as a practical matter, would make it much > harder to steer the effort into using ISO 11179. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 15:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft86H-00079s-TY; Wed, 21 Jun 2006 15:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft86G-00079b-Mo for ltru@ietf.org; Wed, 21 Jun 2006 15:10:52 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft86F-000730-8y for ltru@ietf.org; Wed, 21 Jun 2006 15:10:52 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5LJAnnq024582; Wed, 21 Jun 2006 20:10:49 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5LJAhDk024448; Wed, 21 Jun 2006 20:10:48 +0100 Message-Id: <200606211910.k5LJAhDk024448@mta6.iomartmail.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 20:10:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <001601c694e6$788f6450$650a0a0a@ds.corp.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaGo26Z3n+Okh1yQgaydDzUpmEwUgOEYPRAAABlVJAAAMNGkAABSeagAAV49XAAALATUAABMDFAAAHKzwAAH9piEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: > > I apologize if I have misread your intentions. Not necessary. But thank you anyway. > I will persist, if I may, with one point: if you wish to > suggest that this WG consider something for a new charter, it > is incumbent upon you to explain what it is and why the WG > should consider it. I believe I have already done that and John has reiterated, albeit more eloquently. I thought (was I wrong?) that "sticking > it on the menu" meant putting it in a new charter. No you were not wrong Perhaps it is my turn to apologise. Perhaps I did not realise the true significance and importance of the Charter. Latterly, in the light of Randy's comments, I think perhaps it should be in the Charter. "sticking it on the menu" means "put it up for discussion". However, I can see now that the Charter needs to be tighter than that. I would ask you to re-read my original post. Make note of the use of "if", "may" and "beneficial". Then focus on my key message. The key message was lost in all this. The WG should not be dis-banded but rather should get on with the job of considering ISO 639-3 prior to publication! > As I > indicated, as an abstract notion, I'm happy to consider ISO > 11179 along with other things the WG might do in RFC 3066ter. > But, unless there is some reason to, I oppose actually > mentioning it in the charter as a requirement (just as I > would oppose mentioning any other random ideas--like using > UTF-8 for the registry file). Why... ? In saying that this WG should investigate the possible benefits of ISO 11179 where is the harm? As to UTF-8 why not enter "review and revise registry format as WG deems necessary". > I misread your messages as a > call for including it in the list of work to do. >I'm opposed > to that. I think it may be beneficial to look at it. There is no point in looking at it if once the discussion is on someone says "hey, that's not in our Charter and is therefore out of scope of this WG"! > I'm not opposed to considering if ISO 11179 might be > appropriate within the context of 3066ter, So what are we arguing about? > but I think the > charter scope and the changes to 3066bis should be as minor > as possible (but no more so, to paraphrase Einstein). Well, I am sure I don't want to be here in 3 years time discussing it. > Let me know the address of the flower arranging forum. It > would be a benison after a long day's language tagging. Hmmm... Spiritual flower arranging... Now there is a blessed thought! ;-) Best regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 18:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAp7-0007xO-K9; Wed, 21 Jun 2006 18:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAp5-0007xJ-Qi for ltru@ietf.org; Wed, 21 Jun 2006 18:05:19 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound2-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAp5-0003IR-0R for ltru@ietf.org; Wed, 21 Jun 2006 18:05:19 -0400 Received: from outbound2-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-red-R.bigfish.com (Postfix) with ESMTP id 51C51CB45C3; Wed, 21 Jun 2006 22:05:20 +0000 (UTC) Received: from mail27-red-R.bigfish.com (unknown [172.18.12.3]) by outbound2-red.bigfish.com (Postfix) with ESMTP id 47E7FCB45B6; Wed, 21 Jun 2006 22:05:20 +0000 (UTC) Received: from mail27-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail27-red-R.bigfish.com (Postfix) with ESMTP id 2E0AD3F09B3; Wed, 21 Jun 2006 22:05:18 +0000 (UTC) X-BigFish: VP Received: by mail27-red (MessageSwitch) id 1150927517588300_5898; Wed, 21 Jun 2006 22:05:17 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail27-red.bigfish.com (Postfix) with ESMTP id 8542E3F09B4; Wed, 21 Jun 2006 22:05:17 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006062115071978-145248 ; Wed, 21 Jun 2006 15:07:19 -0700 In-Reply-To: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> To: "Addison Phillips" Subject: RE: [Ltru] Charter Discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 21 Jun 2006 15:04:25 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 06/21/2006 15:04:26, Serialize complete at 06/21/2006 15:04:26, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/21/2006 03:07:19 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/21/2006 03:07:21 PM, Serialize complete at 06/21/2006 03:07:21 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0342199126==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0342199126== Content-Type: multipart/alternative; boundary="=_alternative 0079549988257194_=" This is a multipart message in MIME format. --=_alternative 0079549988257194_= Content-Type: text/plain; charset="US-ASCII" Yes, I'm still lurking. My two cents: I've looked into ISO 11179 very deeply in spots as I'm actively arguing for some of its data element naming/description best practices in another group I serve. The metadata standard I work on for this group has about 2,000 data elements (not data *values* such as "en-US", but *elements* such as "RFC 3066 Language Code"). Each element must be assigned a unique, descriptive name and XML symbol. The naming and unambiguous description of elements in large standards such as this can be very complicated and benefits from the conceptual metamodel, naming guidelines, and other best practices found in ISO 11179. RFC 3066 does not seem to approach the scope of this work at all as far as the number of data elements it contains. It seems to me that ISO 11179 is more appropriate for registries with a larger number of metadata types -- something on the IANA scale, not just RFC 3066. For the record, I have not read the administrative practices section as carefully as the data element naming, metamodel, and description work. It's all good stuff, but to me it seems aimed at a registry with a greater variety of data. FWIW, Karen Broome Sony Pictures Entertainment P.S. When this group of traditional engineers complains about the syntax, punctuation, and terminology rules I want to set for data element description, I tell them how many e-mails a group of IETF linguists are willing to generate on the subject of a single apostrophe. ;) "Addison Phillips" 06/21/2006 09:18 AM To "'John Cowan'" , "'Mark Davis'" cc ltru@ietf.org Subject RE: [Ltru] Charter Discussion > But I see no merit to locking ourselves out in advance. I see merit in limiting the scope of a revision to 3066bis. We have struggled long and mightily to produce 3066bis. There are very few changes necessary to incorporate ISO 639-3, which is the reason for producing a revision. Any additional things we might undertake would need to be really compelling in order for me to support them. Look, it isn't as if ISO 11179 was a secret. It was considered during the development of 3066bis. A few people familiar with the standard counseled the WG then that it was unnecessary to include it: I don't know if this advice was good or not. A few arguments were advanced in its favor, but mainly the argument was "because it is a standard". For us to reverse course and incorporate it now requires an understanding of the benefits and impact of trying to include it. I think we have a very real interest in seeing a revision to 3066bis be very small. Having undergone a major revision, I am of the opinion that we cannot afford another one. So I'm open to the argument, but wish someone would produce it. If it cannot be produced "now" (i.e. in some relatively short period, measured in weeks), I would oppose even mentioning it in our charter, as it is unlikely to have a limited scope or be produced later. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: mercredi 21 juin 2006 08:48 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Charter Discussion > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 0079549988257194_= Content-Type: text/html; charset="US-ASCII"
Yes, I'm still lurking. My two cents:

I've looked into ISO 11179 very deeply in spots as I'm actively arguing for some of its data element naming/description best practices in another group I serve. The metadata standard I work on for this group has about 2,000 data elements (not data *values* such as "en-US", but *elements* such as "RFC 3066 Language Code").  Each element must be assigned a unique, descriptive name and XML symbol. The naming and unambiguous description of elements in large standards such as this can be very complicated and benefits from the conceptual metamodel, naming guidelines, and other best practices found in ISO 11179.

RFC 3066 does not seem to approach the scope of this work at all as far as the number of data elements it contains. It seems to me that ISO 11179 is more appropriate for registries with a larger number of metadata types -- something on the IANA scale, not just RFC 3066.

For the record, I have not read the administrative practices section as carefully as the data element naming, metamodel, and description work. It's all good stuff, but to me it seems aimed at a registry with a greater variety of data.

FWIW,

Karen Broome
Sony Pictures Entertainment

P.S. When this group of traditional engineers complains about the syntax, punctuation, and terminology rules I want to set for data element description, I tell them how many e-mails a group of IETF linguists are willing to generate on the subject of a single apostrophe.  ;)





"Addison Phillips" <addison@yahoo-inc.com>

06/21/2006 09:18 AM

To
"'John Cowan'" <cowan@ccil.org>, "'Mark Davis'" <mark.davis@icu-project.org>
cc
ltru@ietf.org
Subject
RE: [Ltru] Charter Discussion





> But I see no merit to locking ourselves out in advance.

I see merit in limiting the scope of a revision to 3066bis. We have
struggled long and mightily to produce 3066bis. There are very few changes
necessary to incorporate ISO 639-3, which is the reason for producing a
revision. Any additional things we might undertake would need to be really
compelling in order for me to support them.

Look, it isn't as if ISO 11179 was a secret. It was considered during the
development of 3066bis. A few people familiar with the standard counseled
the WG then that it was unnecessary to include it: I don't know if this
advice was good or not. A few arguments were advanced in its favor, but
mainly the argument was "because it is a standard". For us to reverse course
and incorporate it now requires an understanding of the benefits and impact
of trying to include it. I think we have a very real interest in seeing a
revision to 3066bis be very small. Having undergone a major revision, I am
of the opinion that we cannot afford another one.

So I'm open to the argument, but wish someone would produce it. If it cannot
be produced "now" (i.e. in some relatively short period, measured in weeks),
I would oppose even mentioning it in our charter, as it is unlikely to have
a limited scope or be produced later.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.  

> -----Original Message-----
> From: John Cowan [mailto:cowan@ccil.org]
> Sent: mercredi 21 juin 2006 08:48
> To: Mark Davis
> Cc: ltru@ietf.org
> Subject: Re: [Ltru] Charter Discussion
>


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 0079549988257194_=-- --===============0342199126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0342199126==-- From ltru-bounces@ietf.org Wed Jun 21 20:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD3y-000369-Kg; Wed, 21 Jun 2006 20:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD3x-00034b-47 for ltru@ietf.org; Wed, 21 Jun 2006 20:28:49 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtD3p-0002Qu-3R for ltru@ietf.org; Wed, 21 Jun 2006 20:28:45 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5M0SKhM021535; Thu, 22 Jun 2006 09:28:20 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 29d5_018bee48_0186_11db_97c5_0014221fa3c9; Thu, 22 Jun 2006 09:28:19 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5M0SFPw031345; Thu, 22 Jun 2006 09:28:18 +0900 Message-Id: <6.0.0.20.2.20060621140734.03b71070@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 21 Jun 2006 14:15:05 +0900 To: "Addison Phillips" , "'Debbie Garside'" , "'LTRU Working Group'" From: Martin Duerst Subject: Rechartering terminology (was: [Ltru] Charter Discussion) In-Reply-To: <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> References: <200606202305.k5KN5cU6009088@mta6.iomartmail.com> <001501c694c6$a5ff1130$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat on] At 09:07 06/06/21, Addison Phillips wrote: Debbie Garside wrote: >> I'll take that as a vote for re-Charter then! [aside: in the IETF, we don't count votes] >That is a vote for doing 3066ter in this group, soon-ish, with quite limited >scope for change---almost a RFC3066bis "second edition" or errata, >rechartering if necessary. Just a small terminology correction: "Rechartering", in the context of the IETF, and as far as I can remember, refers to changing a group's charter, usually when extending a group's duration. Because both of our current deliverables are (mostly) done, if we want to continue work in this group, we need to change the charter, which means that we need to recharter. Closing the group, with the option of later creating a new group (which would have a new acronym, e.g. ultru (update of language tag registry update :-)) is different from rechartering. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 20:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD3y-00036D-Mj; Wed, 21 Jun 2006 20:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD3x-00034a-4C for ltru@ietf.org; Wed, 21 Jun 2006 20:28:49 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtD3p-0002Qn-3R for ltru@ietf.org; Wed, 21 Jun 2006 20:28:45 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5M0SIDc021532 for ; Thu, 22 Jun 2006 09:28:18 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 29d5_00b565bc_0186_11db_97c5_0014221fa3c9; Thu, 22 Jun 2006 09:28:18 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5M0SFPu031345 for ; Thu, 22 Jun 2006 09:28:18 +0900 Message-Id: <6.0.0.20.2.20060619152835.0769d880@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 21 Jun 2006 23:15:28 +0900 To: "LTRU Working Group" From: Martin Duerst In-Reply-To: <7.0.1.0.2.20060618165520.03b26178@online.fr> References: <7.0.1.0.2.20060618165520.03b26178@online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Subject: [Ltru] Re: Last call: BCP 47 second part. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear LTRU members (cc IETF mailing list), Here are my comments on how I (as a technical contributor) propose to address the Last Call comments made below. I hope others have some comments, too. At 23:56 06/06/18, JFC (Jefsey) Morfin wrote: >Dear IESG Members, > >1. The proposed Draft is not about matching (it is absurd to say that my Italian can "match" your Japanese in order for us to understand each other better). It is about using pattern matching techniques in order to filter lists against a langtag with two results (max one answer, no max) and in two cases (well formed langtag or not). However, the wording is such that without examples it is difficult to understand the specifications of the pattern matching function that is being used - and therefore the possible applications and the purpose of the Draft. The algorithm of this function is undocumented and there is no obligation to document it, what may lead to blocking conflicts if two filters may have to interoperate. This proposition is NOT scalable and does not intent to be scalable. The matching draft of course makes sure that "ja" and "it" do not match. Nothing absurd happening there. Also, what the draft actually describes is matching language tags against language ranges; there are three matching variants, two for filtering and one for lookup. Some of the matching procedures indeed have to be read carefully. But the WG made every attempt to describe them carefully, going through several iterations. And we provide examples, too. The main applications envisioned by the draft are described in the draft, they are things such as selection of documents (e.g. when searching) or document pieces (e.g. for styling) in the case of filtering and finding the best match to return documents or document fragments in the case of lookup (the prototypical example being HTTP language negotiation). As for conflicting filters, there is no requirement that two filters (e.g. in two different protocols) produce exactly the same result. Different protocols may have different needs. That's why the draft leaves some specifics for a particular protocol to be decided. As a result, I do not see anything in comment 1. that would need addressing in the current draft. >2. Either RFC 3066 Bis is well written (what I think we achieved if strictly limited to the Internationalized ASCII Internet) and well applied (what I can see that it is not the case: the review mechanism does not respect RFC 3066 Bis) and the filtering is already built-in, and the functional strategies are to be specific to applications and protocols. Or that Draft, which does not seek to first ensure that langtags respect RFC 3066 Bis (i.e. being well formed or corrected in order to become well formed), is a negation of RFC 3066 Bis. I think that authors had filtering in mind (it was the apex of the first unique document) and did not realise that the work achieved in cleaning the first part made its correction by the second part not necessary anymore. That is if the whole purpose was not a non documented use of the filtering (users mass profiling). If it was not the whole document can be written as "make sure langtags are well formed and feed them on the pattern matching function of your application/protocol to obtain the results it needs along your language management strategy". The commenter seems to claim that draft-ietf-ltru-matching conflicts with draft-ietf-ltru-registry (here called RFC 3066bis) because the later defines well-formed tags while the former does not require well-formed tags. The reason for not requiring checking for well-formed tags when matching was discussed extensively in the WG. There is a very clear reason: requiring this would require to check the IANA language subtag registry, potentially for every matching operation, which was considered operationally infeasible. It would also be an unnecessary performance punishment for those who actually use well-formed tags. In general, non-wellformed tags or ranges will simply not match anything, which is just fine. The commenter is correct in that there is no absolute need for this draft; each protocol or format could come up with it's own way of matching language tags. After all, RFC 3066bis defines how these tags are built, and (to a certain extent) what they mean. However, I consider the current draft valuable because it helps protocol/format designers, who in general are not experts on language tags and language matching, to choose the right kind of matching scheme. Also, one matching scheme was already described in RFC 3066, and so it would be difficult to obsolete RFC 3066 without this draft. I therefore don't see any change that would be needed in the current draft to address comment 2. >3. "*" restrictions in the pattern matching function can hardly be understood without several examples. They add usage limitations to the RFC 3066 Bis format, where they should be documented $B%e(B or the Draft cannot be part of BCP 47. This certainly belongs to the language constraining strategy of the WG-LTRU affinity group and to the interests a co-Chair recently documented. But this is unacceptable to most users, even if it is certainly favourable to a national strategy and to the members of a given consortium. I therefore submit that the IESG Members who are citizens of that nation, or members, or employees of the members of that commercial consortium have a COI. There are no restrictions on the use of "*" in language ranges. There is a very specific treatment of "*" wildcard components in language ranges for extended filtering. The actual algorithm in the draft is described carefully, and an explanation for why it is the way it is is given. This matching algorithm does not add any usage limitations to RFC 3066bis. On the contrary, it was carefully designed to work well together with RFC 3066bis. I do not know of any concrete example where the matching behavior would be unacceptable. Any claims that it is "unacceptable to most users", are therefore, in my view, just made up out of thin air. Also, I have no idea what is meant by "language-constraining strategy". If anybody wanted to restrict the use of certain languages in certain parts of the Internet, they could easily already have done that based on RFC 3066, or could do based on RFC 3066bis, or even just based on statistical analysis of the actual content transmitted (with techniques such as trigrams). And certainly nobody who actually wanted to do such a thing would ask for an RFC or other kind of standard to try to legitimate such restrictions, nor would I hope anybody would condone such behavior just because it would make use of an RFC. As a result, I don't think that anything needs to be done to address comments 3. >4. All the above means that the Draft is useful in at least two circumstances: > - if the langtags are not well formed or do not respect the principles of ISO 639-4 and/or RFC 3066 Bis. > - if the langtags are used for other purposes that are undocumented at the WG-LTRU Charter. >These circumstances should be documented. ISO 639-4 is still being worked on. The possibility of using non-wellformed tags is not something the draft is designed to do; it is just a consequence of not requiring checking for well-formedness (to avoid operational problems). The draft explicitly says that there is no need to check for well-formedness, so I don't see what would need to be documented further. The draft, like most IETF work, mentions possible uses of the technology, in particular as examples to explain design decisions or choices of options for the users (in the case of the draft, the direct users are protocols and formats). Any attempt to describe any and all possible uses for a technology invariably fail, and so shouldn't be attempted in the first place. I therefore don't see any change that would be necessary based on comment 4. >5. The security section should mention that this Daft encourages the disrespect of the RFC 3066 Bis format and further assists dangerous projects that the IETF has refused to mention in RFC 3066 Bis, such as lingual, cultural, racial, and religious profiling through retro-meta-spam ("I know who you are through which langtags you are not aware that you respond to"), two-tier Internet based upon the lingual characteristics of the users and their supposed market value, lack of conformance to ISO 11179, which may lead the IETF, stakeholders, and users to inadequate, costly, and delaying strategies or to conflicts with the Multilingual Internet - as in the sad DoS against the leading economic language ("en-EU") - or to legal access bans by democratic or privacy oriented countries. All of this lends itself to incentives for an Internet fragmentation. As explained above, there is no disrespect for RFC 3066 bis formats, just operational considerations. Also, the draft does not assist any of the 'dangerous projects' mentioned above; any of these projects are, if some entity is determined to do them and has the necessary access, easily possible with various other means. The problem that RFC 3066bis does not allow en-EU is a problem of RFC 3066bis, and may have to be addressed in a future revision, but does not affect the matching draft now in last call. Again, I don't see anything here that would need to be changed in the current draft to address this comment. >6. As far as I understand, two Draft compliant filters may result in different responses for the same filtering list and document. My concern is the interoperability of the proposed BCP 47 with Multilingual Internet registries, tags, etc. This interoperability is not ensured $B%e(B and there is no prospect to see it insured as it is purposely ignored by authors. This represents no incentive for developers. The three matching schemes described in the draft all come with a small number of options. In this sense, it is e.g. possible that two different protocols, having choosen different options, will lead to different results. An example would be an HTTP server serving a document in a different language than a corresponding FTP server (assuming somebody added language negotiation to FTP) for requests with the same language priority list. But as such a setup is highly fictional, and the two servers are configured separately anyway, having different results simply because of different configuration (rather than different language matching), or tweaking the configuration to make the results match, are both possible. So this kind of interoperability is not of importance in practice. Also, it is difficult to try to ensure interoperability with something called 'Multilingual Internet registries' when such a thing does neither exist on paper nor in practice. So there is nothing in comment 6 that would require any changes in the current draft. >7. The acknowledgement section mostly quote those who contributed to the pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation of the WG which never studied and tried to conform to its Charter). This is the privilege of authors to quote who supported them best. However, in this case the document was considerably cleaned through the tough life of the WG. Also, most of the names being quoted are widely known as belonging to a non-IETF affinity group, what enforces the external understanding that BCP 47 documents are actually not IETF documents. This will most probably limit their consideration. After one year of tough debates I can testify these, good or not, three documents are IETF documents for the Internationalized ASCII Internet. I listed the names I consider missing in a Last C all mail. > >Authors either did not read it or are keeping harassing me, since they continue asking for an input. I quote my mail: "every contribution can be a key stone in the final construct. That people like Michael Everson, Ned Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce are real.". I do not ask my name to be listed there since I know "it is not [the] interest [of some in the list] to be associated with [my own] name". > >Or would that mean that the IETF does not really back this deliverable? The question here is: does the IETF wants to influence the world (RFC 3935), document the Internationalised ASCII Internet, or serve the Multilingual Internet development. Many would like to know. The claim that the acknowledgement section mostly quotes those who contributed to the pre-WG documents is in stark contrast with the description of the editors about how they have formed that list of names. Most if not all the people mentioned above are acknowledged by reference, pointing to acknowledgement sections in related documents. In my function as co-chair, I have asked if anybody feels left out both on the WG list and on the IETF list; I have not received anything from anybody. As a technical contributor, I don't think there is any need for any change here. >All the best. >jfc > >PS. Having transparency in mind I copy the IETF main list. This LC ends tomorrow. I do not intent to address the comments. But I will certainly consider them in the appeal I suspect to be unfortunately necessary (NB. Before their first day decision to keep with a twice IETF LC failed document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could finish the work in a few months. I obviously eventually get step by step all what I wanted - in the documents or in the real world: but what a waste of time and effort). Cheers. I remember well that specially at the start of the WG, the WG co-chairs repeatedly asked for actual textual contributions. These were few and far between, and were usually rejected by the WG after some discussion. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 20:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD8m-0005d5-Mi; Wed, 21 Jun 2006 20:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtD8m-0005cW-AJ for ltru@ietf.org; Wed, 21 Jun 2006 20:33:48 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtD8l-0002f8-3y for ltru@ietf.org; Wed, 21 Jun 2006 20:33:48 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FtD8k-00027T-QQ; Wed, 21 Jun 2006 20:33:46 -0400 Date: Wed, 21 Jun 2006 20:33:46 -0400 To: Martin Duerst Subject: Re: [Ltru] Re: Last call: BCP 47 second part. Message-ID: <20060622003346.GR22961@ccil.org> References: <7.0.1.0.2.20060618165520.03b26178@online.fr> <6.0.0.20.2.20060619152835.0769d880@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060619152835.0769d880@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Dear LTRU members (cc IETF mailing list), > > Here are my comments on how I (as a technical contributor) > propose to address the Last Call comments made below. > I hope others have some comments, too. Meta-comment: Well done (which is what Jefsey will be, too). -- John Cowan cowan@ccil.org http://ccil.org/~cowan I come from under the hill, and under the hills and over the hills my paths led. And through the air. I am he that walks unseen. I am the clue-finder, the web-cutter, the stinging fly. I was chosen for the lucky number. --Bilbo _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 20:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDUj-0000gO-8j; Wed, 21 Jun 2006 20:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Ev-0001UV-64 for ltru@ietf.org; Wed, 21 Jun 2006 11:03:33 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Et-0006it-Kx for ltru@ietf.org; Wed, 21 Jun 2006 11:03:33 -0400 Received: from Laptop (81.224.37.252) by pne-smtpout1-sn1.fre.skanova.net (7.2.072.1) id 4492E80F00132D6B for ltru@ietf.org; Wed, 21 Jun 2006 17:03:30 +0200 From: "Webmaster - The Linguasphere Observatory" To: Date: Wed, 21 Jun 2006 17:03:39 +0200 Organization: The Linguasphere Observatory Message-ID: <003f01c69543$e14e9990$ac00a8c0@Laptop> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcaVQ+EGA5WqPuF9T66/VK1D+K9iNg== X-Spam-Score: 0.5 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f X-Mailman-Approved-At: Wed, 21 Jun 2006 20:56:26 -0400 Subject: [Ltru] The Linguasphere Observatory X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: webmaster@linguasphere.info List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1495873561==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1495873561== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C69554.A4D76990" This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C69554.A4D76990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Colleague, This is a very brief mail to draw your attention to the new weblog of Dr David Dalby of the Linguasphere Observatory. This site will follow the development of the second (online) edition of the Linguasphere Observatory Register of the World's Languages and Speech Communities. Dr Dalby would like to invite you to register on the site and to take advantage of the news feed technologies to follow developments and make comments on the sample data that will be published on it. Please feel free to forward this mail to any of your colleagues that may be interested and to publish the URL of the site in relevant newsgroups or online communities. If you would like to organise a reciprocal link then please contact webmaster@linguasphere.info The URL for the site is: http://www.langtag.com Best wishes, Ben Love The Linguasphere Observatory _____________________________________________________ Benjamin Love MCIL Webmaster The Linguasphere Observatory Hebron Whitland SA34 0XT www.langtag.com ------=_NextPart_000_0040_01C69554.A4D76990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Colleague,

 

This is a very brief mail to draw your attention to = the new weblog of Dr David Dalby of the Linguasphere Observatory. This site will = follow the development of the second (online) edition of the Linguasphere = Observatory Register of the World's Languages and Speech Communities. Dr Dalby would like to = invite you to register on the site and to take advantage of the news feed = technologies to follow developments and make comments on the sample data that will be published on it.

 

Please feel free to forward this mail to any of your colleagues that may be interested and to publish the URL of the site in relevant newsgroups or online communities. If you would like to organise = a reciprocal link then please contact webmaster@linguasphere.info =  

 

The URL for the site is: http://www.langtag.com

 

Best wishes,

 

 

Ben Love

 

The Linguasphere = Observatory

 

 

____________________________________________________= _

 

 

Benjamin Love MCIL

Webmaster

 

The Linguasphere = Observatory

Hebron

Whitland

SA34 = 0XT

 =

www.langtag.com

 

 

 

 

------=_NextPart_000_0040_01C69554.A4D76990-- --===============1495873561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1495873561==-- From ltru-bounces@ietf.org Wed Jun 21 21:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDlx-0003KP-Up; Wed, 21 Jun 2006 21:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDlw-0003KK-OP for ltru@ietf.org; Wed, 21 Jun 2006 21:14:16 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDlu-0005ZF-3g for ltru@ietf.org; Wed, 21 Jun 2006 21:14:16 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5M1E8Cg011109; Thu, 22 Jun 2006 10:14:08 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 60da_67e54ab2_018c_11db_81ac_0014221f2a2d; Thu, 22 Jun 2006 10:14:08 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5M1Dx8E031996; Thu, 22 Jun 2006 10:14:06 +0900 Message-Id: <6.0.0.20.2.20060622100018.03badd80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 22 Jun 2006 10:13:38 +0900 To: Karen_Broome@spe.sony.com, "Addison Phillips" From: Martin Duerst Subject: RE: [Ltru] Charter Discussion In-Reply-To: References: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Karen, At 07:04 06/06/22, Karen_Broome@spe.sony.com wrote: >Yes, I'm still lurking. My two cents: This is way more worth than 2 cents! It is the first post in a long time that actually said more about ISO 11179 than its number and the degree to which we 'might consider' it. As a co-chair, I want encourage everybody to either express their opinions on ISO 11179 with a similar level of detail as Karen, or to stop repeating their position. As a technical contributor, Karen's arguments that ISO 11179 is for way bigger things than our language tag registry is very convincing. Unless somebody else brings up equally convincing arguments, my personal opinion is that we should not spend time on IOS 11179 as a group. Regards, Martin. >I've looked into ISO 11179 very deeply in spots as I'm actively arguing for some of its data element naming/description best practices in another group I serve. The metadata standard I work on for this group has about 2,000 data elements (not data *values* such as "en-US", but *elements* such as "RFC 3066 Language Code"). Each element must be assigned a unique, descriptive name and XML symbol. The naming and unambiguous description of elements in large standards such as this can be very complicated and benefits from the conceptual metamodel, naming guidelines, and other best practices found in ISO 11179. > >RFC 3066 does not seem to approach the scope of this work at all as far as the number of data elements it contains. It seems to me that ISO 11179 is more appropriate for registries with a larger number of metadata types -- something on the IANA scale, not just RFC 3066. > >For the record, I have not read the administrative practices section as carefully as the data element naming, metamodel, and description work. It's all good stuff, but to me it seems aimed at a registry with a greater variety of data. > >FWIW, > >Karen Broome >Sony Pictures Entertainment #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 21:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtE8Y-0004fq-MW; Wed, 21 Jun 2006 21:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtE8X-0004fl-Hr for ltru@ietf.org; Wed, 21 Jun 2006 21:37:37 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtE8U-0007HW-SD for ltru@ietf.org; Wed, 21 Jun 2006 21:37:37 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5M1bSGW012868; Thu, 22 Jun 2006 10:37:28 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 29c1_a9f7fd66_018f_11db_9fb2_0014221fa3c9; Thu, 22 Jun 2006 10:37:27 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5M1bIji032375; Thu, 22 Jun 2006 10:37:27 +0900 Message-Id: <6.0.0.20.2.20060622102328.076eb700@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 22 Jun 2006 10:29:53 +0900 To: "Addison Phillips" , Mark Davis From: Martin Duerst Subject: Moving forward (Was: [Ltru] matching draft, issue 50) In-Reply-To: <20060616135307.GB32743@ccil.org> References: <6.0.0.20.2.20060616191343.076930d0@localhost> <20060616135307.GB32743@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat (or actually, shepherd hat) on] The IETF Last Call has ended. I'd like to move forward, at least with issues that seem to have reached consensus (mostly by nobody bringing up any opposing views, which is fine for the minor editorial issues that we are dealing with at the moment). The reply from John below is the only reply on issue 50 that I have seen on the list. Absent sudden disagreement, I would like to instruct the editors to prepare a new version of the draft with variant C for the Abstract, as well as with the other edits as described in http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, and a diff to the -14 version. Regards, Martin. At 22:53 06/06/16, John Cowan wrote: >Martin Duerst scripsit: > >> BTW, as a technical contributor, my preference is C before D before >> B before A. > >+1 > >-- >John Cowan cowan@ccil.org http://www.ccil.org/~cowan > Is it not written, "That which is written, is written"? #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 21:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEAU-00053W-DM; Wed, 21 Jun 2006 21:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEAS-00052p-OC for ltru@ietf.org; Wed, 21 Jun 2006 21:39:36 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtEAR-0007Pu-Mr for ltru@ietf.org; Wed, 21 Jun 2006 21:39:36 -0400 Received: by wr-out-0506.google.com with SMTP id i4so283802wra for ; Wed, 21 Jun 2006 18:39:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QCDZTHyciTqxis2mRYGtJ9PEQ35HVj+H4KuT1No8NBkw522b32PiEi3E3FIXG8wKo6eV/9acxHhNIicMe+W6D7PWfoz4fpIR6Q/wH25BEVdBi7MPxMJ535Ykdg9CFPeWSgzvlex25uh5o0dUq12IS1hTQTapsGtCJ/EIvZIIRgs= Received: by 10.64.204.6 with SMTP id b6mr1958655qbg; Wed, 21 Jun 2006 18:39:34 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Wed, 21 Jun 2006 18:39:34 -0700 (PDT) Message-ID: <30b660a20606211839r68e892eep584f85420b5539f7@mail.gmail.com> Date: Wed, 21 Jun 2006 18:39:34 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Last call: BCP 47 second part. In-Reply-To: <6.0.0.20.2.20060619152835.0769d880@localhost> MIME-Version: 1.0 References: <7.0.1.0.2.20060618165520.03b26178@online.fr> <6.0.0.20.2.20060619152835.0769d880@localhost> X-Google-Sender-Auth: 7261dfde6823de97 X-Spam-Score: 0.7 (/) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1219421848==" Errors-To: ltru-bounces@ietf.org --===============1219421848== Content-Type: multipart/alternative; boundary="----=_Part_355_31924196.1150940374828" ------=_Part_355_31924196.1150940374828 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBmdWxseSBhZ3JlZSB3aXRoIE1hcnRpbi4gTmljZSBqb2IuCgpNYXJrCgpPbiA2LzIxLzA2LCBN YXJ0aW4gRHVlcnN0IDxkdWVyc3RAaXQuYW95YW1hLmFjLmpwPiB3cm90ZToKPgo+IERlYXIgTFRS VSBtZW1iZXJzIChjYyBJRVRGIG1haWxpbmcgbGlzdCksCj4KPiBIZXJlIGFyZSBteSBjb21tZW50 cyBvbiBob3cgSSAoYXMgYSB0ZWNobmljYWwgY29udHJpYnV0b3IpCj4gcHJvcG9zZSB0byBhZGRy ZXNzIHRoZSBMYXN0IENhbGwgY29tbWVudHMgbWFkZSBiZWxvdy4KPiBJIGhvcGUgb3RoZXJzIGhh dmUgc29tZSBjb21tZW50cywgdG9vLgo+Cj4gQXQgMjM6NTYgMDYvMDYvMTgsIEpGQyAoSmVmc2V5 KSBNb3JmaW4gd3JvdGU6Cj4gPkRlYXIgSUVTRyBNZW1iZXJzLAo+ID4KPiA+MS4gIFRoZSBwcm9w b3NlZCBEcmFmdCBpcyBub3QgYWJvdXQgbWF0Y2hpbmcgKGl0IGlzIGFic3VyZCB0byBzYXkgdGhh dCBteQo+IEl0YWxpYW4gY2FuICJtYXRjaCIgeW91ciBKYXBhbmVzZSBpbiBvcmRlciBmb3IgdXMg dG8gdW5kZXJzdGFuZCBlYWNoIG90aGVyCj4gYmV0dGVyKS4gSXQgaXMgYWJvdXQgdXNpbmcgcGF0 dGVybiBtYXRjaGluZyB0ZWNobmlxdWVzIGluIG9yZGVyIHRvIGZpbHRlcgo+IGxpc3RzIGFnYWlu c3QgYSBsYW5ndGFnIHdpdGggdHdvIHJlc3VsdHMgKG1heCBvbmUgYW5zd2VyLCBubyBtYXgpIGFu ZCBpbiB0d28KPiBjYXNlcyAod2VsbCBmb3JtZWQgbGFuZ3RhZyBvciBub3QpLiBIb3dldmVyLCB0 aGUgd29yZGluZyBpcyBzdWNoIHRoYXQKPiB3aXRob3V0IGV4YW1wbGVzIGl0IGlzIGRpZmZpY3Vs dCB0byB1bmRlcnN0YW5kIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUKPiBwYXR0ZXJuIG1hdGNo aW5nIGZ1bmN0aW9uIHRoYXQgaXMgYmVpbmcgdXNlZCAtIGFuZCB0aGVyZWZvcmUgdGhlIHBvc3Np YmxlCj4gYXBwbGljYXRpb25zIGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgRHJhZnQuICBUaGUgYWxn b3JpdGhtIG9mIHRoaXMgZnVuY3Rpb24KPiBpcyB1bmRvY3VtZW50ZWQgYW5kIHRoZXJlIGlzIG5v IG9ibGlnYXRpb24gdG8gZG9jdW1lbnQgaXQsIHdoYXQgbWF5IGxlYWQgdG8KPiBibG9ja2luZyBj b25mbGljdHMgaWYgdHdvIGZpbHRlcnMgbWF5IGhhdmUgdG8gaW50ZXJvcGVyYXRlLiBUaGlzIHBy b3Bvc2l0aW9uCj4gaXMgTk9UIHNjYWxhYmxlIGFuZCBkb2VzIG5vdCBpbnRlbnQgdG8gYmUgc2Nh bGFibGUuCj4KPiBUaGUgbWF0Y2hpbmcgZHJhZnQgb2YgY291cnNlIG1ha2VzIHN1cmUgdGhhdCAi amEiIGFuZCAiaXQiIGRvIG5vdAo+IG1hdGNoLiBOb3RoaW5nIGFic3VyZCBoYXBwZW5pbmcgdGhl cmUuIEFsc28sIHdoYXQgdGhlIGRyYWZ0IGFjdHVhbGx5Cj4gZGVzY3JpYmVzIGlzIG1hdGNoaW5n IGxhbmd1YWdlIHRhZ3MgYWdhaW5zdCBsYW5ndWFnZSByYW5nZXM7IHRoZXJlCj4gYXJlIHRocmVl IG1hdGNoaW5nIHZhcmlhbnRzLCB0d28gZm9yIGZpbHRlcmluZyBhbmQgb25lIGZvciBsb29rdXAu Cj4KPiBTb21lIG9mIHRoZSBtYXRjaGluZyBwcm9jZWR1cmVzIGluZGVlZCBoYXZlIHRvIGJlIHJl YWQgY2FyZWZ1bGx5Lgo+IEJ1dCB0aGUgV0cgbWFkZSBldmVyeSBhdHRlbXB0IHRvIGRlc2NyaWJl IHRoZW0gY2FyZWZ1bGx5LCBnb2luZwo+IHRocm91Z2ggc2V2ZXJhbCBpdGVyYXRpb25zLiBBbmQg d2UgcHJvdmlkZSBleGFtcGxlcywgdG9vLgo+Cj4gVGhlIG1haW4gYXBwbGljYXRpb25zIGVudmlz aW9uZWQgYnkgdGhlIGRyYWZ0IGFyZSBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LAo+IHRoZXkgYXJl IHRoaW5ncyBzdWNoIGFzIHNlbGVjdGlvbiBvZiBkb2N1bWVudHMgKGUuZy4gd2hlbiBzZWFyY2hp bmcpCj4gb3IgZG9jdW1lbnQgcGllY2VzIChlLmcuIGZvciBzdHlsaW5nKSBpbiB0aGUgY2FzZSBv ZiBmaWx0ZXJpbmcgYW5kCj4gZmluZGluZyB0aGUgYmVzdCBtYXRjaCB0byByZXR1cm4gZG9jdW1l bnRzIG9yIGRvY3VtZW50IGZyYWdtZW50cwo+IGluIHRoZSBjYXNlIG9mIGxvb2t1cCAodGhlIHBy b3RvdHlwaWNhbCBleGFtcGxlIGJlaW5nIEhUVFAgbGFuZ3VhZ2UKPiBuZWdvdGlhdGlvbikuCj4K PiBBcyBmb3IgY29uZmxpY3RpbmcgZmlsdGVycywgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhh dCB0d28gZmlsdGVycwo+IChlLmcuIGluIHR3byBkaWZmZXJlbnQgcHJvdG9jb2xzKSBwcm9kdWNl IGV4YWN0bHkgdGhlIHNhbWUgcmVzdWx0Lgo+IERpZmZlcmVudCBwcm90b2NvbHMgbWF5IGhhdmUg ZGlmZmVyZW50IG5lZWRzLiBUaGF0J3Mgd2h5IHRoZSBkcmFmdAo+IGxlYXZlcyBzb21lIHNwZWNp ZmljcyBmb3IgYSBwYXJ0aWN1bGFyIHByb3RvY29sIHRvIGJlIGRlY2lkZWQuCj4KPiBBcyBhIHJl c3VsdCwgSSBkbyBub3Qgc2VlIGFueXRoaW5nIGluIGNvbW1lbnQgMS4gdGhhdCB3b3VsZCBuZWVk Cj4gYWRkcmVzc2luZyBpbiB0aGUgY3VycmVudCBkcmFmdC4KPgo+Cj4gPjIuIEVpdGhlciBSRkMg MzA2NiBCaXMgaXMgd2VsbCB3cml0dGVuICh3aGF0IEkgdGhpbmsgd2UgYWNoaWV2ZWQgaWYKPiBz dHJpY3RseSBsaW1pdGVkIHRvIHRoZSBJbnRlcm5hdGlvbmFsaXplZCBBU0NJSSBJbnRlcm5ldCkg YW5kIHdlbGwgYXBwbGllZAo+ICh3aGF0IEkgY2FuIHNlZSB0aGF0IGl0IGlzIG5vdCB0aGUgY2Fz ZTogdGhlIHJldmlldyBtZWNoYW5pc20gZG9lcyBub3QKPiByZXNwZWN0IFJGQyAzMDY2IEJpcykg YW5kIHRoZSBmaWx0ZXJpbmcgaXMgYWxyZWFkeSBidWlsdC1pbiwgYW5kIHRoZQo+IGZ1bmN0aW9u YWwgc3RyYXRlZ2llcyBhcmUgdG8gYmUgc3BlY2lmaWMgdG8gYXBwbGljYXRpb25zIGFuZCBwcm90 b2NvbHMuIE9yCj4gdGhhdCBEcmFmdCwgd2hpY2ggZG9lcyBub3Qgc2VlayB0byBmaXJzdCBlbnN1 cmUgdGhhdCBsYW5ndGFncyByZXNwZWN0IFJGQwo+IDMwNjYgQmlzIChpLmUuIGJlaW5nIHdlbGwg Zm9ybWVkIG9yIGNvcnJlY3RlZCBpbiBvcmRlciB0byBiZWNvbWUgd2VsbAo+IGZvcm1lZCksIGlz IGEgbmVnYXRpb24gb2YgUkZDIDMwNjYgQmlzLiBJIHRoaW5rIHRoYXQgYXV0aG9ycyBoYWQgZmls dGVyaW5nCj4gaW4gbWluZCAoaXQgd2FzIHRoZSBhcGV4IG9mIHRoZSBmaXJzdCB1bmlxdWUgZG9j dW1lbnQpIGFuZCBkaWQgbm90IHJlYWxpc2UKPiB0aGF0IHRoZSB3b3JrIGFjaGlldmVkIGluIGNs ZWFuaW5nIHRoZSBmaXJzdCBwYXJ0IG1hZGUgaXRzIGNvcnJlY3Rpb24gYnkgdGhlCj4gc2Vjb25k IHBhcnQgbm90IG5lY2Vzc2FyeSBhbnltb3JlLiBUaGF0IGlzIGlmIHRoZSB3aG9sZSBwdXJwb3Nl IHdhcyBub3QgYQo+IG5vbiBkb2N1bWVudGVkIHVzZSBvZiB0aGUgZmlsdGVyaW5nICh1c2VycyBt YXNzIHByb2ZpbGluZykuIElmIGl0IHdhcyBub3QKPiB0aGUgd2hvbGUgZG9jdW1lbnQgY2FuIGJl IHdyaXR0ZW4gYXMgIm1ha2Ugc3VyZSBsYW5ndGFncyBhcmUgd2VsbCBmb3JtZWQgYW5kCj4gZmVl ZCB0aGVtIG9uIHRoZSBwYXR0ZXJuCj4gbWF0Y2hpbmcgZnVuY3Rpb24gb2YgeW91ciBhcHBsaWNh dGlvbi9wcm90b2NvbCB0byBvYnRhaW4gdGhlIHJlc3VsdHMgaXQKPiBuZWVkcyBhbG9uZyB5b3Vy IGxhbmd1YWdlIG1hbmFnZW1lbnQgc3RyYXRlZ3kiLgo+Cj4gVGhlIGNvbW1lbnRlciBzZWVtcyB0 byBjbGFpbSB0aGF0IGRyYWZ0LWlldGYtbHRydS1tYXRjaGluZyBjb25mbGljdHMgd2l0aAo+IGRy YWZ0LWlldGYtbHRydS1yZWdpc3RyeSAoaGVyZSBjYWxsZWQgUkZDIDMwNjZiaXMpIGJlY2F1c2Ug dGhlIGxhdGVyCj4gZGVmaW5lcyB3ZWxsLWZvcm1lZCB0YWdzIHdoaWxlIHRoZSBmb3JtZXIgZG9l cyBub3QgcmVxdWlyZSB3ZWxsLWZvcm1lZAo+IHRhZ3MuIFRoZSByZWFzb24gZm9yIG5vdCByZXF1 aXJpbmcgY2hlY2tpbmcgZm9yIHdlbGwtZm9ybWVkIHRhZ3Mgd2hlbgo+IG1hdGNoaW5nIHdhcyBk aXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIFdHLiBUaGVyZSBpcyBhIHZlcnkgY2xlYXIKPiBy ZWFzb246Cj4gcmVxdWlyaW5nIHRoaXMgd291bGQgcmVxdWlyZSB0byBjaGVjayB0aGUgSUFOQSBs YW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnksCj4gcG90ZW50aWFsbHkgZm9yIGV2ZXJ5IG1hdGNoaW5n IG9wZXJhdGlvbiwgd2hpY2ggd2FzIGNvbnNpZGVyZWQKPiBvcGVyYXRpb25hbGx5Cj4gaW5mZWFz aWJsZS4gSXQgd291bGQgYWxzbyBiZSBhbiB1bm5lY2Vzc2FyeSBwZXJmb3JtYW5jZSBwdW5pc2ht ZW50IGZvcgo+IHRob3NlIHdobyBhY3R1YWxseSB1c2Ugd2VsbC1mb3JtZWQgdGFncy4gSW4gZ2Vu ZXJhbCwgbm9uLXdlbGxmb3JtZWQKPiB0YWdzIG9yIHJhbmdlcyB3aWxsIHNpbXBseSBub3QgbWF0 Y2ggYW55dGhpbmcsIHdoaWNoIGlzIGp1c3QgZmluZS4KPgo+IFRoZSBjb21tZW50ZXIgaXMgY29y cmVjdCBpbiB0aGF0IHRoZXJlIGlzIG5vIGFic29sdXRlIG5lZWQgZm9yIHRoaXMgZHJhZnQ7Cj4g ZWFjaCBwcm90b2NvbCBvciBmb3JtYXQgY291bGQgY29tZSB1cCB3aXRoIGl0J3Mgb3duIHdheSBv ZiBtYXRjaGluZwo+IGxhbmd1YWdlIHRhZ3MuIEFmdGVyIGFsbCwgUkZDIDMwNjZiaXMgZGVmaW5l cyBob3cgdGhlc2UgdGFncyBhcmUgYnVpbHQsCj4gYW5kICh0byBhIGNlcnRhaW4gZXh0ZW50KSB3 aGF0IHRoZXkgbWVhbi4gSG93ZXZlciwgSSBjb25zaWRlciB0aGUgY3VycmVudAo+IGRyYWZ0IHZh bHVhYmxlIGJlY2F1c2UgaXQgaGVscHMgcHJvdG9jb2wvZm9ybWF0IGRlc2lnbmVycywgd2hvIGlu IGdlbmVyYWwKPiBhcmUgbm90IGV4cGVydHMgb24gbGFuZ3VhZ2UgdGFncyBhbmQgbGFuZ3VhZ2Ug bWF0Y2hpbmcsIHRvIGNob29zZSB0aGUKPiByaWdodCBraW5kIG9mIG1hdGNoaW5nIHNjaGVtZS4g QWxzbywgb25lIG1hdGNoaW5nIHNjaGVtZSB3YXMgYWxyZWFkeQo+IGRlc2NyaWJlZCBpbiBSRkMg MzA2NiwgYW5kIHNvIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBvYnNvbGV0ZQo+IFJGQyAzMDY2 IHdpdGhvdXQgdGhpcyBkcmFmdC4KPgo+IEkgdGhlcmVmb3JlIGRvbid0IHNlZSBhbnkgY2hhbmdl IHRoYXQgd291bGQgYmUgbmVlZGVkIGluIHRoZSBjdXJyZW50Cj4gZHJhZnQgdG8gYWRkcmVzcyBj b21tZW50IDIuCj4KPiA+My4gIioiIHJlc3RyaWN0aW9ucyBpbiB0aGUgcGF0dGVybiBtYXRjaGlu ZyBmdW5jdGlvbiBjYW4gaGFyZGx5IGJlCj4gdW5kZXJzdG9vZCB3aXRob3V0IHNldmVyYWwgZXhh bXBsZXMuIFRoZXkgYWRkIHVzYWdlIGxpbWl0YXRpb25zIHRvIHRoZSBSRkMKPiAzMDY2IEJpcyBm b3JtYXQsIHdoZXJlIHRoZXkgc2hvdWxkIGJlIGRvY3VtZW50ZWQg44OlIG9yIHRoZSBEcmFmdCBj YW5ub3QgYmUKPiBwYXJ0IG9mIEJDUCA0Ny4gVGhpcyBjZXJ0YWlubHkgYmVsb25ncyB0byB0aGUg bGFuZ3VhZ2UgY29uc3RyYWluaW5nIHN0cmF0ZWd5Cj4gb2YgdGhlIFdHLUxUUlUgYWZmaW5pdHkg Z3JvdXAgYW5kIHRvIHRoZSBpbnRlcmVzdHMgYSBjby1DaGFpciByZWNlbnRseQo+IGRvY3VtZW50 ZWQuIEJ1dCB0aGlzIGlzIHVuYWNjZXB0YWJsZSB0byBtb3N0IHVzZXJzLCBldmVuIGlmIGl0IGlz IGNlcnRhaW5seQo+IGZhdm91cmFibGUgdG8gYSBuYXRpb25hbCBzdHJhdGVneSBhbmQgdG8gdGhl IG1lbWJlcnMgb2YgYSBnaXZlbiBjb25zb3J0aXVtLgo+IEkgdGhlcmVmb3JlIHN1Ym1pdCB0aGF0 IHRoZSBJRVNHIE1lbWJlcnMgd2hvIGFyZSBjaXRpemVucyBvZiB0aGF0IG5hdGlvbiwgb3IKPiBt ZW1iZXJzLCBvciBlbXBsb3llZXMgb2YgdGhlIG1lbWJlcnMgb2YgdGhhdCBjb21tZXJjaWFsIGNv bnNvcnRpdW0gaGF2ZSBhCj4gQ09JLgo+Cj4gVGhlcmUgYXJlIG5vIHJlc3RyaWN0aW9ucyBvbiB0 aGUgdXNlIG9mICIqIiBpbiBsYW5ndWFnZSByYW5nZXMuCj4gVGhlcmUgaXMgYSB2ZXJ5IHNwZWNp ZmljIHRyZWF0bWVudCBvZiAiKiIgd2lsZGNhcmQgY29tcG9uZW50cyBpbgo+IGxhbmd1YWdlIHJh bmdlcyBmb3IgZXh0ZW5kZWQgZmlsdGVyaW5nLiBUaGUgYWN0dWFsIGFsZ29yaXRobSBpbgo+IHRo ZSBkcmFmdCBpcyBkZXNjcmliZWQgY2FyZWZ1bGx5LCBhbmQgYW4gZXhwbGFuYXRpb24gZm9yIHdo eSBpdCBpcwo+IHRoZSB3YXkgaXQgaXMgaXMgZ2l2ZW4uIFRoaXMgbWF0Y2hpbmcgYWxnb3JpdGht IGRvZXMgbm90IGFkZAo+IGFueSB1c2FnZSBsaW1pdGF0aW9ucyB0byBSRkMgMzA2NmJpcy4gT24g dGhlIGNvbnRyYXJ5LCBpdCB3YXMKPiBjYXJlZnVsbHkgZGVzaWduZWQgdG8gd29yayB3ZWxsIHRv Z2V0aGVyIHdpdGggUkZDIDMwNjZiaXMuCj4KPiBJIGRvIG5vdCBrbm93IG9mIGFueSBjb25jcmV0 ZSBleGFtcGxlIHdoZXJlIHRoZSBtYXRjaGluZyBiZWhhdmlvcgo+IHdvdWxkIGJlIHVuYWNjZXB0 YWJsZS4gQW55IGNsYWltcyB0aGF0IGl0IGlzICJ1bmFjY2VwdGFibGUgdG8KPiBtb3N0IHVzZXJz IiwgYXJlIHRoZXJlZm9yZSwgaW4gbXkgdmlldywganVzdCBtYWRlIHVwIG91dCBvZiB0aGluIGFp ci4KPgo+IEFsc28sIEkgaGF2ZSBubyBpZGVhIHdoYXQgaXMgbWVhbnQgYnkgImxhbmd1YWdlLWNv bnN0cmFpbmluZyBzdHJhdGVneSIuCj4gSWYgYW55Ym9keSB3YW50ZWQgdG8gcmVzdHJpY3QgdGhl IHVzZSBvZiBjZXJ0YWluIGxhbmd1YWdlcyBpbiBjZXJ0YWluCj4gcGFydHMgb2YgdGhlIEludGVy bmV0LCB0aGV5IGNvdWxkIGVhc2lseSBhbHJlYWR5IGhhdmUgZG9uZSB0aGF0IGJhc2VkCj4gb24g UkZDIDMwNjYsIG9yIGNvdWxkIGRvIGJhc2VkIG9uIFJGQyAzMDY2YmlzLCBvciBldmVuIGp1c3Qg YmFzZWQgb24KPiBzdGF0aXN0aWNhbCBhbmFseXNpcyBvZiB0aGUgYWN0dWFsIGNvbnRlbnQgdHJh bnNtaXR0ZWQgKHdpdGggdGVjaG5pcXVlcwo+IHN1Y2ggYXMgdHJpZ3JhbXMpLiBBbmQgY2VydGFp bmx5IG5vYm9keSB3aG8gYWN0dWFsbHkgd2FudGVkIHRvIGRvIHN1Y2gKPiBhIHRoaW5nIHdvdWxk IGFzayBmb3IgYW4gUkZDIG9yIG90aGVyIGtpbmQgb2Ygc3RhbmRhcmQgdG8gdHJ5IHRvCj4gbGVn aXRpbWF0ZSBzdWNoIHJlc3RyaWN0aW9ucywgbm9yIHdvdWxkIEkgaG9wZSBhbnlib2R5IHdvdWxk IGNvbmRvbmUKPiBzdWNoIGJlaGF2aW9yIGp1c3QgYmVjYXVzZSBpdCB3b3VsZCBtYWtlIHVzZSBv ZiBhbiBSRkMuCj4KPiBBcyBhIHJlc3VsdCwgSSBkb24ndCB0aGluayB0aGF0IGFueXRoaW5nIG5l ZWRzIHRvIGJlIGRvbmUgdG8gYWRkcmVzcwo+IGNvbW1lbnRzIDMuCj4KPiA+NC4gQWxsIHRoZSBh Ym92ZSAgbWVhbnMgdGhhdCB0aGUgRHJhZnQgaXMgdXNlZnVsIGluIGF0IGxlYXN0IHR3bwo+IGNp cmN1bXN0YW5jZXM6Cj4gPiAgIC0gaWYgdGhlIGxhbmd0YWdzIGFyZSBub3Qgd2VsbCBmb3JtZWQg b3IgZG8gbm90IHJlc3BlY3QgdGhlIHByaW5jaXBsZXMKPiBvZiBJU08gNjM5LTQgYW5kL29yIFJG QyAzMDY2IEJpcy4KPiA+ICAgLSBpZiB0aGUgbGFuZ3RhZ3MgYXJlIHVzZWQgZm9yIG90aGVyIHB1 cnBvc2VzIHRoYXQgYXJlIHVuZG9jdW1lbnRlZCBhdAo+IHRoZSBXRy1MVFJVIENoYXJ0ZXIuCj4g PlRoZXNlIGNpcmN1bXN0YW5jZXMgc2hvdWxkIGJlIGRvY3VtZW50ZWQuCj4KPiBJU08gNjM5LTQg aXMgc3RpbGwgYmVpbmcgd29ya2VkIG9uLiBUaGUgcG9zc2liaWxpdHkgb2YgdXNpbmcKPiBub24t d2VsbGZvcm1lZAo+IHRhZ3MgaXMgbm90IHNvbWV0aGluZyB0aGUgZHJhZnQgaXMgZGVzaWduZWQg dG8gZG87IGl0IGlzIGp1c3QgYQo+IGNvbnNlcXVlbmNlCj4gb2Ygbm90IHJlcXVpcmluZyBjaGVj a2luZyBmb3Igd2VsbC1mb3JtZWRuZXNzICh0byBhdm9pZCBvcGVyYXRpb25hbAo+IHByb2JsZW1z KS4KPiBUaGUgZHJhZnQgZXhwbGljaXRseSBzYXlzIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0byBj aGVjayBmb3IKPiB3ZWxsLWZvcm1lZG5lc3MsCj4gc28gSSBkb24ndCBzZWUgd2hhdCB3b3VsZCBu ZWVkIHRvIGJlIGRvY3VtZW50ZWQgZnVydGhlci4KPgo+IFRoZSBkcmFmdCwgbGlrZSBtb3N0IElF VEYgd29yaywgbWVudGlvbnMgcG9zc2libGUgdXNlcyBvZiB0aGUgdGVjaG5vbG9neSwKPiBpbiBw YXJ0aWN1bGFyIGFzIGV4YW1wbGVzIHRvIGV4cGxhaW4gZGVzaWduIGRlY2lzaW9ucyBvciBjaG9p Y2VzIG9mCj4gb3B0aW9ucwo+IGZvciB0aGUgdXNlcnMgKGluIHRoZSBjYXNlIG9mIHRoZSBkcmFm dCwgdGhlIGRpcmVjdCB1c2VycyBhcmUgcHJvdG9jb2xzCj4gYW5kIGZvcm1hdHMpLiBBbnkgYXR0 ZW1wdCB0byBkZXNjcmliZSBhbnkgYW5kIGFsbCBwb3NzaWJsZSB1c2VzIGZvciBhCj4gdGVjaG5v bG9neSBpbnZhcmlhYmx5IGZhaWwsIGFuZCBzbyBzaG91bGRuJ3QgYmUgYXR0ZW1wdGVkIGluIHRo ZSBmaXJzdAo+IHBsYWNlLgo+Cj4gSSB0aGVyZWZvcmUgZG9uJ3Qgc2VlIGFueSBjaGFuZ2UgdGhh dCB3b3VsZCBiZSBuZWNlc3NhcnkgYmFzZWQgb24KPiBjb21tZW50IDQuCj4KPiA+NS4gVGhlIHNl Y3VyaXR5IHNlY3Rpb24gc2hvdWxkIG1lbnRpb24gdGhhdCB0aGlzIERhZnQgZW5jb3VyYWdlcyB0 aGUKPiBkaXNyZXNwZWN0IG9mIHRoZSBSRkMgMzA2NiBCaXMgZm9ybWF0IGFuZCBmdXJ0aGVyIGFz c2lzdHMgZGFuZ2Vyb3VzIHByb2plY3RzCj4gdGhhdCB0aGUgSUVURiBoYXMgcmVmdXNlZCB0byBt ZW50aW9uIGluIFJGQyAzMDY2IEJpcywgc3VjaCBhcyBsaW5ndWFsLAo+IGN1bHR1cmFsLCByYWNp YWwsIGFuZCByZWxpZ2lvdXMgcHJvZmlsaW5nIHRocm91Z2ggcmV0cm8tbWV0YS1zcGFtICgiSSBr bm93Cj4gd2hvIHlvdSBhcmUgdGhyb3VnaCB3aGljaCBsYW5ndGFncyB5b3UgYXJlIG5vdCBhd2Fy ZSB0aGF0IHlvdSByZXNwb25kIHRvIiksCj4gdHdvLXRpZXIgSW50ZXJuZXQgYmFzZWQgdXBvbiB0 aGUgbGluZ3VhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHVzZXJzIGFuZAo+IHRoZWlyIHN1cHBv c2VkIG1hcmtldCB2YWx1ZSwgbGFjayBvZiBjb25mb3JtYW5jZSB0byBJU08gMTExNzksIHdoaWNo IG1heQo+IGxlYWQgdGhlIElFVEYsIHN0YWtlaG9sZGVycywgYW5kIHVzZXJzIHRvIGluYWRlcXVh dGUsIGNvc3RseSwgYW5kIGRlbGF5aW5nCj4gc3RyYXRlZ2llcyBvciB0byBjb25mbGljdHMgd2l0 aCB0aGUgTXVsdGlsaW5ndWFsIEludGVybmV0IC0gYXMgaW4gdGhlIHNhZAo+IERvUyBhZ2FpbnN0 IHRoZSBsZWFkaW5nIGVjb25vbWljIGxhbmd1YWdlICgiZW4tRVUiKSAtIG9yIHRvIGxlZ2FsIGFj Y2Vzcwo+IGJhbnMgYnkgZGVtb2NyYXRpYyBvciBwcml2YWN5IG9yaWVudGVkIGNvdW50cmllcy4g QWxsIG9mIHRoaXMgbGVuZHMgaXRzZWxmCj4gdG8gaW5jZW50aXZlcyBmb3IgYW4gSW50ZXJuZXQg ZnJhZ21lbnRhdGlvbi4KPgo+IEFzIGV4cGxhaW5lZCBhYm92ZSwgdGhlcmUgaXMgbm8gZGlzcmVz cGVjdCBmb3IgUkZDIDMwNjYgYmlzIGZvcm1hdHMsIGp1c3QKPiBvcGVyYXRpb25hbAo+IGNvbnNp ZGVyYXRpb25zLiBBbHNvLCB0aGUgZHJhZnQgZG9lcyBub3QgYXNzaXN0IGFueSBvZiB0aGUgJ2Rh bmdlcm91cwo+IHByb2plY3RzJyBtZW50aW9uZWQKPiBhYm92ZTsgYW55IG9mIHRoZXNlIHByb2pl Y3RzIGFyZSwgaWYgc29tZSBlbnRpdHkgaXMgZGV0ZXJtaW5lZCB0byBkbyB0aGVtCj4gYW5kCj4g aGFzIHRoZSBuZWNlc3NhcnkgYWNjZXNzLCBlYXNpbHkgcG9zc2libGUgd2l0aCB2YXJpb3VzIG90 aGVyIG1lYW5zLgo+Cj4gVGhlIHByb2JsZW0gdGhhdCBSRkMgMzA2NmJpcyBkb2VzIG5vdCBhbGxv dyBlbi1FVSBpcyBhIHByb2JsZW0gb2YgUkZDCj4gMzA2NmJpcywKPiBhbmQgbWF5IGhhdmUgdG8g YmUgYWRkcmVzc2VkIGluIGEgZnV0dXJlIHJldmlzaW9uLCBidXQgZG9lcyBub3QgYWZmZWN0IHRo ZQo+IG1hdGNoaW5nIGRyYWZ0IG5vdyBpbiBsYXN0IGNhbGwuCj4KPiBBZ2FpbiwgSSBkb24ndCBz ZWUgYW55dGhpbmcgaGVyZSB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgY2hhbmdlZCBpbiB0aGUKPiBj dXJyZW50IGRyYWZ0IHRvIGFkZHJlc3MgdGhpcyBjb21tZW50Lgo+Cj4KPiA+Ni4gQXMgZmFyIGFz IEkgdW5kZXJzdGFuZCwgdHdvIERyYWZ0IGNvbXBsaWFudCBmaWx0ZXJzIG1heSByZXN1bHQgaW4K PiBkaWZmZXJlbnQgcmVzcG9uc2VzIGZvciB0aGUgc2FtZSBmaWx0ZXJpbmcgbGlzdCBhbmQgZG9j dW1lbnQuIE15IGNvbmNlcm4gaXMKPiB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgcHJvcG9z ZWQgQkNQIDQ3IHdpdGggTXVsdGlsaW5ndWFsIEludGVybmV0Cj4gcmVnaXN0cmllcywgdGFncywg ZXRjLiBUaGlzIGludGVyb3BlcmFiaWxpdHkgaXMgbm90IGVuc3VyZWQg44OlIGFuZCB0aGVyZSBp cwo+IG5vIHByb3NwZWN0IHRvIHNlZSBpdCBpbnN1cmVkIGFzIGl0IGlzIHB1cnBvc2VseSBpZ25v cmVkIGJ5IGF1dGhvcnMuIFRoaXMKPiByZXByZXNlbnRzIG5vIGluY2VudGl2ZSBmb3IgZGV2ZWxv cGVycy4KPgo+IFRoZSB0aHJlZSBtYXRjaGluZyBzY2hlbWVzIGRlc2NyaWJlZCBpbiB0aGUgZHJh ZnQgYWxsIGNvbWUgd2l0aCBhIHNtYWxsCj4gbnVtYmVyCj4gb2Ygb3B0aW9ucy4gSW4gdGhpcyBz ZW5zZSwgaXQgaXMgZS5nLiBwb3NzaWJsZSB0aGF0IHR3byBkaWZmZXJlbnQKPiBwcm90b2NvbHMs Cj4gaGF2aW5nIGNob29zZW4gZGlmZmVyZW50IG9wdGlvbnMsIHdpbGwgbGVhZCB0byBkaWZmZXJl bnQgcmVzdWx0cy4gQW4KPiBleGFtcGxlCj4gd291bGQgYmUgYW4gSFRUUCBzZXJ2ZXIgc2Vydmlu ZyBhIGRvY3VtZW50IGluIGEgZGlmZmVyZW50IGxhbmd1YWdlIHRoYW4gYQo+IGNvcnJlc3BvbmRp bmcgRlRQIHNlcnZlciAoYXNzdW1pbmcgc29tZWJvZHkgYWRkZWQgbGFuZ3VhZ2UgbmVnb3RpYXRp b24gdG8KPiBGVFApIGZvciByZXF1ZXN0cyB3aXRoIHRoZSBzYW1lIGxhbmd1YWdlIHByaW9yaXR5 IGxpc3QuIEJ1dCBhcyBzdWNoIGEKPiBzZXR1cAo+IGlzIGhpZ2hseSBmaWN0aW9uYWwsIGFuZCB0 aGUgdHdvIHNlcnZlcnMgYXJlIGNvbmZpZ3VyZWQgc2VwYXJhdGVseSBhbnl3YXksCj4gaGF2aW5n IGRpZmZlcmVudCByZXN1bHRzIHNpbXBseSBiZWNhdXNlIG9mIGRpZmZlcmVudCBjb25maWd1cmF0 aW9uIChyYXRoZXIKPiB0aGFuIGRpZmZlcmVudCBsYW5ndWFnZSBtYXRjaGluZyksIG9yIHR3ZWFr aW5nIHRoZSBjb25maWd1cmF0aW9uIHRvIG1ha2UKPiB0aGUgcmVzdWx0cyBtYXRjaCwgYXJlIGJv dGggcG9zc2libGUuIFNvIHRoaXMga2luZCBvZiBpbnRlcm9wZXJhYmlsaXR5IGlzCj4gbm90IG9m IGltcG9ydGFuY2UgaW4gcHJhY3RpY2UuCj4KPiBBbHNvLCBpdCBpcyBkaWZmaWN1bHQgdG8gdHJ5 IHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggc29tZXRoaW5nCj4gY2FsbGVkICdNdWx0 aWxpbmd1YWwgSW50ZXJuZXQgcmVnaXN0cmllcycgd2hlbiBzdWNoIGEgdGhpbmcgZG9lcyBuZWl0 aGVyCj4gZXhpc3Qgb24gcGFwZXIgbm9yIGluIHByYWN0aWNlLgo+Cj4gU28gdGhlcmUgaXMgbm90 aGluZyBpbiBjb21tZW50IDYgdGhhdCB3b3VsZCByZXF1aXJlIGFueSBjaGFuZ2VzCj4gaW4gdGhl IGN1cnJlbnQgZHJhZnQuCj4KPgo+ID43LiBUaGUgYWNrbm93bGVkZ2VtZW50IHNlY3Rpb24gbW9z dGx5IHF1b3RlIHRob3NlIHdobyBjb250cmlidXRlZCB0byB0aGUKPiBwcmUtV0ctTFRSVSBkb2N1 bWVudCAodGhlIHRocmVlIFdHLUxUUlUgRHJhZnQgZXhpc3RlZCBwcmlvciB0byB0aGUgY3JlYXRp b24KPiBvZiB0aGUgV0cgd2hpY2ggbmV2ZXIgc3R1ZGllZCBhbmQgdHJpZWQgdG8gY29uZm9ybSB0 byBpdHMgQ2hhcnRlcikuIFRoaXMgaXMKPiB0aGUgcHJpdmlsZWdlIG9mIGF1dGhvcnMgdG8gcXVv dGUgd2hvIHN1cHBvcnRlZCB0aGVtIGJlc3QuIEhvd2V2ZXIsIGluIHRoaXMKPiBjYXNlIHRoZSBk b2N1bWVudCB3YXMgY29uc2lkZXJhYmx5IGNsZWFuZWQgdGhyb3VnaCB0aGUgdG91Z2ggbGlmZSBv ZiB0aGUgV0cuCj4gQWxzbywgbW9zdCBvZiB0aGUgbmFtZXMgYmVpbmcgcXVvdGVkIGFyZSB3aWRl bHkga25vd24gYXMgYmVsb25naW5nIHRvIGEKPiBub24tSUVURiBhZmZpbml0eSBncm91cCwgd2hh dCBlbmZvcmNlcyB0aGUgZXh0ZXJuYWwgdW5kZXJzdGFuZGluZyB0aGF0IEJDUAo+IDQ3IGRvY3Vt ZW50cyBhcmUgYWN0dWFsbHkgbm90IElFVEYgZG9jdW1lbnRzLiBUaGlzIHdpbGwgbW9zdCBwcm9i YWJseSBsaW1pdAo+IHRoZWlyIGNvbnNpZGVyYXRpb24uIEFmdGVyIG9uZSB5ZWFyIG9mIHRvdWdo IGRlYmF0ZXMgSSBjYW4gdGVzdGlmeSB0aGVzZSwKPiBnb29kIG9yIG5vdCwgdGhyZWUgZG9jdW1l bnRzIGFyZSBJRVRGIGRvY3VtZW50cyBmb3IgdGhlIEludGVybmF0aW9uYWxpemVkCj4gQVNDSUkg SW50ZXJuZXQuIEkgbGlzdGVkIHRoZSBuYW1lcyBJIGNvbnNpZGVyIG1pc3NpbmcgaW4gYSBMYXN0 IEMgYWxsIG1haWwuCj4gPgo+ID5BdXRob3JzIGVpdGhlciBkaWQgbm90IHJlYWQgaXQgb3IgYXJl IGtlZXBpbmcgaGFyYXNzaW5nIG1lLCBzaW5jZSB0aGV5Cj4gY29udGludWUgYXNraW5nIGZvciBh biBpbnB1dC4gSSBxdW90ZSBteSBtYWlsOiAiZXZlcnkgY29udHJpYnV0aW9uIGNhbiBiZSBhCj4g a2V5IHN0b25lIGluIHRoZSBmaW5hbCBjb25zdHJ1Y3QuIFRoYXQgcGVvcGxlIGxpa2UgTWljaGFl bCBFdmVyc29uLCBOZWQKPiBGcmVlZCwgTGVlIEdpbGxhbSwgSm9obiBDLiBLbGVuc2luLCBGZWxp eCBTYXNha2ksIE1pY2hlbCBTdWlnbmFyZCwgYW5kIFRleAo+IFRleGluIGFyZSBub3QgcXVvdHRl ZCBzZWVtcyBvZGQuIE90aGVycyBsaWtlIFNjb3R0IEhvbGxlbmJlY2sgYW5kIFNhbQo+IEhhcnRt YW4gcmVhbGx5IGhlbHBlZC4gV2hhdCBhYm91dCBLYXJlbiBCcm9vbWUsIE0uVC4gQ2FycmFzY28g QmVuaXRleiwgTi4KPiBQaWVyY2VpPyBJbnB1dHMgb3IgaGVscCBmcm9tIEJyaWFuIENhcnBlbnRl ciwgVGVkIEhhcmRpZSwgRHlsYW4gTi4gUGllcmNlCj4gYXJlIHJlYWwuIi4gSSBkbyBub3QgYXNr IG15IG5hbWUgdG8gYmUgbGlzdGVkIHRoZXJlIHNpbmNlIEkga25vdyAiaXQgaXMgbm90Cj4gW3Ro ZV0gaW50ZXJlc3QgW29mIHNvbWUgaW4gdGhlIGxpc3RdIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBb bXkgb3duXSBuYW1lIi4KPiA+Cj4gPk9yIHdvdWxkIHRoYXQgbWVhbiB0aGF0IHRoZSBJRVRGIGRv ZXMgbm90IHJlYWxseSBiYWNrIHRoaXMgZGVsaXZlcmFibGU/Cj4gVGhlIHF1ZXN0aW9uIGhlcmUg aXM6IGRvZXMgdGhlIElFVEYgd2FudHMgdG8gaW5mbHVlbmNlIHRoZSB3b3JsZCAoUkZDIDM5MzUp LAo+IGRvY3VtZW50IHRoZSBJbnRlcm5hdGlvbmFsaXNlZCBBU0NJSSBJbnRlcm5ldCwgb3Igc2Vy dmUgdGhlIE11bHRpbGluZ3VhbAo+IEludGVybmV0IGRldmVsb3BtZW50LiBNYW55IHdvdWxkIGxp a2UgdG8ga25vdy4KPgo+IFRoZSBjbGFpbSB0aGF0IHRoZSBhY2tub3dsZWRnZW1lbnQgc2VjdGlv biBtb3N0bHkgcXVvdGVzIHRob3NlIHdobwo+IGNvbnRyaWJ1dGVkIHRvCj4gdGhlIHByZS1XRyBk b2N1bWVudHMgaXMgaW4gc3RhcmsgY29udHJhc3Qgd2l0aCB0aGUgZGVzY3JpcHRpb24gb2YgdGhl Cj4gZWRpdG9ycyBhYm91dAo+IGhvdyB0aGV5IGhhdmUgZm9ybWVkIHRoYXQgbGlzdCBvZiBuYW1l cy4gTW9zdCBpZiBub3QgYWxsIHRoZSBwZW9wbGUKPiBtZW50aW9uZWQgYWJvdmUKPiBhcmUgYWNr bm93bGVkZ2VkIGJ5IHJlZmVyZW5jZSwgcG9pbnRpbmcgdG8gYWNrbm93bGVkZ2VtZW50IHNlY3Rp b25zIGluCj4gcmVsYXRlZAo+IGRvY3VtZW50cy4gSW4gbXkgZnVuY3Rpb24gYXMgY28tY2hhaXIs IEkgaGF2ZSBhc2tlZCBpZiBhbnlib2R5IGZlZWxzIGxlZnQKPiBvdXQKPiBib3RoIG9uIHRoZSBX RyBsaXN0IGFuZCBvbiB0aGUgSUVURiBsaXN0OyBJIGhhdmUgbm90IHJlY2VpdmVkIGFueXRoaW5n Cj4gZnJvbQo+IGFueWJvZHkuCj4KPiBBcyBhIHRlY2huaWNhbCBjb250cmlidXRvciwgSSBkb24n dCB0aGluayB0aGVyZSBpcyBhbnkgbmVlZCBmb3IgYW55IGNoYW5nZQo+IGhlcmUuCj4KPgo+ID5B bGwgdGhlIGJlc3QuCj4gPmpmYwo+ID4KPiA+UFMuIEhhdmluZyB0cmFuc3BhcmVuY3kgaW4gbWlu ZCBJIGNvcHkgdGhlIElFVEYgbWFpbiBsaXN0LiBUaGlzIExDIGVuZHMKPiB0b21vcnJvdy4gSSBk byBub3QgaW50ZW50IHRvIGFkZHJlc3MgdGhlIGNvbW1lbnRzLiBCdXQgSSB3aWxsIGNlcnRhaW5s eQo+IGNvbnNpZGVyIHRoZW0gaW4gdGhlIGFwcGVhbCBJIHN1c3BlY3QgdG8gYmUgdW5mb3J0dW5h dGVseSBuZWNlc3NhcnkgKE5CLgo+IEJlZm9yZSB0aGVpciBmaXJzdCBkYXkgZGVjaXNpb24gdG8g a2VlcCB3aXRoIGEgdHdpY2UgSUVURiBMQyBmYWlsZWQKPiBkb2N1bWVudCwgSSBwcm9wb3NlZCB0 aGUgV0ctTFRSVSBDaGFpcnMgdG8gY28td3JpdGUgdGhlIERyYWZ0cyBzbyB3ZSBjb3VsZAo+IGZp bmlzaCB0aGUgd29yayBpbiBhIGZldyBtb250aHMuIEkgb2J2aW91c2x5ICBldmVudHVhbGx5IGdl dCBzdGVwIGJ5IHN0ZXAKPiBhbGwgd2hhdCBJIHdhbnRlZCAtIGluIHRoZSBkb2N1bWVudHMgb3Ig aW4gdGhlIHJlYWwgd29ybGQ6IGJ1dCB3aGF0IGEgd2FzdGUKPiBvZiB0aW1lIGFuZCBlZmZvcnQp LiBDaGVlcnMuCj4KPiBJIHJlbWVtYmVyIHdlbGwgdGhhdCBzcGVjaWFsbHkgYXQgdGhlIHN0YXJ0 IG9mIHRoZSBXRywgdGhlIFdHIGNvLWNoYWlycwo+IHJlcGVhdGVkbHkgYXNrZWQgZm9yIGFjdHVh bCB0ZXh0dWFsIGNvbnRyaWJ1dGlvbnMuIFRoZXNlIHdlcmUgZmV3IGFuZCBmYXIKPiBiZXR3ZWVu LCBhbmQgd2VyZSB1c3VhbGx5IHJlamVjdGVkIGJ5IHRoZSBXRyBhZnRlciBzb21lIGRpc2N1c3Np b24uCj4KPgo+IFJlZ2FyZHMsICAgIE1hcnRpbi4KPgo+Cj4KPiAjLSMtIyAgTWFydGluIEouIER1 InJzdCwgQXNzb2MuIFByb2Zlc3NvciwgQW95YW1hIEdha3VpbiBVbml2ZXJzaXR5Cj4gIy0jLSMg IGh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwICAgICAgIG1haWx0bzpkdWVyc3RAaXQuYW95 YW1hLmFjLmpwCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cg== ------=_Part_355_31924196.1150940374828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBmdWxseSBhZ3JlZSB3aXRoIE1hcnRpbi4gTmljZSBqb2IuPGJyPjxicj5NYXJrPGJyPjxicj48 ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNi8yMS8wNiwgPGIgY2xhc3M9ImdtYWls X3NlbmRlcm5hbWUiPk1hcnRpbiBEdWVyc3Q8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86ZHVlcnN0 QGl0LmFveWFtYS5hYy5qcCI+ZHVlcnN0QGl0LmFveWFtYS5hYy5qcDwvYT4mZ3Q7IHdyb3RlOgo8 L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6 IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7 IHBhZGRpbmctbGVmdDogMWV4OyI+RGVhciBMVFJVIG1lbWJlcnMgKGNjIElFVEYgbWFpbGluZyBs aXN0KSw8YnI+PGJyPkhlcmUgYXJlIG15IGNvbW1lbnRzIG9uIGhvdyBJIChhcyBhIHRlY2huaWNh bCBjb250cmlidXRvcikKPGJyPnByb3Bvc2UgdG8gYWRkcmVzcyB0aGUgTGFzdCBDYWxsIGNvbW1l bnRzIG1hZGUgYmVsb3cuPGJyPkkgaG9wZSBvdGhlcnMgaGF2ZSBzb21lIGNvbW1lbnRzLCB0b28u PGJyPjxicj5BdCAyMzo1NiAwNi8wNi8xOCwgSkZDIChKZWZzZXkpIE1vcmZpbiB3cm90ZTo8YnI+ Jmd0O0RlYXIgSUVTRyBNZW1iZXJzLDxicj4mZ3Q7PGJyPiZndDsxLiZuYnNwOyZuYnNwO1RoZSBw cm9wb3NlZCBEcmFmdCBpcyBub3QgYWJvdXQgbWF0Y2hpbmcgKGl0IGlzIGFic3VyZCB0byBzYXkg dGhhdCBteSBJdGFsaWFuIGNhbiAmcXVvdDttYXRjaCZxdW90OyB5b3VyIEphcGFuZXNlIGluIG9y ZGVyIGZvciB1cyB0byB1bmRlcnN0YW5kIGVhY2ggb3RoZXIgYmV0dGVyKS4gSXQgaXMgYWJvdXQg dXNpbmcgcGF0dGVybiBtYXRjaGluZyB0ZWNobmlxdWVzIGluIG9yZGVyIHRvIGZpbHRlciBsaXN0 cyBhZ2FpbnN0IGEgbGFuZ3RhZyB3aXRoIHR3byByZXN1bHRzIChtYXggb25lIGFuc3dlciwgbm8g bWF4KSBhbmQgaW4gdHdvIGNhc2VzICh3ZWxsIGZvcm1lZCBsYW5ndGFnIG9yIG5vdCkuIEhvd2V2 ZXIsIHRoZSB3b3JkaW5nIGlzIHN1Y2ggdGhhdCB3aXRob3V0IGV4YW1wbGVzIGl0IGlzIGRpZmZp Y3VsdCB0byB1bmRlcnN0YW5kIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUgcGF0dGVybiBtYXRj aGluZyBmdW5jdGlvbiB0aGF0IGlzIGJlaW5nIHVzZWQgLSBhbmQgdGhlcmVmb3JlIHRoZSBwb3Nz aWJsZSBhcHBsaWNhdGlvbnMgYW5kIHRoZSBwdXJwb3NlIG9mIHRoZSBEcmFmdC4mbmJzcDsmbmJz cDtUaGUgYWxnb3JpdGhtIG9mIHRoaXMgZnVuY3Rpb24gaXMgdW5kb2N1bWVudGVkIGFuZCB0aGVy ZSBpcyBubyBvYmxpZ2F0aW9uIHRvIGRvY3VtZW50IGl0LCB3aGF0IG1heSBsZWFkIHRvIGJsb2Nr aW5nIGNvbmZsaWN0cyBpZiB0d28gZmlsdGVycyBtYXkgaGF2ZSB0byBpbnRlcm9wZXJhdGUuIFRo aXMgcHJvcG9zaXRpb24gaXMgTk9UIHNjYWxhYmxlIGFuZCBkb2VzIG5vdCBpbnRlbnQgdG8gYmUg c2NhbGFibGUuCjxicj48YnI+VGhlIG1hdGNoaW5nIGRyYWZ0IG9mIGNvdXJzZSBtYWtlcyBzdXJl IHRoYXQgJnF1b3Q7amEmcXVvdDsgYW5kICZxdW90O2l0JnF1b3Q7IGRvIG5vdDxicj5tYXRjaC4g Tm90aGluZyBhYnN1cmQgaGFwcGVuaW5nIHRoZXJlLiBBbHNvLCB3aGF0IHRoZSBkcmFmdCBhY3R1 YWxseTxicj5kZXNjcmliZXMgaXMgbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncyBhZ2FpbnN0IGxhbmd1 YWdlIHJhbmdlczsgdGhlcmUKPGJyPmFyZSB0aHJlZSBtYXRjaGluZyB2YXJpYW50cywgdHdvIGZv ciBmaWx0ZXJpbmcgYW5kIG9uZSBmb3IgbG9va3VwLjxicj48YnI+U29tZSBvZiB0aGUgbWF0Y2hp bmcgcHJvY2VkdXJlcyBpbmRlZWQgaGF2ZSB0byBiZSByZWFkIGNhcmVmdWxseS48YnI+QnV0IHRo ZSBXRyBtYWRlIGV2ZXJ5IGF0dGVtcHQgdG8gZGVzY3JpYmUgdGhlbSBjYXJlZnVsbHksIGdvaW5n PGJyPnRocm91Z2ggc2V2ZXJhbCBpdGVyYXRpb25zLiBBbmQgd2UgcHJvdmlkZSBleGFtcGxlcywg dG9vLgo8YnI+PGJyPlRoZSBtYWluIGFwcGxpY2F0aW9ucyBlbnZpc2lvbmVkIGJ5IHRoZSBkcmFm dCBhcmUgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCw8YnI+dGhleSBhcmUgdGhpbmdzIHN1Y2ggYXMg c2VsZWN0aW9uIG9mIGRvY3VtZW50cyAoZS5nLiB3aGVuIHNlYXJjaGluZyk8YnI+b3IgZG9jdW1l bnQgcGllY2VzIChlLmcuIGZvciBzdHlsaW5nKSBpbiB0aGUgY2FzZSBvZiBmaWx0ZXJpbmcgYW5k Cjxicj5maW5kaW5nIHRoZSBiZXN0IG1hdGNoIHRvIHJldHVybiBkb2N1bWVudHMgb3IgZG9jdW1l bnQgZnJhZ21lbnRzPGJyPmluIHRoZSBjYXNlIG9mIGxvb2t1cCAodGhlIHByb3RvdHlwaWNhbCBl eGFtcGxlIGJlaW5nIEhUVFAgbGFuZ3VhZ2U8YnI+bmVnb3RpYXRpb24pLjxicj48YnI+QXMgZm9y IGNvbmZsaWN0aW5nIGZpbHRlcnMsIHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgdHdvIGZp bHRlcnMKPGJyPihlLmcuIGluIHR3byBkaWZmZXJlbnQgcHJvdG9jb2xzKSBwcm9kdWNlIGV4YWN0 bHkgdGhlIHNhbWUgcmVzdWx0Ljxicj5EaWZmZXJlbnQgcHJvdG9jb2xzIG1heSBoYXZlIGRpZmZl cmVudCBuZWVkcy4gVGhhdCdzIHdoeSB0aGUgZHJhZnQ8YnI+bGVhdmVzIHNvbWUgc3BlY2lmaWNz IGZvciBhIHBhcnRpY3VsYXIgcHJvdG9jb2wgdG8gYmUgZGVjaWRlZC48YnI+PGJyPkFzIGEgcmVz dWx0LCBJIGRvIG5vdCBzZWUgYW55dGhpbmcgaW4gY29tbWVudCAxLiB0aGF0IHdvdWxkIG5lZWQK PGJyPmFkZHJlc3NpbmcgaW4gdGhlIGN1cnJlbnQgZHJhZnQuPGJyPjxicj48YnI+Jmd0OzIuIEVp dGhlciBSRkMgMzA2NiBCaXMgaXMgd2VsbCB3cml0dGVuICh3aGF0IEkgdGhpbmsgd2UgYWNoaWV2 ZWQgaWYgc3RyaWN0bHkgbGltaXRlZCB0byB0aGUgSW50ZXJuYXRpb25hbGl6ZWQgQVNDSUkgSW50 ZXJuZXQpIGFuZCB3ZWxsIGFwcGxpZWQgKHdoYXQgSSBjYW4gc2VlIHRoYXQgaXQgaXMgbm90IHRo ZSBjYXNlOiB0aGUgcmV2aWV3IG1lY2hhbmlzbSBkb2VzIG5vdCByZXNwZWN0IFJGQyAzMDY2IEJp cykgYW5kIHRoZSBmaWx0ZXJpbmcgaXMgYWxyZWFkeSBidWlsdC1pbiwgYW5kIHRoZSBmdW5jdGlv bmFsIHN0cmF0ZWdpZXMgYXJlIHRvIGJlIHNwZWNpZmljIHRvIGFwcGxpY2F0aW9ucyBhbmQgcHJv dG9jb2xzLiBPciB0aGF0IERyYWZ0LCB3aGljaCBkb2VzIG5vdCBzZWVrIHRvIGZpcnN0IGVuc3Vy ZSB0aGF0IGxhbmd0YWdzIHJlc3BlY3QgUkZDIDMwNjYgQmlzICgKaS5lLiBiZWluZyB3ZWxsIGZv cm1lZCBvciBjb3JyZWN0ZWQgaW4gb3JkZXIgdG8gYmVjb21lIHdlbGwgZm9ybWVkKSwgaXMgYSBu ZWdhdGlvbiBvZiBSRkMgMzA2NiBCaXMuIEkgdGhpbmsgdGhhdCBhdXRob3JzIGhhZCBmaWx0ZXJp bmcgaW4gbWluZCAoaXQgd2FzIHRoZSBhcGV4IG9mIHRoZSBmaXJzdCB1bmlxdWUgZG9jdW1lbnQp IGFuZCBkaWQgbm90IHJlYWxpc2UgdGhhdCB0aGUgd29yayBhY2hpZXZlZCBpbiBjbGVhbmluZyB0 aGUgZmlyc3QgcGFydCBtYWRlIGl0cyBjb3JyZWN0aW9uIGJ5IHRoZSBzZWNvbmQgcGFydCBub3Qg bmVjZXNzYXJ5IGFueW1vcmUuIFRoYXQgaXMgaWYgdGhlIHdob2xlIHB1cnBvc2Ugd2FzIG5vdCBh IG5vbiBkb2N1bWVudGVkIHVzZSBvZiB0aGUgZmlsdGVyaW5nICh1c2VycyBtYXNzIHByb2ZpbGlu ZykuIElmIGl0IHdhcyBub3QgdGhlIHdob2xlIGRvY3VtZW50IGNhbiBiZSB3cml0dGVuIGFzICZx dW90O21ha2Ugc3VyZSBsYW5ndGFncyBhcmUgd2VsbCBmb3JtZWQgYW5kIGZlZWQgdGhlbSBvbiB0 aGUgcGF0dGVybgo8YnI+IG1hdGNoaW5nIGZ1bmN0aW9uIG9mIHlvdXIgYXBwbGljYXRpb24vcHJv dG9jb2wgdG8gb2J0YWluIHRoZSByZXN1bHRzIGl0IG5lZWRzIGFsb25nIHlvdXIgbGFuZ3VhZ2Ug bWFuYWdlbWVudCBzdHJhdGVneSZxdW90Oy48YnI+PGJyPlRoZSBjb21tZW50ZXIgc2VlbXMgdG8g Y2xhaW0gdGhhdCBkcmFmdC1pZXRmLWx0cnUtbWF0Y2hpbmcgY29uZmxpY3RzIHdpdGg8YnI+ZHJh ZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5IChoZXJlIGNhbGxlZCBSRkMgMzA2NmJpcykgYmVjYXVzZSB0 aGUgbGF0ZXIKPGJyPmRlZmluZXMgd2VsbC1mb3JtZWQgdGFncyB3aGlsZSB0aGUgZm9ybWVyIGRv ZXMgbm90IHJlcXVpcmUgd2VsbC1mb3JtZWQ8YnI+dGFncy4gVGhlIHJlYXNvbiBmb3Igbm90IHJl cXVpcmluZyBjaGVja2luZyBmb3Igd2VsbC1mb3JtZWQgdGFncyB3aGVuPGJyPm1hdGNoaW5nIHdh cyBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIFdHLiBUaGVyZSBpcyBhIHZlcnkgY2xlYXIg cmVhc29uOgo8YnI+cmVxdWlyaW5nIHRoaXMgd291bGQgcmVxdWlyZSB0byBjaGVjayB0aGUgSUFO QSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnksPGJyPnBvdGVudGlhbGx5IGZvciBldmVyeSBtYXRj aGluZyBvcGVyYXRpb24sIHdoaWNoIHdhcyBjb25zaWRlcmVkIG9wZXJhdGlvbmFsbHk8YnI+aW5m ZWFzaWJsZS4gSXQgd291bGQgYWxzbyBiZSBhbiB1bm5lY2Vzc2FyeSBwZXJmb3JtYW5jZSBwdW5p c2htZW50IGZvcgo8YnI+dGhvc2Ugd2hvIGFjdHVhbGx5IHVzZSB3ZWxsLWZvcm1lZCB0YWdzLiBJ biBnZW5lcmFsLCBub24td2VsbGZvcm1lZDxicj50YWdzIG9yIHJhbmdlcyB3aWxsIHNpbXBseSBu b3QgbWF0Y2ggYW55dGhpbmcsIHdoaWNoIGlzIGp1c3QgZmluZS48YnI+PGJyPlRoZSBjb21tZW50 ZXIgaXMgY29ycmVjdCBpbiB0aGF0IHRoZXJlIGlzIG5vIGFic29sdXRlIG5lZWQgZm9yIHRoaXMg ZHJhZnQ7Cjxicj5lYWNoIHByb3RvY29sIG9yIGZvcm1hdCBjb3VsZCBjb21lIHVwIHdpdGggaXQn cyBvd24gd2F5IG9mIG1hdGNoaW5nPGJyPmxhbmd1YWdlIHRhZ3MuIEFmdGVyIGFsbCwgUkZDIDMw NjZiaXMgZGVmaW5lcyBob3cgdGhlc2UgdGFncyBhcmUgYnVpbHQsPGJyPmFuZCAodG8gYSBjZXJ0 YWluIGV4dGVudCkgd2hhdCB0aGV5IG1lYW4uIEhvd2V2ZXIsIEkgY29uc2lkZXIgdGhlIGN1cnJl bnQKPGJyPmRyYWZ0IHZhbHVhYmxlIGJlY2F1c2UgaXQgaGVscHMgcHJvdG9jb2wvZm9ybWF0IGRl c2lnbmVycywgd2hvIGluIGdlbmVyYWw8YnI+YXJlIG5vdCBleHBlcnRzIG9uIGxhbmd1YWdlIHRh Z3MgYW5kIGxhbmd1YWdlIG1hdGNoaW5nLCB0byBjaG9vc2UgdGhlPGJyPnJpZ2h0IGtpbmQgb2Yg bWF0Y2hpbmcgc2NoZW1lLiBBbHNvLCBvbmUgbWF0Y2hpbmcgc2NoZW1lIHdhcyBhbHJlYWR5Cjxi cj5kZXNjcmliZWQgaW4gUkZDIDMwNjYsIGFuZCBzbyBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgdG8g b2Jzb2xldGU8YnI+UkZDIDMwNjYgd2l0aG91dCB0aGlzIGRyYWZ0Ljxicj48YnI+SSB0aGVyZWZv cmUgZG9uJ3Qgc2VlIGFueSBjaGFuZ2UgdGhhdCB3b3VsZCBiZSBuZWVkZWQgaW4gdGhlIGN1cnJl bnQ8YnI+ZHJhZnQgdG8gYWRkcmVzcyBjb21tZW50IDIuPGJyPjxicj4mZ3Q7My4gJnF1b3Q7KiZx dW90OyByZXN0cmljdGlvbnMgaW4gdGhlIHBhdHRlcm4gbWF0Y2hpbmcgZnVuY3Rpb24gY2FuIGhh cmRseSBiZSB1bmRlcnN0b29kIHdpdGhvdXQgc2V2ZXJhbCBleGFtcGxlcy4gVGhleSBhZGQgdXNh Z2UgbGltaXRhdGlvbnMgdG8gdGhlIFJGQyAzMDY2IEJpcyBmb3JtYXQsIHdoZXJlIHRoZXkgc2hv dWxkIGJlIGRvY3VtZW50ZWQg44OlIG9yIHRoZSBEcmFmdCBjYW5ub3QgYmUgcGFydCBvZiBCQ1Ag NDcuIFRoaXMgY2VydGFpbmx5IGJlbG9uZ3MgdG8gdGhlIGxhbmd1YWdlIGNvbnN0cmFpbmluZyBz dHJhdGVneSBvZiB0aGUgV0ctTFRSVSBhZmZpbml0eSBncm91cCBhbmQgdG8gdGhlIGludGVyZXN0 cyBhIGNvLUNoYWlyIHJlY2VudGx5IGRvY3VtZW50ZWQuIEJ1dCB0aGlzIGlzIHVuYWNjZXB0YWJs ZSB0byBtb3N0IHVzZXJzLCBldmVuIGlmIGl0IGlzIGNlcnRhaW5seSBmYXZvdXJhYmxlIHRvIGEg bmF0aW9uYWwgc3RyYXRlZ3kgYW5kIHRvIHRoZSBtZW1iZXJzIG9mIGEgZ2l2ZW4gY29uc29ydGl1 bS4gSSB0aGVyZWZvcmUgc3VibWl0IHRoYXQgdGhlIElFU0cgTWVtYmVycyB3aG8gYXJlIGNpdGl6 ZW5zIG9mIHRoYXQgbmF0aW9uLCBvciBtZW1iZXJzLCBvciBlbXBsb3llZXMgb2YgdGhlIG1lbWJl cnMgb2YgdGhhdCBjb21tZXJjaWFsIGNvbnNvcnRpdW0gaGF2ZSBhIENPSS4KPGJyPjxicj5UaGVy ZSBhcmUgbm8gcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgJnF1b3Q7KiZxdW90OyBpbiBsYW5n dWFnZSByYW5nZXMuPGJyPlRoZXJlIGlzIGEgdmVyeSBzcGVjaWZpYyB0cmVhdG1lbnQgb2YgJnF1 b3Q7KiZxdW90OyB3aWxkY2FyZCBjb21wb25lbnRzIGluPGJyPmxhbmd1YWdlIHJhbmdlcyBmb3Ig ZXh0ZW5kZWQgZmlsdGVyaW5nLiBUaGUgYWN0dWFsIGFsZ29yaXRobSBpbgo8YnI+dGhlIGRyYWZ0 IGlzIGRlc2NyaWJlZCBjYXJlZnVsbHksIGFuZCBhbiBleHBsYW5hdGlvbiBmb3Igd2h5IGl0IGlz PGJyPnRoZSB3YXkgaXQgaXMgaXMgZ2l2ZW4uIFRoaXMgbWF0Y2hpbmcgYWxnb3JpdGhtIGRvZXMg bm90IGFkZDxicj5hbnkgdXNhZ2UgbGltaXRhdGlvbnMgdG8gUkZDIDMwNjZiaXMuIE9uIHRoZSBj b250cmFyeSwgaXQgd2FzPGJyPmNhcmVmdWxseSBkZXNpZ25lZCB0byB3b3JrIHdlbGwgdG9nZXRo ZXIgd2l0aCBSRkMgMzA2NmJpcy4KPGJyPjxicj5JIGRvIG5vdCBrbm93IG9mIGFueSBjb25jcmV0 ZSBleGFtcGxlIHdoZXJlIHRoZSBtYXRjaGluZyBiZWhhdmlvcjxicj53b3VsZCBiZSB1bmFjY2Vw dGFibGUuIEFueSBjbGFpbXMgdGhhdCBpdCBpcyAmcXVvdDt1bmFjY2VwdGFibGUgdG88YnI+bW9z dCB1c2VycyZxdW90OywgYXJlIHRoZXJlZm9yZSwgaW4gbXkgdmlldywganVzdCBtYWRlIHVwIG91 dCBvZiB0aGluIGFpci4KPGJyPjxicj5BbHNvLCBJIGhhdmUgbm8gaWRlYSB3aGF0IGlzIG1lYW50 IGJ5ICZxdW90O2xhbmd1YWdlLWNvbnN0cmFpbmluZyBzdHJhdGVneSZxdW90Oy48YnI+SWYgYW55 Ym9keSB3YW50ZWQgdG8gcmVzdHJpY3QgdGhlIHVzZSBvZiBjZXJ0YWluIGxhbmd1YWdlcyBpbiBj ZXJ0YWluPGJyPnBhcnRzIG9mIHRoZSBJbnRlcm5ldCwgdGhleSBjb3VsZCBlYXNpbHkgYWxyZWFk eSBoYXZlIGRvbmUgdGhhdCBiYXNlZAo8YnI+b24gUkZDIDMwNjYsIG9yIGNvdWxkIGRvIGJhc2Vk IG9uIFJGQyAzMDY2YmlzLCBvciBldmVuIGp1c3QgYmFzZWQgb248YnI+c3RhdGlzdGljYWwgYW5h bHlzaXMgb2YgdGhlIGFjdHVhbCBjb250ZW50IHRyYW5zbWl0dGVkICh3aXRoIHRlY2huaXF1ZXM8 YnI+c3VjaCBhcyB0cmlncmFtcykuIEFuZCBjZXJ0YWlubHkgbm9ib2R5IHdobyBhY3R1YWxseSB3 YW50ZWQgdG8gZG8gc3VjaAo8YnI+YSB0aGluZyB3b3VsZCBhc2sgZm9yIGFuIFJGQyBvciBvdGhl ciBraW5kIG9mIHN0YW5kYXJkIHRvIHRyeSB0bzxicj5sZWdpdGltYXRlIHN1Y2ggcmVzdHJpY3Rp b25zLCBub3Igd291bGQgSSBob3BlIGFueWJvZHkgd291bGQgY29uZG9uZTxicj5zdWNoIGJlaGF2 aW9yIGp1c3QgYmVjYXVzZSBpdCB3b3VsZCBtYWtlIHVzZSBvZiBhbiBSRkMuPGJyPjxicj5BcyBh IHJlc3VsdCwgSSBkb24ndCB0aGluayB0aGF0IGFueXRoaW5nIG5lZWRzIHRvIGJlIGRvbmUgdG8g YWRkcmVzcwo8YnI+Y29tbWVudHMgMy48YnI+PGJyPiZndDs0LiBBbGwgdGhlIGFib3ZlJm5ic3A7 Jm5ic3A7bWVhbnMgdGhhdCB0aGUgRHJhZnQgaXMgdXNlZnVsIGluIGF0IGxlYXN0IHR3byBjaXJj dW1zdGFuY2VzOjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IC0gaWYgdGhlIGxhbmd0YWdzIGFyZSBub3Qg d2VsbCBmb3JtZWQgb3IgZG8gbm90IHJlc3BlY3QgdGhlIHByaW5jaXBsZXMgb2YgSVNPIDYzOS00 IGFuZC9vciBSRkMgMzA2NiBCaXMuCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IC0gaWYgdGhlIGxhbmd0 YWdzIGFyZSB1c2VkIGZvciBvdGhlciBwdXJwb3NlcyB0aGF0IGFyZSB1bmRvY3VtZW50ZWQgYXQg dGhlIFdHLUxUUlUgQ2hhcnRlci48YnI+Jmd0O1RoZXNlIGNpcmN1bXN0YW5jZXMgc2hvdWxkIGJl IGRvY3VtZW50ZWQuPGJyPjxicj5JU08gNjM5LTQgaXMgc3RpbGwgYmVpbmcgd29ya2VkIG9uLiBU aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgbm9uLXdlbGxmb3JtZWQKPGJyPnRhZ3MgaXMgbm90IHNv bWV0aGluZyB0aGUgZHJhZnQgaXMgZGVzaWduZWQgdG8gZG87IGl0IGlzIGp1c3QgYSBjb25zZXF1 ZW5jZTxicj5vZiBub3QgcmVxdWlyaW5nIGNoZWNraW5nIGZvciB3ZWxsLWZvcm1lZG5lc3MgKHRv IGF2b2lkIG9wZXJhdGlvbmFsIHByb2JsZW1zKS48YnI+VGhlIGRyYWZ0IGV4cGxpY2l0bHkgc2F5 cyB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgdG8gY2hlY2sgZm9yIHdlbGwtZm9ybWVkbmVzcywKPGJy PnNvIEkgZG9uJ3Qgc2VlIHdoYXQgd291bGQgbmVlZCB0byBiZSBkb2N1bWVudGVkIGZ1cnRoZXIu PGJyPjxicj5UaGUgZHJhZnQsIGxpa2UgbW9zdCBJRVRGIHdvcmssIG1lbnRpb25zIHBvc3NpYmxl IHVzZXMgb2YgdGhlIHRlY2hub2xvZ3ksPGJyPmluIHBhcnRpY3VsYXIgYXMgZXhhbXBsZXMgdG8g ZXhwbGFpbiBkZXNpZ24gZGVjaXNpb25zIG9yIGNob2ljZXMgb2Ygb3B0aW9uczxicj4KZm9yIHRo ZSB1c2VycyAoaW4gdGhlIGNhc2Ugb2YgdGhlIGRyYWZ0LCB0aGUgZGlyZWN0IHVzZXJzIGFyZSBw cm90b2NvbHM8YnI+YW5kIGZvcm1hdHMpLiBBbnkgYXR0ZW1wdCB0byBkZXNjcmliZSBhbnkgYW5k IGFsbCBwb3NzaWJsZSB1c2VzIGZvciBhPGJyPnRlY2hub2xvZ3kgaW52YXJpYWJseSBmYWlsLCBh bmQgc28gc2hvdWxkbid0IGJlIGF0dGVtcHRlZCBpbiB0aGUgZmlyc3Q8YnI+CnBsYWNlLjxicj48 YnI+SSB0aGVyZWZvcmUgZG9uJ3Qgc2VlIGFueSBjaGFuZ2UgdGhhdCB3b3VsZCBiZSBuZWNlc3Nh cnkgYmFzZWQgb248YnI+Y29tbWVudCA0Ljxicj48YnI+Jmd0OzUuIFRoZSBzZWN1cml0eSBzZWN0 aW9uIHNob3VsZCBtZW50aW9uIHRoYXQgdGhpcyBEYWZ0IGVuY291cmFnZXMgdGhlIGRpc3Jlc3Bl Y3Qgb2YgdGhlIFJGQyAzMDY2IEJpcyBmb3JtYXQgYW5kIGZ1cnRoZXIgYXNzaXN0cyBkYW5nZXJv dXMgcHJvamVjdHMgdGhhdCB0aGUgSUVURiBoYXMgcmVmdXNlZCB0byBtZW50aW9uIGluIFJGQyAz MDY2IEJpcywgc3VjaCBhcyBsaW5ndWFsLCBjdWx0dXJhbCwgcmFjaWFsLCBhbmQgcmVsaWdpb3Vz IHByb2ZpbGluZyB0aHJvdWdoIHJldHJvLW1ldGEtc3BhbSAoJnF1b3Q7SSBrbm93IHdobyB5b3Ug YXJlIHRocm91Z2ggd2hpY2ggbGFuZ3RhZ3MgeW91IGFyZSBub3QgYXdhcmUgdGhhdCB5b3UgcmVz cG9uZCB0byZxdW90OyksIHR3by10aWVyIEludGVybmV0IGJhc2VkIHVwb24gdGhlIGxpbmd1YWwg Y2hhcmFjdGVyaXN0aWNzIG9mIHRoZSB1c2VycyBhbmQgdGhlaXIgc3VwcG9zZWQgbWFya2V0IHZh bHVlLCBsYWNrIG9mIGNvbmZvcm1hbmNlIHRvIElTTyAxMTE3OSwgd2hpY2ggbWF5IGxlYWQgdGhl IElFVEYsIHN0YWtlaG9sZGVycywgYW5kIHVzZXJzIHRvIGluYWRlcXVhdGUsIGNvc3RseSwgYW5k IGRlbGF5aW5nIHN0cmF0ZWdpZXMgb3IgdG8gY29uZmxpY3RzIHdpdGggdGhlIE11bHRpbGluZ3Vh bCBJbnRlcm5ldCAtIGFzIGluIHRoZSBzYWQgRG9TIGFnYWluc3QgdGhlIGxlYWRpbmcgZWNvbm9t aWMgbGFuZ3VhZ2UgKCZxdW90O2VuLUVVJnF1b3Q7KSAtIG9yIHRvIGxlZ2FsIGFjY2VzcyBiYW5z IGJ5IGRlbW9jcmF0aWMgb3IgcHJpdmFjeSBvcmllbnRlZCBjb3VudHJpZXMuIEFsbCBvZiB0aGlz IGxlbmRzIGl0c2VsZiB0byBpbmNlbnRpdmVzIGZvciBhbiBJbnRlcm5ldCBmcmFnbWVudGF0aW9u Lgo8YnI+PGJyPkFzIGV4cGxhaW5lZCBhYm92ZSwgdGhlcmUgaXMgbm8gZGlzcmVzcGVjdCBmb3Ig UkZDIDMwNjYgYmlzIGZvcm1hdHMsIGp1c3Qgb3BlcmF0aW9uYWw8YnI+Y29uc2lkZXJhdGlvbnMu IEFsc28sIHRoZSBkcmFmdCBkb2VzIG5vdCBhc3Npc3QgYW55IG9mIHRoZSAnZGFuZ2Vyb3VzIHBy b2plY3RzJyBtZW50aW9uZWQ8YnI+YWJvdmU7IGFueSBvZiB0aGVzZSBwcm9qZWN0cyBhcmUsIGlm IHNvbWUgZW50aXR5IGlzIGRldGVybWluZWQgdG8gZG8gdGhlbSBhbmQKPGJyPmhhcyB0aGUgbmVj ZXNzYXJ5IGFjY2VzcywgZWFzaWx5IHBvc3NpYmxlIHdpdGggdmFyaW91cyBvdGhlciBtZWFucy48 YnI+PGJyPlRoZSBwcm9ibGVtIHRoYXQgUkZDIDMwNjZiaXMgZG9lcyBub3QgYWxsb3cgZW4tRVUg aXMgYSBwcm9ibGVtIG9mIFJGQyAzMDY2YmlzLDxicj5hbmQgbWF5IGhhdmUgdG8gYmUgYWRkcmVz c2VkIGluIGEgZnV0dXJlIHJldmlzaW9uLCBidXQgZG9lcyBub3QgYWZmZWN0IHRoZQo8YnI+bWF0 Y2hpbmcgZHJhZnQgbm93IGluIGxhc3QgY2FsbC48YnI+PGJyPkFnYWluLCBJIGRvbid0IHNlZSBh bnl0aGluZyBoZXJlIHRoYXQgd291bGQgbmVlZCB0byBiZSBjaGFuZ2VkIGluIHRoZTxicj5jdXJy ZW50IGRyYWZ0IHRvIGFkZHJlc3MgdGhpcyBjb21tZW50Ljxicj48YnI+PGJyPiZndDs2LiBBcyBm YXIgYXMgSSB1bmRlcnN0YW5kLCB0d28gRHJhZnQgY29tcGxpYW50IGZpbHRlcnMgbWF5IHJlc3Vs dCBpbiBkaWZmZXJlbnQgcmVzcG9uc2VzIGZvciB0aGUgc2FtZSBmaWx0ZXJpbmcgbGlzdCBhbmQg ZG9jdW1lbnQuIE15IGNvbmNlcm4gaXMgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIHByb3Bv c2VkIEJDUCA0NyB3aXRoIE11bHRpbGluZ3VhbCBJbnRlcm5ldCByZWdpc3RyaWVzLCB0YWdzLCBl dGMuIFRoaXMgaW50ZXJvcGVyYWJpbGl0eSBpcyBub3QgZW5zdXJlZCDjg6UgYW5kIHRoZXJlIGlz IG5vIHByb3NwZWN0IHRvIHNlZSBpdCBpbnN1cmVkIGFzIGl0IGlzIHB1cnBvc2VseSBpZ25vcmVk IGJ5IGF1dGhvcnMuIFRoaXMgcmVwcmVzZW50cyBubyBpbmNlbnRpdmUgZm9yIGRldmVsb3BlcnMu Cjxicj48YnI+VGhlIHRocmVlIG1hdGNoaW5nIHNjaGVtZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFm dCBhbGwgY29tZSB3aXRoIGEgc21hbGwgbnVtYmVyPGJyPm9mIG9wdGlvbnMuIEluIHRoaXMgc2Vu c2UsIGl0IGlzIGUuZy4gcG9zc2libGUgdGhhdCB0d28gZGlmZmVyZW50IHByb3RvY29scyw8YnI+ aGF2aW5nIGNob29zZW4gZGlmZmVyZW50IG9wdGlvbnMsIHdpbGwgbGVhZCB0byBkaWZmZXJlbnQg cmVzdWx0cy4gQW4gZXhhbXBsZQo8YnI+d291bGQgYmUgYW4gSFRUUCBzZXJ2ZXIgc2VydmluZyBh IGRvY3VtZW50IGluIGEgZGlmZmVyZW50IGxhbmd1YWdlIHRoYW4gYTxicj5jb3JyZXNwb25kaW5n IEZUUCBzZXJ2ZXIgKGFzc3VtaW5nIHNvbWVib2R5IGFkZGVkIGxhbmd1YWdlIG5lZ290aWF0aW9u IHRvPGJyPkZUUCkgZm9yIHJlcXVlc3RzIHdpdGggdGhlIHNhbWUgbGFuZ3VhZ2UgcHJpb3JpdHkg bGlzdC4gQnV0IGFzIHN1Y2ggYSBzZXR1cAo8YnI+aXMgaGlnaGx5IGZpY3Rpb25hbCwgYW5kIHRo ZSB0d28gc2VydmVycyBhcmUgY29uZmlndXJlZCBzZXBhcmF0ZWx5IGFueXdheSw8YnI+aGF2aW5n IGRpZmZlcmVudCByZXN1bHRzIHNpbXBseSBiZWNhdXNlIG9mIGRpZmZlcmVudCBjb25maWd1cmF0 aW9uIChyYXRoZXI8YnI+dGhhbiBkaWZmZXJlbnQgbGFuZ3VhZ2UgbWF0Y2hpbmcpLCBvciB0d2Vh a2luZyB0aGUgY29uZmlndXJhdGlvbiB0byBtYWtlCjxicj50aGUgcmVzdWx0cyBtYXRjaCwgYXJl IGJvdGggcG9zc2libGUuIFNvIHRoaXMga2luZCBvZiBpbnRlcm9wZXJhYmlsaXR5IGlzPGJyPm5v dCBvZiBpbXBvcnRhbmNlIGluIHByYWN0aWNlLjxicj48YnI+QWxzbywgaXQgaXMgZGlmZmljdWx0 IHRvIHRyeSB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHNvbWV0aGluZzxicj5jYWxs ZWQgJ011bHRpbGluZ3VhbCBJbnRlcm5ldCByZWdpc3RyaWVzJyB3aGVuIHN1Y2ggYSB0aGluZyBk b2VzIG5laXRoZXIKPGJyPmV4aXN0IG9uIHBhcGVyIG5vciBpbiBwcmFjdGljZS48YnI+PGJyPlNv IHRoZXJlIGlzIG5vdGhpbmcgaW4gY29tbWVudCA2IHRoYXQgd291bGQgcmVxdWlyZSBhbnkgY2hh bmdlczxicj5pbiB0aGUgY3VycmVudCBkcmFmdC48YnI+PGJyPjxicj4mZ3Q7Ny4gVGhlIGFja25v d2xlZGdlbWVudCBzZWN0aW9uIG1vc3RseSBxdW90ZSB0aG9zZSB3aG8gY29udHJpYnV0ZWQgdG8g dGhlIHByZS1XRy1MVFJVIGRvY3VtZW50ICh0aGUgdGhyZWUgV0ctTFRSVSBEcmFmdCBleGlzdGVk IHByaW9yIHRvIHRoZSBjcmVhdGlvbiBvZiB0aGUgV0cgd2hpY2ggbmV2ZXIgc3R1ZGllZCBhbmQg dHJpZWQgdG8gY29uZm9ybSB0byBpdHMgQ2hhcnRlcikuIFRoaXMgaXMgdGhlIHByaXZpbGVnZSBv ZiBhdXRob3JzIHRvIHF1b3RlIHdobyBzdXBwb3J0ZWQgdGhlbSBiZXN0LiBIb3dldmVyLCBpbiB0 aGlzIGNhc2UgdGhlIGRvY3VtZW50IHdhcyBjb25zaWRlcmFibHkgY2xlYW5lZCB0aHJvdWdoIHRo ZSB0b3VnaCBsaWZlIG9mIHRoZSBXRy4gQWxzbywgbW9zdCBvZiB0aGUgbmFtZXMgYmVpbmcgcXVv dGVkIGFyZSB3aWRlbHkga25vd24gYXMgYmVsb25naW5nIHRvIGEgbm9uLUlFVEYgYWZmaW5pdHkg Z3JvdXAsIHdoYXQgZW5mb3JjZXMgdGhlIGV4dGVybmFsIHVuZGVyc3RhbmRpbmcgdGhhdCBCQ1Ag NDcgZG9jdW1lbnRzIGFyZSBhY3R1YWxseSBub3QgSUVURiBkb2N1bWVudHMuIFRoaXMgd2lsbCBt b3N0IHByb2JhYmx5IGxpbWl0IHRoZWlyIGNvbnNpZGVyYXRpb24uIEFmdGVyIG9uZSB5ZWFyIG9m IHRvdWdoIGRlYmF0ZXMgSSBjYW4gdGVzdGlmeSB0aGVzZSwgZ29vZCBvciBub3QsIHRocmVlIGRv Y3VtZW50cyBhcmUgSUVURiBkb2N1bWVudHMgZm9yIHRoZSBJbnRlcm5hdGlvbmFsaXplZCBBU0NJ SSBJbnRlcm5ldC4gSSBsaXN0ZWQgdGhlIG5hbWVzIEkgY29uc2lkZXIgbWlzc2luZyBpbiBhIExh c3QgQyBhbGwgbWFpbC4KPGJyPiZndDs8YnI+Jmd0O0F1dGhvcnMgZWl0aGVyIGRpZCBub3QgcmVh ZCBpdCBvciBhcmUga2VlcGluZyBoYXJhc3NpbmcgbWUsIHNpbmNlIHRoZXkgY29udGludWUgYXNr aW5nIGZvciBhbiBpbnB1dC4gSSBxdW90ZSBteSBtYWlsOiAmcXVvdDtldmVyeSBjb250cmlidXRp b24gY2FuIGJlIGEga2V5IHN0b25lIGluIHRoZSBmaW5hbCBjb25zdHJ1Y3QuIFRoYXQgcGVvcGxl IGxpa2UgTWljaGFlbCBFdmVyc29uLCBOZWQgRnJlZWQsIExlZSBHaWxsYW0sIEpvaG4gQy4gS2xl bnNpbiwgRmVsaXggU2FzYWtpLCBNaWNoZWwgU3VpZ25hcmQsIGFuZCBUZXggVGV4aW4gYXJlIG5v dCBxdW90dGVkIHNlZW1zIG9kZC4gT3RoZXJzIGxpa2UgU2NvdHQgSG9sbGVuYmVjayBhbmQgU2Ft IEhhcnRtYW4gcmVhbGx5IGhlbHBlZC4gV2hhdCBhYm91dCBLYXJlbiBCcm9vbWUsIApNLlQuIENh cnJhc2NvIEJlbml0ZXosIE4uIFBpZXJjZWk/IElucHV0cyBvciBoZWxwIGZyb20gQnJpYW4gQ2Fy cGVudGVyLCBUZWQgSGFyZGllLCBEeWxhbiBOLiBQaWVyY2UgYXJlIHJlYWwuJnF1b3Q7LiBJIGRv IG5vdCBhc2sgbXkgbmFtZSB0byBiZSBsaXN0ZWQgdGhlcmUgc2luY2UgSSBrbm93ICZxdW90O2l0 IGlzIG5vdCBbdGhlXSBpbnRlcmVzdCBbb2Ygc29tZSBpbiB0aGUgbGlzdF0gdG8gYmUgYXNzb2Np YXRlZCB3aXRoIFtteSBvd25dIG5hbWUmcXVvdDsuCjxicj4mZ3Q7PGJyPiZndDtPciB3b3VsZCB0 aGF0IG1lYW4gdGhhdCB0aGUgSUVURiBkb2VzIG5vdCByZWFsbHkgYmFjayB0aGlzIGRlbGl2ZXJh YmxlPyBUaGUgcXVlc3Rpb24gaGVyZSBpczogZG9lcyB0aGUgSUVURiB3YW50cyB0byBpbmZsdWVu Y2UgdGhlIHdvcmxkIChSRkMgMzkzNSksIGRvY3VtZW50IHRoZSBJbnRlcm5hdGlvbmFsaXNlZCBB U0NJSSBJbnRlcm5ldCwgb3Igc2VydmUgdGhlIE11bHRpbGluZ3VhbCBJbnRlcm5ldCBkZXZlbG9w bWVudC4gTWFueSB3b3VsZCBsaWtlIHRvIGtub3cuCjxicj48YnI+VGhlIGNsYWltIHRoYXQgdGhl IGFja25vd2xlZGdlbWVudCBzZWN0aW9uIG1vc3RseSBxdW90ZXMgdGhvc2Ugd2hvIGNvbnRyaWJ1 dGVkIHRvPGJyPnRoZSBwcmUtV0cgZG9jdW1lbnRzIGlzIGluIHN0YXJrIGNvbnRyYXN0IHdpdGgg dGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBlZGl0b3JzIGFib3V0PGJyPmhvdyB0aGV5IGhhdmUgZm9y bWVkIHRoYXQgbGlzdCBvZiBuYW1lcy4gTW9zdCBpZiBub3QgYWxsIHRoZSBwZW9wbGUgbWVudGlv bmVkIGFib3ZlCjxicj5hcmUgYWNrbm93bGVkZ2VkIGJ5IHJlZmVyZW5jZSwgcG9pbnRpbmcgdG8g YWNrbm93bGVkZ2VtZW50IHNlY3Rpb25zIGluIHJlbGF0ZWQ8YnI+ZG9jdW1lbnRzLiBJbiBteSBm dW5jdGlvbiBhcyBjby1jaGFpciwgSSBoYXZlIGFza2VkIGlmIGFueWJvZHkgZmVlbHMgbGVmdCBv dXQ8YnI+Ym90aCBvbiB0aGUgV0cgbGlzdCBhbmQgb24gdGhlIElFVEYgbGlzdDsgSSBoYXZlIG5v dCByZWNlaXZlZCBhbnl0aGluZyBmcm9tCjxicj5hbnlib2R5Ljxicj48YnI+QXMgYSB0ZWNobmlj YWwgY29udHJpYnV0b3IsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IG5lZWQgZm9yIGFueSBj aGFuZ2UgaGVyZS48YnI+PGJyPjxicj4mZ3Q7QWxsIHRoZSBiZXN0Ljxicj4mZ3Q7amZjPGJyPiZn dDs8YnI+Jmd0O1BTLiBIYXZpbmcgdHJhbnNwYXJlbmN5IGluIG1pbmQgSSBjb3B5IHRoZSBJRVRG IG1haW4gbGlzdC4gVGhpcyBMQyBlbmRzIHRvbW9ycm93LiBJIGRvIG5vdCBpbnRlbnQgdG8gYWRk cmVzcyB0aGUgY29tbWVudHMuIEJ1dCBJIHdpbGwgY2VydGFpbmx5IGNvbnNpZGVyIHRoZW0gaW4g dGhlIGFwcGVhbCBJIHN1c3BlY3QgdG8gYmUgdW5mb3J0dW5hdGVseSBuZWNlc3NhcnkgKE5CLiBC ZWZvcmUgdGhlaXIgZmlyc3QgZGF5IGRlY2lzaW9uIHRvIGtlZXAgd2l0aCBhIHR3aWNlIElFVEYg TEMgZmFpbGVkIGRvY3VtZW50LCBJIHByb3Bvc2VkIHRoZSBXRy1MVFJVIENoYWlycyB0byBjby13 cml0ZSB0aGUgRHJhZnRzIHNvIHdlIGNvdWxkIGZpbmlzaCB0aGUgd29yayBpbiBhIGZldyBtb250 aHMuIEkgb2J2aW91c2x5Jm5ic3A7Jm5ic3A7ZXZlbnR1YWxseSBnZXQgc3RlcCBieSBzdGVwIGFs bCB3aGF0IEkgd2FudGVkIC0gaW4gdGhlIGRvY3VtZW50cyBvciBpbiB0aGUgcmVhbCB3b3JsZDog YnV0IHdoYXQgYSB3YXN0ZSBvZiB0aW1lIGFuZCBlZmZvcnQpLiBDaGVlcnMuCjxicj48YnI+SSBy ZW1lbWJlciB3ZWxsIHRoYXQgc3BlY2lhbGx5IGF0IHRoZSBzdGFydCBvZiB0aGUgV0csIHRoZSBX RyBjby1jaGFpcnM8YnI+cmVwZWF0ZWRseSBhc2tlZCBmb3IgYWN0dWFsIHRleHR1YWwgY29udHJp YnV0aW9ucy4gVGhlc2Ugd2VyZSBmZXcgYW5kIGZhcjxicj5iZXR3ZWVuLCBhbmQgd2VyZSB1c3Vh bGx5IHJlamVjdGVkIGJ5IHRoZSBXRyBhZnRlciBzb21lIGRpc2N1c3Npb24uCjxicj48YnI+PGJy PlJlZ2FyZHMsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWFydGluLjxicj48YnI+PGJyPjxicj4j LSMtIyZuYnNwOyZuYnNwO01hcnRpbiBKLiBEdSZxdW90O3JzdCwgQXNzb2MuIFByb2Zlc3Nvciwg QW95YW1hIEdha3VpbiBVbml2ZXJzaXR5PGJyPiMtIy0jJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0 cDovL3d3dy5zdy5pdC5hb3lhbWEuYWMuanAiPmh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpw PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYWlsdG86PGEgaHJlZj0i bWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMuanAiPgpkdWVyc3RAaXQuYW95YW1hLmFjLmpwPC9h Pjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3Jn Ij5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sdHJ1CjwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_355_31924196.1150940374828-- --===============1219421848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1219421848==-- From ltru-bounces@ietf.org Wed Jun 21 23:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFRw-0005vT-7c; Wed, 21 Jun 2006 23:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFRv-0005vO-8B for ltru@ietf.org; Wed, 21 Jun 2006 23:01:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFRs-0005xn-0e for ltru@ietf.org; Wed, 21 Jun 2006 23:01:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FtFRr-0001L2-EV; Wed, 21 Jun 2006 23:01:39 -0400 Date: Wed, 21 Jun 2006 23:01:39 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Charter Discussion Message-ID: <20060622030139.GT22961@ccil.org> References: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > RFC 3066 does not seem to approach the scope of this work at all as > far as the number of data elements it contains. It seems to me that > ISO 11179 is more appropriate for registries with a larger number of > metadata types -- something on the IANA scale, not just RFC 3066. A cursory look at parts of 11179 leads me to agree; the Language Subtag Registry is not a "metadata registry" in the relevant sense. The metadata registry for language subtags would list the field names in the registry such as "Subtag:", "Description", "Comment:", etc. etc., and is simply too trivial to warrant the application of 11179. So I withdraw my support for considering 11179 in the new charter. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 21 23:38:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtG1j-0004dt-Mi; Wed, 21 Jun 2006 23:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtG1i-0004dl-TO for ltru@ietf.org; Wed, 21 Jun 2006 23:38:42 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtG1g-00034E-Jx for ltru@ietf.org; Wed, 21 Jun 2006 23:38:42 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c125.corp.yahoo.com [10.72.76.125]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5M3cNrm077893; Wed, 21 Jun 2006 20:38:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to: thread-index:x-mimeole; b=QwLdBExvvEn08NgdhesB8M05/VdgkL+OFRo1JTvxg1sjyhdDscgPkA8D7PUGJsqf From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) Date: Wed, 21 Jun 2006 20:38:23 -0700 Message-ID: <001101c695ad$51c23240$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060622102328.076eb700@localhost> Thread-Index: AcaVnIenOX4zC9xaQO6mI30u8F3qiQAEGxuw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I will attend to this in the morning, running the usual tools, the spell checker, and so forth on the finished document, along with a diff. Could you please send me a complete list of the issues (or remind me of the link)? I would like to ensure that I don't miss anything. Once I have done this, I will post it on inter-locale and announce it on the list. Should I proceed to submit it or wait for comments/instructions? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: mercredi 21 juin 2006 18:30 > To: Addison Phillips; Mark Davis > Cc: LTRU Working Group; Ted Hardie > Subject: Moving forward (Was: [Ltru] matching draft, issue 50) > > [co-chair hat (or actually, shepherd hat) on] > > The IETF Last Call has ended. I'd like to move forward, at least > with issues that seem to have reached consensus (mostly by nobody > bringing up any opposing views, which is fine for the minor > editorial issues that we are dealing with at the moment). > > The reply from John below is the only reply on issue 50 that I have > seen on the list. > > Absent sudden disagreement, I would like to instruct the editors > to prepare a new version of the draft with variant C for the Abstract, > as well as with the other edits as described in > http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, > and a diff to the -14 version. > > Regards, Martin. > > > At 22:53 06/06/16, John Cowan wrote: > >Martin Duerst scripsit: > > > >> BTW, as a technical contributor, my preference is C before D before > >> B before A. > > > >+1 > > > >-- > >John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > Is it not written, "That which is written, is written"? > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 02:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIpH-0003mg-9u; Thu, 22 Jun 2006 02:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIpF-0003mb-Mr for ltru@ietf.org; Thu, 22 Jun 2006 02:38:01 -0400 Received: from mailb.microsoft.com ([131.107.1.8] helo=mail3.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIpE-0005z9-Ak for ltru@ietf.org; Thu, 22 Jun 2006 02:38:01 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Wed, 21 Jun 2006 23:37:59 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 23:37:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 23:37:09 -0700 Message-ID: In-Reply-To: <20060621154759.GL22961@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaVSh5ywpRcxJK+TOOFz39v57B3OAAd/9TQ From: "Peter Constable" To: X-OriginalArrivalTime: 22 Jun 2006 06:37:59.0242 (UTC) FILETIME=[67196AA0:01C695C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > Sent: Wednesday, June 21, 2006 8:48 AM > > I'd be stronger about it. Unless someone can present some good > > reasons beforehand for even wanting to consider [ISO 11179], we = should > > definitely not put it in the charter. >=20 > The reason for *considering* it is that it's an international standard > that is germane to what we are doing. If we put it in the charter > and no one presents sufficiently compelling arguments for using it, > we simply say that n default of such arguments we have not used 11179. There are probably two reasons for implementing a product to conform to = an ISO standard: a) it is a de facto industry standard in widespread adoption and for = that basically is essential to success of the product (e.g. ISO 9000)=20 b) it is a requirement for the product to be acceptable to governmental = agencies It will rarely be the case that the reason for implement a product to = conform to an ISO standard is c) even though it's not widely adopted it holds fantastic innovations = with cool benefits In our situation:=20 - I see no indication that (a) holds wrt ISO 11179.=20 - Re (b), it's possible that some agencies such as UNESCO might get = hooked on ISO 11179, but at present I see no indication that IETF = standards-track and best-practice documents are considered = insufficiently propped up for governmental acceptance except perhaps in = a very limited set of currently-hot areas, such as DNS -- and even in = those cases I don't see adoption of something like ISO 11179 being a = particular point of government concern. - Re (c), I don't see any strongly-felt need in our work that ISO 11179 = provides a solution for. IIUC, it defines a model for creation of = meta-data registries -- both a conceptual model for the information = system that constitutes the registry (the infrastructure of the registry = as well as the content therein) as well as processes for the maintenance = and administration. We already have a registry in place, one that has a = fairly-well defined conceptual model (in spite of current debate over = certain details) and also established processes for maintenance and = administration -- processes with respect to which we have limitations in = our flexibility to change. Now, I'm sure that if we studied ISO 11179 we = would gain a better understanding of the nature of our endeavour and = that we would find ways to improve upon what we have. But, I cannot say = whether the cost/benefit ratio would be on the benefit side. The most I = can say is that I have not seen reasons to set an expectation of greater = benefit than cost. So, I'm not in principle opposed to use of ISO 11179 and would certainly = be open to someone providing a concrete explanation of how this = endeavour would benefit from it. I just am not aware of any compelling = benefits at this time.=20 (Which is basically what I said about 18 months ago when a certain = individual was insisting RFC3066bis needed to incorporate conformance to = ISO 11179. Oh, and as I also said then, I don't think ISO 11179 actually = defines any conformance criteria, so I don't think one can really talk = about "conformance to ISO 11179" in any formal sense.) Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 02:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtItB-0007Dc-BC; Thu, 22 Jun 2006 02:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtItA-0007DV-8N for ltru@ietf.org; Thu, 22 Jun 2006 02:42:04 -0400 Received: from mailb.microsoft.com ([131.107.1.8] helo=mail3.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIt8-0006X8-Vs for ltru@ietf.org; Thu, 22 Jun 2006 02:42:04 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Wed, 21 Jun 2006 23:42:02 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Wed, 21 Jun 2006 23:42:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter Discussion Date: Wed, 21 Jun 2006 23:41:24 -0700 Message-ID: In-Reply-To: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaVSh6XLzg3h1s7TYy9bSw2tecMPwAAPjhgAB7eFJA= From: "Peter Constable" To: X-OriginalArrivalTime: 22 Jun 2006 06:42:02.0256 (UTC) FILETIME=[F7F26900:01C695C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Wednesday, June 21, 2006 9:19 AM > I see merit in limiting the scope of a revision to 3066bis. We have > struggled long and mightily to produce 3066bis. There are very few = changes > necessary to incorporate ISO 639-3, which is the reason for producing = a > revision. Any additional things we might undertake would need to be = really > compelling in order for me to support them. +1 The relative importance to incorporate ISO 639-3 over implementation of = ISO 11179 is, IMO, a couple of orders of magnitude. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 05:14:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLGT-00074d-Q3; Thu, 22 Jun 2006 05:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLGS-00074U-Ez for ltru@ietf.org; Thu, 22 Jun 2006 05:14:16 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtLGO-00079e-KG for ltru@ietf.org; Thu, 22 Jun 2006 05:14:16 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5M9E97I005572 for ; Thu, 22 Jun 2006 18:14:09 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 2a65_76667a50_01cf_11db_852f_0014221fa3c9; Thu, 22 Jun 2006 18:14:08 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5M9E4mC007083 for ; Thu, 22 Jun 2006 18:14:09 +0900 Message-Id: <6.0.0.20.2.20060622104117.03ba6c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 22 Jun 2006 17:12:17 +0900 To: "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part. In-Reply-To: <6.0.0.20.2.20060619152554.076ad7d0@localhost> References: <6.0.0.20.2.20060619152554.076ad7d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a co-chair, I have tried to make the comments mentioned in the mail below into issues. Because most of the comments are a mix of different issues, and many issues appear in repeated comments, there is no one-to-one correspondence. Also, there are some (parts of) comments that are addressed directly to the IESG, are un-understandable, or are otherwise not issues that the WG has to look into and address if necessary. These are marked as such if necessary. As usual, the list of Last Call Comments can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. If you think that anything in the issues list is wrong, please don't hesitate to point it out. At 15:28 06/06/19, Martin Duerst wrote: >Dear LTRU mailing list, > >This series of Last Call comments on the matching draft came >through on the main IETF list. I'm forwarding it here for >further discussion. > >Regards, Martin. > >>Date: Sun, 18 Jun 2006 16:56:00 +0200 >>To: ietf@ietf.org >>From: "JFC (Jefsey) Morfin" >>Subject: Last call: BCP 47 second part. >>List-Id: IETF-Discussion >>List-Unsubscribe: >, >>List-Post: >>List-Help: >>List-Subscribe: >, > >>Dear IESG Members, >> >>1. The proposed Draft is not about matching (it is absurd to say that my >Italian can "match" your Japanese in order for us to understand each other >better). It is about using pattern matching techniques in order to filter >lists against a langtag with two results (max one answer, no max) and in >two cases (well formed langtag or not). Made this issue 53: Topic/purpose of draft not (completely) described >However, the wording is such that >without examples it is difficult to understand the specifications of the >pattern matching function that is being used This became issue 54: not enough examples for matching algorithms >- and therefore the possible >applications and the purpose of the Draft. back to issue 53 >The algorithm of this function >is undocumented and there is no obligation to document it, made this issue 55: algorithm is undocumented >what may lead to >blocking conflicts if two filters may have to interoperate. This >proposition is NOT scalable and does not intent to be scalable. made this issue 56: scalability/interoperability problem >>2. Either RFC 3066 Bis is well written (what I think we achieved if >strictly limited to the Internationalized ASCII Internet) and well applied >(what I can see that it is not the case: the review mechanism does not >respect RFC 3066 Bis) and the filtering is already built-in, and the >functional strategies are to be specific to applications and protocols. Or >that Draft, which does not seek to first ensure that langtags respect RFC >3066 Bis (i.e. being well formed or corrected in order to become well >formed), is a negation of RFC 3066 Bis. Created issue 57: matching draft does not respect registry draft (no requirement for well-formedness) >I think that authors had filtering >in mind (it was the apex of the first unique document) and did not realise >that the work achieved in cleaning the first part made its correction by >the second part not necessary anymore. That is if the whole purpose was not >a non documented use of the filtering (users mass profiling). If it was not >the whole document can be written as "make sure langtags are well formed >and feed them on the pattern > matching function of your application/protocol to obtain the results it >needs along your language management strategy". Created issue 58: No need to describe specific matching schemes >>3. "*" restrictions in the pattern matching function can hardly be >understood without several examples. back to issue 54 >They add usage limitations to the RFC >3066 Bis format, added issue 59: wildcards add usage limitations to registry draft >where they should be documented $B%e(B or the Draft cannot be >part of BCP 47. This certainly belongs to the language constraining >strategy of the WG-LTRU affinity group and to the interests a co-Chair >recently documented. But this is unacceptable to most users, even if it is >certainly favourable to a national strategy and to the members of a given >consortium. I therefore submit that the IESG Members who are citizens of >that nation, or members, or employees of the members of that commercial >consortium have a COI. Potential/purported conflicts of interest for IESG Members are not a topic for the WG. >>4. All the above means that the Draft is useful in at least two circumstances: >> - if the langtags are not well formed or do not respect the principles >of ISO 639-4 and/or RFC 3066 Bis. >> - if the langtags are used for other purposes that are undocumented at >the WG-LTRU Charter. >>These circumstances should be documented. subsumed under issue 53 >>5. The security section should mention that this Daft encourages the >disrespect of the RFC 3066 Bis format and further assists dangerous >projects that the IETF has refused to mention in RFC 3066 Bis, such as >lingual, cultural, racial, and religious profiling through retro-meta-spam >("I know who you are through which langtags you are not aware that you >respond to"), two-tier Internet based upon the lingual characteristics of >the users and their supposed market value, lack of conformance to ISO >11179, which may lead the IETF, stakeholders, and users to inadequate, >costly, and delaying strategies or to conflicts with the Multilingual >Internet - as in the sad DoS against the leading economic language >("en-EU") - or to legal access bans by democratic or privacy oriented >countries. All of this lends itself to incentives for an Internet fragmentation. Created issue 60: security section should mention potential for language-based censuring,... >>6. As far as I understand, two Draft compliant filters may result in >different responses for the same filtering list and document. My concern is >the interoperability of the proposed BCP 47 with Multilingual Internet >registries, tags, etc. This interoperability is not ensured $B%e(B and there is >no prospect to see it insured as it is purposely ignored by authors. This >represents no incentive for developers. subsumed under issue 56 >>7. The acknowledgement section mostly quote those who contributed to the >pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation >of the WG which never studied and tried to conform to its Charter). This is >the privilege of authors to quote who supported them best. However, in this >case the document was considerably cleaned through the tough life of the >WG. Also, most of the names being quoted are widely known as belonging to a >non-IETF affinity group, what enforces the external understanding that BCP >47 documents are actually not IETF documents. This will most probably limit >their consideration. After one year of tough debates I can testify these, >good or not, three documents are IETF documents for the Internationalized >ASCII Internet. I listed the names I consider missing in a Last C all mail. >> >>Authors either did not read it or are keeping harassing me, since they >continue asking for an input. I quote my mail: "every contribution can be a >key stone in the final construct. That people like Michael Everson, Ned >Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex >Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam >Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. >Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce >are real.". I do not ask my name to be listed there since I know "it is not >[the] interest [of some in the list] to be associated with [my own] name". >> >>Or would that mean that the IETF does not really back this deliverable? >The question here is: does the IETF wants to influence the world (RFC >3935), document the Internationalised ASCII Internet, or serve the >Multilingual Internet development. Many would like to know. This is already issue 52. Regards, Martin. >>All the best. >>jfc >> >>PS. Having transparency in mind I copy the IETF main list. This LC ends >tomorrow. I do not intent to address the comments. But I will certainly >consider them in the appeal I suspect to be unfortunately necessary (NB. >Before their first day decision to keep with a twice IETF LC failed >document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could >finish the work in a few months. I obviously eventually get step by step >all what I wanted - in the documents or in the real world: but what a waste >of time and effort). Cheers. >> >> >>jfc >> >> >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 08:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNva-0002NU-In; Thu, 22 Jun 2006 08:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNvZ-0002Mt-Dc for ltru@ietf.org; Thu, 22 Jun 2006 08:04:53 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNvW-0007HJ-U9 for ltru@ietf.org; Thu, 22 Jun 2006 08:04:53 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 2563E1E15BE; Thu, 22 Jun 2006 05:04:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jun 2006 05:04:50 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE4F@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Addison Phillips' , 'Martin Duerst' , 'Mark Davis' Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) Date: Thu, 22 Jun 2006 05:04:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Addison, Don't wait very long for comments. The cutoff for submission of a revised I-D is Monday 26 June - after which there is a three week blackout of I-D processing. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Wednesday, June 21, 2006 11:38 PM > To: 'Martin Duerst'; 'Mark Davis' > Cc: 'LTRU Working Group' > Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) > > > I will attend to this in the morning, running the usual > tools, the spell > checker, and so forth on the finished document, along with a diff. > > Could you please send me a complete list of the issues (or > remind me of the > link)? I would like to ensure that I don't miss anything. > > Once I have done this, I will post it on inter-locale and > announce it on the > list. Should I proceed to submit it or wait for comments/instructions? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: mercredi 21 juin 2006 18:30 > > To: Addison Phillips; Mark Davis > > Cc: LTRU Working Group; Ted Hardie > > Subject: Moving forward (Was: [Ltru] matching draft, issue 50) > > > > [co-chair hat (or actually, shepherd hat) on] > > > > The IETF Last Call has ended. I'd like to move forward, at least > > with issues that seem to have reached consensus (mostly by nobody > > bringing up any opposing views, which is fine for the minor > > editorial issues that we are dealing with at the moment). > > > > The reply from John below is the only reply on issue 50 that I have > > seen on the list. > > > > Absent sudden disagreement, I would like to instruct the editors > > to prepare a new version of the draft with variant C for > the Abstract, > > as well as with the other edits as described in > > http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, > > and a diff to the -14 version. > > > > Regards, Martin. > > > > > > At 22:53 06/06/16, John Cowan wrote: > > >Martin Duerst scripsit: > > > > > >> BTW, as a technical contributor, my preference is C > before D before > > >> B before A. > > > > > >+1 > > > > > >-- > > >John Cowan cowan@ccil.org http://www.ccil.org/~cowan > > > Is it not written, "That which is written, is written"? > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp > > mailto:duerst@it.aoyama.ac.jp > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.9.2/372 - Release > Date: 6/21/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.2/372 - Release Date: 6/21/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQqJ-0000aM-Q2; Thu, 22 Jun 2006 11:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQqJ-0000Xi-6M for ltru@ietf.org; Thu, 22 Jun 2006 11:11:39 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQqG-00080k-Rx for ltru@ietf.org; Thu, 22 Jun 2006 11:11:39 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c125.corp.yahoo.com [10.72.76.125]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5MFB6i0099723; Thu, 22 Jun 2006 08:11:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to: thread-index:x-mimeole; b=zFF7jLEE6JG8L5ty8UWCod7ZfsT1VmDyLVrrhrlEk6mNQFQo161Ybu69jZ5iPl3c From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) Date: Thu, 22 Jun 2006 08:11:06 -0700 Message-ID: <001601c6960e$167cbd20$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060622152711.03bc45c0@localhost> Thread-Index: AcaV3E8n6d5VHhsvTQyM3srbsuPqWgAMPqOw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All done. New draft posted. Diff link included. diff: http://tinyurl.com/ektzx http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.xml Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: jeudi 22 juin 2006 00:39 > To: Addison Phillips; 'Mark Davis' > Cc: 'LTRU Working Group'; 'Ted Hardie' > Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) > > At 12:38 06/06/22, Addison Phillips wrote: > >I will attend to this in the morning, running the usual > tools, the spell > >checker, and so forth on the finished document, along with a diff. > > > >Could you please send me a complete list of the issues (or > remind me of the > >link)? I would like to ensure that I don't miss anything. > > Most of the issues are listed in the link below; the actual > issues list is at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ > as always. > > >Once I have done this, I will post it on inter-locale and > announce it on the > >list. > > Great, thanks. > > >Should I proceed to submit it or wait for comments/instructions? > > Please wait, unless you are not available at all on Friday or over > the weekend. > > Regards, Martin. > > >Addison > > > >Addison Phillips > >Internationalization Architect - Yahoo! Inc. > > > >Internationalization is an architecture. > >It is not a feature. > > > >> -----Original Message----- > >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > >> Sent: mercredi 21 juin 2006 18:30 > >> To: Addison Phillips; Mark Davis > >> Cc: LTRU Working Group; Ted Hardie > >> Subject: Moving forward (Was: [Ltru] matching draft, issue 50) > >> > >> [co-chair hat (or actually, shepherd hat) on] > >> > >> The IETF Last Call has ended. I'd like to move forward, at least > >> with issues that seem to have reached consensus (mostly by nobody > >> bringing up any opposing views, which is fine for the minor > >> editorial issues that we are dealing with at the moment). > >> > >> The reply from John below is the only reply on issue 50 that I have > >> seen on the list. > >> > >> Absent sudden disagreement, I would like to instruct the editors > >> to prepare a new version of the draft with variant C for > the Abstract, > >> as well as with the other edits as described in > >> http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, > >> and a diff to the -14 version. > >> > >> Regards, Martin. > >> > >> > >> At 22:53 06/06/16, John Cowan wrote: > >> >Martin Duerst scripsit: > >> > > >> >> BTW, as a technical contributor, my preference is C > before D before > >> >> B before A. > >> > > >> >+1 > >> > > >> >-- > >> >John Cowan cowan@ccil.org http://www.ccil.org/~cowan > >> > Is it not written, "That which is written, is written"? > >> > >> > >> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > >> #-#-# http://www.sw.it.aoyama.ac.jp > >> mailto:duerst@it.aoyama.ac.jp > >> > >> > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 11:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR4I-0000CI-S9; Thu, 22 Jun 2006 11:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR4H-0000CD-Nz for ltru@ietf.org; Thu, 22 Jun 2006 11:26:05 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtR4G-0001hv-FW for ltru@ietf.org; Thu, 22 Jun 2006 11:26:05 -0400 Received: by wr-out-0506.google.com with SMTP id i23so408309wra for ; Thu, 22 Jun 2006 08:26:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JUXb4qmdtCHqWtCjnqkjwXnS17mycMn+Lyok14QccPq5Xl4/XUkZBrFmoFd1ivs6A7QSOuj+mCmcZGwCrDcbuheW/uVALD+Z2pvmxDxuM+bvOHM0Sx/7B1jWyrPDrrsg5AJW4Sc25DnFfgfCsbnE8ZrJFvJr0AZo/GIoMLyGbGY= Received: by 10.65.219.7 with SMTP id w7mr1498081qbq; Thu, 22 Jun 2006 08:26:04 -0700 (PDT) Received: by 10.65.148.20 with HTTP; Thu, 22 Jun 2006 08:26:03 -0700 (PDT) Message-ID: <30b660a20606220826n72b9b3dco5808ff268b0ca4a9@mail.gmail.com> Date: Thu, 22 Jun 2006 08:26:03 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Charter Discussion In-Reply-To: MIME-Version: 1.0 References: <004c01c6954e$5d862d20$650a0a0a@ds.corp.yahoo.com> X-Google-Sender-Auth: 3bcd4415541ac353 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739284084==" Errors-To: ltru-bounces@ietf.org --===============0739284084== Content-Type: multipart/alternative; boundary="----=_Part_6873_3908104.1150989963822" ------=_Part_6873_3908104.1150989963822 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On 6/21/06, Peter Constable wrote: > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > Sent: Wednesday, June 21, 2006 9:19 AM > > > I see merit in limiting the scope of a revision to 3066bis. We have > > struggled long and mightily to produce 3066bis. There are very few > changes > > necessary to incorporate ISO 639-3, which is the reason for producing a > > revision. Any additional things we might undertake would need to be > really > > compelling in order for me to support them. > > +1 > > The relative importance to incorporate ISO 639-3 over implementation of > ISO 11179 is, IMO, a couple of orders of magnitude. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_6873_3908104.1150989963822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1

On 6/21/06, Peter Constable <petercon@microsoft.com> wrote:
> From: Addison Phillips [mailto:addison@yahoo-inc.com]
> Sent: Wednesday, June 21, 2006 9:19 AM

> I see merit in limiting the scope of a revision to 3066bis. We have
> struggled long and mightily to produce 3066bis. There are very few changes
> necessary to incorporate ISO 639-3, which is the reason for producing a
> revision. Any additional things we might undertake would need to be really
> compelling in order for me to support them.

+1

The relative importance to incorporate ISO 639-3 over implementation of ISO 11179 is, IMO, a couple of orders of magnitude.



Peter Constable

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

------=_Part_6873_3908104.1150989963822-- --===============0739284084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0739284084==-- From ltru-bounces@ietf.org Thu Jun 22 13:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSwF-0004Db-IQ; Thu, 22 Jun 2006 13:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSwF-0004DS-37 for ltru@ietf.org; Thu, 22 Jun 2006 13:25:55 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSwD-00025t-Pc for ltru@ietf.org; Thu, 22 Jun 2006 13:25:55 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060622172546.HWCQ13077.mta13.adelphia.net@DGBP7M81> for ; Thu, 22 Jun 2006 13:25:46 -0400 Message-ID: <005201c69620$e4384290$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Charter Discussion Date: Thu, 22 Jun 2006 10:25:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > ... We already have a registry in place, one that has a fairly-well > defined conceptual model (in spite of current debate over certain > details) and also established processes for maintenance and > administration -- processes with respect to which we have limitations > in our flexibility to change. I think the "current debate over certain details" is a sign that it might be worthwhile to define the conceptual model more clearly. There is a significant disparity between list members' views of the purpose of the Description field: is it a cross-reference to ISO standards, a string that uniquely identifies the language (script, etc.), an English translation, a language-dependent transliteration, or a prescriptive spelling with "recommended" letters and punctuation? At the very least, even if we decide not to adopt ISO 11179 principles, we should answer this particular question more definitively. > Now, I'm sure that if we studied ISO 11179 we would gain a better > understanding of the nature of our endeavour and that we would find > ways to improve upon what we have. But, I cannot say whether the > cost/benefit ratio would be on the benefit side. The most I can say is > that I have not seen reasons to set an expectation of greater benefit > than cost. All that is being suggested is that we not reject this effort a priori. A few people who are well-versed in the standard can explain its principles to others, and a reasonably well-informed discussion can proceed from there. It's not necessary for every list member to read all 266 pages. I doubt every LTRU member has read ISO 639, 3166, and 15924 in their entirety either. > The relative importance to incorporate ISO 639-3 over implementation > of ISO 11179 is, IMO, a couple of orders of magnitude. Nobody has suggested that we would have to make a choice between incorporating 639-3 and implementing 11179. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 22 14:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTdc-0000G6-5Y; Thu, 22 Jun 2006 14:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTdb-0000Ff-3h for ltru@ietf.org; Thu, 22 Jun 2006 14:10:43 -0400 Received: from maila.microsoft.com ([131.107.1.6] helo=mail1.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTdZ-0004ka-Qp for ltru@ietf.org; Thu, 22 Jun 2006 14:10:43 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:10:41 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:10:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Charter Discussion Date: Thu, 22 Jun 2006 11:10:09 -0700 Message-ID: In-Reply-To: <005201c69620$e4384290$040aa8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter Discussion Thread-Index: AcaWIO/734fjEDGBR4aoUJedHIxSFAABeSQA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 22 Jun 2006 18:10:41.0046 (UTC) FILETIME=[2BDD6B60:01C69627] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1315676301==" Errors-To: ltru-bounces@ietf.org --===============1315676301== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldF0NCj4gU2VudDog VGh1cnNkYXksIEp1bmUgMjIsIDIwMDYgMTA6MjYgQU0NCg0KDQo+IEkgdGhpbmsgdGhlICJjdXJy ZW50IGRlYmF0ZSBvdmVyIGNlcnRhaW4gZGV0YWlscyIgaXMgYSBzaWduIHRoYXQgaXQNCj4gbWln aHQgYmUgd29ydGh3aGlsZSB0byBkZWZpbmUgdGhlIGNvbmNlcHR1YWwgbW9kZWwgbW9yZSBjbGVh cmx5LiAgVGhlcmUNCj4gaXMgYSBzaWduaWZpY2FudCBkaXNwYXJpdHkgYmV0d2VlbiBsaXN0IG1l bWJlcnMnIHZpZXdzIG9mIHRoZSBwdXJwb3NlIG9mDQo+IHRoZSBEZXNjcmlwdGlvbiBmaWVsZC4u Lg0KDQo+IEF0IHRoZSB2ZXJ5IGxlYXN0LCBldmVuIGlmIHdlIGRlY2lkZSBub3QgdG8gYWRvcHQg SVNPIDExMTc5IHByaW5jaXBsZXMsDQo+IHdlIHNob3VsZCBhbnN3ZXIgdGhpcyBwYXJ0aWN1bGFy IHF1ZXN0aW9uIG1vcmUgZGVmaW5pdGl2ZWx5Lg0KDQpTdXJlLiBCdXQgSSBkb24ndCB0aGluayBp bXBsZW1lbnRpbmcgSVNPIDExMTc5IGlzIHBhcnRpY3VsYXJseSBnb2luZyB0byBoZWxwIHVzIGRl dGVybWluZSB3aGF0IHRoZSBwdXJwb3NlIG9mIHRoZSBEZXNjcmlwdGlvbiBmaWVsZCBpcy4gDQoN Cg0KDQpQZXRlciBDb25zdGFibGUNCg== --===============1315676301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1315676301==-- From ltru-bounces@ietf.org Fri Jun 23 07:38:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjzW-0004xH-Gb; Fri, 23 Jun 2006 07:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjzV-0004W9-9m for ltru@ietf.org; Fri, 23 Jun 2006 07:38:25 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtjzO-0008K1-L7 for ltru@ietf.org; Fri, 23 Jun 2006 07:38:21 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5NBbns5018383; Fri, 23 Jun 2006 20:37:49 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 457c_b2ca2fea_02ac_11db_8c11_0014221fa3c9; Fri, 23 Jun 2006 20:37:49 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5NBbh8k031161; Fri, 23 Jun 2006 20:37:45 +0900 Message-Id: <6.0.0.20.2.20060623183741.086c2420@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Jun 2006 20:35:00 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) In-Reply-To: <001601c6960e$167cbd20$650a0a0a@ds.corp.yahoo.com> References: <6.0.0.20.2.20060622152711.03bc45c0@localhost> <001601c6960e$167cbd20$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The diff link (both the tinyurl and the link on http://www.inter-locale.com/ don't seem to work. In both cases, my browser (Opera) shows that 520 bytes of a document (or of HTTP headers) have been read. Exactly the same happens with the other "generate a diff" links from that page. Addison, can you fix this, or ideally just put up a static diff? If not, I'll have to do the diff myself. Regards, Martin. At 00:11 06/06/23, Addison Phillips wrote: >All done. New draft posted. Diff link included. > >diff: http://tinyurl.com/ektzx > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.txt >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.html >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.xml > >Addison > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 23 10:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmV8-0005yR-JD; Fri, 23 Jun 2006 10:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmV6-0005yM-Pd for ltru@ietf.org; Fri, 23 Jun 2006 10:19:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtmV6-0000XE-NQ for ltru@ietf.org; Fri, 23 Jun 2006 10:19:12 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtmV0-0002Uf-6Y for ltru@ietf.org; Fri, 23 Jun 2006 10:19:12 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c132.corp.yahoo.com [10.72.76.132]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5NEHocZ009299; Fri, 23 Jun 2006 07:17:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-priority: x-msmail-priority:x-mailer:x-mimeole:thread-index:in-reply-to:importance; b=SAyUCnWlVrImxX/bsDkOFMpb7rV4eVqIuHq4iXHlM1ub9bb97z62GMn0ikjqC4ON From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) Date: Fri, 23 Jun 2006 07:17:50 -0700 Message-ID: <001001c696cf$cfe054e0$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaWuaxFgOaKv3avQVqbizwnbV7kDQAFbFzw In-Reply-To: <6.0.0.20.2.20060623183741.086c2420@localhost> Importance: High X-Spam-Score: -16.5 (----------------) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It works for me (Mozilla 1.7 or Firefox). The full URL is: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.inter-local e.com/ID/draft-ietf-ltru-matching-14.txt&url2=http://www.inter-locale.com/ID /draft-ietf-ltru-matching-15.txt But since you ask... try: http://www.inter-locale.com/ID/matching-14-15-diff.html Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: vendredi 23 juin 2006 04:35 > To: Addison Phillips; 'Mark Davis' > Cc: 'LTRU Working Group'; 'Ted Hardie' > Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) > > The diff link (both the tinyurl and the link on > http://www.inter-locale.com/ don't seem to work. > In both cases, my browser (Opera) shows that 520 > bytes of a document (or of HTTP headers) have been > read. Exactly the same happens with the other > "generate a diff" links from that page. > > Addison, can you fix this, or ideally just put > up a static diff? If not, I'll have to do the > diff myself. > > Regards, Martin. > > At 00:11 06/06/23, Addison Phillips wrote: > >All done. New draft posted. Diff link included. > > > >diff: http://tinyurl.com/ektzx > > > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.txt > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.html > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-15.xml > > > >Addison > > > >Addison Phillips > >Internationalization Architect - Yahoo! Inc. > > > >Internationalization is an architecture. > >It is not a feature. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 23 22:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fty1i-00015K-DZ; Fri, 23 Jun 2006 22:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fty1h-000159-2p for ltru@ietf.org; Fri, 23 Jun 2006 22:37:37 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fty1e-0007tx-CB for ltru@ietf.org; Fri, 23 Jun 2006 22:37:37 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5O2bVMb028972; Sat, 24 Jun 2006 11:37:31 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1a84_626d04e0_032a_11db_8e85_0014221f2a2d; Sat, 24 Jun 2006 11:37:30 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5O2bK38012784; Sat, 24 Jun 2006 11:37:23 +0900 Message-Id: <6.0.0.20.2.20060624103110.09743c30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 24 Jun 2006 11:22:02 +0900 To: "Addison Phillips" , Mark Davis From: Martin Duerst Subject: Re: Moving forward (Was: [Ltru] matching draft, issue 50) In-Reply-To: <6.0.0.20.2.20060622102328.076eb700@localhost> References: <6.0.0.20.2.20060616191343.076930d0@localhost> <20060616135307.GB32743@ccil.org> <6.0.0.20.2.20060622102328.076eb700@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Addison, Mark, At 10:29 06/06/22, Martin Duerst wrote: >[co-chair hat (or actually, shepherd hat) on] > >The IETF Last Call has ended. I'd like to move forward, at least >with issues that seem to have reached consensus (mostly by nobody >bringing up any opposing views, which is fine for the minor >editorial issues that we are dealing with at the moment). > >The reply from John below is the only reply on issue 50 that I have >seen on the list. > >Absent sudden disagreement, I would like to instruct the editors >to prepare a new version of the draft with variant C for the Abstract, >as well as with the other edits as described in >http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, >and a diff to the -14 version. I have checked all the changes you have made based on the diff at http://www.inter-locale.com/ID/matching-14-15-diff.html. Many thanks for your work. Everything looks okay to me except the Abstract where you have chosen variant D instead of variant C. In http://www1.ietf.org/mail-archive/web/ltru/current/msg04978.html, I asked for preferences for various versions. Only John Covan and me expressed preferences, both for C. I have then asked you to use variant C in the mail above, and have also put that on the issues list. I don't care about this issue too much, but I'd like to make sure it is handled properly. Can you please change to variant C, or explain why you really and seriously want variant D? If you use variant C, please go ahead and submit a new version. If you prefer variant D, please say so. Regards, Martin. >At 22:53 06/06/16, John Cowan wrote: >>Martin Duerst scripsit: >> >>> BTW, as a technical contributor, my preference is C before D before >>> B before A. >> >>+1 >> >>-- >>John Cowan cowan@ccil.org http://www.ccil.org/~cowan >> Is it not written, "That which is written, is written"? #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 23 22:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fty1z-0001Ol-NL; Fri, 23 Jun 2006 22:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fty1x-0001Ks-W7 for ltru@ietf.org; Fri, 23 Jun 2006 22:37:54 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fty1x-00084f-4V for ltru@ietf.org; Fri, 23 Jun 2006 22:37:53 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k5O2bpvt026628 for ; Sat, 24 Jun 2006 11:37:51 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1a39_6ea5eb50_032a_11db_950d_0014221f2a2d; Sat, 24 Jun 2006 11:37:51 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5O2boTv012789 for ; Sat, 24 Jun 2006 11:37:50 +0900 Message-Id: <6.0.0.20.2.20060624112325.09740860@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 24 Jun 2006 11:35:28 +0900 To: "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part. In-Reply-To: <6.0.0.20.2.20060622104117.03ba6c40@localhost> References: <6.0.0.20.2.20060619152554.076ad7d0@localhost> <6.0.0.20.2.20060622104117.03ba6c40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan and Mark Davis have agreed with my assessment (as a technical contributor) in http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html about how to (not!) deal with the issues below. I have not seen any other comments. I have therefore (as a co-chair/shepherd) marked the issues as 'rejected' or 'irrelevant' (the later for issues where it's not clear how the issue could have possibly been addressed). All the issues from the IETF Last Call are now closed, (see http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/) so that we should be able to move ahead soon. Regards, Martin. At 17:12 06/06/22, Martin Duerst wrote: >As a co-chair, I have tried to make the comments mentioned >in the mail below into issues. Because most of the comments >are a mix of different issues, and many issues appear in >repeated comments, there is no one-to-one correspondence. > >Also, there are some (parts of) comments that are addressed >directly to the IESG, are un-understandable, or are otherwise >not issues that the WG has to look into and address if necessary. >These are marked as such if necessary. > >As usual, the list of Last Call Comments can be found at >http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. If you think >that anything in the issues list is wrong, please don't >hesitate to point it out. > >At 15:28 06/06/19, Martin Duerst wrote: >>Dear LTRU mailing list, >> >>This series of Last Call comments on the matching draft came >>through on the main IETF list. I'm forwarding it here for >>further discussion. >> >>Regards, Martin. >> >>>Date: Sun, 18 Jun 2006 16:56:00 +0200 >>>To: ietf@ietf.org >>>From: "JFC (Jefsey) Morfin" >>>Subject: Last call: BCP 47 second part. >>>List-Id: IETF-Discussion >>>List-Unsubscribe: >>, >>>List-Post: >>>List-Help: >>>List-Subscribe: >>, >> >>>Dear IESG Members, >>> >>>1. The proposed Draft is not about matching (it is absurd to say that my >>Italian can "match" your Japanese in order for us to understand each other >>better). It is about using pattern matching techniques in order to filter >>lists against a langtag with two results (max one answer, no max) and in >>two cases (well formed langtag or not). > >Made this issue 53: Topic/purpose of draft not (completely) described > >>However, the wording is such that >>without examples it is difficult to understand the specifications of the >>pattern matching function that is being used > >This became issue 54: not enough examples for matching algorithms > >>- and therefore the possible >>applications and the purpose of the Draft. > >back to issue 53 > > >>The algorithm of this function >>is undocumented and there is no obligation to document it, > >made this issue 55: algorithm is undocumented > >>what may lead to >>blocking conflicts if two filters may have to interoperate. This >>proposition is NOT scalable and does not intent to be scalable. > >made this issue 56: scalability/interoperability problem > > >>>2. Either RFC 3066 Bis is well written (what I think we achieved if >>strictly limited to the Internationalized ASCII Internet) and well applied >>(what I can see that it is not the case: the review mechanism does not >>respect RFC 3066 Bis) and the filtering is already built-in, and the >>functional strategies are to be specific to applications and protocols. Or >>that Draft, which does not seek to first ensure that langtags respect RFC >>3066 Bis (i.e. being well formed or corrected in order to become well >>formed), is a negation of RFC 3066 Bis. > >Created issue 57: matching draft does not respect registry draft >(no requirement for well-formedness) > >>I think that authors had filtering >>in mind (it was the apex of the first unique document) and did not realise >>that the work achieved in cleaning the first part made its correction by >>the second part not necessary anymore. That is if the whole purpose was not >>a non documented use of the filtering (users mass profiling). If it was not >>the whole document can be written as "make sure langtags are well formed >>and feed them on the pattern >> matching function of your application/protocol to obtain the results it >>needs along your language management strategy". > >Created issue 58: No need to describe specific matching schemes > >>>3. "*" restrictions in the pattern matching function can hardly be >>understood without several examples. > >back to issue 54 > >>They add usage limitations to the RFC >>3066 Bis format, > >added issue 59: wildcards add usage limitations to registry draft > >>where they should be documented $B%e(B or the Draft cannot be >>part of BCP 47. This certainly belongs to the language constraining >>strategy of the WG-LTRU affinity group and to the interests a co-Chair >>recently documented. But this is unacceptable to most users, even if it is >>certainly favourable to a national strategy and to the members of a given >>consortium. I therefore submit that the IESG Members who are citizens of >>that nation, or members, or employees of the members of that commercial >>consortium have a COI. > >Potential/purported conflicts of interest for IESG Members are >not a topic for the WG. > > >>>4. All the above means that the Draft is useful in at least two circumstances: >>> - if the langtags are not well formed or do not respect the principles >>of ISO 639-4 and/or RFC 3066 Bis. >>> - if the langtags are used for other purposes that are undocumented at >>the WG-LTRU Charter. >>>These circumstances should be documented. > >subsumed under issue 53 > > >>>5. The security section should mention that this Daft encourages the >>disrespect of the RFC 3066 Bis format and further assists dangerous >>projects that the IETF has refused to mention in RFC 3066 Bis, such as >>lingual, cultural, racial, and religious profiling through retro-meta-spam >>("I know who you are through which langtags you are not aware that you >>respond to"), two-tier Internet based upon the lingual characteristics of >>the users and their supposed market value, lack of conformance to ISO >>11179, which may lead the IETF, stakeholders, and users to inadequate, >>costly, and delaying strategies or to conflicts with the Multilingual >>Internet - as in the sad DoS against the leading economic language >>("en-EU") - or to legal access bans by democratic or privacy oriented >>countries. All of this lends itself to incentives for an Internet fragmentation. > >Created issue 60: security section should mention potential >for language-based censuring,... > > >>>6. As far as I understand, two Draft compliant filters may result in >>different responses for the same filtering list and document. My concern is >>the interoperability of the proposed BCP 47 with Multilingual Internet >>registries, tags, etc. This interoperability is not ensured $B%e(B and there is >>no prospect to see it insured as it is purposely ignored by authors. This >>represents no incentive for developers. > >subsumed under issue 56 > >>>7. The acknowledgement section mostly quote those who contributed to the >>pre-WG-LTRU document (the three WG-LTRU Draft existed prior to the creation >>of the WG which never studied and tried to conform to its Charter). This is >>the privilege of authors to quote who supported them best. However, in this >>case the document was considerably cleaned through the tough life of the >>WG. Also, most of the names being quoted are widely known as belonging to a >>non-IETF affinity group, what enforces the external understanding that BCP >>47 documents are actually not IETF documents. This will most probably limit >>their consideration. After one year of tough debates I can testify these, >>good or not, three documents are IETF documents for the Internationalized >>ASCII Internet. I listed the names I consider missing in a Last C all mail. >>> >>>Authors either did not read it or are keeping harassing me, since they >>continue asking for an input. I quote my mail: "every contribution can be a >>key stone in the final construct. That people like Michael Everson, Ned >>Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex >>Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam >>Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. >>Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce >>are real.". I do not ask my name to be listed there since I know "it is not >>[the] interest [of some in the list] to be associated with [my own] name". >>> >>>Or would that mean that the IETF does not really back this deliverable? >>The question here is: does the IETF wants to influence the world (RFC >>3935), document the Internationalised ASCII Internet, or serve the >>Multilingual Internet development. Many would like to know. > >This is already issue 52. > > >Regards, Martin. > >>>All the best. >>>jfc >>> >>>PS. Having transparency in mind I copy the IETF main list. This LC ends >>tomorrow. I do not intent to address the comments. But I will certainly >>consider them in the appeal I suspect to be unfortunately necessary (NB. >>Before their first day decision to keep with a twice IETF LC failed >>document, I proposed the WG-LTRU Chairs to co-write the Drafts so we could >>finish the work in a few months. I obviously eventually get step by step >>all what I wanted - in the documents or in the real world: but what a waste >>of time and effort). Cheers. >>> >>> >>>jfc >>> >>> >>> >>>_______________________________________________ >>>Ietf mailing list >>>Ietf@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ietf >> >> >>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >>#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 23 22:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtyMJ-00024r-Q1; Fri, 23 Jun 2006 22:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtyMH-00023A-UQ for ltru@ietf.org; Fri, 23 Jun 2006 22:58:53 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtyMD-0000rB-FP for ltru@ietf.org; Fri, 23 Jun 2006 22:58:53 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c86.corp.yahoo.com [10.72.72.86]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5O2vY01025458; Fri, 23 Jun 2006 19:57:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=SDRSmkxdL9ykNn9BUK3b9vmIyUjEDvws0tOFPVO+rVB1lVfzABmAd9QH6hAPrus0 From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) Date: Fri, 23 Jun 2006 19:57:34 -0700 Message-ID: <001501c69739$f1b83870$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXNz0Ojdstg2+zSTus9PIWPDs55wAAnwwg In-Reply-To: <6.0.0.20.2.20060624103110.09743c30@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My mistake. I have changed the xml source, regenerated the text and html versions and posted them to inter-locale.com. The dynamic link for the diff should still work (albeit not for you?). I'll regenerate a diff in a little while. Please confirm that the file is now correct. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: vendredi 23 juin 2006 19:22 > To: Addison Phillips; Mark Davis > Cc: LTRU Working Group; Ted Hardie > Subject: Re: Moving forward (Was: [Ltru] matching draft, issue 50) > > Hello Addison, Mark, > > At 10:29 06/06/22, Martin Duerst wrote: > >[co-chair hat (or actually, shepherd hat) on] > > > >The IETF Last Call has ended. I'd like to move forward, at least > >with issues that seem to have reached consensus (mostly by nobody > >bringing up any opposing views, which is fine for the minor > >editorial issues that we are dealing with at the moment). > > > >The reply from John below is the only reply on issue 50 that I have > >seen on the list. > > > >Absent sudden disagreement, I would like to instruct the editors > >to prepare a new version of the draft with variant C for the > Abstract, > >as well as with the other edits as described in > >http://www1.ietf.org/mail-archive/web/ltru/current/msg04979.html, > >and a diff to the -14 version. > > I have checked all the changes you have made based on the diff > at http://www.inter-locale.com/ID/matching-14-15-diff.html. > Many thanks for your work. > Everything looks okay to me except the Abstract where you have > chosen variant D instead of variant C. > > In http://www1.ietf.org/mail-archive/web/ltru/current/msg04978.html, > I asked for preferences for various versions. Only John Covan and > me expressed preferences, both for C. I have then asked you to use > variant C in the mail above, and have also put that on the issues > list. > > I don't care about this issue too much, but I'd like to make sure > it is handled properly. Can you please change to variant C, or > explain why you really and seriously want variant D? > > If you use variant C, please go ahead and submit a new version. > If you prefer variant D, please say so. > > Regards, Martin. > > >At 22:53 06/06/16, John Cowan wrote: > >>Martin Duerst scripsit: > >> > >>> BTW, as a technical contributor, my preference is C > before D before > >>> B before A. > >> > >>+1 > >> > >>-- > >>John Cowan cowan@ccil.org http://www.ccil.org/~cowan > >> Is it not written, "That which is written, is written"? > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 23 22:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtyN3-0005Cz-9L; Fri, 23 Jun 2006 22:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtyN1-0004tS-9K for ltru@ietf.org; Fri, 23 Jun 2006 22:59:39 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtyMz-000118-JI for ltru@ietf.org; Fri, 23 Jun 2006 22:59:39 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c86.corp.yahoo.com [10.72.72.86]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5O2wkLR025685; Fri, 23 Jun 2006 19:58:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=K7Jpi07lqLDz/Dy+kKsg4xC7ZTmrAAM0XRX45yalkdNDgheCgMCVbQnSsRXSQf8+ From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Fwd: Last call: BCP 47 second part. Date: Fri, 23 Jun 2006 19:58:46 -0700 Message-ID: <001601c6973a$1c55cc00$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXNz4/SBQxRifJTECDtyzrXk3kfgAAtcBw In-Reply-To: <6.0.0.20.2.20060624112325.09740860@localhost> X-Spam-Score: -14.4 (--------------) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FWIW, +1 for me as well. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: vendredi 23 juin 2006 19:35 > To: LTRU Working Group > Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part. > > John Cowan and Mark Davis have agreed with my assessment > (as a technical contributor) in > http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html > about how to (not!) deal with the issues below. I have not seen > any other comments. I have therefore (as a co-chair/shepherd) > marked the issues as 'rejected' or 'irrelevant' (the later for > issues where it's not clear how the issue could have possibly > been addressed). > > All the issues from the IETF Last Call are now closed, > (see http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/) > so that we should be able to move ahead soon. > > Regards, Martin. > > At 17:12 06/06/22, Martin Duerst wrote: > >As a co-chair, I have tried to make the comments mentioned > >in the mail below into issues. Because most of the comments > >are a mix of different issues, and many issues appear in > >repeated comments, there is no one-to-one correspondence. > > > >Also, there are some (parts of) comments that are addressed > >directly to the IESG, are un-understandable, or are otherwise > >not issues that the WG has to look into and address if necessary. > >These are marked as such if necessary. > > > >As usual, the list of Last Call Comments can be found at > >http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. If you think > >that anything in the issues list is wrong, please don't > >hesitate to point it out. > > > >At 15:28 06/06/19, Martin Duerst wrote: > >>Dear LTRU mailing list, > >> > >>This series of Last Call comments on the matching draft came > >>through on the main IETF list. I'm forwarding it here for > >>further discussion. > >> > >>Regards, Martin. > >> > >>>Date: Sun, 18 Jun 2006 16:56:00 +0200 > >>>To: ietf@ietf.org > >>>From: "JFC (Jefsey) Morfin" > >>>Subject: Last call: BCP 47 second part. > >>>List-Id: IETF-Discussion > >>>List-Unsubscribe: > >>, equest@ietf.org?subject=unsubscribe> > >>>List-Post: > >>>List-Help: > >>>List-Subscribe: > >>, equest@ietf.org?subject=subscribe> > >> > >>>Dear IESG Members, > >>> > >>>1. The proposed Draft is not about matching (it is absurd > to say that my > >>Italian can "match" your Japanese in order for us to > understand each other > >>better). It is about using pattern matching techniques in > order to filter > >>lists against a langtag with two results (max one answer, > no max) and in > >>two cases (well formed langtag or not). > > > >Made this issue 53: Topic/purpose of draft not (completely) described > > > >>However, the wording is such that > >>without examples it is difficult to understand the > specifications of the > >>pattern matching function that is being used > > > >This became issue 54: not enough examples for matching algorithms > > > >>- and therefore the possible > >>applications and the purpose of the Draft. > > > >back to issue 53 > > > > > >>The algorithm of this function > >>is undocumented and there is no obligation to document it, > > > >made this issue 55: algorithm is undocumented > > > >>what may lead to > >>blocking conflicts if two filters may have to interoperate. This > >>proposition is NOT scalable and does not intent to be scalable. > > > >made this issue 56: scalability/interoperability problem > > > > > >>>2. Either RFC 3066 Bis is well written (what I think we > achieved if > >>strictly limited to the Internationalized ASCII Internet) > and well applied > >>(what I can see that it is not the case: the review > mechanism does not > >>respect RFC 3066 Bis) and the filtering is already > built-in, and the > >>functional strategies are to be specific to applications > and protocols. Or > >>that Draft, which does not seek to first ensure that > langtags respect RFC > >>3066 Bis (i.e. being well formed or corrected in order to > become well > >>formed), is a negation of RFC 3066 Bis. > > > >Created issue 57: matching draft does not respect registry draft > >(no requirement for well-formedness) > > > >>I think that authors had filtering > >>in mind (it was the apex of the first unique document) and > did not realise > >>that the work achieved in cleaning the first part made its > correction by > >>the second part not necessary anymore. That is if the whole > purpose was not > >>a non documented use of the filtering (users mass > profiling). If it was not > >>the whole document can be written as "make sure langtags > are well formed > >>and feed them on the pattern > >> matching function of your application/protocol to obtain > the results it > >>needs along your language management strategy". > > > >Created issue 58: No need to describe specific matching schemes > > > >>>3. "*" restrictions in the pattern matching function can hardly be > >>understood without several examples. > > > >back to issue 54 > > > >>They add usage limitations to the RFC > >>3066 Bis format, > > > >added issue 59: wildcards add usage limitations to registry draft > > > >>where they should be documented $B%e(B or the Draft cannot be > >>part of BCP 47. This certainly belongs to the language constraining > >>strategy of the WG-LTRU affinity group and to the interests > a co-Chair > >>recently documented. But this is unacceptable to most > users, even if it is > >>certainly favourable to a national strategy and to the > members of a given > >>consortium. I therefore submit that the IESG Members who > are citizens of > >>that nation, or members, or employees of the members of > that commercial > >>consortium have a COI. > > > >Potential/purported conflicts of interest for IESG Members are > >not a topic for the WG. > > > > > >>>4. All the above means that the Draft is useful in at > least two circumstances: > >>> - if the langtags are not well formed or do not respect > the principles > >>of ISO 639-4 and/or RFC 3066 Bis. > >>> - if the langtags are used for other purposes that are > undocumented at > >>the WG-LTRU Charter. > >>>These circumstances should be documented. > > > >subsumed under issue 53 > > > > > >>>5. The security section should mention that this Daft > encourages the > >>disrespect of the RFC 3066 Bis format and further assists dangerous > >>projects that the IETF has refused to mention in RFC 3066 > Bis, such as > >>lingual, cultural, racial, and religious profiling through > retro-meta-spam > >>("I know who you are through which langtags you are not > aware that you > >>respond to"), two-tier Internet based upon the lingual > characteristics of > >>the users and their supposed market value, lack of > conformance to ISO > >>11179, which may lead the IETF, stakeholders, and users to > inadequate, > >>costly, and delaying strategies or to conflicts with the > Multilingual > >>Internet - as in the sad DoS against the leading economic language > >>("en-EU") - or to legal access bans by democratic or > privacy oriented > >>countries. All of this lends itself to incentives for an > Internet fragmentation. > > > >Created issue 60: security section should mention potential > >for language-based censuring,... > > > > > >>>6. As far as I understand, two Draft compliant filters may > result in > >>different responses for the same filtering list and > document. My concern is > >>the interoperability of the proposed BCP 47 with > Multilingual Internet > >>registries, tags, etc. This interoperability is not ensured > $B%e(B and there is > >>no prospect to see it insured as it is purposely ignored by > authors. This > >>represents no incentive for developers. > > > >subsumed under issue 56 > > > >>>7. The acknowledgement section mostly quote those who > contributed to the > >>pre-WG-LTRU document (the three WG-LTRU Draft existed prior > to the creation > >>of the WG which never studied and tried to conform to its > Charter). This is > >>the privilege of authors to quote who supported them best. > However, in this > >>case the document was considerably cleaned through the > tough life of the > >>WG. Also, most of the names being quoted are widely known > as belonging to a > >>non-IETF affinity group, what enforces the external > understanding that BCP > >>47 documents are actually not IETF documents. This will > most probably limit > >>their consideration. After one year of tough debates I can > testify these, > >>good or not, three documents are IETF documents for the > Internationalized > >>ASCII Internet. I listed the names I consider missing in a > Last C all mail. > >>> > >>>Authors either did not read it or are keeping harassing > me, since they > >>continue asking for an input. I quote my mail: "every > contribution can be a > >>key stone in the final construct. That people like Michael > Everson, Ned > >>Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel > Suignard, and Tex > >>Texin are not quotted seems odd. Others like Scott > Hollenbeck and Sam > >>Hartman really helped. What about Karen Broome, M.T. > Carrasco Benitez, N. > >>Piercei? Inputs or help from Brian Carpenter, Ted Hardie, > Dylan N. Pierce > >>are real.". I do not ask my name to be listed there since I > know "it is not > >>[the] interest [of some in the list] to be associated with > [my own] name". > >>> > >>>Or would that mean that the IETF does not really back this > deliverable? > >>The question here is: does the IETF wants to influence the > world (RFC > >>3935), document the Internationalised ASCII Internet, or serve the > >>Multilingual Internet development. Many would like to know. > > > >This is already issue 52. > > > > > >Regards, Martin. > > > >>>All the best. > >>>jfc > >>> > >>>PS. Having transparency in mind I copy the IETF main list. > This LC ends > >>tomorrow. I do not intent to address the comments. But I > will certainly > >>consider them in the appeal I suspect to be unfortunately > necessary (NB. > >>Before their first day decision to keep with a twice IETF LC failed > >>document, I proposed the WG-LTRU Chairs to co-write the > Drafts so we could > >>finish the work in a few months. I obviously eventually > get step by step > >>all what I wanted - in the documents or in the real world: > but what a waste > >>of time and effort). Cheers. > >>> > >>> > >>>jfc > >>> > >>> > >>> > >>>_______________________________________________ > >>>Ietf mailing list > >>>Ietf@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ietf > >> > >> > >>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > >>#-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > >> > >> > >>_______________________________________________ > >>Ltru mailing list > >>Ltru@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ltru > > > > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > >#-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 24 00:21:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftzea-0004DN-FI; Sat, 24 Jun 2006 00:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzeZ-0004DI-9T for ltru@ietf.org; Sat, 24 Jun 2006 00:21:51 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzeW-0002v4-MC for ltru@ietf.org; Sat, 24 Jun 2006 00:21:51 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5O4LhhG008359; Sat, 24 Jun 2006 13:21:43 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5ef7_f10eebba_0338_11db_8bb9_0014221fa3c9; Sat, 24 Jun 2006 13:21:42 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5O4LbH9014303; Sat, 24 Jun 2006 13:21:41 +0900 Message-Id: <6.0.0.20.2.20060624131853.0974eec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 24 Jun 2006 13:21:04 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: Moving forward (Was: [Ltru] matching draft, issue 50) In-Reply-To: <001501c69739$f1b83870$650a0a0a@ds.corp.yahoo.com> References: <6.0.0.20.2.20060624103110.09743c30@localhost> <001501c69739$f1b83870$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 11:57 06/06/24, Addison Phillips wrote: >My mistake. No problem. >I have changed the xml source, regenerated the text and html >versions and posted them to inter-locale.com. The dynamic link for the diff >should still work (albeit not for you?). It worked today. >I'll regenerate a diff in a little while. > >Please confirm that the file is now correct. It is. Please go ahead and submit it to the Internet-Drafts Editor. Thanks again for all your efforts. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 24 00:56:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu0CA-0007m1-JD; Sat, 24 Jun 2006 00:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu0C9-0007eB-O1; Sat, 24 Jun 2006 00:56:33 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu0C5-0005qG-0a; Sat, 24 Jun 2006 00:56:33 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c86.corp.yahoo.com [10.72.72.86]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5O4tO59048753; Fri, 23 Jun 2006 21:55:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:x-mailer:x-mimeole:thread-index; b=gGBgE9gbtlRDfdkTXxK6dpJ2XvNqwAPuYL4Ic9VTYr7nFoAZg4z1Lemv4SApqHfH From: "Addison Phillips" To: Date: Fri, 23 Jun 2006 21:55:24 -0700 Message-ID: <001701c6974a$67a134f0$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C6970F.BB425CF0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXSmdNgXyACg3oTtSs8H5SSY2KMA== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: dfc1655f2189092f4fafe696b2c0f089 Cc: 'LTRU Working Group' Subject: [Ltru] submission: draft-ietf-ltru-matching-15 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C6970F.BB425CF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Dear Editor, Please find attached the 15th version of draft-ietf-ltru-matching. Best Regards, Addison (for the editors) Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. ------=_NextPart_000_0018_01C6970F.BB425CF0 Content-Type: text/plain; name="draft-ietf-ltru-matching-15.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltru-matching-15.txt" =0A= =0A= =0A= Network Working Group A. Phillips, Ed.=0A= Internet-Draft Yahoo! Inc.=0A= Obsoletes: 3066 (if approved) M. Davis, Ed.=0A= Expires: December 24, 2006 Google=0A= June 22, 2006=0A= =0A= =0A= Matching of Language Tags=0A= draft-ietf-ltru-matching-15=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on December 24, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes a syntax, called a "language-range", for=0A= specifying items in a user's list of language preferences. It also=0A= describes different mechanisms for comparing and matching these to=0A= language tags. Two kinds of matching mechanisms, filtering and=0A= lookup, are defined. Filtering produces a (potentially empty) set of=0A= language tags, whereas lookup produces a single language tag.=0A= Possible applications include language negotiation or content=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 1]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= selection. This document, in combination with RFC 3066bis (Ed.:=0A= replace "3066bis" with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC=0A= 1766.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Language Range . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Basic Language Range . . . . . . . . . . . . . . . . . . . 4=0A= 2.2. Extended Language Range . . . . . . . . . . . . . . . . . 5=0A= 2.3. The Language Priority List . . . . . . . . . . . . . . . . 5=0A= 3. Types of Matching . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Choosing a Matching Scheme . . . . . . . . . . . . . . . . 7=0A= 3.2. Implementation Considerations . . . . . . . . . . . . . . 8=0A= 3.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.3.1. Basic Filtering . . . . . . . . . . . . . . . . . . . 10=0A= 3.3.2. Extended Filtering . . . . . . . . . . . . . . . . . . 11=0A= 3.4. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.4.1. Default Values . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16=0A= 4.1. Choosing Language Ranges . . . . . . . . . . . . . . . . . 16=0A= 4.2. Meaning of Language Tags and Ranges . . . . . . . . . . . 17=0A= 4.3. Considerations for Private Use Subtags . . . . . . . . . . 17=0A= 4.4. Length Considerations for Language Ranges . . . . . . . . 18=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20=0A= 7. Character Set Considerations . . . . . . . . . . . . . . . . . 21=0A= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22=0A= 8.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 25=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 2]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Human beings on our planet have, past and present, used a number of=0A= languages. There are many reasons why one would want to identify the=0A= language used when presenting or requesting information.=0A= =0A= Applications, protocols, or specifications that use language=0A= identifiers, such as the language tags defined in [RFC3066bis],=0A= sometimes need to match language tags to a user's language=0A= preferences.=0A= =0A= This document defines a syntax (called a language range (Section 2))=0A= for specifying items in the user's list of language preferences=0A= (called a language priority list (Section 2.3)), as well as several=0A= schemes for selecting or filtering sets of language tags by comparing=0A= the language tags to the user's preferences. Applications,=0A= protocols, or specifications will have varying needs and requirements=0A= that affect the choice of a suitable matching scheme.=0A= =0A= This document describes: how to indicate a user's preferences using=0A= language ranges; three schemes for matching these ranges to a set of=0A= language tags; and the various practical considerations that apply to=0A= implementing and using these schemes.=0A= =0A= This document, in combination with [RFC3066bis] (Ed.: replace=0A= "3066bis" globally in this document with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced=0A= [RFC1766].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 3]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 2. The Language Range=0A= =0A= Language tags [RFC3066bis] are used to help identify languages,=0A= whether spoken, written, signed, or otherwise signaled, for the=0A= purpose of communication. Applications, protocols, or specifications=0A= that use language tags are often faced with the problem of=0A= identifying sets of content that share certain language attributes.=0A= For example, HTTP/1.1 [RFC2616] describes one such mechanism in its=0A= discussion of the Accept-Language header (Section 14.4), which is=0A= used when selecting content from servers based on the language of=0A= that content.=0A= =0A= It is, thus, useful to have a mechanism for identifying sets of=0A= language tags that share specific attributes. This allows users to=0A= select or filter the language tags based on specific requirements.=0A= Such an identifier is called a "language range".=0A= =0A= There are different types of language range, whose specific=0A= attributes vary according to their application. Language ranges are=0A= similar to language tags: they consist of a sequence of subtags=0A= separated by hyphens. In a language range, each subtag MUST either=0A= be a sequence of ASCII alphanumeric characters or the single=0A= character '*' (%2A, ASTERISK). The character '*' is a "wildcard"=0A= that matches any sequence of subtags. The meaning and uses of=0A= wildcards vary according to the type of language range.=0A= =0A= Language tags and thus language ranges are to be treated as case-=0A= insensitive: there exist conventions for the capitalization of some=0A= of the subtags, but these MUST NOT be taken to carry meaning.=0A= Matching of language tags to language ranges MUST be done in a case-=0A= insensitive manner.=0A= =0A= 2.1. Basic Language Range=0A= =0A= A "basic language range" has the same syntax as an [RFC3066] language=0A= tag or is the single character "*". The basic language range was=0A= originally described by HTTP/1.1 [RFC2616] and later [RFC3066]. It=0A= is defined by the following ABNF [RFC4234]:=0A= =0A= language-range =3D (1*8ALPHA *("-" 1*8alphanum)) / "*"=0A= alphanum =3D ALPHA / DIGIT=0A= =0A= A basic language range differs from the language tags defined in=0A= [RFC3066bis] only in that there is no requirement that it be "well-=0A= formed" or be validated against the IANA Language Subtag Registry.=0A= Such ill-formed ranges will probably not match anything. Note that=0A= the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the=0A= use of digits anywhere in the 'language-range' (see:=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 4]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= [RFC2616errata]).=0A= =0A= 2.2. Extended Language Range=0A= =0A= Occasionally users will wish to select a set of language tags based=0A= on the presence of specific subtags. An "extended language range"=0A= describes a user's language preference as an ordered sequence of=0A= subtags. For example, a user might wish to select all language tags=0A= that contain the region subtag 'CH' (Switzerland). Extended language=0A= ranges are useful for specifying a particular sequence of subtags=0A= that appear in the set of matching tags without having to specify all=0A= of the intervening subtags.=0A= =0A= An extended language range can be represented by the following ABNF:=0A= =0A= extended-language-range =3D (1*8ALPHA / "*")=0A= *("-" (1*8alphanum / "*"))=0A= =0A= The wildcard subtag '*' can occur in any position in the extended=0A= language range, where it matches any sequence of subtags that might=0A= occur in that position in a language tag. However, wildcards outside=0A= the first position are ignored by Extended Filtering (see Section=0A= 3.2.2). The use or absence of one or more wildcards cannot be taken=0A= to imply that a certain number of subtags will appear in the matching=0A= set of language tags.=0A= =0A= 2.3. The Language Priority List=0A= =0A= A user's language preferences will often need to specify more than=0A= one language range and thus users often need to specify a prioritized=0A= list of language ranges in order to best reflect their language=0A= preferences. This is especially true for speakers of minority=0A= languages. A speaker of Breton in France, for example, can specify=0A= "br" followed by "fr", meaning that if Breton is available, it is=0A= preferred, but otherwise French is the best alternative. It can get=0A= more complex: a different user might want to fall back from Skolt=0A= Sami to Northern Sami to Finnish.=0A= =0A= A "language priority list" is a prioritized or weighted list of=0A= language ranges. One well known example of such a list is the=0A= "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section=0A= 14.4) and RFC 3282 [RFC3282].=0A= =0A= The various matching operations described in this document include=0A= considerations for using a language priority list. This document=0A= does not define the syntax for a language priority list; defining=0A= such a syntax is the responsibility of the protocol, application, or=0A= specification that uses it. When given as examples in this document,=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 5]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= language priority lists will be shown as a quoted sequence of ranges=0A= separated by commas, like this: "en, fr, zh-Hant" (which is read=0A= "English before French before Chinese as written in the Traditional=0A= script").=0A= =0A= A simple list of ranges is considered to be in descending order of=0A= priority. Other language priority lists provide "quality weights"=0A= for the language ranges in order to specify the relative priority of=0A= the user's language preferences. An example of this is the use of=0A= "q" values in the syntax of the "Accept-Language" header (defined in=0A= [RFC2616], Section 14.4, and [RFC3282]).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 6]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 3. Types of Matching=0A= =0A= Matching language ranges to language tags can be done in many=0A= different ways. This section describes three such matching schemes,=0A= as well as the considerations for choosing between them. Protocols=0A= and specifications requiring conformance to this specification MUST=0A= clearly indicate the particular mechanism used in selecting or=0A= matching language tags.=0A= =0A= There are two types of matching scheme in this document. A matching=0A= scheme that produces zero or more matching language tags is called=0A= "filtering". A matching scheme that produces exactly one match for a=0A= given request is called "lookup".=0A= =0A= 3.1. Choosing a Matching Scheme=0A= =0A= Applications, protocols, and specifications are faced with the=0A= decision of what type of matching to use. Sometimes, different=0A= styles of matching are suited to different kinds of processing within=0A= a particular application or protocol.=0A= =0A= This document describes three matching schemes:=0A= =0A= 1. Basic Filtering (Section 3.3.1) matches a language priority list=0A= consisting of basic language ranges (Section 2.1) to sets of=0A= language tags.=0A= =0A= 2. Extended Filtering (Section 3.3.2) matches a language priority=0A= list consisting of extended language ranges (Section 2.2) to sets=0A= of language tags.=0A= =0A= 3. Lookup (Section 3.4) matches a language priority list consisting=0A= of basic language ranges to sets of language tags to find the one=0A= _exact_ language tag that best matches the range.=0A= =0A= Filtering can be used to produce a set of results (such as a=0A= collection of documents) by comparing the user's preferences to a set=0A= of language tags. For example, when performing a search, filtering=0A= can be used to limit the results to items tagged as being in the=0A= French language. Filtering can also be used when deciding whether to=0A= perform a language-sensitive process on some content. For example, a=0A= process might cause paragraphs whose language tag matched the=0A= language range "nl" (Dutch) to be displayed in italics within a=0A= document.=0A= =0A= Lookup produces the single result that best matches the user's=0A= preferences from the list of available tags, so it is useful in cases=0A= in which a single item is required (and for which only a single item=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 7]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= can be returned). For example, if a process were to insert a human=0A= readable error message into a protocol header, it might select the=0A= text based on the user's language priority list. Since the process=0A= can return only one item, it is forced to choose a single item and it=0A= has to return some item, even if none of the content's language tags=0A= match the language priority list supplied by the user.=0A= =0A= 3.2. Implementation Considerations=0A= =0A= Language tag matching is a tool, and does not by itself specify a=0A= complete procedure for the use of language tags. Such procedures are=0A= intimately tied to the application protocol in which they occur.=0A= When specifying a protocol operation using matching, the protocol=0A= MUST specify:=0A= =0A= o Which type(s) of language tag matching it uses=0A= =0A= o Whether the operation returns a single result (lookup) or a=0A= possibly empty set of results (filtering)=0A= =0A= o For lookup, what the default item is (or the sequence of=0A= operations or configuration information used to determine the=0A= default) when no matching tag is found. For instance, a protocol=0A= might define the result as failure of the operation, an empty=0A= value, returning some protocol defined or implementation defined=0A= default, or returning i-default [RFC2277].=0A= =0A= Applications, protocols, and specifications are not required to=0A= validate or understand any of the semantics of the language tags or=0A= ranges or of the subtags in them, nor do they require access to the=0A= IANA Language Subtag Registry (see Section 3 in [RFC3066bis]). This=0A= simplifies implementation.=0A= =0A= However, designers of applications, protocols, or specifications are=0A= encouraged to use the information from the IANA Language Subtag=0A= Registry to support canonicalizing language tags and ranges in order=0A= to map grandfathered and obsolete tags or subtags into modern=0A= equivalents.=0A= =0A= Applications, protocols, or specifications that canonicalize ranges=0A= MUST either perform matching operations with both the canonical and=0A= original (unmodified) form of the range or MUST also canonicalize=0A= each tag for the purposes of comparison.=0A= =0A= Note that canonicalizing language ranges makes certain operations=0A= impossible. For example, an implementation that canonicalizes the=0A= language range "art-lojban" (artificial language, lojban variant) to=0A= use the more modern "jbo" (Lojban) cannot be used to select just the=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 8]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= items with the older tag.=0A= =0A= Applications, protocols, or specifications that use basic ranges=0A= might sometimes receive extended language ranges instead. An=0A= application, protocol, or specification MUST choose to: a) map=0A= extended language ranges to basic ranges using the algorithm below,=0A= b) reject any extended language ranges in the language priority list=0A= that are not valid basic language ranges, or c) treat each extended=0A= language range as if it were a basic language range, which will have=0A= the same result as ignoring them, since these ranges will not match=0A= any valid language tags.=0A= =0A= An extended language range is mapped to a basic language range as=0A= follows: if the first subtag is a '*' then the entire range is=0A= treated as "*", otherwise each wildcard subtag is removed. For=0A= example, the extended language range "en-*-US" maps to "en-US"=0A= (English, United States).=0A= =0A= Applications, protocols, or specifications, in addressing their=0A= particular requirements, can offer pre-processing or configuration=0A= options. For example, an implementation could allow a user to=0A= associate or map a particular language range to a different value.=0A= Such a user might wish to associate the language range subtags 'nn'=0A= (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general=0A= subtag 'no' (Norwegian). Or perhaps a user would want to associate=0A= requests for the range "zh-Hans" (Chinese as written in the=0A= Simplified script) with content bearing the language tag "zh-CN"=0A= (Chinese as used in China, where the Simplified script is=0A= predominant). Documentation on how the ranges or tags are altered,=0A= prioritized, or compared in the subsequent match in such an=0A= implementation will assist users in making these types of=0A= configuration choices.=0A= =0A= 3.3. Filtering=0A= =0A= Filtering is used to select the set of language tags that matches a=0A= given language priority list. It is called "filtering" because this=0A= set might contain no items at all or it might return an arbitrarily=0A= large number of matching items: as many items as match the language=0A= priority list, thus "filtering out" the non-matching items.=0A= =0A= In filtering, each language range represents the _least_ specific=0A= language tag (that is, the language tag with fewest number of=0A= subtags) which is an acceptable match. All of the language tags in=0A= the matching set of tags will have an equal or greater number of=0A= subtags than the language range. Every non-wildcard subtag in the=0A= language range will appear in every one of the matching language=0A= tags. For example, if the language priority list consists of the=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 9]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= range "de-CH" (German as used in Switzerland), one might see tags=0A= such as "de-CH-1996" (German as used in Switzerland, orthography of=0A= 1996) but one will never see a tag such as "de" (because the 'CH'=0A= subtag is missing).=0A= =0A= If the language priority list (see Section 2.3) contains more than=0A= one range, the content returned is typically ordered in descending=0A= level of preference, but it MAY be unordered, according to the needs=0A= of the application or protocol.=0A= =0A= Some examples of applications where filtering might be appropriate=0A= include:=0A= =0A= o Applying a style to sections of a document in a particular set of=0A= languages.=0A= =0A= o Displaying the set of documents containing a particular set of=0A= keywords written in a specific set of languages.=0A= =0A= o Selecting all email items written in a specific set of languages.=0A= =0A= o Selecting audio files spoken in a particular language.=0A= =0A= Filtering seems to imply that there is a semantic relationship=0A= between language tags that share the same prefix. While this is=0A= often the case, it is not always true: the language tags that match a=0A= specific language range do not necessarily represent mutually=0A= intelligible languages.=0A= =0A= 3.3.1. Basic Filtering=0A= =0A= Basic filtering compares basic language ranges to language tags.=0A= Each basic language range in the language priority list is considered=0A= in turn, according to priority. A language range matches a=0A= particular language tag if, in a case-insensitive comparison, it=0A= exactly equals the tag, or if it exactly equals a prefix of the tag=0A= such that the first character following the prefix is "-". For=0A= example, the language-range "de-de" (German as used in Germany)=0A= matches the language tag "de-DE-1996" (German as used in Germany,=0A= orthography of 1996), but not the language tags "de-Deva" (German as=0A= written in the Devanagari script) or "de-Latn-DE" (German, Latin=0A= script, as used in Germany).=0A= =0A= The special range "*" in a language priority list matches any tag. A=0A= protocol which uses language ranges MAY specify additional rules=0A= about the semantics of "*"; for instance, HTTP/1.1 [RFC2616]=0A= specifies that the range "*" matches only languages not matched by=0A= any other range within an "Accept-Language" header.=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 10]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= Basic filtering is identical to the type of matching described in=0A= [RFC3066], Section 2.5 (Language-range).=0A= =0A= 3.3.2. Extended Filtering=0A= =0A= Extended filtering compares extended language ranges to language=0A= tags. Each extended language range in the language priority list is=0A= considered in turn, according to priority. A language range matches=0A= a particular language tag if their list of subtags match. To=0A= determine a match:=0A= =0A= 1. Split both the extended language range and the language tag being=0A= compared into a list of subtags by dividing on the hyphen (%2D)=0A= character. Two subtags match if either they are the same when=0A= compared case-insensitively or the language range's subtag is the=0A= wildcard '*'.=0A= =0A= 2. Begin with the first subtag in each list. If the first subtag in=0A= the range does not match the first subtag in the tag, the overall=0A= match fails. Otherwise, move to the next subtag in both the=0A= range and the tag.=0A= =0A= 3. While there are more subtags left in the language range's list:=0A= =0A= A. If the subtag currently being examined in the range is the=0A= wildcard ('*'), move to the next subtag in the range and=0A= continue with the loop.=0A= =0A= B. Else, if there are no more subtags in the language tag's=0A= list, the match fails.=0A= =0A= C. Else, if the current subtag in the range's list matches the=0A= current subtag in the language tag's list, move to the next=0A= subtag in both lists and continue with the loop.=0A= =0A= D. Else, if the language tag's subtag is a "singleton" (a single=0A= letter or digit, which includes the private-use subtag 'x')=0A= the match fails.=0A= =0A= E. Else, move to the next subtag in the language tag's list and=0A= continue with the loop.=0A= =0A= 4. When the language range's list has no more subtags, the match=0A= succeeds.=0A= =0A= Subtags not specified, including those at the end of the language=0A= range, are thus treated as if assigned the wildcard value '*'. Much=0A= like basic filtering, extended filtering selects content with=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 11]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= arbitrarily long tags that share the same initial subtags as the=0A= language range. In addition, extended filtering selects language=0A= tags that contain any intermediate subtags not specified in the=0A= language range. For example, the extended language range "de-*-DE"=0A= (or its synonym "de-DE") matches all of the following tags:=0A= =0A= de-DE (German, as used in Germany)=0A= =0A= de-de (German, as used in Germany)=0A= =0A= de-Latn-DE (Latin script)=0A= =0A= de-Latf-DE (Fraktur variant of Latin script)=0A= =0A= de-DE-x-goethe (private use subtag)=0A= =0A= de-Latn-DE-1996 (orthography of 1996)=0A= =0A= de-Deva-DE (Devanagari script)=0A= =0A= The same range does not match any of the following tags for the=0A= reasons shown:=0A= =0A= de (missing 'DE')=0A= =0A= de-x-DE (singleton 'x' occurs before 'DE')=0A= =0A= de-Deva ('Deva' not equal to 'DE')=0A= =0A= Note: [RFC3066bis] defines each type of subtag (language, script,=0A= region, and so forth) according to position, size, and content. This=0A= means that subtags in a language range can only match specific types=0A= of subtags in a language tag. For example, a subtag such as 'Latn'=0A= is always a script subtag (unless it follows a singleton) while a=0A= subtag such as 'nedis' can only match the equivalent variant subtag.=0A= Two-letter subtags in initial position have a different type=0A= (language) than two-letter subtags in later positions (region). This=0A= is the reason why a wildcard in the extended language range is=0A= significant in the first position but is ignored in all other=0A= positions.=0A= =0A= 3.4. Lookup=0A= =0A= Lookup is used to select the single language tag that best matches=0A= the language priority list for a given request. When performing=0A= lookup, each language range in the language priority list is=0A= considered in turn, according to priority. By contrast with=0A= filtering, each language range represents the _most_ specific tag=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 12]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= which is an acceptable match. The first matching tag found,=0A= according to the user's priority, is considered the closest match and=0A= is the item returned. For example, if the language range is "de-ch",=0A= a lookup operation can produce content with the tags "de" or "de-CH"=0A= but never content with the tag "de-CH-1996". If no language tag=0A= matches the request, the "default" value is returned.=0A= =0A= For example, if an application inserts some dynamic content into a=0A= document, returning an empty string if there is no exact match is not=0A= an option. Instead, the application "falls back" until it finds a=0A= matching language tag associated with a suitable piece of content to=0A= insert. Some applications of lookup include:=0A= =0A= o Selection of a template containing the text for an automated email=0A= response.=0A= =0A= o Selection of a item containing some text for inclusion in a=0A= particular Web page.=0A= =0A= o Selection of a string of text for inclusion in an error log.=0A= =0A= o Selection of an audio file to play as a prompt in a phone system.=0A= =0A= In the lookup scheme, the language range is progressively truncated=0A= from the end until a matching language tag is located. Single letter=0A= or digit subtags (including both the letter 'x' which introduces=0A= private-use sequences, and the subtags that introduce extensions) are=0A= removed at the same time as their closest trailing subtag. For=0A= example, starting with the range "zh-Hant-CN-x-private1-private2"=0A= (Chinese, Traditional script, China, two private use tags) the lookup=0A= progressively searches for content as shown below:=0A= =0A= Example of a Lookup Fallback Pattern=0A= =0A= Range to match: zh-Hant-CN-x-private1-private2=0A= 1. zh-Hant-CN-x-private1-private2=0A= 2. zh-Hant-CN-x-private1=0A= 3. zh-Hant-CN=0A= 4. zh-Hant=0A= 5. zh=0A= 6. (default)=0A= =0A= This fallback behavior allows some flexibility in finding a match.=0A= Without fallback, the default content would be returned immediately=0A= if exactly matching content is unavailable. With fallback, a result=0A= more closely matching the user request can be provided.=0A= =0A= Extensions and unrecognized private-use subtags might be unrelated to=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 13]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= a particular application of lookup. Since these subtags come at the=0A= end of the subtag sequence, they are removed first during the=0A= fallback process and usually pose no barrier to interoperability.=0A= However, an implementation MAY remove these from ranges prior to=0A= performing the lookup (provided the implementation also removes them=0A= from the tags being compared). Such modification is internal to the=0A= implementation and applications, protocols, or specifications SHOULD=0A= NOT remove or modify subtags in content that they return or forward,=0A= because this removes information that can be used elsewhere.=0A= =0A= The special language range "*" matches any language tag. In the=0A= lookup scheme, this range does not convey enough information by=0A= itself to determine which language tag is most appropriate, since it=0A= matches everything. If the language range "*" is followed by other=0A= language ranges, it is skipped. If the language range "*" is the=0A= only one in the language priority list or if no other language range=0A= follows, the default value is computed and returned.=0A= =0A= In some cases, the language priority list can contain one or more=0A= extended language ranges (as, for example, when the same language=0A= priority list is used as input for both lookup and filtering=0A= operations). Wildcard values in an extended language range normally=0A= match any value that can occur in that position in a language tag.=0A= Since only one item can be returned for any given lookup request,=0A= wildcards in a language range have to be processed in a consistent=0A= manner or the same request will produce widely varying results.=0A= Applications, protocols, or specifications that accept extended=0A= language ranges MUST define which item is returned when more than one=0A= item matches the extended language range.=0A= =0A= For example, an implementation could map the extended language ranges=0A= to basic ranges. Another possibility would be for an implementation=0A= to return the matching tag that is first in ASCII-order. If the=0A= language range were "*-CH" ('CH' represents Switzerland) and the set=0A= of tags included "de-CH" (German as used in Switzerland), "fr-CH"=0A= (French, Switzerland), and "it-CH" (Italian, Switzerland), then the=0A= tag "de-CH" would be returned.=0A= =0A= 3.4.1. Default Values=0A= =0A= Each application, protocol, or specification that uses lookup MUST=0A= define the defaulting behavior when no tag matches the language=0A= priority list. What this action consists of strongly depends on how=0A= lookup is being applied. Some examples of defaulting behavior=0A= include:=0A= =0A= o return an item with no language tag or an item of a non-linguistic=0A= nature, such as an image or sound=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 14]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= o return a null string as the language tag value, in cases where the=0A= protocol permits the empty value (see, for example, "xml:lang" in=0A= [XML10])=0A= =0A= o return a particular language tag designated for the operation=0A= =0A= o return the language tag "i-default" (see: [RFC2277])=0A= =0A= o return an error condition or error message=0A= =0A= o return a list of available languages for the user to select from=0A= =0A= When performing lookup using a language priority list, the=0A= progressive search MUST process each language range in the list=0A= before seeking or calculating the default.=0A= =0A= The default value MAY be calculated or include additional searching=0A= or matching. Applications, protocols, or specifications can specify=0A= different ways in which users can specify or override the defaults.=0A= =0A= One common way to provide for a default is to allow a specific=0A= language range to be set as the default for a specific type of=0A= request. If this approach is chosen, this language range MUST be=0A= treated as if it were appended to the end of the language priority=0A= list as a whole, rather than after each item in the language priority=0A= list. The application, protocol, or specification MUST also define=0A= the defaulting behavior if that search fails to find a matching tag=0A= or item.=0A= =0A= For example, if a particular user's language priority list is "fr-FR,=0A= zh-Hant" (French as used in France followed by Chinese as written in=0A= the Traditional script) and the program doing the matching had a=0A= default language range of "ja-JP" (Japanese as used in Japan), then=0A= the program searches as follows:=0A= 1. fr-FR=0A= 2. fr=0A= 3. zh-Hant // next language=0A= 4. zh=0A= 5. ja-JP // now searching for the default content=0A= 6. ja=0A= 7. (implementation defined default)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 15]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 4. Other Considerations=0A= =0A= When working with language ranges and matching schemes, there are=0A= some additional points that can influence the choice of either.=0A= =0A= 4.1. Choosing Language Ranges=0A= =0A= Users indicate their language preferences via the choice of a=0A= language range or the list of language ranges in a language priority=0A= list. The type of matching affects what the best choice is for a=0A= user.=0A= =0A= Most matching schemes make no attempt to process the semantic meaning=0A= of the subtags. The language range is compared, in a case-=0A= insensitive manner, to each language tag being matched, using basic=0A= string processing. Users SHOULD select language ranges that are=0A= well-formed, valid language tags according to [RFC3066bis]=0A= (substituting wildcards as appropriate in extended language ranges).=0A= =0A= Applications are encouraged to canonicalize language tags and ranges=0A= by using the Preferred-Value from the IANA Language Subtag Registry=0A= for tags or subtags which have been deprecated. If the user is=0A= working with content that might use the older form, the user might=0A= want to include both the new and old forms in a language priority=0A= list. For example, the tag "art-lojban" is deprecated. The subtag=0A= 'jbo' is supposed to be used instead, so the user might use it to=0A= form the language range. Or the user might include both in a=0A= language priority list: "jbo, art-lojban".=0A= =0A= Users SHOULD avoid subtags that add no distinguishing value to a=0A= language range. When filtering, the fewer the number of subtags that=0A= appear in the language range, the more content the range will=0A= probably match, while in lookup unnecessary subtags can cause=0A= "better", more-specific content to be skipped in favor of less=0A= specific content. For example, the range "de-Latn-DE" returns=0A= content tagged "de" instead of content tagged "de-DE", even though=0A= the latter is probably a better match.=0A= =0A= Whether a subtag adds distinguishing value can depend on the context=0A= of the request. For example, a user who reads both Simplified and=0A= Traditional Chinese, but who prefers Simplified, might use the range=0A= "zh" for filtering (matching all items that user can read) but "zh-=0A= Hans" for lookup (making sure that user gets the preferred form if=0A= it's available, but the fallback to "zh" will still work). On the=0A= other hand, content in this case ought to be labeled as "zh-Hans" (or=0A= "zh-Hant" if that applies) for filtering, while for lookup, if there=0A= is either "zh-Hans" content or "zh-Hant" content, one of them (the=0A= one considered 'default') also ought to be made available with the=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 16]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= simple "zh". Note that the user can create a language priority list=0A= "zh-Hans, zh" that delivers the best possible results for both=0A= schemes. If the user cannot be sure which scheme is being used (or=0A= if more than one might be applied to a given request), the user=0A= SHOULD specify the most specific (largest number of subtags) range=0A= first and then supply shorter prefixes later in the list to ensure=0A= that filtering returns a complete set of tags.=0A= =0A= Many languages are written predominantly in a single script. This is=0A= usually recorded in the Suppress-Script field in that language=0A= subtag's registry entry. For these languages, script subtags SHOULD=0A= NOT be used to form a language range. Thus the language range "en-=0A= Latn" is inappropriate in most cases (because the vast majority of=0A= English documents are written in the Latin script and thus the 'en'=0A= language subtag has a Suppress-Script field for 'Latn' in the=0A= registry).=0A= =0A= When working with tags and ranges, note that extensions and most=0A= private-use subtags are orthogonal to language tag matching, in that=0A= they specify additional attributes of the text not related to the=0A= goals of most matching schemes. Users SHOULD avoid using these=0A= subtags in language ranges, since they interfere with the selection=0A= of available content. When used in language tags (as opposed to=0A= ranges), these subtags normally do not interfere with filtering=0A= (Section 3), since they appear at the end of the tag and will match=0A= all prefixes. Lookup (Section 3.4) implementations are advised to=0A= ignore unrecognized private-use and extension subtags when performing=0A= language tag fallback.=0A= =0A= 4.2. Meaning of Language Tags and Ranges=0A= =0A= Selecting language tags using language ranges requires some=0A= understanding by users of what they are selecting. The meaning of=0A= the various subtags in a language range are identical to their=0A= meaning in a language tag (see Section 4.2 in [RFC3066bis]), with the=0A= addition that the wildcard "*" represents any matching sequence of=0A= values.=0A= =0A= 4.3. Considerations for Private Use Subtags=0A= =0A= Private agreement is necessary between the parties that intend to use=0A= or exchange language tags that contain private-use subtags. Great=0A= caution SHOULD be used in employing private-use subtags in content or=0A= protocols intended for general use. Private-use subtags are simply=0A= useless for information exchange without prior arrangement.=0A= =0A= The value and semantic meaning of private-use tags and of the subtags=0A= used within such a language tag are not defined. Matching private-=0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 17]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= use tags using language ranges or extended language ranges can result=0A= in unpredictable content being returned.=0A= =0A= 4.4. Length Considerations for Language Ranges=0A= =0A= Language ranges are very similar to language tags in terms of content=0A= and usage. The same types of restrictions on length that can be=0A= applied to language tags can also be applied to language ranges. See=0A= [RFC3066bis] Section 4.3 (Length Considerations).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 18]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 5. IANA Considerations=0A= =0A= This document presents no new or existing considerations for IANA.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 19]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 6. Security Considerations=0A= =0A= Language ranges used in content negotiation might be used to infer=0A= the nationality of the sender, and thus identify potential targets=0A= for surveillance. In addition, unique or highly unusual language=0A= ranges or combinations of language ranges might be used to track a=0A= specific individual's activities.=0A= =0A= This is a special case of the general problem that anything you send=0A= is visible to the receiving party. It is useful to be aware that=0A= such concerns can exist in some cases.=0A= =0A= The evaluation of the exact magnitude of the threat, and any possible=0A= countermeasures, is left to each application or protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 20]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 7. Character Set Considerations=0A= =0A= Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-=0A= MINUS (%x2D). Language ranges also use the character ASTERISK=0A= (%x2A). These characters are present in most character sets, so=0A= presentation or exchange of language tags or ranges should not be=0A= constrained by character set issues.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 21]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= 8. References=0A= =0A= 8.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and=0A= Languages", BCP 18, RFC 2277, January 1998.=0A= =0A= [RFC3066bis]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for the=0A= Identification of Languages", October 2005, .=0A= =0A= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A= Specifications: ABNF", RFC 4234, October 2005.=0A= =0A= 8.2. Informative References=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= [RFC2616errata]=0A= IETF, "HTTP/1.1 Specification Errata", October 2004,=0A= .=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,=0A= May 2002.=0A= =0A= [XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and=0A= F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third=0A= Edition)", World Wide Web Consortium Recommendation,=0A= February 2004, .=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 22]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= Appendix A. Acknowledgments=0A= =0A= Any list of contributors is bound to be incomplete; please regard the=0A= following as only a selection from the group of people who have=0A= contributed to make this document what it is today.=0A= =0A= The contributors to [RFC1766] and [RFC3066], each of which was a=0A= precursor to this document, contributed greatly to the development of=0A= language tag matching, and, in particular, the basic language range=0A= and the basic matching scheme. This document was originally part of=0A= [RFC3066bis], but was split off before that document's completion.=0A= Thus, directly or indirectly, those acknowledged in [RFC3066bis] also=0A= had a hand in the development of this document, and work done prior=0A= to the split is acknowledged in that document.=0A= =0A= The following people (in alphabetical order by family name)=0A= contributed to this document:=0A= =0A= Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, Peter=0A= Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann,=0A= Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson,=0A= Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy=0A= Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many,=0A= many others.=0A= =0A= Very special thanks must go to Harald Tveit Alvestrand, who=0A= originated RFCs 1766 and 3066, and without whom this document would=0A= not have been possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 23]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Addison Phillips (editor)=0A= Yahoo! Inc.=0A= =0A= Email: addison@inter-locale.com=0A= =0A= =0A= Mark Davis (editor)=0A= Google=0A= =0A= Email: mark.davis@macchiato.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 24]=0A= =0C=0A= Internet-Draft ltru-matching June 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires December 24, 2006 [Page 25]=0A= =0C=0A= ------=_NextPart_000_0018_01C6970F.BB425CF0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0018_01C6970F.BB425CF0-- From ltru-bounces@ietf.org Sat Jun 24 02:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1c3-0003FN-3P; Sat, 24 Jun 2006 02:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1c2-0003BH-95 for ltru@ietf.org; Sat, 24 Jun 2006 02:27:22 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu1by-0005T0-Ox for ltru@ietf.org; Sat, 24 Jun 2006 02:27:22 -0400 Received: from h-68-165-4-59.snvacaid.dynamic.covad.net ([68.165.4.59] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fu1bx-0002u7-00 for ltru@ietf.org; Sat, 24 Jun 2006 02:27:18 -0400 Message-ID: <002f01c69757$4b343760$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000601c6380a$144a7450$9fcd15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup Date: Fri, 23 Jun 2006 23:27:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Just what is the proposed change to the document? To delete the example? This is rather late in the process, and, as a technical contributor, I don't see any significant benefit to deleting the example. Randy ----- Original Message ----- From: "Addison Phillips" To: "'Mark Davis'" ; "'John Cowan'" Cc: Sent: Wednesday, February 22, 2006 4:45 PM Subject: RE: [Ltru] Eliminating the preposterous ASCII ordering in lookup It is merely an example of what one could do. It isn't obligatory. So it isn't that bad, I guess. We don't have text that requires a mapping to basic ranges at the moment and don't necessarily need to introduce it. On the other hand, I don't think I'd implement an algorithm that way and most underlying locale-like fallback systems will do as I suggested. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006年2月22日 14:54 > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup > > I'm guessing, but only a guess, that this is related to the following text: > > > For example, an implementation could return the matching content that > > is first in ASCII-order. For example, if the language range were > > "*-CH" and the set of content included "de-CH", "fr-CH", and "it-CH", > > then the content labeled "de-CH" would be returned. > "preposterous" is a overblown language. And I strongly disagree with > your proposed change. In the example there clearly *exists* content > matching *-CH. So returning the default content (which could be, say, > Japanese) is clearly *not* what I would have expected! > > There could, of course, be other strategies for picking a single tag to > return from lookup when there are multiple matches for a wildcard. But > whatever example we choose should not return something so clearly > disconnected from the user's desired outcome. And ASCII is simple to > explain. > > Mark > > John Cowan wrote: > > It's really laughable to suggest that implementations might use ASCII > > tag ordering to make fallback decisions on lookup. IMHO, the behavior > > of extended ranges on lookup should be: > > > > If the first subtag of a language range is '*' and it is > > followed by other ranges in a priority list, skip it. > > If the first subtag is '*' and there are no following > > ranges, return the default content. All other '*' subtags > > should be removed before lookup processing is done. > > > > That is simple, clear, to the point, straightforward, and doesn't > provide > > preposterous results. > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 24 07:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu6Xr-0002x5-Pz; Sat, 24 Jun 2006 07:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu6Xq-0002wz-5R for ltru@ietf.org; Sat, 24 Jun 2006 07:43:22 -0400 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu6Xo-0003Mj-PM for ltru@ietf.org; Sat, 24 Jun 2006 07:43:22 -0400 Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Sat, 24 Jun 2006 11:43:12 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J1D002GG4JZWT@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 24 Jun 2006 11:43:11 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.23]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 24 Jun 2006 12:43:11 +0100 Date: Sat, 24 Jun 2006 12:43:10 +0100 From: Misha Wolf Subject: RE: [Ltru] Fwd: Last call: BCP 47 second part. To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit Thread-Topic: [Ltru] Fwd: Last call: BCP 47 second part. thread-index: AcaXNz4/SBQxRifJTECDtyzrXk3kfgAAtcBwABJLVGA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 24 Jun 2006 11:43:11.0540 (UTC) FILETIME=[5EE7D740:01C69783] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ditto. Misha -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: 24 June 2006 03:59 To: 'Martin Duerst'; 'LTRU Working Group' Subject: RE: [Ltru] Fwd: Last call: BCP 47 second part. FWIW, +1 for me as well. Addison [...] > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: vendredi 23 juin 2006 19:35 > To: LTRU Working Group > Subject: Re: [Ltru] Fwd: Last call: BCP 47 second part. > > John Cowan and Mark Davis have agreed with my assessment > (as a technical contributor) in > http://www1.ietf.org/mail-archive/web/ltru/current/msg05013.html > about how to (not!) deal with the issues below. I have not seen > any other comments. I have therefore (as a co-chair/shepherd) > marked the issues as 'rejected' or 'irrelevant' (the later for > issues where it's not clear how the issue could have possibly > been addressed). [...] To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 24 08:56:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7gN-0007it-Rt; Sat, 24 Jun 2006 08:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7gM-0007in-RB for ltru@ietf.org; Sat, 24 Jun 2006 08:56:14 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu7gI-0000jU-CP for ltru@ietf.org; Sat, 24 Jun 2006 08:56:14 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c86.corp.yahoo.com [10.72.72.86]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5OCregZ052289; Sat, 24 Jun 2006 05:53:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=tUx3515spXpQK8F5oh6m7InjyzfxmEcvvaLNYNJmFqWgOJUcsZbaa5sqQCWna4lm From: "Addison Phillips" To: "'Randy Presuhn'" , Subject: RE: [Ltru] Eliminating the preposterous ASCII ordering in lookup Date: Sat, 24 Jun 2006 05:53:39 -0700 Message-ID: <002701c6978d$37a5bf30$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXV002M+ih+IihQIiZrnk+8OMfGAANdGEw In-Reply-To: <002f01c69757$4b343760$6501a8c0@oemcomputer> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Uh... Randy...? That mail was sent in February? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. =20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: vendredi 23 juin 2006 23:28 > To: ltru@ietf.org > Subject: Re: [Ltru] Eliminating the preposterous ASCII=20 > ordering in lookup >=20 > Hi - >=20 > Just what is the proposed change to the document? > To delete the example? This is rather late in the process, > and, as a technical contributor, I don't see any significant > benefit to deleting the example. >=20 > Randy >=20 > ----- Original Message -----=20 > From: "Addison Phillips" > To: "'Mark Davis'" ; "'John=20 > Cowan'" > Cc: > Sent: Wednesday, February 22, 2006 4:45 PM > Subject: RE: [Ltru] Eliminating the preposterous ASCII=20 > ordering in lookup >=20 >=20 > It is merely an example of what one could do. It isn't=20 > obligatory. So it isn't that bad, I guess. We don't have text=20 > that requires a > mapping to basic ranges at the moment and don't necessarily=20 > need to introduce it. >=20 > On the other hand, I don't think I'd implement an algorithm=20 > that way and most underlying locale-like fallback systems will do as I > suggested. >=20 > Addison >=20 > Addison Phillips > Internationalization Architect - Yahoo! Inc. >=20 > Internationalization is an architecture. > It is not a feature. >=20 > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > Sent: 2006=E5=B9=B42=E6=9C=8822=E6=97=A5 14:54 > > To: John Cowan > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Eliminating the preposterous ASCII=20 > ordering in lookup > > > > I'm guessing, but only a guess, that this is related to the=20 > following text: > > > > > For example, an implementation could return the matching=20 > content that > > > is first in ASCII-order. For example, if the language range were > > > "*-CH" and the set of content included "de-CH", "fr-CH",=20 > and "it-CH", > > > then the content labeled "de-CH" would be returned. > > "preposterous" is a overblown language. And I strongly disagree with > > your proposed change. In the example there clearly *exists* content > > matching *-CH. So returning the default content (which=20 > could be, say, > > Japanese) is clearly *not* what I would have expected! > > > > There could, of course, be other strategies for picking a=20 > single tag to > > return from lookup when there are multiple matches for a=20 > wildcard. But > > whatever example we choose should not return something so clearly > > disconnected from the user's desired outcome. And ASCII is simple to > > explain. > > > > Mark > > > > John Cowan wrote: > > > It's really laughable to suggest that implementations=20 > might use ASCII > > > tag ordering to make fallback decisions on lookup. IMHO,=20 > the behavior > > > of extended ranges on lookup should be: > > > > > > If the first subtag of a language range is '*' and it is > > > followed by other ranges in a priority list, skip it. > > > If the first subtag is '*' and there are no following > > > ranges, return the default content. All other '*' subtags > > > should be removed before lookup processing is done. > > > > > > That is simple, clear, to the point, straightforward, and doesn't > > provide > > > preposterous results. > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jun 24 12:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBJQ-0002VM-BF; Sat, 24 Jun 2006 12:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBJP-0002VH-Jm for ltru@ietf.org; Sat, 24 Jun 2006 12:48:47 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBJP-0006xA-6L for ltru@ietf.org; Sat, 24 Jun 2006 12:48:47 -0400 Received: by nz-out-0102.google.com with SMTP id 9so1059800nzo for ; Sat, 24 Jun 2006 09:48:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Aw49mrsFGVQ77KsP8h0ujONhYcwihKhD7TUYg3pLSixGXxb+yCVZZ6+vQG5GwRs57XBJJfJgKLHN23T1TGtWaWVuHWSJjoEJIJ7VIpr7Q522CiFyttAteUMOdcuzTboro/pYoFflGBLs59v9X/MtUL85hlRWCTN7VxcOAjYTGeQ= Received: by 10.37.14.27 with SMTP id r27mr5474300nzi; Sat, 24 Jun 2006 09:48:42 -0700 (PDT) Received: by 10.36.153.7 with HTTP; Sat, 24 Jun 2006 09:48:42 -0700 (PDT) Message-ID: <30b660a20606240948q75ca05d0vcf24916471ec7748@mail.gmail.com> Date: Sat, 24 Jun 2006 09:48:42 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup In-Reply-To: <002f01c69757$4b343760$6501a8c0@oemcomputer> MIME-Version: 1.0 References: <000601c6380a$144a7450$9fcd15ac@ds.corp.yahoo.com> <002f01c69757$4b343760$6501a8c0@oemcomputer> X-Google-Sender-Auth: 61b6533718a70ad9 X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2051519227==" Errors-To: ltru-bounces@ietf.org --===============2051519227== Content-Type: multipart/alternative; boundary="----=_Part_11660_28612516.1151167722766" ------=_Part_11660_28612516.1151167722766 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZS4KCk9uIDYvMjMvMDYsIFJhbmR5IFByZXN1aG4gPHJhbmR5X3ByZXN1aG5AbWluZHNw cmluZy5jb20+IHdyb3RlOgo+Cj4gSGkgLQo+Cj4gSnVzdCB3aGF0IGlzIHRoZSBwcm9wb3NlZCBj aGFuZ2UgdG8gdGhlIGRvY3VtZW50Pwo+IFRvIGRlbGV0ZSB0aGUgZXhhbXBsZT8gIFRoaXMgaXMg cmF0aGVyIGxhdGUgaW4gdGhlIHByb2Nlc3MsCj4gYW5kLCBhcyBhIHRlY2huaWNhbCBjb250cmli dXRvciwgSSBkb24ndCBzZWUgYW55IHNpZ25pZmljYW50Cj4gYmVuZWZpdCB0byBkZWxldGluZyB0 aGUgZXhhbXBsZS4KPgo+IFJhbmR5Cj4KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4g RnJvbTogIkFkZGlzb24gUGhpbGxpcHMiIDxhZGRpc29uQHlhaG9vLWluYy5jb20+Cj4gVG86ICIn TWFyayBEYXZpcyciIDxtYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz47ICInSm9obiBDb3dhbici IDwKPiBjb3dhbkBjY2lsLm9yZz4KPiBDYzogPGx0cnVAaWV0Zi5vcmc+Cj4gU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAyMiwgMjAwNiA0OjQ1IFBNCj4gU3ViamVjdDogUkU6IFtMdHJ1XSBFbGlt aW5hdGluZyB0aGUgcHJlcG9zdGVyb3VzIEFTQ0lJIG9yZGVyaW5nIGluIGxvb2t1cAo+Cj4KPiBJ dCBpcyBtZXJlbHkgYW4gZXhhbXBsZSBvZiB3aGF0IG9uZSBjb3VsZCBkby4gSXQgaXNuJ3Qgb2Js aWdhdG9yeS4gU28gaXQKPiBpc24ndCB0aGF0IGJhZCwgSSBndWVzcy4gV2UgZG9uJ3QgaGF2ZSB0 ZXh0IHRoYXQgcmVxdWlyZXMgYQo+IG1hcHBpbmcgdG8gYmFzaWMgcmFuZ2VzIGF0IHRoZSBtb21l bnQgYW5kIGRvbid0IG5lY2Vzc2FyaWx5IG5lZWQgdG8KPiBpbnRyb2R1Y2UgaXQuCj4KPiBPbiB0 aGUgb3RoZXIgaGFuZCwgSSBkb24ndCB0aGluayBJJ2QgaW1wbGVtZW50IGFuIGFsZ29yaXRobSB0 aGF0IHdheSBhbmQKPiBtb3N0IHVuZGVybHlpbmcgbG9jYWxlLWxpa2UgZmFsbGJhY2sgc3lzdGVt cyB3aWxsIGRvIGFzIEkKPiBzdWdnZXN0ZWQuCj4KPiBBZGRpc29uCj4KPiBBZGRpc29uIFBoaWxs aXBzCj4gSW50ZXJuYXRpb25hbGl6YXRpb24gQXJjaGl0ZWN0IC0gWWFob28hIEluYy4KPgo+IElu dGVybmF0aW9uYWxpemF0aW9uIGlzIGFuIGFyY2hpdGVjdHVyZS4KPiBJdCBpcyBub3QgYSBmZWF0 dXJlLgo+Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTogTWFyayBEYXZp cyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQo+ID4gU2VudDogMjAwNuW5tDLm nIgyMuaXpSAxNDo1NAo+ID4gVG86IEpvaG4gQ293YW4KPiA+IENjOiBsdHJ1QGlldGYub3JnCj4g PiBTdWJqZWN0OiBSZTogW0x0cnVdIEVsaW1pbmF0aW5nIHRoZSBwcmVwb3N0ZXJvdXMgQVNDSUkg b3JkZXJpbmcgaW4KPiBsb29rdXAKPiA+Cj4gPiBJJ20gZ3Vlc3NpbmcsIGJ1dCBvbmx5IGEgZ3Vl c3MsIHRoYXQgdGhpcyBpcyByZWxhdGVkIHRvIHRoZSBmb2xsb3dpbmcKPiB0ZXh0Ogo+ID4KPiA+ ID4gRm9yIGV4YW1wbGUsIGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIHJldHVybiB0aGUgbWF0Y2hp bmcgY29udGVudCB0aGF0Cj4gPiA+IGlzIGZpcnN0IGluIEFTQ0lJLW9yZGVyLiBGb3IgZXhhbXBs ZSwgaWYgdGhlIGxhbmd1YWdlIHJhbmdlIHdlcmUKPiA+ID4gIiotQ0giIGFuZCB0aGUgc2V0IG9m IGNvbnRlbnQgaW5jbHVkZWQgImRlLUNIIiwgImZyLUNIIiwgYW5kICJpdC1DSCIsCj4gPiA+IHRo ZW4gdGhlIGNvbnRlbnQgbGFiZWxlZCAiZGUtQ0giIHdvdWxkIGJlIHJldHVybmVkLgo+ID4gInBy ZXBvc3Rlcm91cyIgaXMgYSBvdmVyYmxvd24gbGFuZ3VhZ2UuIEFuZCBJIHN0cm9uZ2x5IGRpc2Fn cmVlIHdpdGgKPiA+IHlvdXIgcHJvcG9zZWQgY2hhbmdlLiBJbiB0aGUgZXhhbXBsZSB0aGVyZSBj bGVhcmx5ICpleGlzdHMqIGNvbnRlbnQKPiA+IG1hdGNoaW5nICotQ0guIFNvIHJldHVybmluZyB0 aGUgZGVmYXVsdCBjb250ZW50ICh3aGljaCBjb3VsZCBiZSwgc2F5LAo+ID4gSmFwYW5lc2UpIGlz IGNsZWFybHkgKm5vdCogd2hhdCBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQhCj4gPgo+ID4gVGhlcmUg Y291bGQsIG9mIGNvdXJzZSwgYmUgb3RoZXIgc3RyYXRlZ2llcyBmb3IgcGlja2luZyBhIHNpbmds ZSB0YWcgdG8KPiA+IHJldHVybiBmcm9tIGxvb2t1cCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBt YXRjaGVzIGZvciBhIHdpbGRjYXJkLiBCdXQKPiA+IHdoYXRldmVyIGV4YW1wbGUgd2UgY2hvb3Nl IHNob3VsZCBub3QgcmV0dXJuIHNvbWV0aGluZyBzbyBjbGVhcmx5Cj4gPiBkaXNjb25uZWN0ZWQg ZnJvbSB0aGUgdXNlcidzIGRlc2lyZWQgb3V0Y29tZS4gQW5kIEFTQ0lJIGlzIHNpbXBsZSB0bwo+ ID4gZXhwbGFpbi4KPiA+Cj4gPiBNYXJrCj4gPgo+ID4gSm9obiBDb3dhbiB3cm90ZToKPiA+ID4g SXQncyByZWFsbHkgbGF1Z2hhYmxlIHRvIHN1Z2dlc3QgdGhhdCBpbXBsZW1lbnRhdGlvbnMgbWln aHQgdXNlIEFTQ0lJCj4gPiA+IHRhZyBvcmRlcmluZyB0byBtYWtlIGZhbGxiYWNrIGRlY2lzaW9u cyBvbiBsb29rdXAuICBJTUhPLCB0aGUgYmVoYXZpb3IKPiA+ID4gb2YgZXh0ZW5kZWQgcmFuZ2Vz IG9uIGxvb2t1cCBzaG91bGQgYmU6Cj4gPiA+Cj4gPiA+IElmIHRoZSBmaXJzdCBzdWJ0YWcgb2Yg YSBsYW5ndWFnZSByYW5nZSBpcyAnKicgYW5kIGl0IGlzCj4gPiA+IGZvbGxvd2VkIGJ5IG90aGVy IHJhbmdlcyBpbiBhIHByaW9yaXR5IGxpc3QsIHNraXAgaXQuCj4gPiA+IElmIHRoZSBmaXJzdCBz dWJ0YWcgaXMgJyonIGFuZCB0aGVyZSBhcmUgbm8gZm9sbG93aW5nCj4gPiA+IHJhbmdlcywgcmV0 dXJuIHRoZSBkZWZhdWx0IGNvbnRlbnQuICBBbGwgb3RoZXIgJyonIHN1YnRhZ3MKPiA+ID4gc2hv dWxkIGJlIHJlbW92ZWQgYmVmb3JlIGxvb2t1cCBwcm9jZXNzaW5nIGlzIGRvbmUuCj4gPiA+Cj4g PiA+IFRoYXQgaXMgc2ltcGxlLCBjbGVhciwgdG8gdGhlIHBvaW50LCBzdHJhaWdodGZvcndhcmQs IGFuZCBkb2Vzbid0Cj4gPiBwcm92aWRlCj4gPiA+IHByZXBvc3Rlcm91cyByZXN1bHRzLgo+ID4g Pgo+ID4gPgo+ID4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4gPiBMdHJ1IG1haWxpbmcgbGlzdAo+ID4gTHRydUBpZXRmLm9yZwo+ID4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cj4KPgo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QK PiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydQo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cg== ------=_Part_11660_28612516.1151167722766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZS48YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA2LzIzLzA2 LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+UmFuZHkgUHJlc3VobjwvYj4gJmx0OzxhIGhy ZWY9Im1haWx0bzpyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tIj5yYW5keV9wcmVzdWhuQG1p bmRzcHJpbmcuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQp OyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpIaSAtPGJy Pjxicj5KdXN0IHdoYXQgaXMgdGhlIHByb3Bvc2VkIGNoYW5nZSB0byB0aGUgZG9jdW1lbnQ/PGJy PlRvIGRlbGV0ZSB0aGUgZXhhbXBsZT8mbmJzcDsmbmJzcDtUaGlzIGlzIHJhdGhlciBsYXRlIGlu IHRoZSBwcm9jZXNzLDxicj5hbmQsIGFzIGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9yLCBJIGRvbid0 IHNlZSBhbnkgc2lnbmlmaWNhbnQ8YnI+YmVuZWZpdCB0byBkZWxldGluZyB0aGUgZXhhbXBsZS4K PGJyPjxicj5SYW5keTxicj48YnI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxicj5Gcm9t OiAmcXVvdDtBZGRpc29uIFBoaWxsaXBzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRkaXNv bkB5YWhvby1pbmMuY29tIj5hZGRpc29uQHlhaG9vLWluYy5jb208L2E+Jmd0Ozxicj5UbzogJnF1 b3Q7J01hcmsgRGF2aXMnJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3Ut cHJvamVjdC5vcmciPgptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZzwvYT4mZ3Q7OyAmcXVvdDsn Sm9obiBDb3dhbicmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3dhbkBjY2lsLm9yZyI+Y293 YW5AY2NpbC5vcmc8L2E+Jmd0Ozxicj5DYzogJmx0OzxhIGhyZWY9Im1haWx0bzpsdHJ1QGlldGYu b3JnIj5sdHJ1QGlldGYub3JnPC9hPiZndDs8YnI+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAy MiwgMjAwNiA0OjQ1IFBNCjxicj5TdWJqZWN0OiBSRTogW0x0cnVdIEVsaW1pbmF0aW5nIHRoZSBw cmVwb3N0ZXJvdXMgQVNDSUkgb3JkZXJpbmcgaW4gbG9va3VwPGJyPjxicj48YnI+SXQgaXMgbWVy ZWx5IGFuIGV4YW1wbGUgb2Ygd2hhdCBvbmUgY291bGQgZG8uIEl0IGlzbid0IG9ibGlnYXRvcnku IFNvIGl0IGlzbid0IHRoYXQgYmFkLCBJIGd1ZXNzLiBXZSBkb24ndCBoYXZlIHRleHQgdGhhdCBy ZXF1aXJlcyBhCjxicj5tYXBwaW5nIHRvIGJhc2ljIHJhbmdlcyBhdCB0aGUgbW9tZW50IGFuZCBk b24ndCBuZWNlc3NhcmlseSBuZWVkIHRvIGludHJvZHVjZSBpdC48YnI+PGJyPk9uIHRoZSBvdGhl ciBoYW5kLCBJIGRvbid0IHRoaW5rIEknZCBpbXBsZW1lbnQgYW4gYWxnb3JpdGhtIHRoYXQgd2F5 IGFuZCBtb3N0IHVuZGVybHlpbmcgbG9jYWxlLWxpa2UgZmFsbGJhY2sgc3lzdGVtcyB3aWxsIGRv IGFzIEkKPGJyPnN1Z2dlc3RlZC48YnI+PGJyPkFkZGlzb248YnI+PGJyPkFkZGlzb24gUGhpbGxp cHM8YnI+SW50ZXJuYXRpb25hbGl6YXRpb24gQXJjaGl0ZWN0IC0gWWFob28hIEluYy48YnI+PGJy PkludGVybmF0aW9uYWxpemF0aW9uIGlzIGFuIGFyY2hpdGVjdHVyZS48YnI+SXQgaXMgbm90IGEg ZmVhdHVyZS48YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBG cm9tOiBNYXJrIERhdmlzIFttYWlsdG86CjxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1w cm9qZWN0Lm9yZyI+bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+XTxicj4mZ3Q7IFNlbnQ6 IDIwMDblubQy5pyIMjLml6UgMTQ6NTQ8YnI+Jmd0OyBUbzogSm9obiBDb3dhbjxicj4mZ3Q7IENj OiA8YSBocmVmPSJtYWlsdG86bHRydUBpZXRmLm9yZyI+bHRydUBpZXRmLm9yZzwvYT48YnI+Jmd0 OyBTdWJqZWN0OiBSZTogW0x0cnVdIEVsaW1pbmF0aW5nIHRoZSBwcmVwb3N0ZXJvdXMgQVNDSUkg b3JkZXJpbmcgaW4gbG9va3VwCjxicj4mZ3Q7PGJyPiZndDsgSSdtIGd1ZXNzaW5nLCBidXQgb25s eSBhIGd1ZXNzLCB0aGF0IHRoaXMgaXMgcmVsYXRlZCB0byB0aGUgZm9sbG93aW5nIHRleHQ6PGJy PiZndDs8YnI+Jmd0OyAmZ3Q7IEZvciBleGFtcGxlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBy ZXR1cm4gdGhlIG1hdGNoaW5nIGNvbnRlbnQgdGhhdDxicj4mZ3Q7ICZndDsgaXMgZmlyc3QgaW4g QVNDSUktb3JkZXIuIEZvciBleGFtcGxlLCBpZiB0aGUgbGFuZ3VhZ2UgcmFuZ2Ugd2VyZQo8YnI+ Jmd0OyAmZ3Q7ICZxdW90OyotQ0gmcXVvdDsgYW5kIHRoZSBzZXQgb2YgY29udGVudCBpbmNsdWRl ZCAmcXVvdDtkZS1DSCZxdW90OywgJnF1b3Q7ZnItQ0gmcXVvdDssIGFuZCAmcXVvdDtpdC1DSCZx dW90Oyw8YnI+Jmd0OyAmZ3Q7IHRoZW4gdGhlIGNvbnRlbnQgbGFiZWxlZCAmcXVvdDtkZS1DSCZx dW90OyB3b3VsZCBiZSByZXR1cm5lZC48YnI+Jmd0OyAmcXVvdDtwcmVwb3N0ZXJvdXMmcXVvdDsg aXMgYSBvdmVyYmxvd24gbGFuZ3VhZ2UuIEFuZCBJIHN0cm9uZ2x5IGRpc2FncmVlIHdpdGgKPGJy PiZndDsgeW91ciBwcm9wb3NlZCBjaGFuZ2UuIEluIHRoZSBleGFtcGxlIHRoZXJlIGNsZWFybHkg KmV4aXN0cyogY29udGVudDxicj4mZ3Q7IG1hdGNoaW5nICotQ0guIFNvIHJldHVybmluZyB0aGUg ZGVmYXVsdCBjb250ZW50ICh3aGljaCBjb3VsZCBiZSwgc2F5LDxicj4mZ3Q7IEphcGFuZXNlKSBp cyBjbGVhcmx5ICpub3QqIHdoYXQgSSB3b3VsZCBoYXZlIGV4cGVjdGVkITxicj4KJmd0Ozxicj4m Z3Q7IFRoZXJlIGNvdWxkLCBvZiBjb3Vyc2UsIGJlIG90aGVyIHN0cmF0ZWdpZXMgZm9yIHBpY2tp bmcgYSBzaW5nbGUgdGFnIHRvPGJyPiZndDsgcmV0dXJuIGZyb20gbG9va3VwIHdoZW4gdGhlcmUg YXJlIG11bHRpcGxlIG1hdGNoZXMgZm9yIGEgd2lsZGNhcmQuIEJ1dDxicj4mZ3Q7IHdoYXRldmVy IGV4YW1wbGUgd2UgY2hvb3NlIHNob3VsZCBub3QgcmV0dXJuIHNvbWV0aGluZyBzbyBjbGVhcmx5 Cjxicj4mZ3Q7IGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSB1c2VyJ3MgZGVzaXJlZCBvdXRjb21lLiBB bmQgQVNDSUkgaXMgc2ltcGxlIHRvPGJyPiZndDsgZXhwbGFpbi48YnI+Jmd0Ozxicj4mZ3Q7IE1h cms8YnI+Jmd0Ozxicj4mZ3Q7IEpvaG4gQ293YW4gd3JvdGU6PGJyPiZndDsgJmd0OyBJdCdzIHJl YWxseSBsYXVnaGFibGUgdG8gc3VnZ2VzdCB0aGF0IGltcGxlbWVudGF0aW9ucyBtaWdodCB1c2Ug QVNDSUkKPGJyPiZndDsgJmd0OyB0YWcgb3JkZXJpbmcgdG8gbWFrZSBmYWxsYmFjayBkZWNpc2lv bnMgb24gbG9va3VwLiZuYnNwOyZuYnNwO0lNSE8sIHRoZSBiZWhhdmlvcjxicj4mZ3Q7ICZndDsg b2YgZXh0ZW5kZWQgcmFuZ2VzIG9uIGxvb2t1cCBzaG91bGQgYmU6PGJyPiZndDsgJmd0Ozxicj4m Z3Q7ICZndDsgSWYgdGhlIGZpcnN0IHN1YnRhZyBvZiBhIGxhbmd1YWdlIHJhbmdlIGlzICcqJyBh bmQgaXQgaXM8YnI+CiZndDsgJmd0OyBmb2xsb3dlZCBieSBvdGhlciByYW5nZXMgaW4gYSBwcmlv cml0eSBsaXN0LCBza2lwIGl0Ljxicj4mZ3Q7ICZndDsgSWYgdGhlIGZpcnN0IHN1YnRhZyBpcyAn KicgYW5kIHRoZXJlIGFyZSBubyBmb2xsb3dpbmc8YnI+Jmd0OyAmZ3Q7IHJhbmdlcywgcmV0dXJu IHRoZSBkZWZhdWx0IGNvbnRlbnQuJm5ic3A7Jm5ic3A7QWxsIG90aGVyICcqJyBzdWJ0YWdzPGJy PiZndDsgJmd0OyBzaG91bGQgYmUgcmVtb3ZlZCBiZWZvcmUgbG9va3VwIHByb2Nlc3NpbmcgaXMg ZG9uZS4KPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGhhdCBpcyBzaW1wbGUsIGNsZWFyLCB0 byB0aGUgcG9pbnQsIHN0cmFpZ2h0Zm9yd2FyZCwgYW5kIGRvZXNuJ3Q8YnI+Jmd0OyBwcm92aWRl PGJyPiZndDsgJmd0OyBwcmVwb3N0ZXJvdXMgcmVzdWx0cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsg Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPGJyPiZndDsgTHRydSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJt YWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxicj48YnI+PGJyPjxicj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo8YnI+THRydSBtYWlsaW5n IGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+ PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUi Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj48 YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjxi cj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRy dUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydSI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dTwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_11660_28612516.1151167722766-- --===============2051519227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2051519227==-- From ltru-bounces@ietf.org Sun Jun 25 12:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXDO-0002pD-2m; Sun, 25 Jun 2006 12:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXDN-0002p0-Cv for ltru@ietf.org; Sun, 25 Jun 2006 12:12:01 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXDN-0001F3-3P for ltru@ietf.org; Sun, 25 Jun 2006 12:12:01 -0400 Received: from h-68-165-4-59.snvacaid.dynamic.covad.net ([68.165.4.59] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FuXDM-0004CQ-00 for ltru@ietf.org; Sun, 25 Jun 2006 12:12:00 -0400 Message-ID: <003001c69872$267c1e80$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002701c6978d$37a5bf30$650a0a0a@ds.corp.yahoo.com> Subject: Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup Date: Sun, 25 Jun 2006 09:12:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Hmmm. You're right. I don't know why it showed up in my inbox last Friday. Never mind! Randy ----- Original Message ----- From: "Addison Phillips" To: "'Randy Presuhn'" ; Sent: Saturday, June 24, 2006 5:53 AM Subject: RE: [Ltru] Eliminating the preposterous ASCII ordering in lookup Uh... Randy...? That mail was sent in February? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: vendredi 23 juin 2006 23:28 > To: ltru@ietf.org > Subject: Re: [Ltru] Eliminating the preposterous ASCII > ordering in lookup > > Hi - > > Just what is the proposed change to the document? > To delete the example? This is rather late in the process, > and, as a technical contributor, I don't see any significant > benefit to deleting the example. > > Randy > > ----- Original Message ----- > From: "Addison Phillips" > To: "'Mark Davis'" ; "'John > Cowan'" > Cc: > Sent: Wednesday, February 22, 2006 4:45 PM > Subject: RE: [Ltru] Eliminating the preposterous ASCII > ordering in lookup > > > It is merely an example of what one could do. It isn't > obligatory. So it isn't that bad, I guess. We don't have text > that requires a > mapping to basic ranges at the moment and don't necessarily > need to introduce it. > > On the other hand, I don't think I'd implement an algorithm > that way and most underlying locale-like fallback systems will do as I > suggested. > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > Sent: 2006年2月22日 14:54 > > To: John Cowan > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Eliminating the preposterous ASCII > ordering in lookup > > > > I'm guessing, but only a guess, that this is related to the > following text: > > > > > For example, an implementation could return the matching > content that > > > is first in ASCII-order. For example, if the language range were > > > "*-CH" and the set of content included "de-CH", "fr-CH", > and "it-CH", > > > then the content labeled "de-CH" would be returned. > > "preposterous" is a overblown language. And I strongly disagree with > > your proposed change. In the example there clearly *exists* content > > matching *-CH. So returning the default content (which > could be, say, > > Japanese) is clearly *not* what I would have expected! > > > > There could, of course, be other strategies for picking a > single tag to > > return from lookup when there are multiple matches for a > wildcard. But > > whatever example we choose should not return something so clearly > > disconnected from the user's desired outcome. And ASCII is simple to > > explain. > > > > Mark > > > > John Cowan wrote: > > > It's really laughable to suggest that implementations > might use ASCII > > > tag ordering to make fallback decisions on lookup. IMHO, > the behavior > > > of extended ranges on lookup should be: > > > > > > If the first subtag of a language range is '*' and it is > > > followed by other ranges in a priority list, skip it. > > > If the first subtag is '*' and there are no following > > > ranges, return the default content. All other '*' subtags > > > should be removed before lookup processing is done. > > > > > > That is simple, clear, to the point, straightforward, and doesn't > > provide > > > preposterous results. > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jun 25 21:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fufib-0003Jz-Kd; Sun, 25 Jun 2006 21:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fufia-0003Jt-Ks for ltru@ietf.org; Sun, 25 Jun 2006 21:16:48 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FufiY-00080h-0S for ltru@ietf.org; Sun, 25 Jun 2006 21:16:48 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5Q1GdWx013021; Mon, 26 Jun 2006 10:16:39 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5f98_6b946e18_04b1_11db_9427_0014221fa3c9; Mon, 26 Jun 2006 10:16:39 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5Q1GVmj017152; Mon, 26 Jun 2006 10:16:37 +0900 Message-Id: <6.0.0.20.2.20060625210708.059646a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 25 Jun 2006 21:12:59 +0900 To: "Addison Phillips" , "'Randy Presuhn'" , From: Martin Duerst Subject: RE: [Ltru] Eliminating the preposterous ASCII ordering in lookup In-Reply-To: <002701c6978d$37a5bf30$650a0a0a@ds.corp.yahoo.com> References: <002f01c69757$4b343760$6501a8c0@oemcomputer> <002701c6978d$37a5bf30$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 21:53 06/06/24, Addison Phillips wrote: >Uh... Randy...? > >That mail was sent in February? Yes indeed. We have just finished addressing all the IETF Last Call comments. Except in the case that somebody finds a really major bug, or unless we get some comments from IESG members, discussions on the matching draft are closed. Regards, Martin. >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: vendredi 23 juin 2006 23:28 >> Hi - >> >> Just what is the proposed change to the document? >> To delete the example? This is rather late in the process, >> and, as a technical contributor, I don't see any significant >> benefit to deleting the example. >> >> Randy >> >> ----- Original Message ----- >> From: "Addison Phillips" >> To: "'Mark Davis'" ; "'John >> Cowan'" >> Cc: >> Sent: Wednesday, February 22, 2006 4:45 PM >> Subject: RE: [Ltru] Eliminating the preposterous ASCII >> ordering in lookup #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 27 04:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8qI-0003b9-EZ; Tue, 27 Jun 2006 04:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8qG-0003b4-Vq for ltru@ietf.org; Tue, 27 Jun 2006 04:22:40 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv8qG-0006R5-GM for ltru@ietf.org; Tue, 27 Jun 2006 04:22:40 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5R8MNWg015559; Tue, 27 Jun 2006 09:22:23 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5R8MIZP015428; Tue, 27 Jun 2006 09:22:23 +0100 Message-Id: <200606270822.k5R8MIZP015428@mta6.iomartmail.com> From: "Debbie Garside" To: "'LTRU Working Group'" Date: Tue, 27 Jun 2006 09:22:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcaZws1Q37aMDb5pRAOCrDyITbo8pA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 'Doug Ewell' Subject: [Ltru] Preliminary Investigation into Application of ISO 11179 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Findings of a preliminary investigation into the application of ISO 11179 to the RFC3066bis Registry Cost Initial investigations suggest that ISO 11179 can be applied to the Registry at a base level for very little cost. The main cost is in mapping the ISO 11179 terminology to the existing Registry terminology and a number of additional data elements would be required. The Registry already incorporates a system of metadata elements that are consistent with the model presented within ISO 11179. In particular the value of the following aspects of ISO 11179-6 should be investigated: Identification The attributes registration authority identifier (RAI), data identifier (DI), and version identifier (VI) constitute the international registration data identifier (IRDI). At least one IRDI is required for an administered item. Data identifiers are assigned by a Registration Authority; data identifiers shall be unique within the domain of a Registration Authority. Requirements for a Registration Authority, and a discussion of the IRDI, appear in ISO/IEC 11179-6. As each Registration Authority may determine its own DI assignment scheme, there is no guarantee that the DI by itself will uniquely identify an administered item. For example, if two authorities both use sequential 6-digit numbers, there may be two administered items with the same DI's; however, the administered items will almost certainly not be the same. If one administered item appears in two registers, it will have two DI's. Therefore, both the DI and the RAI are necessary for identification of an administered item. If particular attributes of an administered item change, then a new version of the administered item shall be created and registered. The registrar shall determine these attributes. In such a case, a VI is required to complete the unique identification of an administered item. For further guidance, see ISO/IEC 11179-6. An IRDI can serve as a key when exchanging data among information systems, organizations, or other parties who wish to share a specific administered item, but might not utilize the same names or contexts. ISO/IEC 11179 does not specify the format or content of a unique DI. The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. Implications for the LTRU Registry The DI (or UI - Unique Identifier) cannot be the Subtag as there are already conflicting Subtags within the registry (e.g. cy/CY). It is more preferable that the unique identifier be the chosen language/country/script name (please note, this is not the preferred name). This would fit with the current ISO 639-3, -5 and -6 models and open the Registry to adoption by meta-data knowledge grids. (I will take a good look at the naming conventions within ISO 3166-1 at a later date but prior to publication of FDIS 3166-1). Anomalies within ISO naming conventions of standards issued prior to the adoption of ISO 11179 can be dealt with on a case by case basis via set rules. The Subtag would become a "Representation" with the name being the unique "Data Identifier". This would involve having a "Primary Description" which would form the DI. In reviewing the "Required Metadata Attributes" for a "Preferred Standard" Status administered item, preliminary investigations reveal no serious additional requirements other than those already mentioned here. Some manipulation and interpretation of registry data and standard mandatory requirements would be required but no difficulties are envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) Benefits The ISO 11179 model allows for there being conflicting codes between different meta-data registries in conformity with ISO 11179; that is part of the conceptual model. ("in conformity with" is correct - there are essential parts of the standard). In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 conformant meta-data registries thus facilitating data exchange/interchange whilst giving the LTRU Registry ownership of the data elements contained therein - they become LTRU elements giving room for manoeuvre should ISO get it wrong. This will make language tags more meaningful in the future. The key word here is "linkage". ISO 11179 conformant meta-data registries facilitate the creation of knowledge grids, grid computing and the semantic web! Conclusion At first glance the cost/value ratio favours ISO 11179; there appears to be very little cost yet the true benefits of future interoperability and data exchange are unknown. It is recommended that further investigation be conducted before application of ISO 11179 can be discussed at WG level. Further benefits with regard to data interchange should be explored. It is further recommended that the "investigation into application of ISO 11179 Meta Data Registries to the Registry and its registration procedures be conducted by nominated members of the WG with a view to application" be added to the new LTRU Charter. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 27 06:25:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAkh-0003zJ-Uv; Tue, 27 Jun 2006 06:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAkh-0003z9-8o for ltru@ietf.org; Tue, 27 Jun 2006 06:25:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9vg-0000mN-93 for ltru@ietf.org; Tue, 27 Jun 2006 05:32:20 -0400 Received: from mta5.iomartmail.com ([62.128.193.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv9r9-00025V-C5 for ltru@ietf.org; Tue, 27 Jun 2006 05:27:40 -0400 Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5R9RQnD014130; Tue, 27 Jun 2006 10:27:26 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5R9RLCS013899; Tue, 27 Jun 2006 10:27:26 +0100 Message-Id: <200606270927.k5R9RLCS013899@mta5.iomartmail.com> From: "Debbie Garside" To: "'Debbie Garside'" , "'LTRU Working Group'" Date: Tue, 27 Jun 2006 10:27:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: thread-index: AcaZws1Q37aMDb5pRAOCrDyITbo8pAACIrLw X-Spam-Score: -2.6 (--) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 'Doug Ewell' Subject: [Ltru] RE: Preliminary Investigation into Application of ISO 11179 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org CORRECTION I wrote: ---- The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. ---- It should read: ---- The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the RAI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. ---- The change is from "IRDI" to "RAI" Debbie > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 27 June 2006 09:22 > To: 'LTRU Working Group' > Cc: 'Doug Ewell' > Subject: Preliminary Investigation into Application of ISO 11179 > > Findings of a preliminary investigation into the application > of ISO 11179 to the RFC3066bis Registry > > Cost > Initial investigations suggest that ISO 11179 can be applied > to the Registry at a base level for very little cost. The > main cost is in mapping the ISO 11179 terminology to the > existing Registry terminology and a number of additional data > elements would be required. The Registry already > incorporates a system of metadata elements that are > consistent with the model presented within ISO 11179. > > In particular the value of the following aspects of ISO > 11179-6 should be investigated: > > Identification > The attributes registration authority identifier (RAI), data > identifier (DI), and version identifier (VI) constitute the > international registration data identifier (IRDI). At least > one IRDI is required for an administered item. > > Data identifiers are assigned by a Registration Authority; > data identifiers shall be unique within the domain of a > Registration Authority. > > Requirements for a Registration Authority, and a discussion > of the IRDI, appear in ISO/IEC 11179-6. > > As each Registration Authority may determine its own DI > assignment scheme, there is no guarantee that the DI by > itself will uniquely identify an administered item. For > example, if two authorities both use sequential 6-digit > numbers, there may be two administered items with the same > DI's; however, the administered items will almost certainly > not be the same. > > If one administered item appears in two registers, it will > have two DI's. Therefore, both the DI and the RAI are > necessary for identification of an administered item. > > If particular attributes of an administered item change, then > a new version of the administered item shall be created and > registered. The registrar shall determine these attributes. > In such a case, a VI is required to complete the unique > identification of an administered item. > > For further guidance, see ISO/IEC 11179-6. > > An IRDI can serve as a key when exchanging data among > information systems, organizations, or other parties who wish > to share a specific administered item, but might not utilize > the same names or contexts. > > ISO/IEC 11179 does not specify the format or content of a unique DI. > > The IETF (or LTRU) would need to apply for an International > Code Designator (ICD) - a four integer code; this coupled > with the organization name as well as a "department" > identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The > ICD would be registered by the RA of ISO/IEC 6523 > Organization Codes as Registration Authority Identifier which > is currently BSI. > > Implications for the LTRU Registry > The DI (or UI - Unique Identifier) cannot be the Subtag as > there are already conflicting Subtags within the registry > (e.g. cy/CY). It is more preferable that the unique > identifier be the chosen language/country/script name (please > note, this is not the preferred name). This would fit with > the current ISO 639-3, -5 and -6 models and open the Registry > to adoption by meta-data knowledge grids. (I will take a good > look at the naming conventions within ISO 3166-1 at a later > date but prior to publication of FDIS 3166-1). > > Anomalies within ISO naming conventions of standards issued > prior to the adoption of ISO 11179 can be dealt with on a > case by case basis via set rules. > > The Subtag would become a "Representation" with the name > being the unique "Data Identifier". This would involve having > a "Primary Description" which would form the DI. > > In reviewing the "Required Metadata Attributes" for a > "Preferred Standard" Status administered item, preliminary > investigations reveal no serious additional requirements > other than those already mentioned here. Some manipulation > and interpretation of registry data and standard mandatory > requirements would be required but no difficulties are > envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); > Table B-8 (p.34) > > Benefits > The ISO 11179 model allows for there being conflicting codes > between different meta-data registries in conformity with ISO > 11179; that is part of the conceptual model. ("in conformity > with" is correct - there are essential parts of the standard). > > In essence, the ISO 11179 meta-model supports linkage to > other ISO 11179 conformant meta-data registries thus > facilitating data exchange/interchange whilst giving the LTRU > Registry ownership of the data elements contained therein - > they become LTRU elements giving room for manoeuvre should > ISO get it wrong. > > This will make language tags more meaningful in the future. > The key word here is "linkage". ISO 11179 conformant > meta-data registries facilitate the creation of knowledge > grids, grid computing and the semantic web! > > Conclusion > At first glance the cost/value ratio favours ISO 11179; there > appears to be very little cost yet the true benefits of > future interoperability and data exchange are unknown. > > It is recommended that further investigation be conducted > before application of ISO 11179 can be discussed at WG level. > > Further benefits with regard to data interchange should be explored. > > It is further recommended that the "investigation into > application of ISO 11179 Meta Data Registries to the Registry > and its registration procedures be conducted by nominated > members of the WG with a view to application" be added to the > new LTRU Charter. > > Best regards > > > Debbie Garside > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jun 27 16:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKGR-0002gl-PI; Tue, 27 Jun 2006 16:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKGQ-0002fw-Ak; Tue, 27 Jun 2006 16:34:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwT-0005Q8-7o; Tue, 27 Jun 2006 16:13:49 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJaS-0003X3-BX; Tue, 27 Jun 2006 15:51:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2jx016436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005GA-UR; Tue, 27 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-15.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Matching of Language Tags Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-15.txt Pages : 25 Date : 2006-6-27 This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27115746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27115746.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Tue Jun 27 20:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNaO-0002vw-4r; Tue, 27 Jun 2006 20:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNaM-0002vZ-QI for ltru@ietf.org; Tue, 27 Jun 2006 20:07:14 -0400 Received: from outbound-haw.frontbridge.com ([12.129.219.97] helo=outbound3-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvNaL-0001Br-Kj for ltru@ietf.org; Tue, 27 Jun 2006 20:07:14 -0400 Received: from outbound3-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-haw-R.bigfish.com (Postfix) with ESMTP id 3DDA51607566; Wed, 28 Jun 2006 00:07:13 +0000 (UTC) Received: from mail24-haw-R.bigfish.com (unknown [192.168.51.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound3-haw.bigfish.com (Postfix) with ESMTP id 32DE4160748E; Wed, 28 Jun 2006 00:07:13 +0000 (UTC) Received: from mail24-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail24-haw-R.bigfish.com (Postfix) with ESMTP id 1F7ED4D271E; Wed, 28 Jun 2006 00:07:13 +0000 (UTC) X-BigFish: VP Received: by mail24-haw (MessageSwitch) id 11514532336564_5430; Wed, 28 Jun 2006 00:07:13 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail24-haw.bigfish.com (Postfix) with ESMTP id E54E94D271F; Wed, 28 Jun 2006 00:07:12 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006062717091800-354115 ; Tue, 27 Jun 2006 17:09:18 -0700 In-Reply-To: <200606270822.k5R8MIZP015428@mta6.iomartmail.com> To: "Debbie Garside" Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 27 Jun 2006 17:06:18 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 06/27/2006 17:06:19, Serialize complete at 06/27/2006 17:06:19, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/27/2006 05:09:18 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 06/27/2006 05:09:19 PM, Serialize complete at 06/27/2006 05:09:19 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1328618759==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1328618759== Content-Type: multipart/alternative; boundary="=_alternative 0000A7F08825719B_=" This is a multipart message in MIME format. --=_alternative 0000A7F08825719B_= Content-Type: text/plain; charset="US-ASCII" Debbie, Did you review all of ISO 11179 or just 11179-6? There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this. The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer. The hierarchy, as I understand it, would be something like this: Data Concept Language Code: A standardized code used to identify a particular language or dialect. Data Elements [Data Concept + Representation Class] related to "Language Code" data concept = ISO 639-1 Language Code: A two-letter code assigned by the ISO 639-1 standard to identify a particular language. ISO 639-2/B Language Code ISO 639-2/T Language Code ISO 639-3 Language Code ISO 639-6 Language Code Value Domain Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US". ... For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic: Data Concept = Script Code Data Element = ISO 15924 Script Code Data Concept = Country Code Data Element = ISO 3166 Country Code Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as: En-US Language Name Fr-FR Language Name En-US Script Name En-US Country Name etc. These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think. I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing. :) Best regards, Karen Broome Sony Pictures Entertainment "Debbie Garside" 06/27/2006 01:22 AM To "'LTRU Working Group'" cc 'Doug Ewell' Subject [Ltru] Preliminary Investigation into Application of ISO 11179 Findings of a preliminary investigation into the application of ISO 11179 to the RFC3066bis Registry Cost Initial investigations suggest that ISO 11179 can be applied to the Registry at a base level for very little cost. The main cost is in mapping the ISO 11179 terminology to the existing Registry terminology and a number of additional data elements would be required. The Registry already incorporates a system of metadata elements that are consistent with the model presented within ISO 11179. In particular the value of the following aspects of ISO 11179-6 should be investigated: Identification The attributes registration authority identifier (RAI), data identifier (DI), and version identifier (VI) constitute the international registration data identifier (IRDI). At least one IRDI is required for an administered item. Data identifiers are assigned by a Registration Authority; data identifiers shall be unique within the domain of a Registration Authority. Requirements for a Registration Authority, and a discussion of the IRDI, appear in ISO/IEC 11179-6. As each Registration Authority may determine its own DI assignment scheme, there is no guarantee that the DI by itself will uniquely identify an administered item. For example, if two authorities both use sequential 6-digit numbers, there may be two administered items with the same DI's; however, the administered items will almost certainly not be the same. If one administered item appears in two registers, it will have two DI's. Therefore, both the DI and the RAI are necessary for identification of an administered item. If particular attributes of an administered item change, then a new version of the administered item shall be created and registered. The registrar shall determine these attributes. In such a case, a VI is required to complete the unique identification of an administered item. For further guidance, see ISO/IEC 11179-6. An IRDI can serve as a key when exchanging data among information systems, organizations, or other parties who wish to share a specific administered item, but might not utilize the same names or contexts. ISO/IEC 11179 does not specify the format or content of a unique DI. The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. Implications for the LTRU Registry The DI (or UI - Unique Identifier) cannot be the Subtag as there are already conflicting Subtags within the registry (e.g. cy/CY). It is more preferable that the unique identifier be the chosen language/country/script name (please note, this is not the preferred name). This would fit with the current ISO 639-3, -5 and -6 models and open the Registry to adoption by meta-data knowledge grids. (I will take a good look at the naming conventions within ISO 3166-1 at a later date but prior to publication of FDIS 3166-1). Anomalies within ISO naming conventions of standards issued prior to the adoption of ISO 11179 can be dealt with on a case by case basis via set rules. The Subtag would become a "Representation" with the name being the unique "Data Identifier". This would involve having a "Primary Description" which would form the DI. In reviewing the "Required Metadata Attributes" for a "Preferred Standard" Status administered item, preliminary investigations reveal no serious additional requirements other than those already mentioned here. Some manipulation and interpretation of registry data and standard mandatory requirements would be required but no difficulties are envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) Benefits The ISO 11179 model allows for there being conflicting codes between different meta-data registries in conformity with ISO 11179; that is part of the conceptual model. ("in conformity with" is correct - there are essential parts of the standard). In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 conformant meta-data registries thus facilitating data exchange/interchange whilst giving the LTRU Registry ownership of the data elements contained therein - they become LTRU elements giving room for manoeuvre should ISO get it wrong. This will make language tags more meaningful in the future. The key word here is "linkage". ISO 11179 conformant meta-data registries facilitate the creation of knowledge grids, grid computing and the semantic web! Conclusion At first glance the cost/value ratio favours ISO 11179; there appears to be very little cost yet the true benefits of future interoperability and data exchange are unknown. It is recommended that further investigation be conducted before application of ISO 11179 can be discussed at WG level. Further benefits with regard to data interchange should be explored. It is further recommended that the "investigation into application of ISO 11179 Meta Data Registries to the Registry and its registration procedures be conducted by nominated members of the WG with a view to application" be added to the new LTRU Charter. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 0000A7F08825719B_= Content-Type: text/html; charset="US-ASCII"
Debbie,

Did you review all of ISO 11179 or just 11179-6?

There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this.  The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer.

The hierarchy, as I understand it, would be something like this:

Data Concept
        Language Code: A standardized code used to identify a particular language or dialect.

Data Elements [Data Concept + Representation Class] related to "Language Code" data concept =
  1. ISO 639-1 Language Code:  A two-letter code assigned by the ISO 639-1 standard to identify a particular language.
  2. ISO 639-2/B Language Code
  3. ISO 639-2/T Language Code
  4. ISO 639-3 Language Code
  5. ISO 639-6 Language Code

Value Domain
        Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US".

...

For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic:

Data Concept = Script Code
Data Element = ISO 15924 Script Code

Data Concept = Country Code
Data Element = ISO 3166 Country Code

Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as:
  1. En-US Language Name
  2. Fr-FR Language Name
  3. En-US Script Name
  4. En-US Country Name
etc.

These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think.

I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing.  :)

Best regards,

Karen Broome
Sony Pictures Entertainment


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

06/27/2006 01:22 AM

To
"'LTRU Working Group'" <ltru@ietf.org>
cc
'Doug Ewell' <dewell@adelphia.net>
Subject
[Ltru] Preliminary Investigation into Application of ISO 11179





Findings of a preliminary investigation into the application of ISO 11179 to
the RFC3066bis Registry

Cost
Initial investigations suggest that ISO 11179 can be applied to the Registry
at a base level for very little cost.  The main cost is in mapping the ISO
11179 terminology to the existing Registry terminology and a number of
additional data elements would be required.  The Registry already
incorporates a system of metadata elements that are consistent with the
model presented within ISO 11179.  

In particular the value of the following aspects of ISO 11179-6 should be
investigated:

Identification
The attributes registration authority identifier (RAI), data identifier
(DI), and version identifier (VI) constitute the international registration
data identifier (IRDI). At least one IRDI is required for an administered
item.

Data identifiers are assigned by a Registration Authority; data identifiers
shall be unique within the domain of a Registration Authority.

Requirements for a Registration Authority, and a discussion of the IRDI,
appear in ISO/IEC 11179-6.

As each Registration Authority may determine its own DI assignment scheme,
there is no guarantee that the DI by itself will uniquely identify an
administered item. For example, if two authorities both use sequential
6-digit numbers, there may be two administered items with the same DI's;
however, the administered items will almost certainly not be the same.

If one administered item appears in two registers, it will have two DI's.
Therefore, both the DI and the RAI are necessary for identification of an
administered item.

If particular attributes of an administered item change, then a new version
of the administered item shall be created and registered. The registrar
shall determine these attributes. In such a case, a VI is required to
complete the unique identification of an administered item.

For further guidance, see ISO/IEC 11179-6.

An IRDI can serve as a key when exchanging data among information systems,
organizations, or other parties who wish to share a specific administered
item, but might not utilize the same names or contexts.

ISO/IEC 11179 does not specify the format or content of a unique DI.

The IETF (or LTRU) would need to apply for an International Code Designator
(ICD) - a four integer code; this coupled with the organization name as well
as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.
The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as
Registration Authority Identifier which is currently BSI.  

Implications for the LTRU Registry
The DI (or UI - Unique Identifier) cannot be the Subtag as there are already
conflicting Subtags within the registry (e.g. cy/CY).  It is more preferable
that the unique identifier be the chosen language/country/script name
(please note, this is not the preferred name).  This would fit with the
current ISO 639-3, -5 and -6 models and open the Registry to adoption by
meta-data knowledge grids. (I will take a good look at the naming
conventions within ISO 3166-1 at a later date but prior to publication of
FDIS 3166-1).  

Anomalies within ISO naming conventions of standards issued prior to the
adoption of ISO 11179 can be dealt with on a case by case basis via set
rules.  

The Subtag would become a "Representation" with the name being the unique
"Data Identifier". This would involve having a "Primary Description" which
would form the DI.

In reviewing the "Required Metadata Attributes" for a "Preferred Standard"
Status administered item, preliminary investigations reveal no serious
additional requirements other than those already mentioned here. Some
manipulation and interpretation of registry data and standard mandatory
requirements would be required but no difficulties are envisaged. I would
refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34)

Benefits
The ISO 11179 model allows for there being conflicting codes between
different meta-data registries in conformity with ISO 11179; that is part of
the conceptual model.  ("in conformity with" is correct - there are
essential parts of the standard).

In essence, the ISO 11179 meta-model supports linkage to other ISO 11179
conformant meta-data registries thus facilitating data exchange/interchange
whilst giving the LTRU Registry ownership of the data elements contained
therein - they become LTRU elements giving room for manoeuvre should ISO get
it wrong.

This will make language tags more meaningful in the future.  The key word
here is "linkage".  ISO 11179 conformant meta-data registries facilitate the
creation of knowledge grids, grid computing and the semantic web!

Conclusion
At first glance the cost/value ratio favours ISO 11179; there appears to be
very little cost yet the true benefits of future interoperability and data
exchange are unknown.  

It is recommended that further investigation be conducted before application
of ISO 11179 can be discussed at WG level.

Further benefits with regard to data interchange should be explored.

It is further recommended that the "investigation into application of ISO
11179 Meta Data Registries to the Registry and its registration procedures
be conducted by nominated members of the WG with a view to application" be
added to the new LTRU Charter.  

Best regards


Debbie Garside



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 0000A7F08825719B_=-- --===============1328618759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1328618759==-- From ltru-bounces@ietf.org Wed Jun 28 00:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvRvB-0006xp-GX; Wed, 28 Jun 2006 00:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvRv9-0006xh-RI for ltru@ietf.org; Wed, 28 Jun 2006 00:44:59 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvRv8-0002FT-Kz for ltru@ietf.org; Wed, 28 Jun 2006 00:44:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FvRv6-0001EL-KL; Wed, 28 Jun 2006 00:44:56 -0400 Date: Wed, 28 Jun 2006 00:44:56 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179 Message-ID: <20060628044456.GB2361@ccil.org> References: <200606270822.k5R8MIZP015428@mta6.iomartmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com scripsit: > I'm not opposed to further discussion of this moving forward. I only > question how valuable this is for a standard that has so few data > elements. Exactly what I had in mind. Although language tags are metadata from the viewpoint of users, from *our* viewpoint they are data, and *their* metadata are comparatively trivial, enough so that they don't seem to me to require the machinery of 11179 at all. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like cowan@ccil.org ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 03:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUiR-0002eD-VE; Wed, 28 Jun 2006 03:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUiQ-0002e8-SQ for ltru@ietf.org; Wed, 28 Jun 2006 03:44:02 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUiP-0007E3-Jr for ltru@ietf.org; Wed, 28 Jun 2006 03:44:02 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5S7htAN019347; Wed, 28 Jun 2006 08:43:55 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k5S7hncc019253; Wed, 28 Jun 2006 08:43:54 +0100 Message-Id: <200606280743.k5S7hncc019253@mta6.iomartmail.com> From: "Debbie Garside" To: Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Date: Wed, 28 Jun 2006 08:43:50 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: thread-index: AcaaRtGC6+ZxHRxlRvygUz+eA4jaagAPctTw X-Spam-Score: 2.1 (++) X-Scan-Signature: dd055ca905b7a8538e016a7989511901 Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501619607==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1501619607== Content-Type: multipart/alternative; boundary="----=_NextPart_000_036C_01C69A8E.FAD5FFC0" This is a multi-part message in MIME format. ------=_NextPart_000_036C_01C69A8E.FAD5FFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Karen Thanks for your input. I need to do a little more reading before I respond so it may be a few days :-) I think there are two ways of looking at 11179: 1. As a standard to assist in the design of a Meta-data Registry 2. As a standard to apply to an existing Meta-Data registry. I have been looking at what is as a bare minimum absolutely necessary in order to apply ISO 11179 to the LTRU Registry. I have read the whole standard but I need to do further depth reading to see what is required for the Registry to be conformant. There are one or two things that you have mentioned that do not fit with my interpretation but I would not want to say more until I have studied it further. best regards Debbie _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 28 June 2006 01:06 To: Debbie Garside Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179 Debbie, Did you review all of ISO 11179 or just 11179-6? There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this. The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer. The hierarchy, as I understand it, would be something like this: Data Concept Language Code: A standardized code used to identify a particular language or dialect. Data Elements [Data Concept + Representation Class] related to "Language Code" data concept = 1. ISO 639-1 Language Code: A two-letter code assigned by the ISO 639-1 standard to identify a particular language. 2. ISO 639-2/B Language Code 3. ISO 639-2/T Language Code 4. ISO 639-3 Language Code 5. ISO 639-6 Language Code Value Domain Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US". ... For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic: Data Concept = Script Code Data Element = ISO 15924 Script Code Data Concept = Country Code Data Element = ISO 3166 Country Code Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as: 1. En-US Language Name 2. Fr-FR Language Name 3. En-US Script Name 4. En-US Country Name etc. These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think. I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing. :) Best regards, Karen Broome Sony Pictures Entertainment "Debbie Garside" 06/27/2006 01:22 AM To "'LTRU Working Group'" cc 'Doug Ewell' Subject [Ltru] Preliminary Investigation into Application of ISO 11179 Findings of a preliminary investigation into the application of ISO 11179 to the RFC3066bis Registry Cost Initial investigations suggest that ISO 11179 can be applied to the Registry at a base level for very little cost. The main cost is in mapping the ISO 11179 terminology to the existing Registry terminology and a number of additional data elements would be required. The Registry already incorporates a system of metadata elements that are consistent with the model presented within ISO 11179. In particular the value of the following aspects of ISO 11179-6 should be investigated: Identification The attributes registration authority identifier (RAI), data identifier (DI), and version identifier (VI) constitute the international registration data identifier (IRDI). At least one IRDI is required for an administered item. Data identifiers are assigned by a Registration Authority; data identifiers shall be unique within the domain of a Registration Authority. Requirements for a Registration Authority, and a discussion of the IRDI, appear in ISO/IEC 11179-6. As each Registration Authority may determine its own DI assignment scheme, there is no guarantee that the DI by itself will uniquely identify an administered item. For example, if two authorities both use sequential 6-digit numbers, there may be two administered items with the same DI's; however, the administered items will almost certainly not be the same. If one administered item appears in two registers, it will have two DI's. Therefore, both the DI and the RAI are necessary for identification of an administered item. If particular attributes of an administered item change, then a new version of the administered item shall be created and registered. The registrar shall determine these attributes. In such a case, a VI is required to complete the unique identification of an administered item. For further guidance, see ISO/IEC 11179-6. An IRDI can serve as a key when exchanging data among information systems, organizations, or other parties who wish to share a specific administered item, but might not utilize the same names or contexts. ISO/IEC 11179 does not specify the format or content of a unique DI. The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. Implications for the LTRU Registry The DI (or UI - Unique Identifier) cannot be the Subtag as there are already conflicting Subtags within the registry (e.g. cy/CY). It is more preferable that the unique identifier be the chosen language/country/script name (please note, this is not the preferred name). This would fit with the current ISO 639-3, -5 and -6 models and open the Registry to adoption by meta-data knowledge grids. (I will take a good look at the naming conventions within ISO 3166-1 at a later date but prior to publication of FDIS 3166-1). Anomalies within ISO naming conventions of standards issued prior to the adoption of ISO 11179 can be dealt with on a case by case basis via set rules. The Subtag would become a "Representation" with the name being the unique "Data Identifier". This would involve having a "Primary Description" which would form the DI. In reviewing the "Required Metadata Attributes" for a "Preferred Standard" Status administered item, preliminary investigations reveal no serious additional requirements other than those already mentioned here. Some manipulation and interpretation of registry data and standard mandatory requirements would be required but no difficulties are envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) Benefits The ISO 11179 model allows for there being conflicting codes between different meta-data registries in conformity with ISO 11179; that is part of the conceptual model. ("in conformity with" is correct - there are essential parts of the standard). In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 conformant meta-data registries thus facilitating data exchange/interchange whilst giving the LTRU Registry ownership of the data elements contained therein - they become LTRU elements giving room for manoeuvre should ISO get it wrong. This will make language tags more meaningful in the future. The key word here is "linkage". ISO 11179 conformant meta-data registries facilitate the creation of knowledge grids, grid computing and the semantic web! Conclusion At first glance the cost/value ratio favours ISO 11179; there appears to be very little cost yet the true benefits of future interoperability and data exchange are unknown. It is recommended that further investigation be conducted before application of ISO 11179 can be discussed at WG level. Further benefits with regard to data interchange should be explored. It is further recommended that the "investigation into application of ISO 11179 Meta Data Registries to the Registry and its registration procedures be conducted by nominated members of the WG with a view to application" be added to the new LTRU Charter. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_036C_01C69A8E.FAD5FFC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Karen
 
Thanks for your input.  I need to do a = little more=20 reading before I respond so it may be a few days :-)
 
I think there are two ways of looking at 11179: = 1. As a=20 standard to assist in the design of a Meta-data Registry 2. As a = standard to=20 apply to an existing Meta-Data registry.
 
I have been looking at what is as a bare = minimum absolutely=20 necessary in order to apply ISO 11179 to the LTRU Registry.  I have = read=20 the whole standard but I need to do further depth reading to see = what is=20 required for the Registry to be conformant.
 
There are one or two things that you have = mentioned that do=20 not fit with my interpretation but I would not want to say more until I = have=20 studied it further.
 
best regards
 
Debbie
 

From: Karen_Broome@spe.sony.com=20 [mailto:Karen_Broome@spe.sony.com]
Sent: 28 June 2006=20 01:06
To: Debbie Garside
Cc: 'Doug Ewell'; 'LTRU = Working=20 Group'
Subject: Re: [Ltru] Preliminary Investigation into=20 Application of ISO 11179


Debbie, =

Did you review all of ISO 11179 or just = 11179-6?=20

There is a lot more to = ISO 11179=20 than just the administrative practices (-6) and the previous parts = discuss a=20 hierarchical metadata model not mentioned in your review below. I = think you're=20 confusing the terms "value" and "representation" and the other = sections=20 provide clarity on this.  The top of the hierarchy is the Data = Concept,=20 which is an abstract description independent of its representation -- = a pure=20 semantic layer.

The = hierarchy, as=20 I understand it, would be something like this:

Data Concept
        Language Code: A standardized = code used to=20 identify a particular language or dialect.

Data Elements [Data Concept + = Representation Class]=20 related to "Language Code" data concept =3D
  1. ISO 639-1 Language = Code:  A=20 two-letter code assigned by the ISO 639-1 standard to identify a = particular=20 language.=20
  2. ISO 639-2/B Language = Code=20
  3. ISO 639-2/T Language = Code=20
  4. ISO 639-3 Language = Code=20
  5. ISO 639-6 Language=20 Code

Value = Domain=20
        Each = data element=20 in this case has a "Value Domain" and the Value Domain contains the = individual=20 values such as "en-US".

...=20

For the Language Code data = concept, the=20 ISO 11179 structure seems relevant and useful. But when we look at = some of the=20 other concepts, it seems less useful and perhaps problematic:=20

Data Concept =3D Script = Code=20
Data Element =3D ISO 15924 Script = Code=20

Data Concept =3D Country = Code=20
Data Element =3D ISO 3166 Country = Code=20

Note that "Description" or = even "Subtag=20 Description" is too vague by ISO 11179 rules (subjective judgment, but = there=20 are a lot of examples that support this view) and I think you would = need to=20 break these out as:
  1. En-US Language = Name=20
  2. Fr-FR Language = Name=20
  3. En-US Script = Name=20
  4. En-US Country=20 Name
etc.=20

These are unique data = elements relating=20 to several data concepts, so the current model with its "Description" = field=20 would need serious revision to be compliant, I think. =

I'm not opposed to further discussion of = this moving=20 forward. I only question how valuable this is for a standard that has = so few=20 data elements. It is a good thing that you're familiar with the = section of the=20 standard I've spent the least time reviewing.  :) =

Best regards,

Karen Broome
Sony Pictures = Entertainment



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

06/27/2006 01:22 AM =

To
"'LTRU Working Group'"=20 <ltru@ietf.org>=20
cc
'Doug Ewell'=20 <dewell@adelphia.net>=20
Subject
[Ltru] Preliminary = Investigation=20 into Application of ISO = 11179

=




Findings of a preliminary investigation into the = application of ISO=20 11179 to
the RFC3066bis Registry

Cost
Initial = investigations=20 suggest that ISO 11179 can be applied to the Registry
at a base = level for=20 very little cost.  The main cost is in mapping the ISO
11179=20 terminology to the existing Registry terminology and a number = of
additional=20 data elements would be required.  The Registry = already
incorporates a=20 system of metadata elements that are consistent with the
model = presented=20 within ISO 11179.  

In particular the value of the = following=20 aspects of ISO 11179-6 should be
investigated:=20

Identification
The attributes registration authority = identifier=20 (RAI), data identifier
(DI), and version identifier (VI) constitute = the=20 international registration
data identifier (IRDI). At least one = IRDI is=20 required for an administered
item.

Data identifiers are = assigned by=20 a Registration Authority; data identifiers
shall be unique within = the=20 domain of a Registration Authority.

Requirements for a = Registration=20 Authority, and a discussion of the IRDI,
appear in ISO/IEC=20 11179-6.

As each Registration Authority may determine its own = DI=20 assignment scheme,
there is no guarantee that the DI by itself will = uniquely identify an
administered item. For example, if two = authorities=20 both use sequential
6-digit numbers, there may be two administered = items=20 with the same DI's;
however, the administered items will almost = certainly=20 not be the same.

If one administered item appears in two = registers, it=20 will have two DI's.
Therefore, both the DI and the RAI are = necessary for=20 identification of an
administered item.

If particular = attributes of=20 an administered item change, then a new version
of the administered = item=20 shall be created and registered. The registrar
shall determine = these=20 attributes. In such a case, a VI is required to
complete the unique = identification of an administered item.

For further guidance, = see=20 ISO/IEC 11179-6.

An IRDI can serve as a key when exchanging = data among=20 information systems,
organizations, or other parties who wish to = share a=20 specific administered
item, but might not utilize the same names or = contexts.

ISO/IEC 11179 does not specify the format or content = of a=20 unique DI.

The IETF (or LTRU) would need to apply for an = International=20 Code Designator
(ICD) - a four integer code; this coupled with the=20 organization name as well
as a "department" identifier (OPI) = becomes the=20 IRDI e.g. 1234.IETF.LTRU.
The ICD would be registered by the RA of = ISO/IEC=20 6523 Organization Codes as
Registration Authority Identifier which = is=20 currently BSI.  

Implications for the LTRU Registry
The = DI (or=20 UI - Unique Identifier) cannot be the Subtag as there are=20 already
conflicting Subtags within the registry (e.g. cy/CY). =  It is=20 more preferable
that the unique identifier be the chosen=20 language/country/script name
(please note, this is not the = preferred name).=20  This would fit with the
current ISO 639-3, -5 and -6 models = and open=20 the Registry to adoption by
meta-data knowledge grids. (I will take = a good=20 look at the naming
conventions within ISO 3166-1 at a later date = but prior=20 to publication of
FDIS 3166-1).  

Anomalies within ISO = naming=20 conventions of standards issued prior to the
adoption of ISO 11179 = can be=20 dealt with on a case by case basis via set
rules.   =

The Subtag=20 would become a "Representation" with the name being the = unique
"Data=20 Identifier". This would involve having a "Primary Description" = which
would=20 form the DI.

In reviewing the "Required Metadata Attributes" = for a=20 "Preferred Standard"
Status administered item, preliminary = investigations=20 reveal no serious
additional requirements other than those already=20 mentioned here. Some
manipulation and interpretation of registry = data and=20 standard mandatory
requirements would be required but no = difficulties are=20 envisaged. I would
refer the WG to ISO/IEC 11179-6:2005(E); Table = B-8=20 (p.34)

Benefits
The ISO 11179 model allows for there being=20 conflicting codes between
different meta-data registries in = conformity with=20 ISO 11179; that is part of
the conceptual model.  ("in = conformity=20 with" is correct - there are
essential parts of the = standard).

In=20 essence, the ISO 11179 meta-model supports linkage to other ISO=20 11179
conformant meta-data registries thus facilitating data=20 exchange/interchange
whilst giving the LTRU Registry ownership of = the data=20 elements contained
therein - they become LTRU elements giving room = for=20 manoeuvre should ISO get
it wrong.

This will make language = tags more=20 meaningful in the future.  The key word
here is "linkage". =  ISO=20 11179 conformant meta-data registries facilitate the
creation of = knowledge=20 grids, grid computing and the semantic web!

Conclusion
At = first=20 glance the cost/value ratio favours ISO 11179; there appears to = be
very=20 little cost yet the true benefits of future interoperability and=20 data
exchange are unknown.  

It is recommended that = further=20 investigation be conducted before application
of ISO 11179 can be = discussed=20 at WG level.

Further benefits with regard to data interchange = should=20 be explored.

It is further recommended that the "investigation = into=20 application of ISO
11179 Meta Data Registries to the Registry and = its=20 registration procedures
be conducted by nominated members of the WG = with a=20 view to application" be
added to the new LTRU Charter. =  

Best=20 regards


Debbie=20 = Garside



_______________________________________________Ltru=20 mailing=20 = list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
<= BR>
------=_NextPart_000_036C_01C69A8E.FAD5FFC0-- --===============1501619607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1501619607==-- From ltru-bounces@ietf.org Wed Jun 28 05:54:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWkv-0002pq-Sa; Wed, 28 Jun 2006 05:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWku-0002pl-M7 for ltru@ietf.org; Wed, 28 Jun 2006 05:54:44 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvWkr-0003lL-1u for ltru@ietf.org; Wed, 28 Jun 2006 05:54:44 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k5S9sRNK019857; Wed, 28 Jun 2006 18:54:27 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 019d_16466402_068c_11db_9801_0014221f2a2d; Wed, 28 Jun 2006 18:54:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k5S9sFaH005921; Wed, 28 Jun 2006 18:54:25 +0900 Message-Id: <6.0.0.20.2.20060628171403.0976b300@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 28 Jun 2006 17:25:27 +0900 To: "Debbie Garside" , "'Debbie Garside'" , "'LTRU Working Group'" From: Martin Duerst Subject: Re: [Ltru] RE: Preliminary Investigation into Application of ISO 11179 In-Reply-To: <200606270927.k5R9RLCS013899@mta5.iomartmail.com> References: <200606270927.k5R9RLCS013899@mta5.iomartmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Doug Ewell' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat on] Many thanks to Debbie (and Karen) for looking into this. [as a technical contributor] At 18:27 06/06/27, Debbie Garside wrote: >CORRECTION >It should read: > >---- > >The IETF (or LTRU) would need to apply for an International Code Designator >(ICD) - a four integer code; this coupled with the organization name as well >as a "department" identifier (OPI) becomes the RAI e.g. 1234.IETF.LTRU. The >ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as >Registration Authority Identifier which is currently BSI. > >---- Regarding codes such as 1234.IETF.LTRU, I have to say that I don't personally see the point. I very much agree that having a global identification system is a good thing, but if we are going to use such a system, it should use URIs (or IRIs) in order to be compatible with Web technology. If ISO 11179 doesn't provide or allow this, then I don't think it's worth considering (at least not this aspect of the standard). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 12:33:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvcyb-0007iV-4A; Wed, 28 Jun 2006 12:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcyZ-0007i4-Jw for ltru@ietf.org; Wed, 28 Jun 2006 12:33:15 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcxC-0000xS-Cf for ltru@ietf.org; Wed, 28 Jun 2006 12:31:53 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060628163149.UNVH13077.mta13.adelphia.net@DGBP7M81>; Wed, 28 Jun 2006 12:31:49 -0400 Message-ID: <04ac01c69ad0$48c2f850$040aa8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <20060628100003.AC7BB2596F8@eikenes.alvestrand.no> Date: Wed, 28 Jun 2006 09:31:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: Pointers from registry to documentation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Richard Ishida wrote: > I have been given an action by the W3C Architecture Domain to request > that the language subtag registry at > http://www.iana.org/assignments/language-subtag-registry contain a > pointer to the document that explains what the field names mean. > > Would it be possible to include a comment at the top of the document > containing the URI of the spec? Early "planning" versions of the Registry were in a vertical-bar-delimited format, not record-jar, and did contain a header comment explaining the nature of the file and describing the fields. When we switched to record-jar in April 2005, there was no provision for a file-level comment, only the "Comments:" fields that applies to individual records. Around August, someone apparently proposed adding a file-level comment, but there was little support at the time for adding this. I can't find the exact thread at the moment. I think the general feeling was that the RFC should point to the Registry, not necessarily the other way around. The LTRU Working Group could choose to reopen this topic at the time it revises RFC 3066bis to incorporate ISO 639-3-based subtags. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 13:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvddj-00069i-Dp; Wed, 28 Jun 2006 13:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvddh-00069c-Tf for ltru@ietf.org; Wed, 28 Jun 2006 13:15:45 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvdde-0005Xg-F4 for ltru@ietf.org; Wed, 28 Jun 2006 13:15:45 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c165.corp.yahoo.com [10.72.72.165]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5SH74Ec056525; Wed, 28 Jun 2006 10:07:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=r0Y7bq6vTIO4pu8Wy02WiRSE9o4lvYBMyOj6ipNNa5jhzAsqzYW0u8w5tTfQvPH7 From: "Addison Phillips" To: "'Doug Ewell'" , , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Pointers from registry to documentation Date: Wed, 28 Jun 2006 10:07:04 -0700 Message-ID: <004c01c69ad5$47a14260$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <04ac01c69ad0$48c2f850$040aa8c0@DGBP7M81> Thread-Index: Acaa0KuhaBllnFqPTZWGDxMrqk8mcQAAfITQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Around August, someone apparently=20 > proposed adding a=20 > file-level comment, That would be me. Lack of comments in the file is not fatal. For example, the IANA = "numbers" page does point to the RFC. Presumably anyone reading the = registry will be doing so for a reason. But I agree that in-file = comments would be useful, especially as pointers to BCP 47. However, my sense is that file-level comments will not be added during = an RFC 3066ter effort, in an effort to do as little as possible to the = file format. It might be possible to ease the restriction on the = File-Date so that it can contain Comments fields. Most record-jar = processors are already capable of handling multiple field records = anyway... Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. =20 > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net]=20 > Sent: mercredi 28 juin 2006 09:31 > To: ietf-languages@iana.org; LTRU Working Group > Subject: [Ltru] Re: Pointers from registry to documentation >=20 > Richard Ishida wrote: >=20 > > I have been given an action by the W3C Architecture Domain=20 > to request=20 > > that the language subtag registry at=20 > > http://www.iana.org/assignments/language-subtag-registry contain a=20 > > pointer to the document that explains what the field names mean. > > > > Would it be possible to include a comment at the top of the=20 > document=20 > > containing the URI of the spec? >=20 > Early "planning" versions of the Registry were in a=20 > vertical-bar-delimited format, not record-jar, and did=20 > contain a header=20 > comment explaining the nature of the file and describing the fields.=20 > When we switched to record-jar in April 2005, there was no=20 > provision for=20 > a file-level comment, only the "Comments:" fields that applies to=20 > individual records. Around August, someone apparently=20 > proposed adding a=20 > file-level comment, but there was little support at the time=20 > for adding=20 > this. I can't find the exact thread at the moment. >=20 > I think the general feeling was that the RFC should point to the=20 > Registry, not necessarily the other way around. >=20 > The LTRU Working Group could choose to reopen this topic at=20 > the time it=20 > revises RFC 3066bis to incorporate ISO 639-3-based subtags. >=20 > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 15:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfS0-0006U8-PO; Wed, 28 Jun 2006 15:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfRz-0006U3-Qe for ltru@ietf.org; Wed, 28 Jun 2006 15:11:47 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfRy-0000ux-Bo for ltru@ietf.org; Wed, 28 Jun 2006 15:11:47 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5SJ2BI7006281; Wed, 28 Jun 2006 12:02:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=FzMt6nQQvFkVrLPl56uKwDZt7gn3rFmnsy0W5LqZ03AGR0xevDsdyKQIgMFLBIHc From: "Addison Phillips" To: "'Doug Ewell'" , , "'LTRU Working Group'" Date: Wed, 28 Jun 2006 12:02:11 -0700 Message-ID: <001201c69ae5$5ca98680$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <04ac01c69ad0$48c2f850$040aa8c0@DGBP7M81> Thread-Index: Acaa0I+d+zrdOyFgTbmunMVHp+L/HQAFJgXA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Ltru] RE: Pointers from registry to documentation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FWIW, the original proposal for file-level comments was made here: http://www1.ietf.org/mail-archive/web/ltru/current/msg03286.html The issue was tracked in the issue tracker here: https://rt.psg.com/index.html?q=1103 And the resolution was: --- After discussion, rough consensus was that this as a "nice to have" rather than an essential addition, and that it was more important to finish the WG last call and submit the draft for publication. Consequently, this item is marked "rejected". --- Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Doug Ewell > Sent: mercredi 28 juin 2006 09:31 > To: ietf-languages@iana.org; LTRU Working Group > Subject: Re: Pointers from registry to documentation > > Richard Ishida wrote: > > > I have been given an action by the W3C Architecture Domain > to request > > that the language subtag registry at > > http://www.iana.org/assignments/language-subtag-registry contain a > > pointer to the document that explains what the field names mean. > > > > Would it be possible to include a comment at the top of the > document > > containing the URI of the spec? > > Early "planning" versions of the Registry were in a > vertical-bar-delimited format, not record-jar, and did > contain a header > comment explaining the nature of the file and describing the fields. > When we switched to record-jar in April 2005, there was no > provision for > a file-level comment, only the "Comments:" fields that applies to > individual records. Around August, someone apparently > proposed adding a > file-level comment, but there was little support at the time > for adding > this. I can't find the exact thread at the moment. > > I think the general feeling was that the RFC should point to the > Registry, not necessarily the other way around. > > The LTRU Working Group could choose to reopen this topic at > the time it > revises RFC 3066bis to incorporate ISO 639-3-based subtags. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 15:55:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg7v-00018y-I9; Wed, 28 Jun 2006 15:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg7r-00016L-Ph for ltru@ietf.org; Wed, 28 Jun 2006 15:55:03 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvg7q-0005HH-DY for ltru@ietf.org; Wed, 28 Jun 2006 15:55:03 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060628195501.FZCL13077.mta13.adelphia.net@DGBP7M81>; Wed, 28 Jun 2006 15:55:01 -0400 Message-ID: <04e801c69aec$bbf96180$040aa8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <001201c69ae5$5ca98680$9fcd15ac@ds.corp.yahoo.com> Date: Wed, 28 Jun 2006 12:54:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: Pointers from registry to documentation X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > FWIW, the original proposal for file-level comments was made here: > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03286.html > > The issue was tracked in the issue tracker here: > > https://rt.psg.com/index.html?q=1103 > > And the resolution was: > > --- > After discussion, rough consensus was that this as a "nice to have" > rather than an essential addition, and that it was more important > to finish the WG last call and submit the draft for publication. > Consequently, this item is marked "rejected". > --- Thanks for exhuming that. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 19:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvju0-00049m-H1; Wed, 28 Jun 2006 19:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvjtz-00041G-6h for ltru@ietf.org; Wed, 28 Jun 2006 19:56:59 -0400 Received: from mta3.iomartmail.com ([62.128.193.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjtv-00023x-Nz for ltru@ietf.org; Wed, 28 Jun 2006 19:56:59 -0400 Received: from mta3.iomartmail.com (localhost [127.0.0.1]) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5SN6o8l019689; Thu, 29 Jun 2006 00:06:50 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5SN6iIo019633; Thu, 29 Jun 2006 00:06:49 +0100 Message-Id: <200606282306.k5SN6iIo019633@mta3.iomartmail.com> From: "Debbie Garside" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] RE: Preliminary Investigation into Application of ISO 11179 Date: Thu, 29 Jun 2006 00:06:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6.0.0.20.2.20060628171403.0976b300@localhost> thread-index: AcaamN9gu0MdvRDgShK/R7G9nhVdEgAbUYiw X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Doug Ewell' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin wrote: > Regarding codes such as 1234.IETF.LTRU, I have to say that I > don't personally see the point. I very much agree that having > a global identification system is a good thing, but if we are > going to use such a system, it should use URIs (or IRIs) in > order to be compatible with Web technology. If ISO 11179 > doesn't provide or allow this, then I don't think it's worth > considering (at least not this aspect of the standard). The format of these data elements is as follows: - ICD: integer, variable length, up to 4 digits; - Identification of an organization: variable length, up to 35 characters; - OPI: variable length, up to 35 characters; - OPIS: 1 character. No particular sequence of the four components is specified (at least not in ISO 11179). Additionally, there are no constraints on elements that can be added! Best regards Debbie > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 28 June 2006 09:25 > To: Debbie Garside; 'Debbie Garside'; 'LTRU Working Group' > Cc: 'Doug Ewell' > Subject: Re: [Ltru] RE: Preliminary Investigation into > Application of ISO 11179 > > [co-chair hat on] > Many thanks to Debbie (and Karen) for looking into this. > > > [as a technical contributor] > > At 18:27 06/06/27, Debbie Garside wrote: > >CORRECTION > > >It should read: > > > >---- > > > >The IETF (or LTRU) would need to apply for an International Code > >Designator > >(ICD) - a four integer code; this coupled with the > organization name as > >well as a "department" identifier (OPI) becomes the RAI e.g. > >1234.IETF.LTRU. The ICD would be registered by the RA of > ISO/IEC 6523 Organization Codes as > >Registration Authority Identifier which is currently BSI. > > > >---- > > Regarding codes such as 1234.IETF.LTRU, I have to say that I > don't personally see the point. I very much agree that having > a global identification system is a good thing, but if we are > going to use such a system, it should use URIs (or IRIs) in > order to be compatible with Web technology. If ISO 11179 > doesn't provide or allow this, then I don't think it's worth > considering (at least not this aspect of the standard). > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jun 28 21:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlI5-0007Ue-9q; Wed, 28 Jun 2006 21:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlI4-0007UZ-3z for ltru@ietf.org; Wed, 28 Jun 2006 21:25:56 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlI2-0002lx-Te for ltru@ietf.org; Wed, 28 Jun 2006 21:25:56 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FvlI1-0000Xt-L9; Wed, 28 Jun 2006 21:25:53 -0400 Date: Wed, 28 Jun 2006 21:25:53 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Pointers from registry to documentation Message-ID: <20060629012553.GD21235@ccil.org> References: <04ac01c69ad0$48c2f850$040aa8c0@DGBP7M81> <004c01c69ad5$47a14260$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01c69ad5$47a14260$650a0a0a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > However, my sense is that file-level comments will not be added during > an RFC 3066ter effort, in an effort to do as little as possible to > the file format. It might be possible to ease the restriction on the > File-Date so that it can contain Comments fields. Most record-jar > processors are already capable of handling multiple field records > anyway... My objection to file-level comments is that it's not clear what record they are in, and since we maintain the file record by record, they would need a unique mechanism for change control. This objection wouldn't apply to Comment: entries in the File-Date record, though, and I'd be in favor of that. -- They tried to pierce your heart John Cowan with a Morgul-knife that remains in the http://www.ccil.org/~cowan wound. If they had succeeded, you would become a wraith under the domination of the Dark Lord. --Gandalf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jun 29 22:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8YE-0006kS-Gw; Thu, 29 Jun 2006 22:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8YD-0006kK-0A for ltru@ietf.org; Thu, 29 Jun 2006 22:16:09 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8YB-0000kQ-Pa for ltru@ietf.org; Thu, 29 Jun 2006 22:16:08 -0400 Received: from h-68-165-4-31.snvacaid.dynamic.covad.net ([68.165.4.31] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fw8YB-0002An-00 for ltru@ietf.org; Thu, 29 Jun 2006 22:16:07 -0400 Message-ID: <002d01c69beb$3a62a140$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <052b01c69b41$1cada780$040aa8c0@DGBP7M81> Date: Thu, 29 Jun 2006 19:16:41 -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-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: NEW-MODIFY LANGUAGE SUBTAG MODIFICATION for "Ethi" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: > Sent: Wednesday, June 28, 2006 10:58 PM > Subject: Re: NEW-MODIFY LANGUAGE SUBTAG MODIFICATION for "Ethi" ... > The question is this: Which Description field(s) from the set {A, B, C} > should be used in the Registry entry for this script, and (optionally) > in what order? Bear in mind that the order of Description fields makes > no difference in principle, but in practice some users may view the item > listed first as "preferred" in some way. ... Is this an area where a future update to the registry document might benefit from the addition of clarifying text? Is there are need to add a mechanism (such as ordering) in order to indicate "preference"? As a technical contributor, I think that if users of the registry are making unwarranted "preference" assumptions, we should make it clearer that order doesn't imply preference. Given the purpose of the description field, I think there is no need to add a mechanism to indicate "preference". Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 30 11:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKgz-00069x-2G; Fri, 30 Jun 2006 11:14:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKgy-00069s-45 for ltru@ietf.org; Fri, 30 Jun 2006 11:14:00 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKgw-00053O-Pf for ltru@ietf.org; Fri, 30 Jun 2006 11:14:00 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c249.corp.yahoo.com [10.72.76.249]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k5UFDV1g020527; Fri, 30 Jun 2006 08:13:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=wvXw/rg5VqrjomLQLsw8P3qtctACAnSCMY3X/8HgKNvfWtbhu772yuC7IVwBQgPR From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: NEW-MODIFY LANGUAGE SUBTAG MODIFICATION for "Ethi" Date: Fri, 30 Jun 2006 08:13:30 -0700 Message-ID: <001a01c69c57$bf237e60$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002d01c69beb$3a62a140$6501a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acab6zcPz6UrWQQqS9+n7tElKzXcEgAbG5rw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > As a technical contributor, I think that if users of the registry > are making unwarranted "preference" assumptions, we should make it > clearer that order doesn't imply preference. Given the purpose of > the description field, I think there is no need to add a mechanism > to indicate "preference". +1 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: jeudi 29 juin 2006 19:17 > To: LTRU Working Group > Subject: [Ltru] Re: NEW-MODIFY LANGUAGE SUBTAG MODIFICATION for "Ethi" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 30 12:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMFx-0006Bv-IS; Fri, 30 Jun 2006 12:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMFw-00067h-Mt; Fri, 30 Jun 2006 12:54:12 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwMFu-00059d-AW; Fri, 30 Jun 2006 12:54:12 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c249.corp.yahoo.com [10.72.76.249]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k5UGrlvn023023; Fri, 30 Jun 2006 09:53:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=0kMQhu0XJvoUZ25e+ngmzZ5Yy//mjDwyPlnNeQZQhBY+/kCAdRW+hzCSTDTbVhA6 From: "Addison Phillips" To: "'LTRU Working Group'" Date: Fri, 30 Jun 2006 09:53:47 -0700 Message-ID: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcacZcB8N41F3X0oR0uPHAYxQzq56Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: gen-art@ietf.org Subject: [Ltru] gen-art review and response... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, Following this note is a copy of the Gen-Art review of draft-matching. I = have placed my responses to it into the note with appropriate markup. Ted: your guidance please? Addison =3D=3D=3D=3D=3D=3D=3D=3D I am the assigned Gen-ART reviewer for draft-ietf-ltru-matching-15.txt. For background on Gen-ART, please see = the FAQ at . This set of comments should have reached you during IETF Last Call but = due to holidays I didn't receive the commission till after the last call = ended.Since I see that the authors have already updated the document = since the end of last call, please consult your AD as regards what = action to take on these comments. Summary =3D=3D=3D=3D=3D=3D=3D This document is almost ready for BCP. I have one issue with it (noted = below) which IMO needs to be considered. There are also two 'bugs' in = the specification of character codes and a number of suggested editorial = changes which could be passed to the RFC Editor Bugs: Assuming we are supposed to be using RFC4234 conventions: s2, para 3: s/%2A/%x2A/ s3.3.2, para 2 (Item 1.): s/%2D/%x2D/ [Addison] Good catch. Comment/Issue: I find the whole use of wildcards in extended language ranges = counter-intuitive. The idea that de-de and de-*-de provide the same = matches but the * in *-de is meaningful makes my brain hurt, however I = see some of the reasoning which has lead to this unpleasant result. Be that as it may, if I understand the intention of this document = correctly, the syntactical specification of extended language ranges in = s2.2 is intended to allow for a number of matching algorithms, not = necessarily defined in the draft. It therefore seems inappropriate to = partially specify the semantics in s2.2 as they are used in the extended = filtering algorithm defined in s3.3.2 when some other matching algorithm = might apply different semantics. Any semantics that are specified in = s2.2 should be those that are intended to apply for any matching = algorithm - there may not be any! [Addison] That is the intention: other algorithms that use extended = language ranges must interpret wildcards in the same way. Other range = syntaxes are possible: the WG considered other such for "extended = language ranges". My initial response to s2.2 before reading s3.3.2 was as follows: s2.2: Sequences of wildcards and empty subtag sequences: This section = probably needs to be more explicit in a number of ways: a) Does 'any sequence of subtags' include 'an empty sequence of = subtags'? [Addison] Yes. Intentionally. b) The ABNF allows forms such as aa-*-*-zz: Is this intended? If so is = it equivalent to aa-*-zz or not? [Addison] Yes. And Yes. c) As a particular case of (b) is *-*-zz equivalent to *-zz or is the = wildcard on the primary language tag special? [Addison] They are equivalent. The primary "*" is special in that it = cannot be removed, but it still matches a *sequence* of subtags. d) Is it necessary to add a trailing wildcard to soak up subtags after = the last match (this might become obvious in the matching algorithms but = a comment here might help)? [Addison] No. The trailing wildcard is implied. To summarize, I suggest: - Removing the last paragraph of s2.2 and replacing it with a summary of = any general semantics expected to apply to an Extended Language Range = (e.g., any sequence of wildcards is equivalent to one wildcard, final = wildcards can be omitted, a wildcard matches any sequence (might be = empty or non-empty) of subtags) - Reordering s3.3.2 to describe the intention and give the examples = before specifying the algorithm - this would considerably aid = understanding IMO. Maybe clarify that -*-* is equivalent to -* etc. [Addison] The problem here is that extended langauge ranges (and = language ranges in general) do not have a way to specify negation. The = WG went round-and-about that topic for awhile. While such a syntax is = possible, it wasn't necessary to the matching schemes described in the = draft. Editorial: s1, para 4: Presentation might be clearer as a bulleted list. [Addison] Possibly, but not necessary. s1, para 5: s/-14/(actual version number)/ [Addison] That is the actual version number of draft-registry aka RFC = 3066bis. s2, para 1: Make it clearer that '(section 14.4)' applies to RFC2616 = and not the current document. [Addison] Okay. s2, para 3: A cross-reference to Section 2.1 of [RFC3066bis] where the = syntax of language tags is defined would be helpful. s2, para 3: For = consistency, "hyphen" should be given as a hex value also as in = [RFC3066bis] - hyphen ("-", ABNF [RFC4234] %x2D). [Addison] Okay. s2.1, para 1: The phrase 'has the same syntax as an [RFC3066] language = tag' is undesirable since this specification obsoletes RFC3066. = Something like 'has either a syntax which reflects the overall structure = of [RFC3066bis] language tags or ...' would be better. [Addison] ... but would be wrong. RFC 3066's syntax was different and = more general. The language ranges presented here have the same syntax as = RFC 3066 tags, i.e.: Tag =3D 1*8alphanum *["-" 1*8alphanum] s2.1, para 3: s/Such ill-formed ranges/Any ranges that are not = well-formed/ [Addison] I don't care for this edit. s2.3, para 1: Transliteration/Internationalization issue: Many of the = S=C3=A1mi using peoples transliterate S=C3=A1mi as Saami rather than = Sami. [Addison] Noted. This is a side effect of not having I-Ds use UTF-8 as = their encoding. Perhaps someday I-Ds will join the modern world in this = respect :-).=20 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 30 12:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwML9-0001Ty-PV; Fri, 30 Jun 2006 12:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwML8-0001Mu-J3 for ltru@ietf.org; Fri, 30 Jun 2006 12:59:34 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwML7-0005k3-DQ for ltru@ietf.org; Fri, 30 Jun 2006 12:59:34 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c249.corp.yahoo.com [10.72.76.249]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k5UGxNSf023575; Fri, 30 Jun 2006 09:59:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=OwmTo2Z0qnVjjUjLRiQo4j8NVVsuFgaDvWncpJUM+A9lwg5ihrN712/msbBVv2lE From: "Addison Phillips" To: Date: Fri, 30 Jun 2006 09:59:22 -0700 Message-ID: <000101c69c66$899ca6e0$650a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcacZokGJtott1yWRGGi518i+N/AmA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'LTRU Working Group' Subject: [Ltru] Gen-art review of draft-matching (Brian's comments) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Brian Carpenter asked Mark and I privately: -- I'd really like to have the authors' and shepherds' comments on section 2.2 before casting my ballot on this. Did the WG consciously decide that en-*-*-*-en was valid, and distinct from en-*-*-en?=20 -- en-*-*-*-en is not functionally distinct from "en-*-*-en" (or en-*-en, = en-en, or en-en-*, for that matter). It is possible to construct a language range syntax that uses RFC = 3066bis's syntax. In such a syntax the position and number of wildcards = would be significant. However, the WG discovered that none of the = algorithms we ended up with in this document needed such a syntax. = Therefore we didn't document one. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 30 14:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNo1-0007QQ-GP; Fri, 30 Jun 2006 14:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNo0-0007QL-CE for ltru@ietf.org; Fri, 30 Jun 2006 14:33:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwNnx-0004ET-TN for ltru@ietf.org; Fri, 30 Jun 2006 14:33:28 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5UIXOxx004424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jun 2006 11:33:24 -0700 Received: from [10.0.1.5] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k5UIXLDv010131; Fri, 30 Jun 2006 11:33:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com> References: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com> Date: Fri, 30 Jun 2006 11:33:19 -0700 To: "Addison Phillips" , "'LTRU Working Group'" From: Ted Hardie Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id k5UIXOxx004424 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Subject: [Ltru] Re: gen-art review and response... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 9:53 AM -0700 6/30/06, Addison Phillips wrote: >All, > >Following this note is a copy of the Gen-Art review of draft-matching. I= have placed my responses to it into the note with appropriate markup. > >Ted: your guidance please? > >Addison As you did with the private reply from Brian, send a copy of this directl= y to him (brc@zurich.ibm.com). While he is on the gen-art list, a direct note is best. I believe these two issues: >s2, para 3: s/%2A/%x2A/ >s3.3.2, para 2 (Item 1.): s/%2D/%x2D/ should be fixed with an RFC Editor note. Please let me know if you or th= e chairs disagree. I believe the other issues are adequately explained by your ex= change with Elwyn (and later with Brian) and so do not require text updates. regards, Ted Hardie >=3D=3D=3D=3D=3D=3D=3D=3D > >I am the assigned Gen-ART reviewer for >draft-ietf-ltru-matching-15.txt. For background on Gen-ART, please see t= he FAQ at >. > >This set of comments should have reached you during IETF Last Call but d= ue to holidays I didn't receive the commission till after the last call e= nded.Since I see that the authors have already updated the document since= the end of last call, please consult your AD as regards what action to t= ake on these comments. > >Summary >=3D=3D=3D=3D=3D=3D=3D >This document is almost ready for BCP. I have one issue with it (noted = below) which IMO needs to be considered. There are also two 'bugs' in the= specification of character codes and a number of suggested editorial cha= nges which could be passed to the RFC Editor > >Bugs: >Assuming we are supposed to be using RFC4234 conventions: >s2, para 3: s/%2A/%x2A/ >s3.3.2, para 2 (Item 1.): s/%2D/%x2D/ > >[Addison] Good catch. > >Comment/Issue: >I find the whole use of wildcards in extended language ranges counter-in= tuitive. The idea that de-de and de-*-de provide the same matches but th= e * in *-de is meaningful makes my brain hurt, however I see some of the = reasoning which has lead to this unpleasant result. > >Be that as it may, if I understand the intention of this document correc= tly, the syntactical specification of extended language ranges in s2.2 is= intended to allow for a number of matching algorithms, not necessarily d= efined in the draft. It therefore seems inappropriate to partially speci= fy the semantics in s2.2 as they are used in the extended filtering algor= ithm defined in s3.3.2 when some other matching algorithm might apply dif= ferent semantics. Any semantics that are specified in s2.2 should be thos= e that are intended to apply for any matching algorithm - there may not b= e any! > >[Addison] That is the intention: other algorithms that use extended lang= uage ranges must interpret wildcards in the same way. Other range syntaxe= s are possible: the WG considered other such for "extended language range= s". > >My initial response to s2.2 before reading s3.3.2 was as follows: >s2.2: Sequences of wildcards and empty subtag sequences: This section p= robably needs to be more explicit in a number of ways: >a) Does 'any sequence of subtags' include 'an empty sequence of subtags'= ? > >[Addison] Yes. Intentionally. > >b) The ABNF allows forms such as aa-*-*-zz: Is this intended? If so is= it equivalent to aa-*-zz or not? > >[Addison] Yes. And Yes. > >c) As a particular case of (b) is *-*-zz equivalent to *-zz or is the wi= ldcard on the primary language tag special? > >[Addison] They are equivalent. The primary "*" is special in that it can= not be removed, but it still matches a *sequence* of subtags. > >d) Is it necessary to add a trailing wildcard to soak up subtags after t= he last match (this might become obvious in the matching algorithms but a= comment here might help)? > >[Addison] No. The trailing wildcard is implied. > >To summarize, I suggest: >- Removing the last paragraph of s2.2 and replacing it with a summary of= any general semantics expected to apply to an Extended Language Range (e= .g., any sequence of wildcards is equivalent to one wildcard, final wildc= ards can be omitted, a wildcard matches any sequence (might be empty or n= on-empty) of subtags) >- Reordering s3.3.2 to describe the intention and give the examples befo= re specifying the algorithm - this would considerably aid understanding I= MO. Maybe clarify that -*-* is equivalent to -* etc. > >[Addison] The problem here is that extended langauge ranges (and languag= e ranges in general) do not have a way to specify negation. The WG went r= ound-and-about that topic for awhile. While such a syntax is possible, it= wasn't necessary to the matching schemes described in the draft. > >Editorial: >s1, para 4: Presentation might be clearer as a bulleted list. > >[Addison] Possibly, but not necessary. > >s1, para 5: s/-14/(actual version number)/ > >[Addison] That is the actual version number of draft-registry aka RFC 30= 66bis. > >s2, para 1: Make it clearer that '(section 14.4)' applies to RFC2616 a= nd not the current document. > >[Addison] Okay. > >s2, para 3: A cross-reference to Section 2.1 of [RFC3066bis] where the s= yntax of language tags is defined would be helpful. s2, para 3: For consi= stency, "hyphen" should be given as a hex value also as in [RFC3066bis] -= hyphen ("-", ABNF [RFC4234] %x2D). > >[Addison] Okay. > >s2.1, para 1: The phrase 'has the same syntax as an [RFC3066] language t= ag' is undesirable since this specification obsoletes RFC3066. Something= like 'has either a syntax which reflects the overall structure of [RFC30= 66bis] language tags or ...' would be better. > >[Addison] ... but would be wrong. RFC 3066's syntax was different and mo= re general. The language ranges presented here have the same syntax as RF= C 3066 tags, i.e.: > > Tag =3D 1*8alphanum *["-" 1*8alphanum] > >s2.1, para 3: s/Such ill-formed ranges/Any ranges that are not well-form= ed/ > >[Addison] I don't care for this edit. > >s2.3, para 1: Transliteration/Internationalization issue: Many of the S=E1= mi using peoples transliterate S=E1mi as Saami rather than Sami. > >[Addison] Noted. This is a side effect of not having I-Ds use UTF-8 as t= heir encoding. Perhaps someday I-Ds will join the modern world in this re= spect :-). > > > > > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jun 30 15:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOtU-0007BX-Pw; Fri, 30 Jun 2006 15:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOtT-0007BN-Oo for ltru@ietf.org; Fri, 30 Jun 2006 15:43:11 -0400 Received: from mta1.iomartmail.com ([62.128.193.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOtS-0001d3-De for ltru@ietf.org; Fri, 30 Jun 2006 15:43:11 -0400 Received: from mta1.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5UJgsPE030221; Fri, 30 Jun 2006 20:42:55 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta1.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5UJgltq030123; Fri, 30 Jun 2006 20:42:53 +0100 Message-Id: <200606301942.k5UJgltq030123@mta1.iomartmail.com> From: "Debbie Garside" To: "'Debbie Garside'" , Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Date: Fri, 30 Jun 2006 20:42:47 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaaRtGC6+ZxHRxlRvygUz+eA4jaagAPctTwAH2atfA= In-Reply-To: <200606280743.k5S7hncc019253@mta6.iomartmail.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 6f7d7d4126a03a70c87b926ff3be4cd9 Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953434765==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0953434765== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C69C85.BF9F4F30" This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C69C85.BF9F4F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Karen I have looked at this in a little more detail now and you are correct if we were to consider "Strictly Conforming" to ISO 11179. However, having completed a preliminary test map from the Registry (and associated documentation within the RFC) to Clause 5 of part 3 (Basic Attributes) as well as the requirements of part 6 (as outlined in my previous mail), I think Conformance Level 1 (part 3 clause 6) could be achieved without too much effort. That said, I would really want to study this in more detail, my investigations are still very much preliminary - I would like to do a true implementation to be absolutely sure. If the WG decide to put investigation of implications and benefits of conformity with ISO 11179 for the Registry within the new Charter I would be happy to work with you on this if you have time. Best regards Debbie Garside _____ From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 28 June 2006 08:44 To: Karen_Broome@spe.sony.com Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Hi Karen Thanks for your input. I need to do a little more reading before I respond so it may be a few days :-) I think there are two ways of looking at 11179: 1. As a standard to assist in the design of a Meta-data Registry 2. As a standard to apply to an existing Meta-Data registry. I have been looking at what is as a bare minimum absolutely necessary in order to apply ISO 11179 to the LTRU Registry. I have read the whole standard but I need to do further depth reading to see what is required for the Registry to be conformant. There are one or two things that you have mentioned that do not fit with my interpretation but I would not want to say more until I have studied it further. best regards Debbie _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 28 June 2006 01:06 To: Debbie Garside Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179 Debbie, Did you review all of ISO 11179 or just 11179-6? There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this. The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer. The hierarchy, as I understand it, would be something like this: Data Concept Language Code: A standardized code used to identify a particular language or dialect. Data Elements [Data Concept + Representation Class] related to "Language Code" data concept = 1. ISO 639-1 Language Code: A two-letter code assigned by the ISO 639-1 standard to identify a particular language. 2. ISO 639-2/B Language Code 3. ISO 639-2/T Language Code 4. ISO 639-3 Language Code 5. ISO 639-6 Language Code Value Domain Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US". ... For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic: Data Concept = Script Code Data Element = ISO 15924 Script Code Data Concept = Country Code Data Element = ISO 3166 Country Code Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as: 1. En-US Language Name 2. Fr-FR Language Name 3. En-US Script Name 4. En-US Country Name etc. These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think. I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing. :) Best regards, Karen Broome Sony Pictures Entertainment "Debbie Garside" 06/27/2006 01:22 AM To "'LTRU Working Group'" cc 'Doug Ewell' Subject [Ltru] Preliminary Investigation into Application of ISO 11179 Findings of a preliminary investigation into the application of ISO 11179 to the RFC3066bis Registry Cost Initial investigations suggest that ISO 11179 can be applied to the Registry at a base level for very little cost. The main cost is in mapping the ISO 11179 terminology to the existing Registry terminology and a number of additional data elements would be required. The Registry already incorporates a system of metadata elements that are consistent with the model presented within ISO 11179. In particular the value of the following aspects of ISO 11179-6 should be investigated: Identification The attributes registration authority identifier (RAI), data identifier (DI), and version identifier (VI) constitute the international registration data identifier (IRDI). At least one IRDI is required for an administered item. Data identifiers are assigned by a Registration Authority; data identifiers shall be unique within the domain of a Registration Authority. Requirements for a Registration Authority, and a discussion of the IRDI, appear in ISO/IEC 11179-6. As each Registration Authority may determine its own DI assignment scheme, there is no guarantee that the DI by itself will uniquely identify an administered item. For example, if two authorities both use sequential 6-digit numbers, there may be two administered items with the same DI's; however, the administered items will almost certainly not be the same. If one administered item appears in two registers, it will have two DI's. Therefore, both the DI and the RAI are necessary for identification of an administered item. If particular attributes of an administered item change, then a new version of the administered item shall be created and registered. The registrar shall determine these attributes. In such a case, a VI is required to complete the unique identification of an administered item. For further guidance, see ISO/IEC 11179-6. An IRDI can serve as a key when exchanging data among information systems, organizations, or other parties who wish to share a specific administered item, but might not utilize the same names or contexts. ISO/IEC 11179 does not specify the format or content of a unique DI. The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. Implications for the LTRU Registry The DI (or UI - Unique Identifier) cannot be the Subtag as there are already conflicting Subtags within the registry (e.g. cy/CY). It is more preferable that the unique identifier be the chosen language/country/script name (please note, this is not the preferred name). This would fit with the current ISO 639-3, -5 and -6 models and open the Registry to adoption by meta-data knowledge grids. (I will take a good look at the naming conventions within ISO 3166-1 at a later date but prior to publication of FDIS 3166-1). Anomalies within ISO naming conventions of standards issued prior to the adoption of ISO 11179 can be dealt with on a case by case basis via set rules. The Subtag would become a "Representation" with the name being the unique "Data Identifier". This would involve having a "Primary Description" which would form the DI. In reviewing the "Required Metadata Attributes" for a "Preferred Standard" Status administered item, preliminary investigations reveal no serious additional requirements other than those already mentioned here. Some manipulation and interpretation of registry data and standard mandatory requirements would be required but no difficulties are envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) Benefits The ISO 11179 model allows for there being conflicting codes between different meta-data registries in conformity with ISO 11179; that is part of the conceptual model. ("in conformity with" is correct - there are essential parts of the standard). In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 conformant meta-data registries thus facilitating data exchange/interchange whilst giving the LTRU Registry ownership of the data elements contained therein - they become LTRU elements giving room for manoeuvre should ISO get it wrong. This will make language tags more meaningful in the future. The key word here is "linkage". ISO 11179 conformant meta-data registries facilitate the creation of knowledge grids, grid computing and the semantic web! Conclusion At first glance the cost/value ratio favours ISO 11179; there appears to be very little cost yet the true benefits of future interoperability and data exchange are unknown. It is recommended that further investigation be conducted before application of ISO 11179 can be discussed at WG level. Further benefits with regard to data interchange should be explored. It is further recommended that the "investigation into application of ISO 11179 Meta Data Registries to the Registry and its registration procedures be conducted by nominated members of the WG with a view to application" be added to the new LTRU Charter. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_00E5_01C69C85.BF9F4F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Karen
 
I have looked at this in a little more detail = now and you=20 are correct if we were to consider "Strictly Conforming" to ISO=20 11179.
 
However, having completed a preliminary test = map from the=20 Registry (and associated documentation within the RFC) to Clause 5 = of part=20 3 (Basic Attributes) as well as the requirements of part 6 (as outlined = in my=20 previous mail), I think Conformance Level 1 (part 3 clause 6) could = be=20 achieved without too much effort. 
 
That said, I would really want to study this in = more=20 detail, my investigations are still very much preliminary -  I = would like=20 to do a true implementation to be absolutely sure.
 
If the WG decide to put investigation of = implications and=20 benefits of conformity with ISO 11179 for the Registry within the new = Charter I=20 would be happy to work with you on this if you have = time.
 
Best regards
 
Debbie Garside

From: Debbie Garside=20 [mailto:debbie@ictmarketing.co.uk]
Sent: 28 June 2006=20 08:44
To: Karen_Broome@spe.sony.com
Cc: 'Doug = Ewell';=20 'LTRU Working Group'
Subject: RE: [Ltru] Preliminary = Investigation=20 into Application of ISO 11179

Hi Karen
 
Thanks for your input.  I need to do a = little more=20 reading before I respond so it may be a few days = :-)
 
I think there are two ways of looking at = 11179: 1. As a=20 standard to assist in the design of a Meta-data Registry 2. As a = standard to=20 apply to an existing Meta-Data registry.
 
I have been looking at what is as a bare = minimum=20 absolutely necessary in order to apply ISO 11179 to the LTRU = Registry.  I=20 have read the whole standard but I need to do further depth = reading to=20 see what is required for the Registry to be = conformant.
 
There are one or two things that you have = mentioned that=20 do not fit with my interpretation but I would not want to say more = until I=20 have studied it further.
 
best regards
 
Debbie
 

From: Karen_Broome@spe.sony.com=20 [mailto:Karen_Broome@spe.sony.com]
Sent: 28 June 2006=20 01:06
To: Debbie Garside
Cc: 'Doug Ewell'; 'LTRU = Working=20 Group'
Subject: Re: [Ltru] Preliminary Investigation into=20 Application of ISO 11179


Debbie, =

Did you review all of ISO 11179 or just = 11179-6?=20

There is a lot more = to ISO 11179=20 than just the administrative practices (-6) and the previous parts = discuss a=20 hierarchical metadata model not mentioned in your review below. I = think=20 you're confusing the terms "value" and "representation" and the = other=20 sections provide clarity on this.  The top of the hierarchy is = the Data=20 Concept, which is an abstract description independent of its = representation=20 -- a pure semantic layer.

The=20 hierarchy, as I understand it, would be something like this:=20

Data Concept =
        Language = Code: A=20 standardized code used to identify a particular language or = dialect.=20

Data Elements [Data Concept = +=20 Representation Class] related to "Language Code" data concept = =3D
  1. ISO 639-1 Language = Code:  A=20 two-letter code assigned by the ISO 639-1 standard to identify a=20 particular language.=20
  2. ISO 639-2/B = Language Code=20
  3. ISO 639-2/T = Language Code=20
  4. ISO 639-3 Language = Code=20
  5. ISO 639-6 Language=20 Code

Value = Domain=20
        = Each data=20 element in this case has a "Value Domain" and the Value Domain = contains the=20 individual values such as "en-US".

...

For the = Language Code=20 data concept, the ISO 11179 structure seems relevant and useful. But = when we=20 look at some of the other concepts, it seems less useful and perhaps = problematic:

Data = Concept =3D=20 Script Code
Data Element = =3D ISO 15924=20 Script Code

Data = Concept =3D=20 Country Code
Data = Element =3D ISO 3166=20 Country Code

Note = that=20 "Description" or even "Subtag Description" is too vague by ISO 11179 = rules=20 (subjective judgment, but there are a lot of examples that support = this=20 view) and I think you would need to break these out as:
  1. En-US Language = Name=20
  2. Fr-FR Language = Name=20
  3. En-US Script = Name=20
  4. En-US Country=20 Name
etc.=20

These are unique data = elements relating=20 to several data concepts, so the current model with its = "Description" field=20 would need serious revision to be compliant, I think. =

I'm not opposed to further discussion of = this moving=20 forward. I only question how valuable this is for a standard that = has so few=20 data elements. It is a good thing that you're familiar with the = section of=20 the standard I've spent the least time reviewing.  :)=20

Best regards, =

Karen Broome
Sony Pictures=20 Entertainment



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

06/27/2006 01:22 AM =

To
"'LTRU Working = Group'"=20 <ltru@ietf.org>=20
cc
'Doug Ewell'=20 <dewell@adelphia.net>=20
Subject
[Ltru] Preliminary=20 Investigation into Application of ISO=20 11179

=




<= FONT=20 size=3D2>Findings of a preliminary investigation into the = application of=20 ISO 11179 to
the RFC3066bis Registry

Cost
Initial=20 investigations suggest that ISO 11179 can be applied to the = Registry
at a=20 base level for very little cost.  The main cost is in mapping = the=20 ISO
11179 terminology to the existing Registry terminology and a = number=20 of
additional data elements would be required.  The Registry = already
incorporates a system of metadata elements that are = consistent=20 with the
model presented within ISO 11179.  

In = particular=20 the value of the following aspects of ISO 11179-6 should = be
investigated:=20

Identification
The attributes registration authority = identifier=20 (RAI), data identifier
(DI), and version identifier (VI) = constitute the=20 international registration
data identifier (IRDI). At least one = IRDI is=20 required for an administered
item.

Data identifiers are = assigned=20 by a Registration Authority; data identifiers
shall be unique = within the=20 domain of a Registration Authority.

Requirements for a = Registration=20 Authority, and a discussion of the IRDI,
appear in ISO/IEC=20 11179-6.

As each Registration Authority may determine its own = DI=20 assignment scheme,
there is no guarantee that the DI by itself = will=20 uniquely identify an
administered item. For example, if two = authorities=20 both use sequential
6-digit numbers, there may be two = administered items=20 with the same DI's;
however, the administered items will almost = certainly=20 not be the same.

If one administered item appears in two = registers,=20 it will have two DI's.
Therefore, both the DI and the RAI are = necessary=20 for identification of an
administered item.

If particular = attributes of an administered item change, then a new version
of = the=20 administered item shall be created and registered. The = registrar
shall=20 determine these attributes. In such a case, a VI is required = to
complete=20 the unique identification of an administered item.

For = further=20 guidance, see ISO/IEC 11179-6.

An IRDI can serve as a key = when=20 exchanging data among information systems,
organizations, or = other=20 parties who wish to share a specific administered
item, but might = not=20 utilize the same names or contexts.

ISO/IEC 11179 does not = specify=20 the format or content of a unique DI.

The IETF (or LTRU) = would need=20 to apply for an International Code Designator
(ICD) - a four = integer=20 code; this coupled with the organization name as well
as a = "department"=20 identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.
The ICD = would be=20 registered by the RA of ISO/IEC 6523 Organization Codes = as
Registration=20 Authority Identifier which is currently BSI. =  

Implications for=20 the LTRU Registry
The DI (or UI - Unique Identifier) cannot be = the Subtag=20 as there are already
conflicting Subtags within the registry = (e.g.=20 cy/CY).  It is more preferable
that the unique identifier be = the=20 chosen language/country/script name
(please note, this is not the = preferred name).  This would fit with the
current ISO 639-3, = -5 and=20 -6 models and open the Registry to adoption by
meta-data = knowledge grids.=20 (I will take a good look at the naming
conventions within ISO = 3166-1 at a=20 later date but prior to publication of
FDIS 3166-1).=20  

Anomalies within ISO naming conventions of standards = issued=20 prior to the
adoption of ISO 11179 can be dealt with on a case by = case=20 basis via set
rules.  

The Subtag would become a=20 "Representation" with the name being the unique
"Data = Identifier". This=20 would involve having a "Primary Description" which
would form the = DI.

In reviewing the "Required Metadata Attributes" for a = "Preferred=20 Standard"
Status administered item, preliminary investigations = reveal no=20 serious
additional requirements other than those already = mentioned here.=20 Some
manipulation and interpretation of registry data and = standard=20 mandatory
requirements would be required but no difficulties are=20 envisaged. I would
refer the WG to ISO/IEC 11179-6:2005(E); Table = B-8=20 (p.34)

Benefits
The ISO 11179 model allows for there being = conflicting codes between
different meta-data registries in = conformity=20 with ISO 11179; that is part of
the conceptual model.  ("in=20 conformity with" is correct - there are
essential parts of the=20 standard).

In essence, the ISO 11179 meta-model supports = linkage to=20 other ISO 11179
conformant meta-data registries thus facilitating = data=20 exchange/interchange
whilst giving the LTRU Registry ownership of = the=20 data elements contained
therein - they become LTRU elements = giving room=20 for manoeuvre should ISO get
it wrong.

This will make = language=20 tags more meaningful in the future.  The key word
here is = "linkage".=20  ISO 11179 conformant meta-data registries facilitate = the
creation=20 of knowledge grids, grid computing and the semantic=20 web!

Conclusion
At first glance the cost/value ratio = favours ISO=20 11179; there appears to be
very little cost yet the true benefits = of=20 future interoperability and data
exchange are unknown. =  

It=20 is recommended that further investigation be conducted before=20 application
of ISO 11179 can be discussed at WG level. =

Further=20 benefits with regard to data interchange should be = explored.

It is=20 further recommended that the "investigation into application of = ISO
11179=20 Meta Data Registries to the Registry and its registration = procedures
be=20 conducted by nominated members of the WG with a view to application" = be
added to the new LTRU Charter.  

Best=20 regards


Debbie=20 = Garside



_______________________________________________Ltru=20 mailing=20 = list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
<= BR>
------=_NextPart_000_00E5_01C69C85.BF9F4F30-- --===============0953434765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0953434765==-- From ltru-bounces@ietf.org Fri Jun 30 15:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOwN-0007au-VV; Fri, 30 Jun 2006 15:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOwM-0007ap-Ot for ltru@ietf.org; Fri, 30 Jun 2006 15:46:10 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOwL-0002B4-97 for ltru@ietf.org; Fri, 30 Jun 2006 15:46:10 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5UJk2xJ006383; Fri, 30 Jun 2006 20:46:03 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k5UJjukf006116; Fri, 30 Jun 2006 20:46:01 +0100 Message-Id: <200606301946.k5UJjukf006116@mta2.iomartmail.com> From: "Debbie Garside" To: "'Debbie Garside'" , Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Date: Fri, 30 Jun 2006 20:45:50 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaaRtGC6+ZxHRxlRvygUz+eA4jaagAPctTwAH2atfAAAKJx0A== In-Reply-To: X-Spam-Score: 0.3 (/) X-Scan-Signature: a760c82fa28c4c53b9b163788fb3a40b Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1610352247==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1610352247== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01C69C86.3032BCA0" This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01C69C86.3032BCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I wrote: "Strictly Conforming" This is equal to Conformance Level 2 (All clause 4 Mandatory and Conditional) Best regards Debbie _____ From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 30 June 2006 20:43 To: 'Debbie Garside'; 'Karen_Broome@spe.sony.com' Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Hi Karen I have looked at this in a little more detail now and you are correct if we were to consider "Strictly Conforming" to ISO 11179. However, having completed a preliminary test map from the Registry (and associated documentation within the RFC) to Clause 5 of part 3 (Basic Attributes) as well as the requirements of part 6 (as outlined in my previous mail), I think Conformance Level 1 (part 3 clause 6) could be achieved without too much effort. That said, I would really want to study this in more detail, my investigations are still very much preliminary - I would like to do a true implementation to be absolutely sure. If the WG decide to put investigation of implications and benefits of conformity with ISO 11179 for the Registry within the new Charter I would be happy to work with you on this if you have time. Best regards Debbie Garside _____ From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 28 June 2006 08:44 To: Karen_Broome@spe.sony.com Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179 Hi Karen Thanks for your input. I need to do a little more reading before I respond so it may be a few days :-) I think there are two ways of looking at 11179: 1. As a standard to assist in the design of a Meta-data Registry 2. As a standard to apply to an existing Meta-Data registry. I have been looking at what is as a bare minimum absolutely necessary in order to apply ISO 11179 to the LTRU Registry. I have read the whole standard but I need to do further depth reading to see what is required for the Registry to be conformant. There are one or two things that you have mentioned that do not fit with my interpretation but I would not want to say more until I have studied it further. best regards Debbie _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 28 June 2006 01:06 To: Debbie Garside Cc: 'Doug Ewell'; 'LTRU Working Group' Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179 Debbie, Did you review all of ISO 11179 or just 11179-6? There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this. The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer. The hierarchy, as I understand it, would be something like this: Data Concept Language Code: A standardized code used to identify a particular language or dialect. Data Elements [Data Concept + Representation Class] related to "Language Code" data concept = 1. ISO 639-1 Language Code: A two-letter code assigned by the ISO 639-1 standard to identify a particular language. 2. ISO 639-2/B Language Code 3. ISO 639-2/T Language Code 4. ISO 639-3 Language Code 5. ISO 639-6 Language Code Value Domain Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US". ... For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic: Data Concept = Script Code Data Element = ISO 15924 Script Code Data Concept = Country Code Data Element = ISO 3166 Country Code Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as: 1. En-US Language Name 2. Fr-FR Language Name 3. En-US Script Name 4. En-US Country Name etc. These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think. I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing. :) Best regards, Karen Broome Sony Pictures Entertainment "Debbie Garside" 06/27/2006 01:22 AM To "'LTRU Working Group'" cc 'Doug Ewell' Subject [Ltru] Preliminary Investigation into Application of ISO 11179 Findings of a preliminary investigation into the application of ISO 11179 to the RFC3066bis Registry Cost Initial investigations suggest that ISO 11179 can be applied to the Registry at a base level for very little cost. The main cost is in mapping the ISO 11179 terminology to the existing Registry terminology and a number of additional data elements would be required. The Registry already incorporates a system of metadata elements that are consistent with the model presented within ISO 11179. In particular the value of the following aspects of ISO 11179-6 should be investigated: Identification The attributes registration authority identifier (RAI), data identifier (DI), and version identifier (VI) constitute the international registration data identifier (IRDI). At least one IRDI is required for an administered item. Data identifiers are assigned by a Registration Authority; data identifiers shall be unique within the domain of a Registration Authority. Requirements for a Registration Authority, and a discussion of the IRDI, appear in ISO/IEC 11179-6. As each Registration Authority may determine its own DI assignment scheme, there is no guarantee that the DI by itself will uniquely identify an administered item. For example, if two authorities both use sequential 6-digit numbers, there may be two administered items with the same DI's; however, the administered items will almost certainly not be the same. If one administered item appears in two registers, it will have two DI's. Therefore, both the DI and the RAI are necessary for identification of an administered item. If particular attributes of an administered item change, then a new version of the administered item shall be created and registered. The registrar shall determine these attributes. In such a case, a VI is required to complete the unique identification of an administered item. For further guidance, see ISO/IEC 11179-6. An IRDI can serve as a key when exchanging data among information systems, organizations, or other parties who wish to share a specific administered item, but might not utilize the same names or contexts. ISO/IEC 11179 does not specify the format or content of a unique DI. The IETF (or LTRU) would need to apply for an International Code Designator (ICD) - a four integer code; this coupled with the organization name as well as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as Registration Authority Identifier which is currently BSI. Implications for the LTRU Registry The DI (or UI - Unique Identifier) cannot be the Subtag as there are already conflicting Subtags within the registry (e.g. cy/CY). It is more preferable that the unique identifier be the chosen language/country/script name (please note, this is not the preferred name). This would fit with the current ISO 639-3, -5 and -6 models and open the Registry to adoption by meta-data knowledge grids. (I will take a good look at the naming conventions within ISO 3166-1 at a later date but prior to publication of FDIS 3166-1). Anomalies within ISO naming conventions of standards issued prior to the adoption of ISO 11179 can be dealt with on a case by case basis via set rules. The Subtag would become a "Representation" with the name being the unique "Data Identifier". This would involve having a "Primary Description" which would form the DI. In reviewing the "Required Metadata Attributes" for a "Preferred Standard" Status administered item, preliminary investigations reveal no serious additional requirements other than those already mentioned here. Some manipulation and interpretation of registry data and standard mandatory requirements would be required but no difficulties are envisaged. I would refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) Benefits The ISO 11179 model allows for there being conflicting codes between different meta-data registries in conformity with ISO 11179; that is part of the conceptual model. ("in conformity with" is correct - there are essential parts of the standard). In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 conformant meta-data registries thus facilitating data exchange/interchange whilst giving the LTRU Registry ownership of the data elements contained therein - they become LTRU elements giving room for manoeuvre should ISO get it wrong. This will make language tags more meaningful in the future. The key word here is "linkage". ISO 11179 conformant meta-data registries facilitate the creation of knowledge grids, grid computing and the semantic web! Conclusion At first glance the cost/value ratio favours ISO 11179; there appears to be very little cost yet the true benefits of future interoperability and data exchange are unknown. It is recommended that further investigation be conducted before application of ISO 11179 can be discussed at WG level. Further benefits with regard to data interchange should be explored. It is further recommended that the "investigation into application of ISO 11179 Meta Data Registries to the Registry and its registration procedures be conducted by nominated members of the WG with a view to application" be added to the new LTRU Charter. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_00EF_01C69C86.3032BCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I wrote:
 
 "Strictly Conforming"
 
This is equal to Conformance Level 2 (All = clause 4=20 Mandatory and Conditional)
 
Best regards
 
Debbie

From: Debbie Garside=20 [mailto:debbie@ictmarketing.co.uk]
Sent: 30 June 2006=20 20:43
To: 'Debbie Garside';=20 'Karen_Broome@spe.sony.com'
Cc: 'Doug Ewell'; 'LTRU Working=20 Group'
Subject: RE: [Ltru] Preliminary Investigation into=20 Application of ISO 11179

Hi Karen
 
I have looked at this in a little more detail = now and you=20 are correct if we were to consider "Strictly Conforming" to ISO=20 11179.
 
However, having completed a preliminary test = map from the=20 Registry (and associated documentation within the RFC) to Clause = 5 of=20 part 3 (Basic Attributes) as well as the requirements of part 6 (as = outlined=20 in my previous mail), I think Conformance Level 1 (part 3 clause = 6) could=20 be achieved without too much effort. 
 
That said, I would really want to study this = in more=20 detail, my investigations are still very much preliminary -  I = would like=20 to do a true implementation to be absolutely sure.
 
If the WG decide to put investigation of = implications and=20 benefits of conformity with ISO 11179 for the Registry within the new = Charter=20 I would be happy to work with you on this if you have=20 time.
 
Best regards
 
Debbie Garside

From: Debbie Garside=20 [mailto:debbie@ictmarketing.co.uk]
Sent: 28 June 2006=20 08:44
To: Karen_Broome@spe.sony.com
Cc: 'Doug = Ewell';=20 'LTRU Working Group'
Subject: RE: [Ltru] Preliminary = Investigation=20 into Application of ISO 11179

Hi Karen
 
Thanks for your input.  I need to do a = little more=20 reading before I respond so it may be a few days = :-)
 
I think there are two ways of looking at = 11179: 1. As a=20 standard to assist in the design of a Meta-data Registry 2. As a = standard to=20 apply to an existing Meta-Data registry.
 
I have been looking at what is as a bare = minimum=20 absolutely necessary in order to apply ISO 11179 to the LTRU = Registry. =20 I have read the whole standard but I need to do further depth = reading=20 to see what is required for the Registry to be=20 conformant.
 
There are one or two things that you have = mentioned=20 that do not fit with my interpretation but I would not want to say = more=20 until I have studied it further.
 
best regards
 
Debbie
 

From: = Karen_Broome@spe.sony.com=20 [mailto:Karen_Broome@spe.sony.com]
Sent: 28 June 2006=20 01:06
To: Debbie Garside
Cc: 'Doug Ewell'; = 'LTRU=20 Working Group'
Subject: Re: [Ltru] Preliminary = Investigation=20 into Application of ISO 11179


Debbie, =

Did you review all of ISO 11179 or just = 11179-6?=20

There is a lot = more to ISO=20 11179 than just the administrative practices (-6) and the previous = parts=20 discuss a hierarchical metadata model not mentioned in your review = below.=20 I think you're confusing the terms "value" and "representation" = and the=20 other sections provide clarity on this.  The top of the = hierarchy is=20 the Data Concept, which is an abstract description independent of = its=20 representation -- a pure semantic layer.

The hierarchy, as I understand it, = would be=20 something like this:

Data=20 Concept
    =  =20   Language Code: A standardized code used to identify a = particular=20 language or dialect.

Data=20 Elements [Data Concept + Representation Class] related to = "Language Code"=20 data concept =3D
  1. ISO 639-1 = Language Code:=20  A two-letter code assigned by the ISO 639-1 standard to = identify a=20 particular language.=20
  2. ISO 639-2/B = Language=20 Code=20
  3. ISO 639-2/T = Language=20 Code=20
  4. ISO 639-3 = Language Code=20
  5. ISO 639-6 = Language=20 Code

Value = Domain=20
        = Each data=20 element in this case has a "Value Domain" and the Value Domain = contains=20 the individual values such as "en-US".

...

For=20 the Language Code data concept, the ISO 11179 structure seems = relevant and=20 useful. But when we look at some of the other concepts, it seems = less=20 useful and perhaps problematic:

Data Concept =3D Script Code
Data Element =3D ISO 15924 Script Code =

Data Concept =3D Country Code =
Data Element =3D ISO 3166 Country = Code=20

Note that "Description" = or even=20 "Subtag Description" is too vague by ISO 11179 rules (subjective = judgment,=20 but there are a lot of examples that support this view) and I = think you=20 would need to break these out as:
  1. En-US Language = Name=20
  2. Fr-FR Language = Name=20
  3. En-US Script = Name=20
  4. En-US Country=20 Name
etc.=20

These are unique data = elements=20 relating to several data concepts, so the current model with its=20 "Description" field would need serious revision to be compliant, I = think.

I'm not = opposed to=20 further discussion of this moving forward. I only question how = valuable=20 this is for a standard that has so few data elements. It is a good = thing=20 that you're familiar with the section of the standard I've spent = the least=20 time reviewing.  :)

Best=20 regards,

Karen = Broome
Sony=20 Pictures Entertainment



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

06/27/2006 01:22 = AM

To
"'LTRU Working = Group'"=20 <ltru@ietf.org>=20
cc
'Doug Ewell'=20 <dewell@adelphia.net>=20
Subject
[Ltru] Preliminary=20 Investigation into Application of ISO=20 11179

=




<= FONT=20 size=3D2>Findings of a preliminary investigation into the = application of=20 ISO 11179 to
the RFC3066bis Registry

Cost
Initial=20 investigations suggest that ISO 11179 can be applied to the = Registry
at=20 a base level for very little cost.  The main cost is in = mapping the=20 ISO
11179 terminology to the existing Registry terminology and = a number=20 of
additional data elements would be required.  The = Registry=20 already
incorporates a system of metadata elements that are = consistent=20 with the
model presented within ISO 11179.  

In = particular=20 the value of the following aspects of ISO 11179-6 should=20 be
investigated:

Identification
The attributes = registration=20 authority identifier (RAI), data identifier
(DI), and version=20 identifier (VI) constitute the international registration
data=20 identifier (IRDI). At least one IRDI is required for an=20 administered
item.

Data identifiers are assigned by a=20 Registration Authority; data identifiers
shall be unique within = the=20 domain of a Registration Authority.

Requirements for a=20 Registration Authority, and a discussion of the IRDI,
appear in = ISO/IEC=20 11179-6.

As each Registration Authority may determine its = own DI=20 assignment scheme,
there is no guarantee that the DI by itself = will=20 uniquely identify an
administered item. For example, if two = authorities=20 both use sequential
6-digit numbers, there may be two = administered=20 items with the same DI's;
however, the administered items will = almost=20 certainly not be the same.

If one administered item = appears in two=20 registers, it will have two DI's.
Therefore, both the DI and = the RAI=20 are necessary for identification of an
administered item. =

If=20 particular attributes of an administered item change, then a new=20 version
of the administered item shall be created and = registered. The=20 registrar
shall determine these attributes. In such a case, a = VI is=20 required to
complete the unique identification of an = administered=20 item.

For further guidance, see ISO/IEC 11179-6.

An = IRDI=20 can serve as a key when exchanging data among information=20 systems,
organizations, or other parties who wish to share a = specific=20 administered
item, but might not utilize the same names or=20 contexts.

ISO/IEC 11179 does not specify the format or = content of a=20 unique DI.

The IETF (or LTRU) would need to apply for an=20 International Code Designator
(ICD) - a four integer code; this = coupled=20 with the organization name as well
as a "department" identifier = (OPI)=20 becomes the IRDI e.g. 1234.IETF.LTRU.
The ICD would be = registered by=20 the RA of ISO/IEC 6523 Organization Codes as
Registration = Authority=20 Identifier which is currently BSI.  

Implications for = the LTRU=20 Registry
The DI (or UI - Unique Identifier) cannot be the = Subtag as=20 there are already
conflicting Subtags within the registry (e.g. = cy/CY).=20  It is more preferable
that the unique identifier be the = chosen=20 language/country/script name
(please note, this is not the = preferred=20 name).  This would fit with the
current ISO 639-3, -5 and = -6=20 models and open the Registry to adoption by
meta-data knowledge = grids.=20 (I will take a good look at the naming
conventions within ISO = 3166-1 at=20 a later date but prior to publication of
FDIS 3166-1).=20  

Anomalies within ISO naming conventions of standards = issued=20 prior to the
adoption of ISO 11179 can be dealt with on a case = by case=20 basis via set
rules.  

The Subtag would become a=20 "Representation" with the name being the unique
"Data = Identifier". This=20 would involve having a "Primary Description" which
would form = the=20 DI.

In reviewing the "Required Metadata Attributes" for a=20 "Preferred Standard"
Status administered item, preliminary=20 investigations reveal no serious
additional requirements other = than=20 those already mentioned here. Some
manipulation and = interpretation of=20 registry data and standard mandatory
requirements would be = required but=20 no difficulties are envisaged. I would
refer the WG to ISO/IEC=20 11179-6:2005(E); Table B-8 (p.34)

Benefits
The ISO 11179 = model=20 allows for there being conflicting codes between
different = meta-data=20 registries in conformity with ISO 11179; that is part of
the = conceptual=20 model.  ("in conformity with" is correct - there = are
essential=20 parts of the standard).

In essence, the ISO 11179 = meta-model=20 supports linkage to other ISO 11179
conformant meta-data = registries=20 thus facilitating data exchange/interchange
whilst giving the = LTRU=20 Registry ownership of the data elements contained
therein - = they become=20 LTRU elements giving room for manoeuvre should ISO get
it=20 wrong.

This will make language tags more meaningful in the = future.=20  The key word
here is "linkage".  ISO 11179 = conformant=20 meta-data registries facilitate the
creation of knowledge = grids, grid=20 computing and the semantic web!

Conclusion
At first = glance the=20 cost/value ratio favours ISO 11179; there appears to be
very = little=20 cost yet the true benefits of future interoperability and = data
exchange=20 are unknown.  

It is recommended that further = investigation be=20 conducted before application
of ISO 11179 can be discussed at = WG level.=20

Further benefits with regard to data interchange should be = explored.

It is further recommended that the "investigation = into=20 application of ISO
11179 Meta Data Registries to the Registry = and its=20 registration procedures
be conducted by nominated members of = the WG=20 with a view to application" be
added to the new LTRU Charter.=20  

Best regards


Debbie=20 = Garside



_______________________________________________Ltru=20 mailing=20 = list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
<= BR>
------=_NextPart_000_00EF_01C69C86.3032BCA0-- --===============1610352247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1610352247==-- From ltru-bounces@ietf.org Fri Jun 30 16:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPXr-0006K1-Rb; Fri, 30 Jun 2006 16:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPXq-0006Jt-IR; Fri, 30 Jun 2006 16:24:54 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPXn-000531-Ak; Fri, 30 Jun 2006 16:24:54 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FwPXm-0004Rj-Bu; Fri, 30 Jun 2006 16:24:50 -0400 Date: Fri, 30 Jun 2006 16:24:50 -0400 To: Addison Phillips Subject: Re: [Ltru] gen-art review and response... Message-ID: <20060630202450.GA16164@ccil.org> References: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: gen-art@ietf.org, 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > s2.3, para 1: Transliteration/Internationalization issue: Many of the > Sámi using peoples transliterate Sámi as Saami rather than Sami. > > [Addison] Noted. This is a side effect of not having I-Ds use UTF-8 > as their encoding. Perhaps someday I-Ds will join the modern world in > this respect :-). It's also a side-effect of their proximity to Finnish-speakers, who use the double-vowel convention for long vowels. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru