From ltru-bounces@ietf.org Tue Jan 03 19:10:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtwE8-0005Tp-Rn; Tue, 03 Jan 2006 19:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EttOV-0000sM-Bv for ltru@megatron.ietf.org; Tue, 03 Jan 2006 16:08:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04458 for ; Tue, 3 Jan 2006 16:07:20 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EttTo-00056M-UE for ltru@ietf.org; Tue, 03 Jan 2006 16:14:06 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Jan 2006 13:08:23 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 13:08:22 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 13:08:22 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 13:08:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jan 2006 13:08:20 -0800 Message-ID: Thread-Topic: CLDR update thread-index: AcYGosXDAdtYQPoGRLKaFUtl2KVyEgJ/28KQ From: "Michel Suignard" To: "Mark Davis" , "Harald Tveit Alvestrand" X-OriginalArrivalTime: 03 Jan 2006 21:08:22.0158 (UTC) FILETIME=[D42882E0:01C610A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 03 Jan 2006 19:10:02 -0500 Cc: ltru@ietf.org, cldr@unicode.org Subject: [Ltru] RE: CLDR update X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0510371049==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0510371049== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 fCBGcm9tOiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddIA0K fA0KfCBRdWVzdGlvbjogYWNjb3JkaW5nIHRvDQp8IGh0dHA6Ly93d3cuZXRobm9sb2d1ZS5jb20v c2hvd19sYW5ndWFnZS5hc3A/Y29kZT1oeWUNCnwgdGhlcmUgaXMgbm8gY29kZSBmb3IgRWFzdGVy biB2cyBXZXN0ZXJuIEFybWVuaWFuLiBXaWxsDQp8IElTTyBiZSBhZGRpbmcgdGhpcyBhcyBwYXJ0 IG9mIHRoZSBuZXh0IHJldmlzaW9uPyBJdA0KfCBhcHBlYXJzIHRoYXQgdGhlcmUgYXJlIGRpc3Rp bmN0IGRpZmZlcmVuY2VzIGluDQp8IG9ydGhvZ3JhcGh5IHRoYXQgd2UgbmVlZCB0byBhY2NvdW50 IGZvciwgYXQgbGVhc3QNCnwgYWNjb3JkaW5nIHRvDQp8IGh0dHA6Ly9lbi53aWtpcGVkaWEub3Jn L3dpa2kvQXJtZW5pYW5fbGFuZ3VhZ2UNCg0KVGhlIHdpa2lwZWRpYSBlbnRyeSBzZWVtcyByZWFz b25hYmx5IGFjY3VyYXRlIHRvIG1lLiBPYnZpb3VzbHkgdGhlIEVhc3Rlcm4gdmVyc2lvbiBpcyBt b3JlIGhvbW9nZW5lb3VzLCB3aGlsZSB0aGUgV2VzdGVybiB2ZXJzaW9uIGlzIHRoZSBkaWFzcG9y YSB0b25ndWUgYW5kIGFzIHN1Y2ggaXMgaW5oZXJpdGluZyBmcm9tIHRoZSBjb3VudHJ5IGxhbmd1 YWdlcyB3aGVyZSBpdCBpcyB1c2VkLCBldmVuIGlmIG9yaWdpbmFsbHkgaXQgaGFkIG1hbnkgVHVy a2lzaCBib3Jyb3dpbmdzIGJhc2VkIG9uIHRoZSBzaXR1YXRpb24gdGhhdCBtb3N0IG9mIHRoZSBk aWFzcG9yYSBmb2xrcyBjYW1lIGZyb20gVHVya2V5LCBlc3BlY2lhbGx5IHRoZSBJc3RhbmJ1bCBh cmVhLg0KDQpNaWNoZWwNCg0KDQoNCg== --===============0510371049== 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 --===============0510371049==-- From ltru-bounces@ietf.org Fri Jan 06 10:15:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutJk-0006wy-RB; Fri, 06 Jan 2006 10:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutJi-0006wi-T0 for ltru@megatron.ietf.org; Fri, 06 Jan 2006 10:15:47 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07207 for ; Fri, 6 Jan 2006 10:14:28 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EutJU-0000Je-Mu for ltru@lists.ietf.org; Fri, 06 Jan 2006 16:15:32 +0100 Received: from 1cust121.tnt9.hbg2.deu.da.uu.net ([149.225.140.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 16:15:32 +0100 Received: from nobody by 1cust121.tnt9.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 16:15:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 06 Jan 2006 16:11:50 +0100 Organization: Lines: 12 Message-ID: <43BE88B6.65EB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust121.tnt9.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] IANA language subtag registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi, you probably knew it, I didn't, the registries are online: http://www.iana.org/assignments/language-subtag-registry http://www.iana.org/assignments/language-tag-extensions-registry The RfC editor queue doesn't work at the moment, but Bill has a snapshot when it went from status IANA to EDIT (2006-01-04): http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ltru-registry Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 08 13:32:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvfKj-0007hO-GF; Sun, 08 Jan 2006 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvfKh-0007hB-Fn for ltru@megatron.ietf.org; Sun, 08 Jan 2006 13:31:59 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10559 for ; Sun, 8 Jan 2006 13:30:39 -0500 (EST) 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 <20060108183127.EAQO26442.mta13.adelphia.net@DGBP7M81> for ; Sun, 8 Jan 2006 13:31:27 -0500 Message-ID: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 8 Jan 2006 10:31:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Transfer-Encoding: 7bit Subject: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The last message on this list that was relevant to the progress of our only remaining work item was on December 21, 18 days ago. We were talking about q-values and whether users could see, understand, or customize them, and about Harald's suggestion to assign explicit numeric weights to items in lists. There have been other messages since then, but they don't seem to be related to getting the matching draft done. Can we resolve the remaining issues with draft-matching-08, generate a new draft, and start assessing (again) how close we are to WG Last Call? I hate to see the group stagnating while there is still work to do, and if it is true that none of our documents will be published until all are approved, then we are causing unnecessary delay for users who want to use the new mechanism. -- 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 Jan 08 14:41:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvgPV-0003zP-FL; Sun, 08 Jan 2006 14:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvgPU-0003zK-UN for ltru@megatron.ietf.org; Sun, 08 Jan 2006 14:41:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14108 for ; Sun, 8 Jan 2006 14:39:43 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvgVq-0002Ek-VV for ltru@ietf.org; Sun, 08 Jan 2006 14:47:35 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EvgPG-0002QC-9X; Sun, 08 Jan 2006 11:40:49 -0800 Message-Id: <6.2.3.4.2.20060108200858.043571a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 08 Jan 2006 20:40:35 +0100 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) In-Reply-To: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 19:31 08/01/2006, Doug Ewell wrote: >The last message on this list that was relevant to the progress of >our only remaining work item was on December 21, 18 days ago. We >were talking about q-values and whether users could see, understand, >or customize them, and about Harald's suggestion to assign explicit >numeric weights to items in lists. > >There have been other messages since then, but they don't seem to be >related to getting the matching draft done. > >Can we resolve the remaining issues with draft-matching-08, generate >a new draft, and start assessing (again) how close we are to WG Last >Call? I hate to see the group stagnating while there is still work >to do, and if it is true that none of our documents will be >published until all are approved, then we are causing unnecessary >delay for users who want to use the new mechanism. Dear Doug, the Tunis agreement was reached a few hours before the IESG approved the RFC 3066 bis Draft. This was exactly the sequence I wished. It now permits a more serene approach. In this stabilised context there is an analysis to carry. It is to understand what belongs to an internationalized-US-ASCII Internet and to what belongs to the multilingual/multicultural harmonisation of the International Network. Also, if one can be considered as a unilateral default of the multilateral or cross-lateral other. Who has the competence, the responsibility, the budget, and the ethical and cultural legitimacy for hosting such a debate, and the resulting registries. Your registry is a stable element as it reproduces three ISO standards. It is in the IANA. The RFC 3066 bis Draft can be patched to make its ABNF consistent with reality. It will probably not fly otherwise. The filtering issue is more uncertain as there is a need to fully understand its purpose. There are obviously additional risks exposed by the two-tiered Internet, where langtags may permit lingually discriminatory service quality. People are also concerned about the CLDR project and its relations with the USG/DoD strategies (from meeting annouces by Unicode). Meetings have been hold on various related issues (IDNs, discrimination, profiling, network architecture). They show the whole topic is not stabilized yet. Hence probably not motivating. RFC 3066 bis proposes a language network naming and filtering system. Questions are now what is the use of a name for a language if the language is not identified by its user (what none did during the last 7.000 years)? how does it help/hampers the use of the language in the network? Same for filtering. I introduced an appeal to the IAB to try to clarify if multilingualism belongs or not to the IETF. I suppose advisable to wait for the response Leslie Daigle said the IAB will do. May be also to see how the NSF follows on Tunis and includes lingual support, and how, in GENI. What will be the trend for the IGF. Sorry if this does not match your impatience. It also tries to explain the silence. All the best and happy new year. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 08 19:28:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvktY-0004Kb-Ec; Sun, 08 Jan 2006 19:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvktW-0004KW-K8 for ltru@megatron.ietf.org; Sun, 08 Jan 2006 19:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29612 for ; Sun, 8 Jan 2006 19:26:59 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evkzu-00014S-Aa for ltru@ietf.org; Sun, 08 Jan 2006 19:34:55 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 329F02596D7; Mon, 9 Jan 2006 01:27:06 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17835-09; Mon, 9 Jan 2006 01:27:02 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73AD42596C7; Mon, 9 Jan 2006 01:27:02 +0100 (CET) Date: Mon, 09 Jan 2006 01:28:01 +0100 From: Harald Tveit Alvestrand To: Doug Ewell , LTRU Working Group Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) Message-ID: In-Reply-To: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On s=F8ndag, januar 08, 2006 10:31:25 -0800 Doug Ewell=20 wrote: > The last message on this list that was relevant to the progress of our > only remaining work item was on December 21, 18 days ago. We were > talking about q-values and whether users could see, understand, or > customize them, and about Harald's suggestion to assign explicit numeric > weights to items in lists. > > There have been other messages since then, but they don't seem to be > related to getting the matching draft done. > > Can we resolve the remaining issues with draft-matching-08, generate a > new draft, and start assessing (again) how close we are to WG Last Call? > I hate to see the group stagnating while there is still work to do, and > if it is true that none of our documents will be published until all are > approved, then we are causing unnecessary delay for users who want to use > the new mechanism. Seconded. Chairs, are you thinking about creating an open issues list for the=20 matching draft? I haven't seen tickets for a while here.... Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 08 20:04:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvlSN-0001w4-Ja; Sun, 08 Jan 2006 20:04:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvlSL-0001vz-QC for ltru@megatron.ietf.org; Sun, 08 Jan 2006 20:04:18 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01535 for ; Sun, 8 Jan 2006 20:02:57 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EvlSH-0005Ge-SZ for ltru@lists.ietf.org; Mon, 09 Jan 2006 02:04:13 +0100 Received: from pd9fbad2d.dip0.t-ipconnect.de ([217.251.173.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jan 2006 02:04:13 +0100 Received: from nobody by pd9fbad2d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jan 2006 02:04:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 09 Jan 2006 01:59:20 +0100 Organization: Lines: 66 Message-ID: <43C1B568.179E@xyzzy.claranet.de> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Status of matching draft? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > if it is true that none of our documents will be published > until all are approved I don't share that fear, it's a subtle point that the old BCP also covered some kind of matching, and that "we" split that issue from the new RFC. Anything about the new registry and the new registration procedure is ready. You could post your collected post-date-B updates on the languages list whenever it pleases you. There are also many missing Suppress-Script values. I've noted one of the new "fy" where I'd know how to find some "official evidence" for a registration of "Latn" (better than Google or Wikipedia). > we are causing unnecessary delay for users who want to use > the new mechanism. A short delay is no serious problem. Early adopters trusting that the Suppress-Scripts are complete and publishing numerous explicit scripts in new language-tags could be in trouble. For the matching draft what I recall is: The ABNF for ranges is in essence ready, no showstoppers in sight. Details about interpreting missing subtags (with zero or more explicit "*") are IIRC also ready. For the implementation details, e.g. "scoring" with precise numerical values, or "distance metric", we ran into problems, there are too many ways to get it more or less right and obviously wrong. Maybe the scoring should be only an "informative example", pointing out some potential features plus traps and pitfalls, but not normative. "Number of variants is in theory unlimited" was one issue, and 8-4-2-1 won't fly if you want four independent dimensions with "region more important than whatever variants". Maybe we could shrink it to "language + script + details" (?) Explaining the effects if one or both sides have no script wrt Suppress-Script. Personally I'm also interested in two examples "I want Latn" as first priority (before the language), and "precisely this variant, no matter what the region is". For lists of ranges we should explain that this could be a simple OR (same weight), or an ordered list, and how to get these effects with scoring of the matches plus q-values for the ranges. Maybe we should simply say that "lists of ranges" are out of scope for the matching draft, and focus on the matching for one range. With a note that scoring plus q-values for ranges could extend this concept to lists of more than one range. That's how I recall the discussion, but I probably missed some points. IMO we're seriously in trouble when we try to discuss "integer arithmetic", "percent scales", or other implementation details. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 09 17:45:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5lN-0005XG-60; Mon, 09 Jan 2006 17:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5lL-0005VV-Df for ltru@megatron.ietf.org; Mon, 09 Jan 2006 17:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05265 for ; Mon, 9 Jan 2006 17:43:56 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew5rv-0000US-MF for ltru@ietf.org; Mon, 09 Jan 2006 17:52:04 -0500 Received: (qmail 88311 invoked from network); 9 Jan 2006 22:45:11 -0000 Received: from unknown (HELO ?9.43.213.116?) (unknown) by unknown with SMTP; 9 Jan 2006 22:45:11 -0000 X-pair-Authenticated: 129.42.184.35 Message-ID: <43C2E775.7000808@icu-project.org> Date: Mon, 09 Jan 2006 14:45:09 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> In-Reply-To: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I agree that we need to push this along (I've been out for about 2 weeks). Returning to the subject of weighting. Harald wrote the following (below). From the RFCs referencing Q values, the RFCs that reference it just don't specify what happens. Here is an example: If no Q values are given, the language-ranges are given in priority order, with the leftmost language-range being the most preferred language; this is an extension to the HTTP/1.1 rules, but matches current practice. -- ftp://ftp.isi.edu/in-notes/rfc3282.txt The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language- range in the field that matches the language-tag. If no language- range in the field matches the tag, the language quality factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable. -- ftp://ftp.isi.edu/in-notes/rfc2616.txt My misgivings are that when I specify "fr, de, en;q=0.9" it says nothing about the priority of the two. It could be that they are completely equal in priority, and I just have to put one of them first, or it could be that fr is by far the best, and I can just barely make out German. So it could correspond to either of the following: "fr;q=1.0, de;q=1.0, en;q=0.9" "fr;q=1.0, en;q=0.9, de;q=0.1" (reordered by the resulting priority). Harald's proposal would make it be equivalent to "fr;q=1.0, en;q=0.9, de;q=0.75" ==== http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html If we look at filtering in practice, we see two models. 1. Simplest In Google, for example, you can specify that you either want to allow languages or not. All are equal -- so essentially all q values are 1.0 or 0.0. 2. More sophisticated Fancy systems will allow features like boolean combinations; eg the document contains ("cat" in English OR "Katze" in German OR "chat" in French ), where the priority of a language will depend on other requested characteristics. Thus a document containing "chat" in English (but not "cat") would be excluded from a match. So I am not dead-set against including Harald's approach of each successive item being .75 times the previous, as long as we phrase it so that it is optional. However, I think it would really be simpler to just say that they get the same value as the preceeding item. So, in toto, here is my suggested text to resolve this issue. Replace the the last text paragraph of 3.2.3. Scored Filtering as follows. Implementations or protocols sometimes might wish to use more sophisticated weights that depend on the values of the corresponding elements. For example, depending on the domain, an implementation might give a small distance to the difference closely related subtags. Some examples of closely related subtags might be: Where a language priority list follows the syntax of the "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 14.4) and RFC 3282 [RFC3282], language tags without a Q value are given values equal to the value of the previous language tag (processing from first to last). If the first language tag has no Q value, it is given a value of 1.0. Then language tags with zero Q values are removed. For example, "fr, en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". The distance values given above are then divided by the Q values. For example, if "fr-FR has a distance of 384 and a Q value of 0.8, then the resulting resolved distance is 480. Implementations or protocols may use different weighting systems than the ones described aboves, as long as the weightings and weighting mechanisms are clearly specified. Thus, for example, an implementation or protocol could give all language tags with missing Q values a value of 1.0, or give the distance value 1000 to a language mismatch. They may also wish to use more sophisticated weights that depend on the values of the corresponding elements. For example, depending on the domain, an implementation might give a small distance to the difference closely related subtags. Some examples of closely related subtags might be: Mark > > > Harald Tveit Alvestrand wrote: > > --On fredag, november 18, 2005 17:37:05 -0800 Mark Davis > wrote: > >> We can do an integer only approach. Convert the q's into round(100/q). >> >> For filtering, we can't assume anything about the order of items in the >> list that have the same q values. I have en, de, fr, it, nl. But my >> English is significantly better than my German, which is somewhat better >> than my French, which is significantly better than my Italian, etc. >> >> For lookup, we and everybody I know just uses the q values to reorder >> the >> list. Then throws them away. So for lookup, ordering is very important. > > > If we want to have ordering and q values both "work", we might have to > bite the bullet and define them.... I'd suggest something like > > If an item in the list does not have a q value, its q value is assumed > to be 0.75 times the q value of the preceding item in the list. > If the first item in the list does not have a q value, its q value is > assumed to be 1. > > So the two lists > > en;q=1.0, fr;q=0.75, de > > en, fr, de;q=0.5625 > > would be completely identical. > That at least gives us a consistent, and mostly intuitive, > interpretation of such lists. Doug Ewell wrote: > The last message on this list that was relevant to the progress of our > only remaining work item was on December 21, 18 days ago. We were > talking about q-values and whether users could see, understand, or > customize them, and about Harald's suggestion to assign explicit > numeric weights to items in lists. > > There have been other messages since then, but they don't seem to be > related to getting the matching draft done. > > Can we resolve the remaining issues with draft-matching-08, generate a > new draft, and start assessing (again) how close we are to WG Last > Call? I hate to see the group stagnating while there is still work to > do, and if it is true that none of our documents will be published > until all are approved, then we are causing unnecessary delay for > users who want to use the new mechanism. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > 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 Jan 09 20:06:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew7yB-0001rU-Gk; Mon, 09 Jan 2006 20:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew7y9-0001rG-RW for ltru@megatron.ietf.org; Mon, 09 Jan 2006 20:06:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15836 for ; Mon, 9 Jan 2006 20:05:18 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew84k-000534-H3 for ltru@ietf.org; Mon, 09 Jan 2006 20:13:27 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 332622596EB; Tue, 10 Jan 2006 02:05:25 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26313-03; Tue, 10 Jan 2006 02:03:25 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D40EB2596EA; Tue, 10 Jan 2006 02:03:24 +0100 (CET) Date: Tue, 10 Jan 2006 02:04:24 +0100 From: Harald Tveit Alvestrand To: Mark Davis , Doug Ewell Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) Message-ID: <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> In-Reply-To: <43C2E775.7000808@icu-project.org> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On mandag, januar 09, 2006 14:45:09 -0800 Mark Davis wrote: > So I am not dead-set against including Harald's approach of each > successive item being .75 times the previous, as long as we phrase it so > that it is optional. However, I think it would really be simpler to just > say that they get the same value as the preceeding item. Simpler, but (this came out when I was doing 3066) incompatible with current practice. Browsers generally pretty consistently take the first match on the list; "equal weight" doesn't do that. (A difference of 0.0000001 would also do it "right", of course; 0.75 was just a number from a hat). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 09 21:21:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew98E-00014e-OJ; Mon, 09 Jan 2006 21:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew98C-00014Z-De for ltru@megatron.ietf.org; Mon, 09 Jan 2006 21:21:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22733 for ; Mon, 9 Jan 2006 21:19:44 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew9En-0007v3-No for ltru@ietf.org; Mon, 09 Jan 2006 21:27:55 -0500 Received: (qmail 90904 invoked from network); 10 Jan 2006 02:20:59 -0000 Received: from unknown (HELO ?9.43.213.116?) (unknown) by unknown with SMTP; 10 Jan 2006 02:20:59 -0000 X-pair-Authenticated: 129.42.184.35 Message-ID: <43C31A0A.9000709@icu-project.org> Date: Mon, 09 Jan 2006 18:20:58 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> In-Reply-To: <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org But that is current practice for *lookup*, not for *filtering*. Here is suggested language for the latter, just after Figure 10 in http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html. Where a language priority list contains Q values as in the syntax of the "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 14.4) and RFC 3282 [RFC3282], language tags without a Q value are given values equal to the value of the previous language tag (processing from first to last). If the first language tag has no Q value, it is given a value of 1.0. Then language tags with zero Q values are removed. For example, "fr, en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". The language priority list is then sorted from highest priority to lowest, whereby any two language tags with the same Q values are remain in the same order as in the original language priority list. This list is then traversed as described above in doing lookup. Implementations or protocols may use different lookup mechanisms systems than the ones described aboves, as long as those mechanisms are clearly specified. This has the same effect as what you describe; if you have a list with no Q values, the first one matched is returned. Mark Harald Tveit Alvestrand wrote: > > > --On mandag, januar 09, 2006 14:45:09 -0800 Mark Davis > wrote: > >> So I am not dead-set against including Harald's approach of each >> successive item being .75 times the previous, as long as we phrase it so >> that it is optional. However, I think it would really be simpler to just >> say that they get the same value as the preceeding item. > > > Simpler, but (this came out when I was doing 3066) incompatible with > current practice. > > Browsers generally pretty consistently take the first match on the > list; "equal weight" doesn't do that. (A difference of 0.0000001 would > also do it "right", of course; 0.75 was just a number from a hat). > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 10 04:53:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGBa-0004ee-Pt; Tue, 10 Jan 2006 04:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGBY-0004eZ-Ku for ltru@megatron.ietf.org; Tue, 10 Jan 2006 04:53:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18462 for ; Tue, 10 Jan 2006 04:51:41 -0500 (EST) Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwGID-0003Kk-W6 for ltru@ietf.org; Tue, 10 Jan 2006 04:59:54 -0500 Received: from Speechways@aol.com by imo-m27.mx.aol.com (mail_out_v38_r6.3.) id v.198.4e25c25f (15877); Tue, 10 Jan 2006 04:52:41 -0500 (EST) Received: from Laptop (host86-133-7-246.range86-133.btcentralplus.com [86.133.7.246]) by air-id07.mx.aol.com (v108_r1_b1.2) with ESMTP id MAILINID74-3e0543c383e6328; Tue, 10 Jan 2006 04:52:40 -0500 Message-ID: <001701c615cb$a80593c0$0201a8c0@Laptop> From: "David Dalby" To: References: Date: Tue, 10 Jan 2006 09:53:05 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AOL-IP: 86.133.7.246 X-Spam-Flag: NO X-Spam-Score: 0.5 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Cc: ltru@ietf.org Subject: [Ltru] Re: IUC 29; Note new e-mail address X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1043619039==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1043619039== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C615CB.A708E440" ------=_NextPart_000_0014_01C615CB.A708E440 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable New address for David Dalby and for Linguasphere Observatory (Hebron SA34 0X= T, Wales, UK) is now daviddalby@linguasphere.info (replacing the speechways=20= address from which this message is sent). With thanks, David Dalby tel +44 1994 419 660=20 ----- Original Message -----=20 From: Dana Morris=20 To: speechways@aol.com=20 Sent: Monday, January 09, 2006 5:36 PM Subject: IUC 29: New Program Content; Keynotes Cover Hot Topics =20 Subject: IUC 29: New Program Content; Keynotes Cover Hot Topics =20 What: The 29th Internationalization & Unicode Conference When: March 6-8, 2006 Where: San Francisco, California, U.S.A. Info: http://www.unicodeconference.org/kn =20 =20 The revitalized Internationalization & Unicode Conference is the premier t= echnical conference for both software and Web internationalization. Unicode=20= experts, implementers, clients and vendors are invited to attend this unique= conference, which will be the first to cover Unicode 5.0. The conference pr= ogram is full of new presentations covering cutting-edge trends and technolo= gy. Headlining the conference are three, all-new keynote presentations: =20 Going Global with a Search Engine by Tuoc Luong, Senior Vice President, En= gineering & Technology, Ask Jeeves, Inc. Taking a web service global is best done from the beginning. However, it i= s often the case that a software service is designed and implemented for the= United States first, then re-designed later for other languages and markets= worldwide. This was the case with the Ask Jeeves search service. This talk=20= will touch on all issues (both technical and non-technical) dealing with suc= h a re-design and move globally. The talk will give the audience a good flav= or of the issues involved in moving a highly scaleable search engine interna= tional.=20 =20 Unicode as a =93Unifying Force=94 in Language Education by Colonel Daniel=20= L. Scott, Assistant Commandant, Defense Language Institute Foreign Language=20= Center In the aftermath of 9/11 and the subsequent Global War on Terrorism, a new= family of languages has taken center stage. In this modern world conflict,=20= it=92s often the ancient languages that are emerging and important. Unfortun= ately, most of these ancient languages are not ready for prime time in terms= of computer support. The Defense Language Institute Foreign Language Center= mission is to train a new generation of linguists in these languages. Unico= de will help us transform language training by streamlining curriculum, impl= ementing web-based testing, conducting on-line classes, and fielding self-pa= ced study and reference materials for linguists at all proficiency levels an= d anywhere in the world. In this sense, Unicode becomes a =93unifying force= =94 for language education and support.=20 =20 The Effect of Unicode on Type Design by Charles Bigelow, Vice President, B= igelow & Holmes Inc. =20 The widespread adoption of Unicode has affected type design in ways that w= ere neither anticipated nor intended, but which may become even more signifi= cant in the future. The main factor is the creation of large fonts (=93large= =94 in the sense of many characters), which incorporate characters for sever= al orthographies, scripts, and symbols. A second factor is the structure of=20= the Unicode Standard, organized by named blocks of orthographies, scripts, a= nd symbols. A third factor is conflict between Unicode's definitional distin= ction of glyphs from characters, and the naive user=92s =93common sense=94 v= iew that the glyphs depicted in the Unicode manual are in fact the character= s. Finally, there are legibility factors, user-interface issues, and securit= y problems that arise when different characters are represented by glyphs, o= r combinations of glyphs, that appear similar or identical in some circumsta= nces, especially on display screens at small sizes and low resolutions. This= talk will be illustrated by examples of glyphs and fonts from a variety of=20= typefaces, as well as scripts from Latin to Arabic to Kanji.=20 =20 The conference is produced by The Object Management Group=99 (OMG=99) and=20= is sponsored by: Gold Sponsor Translations.com (www.translations.com); Silve= r Sponsors IBM Corporation (www.ibm.com), Basis Technology (www.basistech.co= m); Media Sponsors MultiLingual Computing Inc. (www.multilingual.com), Local= isation Research Centre (www.localisation.ie); and Organizational Sponsors L= ocalization Industry Standards Association (LISA) (www.lisa.org) and the Glo= balization and Localization Association (GALA) (www.gala-global.org). =20 The early-bird registration discount is available until February 1, 2006.=20= To register, visit http://www.unicodeconference.org/registration.htm. Exhibi= t space is available; for more information on exhibiting contact Sandy Burke= at sandy@omg.org or +1-781-444 0404. For sponsorship opportunities, contact= Nicole Rikkinen at nicole@omg.org. For all other conference-related questio= ns contact Kevin Loughry at loughry@omg.org, +1-781-444 0404. IUC 29 Web sit= e: http://www.unicodeconference.org/kn =20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ About The OMG The Object Management Group=99 (OMG=99) is an international, open membersh= ip, not-for-profit computer industry standards consortium. OMG member compan= ies write, adopt, and maintain its standards following a mature, open proces= s. OMG's standards implement the Model Driven Architecture=AE (MDA=AE), maxi= mizing ROI through a full-lifecycle approach to enterprise integration that=20= covers multiple operating systems, programming languages, middleware and net= working infrastructures, and software development environments. OMG's standa= rds include: UML=AE (Unified Modeling Language=99); CORBA=AE (Common Object=20= Request Broker Architecture); CWM=99 (Common Warehouse Metamodel); and indus= try-specific standards for dozens of vertical markets. OMG has offices at 25= 0 First Ave., Suite 100, Needham, MA 02494 USA. This email may be considered= to be commercial email, an advertisement or a solicitation. If you would prefer not to receive messages from the OMG, or have address=20= corrections, please reply to this email message, requesting Unsubscribe or d= escribing your address corrections. +++++++++++++++++++++++++++++++++++++++++++++++ ------=_NextPart_000_0014_01C615CB.A708E440 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
New address for David Dalby and for Linguas= phere=20 Observatory (Hebron SA34 0XT, Wales, UK) is now daviddalby@linguasphere.info=20 (replacing the speechways address from which this message is sent).
With thanks, David Dalby
tel +44 1994 419 660 
----- Original Message -----
Dana Morris
Sent: Monday, January 09, 2006 5:36= =20 PM
Subject: IUC 29: New Program Conten= t;=20 Keynotes Cover Hot Topics

 =20

= Subject: IUC 29: New Program Content; Keynotes Cover=20 Hot Topics

 

W= hat:      = ;       =20 The 29th Internationalization & Unicode=20 Conference

When:= =20       &= nbsp;            = ;    =20 March 6-8,=20 2006=

Where:           =20 S= an=20 Francisco<= SPAN style=3D"FONT-SIZE: 11pt; mso-bidi-font-size: 12.0pt">, = California,=20 <= SPAN style=3D"FONT-SIZE: 11pt; mso-bidi-font-size: 12.0pt">U.S.A.= =

Info:    &n= bsp;          =20 http://www.unicodeconferen= ce.org/kn

 =

 

The=20 revitalized Internationalization & Unicode Conference is the premier=20 technical conference for both software and Web internationalization. Unico= de=20 experts, implementers, clients and vendors are invited to attend this uniq= ue=20 conference, which will be the first to cover Unicode 5.0. The conference=20 program is full of new presentations covering cutting-edge trends and=20 technology. Headlining the conference are three, all-new keynote=20 presentations:

 

Going Global with a Search=20 Engine by Tuoc Luong, Senior=20 Vice President, Engineering & Technology, Ask Jeeves, Inc.

= Taking a web service=20 global is best done from the beginning. However, it is often the case that= a=20 software service is designed and implemented for the=20 United=20 States first, then re-designed=20 later for other languages and markets worldwide. This was the case with th= e=20 Ask Jeeves search service. This talk will touch on all issues (both techni= cal=20 and non-technical) dealing with such a re-design and move globally. T= he=20 talk will give the audience a good flavor of the issues involved in moving= a=20 highly scaleable search engine international.=20

 <= /P>

Unicode as a =93Unifying Force=94 in Language=20 Education by Colonel Daniel L. Scott, Assistant Commandant, Defense= =20 Language Institute Foreign=20 Language=20 Center=


In the aftermath of 9/11 and the subsequent Global=20= War=20 on Terrorism, a new family of languages has taken center stage. In this mo= dern=20 world conflict, it=92s often the ancient languages that are emerging and=20 important. Unfortunately, most of these ancient languages are not ready fo= r=20 prime time in terms of computer support. The=20 Defense=20 Language=20 Institute=20 Foreign Language=20 Center mission is to train a ne= w=20 generation of linguists in these languages. Unicode will help us transform= =20 language training by streamlining curriculum, implementing web-based testi= ng,=20 conducting on-line classes, and fielding self-paced study and reference=20 materials for linguists at all proficiency levels and anywhere in the worl= d.=20 In this sense, Unicode becomes a =93unifying force=94 for language educati= on and=20 support.

 

The Effect of Unicode on Type Design by=20 Charles Bigelow, Vice President, Bigelow & Holmes Inc.

 

The widespread adoption of Unicode has affected type=20 design in ways that were neither anticipated nor intended, but which may=20 become even more significant in the future. The main factor is the creatio= n of=20 large fonts (=93large=94 in the sense of many characters), which incorpora= te=20 characters for several orthographies, scripts, and symbols. A second facto= r is=20 the structure of the Unicode Standard, organized by named blocks of=20 orthographies, scripts, and symbols. A third factor is conflict between=20 Unicode's definitional distinction of glyphs from characters, and the naiv= e=20 user=92s =93common sense=94 view that the glyphs depicted in the Unicode m= anual are=20 in fact the characters. Finally, there are legibility factors, user-interf= ace=20 issues, and security problems that arise when different characters are=20 represented by glyphs, or combinations of glyphs, that appear similar or=20 identical in some circumstances, especially on display screens at small si= zes=20 and low resolutions. This talk will be illustrated by examples of glyphs a= nd=20 fonts from a variety of typefaces, as well as scripts from Latin to Arabic= to=20 Kanji.

 

The conference is produced by The Object Management=20 Group=99 (OMG=99) and is sponsored by:=20= Gold=20 Sponsor Translations.com (= www.translations.com); Silver Sponsors=20 IBM Corporation (www.ibm.com),=20 Basis Technology (www.basistech.com); Media Sponsors MultiLingual Computing Inc.=20 (www.multilingual.com= ), Localisation Research Centre (www.localisation.ie); and Organizational Sponsors Localization=20= Industry=20 Standards Association (LISA) (www.lisa.org)=20 and the Globalization and Localization Association (GALA) (www.g= ala-global.org).

 

The early-bird registration discount is available until=20 February 1,=20 2006. To register, visit http:/= /www.unicodeconference.org/registration.htm. Exhibit space is available; for more information on=20 exhibiting contact Sandy Burke at = sandy@omg.org=20 or +1-781-444 0404. For sponsorship opportunities, contact Nicole Rikkinen= at=20 .=20 For all other conference-related questions contact Kevin Loughry at l= oughry@omg.org, +1-781-444 040= 4. IUC 29 Web site: http://www.unicodeconference.org/kn

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
About=20 The OMG
The Object Management Group= =99=20 (OMG=99) is an international, open=20 membership, not-for-profit computer industry standards consortium.=20 OMG member companies write, adopt, and=20 maintain its standards following a mature, open process.=20 OMG's standards implement the Model Dri= ven=20 Architecture=AE (MDA=AE), maximizing RO= I=20 through a full-lifecycle approach to enterprise integration that covers=20 multiple operating systems, programming languages, middleware and networki= ng=20 infrastructures, and software development environments.=20 OMG's standards include: UML=AE (Unifie= d=20 Modeling Language=99); CORBA=AE (Common Object Request Broker Architecture= ); CWM=99=20 (Common Warehouse Metamodel); and industry-specific standards for dozens o= f=20 vertical markets. OMG has offices at=20 250 First Ave., Suite 100,=20 Needham, MA=20 02494=20 USA. This email may= be=20 considered to be commercial email, an advertisement or a=20 solicitation.

If you would prefer not to receive messages from the=20 OMG, or have address corrections, pleas= e=20 reply to this email message, requesting Unsubscribe or describing your add= ress=20 corrections.

+++++++++++++++++++++++++++++++++++++++++++++++=

------=_NextPart_000_0014_01C615CB.A708E440-- --===============1043619039== 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 --===============1043619039==-- From ltru-bounces@ietf.org Tue Jan 10 07:32:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwIfg-0006CG-1l; Tue, 10 Jan 2006 07:32:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwIff-0006CB-1D for ltru@megatron.ietf.org; Tue, 10 Jan 2006 07:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26845 for ; Tue, 10 Jan 2006 07:30:55 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwImL-0007G3-MI for ltru@ietf.org; Tue, 10 Jan 2006 07:39:11 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C627A2596FE; Tue, 10 Jan 2006 13:31:04 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15737-03; Tue, 10 Jan 2006 13:30:59 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A424259704; Tue, 10 Jan 2006 13:30:58 +0100 (CET) Date: Tue, 10 Jan 2006 13:31:57 +0100 From: Harald Tveit Alvestrand To: Mark Davis Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) Message-ID: <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> In-Reply-To: <43C31A0A.9000709@icu-project.org> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On mandag, januar 09, 2006 18:20:58 -0800 Mark Davis wrote: > But that is current practice for *lookup*, not for *filtering*. OK, I didn't catch that you were proposing this for filtering only. I continue to claim that making filtering behave inconsistently with lookup will be a decision we'll regret. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 10 10:31:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLSo-00007X-Fz; Tue, 10 Jan 2006 10:31:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLSm-000054-SH for ltru@megatron.ietf.org; Tue, 10 Jan 2006 10:31:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10349 for ; Tue, 10 Jan 2006 10:29:49 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLZU-0004eg-Rv for ltru@ietf.org; Tue, 10 Jan 2006 10:38:06 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EwLSb-0005My-1Q; Tue, 10 Jan 2006 07:30:57 -0800 Message-Id: <6.2.3.4.2.20060110145851.06108ad0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 10 Jan 2006 15:05:42 +0100 To: Harald Tveit Alvestrand , Mark Davis From: r&d afrac Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) In-Reply-To: <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 13:31 10/01/2006, Harald Tveit Alvestrand wrote: >--On mandag, januar 09, 2006 18:20:58 -0800 Mark Davis > wrote: > >>But that is current practice for *lookup*, not for *filtering*. >OK, I didn't catch that you were proposing this for filtering only. >I continue to claim that making filtering behave inconsistently with >lookup will be a decision we'll regret. Mark, I am interested in the impact on usages. Could you document your position? Harald's position seems more users' consistent. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 11 18:32:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpRg-0004hR-B4; Wed, 11 Jan 2006 18:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpRe-0004hM-Ja for ltru@megatron.ietf.org; Wed, 11 Jan 2006 18:31:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24171 for ; Wed, 11 Jan 2006 18:30:38 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwpYd-0004Oq-KY for ltru@ietf.org; Wed, 11 Jan 2006 18:39:12 -0500 Received: (qmail 43256 invoked from network); 11 Jan 2006 23:31:49 -0000 Received: from unknown (HELO ?9.52.67.110?) (unknown) by unknown with SMTP; 11 Jan 2006 23:31:49 -0000 X-pair-Authenticated: 129.42.184.35 Message-ID: <43C59564.90704@icu-project.org> Date: Wed, 11 Jan 2006 15:31:48 -0800 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> In-Reply-To: <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org They have to be "inconsistent"; they are different processes with very different goals. In one case you are filtering for any content that matches X; in the other case, you are looking for the closest match that is not more specific. They necessarily have different outcomes. Are there any other objections to the language additions I proposed, or can we accept them? Mark Harald Tveit Alvestrand wrote: > > > --On mandag, januar 09, 2006 18:20:58 -0800 Mark Davis > wrote: > >> But that is current practice for *lookup*, not for *filtering*. > > > OK, I didn't catch that you were proposing this for filtering only. > > I continue to claim that making filtering behave inconsistently with > lookup will be a decision we'll regret. > > Harald > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 12 02:53:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwxGj-0006Vc-68; Thu, 12 Jan 2006 02:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwxGg-0006VA-UN for ltru@megatron.ietf.org; Thu, 12 Jan 2006 02:53:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28964 for ; Thu, 12 Jan 2006 02:51:49 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwxNj-0003GK-Eo for ltru@ietf.org; Thu, 12 Jan 2006 03:00:29 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EwxGT-00030j-1C; Wed, 11 Jan 2006 23:52:57 -0800 Message-Id: <6.2.3.4.2.20060112074049.0619abf0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 12 Jan 2006 08:52:49 +0100 To: Mark Davis , Harald Tveit Alvestrand From: r&d afrac Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) In-Reply-To: <43C59564.90704@icu-project.org> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> <43C59564.90704@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 00:31 12/01/2006, Mark Davis wrote: >They have to be "inconsistent"; they are different processes with >very different goals. In one case you are filtering for any content >that matches X; in the other case, you are looking for the closest >match that is not more specific. They necessarily have different outcomes. In one case I want to be able to read a text, in the other I want to profile the author. Correct description? jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 12 08:22:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2PU-000497-3m; Thu, 12 Jan 2006 08:22:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2PS-000492-Bx for ltru@megatron.ietf.org; Thu, 12 Jan 2006 08:22:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17128 for ; Thu, 12 Jan 2006 08:21:13 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex2WX-0003ik-Ec for ltru@ietf.org; Thu, 12 Jan 2006 08:29:56 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8286D2596F7; Thu, 12 Jan 2006 14:21:20 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00775-06; Thu, 12 Jan 2006 14:21:16 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id B23BD2596F5; Thu, 12 Jan 2006 14:21:16 +0100 (CET) Date: Thu, 12 Jan 2006 14:22:17 +0100 From: Harald Tveit Alvestrand To: Mark Davis Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) Message-ID: <25322233A6B2F111100A1118@svartdal.hjemme.alvestrand.no> In-Reply-To: <43C59564.90704@icu-project.org> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> <43C59564.90704@icu-project.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On onsdag, januar 11, 2006 15:31:48 -0800 Mark Davis wrote: > They have to be "inconsistent"; they are different processes with very > different goals. In one case you are filtering for any content that > matches X; in the other case, you are looking for the closest match that > is not more specific. They necessarily have different outcomes. I'm not worried about the different outcomes (set versus single). I'm worried about the way the users will have to be trained differently if the proposals are as I understand them now. In one, we'll have to train the users to specify their requirements with as little specificity as possible, and train the content taggers to use as much specificity as possible. In the other, we have to train the users to overspecify their requirements, and train the content taggers to use the most general marking that does not overlap with another alternative. I fear the resulting confusion. My preferred solution is to specify "one way to do it" - that the result of a lookup is the same object as the most-preferred result of a ranked filtering, given the same list of input tags and the same list of tagged objects. > Are there any other objections to the language additions I proposed, or > can we accept them? I think the language is fine for what it wants to accomplish. I don't agree with what it wants to accomplish. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 12 09:34:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3Wx-0005Xp-8o; Thu, 12 Jan 2006 09:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3Wv-0005XZ-Um for ltru@megatron.ietf.org; Thu, 12 Jan 2006 09:34:22 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21274 for ; Thu, 12 Jan 2006 09:32:59 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ex3WU-0005C8-By for ltru@lists.ietf.org; Thu, 12 Jan 2006 15:33:54 +0100 Received: from 1cust155.tnt4.hbg2.deu.da.uu.net ([149.225.70.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jan 2006 15:33:54 +0100 Received: from nobody by 1cust155.tnt4.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jan 2006 15:33:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 Jan 2006 15:32:52 +0100 Organization: Lines: 17 Message-ID: <43C66894.CFB@xyzzy.claranet.de> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> <43C59564.90704@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust155.tnt4.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Status of matching draft? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > They have to be "inconsistent"; they are different processes > with very different goals. In one case you are filtering for > any content that matches X; in the other case, you are > looking for the closest match that is not more specific. They > necessarily have different outcomes. Thanks, that's something I hadn't seen so far. When I look for "de" and get a de-CH match, then I might miss de-CH-1996. With a filter I'd get both. The case "specified script is the Suppress-Script" is an exception, a filter should also return all documents without script subtag. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 12 09:48:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3kM-0001M3-8q; Thu, 12 Jan 2006 09:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3kL-0001Lx-GI for ltru@megatron.ietf.org; Thu, 12 Jan 2006 09:48:13 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22323 for ; Thu, 12 Jan 2006 09:46:51 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ex3k5-0000c4-0v for ltru@lists.ietf.org; Thu, 12 Jan 2006 15:47:57 +0100 Received: from 1cust155.tnt4.hbg2.deu.da.uu.net ([149.225.70.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jan 2006 15:47:56 +0100 Received: from nobody by 1cust155.tnt4.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jan 2006 15:47:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 12 Jan 2006 15:46:31 +0100 Organization: Lines: 19 Message-ID: <43C66BC7.21AE@xyzzy.claranet.de> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> <43C59564.90704@icu-project.org> <6.2.3.4.2.20060112074049.0619abf0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust155.tnt4.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Status of matching draft? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > In one case I want to be able to read a text, in the other > I want to profile the author. Correct description? The second case has many potential usages: Maybe you want to do some further processing, e.g. implement a MOT operator for ranges, or in the most simple case just select what you want manually. In my example "want de, and got de-CH" the second case would allow me to pick de-CH-1996 instead of de-CH if available. I could of course also ask for de-*-*-1996 when I know that I like 1996. But if I like 1996 only for de-CH and not de-DE it's clumsy to get this effect in the first "best match" case. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 12 11:04:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4wE-0005zy-C6; Thu, 12 Jan 2006 11:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4wD-0005zt-0d for ltru@megatron.ietf.org; Thu, 12 Jan 2006 11:04:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27315 for ; Thu, 12 Jan 2006 11:03:10 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex53L-0000BW-FZ for ltru@ietf.org; Thu, 12 Jan 2006 11:11:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Ex4w3-00057c-LZ; Thu, 12 Jan 2006 08:04:24 -0800 Message-Id: <6.2.3.4.2.20060112163453.042f55a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 12 Jan 2006 16:56:22 +0100 To: Harald Tveit Alvestrand , Mark Davis From: r&d afrac Subject: Re: [Ltru] Status of matching draft? (was: Re: weights in scored filtering) In-Reply-To: <25322233A6B2F111100A1118@svartdal.hjemme.alvestrand.no> References: <00ab01c61481$bbc19300$050aa8c0@DGBP7M81> <43C2E775.7000808@icu-project.org> <7C61C145B0F7569B420E675C@svartdal.hjemme.alvestrand.no> <43C31A0A.9000709@icu-project.org> <563BB90E8A76290506AE5A95@svartdal.hjemme.alvestrand.no> <43C59564.90704@icu-project.org> <25322233A6B2F111100A1118@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The result of such a practice may actually be worse that Harald says. Some may want to enter data to get the result of one approach when they suspect the other end follows the other approach. If you add retro-meta-spam (sending meta-data to profile the responses you get) the confusion may be total. I do not object this :-) ! But all I can say: this is a real life problem resulting from the adopted architectural layer violation of represented by the language tag concept, internationalisation and of the lack of security in RFC 3066 bis. What our two leaders document is that an author will be incited to write a text in Volapuk, to say it is in Ploutocratien, so it will be accepted by Australopitecan communities and come across the anti-spam filtering. The RFC 3066 Bis naming system has no other built-in security than trust. This point is in the text of the appeal under finalisation. But not as sophisticated as this. I need to update it now. If I am correct and read you, we are going to see people using their langtags to trick Google to add their texts in other language searches, like when you search for "failure". missa est. jfc At 14:22 12/01/2006, Harald Tveit Alvestrand wrote: >--On onsdag, januar 11, 2006 15:31:48 -0800 Mark Davis > wrote: > >>They have to be "inconsistent"; they are different processes with very >>different goals. In one case you are filtering for any content that >>matches X; in the other case, you are looking for the closest match that >>is not more specific. They necessarily have different outcomes. > >I'm not worried about the different outcomes (set versus single). >I'm worried about the way the users will have to be trained >differently if the proposals are as I understand them now. > >In one, we'll have to train the users to specify their requirements >with as little specificity as possible, and train the content >taggers to use as much specificity as possible. > >In the other, we have to train the users to overspecify their >requirements, and train the content taggers to use the most general >marking that does not overlap with another alternative. > >I fear the resulting confusion. > >My preferred solution is to specify "one way to do it" - that the >result of a lookup is the same object as the most-preferred result >of a ranked filtering, given the same list of input tags and the >same list of tagged objects. > >>Are there any other objections to the language additions I proposed, or >>can we accept them? > >I think the language is fine for what it wants to accomplish. I >don't agree with what it wants to accomplish. > > Harald > > > > >_______________________________________________ >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 Jan 15 19:19:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyI5i-00078D-Se; Sun, 15 Jan 2006 19:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyI5h-000785-Oq for ltru@megatron.ietf.org; Sun, 15 Jan 2006 19:19:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26513 for ; Sun, 15 Jan 2006 19:17:57 -0500 (EST) Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyIDT-00019T-1B for ltru@ietf.org; Sun, 15 Jan 2006 19:27:26 -0500 Received: from charger ([68.100.55.187]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060116001911.EFNN19943.eastrmmtao04.cox.net@charger> for ; Sun, 15 Jan 2006 19:19:11 -0500 From: "Scott Hollenbeck" To: Date: Sun, 15 Jan 2006 19:19:05 -0500 Message-ID: <002c01c61a32$7650eda0$0623520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYaEoWcnG8hmzsQTVywg5ALxgtlhAAH7ScA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Content-Transfer-Encoding: 7bit Subject: [Ltru] FW: appeal to the IESG against an IESG decision X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Since this concerns a document produced by the LTRU working group I believe it's something that should be shared here. Note that IESG decisions must be appealed to the IAB, not to the IESG. I'm sure that error will soon be corrected. -Scott- -----Original Message----- From: Jefsey Morfin [mailto:jefsey@online.fr] Sent: Saturday, January 14, 2006 9:05 AM To: iesg@iesg.org Subject: appeal to the IESG against an IESG decision Dear IESG Members, here is the announced appeal against the IESG decision concerning RFC 3066 Bis Draft of Novembre 15th, 2005. You will note that the Tunis agreement has changed the context of the IANA, IETF and of RFC 3066 Bis. This has permitted a more positive vision of this appeal. You will also find the PDF of this text at http://jefsey.com/appeal-3066b-iesg.pdf Sincerely yours. jfc morfin APPEAL TO THE IESG AGAINST AN IESG DECISION This is an appeal against the IESG decision to approve the RFC 3066 Bis Draft on November 15th, 2005. It documents the context of the appeal. It discusses the points raised against the IESG decision and also proposes solutions to suggest the WG-LTRU. 1. Context This part documents contextual or architectural points which this appeal does not raise. These may be raised if this appeal has to escalate to the IAB. These points help to understand the context of this appeal. 1.1. new challenges Languages are symbolic ways to convey information through different modes (spoken, written, signs). These are the protocols of human layers exchanges. These are parameterised by referents (what is accepted by all their speakers). These are used along various personal styles and in different contexts (what is accepted by all the participants to an exchange). Languages are currently under major evolutions: * *******documents have become computer assisted, with the emergence of "architexts" (smart source of the presented text), with new memorisation, presentation, multilingualisation approaches. * *******new human technologies may lead to different referents for a same language. A text may have consistent orthogonal readings depending on the trade of the readers of a same language. * *******languages are networked. They are used: * *******in polylogual multilocutors contexts documented by underlying or environmental meta-elements. * *******in multilingual and multicultural local competition. Symbolic ways are out of the scope of the IAB and IETF, but protocols over a network are in their scope. However, the mutual impact of protocols, symbolic ways, modes, styles, computer, trade, networking and cultural competition make the identification and the referencing of networked languages an issue of responsibility and of competence, with technical, societal, cultural, economical, political and vernacular usage implications wider than the scope of any existing SSDO. 1.2. globalization vs. harmonisation doctrines Globalization is understood by the IETF as internationalizing the network and localizing the end. The target is to remove the lingual barriers between a supplier and its foreign clients. The Internet, as agreed at the Tunis summit and documented in the reports of IAB and ICANN meetings on IDNs, is the internationalized US data network system. It empowers the American language, culture, economy, etc. The task now is to permit an equal empowerment opportunity to the other 96 % of the mankind. "What ever you can do in American, you MUST be able to do it, with the same comfort, in all other 20.000 languages listed in future ISO 639-6". It calls for a, most probably rewarding, new architecture. The architecture to address this challenge is multilingualisation. It can be a cross-globalization for every language; a universalised core and a personalisation of the ends; a multilateral architecture . In any case it should support the IETF US internationalization, possibly as a default if it permits. Multilingualisation will be a never ending process. It will have to keep pace with the changes in the human society, technology, and cultures. This constant harmonisation will probably be very complex. It will be a dramatic change, from the mono[lingual] Internet we are used to, to the multi[lingual] Internet we need. This evolution will not be limited to its basic requirement: brain to brain interintelligibility. 1.3. conditions of the debate I came to the IETF to offer RFC user QA over multilingual issues at the WG-IDNA. I found no interest in the users' needs. I found a lobby (leadership?) wanting to "influence" the ways the world "design, use and manage" the Internet (RFC 3935). Network hysteresis does not permit to disregard errors engaging usage. Experiences in naming and numbering have shown these may delay the network development for decades. Creating an opposing lobby was my first move. I quickly saw it would only be damaging to the IETF, a bigger waste of time and non productive. This is why I chose to give the necessary time to common sense to prevail, in exposing their mistakes in a way they could forced to correct some of them. The democratic method for that is work and filibustering. Filibustering is not pleasant. But it permitted to obtain what users' protection demanded: - to get the lobby discussed above to expose itself, and its (RFC 3869) commercial sponsors - to get done most of the work needed to clean the messy December 2004 version of the Draft. - to get this Draft approved only after the Tunis Summit made it a US local proposition. It did not permit yet to make it useful to users. This is the reason for this appeal. Work allowed me to build an alternative open solution. Not to be disruptive I need an IAB guidance on its introduction. I used the appeal mechanism against the aforesaid lobby to request it. I now wait for it. 1.4. purpose and context of the Draft The purpose of the WG-LTRU debate and (non-considered) charter is in fact to build an authoritative Language Name System (l call LNS for simplicity). This LNS is to be consistently used to name languages, locale files, lingual products, contents and services, etc. and even possible lingual TLDs. Yet, the WG-LTRU debate has shown the intent was not to build this LNS as the basic building block of the open Multilingual Internet, a Multilingual Internet the world calls for. It was to constrain its ABNF and to use its registry management to influence designers, users and managers (RFC 3935) towards an internationalized Internet along the Unicode consortium' vision. Forging such an exclusive, through the single IANA langtag registry, reminds the ICANN exclusive over the Domain Names registry. Network stability and good governance should then lead to an IETF/Unicode/IANA MoU over Language Names issues. It can either be taken as a commercial war declaration on cultures, or a decision to balkanise the Internet. 1.5. not documented resulting obligations RFC 3066 Bis was to welcome ISO languages and script names within the Internet standards. The Draft does not consider the extensions under way of these standards. It does not discuss what a structural analysis shows as a layer violations(wrong location of the Unicode table, taken as a super charset instead of a registry). The mere allusion to such a possibility was considered as . insulting. * *******ISO 639-4 and 6 may partly or totally obsolete RFC 3066 Bis. Long term JTC1/SG32./W2 efforts, ISO 639-6 and ISO 11179 conformance may lead to much more powerful propositions, giving a corrected RFC 3066 Bis its place in the global language information jigsaw. * *******We all need, and will obviously implement, an open compliance with ISO 11179 and with any other SSDO standard. WG-LTRU decided against ISO 11179 conformance, bridges and compatibility. * *******The support of the Unicode OS unification CLDR locale files project is one of the targets of the WG-LTRU. Its discussion was denied. It is promoted since the Draft has been approved. RFC 3066 Bis makes the IETF to support a unilateral US industry proposition. It imposes on the IETF (RFC 3935) competence and responsibilities demands which it cannot match. The IETF is now going: * *******either to manage a not yet considered, defined, organised and budgeted compilation, verification and dissemination system, eventually much larger than the DNS, in an area foreign to its engineering skills and legitimacy. * *******or to dismay the whole Internet community as it did for the IDNA, but on a much, much larger scale. Without a complete review of the undertaken responsibility and obligations, the first option is unrealistic. 2. Contested points The points documented in this part make the appeal against the IESG decision 2.1. non-documented management aspects The presented Draft does not document the expected usage of the langtag registry. Without any of the concerned linguistic, cultural and political authorities being involved, there are hundreds of languages now documented by a now started IANA registry. They should soon extend to a few tens of thousands. The architecture of this registry is not intended to link other registries. For example, every XML document may at some stage call for an updated direct or indirect access to the IANA langtag registry. Should every Internet user do it only once a year, it would mean more than 30 (average) 2 Meg file downloads a second. There will be a need of a large number of yearly updates, additions, changes (variants, new languages, changes in national structures, etc.), calling for much more user updates. * *******the current "ietf-languages @ alvestrand.no" registry management mailing list has handled 72 registry entries in ten years. * *******there is a reasonable expectation that developers, organisations, users, etc. start relying on the RFC 3066 Bis langtags and on its registry, and that this registry cannot scale and support their current or future legitimate extension expectations. * *******there is a reasonable expectation that traffic needing langtag information to proceed be blocked in an undetermined future, due to a beyond practical possibilities and lack of access to this information. This is not documented in the security considerations part. 2.2. Competition to the IANA The presented Draft does not want to consider alternatives solutions in naming and documenting languages. This creates a situation of competition between the IANA and other registries. No one has been accustomed to such a situation up to now. If such a competition (as it is likely from the current state of the art) find enough support and usage, this may lead to a balkanisation of the Internet where IANA compliant only systems would not be able to use common practice procedures partly supported by the IANA. (Due to the relative volume of data and related data the LNS may represent, it is likely that this will lead to switch of the users from the IANA to the LNS system). This is not documented in the security considerations part. 2.3. ABNF confusion confirmed by the IESG RFC 3066 Bis uses a very restrictive ABNF. This format uses one character or figure prefix, followed by a dash, to introduce one or several specialised subtags of 8 characters or figures. There is no initial prefix if the first subtag is a language code. Most of the 36 characters and figures are not currently assigned a meaning as a prefix. The "x-"prefix opens a private use area. I represented several times that external SSDOs and private users needed a larger space than 8 characters of figures. It has been repeatedly answered that users could use several 8 characters or figure strings to fully document what they wanted. "en-x-ietf2006-ustx7071" is a valid langtag. This format is dissuasive. Its documentation is confused. An example of progressive langtag abbreviation documented that it obeyed to the common rules. The AD, confirmed by the IESG, decided it was a typo, removing the only clarification on the private use format. Harald Alvestrand documented that this format is dangerous. There is no other way than walled gardens to prevent two groups of users to legitimately use the same strings with a different meaning. Everyone can imagine the dangers this may represent. This is not documented in the security considerations part. 2.4. non-documented dangerous types of utilisation The external observable major change from RFC 3066 to RFC 3066 Bis is a distinctive format. The WG-LTRU's Charter demanded it for "easily identifying the role of each subtag in the language tag, so that, for example, whenever a script code or country code is present in the tag it can be extracted, even without access to a current version of the registry". This leads to a dramatically easier use of IETF langtags in order to: * *******profile traffic for cultural, national, racial, religious evaluation * *******cultural, national, racial, religious searches in search engines * *******cultural, national, racial, religious relational "marking" in using retro-meta-spam: one interlocutor "marks" his traffic (web pages, mails, etc.) with langtags. The returning traffic designates the persons who were able to understand it. These persons ignored they were victims of a meta-spam. * *******filter national traffic for specific content, as against human rights or democratic behaviour In addition, it is to be noted that: * *******the information made public through langtags meta-spam on public mails and sites permits to collect information on private persons violating privacy laws of many countries. * *******this hidden privacy violation may endanger the business of search engines which may start offering information (ex.: please search Google for "ar-arab-us") which may be illegal in some countries. * *******this may become criminal activity in some civilised countries when that information concerns cultural, national, racial or religious information on the persons. * *******the documents such as RFC 3066 Bis which permits such a crime and incites Internet users to implement solutions permitting such a crime may be deemed criminal themselves in some countries as inciting to racial hatred. This engages the responsibility and the credibility of the IETF, in particular of its leaders and of the IESG. This would certainly be detrimental to the whole Internet. This is not documented in the security considerations part. 2.5. lack of verification No validation tool is associated to the RFC 3066 Bis langtag proposition. It is entirely based on trust with no security-associated feature. The langtag of a text can be untrue. There is no documented algorithm to permit verifications (for example the number of occurrence of " the " to confirm the claim of "en-" langtag. Actually, the debate on the further filtering document shows an opposition between its author and Harald Alvestrand over the encouragement to use the langtags not to document the text of the content, but to drive the filtering system. Such a practice will defeat the whole purpose of the described best "practice". This is not documented in the security considerations 3. suggested solutions This part documents the suggestions that IESG should give to the WG-LTRU to consider in order to tackle the issues raised above. 3.1. update of the security considerations The first proposition I can suggest is to rewrite the security considerations. This was denied to me by the WG-LTRU, when I started considering some of the points above. The current text is only a copy of the RFC 3066 considerations, as if the RFC 3066 Bis did not introduce any new risk. 3.2. management of the resulting obligations The unilateral centralisation of the IANA functions makes them a political/commercial target. It also confines the IANA to a limited number of issues. In addition, the RFC 3066 Bis now affirms the internationalization approach. The NTIA publicly confirms that the IANA could be sold to the private sector (names have been rumoured). This puts the IANA for the first time in (commercial) competition with the work engaged by other SSDOs or grassroots processes and their own clearing houses. I engaged such a process. I am here to represent the rights and interests of such endeavours which the WG-LTRU disregarded, as an IETF DoS. My DRS project (distributed registry system) is an extended and distributed approach of the IANA. A LNS (language name system) is mandatory to such a project. I will support RFC 3066 Bis langtags, among all the others system we may encounter. The multilateral management and distribution of an inclusive LNS proposition, in a way comparable to the DNS, is probably the only way to get a stable, open, flexible, democratic, and scalable solution. This is what the WG-LTRU should document. I am certainly not alone in considering such architecture. But I may be the only one desiring to maintain consistency with the IETF propositions. 3.3. equal lingual opportunity position I suggest the WG-LTRU should be asked to include in the Draft, the following equal lingual opportunity proposition. "The purpose of technology is not to ensure that everyone should have an equal opportunity regardless of his language, its purpose is to allow for this goal. "In its domain, this document wants to allow everyone to freely share the cultural life of the computer and Internet community, to enjoy using its solutions on an equal linguistic, cultural, technical, economical and commercial basis. It also aims to allow everyone to share into the benefits of the technology and its advancements without distinction of any kind - such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status and education. Therefore the goal is to build a common technical standard for all people and all nations to be used, or embedded in any technical solution, without any limitation resulting from the script, the language, the references or the context of its utilisation environment. "Taking into account the granular nature and the diversity of the world's digital ecosystem, as well as the requirements of its technical convergence, the authors of this technical memorandum strongly advocate its free, secure and stable implementation to serve the rights and freedoms of its users at a global, multinational, international, cultural and lingual, national, local, and personal level, in the respect of sovereign laws and jurisdiction of each State, of the empowerment of local cultures, and of its intergovernance by subsidiarity, in each of its government or private, community or individual application." 3.4. addressing the users need The concept of indicating the language attributes of texts in the documents themselves is a totally new concept, only permitted by the use of architexts through historically very young, blossoming and often non-compatible formats. RFC 3066 Bis (due to the importance of the Internet in content transport, access and archiving) wants to make this revolution in human practices simultaneously: * *******de facto mandatory and global * *******ruled by its sole ASCII ABNF and ISO selected lists. * *******documented by its sole IANA Unicode based and ruled registry. It also wants to make that change as a BCP (description of existing practices) while, * *******it did not consider its consequences in the legal, privacy, cultural, meta-spam, etc. areas. * *******it did not use other names than those selected by Unicode for leading mostly written languages. * *******it was not approved by any concerned legitimate cultural, societal and political representation. Should the US law not object its consequences; such a proposition can be standardised for the Tunis accepted internationalized US Internet. It could even be accepted as a working global default proposition for the convergence of the world digital ecosystem. But it MUST support other language naming systems which are able to replace it along with the evolution of the state of the arts, the user common practices, the legal obligations, the international agreements and the not yet considered security aspects. The diversity supported by the 'tag' URI scheme (RFC 4151) provides an off-the-shelves solution which matches these criteria. Some among all the naming information provided by the langtags can also be obtained from a URI (or IRI). There are three ways of using RFC 4151: * *******to use it as a replacement of RFC 3066 Bis. This would be a final balkanisation of the Internet. * *******to introduce a one-letter/figure+dash sequence as an escape sequence to RFC 4151. This however breaks the langtag concept and continuity. * *******to create a users RFC 4151 ABNF conformant space. It will be introduced by a figure+dash sequence (to be script transparent). Abbreviations of this space will obey RFC 3066 Bis rules. My proposition is "'0-'+RFC 4151 ABNF". Others may be devised. This proposition was disregarded by the WG-LTRU Chair. I was banned for supporting it. An appeal confirmed that odd position. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 16 09:51:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVhx-0002zc-L0; Mon, 16 Jan 2006 09:51:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVhx-0002zX-1F for ltru@megatron.ietf.org; Mon, 16 Jan 2006 09:51:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18024 for ; Mon, 16 Jan 2006 09:50:21 -0500 (EST) Received: from mta4.iomartmail.com ([62.128.193.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVps-0004ZS-0U for ltru@ietf.org; Mon, 16 Jan 2006 09:59:57 -0500 Received: from mta4.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta4.iomartmail.com (8.12.11/8.12.8) with ESMTP id k0GEp76O024265; Mon, 16 Jan 2006 14:51:07 GMT Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta4.iomartmail.com (8.12.11/8.12.8) with ESMTP id k0GEp5un024235; Mon, 16 Jan 2006 14:51:06 GMT From: "Debbie Garside" To: , Date: Mon, 16 Jan 2006 14:51:03 -0000 Message-ID: <044e01c61aac$46949ec0$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.2180 Thread-Index: AcYarEWM+hAFXWo0TH2hCjx4/zxPsQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Country Codes - Guernsey, Jersey and Isle of Man X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I noticed a reference to this in the past few weeks. I have received information today that the official request has now been received by the ISO 3166/MA and the codes will be transferred from the reserved list "very soon"! Sadly I cannot define "very soon"! Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 16 16:36:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyc1b-00035j-WE; Mon, 16 Jan 2006 16:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyc1a-00035P-F0 for ltru@megatron.ietf.org; Mon, 16 Jan 2006 16:36:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17634 for ; Mon, 16 Jan 2006 16:35:02 -0500 (EST) Received: from rly-ip01.mx.aol.com ([64.12.136.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyc9U-0004BS-JF for ltru@ietf.org; Mon, 16 Jan 2006 16:44:42 -0500 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip01.mx.aol.com (8.12.11/8.12.11) with ESMTP id k0GLZCbK008372; Mon, 16 Jan 2006 16:35:13 -0500 Received: from DEBHOME (ACCAC266.ipt.aol.com [172.202.194.102]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id k0GLZ5Sh010180; Mon, 16 Jan 2006 16:35:05 -0500 Message-Id: <200601162135.k0GLZ5Sh010180@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: , Subject: [Ltru] Country Codes - Guernsey, Jersey and Isle of Man Date: Mon, 16 Jan 2006 21:35:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYarEWM+hAFXWo0TH2hCjx4/zxPsQAODAhA X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I noticed a reference to this in the past few weeks. I have received information today that the official request has now been received by the ISO 3166/MA and the codes will be transferred from the Reserved list "very soon"! "Very soon" has been further defined to mean possibly end of January, certainly end of February. Regards Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 17 00:08:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyj53-0001lu-RT; Tue, 17 Jan 2006 00:08:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyj52-0001lm-HA for ltru@megatron.ietf.org; Tue, 17 Jan 2006 00:08:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15744 for ; Tue, 17 Jan 2006 00:07:04 -0500 (EST) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyjD5-0004y4-Nc for ltru@ietf.org; Tue, 17 Jan 2006 00:16:48 -0500 Received: from h-64-105-34-185.snvacaid.dynamic.covad.net ([64.105.34.185] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Eyj50-00073n-00 for ltru@ietf.org; Tue, 17 Jan 2006 00:08:26 -0500 Message-ID: <005401c61b24$1bd8bf40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Mon, 16 Jan 2006 21:08:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ltru] 65th IETF - ltru WG session? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - If you think there is a need for a session of the ltru WG at the 65th IETF meeting, please post your agenda proposals to this mailing list so we can determine whether there is sufficient need and support for a face-to-face meeting. The cut-off date for session requests is February 13, so please make any such proposals before February 10, 2006. Currently, I believe we have no reason to meet. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 18 08:19:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDE6-0002sD-Mh; Wed, 18 Jan 2006 08:19:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDE5-0002s4-NU for ltru@megatron.ietf.org; Wed, 18 Jan 2006 08:19:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11586 for ; Wed, 18 Jan 2006 08:18:23 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzDMQ-00018W-Ew for ltru@ietf.org; Wed, 18 Jan 2006 08:28:26 -0500 Received: from eupig1 (unverified [196.7.183.8]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 18 Jan 2006 13:19:28 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0ITA00J11ICGT0@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 18 Jan 2006 13:19:28 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Wed, 18 Jan 2006 13:19:27 +0000 Date: Wed, 18 Jan 2006 13:19:57 +0000 From: Misha Wolf To: LTRU Working Group 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: Language in XML Schema 1.1 Datatypes Thread-Index: AcYcMVMmKWVBXfNPSGSt3xwisx3EpAAABxhw Content-class: urn:content-classes:message X-OriginalArrivalTime: 18 Jan 2006 13:19:27.0767 (UTC) FILETIME=[CEF36270:01C61C31] X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Language in XML Schema 1.1 Datatypes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I've lost track of where we are in the debate re Standards track=20 etc. It is *very* important that we give guidance to other WGs=20 on how to refer to the otcome of our work. See, for example: http://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/#language Is that correct? Working Draft: XML Schema 1.1 Datatypes The XML Schema Working Group has released an updated Working Draft of "XML Schema 1.1 Part 2: Datatypes." XML schemas define shared markup vocabularies, the structure of XML documents which use those vocabularies, and provide hooks to associate semantics with them. With XML Schema Part 2, datatypes may be defined for use in XML schemas as well as other contexts. Visit the XML home page. http://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/ http://www.w3.org/XML/ Misha 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 Jan 18 10:44:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFTm-0000JB-Ji; Wed, 18 Jan 2006 10:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFTk-0000J0-61 for ltru@megatron.ietf.org; Wed, 18 Jan 2006 10:44:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27202 for ; Wed, 18 Jan 2006 10:42:41 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzFc4-00076F-6S for ltru@ietf.org; Wed, 18 Jan 2006 10:52:46 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68AD22596F4; Wed, 18 Jan 2006 16:42:51 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01732-02; Wed, 18 Jan 2006 16:42:46 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id A85B22596F2; Wed, 18 Jan 2006 16:42:46 +0100 (CET) Date: Wed, 18 Jan 2006 16:43:51 +0100 From: Harald Tveit Alvestrand To: LTRU Working Group , ietf-languages@iana.org Message-ID: <81CA8AEFCB2AC0B41D493C13@svartdal.hjemme.alvestrand.no> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin (fwd) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org FYI. ---------- Forwarded Message ---------- Date: onsdag, januar 18, 2006 07:34:41 -0500 From: Scott Hollenbeck To: ietf@ietf.org, ietf-announce@ietf.org Cc: iesg@ietf.org Subject: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin The IESG has received a request from Harald Alvestrand to approve an RFC 3683 PR-action ("posting rights" action) for JFC (Jefsey) Morfin as a result of a pattern of prior warning and posting rights suspensions for off-topic postings to the LTRU working group and ietf-languages mailing lists that have not produced a change in behavior. This behavior has been characterized as a "denial-of-service" attack to disrupt the consensus-driven process as described in Section 1 of RFC 3683. A timeline of warnings and posting rights suspensions related to this request is included below. The IESG will consider this request. If approved, the PR-action described in Section 2 of RFC 3683 includes provisions to allow list administrators to suspend Mr. Morfin's posting rights to the LTRU working group and ietf-languages mailing list for at least one year. Maintainers of other IETF mailing lists may also remove posting rights to their mailing lists at their discretion. 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 17 February 2006. For the IESG, Scott Hollenbeck Applications Area Director -------------------------- Private warnings sent for LTRU working group mailing list postings: 7 July 2005 16 July 2005 23 September 2005 26 October 2005 Public warnings and suspensions for LTRU working group and ietf-languages mailing list postings: 17 March 2005 (ietf-languages warning) http://www.alvestrand.no/pipermail/ietf-languages/2005-March/003236.html 5 April 2005 (LTRU warning) http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html 12 May 2005 (LTRU suspension) http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html 26 May 2005 (LTRU warning) http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html (Used as basis for 4 July suspension.) 15 June 2005 (ietf-languages suspension) http://www.alvestrand.no/pipermail/ietf-languages/2005-June/003474.html 4 July 2005 (LTRU suspension) http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html (Appealed to AD, appeal upheld, new warning given.) 5 July 2005 (LTRU warning) http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html 15 September 2005 (ietf-languages suspension) http://www.alvestrand.no/pipermail/ietf-languages/2005-September/003585.html 26 September 2005 (LTRU warning) http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html 7 October 2005 PR-Action request sent to IESG http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html 15 October 2005 (LTRU warning) http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html 8 November 2005 (LTRU suspension) http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html (Appealed to AD, appeal denied by AD.) 20 November 2005 (ietf-languages suspension) http://www.alvestrand.no/pipermail/ietf-languages/2005-November/003811.html (Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.) 13 January 2006 (ietf-languages suspension) http://www.alvestrand.no/pipermail/ietf-languages/2006-January/003854.html _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ---------- End Forwarded Message ---------- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 18 11:53:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGYi-0002Ds-KK; Wed, 18 Jan 2006 11:53:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGYf-0002C3-6A for ltru@megatron.ietf.org; Wed, 18 Jan 2006 11:53:19 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03360 for ; Wed, 18 Jan 2006 11:51:51 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EzGWQ-0003Pt-4A for ltru@lists.ietf.org; Wed, 18 Jan 2006 17:50:59 +0100 Received: from 1cust44.tnt5.hbg2.deu.da.uu.net ([149.225.16.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Jan 2006 17:50:58 +0100 Received: from nobody by 1cust44.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Jan 2006 17:50:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 18 Jan 2006 17:47:07 +0100 Organization: Lines: 14 Message-ID: <43CE710B.6F23@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust44.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language in XML Schema 1.1 Datatypes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Misha Wolf wrote: > http://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/#language About 1 MB, sigh. > Is that correct? It's the general 3066 syntax, which is a superset of the more elaborated 3066bis syntax. Ignoring all details for certain kinds of subtags it's still fine for all 3066bis language tags. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 18 12:09:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGoR-0004G0-Ag; Wed, 18 Jan 2006 12:09:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGoP-0004FZ-8o for ltru@megatron.ietf.org; Wed, 18 Jan 2006 12:09:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04370 for ; Wed, 18 Jan 2006 12:08:08 -0500 (EST) 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 1EzGwk-0001gb-Vt for ltru@ietf.org; Wed, 18 Jan 2006 12:18:12 -0500 Received: from uknsprd1 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 18 Jan 2006 17:09:20 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0ITA00B1KSZJVF@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 18 Jan 2006 17:09:19 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 18 Jan 2006 17:08:18 +0000 Date: Wed, 18 Jan 2006 17:09:49 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes To: ltru@ietf.org 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] Re: Language in XML Schema 1.1 Datatypes Thread-Index: AcYcUIYRyInVXuN5TbyqGSXKWExlzgAASgTQ Content-class: urn:content-classes:message X-OriginalArrivalTime: 18 Jan 2006 17:08:19.0103 (UTC) FILETIME=[C776FAF0:01C61C51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org What I was referring to is the text: [Definition:] language represents formal natural language=20 identifiers, as defined by [RFC 3066]or its successor(s) in the=20 IETF Standards Track. Is that correct? =20 Misha -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Frank Ellermann Sent: 18 January 2006 16:47 To: ltru@ietf.org Subject: [Ltru] Re: Language in XML Schema 1.1 Datatypes Misha Wolf wrote: > http://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/#language About 1 MB, sigh. > Is that correct? It's the general 3066 syntax, which is a superset of the more elaborated 3066bis syntax. Ignoring all details for certain kinds of subtags it's still fine for all 3066bis language tags. Bye, Frank 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 Jan 18 15:43:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK9S-0001Xh-O7; Wed, 18 Jan 2006 15:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK9S-0001Xc-AA for ltru@megatron.ietf.org; Wed, 18 Jan 2006 15:43:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21896 for ; Wed, 18 Jan 2006 15:42:03 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKHq-0000mr-5c for ltru@ietf.org; Wed, 18 Jan 2006 15:52:11 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1EzK9N-0007uT-4F; Wed, 18 Jan 2006 15:43:25 -0500 Date: Wed, 18 Jan 2006 15:43:25 -0500 To: Misha Wolf Subject: Re: [Ltru] Re: Language in XML Schema 1.1 Datatypes Message-ID: <20060118204324.GA29460@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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Misha Wolf scripsit: > [Definition:] language represents formal natural language > identifiers, as defined by [RFC 3066]or its successor(s) in the > IETF Standards Track. Technically, no. But the intent is clear enough. I myself introduced this "standards track" language into the XML Recommendation (from which this language is taken) when I didn't understand the IETF process that well. I think, however, that it is of no real importance; whatever the official status, in practice 1766 > 3066 > 3066bis. What troubles me more is that the draft says that the WXS datatype "language" is case-sensitive, and says that it's up to applications to provide case sensitivity. It seems that this is the result of a misunderstanding: mn is one thing (language subtag) and MN is another (country subtag), but of course "MN" as a tag means the same as "mn", since country subtags cannot appear in initial position. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a cowan@ccil.org great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame. --"The Pyre of Denethor" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 19 06:15:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXlP-0000Me-TG; Thu, 19 Jan 2006 06:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXlN-0000MP-OM for ltru@megatron.ietf.org; Thu, 19 Jan 2006 06:15:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12368 for ; Thu, 19 Jan 2006 06:14:06 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzXtr-0002st-Uh for ltru@ietf.org; Thu, 19 Jan 2006 06:24:22 -0500 Received: from uknsprd1 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Thu, 19 Jan 2006 11:15:15 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0ITC00D3W79FU0@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 19 Jan 2006 11:15:15 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 19 Jan 2006 11:15:15 +0000 Date: Thu, 19 Jan 2006 11:15:44 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes To: ltru@ietf.org 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] Re: Language in XML Schema 1.1 Datatypes Thread-Index: AcYcb9aPiOSHtQK8T8W5ZMLFq27OaAAeaF7g Content-class: urn:content-classes:message X-OriginalArrivalTime: 19 Jan 2006 11:15:15.0192 (UTC) FILETIME=[9F486F80:01C61CE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org So should we be responding re case-sensitivity? And as the boilerplate text will keep appearing in W3C=20 specs, should we tweak it? Misha -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: 18 January 2006 20:43 To: Misha Wolf Cc: ltru@ietf.org Subject: Re: [Ltru] Re: Language in XML Schema 1.1 Datatypes Misha Wolf scripsit: > [Definition:] language represents formal natural language=20 > identifiers, as defined by [RFC 3066]or its successor(s) in the=20 > IETF Standards Track. Technically, no. But the intent is clear enough. I myself introduced this "standards track" language into the XML Recommendation (from which this language is taken) when I didn't understand the IETF process that well. I think, however, that it is of no real importance; whatever the official status, in practice 1766 > 3066 > 3066bis. What troubles me more is that the draft says that the WXS datatype "language" is case-sensitive, and says that it's up to applications to provide case sensitivity. It seems that this is the result of a misunderstanding: mn is one thing (language subtag) and MN is another (country subtag), but of course "MN" as a tag means the same as "mn", since country subtags cannot appear in initial position. --=20 And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a cowan@ccil.org great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame. --"The Pyre of Denethor" 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 Thu Jan 19 07:05:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYYA-0007pG-4t; Thu, 19 Jan 2006 07:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYY8-0007p6-Oq for ltru@megatron.ietf.org; Thu, 19 Jan 2006 07:05:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15490 for ; Thu, 19 Jan 2006 07:04:30 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzYgd-0004Jz-Kj for ltru@ietf.org; Thu, 19 Jan 2006 07:14:45 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F5A72596F9; Thu, 19 Jan 2006 13:04:34 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04900-01; Thu, 19 Jan 2006 13:04:30 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC0722596C0; Thu, 19 Jan 2006 13:04:30 +0100 (CET) Date: Thu, 19 Jan 2006 13:05:38 +0100 From: Harald Tveit Alvestrand To: Misha Wolf , ltru@ietf.org Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On torsdag, januar 19, 2006 11:15:44 +0000 Misha Wolf wrote: > So should we be responding re case-sensitivity? I read the boilerplate spec as saying "IETF says this is case insensitive, but XML doesn't have a mechanism to formally declare an attribute value case insensitive, so you have to do this at the application level". If that's so, there's not that much we can do to improve it. XML experts will surely contradict me if I misunderstood.... > And as the boilerplate text will keep appearing in W3C > specs, should we tweak it? no opinion.... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 19 21:46:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmHp-0001s7-Ve; Thu, 19 Jan 2006 21:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmHo-0001s2-BG for ltru@megatron.ietf.org; Thu, 19 Jan 2006 21:46:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25716 for ; Thu, 19 Jan 2006 21:44:33 -0500 (EST) Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmQR-0000Na-Sm for ltru@ietf.org; Thu, 19 Jan 2006 21:54:57 -0500 Received: from charger ([68.100.55.187]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060120024552.GSPA19943.eastrmmtao04.cox.net@charger>; Thu, 19 Jan 2006 21:45:52 -0500 From: "Scott Hollenbeck" To: , Date: Thu, 19 Jan 2006 21:45:49 -0500 Message-ID: <000e01c61d6b$9f3eb170$0623520a@charger> 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.2670 Thread-Index: AcYdXWwic2ewEdnATuKkK5AeCISlgwADb2Bw X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org List members who are not on the IETF list will miss this. You may wish to read and reply to Sam's questions. If you do reply, please send your reply to ietf@ietf.org and/or iesg@ietf.org. -Scott- -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Thursday, January 19, 2006 8:04 PM To: Scott Hollenbeck Cc: ietf@ietf.org; iesg@ietf.org Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin Hi. I agree that Jefsey's participation in LTRU and the ietf-languages lists has been problematic. Even by his own admission Jefsey has been engaging in filibustering--a practice that I think we would agree is disruptive. Take a look at his most recent appeal to the IESG (http://www.ietf.org/IESG/APPEALS/jefsey-morfin-appeal.txt ); quoting from that appeal: This is why I chose to give the necessary time to common sense to prevail, in exposing their mistakes in a way they could forced to correct some of them. The democratic method for that is work and filibustering. Filibustering is not pleasant. But it permitted to obtain what users' protection demanded: As such, I agree that we need to adopt a strategy that prevents Jefsey from disrupting our processes excessively. However a PR action is an incredibly huge hammer. If passed, it removes any process barrier to shutting Jefsey out of any IETF process. While this PR action is specifically targeted at the ietf-languages list it would give the person running any IETF list the ability to unilaterally remove Jefsey from that list. Perhaps this is an appropriate measure to take when all of a person's participation are destructive and they have nothing to offer. That's not true for Jefsey. Jefsy has made significant positive contributions to the IETF list. He has worked to describe the perceptions that the IETF, IANA, ICAN, and related entities are creating a US-centric Internet. He has described concerns of global users and how our protocols, including IDN, may not meet user requirements. These concerns are real and parts of them have been worked on by long-standing members of the community. Take a look at RFC 4185 for an example of a concern that Jefsey shares that members of this organization have spent time working on. I personally have found Jefsey's formulations of these concerns enlightening; I think he has significantly helped me understand how the IETF might be perceived and what some user concerns with our protocol might be. I've also found some of his security comments and some of his comments on IETF process issues useful. So, I think it would be inappropriate to apply this hammer in this case. Instead, I propose that we find a tool appropriate for the problem: a way of limiting Jefsey's ability to block progress in areas where he is clearly blocking our work but not preventing him from participating in the IETF. I'd first ask why repeated 30-day suspensions are ineffective. Harald seems to be getting fairly efficient at suspending Jefsey on ietf-languages. I believe he's been suspended on LTRU before. Is Jefsey actually doing much damage there with all these suspensions? If so, why not give Harald and the LTRU chairs the ability to suspend Jefsey for longer? That might involve a new BCP (or a process experiment), but if we determine the existing tools are inadequate then that seems like a reasonable option. How would a six month suspension be insufficient? Do we really need an unlimited suspension to get work done? Finally, if we somehow all convince ourselves that asking chairs to revisit suspending Jefsey every six months is unacceptable then what about creating way to suspend Jefsey from langtags related issues but not other IETF lists? Sure, Jefsey is annoying on the ietf list, but is he really so much worse than me ranting about fairness and openness, Keith ranting about architecture or Dave Crocker ranting about timely standards development that we cannot have a place for him? Speaking as an individual, if I had to pick conversations to have un-had on the IETF list, there are ones higher on my list than Jefsey. Thanks for your consideration, --Sam _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 23 00:51:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ubc-0005XA-L0; Mon, 23 Jan 2006 00:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0uba-0005X2-FA for ltru@megatron.ietf.org; Mon, 23 Jan 2006 00:51:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18102 for ; Mon, 23 Jan 2006 00:49:36 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0ukr-0000w9-6p for ltru@ietf.org; Mon, 23 Jan 2006 01:00:42 -0500 Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k0N5omd06008; Mon, 23 Jan 2006 14:50:48 +0900 (JST) Received: from (133.2.210.1) by scmse3.scbb.aoyama.ac.jp via smtp id 495d_33fe2a58_8bd4_11da_902b_00304824d3bc; Mon, 23 Jan 2006 14:50:47 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k0N5mmaL026126; Mon, 23 Jan 2006 14:50:11 +0900 Message-Id: <6.0.0.20.2.20060122184057.07f02ca0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 22 Jan 2006 18:43:19 +0900 To: Harald Tveit Alvestrand , Misha Wolf , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 21:05 06/01/19, Harald Tveit Alvestrand wrote: > > >--On torsdag, januar 19, 2006 11:15:44 +0000 Misha Wolf wrote: > >> So should we be responding re case-sensitivity? > >I read the boilerplate spec as saying "IETF says this is case insensitive, but XML doesn't have a mechanism to formally declare an attribute value case insensitive, Correct. >so you have to do this at the application level". If that's so, there's not that much we can do to improve it. Well, we are talking about XML Schema, not XML. XML Schema has something called a post-validation infoset, a formal description of the result of the validation with XML Schema. We could ask that the XML Schema WG defines that the case-normalized (we would have to say how exactly normalized) value of a language tag is available somehow in the post-validation infoset. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 23 09:13:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Ro-00081s-P2; Mon, 23 Jan 2006 09:13:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Ro-00081g-24 for ltru@megatron.ietf.org; Mon, 23 Jan 2006 09:13:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22259 for ; Mon, 23 Jan 2006 09:12:01 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12b9-0007RF-AG for ltru@ietf.org; Mon, 23 Jan 2006 09:23:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA0E42596EC; Mon, 23 Jan 2006 15:12:10 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12959-06; Mon, 23 Jan 2006 15:12:07 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 954982596E1; Mon, 23 Jan 2006 15:12:05 +0100 (CET) Date: Mon, 23 Jan 2006 06:09:28 -0800 From: Harald Tveit Alvestrand To: Martin Duerst , Misha Wolf , ltru@ietf.org Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes Message-ID: <736CE9A622AB25F5362E381F@B50854F0A9192E8EC6CDA126> In-Reply-To: <6.0.0.20.2.20060122184057.07f02ca0@localhost> References: <6.0.0.20.2.20060122184057.07f02ca0@localhost> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1483007768==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1483007768== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========EE8E8207246A58BEA0DD==========" --==========EE8E8207246A58BEA0DD========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 22. januar 2006 18:43 +0900 Martin Duerst =20 wrote: > >so you have to do this at the application level". If that's so, there's > not that much we can do to improve it. > > Well, we are talking about XML Schema, not XML. XML Schema has > something called a post-validation infoset, a formal description > of the result of the validation with XML Schema. We could ask > that the XML Schema WG defines that the case-normalized > (we would have to say how exactly normalized) value of a > language tag is available somehow in the post-validation infoset. It's probably too much effort to ask that it be 639-cased (en-EN), so=20 having a lowercase variant available in the post-validation dataset would=20 suit me. --==========EE8E8207246A58BEA0DD========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD1OOZOMj+2+WY0F4RAoOTAJ9A+b+Ns/AnlzrZt/YQm29MlbazEACfcAbz w7acYXoUjMbl0rLCecMlE7g= =5Cql -----END PGP SIGNATURE----- --==========EE8E8207246A58BEA0DD==========-- --===============1483007768== 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 --===============1483007768==-- From ltru-bounces@ietf.org Mon Jan 23 09:30:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12ie-00046B-JC; Mon, 23 Jan 2006 09:30:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12ic-00045E-KX for ltru@megatron.ietf.org; Mon, 23 Jan 2006 09:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22910 for ; Mon, 23 Jan 2006 09:29:21 -0500 (EST) 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 1F12jF-0007jh-SJ for ltru@ietf.org; Mon, 23 Jan 2006 09:31:35 -0500 Received: from eupig1 (unverified [196.7.183.8]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Mon, 23 Jan 2006 14:21:26 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0ITJ0091DUJQM4@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 23 Jan 2006 14:21:26 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 23 Jan 2006 14:21:21 +0000 Date: Mon, 23 Jan 2006 14:21:54 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes To: ltru@ietf.org 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] Re: Language in XML Schema 1.1 Datatypes Thread-Index: AcYgJy8D+yopB7duQqi6Xm29tCB68AAADv5Q Content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Jan 2006 14:21:21.0273 (UTC) FILETIME=[48702E90:01C62028] X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Harald wrote: > It's probably too much effort to ask that it be 639-cased (en-EN),=20 > so having a lowercase variant available in the post-validation=20 > dataset would suit me. s/dataset/infoset If we conclude that we want to request a specific change, someone=20 will need to take an action to make the request. I imagine that=20 Martin would be the best person to do so. In my earlier mail(s), I was asking about the text: | [Definition:] language represents formal natural language=20 | identifiers, as defined by [RFC 3066]or its successor(s) in the=20 | IETF Standards Track. *That* text is what I meant by the phrase "boilerplate". Are we=20 happy with that text getting propagated? Or would we prefer a=20 reference to BCP 47? Or is there yet some other option? Misha 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 Mon Jan 23 09:31:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12is-0004Fg-1Q; Mon, 23 Jan 2006 09:31:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12ip-0004Da-EI for ltru@megatron.ietf.org; Mon, 23 Jan 2006 09:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23052 for ; Mon, 23 Jan 2006 09:29:35 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12e2-0007Xn-Ao for ltru@ietf.org; Mon, 23 Jan 2006 09:26:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 51CF9460F; Mon, 23 Jan 2006 23:15:57 +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 18543-08; Mon, 23 Jan 2006 23:15:57 +0900 (JST) Received: from ibm-60d333fc0ec (p2031-ipad67marunouchi.tokyo.ocn.ne.jp [220.96.24.31]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 023B943D2; Mon, 23 Jan 2006 23:15:56 +0900 (JST) Date: Mon, 23 Jan 2006 23:15:54 +0900 To: "Martin Duerst" , "Harald Tveit Alvestrand" , "Misha Wolf" , ltru@ietf.org Subject: Re: [Ltru] Re: Language in XML Schema 1.1 Datatypes References: <6.0.0.20.2.20060122184057.07f02ca0@localhost> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: <6.0.0.20.2.20060122184057.07f02ca0@localhost> User-Agent: Opera M2/8.5 (Win32, build 7702) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Sun, 22 Jan 2006 18:43:19 +0900, Martin Duerst =20 wrote: > At 21:05 06/01/19, Harald Tveit Alvestrand wrote: > > > > > >--On torsdag, januar 19, 2006 11:15:44 +0000 Misha Wolf =20 > wrote: > > > >> So should we be responding re case-sensitivity? > > > >I read the boilerplate spec as saying "IETF says this is case =20 > insensitive, but XML doesn't have a mechanism to formally declare an =20 > attribute value case insensitive, > > Correct. > > >so you have to do this at the application level". If that's so, =20 > there's not that much we can do to improve it. > > Well, we are talking about XML Schema, not XML. XML Schema has > something called a post-validation infoset, a formal description > of the result of the validation with XML Schema. We could ask > that the XML Schema WG defines that the case-normalized > (we would have to say how exactly normalized) value of a > language tag is available somehow in the post-validation infoset. I am wondering whether this concerns only the infoset. I could imagine to= =20 define a data type with RELAX NG, which is "case normalized". RELAX NG =20 uses the XML Schema datatypes, but does not create an post-validation =20 infoset. Regards, Felix. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 23 10:47:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ui-00013P-KG; Mon, 23 Jan 2006 10:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ug-00011k-Es for ltru@megatron.ietf.org; Mon, 23 Jan 2006 10:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28842 for ; Mon, 23 Jan 2006 10:45:57 -0500 (EST) Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1442-0002gj-KL for ltru@ietf.org; Mon, 23 Jan 2006 10:57:08 -0500 Received: from duringpersonlx (snvvpn-10-72-66-c11.corp.yahoo.com [10.72.66.11]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k0NFjLPJ033805; Mon, 23 Jan 2006 07:45:21 -0800 (PST) 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=mBfZAixpjdrfPscJdy2plIumpbczHrcc3FvdoY5pM0APISqXuLlquSRE/rQMolGH From: "Addison Phillips" To: "'Misha Wolf'" Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes Date: Mon, 23 Jan 2006 07:47:04 -0800 Message-ID: <000c01c62034$426129d0$05000100@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.2670 Thread-Index: AcYgJy8D+yopB7duQqi6Xm29tCB68AAADv5QAAMHFvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hello Misha, Reference BCP 47. That's what I believe the TAG eventually decided. I know it is what some specs are starting to use. For example, SVG 1.2 Tiny contains this reference: -- [BCP 47] IETF BCP 47, currently represented by RFC 3066 "Tags for the Identification of Languages", H. Alvestrand, January 2001 Available at http://www.ietf.org/rfc/rfc3066.txt. -- I like that boilerplate formulation a lot. Addison Addison Phillips Globalization Architect Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Misha Wolf > Sent: Monday, January 23, 2006 6:22 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes > > Harald wrote: > > > It's probably too much effort to ask that it be 639-cased (en-EN), > > so having a lowercase variant available in the post-validation > > dataset would suit me. > > s/dataset/infoset > > If we conclude that we want to request a specific change, someone > will need to take an action to make the request. I imagine that > Martin would be the best person to do so. > > In my earlier mail(s), I was asking about the text: > > | [Definition:] language represents formal natural language > | identifiers, as defined by [RFC 3066]or its successor(s) in the > | IETF Standards Track. > > *That* text is what I meant by the phrase "boilerplate". Are we > happy with that text getting propagated? Or would we prefer a > reference to BCP 47? Or is there yet some other option? > > Misha > > > 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 Mon Jan 23 11:08:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14F1-0006MK-H4; Mon, 23 Jan 2006 11:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14F0-0006L6-5G for ltru@megatron.ietf.org; Mon, 23 Jan 2006 11:08:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29885 for ; Mon, 23 Jan 2006 11:06:57 -0500 (EST) 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 1F14OK-0003In-Cn for ltru@ietf.org; Mon, 23 Jan 2006 11:18:07 -0500 Received: from eupig1 (unverified [196.7.183.8]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Mon, 23 Jan 2006 16:08:07 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0ITJ00F4YZHJN6@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 23 Jan 2006 16:08:07 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 23 Jan 2006 16:08:07 +0000 Date: Mon, 23 Jan 2006 16:08:36 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes To: ltru@ietf.org 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] Re: Language in XML Schema 1.1 Datatypes Thread-Index: AcYgJy8D+yopB7duQqi6Xm29tCB68AAADv5QAAMHFvAAAN5VIA== Content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Jan 2006 16:08:07.0617 (UTC) FILETIME=[32EAB310:01C62037] X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Looks good to me. Thanks. Now we need a volunteer to propose it to the XML Schema WG. Misha =20 -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com]=20 Sent: 23 January 2006 15:47 To: Misha Wolf Cc: ltru@ietf.org Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes Hello Misha, Reference BCP 47. That's what I believe the TAG eventually decided. I know it is what some specs are starting to use. For example, SVG 1.2 Tiny contains this reference: -- [BCP 47] IETF BCP 47, currently represented by RFC 3066 "Tags for the Identification of Languages", H. Alvestrand, January 2001 Available at http://www.ietf.org/rfc/rfc3066.txt. -- I like that boilerplate formulation a lot. Addison 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 Mon Jan 23 11:16:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14NB-0008Df-JM; Mon, 23 Jan 2006 11:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14N9-0008Da-ME for ltru@megatron.ietf.org; Mon, 23 Jan 2006 11:16:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB00197 for ; Mon, 23 Jan 2006 11:15:22 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14WW-0003W0-9P for ltru@ietf.org; Mon, 23 Jan 2006 11:26:33 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1F14Mz-0008Hf-1I; Mon, 23 Jan 2006 11:16:41 -0500 Date: Mon, 23 Jan 2006 11:16:41 -0500 To: Felix Sasaki Subject: Re: [Ltru] Re: Language in XML Schema 1.1 Datatypes Message-ID: <20060123161640.GB28609@ccil.org> References: <6.0.0.20.2.20060122184057.07f02ca0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org, Misha Wolf X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Felix Sasaki scripsit: > I am wondering whether this concerns only the infoset. I could imagine to > define a data type with RELAX NG, which is "case normalized". RELAX NG > uses the XML Schema datatypes, but does not create an post-validation > infoset. This made me realize what the real problem is with XML Schema as currently designed. Imagine a schema for papers to be published by a certain agency or conference that has multiple working languages. It might be reasonable for the root element of such documents to have a required xml:lang attribute whose value represents, say, English, French, or Russian. In XML Schema or RELAX NG, one would therefore specify this attribute as of type "language" and having possible values "en", "fr", and "ru". Unfortunately, a document with an xml:lang value of "EN" would not pass validation, even though BCP 47 defines "en" and "EN" as synonymous. It gets even worse with longer language tags. This is unfortunate and should be fixed. -- John Cowan cowan@ccil.org www.reutershealth.com www.ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 23 21:34:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1E0h-0004SY-51; Mon, 23 Jan 2006 21:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1E0g-0004ST-9V for ltru@megatron.ietf.org; Mon, 23 Jan 2006 21:34:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26927 for ; Mon, 23 Jan 2006 21:32:47 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1EA6-0004Va-1C for ltru@ietf.org; Mon, 23 Jan 2006 21:44:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7D808460F; Tue, 24 Jan 2006 11:33:48 +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 26670-16; Tue, 24 Jan 2006 11:33:48 +0900 (JST) Received: from ibm-60d333fc0ec.mag.keio.ac.jp (dhcp-246-65.mag.keio.ac.jp [133.27.246.65]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 30BCE4391; Tue, 24 Jan 2006 11:33:48 +0900 (JST) Date: Tue, 24 Jan 2006 11:33:42 +0900 To: "Misha Wolf" , ltru@ietf.org Subject: Re: [Ltru] Re: Language in XML Schema 1.1 Datatypes References: From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.5 (Win32, build 7702) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Tue, 24 Jan 2006 01:08:36 +0900, Misha Wolf =20 wrote: > Looks good to me. Thanks. > > Now we need a volunteer to propose it to the XML Schema WG. I can (and will) do that. As Addison knows, that is part of my job :) Felix > > Misha > > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 23 January 2006 15:47 > To: Misha Wolf > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Language in XML Schema 1.1 Datatypes > > Hello Misha, > > Reference BCP 47. That's what I believe the TAG eventually decided. I > know > it is what some specs are starting to use. For example, SVG 1.2 Tiny > contains this reference: > > -- > [BCP 47] > IETF BCP 47, currently represented by RFC 3066 "Tags for the > Identification of Languages", H. Alvestrand, January 2001 > Available at http://www.ietf.org/rfc/rfc3066.txt. > -- > > I like that boilerplate formulation a lot. > > Addison > > > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender,= =20 > except where the sender specifically states them to be the views of =20 > 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 Tue Jan 24 00:51:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H5h-00054J-Oe; Tue, 24 Jan 2006 00:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H5g-00054B-Eh for ltru@megatron.ietf.org; Tue, 24 Jan 2006 00:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09497 for ; Tue, 24 Jan 2006 00:50:10 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1HF7-0002b1-9E for ltru@ietf.org; Tue, 24 Jan 2006 01:01:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id C019A4451 for ; Tue, 24 Jan 2006 14:51:10 +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 28162-20 for ; Tue, 24 Jan 2006 14:51:10 +0900 (JST) Received: from ibm-60d333fc0ec.mag.keio.ac.jp (dhcp-246-65.mag.keio.ac.jp [133.27.246.65]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 897B34391 for ; Tue, 24 Jan 2006 14:51:10 +0900 (JST) To: "ltru@ietf.org" From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Date: Tue, 24 Jan 2006 14:51:08 +0900 Message-ID: User-Agent: Opera M2/8.5 (Win32, build 7702) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Subject: [Ltru] URI for BCP 47 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi, I am looking for a stable URI to cite BCP 47. Any proposals? Thanks, Felix _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 24 01:31:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Hid-0001RA-KY; Tue, 24 Jan 2006 01:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Hic-0001R5-1K for ltru@megatron.ietf.org; Tue, 24 Jan 2006 01:31:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12010 for ; Tue, 24 Jan 2006 01:30:23 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Hs6-0003y1-2g for ltru@ietf.org; Tue, 24 Jan 2006 01:41:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1F1HiZ-0001JX-ID; Tue, 24 Jan 2006 01:31:51 -0500 Date: Tue, 24 Jan 2006 01:31:51 -0500 To: Felix Sasaki Subject: Re: [Ltru] URI for BCP 47 Message-ID: <20060124063151.GB13005@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Felix Sasaki scripsit: > Hi, > > I am looking for a stable URI to cite BCP 47. Any proposals? RFC 2648 says it's urn:ietf:bcp:47 -- John Cowan http://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 24 01:56:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1I6Z-0000ZB-DZ; Tue, 24 Jan 2006 01:56:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1I6Y-0000Z6-F6 for ltru@megatron.ietf.org; Tue, 24 Jan 2006 01:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13695 for ; Tue, 24 Jan 2006 01:55:08 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1IG1-0004oU-JG for ltru@ietf.org; Tue, 24 Jan 2006 02:06:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B02024669; Tue, 24 Jan 2006 15:56:22 +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 28968-03; Tue, 24 Jan 2006 15:56:22 +0900 (JST) Received: from ibm-60d333fc0ec.mag.keio.ac.jp (dhcp-246-65.mag.keio.ac.jp [133.27.246.65]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 690A4466C; Tue, 24 Jan 2006 15:56:22 +0900 (JST) Date: Tue, 24 Jan 2006 15:56:20 +0900 To: "John Cowan" Subject: Re: [Ltru] URI for BCP 47 References: <20060124063151.GB13005@ccil.org> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: <20060124063151.GB13005@ccil.org> User-Agent: Opera M2/8.5 (Win32, build 7702) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Tue, 24 Jan 2006 15:31:51 +0900, John Cowan wrote: > Felix Sasaki scripsit: >> Hi, >> >> I am looking for a stable URI to cite BCP 47. Any proposals? > > RFC 2648 says it's urn:ietf:bcp:47 Thanks a lot. I know that URNs are used for persistent labeling. But a =20 persistent URI would be nicer, see http://www.w3.org/Provider/Style/URI =20 (look for "I didn't think URLs have to be persistent - that was URNs."). Regards, Felix. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 24 02:16:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IPr-0006oz-0m; Tue, 24 Jan 2006 02:16:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IPp-0006o5-0i for ltru@megatron.ietf.org; Tue, 24 Jan 2006 02:16:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14792 for ; Tue, 24 Jan 2006 02:15:02 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1IZJ-0005Qd-Eh for ltru@ietf.org; Tue, 24 Jan 2006 02:26:22 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1F1IPm-0002WS-VN; Tue, 24 Jan 2006 02:16:30 -0500 Date: Tue, 24 Jan 2006 02:16:30 -0500 To: Felix Sasaki Subject: Re: [Ltru] URI for BCP 47 Message-ID: <20060124071630.GC13005@ccil.org> References: <20060124063151.GB13005@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Felix Sasaki scripsit: > Thanks a lot. I know that URNs are used for persistent labeling. But a > persistent URI would be nicer, see http://www.w3.org/Provider/Style/URI > (look for "I didn't think URLs have to be persistent - that was URNs."). In that case, ftp://ftp.isi.edu/in-notes/bcp/bcp47.txt has been persistent since at least RFC 1766. http://www.rfc-editor.org/rfc/bcp/bcp47.txt is not as old, but may have more authority. -- John Cowan cowan@ccil.org www.reutershealth.com www.ccil.org/~cowan There was an old man Said with a laugh, "I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two." --Emmet O'Brien _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 24 02:21:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IU9-00081X-AQ; Tue, 24 Jan 2006 02:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IU7-00081S-Qq for ltru@megatron.ietf.org; Tue, 24 Jan 2006 02:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14995 for ; Tue, 24 Jan 2006 02:19:29 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Idb-0005Z8-8v for ltru@ietf.org; Tue, 24 Jan 2006 02:30:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 45F75466B; Tue, 24 Jan 2006 16:20:51 +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 28975-13; Tue, 24 Jan 2006 16:20:51 +0900 (JST) Received: from ibm-60d333fc0ec.mag.keio.ac.jp (dhcp-246-65.mag.keio.ac.jp [133.27.246.65]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 052DC4430; Tue, 24 Jan 2006 16:20:50 +0900 (JST) To: "John Cowan" Subject: Re: [Ltru] URI for BCP 47 References: <20060124063151.GB13005@ccil.org> <20060124071630.GC13005@ccil.org> Message-ID: From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Date: Tue, 24 Jan 2006 16:20:47 +0900 In-Reply-To: <20060124071630.GC13005@ccil.org> User-Agent: Opera M2/8.5 (Win32, build 7702) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Tue, 24 Jan 2006 16:16:30 +0900, John Cowan wrote: > Felix Sasaki scripsit: > >> Thanks a lot. I know that URNs are used for persistent labeling. But a >> persistent URI would be nicer, see http://www.w3.org/Provider/Style/UR= I >> (look for "I didn't think URLs have to be persistent - that was URNs."= ). > > In that case, ftp://ftp.isi.edu/in-notes/bcp/bcp47.txt has been =20 > persistent > since at least RFC 1766. http://www.rfc-editor.org/rfc/bcp/bcp47.txt > is not as old, but may have more authority. > Thanks, that helps! Regards, Felix. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 24 08:33:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OIB-0006Sb-6V; Tue, 24 Jan 2006 08:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OI9-0006SO-Cv for ltru@megatron.ietf.org; Tue, 24 Jan 2006 08:33:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12065 for ; Tue, 24 Jan 2006 08:31:30 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ORg-0002EU-IA for ltru@ietf.org; Tue, 24 Jan 2006 08:42:53 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1F1OHw-0008QB-Up; Tue, 24 Jan 2006 05:32:49 -0800 Message-Id: <6.2.3.4.2.20060124131203.046b11c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 24 Jan 2006 13:35:18 +0100 To: "Felix Sasaki" , "John Cowan" From: r&d afrac Subject: Re: [Ltru] URI for BCP 47 In-Reply-To: References: <20060124063151.GB13005@ccil.org> <20060124071630.GC13005@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-593C1AAC X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org 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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 08:20 24/01/2006, Felix Sasaki wrote: >On Tue, 24 Jan 2006 16:16:30 +0900, John Cowan wrote: > >>Felix Sasaki scripsit: >> >>>Thanks a lot. I know that URNs are used for persistent labeling. But a >>>persistent URI would be nicer, see http://www.w3.org/Provider/Style/URI >>>(look for "I didn't think URLs have to be persistent - that was URNs."). >> >>In that case, ftp://ftp.isi.edu/in-notes/bcp/bcp47.txt has been >>persistent >>since at least RFC 1766. http://www.rfc-editor.org/rfc/bcp/bcp47.txt >>is not as old, but may have more authority. > >Thanks, that helps! Felix, I would strongly advise http://www.rfc-editor.org/rfc/bcp/bcp47.txt. This is the original document. And therefore the authoritative source whatever happens in the future. jfc PS. You will note that the document is currently under IESG appeal. This discussion of this appeal may have risen additional concerns and operational solutions. The IESG may either chose to consider them or prefer an architectural guidance through an appeal to the IAB. This currently concerns the architext, the language coding and the security issues. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 25 04:24:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gsr-00068A-Or; Wed, 25 Jan 2006 04:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gso-00067w-OS for ltru@megatron.ietf.org; Wed, 25 Jan 2006 04:24:08 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23747 for ; Wed, 25 Jan 2006 04:22:34 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F1gsi-0005lc-AG for ltru@lists.ietf.org; Wed, 25 Jan 2006 10:24:00 +0100 Received: from pd9fba921.dip0.t-ipconnect.de ([217.251.169.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Jan 2006 10:24:00 +0100 Received: from nobody by pd9fba921.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Jan 2006 10:24:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 25 Jan 2006 10:16:41 +0100 Organization: Lines: 7 Message-ID: <43D741F9.7350@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba921.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: URI for BCP 47 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Felix Sasaki wrote: > I am looking for a stable URI to cite BCP 47. Any proposals? Try for a HTML version, bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 27 01:59:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2NZY-0004zE-3E; Fri, 27 Jan 2006 01:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2NZV-0004xp-0q; Fri, 27 Jan 2006 01:59:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14000; Fri, 27 Jan 2006 01:57:28 -0500 (EST) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2NjN-0002xE-Is; Fri, 27 Jan 2006 02:09:15 -0500 Received: from mswamui-swiss.atl.sa.earthlink.net ([209.86.224.50]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1F2NZE-0005Cz-00; Fri, 27 Jan 2006 01:58:44 -0500 Message-ID: <9733494.1138345124723.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> Date: Fri, 27 Jan 2006 13:58:44 +0700 (GMT+07:00) From: Randy Presuhn To: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - The message is being forwarded to both the ltru and disman working groups. If you're thinking about submitting an I-D for consideration in either group, please keep it in mind. Note also that, at this time, there are no plans for either group to meet in Dallas. If you think there will be a need for a face-to-face meeting, please post any agenda proposals to the appropriate WG mailing list. Randy ltru co-chair disman chair >From: ietf-secretariat@ietf.org >Sent: Jan 27, 2006 12:00 PM >To: ietf-announce@ietf.org >Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA > > >There are two (2) Internet-Draft cutoff dates for the 65th >IETF Meeting in Dallas, TX, USA: > >February 27th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >February 27th 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, >February 20th at 9:00 AM ET. > >March 6th: 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, March 6th 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, March 20th 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 65th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_65.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 Tue Jan 31 23:43:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F49px-0003CC-OO; Tue, 31 Jan 2006 23:43:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F49pw-000322-1E for ltru@megatron.ietf.org; Tue, 31 Jan 2006 23:43:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06331 for ; Tue, 31 Jan 2006 23:40:49 -0500 (EST) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4A08-0004zF-9n for ltru@ietf.org; Tue, 31 Jan 2006 23:53:53 -0500 Received: from mswamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1F49oz-0007PA-00 for ltru@ietf.org; Tue, 31 Jan 2006 23:42:21 -0500 Message-ID: <12459347.1138768941524.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Wed, 1 Feb 2006 11:42:21 +0700 (GMT+07:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ltru] Issue 1039 on administration of ietf-languages@iana.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... Given the IAB decision announced in http://www1.ietf.org/mail-archive/web/ietf/current/msg40406.html , I'd like to know whether there is any interest in producing, after the ltru WG completes its current deliverables, an update to the registry draft to address issue #1039? (issue tracker at https://rt.psg.com/ with user and password "ietf") Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru